Qolca Team · 2026-06-21 · 11 min read
Expanding a business across Peru and Mexico means issuing valid tax documents under two completely different fiscal models. The hard part is not the XML — it is that the issuance lifecycle itself differs. Here is how to architect one platform that handles both.
If you operate in both Peru and Mexico — or you are a Peruvian software team building for a client that does — you eventually hit a wall that looks small and turns out to be load-bearing: you have to issue legally valid tax documents under two fiscal regimes that do not work the same way. It is tempting to treat this as a formatting problem ("Peru wants one XML, Mexico wants another") and bolt a country column onto your invoice table. That assumption is exactly what breaks in production. This article is about the real difference between the two systems and how to architect a single platform that respects both. We have a separate guide on automating SUNAT invoicing in Peru from scratch; here the focus is the multi-country dimension.
Start with the single distinction from which every other difference cascades: when does the tax authority validate the document, relative to when you hand it to the customer?
Mexico uses a hard "clearance" model. A CFDI has no legal existence until it is stamped — timbrado — by a PAC (Proveedor Autorizado de Certificación). You build the XML, send it to the PAC, the PAC validates it against SAT rules, applies the Timbre Fiscal Digital, assigns the UUID, and reports it to SAT — all before you can legally deliver the invoice to your customer. No stamp, no invoice. The PAC is a mandatory, synchronous step sitting in the middle of your issuance path.
Peru uses a soft, post-clearance model. The comprobante de pago electrónico, built in UBL 2.1, is signed by the issuer with their own certificado digital and is valid at the moment of signing and delivery. SUNAT or an OSE validates it afterward and returns a CDR (Constancia de Recepción). You can legally hand the document to the buyer before the authority has cleared it, and reconcile the CDR asynchronously within the allowed window.
Once you see the clearance distinction, the rest of the differences stop looking like trivia and start looking like a specification. The vocabulary, the identifiers, and the proof-of-validity are different at every layer.
Two of these deserve emphasis because they shape your data model, not just your serializer. First, a credit note in Peru is its own nota-de-crédito document, while in Mexico it is a CFDI tipo E that must relate back to the original income CFDI by its UUID — so Mexico forces you to maintain explicit document-to-document links that Peru does not. Second, Peru lets a business self-issue through SEE-SUNAT with no intermediary, while Mexico has a PAC in the path on every single document — which means your Mexico cost model includes a per-timbre fee and your checkout path includes a third-party network call that can fail.
Peruvian teams expanding into Mexico almost always get burned by the same thing: CFDI 4.0 validates the receiver's identity with brutal strictness. In Peru, the buyer's name on a factura is relatively forgiving. In Mexico, the receiver's nombre / razón social must match the SAT registry exactly as it appears on their Constancia de Situación Fiscal — uppercase, and without the corporate suffix (you do not include "S.A. de C.V."). The receiver's Código Postal must match SAT's record exactly, and it is the single field that causes the most rejections. The Régimen Fiscal of both parties comes from a SAT catalog, and SAT now cross-validates the Uso CFDI against the receiver's Régimen Fiscal — you can no longer assign an arbitrary use to any client.
The practical lesson is that a validator written with Peruvian leniency will produce a flood of PAC rejections in Mexico. You have to collect and validate the receiver's fiscal data up front, from their Constancia, before you ever attempt to stamp. There are two more Mexico-specific concerns with no Peru analog. One is Carta Porte — a mandatory complement attached to a CFDI whenever physical goods move in national territory, with version 3.1 mandatory since mid-2024; missing it can be treated as presumed smuggling. The other is the cancellation flow, which is nothing like Peru's comunicación de baja.
Cancellation is asymmetric. In Peru, the issuer sends a comunicación de baja and is largely done. In Mexico, cancellation is a counterparty workflow: the issuer requests it, SAT issues an acuse, and in many cases the receiver has three business days via the Buzón Tributario to accept or reject — with silence counting as tacit acceptance. There are four mandatory motivo codes, and the "errors with a substitute" path requires you to issue the replacement first and link it by UUID before cancelling. Recent rules tighten this further for documents that carry a payment complement. A Peru-first platform has no concept of an asynchronous cancellation-approval inbox; for Mexico you have to build one.
The payment complement itself is the second thing Peru lacks entirely. When a Mexican sale is paid later or in installments (PPD — Pago en Parcialidades o Diferido), you issue the income CFDI with the payment form marked "por definir," and then issue a separate CFDI tipo P — a payment receipt — for each payment you actually receive, linking the original UUID and recording the partiality number and the running balance, due by the fifth business day of the month after the payment lands. Peru has no per-payment fiscal receipt like this. A platform built Peru-first usually has no data model at all for tracking partial payments against an invoice as fiscal documents — and that has to be designed in for Mexico, not patched on.
Here is the engineering thesis that makes a two-country platform maintainable: share the commercial domain, and isolate everything fiscal behind a country adapter. Your sales flow — the customer, the line items, quantities, prices, discounts, currency, the order or quote your chatbot or POS produces — should never know what UBL, a UUID, an RFC, or timbrado is. That internal commercial document is country-agnostic. Tax lives in it only as an abstract concept: a taxable base plus a rate that an adapter will resolve later.
Everything country-specific sits behind a single adapter interface — think of a FiscalAdapter per country exposing the same handful of operations: build, sign, submit-or-stamp, poll-status, and cancel. The adapter owns the serializer (commercial doc to UBL 2.1 for Peru, to CFDI/Anexo 20 for Mexico), the catalogs and validation rules (RUC/DNI checks versus RFC plus exact name-and-postal-code matching plus the Uso-versus-Régimen cross-check), the tax resolver (IGV versus IVA), the signing and transport (certificado digital then OSE/SUNAT returning a CDR, versus CSD signing then a PAC call returning a UUID), the lifecycle state machine (post-clearance versus blocking pre-clearance), and the cancellation workflow. The platform stores the canonical commercial document plus one per-country fiscal artifact — the XML, the UUID-or-series, the CDR-or-acuse, and the status.
Build it this way and country selection becomes data-driven — a tenant maps to a country maps to an adapter — and adding Colombia or Chile later is a new adapter, not a rewrite. That is the whole payoff: the sales experience stays identical across markets while each country's fiscal reality is honored exactly, in isolation, where it belongs.
Multi-country invoicing punishes the team that thinks in file formats and rewards the team that thinks in lifecycles. Get the abstraction right once, and every new country is an adapter — not another rebuild of your entire billing stack.
At Qolca we build custom invoicing platforms for businesses operating across Peru and Mexico, with a country-config architecture that keeps the sales flow unified while honoring SUNAT and SAT each on their own terms — UBL and CDR on one side, CFDI, PAC timbrado, payment complements and the cancellation inbox on the other. The system is yours, with no per-seat lock-in on the integration layer, and it connects to whichever PSE/OSE in Peru and PAC in Mexico you prefer. If you are expanding across both markets and your billing is becoming a tangle of country-specific special cases, it is worth 30 minutes to map what a unified platform would look like for your operation. Book a free initial consultation at https://calendly.com/qolca-info/consultoria-inicial-gratuita, or message us on WhatsApp at https://wa.me/51991376769.