Data da Publicação: 04 de fevereiro de 2026
Versão: 1.00
Referência Legal: LC 214/2025 e LC 227/2026
1. Contexto e objetivo da Nota Técnica
Com a implementação do split payment no âmbito da Reforma Tributária, tornou-se essencial vincular corretamente o Documento Fiscal eletrônico (DFe) à respectiva transação financeira. Essa vinculação é o que permite:
- a correta apuração dos débitos tributários do fornecedor;
- a adequada concessão de créditos ao adquirente;
- a operacionalização eficiente do split payment, especialmente em sua modalidade superinteligente.
A Nota Técnica 2026.001 disciplina como informar essa vinculação diretamente no DFe ou por meio de evento específico, quando a transação financeira não contém, desde o início, a chave do documento fiscal.
2. O que é a vinculação entre DFe e pagamento
A vinculação consiste na associação lógica entre o documento fiscal emitido e a transação financeira correspondente (Pix, boleto, TED etc.).
⚠️ Importante destacar que:
- a vinculação não significa que o pagamento foi efetivamente realizado;
- ela representa uma expectativa de pagamento, que pode ou não se concretizar (ex.: boleto emitido e não pago).
Mesmo assim, essa informação é indispensável para o funcionamento do split payment.
3. Como a vinculação pode ocorrer
Existem duas formas de vinculação no modelo do split payment:
- Informação da chave do DFe na transação de pagamento, no momento em que o pagamento é iniciado;
- Informação dos dados da transação financeira no próprio DFe ou por meio de evento específico.
👉 Esta Nota Técnica trata exclusivamente da segunda forma.
4. Quando informar a vinculação no próprio DFe
O grupo de informações de vinculação deve ser preenchido quando a transação de pagamento for iniciada antes da emissão do DFe, por exemplo:
- boleto emitido antes da nota fiscal;
- QR Code Pix dinâmico gerado antes da emissão do DFe.
Nesses casos, o DFe deve registrar os dados da transação financeira mesmo que o pagamento ainda não tenha sido liquidado.
Principais informações exigidas
Para cada pagamento previsto, devem ser informados, entre outros:
- identificador da transação financeira;
- meio de pagamento (boleto, Pix, TED etc.);
- CNPJ do recebedor do pagamento (que pode ser diferente do emissor do DFe);
- CNPJ base da instituição financeira ou do prestador de serviço de pagamento.
A validação do CNPJ do recebedor é obrigatória e pode gerar rejeição do documento em caso de inconsistência.
5. Evento de vinculação da transação de pagamento
Quando o DFe já foi autorizado sem a vinculação do pagamento, o emitente deverá utilizar um evento específico para realizar essa associação.
Características principais do evento
- Código do evento: 110300 – Vinculação Pagamento;
- Autor: o próprio emissor do DFe;
- Finalidade: vincular uma ou mais transações financeiras a um DFe já autorizado;
- Situação da transação: pode estar apenas iniciada, ainda sem liquidação.
Esse evento é essencial para corrigir cenários como:
- pagamento iniciado sem a chave do DFe;
- erro no preenchimento da chave do documento na transação financeira;
- emissão do DFe antes da definição do meio de pagamento.
Se homologado, o evento retorna com cStat = 135, indicando sucesso.
6. Cancelamento do evento de vinculação
Caso o evento de vinculação tenha sido gerado com erro, existe a possibilidade de cancelamento específico.
Evento de cancelamento
- Código do evento: 110301 – Cancelamento da Vinculação do Pagamento;
- Pré-requisito: existência de um evento de vinculação previamente autorizado;
- Efeito: o evento original passa à condição de anulado.
Assim como no evento de vinculação, o cancelamento homologado retorna com cStat = 135.
7. Impactos práticos para contribuintes e sistemas
A correta e tempestiva vinculação entre DFe e pagamento:
- aumenta as chances de execução do split payment superinteligente;
- reduz a necessidade de ajustes posteriores e devoluções de valores;
- exige atenção especial dos emissores, plataformas e integradores de sistemas.
⏱️ Quanto maior o atraso na informação da vinculação, maior a probabilidade de o sistema executar apenas o split inteligente offline, com retenções temporárias e posterior restituição.
