TL;DR — Résumé Rapide
CFDI erreur 302 : le sceau émetteur ne correspond pas. Vérifiez la paire .cer/.key, la chaîne originale, n'éditez pas le XML après signature, synchronisez le même CSD au PAC et ERP.
L’erreur 302 dans la facturation électronique mexicaine signifie que le sceau numérique de l’émetteur dans le XML ne correspond pas à ce que le SAT ou votre PAC calculent à partir de la chaîne originale et du Certificado de Sello Digital (CSD) du RFC émetteur. Contrairement à l’erreur 401 (certificat non valide ou expiré), l’erreur 302 implique en général un certificat actif mais une signature cryptographique invalide : pas de TimbreFiscalDigital ni d’UUID.
Ce rejet est fréquent après renouvellement du CSD uniquement chez le PAC, migration de serveur de timbrage, ou « correction » manuelle du XML après signature par le système. Il apparaît aussi si des fichiers .cer et .key de générations différentes sont mélangés, ou si l’e.firma (FIEL) remplace le CSD. Les étapes ci-dessous structurent diagnostic et correction sans reconstruire toute la facturation.
L’erreur
Lors de l’envoi au PAC ou au service de timbrage dans Aspel SAE, CONTPAQi ou autre ERP :
302 - Le sceau du contribuable émetteur ne correspond pas au certificat
302 - Sceau numérique de l’émetteur invalide
CFDI302 - Le sceau n’est pas valide
Certains PAC traduisent le code SAT en texte générique ; d’autres affichent le détail de validation du sceau. Le timbrage s’arrête et le folio interne reste sans UUID jusqu’à régénération et signature correctes.
Cause du problème
Le sceau émetteur signe la chaîne originale avec la clé privée du CSD. Toute divergence → 302.
Paire .cer / .key de générations différentes
Après renouvellement sur Certifica tu RFC, nouveau .cer avec ancienne .key ou confusion de RFC dans des dossiers partagés → sceau non vérifiable.
Mot de passe incorrect de la clé privée
Mot de passe erroné dans l’ERP → sceau vide ou corrompu ; le PAC renvoie 302 au premier lot.
XML modifié après signature
Modification des totaux, RFC destinataire, nœuds fiscaux ou espaces après le sceau émetteur invalide la signature. Antivirus ou sync cloud dans le dossier de sortie aussi.
Chaîne originale mal construite
Ordre fixe SAT. Erreurs typiques :
- CFDI 4.0 avec routine de chaîne 3.3.
- Nœuds obligatoires absents de la chaîne mais présents dans le XML.
- Encodage (UTF-8 BOM, fins de ligne Windows).
- Séparateurs supplémentaires dans les intégrations.
CSD différent entre PAC et système signataire
PAC valide un CSD, ERP a signé avec un autre (succursale obsolète, base clonée) → sceau « ne correspond pas ».
FIEL au lieu du CSD
L’e.firma ne remplace pas le CSD pour facturer. Configuration FIEL sur le timbrage → rejets souvent regroupés sous 302.
Double signature ou modèles corrompus
Connecteurs qui signent deux fois ; XSD ok mais validation cryptographique PAC en échec.
Solution étape par étape
1. Isoler XML, message et RFC
Exporter le XML rejeté (logs PAC ou dossier documents électroniques ERP). Noter date, RFC, folio, version CFDI.
2. Confirmer CSD actif au SAT
Connexion sat.gob.mx avec e.firma, Certifica tu RFC, vérifier l’expiration. Si renouvellement récent, identifier la demande qui fournit la paire du jour.
3. Valider la paire .cer et .key
Retélécharger les deux fichiers du même dossier, tester le mot de passe (outil PAC ou assistant ERP), supprimer les anciennes copies.
4. Synchroniser PAC et ERP le même jour
Charger le CSD actuel dans le PAC, confirmer. Dans Aspel SAE : Configuración → Empresa → Facturación electrónica, importer le même .cer/.key, redémarrer l’agent de timbrage si besoin. Même numéro de série des deux côtés.
5. Régénérer sans toucher le XML signé
Annuler l’échec dans SAE, corriger les données métier, générer un XML neuf depuis la facturation. Pas d’édition Notepad en production.
6. Facture test et validation SAT
CFDI de revenu réel à montant symbolique. UUID, XML timbré, Consulta de CFDI → Vigente.
Prévention
- Renouveler CSD SAT, PAC et tous les ERP le même jour ; checklist par succursale.
- Interdire l’édition manuelle du XML pré-timbrage en production.
- Coffre certificats
RFC-série-expiration. - Après correctifs Aspel ou PAC : une facture test avant lots massifs.
- Formation : CSD pour factures, FIEL pour le portail.
Résumé
- Erreur 302 : le sceau émetteur ne correspond pas à la chaîne originale et au CSD.
- Vérifier .cer/.key, mot de passe, PAC + ERP avec le même certificat.
- Ne pas modifier le XML après signature ; régénérer.
- Facture test avec UUID confirme la correction.