Rejeição 785: confira a versão da regra antes de alterar a entrega

Se o emissor mostra o código 785, preserve a mensagem completa e confirme de onde ela veio. O significado histórico é uma restrição estadual à entrega em domicílio com NFC-e. Entretanto, a documentação de 2026 mudou: repetir uma orientação antiga pode levar a empresa a registrar uma venda de forma incorreta.

O primeiro cuidado é não transformar uma entrega real em operação presencial apenas para eliminar o aviso. A correção precisa representar o que aconteceu. Antes de mudar a nota, o suporte deve verificar o XML, a origem do retorno e a versão das regras utilizada pelo emissor.

O que o código significava e o que mudou

No MOC 7.0, Anexo I, a regra B25b-30 relaciona o 785 à NFC-e, modelo 65, com entrega em domicílio não permitida pela UF. A configuração estadual fazia parte da condição. Isso não significava que todas as UFs proibiam a entrega, embora a regra estivesse marcada como obrigatória no manual.

Na NT 2026.002 v1.10a, página 9, essa linha aparece integralmente riscada. Na versão 1.11, a tabela correspondente já não apresenta a B25b-30. A conferência foi feita tanto no texto quanto na aparência dos PDFs oficiais, pois a extração textual isolada conserva palavras de linhas riscadas e pode induzir a erro.

Assim, a base documental atual não sustenta apresentar a regra antiga como exigência vigente de aplicação geral. Ao mesmo tempo, a retirada documental não demonstra, sozinha, o comportamento de cada servidor e instalação. Se o código ainda chegar, registre a data, a UF, o ambiente e a resposta original para esclarecer a ocorrência.

A rejeição veio da SEFAZ ou de uma validação local?

Uma tela pode mostrar mensagens produzidas pelo próprio sistema antes da transmissão. Também pode reapresentar um retorno antigo guardado no histórico. Essas situações pedem tratamentos diferentes de uma resposta recebida agora do autorizador.

Peça ao suporte que confira se houve efetivamente uma requisição e uma resposta do serviço de autorização. Registre o horário, a chave, o código e o motivo devolvidos. Se o bloqueio ocorreu antes do envio, investigue a tabela de validações da aplicação ou da integração. Não atribua à SEFAZ uma mensagem criada localmente.

Se houver resposta recente do autorizador com 785, preserve o conteúdo integral e o endereço acessado. Confira se a tela está vinculada àquela tentativa e ao estabelecimento correto. Um retorno de homologação, um teste antigo ou uma filial diferente não deve ser usado como prova do comportamento atual da produção.

Quais dados reunir para o diagnóstico

O atendimento fica mais objetivo quando a equipe reúne:

• XML da tentativa e retorno original, com os horários correspondentes;

• modelo do documento, UF do emitente e ambiente de transmissão;

• valores de ide/indPres e ide/tpImp presentes no arquivo;

• versão do emissor e da integração que gerou o XML;

• descrição real da venda: como foi realizada e como a mercadoria será entregue.

No contexto histórico do 785, o indicador de presença ligado à entrega era o ponto principal. A NT 2026.002 também atualiza o campo e regras vizinhas para contemplar a NF-e com DANFE Simplificado Tipo 2. Isso exige conferir o conjunto modelo, impressão e operação; não autoriza estender automaticamente o antigo 785 à NF-e modelo 55.

Compare o arquivo transmitido com o pedido. Uma opção correta na tela não garante que a integração tenha enviado o valor correspondente. Identifique em que etapa a informação mudou: cadastro, importação, transformação dos dados ou geração do XML.

Como agir sem descaracterizar a venda

O sistema aplica uma regra antiga antes de transmitir

Solicite ao fornecedor a revisão da validação local com base nas versões oficiais da NT. A equipe técnica deve identificar o componente responsável e corrigir sua implementação. Simplesmente esconder o aviso na interface não resolve uma integração que continua produzindo ou bloqueando dados inadequados.

Depois da atualização, confira a nota preparada e faça a transmissão pelo fluxo normal do emissor. Guarde a versão instalada e o resultado. O atendimento só se encerra com a situação fiscal da nota esclarecida, não apenas com o desaparecimento da mensagem local.

O pedido foi classificado incorretamente

Se as evidências mostram que o indicador não representa a operação, corrija a origem do preenchimento. Uma venda efetivamente presencial pode exigir um ajuste diferente de um pedido feito para entrega. O suporte e o responsável fiscal devem conferir o enquadramento aplicável antes de escolher o valor.

Não use uma substituição automática de indPres=4 por indPres=1 para todas as notas. Também não apague o endereço de uma entrega real. Altere os dados pelo emissor, gere o arquivo e sua assinatura novamente e preserve a tentativa anterior; não edite diretamente um XML assinado.

O autorizador devolveu 785 em uma tentativa atual

Com a operação e o arquivo conferidos, encaminhe a evidência ao suporte e, quando necessário, ao atendimento da SEFAZ. Informe as versões documentais comparadas e peça a confirmação da regra aplicada naquele serviço. Repetir o mesmo envio sem diagnóstico tende a produzir novas falhas, sem esclarecer a divergência.

A escolha de outro documento fiscal depende das características da operação e das regras aplicáveis. Não basta trocar o número do modelo em um arquivo nem emitir outra nota sem verificar o histórico da primeira. Se já houver documento autorizado para a venda, o tratamento precisa considerar essa situação para evitar duplicidade.

Exemplo de atendimento

Uma loja recebe um pedido para entrega. Depois de uma atualização, o caixa continua exibindo 785. O suporte verifica os registros e descobre que a mensagem foi gerada por uma biblioteca antiga, antes de qualquer chamada à SEFAZ.

A equipe preserva a informação verdadeira da entrega e corrige a validação local. Em seguida, confere o XML gerado, transmite a nota e acompanha o resultado. Se surgir outra rejeição, trata a nova causa. A retirada do bloqueio antigo não garante que todas as demais validações serão atendidas.

Como confirmar a conclusão

Verifique a resposta final vinculada à chave correta e guarde o protocolo quando houver autorização. Se persistir divergência entre documentação e retorno, mantenha o caso aberto com evidências, em vez de classificar a nota como resolvida apenas porque a tela mudou.

Para prevenir recorrências, registre qual componente aplicava a regra antiga e revise as integrações que compartilham essa versão. A correção deve alcançar a origem do problema, preservando a descrição real de cada operação.

Fontes e alcance

Conferência documental por IA em 15/10/2026. Não houve teste de emissão por UF ou ambiente.

• MOC 7.0, Anexo I, página 77: contexto histórico da B25b-30.

• NT 2026.002 v1.10a, página 9: linha 785 riscada; versão 1.11, páginas 3, 7 e 9.

• Comparação de orientações práticas anteriores: Oobj, TecnoSpeed e NDD. A recomendação genérica de mudar a operação para presencial não foi adotada.