If you opened a Mexican entity — or you are about to — invoicing is not a formality you solve with a PDF template. Every invoice has to be issued as a CFDI 4.0, digitally signed and validated by a government-authorized provider before it is legally valid. Here is what that means in practice, in plain English.
In Mexico, the invoice of record is an XML document called a CFDI (Comprobante Fiscal Digital por Internet). The PDF your customer receives is only a human-readable rendering of it. Three things make it legally valid:
The CSD — a certificate and private key issued to your company by the tax authority (SAT). Without it you cannot sign anything.
A PAC validates and stamps each invoice on the SAT's behalf. No stamp, no valid invoice. You contract one directly.
Every product needs an official product and unit code; every customer needs their tax ID, tax regime and a declared use for the invoice.
That third point is what surprises US finance teams: it is not enough to know what you sell. Each line item must map to a government catalog, and each customer record must carry tax attributes that simply do not exist in a US system.
The tax ID of your Mexican entity. Your US EIN does not apply here.
Requested by your Mexican entity. This is usually what sets the project calendar — not the software.
Pick one your ERP supports natively, or you will be paying for a custom connector.
This is where most of the cost hides. We cover it in ERP for Mexican operations.
One detail that causes more rejections than any other: your company's legal name has to match the SAT registry character for character. An extra or missing suffix and the invoice bounces. We learned that one on our own books.
With the right ERP edition, configuring e-invoicing — certificates, PAC credentials, series — is a matter of hours. What drives the calendar is everything around it:
Obtaining the CSD and signing with a PAC. Outside your control and usually the long pole.
Assigning SAT product and unit codes across your item master. With hundreds of SKUs this is the bulk of the work.
Tax ID, postal code, tax regime and invoice use for every customer you bill in Mexico.
A realistic range for a clean setup is 4 to 6 weeks end to end. Add time if you sell to large retail chains or the automotive industry: they require an addenda, a custom XML block inside the invoice, and that changes which platform you can even use.
The technical detail lives on our Mexico site. Same team, same engineers.
Which system can legally invoice in Mexico, and why the edition you pick decides it.
Entity, talent, time zone and cost — the practical playbook for US teams.
The three natively supported providers and what to do if yours is not one of them.
Cloud, Odoo.sh or self-hosted — and what each one allows for Mexican invoicing.
Already on SAP? The three honest paths for a Mexican subsidiary, compared.
Generally no. Issuing a CFDI requires a Mexican tax ID (RFC) and a digital seal certificate issued to that entity. If you are selling into Mexico without a local entity, the tax treatment is different and worth reviewing with your accountant before you pick software.
No. The legal document is the signed XML validated by an authorized provider. The PDF is a courtesy rendering of it. Systems that only produce PDFs do not make you compliant.
The provider fees are modest and paid directly to them. The real cost is configuring your ERP and mapping catalogs. Our Mexico packages that include full CFDI 4.0 start at MXN $89,000 — roughly USD $5,000 at 2026 rates — with a committed go-live date.
Fewer than you would expect, and often only in their paid editions. We cover exactly which ones and what changes between them on the ERP page linked above.
Mexican payroll has its own stamped receipt and is a separate module in essentially every ERP. It is never included in a base implementation — ours or anyone else's.
We run our own operation on a Mexican ERP with CFDI 4.0 stamping we built ourselves. The call is free and you leave with scope and a number, even if you build it elsewhere.