Split Payment não muda a alíquota. Muda quem segura o seu dinheiro e por quanto tempo.

O split payment vai entrar na operação pelo fiscal. O impacto vai aparecer no caixa.

Essa sequência é o que torna o tema perigoso para o Controller que está acompanhando a Reforma Tributária (Emenda Constitucional 132/2023) como pauta do time fiscal. Quando o impacto aparecer no fluxo, o modelo de capital de giro, o timing de crédito e o processo de reconciliação já vão estar calibrados para uma realidade que não existe mais.

Split payment não é uma mudança de alíquota. É uma mudança de quem segura o dinheiro e por quanto tempo. E essa diferença tem consequência direta na posição de caixa, na gestão de crédito e na capacidade de o Controller entregar projeção financeira confiável ao CFO.

O que o split payment muda de forma estrutural

No modelo tributário atual, a empresa vendedora recebe o valor integral da transação e é responsável por recolher o imposto no prazo estabelecido. Existe uma janela, variável por imposto e por regime, entre o recebimento do valor e o recolhimento. Essa janela é capital de giro.

O split payment elimina essa janela para os tributos que ele abrange. No modelo previsto para IBS e CBS, parte do valor pago pelo comprador é retida automaticamente no momento da liquidação da transação pelo intermediário financeiro ou pelo sistema de pagamento, e direcionada diretamente ao Fisco. A empresa vendedora recebe o valor líquido de imposto.

Isso muda três coisas ao mesmo tempo.

A primeira é a posição de caixa. O valor que hoje entra integral e é recolhido depois deixa de entrar integral. Empresa com volume relevante de vendas sujeitas ao IBS/CBS no regime de split payment vai ter fluxo de caixa diferente do atual, não por inadimplência ou sazonalidade, mas por design do novo regime.

A segunda é o timing de crédito. O crédito de IBS/CBS ao qual a empresa adquirente tem direito depende da confirmação de que o imposto foi efetivamente recolhido pelo fornecedor. No modelo atual, esse controle é declaratório. No modelo de split payment, o recolhimento é automático e rastreável, o que muda a dinâmica de aproveitamento de crédito e o processo de validação que o Controller precisa manter.

A terceira é o modelo de reconciliação. Conciliar posição fiscal com posição financeira num ambiente de split payment é um processo diferente do atual. O imposto não passa mais pelo caixa da empresa antes de ir ao Fisco. O que passa pelo caixa é o valor líquido. Modelo de conciliação que não foi redesenhado para essa realidade vai gerar divergência permanente entre o que o fiscal apura e o que a Controladoria reporta.

Por que o modelo atual de controle de crédito não funciona para o novo regime

A maioria das operações hoje controla crédito de PIS e COFINS por competência, com apuração mensal e aproveitamento no período subsequente. O processo de validação de crédito envolve cruzamento de notas fiscais de entrada com apuração do fornecedor, processamento no SPED e escrituração no SPED Contribuições.

Esse processo pressupõe que o crédito precisa ser “perseguido”: a empresa adquirente não sabe automaticamente se o fornecedor recolheu o imposto que deveria. Ela precisa acompanhar, cruzar e validar.

O split payment muda essa premissa. Quando o recolhimento é automático e rastreável no momento da transação, o crédito potencialmente tem confirmação mais imediata. Mas o processo de validação, aproveitamento e escrituração no SAP precisa ser redesenhado para capturar essa informação de forma estruturada, não manual.

Controller que chegar no regime pleno do IBS/CBS com o mesmo processo de controle de crédito de PIS/COFINS vai ter dois problemas simultâneos: o processo não vai capturar a informação do jeito certo, e o tempo de correção não vai existir porque a operação já vai estar rodando no novo regime.

O procedimento simplificado, e por que ninguém escolhe cair nele

A LC 227/2026 reorganizou o split payment em dois procedimentos, e não três: o padrão, do art. 32, e o simplificado, do art. 33. A diferença entre eles decide quanto do seu caixa fica retido, e o caminho para cair no segundo é mais curto do que parece.

No procedimento padrão, quem origina a transação de pagamento transmite ao prestador de serviço de pagamento as informações que permitem vincular a operação ao pagamento e identificar os valores de IBS e CBS incidentes. O prestador segrega exatamente esses valores. O que é retido é o imposto real.

No simplificado, não. O § 1º do art. 33 determina que os valores segregados sejam calculados com base em percentual preestabelecido do valor da operação, fixado pelo Comitê Gestor do IBS e pela RFB. E o § 2º, III, diz em letra expressa o que isso significa: esse percentual não guardará relação com o valor dos débitos de IBS e CBS efetivamente incidentes sobre a operação. Ele pode ser diferenciado por setor ou por contribuinte, a partir de metodologia uniforme divulgada previamente, mas continua sendo uma estimativa, não a conta.

Aí está o ponto que muda o desenho do sistema. O § 2º-A, incluído pela LC 227/2026, determina que originar uma transação de pagamento sem a identificação dos valores de IBS e CBS implica opção pelo procedimento simplificado. Não é uma escolha assinada em algum lugar. É consequência automática de um campo que não foi preenchido.

Traduzindo para o ambiente: se a informação que sai do seu SAP não chega ao meio de pagamento com os valores identificados, a empresa não fica de fora do split payment. Ela entra pela porta em que a retenção é calculada por percentual de tabela, sem relação com o imposto que ela de fato deve. Numa operação com margem apertada ou com muito crédito a compensar, a diferença entre reter o imposto real e reter um percentual médio de setor é caixa parado que ninguém orçou.

O que o SAP precisa absorver que ainda não está mapeado na maioria dos projetos

A integração entre o mecanismo de split payment e o SAP tem dimensões que poucos projetos de Reforma estão mapeando com profundidade suficiente.

A primeira é o fluxo de caixa no SAP FI. A liquidação de uma transação com split payment gera um fluxo diferente do atual: o valor que entra na conta bancária já é líquido de imposto. O SAP precisa ser parametrizado para reconhecer e registrar essa diferença de forma que a posição de caixa no sistema reflita a realidade, não o valor bruto antes da retenção.

A segunda é a integração com a apuração de IBS/CBS. O valor retido via split payment precisa ser registrado como imposto já recolhido na apuração do período correspondente. Se essa integração não existir por design no SAP, o time fiscal vai precisar ajustar manualmente a cada período, criando o tipo de processo paralelo que o split payment foi criado para eliminar.

A terceira é o controle de crédito de entrada. O modelo de aproveitamento de crédito de IBS/CBS no regime de split payment tem características diferentes do PIS/COFINS atual. O SAP precisa absorver essas regras de forma estruturada, não como customização provisória que vai ser revisada depois.

A quarta é o modelo de projeção de caixa. Se o sistema de tesouraria ou o módulo de fluxo de caixa do SAP não for recalibrado para considerar que o valor líquido de imposto é o que vai entrar na conta, as projeções de caixa vão ter desvio sistemático até que alguém identifique e corrija a premissa. Esse desvio vai aparecer como “diferença inexplicada” no fechamento, que é exatamente o tipo de problema que o Controller não quer estar explicando ao CFO mês a mês.

As perguntas que o Controller precisa responder antes do regime pleno

1. O modelo de projeção de caixa da empresa considera o impacto do split payment no fluxo de recebimentos? Se o modelo projetou o próximo ciclo com o mesmo padrão de entrada bruta de hoje, a projeção vai estar errada quando o regime pleno começar.
2. O processo de controle e aproveitamento de crédito de IBS/CBS foi redesenhado para o novo modelo de recolhimento automático? Se o processo atual replica a lógica do PIS/COFINS, vai gerar divergência entre o que foi retido na transação e o que foi registrado como crédito aproveitável.
3. A parametrização do SAP FI para recebimentos sujeitos ao split payment foi mapeada e testada no período de coexistência? Se o SAP ainda está processando o valor bruto e o ajuste está sendo feito manualmente, o processo vai escalar o problema quando o volume aumentar no regime pleno.
4. Quarta: o time de Controladoria e o time fiscal estão usando o mesmo modelo de reconciliação? Se fiscal está apurando com base no valor retido via split payment e Controladoria está reconciliando com base no valor bruto da transação, as duas versões da verdade já existem. Só ainda não apareceram no fechamento com força suficiente para exigir explicação.
5. Existe um responsável definido para o redesenho do modelo de capital de giro considerando o split payment? Não um responsável por "acompanhar o tema". Um responsável por entregar o modelo revisado com impacto em caixa quantificado antes do regime pleno.

O que funciona quando o diagnóstico é feito antes do impacto aparecer no fechamento

Empresa que mapeou o impacto do split payment no fluxo de caixa antes do regime pleno tem três vantagens práticas. Primeira: a projeção de caixa do período de transição vai refletir a realidade, não uma premissa desatualizada. Segunda: o processo de aproveitamento de crédito vai estar operacional quando o volume de IBS/CBS em regime pleno começar. Terceira: o time de Controladoria e o time fiscal vão estar usando o mesmo modelo de reconciliação, o que elimina a divergência que aparece no fechamento quando dois modelos diferentes estão sendo aplicados ao mesmo dado.

O que vejo nos diagnósticos que realizamos: a maioria das empresas mapeou o split payment como tema regulatório. Poucas mapearam como redesenho de modelo financeiro com impacto em SAP FI, capital de giro e processo de reconciliação. A diferença entre os dois mapeamentos vai aparecer no primeiro fechamento em que o split payment já estiver em regime pleno e o modelo antigo ainda estiver operando.

Esse mesmo mecanismo de split payment é o centro de outro ponto crítico da Reforma: o impacto direto no capital de giro que a maioria dos modelos financeiros ainda não incorporou, e conecta diretamente com a mudança de apuração assistida, que desloca o risco de calcular para contestar no prazoNa DFSpro, o diagnóstico que realizamos antes do regime pleno do IBS/CBS inclui especificamente o impacto do split payment no modelo financeiro, na parametrização SAP e no processo de reconciliação. Se faz sentido mapear isso antes de o fluxo de caixa mostrar a diferença, o Diagnóstico Fiscal Estruturado é o caminho.

Artigo escrito por Emanuel Kaufman, Head of Business da DFSpro. Especialista em operações fiscais críticas em SAP e Guepardo Tax. Curitiba, 2026. DFSpro