AWRA OpsHub Search

Ten, Fifteen, Thirty-Five, Twenty-Five

Projects & Job Costing AWRA OpsHub Team 13 min read

Victoria does not tell a builder when to invoice. It tells them how much they may hold at each point, as a percentage of the contract price, with the points defined by what has physically been built. Ten per cent when the footings are down. Fifteen when the frame is up and a surveyor has approved it. Thirty-five at lock-up. Twenty-five at fixing. Those four numbers are the whole payment schedule for a contract to build all stages, and a system that cannot hold a contract price cannot check a single one of them.

Four stages, defined by what exists on site

Section 40 of the Domestic Building Contracts Act 1995 begins by defining its own stages, and the definitions are physical rather than administrative. Base stage depends on what kind of floor the home has, and the Act gives five variants — timber floor with base brickwork, timber floor without, suspended concrete slab, concrete floor, and the case where the exterior walls and roof go up before the floor. Frame stage is when the frame is completed <em>and approved by a building surveyor</em>. Lock-up is when the external cladding and roof covering are fixed, the flooring is laid and the external doors and windows are in — the Act is explicit that temporary doors and windows count. Fixing stage is when all the internal cladding, architraves, skirting, doors, built-in shelves, baths, basins, troughs, sinks, cabinets and cupboards are fitted and fixed in position.

Read the frame stage definition again, because it is the only one that is not entirely about the builder. Every other stage is reached when the builder has done a thing. Frame stage is reached when the builder has done a thing <em>and somebody else has signed it off</em>, which means the date the stage was reached is not a date the builder controls, and the evidence for it is a third party's document.

The Table

Section 40(2) then says a builder must not demand, recover or retain more than a listed percentage of the contract price at the completion of a listed stage. Note the three verbs. This is not a schedule of entitlements; it is a ceiling on what may be held, and it bites on retention as much as on invoicing.

Contract to build all stages

At completion of base stage 10%
At completion of frame stage 15%
At completion of lock-up stage 35%
At completion of fixing stage 25%
The four figures, added up 85%

The arithmetic is ours and the conclusion is not: what the remaining fifteen per cent is for, and how the deposit permitted under section 11 sits against these figures, are questions for a construction lawyer rather than for a blog. Two other contract types have their own rows — a contract to build to lock-up stage is capped at 20% at base and 25% at frame, and a contract to build to fixing stage at 12%, 18% and 40%. Same stages, different ceilings, because the scope is different.

And for a major domestic building contract that is not one of the three listed types, section 40(3) drops the percentages and states the principle underneath them: no amount or instalment that is not directly related to the progress of the building work. The parties may agree that neither subsection applies, in the manner the regulations set out. Neither applies to a contract with the Crown or a public statutory authority.

And a cap before anything is built at all

Section 11 caps the deposit a builder may demand or receive before starting any work: 5% where the contract price is $20,000 or more, 10% where it is less — with power for the Governor in Council to raise that dollar threshold by regulation. The consequence of getting it wrong is unusually sharp: the building owner may avoid the contract at any time before completion, unless VCAT thinks that would be unfair in the circumstances, and a court finding the charge proven may order a refund. So the first number in the whole arrangement is a percentage of a figure, checked before any work exists to attach it to.

Every cap in this Act is a percentage of the contract price. Our project record has a name, a code, two dates and a description — and no price at all.

What our projects module can and cannot express

A stage is a named checkpoint on a project, and we have those. A milestone in this product carries a project, a name, an optional due date, a status of open, met or missed, and a sort order — so the four stages above are four milestones in the right order, and a task can be grouped under one. That much models the schedule faithfully. We wrote about what a milestone's date does and does not trigger in <a href="/blog/a-due-date-that-gates-nothing">From Due Date to Deadline</a>, and that finding stands here.

The gap this Act exposes is a different one, and it is upstream of every clock. A project in this product has a name, a code, a status, an owner, a department, a start date, a due date and a description. There is no contract price. And a customer invoice can name a project — that relation exists — but it cannot name a milestone. So the denominator every percentage in this Act is a percentage <em>of</em> is absent, and the link between a stage being reached and money being asked for is absent too.

What section 40 needs, against the projects schema

The input Held today Linked to the stage Checkable as a cap
The four stages, named and ordered Yes Yes No
Whether a stage has been reached Yes Yes No
The date it was reached, and the evidence Partly — configurable by you Partly — configurable by you No
The contract price No No No
What has been invoiced against this project Yes No No
What has been invoiced against this stage No No No
The cumulative percentage held No No No

Built and maintained Configurable by you, not maintained by us Not built

The first two rows are genuinely good and cost nothing to set up. Row four is the one everything else waits on: a percentage needs a denominator, and there is no field on a project for the figure the whole contract is worth. Rows five and six show the shape of the missing link — the invoice knows the project and not the stage, so "what have we asked for at lock-up" cannot be answered even where the money and the milestone both exist.

Two things in the product do point the right way. A task time entry carries a bill rate and an invoice reference, so billable effort can reach a customer invoice — which means the plumbing between project work and an invoice exists, just along the hours axis rather than the stage axis. And a milestone already has a status that can be marked met, which is the event a stage-based schedule would fire on. What is missing is a value beside the name and a percentage beside the value.

Named, ordered checkpoints on a project

A milestone carries a project, a name, a due date, a status of open, met or missed, and a sort order, with tasks grouped underneath it.

Built in

An invoice that knows its project

A customer invoice can name the project it belongs to, alongside its dates, its totals, what has been paid and what is outstanding.

Built in

Billable effort reaching an invoice

A time entry carries a bill rate and an invoice reference, so hours worked on a project task can be billed through.

Built in

Attachments and a signature on a record

A surveyor's approval can be filed against a record today, in the vault, with classification and access logging.

Built in

A contract price on a project

The figure every percentage in this Act is computed from, held once against the project rather than restated on each invoice.

We can add

A stage on an invoice

A relation from the money to the checkpoint it was raised at, so a cumulative percentage per stage is a query.

We can add

A cap tested when an invoice is raised

A percentage ceiling per stage, compared against what has already been asked for and what is being asked for now.

We can add

A stage reached on a third party's certificate

A date and an attributable approver for a checkpoint whose completion somebody outside the organization certifies.

We can add

The straight answer

What AWRA OpsHub does today

  • Ordered, named checkpoints on a project, each with a due date, a status of open, met or missed, and tasks groupable underneath.
  • A project with an owner, a department and dates, and a code unique across the organization.
  • A customer invoice that names its project, with its own dates, totals, amount paid and outstanding balance.
  • Billable effort that reaches an invoice, through a time entry carrying a bill rate, a cost rate and an invoice reference.
  • Documents filed against a record, in the vault, with classification and access logging, so a third party's certificate has somewhere to live.
  • Custom fields on projects, tasks and invoices, so a contract value or a stage reference can be recorded, reported and exported today.
  • Per-currency figures with the composition disclosed rather than converted, on every total this module produces.

More we can add to your workspace

  • A contract price on a project, as a first-class figure with its own currency, which is the denominator every percentage in this Act needs.
  • A percentage ceiling on a checkpoint, so a stage carries the proportion of the contract price that may be held once it is reached.
  • A stage reference on a customer invoice, so money can be attributed to the checkpoint it was raised at.
  • A cumulative figure per project, showing what has been invoiced and what has been received as a proportion of the contract price.
  • A check at the moment an invoice is raised, comparing the cumulative proportion against the ceiling for the stage reached.
  • A completion date and an approver on a checkpoint, for a stage whose completion is certified by somebody outside the organization.
  • A variation that adjusts the contract price, since every ceiling moves when the price does.

Where we point you to a specialist

  • We will not decide whether a stage has been reached. Base stage alone has five definitions in this Act depending on the floor type, and frame stage turns on a building surveyor's approval. Those are site judgements and third-party certifications, and the useful thing software can do is hold the definition you are working to, the date somebody recorded, and the document that supports it.
  • We will not tell you which row of the Table applies to your contract. Whether a contract is to build to lock-up, to fixing, or all stages — and whether it is a major domestic building contract at all — decides the ceilings, and the Act also lets the parties contract out in the manner the regulations set out. A construction lawyer owns that, and getting it wrong changes every number.
  • We hold a position on where a cap belongs, and it is at the point the invoice is raised rather than in a report afterwards. A percentage ceiling that is only visible in a monthly review is a record of an overcharge, not a control against one — and under this Act an overcharge can be met with an order to refund. A quotation from us for this work puts the comparison in front of the person raising the invoice, and shows both figures rather than just refusing.

The first item is one decimal column and a currency, and nothing else on this list is possible without it. The second and third are a decimal on the checkpoint and a nullable relation on the invoice, and together with the first they make the fourth a query and the fifth a comparison — that is the whole build and it is small. The sixth is a date and a person on a checkpoint, worth having wherever somebody outside your organization signs work off. The seventh is the one that needs a proper conversation, because a variation changes a figure other records have already been measured against.

More we can add for you

What we can build for your market on top of the standard product

Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for your market, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a local payroll engine, a rate with a date on it, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.

Dated rates and the periods your obligations actually use

Effective-dated tax rates, so a document raised about a past period is computed against the rate that applied then rather than the rate that applies now, and a credit note that carries the tax split of the supply it reverses. Where a jurisdiction operates a sales-monitoring or fiscalisation scheme, data produced in the published format alongside the approved equipment rather than in place of it.

Banks, payments and pay periods that are not months

Bank statement feeds and local payment rails wired into the Payments Register, and a payroll period that matches your statutory pay cycle rather than the calendar month our schema assumes today. The second is a data-model change and we would quote it as one.

The operational work, which is what most commissions actually are

An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.

Payroll and statutory returns

Income tax, superannuation or provident fund contributions computed on live employee records against your own pay cycle, with the returns produced in the layout your authority expects.

Systems you already run

The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.

How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.

Tell us what you need integrated

Four questions for a system that will bill against stages

Where does the contract value live?

What you will probably hear

On the quotation, or on the first invoice.

How to read it

Ask for it on the project. A figure that lives on a document is a figure that gets superseded, and every cap in this Act is a proportion of one number that has to stay stable across the whole job. If the answer is a custom field, ask whether anything can compute against it.

Can an invoice be attributed to a stage?

What you will probably hear

It can reference the project.

How to read it

Then cumulative-per-stage is unanswerable, which is the only question a percentage ceiling asks. Ask specifically for a milestone reference on the invoice rather than a note in the description, because a note cannot be summed.

What happens when the contract price changes?

What you will probably hear

You edit it.

How to read it

Ask what happens to the percentages already measured against the old figure. A variation is the normal case in construction and it moves every ceiling; a system that silently re-bases history is worse than one that refuses to.

Who records that a stage was reached, and on what evidence?

What you will probably hear

The project manager marks the milestone met.

How to read it

Fine for an internal plan. Here one stage is reached only when a building surveyor approves it, so ask whether a checkpoint can carry a date, an approver who is not one of your users, and the document that certifies it.

Our take

This is the rare compliance shape where the missing piece is a single column. The stages model cleanly as ordered milestones, the invoice already knows the project, and effort already reaches an invoice — what is absent is the contract price and a way to attribute money to a stage, and everything section 40 asks for follows from those two. Until they exist, hold the contract value and the stage as custom fields and do the percentage arithmetic outside the system, and put the surveyor's frame-stage approval in the vault against the project so the one date you do not control is evidenced. If you are billing against stages at any volume, this is a small and unusually well-defined build.

Tell us what your payment schedule is a percentage of

Stage-based billing and period-based billing are different shapes and the second is much better served by most software. We looked at a periodic statutory valuation cycle in <a href="/blog/three-days-after-the-month-ends">Three Days After the Month Ends</a>, and at a payment-claim ladder with its own statutory clocks in <a href="/blog/a-day-that-skips-only-the-holidays">A Day That Skips Only the Holidays</a>.

Talk to us about your workspace

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center