Rejeição 357: como verificar a existência da NF-e ligada à exportação indireta

A rejeição 357 informa que a SEFAZ não encontrou a NF-e cuja chave foi indicada no grupo de exportação indireta. Ter uma chave com aparência correta, ou até um DANFE salvo, não comprova que o documento exista como nota autorizada no ambiente consultado. O primeiro passo é recuperar a documentação verdadeira de origem e conferir o vínculo enviado.

Para a empresa, esse cuidado evita substituir uma referência errada por outra apenas formalmente válida. A nota anterior precisa corresponder à mercadoria e à etapa da operação que estão sendo documentadas.

Qual consulta gera essa rejeição

A regra 4I54-10 do MOC 7.0, página 136 integra a autorização da NF-e modelo 55. Para cada chave em detExport/exportInd/chNFe, ela prevê acesso à base de NF-e quando a UF da chave citada é igual à UF do emitente. A inexistência do documento nessa verificação resulta na 357.

A regra é facultativa por UF. A tabela oficial da SEF-MG v2.00 assinala sua validação em Minas Gerais; a página de downloads informa atualização em 13/03/2026. Essa é evidência estadual específica, sem demonstrar ativação em todas as UFs ou em cada ambiente.

O requisito de mesma UF delimita essa regra; não é permissão para usar uma nota inexistente de outro estado. Tampouco se deve alterar a UF dentro da chave para fugir da consulta. A chave identifica um documento emitido e não pode ser remodelada pelo destinatário.

A referência está no item

No XML, confira det/prod/detExport/exportInd/chNFe. Não confunda esse campo com a chave da NF-e que você está emitindo nem com uma referência informada somente em ide/NFref. A mensagem pode trazer nRef; use esse apontamento e a estrutura do arquivo para localizar a ocorrência rejeitada.

O leiaute do MOC, página 20, define a origem usual: a NF-e recebida com fim específico de exportação. Existe uma ressalva expressa para CFOP 3.503, em que deve ser usada a chave da NF-e que efetivou a exportação.

Por isso, pedir somente “uma nota de compra” pode ser insuficiente. Confirme o documento correto para o item e a operação, verificando emitente, mercadorias e vínculo comercial. Não use outra nota do mesmo fornecedor apenas porque ela está autorizada.

Três verificações antes de corrigir

Primeiro, compare a chave enviada com o XML original recebido. Procure valor truncado, importação de planilha, referência antiga ou seleção de documento errado. Se a diferença estiver no cadastro, restaure integralmente a chave verdadeira. Não tente resolver recalculando apenas o dígito verificador.

Segundo, confirme o ambiente. Uma autorização em homologação não comprova existência em produção. O ambiente deve ser consultado no retorno ou protocolo, pois não pode ser deduzido apenas da aparência da chave.

Terceiro, verifique a situação atual do documento por um canal oficial ou pela consulta integrada já utilizada pela empresa. Um arquivo ainda pendente de autorização não deve ser tratado como origem autorizada só porque já tem chave gerada.

A Omie mostra a conferência da chave recebida na aba de exportação de cada item. O ponto aproveitável é revisar o vínculo no produto, além da capa do pedido. Os nomes de menus não são comuns a todos os sistemas.

Existência e situação fiscal são problemas diferentes

Se a consulta localizar uma nota cancelada ou historicamente denegada, o problema não é simplesmente “não existir”. O MOC trata esses estados na regra 4I54-20, código 358. Não considere um documento adequado apenas porque uma consulta retornou algum registro.

A base técnica da Oobj, na seção sobre chaves da exportação indireta, também separa os testes de inexistência e de cancelamento ou denegação. Essa separação ajuda a direcionar o atendimento: recuperar um documento ausente e substituir um vínculo com documento cancelado exigem evidências diferentes.

A Berga destaca riscos de digitação, ambiente e uso de uma remessa ainda sem autorização. São hipóteses para investigar. Não há, na 4I54-10, um prazo fixo de minutos que garanta sincronização entre bases; repetir envios sem confirmar o estado da origem pode apenas reproduzir a falha.

Se a origem aparece autorizada e a 357 continua

Guarde o XML da origem, o protocolo de autorização, a consulta atual e o arquivo da nota rejeitada. Confirme que todas as provas se referem à mesma chave e ao mesmo ambiente. Compare também a UF da chave com a do emitente da nota em processamento.

Com esse conjunto, o fornecedor do emissor consegue examinar a geração do arquivo e a resposta do autorizador. Uma divergência persistente entre a consulta oficial e o retorno da autorização deve ser encaminhada ao suporte responsável, sem inventar outra chave nem emitir novamente a nota de origem por iniciativa própria.

A exceção de contingência da regra de referência geral 3BA02-10, código 267, não está escrita na 4I54-10. Do mesmo modo, a exceção de NF-e complementar da regra que exige exportInd não dispensa automaticamente a conferência de existência quando esse grupo foi informado.

Cuidados atuais com formato e documento

A NT 2026.004 v1.01, página 7 atualiza chNFe para tipo caractere, mantendo 44 posições, no contexto do CNPJ alfanumérico. Preserve letras e zeros válidos do documento de origem; uma rotina que aceita apenas números pode corromper a identificação no leiaute correspondente.

Também não use NFC-e ou DANFE Simplificado Tipo 2 como alternativa para essa exportação. A NT 2026.002 v1.11, páginas 8–9 restringe operação com exterior e referências nesse formato. A 357 continua sendo validação de autorização da NF-e 55, sem se confundir com evento de exportação.

Corrigido o vínculo, regenere o XML e confira o retorno individual. Se houver envio anterior inconclusivo, consulte sua situação antes de retransmitir. A solução está concluída quando a documentação correta foi vinculada e o resultado da emissão foi confirmado, com protocolo preservado quando autorizada.

Referência de atualização: 10/10/2026. Escopo: autorização NF-e modelo 55, regra facultativa 4I54-10, observada a condição de mesma UF e o ambiente.