Skip to content

What Zoho and Odoo Genuinely Cannot Do for Construction (And What It Costs to Fix)

What Zoho and Odoo cannot do natively for construction ERP - BOQ costing, retention and subcontractor billing

Most articles comparing ERP systems for construction are written to sell one. This one is not.

Techvaria implements both Zoho and Odoo. We also regularly tell contracting firms that neither one, out of the box, does what they actually need β€” and that the honest answer is either a significant custom build or a specialist construction ERP. Getting that call wrong costs a contractor six to nine months and a great deal of goodwill.

So this is the article we wish existed when contractors call us: a plain account of what generic ERP genuinely cannot model for construction, what it costs to close the gap, and when you should walk away and buy something purpose-built instead.

The Core Problem: Construction Accounting Is Not Normal Accounting

Almost every mainstream ERP β€” Zoho, Odoo, NetSuite, Business Central, Xero β€” is built on a transaction model that assumes you sell a thing, invoice for the thing, and get paid for the thing. Construction does not work that way.

In contracting, the commercial reality is that you bill against certified progress on a bill of quantities, a portion of every certified amount is withheld for a year or more, an advance you received at the start is being clawed back across every invoice, and a meaningful share of the work is being done by subcontractors whose own retention and back-charges have to be tracked against the same line items.

None of that is exotic in construction. All of it is foreign to a standard ERP data model. That mismatch β€” not feature count β€” is what determines whether an implementation succeeds.

The Five Things Generic ERP Does Not Model Natively

1. Bill of Quantities as a costing structure

A BOQ is not a product list. It is a hierarchical structure β€” sections, sub-sections, items β€” where each line carries a quantity, a rate, a unit, and its own budget for labour, material, plant and subcontract. Cost is tracked against the BOQ line, not against a product SKU or a project as a whole.

Neither Zoho Books nor Odoo has a native BOQ object. Odoo’s analytic accounting and project cost tracking gets you closer than most, and can be pushed a long way with analytic distribution across a project’s cost lines, but you are still building the BOQ hierarchy yourself and maintaining the mapping between BOQ lines and analytic accounts. Zoho requires the structure to be built in Creator and integrated back to Books.

What this means practically: “cost to complete per BOQ item” β€” the single most important number a QS looks at β€” is a custom report in both platforms, not a standard one.

2. Progress billing against certified work

Construction invoicing is not “issue invoice, await payment.” It is: submit a payment application, the consultant or engineer certifies some portion of it (usually less than you claimed), and you invoice against the certified figure β€” which then feeds the next application’s cumulative position.

This introduces a document that generic ERP simply does not have: the interim payment certificate, sitting between your claim and your invoice, with its own approval state and its own value that differs from what you asked for.

Modelling this properly requires a custom application-and-certification workflow, cumulative-to-date tracking across applications, and the logic to derive an invoice from a certified rather than claimed value. It is achievable in both platforms. It is not present in either.

3. Retention

Retention is deceptively simple to describe and genuinely awkward to implement. A percentage β€” commonly 5% or 10% β€” is withheld from every certified amount. Half is typically released at practical completion, the balance at the end of the defects liability period, often twelve months later.

The requirements this creates:

  • Retention held as a separate balance, not netted invisibly into receivables
  • Release schedules driven by project milestone dates rather than invoice dates
  • Ageing and visibility on retention receivable, which is frequently the largest single asset on a contractor’s balance sheet
  • The mirror image on the payable side for retention you are holding from subcontractors

Both Zoho and Odoo can be made to hold retention through custom fields and dedicated ledger accounts. Neither will manage the release schedule for you, and neither will age it correctly without work. Retention leakage β€” money simply forgotten and never claimed β€” is one of the most common findings when we review a contractor’s books.

4. Advance payment recovery

An advance or mobilisation payment received at contract start is recovered by deducting a percentage from each subsequent certified amount, until fully recouped. It has to be tracked as a liability that amortises against progress, and the recovery has to appear correctly on every payment application.

This is custom logic in both platforms. It is not conceptually hard, but it interacts with retention and with certified-versus-claimed values, and the three together are where most half-built implementations fall over.

5. Subcontractor package management

This is where complexity multiplies. A single project may run a large number of concurrent subcontract packages, each with its own scope, its own BOQ subset, its own retention percentage, its own advance recovery schedule, and its own certification cycle.

On top of that sit back-charges β€” costs you incur on a subcontractor’s behalf and recover from their next certificate β€” and the reconciliation of subcontractor claims against your own main-contract claim, so that you are not certifying work downstream that you have not yet been certified for upstream.

Generic ERP treats a subcontractor as a vendor and their invoice as a bill. That model breaks immediately.

A note on sizing: figures circulating in vendor content about the typical number of subcontract packages per project vary widely and are not independently sourced. Treat them as illustration rather than benchmark β€” the point is that the number is large enough that manual tracking fails, not that it is any specific figure.

What Each Platform Actually Gives You

Requirement Odoo Zoho
BOQ hierarchy and costingNot native. Analytic accounting provides a workable foundation.Not native. Requires Creator plus Books integration.
Progress billing and certificationNot native. Custom workflow required.Not native. Custom workflow required.
Retention withholding and releaseCustom fields plus dedicated accounts. Release schedule is manual.Custom fields plus dedicated accounts. Release schedule is manual.
Advance recoveryCustom logic.Custom logic.
Subcontractor packages and back-chargesPurchase and analytic accounts give partial coverage. Package model is custom.Largely custom.
Project cost and profitabilityGenuinely strong. Analytic accounting is a real advantage here.Good at project level via Projects and Books. Weaker at BOQ line level.
Procurement, inventory, plantStrong and native.Adequate via Inventory. Less depth for plant and equipment.
Site workforce and payroll (UAE WPS)Requires localisation work.Zoho People and Payroll have stronger regional coverage.
Rapid custom app developmentPython module development. Powerful, needs developers.Zoho Creator is genuinely fast for this. A real advantage.

The honest summary: Odoo starts closer on the accounting and operational side because analytic accounting was designed for exactly this kind of multi-dimensional cost tracking. Zoho gets you to a custom solution faster because Creator is a genuinely productive low-code environment and the regional payroll coverage is better. Neither is a construction ERP.

What the Custom Build Actually Involves

Being concrete about effort matters more than being reassuring about it. Broadly, contracting implementations fall into three bands.

Band 1 β€” Project cost visibility only

You want reliable cost capture against projects, decent procurement, and profitability reporting. Billing stays outside the system or is handled simply. This is largely configuration, and both platforms handle it well. Timelines are measured in weeks.

Band 2 β€” Full commercial cycle

BOQ structure, payment applications, certification, retention, advance recovery, and subcontractor packages. This is a genuine development project with data modelling, custom objects, workflow and reporting. Timelines run to several months, and the requirement gathering matters more than the build.

The single most common failure we see is a Band 2 requirement scoped and priced as Band 1. It usually surfaces around month four, when someone asks for a cost-to-complete report per BOQ item and discovers the underlying data was never structured to produce one.

Band 3 β€” Multi-entity, multi-project, JV-heavy contracting

Large contractors with joint ventures, multiple legal entities, complex intercompany arrangements and heavy claims exposure. At this level the custom build starts approaching the cost of a specialist product, and the conversation should change.

When You Should Not Use Zoho or Odoo

Some genuinely useful disqualifiers. Consider a specialist construction ERP instead if:

  • Claims and variations are a material part of your commercial strategy, not an exception. Claims management is a discipline in itself and generic ERP does not model it.
  • You are regularly in joint ventures with complex profit-share and intercompany accounting.
  • Your tender-to-BOQ workflow needs to feed estimation software bidirectionally.
  • You need integrated BIM or 4D scheduling links.
  • You have no appetite for maintaining custom code and no internal or partner capacity to support it over time.

That last point deserves emphasis. A custom build is not a one-off cost. It is a maintenance commitment across every platform upgrade. If nobody owns it after go-live, it will decay, and you will be back to spreadsheets within two years β€” only now with a licence fee attached.

A Practical Decision Framework

Four questions that will resolve this faster than a feature comparison:

1. Do you bill against certified progress on a BOQ? If no, generic ERP is probably fine. If yes, you are in Band 2 or above and should budget accordingly.

2. What proportion of contract value goes to subcontractors? Below roughly a quarter, subcontract handling can stay relatively simple. Above half, package management becomes the core of the system rather than a peripheral feature.

3. Is retention material to your cash position? For most contractors it is one of the largest balance sheet items. If you cannot currently produce an aged retention receivable report, that alone justifies the project.

4. Who maintains the customisation in year three? If there is no credible answer, choose the option with less custom code β€” even if it fits slightly worse today.

Final Thoughts

Zoho and Odoo are both capable platforms, and a great many contracting businesses run successfully on them. But they run successfully on them because someone did the modelling work honestly at the start β€” not because the software arrived understanding what a payment certificate is.

The failures we are asked to rescue almost always share the same origin: a demo that showed project costing, a proposal that priced configuration, and a requirement that was actually a development project. The gap was not in the software. It was in the scoping.

If you are evaluating right now, the most useful thing you can do is take your last completed project’s payment applications, retention schedule and subcontractor certificates into the demo and ask the vendor to model them. Not to describe how they would. To model them. The answer will be clear within an hour.

Scoping a Construction ERP? Get a Second Opinion First.

Techvaria implements both Zoho and Odoo β€” and will tell you plainly if neither fits. Bring us your BOQ, retention schedule and subcontractor certificates, and we'll show you exactly what's configuration and what's development.
Pradeep S

Director @ Techvaria | Solutions Architect | Low-Code & AI Automation for Growth | Proven Expertise in Digital Transformation Across Industries