O manual do split payment não foi escrito para você, mas vai chegar no seu extrato

Em 22 de setembro de 2026, a Receita Federal e o Comitê Gestor do IBS aprovaram, pelo Ato Técnico Conjunto RFB/CGIBS nº 5, os procedimentos e padrões operacionais da Plataforma Pública do Split Payment. Quem recebe pagamento B2B de forma recorrente provavelmente não abriu esse documento, e é exatamente esse documento que vai decidir como a liquidação de cada pagamento vai casar com o documento fiscal correspondente. A documentação foi redigida pensando em quem opera o sistema, bancos e prestadores de serviço de pagamento. O formato de dado que ela estabelece, porém, não fica restrito a esse público: é o mesmo formato que o contas a receber vai precisar reconhecer para fechar a conciliação.

Escrito para o banco. Lido tarde demais pelo recebedor.

O que o Ato Técnico nº 5 aprovou

O Ato Técnico Conjunto RFB/CGIBS nº 5, de 2026-09-22, trata, segundo o próprio texto, de "procedimentos e padrões operacionais aplicáveis à Plataforma Pública do Split Payment", conforme publicado pela RFB e pelo CGIBS. Entre os documentos aprovados está o manual de operações da plataforma, que descreve como a liquidação de um pagamento deve ser estruturada para que o valor do tributo segregado (a parcela de CBS e IBS retida no próprio pagamento) possa ser identificado e vinculado ao documento fiscal que originou a cobrança.

Esse é um ponto que merece precisão: a aprovação formaliza o padrão técnico, não a obrigatoriedade de uso do split payment em 2026. A operação de recolhimento segregado continua sendo uma decisão do contribuinte quanto ao modelo de recolhimento que vai adotar; o que o Ato Técnico fixa é o formato da informação, para que, quando e onde o split payment for aplicado, a Plataforma Pública opere de forma padronizada entre todos os participantes, independentemente de qual instituição processa a liquidação.

Padronizar o formato antes de padronizar o uso é decisão de quem constrói infraestrutura para durar.

Vale notar a diferença entre esse ato e os atos conjuntos anteriores da Reforma Tributária voltados a documento fiscal eletrônico. Enquanto o Ato Conjunto RFB/CGIBS nº 4 tratou de leiaute de NF-e, CT-e e documentos similares, o Ato Técnico nº 5 trata de uma camada distinta, a da liquidação financeira do pagamento. São dois fluxos que, até aqui, evoluíram de forma relativamente independente dentro de boa parte dos projetos de adequação fiscal em SAP: um cuida do documento que sai do faturamento, o outro cuida do dinheiro que entra pela tesouraria. A Plataforma Pública do Split Payment é o ponto em que esses dois fluxos passam a precisar conversar formalmente.

Testes a partir de 15 de outubro

Em 2026-09-30, a Receita Federal publicou comunicado informando que, "a partir de 15 de outubro de 2026 terá início a fase de testes de integração entre os Prestadores de Serviços de Pagamento (PSPs) e a Plataforma Pública do Split Payment", segundo divulgação oficial. Essa fase de testes é o primeiro momento em que o padrão aprovado em setembro vai operar na prática, mesmo que ainda de forma restrita aos participantes que estiverem integrando seus sistemas à plataforma.

O intervalo entre a aprovação da documentação técnica e o início dos testes de integração é curto, menos de um mês. Isso significa que o período disponível para quem não é PSP, mas vai receber pagamentos processados por esse padrão, se informar sobre o conteúdo do manual e avaliar o impacto na própria operação de contas a receber também é curto. Esperar os testes terminarem para começar a ler a documentação significa chegar atrasado ao mesmo ritmo que o próprio cronograma já está impondo aos participantes diretos.

Um mês entre aprovar o padrão e começar a testá-lo. Quase nenhum tempo para quem só vai descobrir o formato no extrato.

Testes de integração entre PSPs e uma plataforma pública costumam seguir um padrão conhecido em projetos de infraestrutura financeira: a fase inicial valida o protocolo técnico entre os participantes diretos, e só depois a camada de retorno de informação para quem recebe o pagamento é exercitada de fato. Isso significa que o formato final do extrato ou do retorno bancário que vai chegar ao contas a receber pode só se estabilizar depois que essa primeira rodada de testes identificar ajustes necessários no próprio padrão publicado em setembro. Acompanhar essa fase de longe, sem indicar interesse junto ao banco ou PSP parceiro, é abrir mão de influenciar como esse formato final vai se parecer quando chegar.

O que o recebedor precisa extrair dessa documentação

Sem ter lido o manual de operações na íntegra, o que é possível afirmar com segurança a partir do que já está confirmado nas fontes oficiais é a natureza do problema que ele resolve: definir como a parcela de tributo segregada em um pagamento se conecta ao documento fiscal que a originou. Essa conexão é o núcleo técnico de qualquer modelo de split payment, porque sem ela o recebedor não consegue provar que o valor líquido recebido, somado ao tributo retido na origem, corresponde exatamente ao valor da nota fiscal emitida.

O que o contas a receber precisa descobrir, ao consultar essa documentação quando ela for lida com o detalhe técnico que merece, é qual identificador vincula a liquidação bancária ao documento fiscal, de que forma o valor segregado aparece no extrato ou no retorno bancário recebido, e se esse formato é compatível com o que o processo de conciliação atual do SAP já espera receber do banco. Essas três perguntas não dependem de interpretação tributária: dependem de leitura técnica cruzada entre o padrão publicado pelo CGIBS e a configuração já existente de conciliação bancária.

A diferença entre descobrir essa incompatibilidade agora e descobrir no primeiro fechamento mensal é a diferença entre um ajuste pontual de configuração e um reprocessamento em lote de todas as liquidações acumuladas no período, feito sob pressão de prazo de fechamento, não com o tempo de teste que a fase de homologação oferece.

Ler antes do extrato é diagnóstico. Ler depois é correção emergencial.

Há ainda uma quarta pergunta que normalmente só aparece depois que as três primeiras já foram respondidas: o que acontece quando a liquidação chega parcial, por atraso do pagador ou por divergência no cálculo do tributo segregado feito do lado de quem paga. O manual de operações, por tratar do funcionamento da plataforma, provavelmente define também o tratamento de exceção para esses casos. Sem conhecer esse tratamento, o contas a receber corre o risco de interpretar como erro de conciliação algo que na verdade é um fluxo previsto, ou o contrário: aceitar como normal uma divergência que o padrão técnico já classificaria como exceção a ser investigada.

Por que isso não é assunto só de banco

A resposta automática, em muitas operações, é que a Plataforma Pública do Split Payment é infraestrutura bancária, e que o papel da empresa é apenas receber o extrato que o banco ou o PSP entregar. Essa leitura ignora que o extrato recebido só tem utilidade para o contas a receber se puder ser conciliado automaticamente com o documento fiscal já lançado no SAP. Se o formato do dado que chega do PSP não for compatível com a lógica de conciliação já configurada, a diferença vira trabalho manual, nota a nota, até que alguém ajuste a integração.

Em fornecedores B2B com faturamento recorrente para clientes industriais, esse tipo de ajuste manual tende a ser amplificado pelo volume de liquidações processadas no período, o mesmo padrão que já aparece em outras mudanças de leiaute fiscal da Reforma Tributária: o volume baixo de exceção vira volume alto de regra assim que a nova obrigação entra em produção plena. A diferença, no caso do split payment, é que o problema não está na emissão do documento fiscal, mas na etapa seguinte, quando o valor do pagamento precisa ser reconciliado com aquilo que já foi emitido.

O banco processa a liquidação. A empresa é quem precisa provar que ela bate com o documento fiscal.

Essa distinção tem um efeito prático sobre quem deveria ser consultado antes de a empresa aceitar passivamente o que o banco oferecer como solução pronta. Um PSP que atende múltiplos clientes com perfis de recebimento diferentes tende a oferecer um formato de retorno padronizado, pensado para o menor denominador comum entre seus clientes, não necessariamente para a lógica de conciliação específica que o SAP de cada empresa já tem configurada. Aceitar esse formato padrão sem confrontá-lo com o processo interno é transferir, sem perceber, o desenho da própria conciliação para um terceiro que nunca viu a configuração do sistema.

Um plano de leitura conjunta: Fiscal, Tesouraria e TI

O manual de operações aprovado pelo Ato Técnico nº 5 não é documento que caiba inteiramente em uma única área. A Tesouraria é quem trata diretamente da liquidação bancária e do retorno recebido do PSP. O Fiscal é quem entende a regra de CBS e IBS aplicada ao documento e precisa validar se o valor segregado está coerente com o que foi calculado na nota. A TI é quem vai, de fato, configurar a integração entre o retorno bancário recebido e o processo de conciliação dentro do SAP.

Ler esse manual isoladamente em qualquer uma dessas três áreas tende a produzir uma leitura incompleta. A Tesouraria pode entender o fluxo de liquidação sem perceber a implicação fiscal da segregação. O Fiscal pode validar a regra tributária sem considerar o formato técnico que o PSP vai efetivamente devolver. A TI pode configurar uma integração tecnicamente correta sem saber que critério de conciliação o Fiscal precisa ver satisfeito antes de dar baixa no documento. O ponto de leitura conjunta existe justamente para fechar essas três lacunas antes que os testes de integração de 15 de outubro revelem a primeira divergência real.

Três áreas, um documento, nenhuma leitura isolada é suficiente.

Um formato prático para essa leitura conjunta é tratar o manual como um documento de requisitos, não como uma norma a ser arquivada depois de uma primeira passada de olhos. Cada área extrai, da sua perspectiva, o que o padrão exige: a Tesouraria mapeia o formato de retorno esperado, o Fiscal confirma se a segregação descrita bate com a regra de CBS e IBS já parametrizada no Guepardo Tax, a TI verifica se a estrutura de dado é compatível com o que a interface bancária do SAP já processa. O encontro dessas três leituras, documentado, é o que transforma uma norma técnica genérica em um plano de ação específico para aquela operação.

A pergunta que decide se a leitura já começou

Antes de qualquer decisão sobre modelo de recolhimento, que continua sendo escolha tributária do contribuinte, existe uma pergunta puramente operacional que já pode ser respondida hoje: alguém do contas a receber já leu o manual de operações do split payment, ou essa leitura ficou inteiramente a cargo do banco? Se a resposta for a segunda, a empresa está delegando a um terceiro a definição do formato de dado que ela mesma vai precisar conciliar, sem ter verificado se esse formato é compatível com o que o SAP já processa hoje.

A documentação técnica de setembro não decide se a empresa vai usar split payment nem em que medida. Decide, para quem usar, como o dado da liquidação vai precisar casar com o documento fiscal. Essa segunda pergunta é operacional, está disponível desde 2026-09-22, e não depende de nenhuma decisão tributária futura para começar a ser respondida.

O Diagnóstico Fiscal Estruturado da DFSpro apoia justamente essa etapa: lê o padrão técnico publicado pelo Comitê Gestor junto com a configuração de conciliação bancária já existente no SAP e mostra, com prova de sistema, onde o vínculo entre liquidação e documento fiscal com CBS e IBS já está preparado e onde ainda depende de ajuste antes que o primeiro extrato real chegue sem conciliar.