Any Mexican business running ERPNext quickly hits a wall at invoicing time. The SAT requires every Sales Invoice to be stamped as a CFDI 4.0 (Comprobante Fiscal Digital por Internet), with a certified PAC applying the digital seal, a valid uso CFDI, a matching regimen fiscal for both emisor and receptor, correct RFC formatting, and — for anything not paid on the spot — a separate Complemento de Pago (REP) when the money actually arrives. ERPNext core has no notion of any of this. Its Sales Invoice, Payment Entry, and Customer DocTypes were never designed for the SAT catalogs, so accountants end up double-keying every invoice into a portal or a third-party desktop tool, reconciling by hand, and hoping the cancellation window and acuse are handled correctly.

ECOSIRE builds a proper Frappe app (erpnext_mx_cfdi) that closes that gap by wiring ERPNext directly to FacturAPI, which acts as your certified PAC. We add the SAT-specific fields where they belong — custom fields and child DocTypes on Sales Invoice, Payment Entry, and Customer for uso_cfdi, regimen_fiscal, forma_pago, metodo_pago, objeto_impuesto, and RFC — plus new DocTypes such as CFDI Log (one row per stamping attempt with UUID, status, and the returned XML/PDF) and SAT Catalog records so c_UsoCFDI, c_RegimenFiscal, c_FormaPago, and c_ClaveProdServ values are validated against real allowed lists instead of free text. RFC format is checked with a validated pattern before anything is sent, so malformed tax IDs never reach the PAC.

Technically, the stamping is driven by hooks.py doc events. On Sales Invoice on_submit, a server-side handler assembles the CFDI 4.0 payload, calls FacturAPI over HTTPS, stores the returned UUID (folio fiscal), the sealed XML, and the PDF back on the document, and writes a CFDI Log entry — all inside idempotent, retry-safe logic so a network blip never produces a double-stamp. Payment Entry on_submit generates the Complemento de Pago automatically when metodo_pago is PPD. Cancellations follow the SAT motivo-de-cancelacion flow (01–04, including substitution UUID) exposed as a whitelisted method and a document action. Whitelisted REST methods let you stamp, fetch, or cancel programmatically; client scripts surface stamping status, the UUID, and one-click XML/PDF download in the Sales Invoice form; role-based permissions and a dedicated CFDI role profile keep stamping and cancellation limited to your fiscal team; and a scheduler event reconciles any invoice left in a pending or error state against FacturAPI so nothing silently falls out of sync.

Because this is build-to-order, you are not downloading a generic marketplace add-on and hoping it fits. After a short scoping call we confirm your PAC/FacturAPI account, your emisor certificates (CSD), your series/folios, your regimen fiscal, and the exact invoice and payment flows you use. We then build the app against your ERPNext version (Frappe/ERPNext v15 or v16), test it on a staging copy of your data with your real customers and product catalog, and only cut over to production after you sign off on UAT. Typical delivery is one working week from confirmed scope, and you receive the full app source in a Git repository you own, so nothing about your compliance stack is a black box.