What is CFDI? Meaning and how it works in Mexico

Every commercial transaction in Mexico that needs to be tax-deductible requires a CFDI (Mexico's electronic invoice). If you're building software that handles payments, e-invoicing, payroll, or logistics in Mexico, this isn't optional. The CFDI is the backbone of the country's entire tax compliance system, and understanding how it works will save you from a lot of rejected CFDIs and confused customers.

What is a CFDI

CFDI stands for Comprobante Fiscal Digital por Internet, which translates to Digital Tax Receipt via Internet. It's an XML document that records a taxable transaction, digitally signed by the issuer and certified by a PAC (Proveedor Autorizado de Certificación, a SAT-authorized provider that stamps CFDIs).

Here's what trips up most people outside Mexico: CFDI means more than "invoice." An invoice is one type of CFDI. But payroll receipts, credit notes (Egreso CFDIs, type E), payment confirmations, and goods transfer documents are all CFDIs too. The term covers every standardized fiscal document that the SAT (Mexico's tax authority, Servicio de Administración Tributaria) uses to track economic activity.

The current version is CFDI 4.0, mandatory since April 1, 2023. No PAC will accept a CFDI in an older format.

How CFDI works

The issuance flow involves three parties: the issuer (you), the PAC, and the SAT.

The critical step is stamping (the certification by a SAT-authorized provider that makes a CFDI valid). When the PAC validates your XML and everything checks out, it assigns a UUID (folio fiscal, the unique ID the PAC assigns when it stamps a CFDI) and attaches the digital tax stamp (Timbre Fiscal Digital, the SAT seal the PAC adds to a CFDI). That UUID becomes the permanent identifier for the document. Cancellations, status queries, verification, everything references that UUID.

The PAC does more than stamp. It validates that the issuer's RFC (Mexico's taxpayer ID, Registro Federal de Contribuyentes) is active and that the tax regime (régimen fiscal, the SAT category a taxpayer is registered under, such as 601 or 626) is a valid key for the type of taxpayer: an individual (persona física) or a legal entity (persona moral). It also checks that the CFDI use (how the recipient will use the CFDI for tax purposes) and form of payment (how the customer paid: cash, bank transfer, card; the FormaPago key) codes exist in the current catalog. One wrong code and the whole thing gets rejected.

Types of CFDI

The typeCode field sets the CFDI type (the TipoDeComprobante key: I income, the regular sales invoice; E credit note; T transfer, moves goods without a sale; N payroll; P payment). Each type serves a different purpose.

Structure of a CFDI

A CFDI is an XML document with a structure defined by the SAT's official XSD. The root element is Comprobante, and inside it, nodes represent each part of the transaction. This is the actual hierarchy:

Comprobante: the root node

The Comprobante element holds the global attributes of the CFDI. These are the most important ones:

Emisor (Issuer)

Tax details of whoever issues the receipt.

Receptor (Recipient)

Tax details of whoever receives the receipt. In CFDI 4.0, the recipient node requires significantly more data than before.

Conceptos (Line Items)

Each Concepto inside the Conceptos node describes one line of the receipt: a product sold or a service rendered.

Each Concepto can contain its own Impuestos node at the line level, with transferred taxes (traslado, a tax the issuer charges the recipient), such as IVA and IEPS (Mexico's excise tax on specific goods and services, Impuesto Especial sobre Producción y Servicios), and withholdings, such as ISR and withheld IVA. It can also include InformacionAduanera for imports, CuentaPredial for real estate, and Parte to break down components of a kit or package.

Impuestos (Global Tax Node)

The Impuestos node at the Comprobante level consolidates all taxes from all line items. It contains:

• TotalImpuestosTrasladados: sum of all transferred IVA and IEPS
• TotalImpuestosRetenidos: sum of all ISR and IVA withholdings
• Traslado and Retencion nodes grouped by tax type, rate, and factor type

Complemento and Addenda

The Complemento node is the SAT's extension point for mandatory additional information. This is where the digital tax stamp goes when the PAC stamps the CFDI. It's also where CFDI complements (complemento, an XML extension the SAT defines for specific operations) live: payment, payroll, Carta Porte (the CFDI complement that documents the transport of goods in Mexico), foreign trade, and others. It's defined as xs:any, meaning it accepts any XML that conforms to a SAT-registered XSD schema.

The Addenda node is similar but for private commercial use between issuer and recipient. It isn't valid for tax purposes; it's where companies add extra information like purchase order numbers, cost centers, or logistics data that their ERP needs.

CFDI 4.0: the current version

Version 4.0 became mandatory on April 1, 2023, after a transition period in which version 3.3 was still accepted. The biggest changes from 3.3 hit the recipient data requirements hard.

Previously, you could get away with only the recipient's RFC and a generic CFDI use code. Now you need their full legal name, RFC, tax address (postal code), and tax regime. This broke integrations everywhere because most systems didn't collect that level of detail from customers. For companies building tax compliance into their software, it meant reworking entire onboarding flows to capture the extra fields.

A mandatory export field was added to every CFDI, even if you don't export anything (set it to 01 - Not Applicable in that case).

Cancellation is stricter too, though these rules aren't specific to 4.0: the SAT applies them to every CFDI version, 3.3 included. You can no longer cancel a CFDI unilaterally after the next business day following issuance. The recipient has to accept the cancellation, except for amounts of $1,000.00 MXN or less and other cases the SAT lists.

CFDI complements: how electronic invoicing evolved

When e-invoicing started in Mexico, the CFDI only needed to represent two things: an income invoice (type I) and a credit note (type E). That initial model worked for the first years. But fiscal reality is more complex than that: there are deferred payments, payroll, freight and goods transfer, foreign trade, and dozens of operations that the tax authority needs to track in detail.

The original income and credit note model wasn't enough to capture all that information. The SAT's solution was to create CFDI complements: sub-XMLs that are inserted inside the main XML to represent specific real-world fiscal concepts.

How the complement architecture works

The main CFDI XML is defined by the Comprobante element (its official schema is the CFDI 4.0 XSD). Inside that XML there's a node called Complemento, and that's where complement sub-XMLs are inserted. Each complement has its own XSD schema, its own validation rules, and its own required fields. It's literally another XML inside the XML.

The most important complements

CFDI frequently asked questions

Issuing a CFDI with Fiscalapi

Building the XML, validating against SAT's catalog, communicating with the PAC, handling the response: doing all of this from scratch is not a good use of your time. Fiscalapi wraps the entire flow into a single API call and returns the stamped XML and its UUID in the response. Cancellations, status checks, and PDF generation all use the same invoice id you get back. SDKs are available for .NET, Node.js, Python, PHP, and Java. Check the documentation to get started or browse working examples on GitHub.

The test environment at test.fiscalapi.com lets you stamp CFDIs at no cost with no tax consequences. It runs the stamping flow, including stamping validations such as the RFC and tax regime checks. Use it before pointing anything at production. The full API documentation covers every endpoint from issuance to cancellation.