SAT/CFDI E-Invoicing Integration in Custom Software

TL;DR: E-invoicing is where custom software built for Mexico quietly breaks: CFDI 4.0 is a regulated integration that changes every year, not a feature you bolt on at the end. Your system never stamps invoices itself — a SAT-authorized PAC does, and unless you handle massive volumes, integrating an existing PAC wins. The essentials: validate the customer's tax data before stamping, archive the stamped XML (the PDF isn't the invoice), and build in retries so a PAC outage doesn't stall sales.

Why invoicing is the most underestimated piece

Any software that handles sales, inventory, or logistics in Mexico will eventually need to issue a CFDI (Comprobante Fiscal Digital por Internet — Mexico's mandatory electronic invoice). It is not optional, and it is not something you “add at the end.” Yet in most rescue projects that reach us, invoicing was treated as just another module in the final week of the timeline.

The catch: electronic invoicing in Mexico isn't a feature — it's a regulated integration that changes every year. CFDI 4.0 has been mandatory since April 2023 as the only valid version for invoices, credit notes, and any tax receipt (Docdigitales, 2025). A system that doesn't account for it in its architecture ends up patched every time the SAT (Mexico's tax authority) publishes an update.

What CFDI 4.0 demands from your system

CFDI 4.0 tightened data validation. Your software can no longer “stamp and see what happens” — it has to validate before sending. The fields that cause the most rejections:

• Exact recipient name and tax address. They must match the SAT's records character for character. One wrong accent, a mistyped legal suffix, or an incorrect postal code, and the invoice is rejected.
• Mandatory recipient tax regime. RESICO, general corporate regime, individual with business activity — your system must capture and validate it.
• CFDI usage consistent with the regime. Not every usage code is valid for every regime, and the SAT enforces it.

The golden rule: your software must validate the customer's tax data before attempting to stamp, ideally against their official tax status certificate. Validating afterward is validating too late.

You don't stamp invoices — the PAC does

This surprises many foreign buyers: your software doesn't “invoice” on its own. Only an Authorized Certification Provider (PAC — Proveedor Autorizado de Certificación) recognized by the SAT can validly stamp a CFDI. The real flow is:

1. Your system generates the XML with the transaction data.
2. It sends it via API to a PAC.
3. The PAC certifies (“stamps”) it and returns the receipt with a digital seal and fiscal folio.
4. Your system stores the stamped XML and generates the printable representation (PDF).

So your invoicing integration is really an integration with a PAC: handling its API, error control, retries, and storage. Any serious vendor must work with a certified PAC or connect directly to one.

The Carta Porte complement: where the fines are

If your company moves goods — own fleet, branch transfers, distribution — you need the Carta Porte complement inside the CFDI, stamped by a PAC. There is no paper version with fiscal validity.

Version 3.1 has been mandatory since July 2024, and penalties rose: fines reach up to $97,330 MXN per document issued incorrectly (IDNUBE, 2026; SAT Fácil, 2026). For a logistics-heavy business, a careless complement integration isn't a bug — it's a recurring financial risk.

The 5 integration mistakes that lead to fines or blocked payments

1. Outdated catalogs. The SAT updates its catalogs periodically (for example, in January 2026). If your PAC or system doesn't refresh them, “silent” validation errors appear: invoices that looked fine but the SAT rejects.
2. Validating after stamping. If you discover a wrong tax ID or regime only after stamping, you've already paid for a stamp and must cancel and re-issue.
3. Not handling cancellations with a reason code. Since 2022, every cancellation requires a reason code and, in many cases, the recipient's acceptance. A system that cancels “the old way” leaves live CFDIs that shouldn't be.
4. Confusing the PDF with the invoice. The tax document is the stamped XML, not the PDF. If your system doesn't archive and back up the XML, you don't have invoices — you have pretty pictures.
5. Coupling stamping directly to the sale with no retries. If the PAC has a brief outage and there's no retry queue, the sale stalls and the customer walks. Invoicing must be resilient, not a single point of failure.

Integrate a PAC or build your own stamping?

This is the key architecture decision. Unless you stamp very high volumes, integrating an existing PAC almost always wins:

The stamped XML, not the PDF, is your invoice. Everything else is a pretty representation of a document that actually lives at the SAT.

What to demand from your software vendor — the Kynoz standard

If you're building or rescuing an invoicing integration, require the proposal to include:

• Tax-data validation before stamping (ideally against the official tax status certificate).
• PAC error handling with retries and logging, so an outage doesn't stall your sales.
• Storage of the stamped XML and acknowledgments, not just the PDF.
• Cancellations with a reason code and a recipient-acceptance flow.
• A catalog-update plan, so you don't fall behind every January.
• Testing in the SAT's sandbox before going to production.

The message for finance and operations

Invoicing isn't “an IT detail”: it's cash flow and regulatory exposure at the same time. A clean integration collects on time, avoids rejections, and shields you from fines; a sloppy one blocks payments, multiplies administrative rework, and exposes you to penalties that never appear in the project budget — but do appear in the P&L.

For nearshore buyers and foreign companies operating in Mexico, this is also a litmus test for a vendor: a team that handles CFDI, PACs, catalogs, and Carta Porte fluently understands the Mexican operating reality. One that treats it as an afterthought will hand you that risk.

FAQ

How does SAT CFDI 4.0 e-invoicing integration work in custom software for Mexico?

Through a PAC (Authorized Certification Provider): your system generates the XML for the transaction, sends it via API to the PAC, the PAC stamps it and returns the receipt with a digital seal and fiscal folio, and your software stores that XML and produces the printable PDF. In practice, an invoicing integration is a PAC integration — API handling, error control, retries, and storage.

Why does Mexico's SAT reject invoices that look correct?

Because CFDI 4.0 requires the recipient's name and tax address to match the SAT's records character for character — one wrong accent or postal code is enough for a rejection. The recipient's tax regime, the CFDI usage code, and outdated catalogs cause rejections too. The fix is validating tax data before stamping, ideally against the customer's official tax status certificate.

Should we integrate an existing PAC or build our own stamping service?

Unless you stamp very high volumes, integrating an existing PAC almost always wins: you reach production in weeks, pay per stamp, and catalog maintenance is handled by the PAC. Building your own stamping means months of work plus SAT certification, which only makes sense for massive volumes or fintech-scale operations.

What are the fines for an incorrect Carta Porte complement in Mexico?

Fines reach up to $97,330 MXN per incorrectly issued document, and version 3.1 has been mandatory since July 2024. If your operation moves goods in Mexico — own fleet, branch transfers, distribution — the Carta Porte complement must travel inside the CFDI and be stamped by a PAC; no paper version has fiscal validity.

Is the PDF a valid tax invoice in Mexico, or do we need the XML?

The stamped XML is the legal tax document; the PDF is just its printable representation. A system that archives only PDFs doesn't hold invoices — it holds pretty pictures of a document that actually lives at the SAT. Any serious integration stores and backs up the stamped XML along with its acknowledgments.

What should we require from a nearshore vendor building our CFDI integration?

Make the proposal spell it out: tax-data validation before stamping, PAC error handling with retries and logging, storage of the stamped XML and acknowledgments, cancellations with a reason code and recipient acceptance, a catalog-update plan, and testing in the SAT's sandbox before production. For nearshore buyers this doubles as a litmus test — a vendor fluent in CFDI, PACs, and Carta Porte understands the Mexican operating reality.