refNFP na NF-e: identificar a nota de produtor e conferir a referência
<refNFP>ide › NFref › refNFPRevisão editorial em 27 de set. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.
refNFP reúne os dados que identificam uma nota fiscal de produtor referenciada pela NF-e. Em vez de uma chave de acesso, o grupo informa UF, mês e ano, CNPJ ou CPF, inscrição estadual, modelo, série e número do documento original. Esses dados pertencem à nota referenciada; não devem ser copiados automaticamente do emitente, da data ou do número da NF-e que está sendo preparada.
Há uma mudança de aceitação relevante: a NT 2026.002 v1.10a programa para 05/10/2026, em produção, a rejeição 682 quando existir refNFP. No corte desta página, 26/09/2026, essa data ainda é futura. A estrutura explica documentos e XML anteriores, mas sua presença no XSD não garante que o autorizador aceite o grupo na data de emissão. Veja o cronograma.
O documento que o grupo descreve
O caminho completo é:
/nfeProc/NFe/infNFe/ide/NFref/refNFP
Dentro de cada ocorrência de NFref, o XML escolhe um tipo de referência. No caso de refNFP, o MOC descreve a informação da nota fiscal de produtor. O schema admite mod=01 ou mod=04; a descrição de leiaute associa 01 à nota fiscal avulsa e 04 à nota fiscal de produtor. Essa indicação identifica o documento original e não altera o modelo da NF-e atual. MOC, BA10–BA18 Schema, refNFP
Uma NF-e emitida por produtor rural continua sendo uma NF-e. A condição do emitente não transforma sua chave de acesso em sete campos de papel. Se o documento original é eletrônico, confira o tipo de referência previsto para ele, como refNFe, e as condições da operação. Não selecione refNFP apenas porque o fornecedor é produtor.
A fonte dos dados é o documento original, apoiado pelo cadastro oficial quando for necessário conferir o emitente. Um DANFE da NF-e atual, o cadastro comercial do destinatário ou a data de digitação não substituem a identidade da nota referenciada. Se o original não está disponível, a conferência fica incompleta: não há base para inventar série, número, IE ou período.
CNPJ ou CPF: uma identidade por referência
O XSD usa uma escolha entre CNPJ e CPF. É necessário informar um dos dois, na posição prevista do grupo. Não se deve incluir os dois para “completar o cadastro”, nem deixar ambos ausentes. Schema, escolha de identificação
Use o identificador do emitente da nota original. CNPJ de outro estabelecimento, CPF do responsável por uma pessoa jurídica ou CNPJ do destinatário não são substitutos técnicos dessa identificação.
O CNPJ tem 14 caracteres no schema atualizado, com posições alfanuméricas admitidas nas 12 primeiras e dígitos verificadores nas duas últimas. O CPF tem 11 dígitos. Máscaras com ponto, barra ou hífen são apresentação visual, não conteúdo dessas tags. A NT 2026.004 atualiza expressamente a descrição do CNPJ de refNFP para 14 caracteres. Tipos básicos NT 2026.004
As páginas de CNPJ em refNFP e CPF em refNFP detalham essas diferenças. Neste grupo, a escolha documental vem antes da validação do formato.
Conferência do grupo campo a campo
| Campo | O que conferir no original | Limite técnico da estrutura |
|---|---|---|
cUF |
UF do emitente da nota referenciada | Código IBGE de UF com dois dígitos, dentre os códigos admitidos |
AAMM |
Ano e mês de emissão da nota referenciada | Quatro dígitos: dois do ano, dois do mês |
CNPJ ou CPF |
Identificação do emitente da nota | Uma alternativa; CNPJ com 14 caracteres ou CPF com 11 dígitos |
IE |
Inscrição estadual registrada no documento e sua relação com o emitente | Tipo TIeDest: literal ISENTO ou de 2 a 14 dígitos |
mod |
Modelo do documento original | 01 ou 04 |
serie |
Série do documento original | 0 ou inteiro de 1 a 999, sem zeros iniciais no inteiro positivo |
nNF |
Número da nota referenciada | Inteiro de 1 a 999999999, sem zeros iniciais |
A tabela descreve as facetas do XSD e a origem de cada dado. Uma cadeia que cabe no tipo não prova que exista uma inscrição, que ela pertença ao produtor ou que o documento seja aceito em determinada operação. Leiaute e tipos básicos Tipos básicos
IE é obrigatória na estrutura. Embora exista uma anotação textual sobre conteúdo vazio no arquivo de tipos, o padrão efetivo de TIeDest não admite uma cadeia vazia. O literal ISENTO aceito no tipo tampouco é autorização para classificar o produtor como isento: essa condição precisa de fundamento no documento e nas regras aplicáveis.
Este recorte sintético e parcial mostra a ordem dos elementos e a escolha por CPF:
<refNFP>
<cUF>35</cUF>
<AAMM>2508</AAMM>
<CPF>52998224725</CPF>
<IE>ISENTO</IE>
<mod>04</mod>
<serie>0</serie>
<nNF>1234</nNF>
</refNFP>
Aqui, 35 representa São Paulo, 2508 representa agosto de 2025, 04 é o modelo indicado e 1234 é o número da nota hipotética. O literal ISENTO serve somente para mostrar uma alternativa lexical do tipo: o exemplo não comprova isenção, cadastro ou autorização. Não é um XML completo nem uma orientação para emissão.
Se o documento original identificar o produtor por CNPJ, a alternativa CNPJ ocupa o lugar de CPF; os dois elementos não coexistem nessa ocorrência. Não altere a identificação apenas para fazer o exemplo ou um validador passar.
Contranota: as condições fazem parte da regra
A palavra “produtor” não basta para concluir que toda movimentação exige a mesma referência. O MOC apresenta regras específicas para NF-e de entrada identificada como contranota, com tpNF=0 e remetente da mesma UF identificado como produtor. Sua aplicação é facultativa, conforme a UF. As demais condições e o confronto com o documento original precisam ser considerados. MOC, BA10-20/30/40/50
| Regra | Redação do MOC anterior à alteração | Ajuste programado pela NT 2026.002 |
|---|---|---|
| BA10-20, rejeição 318 | Ausência de refNFP e de refNFe na contranota definida pela regra |
Passa a verificar a ausência de refNFe; a alternativa refNFP foi riscada |
| BA10-30, rejeição 319 | Exige referência correspondente à saída nas alternativas indicadas | A verificação fica direcionada à NF-e referenciada de saída |
| BA10-40, rejeição 320 | Compara a IE da nota referenciada com a IE do emitente ou do destinatário | Mantém a comparação para a NF-e referenciada; o trecho de refNFP foi riscado |
| BA10-50, rejeição 922 | Limita a referência a refNFe ou refNFP com modelo 04 |
Passa a admitir somente refNFe nessa condição |
Na redação nova, a observação de identificação da contranota explicita também a finalidade normal, finNFe=1, além de entrada, tpNF=0, e remetente da mesma UF com IE de produtor rural. Essa condição integra o conjunto programado para outubro; não deve ser omitida ao analisar a regra nova. NT 2026.002, p. 10
Na BA10-40, a observação permite à UF adotar o confronto dos oito primeiros caracteres do CNPJ no lugar da IE. Isso é uma condição de aplicação da regra, não uma licença para o emissor escolher qual comparação lhe convém. MOC NT 2026.002, pp. 9 e 10
Para diagnosticar, reúna o documento de origem, a finalidade da NF-e, o tipo de movimento, as UFs, a identificação estadual do remetente e a regra devolvida pelo autorizador. A confirmação de que a operação é uma contranota, ou de que exige determinado tratamento fiscal, depende de quem responde por esse enquadramento.
A mudança de 05/10/2026
Na redação anterior do MOC, BA10-10 tratava da duplicidade de nota de produtor referenciada, pela combinação IE, modelo, série e número, com rejeição 682 facultativa. A NT 2026.002 substitui esse critério por “informado refNFP”, com aplicação obrigatória para o modelo 55. A mesma nota técnica ajusta as regras de contranota e exclui regras específicas de data, CNPJ, CPF e IE do grupo. NT 2026.002
O cronograma da versão 1.10a informa:
- 01/09/2026: implantação dessas alterações em teste.
- 05/10/2026: implantação em produção.
- 26/09/2026: corte desta página, anterior à data de produção prevista.
Por isso, uma rejeição 682 em homologação pode corresponder à proibição nova, enquanto um XML histórico pode ter sido analisado pelo critério antigo de duplicidade. Leia a regra, o ambiente e a data juntos. Não remova a referência nem a converta para uma chave inventada: primeiro confirme qual documento existe e qual relação documental é exigida.
Além dessa mudança, NFref não é permitido na NFC-e modelo 65 nem na NF-e com DANFE Simplificado Tipo 2, tpImp=6, pela BA01-10. A extensão ao Tipo 2 tem cronograma próprio, já com produção em 03/08/2026. NT 2026.002, pp. 3 e 9
Como investigar uma referência recusada
Separe três verificações:
- Estrutura: todos os elementos existem na ordem certa? Há exatamente uma identificação, CNPJ ou CPF? O XML usa os formatos definidos?
- Regra de autorização: qual código, regra, ambiente e data foram retornados? A análise usou a redação antiga ou a alteração com produção prevista para 05/10?
- Cadastro e identidade: a inscrição existe e está vinculada ao identificador informado, quando essa consulta for aplicável?
O MOC prevê a rejeição facultativa 688, por IE de produtor inexistente, e 689, por IE não vinculada ao CNPJ/CPF. As regras 3BA15-10/20 consultam o cadastro da SEFAZ quando a nota de produtor referenciada é da própria UF. Não é correto extrapolar essa consulta a qualquer UF, nem tratá-la como consequência automática de um número com formato válido. MOC, p. 136
Na leitura de retornos anteriores, também existem verificações do período, de CNPJ, CPF e IE pelas regras BA12-10 a BA15-10. A NT 2026.002 as exclui no conjunto de mudanças indicado para outubro. Uma mensagem histórica não pode ser interpretada apenas pelo número de uma regra atualizada.
A conferência técnica termina quando a identidade do original, o formato e a condição da regra estão esclarecidos. Ela não decide CFOP, obrigatoriedade de contranota, incidência ou isenção. Essas decisões precisam do contexto da operação e da confirmação do responsável fiscal.
Para navegar: NFref e as alternativas de referência · AAMM da nota de produtor · CNPJ da nota de produtor · CPF da nota de produtor.
Referência técnica para integração
- XPath completo
/nfeProc/NFe/infNFe/ide/NFref/refNFP- 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.