E-invoicing in Mexico: requirements guide

Mexico runs one of the most comprehensive e-invoicing regimes in the world. Every commercial transaction subject to tax must be documented through a CFDI (Mexico's electronic invoice), validated in real time by a government-authorized provider, and then sent to the tax authority. For foreign companies entering the Mexican market or doing business with Mexican counterparties, understanding how this system works is the difference between compliant operations and unrecoverable tax exposure.

This guide explains how Mexico e-invoicing works at the compliance level, what foreign companies must put in place to issue or receive valid invoices, how the integration architecture compares to other countries, and where the real failure points are.

What Mexico e-invoicing means

Mexico's e-invoicing standard is the CFDI (Comprobante Fiscal Digital por Internet). The SAT (Mexico's tax authority, Servicio de Administración Tributaria) defines it in Anexo 20 (the SAT technical standard that defines the CFDI: its XML structure, catalogs, and validation rules) of the Resolución Miscelánea Fiscal (the SAT's annual tax rules). A CFDI is an XML document that contains the full detail of a commercial transaction, signed by the issuer with a digital certificate and validated by a government-authorized intermediary before it reaches the recipient.

The system has three mandatory parties:

• The issuer (emisor). The taxpayer issuing the invoice, identified by an active RFC (Mexico's taxpayer ID, Registro Federal de Contribuyentes) and a valid CSD (Certificado de Sello Digital, the digital seal certificate used to sign CFDIs).
• The PAC (Proveedor Autorizado de Certificación). A private entity authorized by the SAT to validate CFDIs, stamp them (stamping: the certification by a SAT-authorized provider that makes a CFDI valid), and send them to the SAT. Without the PAC's digital tax stamp (Timbre Fiscal Digital, the SAT seal the PAC adds to a CFDI), a CFDI isn't valid for tax purposes.
• The SAT. Mexico's tax authority, which receives a copy of every stamped CFDI from the PAC and uses the data for compliance, audit, and pre-filled tax returns.

CFDI 4.0 has been the mandatory version since April 1, 2023. No PAC will stamp a CFDI in an older format.

Who must comply

The compliance scope is broad. Three categories of entities must issue CFDIs:

• Any Mexican legal entity (persona moral). Corporations, LLCs, partnerships, non-profits, regardless of size or industry.
• Any Mexican individual (persona física) with business income. Self-employed professionals, freelancers, sole proprietors, landlords with rental income.
• Mexican branches or permanent establishments of foreign companies. A foreign company that operates through a permanent establishment in Mexico must issue CFDIs through that establishment.

Foreign companies without a permanent establishment in Mexico do not issue CFDIs directly. Instead, they appear as recipients of CFDIs issued by their Mexican vendors, using the generic foreign-recipient RFC XEXX010101000 and additional fields that capture the foreign tax ID and country.

Required components for compliance

Before a Mexican entity can issue its first CFDI, four elements must be in place.

Active RFC

The taxpayer must hold an active RFC registered with SAT, with the correct tax regime (régimen fiscal, the SAT category a taxpayer is registered under, such as 601 or 626) declared. The regime determines what types of operations are allowed, what withholdings (retención) apply, and which CFDI use (how the recipient will use the CFDI for tax purposes) codes are valid for transactions. For details on tax regimes, see the Spanish-language tax regime guide.

Digital seal certificate (CSD)

The CSD is a digital certificate, similar to an SSL certificate, that the issuer uses to sign every CFDI. It is issued by the SAT, expires after four years, and is tied to a single RFC. Without a valid CSD, no CFDI can be generated.

The CSD must not be confused with the e.firma (the SAT advanced electronic signature that identifies a taxpayer, formerly FIEL), which you use to authenticate with SAT services. Both are required, but they have different roles. The differences are covered in the Spanish-language e.firma vs. CSD guide.

PAC relationship

The PAC is the bridge between the issuer and the SAT. Every CFDI issued outside the SAT's free portal must pass through a PAC, which validates the XML against SAT rules, returns a stamped CFDI with a UUID (folio fiscal, the unique ID the PAC assigns when it stamps a CFDI) and a SAT seal (the seal inside the digital tax stamp that certifies the CFDI), and sends a copy to the SAT. Stamping is what makes the CFDI valid for tax purposes.

PACs are private companies authorized by SAT through a formal certification process. The current list of authorized PACs is published by SAT and updated quarterly. Issuers choose a PAC based on price, integration quality, reliability, and additional services (validation, cancellation management, archive).

Issuing platform

The taxpayer needs a platform to compose the CFDI XML, get it stamped, and deliver the CFDI to the recipient. This can be SAT's free portal (suitable only for low-volume issuance), a desktop invoicing program, an integrated ERP module, or an API platform. For any organization issuing more than a handful of invoices per month, an API integration is the standard approach.

The end-to-end issuance flow

The technical flow of a Mexican e-invoice involves seven steps from data capture to final delivery.

The end-to-end process typically completes in 1 to 3 seconds when the PAC's services are operating normally. The CFDI stamping guide covers the stamping step in detail.

Compliance requirements beyond issuance

Issuing the CFDI is only the start. Mexican law imposes additional obligations on both issuers and recipients.

Five-year retention

Both issuers and recipients must retain the original XML for five years from the date of issuance. The printed representation (the PDF of a CFDI; the XML is the legal document) is for people to read. Loss of the XML during the retention period creates a deductibility risk if SAT later requests it.

Validation by recipients

Recipients must validate every CFDI they receive before booking it as a deductible expense. The validation process confirms the CFDI is stamped, the issuer's status is active at the time of issuance, and the document has not been canceled. The guide to verifying a CFDI covers the methods and edge cases.

Cancellation rules

CFDIs can be canceled, but the process has constraints. For amounts above the SAT-defined threshold, cancellation requires the recipient's acceptance through their tax mailbox (Buzón Tributario). The recipient has three business days to respond; otherwise the cancellation is automatically accepted. A CFDI can be canceled no later than the month in which the annual ISR (Mexico's income tax, Impuesto Sobre la Renta) return for the year it was issued is due. The full cancellation workflow is covered in the CFDI cancellation guide.

Reporting to the SAT

When the PAC stamps a CFDI, it sends a copy to the SAT. There is no separate filing step for individual invoices. A stamped CFDI can't be modified, because the SAT gets a copy of each one. Its issue date can't be more than 72 hours before stamping, or the PAC rejects it.

Monthly reporting

Beyond individual CFDIs, taxpayers must file monthly returns that aggregate the CFDI data: IVA (Mexico's value-added tax, VAT) returns, withholding declarations, and the DIOT (Mexico's monthly informative return on transactions with suppliers and the VAT they charged, Declaración Informativa de Operaciones con Terceros). The SAT pre-fills the provisional ISR and IVA payment returns using CFDI data, and the taxpayer is responsible for reviewing and confirming them. The DIOT is not pre-filled: you capture it or upload it as a file.

How Mexico compares to other e-invoicing regimes

For foreign companies that operate in multiple markets, Mexico's e-invoicing system is best understood by comparison.

Mexico's model is closest to Brazil and Chile: pre-clearance, real-time, mandatory for all B2B and B2C transactions. The main difference between Mexico and Brazil is the intermediary architecture; Mexico relies on private PACs, while Brazil clears directly through SEFAZ (the state tax authorities). Italy operates a similar real-time validation through the SDI (Sistema di Interscambio), but the clearance is post-issuance rather than pre-issuance.

For multinational platforms, the practical implication is that a Mexican implementation cannot be derived from a European e-invoicing module. The data model, the certificate handling, the clearance flow, and the cancellation rules are all different.

Integration paths for foreign companies

Three architectures cover most foreign-company scenarios.

Path 1: Mexican subsidiary with local ERP

The Mexican subsidiary uses a local Mexican ERP (Aspel, Contpaq, Bind, Microsip, or similar) that includes integrated CFDI issuance. The ERP handles the PAC relationship internally and the foreign parent receives consolidated reporting in its preferred format.

This is the most common path for established subsidiaries with stable operations. The trade-off is that local ERPs are not designed for multi-country consolidation, and integration with the parent's global systems often requires custom middleware.

Path 2: Global ERP with Mexican localization module

The foreign parent's global ERP (SAP, Oracle, Microsoft Dynamics, NetSuite) includes a Mexico localization module that connects to a PAC through a certified connector. The module is configured to issue CFDIs based on the ERP's invoice records, with field mapping handled by the localization layer.

This path preserves global ERP consistency but creates dependency on the localization module's coverage. CFDI evolves through SAT updates several times per year: new fields, new validation rules, and new complements (complemento, an XML extension the SAT defines for specific operations). The localization module must keep pace.

Path 3: Direct API integration with a Mexican invoicing API

The foreign parent or its Mexican subsidiary integrates directly with an invoicing API that abstracts the PAC relationship and the XML construction. The API receives invoice data in a clean JSON model and returns the stamped CFDI ready to deliver. The retention of XML, validation of recipients, and management of cancellations are all handled through the API.

This is the path most foreign SaaS platforms and modern multinationals choose. It separates the Mexico compliance layer from the global ERP, allowing each system to focus on its strengths. Fiscalapi follows this model: it exposes a JSON API for CFDI issuance, validation, cancellation, bulk download of received CFDIs (bulk download: the SAT service that delivers the CFDIs a taxpayer issued and received), and reporting integrations. The Fiscalapi documentation covers the integration patterns, and the SDKs provide ready-to-use clients in .NET, Node.js, PHP, Python, and Java.

Common compliance failures

The patterns below account for the majority of compliance issues that foreign companies encounter in their first year of Mexican operations.

Stale recipient data

The recipient's tax regime and the postal code of its tax address (the address registered with the SAT; a CFDI 4.0 carries only its postal code) must match exactly what is registered with SAT at the time of issuance. Foreign systems often capture this data once at customer onboarding and never refresh it. When the customer updates their tax details with the SAT, the stored data becomes stale and invoices start failing validation. The fix is periodic re-validation against the SAT registry for all active customer records.

Missing foreign-recipient fields

When invoicing a foreign customer with XEXX010101000, the recipient's tax regime must be 616 and its postal code must be the CFDI's place of issue (the postal code where the CFDI is issued). On an export that carries Comercio Exterior (the CFDI foreign trade complement for exports), the foreign tax ID and the country code are also mandatory. Foreign-company invoicing modules sometimes default to "domestic recipient" logic and fill these fields with domestic data or leave them out, causing rejections at the PAC.

Late stamping of operations

Mexican law requires CFDIs to be issued at the time of the commercial transaction. Issuing a CFDI weeks or months after the operation creates penalties and exposes the transaction to invalidity. Multinationals that batch-process invoices monthly need to redesign the cadence for Mexican operations.

Cancellation without recipient acceptance

For amounts above the SAT threshold, canceling a CFDI requires the recipient's acceptance. Systems that issue cancellations without monitoring the acceptance status create discrepancies where the issuer records a cancellation but SAT still considers the CFDI active (vigente: not canceled with the SAT). The reconciliation problem surfaces during VAT returns.

Confusing the CSD with the e.firma

The CSD is for signing CFDIs. The e.firma is for authenticating with SAT services. Systems that use the wrong certificate for the wrong operation generate cryptic errors that are difficult to diagnose. The two certificates must be managed separately, with appropriate access controls.

Frequently asked questions

The compliance posture

For foreign companies, Mexico e-invoicing is a continuous compliance discipline that touches every system that records revenue, costs, payroll, or vendor payments. The companies that succeed in the Mexican market treat CFDI compliance as foundational infrastructure: tested, monitored, and reviewed against SAT changes that arrive multiple times per year. The companies that treat it as a one-time integration are the ones whose audit cycles uncover backlogs of rejected invoices, broken deduction trails, and reconciliation gaps that grow more expensive to resolve over time.