Same brand, five sets of books

The brand is the only thing five branches genuinely share, and when the numbers matter they stop sharing even that. A group stays controllable when the item, the customer, the account and the calendar are defined once at the centre, and everything local — price, stock, staff, discount — sits on top as a named, limited permission. Built the other way round, five systems reconciled at month end, the consolidation is a negotiation, not a report.

What has to be defined once, at the centre?

Four things: the item, the customer, the account and the calendar.

The item is one code, one name, one unit, one description per product. Two branches selling "the same" thing under two codes never appear together in a report, and no clever reporting fixes a factory that produced two items.

The customer is subtler. A walk-in belongs to the branch, but a customer who buys at branch two and returns at branch four is a shared customer, and it has to be the same account or the return becomes a discount the second branch gives away.

The account is which legal entity owns the money. This is the part small groups skip, and the reason a transfer between branches ends up booked as a sale by somebody.

The calendar is one close everywhere: five close dates produce five figures that answer no question.

Why does the catalogue belong to the centre and the price to the branch?

Because the catalogue is what makes the brand one thing, and price is what makes a branch viable in its own street.

A central catalogue with a local price is one object carrying a per-branch attribute, and it is cheap to keep: a new product is created once and appears everywhere with its price still to be set. That "still to be set" state is the useful part: it forces a decision at each branch and shows the centre which branches have not made it.

The opposite arrangement — every branch maintaining its own list — produces the two failures that make franchise reporting useless: the same product at three prices with no history of why, and the same product under two codes that never merge.

What does a stock transfer between branches actually move?

Ownership, not only goods, which is why the transfer is the movement most often booked wrong.

Between two shops of one owner it is a location change and nothing else. Between two franchisees it is a sale by one and a purchase by the other, at a price they agree, and the centre records both sides from one document. A group with both kinds needs the type chosen when the transfer is created: the consequence differs and cannot be inferred later.

The goods also have to stop being counted twice while they travel. The van is a location with an owner and a date, and an item leaves the sender's stock when it is loaded rather than when it is received. Otherwise both branches hold it and the group total is overstated by what is in transit.

Who may discount, and how far?

Discounting is the permission most worth naming, because it is the one that quietly destroys a price list.

Three questions decide it: who may go below list (a role, not a job title), by how much (a limit, not a habit), and with what record (a reason code and a name on the line). A discount without a reason code is indistinguishable from a pricing error, and the centre cannot tell a branch that is competing from a branch that is leaking margin.

The limit should be a number the system enforces and a person can override, with the override recorded. Above it, the order waits for approval from someone who is not the person who wants it. That rule removes most drift: a discount stops being a favour at the counter and becomes a decision with a name attached.

What must a consolidated report survive?

Three things it usually fails: branches that close on different dates, transfers booked as sales, and a chart of accounts that differs by branch.

Question	Where the answer has to live	What fails without it
Which item is this?	one central item code	two codes never merge
Who owns the goods in the van?	a transfer with a type and a date	the total counts them twice, or not at all
Was this discount allowed?	a limit plus a reason code	lost margin looks like a pricing error

Give every branch the same account structure and map any local presentation to it once. Reconciling five charts by hand at close is where a group discovers its consolidated figure is an opinion. The W3C's data on the web best practices describe the same discipline for published figures: one definition, stated once, so two readers arrive at the same number.

In what order do you do this?

1. Fix the item list at the centre, and let branches set prices against it with an explicit "no price yet" state.
2. Define the legal entities and which branch belongs to which, before a single transfer is recorded.
3. Give every transfer a type — internal, franchise sale, return — and a date, and make the van a location.
4. Align the period close and the account structure, or accept that consolidation is manual and say so.
5. Write the discount limits by role, with a reason code and an approval above the limit.
6. Build the consolidated view last, from data that already agrees, and check it against one branch's own books before trusting it for the other four.

Where this goes wrong

• The centre owns the catalogue in a spreadsheet. Each branch's system carries a copy, and the copies are updated when somebody remembers.
• Transfers are recorded as sales because that is what the till does, so group revenue is inflated by everything that moved between its own branches.
• Price is set by whoever answers the phone in a branch with no limit, and the centre learns about the margin problem three weeks later.
• Consolidation is a spreadsheet built by one person: nobody else can rebuild it, and it drops a branch that was renamed.
• The fee base is computed from the branch's own report. Whatever the branch reports becomes the fee, and the incentive to report carefully disappears.

What this does not cover

It does not touch the franchise agreement: what the fee is charged on, what a territory means, what happens on termination — a contract question for a lawyer in each market. It assumes the branches run the same software; a group consolidating branches on three different systems has a data problem before it has a reporting problem. And it assumes a handful of branches. At a hundred, the constraints change and the centre needs its own data platform instead of a shared database with a location column.

We build franchise operations where the item, the customer and the account are defined once and each branch holds a bounded permission: catalogue, prices, transfers, discounts, and one consolidated figure that reconciles to a branch's own books.