API de geração do DANFSe será suspensa em 3 de agosto de 2026

TL;DR

A API oficial utilizada para gerar o Documento Auxiliar da Nota Fiscal de Serviço Eletrônica (DANFSe) será suspensa em 3 de agosto de 2026.

A mudança está prevista na Nota Técnica SE/CGNFS-e nº 008, versão 1.02, publicada em 14 de julho de 2026. O documento passa a ser a referência técnica para a geração do DANFSe por softwares emissores de NFS-e, ERPs e sistemas fiscais, seja por solução própria, biblioteca ou serviço de terceiro compatível com o leiaute oficial.

A Nota Técnica nº 008 não anuncia o encerramento ou a suspensão do Portal Nacional da NFS-e nem do Emissor Nacional Web. O impacto principal recai sobre sistemas que dependem da API específica de geração do documento auxiliar.

A ação recomendada é identificar imediatamente se o ERP consome essa API e, somente quando houver essa dependência, implementar ou contratar uma solução de geração compatível com o leiaute oficial e concluir os testes antes da data de suspensão.

O que aconteceu

A Secretaria-Executiva do Comitê Gestor da Nota Fiscal de Serviço Eletrônica de Padrão Nacional publicou a versão 1.02 da Nota Técnica nº 008, que contém as especificações técnicas do DANFSe.

A Nota Técnica informa que a API de geração do DANFSe será sobrestada, ou seja, suspensa, em 3 de agosto de 2026. O documento estabelece as especificações que deverão ser observadas pelos softwares emissores, ERPs e sistemas fiscais na geração da representação visual da NFS-e.

A versão 1.02 também registra ajustes na quantidade de caracteres dos campos, no tratamento dos campos vPis, vCofins e tpRetPisCofins, além de outras correções pontuais.

O serviço atingido é a API específica que gera o DANFSe. Ele não deve ser confundido com os serviços utilizados para transmitir a Declaração de Prestação de Serviços, autorizar a NFS-e, consultar documentos ou executar outros processos da plataforma nacional.

O que é o DANFSe

A Nota Técnica nº 008 caracteriza formalmente o DANFSe como o documento auxiliar da NFS-e impresso em papel. Sua finalidade é facilitar a consulta resumida aos dados da nota e apoiar processos administrativos e financeiros do destinatário.

Na operação dos sistemas, o DANFSe costuma ser produzido em arquivo para visualização e impressão, como PDF, mas a Nota Técnica não estabelece o PDF como formato eletrônico obrigatório. Qualquer formato adotado deve preservar o modelo e os requisitos de impressão definidos na especificação oficial.

Ele pode ser utilizado para:

• facilitar a consulta dos dados da NFS-e;
• atender à necessidade de representação impressa;
• apoiar processos administrativos e financeiros do destinatário;
• permitir a consulta de autenticidade por chave de acesso ou QR Code;
• disponibilizar o documento para visualização, impressão ou envio ao cliente.

O DANFSe não substitui o XML da NFS-e. O arquivo eletrônico continua sendo a origem dos dados fiscais, enquanto o documento auxiliar funciona como representação para leitura, impressão e conferência.

Quem é impactado

A alteração afeta diretamente:

• empresas desenvolvedoras de software fiscal;
• fornecedores de ERP;
• plataformas emissoras de NFS-e;
• sistemas de faturamento integrados à NFS-e Nacional;
• integradores que utilizam a API oficial para obter o DANFSe;
• equipes de desenvolvimento, implantação e sustentação;
• empresas que enviam automaticamente o DANFSe aos clientes;
• portais que armazenam ou disponibilizam o DANFSe em PDF ou em outro formato de representação adotado pela aplicação.

O contribuinte que utiliza somente o Emissor Nacional Web não é, por esse motivo isolado, obrigado a desenvolver um gerador próprio. A adequação técnica é necessária para aplicações que dependem da API de geração do DANFSe.

O que não muda

A suspensão da API não significa:

• encerramento da NFS-e Nacional;
• anúncio de encerramento ou suspensão do Emissor Nacional Web;
• fim da emissão manual pelo Portal Nacional;
• suspensão automática das APIs de emissão da NFS-e;
• alteração da validade do XML autorizado;
• obrigação de desenvolvimento próprio para o usuário que emite apenas pelo portal.

A Nota Técnica nº 008 tem como objeto a especificação e a geração do documento auxiliar. A emissão da NFS-e e os demais serviços de integração possuem fluxos e documentações próprios.

Impactos práticos

O sistema precisa adotar uma solução alternativa de geração

Quando o ERP atualmente depende da API oficial para obter o DANFSe, esse fluxo precisará ser substituído por solução própria, biblioteca ou serviço de terceiro compatível com a Nota Técnica e independente da API suspensa.

A contratação de biblioteca ou serviço de terceiro não elimina a responsabilidade do ERP ou emissor de validar a correspondência com o XML e a conformidade do documento com o modelo oficial.

Na prática, a solução adotada deverá:

1. receber ou localizar o XML da NFS-e;
2. mapear as tags para os campos do DANFSe;
3. aplicar o leiaute definido na Nota Técnica;
4. gerar a representação para visualização, impressão ou download;
5. quando o sistema mantiver arquivo eletrônico, vinculá-lo à respectiva NFS-e como parte da arquitetura operacional.

Os campos precisam refletir o XML

A Nota Técnica determina que os campos do DANFSe representem o conteúdo das respectivas tags do XML da NFS-e. Não podem ser impressas informações que não constem do arquivo eletrônico.

Esse ponto exige cuidado porque o gerador visual não deve completar dados por conta própria, recalcular tributos de forma independente ou utilizar informações divergentes do XML autorizado.

Quando um campo não comportar todo o conteúdo, a versão 1.02 admite tratamento com reticências, observadas as regras de legibilidade e de quantidade de caracteres. Já os campos sem informação no XML devem ser preenchidos com um traço (-), ressalvadas as supressões de linhas e blocos expressamente autorizadas pela Nota Técnica.

O leiaute não é um relatório livre

O DANFSe deve obedecer ao modelo oficial. Entre os requisitos técnicos estão:

• geração em uma única página;
• orientação retrato;
• tamanho mínimo A4;
• margens dentro dos limites definidos;
• disposição padronizada dos blocos;
• regras de espessura de linhas e sombreamento;
• fontes e tamanhos mínimos;
• QR Code para consulta da autenticidade;
• identificação da chave de acesso;
• tratamento dos blocos opcionais e das supressões permitidas.

O sistema pode realizar somente as adaptações expressamente admitidas na Nota Técnica, como a supressão de determinados blocos quando os dados não existirem ou não se aplicarem à operação.

O ambiente de homologação precisa ser identificado

Quando a NFS-e for gerada para teste em ambiente de produção restrita, com tpAmb = 2, o DANFSe deverá apresentar no cabeçalho a expressão:

NFS-e SEM VALIDADE JURÍDICA

Essa validação deve fazer parte do gerador para impedir que documentos de homologação sejam confundidos com documentos de produção.

Cancelamento e substituição exigem tratamento visual

O DANFSe de uma NFS-e cancelada deve apresentar a marca d’água CANCELADA.

No caso de substituição, o documento deve apresentar a marca d’água SUBSTITUÍDA. A chave da NFS-e substituída também deve ser tratada conforme a especificação aplicável ao campo de informações complementares.

O documento contempla informações de IBS e CBS

O leiaute prevê blocos e totalizadores relacionados ao IBS e à CBS, incluindo informações como CST, classificação tributária, base de cálculo, reduções, alíquotas e valores apurados.

A apresentação desses dados deve respeitar o conteúdo existente no XML. O gerador do DANFSe não deve criar informações tributárias ausentes nem utilizar cálculo paralelo como substituto dos valores do documento eletrônico.

A própria Nota Técnica registra uma ressalva: as operações classificadas como novos fatos geradores de IBS e CBS que antes não eram formalizadas por documento fiscal terão especificação própria de DANFSe em futura nota técnica.

Há previsão oficial de obrigatoriedade dos grupos IBS/CBS e de suas validações a partir de 3 de agosto de 2026, conforme cronograma próprio, sujeito ao acompanhamento da documentação oficial da RTC. Esse evento não deve ser confundido com a suspensão da API de geração do DANFSe, que decorre da Nota Técnica nº 008.

Impacto para ERP

Emissão e pós-autorização

O primeiro ponto a revisar é o processo executado depois da autorização da NFS-e.

O ERP deve identificar se:

• chama a API oficial para obter o DANFSe;
• armazena apenas o arquivo de representação retornado pela integração;
• mantém o XML necessário para regenerar o documento;
• permite reimpressão ou novo download;
• atualiza o documento após cancelamento ou substituição.

Quando a dependência da API for confirmada, seu uso precisa ser substituído antes da suspensão.

Motor de geração de documentos

O sistema poderá precisar de um novo template, componente de renderização, biblioteca ou serviço contratado capaz de gerar o DANFSe conforme o padrão nacional.

Esse componente deve controlar:

• tamanho da página;
• orientação;
• margens;
• posição e dimensão dos blocos;
• tamanho mínimo das fontes;
• quebra e truncamento de textos;
• QR Code;
• marcas d’água;
• campos opcionais;
• supressões permitidas;
• geração em uma única página.

Modelo de dados e XML

A geração deve partir do XML da NFS-e ou de um modelo interno comprovadamente sincronizado com ele.

A equipe técnica deve revisar o mapeamento de:

• chave de acesso;
• número, competência e data da NFS-e;
• DPS e respectiva série;
• prestador ou fornecedor;
• tomador ou adquirente;
• destinatário;
• intermediário;
• descrição do serviço;
• tributação municipal;
• tributos federais;
• IBS e CBS;
• valores totais;
• informações complementares;
• ambiente;
• situação e finalidade do documento.

Integrações e armazenamento

Como impacto operacional, a mudança pode afetar integrações que hoje esperam receber da API um arquivo pronto para visualização, impressão ou envio.

Devem ser revisados:

• envio do DANFSe por e-mail;
• portal do cliente;
• armazenamento de documentos;
• faturamento e contas a receber;
• integração com GED;
• download por aplicativos;
• reprocessamento;
• histórico de versões;
• vínculo entre XML, arquivo de representação e chave de acesso.

Como boa prática de ERP, o novo fluxo deve preservar rastreabilidade e permitir demonstrar qual versão do gerador produziu cada documento. Essa recomendação é operacional e não constitui obrigação expressa da Nota Técnica.

Validações preventivas

Antes de disponibilizar o DANFSe, o ERP deve validar pelo menos:

• correspondência entre o documento e o XML;
• chave de acesso;
• ambiente de emissão;
• dados dos participantes;
• valores e totalizadores;
• QR Code;
• textos obrigatórios;
• situação da NFS-e;
• geração em uma única página;
• legibilidade do conteúdo;
• ausência de dados não existentes no XML;
• preenchimento com traço (-) dos campos sem informação no XML, respeitadas as supressões autorizadas;
• informação obrigatória dos totais aproximados dos tributos no campo de Informações Complementares, com discriminação separada das parcelas federais, estaduais e municipais, em valores monetários ou percentuais, conforme a Lei nº 12.741/2012.

Monitoramento e suporte

A adoção de uma solução de geração cria uma nova responsabilidade operacional para o fornecedor do sistema ou para o responsável pela integração.

Como boa prática de ERP, é recomendável manter logs com:

• chave de acesso;
• data e hora da geração;
• versão do leiaute;
• versão do template;
• resultado da renderização;
• erros de mapeamento;
• falhas na geração do QR Code;
• tentativa de regeneração;
• usuário ou processo responsável.

Esses registros reduzem o tempo de diagnóstico quando o cliente não consegue visualizar, baixar ou imprimir o DANFSe. Trata-se de recomendação da Análise Tribium, não de exigência expressa da Nota Técnica.

Riscos operacionais

Uma implantação incompleta pode provocar:

• indisponibilidade do DANFSe após 3 de agosto;
• divergência entre a representação visual e o XML;
• campos tributários ausentes;
• valores impressos incorretamente;
• QR Code inválido;
• documento de homologação sem identificação;
• quebra em mais de uma página;
• dados truncados sem tratamento adequado;
• ausência de marca d’água em nota cancelada ou substituída;
• falhas no envio automático aos clientes;
• aumento de chamados para suporte;
• retrabalho em faturamento e contas a receber.

O risco principal não está apenas na renderização do documento. Ele está na continuidade de toda a cadeia operacional que consome o DANFSe.

O que fazer agora

1. Mapear a dependência: identifique se o ERP ou emissor consome a API oficial de geração do DANFSe.
2. Separar os serviços: confirme que a equipe não está confundindo a API de geração do documento auxiliar com as APIs de emissão, consulta ou recepção da NFS-e.
3. Ler a versão 1.02: revise integralmente a Nota Técnica nº 008 e o modelo de DANFSe constante no anexo.
4. Implementar ou contratar a solução: adote componente próprio, biblioteca ou serviço de terceiro compatível com a Nota Técnica, sem dependência da API oficial suspensa.
5. Mapear o XML: garanta que cada campo impresso tenha origem rastreável no documento eletrônico.
6. Versionar o template: registre a versão da Nota Técnica e do gerador aplicada a cada documento.
7. Executar testes funcionais: valide notas com diferentes participantes, tributos, retenções, textos longos, IBS/CBS, cancelamento, substituição e informações complementares.
8. Testar os ambientes: confira a identificação de homologação e produção.
9. Validar as integrações: teste e-mail, portal do cliente, armazenamento, reimpressão, download e reprocessamento.
10. Preparar contingência operacional: defina como os usuários obterão o documento caso a implantação apresente falhas após a suspensão da API.

Checklist técnico para ERP

• Dependência da API de geração do DANFSe identificada
• Fluxo de emissão separado do fluxo de geração do documento auxiliar
• Nota Técnica nº 008 versão 1.02 revisada
• XML utilizado como fonte dos dados
• Leiaute oficial implementado
• QR Code validado
• Geração em página única validada
• Ambiente de homologação identificado corretamente
• Cancelamento e substituição tratados
• Campos de IBS e CBS testados
• Totais aproximados dos tributos incluídos em Informações Complementares, com parcelas federais, estaduais e municipais discriminadas em valor ou percentual
• Campos sem informação no XML preenchidos com traço (`-`), ressalvadas as supressões autorizadas
• Integrações com e-mail e portal testadas
• Reimpressão e regeneração testadas
• Logs de geração implementados
• Plano de implantação concluído antes de 3 de agosto de 2026

Linha do tempo

Base técnica

A referência principal é a Nota Técnica SE/CGNFS-e nº 008, versão 1.02, de 14 de julho de 2026, que dispõe sobre as especificações técnicas do DANFSe.

O histórico da versão informa alterações relacionadas a:

• nova data de suspensão da API;
• quantidade de caracteres dos campos;
• tratamento de vPis, vCofins e tpRetPisCofins;
• correções pontuais.

Fontes oficiais

• Nota Técnica SE/CGNFS-e nº 008 — versão 1.02
• Comunicado oficial: DANFSE — novos ajustes e prorrogação do prazo para adequação
• Documentação técnica da RTC — grupos IBS/CBS
• Lei nº 12.741, de 8 de dezembro de 2012
• Documentação técnica da NFS-e Nacional
• Portal da Nota Fiscal de Serviço Eletrônica

Fonte complementar

• API de geração do DANFSe será descontinuada; emissão no Portal Nacional permanece

Análise Tribium

A suspensão da API muda a responsabilidade técnica, mas não elimina a necessidade operacional do DANFSe.

Até aqui, sistemas que consumiam a API podiam tratar a representação visual como um recurso externo. A partir da mudança, o ERP ou emissor deverá assumir a responsabilidade por adotar e integrar uma solução compatível, que pode ser própria ou contratada.

Na Análise Tribium, isso transforma o DANFSe em um componente que precisa de governança de versão, testes de regressão e monitoramento. Não basta reproduzir visualmente os campos. O sistema precisa manter correspondência com o XML, respeitar o padrão nacional e garantir continuidade das integrações que dependem da representação visual.

O prazo também exige atenção porque a versão 1.02 foi publicada poucas semanas antes da suspensão. Fornecedores que haviam implementado versões anteriores devem executar uma comparação técnica e evitar presumir que a adequação já está concluída.

O ponto mais sensível é a divergência entre o XML e o documento auxiliar. Uma representação visual aparentemente correta, mas com dados diferentes do arquivo autorizado, cria risco para atendimento, cobrança, conferência, auditoria e relacionamento com o cliente.

Para áreas fiscais e de tecnologia, a prioridade deve ser tratar a mudança como uma implantação integrada, envolvendo desenvolvimento, produto, suporte, faturamento e usuários-chave.

Perguntas frequentes

A emissão da NFS-e pelo Portal Nacional será encerrada?

A Nota Técnica nº 008 não anuncia o encerramento ou a suspensão do Emissor Nacional Web. Sua disponibilidade futura deve ser acompanhada pelos comunicados oficiais do Portal Nacional.

Todas as empresas precisam desenvolver um gerador de DANFSe?

Não. A necessidade de adequação recai sobre ERPs, emissores e aplicações que dependem da API suspensa. Quem utiliza somente o portal não precisa desenvolver um gerador próprio por causa da Nota Técnica nº 008, sem prejuízo de acompanhar eventuais comunicados futuros do Portal Nacional.

A API de emissão da NFS-e também será suspensa?

A Nota Técnica nº 008 não anuncia a suspensão geral das APIs de emissão. Ela trata especificamente da API de geração do DANFSe.

O ERP pode montar o DANFSe com dados de seus cadastros?

O documento deve representar as informações das respectivas tags do XML da NFS-e. O uso de dados internos só é seguro quando houver correspondência comprovada com o arquivo eletrônico autorizado.

O DANFSe pode ter um leiaute próprio da empresa?

O sistema deve seguir o modelo e os padrões definidos na Nota Técnica. Somente as supressões e modificações expressamente permitidas podem ser aplicadas.

O documento precisa ser gerado em PDF?

A Nota Técnica disciplina a representação e a impressão do DANFSe, não um formato exclusivo de arquivo para todas as rotinas. Na prática, o PDF tende a ser utilizado para visualização, armazenamento e envio, desde que preserve o leiaute oficial.

Como tratar uma NFS-e de homologação?

O DANFSe deve conter a expressão “NFS-e SEM VALIDADE JURÍDICA” no cabeçalho quando o XML indicar ambiente de produção restrita com tpAmb = 2.

O que acontece se o ERP não estiver pronto em 3 de agosto?

A emissão da NFS-e pode continuar conforme o canal utilizado, mas o sistema poderá deixar de obter o DANFSe pela API suspensa. Isso pode interromper visualização, download, impressão, envio ao cliente e outros processos que dependam do documento auxiliar.

Conclusão

A suspensão da API de geração do DANFSe em 3 de agosto de 2026 exige ação imediata dos fornecedores de ERP, emissores de NFS-e e equipes de integração que confirmarem dependência desse serviço.

A Nota Técnica nº 008 não anuncia o encerramento do Portal Nacional nem da emissão da NFS-e. Para os sistemas que dependem da API suspensa, a mudança exige a adoção de solução própria ou contratada que gere o documento auxiliar conforme a versão 1.02.

O trabalho deve abranger mais do que o leiaute visual. É necessário revisar o mapeamento do XML, o QR Code, as situações de homologação, cancelamento e substituição, os campos de IBS e CBS, os totais aproximados dos tributos com discriminação federal, estadual e municipal, o tratamento de campos vazios e todas as integrações que consomem o documento.

A recomendação do Tribium é concluir a implementação ou contratação da solução e os respectivos testes antes do prazo, com validação conjunta entre fiscal, desenvolvimento, produto e suporte.