Mexican CFDI Invoice Data Extraction
to Excel: How-to Guide (2026)

What a CFDI Invoice Actually Is — and Why Extracting Data from It Is Different

A CFDI (Comprobante Fiscal Digital por Internet) is Mexico's mandatory electronic invoice format, enforced by SAT (Servicio de Administración Tributaria) since 2014. It is not a document you can treat like a PDF from a US or European supplier. Every CFDI passes through a three-party clearance model: the issuer generates the XML, a PAC (Proveedor Autorizado de Certificación) validates and digitally stamps it — a process called timbrado — and SAT receives a copy in real time. Only after the PAC applies the digital stamp does the invoice become legally valid.

The current version, CFDI 4.0, became mandatory for all taxpayers on April 1, 2023, and introduced stricter receiver validation: the recipient's RFC, legal name, and fiscal domicile postal code must match SAT's taxpayer registry exactly. Version 3.3 invoices are no longer accepted by SAT systems. For anyone receiving Mexican supplier invoices, this means every document you handle is version 4.0, whether you knew it or not.

A CFDI contains fields that have no equivalent in a standard invoice: Uso CFDI (a code declaring how the recipient will use the invoice for tax purposes — G01 for acquisitions, G03 for expenses, P01 for pending payments), Régimen Fiscal (the issuer's tax regime code), and the UUID (Folio Fiscal), a 36-character unique identifier assigned by SAT that becomes the permanent reference for that transaction across every system in Mexico's tax infrastructure. If you are reconciling payments, filing DIOT (Declaración Informativa de Operaciones con Terceros), or preparing for an audit, the UUID is the field that ties everything together.

And then there is the XML. Under Mexican tax law, the XML file is the legally valid document — the PDF representation is secondary and informational. Both issuer and receiver must retain the XML for at least five years under CFF Article 30. Failure to archive CFDIs properly carries fines of 5–10% of the invoice value per occurrence. Companies that treat the PDF as "the invoice" and discard the XML are carrying an audit risk they may not discover until the SAT requests records.

Most Mexico-facing AP teams are not lacking invoice data. They are lacking it in a format their accounting system can ingest. The XML is structured but hierarchical. The PDF is readable but unstructured. The data is the same — getting it into Excel columns is the step that breaks the process.

The Three CFDI Formats You'll Actually Receive — and What Each Means for Extraction

In practice, a Mexican supplier invoice reaches your AP team in one of three forms. Each carries the same CFDI data but requires a fundamentally different extraction approach.

XML extraction sounds straightforward — it is a structured format with a published schema (SAT's Anexo 20 version 4.0, defined in XSD). But the CFDI XML is deeply hierarchical: the root node contains issuer and receiver data, each line item (Concepto) nests quantity, unit code, product/service code (from SAT's c_ClaveProdServ catalog), unit price, and tax breakdown. A Complemento de Pago — required when the original invoice was issued under PPD (Pago en Parcialidades o Diferido) — is a separate XML document that references the original CFDI's UUID and details which payments settled which invoices, when, and in what amounts. Extracting this into flat Excel rows means traversing a tree structure and resolving cross-document references.

PDF extraction is the most common real-world scenario because Mexican suppliers typically email the PDF representation, not the raw XML. The PDF is a human-readable rendering — the same data, but without structured tags. Every field must be identified by its visual position or by semantic understanding of the text. This is where template-based OCR tools break: a CFDI PDF from Grupo Bimbo looks nothing like one from a small proveedor de servicios using CONTPAQi Factura Electrónica.

Scanned or photographed CFDIs add image quality degradation: skewed angles, shadows, low-resolution phone cameras. These arrive from smaller suppliers who print invoices and hand them to delivery drivers, or from field personnel who photograph receipts with WhatsApp. The data is still CFDI data — UUID, RFC, IVA breakdown — but extracting it means working with pixels that no XML parser will ever see.

Understanding the format variety is step one. Step two is knowing exactly which fields matter for your accounting — and which SAT catalog codes they map to.

The CFDI Fields You Need in Your Excel Output — and Why Each One Matters

Not every field in a CFDI belongs in your Excel. A full Anexo 20-compliant XML can contain over 60 distinct data points. For AP reconciliation, accounting entry, and tax filing, these are the fields that justify the column space:

These twelve fields form the minimum viable dataset for any AP workflow involving Mexican invoices. Missing the UUID means you cannot verify the invoice on SAT's portal or track its cancellation status. Missing the Uso CFDI means you may book an expense to the wrong deductibility category. Missing the Régimen Fiscal means you cannot determine whether the supplier's IVA is subject to withholding (retención de IVA, typically 6% of the IVA amount, applicable to suppliers under certain regimes).

Beyond the header-level fields, line items carry their own structured data: quantity, unit of measure (from SAT's c_ClaveUnidad catalog), description, unit price, and per-item tax breakdown. For companies performing three-way matching (PO → goods receipt → CFDI), line-item extraction is what makes the CFDI comparable to the purchase order line by line.

The fields are well-defined. The challenge is getting them out of the document and into your spreadsheet — and that process depends heavily on the format you start with.

How to Extract CFDI Data into Excel: A Step-by-Step Workflow

There are four paths to CFDI data in Excel, ranked from most to least common in real-world AP operations. The path you choose depends on whether you have the XML, the PDF, or just an image — and whether you're processing one invoice or a hundred.

Path 1: XML Parsing (when you have the raw CFDI file)

If your supplier provides the XML — or you download it from the SAT portal — you can extract structured data programmatically. Tools like Python with lxml or dedicated CFDI libraries (cfdipython, PyCFDI) can traverse the Anexo 20 schema and pull fields by XPath. The catch: this path assumes you can write code, handle namespace-qualified XML (every CFDI element sits in a SAT-defined namespace), and maintain parsing logic across catalog updates. SAT updates its catalogs periodically — the c_RegimenFiscal and c_UsoCFDI codes change, and a hardcoded mapping will go stale.

For Complemento de Pago reconciliation — matching payments to original invoices — XML parsing becomes significantly harder because you are working across two XML documents linked only by UUID reference. A single PPD invoice may be settled by multiple payments over months, each generating its own Complemento de Pago. The reconciliation logic (which payment covered which invoice, what was the outstanding balance at each point) is not a simple field extraction — it is a financial calculation across related documents.

Path 2: PDF Extraction with Template-Based Tools

Template-based OCR tools — where you draw bounding boxes around each field on a sample document and the tool re-applies those coordinates to future invoices — break on CFDI PDFs for a simple reason: every supplier uses different invoicing software. A CFDI generated by CONTPAQi Factura Electrónica renders differently from one generated by Aspel FACTURAe, Alegra, or a custom ERP integration. The UUID, RFCs, and IVA breakdown appear in different positions, at different font sizes, with different surrounding text. A template built on a Walmart addenda-compliant CFDI will fail on a small supplier's CFDI and vice versa.

This is a fundamental limitation of coordinate-based extraction applied to a document type where the data structure is standardized (Anexo 20) but the visual layout is not.

Path 3: AI-Powered Semantic Extraction (works on any format)

Semantic extraction — the approach ImageToTable.ai uses — does not look at coordinates. It reads the document as a human would: by understanding what each piece of text means, not where it sits on the page. You tell the tool what fields you want — "UUID," "RFC Emisor," "SubTotal," "IVA 16%" — and the AI locates each value anywhere on the document by recognizing the concept it represents, regardless of layout.

This mechanism is called Custom Column Extraction: you type the column names you want in your output spreadsheet, and the AI uses visual language understanding to find the corresponding data on each page. You do not draw rectangles, you do not build templates, and you do not need to know where on the page a field appears. The same set of column names works across CFDI PDFs from different suppliers, scanned copies, and XML files — because the AI recognizes "IVA 16% is the tax amount at the 16% rate" rather than "the number in the box at coordinates (430, 210)."

Here is the step-by-step workflow:

For teams processing CFDI invoices in volume, batch processing changes the economics. Upload all received CFDIs at once — whether 20 or 200 — and the tool processes them in parallel, merging all extracted data into a single Excel file with one row per invoice. The 18× speed difference between manual entry (roughly 3 minutes per invoice) and AI extraction (5–10 seconds per page) compounds with volume: 100 CFDIs that would take 5 hours of manual keying complete in under 10 minutes. For a monthly AP close cycle, that gap is the difference between finishing reconciliation on time and carrying it into the next period.

The header-level fields are the foundation. But a significant percentage of CFDI invoices — particularly those issued under PPD — carry a layer of complexity that most extraction guides ignore entirely.

Handling Complementos: Payments, Payroll, and Foreign Trade

A complemento is a structured XML addendum embedded within or linked to a CFDI. It contains data required for specific transaction types that the base CFDI schema does not cover. For AP teams, three complementos are particularly important:

Complemento de Pago (Payment Complement)

When a CFDI is issued under the PPD (Pago en Parcialidades o Diferido) payment method, the invoice itself acknowledges that payment will happen later — in installments or as a lump sum after delivery. The Complemento de Pago is a separate CFDI (TipoDeComprobante = "P") that documents the actual payment event. It references the original invoice's UUID and specifies: the payment date, the amount paid, the exchange rate if payment was in a different currency, and which original invoices (potentially multiple) this payment settled.

For extraction into Excel, this creates a one-to-many relationship: one PPD invoice → multiple payment complementos over time. Reconciling this manually means opening each payment complemento XML, reading which UUIDs it references, and updating a tracking spreadsheet. The extraction tool needs to handle cross-document reference resolution — reading the payment date and amount from the complemento and pairing it with the original invoice's data in the same output row.

Complemento de Nómina (Payroll Complement)

Payroll CFDIs carry employee-level detail: the worker's RFC, CURP (Clave Única de Registro de Población), social security number (NSS), job risk category, worked days, and detailed breakdown of perceptions (salary, bonuses) and deductions (ISR, IMSS, INFONAVIT). Companies with Mexican employees receive these as part of outsourcing or PEO (Professional Employer Organization) relationships. Extracting payroll complement data into Excel allows consolidation of employee-level costs across periods for accounting entry and labor cost analysis.

Complemento Carta Porte (Transport Complement)

Since January 2024, the Carta Porte complement version 2.0 made previously optional fields mandatory: customs declaration code, exporter details, and origin/destination data. For logistics and supply chain teams receiving freight-related CFDIs, extraction must capture the transport-specific fields — vehicle plate, transport type, route origin and destination — alongside the standard invoice data. These fields are required for SAT validation and customs clearance.

The most common CFDI extraction gap we see is complemento data left behind. AP teams extract the header fields — UUID, RFC, Total — but never pull the payment complement data, meaning PPD invoices float in the reconciliation spreadsheet with no payment date or settlement reference. The data exists in the complemento XML. It simply never made it into the Excel.

Cross-Border CFDI: When the Buyer Isn't in Mexico

Foreign companies purchasing from Mexican suppliers face an additional layer of complexity. Under CFDI 4.0, the receiver's RFC and fiscal domicile postal code must match SAT's taxpayer registry. A US or European buyer without Mexican tax registration cannot provide an RFC — but the CFDI system still requires one.

In practice, this is resolved by using the generic foreign RFC (XEXX010101000 for legal entities, XAXX010101000 for individuals) and specifying the receiver's tax ID in the destination country in a separate field. The CFDI will be issued with Uso CFDI code S01 (Sin efectos fiscales — no tax effects), meaning the invoice exists for commercial record-keeping but does not generate IVA credit or deductibility for the buyer.

For foreign AP teams, the extraction goal shifts: you are not extracting data for SAT filing, but for internal accounting, payment approval, and cost tracking. The fields that matter are the commercial ones — supplier name, invoice amount, line items, payment method — rather than the tax-specific codes. A well-structured extraction should still capture the UUID; even if you do not file with SAT, the UUID is the only globally unique identifier that definitively proves this invoice exists and was validated.

Export operations add another dimension. A CFDI with the Exportacion field set to "01" (definitiva) or "02" (temporal) carries a Complemento de Comercio Exterior with customs data: the pedimento (customs declaration) number, exporter RFC, and INCOTERM. For cross-border logistics teams reconciling freight invoices against customs declarations, extraction needs to capture both the CFDI data and the foreign trade complement fields in a single output.

How Extraction Methods Compare: Manual Entry, XML Parsing, Templates, and AI

Different teams choose different paths based on volume, technical resources, and the formats they receive. Here is how the main options compare across the dimensions that matter for CFDI data extraction:

XML parsing is the right choice for teams that exclusively receive XML and have in-house development capacity to maintain the parsing code across catalog updates. But a typical AP team in Mexico receives a mix: some suppliers send XML, some send PDF, and a handful — usually smaller suppliers or field personnel — send photos. Relying on XML parsing alone means manually entering the data from every non-XML CFDI, or maintaining a second extraction path for those formats.

Template-based OCR creates a maintenance burden proportional to the number of suppliers. Every new supplier with a different CFDI layout requires a new template. CFDI 4.0 standardized the data fields but not the visual rendering, and the cost of template management grows linearly with supplier count.

AI semantic extraction eliminates the format problem because it works on the meaning of the data, not the position. The same column definitions — UUID, RFC Emisor, IVA, Total — work on any CFDI, from any supplier, in any format. This is particularly valuable for CFDI batch reconciliation during month-end close, when AP teams need to process inbound invoices from 50–200 suppliers, each with their own invoicing system, before the accounting period closes.

FAQ: CFDI Data Extraction to Excel

Why Extraction Is Only Half the Problem

The commonly cited bottleneck in CFDI processing is data entry. But data entry is the visible bottleneck. The hidden one — the one that eats more hours across a month — is the reconciliation that comes after: matching PPD payments to original invoices, verifying that the IVA on the CFDI matches the amount in your accounting system, identifying which CFDIs have been cancelled since you last checked, and confirming that every RFC in your vendor master matches what SAT has on file.

Extraction gets the data out of the document and into a structure you can work with. The value compounds when that structured data feeds directly into your downstream processes — DIOT preparation, CONTPAQi import, vendor reconciliation, month-end accruals — without a manual re-entry step between extraction and action.

A CFDI carries more data than a standard invoice and serves a compliance purpose beyond commercial record-keeping. Extraction done right treats the CFDI for what it is: a tax document with a rigid structure, validated by a government authority in real time, carrying fields that have legal consequences if they are wrong. Getting the data into Excel is the first step. Using it to keep your AP, tax filing, and audit trail consistent is the ongoing result.