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

AAMM em refNF: ano e mês da nota referenciada e rejeição 317

<AAMM>ide › NFref › refNF › AAMM

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

AAMM em refNF é o ano e o mês de emissão da nota modelo 1/1A ou 2 referenciada. O conteúdo tem quatro dígitos: dois do ano e dois do mês. A data vem do documento original, e não da NF-e que está sendo emitida agora. MOC, BA05, p. 11

O XPath é /nfeProc/NFe/infNFe/ide/NFref/refNF/AAMM. A tag diferencia maiúsculas de minúsculas; seu namespace é http://www.portalfiscal.inf.br/nfe. O campo é obrigatório quando refNF está presente, mas a referência tem condições e mudanças próprias de autorização.

A data é a da nota original

Confira a data de emissão no documento anterior e nos registros que o identificam. Data de recebimento, lançamento, pagamento e emissão da NF-e atual não substituem a emissão original.

Por exemplo, uma nota de agosto de 2025 referenciada por uma NF-e de setembro de 2026 continua com AAMM=2508. Copiar 2609 da data atual tornaria a identificação temporal incorreta, mesmo que o XML parecesse bem formado.

O MOC chama a descrição de BA05 de “Ano e Mês de emissão da NF-e”, mas a observação e o grupo deixam claro que o valor é o AAMM da emissão da NF referenciada. Leia o campo dentro de refNF, sem transportar a data de ide/dhEmi. MOC, BA03–BA05

A formação de AAMM é verificável

Depois de confirmar a data original:

  1. Separe o ano e o mês.
  2. Use os dois últimos dígitos do ano.
  3. Represente o mês com dois dígitos, inclusive o zero dos meses 01 a 09.
  4. Concatene ano antes do mês, sem barra, hífen, dia ou horário.
Data sintética confirmada no original Resultado AAMM Leitura
15/01/2025 2501 Janeiro de 2025
20/08/2025 2508 Agosto de 2025
03/12/2025 2512 Dezembro de 2025

O XSD usa um padrão que admite dois dígitos de ano seguidos de mês entre 01 e 12. 0125, no exemplo de janeiro de 2025, estaria invertido e terminaria em mês 25, inválido. 2500, 2513, 202508 e 25/08 também não correspondem ao formato. Schema, refNF/AAMM

Trecho parcial e sintético, para localizar o campo numa referência histórica; não é uma nota pronta para transmissão:

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

O período é agosto de 2025 para a nota modelo 1/1A número 1234, série 1, do emitente sintético identificado. Os demais campos explicam qual nota tem essa data. AAMM isolado não identifica um documento.

Formato válido e período aceito são verificações distintas

O padrão do schema não sabe se a emissão é futura, antiga ou verdadeira. Um conteúdo pode ter quatro dígitos e mês válido sem satisfazer uma regra de autorização.

Na redação anterior do MOC, a BA05-10, para NF-e modelo 55 com NF modelo 1 referenciada, verifica:

  • emissão da nota referenciada há mais de 20 anos da data atual; ou
  • data de emissão superior ao ano/mês atual.

A regra é facultativa e prevê 317 — NF modelo 1 referenciada com data de emissão inválida. O texto da condição cita modelo 1; não generalize essa condição automaticamente a modelo 2, CT-e ou todos os campos homônimos AAMM. MOC, BA05-10, p. 79

No corte sintético de setembro de 2026, 2610 representa outubro de 2026: passa pelo padrão de mês, mas é superior a 2609 na comparação de ano/mês. Já 2508 fica em período anterior. A regra de idade exige a emissão e o momento de validação; o formato sem dia não autoriza inventar uma tolerância adicional na fronteira exata dos 20 anos.

Os dois dígitos de ano também não bastam, isoladamente, para recuperar o século de uma nota antiga. Preserve a data completa do documento original nos registros usados para conferência; não interprete 05 como um século escolhido pelo gerador para fazer a referência caber.

A rejeição 317 e a futura vedação de refNF têm contextos diferentes

A NT 2026.002 v1.10a remove BA05-10 no conjunto de mudanças e altera BA03-10/681 para proibir informar refNF. A nova regra não é uma janela de datas: o problema passa a ser o próprio grupo de referência. NT 2026.002, p. 9

O cronograma é 01/09/2026 em teste e 05/10/2026 em produção. Em 26/09/2026, a mudança ainda é futura em produção. Por isso:

  • Um diagnóstico anterior de 317 precisa conservar a condição e o ambiente aplicáveis.
  • Um retorno novo de proibição de refNF não se resolve trocando AAMM.
  • A remoção da regra de data não autoriza informar uma data falsa nem usar o grupo após a vedação.

As linhas riscadas da NT identificam a redação removida; não são condições adicionais vigentes da regra futura. NT 2026.002, pp. 3 e 9

Conferência da origem antes de qualquer ajuste

Se AAMM está errado no XML, compare a data original, a data armazenada na referência e a transformação do gerador. Identifique se houve cópia da emissão atual, inversão MMAA, perda do zero do mês ou importação de uma data comercial.

Se o retorno é 317, guarde código/motivo, UF, ambiente, data da validação e modelo original. Compare período e idade pelas condições da regra, sem alterar a emissão verdadeira.

Se o retorno anterior é 681 por duplicidade, a combinação da BA03-10 é CNPJ, modelo, série e número; AAMM não integra essa chave de comparação. Mudar o mês não cria uma nota diferente. A nova redação de 681, por sua vez, veda o grupo. MOC, BA03-10, p. 79 NT 2026.002, p. 9

Quando a data verdadeira confirma uma restrição ou há dúvida sobre qual documento pode ser referenciado, reúna original, data completa, motivo da emissão, UF e finalidade para confirmação com o responsável contábil. Não remonte a referência para forçar autorização e não edite o XML assinado ou autorizado.

A página refNF — dados da nota referenciada explica os outros identificadores. O AAMM de refNFP pertence ao grupo de produtor e possui regra própria.

Referência técnica para integração

XPath completo
/nfeProc/NFe/infNFe/ide/NFref/refNF/AAMM
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
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.

pattern
[0-9]{2}[0]{1}[1-9]{1}|[0-9]{2}[1]{1}[0-2]{1}
whiteSpace
preserve