Rejeição 1006: compra governamental informada em NFC-e exige revisar o documento

Se uma venda retornou 1006, confira se o sistema tentou emitir NFC-e com informações de compra governamental. A solução depende de uma decisão anterior ao XML: a operação realmente pertence a esse tratamento ou recebeu a classificação por engano? Remover o grupo automaticamente pode esconder uma necessidade fiscal real; trocar o modelo sem conferir a operação também pode criar outro problema.

A mensagem da NT 2025.002-RTC v1.52 é “Rejeição: NFCe com grupo de compra governamental”. Na autorização da NFC-e, modelo 65, a regra BB01-10 rejeita a presença de gCompraGov. A regra trata da incompatibilidade entre grupo e modelo; não é um aviso de falta de alíquota nem de cadastro municipal. [1]

Por que o grupo foi parar no cupom

O emissor pode montar os dados a partir do cadastro do destinatário, do tipo de operação ou de uma integração. Uma opção governamental marcada em um cadastro compartilhado pode atingir vendas que seguem pelo PDV. Outro caso é o reaproveitamento de uma estrutura preparada para NF-e 55 sem condicionar a geração do grupo ao modelo escolhido.

Essas são hipóteses de investigação, não conclusões obtidas apenas pelo número. Preserve o pedido, o XML transmitido e a resposta do autorizador. Confirme ide/mod=65 e a existência de ide/gCompraGov. Registre também o ambiente, a UF, o autorizador, a versão do sistema e quem selecionou o documento. O arquivo final oferece evidência melhor do que uma tela isolada.

Primeiro cenário: classificação governamental incluída por engano

Se a venda não corresponde a compra governamental, identifique de onde veio a marcação. Pode ser um cliente privado cadastrado incorretamente, uma operação copiada de outro procedimento ou uma integração que atribui o grupo a qualquer destinatário com CNPJ.

Corrija a informação que estiver errada e gere novamente a nota pelo sistema. A conferência precisa mostrar que gCompraGov deixou de ser gerado porque não se aplica à venda. Apagar apenas um de seus campos não demonstra que o grupo inteiro foi removido nem que a causa desapareceu.

Antes de alterar parâmetros compartilhados, veja quais operações eles atendem. Uma configuração pode ser correta para fornecimentos governamentais em NF-e e incorreta quando reutilizada no fluxo de NFC-e. O suporte deve separar os caminhos adequados, preservando o cadastro verdadeiro dos clientes e a documentação das vendas anteriores.

Segundo cenário: a operação precisa de compra governamental

Se o fornecimento efetivamente exige gCompraGov, a rejeição indica que o modelo 65 não comporta esse grupo. A NT reserva ao modelo 55 as regras de compras governamentais ali descritas. A equipe fiscal e o suporte precisam preparar o fluxo de NF-e adequado ao caso, com o tratamento completo da operação. [1]

Isso exige revisar destinatário, tipo de ente e tipo de operação, além de tributos e referências cabíveis. Não basta renomear “cupom” para “nota” em uma tela. O modelo integra a identificação fiscal do documento, e o emissor deve gerar, assinar e transmitir o arquivo correto pelo fluxo correspondente.

Confira a situação de qualquer documento relacionado antes de criar outro. Quando a única tentativa foi rejeitada, trate-a no fluxo do sistema com rastreabilidade. Se houver outra nota já autorizada para o mesmo fornecimento, encaminhe a regularização ao responsável fiscal; não emita uma segunda nota como tentativa de substituir a primeira sem análise.

Terceiro cenário: o cadastro está certo, mas o gerador usa o fluxo errado

Uma empresa pode manter corretamente um órgão público no cadastro e, ainda assim, encaminhar seu pedido para a rotina padrão do PDV. O defeito está na seleção do documento ou na montagem da mensagem, não na identidade do destinatário.

Peça ao suporte que compare o pedido, a configuração de emissão e o XML final. Uma integração pode selecionar modelo 65 por padrão mesmo quando recebe dados governamentais. A correção deve impedir essa combinação e tornar explícito o fluxo fiscal escolhido. Não altere o destinatário para pessoa física nem desmarque sua natureza verdadeira para fazer o cupom passar.

Exemplo de decisão antes do reenvio

Uma papelaria fictícia recebe um pedido associado a um cliente cadastrado como órgão municipal. A venda é encaminhada ao PDV, que monta NFC-e com gCompraGov. A resposta retorna 1006.

A equipe confere o pedido e identifica que o fornecimento pertence a um contrato público que será tratado como compra governamental. Mantém a identidade do destinatário, interrompe o fluxo do cupom rejeitado e pede à área fiscal a definição dos dados da NF-e 55. O suporte prepara a emissão pelo caminho adequado e verifica o novo arquivo. O exemplo ilustra a decisão de modelo; não define alíquotas, contratos ou obrigações de qualquer município específico.

Em outro pedido, de cliente privado, o grupo surgiu porque uma configuração havia sido copiada incorretamente. Nesse caso, a correção seria da marcação indevida, mantendo o modelo fiscal realmente aplicável. Os dois casos produzem o mesmo retorno, mas não admitem a mesma ação automática.

Como conferir a solução

Reveja o XML novo antes da transmissão: o documento 65 não deve conter gCompraGov; quando a operação demanda esse grupo, confirme o modelo 55 e o conjunto de informações aprovado pelo responsável fiscal. Valide também a origem do parâmetro para evitar que o próximo pedido repita a combinação.

Depois de transmitir, examine código e mensagem completos. Outro retorno pode indicar pendência diferente, inclusive nos tributos ou documentos referenciados. Considere concluída a emissão apenas quando a resposta de autorização corresponder à chave e ao documento pretendidos, com o protocolo preservado. Uma mensagem removida da tela não equivale a autorização.

Quando escalar e como interpretar o número

Procure o suporte quando não for possível localizar a origem do grupo, quando o modelo da tela diferir do XML ou quando vários fluxos compartilham a configuração. Acione a contabilidade para definir modelo, natureza da compra e eventual regularização de documentos anteriores. Se a combinação documental está correta e o retorno diverge da regra, encaminhe os arquivos ao autorizador.

Não aplique este artigo a um 1006 devolvido por NFCom, evento ou outro serviço sem conferir sua especificação. Números iguais podem ter mensagens diferentes. Aqui o escopo é exclusivamente BB01-10, autorização de NFC-e 65 na NT indicada.

Base e situação documental

Consulta em 10/10/2026: v1.52 publicada no portal SVRS em 01/10. O aviso ENCAT de 05/10 adiou determinadas mudanças para 26/10 em homologação e 16/11 em produção; BB01-10 é regra anterior, e o aviso não comprova alteração de sua aplicação individual por UF. Não houve teste de emissão. [2][3]

1. NT 2025.002 v1.52, página 32 e grupo BB.

2. Lista de documentos SVRS.

3. Avisos ENCAT/SVRS.

Conferência prática: Webmania, rejeição 1006, Sankhya, rejeição 1006 e TOTVS, implementação de gCompraGov. A terceira fonte é adjacente e específica do Datasul, sem comprovar comportamento do ALRA. Fontes.json registra os limites.