Rejeição 403 — O grupo de informações da NF-e avulsa é de uso exclusivo do Fisco

O que é esta rejeição?#

A Rejeição 403 é retornada pela SEFAZ durante a validação da NF-e quando há uma inconsistência relacionada a modelo do documento fiscal, informação do documento fiscal. Isso significa que a nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Este código indica que rejeição: O grupo de informações da NF-e avulsa é de uso exclusivo do Fisco.

Os campos afetados estão na seção de 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 modelo do documento fiscal está incorreto — deve ser 55 (NF-e) ou 65 (NFC-e)
• O modelo informado não corresponde ao tipo de operação ou ao web service utilizado

Como resolver#

1. Use modelo 55 para NF-e e modelo 65 para NFC-e
2. Verifique se está enviando para o web service correto conforme o modelo do documento

Verificações analíticas#

• Se o campo mod (modelo) dentro de ide contiver valor diferente de 55 ou 65 e simultaneamente o campo tpAmb, cUF e versão do schema indicarem envio ao ambiente de produção SEFAZ, então o documento está estruturalmente incompatível com qualquer web service autorizado: corrija mod para 55 (NF-e) ou 65 (NFC-e) conforme o tipo de operação antes de qualquer retransmissão.
• Se o campo mod for 55 e o ambiente de envio (endpoint utilizado) corresponder ao web service de NFC-e (NfceRecepcaoSincV4), ou se mod for 65 e o envio ocorrer pelo web service de NF-e (NFeRecepcaoLote4), então há incompatibilidade entre modelo declarado e serviço acionado: direcione o documento ao endpoint correto conforme a tabela de URLs por modelo e UF da SEFAZ.
• Se o campo mod for 55 e concomitantemente o campo indPres (indicador de presença) contiver valor 1 (operação presencial no estabelecimento) junto com tpNF=1 (saída) e ausência de destinatário pessoa jurídica (CNPJ vazio e CPF preenchido com consumidor final), então o conjunto de atributos remete a uma operação típica de NFC-e (mod 65) e não de NF-e: revise o modelo ou ajuste os campos de destinatário e presença para refletir a operação correta.
• Se o grupo infNFeSupl (contendo qrCode e urlChave) estiver presente no XML e o campo mod for 55, então há presença de grupo exclusivo de NFC-e dentro de uma NF-e, sinalizando montagem incorreta do documento com mistura de estruturas dos dois modelos: remova o grupo infNFeSupl quando mod=55, pois ele só é válido para NFC-e (mod 65).
• Se o campo tpEmis indicar emissão em contingência offline (valores 5, 6 ou 7) e o campo mod for 55 enviado para o SCAN ou SVC sem que a chave de acesso tenha sido recalculada com o cDV correto após alteração do modelo, então a chave de acesso referenciada internamente em infNFe id pode não corresponder ao documento transmitido: recalcule o dígito verificador da chave de acesso após qualquer correção no campo mod e garanta que id, cChNFe e o conteúdo do atributo Id estejam todos sincronizados.