TL;DR — Resumo Rápido
CFDI erro 302: selo do emissor não corresponde. Verifique par .cer/.key, cadeia original, não edite XML após assinar e sincronize o mesmo CSD no PAC e ERP.
O erro 302 na faturação eletrónica mexicana indica que o selo digital do emissor no XML não corresponde ao que o SAT ou o PAC calculam a partir da cadeia original e do Certificado de Sello Digital (CSD) do RFC emissor. Ao contrário do erro 401 (certificado inválido ou vencido), no 302 o certificado costuma estar ativo, mas a assinatura criptográfica falha: não há TimbreFiscalDigital nem UUID.
A rejeição é frequente após renovar o CSD só no PAC e esquecer o ERP, após migrar servidores de timbrado ou quando alguém «corrige» o XML manualmente depois da assinatura. Também surge ao misturar .cer e .key de gerações diferentes ou ao usar e.firma (FIEL) em vez de CSD. Os passos abaixo organizam diagnóstico e correção sem reconstruir toda a faturação.
O erro
Ao enviar XML ao PAC ou serviço de timbrado no Aspel SAE, CONTPAQi ou outro ERP:
302 - O selo do contribuinte emissor não corresponde ao certificado
302 - Selo digital do emissor inválido
CFDI302 - O selo não é válido
Alguns PACs traduzem o código SAT; outros mostram detalhe de validação do selo. O timbrado para e o folio interno fica sem UUID até regenerar e assinar corretamente.
Causa do problema
O selo do emissor assina a cadeia original com a chave privada do CSD. Qualquer divergência → 302.
Par .cer / .key de gerações distintas
Após renovar o CSD em Certifica tu RFC, novo .cer com .key antiga ou RFC trocado em pastas partilhadas → selo não verificável.
Senha incorreta da chave privada
Senha errada no ERP pode gerar selo vazio ou corrompido; o PAC devolve 302 no primeiro lote.
XML modificado após assinar
Alterar totais, RFC receptor, impostos ou espaços depois do selo invalida a assinatura. Antivírus ou sync na pasta de saída também.
Cadeia original mal construída
Ordem fixa do SAT. Erros típicos:
- CFDI 4.0 com rotina de cadeia 3.3.
- Nós obrigatórios omitidos na cadeia mas presentes no XML.
- Encoding (UTF-8 com BOM, quebras Windows).
- Separadores extra em integrações.
CSD diferente entre PAC e sistema que assina
PAC valida um CSD, ERP assinou com outro (filial desatualizada, base clonada) → selo «não corresponde».
FIEL em vez de CSD
A e.firma não substitui o CSD na faturação. Configurar FIEL no timbrado gera selos rejeitados, muitas vezes agrupados como 302.
Dupla assinatura ou modelos corrompidos
Conectores que assinam duas vezes; XSD ok mas validação criptográfica no PAC falha.
Solução passo a passo
1. Isolar XML, mensagem e RFC
Exportar XML rejeitado do log do PAC ou pasta de documentos eletrónicos do ERP. Anotar data, RFC, folio e versão CFDI.
2. Confirmar CSD ativo no SAT
Entrar em sat.gob.mx com e.firma, Certifica tu RFC, verificar validade. Se renovou recentemente, identificar o trâmite da par atual.
3. Validar par .cer e .key
Baixar novamente ambos do mesmo pedido, testar senha (ferramenta PAC ou assistente ERP), apagar cópias antigas.
4. Sincronizar PAC e ERP no mesmo dia
Carregar CSD atual no PAC. No Aspel SAE: Configuración → Empresa → Facturación electrónica, importar o mesmo .cer/.key, reiniciar agente de timbrado se existir. Mesmo número de série nos dois lados.
5. Regenerar sem tocar XML assinado
Cancelar falha no SAE, corrigir dados de negócio, gerar XML novo pela faturação. Não editar XML em produção.
6. Fatura teste e validação SAT
CFDI de receita real com valor simbólico. UUID, XML timbrado, Consulta de CFDI → Vigente.
Prevenção
- Renovar CSD no SAT, PAC e todos os ERP no mesmo dia; checklist por filial.
- Proibir edição manual de XML pré-timbrado em produção.
- Vault de certificados
RFC-série-validade. - Após patches Aspel ou PAC: uma fatura teste antes de lotes.
- Formação: CSD para faturar, FIEL para portal.
Resumo
- Erro 302: o selo do emissor não corresponde à cadeia original e ao CSD.
- Verificar .cer/.key, senha e PAC + ERP com o mesmo certificado.
- Não modificar XML após assinar; regenerar pelo sistema.
- Fatura teste com UUID confirma a correção.