Mexico E-Invoicing for Foreign Companies: CFDI Compliance Guide

Mexico runs one of the most comprehensive electronic invoicing regimes in the world. Every commercial transaction subject to tax must be documented through a CFDI, validated in real time by a government-authorized provider, and made available to the tax authority on the same day it is issued. 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 electronic invoicing standard is the CFDI (Comprobante Fiscal Digital por Internet), defined in Anexo 20 of the SAT's Resolución Miscelánea Fiscal. 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 and a valid Certificate of Digital Seal (CSD).
• The PAC (Proveedor Autorizado de Certificación). A private entity authorized by the SAT to validate, stamp, and register CFDIs in real time. Without the PAC's digital seal, a CFDI has no legal validity.
• The SAT. Mexico's tax authority, which receives every stamped CFDI within seconds and uses the data for compliance, audit, and pre-filled tax returns.

The mandatory version since January 2023 is CFDI 4.0. 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. Corporations, LLCs, partnerships, non-profits, regardless of size or industry.
• Any Mexican individual 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 address.

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) declared. The regime determines what types of operations are allowed, what withholdings apply, and which CFDI usage codes are valid for transactions. For details on tax regimes, see the regimen fiscal guide.

Certificate of Digital Seal (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 broader digital signature used to authenticate with SAT services). Both are required, but they have different roles. The differences are covered in the FIEL vs CSD guide.

PAC relationship

The PAC is the bridge between the issuer and the SAT. Every CFDI must pass through a PAC, which validates the XML against SAT rules, registers the document in the SAT systems, and returns a stamped CFDI with a unique UUID (folio fiscal) and a SAT digital seal. The PAC operation is what gives the CFDI its legal validity.

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, send it to the PAC, receive the stamped response, and deliver the CFDI to the recipient. This can be SAT's free portal (suitable only for low-volume issuance), a desktop billing 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 both the PAC and SAT services are operating normally. The timbrado 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 PDF representation is for human consumption; only the XML has legal value. 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 CFDI validation guide 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 72 hours to respond; otherwise the cancellation is automatically accepted. CFDIs older than the year of issuance generally cannot be canceled without SAT authorization. The full cancellation workflow is covered in the CFDI cancellation guide.

Same-day reporting to SAT

When the PAC stamps a CFDI, the document is registered with SAT in real time. There is no separate filing step for individual invoices. This is why CFDIs cannot be backdated or modified after stamping; the SAT already has them.

Monthly reporting

Beyond individual CFDIs, taxpayers must file monthly returns that aggregate the CFDI data: VAT (IVA) returns, withholding declarations, and the DIOT (Declaración Informativa de Operaciones con Terceros). These returns are pre-filled by SAT using CFDI data, but the taxpayer is responsible for reviewing and confirming them.

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, new complementos), and 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, 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 fiscal address ZIP 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 fiscal information with 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, additional XML fields are mandatory: the foreign tax ID format, country code, and address details. Foreign-company invoicing modules sometimes default to "domestic recipient" logic and omit these fields, 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 valid. 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 not an IT integration project. It 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.