Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Identificação

idDest na NF-e: operação interna, interestadual e exterior

<idDest>ide › idDest

Revisão editorial em 27 de set. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

idDest classifica o destino territorial da operação: 1=Interna, 2=Interestadual ou 3=Com o exterior. O campo é obrigatório em ide, mas não substitui os endereços do emitente, destinatário, retirada ou entrega. A conferência exige a operação real e as condições de cada regra. MOC, B11a, p. 9

O indicador e os dados que o sustentam

A operação interna está no contexto de uma mesma unidade da federação; a interestadual envolve unidades distintas; a operação com exterior tem seu contexto internacional. Isso não autoriza obter idDest apenas comparando dois endereços cadastrais.

cUF identifica a UF do emitente por código IBGE. cMunFG identifica o município do fato gerador do ICMS. idDest é outra informação: a classificação territorial da operação documentada. Por isso, seu valor não é “41” para Paraná nem um código municipal.

Antes de conferir, reúna tpNF, indFinal, identificação e endereços dos participantes, locais efetivos de retirada/entrega e, quando pertinente, UFCons do combustível. Esses dados permitem interpretar uma diferença que seria invisível numa simples comparação entre emitente e cadastro do cliente.

Restrição da NFC-e e do DANFE Tipo 2

A regra B11a-10 rejeita operação interestadual ou com exterior na NFC-e e na NF-e com tpImp=6, DANFE Simplificado Tipo 2: idDest diferente de 1 gera 707. A extensão ao Tipo 2 está no cronograma de produção de 03/08/2026. Ela não se aplica automaticamente a toda NF-e modelo 55. NT 2026.002, pp.3 e 8

Se a operação verdadeira é interestadual, não declare interna para contornar 707. Confira o documento e formato que foram definidos para ela e a configuração que gerou a combinação incompatível.

Quando os endereços parecem contradizer idDest

As rejeições 772 e 773 possuem condições e exceções distintas para saída e entrada. Nos quadros seguintes, “origem” significa enderEmit/UF, “destinatário”, enderDest/UF, e os locais são entrega/UF e retirada/UF.

Saída interestadual: E12-30, rejeição 772

A regra verifica NF-e de saída (tpNF=1), interestadual (idDest=2), com UF do destinatário igual à do emitente e CNPJ do emitente diferente do destinatário. O MOC manda não rejeitar se algum item tiver UFCons diversa da UF do emitente.

Também exclui os seguintes cenários da regra:

  • entrega com UF diferente da origem, sem UF de retirada;
  • retirada com UF diferente da do destinatário, sem UF de entrega;
  • retirada e entrega informadas, com UFs diferentes entre si.

Entrada interestadual: E12-50, rejeição 772

Para entrada (tpNF=0), o teste básico de UFs iguais e CNPJs diferentes é semelhante; a observação sobre UFCons diversa da origem também existe. Porém, as exceções dos locais mudam:

  • entrega com UF diferente da do destinatário, sem UF de retirada;
  • retirada com UF diferente da origem, sem UF de entrega;
  • retirada e entrega informadas, com UFs diferentes entre si.

Não use a lista da saída para interpretar a entrada: a referência territorial de cada local é diferente. MOC, E12-30 e E12-50, pp.84–85

Saída interna: E12-40, rejeição 773

A regra verifica saída interna (tpNF=1, idDest=1) não destinada a consumidor final, quando UF do destinatário difere da origem. Suas exceções são:

  • UFCons igual à origem;
  • entrega com UF igual à origem, sem UF de retirada;
  • retirada com UF igual à do destinatário, sem UF de entrega;
  • retirada e entrega informadas com UFs iguais entre si.

Entrada interna: E12-60, rejeição 773

Na entrada interna não destinada a consumidor final, o teste de UFs diferentes tem estas exceções:

  • UFCons igual à origem;
  • entrega com UF igual à do destinatário, sem UF de retirada;
  • retirada com UF igual à origem, sem UF de entrega;
  • retirada e entrega informadas com UFs iguais entre si.

O recorte “não destinada a consumidor final” faz parte dessas regras 773. Não o elimine do diagnóstico e não transfira essa condição para a regra 772. MOC, E12-40 e E12-60, pp.84–85

Um cenário que explica a exceção

Considere apenas para leitura da E12-30 uma NF-e de saída com idDest=2, emitente e destinatário cadastrados no Paraná, CNPJs diferentes, entrega efetiva em São Paulo e retirada não informada. A primeira exceção de saída interestadual afasta essa regra 772, apesar dos endereços cadastrais na mesma UF.

Isso demonstra o alcance da validação, não determina tributação, CFOP ou a classificação correta de uma operação particular. Não crie um local fictício para obter a exceção: ela depende da realidade documentada.

XML parcial e conferência final

O fragmento é sintético e parcial, apenas para leitura; omite dados obrigatórios e não está pronto para transmissão.

<ide xmlns="http://www.portalfiscal.inf.br/nfe">
  <mod>55</mod>
  <tpNF>1</tpNF>
  <idDest>2</idDest>
  <tpImp>1</tpImp>
  <finNFe>1</finNFe>
</ide>

A hipótese representa saída interestadual em NF-e normal com DANFE retrato. Os endereços e itens omitidos são indispensáveis para confirmar a consistência do documento inteiro. O XPath é /nfeProc/NFe/infNFe/ide/idDest; sem envelope nfeProc, começa em /NFe.

Em operação com exterior, confira o destinatário e os campos próprios de identificação estrangeira, UF, município e país. Valores especiais do endereço exterior, como EX ou 9999999, não devem ser copiados para o código da UF do emitente ou para cMunFG. A existência de idDest=3 não dispensa essa conferência. MOC, E03a e E14

Para um retorno, identifique a regra exata, a perspectiva de entrada/saída e todos os dados que participam de suas exceções. Se o problema for uma combinação com CFOP, leve ao responsável fiscal os itens, locais, documentos de origem e códigos atualmente definidos; não escolha outro CFOP só pela rejeição.

Corrija o cadastro, a operação ou a geração somente quando a causa estiver comprovada e confira o rascunho. Não modifique XML assinado, não altere endereço verdadeiro para afastar uma regra e não reenvie sem esclarecer o estado da nota. XML estruturalmente válido não prova autorização ou tratamento fiscal correto.

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/ide/idDest
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
1–1 no contexto do elemento pai
Tipo
inline:xs:string · string
Preenchimento no catálogo
Obrigatório

A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.

enumeration
1
enumeration
2
enumeration
3
whiteSpace
preserve