Rejeição 656 — Consumo Indevido

O que é esta rejeição?#

A Rejeição 656 é retornada pela SEFAZ quando o sistema identifica o seguinte problema na NF-e: Consumo Indevido. A nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Causas comuns#

• O sistema emissor está fazendo requisições excessivas ao web service da SEFAZ
• Há um loop de tentativas de envio que está sobrecarregando o serviço

Como resolver#

1. Reduza a frequência de envio de NF-e — implemente intervalo entre requisições
2. Verifique se o sistema não está reenviando NF-e já autorizadas em loop
3. Aguarde alguns minutos antes de tentar novamente

Verificações analíticas#

• Se o campo dhEmi da NF-e atual for igual ou muito próximo (diferença inferior a 1 segundo) ao dhEmi de outra NF-e com mesmo emit/CNPJ já registrada no lote de envio então há duplicidade de timestamp indicando que o sistema gerador está reenviando o mesmo documento em loop sem incrementar corretamente o número sequencial ou o nonce da requisição: cancele o processamento repetido, implemente controle de idempotência baseado em chave de acesso e só reenvie após confirmar ausência de autorização prévia consultando o serviço de consulta de protocolo (NFeConsultaProtocolo) antes de qualquer nova tentativa.
• Se o campo tpEmis for diferente de 1 (emissão normal) e ao mesmo tempo o campo dhRecbto estiver ausente ou a diferença entre dhEmi e o instante atual ultrapassar o prazo de transmissão em contingência estabelecido pela legislação (120 horas para SCAN/FS-DA ou 168 horas para SVC) então o sistema pode estar tentando transmitir lotes de contingência vencidos repetidamente ao web service, gerando carga indevida: valide o prazo de contingência antes de cada tentativa de transmissão e rejeite internamente os documentos fora do prazo sem enviá-los à SEFAZ.
• Se o campo nNF da NF-e sendo enviada for numericamente inferior ou igual ao nNF de uma NF-e já autorizada para o mesmo emit/CNPJ/série/mod registrada na base local então o sistema emissor não está incrementando corretamente o contador de numeração e está regenerando chaves de acesso para documentos que já possuem autorização, provocando requisições repetitivas com chaves distintas para a mesma operação: implemente verificação do último número autorizado antes de gerar novo documento e bloqueie o envio caso a chave já conste como autorizada no retorno de consultas anteriores.
• Se o campo indPag estiver preenchido com 1 (pagamento a prazo) e simultaneamente o somatório de vPag nos elementos detPag for igual a vNF sem nenhum elemento detPag com tPag igual a 90 (sem pagamento) ou 99 (outros) então a inconsistência entre a indicação de prazo e a liquidação integral imediata sugere que o documento está sendo gerado por rotina automatizada com parâmetros de pagamento fixos sem validação semântica, sintoma comum em loops de regeneração de NF-e: revise a lógica de preenchimento do bloco pag para garantir coerência entre indPag, vPag e a natureza real da operação antes de cada envio.
• Se o CRT do emitente for 1 (Simples Nacional) e o CSOSN utilizado nos itens for 900 (outros) enquanto o CFOP indicar operação de venda para consumidor final (idDest=1, tpNF=1) sem nenhum campo de ICMS desonerado preenchido (motDesICMS e vICMSDeson ausentes) e sem redução de base de cálculo (pRedBC zerado) então a combinação de CSOSN genérico com operação padronizada indica que o motor de tributação não está resolvendo corretamente o enquadramento fiscal dos itens, gerando documentos com tributação indefinida que são rejeitados ou suspensos pela SEFAZ e reenviados indefinidamente pelo sistema sem diagnóstico do erro tributário subjacente: corrija o mapeamento CSOSN×CFOP×CRT antes de qualquer nova tentativa de transmissão.