Sua empresa consultou uma NF-e e recebeu de volta a mensagem “Rejeição 656 – Consumo Indevido”? Esse é um dos bloqueios mais frequentes (e mais incompreendidos) na operação fiscal eletrônica. Diferente de outras rejeições, ele não aponta um erro no XML da nota — ele indica que sua aplicação foi desligada da SEFAZ por excesso de requisições. Neste artigo, mostramos exatamente o que dispara essa rejeição, quanto tempo o bloqueio dura e como configurar sua operação para que ela não aconteça de novo.
O que é a Rejeição 656
A Rejeição 656 é um mecanismo de proteção dos servidores da SEFAZ. Quando um certificado digital ou endereço IP ultrapassa o limite de consultas permitidas em uma janela de tempo, a SEFAZ recusa as próximas requisições daquele emissor com o código 656 e a descrição “Rejeição: Consumo Indevido”.
O ponto importante: não é um erro da nota fiscal. É um rate limit. A nota provavelmente está correta — sua aplicação só está perguntando à SEFAZ com frequência demais.
Por que a SEFAZ aplica esse bloqueio
Os webservices da SEFAZ atendem milhões de empresas todos os dias. Um único emissor consultando o mesmo recibo em loop, ou disparando lote atrás de lote sem respeitar intervalos, consome capacidade que deveria ser distribuída entre todos os contribuintes. A Rejeição 656 garante que ninguém monopolize o serviço.
As regras estão formalizadas nas Notas Técnicas NT 2014.002 e NT 2018.002, e são aplicadas pela SEFAZ Virtual e pelas SEFAZ estaduais autorizadoras.
Quais são os limites técnicos
Os tetos publicados pela SEFAZ que disparam a rejeição 656 são, em resumo:
- 600 consultas a cada 5 minutos por certificado digital (limite global do emissor).
- 20 consultas por hora para o mesmo serviço de distribuição de DF-e.
- 10 consultas em 1 hora para a mesma chave de acesso.
- 40 consultas em 1 hora para o mesmo número de recibo (consulta de lote).
- O
ultNSU(último número sequencial único) precisa ser informado em ordem crescente nas consultas de DF-e — repetir ou pular NSU também conta como consumo indevido.
Esses números podem variar levemente por UF, mas servem como referência segura para qualquer integração.
Causas mais comuns no dia a dia
Quase todos os casos de Rejeição 656 que vemos em produção caem em um destes padrões:
- Loop de re-tentativa sem backoff. O sistema emissor recebe um timeout ou um retorno temporário e dispara nova consulta imediatamente, sem esperar. Em segundos, ultrapassa o limite.
- Mais de um sistema usando o mesmo certificado. O ERP, um robô de captura de NF-e e um portal interno consultam a SEFAZ com o mesmo certificado ao mesmo tempo. Cada um respeita seu próprio limite, mas a SEFAZ enxerga a soma.
- Processamento em lote sem janela. Mil notas autorizadas no mesmo minuto geram mil consultas de status na sequência — o pico estoura o limite de 5 minutos.
- NSU repetido ou fora de ordem nas consultas de manifestação do destinatário (DF-e).
- Consulta após o lote já ter retornado tudo. Continuar perguntando “tem mais?” depois que a SEFAZ já respondeu que não tem mais documentos.
Quanto tempo dura o bloqueio
O bloqueio é progressivo e funciona assim:
- Primeiro bloqueio: aproximadamente 60 minutos de espera, com desbloqueio automático.
- Tentativas durante o bloqueio: cada nova requisição feita enquanto o emissor está bloqueado reinicia o cronômetro. Tentar a cada 5 minutos durante o bloqueio é a maneira mais rápida de prolongá-lo.
- 50 bloqueios consecutivos: a SEFAZ pode aplicar bloqueio permanente do certificado/IP, exigindo contato direto com a UF autorizadora para liberação manual.
Em outras palavras: a pior coisa a fazer ao receber uma rejeição 656 é insistir.
Como resolver agora
Se você está vendo a Rejeição 656 neste momento:
- Pare imediatamente as transmissões e consultas com o certificado afetado. Não retente.
- Aguarde 60 minutos a partir da última tentativa. Use esse tempo para investigar a causa.
- Verifique os logs da sua integração: existe alguma rotina em loop? Algum job agendado disparando a cada minuto?
- Se houver mais de uma aplicação usando o mesmo certificado, desabilite as secundárias até identificar o ofensor.
- Após o desbloqueio, volte a operar com cautela — comece com volume baixo e cresça gradualmente.
Se o bloqueio persistir mesmo após uma hora de inatividade, ou se houver suspeita de bloqueio permanente, abra contato com a SEFAZ da sua UF autorizadora.
Boas práticas para não cair de novo
Prevenir a Rejeição 656 é, antes de tudo, uma decisão de arquitetura. Os controles que mais funcionam:
- Centralize as requisições. Um único serviço deve falar com a SEFAZ. ERP, portal e captura devem consumir esse serviço internamente, não a SEFAZ diretamente.
- Implemente backoff exponencial. Em caso de falha, espere 30s, depois 1min, depois 2min, etc. Nunca retente em intervalo fixo curto.
- Respeite o tempo recomendado de consulta de recibo. A SEFAZ devolve no retorno do lote o tempo médio de resposta — use-o como base do
setTimeout, não menos. - Consulte o NSU em sequência e persista o último NSU consultado. Reiniciar a partir de zero a cada execução é uma armadilha clássica.
- Faça rodízio de certificados quando a operação for muito intensa, distribuindo a carga entre múltiplos certificados válidos.
- Monitore o consumo do certificado. Conte requisições por minuto e gere alerta quando passar de 80% do teto.
- Não compartilhe certificado entre setores sem coordenação. Quem usa, registra; quem não está usando, desconecta.
Como o Motor Fiscal trata o consumo indevido
No Motor Fiscal, todas as integrações com a SEFAZ passam por uma camada única de orquestração com rate limiting, backoff automático e rodízio de certificados quando aplicável. O resultado prático é que nossos clientes praticamente não enxergam a Rejeição 656 — quando ela chega, é tratada e absorvida pela camada de retry, sem virar erro de operação.
Se a sua empresa convive com bloqueios recorrentes da SEFAZ ou tem dificuldade em escalar a emissão de NF-e sem bater em limites, fale com nosso time — conseguimos diagnosticar a causa raiz em uma conversa rápida.
Fontes consultadas: documentação técnica da SEFAZ (NT 2014.002 e NT 2018.002).
