Solutions / Construction
Contracting margins are decided long before the final account — by whether you knew your committed cost on the day you committed it, whether the back-charge was raised before the subcontractor demobilised, and whether the variation was priced while anyone still remembered the instruction. A construction ERP makes those things routine rather than heroic.
Generic ERP handles the company. Construction ERP handles the project — and a project is not a cost centre. It has a structure, a client, a set of commitments and an argument at the end of it.
Everything downstream depends on this. A work breakdown structure carrying through to budget, procurement, progress and billing gives you one version of the project rather than four. Get the coding standard right and cost control follows; get it wrong and no reporting rescues it.
Import the bill of quantities, map items to WBS and cost codes, set the budget everything is measured against. Re-measurement, provisional sums and rate build-ups belong in the model rather than bolted on — on most Gulf contracts they are not edge cases.
Budget versus actual is a lagging indicator. The number that matters is committed cost: POs raised, subcontracts awarded, work instructed but not yet invoiced. Showing budget, committed, actual and forecast final cost together is the core of project cost control software, and the reason spreadsheets eventually fail.
Subcontract award, scope, payment terms, retention, advance recovery and certificates in one place. Back-charges deserve particular attention: raise them against the subcontract when they occur, not when someone reconciles the final account and finds the money has already gone out.
Site raises a requisition against a budget line, procurement runs the comparison, the PO commits cost the moment it is approved. Multi-site stores with issue and return against activities, transfers between projects, and reconciliation that survives audit.
Plant tracked by hours or days with internal hire rates charged to the consuming project, so idle plant becomes visible. Timesheets allocated to activities so labour cost lands on the right line — alongside Gulf realities like accommodation, transport and permit status, modelled as data operations can act on.
Measure progress, generate the interim payment certificate, apply retention and advance recovery, then track applied against certified against paid. The gap between those three numbers is your working capital story, and it should be one query rather than one week.
Variations from instruction to pricing to certification with the paper trail attached, plus HSE records, QA/QC inspection requests and NCRs, and document control with revisions and transmittals. All of it feeds cash flow forecasting. These are contemporaneous records: their value is in having captured them at the time.
An ERP built for a single-country contractor assumes one legal entity, one tax regime, one billing behaviour. Contractors here rarely have that luxury: a group might run a Dubai entity, a Riyadh entity, a free zone company and a joint venture on one scheme.
Two invoicing regimes in one group. UAE VAT and Saudi e-invoicing are not variations of the same thing. A Saudi billing entity operates under ZATCA's Fatoora programme: Phase 1 (from December 2021) required invoices generated and stored electronically in a structured format, with QR codes on simplified invoices; Phase 2 (from January 2023, rolled out in waves by revenue threshold) requires integration with the Fatoora platform — UBL 2.1 XML, cryptographic stamp, a CSID obtained through EGS onboarding, UUID, invoice hash and previous-invoice-hash chaining. Standard tax invoices need clearance before they reach the buyer; simplified invoices go to the buyer immediately and are reported within 24 hours. Waves and thresholds have advanced repeatedly, so we confirm what applies to your entity against ZATCA's published guidance per engagement. Inovsion has delivered an ERP-integrated ZATCA e-invoice solution covering EGS onboarding with automated validation — see our ZATCA work and our Saudi Arabia practice.
Payroll that differs by country. Firms employing labour in the UAE commonly have to consider salary payment through the Wage Protection System, which shapes how payroll data leaves the system. We scope that explicitly rather than assuming a generic module covers it.
Site conditions that affect design. Connectivity on a site in month one is not head-office connectivity, so requisitions, goods receipt and inspections need to work offline and sync later. If your requirement is narrower — a developer's sales side rather than delivery — real estate CRM may fit better, and our ERP development practice covers the general case.
This is about fit, not which is better in the abstract. Plenty of firms run well on spreadsheets until a specific threshold is crossed.
| Area | Spreadsheets | Generic ERP | Construction ERP |
|---|---|---|---|
| BOQ & re-measurement | Flexible; every project structured differently | No concept of a BOQ | BOQ mapped to WBS, budget and billing |
| Committed cost | Manual and usually stale | POs exist, rarely roll up to forecast | Budget, committed, actual, forecast in one view |
| Subcontracts & back-charges | Per QS; charges found at final account | Treated as supplier POs | Contract object with certificates and charges |
| IPCs & retention | Built by hand each cycle | Invoicing yes, certification no | Applied vs certified vs paid, with recovery |
| Variations & claims | Email threads and a register | No native model | Instruction to certification, records attached |
| Site capture | Paper, entered later | Desktop-first; adoption fails | Mobile and offline |
| UAE VAT / ZATCA | Handled downstream | Country packs vary; Phase 2 an add-on | Billing behaviour per entity |
| Typical fit | Small teams, few projects | Finance-led, simple projects | Multi-project, subcontract-heavy, multi-entity |
Time on site and with your QS and finance teams. We map how cost flows today, where the reconciliation pain sits, and which existing systems should stay.
Entity and project structure, cost coding standard, integration boundaries with your ledger and payroll, billing behaviour per entity. We agree what is in phase one and what deliberately is not.
Delivered in increments, validated against real projects and real invoices rather than demo data. Running a live project in parallel is uncomfortable, but it surfaces bad assumptions early.
Phased rollout, typically by project rather than big-bang. Training aimed at site users first, because that is where adoption is won or lost.
Our ERP-integrated ZATCA e-invoice solution covers EGS onboarding and integration with broad ERP compatibility and automated validation. The Saudi billing side is not a theoretical exercise for us.
Our delivered work spans IoT-enabled operations software (ClueMaster), a property portal (Rising Walls), logistics and transportation (OneTuch) and e-commerce (HiCare) — see our work.
We work with clients across the UAE, Saudi Arabia and India, including Saudi clients such as RiyadhPharma. That matters when your group spans jurisdictions with different obligations on the same project.
Usually not in the first phase. Most contractors have a finance system that works and a project layer that does not. The lower-risk route is to build the project, cost and commercial layer first and integrate it with the ledger you already run, posting supplier invoices, subcontractor certificates and sales invoices across. Replacing finance later stays a separate decision rather than a dependency.
In our experience a first useful release lands in a few months rather than a few weeks, and the full scope on this page runs considerably longer. The variable is rarely the software. It is how consistently your cost codes, BOQ structure and subcontract terms are defined across projects. Firms without a common standard spend the early phase agreeing one, which is work worth doing regardless.
Yes, and they are separate billing behaviours rather than one setting. A UAE entity issues VAT invoices under UAE rules. A Saudi entity under ZATCA needs the Fatoora requirements met: UBL 2.1 XML, cryptographic stamp, CSID from onboarding, UUID, invoice hash and PIH chaining, with standard invoices cleared before they reach the buyer and simplified invoices reported within 24 hours. We confirm what applies to your entity against ZATCA's published guidance per engagement, because the programme has moved in waves and continues to.
No, and if they do the data will be late. Progress capture, requisitions, goods receipt, plant hours, HSE observations and inspection requests belong on a phone or tablet, with offline capture that syncs when the device reaches signal. Commercial and finance work stays on desktop. That split usually decides whether the system reflects the site or what somebody remembered a fortnight later.
We treat the ERP as where labour cost is allocated to activities, and payroll as a system it feeds or integrates with. Timesheets, attendance, cost code allocation and plant hours belong in the ERP because cost control needs them there. Payroll obligations differ by country — in the UAE, salary payment through the Wage Protection System is a common consideration for firms employing labour there — so we scope that integration explicitly rather than assuming a generic module fits.
That is the common case and it shapes the architecture: multiple legal entities, different tax and invoicing regimes, different currencies, and joint ventures where a project does not map cleanly to one company. We design entity and project structures so consolidated reporting works without forcing every jurisdiction into the same billing behaviour.
It depends on what you already run and how unusual your commercial model is. We build custom platforms and we also integrate with systems already in place — our ZATCA e-invoicing work is designed for broad ERP compatibility rather than assuming one product. For most contractors the answer is a mix: keep what works, build the layer that does not exist, integrate rather than rip out.
Describe the reconciliation that takes your team three days every month and we can usually tell you, within a conversation, whether that is an integration problem, a coding standard problem or a build.