Rejeição 342 — Chave de Acesso informada na Exportação Indireta com DV inválido

O que é esta rejeição?#

A Rejeição 342 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a chave de acesso que identifica unicamente a NF-e, dígito verificador calculado a partir da chave de acesso. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Os campos afetados estão na seção de chave de acesso, identificação da NF-e do XML.

Campos XML relacionados#

Esta rejeição está associada aos seguintes campos do XML da NF-e. Verifique cada um deles ao diagnosticar o problema:

Causas comuns#

• O dígito verificador da chave de acesso está incorreto
• A chave de acesso tem formato inválido (deve ter exatamente 44 dígitos)
• Os componentes da chave (UF, data, CNPJ, modelo, série, número) não correspondem aos dados da NF-e
• O código numérico aleatório (cNF) está ausente ou com formato incorreto

Como resolver#

1. Recalcule o dígito verificador usando o algoritmo módulo 11 conforme especificação da SEFAZ
2. Verifique se todos os componentes da chave de acesso correspondem aos dados informados na NF-e
3. Confirme que a chave tem exatamente 44 dígitos numéricos, sem espaços ou caracteres especiais
4. Regenere a chave de acesso completa no seu sistema emissor e retransmita

Verificações analíticas#

• Se o cNF extraído dos dígitos 36 a 43 da chave de acesso não corresponder ao campo cNF declarado dentro de infNFe/ide, então há divergência entre o código numérico aleatório embutido na chave e o informado no XML, indicando que a chave foi composta com um cNF diferente do persistido no documento: reconstrua a chave concatenando cUF+AAMM(dhEmi)+CNPJ(emit)+mod+serie+nNF+tpEmis+cNF, recalcule o DV por módulo 11 e substitua o campo chNFe.
• Se os dois primeiros dígitos da chave de acesso (cUF embutido) não coincidirem com o código IBGE da UF declarada em ide/cUF e também não corresponderem à UF do endereço do emitente em emit/enderEmit/UF, então a chave foi gerada com código de UF incorreto, tornando o DV inválido mesmo que o algoritmo tenha sido aplicado corretamente: corrija cUF para o código IBGE oficial da UF emitente antes de recalcular o DV.
• Se os dígitos de posição 3 a 6 da chave (AAMM) não corresponderem ao ano e mês extraídos do campo ide/dhEmi, então a data embutida na chave diverge da data de emissão declarada no XML, corrompendo a base de cálculo do DV e podendo indicar que a chave pertence a outro período fiscal: atualize o segmento AAMM da chave com o ano-mês correto de dhEmi e reprocesse o dígito verificador.
• Se os 14 dígitos correspondentes ao CNPJ na posição 7 a 20 da chave de acesso não coincidirem com o CNPJ informado em emit/CNPJ após remoção de máscaras, então o emissor pode ter utilizado CNPJ de filial, matriz ou estabelecimento distinto para compor a chave enquanto o XML declara outro CNPJ: unifique ambos os valores para o CNPJ do estabelecimento emitente real e regenere a chave completa.
• Se ide/tpEmis for diferente de 1 (emissão normal) e o dígito de posição 35 da chave de acesso não refletir o valor correto de tpEmis (por exemplo, tpEmis=9 para contingência off-line), então o campo tpEmis foi omitido ou substituído por 1 na composição da chave mesmo em situação de contingência, alterando a sequência de entrada do módulo 11 e gerando DV incorreto: garanta que o valor real de ide/tpEmis seja inserido na posição 35 da chave antes do cNF e recalcule o DV.