Your online store and your ERP, finally telling the same story.

Two systems, two versions of the truth.

Most Saudi stores start simply: orders arrive in Salla, Zid or Shopify, and someone types them into the accounting system at the end of the day. That works at twenty orders a week. At two hundred, it becomes the bottleneck nobody budgeted for.

• Manual re-keying: orders, shipping fees, discounts and payment-gateway charges are copied by hand, and errors surface only at month-end reconciliation.
• Stock mismatch: the store sells an item the warehouse no longer has, or hides stock that is sitting on the shelf, because the two systems update at different times.
• Unclear tax invoice: the store generates an invoice, the ERP generates another, and nobody is sure which one is the legal tax invoice, or whether both were reported to ZATCA.
• Returns and refunds: a refund in the store isn't matched by a credit note in the books, so VAT returns and stock both drift.
• Payment reconciliation: payouts from mada, card, Apple Pay and buy-now-pay-later providers arrive as net batches that are hard to match to individual orders.

Which system issues the tax invoice?

Decide this before writing any code. Under Phase 2, every invoice must be generated by an onboarded solution, carry a cryptographic stamp and QR code, and be reported to ZATCA's Fatoora platform. Online sales to consumers are typically simplified tax invoices, which must be reported within 24 hours of issuance.

There are two clean answers. Either the store's invoicing (or an app it uses) is the e-invoicing solution, and the ERP records the sale without issuing a second invoice; or the ERP issues the invoice when the order arrives, and the store's own invoice is switched off or treated as an order confirmation. What you must avoid is both systems issuing and reporting an invoice for the same sale.

Returns follow the same rule. A refund or partial return needs a credit note that references the original invoice and goes through the same reporting flow.

B2B orders from VAT-registered buyers are different again: a standard tax invoice must be cleared by ZATCA before the buyer receives it. If your store takes trade orders, the design must handle both flows. Our ZATCA Phase 2 integration page explains clearance and reporting in detail.

Three ways to connect, in plain language.

There is no single right architecture. The choice depends on your order volume, how many channels you sell on, and how much your processes differ from the standard.

Third-party vendors advertise paid Salla and Zid connectors for ERPNext, and Frappe publishes a free connector for Shopify. We assess any existing connector on its merits before recommending a build.

Every major platform exposes the events we need.

A reliable integration reacts to events (an order is created, paid, refunded) rather than polling for changes every few minutes. Each platform documents its own APIs and webhooks:

One flow, from checkout to the general ledger.

• Orders to sales orders or invoices, with line items, discounts, coupons, shipping fees and VAT carried across exactly as the customer paid them.
• Customers, including B2B buyers' VAT numbers and addresses where your store collects them.
• Stock levels from the ERP back to the store, per warehouse or branch, so you stop overselling.
• Products and prices, in whichever direction your team manages them, with SKU as the shared key.
• Payments and gateway fees, recorded so that settlement batches reconcile against orders.
• Cancellations, returns and refunds as credit notes linked to the original invoice.
• Fulfilment and shipment status back to the store, so customers see accurate tracking.
• ZATCA status for each invoice: reported, cleared, rejected or awaiting retry, visible to finance.