Rejeição 618: confira o modelo da chave e o serviço utilizado

A rejeição 618 indica que o modelo identificado na chave de acesso não atende à validação daquela solicitação. O primeiro passo é descobrir qual serviço respondeu: consulta de situação, distribuição de documentos ou registro de evento. O código, sozinho, não demonstra que uma nota anteriormente autorizada perdeu validade nem que a empresa precisa emitir outra.

Também não existe uma correção universal de “trocar para 55”. A mensagem pode mencionar modelo diferente de 55, de 65 ou de 55/65, conforme o contrato. Recuperar a chave autêntica e conferir o destino da solicitação é mais seguro que modificar seus caracteres.

Onde conferir o modelo

Na estrutura de 44 posições, o modelo ocupa as posições 21 e 22: 55 identifica NF-e e 65 identifica NFC-e. Essa localização decorre da composição apresentada no MOC 7.0, Visão Geral, página 19. A identificação do emitente vem antes; série e número vêm depois.

Compare a chave enviada com o XML e o protocolo do documento pretendido. Uma chave de outro documento pode ter o mesmo tamanho, mas isso não a torna adequada ao serviço da NF-e. Confira também o documento selecionado na tela: a venda, a nota de mercadoria e o documento de transporte podem estar associados no ERP sem compartilharem a mesma chave.

Não substitua 57 por 55 dentro de uma chave para tentar consultar a nota da mercadoria. Localize o documento correto e use sua chave completa. Se o documento procurado pertence a outra família fiscal, identifique o serviço correspondente com o suporte.

Consulta de situação e distribuição têm limites diferentes

No NfeConsultaProtocolo, a regra J02f verifica modelo diferente de 55 e 65. A requisição consSitNFe leva a chave em chNFe. Portanto, uma NFC-e não falha nessa regra apenas por ser modelo 65, embora existam outras verificações de ambiente, UF e situação. MOC, páginas 82–83

Já na distribuição NFeDistribuicaoDFe, a consulta específica consChNFe tem a regra H12, restrita ao modelo 55. O algarismo sobrescrito 2 que acompanha H12 é uma nota de aplicação à consulta pela chave; não significa que a mesma validação se aplique às consultas por NSU. A NT 2014.002 v1.40, páginas 11 e 16 preserva essa distinção.

Assim, conseguir consultar a situação de uma NFC-e não garante obter seu XML pelo serviço de distribuição da NF-e. Trocar o modelo da chave para tentar habilitar o download destruiria a identificação original e não criaria permissão de acesso.

Em eventos, leia a condição específica

A parte geral do registro de eventos traz P12-30 com validação 55/65. Ela é combinada com as regras do evento escolhido. Cancelamento normal, cancelamento por substituição, carta de correção e manifestação não são operações intercambiáveis. Por exemplo, a CC-e não é permitida para NFC-e, ainda que a chave passe pela verificação geral de modelo. MOC, páginas 103, 105–106 e 111

Alguns recortes importantes:

• Manifestação do destinatário: a NT 2020.001 v1.60 mantém P12-30 com 55/65. Essa redação genérica não autoriza oferecer manifestação de NFC-e; o contrato tratado é o da manifestação da NF-e

• ECONF e seu cancelamento, 110750/110751: a NT 2024.002 v1.00 usa P12-28 para 55/65. O encaminhamento é próprio: SVRS para NF-e e serviço de eventos da UF para NFC-e

• Prorrogação de industrialização: a NT 2015.001 v1.30 exige modelo 55 nos pedidos, cancelamentos e respostas do Fisco. A versão descreve adoção por SP e MG; não certifica disponibilidade em todos os estados

• Visto Eletrônico do Fisco e seu cancelamento, 400300/400301: o BT 2018.002 v1.00 também registra 618 para modelo diferente de 55. São eventos institucionais, não uma alternativa de correção que o contribuinte deva selecionar

Comprovante de entrega e insucesso na entrega, com seus cancelamentos, exigem modelo 55 nos contratos examinados, mas usam 450 nessa verificação. O diagnóstico não deve juntar todos os erros de modelo sob o número 618.

Duas particularidades que evitam uma conclusão errada

No evento Ator Interessado, 110150, a NT 2020.007 v1.40 risca a antiga P12-30A, que retornava 450 e restringia o modelo a 55. Na mesma página, mantém J02f com 618 e validação 55/65. É necessário considerar a rasura, não apenas o texto extraído do PDF. Essa validação não comprova disponibilidade nem distribuição de XML de NFC-e pelo serviço destinado à NF-e. NT 2020.007 v1.40, páginas 9–10

No EPEC, o mesmo tipo 110140 tem especificações distintas. A NT 2014.001 v1.41 apresenta a regra geral com texto 55/65, mas a coluna de modelo e o contrato são de NF-e 55. Para NFC-e, a NT 2014.003 v1.02 exige especificamente 65 e deixa implementação e vigência a critério da UF. Não migre entre esses contratos apenas para ultrapassar a rejeição.

Como corrigir sem mexer na nota original

1. Guarde o retorno completo, chave enviada, horário, ambiente, UF e versão da aplicação. Se for evento, inclua tpEvento e verEvento

2. Identifique a chamada efetivamente realizada. O nome “consultar nota” na tela não distingue consulta de situação de distribuição

3. Recupere o XML autêntico e compare a chave inteira. Confira se houve seleção do documento errado ou erro de importação

4. Corrija o vínculo ou o encaminhamento comprovadamente incorreto na solicitação. Preserve o XML autorizado da nota

5. Para evento rejeitado, faça o sistema gerar e assinar novamente o pedido coerente. Não edite a chave dentro de um XML assinado

6. Confira o resultado individual. Lote processado, cStat 128, não significa que todos os eventos foram aceitos

Se a chave já coincide com o original, encaminhe os registros ao suporte em canal privado. Não altere o modelo fiscal da operação por tentativa.

Versão também faz parte do diagnóstico

O MOC 5.0 limitava a consulta a 55; a NT 2013.005 ampliou sua regra para 55/65. Orientações antigas não substituem o contrato vigente. Consulta pública por QR Code, tanto de NFC-e como do DANFE Simplificado Tipo 2 da NF-e, tem regras próprias.

Eventos da RTC e do PAA também pedem conferência específica. A NT 2026.006 v1.00 remete às regras gerais do MOC, mas suas cópias oficiais preservadas têm calendários divergentes. Isso não sustenta ativação universal do evento 110300 nem sua confusão com ECONF.

Fontes e escopo

Acervo oficial preservado em 09/10/2026, relido em 10/10/2026; catálogo SVRS consultado nessa data. A análise documental não certifica implantação em cada UF.

Apoio prático efetivamente lido: NDD, Oobj e Webmania. Suas explicações de campos ajudam na triagem; orientações genéricas de emissão ou edição da chave foram delimitadas pelos contratos oficiais.