Catalogue · One module of the operating system
Your rates, your assemblies,
and a matcher that speaks timber.
The catalogue is the cost database underneath every estimate. Items carry a code, a unit, a cost, a cost code and a default supplier. Assemblies turn one measured quantity into a full bill of items using a formula and a wastage allowance per line. And when a supplier sends a new price list, the matcher reads it as construction rather than as text, so “90x45 MGP10 H2 Blue” and “MGP10 90x45 Treated H2” are recognised as the same item.
The Founding Builders Programme · Onboarding in small cohorts
01 / What it does
What this feature does
The catalogue is where your rates live. Every item carries a code, a name, a type, a unit, a cost, the cost code it belongs to, and a default supplier with that supplier’s own code for it. Types cover material, labour, subcontract, equipment, plant hire, consumables and anything else. The reasoning behind keeping a cost database at all, and what separates one that stays useful from one that goes stale, is in the reference on the cost database. This page is about the machinery.
Above the items sit assemblies, which are recipes. An assembly is a unit of work made of catalogue items, and each line in it carries a quantity formula and a wastage percentage, so one measured quantity produces a full set of item quantities rather than a single lump. The idea and where it earns its keep is covered in assemblies and recipes. When a takeoff measurement is linked to an assembly, those formulas are evaluated against the measurement and expanded into priced lines, with the catalogue cost taking precedence over anything stored on the assembly, so the rate you maintain is the rate that gets used.
Two things worth separating early. The catalogue is your rates database. The price book is a different module, a library of whole priced builds you reuse, and it is priced from the catalogue. Different products in this market use the phrase price book for one or the other, which is worth knowing when you are comparing them.
02 / Why it matters
Why builders need it
A rate you retype is a rate you get wrong
Rates kept in a head, an old estimate or a spreadsheet tab are re-entered on every job, and every re-entry is a chance to be out. A rate held once, coded once, is used everywhere without being typed again.
Suppliers rename the same product every year
The item you buy every week arrives on the new price list with the dimensions reordered, the treatment spelled differently and a new code. Matching that by eye across a thousand rows is not a job anyone finishes.
One measurement is never one item
Twelve metres of wall is studs, plates, noggings, fixings and a wastage allowance. Assemblies are what turn a measurement into a bill, and formulas are what stop that bill being a guess.
A cost with no cost code is invisible later
Coding is what makes a cost roll up into a budget, a committed position and a variance. An item that carries its cost code brings the coding with it into every estimate line it lands on.
Price changes with no record are unarguable
When a rate moves you need to know what it was, what it became, where the change came from and who made it. Without that, a costing question a year later has no answer.
Automation that guesses on money is worse than none
A price list importer that quietly matches the wrong item corrupts your rates at scale. The design here refuses to auto-apply anything but a decisive match, and even then not when the unit disagrees.
03 / The VIABUILD way
How VIABUILD handles it
The price list matcher reads construction, not strings. It only acts on a decisive signal, and everything else is ranked for you to settle.
Items reach the catalogue four ways. Typed in one at a time. Bulk uploaded from a spreadsheet, with a preview that shows per-row errors and warnings before anything is written and an update-by-code rule so a re-upload corrects rather than duplicates. Imported from a Buildertrend export, which brings assemblies, items and cost codes together and never overwrites a price you already hold. Or created from a supplier price list, which is the interesting one.
A supplier price list arrives as a spreadsheet. Column names are mapped by synonym, so a list headed price, cost, rate, ex GST or net price is understood without you renaming anything. Then each row is matched against your items by a scoring function that understands the trade. Dimensions are canonicalised, so ninety by forty-five in any order or notation is the same dimension. Lengths in metres and millimetres are reconciled. Grade and treatment tokens like MGP10, F17, H2, LVL and CCA are extracted and compared separately, because getting the grade wrong is a different failure from getting the size wrong. Filler words that carry no meaning are dropped. Units are canonicalised to a common set so each and EA and no. are one unit. What is left is compared as a set of meaningful tokens.
The result is a score plus a classification, and this is where the discipline sits. A row only applies itself when there is a decisive signal, the supplier’s own code, your code, or an exact match once both names are normalised. Even then it will not apply if the unit disagrees, or if the price has moved more than half. Anything below that lands in review with the top candidates ranked and the reasons for each one written out, so you are confirming a judgement rather than making one from scratch. A row that matches nothing can create a new item, but only after a separate duplicate check clears it. Every action is guarded so a row cannot be applied twice, even by two people at once.
Every price change lands in an append-only history against the item, with the old price, the new price, where the change came from, who made it and when. That history cannot be edited or deleted, which is the point of keeping it.
- Items with code, unit, cost, cost code and default supplier
- Assemblies with a formula and a wastage percentage per line
- Takeoff measurements expand assemblies into priced item lines
- Bulk upload with a preview, per-row errors and update by code
- Supplier price lists matched on dimensions, grade, unit and tokens
- Auto-apply only on a decisive signal, everything else to review
- Append-only price history with the source of every change
- Cost codes carry down into estimates, budgets and Xero accounts
04 / The workflow
How it runs, step by step
- 01
Build the item list
Type items in, bulk upload a spreadsheet, or import a Buildertrend export. Each item gets a code, a unit, a cost, a cost code and the supplier you usually buy it from with their code for it.
- 02
Build the assemblies
An assembly is a unit of work made of items. Each line carries a quantity formula against the measured value and a wastage percentage, so the recipe produces real quantities rather than round numbers.
- 03
Measure once and let the recipe expand
A takeoff measurement linked to an assembly evaluates every formula against the measured value and produces priced item lines, taking the current catalogue cost in preference to anything stored on the assembly.
- 04
The cost code travels with the item
Choosing an item on an estimate line sets that line’s cost code from the item, which is what lets the estimate roll up into a budget by cost code when it is locked.
- 05
Upload the supplier’s new price list
Pick the supplier, upload their spreadsheet, and the columns are mapped by synonym. The file itself is archived as a document against the job record, so the source of the rates is always retrievable.
- 06
The matcher does the obvious rows
Rows with a decisive match apply themselves, unless the unit disagrees or the price has moved by more than half, in which case they are handed back to you with the reason.
- 07
You settle the rest
Everything ambiguous is presented with the top candidates ranked and the reasoning behind each. Rows that match nothing can create new items once a duplicate check clears them.
- 08
The history records what changed
Each applied change writes the old price, the new price, the source and the person to an append-only history on the item, so a rate question next year has an answer rather than an argument.
05 / FAQ
Common questions.
The catalogue is your rates database, the items and assemblies you price from. The price book is a separate module holding whole priced builds you reuse, a house type priced once and pushed onto a new job. The catalogue supplies the rates, the price book supplies the shape. Products in this market use the phrase price book for both of those things, which is exactly why it is worth asking any vendor which one they mean before you compare.
An assembly is a unit of work made of catalogue items. Each line in it carries the item, a quantity formula expressed against the measured value, and a wastage percentage. Measure a wall in the takeoff and link it to the wall assembly, and every formula is evaluated against that measurement to produce real quantities for studs, plates, noggings and fixings, priced at the current catalogue cost. Assemblies are one level deep, so an assembly is built from items rather than from other assemblies, which keeps the arithmetic inspectable.
Deterministically, with no language model involved. Each row from the supplier is normalised the way a builder reads it. Dimensions are canonicalised so ninety by forty-five in any order or notation is the same dimension, lengths in metres and millimetres are reconciled, grade and treatment codes such as MGP10, F17, H2 and CCA are pulled out and compared separately, meaningless filler words are dropped and units are reduced to a common set. The remaining tokens are compared as a set, and the score is adjusted up for agreeing dimensions, grade, unit and a sane price, and down for disagreement. A dimension conflict caps the score outright, because a rate matched to the wrong size is a wrong rate no matter how similar the words are. The whole matcher is unit tested and runs without a network call.
Only where there is nothing to ask about. A row applies itself when it carries a decisive signal, the supplier’s own code for the item, your code, or a name that matches exactly once both sides are normalised. Even a decisive match is held back for review if the unit disagrees or if the price has moved by more than half, because both of those are more often a bad match than a real price rise. Everything else lands in review with the top candidates ranked and the reasons written out. New items can be created from unmatched rows, but only after a separate duplicate check clears them, and every action is guarded so the same row cannot be applied twice.
Yes. Every price change writes a row to an append-only history on the item recording the old price, the new price, where the change came from, whether that was a manual edit, a bulk upload or a supplier price list, who made it and when. The history has no update or delete path, so it is a record rather than a working document. That is what lets you answer why a job priced in March costs differently in September.
No, and it is worth being precise about that. The catalogue is a cost database, not a product showroom. Items carry codes, units, costs, cost codes and suppliers, not photographs, brands or variants. Client selections are a separate module with their own options, allowances and client-facing presentation. When Oryn™ drafts selection options for you it looks up matching items in your catalogue and uses them as grounding so the suggestions and the indicative prices reflect what you actually buy, but the option that lands is its own record for you to verify and price, not a live link to a catalogue item.
By mining it, deterministically and overnight, with no model call involved. Oryn builds a private vocabulary for your business by looking at which words appear against which cost codes across your estimates, your catalogue, your takeoff output and your coded invoices. A term only becomes active once it has appeared enough times, is dominated by a single cost code, and has no conflicting evidence. That vocabulary is then used to suggest cost codes on things like supplier quote rows. It only ever suggests. It never writes a record, and everything it learns stays private to your organisation.
Yes. The item list exports to CSV with the codes, names, descriptions, types, units, costs, suppliers and supplier codes, which is the same shape the bulk upload accepts. That matters more than it sounds, because a cost database you cannot export is a cost database you cannot leave, and the ability to leave is one of the questions worth asking every vendor before you commit, which we set out in the software evaluation checklist.
06 / Keep reading
Related features & guides
Upload one supplier price list and watch it sort itself.
Load your rates, build the assemblies you use on every job, then send in the next price list your timber supplier emails you and see how many rows the matcher settles before it asks you anything.