CFDI Data Extraction:
The Complete Guide to Mexican Electronic Invoices

What Makes CFDI Different from Any Other Invoice

Every invoice you have ever processed from a US, European, or Asian supplier follows the same basic pattern: the supplier issues a document, you receive it, and the data — invoice number, date, amount, tax — lives on the document itself. The document is the source of truth. CFDI inverts this model entirely.

A CFDI (Comprobante Fiscal Digital por Internet) is an XML document that must be validated and stamped by a government-authorized PAC (Proveedor Autorizado de Certificación) before it becomes legally valid. This is called the clearance model: the issuer generates the XML, submits it to a PAC, the PAC verifies the structure and digital signature, applies a timbre fiscal (digital stamp), and forwards a copy to SAT — Mexico's tax authority — in real time. Only after this three-way handshake does the invoice exist as a legal document. The UUID (Folio Fiscal) assigned by SAT at that moment becomes the permanent identifier that ties that transaction to every subsequent audit, payment, and tax filing.

This has a practical consequence that surprises most AP teams handling Mexican suppliers for the first time: the XML file is the legally valid invoice. The PDF that arrives attached to the same email is a decorative printout — useful for human review, but carrying no legal weight. Under CFF Article 30, both issuer and recipient must retain the original CFDI XML for at least five years. Disposing of the XML while keeping only the PDF creates an audit exposure that many teams discover only when SAT requests records.

The current version, CFDI 4.0, has been mandatory since April 2023. It introduced stricter recipient validation: the receiver's RFC, legal name, and fiscal domicile postal code must match SAT's taxpayer registry exactly. Version 3.3 invoices are no longer accepted. For anyone building a CFDI extraction workflow, this means every document you handle follows the 4.0 schema — a consistent target for extraction, but one that carries more mandatory fields than previous versions.

The core problem in CFDI extraction is not that the data is missing. It is that the data lives in a format designed for government clearance, not for spreadsheet consumption — and the bridge between the two is what most teams struggle to build.

The Six CFDI Document Types — and When You'll Encounter Each

CFDI is not a single document type. SAT defines six distinct comprobante types, each with its own schema rules, mandatory fields, and extraction requirements. If you process invoices from more than a handful of Mexican suppliers, you will encounter most of them.

The type that creates the most extraction friction in practice is Pago. When a supplier issues an invoice under PPD payment terms, the invoice itself carries the line items and totals but not the payment details. Every time the buyer makes a payment, the supplier issues a separate Pago CFDI containing a Complemento de Pago that specifies which UUID is being paid, in what amount, on what date, and by what method. An AP team processing 40 PPD invoices may have 60–80 CFDIs to reconcile — each requiring a UUID cross-reference between the Ingreso and its payment complement(s).

Core Fields, SAT Catalogs, and What Each Means for Your Spreadsheet

Understanding which fields to extract is not just a technical question — it determines whether your output is usable for DIOT filing, IVA credit reconciliation, and audit response. Every field in a CFDI maps to a SAT catalog code, and the same field can carry different tax consequences depending on the code selected.

Header-Level Fields (Comprobante Node)

Tax Breakdown: IVA, Retenciones, and IEPS

The tax structure in a CFDI lives below the concept (line item) level, nested inside each Concepto. This means the IVA rate and amount are per-line-item, not invoice-level aggregates. Extraction must sum them if your output needs a single tax line per invoice, but the underlying data is granular:

• IVA 16% — standard rate applied to most goods and services. The border region (northern and southern frontier) qualifies for a reduced 8% IVA rate under certain conditions.
• IVA 0% — applies to exports (Exportación=02/03) and certain basic food items, medicines, and agricultural supplies.
• IVA Retenido — the recipient may be required to withhold two-thirds of the IVA and remit it directly to SAT. The CFDI shows both ImpuestosTrasladados (IVA charged by the supplier) and ImpuestosRetenidos (IVA withheld by the buyer).
• ISR Retenido — 10% withholding on services provided by individuals, 1.67% on purchases from the general regime, 20% on interest payments. These must be reported in the monthly DIOT.
• IEPS — excise tax on specific goods: alcohol, tobacco, gasoline, sugary drinks. Each product category maps to a different IEPS rate (3%–160%).

For extraction, the critical point is that one CFDI can carry multiple tax combinations across different line items. A single invoice from a distributor that sells both standard goods (IVA 16%) and IEPS-liable products will have items at 16%, at 16%+IEPS, and potentially at 0%. Your extraction output must either preserve line-level tax detail or correctly aggregate per rate.

The Complemento Layer: Where Most Extraction Guides Stop

A complemento is a structured XML addendum that extends the base CFDI schema for specific transaction types. The base CFDI covers the invoice header and line items. Everything else — payment details, payroll breakdowns, customs data, transport information — lives in complementos. For AP teams processing Mexican invoices, three complementos matter most.

Complemento de Pago (Payment Complement)

Attached to every Pago CFDI, this complement is the single biggest source of extraction complexity in real-world Mexican AP. When a supplier issues an invoice under PPD terms (MétodoPago=PPD), the original Ingreso invoice does not contain payment data. Every time the buyer pays — whether in full, in partial amounts, or on deferred terms — the supplier issues a Pago CFDI whose Complemento de Pago records:

• The UUID of the original Ingreso invoice being paid
• The payment amount applied to that UUID
• The payment date and payment method (transfer, cheque, cash, card)
• The currency and exchange rate at payment time (critical when the original invoice was in USD)
• The outstanding balance after this payment (saldo insoluto)

One Ingreso invoice may be settled by multiple Pago CFDIs — each referencing the same UUID with a different payment amount. The extraction challenge is not technical (the UUID is always present) but procedural: most AP teams never extract the Complemento de Pago at all, leaving the payment data in a separate document that nothing in the workflow connects to the original invoice.

A CFDI line-item extraction that stops at the invoice header and leaves complementos untouched captures roughly 60% of the data your AP team actually needs.

Complemento de Nómina (Payroll Complement)

Employers in Mexico must issue a Nómina CFDI for every employee payment — salary, bonuses, commissions, vacation premiums, severance, and Christmas bonus (aguinaldo). The Complemento de Nómina is one of the most field-dense documents in the CFDI system, containing 50+ structured fields including:

• Employee CURP and IMSS social security number
• Base salary and daily salary (Salario Base de Cotización)
• Ordinary income (percepciones) broken down by type code — Sueldos, Aguinaldo, Prima Vacacional, PTU
• Deductions (deducciones) — ISR withheld, IMSS contributions, INFONAVIT loan payments, SAR/Afore, pension loans
• Overtime hours (Horas Extra) with time type and percentage
• Total net payment

For multi-entity employers, payroll extraction means processing hundreds of Nómina CFDIs per pay cycle. Each employee produces one CFDI per payment, and each requires the complemento fields to be flattened into a HR or payroll reporting spreadsheet.

Complemento de Comercio Exterior (Foreign Trade Complement)

Required when Exportación=02 (definitive export with A1 customs key) or Exportación=03 (definitive export with A2 key). This complement carries the customs-side data for cross-border transactions:

• Pedimento number (customs declaration ID)
• Exporter RFC and full address
• Foreign tax ID of the receiver
• INCOTERM code
• Per-line detail: tariff fraction (fracción arancelaria), customs unit of measure, USD value of goods
• Country of origin and destination

Version 2.0 of this complement has been integrated with CFDI 4.0 since January 2024. For companies that export goods from Mexico, extraction that captures both the base CFDI fields and the foreign trade complement data is essential for reconciling freight invoices against customs declarations.

Why Different PACs Mean Different PDF Layouts

Every CFDI starts from the same XML schema — Anexo 20 version 4.0, defined in SAT's published XSD. The XML is consistent regardless of which PAC stamps it. But the PDF representation, which is what most AP teams actually look at, depends entirely on how each PAC chooses to render the XML into a visual format.

In practice, a CFDI PDF stamped by Finkok will arrange fields in a different visual order than one stamped by SW sapien, Digifact, FacturAPI, or SAT's own free tool. The data is identical. The layout is not. For template-based OCR tools that rely on fixed-position extraction zones, each PAC layout requires a separate template. A business receiving invoices from 20 suppliers that collectively use 8 different PACs would need 8 extraction templates — and would miss invoices from the 9th PAC they had not yet configured.

This is where semantic extraction — AI that reads a document by understanding what each field means rather than where it sits — changes the economics of CFDI processing. A semantic extraction tool that knows the difference between a UUID and an RFC can find both fields anywhere on the page, whether the PAC positioned them at the top, left, right, bottom, or inside a bordered box. The PAC's layout becomes irrelevant, which means a single extraction configuration covers every supplier and every PAC in your portfolio.

Extraction Methods Compared: Which Approach Fits Your CFDI Workflow?

Different teams choose different approaches to CFDI extraction based on document volume, format mix, technical capability, and budget. The following table maps the four main methods against the dimensions that matter for Mexican invoice processing.

The choice between XML parsing and AI semantic extraction is not always straightforward. If every supplier sends the raw CFDI XML and your team has scripting capability, XML parsing using XPath or a library like lxml in Python produces clean, direct field extraction from the structured data. The limitation is that XML parsing cannot read scanned invoices, cannot interpret the visual PDF representation when the XML is not attached, and requires active maintenance when SAT updates the schema (as happened with the 3.3→4.0 migration).

AI semantic extraction, by contrast, works from any visual document — PDF, scanned image, phone photo — and does not require a structured XML input. Modern vision models trained on thousands of invoice layouts can locate the UUID, RFC, and IVA fields by understanding what those labels mean, regardless of where in the document they appear. For teams that receive a mix of PDF attachments (no XML) and scanned documents, this is the only scalable option.

How AI Extraction Handles CFDI Documents — Across All Three Formats

The most practical scenario for most AP teams is that you receive a mix of XML files, PDF attachments, and scanned documents from different suppliers using different PACs. Building a separate workflow for each format creates maintenance overhead and processing gaps. An AI extraction approach that treats all three as input sources with a single field definition simplifies this dramatically.

ImageToTable.ai handles CFDI extraction through its Custom Column Extraction paradigm — you define the columns you want in your output, and the AI locates each value by understanding what the field means, not where it sits on the page. For CFDI, the workflow is:

This approach solves the PAC layout problem automatically: the AI does not depend on fields being in a fixed position, so a CFDI rendered by Finkok (with UUID in the top-right corner of the second page) and one rendered by FacturAPI (with UUID in the lower-left footer) both produce the same structured output.

For complemento extraction specifically, when processing XML files directly, the AI can navigate the hierarchical structure — traversing from the /Complemento/Pagos node of a Pago CFDI to extract the referenced UUID, payment amount, and date. For PDF representations of the same Pago CFDI, the AI reads the complemento fields from wherever the PAC chose to display them on the visual document.

Integrating CFDI Data with Mexican Accounting Software

Extracted CFDI data is only useful if it reaches the system your accounting team actually works in. The Mexican accounting software ecosystem differs significantly from the US or European landscape — the dominant players are local, and each has specific data import expectations.

CONTPAQi

CONTPAQi is the most widely used accounting and business management suite in Mexico, covering accounting (Contabilidad), electronic invoicing (Factura Electrónica), payroll (Nóminas), and commercial operations (Comercial). CONTPAQi natively imports CFDI XML for verification, but for bulk data analysis — reconciling 200 supplier invoices against budget codes, building spending reports by UsoCFDI category, or preparing DIOT inputs — the data needs to be in an Excel format that maps to CONTPAQi's chart of accounts. Extracted columns like RFC, UUID, and IVA amount directly populate CONTPAQi's auxiliar de cuentas when imported as a batch journal entry.

Aspel SAE / COI / NOI

Aspel is the second most common accounting platform in Mexican SMEs, with SAE (administrative), COI (accounting), and NOI (payroll) modules. Like CONTPAQi, Aspel can process CFDI XML for individual invoice verification, but its reporting layer works best when batch CFDI data is pre-compiled in an Excel table that matches Aspel's import templates. Common practice among Mexican controllers is to maintain an auxiliary CFDI register in Excel — one row per invoice, columns for RFC, UUID, folio, IVA rate, and retain — and reconcile it against Aspel's ledger monthly. Automated extraction turns that auxiliary register from a manual typing exercise into a direct export.

SAP and Oracle NetSuite

Larger enterprises operating in Mexico typically run SAP or Oracle NetSuite with localizations for CFDI compliance. These systems handle the XML validation and PAC submission automatically through their built-in CFDI modules. However, the challenge shifts from compliance to reconciliation: procurement and AP teams need to match extracted CFDI data against purchase orders, goods receipt notes, and supplier contract terms. An AI extraction workflow that outputs CFDI data as structured rows — with UUID, RFC, line-item product codes (c_ClaveProdServ), and tax breakdown — feeds directly into SAP's MIRO (Logistics Invoice Verification) or NetSuite's AP batch import processes.

Frequently Asked Questions

The gap between "I have CFDI documents" and "my accounting system has the data" is not a technology gap — it is a format translation gap. The right extraction workflow closes that gap in minutes, not hours.

CFDI data extraction is not fundamentally difficult. The XML is structured. The PDF carries the same data. The complementos are documented in SAT's published XSDs. What makes it hard in practice is the diversity of formats, the variability of PAC layouts, the hierarchical nesting of tax and complemento data, and the fact that most extraction workflows were designed for flat, position-based documents that look the same every time. A semantic approach — one that reads documents by understanding what each field is, not where it sits — handles all of these complexities from a single field definition. You define the columns. The AI finds the data. The format becomes irrelevant.

If you are processing Mexican supplier invoices today and spending more time moving data between documents than using it, the next step is straightforward: take a sample batch — 10 to 20 CFDI files in whatever format you have — and run them through an AI extraction workflow. The gap between "I have the documents" and "my spreadsheet has the data" is smaller than the manual process makes it feel.

This article is part of the ImageToTable.ai guide series on invoice data extraction. For a broader overview, see What Is Invoice Data Extraction? and What Is OCR?. For the beginner's introduction to CFDI, read What Is a CFDI?. For a practical step-by-step extraction tutorial covering each CFDI format, see Mexican CFDI Invoice Data Extraction to Excel. For a deeper look at why CFDI processing confounds traditional AP workflows, read Why Mexican CFDI Invoice Processing Is Harder Than Most Teams Expect.