Most ERP systems were designed around a product moving through a supply chain. You buy materials, you hold inventory, you make or resell something, you ship it, you invoice it. Cost attaches to a unit, revenue recognises on delivery, and the margin is knowable per item. A professional services firm has none of that. Its inventory is people's time, which expires unsold at the end of every day. Its cost of delivery is salary, which is fixed regardless of whether anyone is billable. Its revenue arrives under fee arrangements that may be time-and-materials, fixed price, capped, milestone-based, retainer, or some negotiated hybrid — and the profitability of an engagement is frequently unknown until it is nearly finished. When a services firm implements a generic ERP, the mismatch does not show up in the demo. It shows up eighteen months later, when the finance team is running the business from spreadsheets because the system cannot answer the questions that matter.
The four things generic ERP handles badly
Utilisation. The central operating metric of a services business is what proportion of available capacity is billable, measured by person, by team, by grade and over time. Generic ERP has no native concept of capacity, so utilisation gets calculated outside the system from exported timesheet data — which means it arrives late, is reconciled manually, and is argued about rather than acted on. Work in progress and unbilled revenue. Services work accrues value continuously and bills periodically, creating a persistent gap between delivered effort and issued invoices. WIP has to be tracked, aged, reviewed and written down when it will not be recovered. Product-oriented systems have no natural home for it, so it lives in a spreadsheet, and the write-down conversation happens once a quarter instead of continuously. Revenue recognition on long engagements. Recognising revenue as performance obligations are satisfied — percentage of completion, milestones, or over a service period — requires the system to hold an estimate to complete and to revise it as the engagement progresses. Delivery-triggered recognition logic simply does not model this, and the current accounting standards require it to be done properly. Resource scheduling against the pipeline. The core planning question is whether the people you will need in six weeks are available and appropriately skilled, given deals that have not closed yet. That requires the pipeline, the resource plan and the delivery schedule to sit in one model. In most generic implementations they sit in three systems and a shared calendar. Beneath all four is a structural point: in a services firm the project, not the product or the cost centre, is the unit of financial management. Budget, actual cost, revenue, margin, staffing and billing all need to roll up by engagement, and every report the leadership team cares about is a project-level report. An ERP whose chart of accounts and reporting spine is organised around anything else will fight that requirement permanently.
What good looks like
The successful pattern is a purpose-built professional services capability — either a dedicated PSA platform integrated to the finance system, or a services-oriented module within an ERP that genuinely supports project accounting rather than badging a job-costing feature as one. The practical test when evaluating: can it produce a live project profitability report that includes unbilled WIP and a current estimate to complete, without an export? Can it show forward utilisation against a weighted pipeline? Can it handle a fixed-fee engagement with milestone billing and percentage-of-completion recognition without custom development? If any answer requires a spreadsheet, the gap is architectural rather than configurational, and it will not close. One warning about the integrated-versus-best-of-breed choice. A separate PSA platform integrated to finance is a legitimate and common architecture, and it usually wins on functional depth. The cost is the interface: time, expenses, revenue and billing all have to flow reliably, and the reconciliation between the two systems becomes a monthly task that someone owns forever. A single system that does both adequately is often the better answer for a firm under a few hundred people; above that, functional depth tends to win.
| Requirement | Scenario to test |
|---|---|
| Unbilled work | Age WIP and show the effect of a write-down |
| Fee structure | Follow actual fixed-fee, capped or retainer arrangements |
| Capacity | Connect skills and availability to the opportunity pipeline |
| Multi-entity work | Trace contracting entity, delivery entity and recharges |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for Services ERP Assessment
- Make the project the reporting spine before selecting anything. If engagement-level profitability is not a native dimension, every report becomes an export.
- Test WIP and unbilled revenue in the demo with your own scenario. Ask to see aged WIP, a write-down, and the resulting margin impact — not a slide about it.
- Check revenue recognition against your actual fee structures. Fixed fee with milestones, capped time-and-materials, and retainers each behave differently, and "we support percentage of completion" is not an answer.
- Insist on timesheet capture that people will actually use. Mobile, fast, and pre-populated from the schedule; every downstream number depends on time data arriving on time.
- Connect resourcing to the pipeline explicitly. Forward utilisation against weighted opportunities is the planning view that prevents both bench cost and delivery failure.
- Define your utilisation formula before implementation, not after. Which hours count as available, how leave and training are treated, and what grade mix means — disagreement here invalidates the metric.
- Cost the integration if you choose a separate PSA platform. Time, expense, revenue and billing interfaces plus a permanent monthly reconciliation owner.
- Get change orders into the system, not into email. Scope changes that never reach the engagement record are the most common cause of unrecoverable WIP.
The Regional Dimension
Services firms in the Gulf carry requirements that off-the-shelf project accounting rarely anticipates. Multi-entity delivery is the dominant complication. A regional consultancy, engineering firm or agency typically operates several legal entities — mainland companies, free zone entities, and separate establishments in Saudi Arabia, Qatar or elsewhere — and a single client engagement frequently draws staff from more than one. That generates intercompany recharging on every timesheet line, with transfer pricing implications, and it is compounded by the fact that free zone entities face activity restrictions on where and for whom they can deliver work. The system has to know which entity is contracting, which entity is delivering, and how the cost moves between them. Most generic implementations discover this after go-live. Cost-rate construction is genuinely different here. An employee's fully loaded cost includes not only salary but visa and residency costs, medical insurance for the employee and often dependants, annual flight allowances, housing allowances, and accrued end-of-service gratuity — with the gratuity accrual rising with tenure, which means the same person's cost rate changes over time in a way that product-market payroll assumptions do not capture. Firms that use salary alone as the cost rate systematically overstate engagement margin, often by a meaningful amount. The tax and compliance layer adds more. VAT treatment varies by whether the client is onshore, in a designated zone, or outside the GCC, and place-of-supply rules for services are not intuitive. Saudi e-invoicing requires clearance of invoices through the tax authority's platform, which constrains how and when a services invoice can be issued and effectively removes the option of a loosely governed billing process. Withholding tax applies in several regional markets on cross-border service fees and needs to be modelled at engagement level or it becomes a margin surprise at collection. Two further local realities. Payment cycles on regional projects, particularly in construction, government and large family-group work, are long, and retention amounts are common on engineering and construction-adjacent contracts — which makes WIP and receivables management more consequential than in markets with faster settlement. And Saudisation and Emiratisation requirements mean workforce composition is a regulated constraint rather than purely a commercial one, so resource planning has to track national employment ratios alongside skills and availability. A resourcing model that optimises only for cost and utilisation will produce staffing plans the firm cannot legally execute.
The objection worth taking seriously
The honest counter-argument is that most services firms do not fail because of their system. They fail because they scoped an engagement badly, priced it optimistically, staffed it with the wrong people, or did not have the conversation with the client when the work changed. A better system makes those failures visible faster; it does not prevent them. Firms that buy a PSA platform expecting it to fix commercial discipline are disappointed, and the implementation frequently gets blamed for a problem it was never going to solve. There is also a real proportionality question. For a firm under about thirty people, a well-built spreadsheet model plus straightforward accounting software genuinely works, and the overhead of a full project accounting implementation — licence cost, implementation effort, and the timesheet discipline it demands of every fee earner — can exceed the benefit. The transition point is usually when the number of concurrent engagements exceeds what one person can hold in their head, or when someone outside finance needs the numbers without asking finance for them. And a caution about precision. Project accounting systems can produce margin figures to two decimal places built on cost rates that are estimates, overhead allocations that are conventions, and time entries submitted a week late from memory. The false confidence that creates is its own risk: leadership teams make staffing and pricing decisions on numbers that look authoritative and are approximately right at best. The discipline worth keeping is to understand which inputs are measured and which are allocated, and to make the big decisions on the measured ones.
Common Questions
Should we buy a separate PSA platform or use an ERP module?
Functional depth generally favours a dedicated platform; simplicity and lower total cost favour a single system. As a rough guide, firms up to a few hundred people are usually better served by one adequate system, and larger or more complex firms by best-of-breed with a properly owned integration.
What is the most commonly underestimated requirement?
Intercompany delivery. The moment staff from one legal entity work on another entity's engagement, you need recharging, transfer pricing treatment and consolidated project reporting — and almost nobody raises it during selection.
Why do utilisation numbers get disputed so often?
Because the denominator was never agreed. Available hours, treatment of leave, training, business development and internal work all change the result substantially. Define the formula in writing before implementation and publish it.
Where is AI actually useful in project accounting?
The most valuable application is prediction rather than automation: using historical engagement data to forecast final cost and completion date from partial progress, which surfaces overruns while there is still time to act — the single most valuable early warning a services firm can have, and something estimate-to-complete processes based on delivery-lead optimism consistently miss. Secondary uses that work now: timesheet reconstruction from calendar, email and document activity to improve the quality and timeliness of time data, automated scope-change detection by comparing delivered work against the engagement letter, and resource matching across skills, availability, cost and nationality constraints. The limitation is data quality — prediction trained on historical projects where time was recorded loosely and scope changes were never logged will confidently reproduce those errors. Fix the capture discipline first; the models are only as good as the engagement records they learn from.
Services ERP Assessment — if engagement-level profitability with live WIP requires an export, the gap is architectural and configuration will not close it.