No split payment, o imposto sai da venda antes do dinheiro entrar na conta de quem vendeu

Uma empresa vende um lote de produtos e emite a nota fiscal pelo valor cheio. Alguns dias depois, o extrato bancário mostra um valor menor do que o esperado, e o time financeiro abre uma investigação de divergência. No regime de split payment da LC 214/2025, essa diferença não é erro nem atraso: é o IBS e a CBS já segregados pelo prestador de pagamento antes de o dinheiro chegar na conta da empresa que vendeu. Na nossa leitura, é uma mudança de ordem que parece pequena no papel e tem efeito grande na rotina de conciliação: o imposto deixa de ser algo que a empresa calcula e recolhe depois, e passa a ser algo que ela recebe já descontado, no mesmo instante da liquidação.

O procedimento padrão: segregação antes da disponibilização

O art. 32 da LC 214/2025 descreve o procedimento padrão do split payment, e é no lançamento de recebimento do SAP (FI, conciliação bancária) que essa segregação precisa ser reconhecida como componente esperado do valor líquido, não como divergência a investigar. O fornecedor (quem vende) inclui no documento fiscal eletrônico informações que vinculam a operação à transação de pagamento e identificam os valores de IBS e CBS incidentes. O §3º do mesmo artigo é o núcleo do mecanismo: "Antes da disponibilização dos recursos ao fornecedor, o prestador de serviço de pagamento ou a instituição operadora do sistema de pagamento deverá, com base nas informações recebidas, consultar sistema do Comitê Gestor do IBS e da RFB sobre os valores a serem segregados e recolhidos." O verbo importa: "antes". O prestador de pagamento não repassa o valor bruto da venda para depois a empresa recolher o imposto; ele consulta o sistema do Comitê Gestor, calcula o valor a segregar, e só então disponibiliza o restante ao fornecedor.

O valor segregado é uma diferença, não o total do imposto

O próprio §3º detalha que o valor segregado corresponde à diferença positiva entre os débitos de IBS e CBS destacados no documento fiscal e as parcelas desses débitos que já tiverem sido extintas por outra via (por exemplo, um crédito compensado). Isso significa que o valor retido na liquidação não é necessariamente igual ao imposto total da nota: pode ser menor, se parte do débito já tiver sido extinta antes da liquidação financeira acontecer. Para o time de conciliação bancária, isso quer dizer que o valor líquido recebido não é uma fração fixa e previsível do valor bruto da venda: varia conforme o histórico de extinção de débito daquela operação específica.

Uma diferença entre o valor da nota e o valor que chegou na conta deixa de ser sinal de erro. Passa a ser, por padrão, o imposto que o próprio sistema de pagamento já recolheu antes de a empresa ver o dinheiro.

Quem monta a informação que conecta a nota ao pagamento

O §1º do art. 32, na redação dada pela LC 227/2026, atribui ao originador da transação de pagamento a obrigação de transmitir ao prestador de serviço de pagamento as informações que vinculam a operação à transação e identificam os valores de IBS/CBS. O §2º-A acrescenta uma hipótese relevante: quando a transação de pagamento é iniciada pelo recebedor (o vendedor, cobrando do comprador), ele pode optar por não transmitir essa vinculação ao prestador de pagamento, hipótese em que o próprio fornecedor ou a plataforma digital precisa incluir, no documento fiscal eletrônico, a informação que permite essa vinculação. Ou seja: em determinados arranjos de cobrança, é a nota fiscal emitida pelo vendedor que carrega o dado que decide quanto vai ser retido na liquidação, não um sistema externo à empresa.

Isso muda o risco de uma nota fiscal mal emitida. Um erro na vinculação entre a operação e a transação de pagamento, ou um valor de IBS/CBS destacado incorretamente no documento fiscal, deixa de ser só um problema de conformidade fiscal isolado: passa a afetar diretamente o valor que chega na conta corrente da empresa naquele recebimento específico, com efeito imediato de caixa, não só um risco de autuação futura.

Quando a consulta em tempo real falha: o dinheiro pode ficar até 3 dias úteis parado

O §4º do art. 32 trata do cenário em que a consulta ao sistema do Comitê Gestor, prevista no §3º, não pode ser feita no momento da liquidação. Nesse caso, o prestador de pagamento segrega e recolhe o valor de IBS/CBS com base só nas informações recebidas (sem a confirmação em tempo real), e o Comitê Gestor e a RFB fazem o cálculo correto depois, transferindo ao fornecedor, "em até 3 (três) dias úteis", os valores que excederem o montante realmente devido. Isso significa que, em contingência, o valor líquido que chega na conta no dia da venda pode estar segregado a mais do que o devido, com a diferença retornando só depois, dentro de uma janela de até três dias úteis.

Para uma empresa que projeta caixa diário com base no valor líquido esperado de cada recebimento, esse prazo de contingência não é um detalhe de bastidor: é uma variável real de fluxo de caixa. Uma operação de maior valor, liquidada num dia em que o sistema do Comitê Gestor está indisponível, pode reter mais recursos do que o necessário por até três dias úteis, sem que isso apareça como pendência em nenhum relatório até alguém ir conferir o extrato linha a linha contra a nota original.

Quando quem transmite a informação é a plataforma, não a própria empresa

O §2º do art. 32 lista quem pode transmitir ao prestador de pagamento as informações de vinculação e valor de IBS/CBS: o fornecedor, a plataforma digital (nas operações realizadas por seu intermédio, nos termos do art. 22 da mesma lei) ou outra pessoa ou entidade sem personalidade jurídica que receber o pagamento. Para uma indústria ou distribuidora que vende também por marketplace ou plataforma de pagamento de terceiro, isso significa que o dado que decide quanto vai ser segregado na liquidação de parte das vendas não é produzido pela própria empresa, é produzido pela plataforma. A conciliação bancária, nesse canal, depende da qualidade de um dado que a empresa não controla diretamente.

Isso cria uma diferença prática entre canais de venda dentro da mesma empresa: o time financeiro que reconcilia venda direta (nota emitida pela própria empresa, informação de vinculação sob controle interno) enfrenta um processo, e o que reconcilia venda via plataforma enfrenta outro, com uma fonte de erro adicional fora do próprio SAP. Uma rotina de conciliação que trata todos os canais de venda como iguais, sem diferenciar de onde vem a informação que gerou a segregação, tende a demorar mais para identificar a causa real de uma divergência quando ela aparece num canal de plataforma.

O crédito do comprador não muda, o caixa do vendedor sim

Vale separar dois efeitos que o split payment produz ao mesmo tempo, e que não se confundem. Do lado do comprador (quando ele é contribuinte do regime regular), o crédito de IBS/CBS sobre a operação segue as regras gerais de apropriação já tratadas pelo art. 47 desta mesma lei, sem alteração pelo mecanismo de split payment em si. Do lado do vendedor, o efeito é puramente de caixa e de conciliação: o valor que ele recebe na liquidação já vem líquido do imposto, o que muda a forma como o recebimento precisa ser lançado e batido contra a nota fiscal emitida. Um sistema que trata o valor recebido como se fosse igual ao valor bruto da venda, sem reconhecer a segregação, vai gerar divergência de conciliação em praticamente toda operação sujeita a split payment.

O que isso exige da conciliação bancária e do registro de recebimento

Em diagnósticos de operação fiscal em ambiente SAP, um padrão recorrente é a conciliação bancária tratando toda diferença entre o valor da fatura e o valor recebido como uma divergência a investigar, porque foi assim que ela sempre funcionou antes do split payment existir. Com split payment em operação, uma parcela relevante dessas diferenças deixa de ser exceção e passa a ser a regra: o valor segregado de IBS/CBS precisa ser reconhecido, no próprio lançamento de recebimento, como o imposto já recolhido na fonte, não como um valor a esclarecer.

Isso exige que o lançamento de recebimento no SAP (FI, conciliação bancária) tenha um campo ou uma regra que decomponha automaticamente o valor líquido recebido em duas partes: o valor da venda propriamente dito e o valor de IBS/CBS já segregado na liquidação, cada um batendo com a informação correspondente da nota fiscal. Sem essa decomposição automática, o time financeiro depende de conferência manual, operação por operação, para saber se o valor recebido está correto ou se há uma divergência real por trás da diferença.

A pergunta que sustenta a resposta, se o caixa não bater

Para o CFO ou Diretor Fiscal de uma empresa que vende com pagamento eletrônico sujeito a split payment, a pergunta central é direta: o processo de conciliação bancária reconhece, hoje, o valor de IBS/CBS segregado na liquidação como componente esperado do recebimento, ou toda diferença entre o valor da nota e o valor recebido ainda é tratada como divergência a investigar caso a caso? Sem essa distinção automatizada, o time financeiro perde tempo revalidando manualmente algo que a própria lei já explica, e corre o risco de não perceber quando uma diferença é, de fato, um erro real de vinculação entre nota e pagamento.

A segunda pergunta é sobre a contingência do §4º: existe visibilidade sobre quantas operações, em um determinado período, tiveram a segregação calculada sem a consulta em tempo real ao sistema do Comitê Gestor, e sobre se o retorno do valor excedente dentro do prazo de até 3 dias úteis está sendo efetivamente monitorado, ou se esse crédito de caixa simplesmente se perde no meio de outros recebimentos? Uma resposta clara para as duas perguntas, com responsável nomeado, é a diferença entre presumir que o caixa recebido está certo porque a venda foi processada sem erro visível, e conseguir provar, operação por operação, o que foi segregado, por que, e quando o excedente retornou.

Vale registrar o que essa revisão não exige: não é necessário reformular todo o processo de conciliação de uma vez. É possível, hoje, mapear quais canais de venda e quais prestadores de pagamento operam sob split payment, confirmar se a nota fiscal emitida carrega corretamente a informação de vinculação exigida pelo art. 32, e ajustar o lançamento de recebimento no SAP para decompor, desde a origem, valor de venda e valor de imposto segregado. Esse ajuste evita presumir que uma diferença de caixa é sempre exceção, quando, sob split payment, ela é o comportamento esperado do sistema.