How Jabr handles the handoff
The platform supplies commerce events. Jabr applies the accounting boundary and records where each order ended up.
Jabr accepts events only through the secret callback URL registered for the store, then resolves Zid's store identifier to one connected company. Manual Sync uses the same posting engine.
When a Zid event or list row lacks its invoice tax breakdown, Jabr fetches the full order before posting. A VAT-registered company never gets a guessed zero from an incomplete payload.
Delivery is the revenue point. Complete, internally consistent lines can become a customer invoice; mapped products relieve stock and cost. If the line or tax evidence cannot support that document, Jabr posts the supported aggregate entry and flags the reason.
Jabr links the reversal to the original Zid marker. It uses a credit note where the original became an invoice and a reversing entry for aggregate cases, without erasing the original transaction.
Webhook retries and manual catch-up converge on the same platform-and-order marker. A claimed or completed side effect is not silently posted a second time.
What changes in the ledger
These are net accounting effects for common paths. Jabr retains the underlying invoice, receipt, settlement or journal records that produced them; account names follow the company's configured chart.
Bank-classified payment before delivery
Cash is recorded and output VAT is recognized, while the net sale remains a customer advance until delivery.
| Account | Side |
|---|---|
| Bank account | Debit |
| Customer advances | Credit |
| VAT payable (output) | Credit |
Delivery after that advance
The advance moves to revenue without recognizing VAT again. Mapped inventory also moves to cost of goods sold.
| Account | Side |
|---|---|
| Customer advances | Debit |
| Sales revenue | Credit |
| Cost of goods sold | Debit |
| Inventory | Credit |
Delivered but not yet remitted
For cash on delivery, the invoice remains receivable until the courier remits. Mapped inventory is relieved at delivery.
| Account | Side |
|---|---|
| Accounts receivable | Debit |
| Sales revenue | Credit |
| VAT payable (output) | Credit |
| Cost of goods sold | Debit |
| Inventory | Credit |
Connect from inside your company
The public page explains the behavior. Authentication starts only from the Connections page of the Jabr company you choose.
- 1
Sign in to Jabr, choose the company, open Connections and select Zid.
- 2
Approve access on Zid's authorization screen. On return, Jabr stores the connection for that company and registers its order webhooks.
- 3
Confirm the store shown in Connections and run Sync for recent history. New order, status and payment changes then arrive through the registered callbacks.
A visible control trail
The useful difference is not another promise of automation. It is being able to see the source, the checks and the accounting outcome.
Provider evidence is retained
Platform ids, dates, totals and observed state stay attached to the integration record instead of disappearing inside a summary.
Unsafe assumptions stop here
Unsupported currency, incomplete tax detail, unresolved identity and inconsistent amounts become explicit waiting, failed or review states.
The result remains inspectable
Documents, entries, mappings and reversals keep their source references, while sync history shows what posted and what still needs attention.
Boundaries Jabr will not cross silently
These are product rules, not fine print. They prevent incomplete provider data from becoming confident but incorrect accounting.
- Jabr does not issue a second ZATCA sales document for a supply already invoiced by the storefront. The Jabr invoice is an internal accounting document for the connected books, not a duplicate customer tax invoice.
- Product identity uses a saved mapping first, then a unique SKU. An unmapped line can still record the sale, but it does not relieve stock or book cost until a person resolves the mapping.
- Incomplete or internally inconsistent line and VAT evidence does not become a fabricated itemized invoice. Jabr uses the supported aggregate path and exposes the exception.
- A refund reverses the booked financial position. Stock is not silently returned unless the workflow has reliable physical-return evidence.
- Storefront posting is SAR-only. Jabr rejects a foreign-currency order rather than booking its raw amount as Saudi riyals.
Where Jabr stops and shows its work
Why can an order stay in Waiting?
If it is neither paid nor delivered, there is no supported tax or revenue event to post. Zero-total orders and temporarily unavailable provider detail also stay visible for a later retry.
Why did an order become an entry instead of an invoice?
An invoice requires product lines that cover the subtotal and line-level tax that agrees with the order. If those checks fail, the aggregate order figures can still be posted safely and the document limitation is recorded for review.
What happens when a webhook is delivered twice?
Jabr claims a side effect against the platform and order id before writing. A retry, a second webhook or a manual Sync reaches the same marker instead of creating a second sale.
How are store products linked to inventory?
Jabr follows an existing platform-product mapping first. Otherwise it accepts only a SKU that identifies exactly one Jabr product, saves that choice, and sends every ambiguous or missing match to the mapping panel.
Where do Tabby and Tamara amounts appear?
They go to a separate clearing account for the identified provider, not directly to bank. Fees are recorded from the later settlement statement because the order payload does not prove the final fee.
Connect from the company you want to use
Read the behavior here without an account. When ready, open Connections inside Jabr to authorize the provider for one specific company.