From Disconnected Spreadsheets to One System of Record: Building a Multi-Branch ERP

When a growing organisation runs HR in one spreadsheet, accounting in another and sales at the till in a third system, nobody has the full picture. For an organisation operating across multiple branches and business units, we built a unified back-office platform that combines HR and payroll, accounting, and point of sale with inventory. The headline outcome was simple to state: disconnected spreadsheets were replaced by a single operational system of record spanning HR, finance and retail.

This post covers what made that work and what we would tell any business considering the same move.

Why one system of record matters most

It is tempting to evaluate an ERP module by module: is the payroll good, is the inventory good. Those matter, but the bigger change is structural. When HR, finance and retail share one database:

• A sale at a branch till and the stock it consumes are the same event, not two entries in two places.
• Payroll draws on the same attendance and leave records that managers approve.
• Branch performance can be compared on the same definitions everywhere.

Spreadsheets cannot do this because each one is its own source of truth. Reconciling them becomes a job in itself, and errors hide in the gaps between files.

What the platform covers

HR and payroll

Attendance, leave, payroll and end-of-service calculations are automated. These are exactly the calculations that go wrong in spreadsheets: formulas copied incorrectly, a rule applied to one branch but not another, an end-of-service amount worked out by hand from incomplete history.

Accounting

A multi-branch chart of accounts and ledgers means each branch has its own books while the organisation still sees the whole. Designing branches into the accounting structure from the start is what makes consolidated reporting possible without manual merging.

Point of sale and inventory

Integrated point of sale and inventory tie retail activity directly into the same system. What is sold is what leaves stock, and both flow into the same financial picture.

Branches belong in the data model

The most important design decision in a multi-branch system is where the branch lives. If the software is built for one location and branches are added later as a label or filter, every report, permission and calculation has to be retrofitted.

Here, branches and business units are part of the structure from the start. Accounts, staff, stock and sales all belong to a branch, which is what allows the organisation to run each branch independently and still see everything together.

Access control is a feature

In a multi-branch organisation, who can see what is not a detail. A branch manager should not see another branch's payroll. A cashier should not open the ledgers. Head office needs everything.

The platform has fine-grained role-based access across branches and tenants. That is what makes it safe to put everyone on one system. When the groups using a back office do very different jobs, separate interfaces can help too, as we describe in two admin panels, not one.

Choosing the tools

The platform is built on Laravel, with Laravel Nova for the administrative interface and MySQL for data. Nova provides a consistent, capable admin interface quickly, which let the effort go into business rules rather than hand-building every back-office screen.

If you are considering an ERP

• Start from the decisions your spreadsheets currently make badly, not from a module list.
• Design branches or locations into the model on day one.
• Treat access control as a requirement from the first conversation.
• Automate the calculations with the highest cost of error first.
• Measure success by how much reconciliation work disappears.

The anonymised project write-up is in our work library. Replacing spreadsheets with systems built around how a business actually runs is the centre of our business automation service. For a much smaller version of the same problem, see why partial payments break spreadsheets.