NF-e
Rejeição 1209: confira o modelo da nota anterior na compra governamental
Se sua empresa está documentando uma operação com ente governamental e recebeu a rejeição 1209, confira qual documento foi escolhido como referência. O problema está no modelo contido na chave da nota anterior informada no grupo da compra governamental. Uma chave de outro tipo de documento pode ter sido vinculada ao…
Se sua empresa está documentando uma operação com ente governamental e recebeu a rejeição 1209, confira qual documento foi escolhido como referência. O problema está no modelo contido na chave da nota anterior informada no grupo da compra governamental. Uma chave de outro tipo de documento pode ter sido vinculada ao processo por engano. A correção começa pela identificação da operação e do arquivo original, antes de transmitir novamente.
A mensagem documentada é: “Rejeição: DFe referenciado em operação com ente governamental com Modelo inválido [nOcor:nnn]”. O marcador nOcor aponta a ocorrência da referência indicada na resposta. Quando houver várias chaves, preserve a lista e localize a ocorrência correspondente; não suponha que o primeiro documento exibido na tela foi o rejeitado.
O que a SEFAZ confere
A regra BB05-120, na NT 2025.002-RTC v1.52, página 34, se aplica à autorização de NF-e, modelo 55. Quando gCompraGov/refDFeAnt é informado, verifica cada chave referenciada: o modelo do documento anterior precisa ser 55. Uma NFC-e modelo 65 não satisfaz essa condição, mesmo que pertença à empresa ou tenha sido emitida para o mesmo cliente.
Esse é o modelo da referência, além do modelo da nota atual. A abrangência geral da NT sobre NF-e e NFC-e não torna esta regra aplicável ao modelo 65. Também não se trata de referência por item nem de uma chave colocada apenas nas informações complementares. Identifique o campo que efetivamente entrou no XML enviado.
O grupo foi ampliado na v1.40. Seu cronograma documental previa homologação até 01/07/2026 e produção em 03/08/2026. Na consulta de 10/10/2026, a lista oficial continuava apresentando a v1.52. O aviso de 05/10 adiou mudanças dessa versão para 26/10 em homologação e 16/11 em produção; não demonstra suspensão desta regra herdada. A tabela a classifica como obrigatória, mas não comprova sua execução em toda UF. Registre autorizador, UF, ambiente e versão do emissor no caso concreto.
Onde costuma nascer a divergência
O erro pode começar na seleção de documentos: um operador escolheu um cupom da venda no lugar da NF-e anterior do processo governamental. Outra possibilidade é a integração trazer uma chave de uma pasta com diferentes modelos. Um cadastro que mostra apenas número e valor facilita a confusão, porque documentos de modelos distintos podem ter números iguais.
Há ainda a falha de leitura. Uma captura de tela, um PDF com baixa qualidade ou um código de barras interpretado incorretamente pode gerar uma sequência diferente da chave original. Nesses casos, não basta olhar o nome do arquivo. O XML do documento anterior e sua consulta oficial precisam confirmar sua identidade.
Faça a conferência em duas etapas
Primeiro, reúna o XML rejeitado, a resposta completa e os documentos que sustentam o vínculo: fornecimento, contrato, recebimento ou outra etapa pertinente. Preserve horário, chave atual, ambiente e lista de referências. Compare a ocorrência apontada pelo retorno com o conteúdo de refDFeAnt.
Depois, localize o XML autorizado da referência e confirme seu modelo em ide/mod, sua chave e seu vínculo com a operação. O suporte pode também conferir o segmento do modelo na chave de 44 posições. Essa análise deve usar o documento original; não é uma autorização para editar dois algarismos. A chave identifica um documento e contém outras informações e um dígito verificador.
Não confunda um número de nota, uma chave de NFC-e e uma chave de NF-e. Todos podem estar associados à venda no sistema interno, mas só a referência fiscal compatível com esta regra serve naquele campo.
Como corrigir por cenário
Foi selecionada uma NFC-e ou outro documento
Remova o vínculo incorreto do documento rejeitado e selecione a NF-e anterior que realmente corresponde à etapa da operação, se ela existir e for a referência fiscal cabível. Confira mais que o modelo: emitente, situação, período e relação com o processo também precisam fazer sentido. Outras regras analisam esses pontos.
Se só existe uma NFC-e, não invente uma NF-e anterior nem copie a chave de outro cliente. Encaminhe o conjunto ao responsável fiscal para definir a documentação correta. A regra técnica não estabelece, sozinha, como regularizar toda operação documentada originalmente por outro modelo.
A referência original é NF-e 55, mas o XML enviou outra chave
Investigue a transformação da integração e o vínculo da tela com o arquivo transmitido. Corrija a origem comprovadamente errada e gere novamente o XML pelo emissor, com a assinatura correspondente. Guarde as duas versões para demonstrar qual referência mudou. Não altere manualmente um XML assinado e trate-o como íntegro.
Todos os documentos conferidos são modelo 55
Examine cada ocorrência da lista, inclusive vínculos que a tela resumida não mostra. Se o retorno continuar incompatível com o XML transmitido, o suporte deve analisar o log do envio e o resultado recebido do autorizador. Preserve evidências antes de concluir que há falha da SEFAZ.
Exemplo hipotético
Uma distribuidora forneceu materiais para uma prefeitura. Ao preparar o documento de uma etapa posterior, o operador buscou a venda pelo valor e vinculou uma chave de NFC-e guardada junto dos comprovantes. A autorização respondeu 1209.
A equipe localizou a ocorrência indicada, comparou o XML anterior e confirmou que o documento selecionado era modelo 65. O processo também continha a NF-e modelo 55 correspondente ao fornecimento. Depois de validar o vínculo com o responsável fiscal, corrigiu a seleção no emissor e regenerou o documento. Não mudou o modelo da chave antiga nem emitiu outra operação apenas para contornar a mensagem.
Como verificar o resultado e quando escalar
Confira no novo XML que a referência selecionada é a NF-e correta e examine a resposta final para a chave atual. O desaparecimento do 1209 pode dar lugar a outra rejeição; não significa autorização. Quando autorizada, preserve XML e protocolo e confira o vínculo interno com o processo governamental.
Acione o suporte se a seleção correta não chegar ao XML, se houver leitura inconsistente da chave ou divergência entre envio e retorno. Procure o responsável fiscal quando faltar o documento anterior cabível ou houver dúvida sobre a etapa documentada. Leve os arquivos originais e os fatos da operação; eles permitem corrigir a causa sem trocar a realidade fiscal pelo dado que passa na validação.
Fontes
Consulta e revisão documental por IA: 10/10/2026. Não houve teste de emissão por UF ou ambiente.
Documentos oficiais SVRS, publicação da v1.52 em 01/10/2026.
BuscadorNCM, página específica 1209, confrontada com a NT; generalizações de ativação por UF não foram adotadas.
TecnoSpeed, panorama da RTC, Tax360, versões da RTC e Papo Fiscal, alterações dos grupos: apoio adjacente, sem três soluções independentes específicas para o 1209.