Rejeição 377: como corrigir o país do destinatário na NF-e

A rejeição 377 significa que o código enviado para identificar o país do destinatário não foi encontrado na tabela adotada pela NF-e. A correção começa por confirmar o endereço verdadeiro desse participante e localizar o código correspondente na tabela oficial. Escrever o nome certo do país na tela não resolve se a integração transmitir outro número.

O diagnóstico vale para o retorno de autorização de NF-e e NFC-e, modelos 55 e 65. Guarde a mensagem completa, o XML enviado, o ambiente e o horário da tentativa. A indicação de país inexistente se refere ao valor cadastrado no documento; ela não demonstra que a empresa destinatária seja inexistente ou esteja irregular.

Qual campo a SEFAZ está verificando

A regra E14-04 do MOC 7.0, página 85 verifica o código do país quando ele foi informado em dest/enderDest/cPais. No XML completo, o caminho é NFe/infNFe/dest/enderDest/cPais. A aplicação está classificada como obrigatória para os modelos 55 e 65, dentro do predicado da regra.

Esse campo pertence ao endereço do destinatário. Os códigos de país do emitente, da retirada, da entrega e de um item tributado pelo ISSQN ficam em outros grupos. Uma pesquisa apenas pela palavra cPais pode encontrar vários resultados e levar a uma alteração no lugar errado. Para um técnico, o nome do grupo pai é tão importante quanto o nome da tag.

A regra manda consultar a tabela do BACEN disponibilizada como apoio no Portal da NF-e. Não é uma escolha por semelhança com a tabela de municípios do IBGE, com siglas internacionais ou com a numeração interna de um ERP. O campo xPais contém a descrição; preencher essa descrição não substitui o código fiscal.

Use a tabela da NF-e e confira a data

O Portal Nacional, seção Diversos disponibiliza a Tabela de Países relacionada à NT 2018.003. A versão 1.01 dessa nota técnica determina que a validação considere a data de emissão. Portanto, uma base antiga de países pode precisar de revisão mesmo que o cadastro tenha sido usado anteriormente.

O Brasil é identificado por 1058, conforme o próprio MOC. Esse valor só é uma correção adequada quando corresponde ao país efetivo do destinatário e ao enquadramento da operação. Para um destinatário no exterior, procure o país confirmado na tabela; não use Brasil como valor padrão para eliminar o erro.

Zeros não significativos podem estar presentes ou ausentes, segundo a observação da E14-04. Isso não permite remover dígitos que fazem parte do código, acrescentar números arbitrários nem ultrapassar o tamanho previsto no leiaute. O responsável pela integração deve conferir simultaneamente o domínio do código e a estrutura aceita pelo schema em uso.

Corrija a origem do dado

1. Confirme qual destinatário foi utilizado na nota. Em uma entrada, ele pode representar o remetente da operação. Compare os dados da nota com a documentação comercial, sem presumir que o endereço de cobrança seja o endereço fiscal correto.

2. Identifique o país real e procure seu registro na tabela publicada pelo Portal da NF-e. Guarde a referência consultada e a data da conferência.

3. Abra o cadastro que alimenta o documento. Confira se existe uma separação entre código interno do país e código fiscal exportado para o XML.

4. Ajuste o vínculo correto no emissor. Verifique também integrações de pedidos, importadores de cadastro e rotinas que copiam documentos antigos.

5. Atualize a nota rejeitada e gere uma nova prévia do XML. Confira dest/enderDest/cPais, não apenas o texto apresentado na tela.

A orientação da TOTVS para a linha Logix localiza a correção no cadastro de países. Já o material da Sankhya trata do campo de domicílio fiscal e da geração de novo lote. São exemplos de onde o problema pode nascer; os menus dependem do produto usado pela empresa.

Um cadastro aparentemente correto pode gerar um XML errado

Imagine um destinatário comprovadamente estabelecido no Brasil. A tela mostra Brasil, mas o campo fiscal do país aponta para um identificador interno da integração. Confirmada essa origem, o ajuste é fazer a exportação enviar 1058. Trocar o nome para letras maiúsculas, editar o município ou mudar o CFOP não corrige o mapeamento que permaneceu errado.

Se a tabela geral já foi corrigida, uma nota preparada antes da alteração pode conservar a informação anterior. Compare o arquivo rejeitado com o recém-gerado. Se os dois contêm o mesmo código indevido, a atualização não chegou ao documento ou outra rotina sobrescreveu o campo. O guia da Omie sobre a 377 também distingue o código numérico das informações descritivas e aponta a necessidade de análise técnica da configuração.

País existente não significa operação inteiramente correta

A 377 verifica a existência do código. Outras validações confrontam país, UF e operação, incluindo regras relacionadas às rejeições 510, 511 e 926. Um código existente pode continuar incompatível com os fatos. Por isso, não altere idDest, CFOP ou identificação do destinatário apenas para fazer o país escolhido parecer coerente.

A condição de operação com o exterior não permite deduzir, sozinha, todos os endereços do documento. Há operações com participantes e locais distintos, além de exceções documentais próprias. Quando a dúvida é sobre o enquadramento fiscal, peça sua definição ao responsável tributário antes de mudar os indicadores.

Depois da correção, deixe o emissor validar e assinar o novo arquivo. Reenvie pelo fluxo da nota rejeitada e confira o resultado final da autorização. Se houver dúvida sobre uma tentativa anterior, consulte sua situação antes de gerar outro documento. Para suporte, reúna retorno, modelo, UF autorizadora, ambiente, código transmitido e caminho XML, usando canal seguro.

Referência de atualização: 09/10/2026. A base nacional e as notas técnicas foram confrontadas; a aplicação operacional deve ser confirmada para a versão, UF e ambiente utilizados.