Rejeições fiscais
Falha de conexão com a SEFAZ: como investigar sem duplicar a nota
Quando o emissor informa falha de conexão, tempo limite excedido ou ausência de resposta, primeiro descubra o resultado das tentativas anteriores. A mensagem descreve o que o sistema conseguiu receber, e não necessariamente o que aconteceu na SEFAZ. Uma nota pode ter sido processada enquanto o retorno se perdeu no…
Quando o emissor informa falha de conexão, tempo limite excedido ou ausência de resposta, primeiro descubra o resultado das tentativas anteriores. A mensagem descreve o que o sistema conseguiu receber, e não necessariamente o que aconteceu na SEFAZ. Uma nota pode ter sido processada enquanto o retorno se perdeu no caminho.
Este guia trata da comunicação na emissão de NF-e, modelo 55, com cuidados também relevantes para a NFC-e, modelo 65. O diagnóstico deve identificar modelo, UF autorizadora, ambiente e serviço utilizado. Consulta de protocolo, autorização e envio de evento são solicitações diferentes; uma falha em uma delas não demonstra falha em todas.
Separe falta de resposta e rejeição fiscal
Uma rejeição documentada traz a resposta do serviço, com código e motivo. Um erro de rede pode ocorrer antes de essa resposta existir no emissor. Se a tela estiver em branco, procure o registro técnico e o arquivo de retorno antes de atribuir a ocorrência a cadastro, certificado ou indisponibilidade nacional.
Também confirme a origem do código. Mensagens do programa, do sistema operacional e da conexão não são automaticamente códigos cStat da SEFAZ. Alterar NCM, CFOP, valores ou destinatário não corrige uma falha de transporte da mensagem e pode criar um problema fiscal adicional.
Preserve os dados necessários à investigação
Registre o texto completo do erro, data e horário, versão do emissor, empresa, modelo, UF, ambiente e operação executada. Separe a chave, a série, o número da nota e o recibo, quando existir. Guarde o XML transmitido e os retornos anteriores.
Informe se o problema ocorre com todas as notas, apenas com uma empresa, em uma estação ou durante uma tarefa específica. Esses recortes ajudam o suporte a comparar os casos. Eles não provam a causa sozinhos: uma falha restrita a uma máquina ainda precisa de conferência da rede, da configuração e do acesso ao certificado.
Consulte o resultado antes de reenviar
Se o envio assíncrono devolveu recibo, acompanhe o processamento desse lote pelo procedimento do emissor. O código 104 indica lote processado, exigindo conferir os resultados individuais; o 105 indica processamento em andamento. O recibo não é, por si só, autorização da nota.
Quando a transmissão ficou sem resposta ou o recibo não estiver disponível, consulte a situação pela chave no ambiente e autorizador corretos. Se localizar autorização, recupere o protocolo e reconcilie o estado no sistema. Não gere outra nota para substituir um documento que apenas parecia pendente localmente.
Uma consulta rejeitada ou também interrompida não comprova ausência da nota. Esclareça a falha dessa consulta antes de decidir sobre reenvio ou numeração. Ao encontrar duplicidade, investigue o documento existente e seus dados, em vez de modificar o número ou a chave para tentar passar.
Confira o caminho utilizado pelo emissor
O acesso deve ser verificado no computador ou servidor que efetivamente realiza a comunicação. Abrir um site em outra estação não comprova que o serviço do emissor consegue chegar ao autorizador. Peça à equipe técnica que identifique o endereço de serviço, a UF e o ambiente configurados.
Investigue resolução de nomes, acesso à rede, regras de proxy e controles de tráfego conforme o erro registrado. Compare com alterações recentes e com outras estações, usando testes orientados pelo suporte. Uma diferença de comportamento entre redes é uma pista sobre o caminho da conexão, não uma prova automática de problema na SEFAZ.
Confira também qual certificado o emissor está utilizando, sua validade e a disponibilidade de acesso à chave privada pelo processo responsável. O MOC distingue certificado de transmissão e assinatura das mensagens. Não conclua que o certificado precisa ser substituído apenas porque ocorreu um timeout; primeiro localize a etapa que falhou.
No ALRA, o suporte deve confirmar o componente, o serviço e o procedimento realmente instalados. Não copie configurações de consoles de outros produtos nem desative a validação de certificados para fazer a comunicação funcionar. Se houver ajuste necessário, documente a causa e valide o resultado no fluxo correspondente.
Disponibilidade do serviço e situação da nota
A consulta de status do serviço informa a condição do processamento do autorizador. Ela não substitui a consulta da situação de uma nota específica. O MOC relaciona os retornos 107, serviço em operação; 108, paralisação temporária; e 109, paralisação sem previsão, conforme o serviço consultado.
Considere horário, ambiente, UF e abrangência do aviso oficial. Um registro de normalidade não garante a conclusão de toda comunicação a partir da rede da empresa. Da mesma forma, uma indisponibilidade divulgada não resolve a dúvida sobre uma nota enviada antes da interrupção.
Evite clicar repetidamente em enviar ou manter consultas sem intervalo. Tentativas sucessivas podem sobrecarregar o serviço e provocar controles de consumo indevido. O suporte deve conferir a rotina de repetição e o intervalo aplicável ao serviço e à versão, preservando o acompanhamento de documentos pendentes.
Contingência exige procedimento próprio
A falha de comunicação não habilita automaticamente qualquer modalidade de contingência. Antes de mudar o tipo de emissão, confirme o modelo, a UF, a modalidade permitida, as condições de ativação e o tratamento das tentativas sem retorno. NF-e e NFC-e não compartilham indistintamente os mesmos procedimentos.
O uso de SVC, EPEC ou emissão offline envolve regras próprias de documentação, impressão e transmissão posterior. Não escolha uma modalidade apenas porque uma página antiga a recomenda para todo caso. Este guia orienta a investigação da comunicação; a emissão em contingência deve seguir a documentação vigente e a configuração validada do emissor.
Como confirmar a recuperação
Depois de corrigir a causa demonstrada, conclua a consulta ou a tentativa pendente pelo fluxo apropriado. Compare chave, ambiente, resultado e protocolo. Confirme também que o estado apresentado no ALRA corresponde ao retorno fiscal recuperado.
Por exemplo, uma interrupção no retorno deixou uma nota pendente no sistema. A consulta posterior encontrou sua autorização; a providência é recuperar esse resultado, sem criar outro documento. Se a consulta ainda falhar, a conclusão continua em aberto. O atendimento deve registrar o que foi comprovado e o que falta esclarecer, sem tratar o desaparecimento da mensagem como sucesso.
Fontes
Conferência documental em 16/10/2026: MOC 7.0 — Visão Geral, páginas 53, 58, 60, 63, 67, 75–78, 82–83 e 85–86, nos trechos técnicos indicados; Ajuste SINIEF 07/05, contingência e consumo dos serviços, com reuso de leituras documentadas. Consulta de status não foi executada para comprovar disponibilidade atual.
Três apoios específicos foram confrontados: Omie, mensagem em branco, Sankhya, timeout e NFePHP, esclarecimentos sobre timeout. Receitas antigas, hipóteses apresentadas como certezas e automatismos de reemissão ou contingência foram filtrados. Não houve diagnóstico de máquina real, transmissão, consulta individual ou criação de imagens.