Rejeição 1197: mais de uma referência no recebimento após o fornecimento governamental

Se a empresa já forneceu mercadorias a um órgão público e agora documenta o recebimento, a rejeição 1197 indica que há mais de uma chave anterior no grupo governamental. Excluir uma referência ao acaso pode eliminar a mensagem e deixar um vínculo fiscal incompatível com o que aconteceu.

Interrompa as tentativas repetidas e preserve o XML rejeitado. Separe o comprovante do recebimento, os documentos de fornecimento e a identificação do contrato. A análise precisa responder duas perguntas: a etapa governamental está correta e quais antecedentes efetivamente pertencem à operação documentada?

Mensagem, regra e campo conferidos

O retorno documentado é “Rejeição: Referenciado mais de um DFe anterior em operação com ente governamental na operação de recebimento do pagamento com fornecimento já realizado”. O cStat 1197 corresponde à BB05-30, na página 33 da NT 2025.002-RTC v1.52, para autorização de NF-e modelo 55.

A condição exige tpOperGov=2, recebimento do pagamento com fornecimento já realizado, e mais de uma chave de acesso em gCompraGov/refDFeAnt. Trata-se da quantidade de referências dentro desse grupo. Não é a quantidade de itens da nota, de parcelas do contrato nem de comprovantes bancários arquivados pela empresa.

O leiaute permite repetições em outros contextos, mas a regra do tipo 2 limita esse estágio. A aceitação estrutural do XML não garante aceitação do conteúdo: a integração precisa considerar o leiaute e a condição de negócio.

Como o contexto muda o diagnóstico

A ausência da referência no mesmo tipo 2 é tratada pela rejeição 1196. A duplicidade de uma mesma chave também possui validação própria no grupo governamental. Não atribua a 1197 a função de decidir qual chave é correta, de confirmar a autorização do antecedente ou de identificar sozinho um pagamento duplicado.

Este artigo não transfere a regra para NFC-e modelo 65, para eventos nem para outros documentos eletrônicos. O serviço e o modelo do XML enviado precisam ser identificados antes de aplicar a orientação.

Vigência documental na consulta de 10/10/2026

Em 10/10/2026, a SVRS lista a v1.52 como a referência publicada em 01/10. A inclusão da BB05-30 consta no histórico da v1.40, página 5, com previsão de homologação até 01/07/2026 e produção em 03/08/2026. A página 33 não apresenta indicação de implementação futura ou exceção de UF para essa regra.

O aviso ENCAT de 05/10 posterga as implantações citadas da v1.52 para 26/10 em homologação e 16/11 em produção. Isso não suspende automaticamente a BB05-30 de versão anterior. O calendário foi conferido documentalmente, sem emissão de teste em todas as UFs. Preserve o ambiente, o autorizador e a versão do emissor para conferir a aplicação no caso concreto.

Causas que vale investigar

Uma integração pode reunir todos os documentos de um contrato ao montar a nota de recebimento. Se o contrato tem vários fornecimentos, a rotina pode transportar várias chaves sem conferir o limite do estágio informado. Outra hipótese é a seleção simultânea de um vínculo manual e de um vínculo automático.

Há também a cópia de um registro com referências antigas ou a repetição da mesma associação no cadastro. Mesmo quando duas posições contêm a mesma chave, não basta discutir se representam um ou dois documentos na realidade: o suporte deve conferir as ocorrências efetivamente geradas no XML.

São hipóteses: compare os dados preservados e identifique a origem de cada ocorrência antes de corrigir a geração ou a escolha documental.

Passos para localizar o problema

Liste todas as ocorrências de refDFeAnt dentro de gCompraGov, mantendo a ordem do XML. Ao lado de cada chave, identifique o arquivo fiscal correspondente, sua situação e o fornecimento que representa. Confira também o tipo governamental transmitido, não apenas o rótulo mostrado na tela.

Concilie o valor e a data do recebimento com os documentos da operação. Um pagamento que liquida obrigações distintas precisa de análise fiscal da documentação adequada; não conclua que uma única nota poderá representar tudo porque o banco fez um único crédito. Valor bancário e vínculo fiscal são informações relacionadas, mas possuem funções diferentes.

Se a tela mostra uma referência e o XML contém duas, compare o cadastro com a integração. Confira a coexistência de vínculos automáticos e manuais. Preserve os arquivos anteriores como prova da operação.

Correção por cenário

Uma única operação, referência extra comprovadamente indevida. Remova o vínculo incorreto na origem, com validação fiscal, mantendo a chave pertinente. Gere novamente o arquivo e confira se existe somente a ocorrência adequada ao tipo 2. Registre qual associação foi retirada e por quê.

Uma associação correta foi serializada mais de uma vez. O suporte deve corrigir a geração repetida e conferir o próximo XML. Evite resolver apenas a cópia enviada: se a origem continua duplicando, o problema pode voltar na próxima emissão. Essa análise não dispensa as demais validações de chave e de situação do documento anterior.

Recebimento relacionado a vários fornecimentos reais. Encaminhe o conjunto ao responsável fiscal para definir como documentar a operação. A regra mostra que mais de uma referência não é admitida nesse tipo; ela não fornece uma autorização geral para dividir notas ou pagamentos. Não selecione a chave de maior valor nem descarte as outras por conveniência.

Etapa informada diverge dos fatos. Reavalie tpOperGov com comprovantes de entrega e recebimento. Ajuste somente quando a classificação estiver errada. Trocar o estágio para aproveitar uma possibilidade de repetição do campo altera a informação fiscal e não é solução aceitável.

Exemplo original

Uma empresa entrega computadores a uma autarquia e, depois, recebe o pagamento relativo àquela entrega. A rotina de faturamento busca a chave correta, mas também conserva uma referência herdada de uma entrega anterior do mesmo contrato. A nota do recebimento, com tipo 2, sai com duas ocorrências e retorna 1197.

A equipe compara os documentos e demonstra que a referência herdada pertence a outro recebimento. O fiscal valida sua retirada, e o suporte corrige o reaproveitamento do registro. O novo XML conserva a chave pertinente e o histórico de ambas as entregas permanece arquivado.

Confirmação e escalonamento

Faça uma tentativa controlada depois da correção e examine o resultado final. Se outra rejeição surgir, trate seu diagnóstico. A emissão só deve ser encerrada após confirmação de autorização e preservação do XML com protocolo; a redução da contagem de referências não garante aprovação fiscal do restante.

Procure o contador para vários fornecimentos, conciliação incerta ou dúvida sobre a etapa. Procure o suporte se a referência extra voltar ou se houver divergência entre tela e XML. Encaminhe retorno completo, arquivos, horário, ambiente e a lista dos vínculos conferidos.

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-30, p.33; histórico, p.5–6, e regras vizinhas de chave, p.34.

• Documentos oficiais SVRS e avisos SVRS, registro ENCAT de 05/10, materiais capturados em 10/10/2026. O aviso foi localizado na listagem geral salva.

• TecnoSpeed, evolução da NT: apoio adjacente. Não foram confirmados três publicadores práticos independentes com solução específica e atual para 1197. Essa limitação descreve os materiais disponíveis, sem afirmar ausência universal de outros guias.

Elaboração documental v3 por IA, baseada nos materiais salvos de 10/10/2026. Referências sem corpo ou registro comprovados não integram os apoios deste artigo. Novas revisões técnica/editorial e cruzada pendentes. Sem nova consulta online, inspeção visual ou teste de autorização nesta etapa; sem certificação fiscal humana.