Rejeição 396: como encontrar o parâmetro que falta no QR Code

A rejeição 396 indica que falta um parâmetro exigido na composição do QR Code enviado para autorização. A correção depende da versão e da forma de emissão: acrescentar indiscriminadamente todos os campos encontrados em um tutorial pode transformar uma ausência em uma nova inconsistência.

Comece pelo retorno completo da SEFAZ, especialmente pela indicação do parâmetro, e pelo XML efetivamente transmitido. O desenho do QR no DANFE não revela, sozinho, se o conteúdo foi montado corretamente. A análise também precisa distinguir NFC-e modelo 65 de NF-e modelo 55 com DANFE Simplificado Tipo 2.

Ausência do QR e ausência de um parâmetro são situações diferentes

Quando o campo qrCode exigido não existe, o diagnóstico relacionado é a rejeição 394. No caso de 396, o foco está nas partes que compõem o conteúdo desse campo. O grupo infNFeSupl também contém urlChave, destinado à consulta pela chave de acesso; preencher esse endereço não supre um parâmetro ausente do QR.

A mensagem 396 é um resultado de autorização. Identificadores como ZX02-224 e ZX02-232 são referências das regras técnicas, não códigos adicionais devolvidos ao contribuinte. Há várias regras com a mesma mensagem porque chave, versão, ambiente e outros dados podem faltar separadamente. NT 2025.001 v1.03, páginas 11–13

Primeiro descubra qual estrutura o sistema deveria gerar

Na NFC-e, a composição documentada muda entre as versões 2 e 3:

• Versão 2, emissão normal: chave de acesso, versão, ambiente, identificador do CSC e hash

• Versão 2, contingência offline: chave, versão, ambiente, dia da emissão, total da nota, DigestValue convertido, identificador do CSC e hash

• Versão 3, emissão normal: apenas chave, versão e ambiente

• Versão 3, contingência offline: chave, versão, ambiente, dia da emissão, total, tipo de identificação do destinatário, identificação do destinatário e assinatura

A ordem é parte do leiaute. Nas versões 2 e 3, os parâmetros são posicionais e separados por barra vertical. Um separador eliminado pode deslocar os campos seguintes; por isso, contar posições é tão importante quanto verificar valores. Dia e total pertencem ao QR de contingência, com tpEmis=9, e não devem ser acrescentados ao QR normal. Manual DANFE-NFC-e e QR Code v6.0, páginas 21–22 e 29–30

No QR v3 não há parâmetros de CSC, identificador do CSC, hash ou DigestValue. A presença desses termos em tabelas de mensagens ou em tutoriais de versões anteriores não os torna obrigatórios na estrutura nova. A ausência da assinatura exigida no v3 offline tem regra própria, com código 474.

Destinatário não identificado exige atenção às posições

No v3 offline da NFC-e, o manual prevê posições vazias para destinatário não identificado, preservando os separadores. Para destinatário estrangeiro, há orientação específica para a posição de identificação. Portanto, a referência a “parâmetro não informado” não autoriza inventar CPF, CNPJ ou texto para preencher um espaço que o leiaute determina deixar vazio.

Confira a situação real no XML e aplique a tabela da versão utilizada. O tipo e a identificação precisam ser coerentes com a nota. Remover posições vazias por uma rotina automática de limpeza pode deslocar a assinatura e produzir um QR incorreto. Essa é uma falha de montagem a ser corrigida no emissor, não no cadastro do cliente por tentativa.

O que muda na NF-e modelo 55

A NT 2026.002 v1.11 estendeu validações de parâmetros aos modelos 55/65 e exige QR v3 para a NF-e com DANFE Simplificado Tipo 2, tpImp=6. A contingência offline do modelo 55, nesse conjunto de regras, é admitida somente para esse formato. Não se deve aplicar ao Tipo 2 a receita de CSC e hash do QR v2 da NFC-e. NT 2026.002 v1.11, páginas 20–23

O cronograma desse bloco prevê produção em 03/08/2026; a alteração para 14/12/2026 da mesma NT alcança três outras regras indicadas no documento. Também não há autorização para generalizar o Tipo 2 a qualquer DANFE: a NT 2026.010 ainda remete a norma futura as condições de QR nos demais formatos, inclusive retrato e paisagem.

Um roteiro de correção que evita retrabalho

1. Registre cStat, mensagem completa, parâmetro citado, modelo, UF, ambiente, versão do emissor e forma de emissão

2. Abra uma cópia do XML transmitido e identifique o conteúdo de qrCode, sem divulgar dados de clientes ou segredos do emissor

3. Compare a sequência com a composição correta. Separe ausência real de posição vazia prevista e de campo que nem pertence àquela versão

4. Corrija a configuração ou a rotina que gera o QR. Regenere os elementos dependentes pelo fluxo regular do emissor

5. Antes de retransmitir, confira a situação do documento para evitar duplicidade. Após o envio, verifique a autorização e a correspondência do DANFE com o XML final

Imagine um caixa que recebeu atualização para QR v3, mas ainda executa uma validação interna antiga exigindo CSC. Acrescentar o identificador ao QR normal v3 não resolve a incompatibilidade entre os componentes. É necessário alinhar gerador, validador e configuração à mesma versão.

Os materiais de TecnoSpeed, Oobj e Webmania ajudam a reconhecer falhas de composição. Suas listas de campos precisam ser lidas no contexto do QR v2; a atualização para v3 vem das fontes oficiais.

Como confirmar que a ocorrência terminou

Se o aviso apareceu somente na consulta pública, recupere o código e a mensagem daquele serviço: o manual usa, por exemplo, 212 para versão ausente e 214 para ambiente ausente. Eles não equivalem ao cStat 396 da autorização.

O encerramento exige duas verificações separadas: resposta de autorização do documento corrigido e leitura coerente do QR correspondente. Preserve o retorno anterior e a versão final para demonstrar o que mudou. Assim, a empresa resolve a origem da falha sem inserir dados desnecessários ou tratar um problema de consulta como rejeição de emissão.