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

refNF na NF-e: dados da nota modelo 1/1A ou 2 e mudança da rejeição 681

<refNF>ide › NFref › refNF

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

refNF identifica uma nota fiscal modelo 1/1A ou modelo 2 referenciada por seis dados do documento original: UF, ano/mês de emissão, CNPJ do emitente, modelo, série e número. Ele fica em ide/NFref, como alternativa à referência por chave eletrônica. MOC, BA03–BA09, pp. 11–12

A presença do grupo em um XML antigo permite reconhecer a nota original. Para nova autorização, é necessário considerar a vedação de refNF prevista pela NT 2026.002 para 05/10/2026 em produção, futura no corte de 26/09/2026. O retorno 681 deixa de representar somente duplicidade na nova redação. NT 2026.002, pp. 3 e 9

O XPath completo é /nfeProc/NFe/infNFe/ide/NFref/refNF, no namespace http://www.portalfiscal.inf.br/nfe.

Nesta página: dados, diferenças, exemplo, 681 e diagnóstico.

Os seis campos pertencem ao documento anterior

No schema, todos os filhos aparecem uma vez e nesta sequência:

Campo Dado do documento original Formato e conferência
cUF UF do emitente da nota referenciada Código de dois dígitos da tabela IBGE; não sigla ou município
AAMM Ano e mês da emissão original Dois dígitos de ano e dois de mês, por exemplo 2508
CNPJ CNPJ do estabelecimento que emitiu a nota 14 posições, sem máscara
mod Modelo da nota original 01 para 1/1A; 02 para modelo 2
serie Série da nota original Zero se não utilizada; domínio numérico de até três dígitos
nNF Número da nota original De 1 a 999999999, no tipo TNF

A origem é o documento em papel e seus registros verificáveis. Não use os campos de ide ou emit da nota atual como substitutos automáticos. Uma NF-e de entrada pode ser emitida por uma empresa e referenciar nota anterior de outro emitente; o grupo descreve a origem, não quem está operando o emissor agora. MOC, BA04–BA09 Schema, refNF

O CNPJ foi atualizado para caracteres pela NT 2026.004. No tipo TCnpj, as primeiras 12 posições admitem números ou letras maiúsculas e as duas últimas são os dígitos verificadores numéricos. Isso não altera o CNPJ verdadeiro de uma nota antiga nem autoriza substituir seu estabelecimento pela matriz. NT 2026.004, pp. 3 e 5 Tipos básicos

A obrigatoriedade dos seis filhos vale quando refNF aparece. O grupo é uma alternativa de NFref, não uma exigência universal em toda NF-e. A escolha estrutural permite apenas uma alternativa documental em cada ocorrência do pai.

A espécie documental define o caminho

Uma cópia impressa de documento eletrônico não é, por esse motivo, NF modelo 1. Identifique a espécie do original:

  • refNF descreve modelo 1/1A ou 2 com os seis campos.
  • refNFe usa chave de acesso e tem regras próprias de modelo e finalidade.
  • refNFP descreve o documento do grupo de produtor, com CNPJ ou CPF, IE e modelos 01/04.
  • refECF descreve cupom por modelo, equipamento e COO.
  • refCTe identifica CT-e por chave.

O código 01 existe também no domínio de refNFP; sua coincidência não torna os grupos intercambiáveis. CNPJ, CPF e IE, assim como o contexto da operação, precisam ser lidos no caminho correto. MOC, grupo BA Schema, NFref

Não fabrique uma chave de 44 posições para uma nota em papel e não reduza uma chave eletrônica ao número da nota para fazê-la caber em refNF/nNF. Se a origem não cabe no grupo descrito, a questão é a identificação documental e a operação, não um ajuste arbitrário de formato.

A NFC-e e a NF-e com DANFE Simplificado Tipo 2, tpImp=6, vedam o grupo pai NFref pela BA01-10/708. Essa condição não depende de o documento em papel estar corretamente identificado. NT 2026.002, pp. 3 e 9

Exemplo de nota sem série

Trecho parcial e sintético, para leitura histórica; não é uma nota pronta para transmissão nem indicação de uso após a vedação:

<NFref xmlns="http://www.portalfiscal.inf.br/nfe">
  <refNF>
    <cUF>35</cUF>
    <AAMM>2508</AAMM>
    <CNPJ>12345678000195</CNPJ>
    <mod>01</mod>
    <serie>0</serie>
    <nNF>1234</nNF>
  </refNF>
</NFref>

O exemplo pressupõe nota modelo 1/1A de emitente em São Paulo, emitida em agosto de 2025, número 1234 e sem série utilizada. Por isso, serie é 0. O CNPJ é sintético, com DV coerente; não demonstra cadastro real.

AAMM=2508 não é a data da NF-e atual. serie=0 não significa série desconhecida: se uma série existe no original, ela precisa ser conferida. O tipo TSerie representa zero ou inteiro de 1 a 999, sem zeros iniciais nos valores positivos. O tipo TNF representa número positivo com até nove dígitos, também sem zeros iniciais. Assim, nNF=0 ou 000001234 não corresponde a esse domínio, embora o documento impresso possa apresentar preenchimento visual à esquerda. MOC, BA08/09 Tipos TSerie/TNF

Se o original possui série alfanumérica ou um identificador que não se encaixa nesses tipos, não remova caracteres para improvisar uma identidade. Recupere o documento e confirme sua espécie e a representação cabível.

A regra 681 muda de significado em outubro

Na redação anterior do MOC, a BA03-10/681 é facultativa no modelo 55 e verifica repetição pelo mesmo CNPJ, modelo, série e número. A data AAMM não faz parte dessa combinação de duplicidade. Trocar apenas o mês não transforma a mesma nota em outra. MOC, p. 79

Na NT 2026.002 v1.10a, essa regra passa a proibir informar refNF, com aplicação obrigatória e o mesmo código 681. O critério de duplicidade está riscado na nova redação. Assim, uma referência única e com todos os dados corretos pode continuar bloqueada quando a vedação for aplicável. NT 2026.002, p. 9

O cronograma dessa alteração é 01/09/2026 em teste e 05/10/2026 em produção. Em 26/09/2026, a mudança ainda é futura em produção; homologação pode estar no marco anterior de teste. A análise precisa guardar ambiente, data e motivo efetivamente retornado, sem interpretar todo 681 como duplicidade nem presumir uma vedação já ativa em produção apenas pela publicação da NT. NT 2026.002, p. 3

Conferência dos erros antes e depois do marco

As outras verificações antigas também têm contexto e destino:

Regra anterior do MOC O que verificar Mudança documentada
BA05-10 / 317 Emissão de modelo 1 há mais de 20 anos ou AAMM superior ao atual Removida no conjunto da NT 2026.002
BA06-10 / 548 CNPJ zerado, nulo ou DV inválido Removida no mesmo conjunto
BA20-20 / 923 refNF ou refECF com idDest<>1, operação interestadual/exterior Removida no mesmo conjunto

A tabela do MOC repete, na descrição da 548, um texto sobre data, mas a condição da BA06-10 verifica CNPJ. Para um retorno real, conserve código e motivo exatos e compare o CNPJ, sem concluir que a causa é AAMM pelo texto isolado. MOC, pp. 79 e 81

Na redação futura, essas linhas riscadas não constituem uma lista de ajustes que liberam refNF. Corrigir a data, o DV ou a repetição atende apenas à causa que se comprovou no contexto anterior; não supera a vedação do grupo. NT 2026.002, pp. 3, 9 e 11

Para uma conferência verificável:

  1. Recupere a nota original e identifique modelo, emitente, UF, emissão, série e número.
  2. Compare todos os campos do grupo e sua ordem, sem usar informações da NF-e atual como preenchimento automático.
  3. Compare as combinações entre ocorrências para investigar duplicidade anterior.
  4. Registre modelo atual, finalidade, tpImp, idDest, UF, ambiente, data e retorno completo.
  5. Corrija somente erro de vínculo ou geração confirmado. Preserve o XML assinado/autorizado e não modifique dados verdadeiros para contornar regra.

Se a operação pretende relacionar um documento em papel a uma nova NF-e, confirme a hipótese documental e a finalidade com o responsável contábil, levando o original, motivo da emissão, UF e data. A proibição do grupo não permite mudar a espécie original ou criar uma chave eletrônica fictícia.

Os detalhes têm páginas próprias: AAMM da nota referenciada, CNPJ do emitente original e série da referência.

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/ide/NFref/refNF
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:complexType
Preenchimento no catálogo
Condicional

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.