Franchise and multi-entity · Software category
Franchise and multi-entity builder software,
and why three structures get sold as one.
A franchise network, a group of your own companies, and three branches under one ABN look similar in a demo. They are not the same problem. This page covers what the software has to do in each case, what to ask a provider, the honest limits, and how VIABUILD handles the two shapes it actually has.
01 / The direct answer
What franchise and multi-entity builder software has to do
Franchise and multi-entity builder software is construction software that can tell one legal entity from another, and can put the right jobs, claims and bills in the right company. That sounds like a reporting feature. It is a structure feature. The moment two companies share a login, a supplier file or a Xero connection they should not share, you no longer have a group. You have one set of books with extra names on the jobs.
Two shapes need this, and they need it for different reasons. A franchise network is a set of separate companies under one brand. Head office sets the standard and reads the network. A developer builder who runs several of their own companies needs one team to switch between those companies without mixing the files. Both get sold as “multi-entity”. Only one of them is a network.
A third shape gets bundled in and should not be. Branches, offices or divisions inside one company are a reporting split, not a second set of books. If that is your structure, the questions on this page will save you a shortlist that cannot answer them. Construction management software in Australia covers the single-entity buying decision. This page is the group decision.
02 / The distinction
Three structures that get one product demo
The demo looks the same until you ask which company a bill posts to. Start here, before the feature list.
A franchise network
Each franchisee is its own company. Head office sits above the network, sets the standard, and reads across locations. The software problem is consistency without erasing local pricing: the same designs and inclusions, priced for each market, with head office able to see margin, time and compliance across the group.
A multi-entity group
One team runs several of its own companies. Each company keeps its own jobs, claims and accounts file. The software problem is switching without mixing: the same people, a role in each entity, and a hard wall so one company’s bills never appear inside another.
Branches under one company
Three offices, one ABN, one set of books. Builders often ask for this as multi-entity. It is not. It is a reporting split inside a single organisation: by office, region or business unit. That shape needs a different product answer, and it is the one most platforms quietly fail to say they do not have.
The operator tell is simple. If the director cannot say, without looking it up, which company owns the job on site this week, the software will not fix the structure. It will reproduce the confusion at higher resolution. Settle the structure first. Then look at modules.
03 / Why it fails
The stack that works for one office fails at the fifth
A single-entity builder can survive a messy stack for a long time. The owner knows which spreadsheet is true, the bookkeeper knows which Xero file to open, and the cost of reconciling it is one person’s evening. That arrangement does not survive a network.
Each extra location multiplies the same admin: a different estimating file, a different way of coding invoices, a different set of inclusions, a different story about margin. Head office then rebuilds a group picture from exports that were never designed to be added together. The rebuild is always a fortnight old, and it is always someone’s Friday. That is the same seam problem stack sprawl creates inside one company, except the seams now sit between companies as well as between modules.
The other failure is quieter. A group that holds each project in its own company, then runs the companies from one inbox and one Xero file “for convenience”, discovers the cost at BAS time or when a claim is raised in the wrong entity. The software did what it was asked. The structure was never made explicit. Multi-entity software exists to make that mix-up hard, not to offer a branch dropdown that looks like a fix.
04 / Before you buy
Six things to look for
The first three decide whether the books stay honest. The last three decide whether head office can run the network without a second system.
Name the legal entity the job belongs to
Every live job, claim and supplier bill has to sit in one company. Ask what happens if someone is logged into the wrong entity when they raise an order. A system that only tags a job with a branch name is still one set of books wearing a label.
One login, a role in each company
The same estimator or accounts person should not need a new email for every entity. Ask how a role is set per company, and whether switching entities changes which company’s data is on screen. If it cannot do that, the group will keep a spreadsheet of who can see what.
Accounts stay per company
Each entity that has its own Xero file needs its own connection. Jobs, bills and claims have to post to the right company, and nothing financial should be merged between them. Ask to see two companies side by side, then switch. The test is that you cannot see the other file.
A standard the network can push
For a franchise, the value is a central price book, standard inclusions and group supply agreements that head office maintains once. Ask what is pushed, what a franchisee can override for local rates, and what happens to a quote already sent when the network rate moves.
A view across the network that is not a consolidated P&L
Head office needs to compare locations on the same measures. That is benchmarking, not a merged profit and loss. Ask which figures are computed from the jobs themselves, whether you can filter by territory, and whether a location can be anonymised when the board looks at the set.
A launch path for the next location
A new franchisee or a new company in the group should start from a template, not from a blank file. Ask what is cloned (cost codes, price book, assemblies, supply agreements), who configures local pricing, and how long the last launch actually took, not the brochure number.
05 / The conversation
Questions worth asking a provider
Six questions with specific answers. The first separates a real entity switch from a branch label. The last one tells you where the workarounds will be.
- 01
Show me two companies, then switch
Not a slide. Two live entities, a user who belongs to both, and the moment of the switch. You should see a different job list, a different Xero connection and a different role. If the demonstration stays inside one company and talks about “sites” or “offices”, you are being shown a label, not a structure.
- 02
What can head office push, and what stays local
For a franchise: the price book, standard inclusions, designs and group supply agreements. Ask which of those are live today, which are a later stage, and what a franchisee is allowed to change for their market. A promise that “the network shares everything” is usually a future slide.
- 03
What do you measure across locations
Ask for the actual list, not “dashboards”. Average gross margin, budget utilisation, build time, invoice processing time, build cost per square metre, open defects and open safety actions are the kind of measures that come from the jobs. A consolidated multi-entity profit and loss is a different product. If they offer both, ask to see both.
- 04
How does a new franchisee or company get onto the system
Walk the last launch. Who cloned the template, who set local rates, who trained the team, and how long until they priced a real job. Then ask what happens when the incoming location is still on Databuild, spreadsheets, or a mix. Mixed stacks are the usual starting point, not the exception.
- 05
What sits in each Xero file, and what never crosses
Bills, claims, contacts and tracking categories should post to the company that owns the job. Switching entities should change the file you are in. Ask what, if anything, is shared at the group layer today, and write down the answer, because “shared catalogue next” is not the same as “shared catalogue now”.
- 06
What do you not do for this structure
The fastest read in the category. Internal divisions inside one company, a consolidated group P&L, payroll, and a catalogue shared across a developer group are the edges that decide a shortlist. A provider who names them is telling you where the workarounds will be.
06 / Honest limits
What this category of software cannot pretend
It cannot turn three branches of one company into three companies. If the legal structure is one ABN, the software is one organisation. Asking a vendor to “just add offices” is asking for a reporting dimension most construction platforms do not have, including VIABUILD. That is a structure conversation with your accountant, not a settings conversation with a salesperson.
It cannot produce a consolidated group profit and loss from several entities unless that product actually builds one. Benchmarking across a franchise network (margin, time, cost per square metre, defects, safety) is a comparison. A consolidated profit and loss is a merge. They look similar on a slide. They are not the same report, and treating them as the same report is how a board gets a number nobody can reconcile to the files.
And it cannot share what has not been built to share. A central price book pushed to franchisees is one capability. A developer group sharing one catalogue, one cost-code list and one set of templates across its own companies is another. Ask which of those is live. A roadmap slide is useful context. It is not a feature you can run a network on this month.
07 / How VIABUILD does it
Two shapes, two plans, no invented third
VIABUILD is the Construction Operating System for residential builders. For groups it has two answers, and they are not interchangeable.
Franchise networks run as a network of organisations. Each franchisee is its own account. Head office sees across them from a franchisor command centre: live WIP, sales and margin, with variance alerts. Head office pushes a central price book and standard inclusions, holds a shared design library, and keeps a group supply agreement register with expiry tracking so franchisees see negotiated deals from day one. Franchisees price for their local market. They can be grouped into offices and regions. Benchmarking covers 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. Build time and cost per square metre can be blank until there is source data on the jobs. Compliance reporting exports to Excel. Each location has its own accounts payable inbox; Oryn reads, matches and codes invoices there. Network pricing is quoted.
Developer builders who run several of their own companies use the Developer plan. Each entity keeps its own jobs, claims and Xero file. The team switches between entities from one login, with a role set in each. Switching changes which company you are working in. It never shows one company’s data inside another. Each entity runs the same operating system as the Business plan: estimating, purchase orders, scheduling, cost tracking, selections, claims, variations, ViaSite and site safety. Sharing one catalogue, cost codes and templates across the group is the next stage of the rollout. It is not live yet. Today each entity can import the same price lists and cost codes.
What we do not claim. No offices or divisions inside a single organisation. No consolidated multi-entity profit and loss. No payroll, and no labour hours costed to jobs from timesheets. Enterprise builders who are one large company, rather than a network or a group of companies, want the enterprise command centre on one organisation: live portfolio WIP and margin, PM and supplier analytics, and construction roles. That is a different page because it is a different structure.
08 / The plans
Which plan matches the structure
If you are one residential building company, the standard plan is seven days free, then $555 a month including GST. That is the published Business plan. It is the wrong plan the moment you need a second legal entity on the same login.
If you already run several of your own companies with one team, the Developer plan is A$950 a month inclusive of GST, with two entities and three users included. Each extra entity is A$350 a month. Each extra user is A$65 a month. It is set up with our team after a demo, not through the self-serve signup. The published figures and the current sharing limits are on the Developer plan page and on pricing.
If you are a franchise network, pricing is quoted. The partnership is scoped around the command centre, the network price book, how franchisees are set up and the number of franchisees. Book that conversation from the franchise page. Coming off Databuild, spreadsheets or a mix is the usual start; migration is how a team, not just a login, comes across.
09 / FAQ
Common questions.
It is construction software shaped around a network of separate companies under one brand, not around a single office with several jobs. Each franchisee runs estimating, procurement, scheduling, claims and cost control as its own organisation. Head office sets a standard (price book, inclusions, group supply agreements) and reads the network from a command centre: live WIP and margin, plus benchmarking on the same measures across locations. The phrase construction software for franchise networks describes the same category.
It is software for a builder who holds more than one company and needs one team to work in all of them without mixing the books. Each entity keeps its own jobs, claims and Xero file. A user signs in once, holds a role in each entity they belong to, and switching entities changes which company is on screen. It is not the same as tagging jobs with a branch name inside one organisation, and it is not a consolidated group profit and loss.
No. There is no office, division, region or business unit inside a single VIABUILD organisation, and there is no consolidated multi-entity profit and loss. If three branches sit under one ABN, they share one job list and one set of reports. What is built is the franchise model, where each location is its own organisation and head office sits above them, and the Developer plan, where one team switches between several of its own companies. If your structure is branches under one company, raise it in the demo before you shortlist.
Head office holds a central price book and standard inclusions and pushes them to franchisees, with a shared design library and a group supply agreement register that carries expiry dates. Each franchisee prices for their local market. Franchisees can be grouped into offices and regions, and head office can drill into any one of them. Benchmarking runs 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. Build time and cost per square metre can be blank until there is source data on the jobs.
The Developer plan is A$950 a month inclusive of GST, with two entities and three users included. Each extra entity is A$350 a month. Each extra user is A$65 a month. Each entity is its own VIABUILD account with its own Xero connection, so jobs, bills and claims post to the right company. The team switches between entities from one login, with a role set in each. It is rolling out with the first group customers and is set up after a demo, not through the self-serve Business signup. Sharing one catalogue, cost codes and templates across the group is the next stage of that rollout. It is not live yet. Today each entity can import the same price lists and cost codes so the companies start from the same standard.
The standard plan is seven days free, then $555 a month including GST. That is the published Business plan for a single-entity residential builder. Franchise network pricing is quoted, because the shape of those engagements varies. The Developer plan above is the published figure for a builder who already runs several companies with one team.
Yes. Mixed stacks are the usual starting point. The network standard is set once (cost codes, price book, templates and supply agreements), each franchisee’s suppliers and pricing come across by import, and franchisees launch from the onboarding template. Each location can run the old system side by side until the team trusts VIABUILD on live jobs. The same side-by-side path is how a larger builder migrates a team: roles first, a pilot set of jobs, then the rest of the book once those jobs reconcile.
A new franchisee is set up in one step from the network template. The operations team clones it, configures local pricing and trains the franchisee. That is the setup, not a promise that every historical job is already in the system.
Four limits, and they are the ones that decide a shortlist. No offices or divisions inside one organisation. No consolidated multi-entity profit and loss. No shared group catalogue on the Developer plan yet, only the same lists imported into each entity. And no payroll, and no labour hours costed to jobs from timesheets. Those are gaps to weigh, not footnotes.
10 / Keep reading
Keep reading on groups, plans and the buying decision
The Developer plan, the franchise and enterprise landings, the category guides, and the modules a network actually runs.
Bring the structure, not a feature list.
Book a demo and say how the companies are set up: a franchise network, several of your own entities, or branches under one ABN. We will say exactly which of those VIABUILD can run today.