Accounting automation in Saudi Arabia, without giving up control of your ledger

What can be automated, and what that means in practice

The mechanical half of bookkeeping is matching and arithmetic, and both are solved problems. Every sales invoice, vendor bill, bank line, payroll run and payment settlement can be pulled from the systems that already hold them, mirrored into a double-entry ledger, and matched against each other by reference, by amount and date, or by fee arithmetic. None of that needs judgement, and none of it should be done by a person at a keyboard.

What follows the match is a proposed journal entry: which accounts move, in which direction, with which VAT code. That proposal is checked deterministically before anyone sees it. Does it balance to the halala, does the VAT figure reconcile to the rate, is the date inside an open period, is the account one that exists in your chart. An entry that fails any of those never reaches a human as a suggestion.

• Mirroring invoices, bills, bank lines, payroll and settlements into a shadow ledger
• Matching a lump payout back to the orders and fees that made it
• Proposing the journal entry with its VAT treatment attached
• Checking the proposal balances before a person is asked to look at it
• Assembling the VAT return with the source documents linked to each figure

The part that is not automation: approval

Nothing posts to your ledger on its own. Every entry sits as a draft until a person approves it, and in the first year of running this there is no automatic posting path at all. That is a deliberate limit rather than a missing feature. An automatic posting that is wrong costs more to unwind than the twenty seconds of approval it saved, and it moves the accountability for a number from a person to a system.

The practical shape of this is batch approval. Your accountant sees a queue of drafts, each with the source document beside it and the reasoning recorded, and approves them in groups. That is a different job from typing entries, and it is the job an accountant should have.

Where language models help and where they must not

A model is good at reading a scanned delivery note, guessing the right expense category from a vendor's history, and writing the one plain sentence that explains a variance. It is not good at arithmetic and must never be trusted with any. Every balance, every VAT computation, every match residual in this system is plain TypeScript that can be read and tested.

That split matters when something goes wrong. If a category is wrong, a person corrects it and the correction becomes training data. If a total were wrong, you would have a ledger you cannot rely on, and no amount of correction fixes the trust.

The Saudi specifics that generic tools miss

VAT at 15% with the five codes a Saudi return actually uses. ZATCA Phase 2 invoice clearance and reporting, with the invoice hash chain that makes a deleted invoice visible. GOSI split between employee and employer contributions. End of service benefit accruing under the labour law rather than as a year-end guess. Zakat computed on the adjusted base rather than on accounting profit.

Payment rails matter as much as regulation. Moyasar publishes a settlements API. Tap has a payout webhook and a download endpoint. Tabby and Tamara give you a dashboard export and nothing else, which means a real system has to handle a CSV as a first-class input rather than as a fallback.

What you would actually do next

Start with a read of the books you have. A health check reads your ledger once and reports what is in it: unreconciled value, missing invoices, accounts classified into the wrong place, VAT figures with no evidence behind them, each counted and priced. It takes about ten minutes of your time to set up and you keep the report whether or not you go further.