No dia 05 de fevereiro de 2026, foram publicadas as primeiras diretrizes do split payment, nas Notas Técnicas de de bilhetes de passagem – BPe, água e saneamento – NFAg, CTe, CTeOS e CTeSimp.
Dentro das Notas Técnicas, a RFB trouxe alguns exemplos de transações sujeitas ao split payment, conforme segue:
Exemplo 1:
No primeiro exemplo, o boleto ou o QR Code Pix é gerado antes da emissão do documento fiscal.
Nesses casos, após a emissão do boleto, o fornecedor emitirá o documento fiscal, o qual deverá reportar os dados das transações financeiras previamente iniciadas, ainda que estejam pendentes de efetivo pagamento e liquidação, viabilizando a vinculação.

Exemplo 2:
Nesse caso, o fornecedor primeiro emite o documento fiscal e, em seguida, emite o QR code Pix para o adquirente, informando os valores do IBS e da CBS, mas sem a chave do documento fiscal previamente emitido.
A vinculação para o split payment fica inicialmente pendente, de modo que, para vinculação, o fornecedor deverá emitir um evento atrelado ao documento fiscal, com os dados do pix, que a vinculação será realizada.

Exemplo 3:
No terceiro caso, é trazido um cenário em que o documento fiscal é emitido antes mesmo da transação financeira – isto é, o adquirente efetua o pagamento via TED, informando a chave do documento fiscal. Contudo, ao preenchê-lo, comete um erro, impedindo a correta vinculação da transação e do documento fiscal.
Para solucionar o problema, o fornecedor emitirá um evento, atrelando ao documento fiscal com os dados da transação financeira (TED no caso em tela).

O que isso significa na prática?
- O split payment só acontece se o DF-e e o respectivo pagamento “conversarem”. O gatilho é a vinculação entre a transação financeira (boleto/Pix/TED) e o documento fiscal.
- A ordem dos passos pode variar, mas o resultado tem que ser o mesmo: vínculo criado. Pode nascer primeiro o boleto/QR (antes do DF-e) ou primeiro o DF-e (antes do QR/boleto). Em ambos, você precisa informar os dados do outro lado depois.
- Se não vinculou no ato, vincula depois por “evento”. Quando o Pix não leva a chave do DF-e, ou quando a TED foi preenchida com erro, a correção é: emitir um evento no DF-e com os dados do pagamento para “amarrar” tudo.
- Implica mudança operacional imediata: (i) Guardar/registrar IDs do pagamento (Pix/boletos/TED) no fluxo de faturamento; (ii) Conferir chave do DF-e quando o pagamento permitir informar; (iii) Criar rotina de conciliação (pagou ≠ vinculou, pode ser necessário disparar um evento) e (iv) tratar erro como risco fiscal, porque sem vínculo pode travar/impedir a segregação correta do IBS/CBS.
Em resumo: o split payment não é “só do banco”. A RFB está desenhando um modelo em que a empresa precisa ter processo e sistema para vincular pagamento x DF-e, inclusive com eventos de ajuste quando a vinculação não vier perfeita.