Rejeição 656: interrompa as tentativas e identifique o serviço bloqueado

A rejeição 656 indica consumo indevido de um serviço fiscal. Para resolver, a empresa precisa interromper as tentativas repetidas, identificar a operação que provocou o bloqueio e corrigir seu funcionamento antes de retomá-la. Insistir no botão de envio pode prolongar a parada, inclusive quando a emissão ou a consulta é urgente.

O número aparece tanto na autorização e em serviços relacionados à NF-e e à NFC-e quanto na distribuição de documentos da NF-e. Os limites e as condições são diferentes. Por isso, a primeira pergunta ao suporte deve ser: qual Web Service devolveu o 656, com qual mensagem completa e para qual operação?

Primeiro, separe emissão de distribuição

Na autorização, o problema pode começar com uma nota rejeitada por outro motivo. O sistema continua transmitindo o mesmo documento sem corrigir o erro inicial, até acionar o controle de consumo. Nesse caso, o 656 é uma consequência: a rejeição anterior continua precisando de tratamento.

Na distribuição, o sistema está buscando documentos e eventos de interesse do contribuinte pelo NFeDistribuicaoDFe. O bloqueio pode decorrer de consulta fora da sequência, insistência quando não há novos documentos ou excesso de consultas pontuais. Isso não significa, por si só, que uma nota foi rejeitada na emissão.

O ramo de distribuição tratado pela NT 2014.002 refere-se à NF-e modelo 55. Não transforme essa rotina em uma promessa de recuperação de NFC-e modelo 65. Já os controles gerais do MOC indicam expressamente modelos 55/65, conforme o serviço utilizado.

Limites de referência dos serviços gerais

O MOC 7.0, seção 4.3, baseado na NT 2018.002, apresenta controles facultativos, parametrizáveis pelo autorizador:

• Autorização: mais de 30 rejeições iguais para a mesma NF-e/NFC-e

• Consulta de lote: mais de 40 consultas ao mesmo recibo em uma hora

• Inutilização: mais de 20 rejeições iguais para a mesma solicitação

• Consulta de protocolo: mais de 10 consultas à mesma chave em uma hora

• Registro de eventos: mais de 20 rejeições iguais para o mesmo evento

• Outros serviços: repetição em ciclo com mais de 40 envios que gere erro ou sobrecarregue o autorizador

Esses números são referências documentais, não franquias garantidas. O manual prevê bloqueio do Web Service por até uma hora, com parâmetros ajustáveis a qualquer momento pelo ambiente autorizador. O controle pode considerar o CNPJ do certificado com o IP ou o CNPJ do emitente. Nos ramos de autorização, inutilização e eventos, há ainda previsão de bloqueio permanente, a critério da UF, após 50 bloqueios de referência, exigindo contato com a administração tributária.

Existe exemplo estadual concreto: a SEF/MG informa ativação em homologação e produção para autorização de NFC-e, por CNPJ emissor, quando houver mais de 200 rejeições iguais. A tabela mineira versão 2.00, de 13/03/2026, também marca esse controle como aplicado. Essa configuração não deve ser copiada para outra UF, para NF-e 55 ou para distribuição.

As três operações da distribuição

A NT 2014.002 v1.40, itens 3.11.4.1 e 3.11.4.2 distingue:

1. distNSU: busca sequencial. A chamada seguinte deve usar o ultNSU devolvido pela anterior. Se o serviço informar cStat 137, ou se ultNSU alcançar maxNSU, aguarde uma hora antes de consultar novamente. Reiniciar a sequência arbitrariamente pode causar bloqueio

2. consNSU: busca pontual de um NSU, útil para recuperar uma lacuna identificada na base local

3. consChNFe: busca pontual pela chave de acesso, conforme as permissões de acesso ao documento

Para as consultas pontuais consNSU e consChNFe, a nota técnica descreve limite de 20 consultas por hora e bloqueio do CNPJ quando excedido. Não aplique esse limite indistintamente ao distNSU nem considere cada nova chave uma autorização para ignorar o controle. Para recuperar o conjunto de documentos disponíveis, use o fluxo sequencial previsto.

Nos três tipos, depois do 656, a orientação é aguardar uma hora. Uma consulta antecipada reinicia a contagem. Vários programas consultando o mesmo CNPJ completo informado na requisição precisam coordenar a sequência e a pausa; parar apenas a tela do operador pode ser insuficiente se um serviço automático continuar ativo.

Outros contextos exigem contrato próprio

A NT 2022.001 v1.00, seção 03.3 também prevê 656 na Consulta GTIN por consumo excessivo em curto intervalo. Essa menção não define um limite numérico próprio. Não transfira automaticamente os limites da distribuição para essa consulta auxiliar.

O MOC 6.0 documentava o mesmo código nos antigos serviços NfeConsultaDest e NfeDownloadNF, por repetição de consultas ou downloads já disponibilizados. Esse é um contexto histórico: não comprova disponibilidade atual desses serviços nem autoriza aplicar seus parâmetros ao NFeDistribuicaoDFe. Em logs antigos, a versão e o nome do serviço continuam essenciais para interpretar o retorno.

Procedimento seguro para retomar

Comece guardando o retorno completo, horário, ambiente, serviço, operação e identificador envolvido: chave, recibo, evento, inutilização ou NSU. Preserve também a rejeição imediatamente anterior ao consumo indevido. Esse conjunto permite diferenciar um erro fiscal persistente de um problema na rotina de consultas.

Em seguida, peça ao responsável técnico que suspenda os reenvios automáticos e identifique todos os sistemas concorrentes. Inclua integrações contábeis, coletores de XML e tarefas executadas em segundo plano. Combine quem será responsável pela retomada para evitar que cada equipe faça um teste durante o bloqueio.

Corrija a causa enquanto aguarda. Na emissão, ajuste apenas dados que estejam comprovadamente errados, segundo a rejeição original. Na distribuição, confira a persistência do ultNSU, a sequência utilizada e o tratamento do retorno sem documentos. A NT prevê retorno do ultNSU no 656 de distNSU; quando presente, ele ajuda a reconciliar a posição, mas não elimina a espera.

Depois do intervalo aplicável, faça uma tentativa controlada e leia o novo retorno. Se o bloqueio continuar mesmo com pausa comprovada, leve os registros ao fornecedor e à SEFAZ responsável. Não prometa liberação em horário exato quando o ambiente adota parâmetros próprios ou exige atendimento.

Evite que a interrupção volte

Uma rotina confiável registra tentativas, centraliza o controle por contribuinte e serviço e impede repetição automática de rejeições sem correção. Após falha de comunicação, confira o resultado anterior antes de gerar novas emissões ou eventos. Nunca troque IP, CNPJ ou certificado para contornar o bloqueio.

Para a gestão, o encerramento não é apenas o desaparecimento do 656. Confirme que a causa foi corrigida, que a operação pretendida recebeu resultado válido e que documentos, protocolos e posições de consulta foram preservados. Assim, o faturamento retorna sem transformar a urgência em novos erros.

Base consultada

Documentação oficial preservada em 09/10/2026 e relida em 10/10/2026: MOC 7.0, NT 2018.002 v1.00, NT 2014.002 v1.40, NT 2022.001 v1.00 e MOC 6.0 histórico. Aviso e tabela SEF/MG consultados em 10/10/2026. A presença documental não certifica implantação em todas as UFs.

Leituras práticas de três editores: Omie, histórico da rejeição anterior, TecnoSpeed, contexto de controle de NSU e horário e Oobj, contexto de distribuição e concorrência entre aplicações. Os limites oficiais foram mantidos por operação, sem importar generalizações dos tutoriais.