Split payment: qual nota esse pagamento está pagando?
O split payment não vai ser obrigatório em janeiro de 2027, e isso não é folga. As regras ganharam versão aprovada em setembro de 2026 e exigem uma coisa que a sua operação provavelmente não sabe fazer: dizer, no momento do pagamento, qual nota fiscal aquele dinheiro está pagando.
O que exatamente foi adiado?
A obrigatoriedade, não o mecanismo. Em entrevista ao g1 em 30 de agosto de 2026, reproduzida pelo Poder360, o subsecretário de Gestão Corporativa da Receita Federal, Juliano Neves, disse que o split começa de forma opcional, meio de pagamento a meio de pagamento, e que "ninguém vai ser obrigado enquanto não estiver disponível para todos os meios de pagamento". A Receita confirmou a previsão de 2028 para a obrigatoriedade nas operações entre empresas, e Neves disse não ter data fechada, porque ela depende da prontidão dos prestadores de pagamento. Três dias antes, em nota repassada ao Jornal do Comércio pela Sefaz-RS, o Comitê Gestor do IBS já tinha informado que a versão completa não estaria disponível em janeiro de 2027.
Essa data ainda não está em norma. O regulamento do IBS (Resolução CGIBS nº 6, de 30 de abril de 2026, art. 33) manda implantar o split em pelo menos duas etapas, nos termos de ato conjunto da Receita e do Comitê Gestor, e permite que a primeira seja de uso facultativo. Até 10 de outubro de 2026, esse ato com o calendário não aparece entre os atos conjuntos publicados pelo Comitê. O próprio Manual de Operações remete o cronograma a um documento à parte, o Plano de Implantação, que também não foi publicado.
Enquanto o calendário fica em aberto, o desenho foi aprovado. A primeira documentação técnica saiu em 3 de junho de 2026, com o Ato Conjunto RFB/CGIBS nº 2. O Ato Técnico Conjunto RFB/SUARA/CGIBS/Diretoria-Executiva nº 5, de 22 de setembro de 2026, publicado no site do Comitê em 24 de setembro, aprovou o Manual de Operações v1.0.1, o Manual de Integração v1.1.1 e o Manual de Tempos v1.0.1, entre outros, e ratificou as versões de Operações e Tempos que circulavam como minuta. Pelo mesmo ato, as versões sequenciais seguintes só podem corrigir erro material ou ajustar redação.
A parte técnica também anda. Segundo comunicado da Receita de 30 de setembro de 2026, a fase de testes de integração entre os prestadores de serviço de pagamento e a plataforma do split tem início marcado para 15 de outubro de 2026, sem nenhuma transação processada em caráter definitivo.
Existe um manual só para tempos. Prazos, janelas operacionais e marcos temporais ganharam documento próprio. Isso diz mais sobre a natureza do problema do que qualquer análise de conjuntura.
O que o mecanismo pede da sua operação
Ele pede um vínculo. O Manual de Operações aprovado define o campo Documento Fiscal como o identificador, a chave de acesso, que liga a transação de pagamento à operação fiscal correspondente (seção 3.1). Na primeira fase, o split vale só entre pessoas jurídicas e é facultativo para quem origina o pagamento: se os campos fiscais não forem preenchidos, a transação segue normalmente e simplesmente não tem split.
A regra muda conforme quem inicia o pagamento. Nos arranjos iniciados pelo recebedor, como boleto, Pix dinâmico e Pix automático, preencher o documento fiscal no arranjo é opcional, e o recebedor pode estabelecer o vínculo diretamente com o governo depois (seção 3.2). Nos arranjos iniciados por quem paga, ou seja, Pix estático, TED e TEF, os três campos são obrigatórios para que haja split: CBS informado, IBS informado e documento fiscal (seção 3.3).
E aqui está a parte que muda a rotina de quem paga fornecedor. O manual é explícito ao dizer que, nesses arranjos, o documento fiscal precisa estar disponível ao pagador antes da iniciação da transação, e que, em regra, ele é comunicado pelo recebedor ao pagador por canais externos ao arranjo de pagamento.
Traduzindo: alguém no seu financeiro precisa ter a chave da nota do fornecedor em mãos, dentro do sistema, antes de mandar o Pix. Hoje essa pessoa costuma digitar o valor a partir de um e-mail, de um PDF anexo ou de uma mensagem.
Por que não dá para acertar depois
Porque o manual aprovado fecha essa porta. Nos arranjos iniciados pelo pagador não há mecanismo de vínculo posterior entre transação e documento fiscal, e o vínculo se estabelece exclusivamente pelo preenchimento do campo no momento do pagamento (seção 3.3). A regra já estava na minuta, a versão 1.0.0, e passou sem mudança para a versão aprovada em setembro.
Os arranjos de pagamento também não enxergam os dados da nota além da chave, e por isso não validam nada. A coerência entre o documento fiscal e as partes envolvidas é responsabilidade de quem origina a transação (seção 3.4.1). Não existe conferência do banco para salvar um dado errado.
Esse vínculo não é burocracia. É ele que viabiliza a conciliação entre o tributo segregado e o documento fiscal por parte da Receita Federal e do Comitê Gestor, permitindo a extinção do débito de quem vende e o aproveitamento do crédito por quem compra (seção 3.4.2). Num pagamento com split, é esse vínculo que liga o tributo recolhido ao crédito de quem compra.
Você não tem um problema de sistema de pagamento. Tem o mesmo problema de sempre, que é a ausência de decisão sobre onde vive cada dado, agora com um prazo que ainda não tem data, mas vai ter.
Onde a conciliação quebra
O cenário abaixo é hipotético, montado com uma estrutura comum em prestadoras de serviço B2B. Os números são ilustrativos e não são medição.
Uma empresa de manutenção industrial emite cerca de 300 notas por mês. O cliente grande paga três notas de uma vez, por transferência, arredondando o valor. O financeiro concilia abrindo o extrato ao lado da planilha de contas a receber e somando até o número bater.
Isso funciona porque a conciliação acontece dias depois, na mão, com margem para interpretação. Quando o pagamento usa split, o mecanismo tira as três coisas. A separação do tributo ocorre na liquidação financeira, antes de o valor líquido chegar à conta, e o valor creditado deixa de ser o valor da nota.
O mecanismo prevê o caso das três notas juntas. Existe a figura do documento fiscal agregador, criado nos sistemas do governo, que reúne várias notas sob um único identificador, e cada transação aceita apenas um documento fiscal, único ou agregador (seção 3.4.2). Numa transferência, alguém, ou algum sistema, precisa gerar esse agregador antes do pagamento acontecer.
Existe também regra para pagamento parcial. Nos arranjos iniciados pelo recebedor o tributo segregado cai proporcionalmente ao valor pago. Nos arranjos iniciados pelo pagador não há cálculo de proporcionalidade: o valor segregado é exatamente o que o pagador digitou (seção 5.1).
Repare no que essa última frase significa. O tributo separado do seu recebimento passa a depender do que um funcionário do seu cliente digitou na hora do pagamento.
Três perguntas para fazer esta semana
A primeira é para o time de contas a receber: quando o dinheiro entra na conta, o seu sistema sabe sozinho a qual nota ele pertence, ou alguém descobre isso somando valores? Se a resposta envolve uma pessoa e uma planilha, o vínculo que o split payment exige não existe na sua operação.
A segunda é para contas a pagar: quando você paga um fornecedor por Pix ou TED, a chave da nota dele está no seu sistema naquele momento? Se a nota chega por e-mail e o valor é digitado à mão, esse é o ponto que precisa mudar.
A terceira é para quem responde pelo caixa: o seu sistema guarda o valor da nota e o valor que efetivamente caiu na conta como dois campos, ou registra só um deles? Se registra só um, alguém reconstrói o outro à mão todo mês.
A ordem importa. Resolver o cadastro e o vínculo antes de escolher ferramenta é o que separa um projeto de escopo claro de uma troca de sistema que não resolve, pelo mesmo motivo que já vale para o cadastro na reforma tributária.
Perguntas frequentes
A integração com o ERP e o banco que eu já uso vai ser complicada?
Depende menos da integração e mais do que existe para integrar. Conectar sistema e banco é trabalho conhecido, com API e retorno bancário. O trabalho difícil é anterior: definir onde mora o vínculo entre título, nota e recebimento, e quem tem autoridade para criá-lo. Empresas que já têm essa definição costumam tratar a conexão como configuração. Um exemplo de decisão de fonte única é a SuperVida, que tirou a gestão de contratos do Airtable e a levou para um ERP sob medida.
Não tenho equipe de TI para tocar isso. Dá para esperar o fornecedor do ERP resolver?
O fornecedor entrega os campos. Quem preenche o campo é a sua operação, e a obrigação de garantir a coerência entre o documento fiscal e as partes envolvidas é de quem origina o pagamento, conforme o Manual de Operações aprovado pela Receita e pelo Comitê Gestor. A parte que nenhum fornecedor faz por você é decidir de onde sai a chave da nota na hora de pagar.
Vale investir nisso agora, se a obrigatoriedade ainda não tem data em norma?
O retorno não depende do calendário tributário. Conciliação manual já consome hora de gente qualificada todo mês e já produz recebimento não identificado. O que a reforma faz é transformar um custo silencioso em risco de crédito não aproveitado, com regras que já estão aprovadas e só esperam a data. Se o número de horas gastas hoje na conciliação não estiver medido, esse é o primeiro item a levantar antes de aprovar qualquer orçamento.
O próximo passo
Se você quiser testar onde a sua operação já responde "qual nota este pagamento paga" e onde ela ainda depende de alguém somando valores no extrato, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos sobre exatamente isso.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico