Home › Specialized Modules › Contracting & Construction

Contracting & Construction

Runs the whole contracting cycle: register the contract with its bill of quantities, issue periodic progress billings for the work actually done — the system computes retention, advance recovery, VAT and the net payable and posts the entry automatically — then track each contract's actual cost from the ledger through its cost centre, measure profitability against a cost budget and an estimate at completion, recognise revenue by percentage of completion, and manage variation orders, subcontractors and bank guarantees.

Overview and workflow

When do you use this module? When you execute work for a project owner under a contract with a bill of quantities, and get paid for what you complete in stages rather than in one go. The essential difference from an ordinary sales invoice is that revenue here is recognised on a percentage-of-completion basis, part of every certificate is retained by the owner, and part of the advance is recovered.

Register the contract on the Contracts screen: owner, value, the percentages (retention, advance recovery, VAT), then the bill of quantities.
Assign a cost centre — the contract's actual costs accumulate on it. Each contract needs its own (the system prevents sharing).
Activate the contract so certificates can be raised against it.
Record the advance received from the owner on the Advances & Retention screen.
Issue certificates periodically from Progress Billings — you enter only this period's quantity per item.
Book costs: issue materials from a warehouse or pay equipment hire on Contract Costs, and tag purchase invoice lines with the contract's cost centre.
Set the cost budget on Contract Cost Budget and revise the cost-to-complete forecast periodically.
Recognise revenue at each period end from Revenue Recognition.
Manage changes through Variation Orders, and sublet work through Subcontracts.
Log claims the day the event happens in the claims register — before the notice deadline passes.
Register bank guarantees in the guarantee register and watch their expiry.
Monitor completion and profitability on the dashboard and reports.
Release retention at the end, then close the contract.

One-time accounting setup: under «Settings → Accounts» configure the contracting accounts: Contr.ContractRevenueAccountCode, Contr.RetentionReceivableAccountCode, Contr.OwnerAdvanceAccountCode, Contr.MaterialsAccountCode, Contr.SubcontractorAccountCode, Contr.EquipmentRentalAccountCode and Contr.SubcontractorAdvanceAccountCode, plus Contr.WipAccountCode (contract work in progress) and Contr.ExcessBillingsAccountCode (excess billings) — the last two belong to revenue recognition. Companies created on the «Contracting & Construction» activity get these set automatically. Without the required account the system refuses to post and names the missing key in the message.

Permission	What it allows
`CONTR.Contracts.View / Create / Edit / Delete`	The contract register and bills of quantities.
`CONTR.Contracts.Manage`	Activating, suspending and closing a contract.
`CONTR.Billings.View / Create / Edit / Delete`	Preparing certificates and editing drafts.
`CONTR.Billings.Post / Unpost`	Posting and unposting a certificate — the financially sensitive right.
`CONTR.Advances.View / Create`	Owner advances and retention releases.
`CONTR.Costs.View / Create / Delete`	Direct contract costs (materials, equipment) and reversing them.
`CONTR.Variations.View / Create / Edit / Delete`	Preparing variation orders.
`CONTR.Variations.Approve`	Approving a variation — what actually rewrites the contract's BOQ and value.
`CONTR.Subcontracts.` and `CONTR.SubBillings.`	Subcontracts and their certificates.
`CONTR.SubAdvances.View / Create`	Advances paid to subcontractors.
`CONTR.Budget.View / Manage`	The contract cost budget and the cost-to-complete forecast.
`CONTR.Revenue.View / Create / Unpost`	Revenue recognition — it moves the financial statements directly, so grant it carefully.
`CONTR.Guarantees.View / Create / Manage`	The guarantee register; Manage covers extending, releasing and recording a claim.

Tenders and estimating

Path: Contracting → Tenders and estimating — /contr/tenders

This is where a contract begins.

The estimate is the budget. A contractor who wins a job and then types a cost budget into a screen from memory has thrown away the only figures anyone genuinely thought about: the ones that were priced, argued over and submitted. So awarding creates the contract and its budget in one step.

1. A rate is built up, not typed

Every item carries a rate build-up: how much labour, material and plant one unit consumes.

Kind	Description	Qty per unit	Unit cost	Cost
Labour	Concrete gang	0.35 day	400	140.00
Material	Ready-mix	1.05 m³	210	220.50
Equipment	Pump	0.10 hr	300	30.00
Cost per m³				390.50

A typed rate is a guess nobody can revisit; a built-up one can be re-costed when steel moves, without re-pricing the whole tender by hand.

2. Mark-up is not margin

Overheads % and profit % are set on the tender, so an item's rate = cost × (1 + their sum).

They are two entirely different numbers, and the screen shows both side by side on purpose: adding 20% to 100 gives 120, which is a 16.7% margin, not 20%. Confusing them is the most common way a tender goes out cheaper than its author believes.

Overheads are kept apart from profit because the first is a cost that must be recovered and the second is a decision.

3. Commercial loading

Leaving the rate blank means cost plus overheads and profit. Typing one is a commercial loading — front-loading early items is normal practice for cash flow.

The built-up cost does not move when a rate is loaded, so the item's real margin stays visible rather than assumed.

4. Cost by kind

Answers at a glance how much of a job is labour, material and plant — the first question asked when sizing up risk.

5. The award

What is created	At what price
The contract	Its value = the submitted tender value
The BOQ	At the selling rate (each item's submitted rate)
The cost budget	At the built-up cost, spread across cost codes

The budget the job is measured against for its whole life is therefore the one that was priced. That is the loop that makes the contract budget, the CVR and the S-curve mean something: all three compare against what was actually thought about.

Guards: an awarded tender is frozen — it cannot be edited, deleted or awarded twice, because the contract's budget rests on it. And a tender is never made "won" by changing its status: it is awarded, and the contract comes with it.

Contracts and the bill of quantities

Path: Contracting → Contracts — /contr/contracts

Purpose: the contract holds the agreement with the owner — its value, its percentages, and the BOQ every certificate bills against. It gets an automatic code like CONTR-00001 unless you type one.

Contract fields

Field	Required	Description
Contract name	Yes	The project, e.g. "Office building — phase one".
Client / owner	Yes	Picked from customers; the receivable is posted against them.
Cost centre	No (strongly recommended)	The bucket the contract's actual costs land in. Two contracts may not share one — each would report the other's spend, so the system refuses it.
Contract value	Yes	The contracted amount; you are warned when the BOQ total does not reconcile with it.
Retention %	No	Withheld from every certificate into the retention account until released.
Advance recovery %	No	Deducted from every certificate to recover the advance gradually.
VAT %	No	Charged on the value of work certified in each period.

Bill of quantities (BOQ)

Each item has a number, description, unit, contract quantity and unit rate — its total is computed. The "Certified" column shows how much of each item has been certified through posted certificates.

Fixed rules: an item that has been partly certified cannot be deleted, and the BOQ of a closed contract cannot be edited. Once a contract is active, prefer changing it through a variation order rather than editing in place, so every change keeps a document, a date and an approval.

Contract lifecycle

Draft → Active (via "Activate"; no certificates before it) → Suspended → Closed. The system refuses to close a contract while retention is still held, so money owed by the owner is never forgotten.

Foreign-currency contracts

A contract has a currency and an exchange rate. A contract written in a foreign currency states its value, BOQ rates, certificates and advances in that currency, while the books stay in the base currency — each document converted at its own rate when it posts. Leave the currency empty for a base-currency contract, which is what every existing contract is.

Two rates, not one: the contract's rate is the one agreed at signing and is the default for its documents. Each certificate carries its own rate, starting from the contract's and adjusted to the rate on its date — because a certificate is converted in practice at the rate ruling when it is issued, not when the contract was signed.

Why base-currency mirrors are kept: actual cost always comes out of the ledger in the base currency. Measuring cost-to-cost percent complete, revenue recognition or contract profit against foreign-currency amounts would compare two different moneys. So the contract stores its value in base at its signing rate, and the certified total as the sum of what actually posted — each certificate at its own rate — never a retranslation of the running total. Revenue recognition and the onerous-contract provision are measured on that basis.

Percent complete by quantity is a ratio within one contract (certified ÷ contract value), so currency does not affect it. The contracting dashboard sums across contracts, so it totals in base.

Known limit: open balances (receivables, advances, retention) are not retranslated at period end, so unrealised exchange differences are not computed automatically — record them with a manual entry if your accounting policy requires it.

Progress billings

Path: Contracting → Progress Billings — /contr/billings

Purpose: a periodic claim for the work done in the period. Pick the contract and the system brings its entire BOQ with, per item, the contract quantity, what was previously certified and what remains. You enter only this period's quantity; everything else is computed live.

The deductions strip — how the net payable is derived

Element	How it is computed
Work value	Sum of (period quantity × unit rate) across the items.
Retention	Work value × retention % — deducted and recorded as an asset held by the owner.
Advance recovery	Work value × recovery %, capped at the advance still unrecovered.
VAT	Work value × VAT % — added.
Net payable	Work value + VAT − retention − advance recovery.

Example: work of 260,000 with 10% retention, 20% recovery and 15% VAT → retention 26,000, recovery 52,000, VAT 39,000 and a net payable of 221,000.

The journal entry on posting

Side	Account	Amount
Debit	Accounts receivable	Net payable
Debit	Retention receivable	Retention
Debit	Advances from owners	Advance recovered
Credit	Contract revenue	The full work value
Credit	Output VAT	VAT

Note that revenue is recognised at the full value of the work done, not the net collected — that is what percentage-of-completion means. The "View journal entry" button shows the resulting entry from the screen.

Statuses and the rules around them

Draft (editable) → Approved (optional approval step) → Posted (has an entry, not editable).

What the system prevents:

Over-billing: an item's cumulative certified quantity may not exceed its BOQ quantity — raise a variation order if more is needed.
Out-of-order unposting: a certificate cannot be unposted while a later one is still posted, so cumulative quantities unwind in the right order.
Deleting a posted certificate: unpost it first.

Unposting creates a reversing entry (the original is never deleted) and restores quantities and balances.

You can print or download the certificate from the screen, once it is posted.

The certificate sheet. It prints on a contracting-specific layout rather than the generic invoice sheet, because a certificate is signed off by three parties. Each item shows its contract quantity and unit rate, then the executed quantities as previous / current / cumulative, then the item's remaining quantity, then the amounts across those same three columns; the total work at the foot of the table is the sum of the lines, not a figure carried from the header. Below it runs the deductions ladder in contract order — work this period, retention, advance recovery, VAT — down to the net payable, spelled out in words, beside the contract-to-date position (contract value, previous cumulative, cumulative to date, percent complete). The sheet is footed by three signature blocks: the contractor claims, the consultant certifies the measurement, the owner approves payment. It prints landscape, to fit the columns.

Advances and retention

Path: Contracting → Advances & Retention — /contr/receipts

Two cash movements on a contract; both post immediately on save:

Type	Entry	Effect
Advance received	Dr cash/bank — Cr advances from owners	Increases the advance balance later recovered from certificates.
Retention release	Dr cash/bank — Cr retention receivable	Reduces retention; releasing more than is actually held is refused.

Contract costs

Path: Contracting → Contract Costs — /contr/costs

An accounting point worth stating plainly: buying materials is not a contract cost. A purchase invoice puts materials into inventory, which is an asset. The cost is realised when the materials are issued to the project. So purchases do not appear as contract cost until you issue them here.

Cost type	What you enter	Entry
Materials	Item, warehouse and quantity — no amount	Dr contract materials — Cr inventory, at the item's weighted-average cost at issue time.
Equipment rental	Amount and paying account	Dr equipment rental — Cr cash/bank.
Labour & other	Amount and paying account	Dr contract materials (or an account you choose) — Cr cash/bank.

Every debit carries the contract's cost centre, which is what makes the cost appear on the dashboard and in the profitability report. "Reverse" creates a reversing entry and returns the materials to stock at the same cost they left at.

What about purchase and service invoices? Put the contract's cost centre on the invoice line itself (the "Cost centre" column on the purchase invoice); the entry is split automatically and the cost is attributed to the contract. That is the right route for services and expenses that never pass through stock.

Labour and equipment hours

Path: Contracting → Operational Resources — /contr/resources and Contracting → Timesheets — /contr/timesheets

The Contract Costs screen records what has a payment behind it. Two of the largest costs have no payment at contract level: labour, since payroll is one lump at month end and the question is how much of it each contract consumed; and owned equipment, since the company's own excavator invoices nobody yet the contract still consumes it. Both are answered by an hourly rate × hours worked.

Operational resources

Define labour trades and owned machines, each with a normal and an overtime rate. Leave the overtime rate at zero to charge overtime at the normal rate.

An equipment rate is the internal hire rate, not the machine's real cost. The real cost reaches the books separately as depreciation, fuel and repairs; what you set here is what you want to charge contracts for using it.

The timesheet

Record each resource's hours on the contract for the period. The sheet saves as a draft and touches no accounts until you post it.

Side	Account	Amount
Debit	Project labour — on the contract's cost centre	Labour hours cost
Debit	Equipment cost — on the contract's cost centre	Equipment hours cost
Credit	Accrued wages	Labour hours cost
Credit	Equipment cost recovery	Equipment hours cost

Why a separate credit per kind? Because charging a contract must not invent new company expense. Labour is offset to accrued wages, which payroll later clears, so the wage bill is never counted twice. Equipment is offset to equipment cost recovery, a contra account, because the machine's costs are already in the books — and that account's balance tells you how much of the fleet's cost the contracts absorbed.
Neither credit carries a cost centre, deliberately: the cost centre is how the system measures a contract's actual cost, so charging the credits to it would feed them straight back in as contract cost.

Rules: a posted sheet cannot be edited until it is unposted — which returns it to draft and withdraws the cost from the contract in full. A resource with timesheet history is deactivated rather than deleted. Changing an hourly rate applies to future sheets, since every posted line keeps the rate it was computed at.

Payroll

Path: Contracting → Payroll — /contr/payroll

This screen is the other side of the timesheet. A timesheet charges a worker's hours to a contract and credits wages accrued, and that entry is a promise: "this labour has been charged to a job and will be paid for later". Payroll is where the promise is kept.

The whole difficulty of payroll here is one thing: not expensing the same wage twice. The hours the timesheets charged to contracts are already in the income statement, so expensing the full wage bill again would double the cost of labour.

How the gross wage bill splits

Part	Where it goes	Why
What timesheets already charged to jobs	Debit wages accrued	Clears the liability the timesheet created — it is not expensed again
Whatever is left	Unallocated labour (an expense)	Idle time, waiting for materials, site staff nobody booked to a job

Unallocated labour is not a formality: it is what the company pays for hours it cannot attribute to any work. A company that never looks at it does not know what it is losing there.

The "charged to contracts" column

It is the worker's balance in the wages-accrued account: everything posted timesheets ever charged for him, less what earlier runs already cleared.

Why a position rather than a monthly match? Because a timesheet entered after its month's payroll had run would be stranded in the accrual forever if the match were by work date, and the wages-accrued balance would drift quietly upward year after year with nobody noticing. As a position, a late entry is simply carried into the next run.

It is also why the figures are recomputed at posting rather than when the draft was saved: a timesheet posted in between must not be missed.

The entry that posts

Side	Account
Debit	Wages accrued — the amount charged to contracts
Debit	Unallocated labour — the remainder
Debit	Employer contributions
Credit	Payroll deductions payable
Credit	Employer contributions payable
Credit	Net payroll payable — the net

Employer contributions are an expense on top of gross and are never taken out of the worker's pay, so they carry their own expense and liability and balance between themselves.

Paying

Posting creates the liability; paying is a second entry that clears net payroll payable against cash or bank.

Guards: one run per month (a second run for the same period would clear the accrual twice), deductions cannot exceed a worker's gross pay, and a paid run cannot be unposted before its payment is reversed — otherwise the payment would be left hanging against a liability that no longer exists.

Unallocated labour can come out negative, and it is left visible on purpose: it means the contracts were charged more than the wages actually cost. Clamping it to zero would have overstated contract cost silently.

The limit of this screen: it is payroll for the site workforce, to clear what the timesheets accrued — not an HR system. No leave balances, no end-of-service, no statutory tax tables; amounts are entered rather than derived from a rule engine.

End of service and wage protection

Path: Contracting → End of service — /contr/end-of-service

The benefit is not a cost that appears the day a worker leaves; it is earned every month he stays. A company that books it only on departure reports profits it does not have, and then takes the hit in one blow the year its crew turns over.

Employment data first

On the Resources screen, per worker: national ID, IBAN, hire date, and basic wage and housing allowance held separately.

These fields appear for labour only. A machine has no hire date and no bank account, and giving one either would end with it on a payroll file.

The monthly provision

Column	What it is
Service years	Hire date to the cut-off (or to the termination date)
Entitlement days	Under the rule configured in settings
Accrued to date	Entitlement days × (monthly wage ÷ 30)
Previously provided	What earlier runs posted
Movement	The difference — the only thing that posts

Only the difference posts, so re-running is safe and a wage rise tops the provision up rather than charging it twice. The entry is Dr end-of-service expense / Cr provision.

The entitlement rule is a setting, not code

Set in «Settings → Contracting»: days per year for the first five years, days per year thereafter, and whether allowances count towards the wage.

Country	Common rule
Saudi Arabia	Half a month (15 days) per year for the first five, then a month (30)
UAE	21 days per year for the first five, then 30

Burying either rule in code would have made the system quietly wrong in every other country. It asks you for your law rather than assuming it.

Settling a leaver

Record the termination date on the worker and he appears under "leavers not yet settled". Settlement pays out of the provision: Dr provision / Cr cash.

Why is settlement separate from the accrual? Because the accrual is what the worker earned and the payment is what was agreed — they differ whenever a resignation scales the entitlement down. The difference is released by the next run automatically, because a settled worker's position is zero. Correct accounting with no special case.

The wage-protection (WPS) file

From a posted payroll run, the "wage protection file" button shows a row per worker and then downloads the file.

The most useful part is the validation: a worker with no IBAN or no identifier cannot be on the file, and the screen names him before payday instead of the bank discovering it afterwards — which is usually where late wages begin. The establishment ID must also be set in «Settings → Contracting».

A known limit: the file is in the wage-protection shape, but the exact layout differs by bank and country and is revised periodically. Validate the first file with your bank before relying on it — the system does not claim a compliance nobody has verified.

Contract cost budget

Path: Contracting → Contract Cost Budget — /contr/budgets

Purpose: the BOQ tells you what you will be paid; the budget tells you what it will cost. You enter the cost budget by category (materials, subcontractors, labour, equipment, overhead, other) and the system compares it against the actual cost read from the ledger.

Commitment budget control

Comparing the budget against actual cost alone is control that arrives too late — the money is already gone. A contractor overspends the moment a subcontract is signed or a purchase order issued. So a budget line carries four figures: Budget − Actual − Committed = Available.

A commitment is derived, never posted. A promise to pay is not an accounting liability until the other side performs, so it does not touch the ledger — the same reasoning as bank guarantees. It is computed from subcontracts (value less what has been certified, so it shrinks with each certificate and reaches zero on its own) and from purchase orders tagged with the contract's cost centre, less what has been received against them. Open commitments are listed document by document, so any overrun traces back to its cause.

The policy lives under Settings → Contracting: Off / Warn / Block plus a tolerance percentage, defaulting to Warn. A hard block by default is a poor idea: a site that cannot issue an urgent subcontract because a line is short by two hundred will switch the whole control off.
A heading with no budget blocks nothing — nothing was promised about it, and treating it as zero would refuse every unbudgeted purchase.

Closing a purchase order: an order received in full liquidates its own commitment. One received partly and then abandoned would hold its residue against the budget forever — so it is closed from the purchase-orders screen with a stated reason, releasing the balance. Closing is a statement about the future: neither the order nor its receipts is touched and no entry is made, and "reopen" restores the commitment if the supplier delivers after all.

Accuracy of the split: actual cost is split across headings by mapping ledger accounts back through the contracting account keys. If several keys point at the same account the headings cannot be told apart, and the system says so on screen rather than showing a split that looks exact — the totals are correct either way. Give each key its own account for an exact split.

Cost to complete and the estimate at completion

A budget is set once; reality moves. That is what the cost-to-complete field is for — the project team revises it periodically, and from it comes the estimate at completion (EAC):

Situation	Estimate at completion
A forecast has been entered	Actual cost + cost to complete
No forecast entered	The budget as it stands — unless actual cost has already overrun it, in which case actual wins

Three figures follow from it, shown at the foot of the screen:

% complete by cost = actual cost ÷ EAC. This is the basis of revenue recognition.
Budget variance = budget − EAC. Negative means a forecast overrun.
Expected gross profit = contract value − EAC.

Onerous contracts: when the EAC exceeds the contract value, a red warning appears with the expected loss. The accounting standard requires a contract loss to be recognised as soon as it is foreseen, not when it materialises — and the system now raises the provision automatically inside the same recognition run: Dr Onerous contract loss, Cr Provision for onerous contracts.
The provision is measured on the remaining work — "expected loss × (1 − percent complete)" — because the loss on work already performed is already in P&L: on an onerous contract the cost-to-cost method recognises revenue below cost, so providing for the whole expected loss would charge that portion twice. It posts as a movement, like the contract position: each run tops it up or releases it by the difference only. If the contract stops being onerous, the provision falls to zero and the earlier charge reverses.
Configure the Onerous contract loss and Provision for onerous contracts accounts under Settings → Accounts. Do not point the loss account at one of the contract-cost accounts: the provision entry deliberately carries no cost centre for exactly this reason — were the provision counted as construction cost, the EAC would rise, the expected loss would rise, and the provision would grow without end.

Prerequisite: actual cost is read from the ledger through the contract's cost centre. Without one, actual cost shows as zero no matter what you spend. See Contract Costs.

Work breakdown structure and performance

Path: Contracting → Work Breakdown Structure — /contr/wbs

A contract total tells you nothing about where it is going wrong. The structure is a tree of work packages, each with a code, name, parent and a baseline (planned start and finish), with BOQ items attached to them.

The BOQ attachment is the whole point. A package measures nothing until items are attached to it: that is where its planned value and its earned value come from. The value of items not attached to any package is shown explicitly, so no work disappears from the measurement silently.

How performance is measured

Measure	How it is computed
Earned value (EV)	Σ (certified quantity × unit rate) of the package's BOQ items
Planned value to date (PV)	The package's value × how much of its baseline window has elapsed
Schedule variance (SV)	EV − PV — negative means behind programme
Schedule performance index (SPI)	EV ÷ PV — below one means behind

Why this measurement is honest: earned value comes from quantities an engineer actually certified on a مستخلص, not from a percentage someone types. That alone is the reason earned-value reporting is worthless in most systems.

A package with no baseline is reported as unscheduled and gets no index — calling it "on time" would be a comfortable lie.

CPI is contract-level only. Cost reaches the ledger against the contract's single cost centre, so there is no honest way to split it per package. Guessing a split would have been the easiest thing here and the most misleading, so the system refuses and says so on screen.

Tree rules: making a package its own ancestor is refused (the rollup would be infinite), as is deleting a package that still has BOQ items attached, or reusing a code.

Network schedule (critical path)

Path: Contracting → Network schedule — /contr/schedule

A bar chart of dates somebody typed is a wish. A network is a claim about cause: this cannot start until that finishes. Once the logic is stated, the duration of the job stops being an opinion and becomes arithmetic — it lasts as long as its longest chain of causes, and everything off that chain carries float.

Why the distinction matters. A contractor who cannot tell a critical activity from one with a fortnight of float spends its attention on the wrong one. A critical activity has zero float: a day lost on it is a day lost on the whole job.

What you enter, what is computed

You enter	The system computes
Activity: code, name, duration in working days	Early start and early finish (forward pass)
Dependency: predecessor, successor, type, lag	Late start and late finish (backward pass)
A constraint date, where one exists	Total float = late start − early start
Actual start / finish and percent complete	The critical path, the duration, the slip vs the contract

Dependency types

Type	Meaning
Finish to start (FS)	The common one: the successor cannot start until the predecessor ends
Start to start (SS)	They start together — excavation and shoring
Finish to finish (FF)	They end together
Start to finish (SF)	Rare; used for shift handovers

Lag may be positive or negative: seven days for concrete to cure is a positive lag during which nobody works, while a negative lag is a deliberate overlap.

Durations are WORKING days, not calendar days, so a ten-day activity does not quietly finish on a Friday. The weekly rest days come from the contracting settings (Gulf default: Friday and Saturday). Public holidays are NOT modelled, and the screen says so — a holiday calendar nobody maintains is worse than an honest absence of one.

A cyclic network is refused before it is stored. If A precedes B and B precedes A, "what comes first" has no answer. The system does not silently break the loop — that would produce a schedule that looks fine and is arbitrary — it refuses the save and names the activities caught in the cycle.

A constraint date can only ever push an activity later, never pull it earlier. The logic is a statement about physical possibility: concrete is not poured before the steel is fixed, whatever the constraint says. And an activity that has actually started started on a real date, whatever the plan said.

The baseline is what makes delay measurable

"Freeze baseline" stores today's computed dates, and slip is measured against those from then on. Without it, re-planning a late job is a trick: the dates move and the delay disappears. Freeze it when the programme is approved, not after.

It closes a limitation that was declared on the S-curve: planned value used to come from a hand-drawn window on the work package. Now, where activities are attached to a package, its value is spread across them in proportion to duration using the critical path dates — so the curve rests on a real network.

S-curve

Path: Contracting → S-curve — /contr/s-curve

Three figures mean little apart and say everything drawn on one axis, month by month:

Curve	What it is	Where it comes from
PV — planned value	What should have been done by this date	The network schedule where one exists, otherwise the baseline in the work breakdown structure
EV — earned value	What was actually done and certified	Certified quantities on posted certificates
AC — actual cost	What it actually cost	The ledger, on the contract's cost centre

It reads as a picture, with no arithmetic: earned below planned means late; cost above earned means expensive. The gap between them is the whole reason for putting them on one chart.

Why two curves stop at today

The earned and actual curves end at the current month rather than running to the end of the plan. That is deliberate: carrying them forward flat — which most systems do — draws a project that stopped working. Only the planned curve reaches the finish, because only the plan is about the future.

Where the planned curve comes from

Situation	What is drawn
WBS baseline dates exist	A real schedule: each package's value spread across its own window
No baseline, but the contract has an end date	The contract value spread evenly over its duration — and the screen declares this an assumption, not a schedule
No baseline and no end date	No planned curve is drawn and no schedule index is claimed

Inventing a straight line in that last case would have been the easiest thing here and the most misleading; the system refuses and says so on screen.

"Today" on the curve is exactly "today" on the WBS screen. Planned value rolls up from the root packages the same way, so two screens can never disagree about one project's progress.

The forecasts

Figure	How it is computed
Schedule index (SPI)	EV ÷ PV — below one means late
Cost index (CPI)	EV ÷ AC — below one means spending faster than earning
Forecast cost at completion	BOQ value ÷ CPI — at the rate you have been converting money into value
Projected finish	From the last six months' rate; a job that is not moving gets no date

Using the recent months rather than the whole history is deliberate: a job that has picked up or stalled lately is what a forecast should reflect.

Beneath the chart sits its table of numbers, month by month, because a chart nobody can tie back to figures is decoration.

Cash-flow forecast

Path: Contracting → Cash-flow Forecast — /contr/cash-flow

A contract can be profitable and still sink the company. Profit and cash are not the same thing on a job that bills monthly, has a tenth of every certificate withheld for a year, and pays its subcontractors before the owner pays it. This screen shows a contract's remaining cash, month by month.

The three terms

Set on the contract itself, they are what turns amounts into a flow rather than balances:

Term	Effect
Client payment days	Delays the collection of each certificate
Supplier payment days	Delays subcontractor and supplier payments
Retention release days	The maintenance period — what makes retention the last cash you see

How it is computed

Inflow: work not yet certified, spread across the remaining months, each month as work value + VAT − retention − advance recovery, delayed by the client's payment term. Plus the retention release, once, the maintenance period after the work ends.
Outflow: open commitments (subcontracts and purchase orders) and budget not yet committed, delayed by the supplier term.

The most important figure: peak funding requirement. It is the lowest point the cumulative reaches — the money you must arrange to fund the contract before that month arrives. A profitable contract can need it in its second month, because the subcontractor is paid before the owner pays.

Known limit: this forecasts the remaining flows only, and does not include collection of certificates already issued — the system does not link a receipt back to the certificate it settled. The warning appears on the screen itself.
A contract with no end date gives no basis for spreading its work across months; the screen flags this and an end date must be added.

Cost value reconciliation (CVR)

Path: Contracting → Cost value reconciliation — /contr/cvr

This is the report a contracting company is actually run on. Its question is not "are we profitable" but "is the profit we are reporting real".

Why ask at all? Because a job looks profitable whenever its cost is late arriving: the subcontractor has done the work but not certified it, the supplier delivered but has not invoiced. Measure value to date against only the cost that reached the books and you have measured two things at two different dates.

The two sides

Value side	Cost side
Certified to date (Σ posted certificates)	Cost in the books (the ledger, on the contract's cost centre)
+ probable claims from the claims register	+ cost not yet arrived — entered by the quantity surveyor
+ a value adjustment the QS judges
= value to date	= total cost

The difference between them is the margin to date.

1. The accrual is entered, not derived

"Cost not yet arrived" is the most important figure in the report. It cannot be taken from the books — that is exactly what makes it an accrual. It is asked for per cost code, because that is the level at which a QS actually knows the answer: how much the subcontractor has done and not certified, how much material arrived without an invoice.
Leave it out and the job flatters itself every single month.

2. Margin taken against final margin

A positive margin is not enough; what matters is that it is not higher than the margin the job will finish on. Taking 15% today on work that will end at 5% means you have drawn profit you have not earned, and you will give it back in a later month.

So the report shows margin ahead of forecast in points and warns explicitly once the gap passes half a point. This is the most common way a contractor's accounts flatter themselves.

3. A snapshot that carries the previous one

The report is per month and carries the previous month's position, so this month's movement appears inside the document itself — which is management's real question: what changed? An issued report cannot be edited or deleted, and a month cannot be issued after a later one already has been, because the positions chain.

The breakdown by trade

Per cost code: budget, cost in the books, accrual, forecast final cost and variance. The forecast never drops below what has already been spent — a trade does not finish for less than it has cost.

The lines add up to the header, including the "uncoded" row: a report whose lines do not reconcile to its own totals is worse than no report. See the contract budget and "Cost codes" in the accounting manual.

Prerequisite: the breakdown assumes costs are coded. Without coding everything lands in a single "uncoded" row — the header stays correct, but the detail stops being useful.

Revenue recognition by percentage of completion

Path: Contracting → Revenue Recognition — /contr/revenue

Purpose: in contracting, what you bill and what you earn are rarely the same. You may bill in advance of the work, or work a whole month before issuing its certificate. The standard requires the income statement to show what was actually earned. This screen is the period-end adjustment that achieves that.

How it is computed

% complete = actual cost ÷ estimate at completion (from the budget screen).
Revenue earned = contract value × % complete.
The difference = revenue earned − actually billed (the total of posted certificates).

Situation	Meaning	Where it appears
Earned > billed	You have done more than you invoiced	Contract work in progress — an asset
Earned < billed	You have invoiced more than you did	Excess billings — a liability

The key point: a progress billing books revenue when it is invoiced. So a recognition run does not re-recognise revenue — it posts only the adjustment that moves it from "billed" to "earned". That is why each run posts only the movement since the previous one, which keeps both balance-sheet accounts correct and the income statement always showing revenue earned to date.

What you see before posting

Pick the contract and the screen lays out the whole measurement before you commit to anything: actual cost, the EAC and % complete; then revenue earned against billed; then the net position (asset or liability); then the movement that will be posted now. If nothing has changed since the previous run the post button is disabled — no empty entries.

Operational notes:

The position flips between asset and liability automatically, with no intervention from you.
Unposting reverses that run's movement and restores the previous position; only the most recent run may be unposted.
A contract with no cost centre cannot have revenue recognised — the system refuses and explains why.

Uninstalled materials (IFRS 15 B19): a material that reaches site before it is built in has entered cost, but its work is not done — left in the progress measure it pulls margin forward. So it is recognised at cost, zero margin and excluded from the measure of progress. Enter two figures on the budget screen: the materials budget (expected total) and the cost delivered to date. The effect: delivering a riyal of materials adds exactly one riyal of revenue and the work percentage does not move. With the budget at zero, recognition behaves exactly as before.

Variation orders

Path: Contracting → Variation Orders — /contr/variations

Purpose: the formal way to change the scope of a live contract. Instead of editing the BOQ directly (which loses the trail), you raise a documented variation with a date, a description and an approval; on approval it is applied to the BOQ and the contract value in one step.

Pick the contract and the system shows its current items; for each you enter a quantity change (positive to add, negative to omit) and the new rate, or you append brand-new items.

How the value effect is computed: per item, (new qty × new rate) − (current qty × current rate). An item of 100 units at 1,000 that gains 40 units and is re-rated to 1,200 has an effect of (140×1,200) − (100×1,000) = 68,000 — i.e. a rate change re-prices the whole quantity, not just the increase.

What the system prevents: an item cannot be cut below what has already been certified, and an approved variation cannot be deleted — it is part of the contract, and undoing it means issuing a counter-variation. Approval itself sits behind its own permission, CONTR.Variations.Approve.

Site records

Path: Contracting → Site records — /contr/site

Three registers on one screen: the site diary, the RFIs and the punch list. None of them posts to the ledger.

That is not a limitation, it is the point. Their value is evidence: a delay claim without daily records is an assertion; with them it is proof. This is the layer that makes the claims register usable rather than aspirational.

1. The site diary

Weather, working hours, labour and plant on site, work executed, materials received, visitors — and above all the delays and disruption field.

Written every day, including days when nothing happened. A gap in the diary is what the other side points at.

Guards: one diary per site per day (two records for one day are two versions of the truth), and a day cannot be flagged as a delay event without saying what the delay was — an unexplained flag proves nothing.

2. RFIs

A question to the consultant that work is waiting on. The figure that matters is days open: one answered in two days costs nothing, while the same question left six weeks with a crew standing by is a delay.

Status	What happens
Open	Keeps ageing, day by day
Open past "required by"	Flagged overdue, and can be raised as a claim
Answered	Stops ageing on the day it was answered

Recording an answer date moves it off "open" by itself — otherwise it would age forever and overstate the delay it caused. And an answer cannot predate the question.

3. The punch list

Handover is not a date, it is a list reaching zero. Each item has a severity, and a critical one blocks handover on its own. The screen shows the percentage verified and the number of critical items still open.

Status	Meaning
Open	Nothing done about it yet
Fixed	The contractor says it is done; nobody has checked
Verified	Checked and accepted — the only status that closes an item
Rejected	Checked and rejected, and the reason is required or the same item comes back unchanged

An item whose responsibility lies with a subcontractor is the beginning of a back-charge to him: the cost of putting it right is his, not the main contract's. A verified item cannot be deleted — it is the record that it was put right.

4. From a record to a claim

A delay day or an overdue RFI can be raised as a claim from where it sits, and the claim is created carrying the record's reference and its text in its description.

The record is then frozen against editing and deletion — because the claim rests on it, and removing it would remove the evidence.

The event date on an RFI claim is the day the answer was needed, not the day the question was asked: the delay starts when the work stopped waiting patiently.

Document control

Path: Contracting → Document control — /contr/documents

Everything built on a site is built from a piece of paper, and the expensive failure is never a missing drawing — it is a SUPERSEDED one still being worked to: the wall goes up to revision B while revision C moved the opening, and the cost is demolition. The screen answers exactly two questions and refuses to be vague about either.

First: which revision is current?

One, always. Approving a revision for construction supersedes the previous one automatically.

"Superseded" is not a state you pick. It is the consequence of a newer revision being approved; setting it by hand would leave a drawing with no current revision and no explanation.

Pulling the current revision back to review leaves the drawing with nothing buildable, and the register states that plainly — better than letting a withdrawn revision keep looking current.

The drawing number belongs to the designer, not to the system. A drawing has an identity in the world before it reaches us, and inventing a second one would be one more thing to reconcile. Only the transmittal is numbered automatically: it is the document we originate.

Second: can we prove the party doing the work was given it?

"We sent it" and "they had it" are different claims, and only the second wins an argument. A transmittal passes through three states:

State	What it means
Draft	A list somebody typed. Nothing has gone out; the contents can be changed
Issued	It actually went. The contents are frozen — a historical fact
Acknowledged	The other side confirmed receipt. This alone proves delivery

An acknowledgement with no person's name is refused — that is exactly what a signature is — and so is one dated before the transmittal was sent.

The screen shows the dangerous state directly: "no proof of receipt" = a drawing approved for construction that nobody has acknowledged receiving, i.e. the office believes the site has it and cannot prove it.

A transmittal line points at the REVISION, never at the drawing: "we sent you A-101" is worthless; "we sent you A-101 rev C on the 4th" is proof.

Two dates: when it was needed, and when it arrived

Every revision carries both on purpose, and the gap between them is late issue of information — a ground for extension of time in every standard form of contract, claimable only because somebody wrote both dates down at the time. A revision that has not arrived keeps ageing, because the delay it is causing has not stopped.

Raising the claim from the register carries the drawing, the revision and both dates into the claim's description, and the event date is the day the information was needed, not the day the paper turned up — exactly as with RFIs. A revision that arrived on time cannot be claimed for, and one revision cannot raise two claims.

Information arrives on an incoming transmittal, so issuing one fills in the received date of the revisions it carries — but only where that date is blank, because a date recorded by whoever took delivery is better evidence than one the system infers.

What has gone out cannot be deleted: a transmitted revision, a drawing any of whose revisions was transmitted, and an issued transmittal are all protected, because each is part of the record of what changed hands.

Claims register

Path: Contracting → Claims register — /contr/claims

A claim is not a variation order. A variation is agreed, so it amends the contract. A claim is a contested request for extra cost or time: rock that was not on the drawings, late access to the site, a surge in steel prices. It becomes money only on the day it is settled, and at that point the system raises a variation order for the agreed amount.

The most dangerous figure on the screen is the notice deadline. Most contracts require the owner to be notified within a fixed period of the event, and a claim that misses its notice is lost even if it was entirely valid. So the system computes event date + notice period, shows the days remaining, flags a claim "notice at risk" seven days out and "time-barred" afterwards. Both are surfaced at the top of the register.

The notice period is set per contract in claim notice days (28 by default — the common FIDIC period). If your contract states otherwise, change it on the contract.

Amount claimed vs highly probable

A claim carries two amounts on purpose: the amount claimed, which is what you asked for, and the highly probable amount, which is what you judge is likely to be accepted. This is not extra paperwork: the IFRS 15 variable-consideration constraint only allows recognition to the extent a significant reversal is unlikely. The rest is disclosure, not revenue. The system refuses a probable amount larger than the claimed amount.

Claim lifecycle

Status	Meaning
Draft	Recorded internally; the owner has not been notified
Submitted	Notice served — reached automatically the moment a notice date is entered
Under review	With the owner or the engineer
Rejected / Withdrawn	Ended with nothing; the probable amount is zeroed
Settled	An amount was agreed and a variation order was raised; the claim then freezes

Settlement

On settlement you enter the amount agreed and the days granted. The system creates a draft variation order for that amount, links it to the claim, and zeroes the probable amount — because the money has moved to the variation order and must not be counted twice. Settlement posts nothing by itself: open the variation order and approve it to move the contract value. A settled claim carries an "open variation order" button that takes you straight there.

Guards: more cannot be agreed than was claimed, a notice date cannot precede the event, and a settled claim can be neither edited nor deleted.

Subcontracts and their certificates

Path: Contracting → Subcontracts — /contr/subcontracts

A subcontract sublets part of the work to a subcontractor (picked from suppliers), with its own value and percentages: retention, advance recovery and VAT.

Advances to subcontractors

Path: Contracting → Subcontractor Advances — /contr/sub-advances

When you pay a subcontractor before he has earned it: Dr advances to subcontractors (an asset — the money has gone out but is not yet earned) Cr cash/bank. It is then recovered automatically from his certificates at the rate set on the subcontract.

If the recovery rate is left at zero, nothing is recovered automatically from the certificates — set the rate on the subcontract first.

Subcontract BOQ (optional): add items with a description, unit, contracted quantity and unit rate, and the subcontract becomes measured — its certificates are then raised by quantity rather than a lump figure. Leave the table empty for a lump-sum package and the certificate stays a single typed amount, exactly as before.
An item cannot be deleted once it has been certified, so the cumulative quantities on posted certificates stay intact.

Subcontractor certificate

Path: Contracting → Subcontractor Billings — /contr/sub-billings

Side	Account	Amount
Debit	Subcontractors (cost) — carrying the contract's cost centre	Work value
Debit	Input VAT	VAT
Credit	Advances to subcontractors	Advance recovered
Credit	Withholding tax payable	Tax withheld
Credit	Accounts payable	Work value + VAT − advance recovered − WHT

Withholding tax: set a withholding tax rate on the subcontract and it is deducted from every certificate and remitted to the tax authority instead of being paid to him. It is charged on the work value, excluding VAT — the VAT is the authority's own money passing through you, and withholding on it would be tax on tax.
It is not a cost: the full work value stays as the P&L charge, and only who is owed the money changes. The amount withheld is tracked cumulatively on the subcontract and is reduced automatically when a certificate is unposted. Changing the rate applies to future certificates only; each posted certificate keeps the rate it was computed at.
Configure the Withholding Tax Payable account under Settings → Accounts, and do not point it at the VAT account — they are two different liabilities to the same authority and must never be pooled.

A note on subcontractor retention: what you withhold from a subcontractor stays inside the payables balance and is tracked on the subcontract's "Retention" figure for aging and follow-up; it is paid out later through an ordinary supplier payment. This differs from owner retention, which gets its own account — the reason being that the contracting chart contains a receivable retention account (held by clients) but no payable one.

Bank guarantees

Path: Contracting → Bank Guarantees — /contr/guarantees

Purpose: a register of every guarantee the company issues in favour of an owner or a tender board, and a watch on their expiry dates. That watch is not administrative detail: a performance bond that lapses without being extended can hold up payment on an entire project.

Type	When it is issued
Bid bond	With the tender — before any contract exists, so it is registered with no contract.
Performance bond	On award, and stays live for the duration of the project.
Advance payment	Against the advance, reduced or released as it is recovered.
Retention	To release retention early instead of waiting for the end of the project.
Maintenance	For the defects-liability period after handover.

Expiry watch

Live guarantees are listed first, sorted by the nearest expiry, each with a "days to expiry" column (which goes negative once passed). Anything expiring within thirty days is flagged explicitly. Across the top are the KPIs: active count and total value, what expires soon and its value, and the cash margin blocked at the banks.

Actions on a guarantee

Action	Effect
Extend	Enter a new expiry date and the guarantee stays live. The system refuses a date earlier than the current one.
Release	Returned by the beneficiary and cancelled at the bank — it leaves the live exposure and the release date is stamped.
Record claim	The beneficiary has actually called it. Record it here, and book the liability with a manual entry.

This is a tracking register and posts no journal entry. A guarantee is a contingent liability, not recognised in the books unless it is called. The bank commission and cash margin fields are recorded for tracking only — if you want the commission as an expense, record it with an ordinary payment voucher.

Approvals on contracting documents

Path: Settings → Approvals and the Approvals screen

Purpose: requiring management sign-off before a document posts. It is a basic requirement in larger companies, where whoever prepares a certificate must not be the one who posts it.

Two contracting documents are supported:

Document	Amount the threshold is measured against
Progress billing	Its net payable.
Variation order	The absolute effect on the contract value — a large omission deserves sign-off just as much as a large addition.

How it works

In the approval settings, enable a rule for the document type and set the minimum amount, the approver role and an optional second level.
On posting: below the threshold it posts straight away; above it the document does not post — an approval request is raised, the approvers are notified, and a clear message is returned.
The document stays unposted for as long as the request is pending.
As soon as the final level approves, the document posts automatically — no need to go back to it.
Rejection returns it to the preparer with the reason.

Requests are tracked on the Approvals screen, and you are notified about them.

Dashboard and reports

Path: Contracting (module header) — /contr/dashboard

Portfolio KPIs: active contracts, total value, total certified, % complete, retention held, advances outstanding, subcontractor cost, actual cost and net profit — plus a per-contract profitability table.

"Subcontractor cost" vs "Actual cost": the first is the sum of subcontractor certificates only; the second is everything posted to the contract's cost centre in the ledger — subcontractors, issued materials, equipment and any purchase invoice tagged with the centre. The second is the fuller measure of a contract's profitability.

Module reports (Report Centre → Contracting)

Report	What it shows
Contract register	Each contract with value, certified, % complete, retention, advances and status.
Progress billing register	Every certificate with its deduction split, net and status.
Retention aging	Unreleased retention per contract and days since the last certificate.
Contract profitability	Certified value against subcontractor cost, gross profit and margin.
Cost to complete	Per BOQ item: remaining quantity, remaining value and % complete.

Joint ventures

Path: Contracting → Joint ventures — /contr/joint-ventures

A construction joint venture is a joint operation in IFRS 11 terms, not a separate company: the partners share the revenue, the cost and the result directly.

This is the operating partner's accounting. The operator invoices the client for the whole job and pays the whole cost, so the contract sits in his books in full and a periodic allocation takes each partner's share out of his results. A non-operating share needs none of this: the participant simply records the contract at its own share and there is nothing to allocate.

1. Partners and shares

Open the contract from the screen and record its partners with each one's percentage. Our own share is the remainder — computed, never stored, so it can never disagree with theirs. Shares totalling more than 100% are refused.

Each partner may have his own current account; left empty, the default from «Settings → Accounts» is used. Giving each partner his own account is what makes their positions distinguishable in the trial balance.

2. Partner share allocation

An allocation is a periodic document that moves each partner's share of revenue and of cost onto his current account, leaving only our share in the income statement. The screen shows exactly what would post before you post it.

It carries a cumulative position per partner and posts only the difference from the previous run — exactly as revenue recognition does. So it can be re-run at will without double-counting, and a renegotiated share corrects itself on the next run.

Rule one: no leg of the entry carries the contract's cost centre. The system defines actual cost as everything posted to that centre on an expense account. A partner-share leg stamped with the centre would cut measured cost down to our share while the contract value stayed whole: percent-complete collapses, the estimate at completion follows, and the next allocation is computed from the damage it did itself. The cost centre keeps the whole job, because percent-complete, earned value and the budget are all about the job rather than our slice of it.

Rule two: the shares go to contra accounts. "Partners' share of revenue" and "partners' share of cost", never revenue and cost themselves — netting those down hides the job's real size, and the statement must show the gross with the partners' share as a visible, auditable deduction.

3. The entry that posts

Side	Account	Amount
Debit	Partners' share of revenue (contra-revenue)	Movement in their revenue share
Credit	Partners' share of cost (contra-expense)	Movement in their cost share
Credit / Debit	Each partner's current account	The difference — what he earned

It balances by construction: each partner's movement is his revenue delta minus his cost delta, so the partner legs always sum to exactly the difference of the other two. If cost has not moved between two runs, the cost leg simply does not appear.

4. Settling with a partner

The current-account balance is cleared with a settlement document: paid to the partner or received from him, against a cash or bank account.

A settlement touches neither revenue nor cost. The position was decided by the allocation, and paying it must never restate it — which is precisely why it is a separate document.

Guards: a partner still carrying an allocated balance cannot be removed; set his share to 0%, post one allocation to reverse him out, then remove him. Allocations unpost newest first, because the positions chain. And an allocation is refused on a contract with no cost centre — there is no measured cost to split.

Frequently asked

Why don't my purchases show as contract cost? Because a purchase goes into inventory (an asset). Issue the materials to the contract from "Contract Costs", or put the contract's cost centre on the purchase invoice line if it is a service or expense that never touches stock.

The system refused to close the contract. Retention is still held — release it from "Advances & Retention" first.

I need to certify more than the contracted quantity. Raise and approve a variation order, then issue the certificate.

The system refused to link a cost centre to a new contract. It already belongs to another contract. Create a dedicated centre per contract so each one's cost stays correct.

% complete by cost shows zero. Either the contract has no cost centre so its actual cost cannot be measured, or no cost budget and no forecast have been entered so there is no basis to measure against. See the budget screen.

The revenue recognition post button is disabled. There is no difference between the current position and the previous run — nothing to post.

I posted a certificate and it was refused, pending approval. An approval rule is enabled and the amount is over its threshold. Track the request on the Approvals screen; the certificate posts automatically once approved.

The system refused to extend a guarantee. The new date must be after the current expiry.

"Configure … in Settings" message. Your chart of accounts is missing the required account, or it has not been linked yet — link it under «Settings → Accounts».

Frequently asked questions

How do I create a contract?

Open Contracting › Contracts › New, set the client, contract value, BOQ/WBS and payment terms; the contract becomes the hub for billing, costs and retention.

How does progress billing work?

Raise progress (interim) invoices for the completed percentage or measured work; the system tracks billed-to-date versus the contract value.

How are subcontractors and retention handled?

Subcontracts track their own billing and retention; KEMTOVA ERP withholds retention on both client and subcontractor certificates and releases it later.

Does contracting recognize revenue over time?

Yes. Revenue recognition follows percentage of completion, with billings-in-excess/under handled as contract assets and liabilities per IFRS 15.