Saudi businesses running ERPNext hit a wall the moment they are enrolled in a ZATCA Fatoorah wave. ERPNext core will happily produce a Sales Invoice and a print format, but it has no concept of a ZATCA-compliant TLV QR code, no ECDSA cryptographic stamp, no compliant UBL 2.1 XML, and no way to talk to the Fatoora clearance and reporting endpoints. That gap is not cosmetic — for standard (B2B) invoices, a document that has not been cleared by ZATCA before issuance is not a legal invoice, and simplified (B2C) invoices must be reported within 24 hours. Finance teams end up bridging this with a second portal or a manual middleware, re-keying every invoice and losing the single source of truth ERPNext was supposed to give them.

We build a proper Frappe app (installed into your bench, e.g. bench get-app + bench install-app) that keeps the entire compliance flow inside ERPNext. The app ships its own DocTypes — a ZATCA Settings single for CSID/credentials and environment, a per-invoice ZATCA E-Invoice Log that stores the UUID, invoice hash (PIH chaining), signed XML, cleared/reported status and the full ZATCA response, plus a Device Onboarding DocType for CSR generation and CSID lifecycle. Compliance is triggered by hooks.py document events (on_submit, on_cancel) on Sales Invoice and POS Invoice, so nothing depends on a user remembering to click a button: on submit we build the UBL 2.1 XML, canonicalize and hash it, apply the ECDSA cryptographic stamp with the private key tied to your CSID, generate the TLV-encoded Base64 QR (seller name, VAT number, timestamp, totals, VAT amount, hash, signature), then call the clearance API for standard invoices or the reporting API for simplified invoices.

The integration is engineered the way a senior Frappe engineer would want to inherit it. ZATCA calls run through whitelisted server-side methods (@frappe.whitelist()) and are exposed over the Frappe REST API for headless/POS integrations; failures are never swallowed — they land in the E-Invoice Log with the raw ZATCA warning/error codes and are retried by a scheduler_events background job so a transient Fatoora outage does not block your billing. Client Scripts surface QR, stamp and clearance status directly on the Sales Invoice form, and a custom Role Profile (e.g. "ZATCA Officer") plus permission rules control who can onboard devices, re-submit, or view credentials. Everything targets Frappe/ERPNext v15 and is forward-tested against v16, and the compliance certificate/QR is wired into your existing print format so the customer-facing invoice is compliant on day one.

Because this is build-to-order, we start from your actual chart of invoice scenarios — standard vs simplified, credit/debit notes, multi-branch VAT registrations, POS, and any existing customizations — rather than shipping a one-size app. After a short scoping call we confirm the exact scope in writing, then build against your ERPNext version and configuration, deliver on a staging bench for UAT with the ZATCA sandbox, and only go live once compliance is verified. Typical delivery is 2–4 weeks from confirmed scope, and you receive the full source and git repo so you own what you run.