Voltar para o blog

NF-e

Rejeição 1205: recupere a chave anterior com a UF verdadeira

Se uma NF-e de operação com ente governamental retorna o código 1205, a primeira conferência é a chave do documento fiscal anterior que foi referenciada. A mensagem aponta uma UF inválida dentro dessa chave. Não é uma instrução para mudar o endereço do cliente, o local de entrega ou o estado da própria empresa.

Blog ALRA
Capa ilustrada da ALRA: Rejeição 1205: recupere a chave anterior com a UF verdadeira.

Se uma NF-e de operação com ente governamental retorna o código 1205, a primeira conferência é a chave do documento fiscal anterior que foi referenciada. A mensagem aponta uma UF inválida dentro dessa chave. Não é uma instrução para mudar o endereço do cliente, o local de entrega ou o estado da própria empresa.

O texto documentado é: “Rejeição: DFe referenciado em operação com ente governamental com UF inválida [nOcor:nnn]”. Guarde o retorno completo e o XML transmitido. Depois, localize a referência mencionada e compare com o documento de origem. Uma correção baseada apenas na sigla de estado exibida na tela pode atingir o dado errado.

O contexto específico do 1205

A BB05-80, na página 34 da NT 2025.002-RTC v1.52, se aplica à autorização da NF-e modelo 55. Quando a nota informa chave do documento fiscal anterior em gCompraGov/refDFeAnt, a regra examina cada chave referenciada e prevê o 1205 se ela contiver UF inválida. A coluna Modelo não inclui NFC-e 65. [1]

A regra não exige que o estado da nota anterior seja igual ao estado da nota atual ou ao do órgão comprador. Sua condição é a invalidade da UF na chave referenciada. Portanto, não transforme uma operação entre estados em erro automático. A relação fiscal entre os documentos precisa ser verdadeira, mas essa análise é diferente da validação estrutural descrita aqui.

Não confunda os grupos de referência do XML. O responsável fiscal deve confirmar a etapa do fornecimento ou pagamento e o documento anterior pertinente. Uma chave correta em grupo inadequado ainda demanda revisão do enquadramento.

Qual informação da chave representa a UF

Na composição descrita pelo MOC 7.0, os dois primeiros caracteres da chave representam o código da UF do emitente do documento fiscal. É um código numérico da tabela do IBGE, não a sigla do estado nem um código de município. A tabela oficial relaciona, por exemplo, 35 a São Paulo e 31 a Minas Gerais. [2]

Quando se trata de uma referência, estamos lendo a chave do documento anterior. O estado do comprador ou o ambiente autorizador usado pela nota atual não deve ser inserido nessas posições por conveniência. O identificador anterior precisa permanecer o que foi efetivamente emitido e autorizado.

Um código de UF válido não prova a identidade do documento. Confirme a chave completa e seu vínculo com a compra; não substitua o início por qualquer valor da tabela.

Roteiro para encontrar a origem da divergência

Reúna o XML da nota rejeitada, o retorno, o XML autorizado do documento anterior e o registro da operação no emissor. Localize os valores de refDFeAnt no arquivo efetivamente enviado. Quando houver mais de uma referência, use a ocorrência indicada como ponto inicial e confira também as demais. Não presuma a correspondência entre a numeração do retorno e a ordem de uma tela sem verificá-la.

Compare a chave transmitida com a original, incluindo tamanho e todas as posições. Depois confira se o cadastro mostra a mesma informação. Esse caminho separa erro de transcrição de falha na montagem do arquivo. Também permite verificar se o sistema utilizou uma referência diferente da selecionada pelo operador.

Registre UF do estabelecimento, autorizador, ambiente e versão do emissor. A regra no PDF não comprova a versão executada pelo ambiente que respondeu.

Como corrigir em cada cenário

A cópia ou importação alterou a chave. Recupere a sequência integral do XML autorizado anterior e corrija a associação na origem, sem editar apenas o início. Se o arquivo intermediário perdeu posições ou precisão, a formatação não recupera o conteúdo: volte ao original. São hipóteses de diagnóstico; não se presume qual rejeição será devolvida primeiro pelo autorizador.

Uma integração tentou remontar a chave. Investigue se ela usou sigla de estado, código interno, UF do comprador ou um valor zerado. O ajuste é preservar a chave real do documento anterior, extraída conforme o leiaute, e corrigir a rotina que substituiu suas posições. Não altere o endereço do órgão público para combinar com a sequência gerada.

A referência veio de outra operação. Mesmo uma chave sem erro estrutural precisa corresponder ao documento que deve ser relacionado. Reconcilie contrato, fornecimento, pagamento e histórico fiscal com a contabilidade. Escolher qualquer nota anterior com uma UF válida pode eliminar um problema de formato e criar um vínculo fiscal falso. A decisão de substituir ou retirar a referência deve resultar da identificação do documento correto.

A original coincide com o XML enviado. Confira todas as ocorrências e a correspondência entre retorno e tentativa. Persistindo a divergência, peça análise ao suporte e, quando necessário, ao autorizador competente. Preserve as evidências; testes sucessivos mudando UF dificultam o diagnóstico e não recuperam a identidade do documento.

Exemplo original

Uma fornecedora fictícia de equipamentos atende uma prefeitura mineira, mas o documento anterior foi emitido por seu estabelecimento paulista. A integração cria a referência com um código interno de estado que não pertence à tabela oficial. A transmissão recebe 1205.

A equipe recupera a NF-e anterior e confirma que a chave original começa com 35, código de São Paulo. Ela corrige o transporte da chave completa entre os sistemas e preserva o destinatário mineiro e os demais fatos da operação. O início 35 não é escolhido porque parece adequado: ele vem do documento verdadeiro. Não se apresenta aqui uma chave fiscal completa nem uma emissão testada; o exemplo mostra por que UF do documento anterior e endereço do comprador são informações distintas.

Como confirmar a solução

Confira a igualdade integral entre a referência do novo XML e o identificador do documento anterior correto. Verifique o vínculo com a etapa da compra governamental e leia o novo retorno. A validade completa e a situação do documento exigem outras conferências; deixar de receber 1205 não significa autorização automática.

Quando houver resultado de autorização correspondente à nota atual, preserve seu XML e protocolo. Se surgir outra rejeição, trate o contexto específico. Acione o suporte para divergências de integração ou geração. Procure o responsável fiscal quando não estiver claro qual documento relacionar ou se o grupo de compra governamental é cabível na operação. Não altere dados verdadeiros de endereço ou tributação para satisfazer uma validação da referência.

Versão e calendário da regra

A base é a v1.52 capturada em 10/10/2026, listada na SVRS como publicada em 01/10. A inclusão da BB05-80 na v1.40, página 5, prevê homologação até 01/07/2026 e produção em 03/08/2026. [1]

O aviso ENCAT de 05/10, na listagem salva, posterga as implantações enumeradas da v1.52 para 26/10 e 16/11. Não comprova suspensão genérica das regras herdadas. A releitura local de 13/10 não atualizou a norma ou demonstrou execução por UF, autorizador e ambiente. [3]

A página 6 distingue validações específicas dos campos IBS/CBS/IS e validade jurídica conforme legislação. Não orienta omitir tributos ou alterar fatos para evitar controles. O MOC é histórico e não foi tratado como atualização integral do leiaute.

Fontes e limites

Elaboração v2 por IA em 13/10/2026, baseada somente nos materiais salvos. Própria e cruzada dos novos hashes pendentes; nenhuma aprovação nesta elaboração.

  1. NT 2025.002-RTC v1.52, páginas 5–6, 17 e 34: BB05-80, condição, modelo e cronograma.

  2. MOC 7.0, Visão Geral, PDF salvo da SVRS, tabela 2-1, página 19, e tabela 8-1, página 129: composição numérica da chave e códigos de UF. Não certifica a antiga abertura CONFAZ ou atualização integral do manual.

  3. Listagem de avisos SVRS e Documentos SVRS: capturas de 10/10, sem nova consulta online ou implantação uniforme comprovada.

  4. TecnoSpeed, panorama da NT: corpo salvo como apoio adjacente, sem guia específico 1205 ou comprovação de recursos ALRA.

NS7 e TaxUp foram retirados dos apoios ativos: seus corpos e atos individuais declarados na v1 não foram recuperados nos caminhos examinados. Os registros anteriores e a negativa permanecem preservados e inativos na fundamentação da v2. Não se afirma ausência universal de outros guias nem confirmação retrospectiva dessas páginas. Sem HTTP novo, emissão, teste XSD, direito fiscal individual ou certificação humana.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.