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.
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.
NT 2025.002-RTC v1.52, páginas 5–6, 17 e 34: BB05-80, condição, modelo e cronograma.
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.
Listagem de avisos SVRS e Documentos SVRS: capturas de 10/10, sem nova consulta online ou implantação uniforme comprovada.
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.