Most companies do not need a different ERP. They need the one part that is genuinely theirs — the pricing rule, the approval chain, the way their sector is regulated — to stop being a spreadsheet bolted onto a system that will not bend. We build that part, or the whole system, around how you actually operate, in Arabic and English.
An ERP is the system of record for how money, stock, people and work move through the company. Packaged products cover that ground well, and for a business that runs the way its industry generally runs, buying and configuring one is the cheaper, faster and safer decision. We will tell you when that is the case, and we would rather integrate with a good product than replace it.
Custom earns its cost in one situation: the thing that makes you money is the thing the package cannot express. A contractor whose billing follows certified progress and retention, a distributor whose price depends on the customer, the quantity and the season, a service company whose approvals branch by value and by entity — these are not preferences. When the standard system cannot hold them, the work moves into spreadsheets, and the ERP quietly stops being the system of record while still costing a licence.
The middle path is the honest one for most companies here: keep a proven package for the ledger and the standard modules, and build the layer where your difference actually lives on top of it, connected properly. That is usually a smaller, cheaper and less risky project than either extreme, and it leaves you free to change one side without rebuilding the other.
Whatever the shape, a system operating in Saudi Arabia has non-negotiable edges. Sales invoices fall under ZATCA e-invoicing, with the integration phase set by the wave your revenue puts you in. Payroll has to produce GOSI contributions and a file the Wage Protection System will accept, and it has to handle allowances, end-of-service and leave the way Saudi labour practice expects. Hijri dates, Arabic names and national ID formats belong in the data model from the first day, not in a later patch. We build against these from the start because retrofitting any one of them is a rewrite of everything above it.
Before any code, a written read of what you run today, where the work has escaped into spreadsheets, and what a packaged product would and would not cover. If buying wins, that is what the document says — and we will help you configure it instead.
Finance and accounting, inventory and warehousing, purchasing, sales and projects, HR and payroll — scoped to the ones you actually need first, and built so a module can be added later without disturbing what is live.
E-invoicing with the QR, hash chain and sequence produced correctly rather than approximately; payroll that outputs GOSI contributions and a WPS-acceptable file; and the reports your accountant and auditor ask for in the format they ask for.
Banks, payment gateways, e-commerce and point of sale, carriers, SMS and WhatsApp, and any partner or government interface you depend on — with one system designated the source of truth for each piece of data so two never disagree.
Chart of accounts, opening balances, customers, suppliers, items and history — cleaned, mapped, loaded and reconciled against your closing figures before anyone is asked to trust the new system.
Cloud, on-premise or a hybrid to suit your data-residency position; roles and permissions designed per department; an audit trail on the records that matter; backups verified by restore, and a support arrangement in writing.
Two to four weeks with the people who run finance, stock, sales and HR. We map the processes as they genuinely happen, list the workarounds, and produce a build-vs-buy recommendation with the numbers behind it.
The document structure, the chart of accounts, the approval rules and the permissions per role — agreed on paper and reviewed by your accountant before development, because these are the decisions that are expensive to change later.
One module goes live at a time, on real data, with the people who will use it. Finance first in most cases, because everything downstream posts into it. You are reacting to working software throughout, not to progress reports.
Balances loaded and reconciled, then a period where the new system runs beside the old one and the two are compared at close. A cutover without a parallel period is how a company discovers in month two that its stock valuation moved.
Training in Arabic for the people doing the work and in whichever language management prefers for the reports, documentation and the source code in your own repository, then an agreed support window and a rhythm for changes.
Count the workarounds, not the features. List the processes that currently run outside your system — the spreadsheet that prices a quotation, the WhatsApp group that approves a purchase, the file someone rekeys into accounts — and ask whether a packaged product could hold them with configuration alone. If it could, buy it: you get a proven ledger, other people’s bug fixes and a hiring pool that already knows it. If those workarounds exist because your commercial logic genuinely differs from the industry template, that is where custom pays, and often only for that part. We do this as a written assessment first, and we have recommended buying often enough that we would rather you asked us than a vendor with one product to sell.
Yes — these are requirements we design in, not features we add at the end. On invoicing, the system produces compliant tax invoices with the QR, the hash chain and the counter intact, and it distinguishes standard invoices from the simplified ones retail issues. Your integration dates depend on the wave ZATCA has placed you in, and the notice you received is what governs them. On payroll, the system calculates GOSI contributions and produces a file the Wage Protection System accepts, alongside allowances, leave and end-of-service. We test all of this against your own real data before go-live rather than against sample records, because that is where the edge cases live.
Usually yes, and the constraint is the quality of what exists rather than the export format. We take the chart of accounts, opening balances, customers, suppliers, items and as much transaction history as is genuinely useful, then clean and map it — and this is where most of the effort goes, because duplicate customers, items with three spellings and balances that never reconciled do not become correct by being moved. We reconcile the loaded data against your closing trial balance and stock valuation before anyone is asked to work in the new system. Where history is too poor to migrate cleanly, we will say so and keep the old system available read-only rather than import numbers you cannot defend.
All three shapes are possible and the choice is usually driven by policy rather than technology. Cloud is the default for most companies: no server room, easier updates, and remote access for branches. On-premise still makes sense where a contract, a regulator or an internal policy requires it, or where the site genuinely cannot depend on connectivity. Hybrid — the system in the cloud with a local component for point of sale or production — covers a common middle case. Wherever it runs, we set it up so you hold the accounts and the infrastructure rather than us, and residency requirements should be confirmed with your own compliance advisor since they differ by sector and by contract.
A focused first phase — typically finance plus one operational module — runs three to five months from assessment to live use. A full multi-module system is a programme rather than a project and is measured in quarters, which is exactly why we do not attempt it in one release. Finance usually goes first because everything downstream posts into it, then the module with the worst workaround. What actually determines the schedule is rarely development speed: it is how quickly decisions get made on your side, the state of the data being migrated, and whether the people who will use it are given time to test. We say which of those are on your side of the line at the start, not in the delay email.
Book a short call and we will come back with a clear plan and a realistic budget — in Arabic or English.
Talk to us
