TL;DR — Resumen Rápido
CFDI error 302: el sello del emisor no corresponde. Revise pareja .cer/.key, cadena original, ObjetoImp coherente y que no edite el XML después de firmar antes del PAC.
El error 302 en la facturación electrónica mexicana indica que el sello digital del emisor grabado en el XML no corresponde con lo que el SAT o el PAC calculan a partir de la cadena original y del Certificado de Sello Digital (CSD) del RFC emisor. A diferencia del error 401 (certificado no vigente o no reconocido), en el 302 el certificado suele estar activo, pero la firma criptográfica no valida: el comprobante se rechaza antes de insertar el TimbreFiscalDigital y no obtiene UUID.
Este rechazo es frecuente tras renovar el CSD solo en el PAC y olvidar el ERP, tras migrar servidores de timbrado, o cuando alguien “corrige” el XML a mano después de que el sistema ya lo firmó. También aparece si se mezclan archivos .cer y .key de generaciones distintas o si se intenta timbrar con e.firma (FIEL) en lugar del CSD. La guía siguiente ordena diagnóstico y corrección sin reinstalar todo el entorno de facturación.
El Error
Al enviar el XML al PAC o al servicio de timbrado integrado en Aspel SAE, CONTPAQi u otro ERP, pueden aparecer mensajes como:
302 - El sello del contribuyente emisor no corresponde al certificado
302 - Sello digital del emisor inválido
CFDI302 - El sello no es válido
Error de validación de sello: no corresponde
Algunos PAC traducen el código SAT a texto genérico; otros muestran el detalle de validación de sello. En todos los casos el timbrado se detiene y el folio interno queda sin UUID hasta regenerar y firmar correctamente.
Causa del Problema
El sello del emisor es el resultado de firmar la cadena original con la llave privada del CSD. Si cualquier byte de la cadena o de la firma no coincide con lo esperado, el validador responde 302.
Pareja .cer / .key de distintas generaciones
Al renovar el CSD en el portal Certifica tu RFC, el SAT entrega un nuevo par. Cargar el .cer nuevo con la .key anterior — o mezclar archivos de dos RFC en carpetas compartidas — produce un sello que no puede verificarse aunque la contraseña sea correcta.
Contraseña incorrecta de la llave privada
Una contraseña errónea en el ERP a veces genera un sello vacío o corrupto sin mensaje claro en pantalla; el PAC devuelve 302 en el primer intento de timbrado masivo.
XML modificado después de firmar
Abrir el XML en un editor, cambiar totales, RFC del receptor, nodos de impuestos o espacios en blanco después del sello del emisor invalida la firma. Lo mismo ocurre si un antivirus o sincronización cloud altera el archivo en la carpeta de salida.
Cadena original mal construida
La cadena concatena campos del comprobante en orden fijo definido por el SAT. Errores típicos:
- Versión CFDI 4.0 con rutina de cadena de 3.3.
- Omisión de nodos obligatorios que sí están en el XML (por ejemplo
Exportaciono atributos de receptor). - Encoding distinto (UTF-8 con BOM, saltos de línea Windows mezclados).
- Separadores o pipes adicionales por integraciones personalizadas.
CSD distinto entre PAC y sistema que firma
Si el PAC valida con un CSD y el ERP firmó con otro (sucursal desactualizada, base de datos clonada), el sello “no corresponde” aunque ambos certificados estén vigentes para el mismo RFC en teoría.
Uso de FIEL en lugar de CSD
La e.firma no sustituye al CSD en facturación. Configurar la FIEL en la ruta de timbrado genera sellos que el ecosistema CFDI rechaza con códigos de sello, a menudo agrupados como 302.
Doble firma o plantillas corruptas
Algunos conectores firman dos veces o insertan un sello de prueba. El XSD puede aceptar la estructura y aun así fallar la validación criptográfica en el PAC.
Solución Paso a Paso
1. Aislar XML, mensaje y RFC
Exporte el XML rechazado desde el log del PAC o la carpeta de documentos electrónicos del ERP. Anote fecha, hora, RFC emisor, folio y versión CFDI. No reutilice ese archivo para correcciones manuales en producción.
2. Confirmar CSD vigente y único en el SAT
Ingrese a sat.gob.mx con e.firma, abra Certifica tu RFC y verifique que el CSD activo no esté vencido. Si renovó recientemente, identifique la fecha del trámite que generó el par que debe usarse hoy.
3. Validar pareja .cer y .key
Descargue de nuevo ambos archivos del mismo trámite. Importe en un medio seguro y pruebe la contraseña de la llave con la herramienta que ofrece su PAC o con el asistente del ERP. Elimine copias antiguas en C:\Certificados o rutas Linux compartidas para evitar confusiones.
4. Sincronizar PAC y ERP el mismo día
En el panel del PAC autorizado, cargue el CSD actual y espere confirmación. En Aspel SAE: Configuración → Empresa → Facturación electrónica, importe el mismo .cer y .key, reinicie el servicio de timbrado si existe agente nocturno. Los dos ambientes deben apuntar al mismo número de serie del certificado.
5. Regenerar comprobante sin tocar el XML firmado
Cancele el intento fallido en SAE, corrija datos de negocio si aplica (ObjetoImp, impuestos), y genere un XML nuevo desde el menú de facturación. No edite el XML con Notepad++ salvo emergencia en ambiente de pruebas.
6. Timbrar factura de prueba y validar en SAT
Emita un CFDI de ingreso real con monto simbólico. Confirme UUID, descargue XML timbrado y use Consulta de CFDI en el portal SAT para estatus Vigente. Archive evidencia para auditoría.
Prevención
- Renueve CSD en SAT, PAC y todos los ERP el mismo día; use checklist por sucursal.
- Prohiba edición manual de XML pre-timbrado en producción.
- Centralice certificados en vault con nombre
RFC-serie-vigencia. - Tras parches de Aspel o del PAC, ejecute una factura de prueba antes de lotes masivos.
- Capacite al equipo: CSD para facturar, FIEL para trámites.
Resumen
- El error 302 significa que el sello del emisor no corresponde a la cadena original y al CSD.
- Revise pareja .cer/.key, contraseña, y que PAC y ERP usen el mismo certificado.
- No modifique el XML después de firmar; regenere desde el sistema.
- Una factura de prueba con UUID confirma la corrección.