Rejeição 1195: referência indevida no fornecimento ao governo com pagamento posterior

Se sua empresa forneceu mercadorias a um órgão público e receberá depois, a rejeição 1195 pede uma conferência do vínculo com documentos anteriores. Nesse estágio, a informação de uma chave anterior no grupo de compras governamentais contraria a regra. Antes de remover qualquer campo, confirme se a nota realmente representa o fornecimento com pagamento posterior. Essa decisão depende da operação realizada, não do resultado que se deseja obter na transmissão.

Guarde o XML enviado e a resposta completa. A mensagem indica um problema específico de preenchimento; ela não determina que a venda foi cancelada, que o governo pagou ou que a empresa perdeu o contrato. Também não justifica emitir outra nota sem examinar o documento que recebeu o retorno.

Qual mensagem e qual documento estão envolvidos

A mensagem documental é “Rejeição: Referenciado indevidamente DFe anterior em operação com ente governamental na operação de fornecimento com pagamento posterior”. O código é 1195, vinculado à regra BB05-10 da NT 2025.002-RTC v1.52, página 33. O serviço é autorização de NF-e modelo 55. A condição é tpOperGov=1, com informação indevida de gCompraGov/refDFeAnt.

tpOperGov identifica a etapa da operação governamental. refDFeAnt identifica a chave de acesso de um documento fiscal anterior dentro desse grupo. Essa referência não equivale ao número de empenho, à identificação do contrato ou ao comprovante bancário. Acrescentar qualquer desses números no campo não transforma o dado em uma chave fiscal válida.

Este diagnóstico não se estende à NFC-e modelo 65. A própria NT possui outra validação para o grupo governamental na NFC-e. Tampouco se aplica automaticamente a um código parecido recebido em outro documento eletrônico ou serviço.

O calendário precisa ser interpretado por regra

A revisão documental foi realizada em 10/10/2026. A listagem oficial da SVRS mantém a v1.52, publicada em 01/10/2026. O histórico da página 5 situa a inclusão da BB05-10 na v1.40, com previsão de homologação até 01/07/2026 e produção em 03/08/2026. O bloco da regra na página 33 não informa implementação futura nem exceção estadual.

O aviso ENCAT de 05/10/2026 posterga as implantações da v1.52 citadas no comunicado para 26/10 em homologação e 16/11 em produção. Não se conclui daí que a BB05-10 herdada da v1.40 foi suspensa. Datas documentais também não comprovam a ativação em toda UF. Registre o autorizador utilizado e o ambiente efetivo do envio. Não houve emissão de teste nesta revisão.

Por que uma referência aparece onde não deveria

Uma hipótese é a cópia de uma nota de outra etapa do contrato. O modelo anterior podia representar um recebimento após o fornecimento e conter a referência pertinente àquele estágio. Ao reaproveitá-lo, o sistema ou o operador pode conservar a chave mesmo depois de selecionar fornecimento com pagamento posterior.

Outra hipótese é uma integração que inclui referências em toda operação governamental, sem distinguir as etapas. Há ainda o caso em que o tipo da operação foi selecionado incorretamente: o XML diz que o pagamento ocorrerá depois, mas os documentos da empresa demonstram que ele já ocorreu. Essas hipóteses orientam a investigação; o código sozinho não confirma nenhuma delas.

Como conferir sem perder o histórico

1. Identifique a NF-e pelo emitente, série, número, chave e ambiente. Compare o retorno ao XML efetivamente transmitido, não apenas à prévia exibida na tela.

2. Reúna pedido, contrato, documentos de entrega e informações do financeiro. Estabeleça se houve fornecimento e se o pagamento já ocorreu.

3. Peça ao responsável fiscal que confirme a etapa documentada. Confira tpOperGov e a existência de refDFeAnt dentro de gCompraGov.

4. Identifique a origem de cada chave adicionada: digitação, cópia, pedido importado ou integração. Preserve essa evidência para corrigir também a origem do preenchimento.

A referência pode estar visível em outra área do sistema e acabar serializada no lugar errado. O suporte deve conferir o caminho completo no XML. Procurar apenas uma sequência de 44 caracteres em todo o arquivo não resolve a diferença entre grupos.

Correção conforme a operação real

Fornecimento realizado, pagamento posterior confirmado. Mantido o enquadramento correto em tpOperGov=1, retire a referência indevida desse grupo na geração do documento, com acompanhamento fiscal. Não elimine os arquivos da operação anterior nem apague referências de outros grupos por aproximação. Gere novamente o XML a partir do registro corrigido e confira que o emissor não recolocou a chave.

Etapa governamental selecionada incorretamente. Corrija a classificação somente após confrontar entrega e pagamento com os documentos. Outros tipos têm exigências próprias de referência. Trocar o tipo para fazer a chave ser aceita, sem correspondência com os fatos, pode esconder o primeiro erro e produzir informação fiscal incorreta.

XML diferente do cadastro revisado. Encaminhe ao suporte a comparação entre o registro e o arquivo transmitido. A correção pode estar no mapeamento ou na rotina de reaproveitamento. Evite edição manual do XML já assinado: a correção deve resultar em documento novamente gerado, validado e assinado pelo fluxo autorizado do emissor.

Exemplo original

Uma distribuidora entrega cadeiras a uma prefeitura, com recebimento previsto para o mês seguinte. Para preparar a NF-e, utiliza um registro copiado de outra operação governamental. A cópia conserva uma chave em refDFeAnt, embora a nova nota esteja classificada com tpOperGov=1.

Depois do retorno 1195, a equipe confirma a entrega e a ausência do pagamento. O fiscal mantém a etapa correta e o suporte remove o vínculo herdado na origem. A empresa preserva a nota antiga em seu arquivo, gera o novo XML e confere que a referência indevida desapareceu somente do grupo governamental da nova emissão.

Verificação do resultado e atendimento

Faça uma nova tentativa controlada e leia o resultado final do serviço. O desaparecimento de 1195 confirma apenas que esse impedimento deixou de ser retornado; outra validação pode aparecer. A conclusão da emissão exige situação de autorização confirmada, XML correspondente e protocolo preservado.

Escale ao contador quando entrega, recebimento ou enquadramento estiverem incertos. Acione o suporte quando a chave voltar após a correção ou quando o arquivo transmitido divergir do cadastro. Envie XML, retorno, horários, versão do emissor, ambiente e descrição da etapa comprovada. Preserve dados e evite tentativas repetidas enquanto a causa permanece.

A página 6 da NT delimita as validações específicas de IBS/CBS/IS aos documentos que contenham seus campos. Essa condição técnica não dispensa obrigações legais nem orienta retirar tributos para evitar o controle. A análise do vínculo deve permanecer compatível com a operação e com a versão do autorizador.

Fontes e limites

• NT 2025.002-RTC v1.52, BB05-10, p.33; histórico e cronograma, p.5–6.

• Listagem oficial de documentos SVRS, consulta em 10/10/2026.

• Aviso ENCAT de 05/10/2026, consultado em 10/10/2026; não transfere automaticamente o adiamento à regra herdada.

• CIGAM, adequações à reforma tributária e TecnoSpeed, evolução da NT: apoio adjacente, sem comprovar funcionalidades do ALRA. A pesquisa não confirmou três publicadores independentes com solução específica e atual para 1195.

Revisão documental por IA, sem teste de emissão por UF ou certificação fiscal humana.