NT 2026.006 v1.01: vinculação da transação de pagamento, evento 110300 e prazos

A nota técnica cria na NF-e e na NFC-e o grupo que liga o documento fiscal ao boleto, ao Pix ou à TED usados no pagamento. Cria também um evento para fazer essa ligação depois da autorização. A versão 1.01 fixa a homologação até 26 de outubro e a produção em 16 de novembro de 2026.

1. O que é a NT 2026.006

A Nota Técnica 2026.006, “Reforma Tributária do Consumo, Vinculação com a Transação de Pagamento do DF-e”, foi publicada em 25 de agosto de 2026 no Portal da Nota Fiscal Eletrônica. A versão em vigor é a 1.01, de outubro de 2026, publicada em 30 de outubro. Ela só altera as datas de implantação e foi aprovada pelo Ato Técnico Conjunto nº 10, de 28 de outubro. O PDF tem dez páginas e vale para a NF-e e para a NFC-e, modelos 55 e 65. Está no hub de conteúdos da Migrate, com download direto.

A nota tem caráter preparatório. O texto diz que a implantação do split payment está prevista para 2027. Por isso, não há exigência de preenchimento ou uso dos campos em produção em 2026. A ativação efetiva ocorrerá quando o mecanismo entrar em vigência, e as orientações virão pelos canais do CGIBS e da Receita Federal.

O objetivo é permitir que fiscos, emissores e demais atores planejem, desenvolvam e testem as adaptações com antecedência. Quem quiser entender o mecanismo antes de ler a nota pode começar por Split payment: o que é e como se conecta à apuração assistida.

A NF-e chega por último a esse grupo de campos. As Notas Técnicas 2026.001 de CT-e, BP-e, NF3e, NFCom, NFAg e NFGas criaram a mesma estrutura nesses documentos no primeiro semestre. O Informe Técnico 2026.001, publicado no mesmo dia que a nota, traz a tabela de códigos de meio de pagamento que todos eles usam.

2. Por que vincular o documento fiscal à transação de pagamento

A introdução explica a necessidade. No split payment, a instituição de pagamento separa o IBS e a CBS no momento da liquidação. Para isso, precisa saber a qual documento fiscal aquela transação pertence. A nota diz que a vinculação é estritamente necessária para apurar os débitos do fornecedor e conceder os créditos ao adquirente.

Há duas formas de o contribuinte indicar o vínculo. Na primeira, ele transmite a chave do documento fiscal ao prestador de serviço de pagamento no início da transação. Na segunda, informa os dados da transação financeira em campos do documento ou em um evento. A NT 2026.006 detalha a segunda forma.

A nota faz um alerta. O vínculo indicado pelo contribuinte não significa pagamento efetuado e liquidado. Ele indica uma expectativa de pagamento, que pode ou não se concretizar. Um boleto pode ser emitido e não ser pago.

O tempo importa. Nas transações originadas pelo fornecedor, a vinculação precisa acontecer antes da liquidação para viabilizar o que a nota chama de split payment superinteligente. Quanto mais o fornecedor demorar para reportar o vínculo, menor a chance de esse split ser executado. Sem ele, roda o split inteligente offline, com devolução do valor retido a maior em até três dias úteis.

A nota traz três exemplos. No primeiro, o fornecedor emite um boleto antes do documento fiscal. Como o boleto saiu sem a chave, o vínculo fica pendente. Ao emitir o documento, o fornecedor preenche o grupo YC com os dados do boleto e fecha o vínculo.

No segundo, o fornecedor emite o documento e depois gera um QR Code Pix dinâmico com os valores de IBS e CBS, mas sem a chave do documento. A nota cita aqui o § 2º-A do artigo 32 da Lei Complementar 214, com redação da Lei Complementar 227. Para efetivar o vínculo, o fornecedor envia o evento com os dados do Pix.

No terceiro, o adquirente paga por TED informando a chave, mas erra o preenchimento. O erro impede a vinculação. O fornecedor resolve enviando o evento com os dados da transação.

3. O grupo YC no leiaute da NF-e e da NFC-e

A nota cria o grupo YC, “Informações da Vinculação com a Transação de Pagamento do DF-e (Split Payment)”. Ele deve ser informado sempre que a transação de pagamento começar antes da emissão do documento. Os exemplos da nota são o boleto e o QR Code Pix dinâmico gerados antes do DF-e. Nesse caso, o documento reporta as transações já iniciadas, mesmo que ainda pendentes de pagamento e liquidação.

O grupo gPgtoVinc, YC01, é opcional e fica no nível da nota. Dentro dele, o grupo gPgto, YC02, repete de 1 a 99 vezes, uma para cada pagamento previsto. Cada ocorrência leva cinco informações, descritas na tabela a seguir.

ID	Campo	Tipo	Tamanho	O que informa
YC01	gPgtoVinc	grupo, 0-1		Vinculação com a transação de pagamento
YC02	gPgto	grupo, 1-99		Dados de cada pagamento previsto
YC03	nPag	atributo numérico	3	Numerador único de cada pagamento
YC04	idTransacao	atributo texto	2 a 35	Identificador da transação financeira
YC05	tpMeioPgto	numérico	2	Código do meio de pagamento, pela tabela do Informe Técnico 2026.001
YC06	CNPJReceb	texto	14	CNPJ completo de quem recebe o pagamento
YC07	CNPJBasePSP	texto	8	CNPJ base da instituição financeira ou de pagamento do recebedor

Dois detalhes do CNPJ do recebedor. Ele é o responsável por receber os valores do adquirente na transação. A nota diz que ele pode ser diferente do CNPJ do fornecedor que consta no documento fiscal, como no caso de uma plataforma que recebe pelo vendedor.

O grupo YC não substitui os grupos já existentes. A nota deixa claro que o preenchimento dele não dispensa os grupos YA, Informações de Pagamento, e YB, Informações do Intermediador da Transação, exigidos pela legislação estadual. Isso vale mesmo quando os dois grupos trazem os mesmos códigos de tipo de pagamento.

4. As regras de validação do grupo YC

A nota inclui quatro regras para o grupo, todas para os modelos 55 e 65. Duas vêm do esquema XML e duas conferem o conteúdo informado.

YC03-10 rejeita o atributo nPag duplicado dentro do grupo, e YC04-20 rejeita o atributo idTransacao duplicado. As duas devolvem o código 215, falha no esquema XML, porque a validação é feita pelo schema.

YC05-10 rejeita o código de meio de pagamento inválido, em cada ocorrência de gPgto, com o código 1273 e a mensagem “Meio de pagamento inválido”, seguida do nPag. YC06-10 rejeita o CNPJ do recebedor inválido, código 1274, também com o nPag na mensagem.

Regra	Modelo	Rejeição	O que valida
YC03-10	55/65	215	nPag duplicado, pelo schema
YC04-20	55/65	215	idTransacao duplicado, pelo schema
YC05-10	55/65	1273	Meio de pagamento inválido, por ocorrência
YC06-10	55/65	1274	CNPJ do recebedor inválido, por ocorrência

Os códigos válidos de meio de pagamento estão no Informe Técnico 2026.001. A versão 1.01, de agosto de 2026, lista seis códigos para o grupo de vinculação: boleto (15), Pix QR Code (17) e TED (18). Também Pix por chave ou QR Code estático (20), Pix automático (23) e TEF ou book transfer (24). O informe marca os dois últimos como códigos novos, a atualizar na tabela nacional.

O informe diz que código fora dessa lista causa a rejeição 1003, tipo de pagamento inválido. A nota técnica, por sua vez, atribui ao meio de pagamento inválido no grupo YC o código 1273. O informe também avisa que novos códigos entram por atualização dele.

5. O evento 110300 de vinculação da transação de pagamento

Nem sempre a transação começa antes do documento. Para os casos em que o documento já foi autorizado, a nota cria o evento “Vinculação Pagamento”, código 110300. O emitente gera o evento sempre que quiser vincular uma ou mais transações financeiras a um documento autorizado. A transação pode estar apenas iniciada, como um boleto emitido ou um QR Code Pix gerado.

O autor é o emitente da NF-e ou da NFC-e, e o evento vale para os modelos 55 e 65. A parte específica vai na tag detEvento do web service de registro de eventos, descrito na seção 5.8 do Manual de Orientação do Contribuinte. O schema geral é o envEventoNFe_v9.99.xsd e o específico é o e110300_v1.00.xsd.

Os campos do evento repetem a lógica do grupo YC. A descrição é “Vinculação Pagamento”, o tipo de autor é 1, empresa emitente, e o evento leva o número do protocolo de autorização do documento. Depois vem o grupo gPgto, com idTransacao, tpMeioPgto, CNPJReceb e CNPJBasePSP, nos mesmos tamanhos do leiaute.

ID	Campo	Ocorrência	Tamanho	O que informa
P19	descEvento	1-1	20	Texto fixo “Vinculação Pagamento”
P21	tpAutor	1-1	1	Informar 1, empresa emitente
P23	nProt	1-1	15	Protocolo de autorização do documento
P24	gPgto	1-1		Dados do pagamento previsto
P25	idTransacao	1-1	2 a 35	Identificador da transação financeira
P26	tpMeioPgto	1-1	2	Código do meio de pagamento, Informe Técnico 2026.001
P27	CNPJReceb	1-1	14	CNPJ completo do recebedor
P28	CNPJBasePSP	1-1	8	CNPJ base da instituição de pagamento do recebedor

O evento tem três regras específicas, além das regras gerais do item 5.8.4 do manual. P21-10 rejeita tipo de autor diferente de 1 com o código 466. P26-10 rejeita o meio de pagamento inválido com o código 1273. P27-10 rejeita o CNPJ do recebedor inválido com o código 1274.

Para cancelar um evento de vinculação, a nota aponta o evento genérico 110001, Cancelamento de Evento, especificado na NT 2025.002-RTC. Não há evento de cancelamento próprio.

A nota também separa o novo evento de outro já existente. O evento 110300 não substitui o evento de Conciliação Financeira, a ECONF, instituído pela NT 2024.002 e exigido conforme a legislação estadual. Os dois convivem. Sobre o papel dos eventos na apuração, veja Eventos fiscais na NF-e e NFC-e.

6. Datas e passos para implementar

O cronograma da versão 1.00 trazia homologação em 5 de outubro e produção em 3 de novembro de 2026. Em 27 de outubro, um aviso do ENCAT no portal da SVRS levou a produção para 16 de novembro de 2026. A versão 1.01, publicada em 30 de outubro, grava as datas novas: homologação até 26 de outubro e produção em 16 de novembro de 2026.

Vale repetir o que a própria nota diz: não há exigência de preenchimento ou uso dos campos em produção em 2026. A data de produção é a do leiaute e das regras, para quem quiser enviar o grupo ou o evento. A obrigação virá com instrumentos do CGIBS e da Receita Federal, quando o split payment entrar em vigência, previsto para 2027.

1. Inclua o grupo gPgtoVinc no gerador do XML da NF-e e da NFC-e, com até 99 ocorrências de gPgto e numerador único por ocorrência.
2. Guarde, no sistema de faturamento, o identificador da transação de cada boleto, Pix ou TED gerado antes da nota. É ele que vai no idTransacao, com 2 a 35 caracteres.
3. Parametrize o tpMeioPgto pela tabela do Informe Técnico 2026.001 e acompanhe as atualizações do informe, porque a lista de códigos cresce por ele.
4. Cadastre, por meio de recebimento, o CNPJ do recebedor e o CNPJ base da instituição de pagamento. Em venda por plataforma, o recebedor pode não ser o emitente.
5. Implemente o evento 110300 para as transações iniciadas depois da autorização, com o schema e110300_v1.00.xsd, e o cancelamento pelo evento 110001.
6. Mantenha os grupos YA e YB como estão. O grupo YC é adicional, não substitui nenhum dos dois.
7. Teste em homologação, com implantação prevista até 26 de outubro pela versão 1.01. Cubra o grupo e o evento: um boleto emitido antes da nota e um Pix gerado depois dela.

Se a sua equipe está preparando a vinculação do pagamento, a Migrate acompanha a nota técnica desde a publicação e pode ajudar na leitura, em parceria com a sua equipe.

7. Perguntas frequentes

Preciso preencher o grupo YC a partir de 16 de novembro?
Não. A nota diz que não há exigência de preenchimento ou uso dos campos em produção em 2026. A data de 16 de novembro é a da entrada do leiaute e das regras em produção. A obrigação virá quando o split payment entrar em vigência, previsto para 2027, por instrumentos do CGIBS e da Receita Federal.

Quando uso o grupo YC e quando uso o evento 110300?
O grupo YC vai no XML quando a transação de pagamento começou antes da emissão do documento, como um boleto ou um QR Code Pix dinâmico gerados antes. O evento 110300 serve para vincular transações a um documento já autorizado, como um Pix gerado depois da nota ou uma TED com a chave preenchida errada.

O grupo YC substitui o grupo de pagamento YA ou o intermediador YB?
Não. A nota diz que o preenchimento do grupo YC não dispensa os grupos YA, Informações de Pagamento, e YB, Informações do Intermediador da Transação, exigidos pela legislação estadual. Isso vale mesmo quando os grupos trazem os mesmos códigos de tipo de pagamento.

O evento 110300 substitui a conciliação financeira?
Não. A nota diz que o evento de vinculação não substitui o evento de Conciliação Financeira, a ECONF, instituído pela NT 2024.002 e exigido conforme a legislação estadual. São eventos diferentes, com funções diferentes.

Quais meios de pagamento a nota aceita?
A nota remete à Tabela Nacional de Códigos de Meios de Pagamento, no Informe Técnico 2026.001. A versão 1.01 lista boleto (15), Pix QR Code (17), TED (18), Pix por chave ou QR Code estático (20), Pix automático (23) e TEF ou book transfer (24). Código fora da lista é rejeitado.

O vínculo informado prova que a nota foi paga?
Não. A nota é explícita: o vínculo indica uma expectativa de pagamento, que pode ou não se concretizar. Um boleto pode ser emitido e não ser pago. O que a vinculação faz é dizer ao sistema do split payment a qual documento aquela transação pertence.

Como cancelo um evento de vinculação enviado errado?
Pelo evento genérico 110001, Cancelamento de Evento, especificado na NT 2025.002-RTC. A NT 2026.006 não cria evento de cancelamento próprio.

Onde está o documento oficial?
No Portal da Nota Fiscal Eletrônica, em Documentos e Notas Técnicas. A versão 1.01 foi publicada em 30 de outubro de 2026, e a 1.00, em 25 de agosto. O PDF tem dez páginas. Também está no hub de conteúdos da Migrate, com download direto do PDF.

Migrate ao seu lado na vinculação do pagamento

A Migrate trabalha com documento fiscal eletrônico há mais de 20 anos, em cinco países. Acompanha cada nota técnica da Reforma desde a publicação, com a análise do que muda no código.

Se a sua software house está preparando a NF-e e a NFC-e para o split payment, vale uma conversa. Fale com um especialista da Migrate.

Referências

BRASIL. Encontro Nacional de Coordenadores e Administradores Tributários Estaduais. Nota Técnica 2026.006, Reforma Tributária do Consumo, Vinculação com a Transação de Pagamento do DF-e, versão 1.01, outubro de 2026, publicada em 30 de outubro de 2026. Portal da Nota Fiscal Eletrônica. https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=7xf05PpO4Z0=

BRASIL. Receita Federal e Comitê Gestor do IBS. Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 10, de 28 de outubro de 2026, art. 1º, inciso I, alínea “c”. Diário Oficial da União de 29 de outubro de 2026.

BRASIL. Informe Técnico 2026.001, Tabela de Meios de Pagamento para Vinculação de Pagamento, versão 1.01, agosto de 2026, publicado em 25 de agosto de 2026. Portal da Nota Fiscal Eletrônica. https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=vZg2QuZtVg0=

ENCAT. Coordenação Técnica. Alteração em datas de implantação de Notas Técnicas, aviso de 27 de outubro de 2026. Portal da SVRS, Avisos da NF-e. https://dfe-portal.svrs.rs.gov.br/Nfe/Avisos

BRASIL. Nota Técnica 2025.002-RTC, versão 1.53, publicada em 30 de outubro de 2026. Portal da Nota Fiscal Eletrônica. https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=BMcHSMEoepU=

BRASIL. Nota Técnica 2024.002, Evento de Conciliação Financeira. Portal da Nota Fiscal Eletrônica, Documentos e Notas Técnicas. https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=04BIflQt1aY=

BRASIL. Lei Complementar nº 214, de 16 de janeiro de 2025, artigo 32, § 2º-A, incluído pela Lei Complementar nº 227, de 2026. Planalto. https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp214.htm