From a gateway event to a reconciled outcome
Jabr separates provider evidence, receivable collection, settlement, fees and refunds so each one changes only the accounts it actually proves.
Jabr verifies the latest status and stores only the accounting-safe payment fields. No revenue, VAT or bank entry is created merely because the charge succeeded.
The exact collected amount debits Moyasar Clearing and credits Accounts Receivable. The issued invoice remains the source of revenue and output VAT.
Jabr uses the settlement header and lines, not the estimated fee on a payment. Unsupported line types, custom splits, currency differences or an arithmetic variance stop posting for review.
A gateway refund does not prove a sales return or that stock came back. Jabr requires the linked credit-note or dispute treatment before clearing the money side.
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.
Collected against an issued invoice
This settles trade receivables into the gateway subledger. It creates no second revenue or output VAT line.
| Account | Side |
|---|---|
| Moyasar clearing | Debit |
| Accounts receivable | Credit |
Provider settlement reaches the bank
The actual deposit and supported fee evidence clear the provider receivable. Input VAT is separated only when valid tax evidence supports recovery.
| Account | Side |
|---|---|
| Bank account | Debit |
| Payment processing fees | Debit |
| Input VAT recoverable | Debit |
| Moyasar clearing | 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
Open Connections for the intended Jabr company and enter that merchant's Moyasar secret key. Jabr never asks for card data or the publishable checkout key.
- 2
Jabr validates the key, stores it encrypted for that company, and registers a tenant-specific webhook when a secure callback URL is available.
- 3
Sync recent activity, review unmatched payments, and confirm only exact receivable matches. Reconcile deposits from Moyasar settlement evidence or the bank/POS report available to the account.
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.
- An unmatched payment never creates sales revenue, output VAT, a customer invoice or a ZATCA document.
- A Moyasar hosted invoice is a payment request, not a ZATCA tax invoice and not a substitute for the merchant's sales evidence.
- The fee shown on an individual payment is estimated and includes VAT. Jabr does not book it as a final expense; settlement evidence controls the actual fee.
- A refund or chargeback does not automatically issue a credit note, reverse output VAT or return inventory. Those outcomes need their own supporting facts.
- Moyasar is a payment gateway, not an open-banking feed. It does not supply the company's complete bank transaction history.
Where Jabr stops and shows its work
Which Moyasar key does Jabr need?
The secret key is required for server-side payment verification and synchronization. The publishable key creates checkout payments in a browser and is not needed by this accounting connection.
Does a paid Moyasar transaction enter the VAT return?
Not by itself. VAT comes from the underlying taxable supply and its valid document or tax-point workflow. Matching a payment to an issued invoice changes clearing and receivables only.
What if Salla or Zid already recorded the order payment?
Jabr does not blindly post the gateway row. Already-paid storefront invoices are not open matching targets, and any uncertain overlap stays in review instead of creating another bank, receivable, revenue or VAT movement.
Why might settlements require a bank or POS report?
Moyasar's settlement API is not available to every merchant model. When the account does not expose it, Jabr states that limitation and requires the provider's bank/POS settlement report rather than estimating the deposit and fees.
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.