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:

1. 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.
2. 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.
3. 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.
4. NSU repetido ou fora de ordem nas consultas de manifestação do destinatário (DF-e).
5. 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:

1. Pare imediatamente as transmissões e consultas com o certificado afetado. Não retente.
2. Aguarde 60 minutos a partir da última tentativa. Use esse tempo para investigar a causa.
3. Verifique os logs da sua integração: existe alguma rotina em loop? Algum job agendado disparando a cada minuto?
4. Se houver mais de uma aplicação usando o mesmo certificado, desabilite as secundárias até identificar o ofensor.
5. 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).

O post Rejeição 656 – Consumo Indevido na NF-e: como identificar, resolver e prevenir apareceu primeiro em Motor Fiscal | Escrituração e Automação Fiscal NFe CTe NFSe NFTS.