Rejeição 705: corrija a presença indevida da data de entrada ou saída

A rejeição 705 indica que o documento contém uma data de entrada ou saída que não deveria ser informada naquele contexto. O primeiro passo é conferir o XML transmitido. A data pode estar correta na agenda da empresa e ainda assim ser indevida no arquivo fiscal. Trocar o dia ou igualar esse horário ao da emissão mantém o problema: a informação continua presente.

Na NT 2026.002 v1.11, a regra B10-10 alcança NFC-e modelo 65 ou NF-e modelo 55 com DANFE Simplificado Tipo 2, identificado por tpImp=6. O campo a investigar é dhSaiEnt, dentro do grupo de identificação ide, no serviço de autorização. A condição do Tipo 2 se refere ao modelo 55; a NFC-e já está abrangida por seu próprio modelo. [1]

Entenda qual informação deve ser preservada

O campo dhEmi registra a data e a hora de emissão. Já dhSaiEnt representa a entrada ou saída da mercadoria. A correção da 705 exige tratar o preenchimento indevido deste segundo campo, preservando a emissão verdadeira e os demais fatos da operação. O leiaute distingue expressamente as duas informações. [2]

O pedido pode conter datas de separação, expedição e entrega. Esses registros continuam úteis para a empresa. O problema aparece quando um preenchimento automático ou uma integração copia uma dessas datas para um documento que não admite dhSaiEnt. A solução deve corrigir essa transferência, mantendo o agendamento no controle operacional adequado.

O schema compartilhado dos modelos permite que dhSaiEnt seja omitido. Isso não significa que sua presença seja aceita em qualquer emissão: além da estrutura do XML, aplicam-se as regras de negócio do contexto. Para a NFC-e e para a NF-e com Tipo 2, a B10-10 determina a ausência dessa informação. [1][3]

O que mudou no alcance da rejeição

O MOC 7.0 já apresentava a B10-10 para NFC-e. A documentação consultada em 15/10/2026 inclui a ampliação da NT 2026.002 v1.11 para a NF-e com DANFE Simplificado Tipo 2. Assim, um guia antigo restrito ao modelo 65 pode ajudar a entender o campo, mas não descreve sozinho todo o alcance atual. [1][2]

Na página 3 da NT, a atualização da B10-10 integra o cronograma de testes em 01/07/2026 e produção em 03/08/2026. O adiamento para 14/12/2026 menciona I08-180, BA02-35 e VC02-40, sem incluir a B10-10. Confira a versão usada pelo emissor e o contexto do retorno, evitando aplicar a data de outra regra a este diagnóstico.

A B10-10 está marcada como obrigatória e não traz exceção própria por UF, ambiente ou contingência. As exceções da rejeição 704 tratam do atraso de emissão e não autorizam preencher dhSaiEnt nesta situação. Ao mesmo tempo, a restrição do Tipo 2 não deve ser estendida automaticamente a todas as NF-e modelo 55.

Confira o arquivo que efetivamente chegou à transmissão

Guarde o XML rejeitado e a resposta correspondente. Registre a mensagem completa, modelo, tpImp, ambiente, UF, versão do emissor e identificação da tentativa. Esses dados permitem separar a informação exibida na tela daquela realmente produzida pela integração.

Peça ao suporte para localizar dhSaiEnt no arquivo enviado. Investigue se o valor veio do pedido, de uma nota copiada, de um cadastro padrão ou de uma rotina compartilhada entre NF-e e NFC-e. Uma tela vazia não comprova que a tag foi omitida no XML.

Compare também os arquivos gerado, assinado e transmitido. A fila pode continuar utilizando uma versão anterior após um ajuste de configuração. Se o arquivo disponível não contém o campo, confira se ele corresponde exatamente à nota e à tentativa do retorno. Essa verificação evita alterar informações que não explicam a rejeição recebida.

Ajuste a geração conforme o contexto

NFC-e com dhSaiEnt. Ajuste a geração para omitir o campo. Evite substituir o conteúdo por data fictícia, valor zerado ou tag vazia. A intenção da regra é a ausência da informação, preservando dhEmi, produtos, valores e demais dados reais.

NF-e com tpImp=6. O mesmo cuidado se aplica ao DANFE Simplificado Tipo 2. Corrija a presença indevida sem trocar modelo ou formato apenas para contornar a validação. A definição do documento adequado depende da operação e deve ser confirmada pelo responsável fiscal.

NF-e com outro formato. Analise as regras próprias desse documento antes de retirar uma data de entrada ou saída. Uma alteração geral na integração pode prejudicar outras operações. Se o retorno informa 705 fora do contexto descrito, encaminhe o XML efetivamente transmitido ao suporte para esclarecer a divergência.

Preenchimento automático persistente. Corrija a origem do valor e a condição que o inclui no XML. Verifique uma nova geração antes de transmitir, incluindo a distinção entre os modelos e formatos atendidos pelo mesmo emissor.

Exemplo: um agendamento copiado para o XML

Em uma loja fictícia de utensílios, o cliente combina retirar uma compra no sábado. Suponha que o responsável fiscal já tenha considerado adequada a emissão de NFC-e para essa operação. A integração copia a data da retirada para dhSaiEnt, e a transmissão recebe 705.

O tratamento esperado é preservar o agendamento no pedido e corrigir a integração para gerar a NFC-e sem o campo indevido. O suporte deve conferir a nova geração e a data verdadeira de emissão. O exemplo ilustra um erro de montagem; não demonstra que qualquer venda com retirada ou entrega pode ser documentada por NFC-e.

Confirme o resultado da correção

Após o ajuste, gere e assine o documento pelo fluxo normal do emissor. Editar manualmente um XML já assinado não substitui esse processo. Preserve o arquivo rejeitado e o retorno anterior para permitir a comparação com a nova tentativa.

Examine a resposta individual da nota e guarde o protocolo quando houver autorização. O recebimento de um lote ou o desaparecimento da mensagem 705 não comprovam, isoladamente, que a emissão foi concluída. Se aparecer outro código, investigue a condição específica indicada por ele.

Acione o suporte quando a data reaparecer, a fila usar um arquivo antigo ou o retorno não corresponder ao XML disponível. Envolva o responsável fiscal quando houver dúvida sobre modelo, formato ou enquadramento da operação. A correção deve tratar o preenchimento indevido e preservar os registros verdadeiros da empresa, sem modificar outros dados para tentar obter autorização.

Fontes

1. NT 2026.002 v1.11 — SVRS: páginas 3, 7 e 8, cronograma, tpImp e B10-10.

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

3. Schemas oficiais de NF-e/NFC-e: pacote PL_010f v1.04, declaração de dhSaiEnt no leiaute.

4. Apoios específicos: Oobj, TecnoSpeed e Webmania. Seus procedimentos particulares não substituem a regra oficial ou a conferência do XML gerado.