Rejeição 672: diferencie a versão do QR Code do vínculo com o PAA

Se apareceu o código 672, guarde a mensagem completa antes de alterar a nota. A documentação consultada apresenta dois problemas diferentes: uma versão de QR Code não permitida na NF-e com DANFE Simplificado Tipo 2 e a falta de vínculo ativo do emitente com um Provedor de Assinatura e Autorização, o PAA. Atualizar o QR Code não cria esse vínculo; corrigir um cadastro de provedor não resolve a versão do QR.

Para identificar o caminho correto, confira o documento enviado, o serviço que respondeu e o texto do retorno. A análise começa nessas evidências, sem trocar emitente, modelo ou fatos da venda para eliminar a rejeição.

Quando a mensagem trata do QR Code

A mensagem é “Rejeição: NF-e com DANFE Simplificado Tipo 2 com versão de qrCode não permitida”. A ocorrência corresponde à regra ZX02-220, modelo 55, na página 20 da NT 2026.002 v1.11. A linha verifica, quando o QR Code está informado, se sua versão é diferente de 3.

O DANFE Simplificado Tipo 2 continua pertencendo à NF-e modelo 55. O formato é identificado por tpImp=6; ele não transforma o documento em NFC-e modelo 65. Essa orientação não determina que todo QR Code de qualquer documento fiscal deva ser alterado para versão 3.

A versão do QR Code também não é a versão do leiaute XML. Trocar o atributo de versão do XML, o certificado ou a numeração da nota não corrige a montagem dos parâmetros do QR.

Como localizar a causa

Peça ao suporte o XML efetivamente transmitido e a configuração do gerador correspondente àquela nota. Compare o modelo, o formato de impressão, a URL e a versão inserida no QR Code. Confira também se o arquivo foi gerado antes de uma atualização do emissor ou por uma integração com configuração própria.

Ver um QR Code na impressão não prova que seu conteúdo está correto. Uma imagem pode ser perfeitamente legível e conter uma URL montada com versão inadequada. Da mesma forma, uma configuração correta na tela não prova que o arquivo rejeitado foi regenerado depois do ajuste.

Registre a UF do emitente, o autorizador, o ambiente de homologação ou produção e a versão do sistema. A aceitação em teste não equivale à autorização de uma emissão real. Se o arquivo for NFC-e ou NF-e com outro formato, não aplique automaticamente este diagnóstico: confira novamente a mensagem e sua origem.

Correção conforme o cenário

Gerador reaproveitado de outra rotina. Uma integração pode ter usado parâmetros destinados a um documento diferente. O suporte deve ajustar a rotina para o contrato de QR Code aplicável à NF-e com Tipo 2, incluindo a versão e os demais parâmetros exigidos. Substituir somente um algarismo em uma URL antiga não demonstra conformidade com o conjunto da especificação.

Atualização instalada, arquivo antigo reenviado. Confira o momento em que o XML foi criado. A nova tentativa pode estar reutilizando o conteúdo que já havia sido rejeitado. Corrija a origem e regenere pelo emissor, seguindo seu fluxo de assinatura e validação. Preserve o arquivo anterior para comparar a mudança.

Tela e arquivo apresentam dados diferentes. Investigue qual componente monta o QR: terminal, servidor, integração ou rotina de impressão. Ajustar apenas a impressora não resolve um parâmetro enviado incorretamente no XML. O suporte precisa alcançar a origem que efetivamente produziu o arquivo.

Não edite manualmente um XML assinado nem declare outro modelo ou tipo de emissão apenas para passar na validação. Se o documento escolhido não corresponde à operação, a definição do procedimento cabe ao responsável fiscal.

Exemplo original

Uma loja fictícia prepara uma NF-e modelo 55 com DANFE Tipo 2. A impressão contém um QR Code, mas o retorno informa 672 e a mensagem de versão não permitida. A integração havia conservado o gerador de uma rotina anterior, que produziu versão 2.

O suporte identifica a configuração utilizada por aquela emissão e adequa o gerador ao contrato correspondente. Depois regenera o documento rejeitado, preservando cliente, itens, valores e demais fatos da venda. A equipe compara os arquivos e examina o novo resultado. A troca da versão, isoladamente, não garante autorização: os outros parâmetros e regras continuam sujeitos à validação.

Quando a mensagem trata do PAA

A outra mensagem documentada é “Rejeição: Emitente não associado ao PAA”. Na NT 2026.001 PAA v1.02b, página 18, a P81-30 pertence ao ramo de eventos relacionado ao PAA, para modelo 55. Quando infPAA está informado, o trecho verifica o vínculo ativo usando CNPJPAA e o CNPJ do emitente. A observação restringe a implementação dessa regra à SVRS.

Nesse cenário, confira se a identificação enviada corresponde ao provedor contratado e ao estabelecimento emitente. Peça ao provedor que verifique a associação efetiva, sua situação e o ambiente do atendimento. Ter contratado um serviço não comprova que o vínculo exigido está ativo para o estabelecimento utilizado.

Se houve migração de provedor ou alteração de estabelecimento, compare os dados enviados com os registros da associação. Corrija somente uma identificação comprovadamente errada. Quando faltar vínculo, sua regularização precisa seguir o procedimento autorizado, sem utilizar o CNPJ de outra empresa ou remover infPAA para disfarçar a emissão intermediada.

A nota técnica distingue esse ramo da autorização: a ZG02-30, página 14, passou a registrar 936 para a mesma mensagem, substituindo números anteriores, inclusive 672. Não transporte um código riscado da autorização para a P81-30, nem transforme uma rejeição de evento em conclusão sobre a situação de uma NF-e.

Cronograma e limite documental

O cronograma da NT 2026.002 inclui ZX02-220 no conjunto previsto para testes em 01/07/2026 e produção em 03/08/2026. O adiamento para 14/12/2026 cita somente I08-180, BA02-35 e VC02-40; não deve ser transferido para esta regra do QR Code.

A conferência documental em 15/10/2026 utiliza a NT 2026.002 v1.11, o pacote XML 010f e uma nova obtenção oficial da NT PAA v1.02b. Na página 3 desta última, a linha v1.02 registra homologação em 03/08/2026 e produção em 05/10/2026. As correções 1.02a e 1.02b não apresentam novas datas. Não transfira o calendário do DANFE para eventos do PAA.

Na marcação gráfica consultada, a página 14 risca os códigos anteriores da ZG02-30 e conserva 936. A página 18 mantém 672 na P81-30 de eventos. Assim, uma notícia que resume a troca de 672 por 936 na autorização não significa que a rejeição desapareceu de todos os serviços. Nenhuma dessas conferências documentais atesta execução individual em cada autorizador ou a associação de uma empresa concreta.

Como verificar o resultado e quando escalar

Depois da correção adequada, examine o retorno da operação correspondente. Na autorização, preserve o protocolo quando houver autorização; um envio recebido ou o desaparecimento de 672 não basta. No ramo de eventos, confira o resultado específico do evento e seu vínculo com o documento, sem presumir uma nova autorização da nota.

Encaminhe ao suporte os arquivos anterior e posterior, mensagens, UF, ambiente, serviço e versão do emissor. Acione o provedor para divergências de vínculo e a contabilidade para dúvidas sobre o documento ou procedimento fiscal. O objetivo é comprovar a correção da causa, preservando o histórico e a realidade da operação.

Fontes

Conferência documental em 15/10/2026. Sem emissão de teste ou validação operacional do ALRA.

• NT 2026.002 v1.11, páginas 3, 11 e 20: regras e calendário do DANFE Tipo 2.

• NT 2026.001 PAA v1.02b, páginas 3 e 14–18: autorização e eventos são contextos distintos.

• MOC 7.0, Anexo I, páginas 15 e 66, com esquemas XML do Portal Nacional, pacote 010f.

• Apoios consultados: Buscador NCM, Conthouse, FiscoScan. A transcrição da NT pelo FiscoScan é apoio documental; não constitui manual operacional do ALRA. As regras são sustentadas pelas fontes oficiais acima.