Split payment e ERP: o que as empresas precisam adaptar nos sistemas

Split payment e ERP: o que os sistemas das empresas precisarão controlar

Emitir corretamente IBS e CBS será apenas o começo. Com o split payment, empresas precisarão integrar documento fiscal, contas a receber, pagamento, valor segregado, banco e apuração assistida sem criar diferenças artificiais

Por Cleiton Celini e Gledson Alves, sócios e contadores da AUDICONT Contabilidade

Uma empresa pode estar preparada para calcular IBS e CBS na nota fiscal e, mesmo assim, não estar preparada para o split payment.

O problema aparece depois da emissão.

O cliente paga uma venda. Parte do valor pode ser destinada à extinção dos novos tributos durante a liquidação financeira. O fornecedor recebe o valor líquido. O contas a receber precisa reconhecer que o cliente quitou a obrigação. O fiscal precisa identificar o que aconteceu com IBS e CBS. A contabilidade precisa explicar a liquidação. E o ERP precisa fazer todas essas informações apontarem para a mesma operação.

Se essa ligação falhar, uma transação regular pode aparecer internamente como inadimplência, diferença bancária, divergência fiscal ou saldo contábil sem explicação.

Na matéria anterior desta série, sobre conciliação entre nota fiscal, pagamento e valor recebido, mostramos que o valor pago pelo cliente e o valor efetivamente disponibilizado ao fornecedor podem não ser iguais.

A próxima questão é operacional:

o sistema da empresa conseguirá explicar automaticamente essa diferença?

A resposta dependerá menos de um novo campo na nota fiscal e mais da capacidade de o ERP acompanhar a operação do início ao fim.

Estar preparado para IBS e CBS não é o mesmo que estar preparado para o split payment

A adaptação à Reforma Tributária costuma começar pelo documento fiscal.

Empresas e fornecedores de software estão revisando:

• cadastro de produtos e serviços;
• classificação tributária;
• alíquotas;
• reduções;
• regimes diferenciados;
• destaque de IBS e CBS;
• novos campos dos documentos fiscais.

Tudo isso é necessário.

Mas o split payment acrescenta uma etapa que ocorre depois da emissão da nota e no momento da liquidação financeira.

A LC nº 214/2025 prevê o recolhimento na liquidação financeira como modalidade de extinção dos débitos de IBS e CBS. A regulamentação do mecanismo e a documentação da Plataforma Pública do Split Payment avançam na vinculação entre operação fiscal, transação de pagamento e valor destinado aos tributos.

Por isso, um ERP preparado apenas para calcular IBS e CBS pode ainda não estar preparado para controlar o que acontece quando o cliente paga.

A AUDICONT Contabilidade já destacou em matéria anterior que IBS e CBS na nota fiscal não eliminam a necessidade de conferência fiscal.

Com o split payment, essa necessidade de conferência alcança também o financeiro.

O primeiro desafio será ligar pagamento e operação

Em uma empresa com poucas transações, identificar qual pagamento corresponde a determinada nota pode parecer simples.

Em uma operação de maior volume, o cenário muda rapidamente.

Uma empresa pode ter:

• milhares de documentos fiscais por dia;
• clientes pagando várias notas em uma única transferência;
• uma mesma nota liquidada em várias parcelas;
• recebimentos por Pix;
• boletos;
• cartões;
• marketplaces;
• antecipações;
• cancelamentos;
• devoluções.

Nesse ambiente, o crédito bancário isolado não explica a operação.

O sistema precisa saber:

qual pagamento está liquidando qual documento fiscal.

Esse vínculo ganha importância porque o split payment não foi desenhado apenas como um recolhimento genérico sobre o movimento financeiro da empresa. O procedimento depende de informações capazes de relacionar a transação financeira à operação correspondente.

Sem essa rastreabilidade, a conciliação começa errada na origem.

O ERP terá de separar três conceitos que muitas empresas ainda tratam como um só

Com o novo modelo, será importante distinguir:

valor faturado

valor pago pelo cliente

valor efetivamente disponibilizado ao fornecedor

Considere um exemplo exclusivamente didático:

Nota fiscal: R$ 100.000
Pagamento realizado pelo cliente: R$ 100.000
Valor efetivamente segregado para IBS/CBS: R$ X
Valor líquido disponibilizado à empresa: R$ 100.000 menos R$ X

O cliente pode ter quitado integralmente sua obrigação.

O fato de o banco apresentar valor inferior a R$ 100 mil não significa, por si só, que exista saldo em aberto.

Esse é o ponto central da matéria anterior sobre conciliação do split payment.

Agora surge uma exigência adicional: o ERP precisa registrar por que existe a diferença.

O sistema não pode transformar split payment em inadimplência

Imagine uma duplicata de R$ 100 mil.

O cliente paga integralmente.

Uma parcela da liquidação segue para a extinção de IBS e CBS e somente o valor líquido fica disponível na conta da empresa.

Se a baixa do título estiver configurada apenas para localizar no banco um crédito idêntico ao valor da duplicata, o ERP poderá deixar um saldo residual indevido.

A partir desse erro, outras consequências podem aparecer:

• cobrança automática de valor já pago;
• bloqueio indevido de limite de crédito;
• aging de clientes incorreto;
• divergência na conciliação bancária;
• contas a receber superavaliado;
• diferença contábil;
• retrabalho entre financeiro e fiscal.

Nesse cenário, o cliente não está inadimplente.

O sistema é que não conseguiu interpretar a forma pela qual a obrigação foi liquidada.

O valor do tributo destacado e o valor do split não devem ser tratados como sinônimos

Outro ponto importante é evitar uma simplificação tecnológica.

O ERP não deveria partir automaticamente da premissa:

valor da operação × alíquota = valor efetivamente segregado.

O valor tributário da operação e o montante efetivamente utilizado pelo split payment não são necessariamente conceitos idênticos.

A regulamentação prevê procedimentos próprios para determinar aquilo que efetivamente precisa ser segregado na liquidação, considerando a situação do débito e as regras aplicáveis à operação.

Na prática, a empresa precisará distinguir:

IBS e CBS calculados

de

IBS e CBS efetivamente extintos naquela liquidação financeira.

A conciliação deve trabalhar com aquilo que realmente ocorreu, e não apenas com uma expectativa calculada pelo ERP.

O valor líquido recebido precisa continuar existindo como informação própria

A empresa também não pode perder a dimensão financeira real da transação.

Uma mesma venda pode produzir simultaneamente:

R$ 100 mil faturados

R$ 100 mil pagos pelo cliente

R$ X destinados aos tributos

R$ 100 mil menos R$ X disponíveis no banco

Todos os números são verdadeiros.

Cada um responde a uma pergunta diferente.

O problema surge quando um único campo denominado "valor recebido" tenta representar todos eles.

A estrutura dos relatórios gerenciais terá de permitir que a empresa explique claramente:

quanto vendeu;

quanto o cliente pagou;

quanto foi destinado ao split;

quanto efetivamente entrou em disponibilidade.

Essa necessidade também se conecta à matéria já publicada sobre como a Reforma Tributária exige revisão dos controles contábeis.

Banco conciliado não significa necessariamente tributo conciliado

Há ainda uma camada que não aparece no extrato.

O financeiro pode conseguir explicar perfeitamente por que determinado valor líquido entrou na conta.

Mesmo assim, será necessário verificar se o efeito tributário correspondente também foi reconhecido corretamente.

A pergunta passa a ser:

o valor que o financeiro identifica como destinado ao IBS e à CBS aparece na apuração como extinção do débito correspondente?

Esse controle cria uma nova conciliação:

ERP financeiro

↓

informação do split

↓

apuração assistida

Se o banco fechar e a apuração não, a operação continua divergente.

É por isso que o split payment aproxima áreas que tradicionalmente poderiam trabalhar com rotinas relativamente independentes.

Pagamentos parciais podem revelar rapidamente as limitações do ERP

Considere uma nota fiscal de R$ 100 mil liquidada em três pagamentos:

R$ 30 mil

R$ 30 mil

R$ 40 mil

O ERP terá de manter esses três eventos ligados à mesma operação.

Agora imagine o cenário inverso:

um pagamento de R$ 300 mil liquida seis notas diferentes.

O sistema precisará decompor a liquidação e preservar a rastreabilidade de cada parcela.

Esses casos deixam claro que a adaptação não pode ser construída apenas para o exemplo mais simples:

uma nota → um pagamento → um split.

A rotina empresarial real costuma ser muito mais complexa.

Cancelamentos e devoluções exigirão que o histórico não seja perdido

Na primeira matéria desta série, mostramos que uma venda desfeita depois da ocorrência do split pode produzir estornos, novos débitos e transferências posteriores.

Isso significa que a rastreabilidade precisa sobreviver ao cancelamento.

O ERP deve conseguir preservar a conexão entre:

venda original

↓

documento fiscal

↓

pagamento

↓

valor segregado

↓

cancelamento ou devolução

↓

efeito na apuração

↓

eventual transferência posterior

Se o sistema simplesmente marca uma nota como cancelada e perde o histórico das etapas anteriores, a empresa pode ter dificuldade para explicar os movimentos posteriores.

Uma entrada futura no banco também precisará ser conciliada

Imagine que determinada operação seja desfeita.

Depois dos ajustes tributários, uma transferência chega à empresa.

O extrato mostra apenas uma entrada financeira.

Para conciliá-la corretamente, o sistema precisa saber:

• qual venda originou o valor;
• qual documento fiscal está relacionado;
• qual cancelamento ou devolução gerou o ajuste;
• quanto se refere ao IBS;
• quanto se refere à CBS;
• se ainda existe saldo pendente.

Esse controle será particularmente importante em empresas com grande volume de transações.

Sem rastreabilidade, entradas legítimas podem se transformar em valores não identificados.

A pergunta ao fornecedor do ERP precisa deixar de ser genérica

Perguntar apenas:

“Seu ERP já está pronto para a Reforma Tributária?”

pode produzir uma resposta pouco útil.

A empresa deveria transformar essa pergunta em testes objetivos.

Por exemplo:

O sistema vincula pagamento e documento fiscal?

Consegue baixar integralmente um recebível quando o valor líquido no banco é inferior em razão do split?

Registra separadamente o valor calculado e o valor efetivamente segregado?

Consegue identificar IBS e CBS individualmente?

Trata pagamentos parciais?

Trata um único pagamento vinculado a várias notas?

Preserva o histórico em cancelamentos e devoluções?

Consegue identificar transferências posteriores relacionadas a uma operação anterior?

Como receberá informações dos novos ambientes tributários?

Quais integrações serão realizadas por API?

Essas respostas demonstram muito mais sobre o nível real de preparação.

APIs e integração deixam de ser assunto exclusivo da equipe de tecnologia

O CGIBS já disponibiliza documentação da Plataforma Pública do Split Payment, incluindo materiais técnicos destinados aos participantes responsáveis pela construção das integrações.

A Receita Federal também mantém ambientes e serviços ligados à implementação da CBS e da apuração assistida.

Para muitas empresas, não será necessário desenvolver diretamente uma integração com esses ambientes.

Essa responsabilidade pode ficar com:

• ERP;
• instituição financeira;
• adquirente;
• banco;
• plataforma de pagamento;
• software fiscal.

Mas isso não elimina a responsabilidade gerencial da empresa.

Ela precisa saber:

quais informações chegarão ao ERP;

com qual identificador;

em que prazo;

como serão conciliadas;

e quem investigará uma divergência.

A tecnologia pode automatizar o fluxo.

Ela não elimina a necessidade de desenhá-lo corretamente.

2026 é o melhor momento para descobrir as falhas

O período de transição permite que empresas, desenvolvedores e administrações tributárias testem sistemas e ajustem processos antes das próximas etapas da Reforma Tributária.

Isso dá às empresas uma oportunidade importante.

Uma diferença identificada hoje pode ser tratada como problema de implantação.

A mesma diferença descoberta depois da entrada plena dos efeitos financeiros poderá significar:

• saldo de cliente errado;
• caixa não conciliado;
• tributo divergente;
• retrabalho;
• cobrança indevida;
• dificuldade para fechar a contabilidade.

Quanto mais cedo o fluxo for testado, menor tende a ser o custo de correção.

Uma venda precisará deixar uma trilha digital completa

A palavra central desta etapa da Reforma Tributária é rastreabilidade.

A empresa deve ser capaz de escolher uma venda e reconstruir toda a sequência:

Documento fiscal

↓

Contas a receber

↓

Transação de pagamento

↓

Valor pago pelo cliente

↓

IBS e CBS da operação

↓

Valor efetivamente segregado

↓

Valor líquido disponibilizado

↓

Extinção reconhecida na apuração

↓

Eventual cancelamento ou devolução

↓

Transferência ou ajuste posterior

Quanto maior o número de operações, menor será a possibilidade de reconstruir essa trilha manualmente.

É nesse ponto que o ERP deixa de ser apenas sistema de registro e passa a ser parte do controle tributário.

Fiscal, financeiro, contabilidade e TI passam a responder pela mesma operação

O split payment atravessa departamentos.

O financeiro acompanha pagamento e banco.

O fiscal acompanha documento, débito e apuração.

A contabilidade precisa reconhecer corretamente os diferentes componentes da liquidação.

O TI garante a integração.

O fornecedor do ERP transforma as regras em sistema.

Na avaliação de Cleiton Celini e Gledson Alves, sócios e contadores da AUDICONT Contabilidade, limitar a preparação para a Reforma Tributária à configuração de IBS e CBS no documento fiscal cria uma falsa sensação de segurança.

O verdadeiro teste começará quando a operação for paga.

Nesse momento, a empresa precisará demonstrar que consegue acompanhar uma venda desde o faturamento até a liquidação, identificar quanto foi destinado aos tributos, explicar a diferença bancária e verificar o reflexo na apuração.

O ERP preparado para a Reforma Tributária não será apenas aquele que calcula corretamente IBS e CBS. Será aquele que consegue explicar o ciclo completo da operação.

Um teste com dez vendas pode mostrar se a empresa está pronta

Uma avaliação inicial pode ser feita sem projeto complexo.

Selecione dez operações reais e tente responder, para cada uma:

1. Qual documento fiscal originou a venda?

2. Qual recebível foi gerado?

3. Qual pagamento liquidou esse recebível?

4. O sistema consegue identificar o valor total pago pelo cliente?

5. Onde ficaria registrado o valor efetivamente segregado pelo split?

6. Como o ERP baixaria o cliente se o banco recebesse apenas o líquido?

7. Como o fiscal verificaria a extinção do débito?

8. Como a contabilidade reconheceria essa liquidação?

9. Se a venda fosse cancelada, o vínculo com todos esses eventos permaneceria?

10. Uma transferência recebida posteriormente conseguiria ser relacionada à operação original?

Se várias respostas dependerem de planilhas paralelas, conferência visual de extrato ou memória dos funcionários, a empresa já identificou um risco de implantação.

Perguntas frequentes

1. Um ERP que já calcula IBS e CBS está preparado para o split payment?

Não necessariamente. Calcular os novos tributos resolve apenas uma etapa. O sistema também precisará relacionar documento fiscal, contas a receber, pagamento, valor segregado, valor líquido recebido e apuração.

2. O pagamento precisará ser relacionado à nota fiscal?

A arquitetura do split payment depende da vinculação entre transação financeira e operação. A forma como cada ERP armazenará e utilizará essa informação dependerá da solução tecnológica adotada.

3. O cliente pode ter quitado a compra mesmo que entre menos dinheiro no banco?

Sim. Se a diferença decorrer regularmente do split payment, o valor líquido disponibilizado à empresa pode ser inferior ao total pago pelo cliente sem que exista inadimplência.

4. O valor segregado será sempre igual ao IBS e à CBS calculados na nota?

Não necessariamente. O valor efetivamente utilizado pelo mecanismo depende das regras aplicáveis à liquidação e da situação do débito da operação.

5. Toda empresa precisará desenvolver integração própria com as APIs?

Não. Em muitos casos, a integração será realizada pelos fornecedores de ERP, bancos, adquirentes ou instituições de pagamento. A empresa precisa, porém, garantir que as informações necessárias sejam recebidas e conciliadas.

6. Qual é o principal risco de um ERP despreparado?

Criar divergências que não existem na operação real: clientes aparentemente inadimplentes, diferenças bancárias, valores tributários não conciliados e saldos contábeis sem explicação.

Fontes consultadas

• Presidência da República - Lei Complementar nº 214, de 16 de janeiro de 2025
• Presidência da República - Lei Complementar nº 227, de 13 de janeiro de 2026
• Presidência da República - Decreto nº 12.955/2026
• Comitê Gestor do IBS - Resolução CGIBS nº 6, de 30 de abril de 2026
• Comitê Gestor do IBS - Plataforma Pública do Split Payment - Manual de Integração, versão 1.0.
  
  
• Comitê Gestor do IBS - Plataforma Pública do Split Payment, documentação técnica e materiais de integração.
  
  
• Receita Federal - Programa da Reforma Tributária do Consumo.
  
  
• Receita Federal - Manual da Plataforma CBS, ambiente de testes e apuração assistida.
  
  
• Receita Federal - Piloto da Contribuição sobre Bens e Serviços, voltado ao teste e aprimoramento dos sistemas e processos da CBS.