Business softwareCustom softwareIntegrationSMEs
Multi-site back-office software for growing networks
6 min read
Multi-site back-office software is one management application shared by every branch, store or depot in a network: each location runs its stock, schedules and operations with its own permissions, and head office sees consolidated figures without waiting for month-end spreadsheets. It starts paying off once a network grows past two or three sites and nobody has a reliable view of the whole anymore.
This guide covers what such a tool must do, the technical point that leaves no room for error (per-site permissions), and how to decide between an off-the-shelf product and custom software.
Signs your network has outgrown its tools
A growing network often keeps the tools of its first location and copies them every time it opens a new one. Each branch has its own stock spreadsheet, a schedule on a whiteboard or a shared calendar, and head office rebuilds the figures by hand. The symptoms are easy to recognise:
- group figures arrive a week late, because someone has to collect and merge every site's files;
- two branches apply different rules, because each copy of the spreadsheet has drifted on its own;
- stock transfers between sites go through phone calls or emails, and nobody knows exactly what is in transit;
- opening a new location takes days of setup, even though the work is the same everywhere;
- closing the books ties up head office for days, splitting costs and revenue by site.
If several of these sound familiar, the issue is no longer one branch's tool, it is the lack of a network tool. Our guide to replacing Excel with a custom application covers that move for a single site; multi-site adds permissions and consolidation on top.
What a multi-site back office does
The principle is simple: one database, one application, but a different view depending on who logs in and for which location. It is one of the example projects on our home page, a multi-site back office handling stock, schedules and permissions by site, group consolidation and accounting exports.
| Function | At each site | At head office |
|---|---|---|
| Stock | Receipts, issues, counts, transfers | Total stock, alerts, valuation |
| Scheduling | Teams, bookings, absences | Workload by site, cover between sites |
| Permissions | Access limited to own site | Roles, assigned sites, new openings |
| Figures | Site dashboard | Consolidation and site comparison |
| Accounting | Entries split by site | Exports by site and by period |
Two design decisions shape everything else. The first is what is shared and what belongs to each site. The product catalogue, price lists and document templates are usually shared; opening hours, teams and sometimes local prices vary. The second is what moves between sites. A stock transfer, an employee covering another branch or a customer served by two locations must be designed in from the start, or they will end up as workarounds.
Per-site permissions: no room for error
In a multi-site tool, "who can see what" is not an interface detail. A branch manager must see only their branch, a regional manager their sites, head office everything; an accountant may read everything and change nothing. Hiding a button is not enough: every request sent to the server must be checked, otherwise editing an address in the browser is enough to read another site's data.
This is not a theoretical risk. In the 2025 edition of its Top 10 web application security risks, the OWASP Foundation ranks broken access control first and reports that 100% of the applications tested in its data showed some form of it. For a network, the answer is a permission model written down in full (roles, assigned sites, exceptions), enforced on the server and covered by automated tests. Our article on business application security essentials covers the rest.
Group reporting and accounting exports
Consolidation is what makes the business case for leadership: revenue, margin, stock and activity by location, comparable at a glance, with no intermediate files. It is only reliable if the same calculation rules apply everywhere, which a single tool guarantees by design.
On the accounting side, the back office does not replace your accounting software; it feeds it. Entries or exports are split by location (cost centre, branch, analytical code) the way your accountant expects, and the split is decided during design, not at the first close. Regulation is pushing the same way in several countries. France, for example, has required every VAT-registered business to be able to receive electronic invoices since 1 September 2026, with small businesses obliged to issue them from 1 September 2027. A back office that issues or receives invoices has to exchange data cleanly with whatever invoicing platform the company uses, and the same holds wherever e-invoicing rules apply to you.
Off-the-shelf or custom?
Many trades already have multi-location software: point of sale and stock for retail, branch management for rental or staffing firms. It is often the right answer.
| Situation | Off-the-shelf | Custom |
|---|---|---|
| Standard trade, well covered | Good fit | Rarely justified |
| Rules specific to your network | Workarounds | Good fit |
| Several tools to connect | Depends on connectors | Good fit |
| Cost per user and per site | Grows with the network | Depends on the model |
Custom software earns its place when the way your network operates is a competitive edge (coordination between sites, specific services, pricing rules), when several existing tools must be connected, or when per-site licences become your largest software cost. Our guide to what a custom business application costs explains what drives the budget, and where to host a business application in Europe covers where your network's data should live.
Rolling out location by location
The rollout matters as much as the software. Networks that switch every branch on the same Monday find every problem everywhere at once. What works:
- One pilot location, representative and willing, uses the tool alone for a few weeks; its feedback shapes the tool.
- Data migration per site, at the moment that site switches: stock, customers, useful history. Data nobody needs stays in the old tool, archived.
- Rollout in waves, with one trained go-to person at each site before it goes live.
- A template for new locations: adding a branch should be a matter of configuration, not development.
On budget, a network tool can be paid for in two ways: a fixed-price build followed by maintenance, or an all-inclusive monthly subscription. Our comparison of subscription versus upfront build looks at both over three years on the same scope.
Where to start
Pick two or three representative locations and write down, for each, how stock, schedules and reporting work today. That is enough for a first scoping. At LPR Studio, we turn it into a free visual prototype presented in a video call within 5 working days: one site's view, head office's view and the permission model, on screen, before you commit to anything. The three ways to pay for the build are on our offers page.