TL;DR — Quick Summary
CFDI error 302: issuer seal does not match. Verify .cer/.key pair, original string, no post-sign XML edits, and sync the same CSD in PAC and ERP before restamping.
CFDI error 302 during Mexican e-invoicing means the issuer digital seal embedded in the XML does not match what SAT or your PAC compute from the original string and the issuer Certificado de Sello Digital (CSD). Unlike error 401 (certificate not valid or expired), error 302 usually involves an active certificate but a failed cryptographic signature: stamping stops before TimbreFiscalDigital is added and there is no UUID.
This rejection is common after renewing the CSD only at the PAC while forgetting the ERP, after migrating stamping servers, or when someone “fixes” the XML manually after the system already signed it. It also appears when .cer and .key files from different generations are mixed, or when e.firma (FIEL) is used instead of CSD. The steps below organize diagnosis and recovery without rebuilding the entire billing stack.
The Error
When sending XML to the PAC or a stamping service inside Aspel SAE, CONTPAQi, or another ERP, you may see:
302 - The issuer taxpayer seal does not match the certificate
302 - Invalid issuer digital seal
CFDI302 - Seal is not valid
Seal validation error: does not match
Some PACs translate the SAT code to generic text; others show seal validation detail. In every case stamping halts and the internal folio has no UUID until you regenerate and sign correctly.
Cause of the Problem
The issuer seal is produced by signing the original string with the CSD private key. If any byte of the string or signature diverges from expectations, validators return 302.
.cer / .key pair from different generations
When you renew CSD on Certifica tu RFC, SAT delivers a new pair. Loading a new .cer with an old .key — or mixing files from two RFCs in shared folders — yields a seal that cannot be verified even with the right password.
Wrong private-key password
A bad password in the ERP sometimes produces an empty or corrupt seal without a clear on-screen message; the PAC returns 302 on the first mass-stamping run.
XML modified after signing
Opening XML in an editor and changing totals, receiver RFC, tax nodes, or whitespace after the issuer seal invalidates the signature. The same happens if antivirus or cloud sync alters files in the output folder.
Incorrect original string construction
The string concatenates invoice fields in a fixed SAT order. Typical mistakes:
- CFDI 4.0 invoice with a 3.3 string routine.
- Missing nodes that still exist in XML (for example
Exportacionor receiver attributes). - Different encoding (UTF-8 with BOM, mixed Windows line breaks).
- Extra separators from custom integrations.
Different CSD at PAC vs signing system
If the PAC validates one CSD while the ERP signed with another (outdated branch database, cloned company), the seal “does not match” even though both certificates might be valid for the same RFC in theory.
Using FIEL instead of CSD
e.firma does not replace CSD for invoicing. Configuring FIEL on the stamping path produces seals the CFDI ecosystem rejects, often reported as seal errors grouped under 302.
Double signing or corrupt templates
Some connectors sign twice or insert a test seal. XSD may accept structure while cryptographic validation still fails at the PAC.
Step-by-Step Solution
1. Isolate XML, message, and RFC
Export rejected XML from PAC logs or the ERP electronic-documents folder. Record date, time, issuer RFC, folio, and CFDI version. Do not reuse that file for manual production fixes.
2. Confirm active single CSD on SAT
Log in to sat.gob.mx with e.firma, open Certifica tu RFC, and verify the active CSD is not expired. If you renewed recently, note which request date produced the pair you must use today.
3. Validate .cer and .key pair
Download both files again from the same request. Store securely and test the key password with your PAC tool or ERP wizard. Delete old copies in shared certificate folders to avoid mix-ups.
4. Sync PAC and ERP the same day
In the authorized PAC panel, upload the current CSD and wait for confirmation. In Aspel SAE: Configuration → Company → Electronic invoicing, import the same .cer and .key, restart the stamping agent if you run overnight batches. Both sides must reference the same certificate serial number.
5. Regenerate invoice without touching signed XML
Cancel the failed attempt in SAE, fix business data if needed (ObjetoImp, taxes), and generate fresh XML from the billing menu. Do not edit XML in Notepad++ except in a test environment.
6. Stamp test invoice and validate on SAT
Issue a real income CFDI with a symbolic amount. Confirm UUID, download stamped XML, and use SAT CFDI lookup for Vigente status. Archive evidence for audit.
Prevention
- Renew CSD on SAT, PAC, and every ERP the same day; use a per-branch checklist.
- Ban manual pre-stamp XML edits in production.
- Centralize certificates in a vault named
RFC-serial-expiry. - After Aspel or PAC patches, run one test invoice before large batches.
- Train staff: CSD for invoices, FIEL for portal procedures.
Summary
- Error 302 means the issuer seal does not match the original string and CSD.
- Check .cer/.key pair, password, and PAC + ERP using the same certificate.
- Do not modify XML after signing; regenerate from the system.
- A test invoice with UUID confirms the fix.