Rejeição 1211: retire a repetição da referência na compra governamental

Se a NF-e de uma operação com ente governamental recebeu o código 1211, confira a lista de documentos anteriores vinculados a ela. Uma mesma chave foi informada mais de uma vez no grupo da compra governamental. O erro pode estar no cadastro, na seleção feita pelo operador ou na integração que reuniu os vínculos. Identifique a repetição no XML enviado antes de excluir qualquer registro.

A mensagem documentada é “Rejeição: DFe referenciado em operação com ente governamental em duplicidade [nOcor:nnn]”. O trecho nOcor sinaliza a ocorrência da referência apontada pelo retorno. Guarde a resposta integral e a ordem da lista para que o suporte possa localizar o vínculo exato.

Duplicidade de referência e duplicidade de emissão são problemas diferentes

A BB05-140, na NT 2025.002-RTC v1.52, página 34, é uma regra de autorização de NF-e modelo 55. Quando gCompraGov/refDFeAnt contém chaves anteriores, verifica se uma chave se repete. O teste diz respeito à identidade completa da referência, não apenas ao número da nota ou ao valor da operação.

O 1211 não é a rejeição 204 de duplicidade de NF-e transmitida. Não significa que a nota atual já foi autorizada, nem determina cancelamento da nota anterior. Também não comprova que duas linhas financeiras representam duas emissões fiscais. Cada situação deve ser investigada pelos documentos e pelo serviço que devolveu a mensagem.

Não aplique este diagnóstico indistintamente à NFC-e modelo 65 ou ao referenciamento por item. A NT abrange os dois modelos, mas a coluna desta regra indica apenas 55 e seu campo é o grupo de compra governamental. Um mesmo número sem a mesma chave completa não satisfaz, por si só, o conceito de duplicidade da BB05-140.

O contexto documental em 10/10/2026

A criação de refDFeAnt e da BB05-140 consta da v1.40, com previsão de homologação até 01/07/2026 e produção em 03/08/2026. Na consulta atual, a lista oficial SVRS apresentava a v1.52, publicada em 01/10. O aviso de 05/10 passou as mudanças dessa versão para 26/10 em homologação e 16/11 em produção. Esse aviso não permite presumir suspensão de todas as regras anteriores.

Não foi identificado aviso de implementação futura na linha BB05-140 lida. Ainda assim, a pesquisa documental não verificou emissão real por UF ou autorizador. Registre o ambiente que respondeu, a UF e a versão do emissor. A coluna obrigatória do documento sustenta a regra nacional descrita; não é prova de execução operacional uniforme em cada ambiente.

Como a mesma chave entra duas vezes

Uma empresa pode ter dois registros internos relacionados à mesma nota: a venda e o recebimento. Se ambos forem selecionados como se fossem documentos fiscais distintos, o gerador pode repetir a chave. Outro cenário é a importação de um arquivo seguida de inclusão manual da mesma referência.

Na integração, a repetição pode aparecer ao juntar listas de módulos diferentes ou ao repetir o processamento de uma etapa. Uma tela que elimina linhas iguais para apresentação pode esconder o problema existente no XML. Por isso, contar documentos na tela não é suficiente para demonstrar o que foi enviado.

Também há o caso de duas notas diferentes cadastradas com a mesma chave por erro de cópia. Nesse cenário, simplesmente remover uma ocorrência pode esconder a falta do segundo documento verdadeiro. O diagnóstico precisa descobrir se existem dois vínculos da mesma NF-e ou se um cadastro recebeu a identidade fiscal errada.

Confira a lista e os documentos que a sustentam

Preserve o XML rejeitado, a resposta, o horário e os registros da operação. Localize todas as ocorrências de refDFeAnt no grupo da compra governamental. Compare as chaves completas e anote quais posições repetem exatamente o mesmo valor. Não use apenas o final da chave ou o número impresso como critério.

Relacione cada ocorrência ao registro que a gerou: nota, fornecimento, recebimento, importação ou vínculo manual. Em seguida, confronte com os XMLs originais e protocolos das notas anteriores. Essa relação mostra se o problema é uma repetição técnica ou uma seleção fiscal equivocada.

Se houver parcelas ou entregas distintas, peça ao responsável fiscal que confirme quais documentos anteriores realmente correspondem à etapa atual. A existência de duas parcelas não cria duas chaves diferentes para a mesma NF-e. Ao mesmo tempo, notas verdadeiramente distintas não devem ser descartadas apenas porque têm valor ou número parecido.

Correção em cada cenário

A mesma NF-e foi incluída duas vezes

Depois de confirmar a identidade, mantenha o vínculo fiscal cabível e elimine a repetição no documento rejeitado. Corrija o gerador para não inserir novamente a mesma chave na lista. Preserve os registros comerciais e financeiros: retirar a repetição fiscal não significa apagar uma parcela, entrega ou recebimento legítimo do sistema.

Duas notas diferentes receberam a mesma chave no cadastro

Localize o XML autorizado de cada nota e corrija o cadastro cuja identidade foi copiada incorretamente. Refaça a lista com as chaves verdadeiras, apenas se ambos os documentos forem referências cabíveis. Não invente uma chave alternativa nem altere dígitos para tornar os valores diferentes.

A tela mostra uma referência, mas o XML traz duas

Encaminhe a comparação ao suporte. A equipe precisa revisar o caminho de geração e a junção de listas, incluindo reprocessamentos e integrações. A correção deve alcançar o arquivo transmitido. Gere e assine novamente pelo emissor; um XML assinado editado manualmente não é o documento íntegro do fluxo.

Exemplo hipotético

Uma fornecedora de mobiliário registra a entrega a um órgão público e, depois, o recebimento correspondente. A integração busca referências nos dois módulos e encontra a mesma NF-e anterior em ambos. O XML da nova etapa contém a chave duas vezes e recebe 1211.

A equipe compara a lista com o arquivo autorizado e confirma que há uma única NF-e anterior cabível. Ela mantém esse vínculo uma vez e corrige a junção feita pela integração. Os registros de entrega e recebimento continuam preservados; o ajuste foi na lista de referências, sem apagar a história comercial ou produzir uma segunda nota.

Resultado e escalonamento

Confira o novo XML e conte as ocorrências de cada chave no grupo. Leia o retorno correspondente à nota atual: uma nova rejeição exige diagnóstico próprio, e o desaparecimento do 1211 não equivale a autorização. Quando houver autorização, guarde XML e protocolo e confirme a associação correta das notas anteriores no processo.

Acione o suporte quando a repetição voltar depois de corrigida, aparecer apenas no XML ou não tiver origem identificada. Envolva o responsável fiscal se houver dúvida sobre quais documentos deveriam compor o vínculo. Se duas notas já foram efetivamente emitidas para a mesma operação, trate essa situação separadamente com consulta e orientação fiscal; o 1211, isoladamente, não resolve duplicidade de emissão.

Fontes

Consulta e revisão por IA: 10/10/2026; sem teste de emissão por UF ou ambiente.

• NT 2025.002-RTC v1.52, páginas 5–6 e 34, BB05-140.

• Documentos oficiais SVRS e aviso ENCAT de 05/10.

• BuscadorNCM, 1211: consulta específica confrontada com a NT; a instrução genérica de CST não foi adotada para corrigir duplicidade de referência.

• TecnoSpeed, Tax360 e Papo Fiscal: apoio adjacente; não representam três soluções específicas independentes para este código.