Rejeição 1199: confira a referência no recebimento antecipado de compra governamental

Se a NF-e de uma compra governamental voltou com a rejeição 1199, confira qual momento da operação está sendo documentado. O XML informa recebimento do pagamento antes do fornecimento, mas também traz uma chave de documento anterior em um campo que não deve existir nesse cenário. A correção começa pelo contrato, pelo recebimento e pela entrega efetivamente ocorridos.

A mensagem exata é: “Rejeição: Referenciado indevidamente DFe anterior em operação com ente governamental na operação de recebimento do pagamento com fornecimento posterior”. Ela não declara que o contrato ou o pagamento são inválidos. Identifica uma incompatibilidade entre o tipo da operação e a referência enviada.

Onde a regra se aplica

A BB05-50 da NT 2025.002-RTC v1.52, página 33, trata da autorização da NF-e modelo 55. O teste combina ide/gCompraGov/tpOperGov=4 com a presença indevida de gCompraGov/refDFeAnt, chave do documento fiscal anterior. Não se aplica automaticamente à NFC-e modelo 65, a uma NFS-e ou ao recebimento de eventos.

O grupo de compras governamentais identifica informações próprias dessas operações. Seu tipo não é um código livre escolhido para atender à validação. Os quatro valores documentados representam momentos distintos: fornecimento com pagamento posterior (1), recebimento com fornecimento já realizado (2), fornecimento com pagamento já realizado (3) e recebimento com fornecimento posterior (4). A empresa precisa identificar qual deles descreve o fato, com o responsável fiscal.

Há outras formas de referenciar documentos na NF-e. A regra 1199 olha especificamente refDFeAnt dentro de gCompraGov. Não significa que toda referência de cabeçalho ou de item deva ser apagada. Essas referências possuem condições próprias e podem ser necessárias em outros contextos.

Vigência: cuidado com o prazo da versão mais recente

Na consulta de 10/10/2026, o documento de referência é a v1.52. Seu quadro de histórico, página 5, inclui a BB05-50 no conjunto criado pela v1.40, com homologação até 01/07/2026 e produção em 03/08/2026. O aviso ENCAT de 05/10/2026 adiou a implantação anunciada para a v1.52 para 26/10 em homologação e 16/11/2026 em produção. Esse aviso não transfere automaticamente a BB05-50 para novembro: ela pertence ao conjunto anterior.

O calendário documental também não comprova sozinho a execução da regra em cada UF e autorizador. Registre a UF do emitente, o serviço que respondeu, o ambiente de homologação ou produção, o horário e a versão do emissor. Uma rejeição efetivamente recebida é evidência daquele envio; uma simulação local ou um artigo sobre o cronograma não demonstra a mesma coisa.

O que guardar antes de alterar a nota

Preserve o XML rejeitado e a resposta completa. Separe o comprovante de recebimento, a documentação da compra e os registros da entrega. Confira no arquivo transmitido o modelo, a finalidade, o tipo da operação governamental e a referência anterior. Uma tela correta pode coexistir com XML gerado a partir de uma configuração antiga.

Identifique também de onde veio a chave. Foi digitada, copiada de outra nota, importada pela integração ou mantida ao duplicar um documento? Essa investigação distingue um dado indevido do cadastro de um problema recorrente no gerador. A numeração da chave, isoladamente, não explica por que ela foi usada.

Como corrigir por cenário

Houve recebimento antes do fornecimento e o tipo 4 está correto

Depois de confirmar esse fato com a equipe fiscal, retire a referência indevida desse campo no documento rejeitado, pelo fluxo do emissor. Refaça o XML e a assinatura quando seu conteúdo mudar. Não edite manualmente o arquivo assinado nem reutilize sua assinatura sobre conteúdo diferente.

Se a referência veio de um modelo de emissão, corrija a configuração que a inclui automaticamente. Caso contrário, a mesma incompatibilidade pode reaparecer nos próximos documentos. Preserve o vínculo administrativo com o contrato e com os comprovantes nos registros apropriados; a ausência de refDFeAnt nesse XML não elimina a necessidade de rastrear a operação.

O fornecimento já aconteceu e o tipo 4 foi selecionado por engano

Suspenda a correção automática. Levante a sequência real de fornecimento e recebimento e peça ao responsável fiscal para definir o enquadramento correto. Não basta trocar o indicador de 4 para outro número.

Se o cenário confirmado for tipo 2, a BB05-20 exige documento anterior e a BB05-30 restringe a quantidade a uma chave. Se for tipo 3, a BB05-40 também exige referência, com verificações adicionais do documento anterior. Essas regras explicam por que apagar a chave indiscriminadamente pode criar outro erro sem resolver o fato fiscal.

O cadastro parece correto, mas a integração inclui a referência

Compare o XML com a tela, o pedido e os parâmetros do integrador. Peça ao suporte a origem de refDFeAnt e a condição usada para gerar o campo. O ajuste deve impedir sua inclusão indevida quando tpOperGov=4, preservando as referências exigidas nos demais tipos. Uma alteração global que retire todas as referências pode prejudicar outras emissões.

A resposta parece incompatível com o XML preservado

Confira se o arquivo analisado é o realmente transmitido, no mesmo ambiente e horário. Compare a resposta da SEFAZ com a mensagem interna do sistema. Se não houver tipo 4 e referência anterior juntos no envio, o suporte precisa investigar a associação entre documento, retorno e tentativa antes de qualquer alteração fiscal.

Exemplo hipotético

Uma empresa fictícia recebe antecipadamente R$ 8.400 de um órgão público para fornecer materiais depois. O responsável fiscal confirma o cenário tipo 4. Ao preparar a NF-e, o operador duplica uma configuração antiga que traz a chave de uma entrega anterior. O XML enviado recebe 1199.

A equipe compara recebimento e contrato, confirma que aquela chave não pertence ao campo desta etapa e a retira de gCompraGov/refDFeAnt. O suporte corrige a origem automática do dado. A empresa gera novamente o documento rejeitado e examina a nova resposta. O exemplo não define a tributação nem garante autorização: mostra como corrigir a incompatibilidade identificada sem alterar pagamento ou entrega reais.

Como verificar o resultado e quando escalar

Confira o XML final e a nova resposta oficial. O desaparecimento do 1199 pode revelar outra validação; não é sinônimo de autorização. Só registre o documento como autorizado com o retorno correspondente e o protocolo vinculado à chave correta. Guarde os arquivos e confira se os registros internos refletem a operação confirmada.

Acione a contabilidade quando houver dúvida sobre o momento fiscal, finalidade, classificação ou documentos já emitidos. Acione o suporte quando o campo reaparecer, houver diferença entre tela e XML ou faltar rastreabilidade do retorno. Encaminhe à SEFAZ, pelos canais da UF, divergência persistente documentada. Não repita envios sem corrigir a causa demonstrada.

Fontes

Consulta e revisão documental por IA: 10/10/2026. Sem teste de emissão por UF/autorizador/ambiente.

• NT 2025.002-RTC v1.52, páginas 5–6, 17 e 33–35; BB05-50 e regras próximas.

• Lista de documentos da SVRS e aviso ENCAT de 05/10/2026.

• Buscador NCM, registro específico 1199: confirmação complementar de mensagem, sem prova operacional.

• NS7, lista de rejeições: registro específico da mensagem, sem roteiro completo de correção.

• CIGAM, configuração da Reforma Tributária: apoio adjacente sobre tipos de operação e geração da referência; instruções de interface são próprias daquele produto.

Limite da pesquisa prática: registros específicos e orientações adjacentes têm alcances distintos. Não foram confirmados três guias independentes com diagnóstico completo do código 1199. A condição técnica e o cronograma foram fundamentados no documento oficial e em seu aviso posterior.