Split payment na Reforma Tributária e o Odoo

Entre as novidades estruturais da Reforma Tributária (EC 132/2023, LC 214/2025), o split payment é a que mais altera a relação entre o fiscal e o financeiro de uma empresa. Não é só uma mudança de alíquota ou de sigla: é uma mudança no momento e no mecanismo em que o tributo sai do seu caixa. Para gestores e controllers, entender isso cedo evita um susto de fluxo de caixa lá na frente.

Antes de seguir: alguns detalhes operacionais do split payment ainda dependem de regulamentação infralegal e de definições do Comitê Gestor do IBS. Onde isso acontece, este post sinaliza explicitamente. O objetivo aqui é dar o conceito correto e a direção, não cravar mecânica que ainda está sendo escrita.

O que é split payment

No modelo tradicional, a empresa recebe o valor cheio da venda (produto + tributo embutido), e depois recolhe o tributo ao fisco em uma data futura, via apuração mensal. Existe um intervalo entre receber e recolher — e nesse intervalo o dinheiro do tributo fica no caixa da empresa.

O split payment (“pagamento dividido”) muda isso: o tributo (IBS e CBS) é separado e direcionado ao fisco no momento da liquidação financeira da operação — ou seja, quando o pagamento é efetivamente processado. Em vez de a empresa receber tudo e recolher depois, a parcela do tributo já é destacada e encaminhada na própria transação de pagamento.

A lógica por trás é combater a inadimplência tributária e a sonegação: o tributo é recolhido na fonte do fluxo financeiro, reduzindo a chance de uma operação acontecer sem o imposto correspondente chegar ao fisco. É um dos pilares que sustenta a promessa de não-cumulatividade ampla da Reforma.

Em que casos se aplica

A LC 214/2025 prevê o split payment como mecanismo de arrecadação do IBS e da CBS, com modalidades distintas. De forma simplificada e cautelosa:

• Operações com meios de pagamento eletrônicos (cartão, Pix, e instrumentos similares) tendem a ser o terreno natural do split, porque o tributo pode ser separado pelo prestador de serviço de pagamento no momento da liquidação.
• Há previsão de modalidades inteligentes/automáticas em que o sistema de pagamento consulta o tributo devido daquela operação e faz a retenção correspondente.

Importante: a abrangência exata, os prazos de adoção obrigatória por tipo de operação e a integração técnica com os arranjos de pagamento estão entre os pontos que ainda dependem de regulamentação detalhada e da estrutura do Comitê Gestor. Trate as descrições acima como direção, e acompanhe as normas oficiais em gov.br para os detalhes que valerão na sua operação específica.

O impacto no fluxo de caixa

Este é o ponto que merece atenção do financeiro, não só do fiscal.

Hoje, aquele intervalo entre receber e recolher funciona, na prática, como um capital de giro temporário — a empresa opera por alguns dias ou semanas com o dinheiro do tributo no caixa antes de repassá-lo. Com o split payment, esse intervalo encolhe ou desaparece para as operações afetadas: o tributo sai praticamente junto com o recebimento.

Para muitas empresas isso significa revisar premissas de capital de giro. Negócios que dependiam (mesmo sem perceber) desse “float” tributário para girar precisarão ajustar projeções de caixa. Não é um custo novo — o tributo sempre foi devido — mas é uma antecipação do desembolso efetivo, e antecipação de desembolso é, financeiramente, um custo real de oportunidade.

A recomendação prática: simular o efeito do split no fluxo de caixa antes da adoção obrigatória, separando as operações que tendem a cair no mecanismo (pagamentos eletrônicos) das que não caem.

O que o ERP precisa fazer

O split payment é, tecnicamente, onde fiscal, financeiro e meios de pagamento deixam de ser silos. Historicamente, em muitos ERPs, esses três mundos conversam pouco: o fiscal calcula o tributo na nota, o financeiro registra o título a receber, e a conciliação do pagamento é uma etapa posterior e separada. O split exige que eles operem de forma integrada e, em parte, em tempo real.

No Odoo com a localização OCA, isso significa:

• O motor fiscal precisa saber, por operação, qual é o IBS e a CBS devidos — o que já é endereçado pelos novos cadastros de tributo (l10n_br_fiscal.tax é genérico e acomoda CBS/IBS como novos tributos) e pelo motor de cálculo com não-cumulatividade ampla, em desenvolvimento na comunidade OCA.
• O financeiro precisa registrar o recebimento já líquido da parcela recolhida via split, refletindo corretamente quanto entrou de fato no caixa versus quanto foi direcionado ao fisco.
• A integração com meios de pagamento precisa capturar o evento de liquidação e a retenção feita pelo arranjo de pagamento, conciliando-o contra o tributo apurado na operação original.

Em uma localização open-source upstream, essa integração é construída de forma compartilhada e auditável, com a KMEE entre as mantenedoras principais — em vez de depender de um único fornecedor entregar uma “caixa-preta” no seu prazo. Como vários detalhes do split ainda estão em regulamentação, ter a base em um repositório com múltiplos mantenedores ativos significa que os ajustes acompanham as normas conforme elas saem, sem prender o cliente a um fornecedor único.

Vale reforçar: a parte do split que depende de como exatamente os arranjos de pagamento farão a separação técnica é o pedaço com mais definições pendentes. O desenho conceitual no ERP pode (e deve) começar agora; a fiação fina com cada meio de pagamento amadurece junto com a regulamentação.

Leituras relacionadas

• Reforma Tributária 2026: IBS, CBS, IS — o overview das três siglas e do cronograma
• Alíquota-teste 2026: CBS e IBS, o que fazer agora — a ação urgente deste ano
• Reforma Tributária por setor: varejo, indústria e serviços — exposição por segmento
• Reforma Tributária 2026 no Odoo — prontidão da plataforma
• Localização Fiscal Brasileira no Odoo — o hub da localização OCA
• Glossário fiscal — termos e siglas explicados