Código 683: diagnóstico e solução por cenário

A rejeição 683 indica, nos cenários tratados aqui, que a chave de um documento referenciado contém o número desse documento zerado. A correção começa pela recuperação da referência verdadeira. Não basta substituir os zeros por um número qualquer ou usar o número da NF-e que está sendo emitida.

Este artigo trata da autorização de NF-e, modelo 55, com referências em refNFe, refCTe ou refNFeSig. Confira sempre a mensagem completa recebida, o campo utilizado e a versão da documentação. Procurar somente o código em uma lista antiga pode levar a uma orientação que não corresponde ao retorno atual.

Localize a ocorrência e o campo

Guarde a resposta da Sefaz e o XML transmitido. A indicação nOcor ajuda a localizar a ocorrência no grupo de documentos referenciados. Se houver várias referências, examine cada uma sem assumir que o documento destacado na tela seja aquele efetivamente enviado naquela posição.

O MOC e a NT 2022.003 v1.11 apresentam três verificações de número zerado, todas classificadas como facultativas para NF-e modelo 55:

O modelo 55 nessa classificação identifica a nota em emissão. No segundo cenário, o documento referenciado é um CT-e. A existência desse campo não permite inserir uma chave de transporte em qualquer outro campo nem dispensa a pertinência da referência à operação.

A classificação facultativa também não autoriza preencher um número fictício. Ela deve ser considerada na análise da aplicação da regra pelo autorizador, sem prometer comportamento idêntico em toda UF e em homologação ou produção.

Número da nota e código numérico são campos diferentes

Na composição da chave da NF-e, o número do documento, identificado como nNF, ocupa nove posições. O código numérico, cNF, ocupa oito posições e é outro componente. O dígito verificador também é separado. Confundir esses elementos é especialmente perigoso quando a referência usa refNFeSig.

O segmento 000000734 representa o número 734 com zeros à esquerda. Ele é diferente de 000000000, que representa o número zerado. Esses segmentos são apenas exemplos de leitura do número; não são chaves completas nem podem ser usados como identificadores de documentos reais.

No referenciamento em sigilo, zerar o código numérico faz parte da finalidade do campo. Isso não significa zerar o número da nota. A BA02a-70 verifica o número do documento, enquanto a BA02a-74, associada à rejeição 955, trata do código numérico que deveria estar zerado nessa referência. As duas condições não devem ser trocadas.

Recupere o documento antes de corrigir

Compare a referência transmitida com o XML autorizado do documento de origem ou com outra representação confiável de sua chave. Confira o emitente, o modelo, a série e o número para assegurar que o documento recuperado é aquele relacionado à operação.

Se uma integração produziu a chave a partir de campos separados, verifique como o número de origem chegou à montagem. Um campo não preenchido ou um mapeamento incorreto pode ter sido transformado em zeros. Essas são hipóteses a investigar no caso concreto, não causas universais demonstradas pelo retorno 683.

Quando a referência completa foi copiada incorretamente, substitua-a pela chave verdadeira do documento cabível. Não troque apenas o trecho zerado e recalcule o dígito para criar uma sequência aparentemente válida. A consistência formal da sequência não prova a existência do documento nem sua relação com a operação.

Também não remova uma referência obrigatória para conseguir transmitir. Se o documento correto não estiver disponível ou houver dúvida sobre qual nota deve ser referenciada, esclareça a origem da operação antes de prosseguir.

Cuidado específico com a referência em sigilo

O uso de refNFeSig depende de suas próprias condições. A NT 2022.003 o apresenta como recurso para preservação do sigilo fiscal, não como substituto geral da chave completa. Nas devoluções, complementações e situações em que a legislação exigir, a referência pela chave completa continua obrigatória.

Portanto, um exemplo que associe devolução a refNFeSig não deve ser reproduzido como modelo de correção. Não altere a finalidade da nota, o tipo da operação ou o documento de origem para manter um campo inadequado. A configuração deve refletir o caso fiscal verdadeiro.

Na situação em que a referência em sigilo for cabível, a geração deve preservar corretamente a identificação do documento e aplicar o tratamento previsto ao código numérico. Essa tarefa pertence ao fluxo do emissor ou da integração; não deve ser feita por edição improvisada de um XML assinado.

Exemplo de recuperação do dado correto

Suponha que a nota de origem tenha número 734, mas uma importação tenha enviado zeros no segmento reservado ao número da referência. A conferência com o XML original mostra que o dado se perdeu durante o processamento. A equipe deve corrigir essa origem e regenerar a referência adequada, preservando os demais dados verdadeiros.

O exemplo não recomenda usar 734 em outro documento nem afirma que todos os demais campos já passaram pelas validações. Se a operação exigir chave completa, ela deve ser recuperada integralmente; se admitir referência em sigilo, suas condições continuam aplicáveis.

Reenvio e acompanhamento

Depois do ajuste, gere o XML novamente pelo emissor, confira a referência resultante e transmita. Leia o novo retorno e confirme a autorização correspondente. A ausência da mensagem 683, sozinha, não comprova que todas as referências estão válidas ou que a nota foi autorizada.

As alterações de 2026 sobre modelos de documentos referenciados têm condições e cronogramas próprios. O prazo de produção de 14/12/2026 das regras BA02-35 e VC02-40, relacionadas à 679, não adia a verificação de número zerado da 683. Não transfira datas entre regras vizinhas.

Se o problema persistir, encaminhe ao suporte a resposta completa, o XML enviado, a ocorrência apontada e o documento de origem. Isso permite separar falha de preenchimento, mapeamento e escolha do campo sem cancelar documentos válidos ou inventar uma nova numeração.

Fontes

Pesquisa em 16/10/2026. MOC 7.0 — Anexo I, páginas 79 e 81; MOC 7.0 — Visão Geral, página 19; NT 2022.003 v1.11, páginas 4–5 e 9–10; NT 2026.002 v1.11, páginas 3, 9 e 18. Os MOCs e a NT 2026.002 foram capturados em 15/10, horário de Brasília; a NT 2022.003, em 16/10.

Apoios específicos: InvoiSys, Oobj e Webmania. Exemplos de XML, generalizações sobre qualquer erro de chave e promessas de validação foram confrontados com os critérios oficiais, sem transportar menus ou rotinas de outros emissores para o ALRA.