ide na NF-e e NFC-e: como conferir a identificação da nota

O grupo ide reúne as informações que identificam a nota e caracterizam a emissão: modelo, série, número, datas, tipo de operação, destino, finalidade, ambiente e processo emissor. Ele aparece uma vez dentro de infNFe. Entender suas relações ajuda a descobrir se um problema nasceu no cadastro, na descrição da operação ou na geração do XML. MOC, pp.8–11

O que o grupo identifica

No XML processado, o caminho é /nfeProc/NFe/infNFe/ide. Se a raiz do arquivo for NFe, começa em /NFe/infNFe/ide. O namespace é http://www.portalfiscal.inf.br/nfe; consultas XPath devem associar um prefixo a ele.

ide não contém todos os dados da nota. O emitente fica em emit, os itens em det, os totais em total e o resultado da autorização em protNFe, fora de infNFe. Assim, encontrar número, modelo ou data em ide não demonstra que houve autorização.

A ocorrência obrigatória do grupo também não torna todos os filhos obrigatórios. Campos condicionais não devem ser gerados como tags vazias, nem copiados de outra nota só para completar uma lista.

De onde vêm os dados

tpAmb=1 identifica produção e 2, homologação; deve corresponder ao serviço acessado. tpEmis descreve a forma de emissão, enquanto tpImp descreve o DANFE. São controles diferentes. indPag, presente em documentação histórica, foi excluído do leiaute 4.00; pagamento não deve ser representado recriando esse filho. MOC, pp.8–11 e B24-10

Entre os condicionais estão dhSaiEnt, os dados de contingência e referências. dhCont informa a entrada em contingência e xJust, sua justificativa. A emissão normal não comporta esse par; os tipos 2, 4, 5 e 9 o exigem pelas regras B28-10/20. Esse par não substitui a data de emissão nem a saída da mercadoria.

As combinações que precisam ser conferidas

A NF-e com mod=55 e tpImp=6 continua sendo modelo 55: o 6 indica DANFE Simplificado Tipo 2. A NT 2026.002 estendeu a esse contexto restrições que também alcançam a NFC-e: não informar dhSaiEnt, não representar entrada, manter operação interna, finalidade normal e consumidor final. O indicador de presença admitido é 1, 4 ou 5, conforme o cenário real. O cronograma das mudanças de domínio e dessas regras prevê produção em 03/08/2026. NT 2026.002, pp.3 e 7–9

Isso não permite aplicar essas restrições indistintamente a toda NF-e. Uma NF-e em outro formato exige sua própria conferência. Também não permite converter operação interestadual em interna para obter autorização: a representação precisa permanecer verdadeira.

A evolução da Reforma Tributária acrescentou finNFe=5 para nota de crédito e 6 para débito, com tpNFCredito ou tpNFDebito e regras próprias. cMunFGIBS identifica outro contexto de fato gerador e não substitui cMunFG. Campos como dPrevEntrega, cIndOp e os grupos de compra governamental e pagamento antecipado possuem aplicação específica; sua existência no leiaute não exige preenchê-los em toda nota. NT 2025.002, pp.15–17

NFref reúne referências fiscais: a NT 2026.004 registra ocorrência 0–999, mas quantidade estrutural não define a obrigação da operação. Referência em ide/NFref e referência por item em det/prod/DFeReferenciado têm regras distintas. A NFC-e e a NF-e com DANFE Tipo 2 não podem informar NFref; finalidades de crédito, complementação e devolução exigem análise do grupo e cronograma aplicáveis. Os ajustes de referenciamento da NT 2026.002 v1.10/1.10a têm produção prevista para 05/10/2026, futura em 26/09/2026. NT 2026.004, p. 5 NT 2026.002, pp.3 e 9

Como ler um fragmento

Este XML é parcial e sintético: mostra alguns filhos na sequência relativa do grupo, omitindo campos obrigatórios e demais partes da nota. Não é um ide completo, não contém chave calculada e não está pronto para transmissão.

<ide xmlns="http://www.portalfiscal.inf.br/nfe">
  <mod>55</mod>
  <tpNF>1</tpNF>
  <idDest>1</idDest>
  <tpImp>1</tpImp>
  <tpEmis>1</tpEmis>
  <tpAmb>2</tpAmb>
  <finNFe>1</finNFe>
  <indFinal>1</indFinal>
  <indPres>1</indPres>
  <procEmi>0</procEmi>
  <verProc>EmissorExemplo-2.0</verProc>
</ide>

A leitura conjunta representa NF-e, saída, operação interna, DANFE retrato, emissão normal e homologação, finalidade normal, consumidor final e operação presencial. O processo 0 é aplicativo do contribuinte; o texto da versão é ilustrativo. Essas hipóteses explicam os códigos, sem escolher a finalidade ou tributação de uma operação real.

Como investigar inconsistências

1. Identifique modelo, ambiente, empresa emitente e XML correspondente ao retorno. Diferencie rascunho de documento autorizado.
2. Leia cStat e a mensagem integral. Uma falha de XSD exige conferir presença, ordem, formato e pacote do schema; uma rejeição de negócio exige as condições da regra.
3. Compare os campos envolvidos. Por exemplo, 705 em uma NF-e com tpImp=6 pode decorrer de dhSaiEnt indevido, mesmo sendo modelo 55. A restrição é da combinação, não da existência geral do campo.
4. Se o erro envolver a chave, confira Id, cUF, ano/mês de dhEmi, emitente, modelo, série, número, tpEmis, cNF e cDV em conjunto.
5. Corrija a origem comprovada no emissor e valide a geração antes da assinatura. Não edite XML assinado, não altere a operação verdadeira e não reenvie sem esclarecer o estado do documento.

A definição de finalidade, códigos fiscais e tratamento da operação exige seus documentos e a confirmação do responsável fiscal. Com esses parâmetros definidos, a conferência técnica verifica se ide, participantes, itens e referências os representam de maneira coerente. Validade estrutural e autorização fiscal continuam sendo verificações distintas.