Rejeição 484: como conferir o tipo de emissão na chave do EPEC

A rejeição 484 informa que a chave de acesso enviada no EPEC contém um tipo de emissão diferente de 4. O ponto conferido é a posição 35 da chave, contando da esquerda para a direita a partir de 1. Para a empresa, isso pede uma verificação do documento efetivamente transmitido: selecionar “EPEC” na tela do emissor não prova que o evento levou a chave correspondente.

A providência inicial é guardar o XML enviado e seu retorno, interromper tentativas repetidas e verificar o histórico da operação. Alterar um dígito manualmente, gerar outra numeração ou reenviar em emissão normal pode criar uma divergência adicional, especialmente se alguma transmissão anterior já tiver sido aceita.

O que a validação realmente examina

EPEC é o Evento Prévio de Emissão em Contingência, identificado pelo tipo de evento 110140. Ele leva um resumo do documento fiscal. Seu registro é uma etapa diferente da autorização da nota completa.

Na NF-e modelo 55, a regra P12-50 da NT 2014.001 v1.41, página 11, prevê a rejeição 484 quando o tipo de emissão incorporado à chave não é 4. O leiaute do evento também explicita essa exigência no campo chNFe.

Não se trata de uma ordem para fazer toda nota usar EPEC. Trata-se de uma condição para aquele evento. Se uma nota pertence a outra modalidade, é preciso investigar por que o sistema tentou produzir um EPEC para ela e qual é sua situação fiscal antes de decidir o procedimento correto.

Separe NF-e 55 de NFC-e 65

A NFC-e possui especificação própria. A NT NFC-e 2014.003 v1.02, página 11, também apresenta P12-50 e o código 484. Nesse documento, porém, a chave é de modelo 65, e a implantação do EPEC depende da unidade federada. A coincidência do código não torna iguais os serviços de recepção.

Para NF-e 55, a especificação trata do registro no Ambiente Nacional. Para NFC-e 65, descreve ambiente de contingência estadual. São Paulo, por exemplo, informa que a ativação do EPEC em produção depende de indisponibilidade do ambiente normal. Essa orientação estadual não comprova que o serviço esteja ativo neste momento, nem vale automaticamente para outras UFs.

Também há restrições documentais recentes para o modelo 55. A NT 2014.001 v1.41 registra impedimento para emitentes do Paraná e da Paraíba, com produção prevista em 05/10/2026. Esse cronograma exige atenção à elegibilidade; não constitui teste de implantação em todos os autorizadores. Uma chave corretamente composta não supera uma restrição de uso do serviço.

Faça uma conferência em quatro etapas

1. Identifique a tentativa. Registre modelo, UF, ambiente de produção ou homologação, serviço chamado, código e mensagem completos. Peça ao suporte o XML efetivamente transmitido, não apenas a visualização atual da nota no sistema.

2. Compare documento e evento. Confira chNFe no EPEC, a chave da nota que originou o evento e o campo tpEmis dessa nota. A equipe técnica deve localizar a posição 35 sem eliminar zeros nem usar uma chave abreviada.

3. Reconstrua o histórico. Verifique respostas anteriores, protocolos, filas e consultas disponíveis. Falta de resposta na tela não demonstra que o evento ou a nota deixaram de ser recebidos.

4. Defina a correção pelo estado real. Só depois da comparação, o responsável fiscal e o suporte podem avaliar o ajuste do gerador e a possibilidade de nova transmissão. Um documento já autorizado não deve ser reescrito para combinar com uma tentativa rejeitada.

Essa sequência distingue uma falha de geração de XML de um evento associado ao documento errado. As duas situações podem parecer iguais no painel do ERP, mas exigem encaminhamentos diferentes.

Exemplo: a tela mostra EPEC, mas a chave não acompanha

Imagine que a equipe veja “contingência EPEC” no cadastro da nota. O arquivo efetivamente enviado, entretanto, aponta para uma chave cuja posição 35 contém 1. A rejeição é compatível com essa divergência, mesmo que a configuração exibida hoje esteja correta.

O suporte precisa descobrir se foi usada uma versão antiga do documento, uma associação incorreta ou uma fila montada antes da alteração de configuração. São hipóteses de diagnóstico, não causas comprovadas pelo número 484. Recuperar o XML original e os horários reais permite verificar qual delas ocorreu.

A solução técnica deve preservar a ligação com a operação verdadeira. Não basta substituir o 1 por 4: a chave integra a identificação do documento, e o evento possui campos relacionados e assinatura digital. Tampouco se devem inventar datas de emissão ou de contingência para fazer uma tentativa passar.

Se já existir EPEC ou nota autorizada

O registro anterior muda o encaminhamento. Primeiro, compare sua chave, os dados e o protocolo com a operação que está sendo tratada. Uma nova resposta 484 não apaga um evento anterior nem comprova que a numeração esteja disponível.

Nas especificações do EPEC, cStat 128 indica processamento do lote; é necessário ler o resultado individual. O retorno 136 identifica o registro do evento ainda sem vínculo com a nota completa. Já o 124 aparece na consulta de situação quando há EPEC autorizado. Nenhum desses elementos, isoladamente, substitui a conferência da autorização da nota correspondente.

Confirmado o EPEC válido, a regularização deve conservar sua correspondência com o documento fiscal. Divergência de chave, dados ou situação precisa ser resolvida antes de retransmitir. A orientação paulista para NF-e reforça a necessidade de acompanhar a conciliação; seu procedimento administrativo é estadual, não uma receita nacional.

Atenção ao emitente pessoa física

A documentação atual do EPEC de NF-e 55 contempla CPF. Isso não comprova a mesma compatibilidade no EPEC da NFC-e 65: a NT 2014.003 v1.02 mantém uma restrição ao autor pessoa física, enquanto a NT 2023.002 ampliou o uso de CPF no serviço de autorização da NFC-e. Sem confirmação específica da UF e do serviço EPEC, não se deve orientar esse ramo como operacionalmente disponível.

Para prevenir recorrências, o sistema deve manter juntos o XML da nota, o evento e cada retorno, além de impedir que uma fila reutilize documentos desatualizados. O diagnóstico estará concluído quando o arquivo causador da 484 for identificado e o histórico fiscal estiver reconciliado, permitindo uma decisão segura sobre o próximo passo.

Atenção a registros históricos de DPEC

O Manual de Contingência de março de 2009 usava 484 para dígito verificador inválido em recepção e consulta da antiga DPEC. É outro contexto documental, não uma instrução para usar esse serviço hoje. Ao analisar um arquivo antigo, confira o serviço e a mensagem completa antes de aplicar o diagnóstico de tipo de emissão do EPEC.

Fontes e limites da análise

Revisão documental em 10/10/2026, com PDFs oficiais preservados em 09/10/2026: NT 2014.001 v1.41, de agosto de 2026, e NT NFC-e 2014.003 v1.02, de janeiro de 2015. Foram lidos Berga.App, sobre a 484, Oobj, sobre emissão EPEC e TecnoSpeed, sobre contingência EPEC. Os dois últimos são guias contextuais, não análises específicas da 484. Suas instruções não substituem a documentação oficial nem autorizam alterações sem conciliação prévia.