Mexican CFDI Invoice Processing
50+ XMLs from 14 Suppliers, One Clean AP Spreadsheet

When 50 CFDI XMLs Hit Month-End — The Gap Between "Each XML is Valid" and "The Batch is Clean"

Mexico's CFDI system operates on a three-party clearance model: the supplier generates an XML under Anexo 20 specifications, a certified PAC validates and stamps it with a UUID (the 36-character Folio Fiscal), and SAT receives it in real time. By the time a CFDI reaches your AP department as the receptor, the XML has already been certified. This is different from paper invoices or PDF-only vendor bills in most other countries — and it creates a misleading first impression.

Because each XML is individually valid, AP teams assume the batch will be clean too. It won't. Five structural problems emerge when you gather 50+ CFDI XMLs from multiple suppliers and try to consolidate them into a single AP spreadsheet:

PUE and PPD mixing. CFDI invoices carry a Método de Pago field that splits your entire batch into two fundamentally different processing pipelines. PUE (Pago en una sola exhibición) invoices are complete in themselves — the invoice is the final fiscal record. PPD (Pago en parcialidades o diferido) invoices are incomplete until a matching Pago CFDI with a Complemento de Pago arrives. In a batch of 50 supplier XMLs, you might have 32 PUE and 18 PPD. The PPD ones can't be booked until the payment complement is received and verified against the original invoice UUID. If your AP spreadsheet treats them all as equivalent line items, you'll book 18 transactions that are not yet deductible for IVA purposes.

Uso CFDI fragmentation. Every CFDI carries a mandatory Uso CFDI code — a SAT catalog value that determines how the receptor (your company) will apply the invoice for tax purposes. G01 (general business acquisition), G03 (general expense), and D01 (deductible acquisition for specific operations) are all common in a supplier batch — but they trigger different tax treatments, different DIOT reporting categories, and different IVA credit rules. A spreadsheet that lumps all CFDIs into one "Tax" column without the Uso CFDI code is useless for filing the DIOT, the monthly VAT purchase declaration due by the 17th.

UUID-based deduplication failure. Most AP systems deduplicate on vendor name + invoice number. In CFDI, the invoice number (Folio) is only unique within a single supplier's Serie — and even then, a supplier might append a new UUID after canceling and reissuing a corrected invoice. The true unique identifier is the 36-character Folio Fiscal (UUID) assigned by the PAC during timbrado. Without extracting the UUID from every XML, two different CFDIs from different suppliers with the same Folio value will be flagged as duplicates — or a corrected replacement CFDI won't be recognized as superseding the original.

Complemento de Pago reconciliation lag. For PPD invoices, the payment receipt (CFDI Tipo Pago with Complemento de Pago) arrives separately — sometimes days or weeks after the original Ingreso invoice. It references the original invoice UUID, records the payment amount, date, and method, and must be cross-referenced against the open AP line. In a manual workflow, matching 18 PPD invoices to their respective Complemento de Pago across a batch of 50+ documents is a reconciliation exercise that can take hours — and one missed match leaves an undeductible expense in your ledger.

RFC format variations in the receptor block. CFDI 4.0 mandates exact RFC in the receptor (your company's) node. But some suppliers — particularly smaller ones or agricultural producers — issue CFDIs with generic RFC XAXX010101000 when they don't have your complete fiscal data. Others send invoices addressed to your subsidiary's RFC while your AP system expects the parent company's RFC. These mismatches flag at the SAT level: the CFDI exists, it's certified, but the receptor RFC doesn't match your registered tax ID, which means IVA credit may be denied during audit.

PUE vs PPD in Bulk — Why One Campo Splits Your Entire Month-End Process

In Mexico's CFDI system, Método de Pago is not a reporting convenience. It is a fiscal classification that determines whether an invoice can be deducted immediately or only after a matching payment receipt is filed. According to the Resolución Miscelánea Fiscal (RMF), PUE invoices are deductible at issuance. PPD invoices become deductible only when the Complemento de Pago is issued and the payment event is registered with SAT.

For batch processing, this binary creates a practical fork in your workflow:

The batch processing implication: before you run any extraction, you must first sort the CFDI XMLs by Método de Pago. The PUE batch can go straight to extraction and booking. The PPD batch needs a secondary pass — each Ingreso must be matched to its corresponding Pago CFDI before it enters the ledger. If you don't split the batch upfront, you'll have 18 booked transactions that are not yet fiscally complete, and your DIOT will disagree with your AP ledger.

For AP teams processing 50+ CFDI XMLs at month-end, sorting by Método de Pago — and keeping a running list of unreconciled PPD UUIDs — is the single most important pre-processing step. It's also the one most frequently skipped, because most batch processing tools treat all invoices as equivalent.

Uso CFDI Sorting — Why G01, G03, and D01 Can't Share the Same Reconciliation

The Uso CFDI catalog (c_UsoCFDI) is a SAT-maintained code list that the receptor — your company — must assign correctly for every received CFDI. This is not the supplier's decision; it's your declaration of how the expense will be treated. The three most common codes in a supplier batch:

G01, G03, and D01 CFDIs flow to different lines on the DIOT — Mexico's monthly VAT purchase declaration, due by the 17th of each month and now filed entirely online through SAT's web platform. If your batch extraction output treats all three codes as a single "Tax" column, your DIOT preparer must manually re-sort the extracted data by Uso CFDI before filing. That's an extra pass on 50+ rows.

The fix is simple: extract the Uso CFDI code as a dedicated column in your batch output. Then your AP spreadsheet can be sorted, pivoted, or filtered by code before DIOT filing — and your month-end reconciliation can validate that every G01 line in the batch matches a supplier RFC in the G01 section of the DIOT, every G03 in its respective section, and so on. A two-column extraction (Amount + Tax) is a broken batch. A multi-column extraction that preserves Uso CFDI, UUID, Método de Pago, and supplier RFC is a closed loop.

UUID Deduplication — Why the Folio Fiscal, Not the Folio, Is Your Real Invoice Number

Every CFDI XML carries two identifiers that look similar but serve entirely different purposes: the Folio (invoice number assigned by the supplier's own numbering sequence) and the UUID (the 36-character Folio Fiscal assigned by the PAC at timbrado). For AP deduplication, the Folio is unreliable. The UUID is the only trusted key.

Three deduplication failure modes specific to CFDI batch processing:

Cross-supplier Folio collision. Supplier A issues Folio #1523 in Serie A. Supplier B also issues Folio #1523 in Serie F. If your AP system deduplicates on vendor name + Folio alone, both are recognized as unique — but if the same supplier re-transmits the same CFDI after a correction, the system won't detect it as a duplicate because the UUID changed while the Folio stayed the same. You need UUID-level dedup.

Correction via CFDI substitution. Under SAT cancellation rules, a supplier can cancel a CFDI with Motivo 01 ("invoice issued with errors containing the wrong data") and reissue a corrected version with a new UUID. The old UUID is invalidated, but a system that deduplicates by Folio will see the same Folio on both the canceled and the corrected XML — and may flag the corrected version as a duplicate, suppressing the valid invoice.

Resubmission in a different batch cycle. Suppliers occasionally re-send XMLs that you've already processed — especially if they use batch email delivery at month-end. Without UUID-based deduplication, the same CFDI lands in two consecutive month-end batches and is booked twice.

For batch AP, the extraction output must include the UUID as a dedicated column. Before posting any line to the ledger, check the UUID against your transaction history. A distinct UUID count that matches the number of XMLs in the batch is a quick integrity check — if 50 files produce 47 distinct UUIDs, you have 3 duplicates to investigate before posting.

The Complemento de Pago Problem — When the Invoice Says PPD and the Payment Receipt Arrives Days Later

The Complemento de Pago is the mechanism that completes the fiscal life of a PPD invoice. When a supplier issues an Ingreso CFDI with Método de Pago = PPD, the transaction is not fiscally closed until a separate Pago CFDI arrives, bearing a Complemento de Pago that references the original invoice UUID.

For AP teams, the Complemento de Pago creates a two-document reconciliation problem that compounds at batch scale:

Timing gap. The Ingreso arrives during the month. The Pago CFDI with the payment complement arrives days or weeks later — often in a different accounting period. Your batch at month-end might contain 35 Ingreso PPD CFDIs and only 28 matching Pago CFDIs. The 7 unmatched ones can't be closed. If you book them anyway, the expense is non-deductible for IVA, and SAT's algorithmic reconciliation will flag the mismatch.

Parcialidad tracking. When a supplier payment is made in installments, each partial payment generates its own Pago CFDI. One Ingreso for $100,000 MXN paid in three installments produces three Pago CFDIs — each referencing the same original UUID but recording a different payment amount and date. Your AP spreadsheet needs to track payment status at the installment level, not the invoice level, because IVA credit becomes available incrementally as each Complemento de Pago is issued.

Cross-batch reconciliation. In practice, the Complemento de Pago rarely arrives in the same batch as the original Ingreso. Month-end AP close requires pulling the list of open PPD UUIDs from the previous month's batch, cross-referencing against newly received Pago CFDIs, and then closing the matched pairs. This is manual reconciliation work that scales linearly with batch size — 35 open PPD items = 35 manual lookups, each requiring finding the Pago XML, extracting the complement fields, and verifying the amounts match.

RFC Format Variations — Why XAXX010101000 Breaks Your Vendor Master Lookup

CFDI 4.0 tightened the receptor (receiver) identification requirements significantly compared to version 3.3. Under CFDI 4.0, the receptor node must contain the exact RFC (tax ID), legal name (Nombre), postal code (DomicilioFiscalReceptor), and tax regime (RegimenFiscalReceptor) — all pre-validated against SAT's taxpayer database before the PAC will apply the timbre. This was designed to eliminate the "fiscal ghost" problem where invoices were issued to non-existent or mismatched taxpayers.

For AP batch processing, the practical consequence is that a batch of 50 CFDI XMLs from suppliers will not have a uniform receptor RFC — even if all are addressed to your company:

In a batch of 50 supplier CFDI XMLs, especially from smaller suppliers (agricultural producers, rural distributors, independent service providers), 5–10% will carry a generic or mismatched RFC. These CFDIs are certified and technically valid — SAT accepted them — but your company cannot claim IVA credit on them. The batch output must flag these separately, and the AP team must follow up with the supplier to reissue the CFDI with the correct receptor RFC before the month-end DIOT filing window closes.

CFDI 4.0 Field Validation in Bulk — What SAT Rejects Before Your Team Sees It

CFDI 4.0, mandatory since April 1, 2023, introduced stricter field validations and new mandatory fields. For AP teams receiving batches of XMLs, the relevant changes are:

RegimenFiscalReceptor is now mandatory. Under CFDI 3.3, the receptor's tax regime was optional. Under 4.0, every CFDI must include the receptor's Regimen Fiscal code (from SAT catalog c_RegimenFiscal). If your company operates under multiple regimes — for example, Régimen General de Ley Personas Morales (code 601) for core operations and Régimen de Actividades Empresariales con ingresos a través de plataformas tecnológicas (code 625) for a separate line of business — the CFDIs in your batch must reflect which regime each transaction falls under. A mismatch between the invoice's RegimenFiscalReceptor and your registered regime creates an audit exposure.

RFC + Nombre cross-validation. CFDI 4.0 pre-validates the receptor's RFC against the registered legal name in SAT's database. If a supplier enters your correct RFC but a slightly wrong legal name (e.g., "SA de CV" instead of "S.A. de C.V."), the PAC rejects the CFDI before timbrado. This means that CFDI 4.0 XMLs reaching your inbox are structurally more reliable — but the counterpart is that errors at issuance are more likely to result in outright rejection rather than a flawed-but-certified invoice. The batch you process is cleaner but smaller: some suppliers will have had their invoices rejected and may not have reissued them yet.

Exportación field. CFDI 4.0 introduced a mandatory Exportación field (c_Exportacion) — values 01 (not subject to export), 02 (definitive export, A1), 03 (definitive export, A2), or 04 (temporary export). For companies that export goods, a batch of supplier CFDIs will contain both Exportación=01 and Exportación=02/03 invoices. The 02/03 CFDIs carry different VAT treatment (IVA at 0% on export sales) and often include the Foreign Trade Complement (Complemento de Comercio Exterior 2.0, mandatory since January 2024). These export-tagged invoices must be segregated from domestic invoices in the batch output because the DIOT filing separates domestic and export-related purchases.

For the batch validator, a quick pre-extraction scan can surface useful signals: count the distinct RegimenFiscalReceptor values (more than 1 = potential regime mismatch), check the Exportación field distribution (mixed domestic/export batch), and count distinct receptor RFCs (generic RFCs flagged). A 3-second pre-flight on a batch of 50 XMLs saves half an hour of downstream sorting.

SAT Portal Batch Download Limits — What You Can (and Can't) Pull from the Buzón Tributario

A practical constraint that shapes Mexican AP batch workflow: the SAT portal allows taxpayers to download their received CFDIs through the Buzón Tributario, but with limits that become relevant at scale. The portal's mass download functionality typically caps at 500,000 registros per request — far above what a mid-market AP team needs — but the web interface imposes a practical constraint: manual download sessions time out, and browsing through month-by-month received CFDIs to cherry-pick individual XMLs is no faster than requesting them directly from suppliers.

For AP teams processing 50–200 CFDI XMLs per month, the more common bottleneck is not SAT download limits but supplier delivery consistency. Larger Mexican suppliers using PACs like CONTPAQi (#1 PAC in Mexico) or EDICOM typically auto-deliver certified XMLs to the buyer. Smaller suppliers using free SAT tools or low-cost PACs may only generate the CFDI without automated delivery to the receptor — meaning the PDF version (with QR code for SAT verification) reaches your AP team while the XML must be requested separately.

The batch workflow for sporadic or small-supplier CFDIs where the XML is missing involves two practical approaches: either request the XML from the supplier (which adds 1–3 business days to month-end close) or use the PDF version with a data extraction tool that can read invoice data from PDFs and images — extracting the same fields into the same columns alongside the XMLs you do have. This mixed-source consolidation is where batch processing moves from "run an XML parser 50 times" to a real operational workflow.

From 50 CFDI XMLs to One AP Spreadsheet — A Month-End Workflow

Here is a batch workflow that accounts for the structural challenges described above. It's designed for an AP analyst at month-end, facing 50+ CFDI XMLs from 14 suppliers, with a CONTPAQi or Aspel-COI import deadline on day 3 after close.

This workflow processes the batch in approximately the same time it takes an analyst to manually extract data from 6–8 CFDI PDFs one at a time — but it handles 50+ and produces output that is DIOT-ready, not just "data in a spreadsheet."

For a deeper dive into the fundamentals of extracting structured data from CFDI XMLs and PDFs — including how to handle mixed-format batches where not all suppliers provide the XML — see our guide on Mexican CFDI invoice extraction to Excel.

FAQ — Batch Mexican CFDI Invoice Processing

Can batch CFDI processing handle mixed PUE and PPD invoices in the same run?

Technically yes — a batch tool can extract data from both. But for accounting accuracy, they should be processed as separate sub-batches. PUE invoices can be posted immediately. PPD invoices must be paired with their Complemento de Pago before posting. Merging both into the same output without the PPD reconciliation step creates open liabilities in your ledger.

What's the practical limit for SAT portal batch download of received CFDIs?

The SAT portal's bulk download through the Buzón Tributario supports up to 500,000 registros per request — far exceeding typical AP volumes. However, the web interface is session-timed and not designed for rapid retrieval of individual supplier XMLs. For month-end AP, requesting XMLs directly from suppliers or using an automated PAC-to-receptor delivery service is faster than manual SAT portal downloads.

Does ImageToTable.ai handle CFDI XML files directly, or only PDF versions?

ImageToTable.ai processes PDFs, JPG, PNG images, and can handle document screenshots. For XML CFDI files, you can upload the PDF rendering of the CFDI (which every Mexican supplier must provide alongside the XML), and the tool extracts the same fields — UUID, RFCs, amounts, dates, Método de Pago — into structured columns. For mixed XML + PDF batches where some suppliers only sent the printed version, everything merges into one spreadsheet.

How do you handle CFDI UUID deduplication across multiple month-end batches?

Maintain a running UUID register. Before posting each new batch, cross-check every UUID against the register. A distinct UUID count that matches the file count confirms no duplicates. UUIDs that appear in two separate batches indicate either a resubmission (same CFDI sent twice) or a correction (canceled and reissued with a new UUID — the old one invalidated). In both cases, investigate before posting. A batch extraction output that includes the UUID column makes this check a 30-second pivot table exercise.

Why do some CFDIs use a generic RFC like XAXX010101000, and can I still book those invoices?

XAXX010101000 is the SAT-designated generic RFC for a foreign receptor whose Mexican RFC is not available. You can book the invoice in your ledger, but IVA on that CFDI is not creditable — it cannot be deducted for VAT purposes. To claim IVA credit, you must request the supplier to reissue the CFDI with your company's correct, registered RFC. This is one of the most common exceptions in a batch of 50+ supplier CFDIs, and generic RFCs should be flagged before posting.

Can the Complemento de Pago be matched to its original invoice automatically in a batch?

Yes, if your batch processing tool extracts the original invoice UUID from each Pago CFDI's Complemento de Pago node — the <pago20:Pago> element references the original invoice UUID in its DocumentoRelacionado child — and cross-references it against the UUIDs of open PPD Ingreso invoices. This is a structured XML-to-XML match and can be fully automated, turning 18 manual reconciliations into zero.

What CFDI types should I expect in a typical multi-supplier batch?

In a batch from large distributors and industrial suppliers, expect mostly Ingreso (Tipo I) with Método PPD. Manufacturers and service providers may use both PUE and PPD depending on contract terms. You may also receive Egreso (Tipo E) credit notes for returns or adjustments — these must be matched against their original Ingreso and handled as contra-entries, not standalone line items. Payroll CFDIs (Tipo N, Nómina) are processed separately and should be filtered out of your AP batch.

The Real Bottleneck in Mexican AP Isn't Data Entry Speed — It's Reconciliation Integrity

If each CFDI XML takes 3 minutes to open, scan, and manually copy 8 fields into a spreadsheet, processing 50 supplier invoices consumes 2.5 hours of an AP analyst's month-end. But that calculation misses the real cost. The 2.5 hours of data entry are followed by another 3–4 hours of reconciliation — matching PPD invoices to payment complements, checking UUIDs against prior batches, sorting by Uso CFDI for DIOT filing, and chasing generic RFCs with suppliers.

The bottleneck in Mexican AP isn't data entry speed. It's that the output of a manual extraction — a spreadsheet with Vendor Name, Amount, and Tax — contains none of the fields needed for reconciliation. UUID, Método de Pago, Uso CFDI, Exportación, RegimenFiscalReceptor — these are the fields that turn a flat list of invoices into a DIOT-ready, audit-proof AP batch. A batch extraction that preserves all of them simultaneously eliminates the reconciliation pass, which is where the real time is spent.

The first time you process a batch of 50 CFDI XMLs from 14 suppliers and export a spreadsheet where the UUID column is populated, the PUE/PPD split is pre-sorted, and the Uso CFDI grouping matches the DIOT sections — you'll realize that the extraction itself was never the hard part. The hard part was the reconciliation you used to do after.