A adequação dos documentos fiscais eletrônicos à Reforma Tributária do Consumo alcança tanto a rotina contábil quanto a arquitetura dos emissores. Para quem mantém um ERP em Delphi, uma biblioteca de geração de XML ou uma integração com autorizadores, uma alteração aparentemente localizada em devoluções pode atravessar cadastro, regra de negócio, serialização, validação prévia, transmissão e tratamento de rejeições.
Há um ponto institucional já confirmado: o Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 10, de 28 de outubro de 2026, aprovou a Nota Técnica 2025.002-RTC, versão 1.53, para a NF-e modelo 55 e a NFC-e modelo 65. O ato foi publicado em 29 de outubro de 2026 e produz efeitos na própria data de publicação.
O tema, porém, pede precisão. A aprovação do documento técnico não autoriza concluir, por si só, que todo novo comportamento esteja simultaneamente implantado, exigido em cada ambiente ou idêntico em todas as Unidades da Federação. O conteúdo detalhado da versão 1.53 foi consultado em um espelho secundário porque o arquivo original da nota, no Portal Nacional da NF-e, não pôde ser aberto durante a pesquisa. Assim, este artigo separa o que está confirmado do que deve ser conferido diretamente no PDF oficial, nos schemas vigentes e no autorizador aplicável.
O percurso será prático: primeiro, situaremos o alcance da nota; depois, examinaremos as mudanças atribuídas às devoluções; em seguida, discutiremos os efeitos no modelo do ERP e, por fim, apresentaremos um roteiro de testes e decisão para desenvolvimento e contabilidade.
O que está confirmado sobre a versão 1.53
A confirmação normativa é objetiva. O Ato Técnico Conjunto nº 10 aprovou a NT 2025.002-RTC v1.53 para os documentos NF-e, modelo 55, e NFC-e, modelo 65. Isso vincula a versão ao ecossistema desses dois documentos fiscais eletrônicos e mostra que a alteração está inserida na agenda técnica da RTC, não em uma especificação isolada de um fornecedor de software.
O índice do Portal Nacional da NF-e identifica a nota como uma adequação de leiautes e regras de validação para inclusão de campos e regras relacionados à Reforma Tributária do Consumo. A base legal mais ampla também prevê a adaptação dos sistemas autorizadores e a observância de leiaute padronizado para os documentos fiscais eletrônicos ligados a IBS e CBS, conforme a Lei Complementar nº 214, de 16 de janeiro de 2025.
Para a equipe de produto, essa combinação de fontes sustenta uma decisão importante: a versão deve entrar no radar de manutenção fiscal, com responsável técnico, responsável tributário e trilha de homologação. Ela não deve ser tratada apenas como atualização cosmética de tags.
Também é essencial distinguir três planos. O primeiro é a aprovação do documento técnico, confirmada pelo ato. O segundo é a implantação nos ambientes, que depende do cronograma e da operacionalização dos autorizadores. O terceiro é a exigibilidade de uma validação em determinada emissão. Esses planos se relacionam, mas não são sinônimos. Uma regra pode constar na documentação e ainda requerer verificação de disponibilidade no ambiente efetivamente usado pela empresa.
O foco operacional: devolução e referência ao documento original
A leitura do PDF hospedado em espelho secundário indica que a versão 1.53 concentra alterações relevantes na forma de referenciar o documento devolvido. Segundo esse material, a chave de acesso poderá ser indicada no cabeçalho, por meio de refNFe, ou no item, em DFeReferenciado/chaveAcesso. A mesma leitura informa que os dois níveis não devem ser empregados simultaneamente na mesma devolução.
Essa descrição precisa ser tratada como informação técnica a confirmar no documento oficial, e não como transcrição definitiva de leiaute. Ainda assim, ela revela uma mudança de modelagem que vale antecipar: o ERP precisa saber em qual nível está a referência e impedir combinações incompatíveis antes de montar o XML.
Em uma devolução referenciada no cabeçalho, o documento original é associado à operação como um todo. Em uma devolução com referências nos itens, a associação se aproxima da granularidade da mercadoria devolvida. Não se trata apenas de escolher onde escrever uma chave de acesso: a escolha altera a origem da informação, a tela de lançamento, a consistência entre itens e cabeçalho e as rotinas de importação ou conferência.
O mesmo espelho aponta que nItem passa a ser opcional no cenário abordado. Caso essa alteração seja confirmada no PDF oficial e nos XSDs aplicáveis, o sistema não pode mais assumir que a ausência do número do item torna automaticamente o documento inválido. Ao mesmo tempo, opcionalidade de um elemento não elimina a necessidade de validação de negócio. A aplicação deverá continuar distinguindo situações em que a referência por item exige identificação específica daquelas em que a regra permite a omissão.
Referência no cabeçalho ou no item: escolha de negócio, não detalhe de XML
Em sistemas maduros, a camada de XML não deveria decidir sozinha se a referência será no cabeçalho ou no item. Essa decisão precisa nascer de uma estrutura de domínio clara. Uma devolução deve carregar, no mínimo, a modalidade de referência, a chave do documento originário e, quando pertinente, a relação entre itens da devolução e itens do documento referenciado.
Um erro comum é armazenar somente uma chave de NF-e no cabeçalho e tentar derivar as referências por item na hora da transmissão. Esse desenho se torna frágil quando a operação envolve devolução parcial, seleção de mercadorias específicas, agrupamento de documentos ou necessidade de auditoria contábil. A tela pode até parecer simples, mas o banco de dados precisa preservar a decisão tomada pelo usuário e sua justificativa operacional.
Para a contabilidade, a principal consequência é de governança: o processo de devolução deve informar com clareza qual documento foi devolvido e como os itens devolvidos se conectam à operação anterior. Para desenvolvimento, a consequência é a necessidade de preservar essa rastreabilidade em regras, logs e interfaces de integração.
Limite de ocorrências no cabeçalho e rejeição
O material técnico secundário consultado informa que, em devolução com referência no cabeçalho, haveria limite de uma ocorrência de NFref. Também descreve uma regra identificada como B25-40, com rejeição 255 em produção para situações que incluem NF-e complementar, de devolução ou determinadas NF-e de crédito quando houver mais de uma NFref no cabeçalho.
Como o texto original da NT não foi diretamente conferido na pesquisa, não é prudente reproduzir condições completas, precedências ou mensagens literais de rejeição como se estivessem validadas na fonte primária. A conclusão segura é outra: a montagem de referências de cabeçalho merece teste específico, sobretudo em rotinas que reaproveitam estruturas genéricas de NF-e referenciada e permitem múltiplas ocorrências por padrão.
Em outras palavras, não basta validar se a chave tem 44 posições e dígitos verificadores consistentes. É necessário validar cardinalidade, nível de inserção e coexistência entre referências de cabeçalho e de item, de acordo com a versão oficial de schema e regras aplicável ao ambiente.
Impactos no ERP, na integração e no código Delphi
A mudança atribuída à v1.53 é um bom exemplo de por que manutenção fiscal não deve ficar confinada a uma unit responsável por gerar XML. A decisão de referência atravessa pelo menos cinco camadas: persistência, regra de negócio, interface, serialização e retorno do autorizador.
Na persistência, prefira estruturas explícitas em vez de campos genéricos de texto. Um registro de referência deve informar a chave, o nível de aplicação — cabeçalho ou item —, o item interno de origem e, se aplicável, o identificador do item do documento referenciado. Essa separação facilita auditoria, evita duplicidade e permite que uma validação local seja realizada antes da assinatura digital.
No domínio Delphi, vale representar a modalidade como tipo enumerado, e não como convenção baseada em valores nulos. Por exemplo, uma enumeração interna pode distinguir referência no cabeçalho, referência por item e ausência de referência. A classe ou record responsável pela NF-e pode então expor uma validação que rejeite, ainda na aplicação, uma combinação de referências de níveis distintos quando a regra oficial assim determinar.
A vantagem não é estética. Regras embutidas em if dispersos em formulários, serviços e geradores de XML tendem a divergir com o tempo. Uma função centralizada reduz o risco de a emissão manual respeitar a regra enquanto a integração por API envia uma estrutura diferente.
Na serialização, a recomendação é não supor nomes de elementos nem ordem de grupos com base em versões anteriores. O desenvolvedor deve atualizar o pacote de schemas oficial, regenerar ou revisar os bindings quando necessário e validar o XML contra o XSD efetivamente distribuído para a versão adotada. Um XML visualmente correto pode falhar por cardinalidade, ordem ou grupo inadequado.
Na integração, os retornos do autorizador devem ser armazenados com contexto suficiente para suporte: ambiente, UF ou autorizador, data e hora registradas pelo sistema, chave do documento, versão do componente emissor, XML enviado, XML autorizado ou rejeitado e código de retorno. Essa disciplina permite separar uma falha do novo cenário de devolução de um problema de certificado, conectividade ou cadastro.
Cronograma: como interpretar sem prometer mais do que a evidência permite
O espelho técnico consultado informa implantação em homologação até 9 de novembro de 2026 e em produção até 16 de novembro de 2026 para as alterações da v1.53. A mesma informação traz uma ressalva relevante: a implantação em homologação pode variar por UF.
Essas datas são úteis para planejamento, mas devem ser apresentadas com a devida qualificação. Elas foram lidas em fonte secundária, pois o PDF original da nota não foi aberto durante a pesquisa. Além disso, a expressão “até” não informa horário de corte, janela operacional ou disponibilidade uniforme entre autorizadores. Portanto, não há base para afirmar um horário nacional de virada ou garantir que todos os ambientes estariam prontos na mesma data.
Na prática, o calendário interno do ERP deve trabalhar com uma janela de preparação anterior à data indicada e uma etapa de confirmação por ambiente. Empresas que usam mais de uma UF, contingência, integrações terceirizadas ou diferentes componentes de emissão precisam testar cada rota relevante. A existência de homologação em um autorizador não demonstra, sozinha, o mesmo comportamento em todos os demais.
Limitações e cuidados de interpretação
A principal limitação desta análise é documental. O arquivo original da NT 2025.002-RTC v1.53 no Portal Nacional da NF-e retornou loop de redirecionamento no mecanismo de pesquisa. Por isso, o histórico de alterações, o cronograma detalhado, os campos, as regras e as rejeições foram examinados em cópia disponibilizada por fonte secundária.
Essa cópia é coerente com a existência da nota, sua versão e seu contexto, que foram confirmados por fonte oficial. Ainda assim, coerência não equivale a substituição da fonte primária. Antes de publicar exemplos de XML, alterar produção ou comunicar obrigatoriedade a clientes, a equipe deve baixar e arquivar manualmente o PDF oficial v1.53 e os schemas oficiais que forem disponibilizados.
Também não foram confirmados, nesta pesquisa, os pacotes oficiais de XSD especificamente associados à versão 1.53. Sem esses arquivos, não é possível assegurar a estrutura exata de cada grupo XML, a ordem dos elementos ou a cardinalidade formal. Por esse motivo, este texto deliberadamente não apresenta XML de exemplo.
Por fim, a NT tem escopo ligado à RTC, mas as evidências disponíveis não permitem concluir que toda a tributação de IBS, CBS ou Imposto Seletivo se tornou obrigatória em produção em razão da v1.53. O foco aqui é a revisão de devoluções e das validações apontadas no material técnico consultado.
Aplicação prática
A preparação pode começar antes da conferência final do PDF, desde que as mudanças sejam controladas por configuração e não sejam liberadas como regra definitiva de produção. Um plano útil envolve as etapas a seguir.
1. Montar uma matriz de impacto
Liste todas as rotinas que emitem devolução: tela manual, importação de XML, integração de marketplace, API, processo de logística reversa, emissão em lote e contingência. Para cada uma, identifique se a referência é atualmente armazenada no cabeçalho, nos itens ou em ambos. A meta é encontrar comportamentos implícitos antes que eles cheguem ao XML.
Inclua a área contábil nessa revisão. Ela deve validar se os cenários de devolução praticados pela empresa correspondem aos dados que o sistema consegue registrar e demonstrar posteriormente. O desenho técnico deve refletir a operação, e não obrigar o usuário a adaptar o fato econômico a uma limitação de tela.
2. Separar validação de negócio e validação de schema
Implemente validações locais para impedir, conforme a confirmação da regra oficial, a coexistência de referência no cabeçalho e nos itens. Crie também uma validação de cardinalidade para referências no cabeçalho. Essas verificações devem emitir mensagens compreensíveis para o usuário e códigos internos úteis ao suporte.
Em paralelo, valide o XML contra o XSD oficial. A validação de negócio responde se a operação faz sentido para a regra fiscal; a validação de schema responde se o arquivo respeita a estrutura formal. Uma não substitui a outra.
3. Criar casos de teste representativos
Prepare casos de homologação com devolução integral, devolução parcial, devolução com referência no cabeçalho, devolução com referência por item, ausência de nItem quando o cenário oficial permitir e tentativa de preenchimento simultâneo nos dois níveis. Inclua também casos negativos: mais de uma referência de cabeçalho, chave inválida, item sem vínculo e combinação não permitida.
Não use o resultado de um único envio como prova de conformidade nacional. Registre a UF, o autorizador, o ambiente, a versão do componente e a resposta recebida. Se houver clientes em diversas UFs, mantenha uma matriz de resultados por rota de emissão.
4. Atualizar componentes e controlar versões
No ecossistema Delphi, confirme qual componente ou biblioteca monta o XML e como ela recebe atualizações de schema. Não altere manualmente uma unit de fornecedor sem estratégia de manutenção: registre o patch, mantenha testes automatizados e avalie como a mudança será reaplicada em atualizações futuras.
Versione a regra interna e os schemas usados no build. Em caso de rejeição posterior, será possível saber exatamente qual gerador produziu o XML e qual conjunto de regras estava ativo.
5. Liberar por etapas e manter contingência operacional
A liberação ideal começa em homologação, com conferência conjunta entre desenvolvimento e fiscal. Depois, avance para produção de forma monitorada, preferencialmente com alertas para rejeições relacionadas a referências e devoluções. Caso a empresa opere grande volume, uma chave de configuração por UF ou por ambiente pode reduzir o risco de ativar comportamento novo onde ainda não foi validado.
O procedimento final deve incluir a consulta ao PDF oficial, aos schemas correspondentes e aos comunicados do autorizador utilizado. Essa verificação é o ponto que transforma uma preparação prudente em implementação aderente à especificação vigente.
Conclusão
A NT 2025.002-RTC v1.53 foi oficialmente aprovada para NF-e modelo 55 e NFC-e modelo 65, o que justifica sua priorização por fornecedores de ERP, desenvolvedores Delphi e equipes contábeis. O conteúdo técnico consultado indica atenção especial às devoluções, sobretudo à referência do documento devolvido no cabeçalho ou nos itens e às validações relacionadas.
A resposta mais segura não é alterar o XML às pressas nem ignorar a versão até surgir uma rejeição em produção. É preparar o modelo de dados, centralizar regras de negócio, atualizar a estratégia de validação e testar por ambiente e UF. Ao mesmo tempo, é indispensável confirmar o texto no PDF oficial e nos XSDs vigentes antes de afirmar detalhes de tags, cardinalidades e rejeições como definitivos.
Essa combinação de cautela documental e antecipação técnica reduz retrabalho. Para a contabilidade, preserva rastreabilidade nas devoluções. Para o desenvolvimento, evita que uma mudança fiscal se transforme em comportamento disperso, difícil de testar e ainda mais difícil de sustentar.
Referências
BRASIL. Comitê Gestor do IBS; BRASIL. Receita Federal do Brasil. Ato Técnico Conjunto RFB/SUFIS/CGIBS/Diretoria-Executiva nº 10, de 28 de outubro de 2026. 2026. Disponível em: https://www.cte.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=VKMV8IDTX8A%3D. Acesso em: 3 nov. 2026.
BRASIL. Presidência da República. Lei Complementar nº 214, de 16 de janeiro de 2025. Institui o Imposto sobre Bens e Serviços, a Contribuição sobre Bens e Serviços e o Imposto Seletivo. Brasília, DF: Planalto, 2025. Disponível em: https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp214.htm. Acesso em: 3 nov. 2026.
ENCAT. Portal Nacional da NF-e. Nota Técnica 2025.002 v1.53: RTC. 2026. Disponível em: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=BMcHSMEoepU=. Acesso em: 3 nov. 2026.
LEGISWEB. Reforma Tributária do Consumo: adequações NF-e / NFC-e — Nota Técnica 2025.002-RTC, versão 1.53. 2026. Disponível em: https://www.legisweb.com.br/downloads/?id=6ae4e2bf7853f1.04455899&raw=1. Acesso em: 3 nov. 2026.
0 comentário(s)