Até semana passada, o split payment era problema do banco. O ato publicado no Diário Oficial de ontem mudou o endereço: agora a sua nota fiscal precisa dizer como a operação foi paga — e existe uma rejeição esperando quem errar o código.
- O Ato Técnico Conjunto RFB/SUFIS/CGIBS nº 2, de 21/08/2026 (DOU de 24/08) aprovou a Nota Técnica 2026.006 v1.00 — "Vinculação com a Transação de Pagamento do DF-e" para a NF-e (modelo 55) e a NFC-e (modelo 65).
- A vinculação de pagamento já existia para CT-e, BP-e, NF3e, NFCom, NFAg e NFGas, pelas NTs 2026.001. Agora ela chega aos dois documentos que a esmagadora maioria das empresas emite.
- O grupo de campos é, nas palavras do Informe Técnico oficial, "voltado para as informações que serão utilizadas no sistema do Split Payment" — é a ponte entre a nota fiscal e o pagamento que permite separar o tributo na liquidação.
- São 6 códigos válidos de meio de pagamento: boleto (15), Pix QRCode (17), TED (18), Pix chave ou QRCode estático (20), Pix automático (23) e TEF/booktransfer (24). Código diferente disso gera a rejeição 1003 — "Tipo de Pagamento inválido".
- Os mesmos 6 arranjos do Manual de Integração da Plataforma de Split Payment. Cartão de crédito e débito continuam fora — dos dois lados.
Publicamos ontem uma análise do Manual de Integração da Plataforma de Split Payment, e a conclusão era tranquilizadora: aquele documento é dirigido a prestadores de serviço de pagamento — bancos, instituições de pagamento, gateways —, não ao lojista. O Informe de Segregação, com seus lotes de mil transações e seus três passos de remessa, é obrigação técnica do PSP. O CFO não precisava reescrever ERP nenhum.
Aquilo continua verdadeiro. Mas o Diário Oficial de ontem trouxe a peça complementar — e essa, sim, é do lado de cá. É mais um capítulo do calendário que vem sendo montado desde o Ato Conjunto nº 4, que fixou as datas dos documentos fiscais.
O que foi publicado
O Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 2, de 21 de agosto de 2026, assinado pela Subsecretaria de Fiscalização da Receita Federal e pela Diretoria-Executiva do Comitê Gestor do IBS, aprovou um conjunto de documentação técnica de documentos fiscais eletrônicos. A lista é longa e inclui manuais de NFAg, NFGas e da nova NF-e de Alienação de Bens Imóveis. Mas dois itens mudam o dia a dia de quem emite nota:
- Nota Técnica 2026.006 – versão 1.00 – Vinculação com a Transação de Pagamento do DF-e, aplicável à NF-e modelo 55 e à NFC-e modelo 65;
- Informe Técnico 2026.001 – versão 1.01 – Tabelas de Meios de Pagamento para Vinculação Pagamento.
O ato entra em vigor e produz efeitos na data da publicação — o mesmo padrão de vigência imediata que já vimos nos ajustes anteriores da NF-e. A documentação fica disponível nos portais oficiais dos documentos fiscais eletrônicos.
O que é a "vinculação de pagamento" — e por que ela existe
O split payment promete separar o tributo no momento da liquidação financeira. Para isso funcionar, alguém precisa dizer ao sistema qual documento fiscal corresponde a qual pagamento. Sem essa amarração, o banco vê dinheiro entrando e não sabe quanto daquilo é IBS e CBS.
É exatamente essa a função do grupo de campos criado pelas Notas Técnicas. O Informe Técnico oficial é explícito ao descrever a estrutura como "voltada para as informações que serão utilizadas no sistema do Split Payment", contendo uma tag para informar o código do meio de pagamento utilizado na transação.
A novidade não é o conceito — as NTs 2026.001 já haviam introduzido esse grupo no CT-e, no BP-e, no NF3e, no NFCom, no NFAg e no NFGas. A novidade é o alcance: com a NT 2026.006, a vinculação chega à NF-e e à NFC-e. São os documentos da indústria, do comércio, do atacado, do varejo — de praticamente todo mundo, incluindo os setores regulados que acompanhamos de perto.
O Manual de Integração de junho descreveu o que o PSP faz: receber, segregar e informar. A NT 2026.006 descreve o que o emissor faz: identificar, no próprio documento fiscal, como aquela operação será paga. São as duas pontas da mesma ponte — e a segunda acaba de ser construída.
Os 6 códigos válidos — e a rejeição que espera quem errar
O Informe Técnico 2026.001 fixa quais códigos da tabela nacional de meios de pagamento podem ser usados no grupo de vinculação:
| Código | Meio de pagamento |
|---|---|
| 15 | Boleto |
| 17 | Pix QRCode |
| 18 | TED |
| 20 | Pix chave ou QRCode estático |
| 23 | Pix automático (código novo) |
| 24 | TEF / booktransfer (código novo) |
E a consequência de errar está escrita na norma, sem eufemismo: "a utilização de um código diferente dos relacionados acima causará a rejeição 1003 – Tipo de Pagamento inválido". Não é advertência, não é alerta de conformidade: é nota que não passa.
Vale notar que dois desses códigos — o 23 (Pix automático) e o 24 (TEF/booktransfer) — são novos e serão incluídos na tabela nacional. Quem mantém tabela de domínio espelhada no ERP precisa atualizá-la, ou vai rejeitar internamente um código que a SEFAZ aceita.
A simetria que confirma a arquitetura
Compare as duas listas. O Manual de Integração da Plataforma de Split Payment cobre boleto, Pix Dinâmico, Pix Automático, Pix Estático, TED e TEF. O Informe Técnico da vinculação aceita boleto, Pix QRCode, TED, Pix estático, Pix automático e TEF. São os mesmos seis arranjos, dos dois lados.
Isso diz duas coisas ao CFO. A primeira é que a arquitetura é coerente: o que o PSP consegue segregar é exatamente o que o emissor consegue declarar. A segunda é mais prática — cartão de crédito e de débito continuam fora dos dois documentos. Quem tem receita relevante em cartão segue, por ora, no regime de apuração pelo próprio contribuinte, e sem data definida para mudar — cenário que já havíamos mapeado nos três cenários de preparação ao split.
O que isso muda no seu ERP
Aqui é onde a conversa sai do normativo e entra no orçamento. A vinculação exige que o sistema emissor saiba, no momento da emissão, o meio de pagamento da operação — e o informe corretamente. Parece trivial e não é, por três razões:
O dado nem sempre está no emissor
Em muitas operações B2B, a nota é emitida antes de o pagamento ser definido, ou o financeiro decide a forma depois. A informação que a NT pede pode estar no contas a receber, não no faturamento — e os dois sistemas precisam conversar.
Tabela de domínio desatualizada rejeita nota
Os códigos 23 e 24 são novos. ERP com tabela fixa, sem atualização, vai barrar internamente ou enviar código inválido — e cair na rejeição 1003.
Operações com pagamento misto
Venda paga parte em boleto, parte em Pix, parte em cartão. Como o cartão está fora do escopo, a operação fica repartida entre o que entra na vinculação e o que não entra — e isso precisa estar desenhado antes, não descoberto na rejeição.
É o mesmo tipo de trabalho que a regra de validação 1115 exigiu em agosto, e que a adaptação dos sistemas fiscais vem cobrando desde o início do ano: não é reescrever o ERP, é garantir que um campo novo seja preenchido com o dado certo, vindo do lugar certo.
O que fazer nesta semana
- Pergunte ao fornecedor do seu ERP se ele já implementou a NT 2026.006 para NF-e e NFC-e, e em que versão. Essa é a pergunta que destrava tudo — e a resposta dele diz se o problema é seu ou dele.
- Confira a tabela de meios de pagamento do seu sistema: os códigos 23 e 24 precisam existir. Tabela de domínio congelada é a causa mais banal de rejeição.
- Mapeie de onde vem o dado do meio de pagamento no seu fluxo. Se ele nasce no contas a receber e a nota sai do faturamento, há uma integração a fazer.
- Liste as operações com pagamento misto e defina o tratamento antes de a primeira nota ser rejeitada.
- Se você é do Simples, confira também como as opções de tributação do IBS e da CBS interagem com o seu documento fiscal.
- Não confunda com o Informe de Segregação. Aquele continua sendo do seu PSP — e vale confirmar com ele o roadmap de adequação, como detalhamos na análise do Manual de Integração.
Para quem opera no Simples e está com a cabeça na janela de setembro, vale a distinção: essa vinculação acompanha o regime de emissão do documento fiscal, e não a decisão de recolher IBS e CBS dentro ou fora do DAS — que é assunto do Roteiro da Opção publicado pela Receita na mesma semana. São dois calendários distintos correndo em paralelo, como já são o da NFS-e e o do Arquivo Local em outubro.
A Algoritimado é CFO fracionado para mercados regulados. Quando um dado precisa atravessar faturamento, contas a receber e emissor fiscal, o problema deixou de ser de TI e virou de governança financeira.
Falar com a Algoritimado Conhecer a ferramenta gratuita de TPPerguntas frequentes
- O que é a vinculação com a transação de pagamento na NF-e?
- É um grupo de campos no documento fiscal eletrônico que identifica como a operação foi paga, criado para alimentar o sistema do split payment. Ele permite amarrar o documento fiscal à transação financeira, para que o tributo possa ser separado na liquidação. Foi levado à NF-e (modelo 55) e à NFC-e (modelo 65) pela Nota Técnica 2026.006 v1.00, aprovada pelo Ato Técnico Conjunto RFB/CGIBS nº 2, de 21/08/2026.
- Quais são os códigos de meio de pagamento aceitos?
- Seis, conforme o Informe Técnico 2026.001: 15 (boleto), 17 (Pix QRCode), 18 (TED), 20 (Pix chave ou QRCode estático), 23 (Pix automático) e 24 (TEF/booktransfer). Os códigos 23 e 24 são novos e serão incluídos na tabela nacional de meios de pagamento.
- O que acontece se eu informar um código errado?
- O documento é rejeitado. O Informe Técnico é expresso: "a utilização de um código diferente dos relacionados acima causará a rejeição 1003 – Tipo de Pagamento inválido". Por isso a tabela de domínio do ERP precisa estar atualizada com os códigos 23 e 24.
- Cartão de crédito e débito entram no split payment?
- Não, nem no lado do emissor nem no do prestador de pagamento. Os seis códigos da vinculação correspondem exatamente aos seis arranjos cobertos pelo Manual de Integração da Plataforma de Split Payment (boleto, Pix nas três modalidades, TED e TEF). Cartões não constam de nenhum dos dois documentos, e não há ato definindo quando entram.
- Isso é a mesma coisa que o Informe de Segregação?
- Não. O Informe de Segregação é obrigação técnica do prestador de serviço de pagamento, que comunica à plataforma os valores de IBS e CBS efetivamente segregados na liquidação. A vinculação de pagamento é obrigação do emissor do documento fiscal, que informa como a operação será paga. São as duas pontas do mesmo mecanismo, com responsáveis diferentes.
- Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 2, de 21 de agosto de 2026 — publicado no DOU de 24/08/2026 e no sítio do CGIBS; PDF oficial consultado em cgibs.gov.br/atos-tecnicos-conjuntos em 25/08/2026. Art. 1º, I, "a" (NT 2026.006) e "e" (IT 2026.001 v1.01); art. 2º (vigência na publicação).
- Informe Técnico 2026.001 v1.00 — Tabela de Meios de Pagamento para Vinculação Pagamento (Projeto RTC), consultado no portal de DF-e da SEFAZ Virtual RS: introdução, tabela de códigos e regra da rejeição 1003.
- Decreto nº 12.955/2026 (arts. 112 e 116) e Resolução CGIBS nº 6/2026 — fundamento do ato; Resolução CGIBS nº 17, de 30/07/2026 — competência.
Conteúdo informativo; não constitui parecer jurídico ou contábil, nem substitui a análise do caso concreto. Documentação técnica de documentos fiscais é atualizada com frequência — confirme sempre a versão vigente nos portais oficiais antes de implementar.
0 comentários