Rejeição 491 na NF-e: confira o tipo de evento e o serviço usado

A rejeição 491 pode aparecer quando o sistema tenta registrar uma Carta de Correção, um cancelamento ou outro evento e o tipo informado não é aceito naquele processamento. O primeiro cuidado é identificar qual evento foi enviado, para qual serviço e em qual ambiente. Um código existente na tabela de eventos pode estar sendo encaminhado ao lugar errado.

Para a empresa, isso significa que a providência solicitada ainda precisa ser conferida. Uma rejeição de evento não prova que a NF-e original perdeu sua autorização. Não emita outra nota nem altere o fato que pretendia comunicar apenas para eliminar a mensagem.

O que a SEFAZ está validando

No MOC 7.0, Anexo I, página 73, a regra D04 verifica a validade de tpEvento. A escolha do esquema de validação combina esse tipo com verEvento, a versão do detalhe. São verificações diferentes: 491 trata do tipo; 492, da versão; 493, da adequação do conteúdo específico ao esquema XML.

Guarde a resposta completa, com cStat e xMotivo, e o XML efetivamente transmitido. Se o lote estiver processado, confira o resultado individual de cada evento: a situação geral do lote não confirma, sozinha, que todas as solicitações foram registradas. Essa separação evita que uma tela de “envio concluído” encerre um problema ainda aberto. MOC, página 73

Em quais eventos esse diagnóstico aparece

O contrato técnico é a especificação aplicável ao serviço, modelo e evento. Os documentos oficiais consultados registram 491 em diferentes famílias:

• Cancelamento e CC-e: 110111 e 110110. O cancelamento por substituição, 110112, tem requisitos próprios; a NT 2018.004 descreve originalmente esse procedimento para NFC-e, modelo 65

• EPEC, 110140: a NF-e modelo 55 usa a NT 2014.001 v1.41; a NFC-e modelo 65 possui contrato separado, NT 2014.003 v1.02, cuja adoção e vigência dependem da UF

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

• Prorrogação de suspensão do ICMS: pedidos 111500/111501 e cancelamentos 111502/111503. As respostas 411500 a 411503 pertencem ao Fisco. A NT 2015.001 v1.30 cita São Paulo e Minas Gerais; a nova implementação de solicitação completa tem cronograma específico de MG

• Comprovante de entrega 110130/110131, insucesso na entrega 110192/110193 e ator interessado 110150: contratos de NF-e modelo 55 das NTs 2021.001 v1.01, 2023.005 v1.02 e 2020.007 v1.40, respectivamente

• Conciliação financeira 110750/110751: a NT 2024.002 v1.00 separa o atendimento da NF-e 55, na SVRS para todas as UFs, daquele da NFC-e 65, no serviço de eventos da própria UF

Também há contratos exclusivos do Fisco, como o Visto Eletrônico, eventos 400300/400301, no BT 2018.002 v1.00. Essa relação ajuda a localizar a documentação; não transforma todos os eventos em opções disponíveis para qualquer nota. Um destinatário não deve escolher um evento do emitente, e uma empresa não pode se apresentar como o Fisco.

O ramo específico de eventos com PAA

A NT 2026.001 v1.02b acrescenta uma situação importante. Na regra P80-40, modelo 55, se o grupo infPAA estiver informado e o tipo não for 110111, 110112 ou 110110, ocorre 491. A implementação dessa regra é indicada somente na SVRS.

O quadro possui uma revisão visual: o texto antigo “O tpEvento informado inválido” está riscado; a mensagem passa a ser “Tipo de Evento inválido para o ambiente de autorização”. As páginas 17 e 18 precisam ser lidas em conjunto.

Nesse cenário, revise com o fornecedor se o evento, o autor e as informações do Provedor de Assinatura e Autorização correspondem à operação. A lista da P80-40 não concede, por si, permissão para usar cada evento. Também não autoriza remover infPAA indiscriminadamente de uma operação que o exige. NT do PAA, páginas 17–18

Quando o código está certo e o destino está errado

Uma CC-e pode estar identificada corretamente como 110110 e, ainda assim, ser encaminhada para a Sefaz Virtual de Contingência. O Manual de Contingência distingue os serviços: prevê cancelamento de notas autorizadas pela própria SVC, mas não disponibiliza inicialmente CC-e e outros eventos nesse ambiente.

Portanto, confira o destino da transmissão e o compartilhamento da nota antes de tentar novamente no serviço adequado. A orientação prática de aguardar sincronização precisa vir acompanhada dessa conferência. Repetir indefinidamente a mesma CC-e na SVC não corrige o encaminhamento. MOC, Anexo III, páginas 10–11

Como corrigir sem criar outro problema

1. Identifique a providência real: corrigir uma informação permitida, cancelar uma nota, manifestar uma compra ou registrar outro fato. Confirme também quem é seu autor legítimo

2. Solicite ao suporte o tpEvento transmitido, a chave, o modelo, a UF, tpAmb e o endereço do serviço. O nome do botão no ERP não substitui esses dados

3. Compare o XML com a especificação vigente daquele evento. Se o sistema gerou o código errado, corrija o mapeamento na origem; se enviou ao serviço errado, ajuste o encaminhamento previsto para aquele contrato

4. Regenere e valide o evento no emissor. Alterar um XML já assinado pode invalidar a assinatura e gerar uma rejeição diferente

5. Antes da retransmissão, consulte o histórico disponível e reconcilie tentativas anteriores, principalmente se houve demora ou perda de resposta. Preserve o número sequencial conforme as regras do evento

6. Confira o retorno individual e arquive o protocolo correspondente. O encerramento deve refletir o que a SEFAZ efetivamente registrou

Por exemplo, uma compra desconhecida não pode receber “Confirmação da Operação” só porque esse tipo passou na validação. Corrigir a identificação técnica deve preservar o significado fiscal da declaração.

Como prevenir a reincidência

Peça ao fornecedor uma matriz de eventos por modelo, autor, ambiente e versão, com teste após atualizações. Novos eventos também exigem cautela: a NT 2026.006 prevê o 110300, mas as cópias oficiais consultadas apresentam cronogramas diferentes e qualificam os campos de split payment como preparatórios, sem exigência de uso em produção em 2026. A data de uma tabela não demonstra disponibilidade universal.

Fontes práticas consultadas

Foram lidos três editores independentes: TecnoSpeed, sobre identificação do evento; Sankhya, sobre conferência do XML; e Omie, sobre CC-e e contingência. Suas orientações foram delimitadas pelos contratos oficiais, sem tratar espera ou troca de código como solução universal.