Procurement · One module of the operating system
Raise the order off the budget.
Not off a spreadsheet.
Purchase orders generated straight from the locked job budget, grouped by cost code, previewed by the same code that creates them. Each order line carries a link back to the budget line and the estimate line behind it, and when supplier invoices are recorded, the order’s invoiced and remaining amounts are recalculated from the sum of those invoices rather than adjusted on a running total. Procurement is one module of the construction operating system, so the number you priced is the number the order commits.
The Founding Builders Programme · Onboarding in small cohorts
01 / What it does
What this feature does
Purchase orders is the module in VIABUILD that turns a job budget into recorded commitments. When an estimate is locked into a budget, orders can be drafted directly from the budget lines, grouped by cost code, so a trade or supply package becomes an order without anyone re-typing scope, quantities or rates into a separate document. The discipline itself, what a good order contains and why the timing of it decides everything, is covered in the purchase orders reference. This page is about the machinery underneath it.
Two design decisions matter more than the rest. The first is traceability: every purchase order line holds a link back to the budget line and the estimate line it came from, so a cost on an order can be followed back to the number that was priced. The second is how the money on an order is calculated. Invoiced and remaining amounts are recomputed from the invoices themselves each time one is recorded, not incremented on a stored figure, which is the difference between a balance that can be trusted and one that has to be checked.
Because the module sits inside one operating system, an order raised here is the same order that cost tracking reads as committed cost, that accounts payable matches an invoice against, and that pushes to your ledger through the Xero integration once the resulting bill is approved.
02 / Why it matters
Why builders need it
Orders raised outside the budget
An order written in a spreadsheet or typed into an email has no link to the budget line that priced it. The commitment is real, but the job cannot see it, so committed cost becomes an estimate of an estimate.
Committed cost is the earliest honest number
Invoices arrive weeks after the money is promised. Recorded orders make committed cost a real figure months before the ledger agrees, and that gap is the only window where a job can still be steered.
Running totals drift
A balance kept by adding and subtracting drifts the moment an invoice is edited, deleted, or written by two parts of a system at once. Drifted purchase order balances are one of the most common quiet failures in construction admin.
Cost codes turn orders into a position
Orders grouped by cost code roll up into a committed position you can read against the budget. Ungrouped orders are a list of documents, not a picture of where the job is heading.
The programme moves and the orders do not
Frame slips two weeks, the truss delivery does not, and materials land on a site that cannot take them. The date on the order needs to hear about the change in the schedule.
Matching without a record settles nothing
If an invoice was matched to an order but nobody recorded how close the match was, why it matched, or who accepted it, the decision cannot be reviewed later. It has to be made again from scratch.
03 / The VIABUILD way
How VIABUILD handles it
Generated from the locked budget, then kept honest by recomputation.
The sequence starts at the budget. An estimate is locked into the job budget, and that lock is deliberate: it fixes the baseline the job is measured against, and changing it afterwards runs through an unlock request and an audit log rather than a quiet edit. From that fixed baseline, orders are drafted off the budget lines and grouped by cost code. Before anything is committed, you see a preview of exactly what will be created, and the preview is produced by the same code that does the creating, so it is the real result rather than an approximation of it. Generating orders is also the point at which the system checks the committed position against the budget for those cost codes.
Each created order line keeps its link to the budget line and the estimate line behind it. Orders go out to suppliers as branded PDFs by email. When a supplier invoice is later recorded against an order, the order’s invoiced total and remaining balance are recalculated by the database from the sum of the actual invoices attached to it. That is the part worth pausing on. Nothing is added to a stored running total, so there is no arithmetic to fall out of step when an invoice is amended or removed, and the figure on the order cannot silently disagree with the invoices that produced it. The balance is not a number the system remembers; it is a number the system derives.
Two more mechanisms keep orders aligned with reality. A schedule task can be linked to the order that delivers it, and when that task moves, the system suggests updating the order’s expected date, which you apply with one click. It never rewrites a date on a document a supplier has already seen, and received, closed and cancelled orders are never flagged. Invoice matching records a confidence score, the reasons behind the match, the variance in both dollars and percent, and who matched it and when, so the decision stays reviewable. Approved supplier bills push to Xero with tracking categories so the cost lands against the right job, and if someone edits a pushed bill inside Xero, the difference is detected and surfaced as a warning rather than quietly overwritten.
- Orders drafted off locked budget lines, grouped by cost code
- Preview generated by the same code that creates the orders
- Every order line linked to its budget and estimate line
- Invoiced and remaining amounts recomputed from the invoices
- Schedule-linked delivery dates suggested, applied by you
- Matching records confidence, reasons, variance and who accepted it
- Branded PDF orders sent by email
- Approved bills push to Xero with tracking categories
04 / The workflow
How it runs, step by step
- 01
Lock the estimate into the budget
The won estimate is pushed once into the job budget and the baseline is fixed. Changes after that run through an unlock request and an audit log, so the number orders are raised against does not move without a record.
- 02
Draft orders off the budget lines
Orders are generated from the budget, grouped by cost code, so each supply or trade package becomes an order carrying the scope and value that were priced.
- 03
Preview before anything is committed
You see exactly what will be created before it exists. The preview runs through the same code that performs the creation, so it shows the real outcome rather than a rehearsal of it.
- 04
Send it as a branded PDF
The order goes to the supplier by email as a branded PDF, which becomes the document both sides check deliveries and invoices against.
- 05
Keep the delivery date in step with the programme
Where a schedule task is linked to its order, moving the task prompts a suggestion to update the order’s expected date. You apply it with one click. Orders already received, closed or cancelled are left alone.
- 06
Match the supplier invoice to the order
The invoice is held against its order, with a confidence score, the reasons for the match, the variance in dollars and percent, and a record of who matched it and when.
- 07
The remaining balance recalculates from source
Recording the invoice triggers a recalculation of the order’s invoiced and remaining amounts from the sum of the invoices attached to it, so the balance is derived from the evidence rather than carried forward.
- 08
Approved bills land in your ledger
Approved supplier bills push to Xero with tracking categories so cost sits against the right job, and an edit made to a pushed bill inside Xero is surfaced as a warning rather than overwritten.
05 / FAQ
Common questions.
Once an estimate has been locked into the job budget, orders are drafted from the budget lines and grouped by cost code, so a supply or trade package becomes an order without the scope and values being re-typed. You review a preview of exactly what will be created before anything is committed, and that preview is generated by the same code that performs the creation, so what you approve is what you get. Each created order line keeps a link back to the budget line and the estimate line it came from.
The balance is recomputed rather than remembered. When an invoice is recorded against an order, the order’s invoiced and remaining amounts are recalculated by the database from the sum of the actual invoices attached to it, instead of being added to a stored running total. This matters because a running total only stays correct while every single write to it is correct. Edit an invoice, delete one, or have two parts of a system update the same figure, and a stored total quietly goes wrong with nothing to indicate it has. A figure derived from the invoices cannot disagree with them, because there is no separate number to disagree.
No, and that is deliberate. The estimate is pushed into the budget once, at the point of locking, and from then on the budget is a fixed baseline rather than a live mirror of the estimate. A baseline that keeps moving cannot be measured against, and orders raised against a shifting number tell you nothing about variance. Changes to a locked budget go through an unlock request and are recorded in an audit log, so the budget can still change when it genuinely should, with a record of who changed it and why.
Where a schedule task has been linked to the order that delivers it, moving the task causes the system to suggest updating the order’s expected date, which you apply with one click. It suggests rather than acts, because the order is a document a supplier has already received, and silently changing a date on a document someone else is working from creates a disagreement neither party can see. Orders that have been received, closed or cancelled are never flagged.
An invoice is matched to its order with the working recorded alongside the result: a confidence score for the match, the reasons the match was made, the variance between the invoice and the order in both dollars and percent, and who accepted the match and when. That record is what makes the decision reviewable months later. A match with no reasoning attached has to be re-derived from scratch every time somebody questions it.
No. Purchase orders are generated from budget lines that a person priced and locked, previewed by that person before creation, and sent by that person. Coding comes from the cost code on the budget line, not from a model’s guess, and no order is approved automatically. Intelligence in this module is applied to the things that genuinely benefit from it, reading supplier invoices in accounts payable and proposing a date change when the programme moves, and every one of those proposals is confirmed by a human before it takes effect.
06 / Keep reading
Related features & guides
Commit off the budget, and let the order do the checking.
Start with 7 days free, the full operating system, real data. $199 for your first month, then $555/mo. Lock a budget on a real job, generate the orders by cost code, and watch each invoice correct the order’s remaining balance from the invoices behind it.