Rejeição 619: como tratar número da nota zerado na chave de acesso

A rejeição 619, “Chave de Acesso inválida (número NF = 0)”, aponta que o trecho da chave destinado ao número do documento está zerado. Antes de mudar qualquer cadastro, identifique a solicitação recusada. O retorno aparece em consulta, distribuição e diferentes eventos; não significa, por si só, que a nota original deixou de estar autorizada.

A solução segura é recuperar a chave correta do documento pretendido ou corrigir a origem de sua geração quando o fluxo realmente exige isso. Não substitua os zeros por 1, não reinicie o contador da série e não emita uma segunda nota apenas para desaparecer o aviso.

Qual número está sendo verificado?

Na chave de 44 posições, o número da NF-e ou NFC-e ocupa as posições 26 a 34, totalizando nove caracteres. O segmento 000000000 representa número zero. Já um número como 123 aparece preenchido à esquerda até completar o tamanho: 000000123. Ter zeros de preenchimento não é a mesma coisa que ter o número inteiro zerado. MOC 7.0, Visão Geral, página 19

Esse componente corresponde a nNF. Ele não é a série, o código numérico cNF, o número do protocolo ou a sequência nSeqEvento. Uma alteração na sequência do evento não preenche o número que falta na chave da nota.

Também não se deve condenar qualquer chave que contenha uma sequência de zeros. O leiaute usa preenchimentos próprios, e existem referências específicas com código numérico zerado. Isso é diferente de zerar nNF. A leitura precisa localizar o componente correto, sem reconstruir o documento por adivinhação.

Localize primeiro o serviço que respondeu

Na consulta de situação NfeConsultaProtocolo, a regra J02g retorna 619 quando o número na chave é zero. A requisição consSitNFe informa chNFe; não transmite uma nova nota para autorização. Alterar o número de uma venda no cadastro do ERP pode, portanto, não atingir a causa daquela consulta. MOC, páginas 82–83

Na distribuição NFeDistribuicaoDFe, a regra H13 tem a mesma verificação, aplicada ao tipo consChNFe. O sobrescrito 2 da tabela remete a essa condição; não transforma a regra em validação geral das consultas distNSU e consNSU. Esse contrato é de NF-e modelo 55, mesmo que outro serviço permita consultar a situação de uma NFC-e. NT 2014.002 v1.40, página 11

Nos eventos, a parte geral do MOC usa P12-34, sobre chNFe. Cancelamento e CC-e seguem essa base, acrescida das condições do tipo solicitado. Um evento rejeitado por chave malformada não cancela a nota nem registra a correção pretendida. Também não habilita CC-e para NFC-e.

Um roteiro para a equipe de faturamento

1. Preserve o XML enviado e o retorno. Registre cStat, xMotivo, chave, ambiente, horário, UF e versão da integração; em eventos, anote o tipo e a sequência

2. Localize o documento de origem pelo pedido, emitente, série, número e data. Compare o XML preservado e seu protocolo, evitando confiar apenas no nome do arquivo

3. Confira o trecho de nove posições e a chave completa. A tela pode mostrar o número correto enquanto a integração transmite uma chave antiga ou incompleta

4. Identifique a etapa defeituosa: importação, seleção do documento, montagem do pedido ou geração de chave. Peça ao suporte que mostre a divergência efetivamente transmitida

5. Se for consulta ou evento de documento existente, substitua o vínculo incorreto pela chave autêntica. Preserve o XML autorizado e gere novamente apenas a solicitação necessária

6. Se houve envio anterior sem resposta conclusiva, recupere os registros e verifique o processamento antes de retransmitir. Ausência de resposta não prova rejeição

7. Confira o novo retorno e arquive a evidência correspondente. A mudança de mensagem não demonstra conclusão do procedimento

Compartilhe arquivos fiscais somente pelo canal privado adequado. Para reproduzir defeitos de integração em homologação, use dados de teste próprios desse ambiente, sem transformar uma chave fictícia em referência de produção.

Dois exemplos de origem do problema

Uma empresa importa um XML de compra, mas o módulo de manifestação usa uma chave montada antes de receber o número da nota. O faturamento enxerga 123 na tela, enquanto a chave enviada tem o segmento numérico zerado. O reparo é alinhar a importação e a solicitação à chave original da compra, não mudar a numeração do fornecedor.

Em outro cenário, uma rotina prepara dados para EPEC com uma estrutura incompleta. Nesse fluxo, a nota pode ainda não estar autorizada. A equipe precisa conferir a numeração efetivamente reservada, os registros anteriores e o contrato da contingência antes de gerar o evento coerente. Não há autorização para escolher um número livre por tentativa. Registro de EPEC e autorização da nota são etapas diferentes.

Esses são exemplos de investigação, não causas presumidas em todo caso. A conferência dos arquivos é que demonstra se houve preenchimento automático com zeros, reaproveitamento de dados ou seleção incorreta.

Quais eventos precisam de cuidado adicional?

A verificação de número zero está documentada na manifestação do destinatário, NT 2020.001 v1.60, e em ECONF e seu cancelamento, NT 2024.002 v1.00. A validação da chave não substitui as condições de autoria e modelo: manifestação é tratada no contrato da NF-e; ECONF contempla NF-e/NFC-e com encaminhamento próprio.

Comprovante de entrega, 110130/110131, e insucesso na entrega, 110192/110193, também têm P12-34, nos contratos das NTs 2021.001 v1.01 e 2023.005 v1.02. Esses eventos são de NF-e 55. Prorrogação de industrialização, seus cancelamentos e respostas do Fisco usam a mesma ideia em linhas identificadas como P11 na NT 2015.001 v1.30, que descreve adoção por SP/MG. As respostas fiscais e o Visto Eletrônico 400300 e seu cancelamento 400301 são ações do Fisco.

No Ator Interessado 110150, a NT 2020.007 v1.40 traz uma ressalva decisiva: P12-34 tem o marcador (*1), cuja nota limita a aplicação a tpAutor=1, o emitente. Não estenda essa condição aos tipos 2 e 3 nem altere a autoria para contornar uma rejeição. NT 2020.007 v1.40, páginas 9–10

O EPEC 110140 tem contratos separados: NT 2014.001 v1.41 para NF-e 55 e NT 2014.003 v1.02 para NFC-e 65, cuja adoção depende da UF. Não generalize a disponibilidade da contingência entre estados e modelos.

Como prevenir e confirmar a solução

Mantenha a chave como identificador textual, preserve seus caracteres e evite conversão por planilhas. A NT 2026.004 v1.01 atualiza campos para CNPJ alfanumérico; remover letras indiscriminadamente não é uma limpeza segura. Gere consultas e eventos a partir do documento correto, com rastreabilidade até o arquivo de origem.

Em eventos, cStat 128 informa processamento do lote, não sucesso individual. Confira o resultado de cada solicitação e seu protocolo. Consulta pública por QR Code tem contrato diferente; referências antigas ao serviço de download também não substituem as regras atuais de distribuição.

Fontes e escopo

Base oficial preservada em 09/10/2026 e relida em 10/10/2026, sem teste de implantação por UF. Contratos RTC/PAA foram separados dos eventos anteriores; a NT 2026.006 v1.00 tem calendários oficiais divergentes, sem presunção de ativação universal.

Apoio prático efetivamente lido: NDD, Berga e NS7. Foram aproveitadas a localização do número e a investigação da geração; recomendações genéricas de reiniciar numeração, regerar chave ou reemitir não se aplicam automaticamente a documento existente.