Rejeição 903: corrija o QR Code antigo “100” da NFC-e

A rejeição 903 informa que a NFC-e foi enviada com a versão antiga “100” do QR Code em uma data de emissão para a qual esse formato deixou de ser válido. A correção passa pelo gerador do documento: atualizar a montagem da URL e seus parâmetros, conforme o leiaute aplicável. Alterar somente o desenho impresso no DANFE não corrige o conteúdo transmitido.

Antes de tentar novamente, guarde o XML rejeitado e a resposta completa da SEFAZ. Eles permitem identificar se o programa continua usando uma configuração antiga, se uma integração reaproveitou o conteúdo anterior ou se o retorno consultado pertence a outra tentativa.

O que a regra verifica

O MOC 7.0, Anexo I, página 128, apresenta a regra ZX02-15, obrigatória para a NFC-e, modelo 65. Ela combina duas condições: QR Code na versão “100” e data de emissão posterior a 30/09/2018. Essa linha não contém exceção própria por UF ou ambiente. As exceções da regra vizinha sobre ausência do QR Code não devem ser transferidas para a 903.

O número “100” nesse contexto identifica a versão do QR Code. Ele não significa o retorno cStat=100, usado na autorização, nem a versão “4.00” do leiaute XML. Um arquivo pode estar no leiaute XML 4.00 e ainda carregar uma URL antiga dentro de infNFeSupl/qrCode.

O esquema XML também não substitui essa regra de negócio. O pacote 010f conserva um padrão de QR Code com nVersao=100; a presença dessa estrutura no XSD não libera seu uso em emissões atuais. Não retroceda a data da venda para tentar satisfazer a condição histórica.

A versão de destino exige atenção

Guias publicados na transição de 2018 normalmente recomendam passar da versão “100” para a versão 2. Essa explicação ajuda a reconhecer a origem do problema, mas hoje deve ser confrontada com a documentação posterior.

A NT 2025.001 v1.03 documenta o QR Code 3. Nessa versão, o controle próprio do QR Code deixa de usar o CSC. Na emissão normal, a URL contém chave de acesso, versão e ambiente. Na contingência offline, há parâmetros adicionais e assinatura específica do QR Code. Essa assinatura não se confunde com a assinatura digital do XML.

O mesmo documento mantém a estrutura da versão 2, que utiliza identificador do CSC e hash. Portanto, apagar o CSC de uma configuração que ainda gera QR Code 2 não é uma correção completa. Também não basta substituir os caracteres “100” por “3”: a composição dos parâmetros é diferente.

Na seção 02.2, a NT trata a adoção da versão 3 como opção para emitentes identificados por CNPJ e dá tratamento específico ao produtor rural pessoa física. A seção 02.1 situa a exclusividade geral da versão 3 no futuro, sem data definida naquele documento. A escolha deve considerar o perfil do emitente, a documentação atual e o ambiente da UF; esta orientação não certifica a instalação de um contribuinte específico.

O calendário inicial da NT previa a implantação do QR Code 3 até 02/06/2025 em testes e até 01/09/2025 em produção. As datas de 20/10/2025 e 03/11/2025, registradas para ajustes da versão 1.03, não são uma nova data geral de início do QR Code 3.

Não confunda com a NF-e de modelo 55

A NT 2026.002 v1.11 trata o DANFE Simplificado Tipo 2 da NF-e, identificado por tpImp=6. Na página 20, a regra ZX02-220, modelo 55, rejeita QR Code diferente da versão 3 com a mensagem 672. É uma validação distinta da ZX02-15/903 da NFC-e.

O calendário dessas alterações do Tipo 2 prevê testes em 01/07/2026 e produção em 03/08/2026. Isso não transforma a 903 em regra geral para qualquer NF-e. Se o documento é modelo 55, confira o código e o motivo efetivamente retornados antes de aplicar este diagnóstico.

Como localizar a origem no sistema

Compare os dados da mesma tentativa:

• modelo, chave, número, série, data de emissão e ambiente;

• conteúdo de infNFeSupl/qrCode, incluindo a versão efetivamente enviada;

• tipo de emissão normal ou contingência e seus parâmetros;

• versão do emissor e do componente responsável pela montagem da URL;

• configuração utilizada pelo terminal ou integração que gerou o arquivo.

Quando outros terminais emitem corretamente, compare suas versões e configurações com as do equipamento que falhou. Uma restauração de backup, instalação antiga ou integração desatualizada pode explicar a diferença, mas isso precisa ser confirmado no XML. O fato de o QR Code abrir uma página não comprova a autorização da nota.

Corrija e confira o novo envio

1. Identifique o gerador da URL. Solicite ao suporte a revisão do emissor ou componente responsável pelo campo. Atualizar apenas o relatório de impressão deixa a causa no XML.

2. Defina o leiaute aplicável. Confira modelo, perfil do emitente, UF, ambiente e tipo de emissão. Ajuste a geração completa para a versão escolhida, com CSC/hash ou assinatura do QR Code conforme sua estrutura.

3. Regere o documento rejeitado pelo fluxo do sistema. Preserve os dados verdadeiros da operação e confira se o novo arquivo deixou de carregar nVersao=100. Não recrie a venda nem mude sua data apenas para eliminar a mensagem.

4. Valide o resultado. Transmita pelo procedimento apropriado e confira a resposta da mesma chave. Se a situação de uma tentativa anterior estiver incerta, consulte-a antes de provocar outra emissão. O encerramento depende do protocolo de autorização, não apenas do desaparecimento da 903 na tela.

Se o erro persistir, encaminhe ao suporte o XML enviado, o retorno completo, a identificação do terminal, a versão instalada e o horário da tentativa. Não envie senhas, certificado privado ou CSC em canais públicos.

Exemplo prático

Após restaurar um backup, uma papelaria passa a receber a 903 em um dos caixas. O responsável confere o arquivo e encontra nVersao=100, embora o leiaute XML esteja em 4.00. O suporte identifica o componente antigo, corrige a geração para o formato aplicável e regenera a NFC-e rejeitada com a data real da operação. A equipe confere o novo XML e o protocolo antes de concluir o atendimento. Esse procedimento corrige a origem; editar a imagem do cupom não resolveria o envio antigo.

Fontes

Base documental conferida em 15/10/2026, com capturas e reutilizações identificadas no registro de fontes:

• MOC 7.0 — Anexo I, páginas 128 e 152: ZX02-15 e mensagem 903.

• NT 2025.001 v1.03 corrigida, páginas 2–5 e 11–14: cronogramas, coexistência e composição dos QR Codes.

• Portal da NF-e — Notas Técnicas: identificação da revisão corrigida; NT 2026.002 v1.11, páginas 3 e 20, para delimitar o Tipo 2. Esquema 010f, declaração infNFeSupl, como conferência estrutural.

• Oobj — rejeição 903, TecnoSpeed — rejeição 903 e NDD — rejeição 903: corpos específicos consultados para diagnóstico. A recomendação exclusiva de QR Code 2 da Oobj foi delimitada historicamente; o exemplo TecnoSpeed ainda contendo “100” não foi reproduzido como solução. Procedimentos e versões comerciais desses fornecedores não foram atribuídos ao ALRA.