Voltar para o blog

Rejeições fiscais

Rejeição 704: confira o horário de emissão e a fila de envio

Quando a nota retorna com rejeição 704, confira o horário gravado no XML e quanto tempo passou até a recepção pela Sefaz. O atraso pode surgir de um relógio incorreto, de uma conversão de fuso ou da espera na transmissão. A mensagem, sozinha, não identifica qual equipamento causou a diferença. O diagnóstico deve…

Blog ALRA
Capa ilustrada da ALRA: Rejeição 704: confira o horário de emissão e a fila de envio.

Quando a nota retorna com rejeição 704, confira o horário gravado no XML e quanto tempo passou até a recepção pela Sefaz. O atraso pode surgir de um relógio incorreto, de uma conversão de fuso ou da espera na transmissão. A mensagem, sozinha, não identifica qual equipamento causou a diferença. O diagnóstico deve preservar a data verdadeira da operação e os registros do envio.

A regra B09-40 da NT 2026.002 v1.11 alcança a NFC-e, modelo 65, e a NF-e, modelo 55, com DANFE Simplificado Tipo 2, identificado por tpImp=6. Por isso, um atendimento baseado apenas na descrição antiga “NFC-e com Data-Hora de emissão atrasada” pode deixar de examinar um caso abrangido pela atualização. A indicação “55/65” também não torna o limite aplicável indistintamente a toda NF-e. [1]

Qual diferença de horário provoca a rejeição?

No contexto indicado, a B09-40 verifica atraso superior a cinco minutos da data e hora de emissão em relação à recepção na Sefaz. A condição principal cita tpEmis=1, emissão normal, e os tipos 6 e 7, associados às SVC. A presença desses tipos na descrição não concede permissão geral de utilizar SVC: o modelo e o procedimento precisam admitir aquela modalidade. [1]

A observação da mesma regra relaciona os cinco minutos ao sincronismo entre servidores da empresa e do autorizador. Ela não acrescenta outra tolerância de cinco minutos. Portanto, não há fundamento nessa linha para trabalhar com dez minutos. Ficar dentro do intervalo tampouco garante autorização, pois outras validações continuam aplicáveis.

Existem duas exceções a critério da UF. A primeira permite aplicar a rejeição a qualquer tipo de emissão. A segunda admite aceitar documento muito atrasado que tenha sido efetivamente emitido em contingência, nos tipos 4 ou 9 citados. Para esses documentos aceitos e transmitidos após 24 horas, a regra prevê cStat=150, autorização fora de prazo. Isso não transforma 24 horas em prazo livre de emissão normal nem garante aceitação de qualquer contingência. [1]

Confira a versão e o contexto do documento

O MOC 7.0 apresentava a B09-40 para a NFC-e. Na documentação consultada em 15/10/2026, a NT 2026.002 v1.11 amplia o contexto para a NF-e com DANFE Simplificado Tipo 2. Seu cronograma associa essa atualização a testes em 01/07/2026 e produção em 03/08/2026. O adiamento para 14/12/2026 identifica outras três regras, sem incluir a B09-40. [1][2]

Esse calendário orienta a conferência de versão; as escolhas expressamente atribuídas à UF exigem verificar o procedimento do autorizador usado. Se houver divergência entre o retorno e a documentação, registre ambiente, UF e versão do emissor para análise do suporte.

Outro cuidado com materiais antigos é o tipo de emissão 3: a documentação atual o associa ao regime especial Nota Fiscal Fácil, enquanto SCAN aparece como modalidade desativada. O regime NFF possui funcionamento próprio. Ele não é uma opção para regularizar, por conveniência, uma emissão atrasada de um sistema comum. [1][3]

Descubra onde o tempo se perdeu

Guarde o XML transmitido e seu retorno. Localize dhEmi, que contém a data e hora de emissão, incluindo o deslocamento de fuso. Compare o instante representado com a recepção informada pela Sefaz, quando disponível. Dois horários visualmente semelhantes podem representar instantes diferentes quando a integração aplica o fuso incorretamente.

Registre modelo, tpImp, tpEmis, ambiente, UF e horário da tentativa. Peça ao suporte que identifique a origem do horário: terminal do caixa, servidor local, serviço em nuvem ou integração. Corrigir somente o computador do operador pode não afetar o valor que chega ao XML.

Examine quando o documento foi gerado, assinado e transmitido. Uma fila pode reter o arquivo por demora de processamento, perda de conexão ou repetição de uma tentativa anterior. Acompanhar esses momentos ajuda a distinguir atraso real de transmissão e preenchimento incorreto. Evite alterar relógios ou configurações por tentativa, sem identificar a origem da diferença.

Como tratar o resultado da investigação

Relógio ou fuso incorreto. O suporte deve corrigir a fonte do horário ou sua conversão. O tratamento da nota rejeitada precisa refletir a operação real e o procedimento fiscal adequado. Não atribua uma nova data à venda apenas para diminuir o atraso calculado.

Emissão normal parada na fila. Corrija o gargalo e confira a situação do documento. Se o horário verdadeiro ficou fora do limite aplicável, envolva o responsável fiscal para definir a regularização. Repetir o envio do mesmo XML antigo não reduz a diferença de tempo.

Contingência realmente utilizada. Preserve o XML e os registros da indisponibilidade. Confirme modelo, tipo de emissão, condições e prazos admitidos pela UF. A exceção não autoriza declarar contingência depois do ocorrido somente para escapar da rejeição. O retorno 150 decorre da aceitação do documento naquele contexto.

NF-e com outro formato de DANFE. Se o modelo é 55 e tpImp difere de 6, confira o arquivo efetivamente enviado e a mensagem completa. Pode existir diferença entre a tela e a integração. Encaminhe as evidências ao suporte antes de aplicar uma correção baseada no contexto errado.

Exemplo: um arquivo aguardando transmissão

Em uma papelaria fictícia, uma NFC-e normal é gerada às 09h12min00s e recebida às 09h18min40s, no mesmo fuso. A diferença é de seis minutos e quarenta segundos. O relógio pode estar correto, mas a espera na integração ultrapassa os cinco minutos da regra.

Os registros mostram que o arquivo permaneceu na fila antes do envio. O suporte deve corrigir essa demora, enquanto o responsável fiscal orienta o tratamento da operação e do documento rejeitado. Mudar apenas o horário no XML esconderia a causa e poderia descaracterizar a emissão.

Verifique a resposta antes de encerrar

Consulte o resultado individual da nota e preserve o protocolo quando houver autorização. Recebimento de lote e desaparecimento da mensagem na tela não comprovam, isoladamente, emissão concluída. Quando o retorno admitido for 150, registre autorização fora de prazo; esse código não é rejeição.

Se houve transmissão anterior com resultado desconhecido, esclareça a situação antes de iniciar outro procedimento. Encaminhe ao suporte os horários com fuso, o XML, o retorno e a identificação da tentativa. O tratamento deve corrigir a causa comprovada e preservar a realidade da venda, sem prometer aprovação automática nas demais validações.

Fontes

  1. NT 2026.002 v1.11 — SVRS: páginas 3, 7 e 8, cronograma, tipos de emissão e B09-40.

  2. MOC 7.0, Anexo I: páginas 9 e 76, campos e regra histórica.

  3. NT 2021.002 v1.12 — Nota Fiscal Fácil: páginas 4, 7 e 10; listagem oficial de NFF.

  4. Apoios de diagnóstico: Oobj, TecnoSpeed e TOTVS WinThor. As condições da NT atual prevalecem sobre exemplos e procedimentos antigos desses sistemas.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.