Rejeição 810: resposta do Fisco incompatível com o tipo do pedido

A rejeição 810 informa que o tpEvento da resposta do Fisco não corresponde ao tipo do pedido de prorrogação ou de cancelamento relacionado. O problema está na ligação entre dois eventos: a solicitação original e a resposta fiscal. Conferir somente a chave da NF-e não é suficiente, porque uma mesma nota pode ter pedidos de tipos diferentes em seu histórico.

A mensagem prevista é: “tpEvento do Evento Fisco não corresponde ao tpEvento do Evento de Pedido de Prorrogação ou de Cancelamento”. Preserve o retorno completo e identifique a mensagem efetivamente enviada antes de qualquer ajuste. A rejeição desse evento não demonstra que a NF-e original deixou de existir ou que sua numeração ficou disponível para outra emissão.

Qual relação a SEFAZ verifica

A NT 2015.001 v1.30 apresenta a validação P13/P19, obrigatória, na seção do evento Fisco de prorrogação da suspensão do ICMS. O campo P13 identifica o tipo da resposta fiscal. O campo P19, chamado idPedido, aponta para o evento original que motivou essa resposta.

A tabela da nota técnica estabelece os seguintes pares:

Essa tabela não autoriza o contribuinte a produzir as respostas iniciadas por 4115. A especificação atribui o evento Fisco à UF que processou a solicitação e exige assinatura com o certificado da Secretaria da Fazenda. À empresa cabe apresentar seu pedido e acompanhar a decisão correspondente.

O contexto é a NF-e modelo 55. A própria seção valida a chave e rejeita modelo diferente de 55. Não aplique esses pares a outros documentos fiscais apenas porque o sistema apresentou o mesmo número de rejeição.

O papel do identificador do pedido

O idPedido deve corresponder ao Id do evento original, formado pela literal ID, seu tipo, a chave da NF-e e a sequência. Assim, ele identifica uma solicitação específica. Não deve ser preenchido com o número do pedido comercial, a chave isolada da nota ou o protocolo de registro.

Há duas verificações complementares no diagnóstico: a resposta deve ter o tipo adequado à operação, e a referência deve apontar para o pedido efetivamente pretendido. Um tipo correto para determinado pedido pode ficar incompatível quando a referência aponta para outro. Inversamente, uma referência correta pode receber uma resposta gerada com o tipo errado.

Não altere o pedido original para fazê-lo combinar com uma resposta incorreta. Primeiro reconstrua o histórico real, incluindo solicitações, cancelamentos, protocolos e decisões. Essa conferência também evita confundir um cancelamento de pedido de prorrogação com o cancelamento da própria NF-e, que é outra operação.

Como investigar e encaminhar

1. Reúna os dois lados da relação. Localize o XML da solicitação original e seu retorno, além da mensagem que apresentou o 810. Registre chave, UF, ambiente, tpEvento, sequência e idPedido. Confirme que os arquivos pertencem à mesma operação e não vieram de uma tentativa de homologação usada como referência em produção.

2. Identifique o pedido apontado. Verifique qual evento o idPedido realmente referencia e qual seu tipo registrado. Não deduza o tipo apenas da descrição exibida pelo emissor: uma tela pode apresentar um nome resumido enquanto o XML contém outro código.

3. Compare o par com a tabela oficial. Para um pedido 111501, por exemplo, a resposta correspondente é 411501. Se o arquivo de resposta usa 411500, há diferença entre primeiro e segundo prazo. Se a referência aponta para 111502, trata-se de cancelamento de pedido, com outro par previsto.

4. Encaminhe o reparo ao responsável pela origem da falha. O suporte pode investigar seleção indevida de histórico, montagem de referência ou roteamento do evento. Quando a inconsistência estiver em uma resposta fiscal, a providência deve ser tratada pelo canal competente da administração tributária. O contribuinte não deve editar, assinar ou recriar essa decisão localmente.

5. Confira a cadeia após o ajuste. Preserve os arquivos anteriores e analise o novo resultado individual. Corrigir a correspondência de tipos não demonstra, por si só, que todos os requisitos foram atendidos ou que a prorrogação foi deferida. Outras validações podem apontar problemas diferentes.

Exemplo sem alteração do fato fiscal

Considere uma solicitação real de cancelamento do primeiro pedido, de tipo 111502. Uma resposta montada como 411500 representa resposta ao pedido de prorrogação, não ao seu cancelamento. O diagnóstico deve apontar essa incompatibilidade para quem mantém o fluxo fiscal.

O par documental previsto para aquela solicitação é 111502 e 411502. Isso não significa transformar manualmente um XML já assinado nem escolher uma decisão favorável. O conteúdo, a referência, a autoria e o registro precisam continuar correspondendo à operação verdadeira e ao procedimento admitido.

Registro, decisão e particularidades da UF

Não confunda o 810 com o 808, que verifica autoria do evento fiscal, nem com o 809, relacionado à existência do pedido ou ao deferimento indicado na mensagem. A conferência de um requisito não substitui os demais. Também é necessário examinar o resultado individual: 128 significa lote processado, e protocolo de registro não equivale a deferimento da prorrogação.

A NT documenta modalidades parcial em São Paulo e completa em Minas Gerais, com calendário próprio para a implementação mineira. A orientação oficial de MG consultada em 16/10/2026 acrescenta condições operacionais: pedidos totais, um evento por vez e análise do Fisco. Ela preserva encaminhamento administrativo para a segunda prorrogação quando a primeira foi autorizada pela Delegacia Fiscal antes de 01/12/2025.

Essas particularidades não mudam arbitrariamente os pares da tabela. Elas mostram por que a situação do pedido e a orientação estadual precisam ser conferidas antes de gerar outra solicitação. O procedimento adequado depende da operação real, da UF e do ambiente; não há promessa de aceitação individual neste guia.

Fontes

Base: NT 2015.001 v1.30, páginas físicas 7, 19 e 48–58, especialmente P13/P19 na página 55. Contexto estadual: SEF/MG — Pedido de Prorrogação.

Apoios efetivamente confrontados: TecnoSpeed, Senior e RWA. São dois panoramas e uma ficha do código, não três tutoriais exclusivos do 810. O código 41150 truncado em um trecho TecnoSpeed não foi reproduzido. Não houve validação de XML, assinatura, transmissão ou telas ALRA.