The design repeats.
So should everything you did to price it.

Yes, and the precision matters when you are comparing products because the phrase price book means two different things in this market. In VIABUILD a price book entry is a whole priced build, not a rate lookup. It is structured exactly like a real estimate with sections, line items, plans, takeoff sessions and measurements, attached to no job. Pushing it onto a new job clones all of it, sections, plans and plan pages, takeoff sessions and their measurements, bill of material items, deductions and graphic measurements, with every internal reference remapped to the copies rather than left pointing at the library, and it lands as a draft estimate that records which entry and which revision it came from. If any part of the copy fails, the partial estimate is removed rather than left half built, so you cannot inherit a design quietly missing a section. The rates it is priced from live in the catalogue, which is the item and assembly database underneath it.

The system tells you rather than waiting for you to check. Every price book line priced from a catalogue item keeps a link to that item, and the price captured on the line is compared against the item current price. That produces a running count of how many entries are affected, carried in the navigation, and a per-entry table listing the specific lines with what they were priced at against what the catalogue now says. Re-pricing does not edit in place. It clones the whole entry to a new revision, re-prices only the lines carrying a catalogue item, leaves anything you priced by hand exactly as you priced it, and marks the previous revision superseded so it stays readable. Worth being precise about the scope: this drift signal watches price books, which is where a stale rate does the most damage because you quote from it repeatedly. It does not watch the estimates already pushed onto live jobs, and that is deliberate, since a quote you have already sent should not change because someone tidied the library afterwards.

One catalogue of items and assemblies for the organisation, so every estimator prices from the same rates rather than from a personal copy. Supplier price lists come in as CSV, spreadsheet or PDF and are matched against what you already hold, and the matcher is built for the way suppliers actually behave, renaming the same product between lists. It normalises construction attributes, dimensions, timber grades, treatments and units, into a canonical form, so a description written three different ways resolves to one item rather than creating three. Decisive matches apply automatically, uncertain ones go to a review queue instead of being guessed, anything close to an existing item is flagged as a possible duplicate rather than created, and the phrasings you confirm are learned so the next list from that supplier matches better. Every price change is written to an append-only history recording the old price, the new price and where the change came from, and those history rows cannot be edited or deleted.

No, and it is better to be straight about that than to let you find out later. Claims in VIABUILD are raised per job. There is no bulk or batch claim run across the portfolio, and the only bulk action in the product is sending purchase orders. What does scale is the work behind each claim rather than the clicking. The claim is drafted from the job, so the stages, the contract value and the approved variations already on record are not rebuilt. The claim schedule is your own contract stages at your own percentages rather than a template you have to bend to fit. And a claim tied to a build stage cannot go to the client until that phase tasks are complete, with an explicit early-claim override that records the percentage the phase was actually at when it was approved, which at volume is the difference between a claim schedule and a claim policy.

Three things, all computed from the same records the jobs run on rather than from an imported copy. A cross-job dashboard carrying active job count, total locked budget, total committed on purchase orders actually sent, total actual from approved supplier invoices, and the accounts payable queue, with a per-job margin table underneath. Three prebuilt reports that read across every job: work in progress with contract sum, budget, costs to date, percent complete, earned revenue and over or under claimed; job profitability with committed, actual, forecast cost and forecast margin; and safety compliance with open hazards, incidents, SWMS outstanding and inductions. And a weekly cash flow forecast across the whole organisation rather than job by job, built from claims, schedule phases, invoices and purchase orders with client payment lag and BAS and GST included. All of it exports to CSV, and a saved report can be scheduled daily, weekly or monthly and emailed with the file attached. Every figure is deterministic arithmetic. No model produces a number, which is why none of it is described as AI forecasting.

Franchise networks yes, internal divisions no, and the distinction is worth understanding before you shortlist. There is no concept of an office, division, region or business unit inside a single organisation, so a builder running three branches under one entity cannot split reporting by branch and there is no consolidated multi-entity profit and loss. What is built out properly is the franchise model, where each franchisee is its own organisation and the franchisor sits above the network. That carries a central price book and standard inclusions pushed down to franchisees, a shared design library, a group supply agreement register, franchisee onboarding, compliance, and benchmarking across the network on average gross margin, budget utilisation, build time, invoice processing time, build cost per square metre, open defects per job and open safety actions per job, with a territory filter and an option to anonymise. If your structure is several offices under one company rather than several companies under a brand, raise it early.

No bulk claim run across jobs, as above. No divisions or offices within one organisation. No preset HIA or MBA stage templates to pick from, so your claim stages and percentages are set up per contract, which gives you contracts that match what you actually signed at the cost of setting them up. No retention handling, which matters less on domestic contracts than commercial ones. No contingency mechanism beyond budgeting it as a cost code line. No payroll, and no labour hours costed to jobs from timesheets. And nothing in the numbers is produced by a model. Takeoff measurement is deterministic computer vision over the drawing, pricing is arithmetic over your own rates, and Oryn sits at the point paperwork enters the system, reading plans and supplier invoices, matching them to orders and suggesting cost codes from your own history, citing the document and page every value came from and never committing anything touching money or a contract without a person confirming it.