Existe uma pergunta chegando às equipes que desenvolvem ERP, e-commerce e sistemas emissores de NF-e. Ela é sempre a mesma: o que muda na NF-e com o Split Payment?
A resposta começa pela Nota Técnica 2026.006, publicada em agosto de 2026. A partir dela, o que muda na NF-e com o Split Payment deixa de ser uma hipótese distante. Assim, o tema passa a integrar o trabalho de adequação dos emissores.
Ela altera o layout da NF-e e da NFC-e. O objetivo é permitir a vinculação do documento fiscal com a transação de pagamento. Na prática, o sistema também passa a registrar dados que relacionam a nota à operação financeira.
Por isso, entender o que muda na NF-e com o Split Payment não pode ficar para 2027. O mecanismo de segregação automática de IBS e CBS ainda tem cronograma próprio, mas a adaptação técnica já começou.
De acordo com a nota técnica, o ambiente de homologação está aberto desde 3 de agosto de 2026. Em seguida, a entrada em produção está prevista para 5 de outubro, de forma facultativa.
O Split Payment começa antes da obrigatoriedade
O Split Payment separa automaticamente a parcela de IBS e CBS no momento do pagamento. Em seguida, o mecanismo recolhe o valor diretamente para o Fisco. De acordo com a Lei Complementar 214/2025, esse desenho faz parte do novo modelo tributário.
Embora 2027 seja associado ao início do Split Payment, sua adoção será facultativa nesse ano. Por outro lado, a obrigatoriedade entre empresas está projetada para 2028. Portanto, isso não elimina a necessidade de preparar o emissor agora.
Esse calendário explica o que muda na NF-e com o Split Payment. Também mostra por que a preparação técnica não deve acompanhar apenas a data de obrigatoriedade. A data de segregação efetiva do dinheiro pode seguir o cronograma do mecanismo, mas o layout fiscal possui prazo próprio.
A equipe que confundir esses dois calendários corre um risco real. Ou seja, pode descobrir tarde demais que precisa alterar a arquitetura do emissor.
O que muda na NF-e com o Split Payment segundo a NT 2026.006
Primeiro, é preciso olhar para as duas estruturas criadas pela NT 2026.006. A primeira é o grupo YC, identificado no XML como gPgtoVinc. Ele reúne informações da vinculação da transação de pagamento ao documento fiscal.
Por exemplo, o grupo registra os seguintes dados:
idTransacao— o identificador da transação;tpMeioPgto— o meio de pagamento;CNPJReceb— o CNPJ de quem recebe;CNPJBasePSP— o CNPJ base do prestador de serviço de pagamento.
Em seguida, vem o evento 110300, usado para vincular uma transação financeira a um documento fiscal já autorizado. Por outro lado, o cancelamento de uma vinculação incorreta ocorre pelo evento genérico 110001, previsto na NT 2025.002.
Portanto, o que muda na NF-e com o Split Payment envolve novos dados no XML. Também envolve uma nova rotina de eventos para corrigir ou cancelar vínculos.
Contudo, durante 2026, o preenchimento dessas estruturas ainda é facultativo. A antecipação serve para que os sistemas sejam desenvolvidos e testados antes da exigência efetiva. Nesse período, o time valida o que muda na NF-e com o Split Payment sem esperar uma exigência obrigatória.
Como a nota será ligada ao pagamento
Há duas formas de realizar essa vinculação. A diferença, portanto, está na ordem em que o documento fiscal e a transação financeira são criados.
A NF-e é emitida antes do pagamento
Quando o documento fiscal nasce primeiro, a chave da NF-e pode ser enviada ao prestador de pagamento. O envio ocorre no momento em que a transação começa. Por exemplo, o QR Code Pix já carrega a referência ao documento.
Nesse modelo, a instituição de pagamento recebe a chave desde o início. Logo, ela consegue concluir a vinculação automaticamente. Para o emissor, porém, isso exige integração com o provedor de pagamento no momento da cobrança.
Esse cenário explica o que muda na NF-e com o Split Payment. Muitos ERPs, porém, mantêm emissão fiscal e cobrança em fluxos separados. Portanto, a chave da nota precisa participar da transação financeira.
O pagamento acontece antes da NF-e
O segundo fluxo ocorre quando boleto, Pix ou TED são criados antes da emissão do documento. Contudo, como ainda não existe uma chave de NF-e, a vinculação não pode ser concluída naquele momento.
Em seguida, depois da autorização, o sistema informa os dados da transação pelo grupo YC ou pelo evento 110300. Portanto, o vínculo pode permanecer pendente até essa etapa.
Esse ponto é central para entender o que muda na NF-e com o Split Payment. Ou seja, vincular uma transação não significa confirmar que ela foi liquidada. Por exemplo, um boleto pode não ser pago e um Pix pode não ser concluído. Portanto, o sistema precisa tratar vinculação e liquidação como estados diferentes.
Três situações que o ERP precisa testar
Quando o time transforma o fluxo em casos de teste, tudo fica mais claro. Assim, o que muda na NF-e com o Split Payment aparece com mais nitidez.
NF-e antes do pagamento
Primeiro, o fornecedor emite a nota e o cliente paga depois, informando a chave do documento na transação. Porém, se houver erro de digitação ou formatação, o vínculo pode ficar pendente até a correção pelo evento 110300.
Boleto ou Pix antes da NF-e
Nesse caso, o fornecedor também cria a cobrança antes do documento fiscal. Em seguida, depois da emissão, o grupo YC registra os dados da transação e fecha o vínculo. No Pix dinâmico, porém, a cobrança nasce sem a chave da NF-e. Logo, o evento 110300 pode ser necessário para completar a associação.
Vinculação posterior ou incorreta
Também pode ocorrer de a transação já existir e a associação não ser resolvida. Isso acontece por erro de chave, atraso ou inconsistência de dados. Nesses casos, portanto, o sistema precisa identificar pendências, corrigir vínculos pelo 110300 e cancelar registros incorretos pelo 110001. Por isso, o que muda na NF-e com o Split Payment exige monitoramento do ciclo completo. Não basta apenas gerar o XML.
O grupo YC não substitui YA, YB ou ECONF
Além disso, o que muda na NF-e com o Split Payment não elimina informações que já existem. Ou seja, o grupo YC não substitui o que o documento fiscal já declara.
Os grupos YA e YB continuam descrevendo as informações de pagamento exigidas no documento fiscal. Por outro lado, o grupo YC tem outra função: conectar a NF-e ou NFC-e a uma transação financeira identificável.
O mesmo vale, também, para o evento ECONF, criado pela NT 2024.002. Ele continua voltado à conciliação financeira. Em contrapartida, o YC e o evento 110300 tratam da vinculação entre o documento e a transação esperada ou efetivada.
Assim, o que muda na NF-e com o Split Payment é uma camada adicional de dados e eventos. Portanto, substituir mentalmente YC por YA, YB ou ECONF cria lacunas no desenvolvimento.
O maior risco está em deixar os testes para o fim do ano
O calendário fiscal de 2026 já reúne mudanças de IBS e CBS. Também entram na conta a tabela de CFOP e os meios de pagamento. Portanto, a NT 2026.006 acrescenta mais uma frente de desenvolvimento. A produção, porém, está prevista para 5 de outubro. Por isso, o que muda na NF-e com o Split Payment precisa entrar no planejamento técnico antes dessa data. A equipe que não testar previamente perde a oportunidade de validar o comportamento em homologação.
Inclusive, o adiamento do Split Payment obrigatório para 2028 não altera o cronograma da NT 2026.006. Portanto, essa diferença deve orientar o planejamento do produto.
O que testar em homologação
Para validar o que muda na NF-e com o Split Payment, o ambiente de testes também precisa reproduzir quatro situações:
- Transação criada depois da NF-e, com a chave transmitida corretamente ao prestador de pagamento.
- Transação criada antes da NF-e, deixando o vínculo pendente até o grupo YC ou o evento 110300.
- Transação com erro na chave ou nos dados, exigindo correção.
- Cancelamento de uma vinculação registrada incorretamente pelo evento 110001.
Em resumo, esses cenários ajudam a validar o que muda na NF-e com o Split Payment. Também permitem verificar emissão, persistência dos dados, tratamento de pendências e correção de eventos. Como a informação ainda é facultativa em 2026, a equipe pode testar com calma. Assim, ninguém submete o cliente ao impacto de uma exigência obrigatória.
O que o desenvolvimento deve fazer agora
Primeiro, a adaptação ao que muda na NF-e com o Split Payment começa com a leitura da NT 2026.006. Ou seja, desenvolvimento e fiscal precisam ler a nota em conjunto. O time técnico entende os campos e eventos. A área fiscal, por outro lado, avalia como eles se encaixam no processo tributário.
Depois, vale mapear onde o ERP cria boletos, Pix ou outras cobranças antes da emissão da NF-e. Esses pontos tendem a concentrar os vínculos pendentes.
Por fim, o emissor deve implementar o suporte ao grupo YC e ao evento 110300 em homologação. Também precisa criar a rotina de correção e cancelamento pelo 110001. Além disso, deve confirmar que YA, YB e ECONF continuam funcionando normalmente. Assim, esse trabalho reduz um risco: descobrir em produção que o fluxo de cobrança não conversa com o fluxo fiscal.
Uma camada fiscal que pode sair do roadmap interno
Nem toda empresa precisa desenvolver esse suporte do zero. Por exemplo, plataformas de emissão fiscal via API podem absorver parte dessa complexidade. Também acompanham as alterações de layout, eventos e regras.
A Webmania, por exemplo, emite NF-e, NFC-e e outros documentos fiscais por API REST. Também informa que acompanha as mudanças de leiaute dos órgãos responsáveis. Portanto, o grupo YC e o evento 110300 já entraram no roadmap da plataforma. A operação processa mais de 15 milhões de documentos fiscais por mês. Também mantém mais de 10 mil regras fiscais atualizadas diariamente.
Para o time de desenvolvimento, portanto, isso pode reduzir o esforço dedicado à manutenção da camada fiscal. Assim, sobra capacidade para o produto. Ainda assim, a empresa precisa entender o fluxo. É ela que valida se a solução atende aos seus processos de cobrança e pagamento.
As dúvidas que aparecem antes do prazo acabar
O que é o Split Payment na NF-e?
Em resumo, o Split Payment separa a parcela de IBS e CBS no momento do pagamento. Portanto, o tributo segue direto para o Fisco. Assim, na NF-e a mudança aparece como uma vinculação entre o documento e a transação financeira.
O que é o grupo YC no XML da NF-e?
O grupo YC, identificado como gPgtoVinc, registra o identificador da transação, o meio de pagamento e os CNPJs envolvidos. Contudo, ele não substitui os grupos YA e YB, que continuam válidos.
Quando o evento 110300 é necessário?
O evento 110300 entra quando a transação financeira nasce antes da NF-e. Por exemplo, num Pix dinâmico emitido sem a chave do documento. Portanto, ele também serve para corrigir vínculos pendentes depois da autorização.
Qual a diferença entre o evento 110300 e o ECONF?
De acordo com a NT 2024.002, o ECONF trata da conciliação financeira do documento. Em contrapartida, o evento 110300 trata da vinculação entre nota e transação. Ou seja, os dois convivem.
O preenchimento já é obrigatório em 2026?
Não. De acordo com a NT 2026.006, o preenchimento segue facultativo durante 2026. Porém, a produção facultativa começa em 5 de outubro.
2027 não deve ser o ponto de partida
A Reforma Tributária concentra em 2027 diversos eventos, mas cada um possui cronograma próprio. O Split Payment pode começar sua adoção facultativa naquele período. Por outro lado, a infraestrutura técnica para vincular nota e pagamento já tem datas definidas.
Por isso, o que muda na NF-e com o Split Payment deve entrar no planejamento antes da obrigatoriedade do mecanismo. Inclusive, a homologação já está aberta e a produção está prevista para outubro de 2026.
Em suma, o ponto mais relevante é operacional. Portanto, o emissor precisa saber relacionar documento fiscal e transação financeira. Também precisa tratar vínculos pendentes e corrigir associações quando necessário. Quanto antes esse fluxo for testado, menor será a pressão quando a regra passar a ser efetivamente exigida.
Por fim, vale abrir a documentação da API e reproduzir os quatro cenários em homologação antes de outubro.
