The real decision is not which construction ERP to buy. It is whether you need one at all, or whether a general ERP with a projects module will do — and there are five specific things that answer it.
Most ERPs have a projects module. It is usually a cost centre with a start and end date, and for many industries that is enough. Contracting is not one of them, for five specific reasons.
1. Measurement. A contractor does not bill what was delivered, they bill what was measured and certified. That requires a measurement record tied to bill-of-quantity line items, and it is the single most common absence in generic systems.
2. Retention. A percentage of every certified bill is withheld and released long after, sometimes years. Held as a header percentage it cannot be aggregated; held as a Retention Receivable ledger account it becomes a number you can chase.
3. Subcontractor bills against work done. Not a purchase invoice — a running account with a subcontractor, measured, certified and retained in the same way your client does to you.
4. Material against a BOQ. The question is never "what did we buy", it is "did what we buy match what the executed work should have consumed". That requires consumption linked to BOQ items, not just to a project.
5. Site labour distinct from payroll. Daily attendance of gangs at rates, often through contractors, is a different problem from salaried payroll, and systems that model only the second cannot cost the first.
Score yourself honestly on those five. If fewer than three matter, a generic ERP is the better buy.
Ask any vendor: where does the quantity in a measurement entry come from?
"The engineer enters it" describes a form. It means site progress is recorded once by a supervisor and then re-typed by someone else into a measurement record — two entries of the same fact, by different people, at different times. They will diverge, and the divergence surfaces when a client certifies less than you billed.
"It derives from work already logged against that BOQ activity" describes a system. It is a materially harder thing to build and it is the difference between software that reduces disagreement and software that adds a place for it to happen.
Ask for total retention outstanding across all projects, with expected release dates. Then watch what happens.
If the answer arrives on screen, retention is modelled as money owed. If it requires a spreadsheet, or a project-by-project trawl, retention is stored as a percentage on bill headers and is not really being tracked — which for most contractors is one of the largest and least visible amounts they are owed.
This test takes a minute and eliminates more products than an hour of feature comparison.
Construction ERP implementations rarely fail on capability. They fail on adoption, and specifically on the gap between the office and the site.
The pattern is consistent: the system is chosen by the commercial team, configured thoroughly, and then requires site staff to enter data on a form designed for a desk. Site staff continue sending progress on WhatsApp. Within two quarters someone in the office is re-keying WhatsApp messages into the ERP, and the project is quietly declared complete while delivering nothing it promised.
Two things predict success. First, whether daily site entry is genuinely faster than the WhatsApp message it replaces — not comparable, faster. Second, whether the people who will do that entry were in the evaluation. A system chosen without them will be a system used without them.
Traditional construction ERP is sold with an implementation project attached — discovery, configuration, data migration, training, phased go-live — measured in quarters. Sometimes that is genuinely necessary. Often it is a consequence of software that cannot do anything useful until it has been configured to your exact process.
The useful question is what works on day one with no configuration. If the answer is "nothing until we have modelled your workflow", price in the consultant time and the internal attention, both of which are usually larger than the licence. If the answer is that projects, BOQ and site logs work immediately and configuration is refinement rather than prerequisite, the risk profile is completely different.
All five capabilities above are built: measurement synced from logged work-done quantities, retention posted to its own Retention Receivable ledger account, subcontracts with subcontractor bills, material consumption against BOQ items, and site labour attendance separate from salaried payroll. Alongside them, procurement from requisition through RFQ to purchase order and three-way match, bank guarantees, tender tracking, a project WBS, change orders, quality and safety records, and GST with e-invoicing and e-way bills.
Three things are genuinely absent and worth weighing. There is no critical-path scheduling — Rebota tracks activities and progress, not a resource-levelled CPM network, so planners keep Primavera or MS Project. There is no BIM integration, so quantities come from the BOQ and measurement book rather than from a model. And group consolidation across many SPVs is manual, which matters to developers running each project as its own company.
| Feature | Generic ERP + projects | Traditional construction ERP | Rebota |
|---|---|---|---|
| Projects with budgets and costs | |||
| BOQ as a live structure after tender | |||
| Measurement derived from logged site work | Varies | ||
| Retention as a ledger account | |||
| Retention outstanding across all projects | Varies | ||
| Subcontractor running accounts | |||
| Material consumption against BOQ items | |||
| Site labour distinct from payroll | Varies | ||
| GST e-invoicing and e-way bills | Varies | Varies | |
| Usable before configuration | Varies | Months | Day one |
| Critical-path scheduling | Often | Use P6 or MSP | |
| BIM integration | Sometimes | Not built |
Contractors for whom at least three of the five capabilities matter — measurement, retention, subcontractor bills, material against BOQ, site labour — and who currently hold those together with spreadsheets, WhatsApp and memory.
A firm doing lump-sum work with no measurement, no retention and no subcontractors. That is a projects problem, not a contracting one, and a generic ERP or good accounting software will serve you better and cheaper.
A traditional construction ERP wins where integrated CPM scheduling is non-negotiable, or where a listed group needs statutory consolidation across many subsidiaries. Both are real gaps in Rebota, not preferences.
One site, one supervisor, one client, and you are there every day. Version drift is a problem of more than one person — below that threshold spreadsheets are genuinely fine.
The licence is rarely the cost. It is the implementation attention, the consultant time where configuration is a prerequisite rather than a refinement, and — most reliably underestimated — the effort of getting site staff to record progress in the system rather than on WhatsApp.
Score the five capabilities honestly. Below three, buy generic. Above three, judge candidates on where measurement quantities come from and whether they can state retention outstanding in one minute. Those two questions predict more about a system than any feature matrix.
Contractors who get value from construction ERP put site data entry ahead of reporting in the rollout order. The instinct is the reverse — configure the dashboards the directors asked for, then get the site to feed them — and it fails reliably, because the dashboards are empty for months and confidence goes with them. Starting with one thing site staff enter daily, and making it genuinely faster than the message it replaces, produces a system with real data in it. Everything else can be built on that; nothing can be built without it.
