Rejeição 1000 na NFC-e: confira a presença do comprador antes de informar o município do IBS

Se a NFC-e voltou com o código 1000, confira como a venda foi realizada e quais informações o emissor colocou no cabeçalho da nota. O problema pode ser um município do IBS preenchido automaticamente em uma operação que não admite esse campo. Trocar a cidade, a alíquota ou a classificação tributária do produto sem identificar a causa não resolve essa incompatibilidade.

A mensagem oficial é “Rejeição: Município do fato gerador do IBS informado indevidamente”. O diagnóstico começa pelo XML efetivamente transmitido e pela presença do comprador, não pelo cadastro isolado de um produto. Preserve o retorno completo antes de atualizar a nota rejeitada.

Qual regra está sendo aplicada

A NT 2025.002 RTC v1.52, página 32, apresenta a regra B25b-60 para a NFC-e, modelo 65. Ela rejeita a combinação de município do IBS informado em ide/cMunFGIBS com indicador de presença diferente de 5 em ide/indPres. O valor 5 identifica operação presencial fora do estabelecimento.

Os dois campos ficam na identificação do documento. Esse retorno não aponta, por si só, erro no CST, no cClassTrib ou no cálculo do imposto de determinado item. A regra também não se confunde com a validação de existência do código municipal na tabela do IBGE.

O leiaute da mesma NT, página 15, restringe o preenchimento de cMunFGIBS à operação presencial fora do estabelecimento quando não estiverem preenchidos o endereço do destinatário nem o local de entrega. Portanto, além de comparar os dois campos da regra, o suporte precisa examinar os endereços e o leiaute aplicável. Não apague endereços verdadeiros para criar artificialmente essa condição.

Confirme o contexto do retorno

Este artigo trata do cStat 1000 na autorização da NFC-e. A documentação citada identifica expressamente o modelo 65 para B25b-60. Não estenda essa linha automaticamente a toda NF-e modelo 55, à NFS-e ou a uma mensagem interna de um sistema com o mesmo número.

Há exemplo público de um emissor que exibe “1000” junto de um erro interno de código municipal de entrega. Nesse caso, o retorno bruto e o serviço permitem distinguir a validação do aplicativo do cStat enviado pela SEFAZ. O mesmo cuidado vale para um tutorial que usa “NF-e” como nome genérico de documentos eletrônicos.

Registre a UF, o autorizador que recebeu a transmissão, o ambiente e a versão do emissor. Homologação e produção têm respostas e cronogramas próprios. Um teste aprovado em homologação não comprova o resultado fiscal de uma venda em produção.

O que reunir antes de corrigir

Separe o XML rejeitado, a resposta com cStat e xMotivo, o horário, a chave, o modelo e a identificação da operação. No XML, compare indPres, cMunFGIBS, dest/enderDest e o grupo entrega. Confira também cMunFG, que corresponde ao fato gerador do ICMS: ele não é um substituto automático do campo do IBS.

Depois confirme com quem realizou a venda onde houve a presença do comprador. Uma venda no balcão, uma entrega a domicílio e uma operação presencial fora do estabelecimento não devem receber o mesmo indicador só porque todas terminam com a mercadoria nas mãos do cliente.

Investigue de onde veio o município: cadastro do estabelecimento, tipo de operação, integração, importação ou configuração geral. Uma tela atualizada pode estar correta enquanto a nota preparada anteriormente conserva valores antigos. A comparação precisa alcançar o arquivo transmitido.

Como tratar os principais cenários

A venda foi presencial no estabelecimento

Se a venda ocorreu no balcão e o XML declara indPres=1, verifique por que cMunFGIBS foi preenchido. Confirmado o preenchimento indevido, corrija a configuração que o gera e atualize a nota pelo emissor. Mantenha a presença que descreve a venda real e preserve os demais dados corretos.

Não mude para 5 apenas para atender à comparação da regra. Isso faria o documento declarar uma modalidade diferente da operação realizada e poderia afetar outras validações.

Houve entrega a domicílio

Quando a operação estiver corretamente enquadrada com indicador 4, a B25b-60 continua comparando esse valor com 5. Se o município do IBS foi inserido indevidamente, revise sua geração. Confira separadamente as informações de endereço exigidas para a modalidade e as condições atuais do documento.

O endereço de entrega não deve ser apagado para fazer caber um campo adicional. Se houver dúvida sobre a classificação da venda, a decisão deve anteceder a nova transmissão e ter apoio do responsável fiscal.

A venda foi presencial fora do estabelecimento

Se a operação realmente ocorreu nessa modalidade, mas o XML conserva indicador 1 ou outro valor, corrija a origem dessa informação. Confira o município efetivo e as condições de endereço previstas no leiaute. O suporte deve verificar o conjunto, incluindo a regra relacionada 1005 para ausência do município em operação declarada com indicador 5.

Não aplique automaticamente a solução de remover cMunFGIBS em toda rejeição 1000. Primeiro determine qual informação está errada. Uma correção coerente pode exigir ajustar a presença que foi cadastrada incorretamente.

Exemplo hipotético

Uma loja de materiais de pintura prepara uma NFC-e de R$ 184 para uma compra realizada no balcão. Após uma atualização, a integração passa a copiar um município para cMunFGIBS em todas as vendas. A nota mantém indPres=1 e recebe 1000.

A equipe compara o XML com a venda e identifica a cópia automática. Corrige a configuração e regenera o documento rejeitado sem o campo indevido, mantendo produtos, valores e modalidade verdadeiros. O exemplo não depende de alterar tributação ou inventar uma venda fora da loja. A autorização ainda precisa ser confirmada no novo retorno.

Como verificar o resultado e quando escalar

Confira o novo XML antes do envio e registre exatamente quais dados mudaram. Use o fluxo do emissor para gerar e assinar o arquivo atualizado; não edite manualmente um XML assinado. Depois leia a resposta correspondente à chave e ao ambiente corretos. O desaparecimento do 1000 pode ser seguido de outra rejeição e não equivale à autorização.

Acione o suporte se o arquivo continua recebendo um campo removido na tela, se integrações enviam valores diferentes ou se a mensagem vem apenas do aplicativo. Encaminhe ao responsável fiscal dúvidas sobre modalidade, local da operação ou necessidade do campo. Persistindo divergência entre regra documentada e retorno, reúna os arquivos e procure o autorizador competente.

Versão e cronograma conferidos

Consulta documental: 10/10/2026. O portal lista a v1.52, publicada em 01/10/2026. O aviso ENCAT de 05/10 postergou mudanças das NTs citadas para 26/10 em homologação e 16/11 em produção. Isso não adia automaticamente a B25b-60, já presente em versões anteriores. A presença documental também não comprova implantação individual por UF. Confira a configuração do ambiente e o retorno concreto com o suporte.

Fontes

• NT 2025.002 RTC v1.52, p. 4–6, 15–16 e 32; B12a, B25b-60 e B25b-70.

• SVRS, documentos e avisos, catálogo e aviso ENCAT de 05/10/2026.

• Migrate/InvoiCy, rejeição 1000 e Sankhya, presença fora do estabelecimento: apoio prático, sujeito ao modelo definido na fonte oficial.

• TOTVS, código interno 6012 exibido com 1000: contexto distinto, não solução da B25b-60.

Revisão documental por IA; sem teste de emissão em ambientes fiscais. As divergências e limitações das fontes práticas estão registradas em fontes.json.