O Split Payment conecta dados fiscais, pagamentos e liquidação financeira ao permitir a segregação e o recolhimento do IBS e da CBS no momento da liquidação da transação. Pela Lei Complementar nº 214/2025, prestadores de serviços de pagamento eletrônico e instituições operadoras de sistemas de pagamento participam desse processo a partir das informações necessárias para vincular a operação comercial, o documento fiscal e a transação financeira.
Para bancos, fintechs, adquirentes e subadquirentes, a mudança não significa assumir o cálculo tributário realizado pelas empresas. A nova arquitetura exige que a infraestrutura responsável pela liquidação receba informações da operação, consulte os ambientes do Comitê Gestor do IBS e da Receita Federal e execute os procedimentos de segregação e recolhimento previstos na legislação. O pagamento passa, assim, a depender de informações produzidas fora da infraestrutura financeira.
Essa conexão aproxima sistemas que historicamente operaram em fluxos distintos. O ERP registra e estrutura informações da operação. O documento fiscal eletrônico formaliza os dados fiscais. A infraestrutura de pagamento movimenta os recursos. Os ambientes públicos participam da consulta e do tratamento tributário. Com o Split Payment, a correspondência entre essas camadas se torna necessária para que a liquidação financeira preserve a relação com a operação econômica que lhe deu origem.
O Split Payment funciona por meio da segregação e do recolhimento do IBS e da CBS durante a liquidação financeira da operação. O art. 31 da Lei Complementar nº 214/2025 estabelece a participação dos prestadores de serviços de pagamento eletrônico e das instituições operadoras de sistemas de pagamento e determina a consulta aos ambientes do Comitê Gestor do IBS e da Receita Federal para a execução do mecanismo. Com isso, a liquidação passa a incorporar a troca e o processamento de informações fiscais necessárias à segregação dos tributos.
Essa arquitetura ganhou uma dimensão técnica mais concreta com o Ato Conjunto RFB/CGIBS nº 2/2026, que aprovou documentos relacionados à Plataforma do Split Payment, incluindo o Manual de Integração e especificações para a conexão dos sistemas envolvidos. A publicação mostra que a implementação exige uma infraestrutura capaz de relacionar informações da operação comercial, do pagamento e dos ambientes administrados pelo Fisco.
A mesma operação passa a ser reconhecida por diferentes infraestruturas digitais. Para a empresa, existe uma venda associada a um documento fiscal. Para a instituição financeira, existe uma transação que precisa ser liquidada. Para a administração tributária, existem informações necessárias para identificar débitos, créditos, recolhimentos e eventuais ajustes. O funcionamento do Split Payment depende da correspondência entre essas diferentes representações da operação.
A implementação será gradual e seguirá o cronograma estabelecido pelos órgãos responsáveis. Essa progressividade é relevante para empresas e instituições financeiras porque a preparação envolve desenvolvimento, integração, testes e homologação antes que o mecanismo alcance uma escala maior de operações. A discussão deixa de ficar restrita ao desenho jurídico do Split Payment e alcança a capacidade dos sistemas de trocar informações com consistência.
A principal mudança do Split Payment para bancos e fintechs não é a obrigação de calcular IBS e CBS, mas a necessidade de operar uma infraestrutura financeira que consome informações fiscais para executar a liquidação. A Plataforma Pública do Split Payment cria uma camada de comunicação entre os sistemas de pagamento e os ambientes fiscais, fazendo com que dados originados na operação comercial participem do processo que determina a segregação e o recolhimento dos tributos.
Essa arquitetura cria uma dependência tecnológica entre sistemas que possuem funções diferentes. O ERP registra informações da operação comercial e alimenta a emissão do documento fiscal. A infraestrutura financeira recebe os dados necessários para identificar e liquidar a transação. Os ambientes do Comitê Gestor do IBS e da Receita Federal participam das consultas previstas para o funcionamento do Split Payment. Para que o mecanismo funcione, essas camadas precisam reconhecer a mesma operação e preservar sua correspondência ao longo do fluxo.
Em uma operação de varejo, por exemplo, informações tributárias podem ser produzidas a partir dos dados registrados no ERP e refletidas no documento fiscal antes de alcançarem as etapas relacionadas ao pagamento e à liquidação. Quanto maior o volume transacional e o número de sistemas envolvidos, maior a necessidade de manter íntegra a relação entre operação econômica, documento fiscal e transação financeira.
Essa exigência se torna especialmente relevante em marketplaces e operações omnichannel, onde o Split Payment tributário pode coexistir com estruturas de divisão comercial dos recebíveis. A plataforma pode distribuir valores entre diferentes participantes da venda enquanto a infraestrutura tributária precisa preservar a vinculação entre a operação de origem, o documento fiscal e a transação financeira utilizada na segregação do IBS e da CBS. Nesse ambiente, conciliar corretamente as duas lógicas depende da qualidade dos identificadores e das informações que atravessam a cadeia.
A evolução da documentação fiscal eletrônica já aponta para essa integração. Para a NF-e e a NFC-e, a NT 2026.006 v1.00 criou o grupo YC (Informações da Vinculação com a Transação de Pagamento do DF-e) e o evento 110300 (Vinculação Pagamento), destinados a estabelecer a relação direta entre o documento fiscal e a respectiva transação de pagamento. A implantação técnica está prevista para 05/10/2026 em ambiente de homologação e 03/11/2026 em produção, em caráter preparatório e sem obrigatoriedade de utilização em 2026.
Esse detalhe merece atenção porque impede uma leitura simplista: o XML não será transformado em um mero comando financeiro isolado. O que está sendo construído é uma arquitetura capaz de relacionar, em tempo real, o documento que registra a operação econômica com a transação que movimenta seus recursos.
A diferença parece técnica, mas possui consequências econômicas diretas. Se uma empresa emite documentos com informações inconsistentes, mantém cadastros desatualizados ou não consegue reconciliar seus eventos fiscais e financeiros, o problema pode ultrapassar o fechamento fiscal. A inconsistência alcança a etapa de liquidação e exige tratamento operacional posterior.
A Receita Federal orienta que os contribuintes devem emitir documentos fiscais eletrônicos com destaque individualizado de CBS e IBS conforme os leiautes e Notas Técnicas aplicáveis. Essa orientação reforça que o período de transição serve para testes e ajustes finos na adaptação dos sistemas. A informação fiscal começa, assim, a ocupar uma posição diferente dentro da arquitetura empresarial, pois alimenta processos utilizados para apuração, reconhecimento de créditos, conciliação e, com o Split Payment, liquidação financeira.
O principal risco operacional do Split Payment para bancos e fintechs não está no cálculo do IBS e da CBS, mas na correspondência entre a informação fiscal recebida e a operação financeira que será liquidada. Instituições financeiras não serão responsáveis por reproduzir internamente toda a inteligência tributária das empresas, mas precisarão operar com informações capazes de relacionar documento fiscal, cadastro, valor e identificadores do pagamento. Divergências entre esses elementos podem exigir tratamento e reconciliação ao longo do processo.
O próprio desenho legal e regulamentar prevê procedimentos para situações em que a consulta aos sistemas envolvidos no Split Payment não possa ser realizada no momento da transação, permitindo a continuidade das operações com tratamento e ajustes posteriores na apuração periódica. Essa previsão mostra que a integração entre os sistemas não elimina as exceções operacionais. Ela cria a necessidade de identificar divergências, executar ajustes e preservar a rastreabilidade entre a operação original e o tratamento realizado posteriormente.
A disponibilidade da infraestrutura pública também entra nessa equação. Se uma consulta aos ambientes do CGIBS ou da Receita Federal apresentar latência ou indisponibilidade, a operação comercial precisa considerar os mecanismos de contingência previstos para essas situações. Para bancos, fintechs e empresas, resiliência tecnológica e tratamento de exceções tornam-se componentes da arquitetura necessária para impedir que uma falha de comunicação comprometa a continuidade do fluxo operacional.
O Split Payment pode afetar o capital de giro porque os valores correspondentes ao IBS e à CBS são segregados durante a liquidação e deixam de permanecer integralmente à disposição do fornecedor. O efeito ganha relevância em empresas com grande volume de recebíveis e margens reduzidas, nas quais alterações no fluxo líquido das vendas podem interferir diretamente na gestão diária de caixa.
O impacto financeiro, porém, não depende apenas do valor segregado. A dinâmica envolve a sincronização entre liquidação financeira, reconhecimento do débito tributário, extinção da obrigação, apropriação de créditos, eventuais ajustes e disponibilidade dos recursos. A legislação prevê mecanismos para tratamento de diferenças e situações de contingência, inclusive com ajustes posteriores quando o valor efetivamente devido não corresponder ao montante inicialmente segregado.
Essa dinâmica coloca a reconciliação tributário-financeira no centro da gestão de liquidez. Diferenças entre valores segregados, tributos efetivamente devidos, créditos reconhecidos e recursos posteriormente disponibilizados precisam ser identificadas para que a empresa consiga compreender o fluxo líquido de cada operação e seus efeitos sobre caixa e recebíveis.
Para o CFO, a análise deixa de considerar somente o valor bruto das vendas e o recebimento líquido. A tesouraria precisa acompanhar como os eventos tributários interferem nos fluxos financeiros, enquanto controladoria e fiscal precisam relacionar apuração, débitos, créditos e valores liquidados. Tecnologia completa essa cadeia ao garantir que as informações possam ser cruzadas e reconciliadas entre os diferentes sistemas envolvidos.
O Motor de Decisão pode atuar antes da liquidação financeira ao organizar regras, informações fiscais e características da operação que determinam a qualidade do dado enviado às etapas seguintes. Ele não é um componente obrigatório da infraestrutura bancária prevista para o Split Payment. Sua função está na origem da informação, onde decisões tributárias podem ser aplicadas antes da emissão do documento fiscal e da vinculação da operação à transação de pagamento.
Essa antecipação é relevante porque o dado que chega à infraestrutura financeira não deveria depender de correções realizadas apenas no momento da liquidação. Quanto maior a consistência entre classificação da operação, cálculo tributário, documento fiscal e informações de pagamento, menor tende a ser a necessidade de tratar divergências nas etapas posteriores.
A Omnitax trabalha essa lógica ao posicionar o motor tributário como uma camada conectada ao ERP, aos documentos eletrônicos, às regras e aos eventos da operação. Associada ao DNA Tributário de cada organização, essa arquitetura concentra a inteligência necessária para que as particularidades fiscais da empresa sejam consideradas antes que os dados avancem para outros sistemas.
Para o Split Payment, essa organização importa porque a infraestrutura financeira passa a depender de informações originadas fora dela. Quando operação, classificação, cálculo e documento permanecem consistentes, bancos, fintechs e demais participantes recebem dados com maior correspondência em relação à transação que será liquidada. Quando a informação nasce fragmentada, as divergências podem avançar pela cadeia e exigir reconciliação posterior.
A arquitetura do Split Payment distribui responsabilidades entre diferentes camadas. A inteligência tributária da operação permanece nas empresas e em seus sistemas. Os ambientes públicos fornecem a infraestrutura necessária às consultas e ao tratamento previsto pelo novo modelo. Bancos e demais participantes continuam responsáveis pelas funções relacionadas ao pagamento e à liquidação. A consistência depende da capacidade de essas camadas reconhecerem corretamente a mesma operação.
O Split Payment e a Apuração Assistida se relacionam pelo uso estruturado das informações fiscais produzidas ao longo da operação, embora cumpram funções diferentes dentro da Reforma Tributária. Enquanto o Split Payment utiliza informações da operação para viabilizar a segregação e o recolhimento de IBS e CBS na liquidação, a Apuração Assistida utiliza documentos e eventos fiscais para apoiar o reconhecimento de débitos, créditos e demais elementos necessários à apuração dos tributos.
Essa aproximação aumenta a importância da consistência dos dados produzidos desde a origem da operação. As orientações divulgadas pela Receita Federal em 2026 reforçam o papel dos documentos fiscais eletrônicos e das informações estruturadas durante a transição para IBS e CBS. Quanto maior a utilização desses registros nos processos tributários, maior a dependência de cadastros, classificações, cálculos e documentos coerentes entre si.
A convergência aparece quando a mesma operação precisa permanecer reconhecível em diferentes etapas. A apuração utiliza informações fiscais para identificar débitos, créditos e eventos. O Split Payment depende de informações relacionadas à operação para executar os procedimentos de segregação e recolhimento. Embora cada mecanismo tenha finalidade própria, ambos ampliam a necessidade de rastrear a relação entre o fato econômico, o documento fiscal e os registros produzidos posteriormente.
Uma inconsistência originada no ERP pode, portanto, avançar para o documento fiscal e alcançar outras etapas do fluxo tributário. Quando diferentes sistemas passam a utilizar informações relacionadas à mesma operação, a qualidade do dado influencia apuração, conciliação e tratamento das diferenças. A integração entre essas camadas reduz a dependência de correções tardias e aumenta a importância da rastreabilidade ao longo de todo o processo.
O Split Payment afeta bancos, fintechs, adquirentes e subadquirentes ao criar uma nova camada de integração entre a infraestrutura de pagamentos e as informações fiscais utilizadas na segregação e no recolhimento do IBS e da CBS. Essas instituições não assumem a responsabilidade tributária do vendedor nem se transformam em departamentos fiscais das empresas, mas precisam compreender quais dados participam do processo, como esses dados se relacionam com a transação financeira e quais ambientes precisam ser consultados durante a execução do mecanismo.
Essa integração também pode abrir espaço para novos serviços de conciliação tributário-financeira, antecipação de recebíveis considerando os efeitos do Split Payment, gestão de liquidez e análise de eventos fiscais associados às transações. A capacidade de relacionar informações fiscais e financeiras tende a ganhar relevância à medida que documento fiscal, pagamento, segregação tributária e liquidação passam a integrar uma mesma cadeia operacional.
Operações como desconto de duplicatas, securitização e antecipação via FIDCs também poderão incorporar os efeitos do Split Payment na análise de recebíveis e na estruturação de garantias, uma vez que a segregação do IBS e da CBS pode alterar o fluxo líquido associado à liquidação da operação.
Para bancos e fintechs, a oportunidade não está em assumir o cálculo tributário das empresas, mas em compreender a camada de informação fiscal que passa a participar da liquidação. Essa compreensão pode apoiar serviços de liquidez, conciliação e análise de recebíveis que considerem os efeitos da segregação tributária sobre os fluxos financeiros.
Do ponto de vista tecnológico, essa arquitetura exige atenção a APIs, observabilidade, tratamento de exceções e rastreabilidade. Os documentos técnicos relacionados à Plataforma do Split Payment reforçam a necessidade de integração entre os sistemas participantes, tornando a capacidade de identificar falhas, preservar a correspondência entre registros e tratar exceções parte relevante da infraestrutura operacional.
A discussão sobre Split Payment costuma se concentrar no recolhimento automático do IBS e da CBS. Para a indústria financeira, entretanto, a questão mais relevante pode estar na infraestrutura necessária para fazer esse mecanismo conviver com uma economia digital de alto volume.
O desafio não será simplesmente segregar valores. Será preservar a correspondência entre operação econômica, documento fiscal, informação tributária e transação financeira ao longo de todo o processo.
Essa correspondência exigirá integração entre ERP, XML, sistemas de pagamento, plataformas digitais, bases fiscais, mecanismos de decisão e estruturas de apuração. Em operações omnichannel e marketplaces, onde múltiplas jornadas comerciais podem convergir para diferentes meios de pagamento, a necessidade de uma referência única para a operação tende a ser ainda mais relevante.
É nesse ponto que conceitos como DNA Tributário, única fonte da verdade e infraestrutura tributária deixam de representar apenas arquitetura interna da empresa. Eles passam a dialogar com uma infraestrutura externa que também precisa reconhecer a operação.
A empresa precisa produzir o dado correto. O sistema fiscal precisa recebê-lo e processá-lo. A infraestrutura de pagamento precisa utilizar as informações necessárias à segregação. A liquidação precisa registrar o resultado. E toda a cadeia precisa ser capaz de demonstrar o que aconteceu.
O dinheiro continua sendo liquidado pelo sistema financeiro. A informação que determina como parte desse dinheiro será tratada, entretanto, nasce muito antes.
A integração entre infraestrutura fiscal e financeira é crítica no Split Payment porque a liquidação precisa preservar a correspondência entre a operação econômica, o documento fiscal, as informações tributárias e a transação de pagamento. O mecanismo costuma ser analisado pela ótica da segregação automática dos tributos, mas sua execução em escala depende da capacidade de diferentes sistemas reconhecerem e tratarem corretamente a mesma operação.
Essa integração envolve ERP, XML, plataformas de pagamento, bases fiscais, motores de decisão e ambientes de apuração. Cada componente possui uma função diferente, mas os dados precisam permanecer relacionados ao longo do fluxo. Quando essa correspondência é perdida, aumenta a necessidade de conciliações, ajustes e tratamento de exceções nas etapas posteriores.
É nesse ponto que conceitos como DNA Tributário e única fonte da verdade fiscal ganham relevância dentro da arquitetura empresarial. A centralização das regras e particularidades tributárias da empresa reduz a fragmentação da informação entre sistemas e permite que ERP, documentos eletrônicos e demais aplicações consumam uma referência fiscal consistente. No Split Payment, essa organização importa porque parte das informações utilizadas pela infraestrutura financeira nasce antes da liquidação.
A empresa precisa saber qual regra aplicou, qual dado utilizou, qual decisão tomou e qual documento gerou. A infraestrutura financeira precisa relacionar a transação aos elementos necessários para a liquidação. Os ambientes fiscais precisam receber e processar as informações previstas para cada etapa. Quando essas diferentes camadas preservam a identidade da operação, torna-se possível acompanhar o fluxo desde sua origem tributária até seus efeitos financeiros.
