Multi location restaurant accounting: five sites, one comparable P&L
Published on :
August 26, 2026


Nicolas Marchais is co-founder and CEO of Phacet. After seven years at Spendesk, he built Phacet as the agentic layer that orchestrates across ERP, banking and email systems. Reliable, auditable, cross-system, what he calls a Finance Workforce.
Multi location restaurant accounting is the set of structures and controls that lets a restaurant group produce a profit and loss statement per site that can actually be compared with the others, plus one consolidated view of the group. It rests on four decisions: how the sites are structured legally, which chart of accounts they share, which accounts carry the flows between them, and which calendar closes them. Get those four right and the fifth restaurant costs you no extra close time. Get them wrong and every new opening adds a week of reconciliation.
At La Nouvelle Garde, the Paris brasserie group, the supplier inbox alone took two full days per week from one person before automation, and delivery notes were checked against invoices by sampling only. That is not an accounting failure. It is what happens when a structure designed for one restaurant is asked to carry ten.
Key takeaways
- Multi location restaurant accounting only produces comparable sites if the chart of accounts, the close calendar and the cost allocation rules are identical across every location.
- A 4-4-5 calendar produces twelve periods per year, not thirteen; a 13-period calendar produces thirteen four-week periods. Both run 364 days and need a 53rd week every five or six years.
- Flows between restaurants belong in intercompany accounts that eliminate on consolidation, never in the operating expense accounts that feed the site P&L.
- Across the six editorial pages ranking in Google's top 20 for this topic, the terms audit trail, purchase order and 13-period appear zero times, measured by script in August 2026.
- Jinchan, operating two Paris restaurants plus an import business, routes each invoice to the correct entity automatically and reviews five or six items a day instead of thirty.
What multi location restaurant accounting actually has to solve
Single site accounting answers one question: did this restaurant make money last month. Multi site accounting has to answer that question five times over, in a form where the five answers can be laid side by side, and then answer a sixth question about the group as a whole.
That double requirement is what breaks. Consolidation is easy to describe and hard to do, because it depends on decisions taken long before the close: how a manager codes a case of wine, when a site stops counting the month, whether a transfer of stock from Site 2 to Site 4 shows up as a cost in one and nothing in the other.
Three layers sit underneath a comparable P&L, and they have to be built in order. The legal and ledger structure decides what a site even is. The coding and calendar rules decide whether two sites are measuring the same thing. The transaction controls decide whether the numbers entering the ledger are correct in the first place. Skipping to the third layer is the common mistake: a group buys reporting software and discovers it is now consolidating five inconsistent sets of books faster than before.
Why does the P&L stop being comparable at the fifth restaurant?
Because up to four sites, a single controller holds the exceptions in their head. They know Site 3 books its delivery driver under transport and Site 1 books the same cost under food. They correct it mentally when they read the report. At the fifth site that memory stops being reliable, and nobody notices the moment it fails.
The symptom is a food cost percentage that varies by three or four points between sites and cannot be explained operationally. Management assumes a kitchen problem and investigates portioning. The real cause is a coding difference, or a cut-off difference, or a site that received a large delivery on the 30th and booked the invoice on the 3rd.
Marie-Céline Kauff, Head of Finance at The French Bastards, describes the reporting consequence directly after the group went from seven to fourteen shops:
"I need full visibility on expenses for the reporting to be coherent and realistic."
Exhaustiveness comes before comparability, and comparability comes before analysis. A group that analyses variance on an incomplete cost base is measuring its own gaps.
One company with five establishments, or five companies?
This is the first decision and the one most often taken by default, usually by whoever set up the second site. It has direct accounting consequences that are worth naming before an accountant inherits them.
| Decision point | One entity, five establishments | Five entities under a holding |
|---|---|---|
| Statutory accounts | One set for the whole group | One set per entity, plus consolidation |
| Site P&L | Analytical segment or cost centre | Native, each entity has its own |
| Flows between sites | Internal transfer, no invoice | Real invoice, eliminated on consolidation |
| Ring-fencing a bad site | Not possible | Possible, losses stay in the entity |
| Selling one restaurant | Asset sale, heavier | Share sale, cleaner |
| Close workload | Lower, one ledger | Higher, scales with entity count |
Neither structure is right in the abstract. The one entity model is lighter to close and is usually correct for a group of similar sites under one brand with no outside investors per site. The multi entity model costs more to run every month and buys optionality: separate investors per restaurant, clean disposals, risk containment.
What matters for accounting is that the choice is made explicitly. Groups that drift into five entities without deciding to end up paying the multi entity close cost without ever using the multi entity benefits.
Which accounts carry the flows between your restaurants?
Stock moves between sites. Site 2 borrows twenty kilos from Site 4 on a Saturday. Head office pays a group insurance premium and recharges it. A central kitchen supplies three restaurants. These flows are real and they have to land somewhere, and where they land determines whether your site P&L means anything.
The rule is short. A flow between two sites of the same group is not a cost of the group. It is a movement inside it. If it lands in an operating expense account at the receiving site and a revenue account at the supplying site, the group P&L will show a cost and a revenue that never existed outside the walls, and the site margins will both be wrong.
Flows between entities therefore belong in dedicated intercompany accounts, held in balance on both sides, and eliminated at consolidation. Two properties matter more than the account number: reciprocity, meaning the balance at Site 2 mirrors the balance at Site 4 to the cent, and traceability, meaning each movement can be pointed back to a document.
Reciprocity is the check that fails silently. It fails when one side books the transfer and the other forgets, when the two sides use different valuations for the same stock, or when a transfer is recorded in one period at one site and the following period at the other. The consolidated accounts then carry a residual difference that nobody can explain in the fifth month. The intercompany reconciliation agent exists for exactly this: match both sides continuously rather than discover the gap at year end.
Twelve periods or thirteen: choosing a close calendar that makes sites comparable
Calendar months are a bad unit of measure for restaurants. February has four weekends, March sometimes has five. Comparing a site's March against its February, or against another site's March in a different year, means comparing a different number of trading Saturdays. In a business where Friday and Saturday can carry a third of the week's revenue, that is not noise, it is the signal.
Two conventions fix this, and they are routinely confused, including in Google's own AI Overview on this topic, which presents "4-4-5 or 4-week period" as a single option. They are not the same thing.
| Property | Calendar months | 4-4-5 (or 4-5-4) | 13 periods |
|---|---|---|---|
| Periods per year | 12 | 12 | 13 |
| Weeks per period | 4 or 5, variable | 4, 4 then 5 by quarter | 4, always |
| Same weekday count | No | No, within the quarter | Yes |
| Quarters comparable | No | Yes, 13 weeks each | No, 13 does not divide by 4 |
| Aligns with VAT and payroll | Yes | Partly | No |
| Year length | 365 or 366 days | 364 days | 364 days |
A 4-4-5 calendar splits each 13 week quarter into two four week periods and one five week period, which gives twelve periods a year. A 13-period calendar gives thirteen equal four week periods. Both run 364 days, so both need a 53rd week roughly every five or six years. The National Retail Federation, which maintains the 4-5-4 variant, adds that 53rd week when four or more days of January fall into it.
The practical guidance for a five restaurant group: 13 periods gives the cleanest site to site comparison and the most painful reconciliation against payroll and VAT, which stay on calendar months. A 4-4-5 gives comparable quarters and keeps you closer to the statutory calendar. Calendar months are defensible only if every site is compared like for like on a per trading day basis rather than on the raw total.
Whichever you pick, the non-negotiable is that all sites use it. A group where two restaurants close on the last Sunday and three on the last day of the month has no comparable P&L, whatever software it consolidates with.
The inventory count is a comparability decision, not a stock decision
The calendar choice only holds if the inventory count follows it. Food cost is computed as opening inventory plus purchases minus closing inventory, so a site that counts on Sunday evening and a site that counts on Wednesday morning are computing food cost over two different windows. The gap shows up as a margin difference that operations cannot explain and that reverses the following period.
Three rules make counts comparable across a multi-entity group. Every site counts on the same day and at the same point in the service cycle, ideally after close and before the first delivery of the new period. Every site values the same product at the same cost, which means a single vendor price reference for the group rather than each manager using their last invoice. And any stock transferred between sites in the final days of the period is counted once, at the receiving site, with the corresponding intercompany entry posted in the same period on both sides.
The same discipline protects the cash flow view. Purchases booked at delivery date rather than payment date give a group-level payables position that reflects real commitments, which is what makes a rolling cash flow forecast across five sites usable rather than indicative.
How does POS revenue reach the ledger without a journal entry per site?
The revenue side is where multi site accounting silently loses hours. Each site's point of sale produces a daily total that is not a revenue figure: it mixes VAT rates, discounts, tips, gift cards sold and gift cards redeemed, and delivery platform commissions that are netted before the money arrives.
Five sites means five of these to decompose every day, or twenty five if each site also runs several delivery platforms. Done manually, this is a full time job. Done by a rule, it is a daily journal entry per site that lands automatically, and a difference to review when the bank does not match the expected settlement.
The mapping table between POS categories and general ledger accounts is the artefact that carries all of this, and it is the one nobody maintains. A new menu category is created at one site, it maps to nothing, and its revenue lands in a suspense account or in the wrong line. Two agents matter here: bridging POS revenue to accounting for the daily entry, and checking the analytical mapping table so that unmapped categories surface as an alert rather than as a variance three weeks later.
Where supplier invoices enter the accounting architecture
Everything above assumes the numbers arriving in the ledger are correct. They frequently are not, and the accounting structure has no way of knowing: a ledger records what it is given.
This is the second half of the problem and it deserves its own treatment. The short version is that a group with five restaurants receives supplier invoices at five addresses, negotiates prices at one, and has no mechanism connecting the two. A supplier billing two percent above the agreed rate is invisible at each site, because two percent of one site's weekly order is a rounding error, and material at group level. We covered the mechanics of that control in detail in how restaurant groups validate supplier invoices across multiple locations, including weekly price list handling and cross-site pattern detection.
For the accounting architecture, one point is enough: the validation layer belongs upstream of the ledger, not downstream. An error caught before the entry is a correction. The same error caught at close is a restatement, and at five sites it is five restatements. The reconciliation layer is what sits between the document and the entry.
What an exception-only close looks like across five restaurants
The target state is not a faster manual close. It is a close where the finance team looks only at what broke.
| Close task | Manual, five sites | Exception-only |
|---|---|---|
| POS to ledger | 5 daily entries keyed by hand | Automatic, review settlement gaps |
| Supplier invoices | Every invoice opened and coded | Review price and quantity flags |
| Intercompany | Reconciled at year end | Review non-reciprocal balances |
| Coding consistency | Spotted by the controller, or not | Review unmapped and outlier codings |
| Cut-off | Chased by email per site | Review deliveries without invoices |
| What scales with site count | Total transactions | Exception count only |
That last row is the whole economic argument. When the team touches every transaction, a sixth restaurant adds a proportional workload. When the team touches only exceptions, a sixth restaurant adds the exception rate applied to its volume, which is a much smaller number. Alban Cacace, Co-founder and COO of Jinchan, describes the shift in operational terms:
"Before, I could have thirty emails mixed together. Now I see five or six, and I immediately know what needs my attention."
Jinchan is a useful case here precisely because it is not five identical restaurants. The group runs two Paris restaurants and an import and export business, so every incoming document has to be routed to the correct entity before anything else happens. Entity routing is the first control in a multi entity close, and it is the one most often left to human judgement.
Théo Richard, CFO of La Nouvelle Garde, put the sequencing question in the sharpest available form when the group faced the same growth curve: hiring should only come after automating. His stated next step is instructive for any group at this stage, an anomaly dashboard tracking the riskiest suppliers and establishments, plus two or three key indicators per establishment covering finance, margin and headcount. That is what a comparable site P&L is actually for.
The comparison is the deliverable
Multi location restaurant accounting is judged on one output: can you put five site P&Ls next to each other and trust the differences. Everything else, the entity structure, the account plan, the calendar, the intercompany discipline, the invoice controls, exists to make that one comparison honest.
Groups that get it wrong do not usually get it wrong through incompetence. They get it wrong through sequence: they add sites faster than they add structure, and each opening layers a new exception onto a model that was designed for one restaurant. The fix is not a bigger finance team. It is deciding the four structural questions once, applying them to every site including the ones that open next year, and moving the human effort from processing to exceptions.
For a broader view of how this fits the sector, see how Phacet approaches finance in food and beverage groups, and the operational and strategic angles for finance leadership at multi site companies.
FAQ
What is it called when a restaurant has multiple locations?
A group operating several restaurants is called a multi unit or multi location operator, and a chain when the sites share a brand and a standardized offer. A franchise is different: the sites are owned by independent franchisees under licence. The distinction matters for accounting, because franchised sites are separate businesses, not consolidated entities.
How many locations do you need to be considered a chain?
There is no legal or accounting threshold. Industry datasets use their own conventions, often starting at two or three units under common branding. The threshold that changes your accounting is different: it is the second legal entity, because that is when consolidation, intercompany balances and eliminations begin, regardless of how many restaurants you run.
What is the best accounting method for restaurants?
Accrual accounting, in almost every multi site case. Cash accounting records a supplier cost when it is paid, which can be weeks after the food was sold, so it detaches cost from the revenue it produced. Accrual matches both to the same period, which is the precondition for a food cost percentage that means anything site to site.
What is the 30/30/30 rule for restaurants?
It is a commonly cited cost structure benchmark: roughly 30 percent of revenue to food and beverage, 30 percent to labor, 30 percent to overhead, leaving around 10 percent margin. It is a rule of thumb, not a standard, and it is only readable across sites if every location codes the same costs to the same accounts.
What is the 30/30/10 rule for restaurant expenses?
It is the same guideline stated with the profit line made explicit: 30 percent food, 30 percent labor, and a target of around 10 percent net profit, with overhead absorbing the remainder. In practice, prime cost, meaning food and beverage cost plus total labor cost, is the more useful control because it is measurable weekly rather than monthly.
Latest Resources
Unlock your AI potential
Go further with your financial workflows — with AI built around your needs.

