What did we actually make on yesterday's orders? For most Saudi stores, the answer is assembled by hand: the store shows the order total, the gateway settlement file shows a smaller net figure, the ZATCA invoice record follows its own logic, and the stock count disagrees with all three. A custom reconciliation dashboard joins them on the order itself, in one Arabic-ready screen. This guide scopes that layer, and when you should not build it at all.
The short answer: the three domains, the joins between them, and what "reconciled" means
The dashboard joins three domains. Invoicing: every order's ZATCA e-invoice and its status. Money: every mada and card settlement, split into gross, fees, refunds, net. Stock: what store, POS and warehouse each believe you hold. The order is the join — one record carrying its invoice status, its settlement status and its stock movements together.
An order is reconciled only when all three agree: its invoice reached the correct ZATCA state, its settlement matches after the fees and refunds your gateway agreement defines, and its stock decrement matches what was picked. Everything else is an exception — and exceptions are what your team sees first.
The month-end problem: three systems, three truths, one spreadsheet
Finance exports the settlement file and finds payouts bundled across days, net of fees, refunds deducted from later batches. Operations exports the order list and finds cancelled and cash-on-delivery orders inside the same totals. The invoicing tool holds a third record, and a quietly failed invoice sits unnoticed until someone goes looking.
So the month closes in a spreadsheet, weeks after the money moved: the settlement that never arrived, the invoice never reported, the product oversold because POS and store counted the same shelf differently. The dashboard creates no new data — it removes the delay between an event and the moment someone sees the records disagree. If your ecommerce store and its invoicing and payment setup already work, this layer sits above them.
Domain 1 — ZATCA invoices: issued, cleared or reported, failed — visible per order
ZATCA's Integration Phase connects a taxpayer's invoicing solution to the Fatoora platform, in a specified format with additional fields, rolled out in waves with advance notice. Within it, standard tax invoices follow a clearance model and simplified tax invoices a reporting model — the distinction your dashboard must respect, because an invoice's correct end-state depends on its type.
Per order, the dashboard shows one state: issued and cleared, issued and reported, pending submission, or failed. Failed matters most — not as a checkout problem to debug here, but as a queue item with the order reference attached, found the same day. Credit and debit notes sit on the same record, linked to the invoice they adjust.
Domain 2 — Mada and gateway settlements: gross, fees, refunds and net, matched to orders
A settlement is not an order payment. Gateways settle in batches, on their own timing, net of fees — and the fee structure is the one in your own gateway agreement, not a universal rate. One Saudi gateway's official FAQ states its fees come from its sales team; an honest dashboard therefore models your contracted rate, not a headline.
Each batch is shown decomposed: gross, fees, refunds, any holds your gateway reports, and the net that should reach the bank — then matched back to orders. A paid order with no settlement line after the normal payout window is an exception; a settlement line matching no order is another. Refunds run in reverse: the money left your account, but did the order, the invoice note and the stock move with it?
Domain 3 — Inventory: one stock truth across store, POS and warehouse
The store decrements on order placement, the POS on the till sale, and the warehouse count is what a person last counted. When those are three numbers, the storefront sells what the shelf does not have — and the refund and apology cost more than the margin did.
The inventory view is plain: per SKU, what each source claims and the variance between them, highlighting the two states that lose money — negative stock, where sales exceeded every count, and silent divergence, where sources drift apart without a single error. It does not replace your inventory system; it shows which source the business trusts, and where that trust is already broken.
The joins: the order as the spine — invoice, settlement and stock movement on one record
This is matching built on identifiers. The order ID from your platform — Salla, Zid, Shopify or WooCommerce — is the spine. The invoice hangs off it through the reference your invoicing solution returns; the settlement through the gateway's order reference; stock movements through the SKU lines.
Where a source gives no clean reference — a settlement file with only batch totals — the dashboard matches on amount, date window and payment reference, marking the match probable rather than certain. A screen pretending every match is exact teaches finance to stop trusting it. The result is less a report than an internal web portal: one record, three evidence trails, a clear state for each.
Exception-first design: unmatched, failed and negative — the queues your team actually works
Most dashboard projects fail by leading with charts; nobody's job improves with a prettier total of money that does not reconcile. The useful home screen is three queues: settlements that matched no order, invoices in no correct state, and SKUs gone negative or diverged — each item carrying its order reference, amounts and age.
Worked daily, the queues stay short and month-end becomes a review instead of an excavation. Worked monthly, they become the same spreadsheet in better colours. What decides the outcome is whether every exception has an owner and ages visibly until it clears.
Build, buy or extend the ERP? The honest decision before any dashboard is commissioned
Three routes exist. First, an ERP or accounting suite with its own ledger may already join invoicing, inventory and settlements. If your store can live inside that suite's way of working, buy it and do not build: the dashboard's value is avoiding a books migration, and if you will migrate anyway, the suite is more complete.
Second, if accounting covers invoicing and stock but leaves settlement matching manual, a narrower settlements-only build may be right. Third, build the full layer when you keep your current store, gateway and accounting setup and the pain is the joins between them. The wider route question sits in our guide to low-code internal tools vs a custom dashboard: low-code suits single-source views; multi-source matching with exception queues is where custom earns its cost.
Integration inventory: APIs and files from your store, gateway, invoicing and accounting
Before anyone prices this build, inventory what each system can give. From the store: orders, lines, refunds and inventory levels, ideally by API with webhooks. From the gateway: settlement reports or an API exposing batch composition — gross, fees, refunds, net, payout date — plus the reference tying a line to an order. From invoicing: invoice references and their ZATCA states. From accounting: the mapping totals must post against.
Gaps are normal; price them rather than discovering them mid-build. A gateway offering only a daily CSV means a file-ingestion step; a POS that cannot expose stock means a count-import routine. Our method for scoping an API integration applies. The Saudi-specific part is the data model, not the code; the engineering is a normal part of web development in Saudi Arabia.
Arabic operations view: roles for finance, operations and the owner
The people working the queues think in Arabic, so the operations view is Arabic-first, with English where finance prefers it. Roles keep it usable: finance sees settlements, invoicing states and the month-end position; operations sees stock variances; the owner sees a summary — orders reconciled, value in exception, oldest open item.
Permissions matter as much as language. Whoever resolves a settlement exception should not be able to alter the amounts beneath it, and every resolution keeps its audit trail. A quietly editable dashboard becomes a fourth version of the truth — the problem it was built to end.
FAQ
Is this dashboard a replacement for our accounting software or ERP?
No. It is a reconciliation layer across your store, gateway, invoicing solution and accounting records; your accounting software remains the book of record. If an ERP suite already joins all three domains in its own ledger and you are willing to migrate your books to it, buy that instead.
Which invoice states should the dashboard show for ZATCA e-invoices?
Four states matter: issued and cleared, issued and reported, pending submission, and failed. Standard tax invoices follow ZATCA's clearance model and simplified tax invoices its reporting model, so the correct end-state depends on invoice type. The dashboard surfaces the state; fixing a rejected submission belongs to your invoicing integration.
Can the dashboard use our gateway's settlement files if there is no API?
Yes, if the file exposes the reference, amounts and payout timing to match lines to orders — a daily or per-batch CSV becomes an ingestion step in the build. Where a file gives only batch totals, matches are marked probable rather than certain, so finance sees the confidence level instead of trusting a forced match.
Does it work with Salla, Zid, Shopify and WooCommerce?
The design assumes one of those platforms as the order source and joins the other domains around its order ID. What varies is how orders, refunds and inventory are exposed — API, webhook or export — which the integration inventory checks first.
How is the dashboard priced?
As a custom project, scoped from your integration inventory: the sources, their APIs or files, and the exception workflows you need. WebStackRank provides an itemised proposal within 24 business hours, with 50% deposit to begin and 50% at launch. Any quote given before that inventory exists is a guess.
Scope the dashboard that ends your month-end spreadsheet (CTA)
Bring us three exports — one week of orders, one settlement file, your invoicing report — and we will map the joins and exceptions they already contain, then scope the dashboard against real data. Start with our custom web application development service, or WhatsApp us at +971 52 595 3174 with your platform and gateway named. If an ERP you own makes the build unnecessary, the scoping will say so first.
