Importing a Candy BOQ Into Your ERP

The handover nobody designs

Almost every UAE contractor of any size estimates in Candy and runs the project somewhere else.

The tender is built in CCS Candy — take-off, rate build-up, resource pricing, mark-up, the whole commercial position. It wins. And then somebody opens Excel, retypes a budget into the accounting system, and the connection between the estimate and the live project is broken on day one.

From that point the project has two truths. The estimator’s version, which knows what every rate was built from. And the accountant’s version, which knows what has been spent but not what it was supposed to cost at line level. They are reconciled monthly by hand, badly, and the reconciliation is what a commercial manager spends the first week of every month doing.

The fix is not complicated in principle: import the priced BOQ from Candy into the ERP as the project’s cost structure. Doing it properly is a different matter, and this guide covers what that actually involves.

What Candy is, and why it sits outside the ERP

CCS Candy — now part of RIB Software — is estimating and project control software built specifically for construction. It is dominant in the Middle East, Africa and parts of Asia, and if you work with UAE contractors you will encounter it constantly.

What it does well:

• Take-off and measurement, working to POMI, NRM2 or CESMM conventions
• Rate build-up from first principles — labour, plant, material, subcontract and overhead resources assembled into a unit rate
• Resource libraries carrying current prices, reused across tenders
• Bill production in the structure the consultant issued
• Cash flow and valuation modelling at tender stage

What it is not: a finance system. It does not hold your general ledger, run payroll, or manage supplier invoices. Nor should it.

So the two systems coexist by design. Candy owns pricing. The ERP owns execution. The question is not whether to replace one with the other — it is what crosses the boundary between them, and in what shape.

What actually breaks at the handover

Six specific things, and they compound.

The budget is re-keyed rather than transferred. Somebody types totals into the ERP. Transcription errors happen, but the bigger problem is that only the totals move. The line-level detail stays in Candy.

Cost codes are invented rather than inherited. Finance creates a code structure that suits accounting. Estimating priced against a bill structure that suits measurement. Procurement orders against supplier packages. Three structures describing the same work, and no reliable way to move between them.

Rate build-ups do not travel. Candy knows that the AED 340/m³ concrete rate was built from a specific mix price, a specific labour gang and a specific plant allocation. The ERP receives AED 340 and nothing else. When the concrete supplier raises prices, nobody can quickly say which BOQ lines are exposed or by how much.

Provisional sums and prime cost sums lose their status. Imported as ordinary budget lines, they look like committed scope. They are not — they are placeholders to be expended against instruction, and treating them as budget overstates what has actually been allowed for.

Preliminaries are dumped into one line. A single “preliminaries — AED 4.2m” budget line cannot be controlled. Site staff, temporary works, plant, insurance and site running costs are different cost types with different owners and different time profiles.

The bill structure is flattened. Bills, sub-bills and section hierarchy collapse into a flat list, and the reporting hierarchy the QS relied on disappears.

Each is survivable alone. Together they are why so many contractors have an ERP that produces accurate accounts and no useful project cost control.

What to bring across, and what to leave behind

Not everything in Candy belongs in the ERP. Deciding this before the mapping work starts saves a great deal of argument later.

The principle: the ERP needs to know what the budget is at line level. It does not need to know how the rate was constructed. Rate build-up stays where it is maintained.

The exception worth arguing about: resource-level budget. Some contractors split each BOQ line’s budget into labour, plant, material and subcontract in the ERP, so actual cost can be compared to allowance by cost type rather than only in total. It gives materially better control and it roughly doubles the mapping effort. Decide deliberately.

The mapping decision

This is the whole job. Everything else is mechanics.

Candy’s bill structure is organised for measurement. The ERP’s cost structure is organised for control. They are not the same shape and pretending they are is where these projects fail. The work breakdown structure is the spine both have to hang from.

Option 1 — BOQ line as cost code

Every BOQ item becomes a cost code in the ERP.

Good: perfect traceability, valuation straight from the same structure, variations price against the original line.
Bad: a 3,000-line bill produces 3,000 cost codes. Procurement staff cannot code a purchase order to the right one, and they will guess.

Works on small projects. Collapses above roughly 500 lines.

Option 2 — cost code group, BOQ line beneath

Cost codes sit at bill or sub-bill level — perhaps 40 to 150 for a typical project. BOQ lines hang beneath as a reporting dimension.

Good: procurement can actually use it. Reporting rolls up cleanly. Line detail is retained for valuation.
Bad: cost is controlled at group level, so a single over-running line inside a healthy group is less visible.

This is the right answer for most UAE contractors and it is what we would default to.

Option 3 — standard cost code library, BOQ mapped to it

The contractor maintains a fixed cost code library used on every project. Each project’s BOQ maps into it at import.

Good: consistent reporting across the portfolio, comparable rates between projects, procurement staff learn one structure.
Bad: the mapping is manual on every project, and BOQ items that do not fit the library have to be forced somewhere.

Best for contractors running many similar projects. The cross-project rate comparison it enables is genuinely valuable — it is the only way to know whether your blockwork rate is drifting.

Whichever you choose, agree it across estimating, procurement and finance before the first import. All three post against it, and a structure agreed by only one of them will be abandoned by the other two within a month.

How the import works

Step 1 — export from Candy

Candy exports to Excel and to structured formats. The Excel export is the practical route for most implementations.

Export the priced bill with, at minimum: bill and section references, item reference, full description, unit, quantity, rate, amount, and item type where Candy distinguishes measured work from provisional and PC sums.

Step 2 — normalise the extract

The export is rarely import-ready.

• Strip merged cells and repeated headers. Candy’s Excel output is formatted for reading.
• Flatten the hierarchy into explicit columns — a bill code and section code on every row, rather than implied by position.
• Separate rate and amount into clean numeric columns.
• Classify item type — measured, provisional sum, PC sum, dayworks, contingency, preliminary.
• Handle blank and heading rows. Section headers and page totals are not items.

Step 3 — map to cost codes

Apply the decision above. Build the mapping as a saved, reusable table rather than as a one-off transformation — the same project will be re-imported when the bill is revised, and it will be revised.

Step 4 — validate before loading

Five checks, and none is optional:

The first check is the one that matters. If the imported total does not equal the tender sum, stop and find the difference. Loading a budget that does not reconcile to the winning tender means every report from that project is wrong, and it will not be discovered for months.

Step 5 — load and lock the baseline

Load into the ERP as the project’s original budget. Then lock it.

The original baseline must remain fixed. Revisions — approved variations, budget transfers — are recorded as movements against it, not by editing it. A budget that has been silently edited cannot be reported against, and the question “how does this compare to what we tendered?” becomes unanswerable.

Step 6 — reconcile after the first month

Run the first month’s cost against the imported budget and check that the cost codes are actually being used. They will not be, entirely. Procurement will have coded some purchase orders to the wrong place, and site will have coded timesheets to a default. Fix it in month one, while the volume is small.

What this gives you afterwards

Committed cost against the tendered rate at line level. A purchase order raised against a BOQ line updates committed cost immediately — weeks before the invoice arrives. That gap between commitment and invoice is where most project losses become unrecoverable, and it is what project costing software exists to close.

Interim valuations from the same structure the bill was priced in. Measured progress against BOQ items produces the payment application directly, rather than through a parallel spreadsheet that never quite agrees with the cost report.

Variations priced from contract rates. When the employer instructs a change, the first question is whether a BOQ rate applies. With the bill in the ERP, that lookup takes seconds. Getting variation orders priced from contract rates rather than negotiated from scratch is the cheapest and least contentious route available.

Cost-to-complete that means something. Actual plus committed plus remaining, at line level, feeding earned value management and the WIP calculation rather than being estimated in aggregate.

Rate feedback into the next tender. Actual cost per BOQ line, compared against the rate that was priced. Over several projects this is the most valuable output of the whole exercise, and almost nobody captures it — the estimator keeps pricing from the resource library while the site keeps proving the library wrong.

Where these projects go wrong

Importing before agreeing the cost code structure. The most common failure. The import is technically successful and commercially useless, and it has to be redone.

Treating it as a one-time exercise. Bills get revised. The import needs to be a repeatable, versioned process, not a heroic effort by one person who then leaves.

Losing the audit trail. Every import should record what was loaded, from which Candy file, by whom, on what date. When a figure is questioned eight months later — and it will be — that record is the answer.

Importing unpriced bills. A bill with no rates has no budget in it. Import the priced version, after award.

Ignoring the preliminaries split. Preliminaries are typically 8–12% of the project. Loading them as one line surrenders control of a significant sum. Split at minimum into staff, temporary works and plant, site running costs, and insurances and bonds.

No plan for the revised bill. Post-award the bill changes — variations, remeasurement, agreed corrections. If the process only handles the original import, the ERP budget and the current commercial position diverge from month two.

Which ERPs handle this well

The requirement is a project cost structure that can hold several thousand lines with a hierarchy, and code transactions to it from procurement, subcontracts, timesheets and plant.

Microsoft Dynamics 365 Finance & Operations with a construction industry solution layered on it handles BOQ-driven structures natively, including BOQ import with mapping and validation.

Odoo handles it through analytic accounting and project cost structures, and works well for contractors up to moderate bill sizes. Very large bills need care in how the analytic hierarchy is configured.

Generic accounting software does not handle it. A chart of accounts is not a cost breakdown structure, and forcing one to behave like the other produces a chart with four thousand accounts and no useful reporting.

For contractors evaluating this properly, construction ERP software in the UAE should be assessed specifically on how it holds a BOQ — not on whether it has a “projects” module.

Part of our complete guide to ERP for construction.