Products

Trips with SAMA's three-role crews, vehicle eligibility from documents and the five-year service life, an append-only hash-chained custody ledger anchored daily outside the database, maker/checker reconciliation with a mandatory second factor, rate cards per customer, SLA measurement, dispute evidence packs, an offline field app, GPS ingest with geofence arrivals, Arabic/English UI, and a live connector that pushes contract fees for completed trips into Odoo as draft invoices and syncs customers.

For operators that already run, or plan to run, Odoo Enterprise for accounting, HR and ZATCA e-invoicing and want a specialised operations layer on top rather than a second ERP.

• Every tenant's rows are isolated by PostgreSQL row-level security; the application role cannot bypass it.
• The database itself refuses edits to the custody ledger; corrections are new, linked entries.
• Money is stored as integer halalas with an ISO 4217 code, never as floating point.

Where it stands today: everything above runs on our development environment against a real Odoo 17 instance, with 86 automated tests. A KSA-hosted environment is provisioned per pilot; the client's own Odoo Enterprise instance is connected at implementation.

The same operations core plus native finance: a double-entry general ledger that must balance at commit, immutable postings with reversals, receivables and payables, credit notes, bank statement import and reconciliation, period close, P&L, balance sheet and VAT return figures, employees and payroll runs with maker/checker approval and a WPS file, and ZATCA Phase 2 e-invoicing: certificate onboarding, signed UBL documents and clearance, verified against ZATCA's sandbox.

For operators that want a single purpose-built system with no third-party ERP licence, and are prepared for a longer build in exchange for full control.

• A journal entry that does not balance to the halala cannot be saved: the database checks it at commit.
• Invoices carry a per-tenant hash chain and are immutable once issued; ZATCA submissions are an append-only history.
• Load-tested at 500 vehicles and 5,000 trips a day with 50 concurrent users, 100 % success on both editions (the runs, including the two that found defects, are published in each edition's operations document); backups every 15 minutes with a nightly timed restore drill.

Where it stands today: all of the above runs on our development environment with 112 automated tests, including a live flow against ZATCA's sandbox (compliance samples passed, documents cleared). Production ZATCA onboarding uses the client's own certificate; the WPS file layout is validated on the first Mudad upload; GOSI rates are configuration to be confirmed by the client's payroll officer.