If you sell in Mexico, every invoice has to become a SAT-stamped CFDI 4.0 with a valid UUID before it is legally issued — and ERPNext core has no idea what a CFDI, a PAC, or a complemento de pago is. Teams typically bridge the gap with brittle spreadsheets, a separate portal from their PAC (Finkok, SW Sapien, Facturama, etc.), and manual re-keying that drifts out of sync with the actual Sales Invoice. The moment SAT rejects an XML for a bad RegimenFiscalReceptor, a missing UsoCFDI, or a wrong ObjetoImp, the finance team is stuck reconciling paper against a portal that the ERP never sees.

ECOSIRE builds a proper Frappe app that makes CFDI 4.0 a native part of your ERPNext document flow. We add a custom CFDI Document DocType linked one-to-one to Sales Invoice, plus a PAC Settings single DocType holding your credentials, CSD certificate (.cer/.key), and environment (sandbox vs. production). On submit, a hooks.py doc event (Sales Invoice: on_submit) builds the CFDI 4.0 XML from the invoice, its items, customer RFC and tax rows — populating cfdi:Comprobante, cfdi:Emisor, cfdi:Receptor, cfdi:Conceptos and the cfdi:Impuestos block with correct IVA/retenciones — then calls your PAC's stamping API through a whitelisted server method. The returned TimbreFiscalDigital (UUID, SAT seal, certificate number, stamp timestamp) is written back onto the linked record and the stamped XML plus a rendered PDF are attached to the invoice.

Payment complementos are handled where the money actually moves: a doc event on Payment Entry builds the Complemento de Pago 2.0 (Pagos20) referencing the related CFDIs, their IdDocumento UUIDs, ImpSaldoAnt/ImpPagado amounts and payment method, then stamps it through the same PAC lane. Cancellations follow the SAT 4.0 motive codes (01–04) with the substitution-UUID requirement for code 01; we expose a guarded cancel action that calls the PAC's cancellation endpoint, records the acuse, and reflects the accepted/pending status back on the document. A scheduler event polls for pending cancellation acknowledgements so nobody has to babysit the PAC portal. Everything is permission-gated with a dedicated role profile so only authorized accounting users can stamp or cancel, and the stamped artifacts are reachable over the Frappe REST API for downstream integrations.

Because this is build-to-order, nothing ships until we agree on scope. We start with a short scoping call to confirm your PAC, CFDI use cases (ingreso, egreso, pago, traslado), regimes and edge cases, then build against your chart of accounts and tax templates. You get the work validated on a staging bench first, a UAT sign-off, and a clean cutover to production on Frappe/ERPNext v15 or v16. Typical delivery is one working week from confirmed scope, and you receive the full source as an installable Frappe app plus the git repository so you are never locked in.