Software category · Australia

Construction management software,
judged against an Australian build.

The category covers six jobs, pricing the work, committing the money, running the programme, controlling cost, getting paid and holding the record. What decides whether a product suits an Australian residential builder is how it handles stage claims, GST, the accounting seam and the site boundary. This page covers what the category is, what this market specifically demands, how a suite differs from point tools, what to look for, the questions worth asking, the honest limits, and how VIABUILD approaches it.

01 / The direct answer

What construction management software is

Construction management software is the system a building business runs its jobs in, as opposed to the system it keeps its accounts in. It holds the estimate, the budget, the purchase orders, the programme, the cost position, the claims and variations, and the document record, and its value comes from those things being connected rather than from any one of them individually.

That distinction is the whole decision. Almost every product in this market can produce a purchase order and a schedule. What separates them is whether the estimate becomes the budget without being re-typed, whether a purchase order moves a committed cost figure the day it is raised, and whether an approved variation reaches the next progress claim by itself. Feature lists do not show you that. A trial on one of your own jobs does.

This page is about the category and what an Australian residential builder should demand of it. If you have already decided to buy and want the selection process itself, the method is in the guide to choosing construction software, and the cost of the arrangement you have now is set out in software stack sprawl.

02 / The scope

The six jobs the category actually covers

Products in this market cover different subsets of these six and describe themselves the same way regardless. Working out which ones you are buying, and which you are keeping elsewhere, is more useful than comparing feature counts.

Pricing the job

Takeoff off the drawings, an estimate built from quantities and your own rates, allowances and provisional sums, and the margin decision on top. This is where the profit on the job is decided, months before anyone turns a sod, and it is the module builders most often keep in a spreadsheet longest.

Turning the price into commitments

The estimate becomes a budget, the budget becomes trade packages and purchase orders, and each order becomes a commitment against a cost code. Procurement is the hinge between what you priced and what you will actually spend, and it is where a suite earns its keep.

Running the programme

Tasks, durations, dependencies, trade bookings and a baseline to measure slip against. Scheduling is the module most often bought and least often maintained, because a programme nobody updates is worse than a whiteboard.

Controlling cost while it can change

Budget against committed against actual, per cost code, on every live job, with a forecast of where the job finishes. This is the difference between a builder who knows on Tuesday and a builder who finds out at close-out.

Getting paid and staying compliant

Progress claims against contract stages, variations priced and approved before the work is done, retention tracked to its release points, and a tax invoice that stands up. In Australia this module carries statutory weight that overseas products were never built for.

Holding the record

Drawings and revisions, contracts, site diaries, photos, RFIs, inductions and SWMS. Most of the time this is filing. On the day a defect claim or an adjudication arrives it is the only asset you have, and it cannot be assembled retrospectively.

The order matters, because these six are a chain rather than a menu. The estimate sets the budget, the budget authorises the purchase orders, the orders create the committed cost, the invoices settle it, the programme decides when each of those happens, and the claims recover it. A product that is strong at one link and silent about the one before it will make you the integration.

03 / The local requirement

What an Australian residential builder needs on top

This is where a globally excellent product can still be the wrong purchase. None of these are preferences. They are the shape of contracting and taxation in this country, and they are expensive to work around.

GST and BAS run through everything

Every claim is a tax invoice, every supplier bill carries GST, and the whole lot has to agree at BAS time. Software that treats tax as a configurable percentage usually handles GST correctly and rounding inconsistently, and the difference only shows up when the ledger and the job view disagree by a few dollars a month.

Claiming runs on contract stages, not pay applications

Australian domestic building contracts claim against defined stages, base, frame, lockup, fixing, completion, at percentages set in the contract. American products claim through a pay application against a schedule of values, with lien waivers attached. Both are progress claiming, and the workflows are not interchangeable.

Security of payment sets the clock

Each state and territory has its own Act, its own definition of a payment claim and its own response window for a payment schedule. Software cannot give you compliance, but it can record what was served and when, which is the part builders most often cannot reconstruct later.

Home warranty cover sits over the job

Domestic building insurance is a state scheme with a different name and a different administrator in almost every jurisdiction, and eligibility is assessed on your financials. A system that holds a clean job cost position is quietly doing eligibility work for you every year.

The ledger is usually Xero or MYOB

Most construction software sold here integrates with one or both, because that is where the accountant already works. The integration is the seam that decides whether you have one system or two, so it deserves more evaluation time than any single feature.

Contractor payments get reported

Building and construction businesses that pay contractors report those payments to the ATO annually. It is a bookkeeping task rather than a software feature, but it is a good reason to insist that subcontractor payments are coded properly at the point they are made rather than sorted out in July.

There is one more requirement that is harder to see on a feature list. Australian residential building runs on provisional sums, prime cost items and client selections against allowances, and those three things behave as a system. A selection made above its allowance is a variation waiting to happen, and if the software treats selections as a client-facing catalogue with no connection to the budget, the difference surfaces at the worst possible moment. The mechanics are set out in prime cost and provisional sums and selections management.

04 / The structural choice

A suite and a set of point tools fail differently

Most builders arrive at this decision from the same place, a spreadsheet for estimating, a separate takeoff app, a scheduler, email for purchase orders and the accountant for the rest. The question is not which of those is worst. It is whether the cost you are carrying is in the tools or in the gaps between them.

Point tools fail on the seams. Each one is good at its job and none of them knows about the others, so a number exists in four versions with no rule about which is authoritative. The work of reconciling those versions is invisible because it never appears as a task, it appears as somebody being busy. It is also the work that gets skipped first when the business is under pressure, which is exactly when the numbers matter most.

Suites fail on depth and on adoption. A management platform’s estimating module will rarely match a dedicated estimating package, and a suite where four of twelve modules are genuinely used is worse than four tools that are all current, because the reports built across stale modules are confidently wrong. That failure is not a software defect. It is what happens when a business buys more system than it has habits for.

The useful way to decide is to count seams rather than features. Write down every point where a number leaves one tool and is typed into another, and estimate the hours a week somebody spends on that. If the answer is small, keep your point tools and buy depth. If the answer is a day a week, no amount of feature comparison changes the fact that you have a seam problem, and only one data model fixes a seam problem.

05 / Before you buy

Six things to look for

All six are testable in a trial on a real job with a real contract. Rank them by where your business currently leaks time rather than by which sounds most impressive in a demonstration.

One data model, not one login

The test of a suite is whether a number entered once appears everywhere it is relevant. Ask for a specific chain, an estimate line becoming a budget line becoming a purchase order becoming a committed cost becoming a coded invoice. If any step is an import, an export or a re-key, you have bought several products behind one menu.

Built for how you contract

Fixed price and cost plus behave differently in every module downstream, from how a variation is priced to what the client sees. Take the contract type you actually use, and the least standard job you have signed, and set it up during the trial rather than watching the demonstration dataset.

Something the site will actually use

Office software fails at the site boundary. Diaries, photos, defects and confirmations either arrive from the people doing the work or they are typed up later by someone who was not there. Judge the field experience on a phone, on site, on bad reception, not on a laptop in a meeting.

An accounting seam you can describe in one sentence

Decide which system owns contacts, which owns bills, which owns invoices, and what direction each one flows. If the vendor cannot state that rule plainly, your bookkeeper will be discovering it for the next six months.

Adoption cost, not feature count

Every module you buy is a habit someone has to keep. A platform with twelve modules and three that are used is worse than four modules that are all current, because the reports built on stale modules are confidently wrong. Ask what the vendor expects you to stop doing.

Your data on the way out

Estimates, cost history, claims and the document record are the raw material of your next tender and your defence in a warranty claim. Ask what exports, in what format, and whether it includes attachments. Ask before you sign, because it is the one question that gets harder to ask later.

06 / The conversation

Questions worth asking a provider

Six questions with specific answers. The first is the most diagnostic in the category, and the last one tells you the most about the person you would be buying from.

  1. 01

    Show me one number travel the whole way through

    Pick a line, say the framing package. Ask to see it as an estimate line, then a budget line, then a purchase order, then a committed cost, then a supplier invoice coded against it, then its effect on the forecast. Every place the demonstrator has to open a spreadsheet or re-type a figure is a seam you will maintain by hand.

  2. 02

    Which Australian builders like me are using this today

    Not a logo wall. Ask for the shape, custom homes or volume, how many live jobs, what state, fixed price or cost plus, and whether they run the same modules you intend to. A product with genuine residential Australian usage will answer specifically. A product that was localised for this market will answer in generalities.

  3. 03

    What exactly syncs with my accounting system

    Object by object and direction by direction. Contacts, bills, invoices, payments, tracking categories, GST treatment. Then ask what does not sync, and what is on a roadmap rather than shipped. The gap between "integrates with Xero" and a working two-way sync is where most double entry lives.

  4. 04

    What does my site supervisor have to do every day

    Get the daily routine described in minutes, not features. Then ask what happens when they do not do it. A system that degrades gracefully when the site is busy is worth more than one that produces beautiful reports only when every field is complete.

  5. 05

    What is the real total for my team, including the year two price

    Price your actual shape. Per user, per job and per active project produce very different bills for a builder with six live jobs and four office staff. Ask about implementation fees, training, data migration and what happens at renewal. Then ask what a second entity or a second brand costs, if you might ever need one.

  6. 06

    What do you not do

    The most useful question in any software conversation, and the fastest read on a vendor. Every product has an edge. A provider who names theirs, payroll, or civil claiming, or heavy plant, is telling you where the workarounds will be. A provider who claims none is either not listening or not being straight with you.

07 / Honest limits

What construction management software cannot do

Four limits, and knowing them before you buy changes what you expect from an implementation.

It cannot fix a bad estimate. Every downstream module compares against the budget, and if the budget was optimistic at tender the system will report accurately and early that the job is losing money. Worth knowing, and not the same as making money. The cause sits upstream in estimating and in the handover into the budget.

It cannot capture what nobody enters. Committed cost exists only if purchase orders are genuinely raised before the order is placed, and a site record exists only if someone on site produces it. The real implementation project is the habit, not the configuration, which is why the field experience deserves more weight in an evaluation than it usually gets.

It cannot supply compliance. Security of payment legislation differs in every state and territory, home warranty cover is a state scheme, and the building contract is a legal document. Software can hold dates, records and evidence, which genuinely helps. It cannot tell you your position, and any product implying otherwise is overclaiming. The structure is in security of payment by state, and specific matters belong with a lawyer.

And it cannot make the decision. A forecast four per cent over budget is the beginning of a conversation about scope, a variation or a supplier, and no system has a view on which is correct. Construction management software is an instrument. It buys you time and earlier information, which is worth a great deal, and it does not run the business.

08 / How VIABUILD does it

One operating system rather than a set of connected modules

VIABUILD is the Construction Operating System for residential builders. The distinction it is built on is the one this page keeps returning to. Estimating, takeoff, procurement, purchase orders, cost control, scheduling, progress claims, variations, selections, documents, safety and the field app share one data model, so an estimate line becomes a budget line, a purchase order, a committed cost and then a coded supplier invoice without being entered twice.

Oryn™ is the intelligence layer inside those modules rather than an assistant beside them. It reads supplier invoices and codes them to the job in accounts payable, measures quantities off the drawings in takeoff using deterministic computer vision rather than a language model interpreting a plan, drafts the client note on a progress claim from work actually done, and flags cost drift at 2, 5 and 10 per cent in cost control. The Australian specifics are built in rather than configured, stage-based claiming, GST carried through to the ledger, and a two-way Xero sync with tracking categories.

What we do not claim. Oryn never commits anything touching money or a contract on its own, every value it extracts cites the document and page it came from and waits for a person to confirm it, and the financial figures, the cash flow forecast and the variance thresholds are deterministic calculations rather than model output. VIABUILD does not do payroll, it does not assess your position under any state’s legislation, and it does not improve an estimate that was wrong at tender. The audience page is VIABUILD for residential builders, and the comparisons set it against specific alternatives.

09 / FAQ

Common questions.

Construction management software is the system a building business runs its jobs in, as distinct from the system it keeps its accounts in. In residential building it usually covers six areas. Pricing the job, through takeoff and estimating. Turning the price into commitments, through budgets, trade packages and purchase orders. Running the programme, through scheduling. Controlling cost, by comparing budget against committed against actual while the job is live. Getting paid, through progress claims, variations and retention. And holding the record, the drawings, contracts, diaries, photos and safety documents that prove what happened. Products differ enormously in how many of those six they cover and how well the covered ones connect to each other, which is the real basis for comparison rather than the feature count.

Five things, and they are structural rather than cosmetic. Progress claiming against contract build stages rather than an American pay application against a schedule of values. GST calculated and carried consistently from the claim to the ledger so the BAS reconciles. An integration with Xero or MYOB, because that is where an Australian builder’s accountant works. Awareness that security of payment legislation is state by state, with different response windows, rather than a single national regime. And a data structure that suits domestic building contracts, including provisional sums, prime cost items and client selections against allowances. A well-built overseas product can be adapted to some of this. The parts that cannot be adapted are the ones worth testing hardest, and the claiming workflow is usually the first to break.

It depends on where your cost is going, and the honest answer is that both arrangements work and both fail in predictable ways. Point tools win on depth. A dedicated estimating package will out-estimate the estimating module of a suite, and a dedicated scheduler will out-schedule the schedule inside a management platform. Suites win on the seams. The cost of point tools is not the subscriptions, it is the re-keying between them and the fact that every number exists in several versions with no rule about which is right. The practical test is to count your seams. If you have three tools and one person moves data between them for six hours a week, that is a suite-sized problem whatever the feature comparison says. If you have one exceptional estimating tool and everything else is genuinely fine, changing it to gain integration is a poor trade.

Published pricing in this market usually sits somewhere between a few hundred and a few thousand dollars a month, and the spread is wide because the pricing models are not comparable. Per user pricing suits a small office with many jobs. Per job or per active project pricing suits a business with few staff and few concurrent builds, and gets expensive quickly for a volume builder. What the subscription figure leaves out is the part that actually decides the total, implementation time, data migration, training, and the administrative labour the system needs to stay current. The most reliable way to compare is to price your real shape, then add the hours per week your team will spend keeping the system fed, because that number is usually larger than the licence and it is the one that varies most between products.

Not necessarily, and it is worth being honest about the threshold. A builder running one or two jobs, where the same person prices, orders, supervises and claims, genuinely can hold the business in a spreadsheet and a phone. What breaks that arrangement is rarely complexity. It is concurrency and delegation. The moment there are more live jobs than one person can hold in their head, or the moment someone other than the owner has to know where a job sits, the spreadsheet stops being a record and becomes a bottleneck. The other trigger is delay. If you consistently learn about a cost problem after the money is spent, that is a systems failure rather than a discipline failure, and no amount of trying harder fixes it.

Four limits worth naming before you buy. It cannot fix a bad estimate, and it will report accurately and early that a job priced badly is losing money, which is useful but is not profit. It cannot capture what nobody enters, so a platform with excellent committed cost tracking and a team that still orders by text message produces the same picture as a spreadsheet. It cannot supply compliance, and any product implying it manages your security of payment position or your warranty obligations is overclaiming. And it cannot make a decision. Knowing a job will finish four per cent over is the start of a conversation about scope, a variation or a supplier, and the software has no view on which is right. The value is earlier information and less re-keying, which is worth a great deal, and it is not the same as the software running the business.

Two ways, and the first matters more. VIABUILD is built as one operating system on a single data model rather than a set of modules joined by integrations, so an estimate line becomes a budget line, a purchase order, a committed cost and then a coded invoice without being re-entered. That is the difference between a suite and a collection. The second is Oryn, the intelligence layer inside every module. Oryn reads supplier invoices and codes them to the job, measures takeoff off the plans with deterministic computer vision rather than a language model guessing, drafts claim notes from work actually done, and flags cost variance the moment a line crosses a threshold. What Oryn never does is commit anything that touches money or a contract on its own. Every value it produces cites the document and page it came from and waits for a person to confirm it. The comparison pages set VIABUILD against specific alternatives if you are shortlisting.

10 / Keep reading

Keep reading before you shortlist

The selection method, the cost of the stack you have now, the Australian financial context, and the other category guides.

One system, or one more integration.

VIABUILD runs estimating, takeoff, procurement, scheduling, cost control and progress claims on a single data model, with Oryn reading the invoices, measuring the plans and flagging the drift. Built for Australian residential contracting, synced to Xero.