Rejeição 253: como corrigir o dígito verificador da chave de acesso

A rejeição 253 indica que o dígito verificador não confere com a chave de acesso formada pelos dados da própria nota. A solução segura é conferir esses dados e corrigir a rotina que monta a chave. Trocar somente o último número, sem descobrir a origem da divergência, pode produzir uma chave aparentemente válida para informações erradas.

Esse diagnóstico vale para a autorização de NF-e, modelo 55, e NFC-e, modelo 65. A regra B23-10 aparece como obrigatória no MOC 7.0, Anexo I, página 77. Antes de agir, confira o retorno completo da Sefaz, o modelo e a tentativa de transmissão à qual ele pertence.

O que significa chave composta

A chave não é um número livre que o operador escolhe. Ela reúne informações do documento em posições definidas: código da UF, ano e mês de emissão, identificação do emitente, modelo, série, número da nota, tipo de emissão, código numérico e dígito verificador. No padrão atual, são 44 posições, inclusive quando há letras permitidas na parte do CNPJ.

A série ocupa três posições na chave; o número da nota, nove; o código numérico cNF, oito; e o dígito cDV, uma. O atributo Id do grupo infNFe contém o prefixo NFe seguido da chave. Esse prefixo não integra as 44 posições nem entra no cálculo do DV.

A rejeição 253 examina a chave obtida pela concatenação dos campos correspondentes. Já a rejeição 502 verifica a correspondência entre o Id e essa composição. São controles próximos, mas diferentes. O sistema pode apresentar um deles primeiro; eliminar uma mensagem não dispensa conferir a estrutura inteira.

Comece pelo arquivo que realmente foi enviado

Separe o XML transmitido, o retorno da Sefaz e o registro da operação no emissor. Não use apenas uma prévia da nota: a integração pode ter alterado campos depois de exibir a tela. Guarde também o horário, a UF, o ambiente de produção ou homologação e a versão do programa.

Peça à equipe responsável para comparar os campos do XML com os valores usados na construção da chave. Merecem atenção a data de emissão, o CNPJ ou CPF aplicável, a série, o número, tpEmis e cNF. Verifique ainda se os zeros à esquerda foram preservados e se nenhum trecho recebeu máscara, espaço ou separador indevido.

A identificação usada na composição precisa respeitar o cenário fiscal. O MOC prevê tratamento específico para nota avulsa das séries 890–899, com consideração do CNPJ da Sefaz correspondente. Por isso, uma rotina que sempre copia a identificação do emitente, sem reconhecer as exceções documentadas, também precisa de revisão.

O cálculo deve acompanhar o CNPJ alfanumérico

Não é mais seguro aplicar a orientação genérica de deixar a chave apenas com números. A NT Conjunta 2025.001 trata das letras admitidas no CNPJ e de seu impacto na chave. A NT 2026.004 v1.01 atualiza os schemas da NF-e e NFC-e. A Receita Federal confirmou a primeira inscrição alfanumérica em 31 de julho de 2026, com adoção gradual e preservação dos CNPJs numéricos já emitidos. Isso é diferente do cronograma de implantação dos schemas fiscais.

Para a equipe técnica, o exemplo oficial do Anexo II da NT Conjunta calcula o DV sobre as 43 posições anteriores a ele, usando o valor ASCII de cada caractere menos 48. Aplica os pesos de 2 a 9, repetidos da direita para a esquerda, e o módulo 11. Resultados 10 ou 11 são convertidos em zero. Cada caractere permanece uma posição de cálculo; não se deve transformar uma letra em dois novos dígitos da chave.

O empresário não precisa fazer essa conta manualmente. Precisa garantir que a biblioteca fiscal instalada implemente a especificação vigente e preserve a identificação verdadeira. Apagar uma letra legítima para satisfazer um validador antigo altera o documento e não resolve a causa.

Como corrigir sem criar outra inconsistência

1. Confirme que o retorno é 253 da autorização e identifique o XML correspondente. Se houver outra tentativa com resposta perdida, esclareça seu resultado antes de criar outro documento.

2. Confira os dados fiscais de origem. Corrija informação errada somente com base no documento, no cadastro correto e na operação real.

3. Solicite ao emissor que gere novamente a chave completa e o cDV a partir desses campos consistentes. Se o defeito estiver no programa, aplique a atualização indicada pelo fornecedor para a versão utilizada.

4. Gere e assine novamente o XML pelo fluxo normal do sistema. Uma edição posterior à assinatura compromete sua validade.

5. Valide o arquivo e transmita a tentativa corrigida no ambiente e autorizador apropriados. Leia o novo retorno e confirme a autorização antes de tratar a nota como concluída.

Não altere número, série, data ou tipo de emissão apenas para experimentar uma chave diferente. Também não é necessário trocar o certificado digital só porque apareceu uma rejeição de DV: a causa precisa ser demonstrada.

Quando o cadastro está correto, mas o erro continua

Uma possibilidade é haver duas rotinas montando a mesma nota: uma calcula a chave e outra atualiza um campo depois. Outra é a convivência de uma biblioteca fiscal atualizada com um módulo antigo de assinatura ou transmissão. Essas são hipóteses para investigação, não conclusões automáticas sobre seu sistema.

Os materiais da InvoiSys, da TecnoSpeed e da TOTVS para Protheus reforçam a necessidade de investigar a geração automática. Instruções específicas de produto não substituem a composição oficial nem devem ser aplicadas em outro ERP.

Para encerrar o atendimento, registre qual campo ou rotina estava incorreto, qual atualização foi aplicada e qual protocolo corresponde ao arquivo autorizado. A prevenção consiste em manter uma única origem consistente para os dados da nota e conservar os arquivos efetivamente enviados.

Conferência documental: 9 de outubro de 2026. Cronogramas de schema e validação devem ser verificados por ambiente e autorizador; a publicação de uma nota técnica não comprova, isoladamente, o comportamento de todas as UFs.