- In Mexico there's no such thing as a paper invoice. Every fiscal receipt is a CFDI: an XML that a PAC certifies ("stamps") before it's valid.
- The current version is CFDI 4.0. Its most painful change for a shop: the customer's details must match the SAT's records exactly, or stamping gets rejected.
- Your shop program needs to integrate a PAC and your digital seal certificates (CSD). Without that, no matter how nice the repair order looks, you can't invoice a customer.
- Every part and every service needs its SAT catalog key. This is where a shop gets stuck the most, because you're selling two different kinds of things on the same ticket.
- The SAT doesn't "approve" shop programs. What it authorizes is PAC providers. Be wary of anyone selling a seal that doesn't exist.
Can a shop in Mexico invoice without software? No. And it's not a matter of convenience: the fiscal receipt is a file. The CFDI (Comprobante Fiscal Digital por Internet) is born as an XML, is signed by your digital seal certificate, is certified by a third party authorized by the SAT, and only then does it exist. The nice PDF you send the customer is a printed representation of that XML, not the invoice.
This puts the Mexican shop in a different position than a Spanish or Argentinian one: here the invoicing program isn't an operational nicety, it's a requirement to get paid. This guide covers exactly what CFDI 4.0 requires, where shops get stuck, and what to ask your provider before signing anything.
What CFDI is, and why your shop can't invoice without software
The full circuit of a Mexican invoice has four steps, and only the first one is yours:
- You generate the XML with the repair's data: customer, line items, taxes, payment form and method.
- You seal it with your Certificado de Sello Digital (CSD), which you get from the SAT and which is different from your e.firma.
- A PAC stamps it (Proveedor Autorizado de Certificación): it validates the structure and adds the digital fiscal stamp, the fiscal folio (UUID) and the SAT's seal.
- It's delivered to the customer: the stamped XML plus its printed representation.
Step three is what surprises anyone coming from another country: there's a mandatory intermediary. A shop doesn't send its invoices straight to the SAT — it sends them to an authorized PAC. And that raises the first real question for your software provider: is stamping included, or do I contract it separately? It's a real cost difference and a real headache difference, because if your program doesn't integrate a PAC you'll end up retyping data by hand into another provider's portal — exactly what a shop program should be saving you from.
The customer details that can sink an invoice
If there's one thing that has made Mexican shops suffer since CFDI 4.0 arrived, it's this: the recipient's details have to match the SAT's records, character for character. "Close enough" doesn't cut it anymore. Stamping validates against the taxpayer registry and, if anything doesn't match, it rejects.
What you need from the customer to be able to invoice them:
- Valid, active RFC.
- Name or legal name exactly as it appears on their Constancia de Situación Fiscal. No extra or missing "S.A. de C.V.", no invented accents, no abbreviations of your own.
- Fiscal address postal code (not the home address, not the shop's: the fiscal one).
- Tax regime they're registered under.
- CFDI use, which also has to be compatible with their regime. An individual under a given regime can't use just any use key.
The practical consequence at a shop is uncomfortable: the moment to ask for these details is before handing back the vehicle, not after. When the customer has already left with their car and asks for an invoice three days later, the WhatsApp back-and-forth begins to get the Constancia de Situación Fiscal. Any shop program worth using in Mexico should store the customer's complete tax record from their first visit and reuse it, not ask for it every time.
What about the customer who doesn't want an invoice?
That's the majority at a neighborhood shop. For those sales there's the global CFDI: a receipt that groups general-public transactions for a period, using the generic RFC. The obligation to record the sale doesn't go away; what changes is the format.
Watch out for the temptation to not record anything "because they didn't ask for an invoice." The SAT cross-references data, and a shop invoicing three repairs a month while running four lifts stands out on its own. A serious program generates the global CFDI without you having to think about it.
SAT catalogs: a shop's specific problem
Every line item on the invoice needs a product or service key and a unit key from the SAT's official catalogs. And this is where a shop suffers more than an ordinary store, for a simple reason: on the same invoice you're selling things and you're selling time.
A typical repair includes parts (brake pads, filter, oil), consumables and labor. Every line needs its correct key, and they're not the same for a part as for a service. Multiply that by a catalog of hundreds of parts and you'll understand why many shops end up using one generic key for everything: it's convenient, and it's a risk.
What your program should do for you:
- Store the SAT key on each part's and each service's record, once, not on every invoice.
- Keep the catalogs updated. The SAT reviews them periodically, and a retired key sinks stamping.
- Let you bulk-load your parts catalog with its keys, not one at a time.
Canceling an invoice is no longer free or instant
At a shop, more gets canceled than you'd expect: the customer gave the wrong RFC, the estimate changed mid-repair, something got invoiced twice. It's worth knowing that canceling a CFDI has rules: you have to state a cancellation reason, and in several cases the recipient has to accept the cancellation, plus there are deadlines limiting how long you have to do it.
The practical takeaway: it's far cheaper to invoice correctly the first time than to rely on canceling afterward. And to invoice correctly the first time, you need the customer's tax details before you touch the vehicle, not while they're already waiting at the register.
What to demand from your shop program
- Does it stamp from inside the program? If you have to go to another portal to upload the XML, it's not integrated — it's only "ready for."
- Is the PAC included in the price, or billed separately? Ask how many stamps are included per month and what going over costs. It's the most common fine print.
- Does it store the customer's complete tax record? RFC, exact name, fiscal postal code, regime and CFDI use. If it only keeps "name and phone," you'll get stamping rejections daily.
- Does it carry SAT keys on parts and services? And even better: does it let you import your full catalog?
- Does it generate the global CFDI for general-public sales?
- Does it manage cancellations with their reason and notify you of the request's status?
- Does it keep the XML files? The PDF doesn't work as fiscal backup. The file that matters is the stamped XML, and you have to keep it.
And a warning about the marketing language: the SAT doesn't authorize or "approve" shop programs. What it authorizes is PAC providers. If a vendor sells you on their software being "certified by the SAT," they're describing a seal that doesn't exist for that product category. The right question is different: "which authorized PAC do you stamp through?" That one has a verifiable answer on the SAT's official list.
The invoice is the end, not the business
Everything above solves the last step: getting paid correctly and without surprises. But a shop's money gets lost earlier, and no regulation fixes that: in the quote sent over WhatsApp that nobody followed up on, in the customer who wasn't told the car was ready, in the service that was due in six months and that nobody remembered.
If you're switching programs because the one you have doesn't stamp properly, use the change to fix the whole journey. Coming out of the process with your invoices in order and everything else the same as before means you've paid for half the benefit. We cover this with more regional context in shop software in Latin America.
- SAT — Electronic invoice format (Anexo 20), CFDI technical specification
- SAT — Fiscal receipts: what they are and how they're issued
- SAT — Official list of Authorized Certification Providers (PAC)
- SAT — CFDI catalogs (product/service and unit keys)
- SAT — Digital Seal Certificate (CSD): procedure and use
- SAT — Invoice cancellation: reasons, deadlines and recipient acceptance
- SAT — Constancia de Situación Fiscal (the details you need from the customer)
AI quotes, scheduling, mechanic app, inventory and customer portal. 3 months for €1, no lock-in.
Start for €1