Rejeição 492 na NF-e: como conferir a versão do evento

A rejeição 492 indica que a versão informada para o evento não foi aceita. Isso pode impedir o registro de um cancelamento, de uma manifestação ou de outra comunicação vinculada ao documento fiscal. A correção começa no XML transmitido e na especificação daquele evento, não na escolha de um número de versão por tentativa.

Para o empresário, a pergunta útil ao fornecedor é: “Qual versão do detalhe foi enviada e qual é aceita por este serviço, para este evento e ambiente?”. Dizer apenas que o sistema está atualizado não responde a essa pergunta.

Versões parecidas têm funções diferentes

O MOC 7.0, Anexo I, página 73, determina que o esquema XML seja escolhido pela combinação entre tpEvento e verEvento. A regra D05 verifica a validade de verEvento; D04 trata do tipo e D06 verifica o conteúdo de detEvento.

Há várias referências a versão em uma integração, e elas não devem ser igualadas automaticamente:

• A versão da Nota Técnica identifica uma revisão documental. NT 2020.001 v1.60 não significa que todos os eventos devam informar verEvento=1.60

• A versão do XML da NF-e identifica o leiaute da nota. Não é, necessariamente, a versão de seu evento

• Os atributos versao do lote e do elemento evento identificam os respectivos leiautes de transporte

• verEvento identifica a versão do detalhe; detEvento possui seu próprio atributo versao, relacionado a ela conforme o contrato

• O esquema XSD valida a estrutura correspondente. Seu pacote de distribuição pode mudar sem que todos os eventos mudem de versão

• A versão do Web Service, da biblioteca ou do ERP e o campo verAplic descrevem outras camadas. Um serviço com “4” no nome não exige verEvento=4.00

Essas diferenças são documentadas nos campos dos eventos, inclusive no EPEC e na manifestação. Não substitua todas as ocorrências de “versão” pelo mesmo valor. MOC, página 73

O alcance muda conforme o serviço

A regra comum é reutilizada por contratos diferentes. Foram conferidos, além do MOC:

• Manifestação do destinatário da NF-e 55: eventos 210200/210210/210220/210240, NT 2020.001 v1.60

• EPEC 110140: NT 2014.001 v1.41 para NF-e 55; NT 2014.003 v1.02 para NFC-e 65, cuja implementação depende da UF

• Prorrogação de suspensão do ICMS e seus cancelamentos, 111500 a 111503; respostas do Fisco, 411500 a 411503. A NT 2015.001 v1.30 documenta adoção por SP e MG, com a implementação nova de solicitação completa específica de MG

• Comprovante de entrega 110130/110131 e insucesso 110192/110193 da NF-e 55, nas NTs 2021.001 v1.01 e 2023.005 v1.02

• Ator interessado 110150, NF-e 55, NT 2020.007 v1.40; atendimento definido no Ambiente Nacional

• Cancelamento por substituição da NFC-e 65, 110112, NT 2018.004 v1.00; e conciliação financeira 110750/110751, modelos 55/65, NT 2024.002 v1.00

O BT 2018.002 v1.00 também enumera 492 no Visto Eletrônico do Fisco, 400300/400301. No ECONF, a NF-e 55 usa a SVRS para contribuintes de todas as UFs; a NFC-e 65 usa o serviço próprio da UF. Saber esse destino é parte da investigação, pois um XML correto para determinada integração não comprova compatibilidade com outra.

As revisões acima são referências documentais preservadas, lidas em outubro de 2026. Não representam certificação de implantação em cada autorizador. A versão aplicável precisa ser confirmada com o serviço utilizado.

Um exemplo de confusão comum

Imagine que o ERP foi atualizado para uma nova revisão fiscal e passou a preencher verEvento com a versão da própria aplicação. A nota original pode continuar autorizada, mas o evento será montado com uma identificação que o recebedor não reconhece.

Nesse caso, voltar o ERP inteiro para uma versão antiga não é a primeira providência. O suporte deve localizar a configuração ou transformação responsável pelo campo e gerar o evento conforme o contrato correto. Se o leiaute exigir 1.00, esse é o valor a usar porque a especificação o exige, e não porque costuma aparecer em exemplos de internet.

Um relato histórico de 2017 no Projeto ACBr descreve justamente uma alteração no preenchimento da versão pelo componente. Ele é útil para lembrar que atualizar a biblioteca não garante o preenchimento correto na aplicação. Não serve como instrução para instalar uma versão antiga ou reutilizar código daquele período.

Roteiro para resolver a rejeição

1. Separe o XML enviado e a resposta original. Identifique cStat, xMotivo, tpEvento, verEvento, os atributos versao, modelo, UF, ambiente e serviço

2. Confirme a especificação e os XSDs aplicáveis ao evento. Compare a versão aceita em produção com a de homologação; uma implantação pode ocorrer em datas diferentes

3. Peça ao fornecedor que verifique a configuração efetivamente carregada. É possível atualizar um pacote e manter a aplicação usando esquemas ou parâmetros de outra pasta

4. Corrija o gerador ou a integração, preservando o tipo de evento e o fato comunicado. Não troque uma manifestação por outra nem transforme um cancelamento em CC-e

5. Gere novamente o XML e valide sua estrutura. Confira a coerência entre verEvento e o detalhe conforme a especificação. Se houve alteração de conteúdo assinado, a assinatura deve ser refeita pelo sistema

6. Consulte o histórico e reconcilie resultados de tentativas anteriores antes de retransmitir. Uma falha de comunicação pode ter escondido um registro já realizado

7. Verifique o retorno individual e guarde o protocolo. “Lote processado” não substitui a confirmação do evento solicitado

Se o retorno passar a ser 493, o diagnóstico mudou: o problema pode estar no formato ou nos campos do detalhe. Evite continuar alterando verEvento quando a mensagem aponta outra validação.

O que pedir em uma atualização

Solicite que o fornecedor registre, para cada evento usado pela empresa, o par tipo/versão, os esquemas carregados e os ambientes testados. O teste deve acompanhar a operação completa, incluindo a consulta do resultado.

Campos recém-documentados não são automaticamente obrigatórios. A NT 2026.006, relativa ao evento 110300, apresenta datas distintas nas cópias oficiais consultadas e mantém caráter preparatório para o split payment, sem exigência de preenchimento em produção em 2026. Ela não justifica trocar versões de eventos já existentes nem pressupor que o novo serviço esteja universalmente ativo.

Fontes práticas consultadas

A pesquisa leu Projeto ACBr, relato sobre 492, TecnoSpeed, validação de esquema do evento e Senior, geração de ECONF. Os dois últimos são guias contextuais, não soluções específicas de 492. Seus exemplos ajudam a separar campos e etapas, mas não substituem o leiaute oficial nem devem ser copiados integralmente.