Saudi retailers and restaurants running ERPNext POS face a hard regulatory wall: ZATCA's Fatoora Phase 2 (the Integration Phase) requires every simplified tax invoice issued at the counter to carry a cryptographic stamp, a TLV-encoded QR code, and to be reported to the ZATCA platform within 24 hours — with your device onboarded via a CSID (Cryptographic Stamp Identifier). ERPNext core gives you POS Invoices, VAT tax templates, and print formats, but it has no concept of a ZATCA CSID, no signed-XML generator, no UUID/PIH invoice hash chain, and no connection to the Fatoora reporting API. Teams try to bridge this with print-format hacks and manual QR strings, and end up with invoices that fail ZATCA validation and block go-live.

ECOSIRE builds a dedicated Frappe app that closes that gap end to end. The app ships as a proper Frappe module with its own DocTypes — a ZATCA Settings singleton for the seller identity, VAT registration, and environment (sandbox / simulation / production), a ZATCA Device DocType that stores each onboarded CSID and its private key, and a ZATCA Invoice Log that records the signed XML, the invoice hash (PIH/ICV chain), the QR payload, and the ZATCA clearance/reporting response for every document. We hook into the POS Invoice lifecycle through hooks.py doc events (on_submit, before_cancel): on submit, a server-side method builds the UBL 2.1 XML, applies the ECDSA cryptographic stamp using the device certificate, generates the Base64 TLV QR per ZATCA's tag specification, and calls the Fatoora reporting endpoint. Simplified invoices (B2C) are reported after issuance; standard tax invoices (B2B) go through the clearance flow. Bilingual Arabic/English tax invoice print formats render the seller/buyer data, VAT breakdown, and QR so the counter can hand over a compliant receipt immediately.

Under the hood the integration is designed to be operable, not a black box. CSID onboarding is driven from the ZATCA Device DocType via whitelisted methods that call ZATCA's compliance and production CSID APIs, so a store manager can onboard a new till without touching the server. Failed reports are queued and retried through a Frappe scheduler event rather than lost, and every attempt is written to the invoice log with the ZATCA request ID and any validation warnings. Role profiles and permissions keep certificate material and settings restricted to your finance/admin roles while cashiers only see the POS. The whole thing exposes clean whitelisted REST endpoints so a headless POS front end or a second location can trigger the same signing pipeline.

The app is built for the ERPNext/Frappe version you run — v15 or the current v16 — and tested against ZATCA's sandbox and simulation environments before it ever touches production. Because this is a build-to-order engagement, we start from your actual chart of accounts, VAT setup, POS profiles, and receipt layout rather than a generic template: the QR tags, invoice numbering, and clearance rules are wired to how your business actually issues invoices.

Delivery works as a scoped project, not a download. After a short scoping call we confirm exactly which invoice types, locations, and devices are in scope, then build, install on your staging site, and run UAT against the ZATCA sandbox. Typical delivery is one working week from confirmed scope. You receive the full source repository, install and configuration docs, a training session for your finance team, and a post-go-live support window so any ZATCA validation edge cases are handled while your first real invoices flow.