Split Payment na Reforma Tributária: O que Muda no ERP

Guia técnico com fundamentos legais, modalidades de retenção, cronograma oficial e o que muda na integração do ERP com meios de pagamento

📅 20 de agosto de 2026 • ⏱️ 16 min de leitura

Resumo: O split payment é o mecanismo da Reforma Tributária que separa e recolhe o IBS e a CBS automaticamente no momento da liquidação financeira do pagamento — antes mesmo de o valor entrar no caixa do fornecedor. Previsto nos artigos 31 a 35 da Lei Complementar nº 214/2025, ele muda o ponto em que o tributo é extinto: não é mais só uma obrigação apurada no ERP e paga depois, é uma retenção que acontece dentro do fluxo de pagamento, em parceria com bancos, adquirentes e provedores de Pix e boleto. Neste guia você vai entender as três modalidades previstas em lei, o cronograma real de 2026 a 2027, um exemplo numérico do impacto no fluxo de caixa e como esse requisito se traduz em especificação técnica para quem configura ou desenvolve um ERP fiscal.

---

Contexto e relevância

Desde a promulgação da Emenda Constitucional nº 132/2023, a Reforma Tributária do Consumo vem sendo regulamentada em camadas: primeiro a estrutura de IBS e CBS, depois os regimes específicos e diferenciados, depois os detalhes de escrituração como o cClassTrib. O split payment é a camada que mexe em algo que nenhuma reforma tributária anterior havia tocado: o instante em que o tributo é extinto.

No modelo atual, a empresa vende, recebe o valor integral na conta, apura o imposto devido e recolhe depois, dentro do prazo legal — um intervalo em que o dinheiro do tributo transita pelo caixa do contribuinte. O split payment quebra essa lógica: a Lei Complementar nº 214/2025 autoriza que o próprio meio de pagamento — o banco, a adquirente de cartão, o provedor de Pix ou o emissor de boleto — separe o valor do IBS e da CBS no momento da liquidação e o transfira diretamente para a Receita Federal e para o Comitê Gestor do IBS (CGIBS), sem que esse valor chegue a compor o saldo disponível do fornecedor.

Para quem configura ou desenvolve um ERP, isso não é só uma mudança de alíquota ou de campo em nota fiscal: é uma mudança estrutural na forma como o sistema fiscal precisa se comunicar com o módulo financeiro e com terceiros externos ao ERP — bancos e adquirentes — em tempo real.

📌 Importante: o split payment não substitui a nota fiscal eletrônica nem a apuração do IBS/CBS no ERP. Ele muda quem recolhe e quando, mas a obrigação de apurar corretamente o tributo, vinculá-lo ao documento fiscal e reconciliar os valores continua sendo do contribuinte.

Fundamento legal

O split payment está disciplinado pelos seguintes instrumentos normativos:

• Emenda Constitucional nº 132/2023 — institui a Reforma Tributária do Consumo e cria o IBS e a CBS.
• Lei Complementar nº 214/2025, artigos 31 a 35 (Subseção III) — regulamenta especificamente o split payment como uma das modalidades de extinção do crédito tributário do IBS e da CBS, ao lado da compensação com créditos apropriados e do recolhimento no prazo regular.
• Ato Conjunto RFB/CGIBS nº 2, de 27 de maio de 2026 — autoriza a publicação do Manual de Integração e do Swagger (especificação da API) da Plataforma Pública do Split Payment, o canal técnico que conecta provedores de pagamento à Receita Federal e ao Comitê Gestor do IBS.

A Plataforma Pública do Split Payment funciona como um hub de comunicação entre os agentes do arranjo de pagamento (adquirentes, instituições de pagamento, bancos) e os entes fazendários — ela não define regras de negócio próprias, apenas transporta e valida os dados que os dois lados precisam trocar para segregar o tributo corretamente. Os meios de pagamento já contemplados na documentação técnica publicada são TED, TEF, Pix (por chave e por QR Code dinâmico) e boleto.

📌 Base legal: este guia se fundamenta na EC 132/2023, na LC 214/2025 (arts. 31 a 35) e no Ato Conjunto RFB/CGIBS nº 2/2026. Por se tratar de mecanismo em fase de regulamentação técnica progressiva, novos atos conjuntos podem detalhar ou ajustar pontos ainda abertos — consulte sempre o Portal da Reforma Tributária e o portal da Receita Federal antes de tomar decisão de implementação.

Como funciona o split payment

O mecanismo atua no momento da liquidação financeira da operação — ou seja, quando o dinheiro efetivamente muda de mãos entre o pagador e o fornecedor, não no momento da emissão da nota fiscal. Em linhas gerais:

1. O cliente paga a compra por um dos meios de pagamento eletrônicos contemplados (Pix, TED, TEF, boleto ou, futuramente, cartão).
2. O provedor de pagamento (banco, instituição de pagamento ou adquirente) consulta a Plataforma Pública do Split Payment para saber quanto de IBS e de CBS deve ser destacado daquele pagamento específico.
3. O provedor de pagamento retém e transfere diretamente os valores de IBS e CBS para o Comitê Gestor do IBS e para a Receita Federal.
4. O fornecedor recebe apenas o valor líquido — o preço da operação já descontado do tributo retido na fonte do pagamento.

A responsabilidade tributária, porém, não migra para o provedor de pagamento. Ele apenas executa a segregação técnica; quem continua respondendo pela correção do valor apurado, pela reconciliação entre o documento fiscal e o valor efetivamente retido, e por eventuais diferenças, é o próprio contribuinte-fornecedor.

Um ponto estrutural que a legislação já deixa explícito: cada documento fiscal eletrônico (DFe) — NF-e, NFS-e ou equivalente — precisa estar tecnicamente vinculado à transação de pagamento correspondente. É essa vinculação que permite à Plataforma Pública identificar, no momento da liquidação, qual operação está sendo paga e qual valor de tributo deve ser destacado.

As três modalidades previstas na lei

A LC 214/2025 não impõe um único fluxo de retenção — ela prevê três modalidades, pensadas para acomodar diferentes níveis de maturidade tecnológica do arranjo de pagamento e cenários de indisponibilidade de sistema:

Modalidade	Como funciona	Quando se aplica
Padrão (ou “inteligente”)	O provedor de pagamento consulta em tempo real o sistema da Receita Federal/Comitê Gestor, com base nos dados individualizados da transação, e retém exatamente o valor de IBS/CBS calculado para aquela operação específica.	Cenário-alvo do modelo, quando a integração plena estiver madura.
Simplificada	O provedor aplica um percentual predefinido (por setor ou perfil de contribuinte) sobre o valor do pagamento, sem consulta individualizada em tempo real. Ajustes e devoluções de eventual valor retido a maior ocorrem depois, em até três dias úteis.	Transição, ou arranjos de pagamento com menor capacidade de integração em tempo real.
Contingência	Se a consulta ao sistema da Receita Federal/Comitê Gestor falhar, o provedor retém o valor com base no que está destacado no próprio documento fiscal, e o ajuste fino ocorre posteriormente, com devolução do excedente em até três dias úteis.	Indisponibilidade temporária da Plataforma Pública ou dos sistemas do provedor.

💡 Dica de compliance: independentemente da modalidade aplicada em cada pagamento, o ERP precisa registrar qual modalidade foi usada em cada transação retida, porque isso afeta a reconciliação: uma retenção simplificada ou de contingência quase sempre vai gerar uma diferença a ajustar contra o valor apurado no documento fiscal, e essa diferença precisa ser rastreável até a operação de origem.

Cronograma de implementação

Assim como o restante da Reforma Tributária, o split payment tem entrada em vigor escalonada — e é importante não confundir o cronograma de teste do split payment com o cronograma geral de CBS/IBS:

Período	O que acontece
2026	Ano de testes técnicos e calibração. A cobrança efetiva de CBS/IBS já começa de forma simbólica (0,9% CBS + 0,1% IBS), mas o mecanismo de split payment em si roda em ambiente de teste, sem produzir retenção real generalizada nas operações das empresas. Em 27/05/2026, o Ato Conjunto RFB/CGIBS nº 2/2026 publicou o Manual de Integração e o Swagger da Plataforma Pública, autorizando provedores de pagamento a começar a desenvolver suas integrações.
2027	Início da fase de uso — inicialmente opcional e concentrada em operações B2B, dentro dos meios de pagamento já especificados (Pix, TED, TEF, boleto). A obrigatoriedade plena e a ampliação para outros meios de pagamento (como cartão) seguem cronograma a ser definido por ato conjunto da Receita Federal e do Comitê Gestor do IBS.
2029-2032	Split payment convive com a transição gradual entre ICMS/ISS e IBS, acompanhando a redução progressiva dos tributos antigos.
2033	Horizonte de consolidação plena do novo sistema tributário sobre o consumo, com o split payment operando como mecanismo padrão de recolhimento de IBS/CBS.

⚠️ Risco fiscal: tratar 2027 como “ainda não obrigatório, posso ignorar” é um erro de dimensionamento comum. Mesmo com o uso inicial opcional e restrito a B2B, empresas que vendem para outras empresas via Pix, TED, TEF ou boleto — a maioria das operações B2B no Brasil — são justamente o público-alvo da primeira fase. Adiar a adaptação do ERP para depois de 2027 significa correr o projeto sob pressão, no exato momento em que o mecanismo passa a valer para o seu segmento.

Exemplo prático com impacto no fluxo de caixa

Cenário: Empresa A vende R$ 50.000,00 em mercadorias para a Empresa B, ambas operações regidas pelo regime regular de IBS/CBS, com pagamento via Pix. Considerando, para fins didáticos, uma alíquota combinada de referência de IBS + CBS de 26,5% sobre o valor da operação (valor de referência amplamente discutido no debate público da Reforma; a alíquota efetiva vigente em cada período de transição deve ser sempre confirmada nas tabelas oficiais).

Sem split payment (modelo de recolhimento tradicional):

Item	Valor
Valor recebido no caixa da Empresa A	R$ 50.000,00
IBS + CBS devidos (apurados no ERP, a recolher depois)	R$ 13.250,00
Caixa disponível até o vencimento da obrigação	R$ 50.000,00

Com split payment na modalidade padrão:

Item	Valor
Valor pago pela Empresa B via Pix	R$ 50.000,00
IBS + CBS retidos automaticamente pelo provedor de pagamento	R$ 13.250,00
Valor líquido creditado no caixa da Empresa A	R$ 36.750,00

O valor total do tributo devido não muda — a diferença é que, no segundo cenário, a Empresa A nunca chega a ter disponibilidade sobre os R$ 13.250,00: o dinheiro sai direto da liquidação do Pix para a Receita Federal e o Comitê Gestor do IBS. Isso reduz o risco de inadimplência fiscal por uso indevido do caixa, mas também reduz o capital de giro disponível no curto prazo — um ponto que times financeiros precisam antecipar na projeção de fluxo de caixa, e que sistemas de ERP precisam refletir corretamente na conciliação bancária.

Do requisito de negócio à especificação técnica

Esta é a camada em que a mudança deixa de ser uma notícia fiscal e vira trabalho de configuração e desenvolvimento de sistema. Um ERP que hoje só sabe apurar imposto e gerar guia de recolhimento precisa evoluir para reconciliar retenções feitas por terceiros, em tempo real, contra o documento fiscal emitido.

Requisito funcional

RF-01 — Reconciliação de retenção por split payment

• Ator: Módulo Financeiro / Módulo Fiscal do ERP
• Pré-condição: existe uma NF-e ou NFS-e emitida com IBS/CBS destacados e vinculada a uma transação de pagamento sujeita a split payment (Pix, TED, TEF ou boleto, no arranjo B2B).
• Descrição: o sistema deve capturar a confirmação de liquidação financeira do pagamento, identificar a modalidade de retenção aplicada (padrão, simplificada ou contingência) e o valor efetivamente retido de IBS/CBS, e vincular esse valor ao documento fiscal correspondente, de forma que o caixa líquido recebido reflita corretamente o valor bruto menos a retenção.
• Pós-condição: o lançamento financeiro da operação é conciliado automaticamente com o valor líquido recebido, e qualquer diferença entre o valor retido e o valor apurado no documento fiscal é sinalizada para análise antes do fechamento do período.

Critério de aceite

Cenário: retenção na modalidade padrão sem divergência

• Dado que uma NF-e de R$ 50.000,00 com IBS/CBS destacados foi emitida e vinculada a uma cobrança Pix
• Quando o provedor de pagamento liquidar o Pix e retiver o valor de IBS/CBS na modalidade padrão
• Então o sistema deve registrar o recebimento líquido no módulo financeiro
• E o valor retido informado pelo provedor deve ser conciliado automaticamente com o valor de IBS/CBS destacado na NF-e
• E nenhuma pendência deve ser gerada quando os dois valores coincidirem dentro da tolerância de arredondamento definida

Cenário: retenção em contingência com divergência de valor

• Dado que a consulta à Plataforma Pública falhou no momento do pagamento e o provedor aplicou a modalidade de contingência
• Quando o valor retido pelo provedor divergir do valor de IBS/CBS destacado no documento fiscal
• Então o sistema deve gerar uma pendência de reconciliação identificando a operação, o valor esperado e o valor efetivamente retido
• E o sistema não deve fechar automaticamente o período fiscal enquanto houver pendências de reconciliação de split payment em aberto

Artefato técnico: o vínculo entre documento fiscal e transação de pagamento

O ponto tecnicamente mais sensível do split payment, do ponto de vista de integração, é justamente essa vinculação obrigatória entre o DFe e a transação de pagamento — sem ela, a Plataforma Pública não tem como saber, no instante da liquidação, qual operação está sendo paga e qual tributo deve segregar.

📌 Transparência sobre o que já está confirmado: a especificação exata dos campos trocados na API da Plataforma Pública está no Manual de Integração e no Swagger publicados pelo Ato Conjunto RFB/CGIBS nº 2/2026, documentos técnicos ainda em evolução e destinados primariamente aos provedores de pagamento, não aos ERPs dos contribuintes diretamente. Este guia não reproduz nomes de campos ou contratos de API que não puderam ser verificados em fonte primária estável — o que já está juridicamente confirmado é a obrigação de vínculo entre DFe e pagamento, prevista na própria LC 214/2025. Antes de codificar essa integração, valide a versão vigente do manual no domínio oficial da Receita Federal ou do Comitê Gestor do IBS.

O que já pode ser especificado com segurança, no nível de requisito de sistema, é o contrato de dados mínimo que o módulo fiscal do ERP precisa conseguir expor para o módulo financeiro (ou para o provedor de pagamento, conforme o arranjo escolhido pela empresa):

Vínculo DFe ↔ Pagamento (nível conceitual)
├─ chaveAcesso (chave de 44 dígitos do DFe, já usada na NF-e)
├─ valorTotalOperacao
├─ valorIBS / valorCBS destacados no documento
├─ identificadorTransacaoPagamento (referência única no arranjo: txid do Pix, nosso número do boleto, etc.)
└─ modalidadeSplitAplicada (padrão | simplificada | contingência) — retornada pelo provedor após a liquidação

Esse contrato conceitual já é suficiente para orientar a área de TI a mapear, no cadastro de contas a receber e na emissão fiscal, onde cada um desses dados precisa nascer e para onde precisa ser enviado — mesmo antes de o time de integração acessar o Swagger oficial linha a linha.

Riscos fiscais e armadilhas

A adaptação tardia ou incompleta ao split payment expõe a empresa a riscos que vão além do atraso de projeto:

• Divergência de caixa não identificada — se o ERP não reconciliar o valor líquido recebido com o valor retido, a empresa pode registrar contabilmente um recebimento maior do que o efetivamente disponível, distorcendo o fluxo de caixa projetado.
• Falha de vínculo entre DFe e pagamento — se o documento fiscal não estiver corretamente associado à transação, a retenção pode cair em contingência sistematicamente, gerando volume desnecessário de ajustes manuais.
• Fechamento fiscal prematuro — encerrar o período de apuração sem reconciliar todas as retenções de split payment pendentes é uma fonte provável de divergência entre o SPED e o valor efetivamente recolhido por terceiros.
• Dependência de fornecedor de pagamento não homologado — trabalhar com adquirentes ou instituições de pagamento que ainda não implementaram a integração com a Plataforma Pública pode empurrar toda operação da empresa para a modalidade de contingência, mesmo depois de a obrigatoriedade avançar.

A mitigação passa por:

• Mapear, já em 2026, quais provedores de pagamento usados pela empresa (adquirente de Pix, banco emissor de boleto) têm cronograma de integração com a Plataforma Pública do Split Payment.
• Incluir a reconciliação de split payment como etapa formal do fechamento fiscal mensal, não como ajuste manual eventual.
• Acompanhar os atos conjuntos da Receita Federal e do Comitê Gestor do IBS, já que o cronograma de obrigatoriedade por meio de pagamento pode mudar por ato infralegal.

Boas práticas de compliance

• Trate o split payment como um projeto de integração, não apenas de parametrização fiscal — ele envolve o time financeiro, o time fiscal e, possivelmente, o fornecedor de meios de pagamento da empresa.
• Documente, para cada arranjo de pagamento utilizado, se a integração com a Plataforma Pública já está disponível ou se a empresa ainda depende da modalidade de contingência.
• Mantenha rastreabilidade completa entre chave de acesso do DFe, transação de pagamento e modalidade de retenção aplicada — essa trinca é a base de qualquer auditoria futura sobre o tema.
• Antes de assumir obrigatoriedade em uma data específica, confirme no Portal da Reforma Tributária e nos canais oficiais da Receita Federal e do Comitê Gestor do IBS, já que o cronograma de expansão por meio de pagamento e por porte de empresa é definido por ato conjunto e pode ser ajustado.

Conclusão

• O split payment (LC 214/2025, arts. 31-35) muda o momento em que o IBS e a CBS são extintos: a retenção acontece na liquidação do pagamento, não na apuração posterior do ERP.
• Existem três modalidades previstas — padrão, simplificada e contingência — e o ERP precisa saber tratar as três, especialmente a reconciliação de divergências geradas pela contingência.
• O cronograma real: 2026 é ano de testes e publicação da documentação técnica (Ato Conjunto RFB/CGIBS nº 2/2026); 2027 inicia o uso opcional em operações B2B via Pix, TED, TEF e boleto.
• O requisito central para o ERP é garantir o vínculo técnico entre o documento fiscal eletrônico e a transação de pagamento, e reconciliar automaticamente o valor retido contra o valor apurado no documento.
• Por ser um mecanismo ainda em regulamentação técnica progressiva, a especificação de campos de integração deve sempre ser validada na fonte oficial mais recente antes da implementação.

💡 Continue aprendendo: se você está revisando o cadastro fiscal da sua empresa para a Reforma Tributária, veja também como o cClassTrib está mudando a validação das NF-e e o guia completo de CFOP para analistas de ERP, para entender como as diferentes camadas da reforma se conectam no dia a dia do sistema fiscal.

Referências

• Lei Complementar nº 214, de 16 de janeiro de 2025 — Presidência da República.
• Emenda Constitucional nº 132/2023 — Presidência da República.
• Receita Federal e Comitê Gestor do IBS publicam documentação técnica da Plataforma Pública do Split Payment — Receita Federal do Brasil.
• Ato Conjunto RFB/CGIBS nº 2, de 27/05/2026 — LegisWeb.
• Portal da Reforma Tributária do Consumo — https://www.gov.br/fazenda/pt-br/acesso-a-informacao/acoes-e-programas/reforma-tributaria.