.jpg)
How to Handle Central Kitchen Transfers in a Multi-Entity Xero Restaurant Group
You opened a central kitchen for a reason: prep and buy in one place, hold food cost down across every site, and open the next store without rebuilding your supply chain each time. That payoff is real, and most of your accounting keeps up with it. The one place it does not is the internal delivery. Every time the kitchen sends stock to one of your own stores, that single movement has to be recorded in two separate Xero files, and because each entity keeps its own books, nothing posts both sides for you, so someone keys it in by hand, twice, for every internal delivery, every week. Getting this right is what keeps the whole model paying off: each site's P&L shows its true cost, month-end closes without a scramble, and you can open the next location without handing your finance team another pile of manual entries. Get it wrong and that hidden manual load, and the errors buried in it, grow with every store you add. This guide walks you through how to handle it: what your multi-entity Xero setup already does for you, where it stops, and the two decisions that keep a multi-entity Xero restaurant group manageable as you scale.
Step 1: Map What Your Multi-Entity Xero Setup Already Handles
Run a restaurant group as several legal entities and each one usually keeps its own Xero file. A multi-entity Xero setup is that arrangement: one accounting organisation per legal entity, each mapped to its own outlets. The external purchasing posts cleanly. It is the single internal delivery between two of your own entities that has nowhere to go.
Start with what works, because most of it does. Each entity in the group connects its own accounting platform, and purchase invoices, supplier returns and central kitchen B2B orders post to the correct entity automatically. If a sync fails, the source document is un-posted and flagged with a retry, so nothing is left half-recorded. Per-location mapping routes each outlet to its own Xero organisation from one place, so a group can run many separate Xero files without logging into each one to move data across.
Underneath that, every entity maps its outlets to accounting cost centres, aligns its tax rates to Xero's tax codes, and assigns a general ledger (GL) purchase account to each inventory item, so purchase journal entries land on the right code from day one. That is the reliable spine of a multi-entity Xero restaurant group: invoices and credit notes flowing per entity, each file self-contained. The break comes at exactly one point.
Step 2: Find Where the Internal Transfer Breaks
The break is structural, not a setup mistake. When a central kitchen sells to one of its own stores, the same item has to carry two roles: a purchase code when a supplier delivers it into the kitchen, and a sales code when the kitchen ships it out to the store. An inventory item holds one general ledger code, so the moment that item also carries external supplier invoices, the internal transfer invoice has no second code to post against and cannot land.
This is the same fault line that runs through a group's multi-entity chart of accounts, seen from the transfer side rather than the code-mapping side. It is not solved by a clever configuration: no standard setup posts an internal central-kitchen-to-store transfer as two entries in two separate files on its own, and the common workaround among groups that hit it is simply not to post internal transfers into the kitchen's ledger at all. That is a real, defensible choice, and it is the reason this has to be decided rather than assumed.
Step 3: Count What the Manual Double Entry Costs You
Because the transfer will not post itself, someone keys it in twice: once as a sales invoice in the kitchen's file and once as a bill in the store's file. On its own that is a two-minute job. Across a real group it is not. A mid-size operator running roughly eight internal deliveries a week across five or more separate Xero files is entering about sixteen accounting lines by hand every week, near eight hundred a year, and every one is a chance to mistype a figure, code it wrong, or miss the delivery entirely.
The number also grows with the group, not with effort. Each new store or brand that trades internally adds another file and another set of hand-keyed entries, so the task gets heavier exactly as the finance team gets busier. This is the cost that stays invisible on a feature comparison and shows up only in the month-end close.
Step 4: See One Delivery as Two Ledger Entries
To decide anything, be precise about what a single internal delivery actually is in accounting terms. It is not one event, it is two, sitting in two different Xero organisations. The kitchen owes a sales record for goods it sold out; the store owes a purchase record for goods it bought in. Both describe the same physical delivery, and both have to reconcile at close.
| Ledger | Document that must post | How it happens today |
|---|---|---|
| Central kitchen's Xero file | Draft sales invoice, out to the store | Entered by hand |
| Receiving store's Xero file | Draft bill, in from the kitchen | Entered by hand |
Step 5: Set the Right Internal Transfer Price
The second decision is the number on that invoice, and it is easy to get wrong by defaulting to a figure the system already knows. Neither the recipe build cost nor the store's menu price is the right value for an inter-entity transfer: cost price hides the kitchen's own margin and makes the store look cheaper to run than it is, while menu price inflates the kitchen's revenue against a sale that never left the group. What most operators actually need is a third, distinct internal transfer price, agreed once and applied consistently.
| Price basis | What it is | What it distorts |
|---|---|---|
| Recipe cost price | The internal build cost of the item | Hides the kitchen's margin; the store looks cheaper than it runs |
| Menu or retail price | The price the store sells at | Inflates kitchen revenue on a sale that stayed inside the group |
| Set internal transfer price | A distinct, agreed inter-entity price | Nothing, once agreed and applied the same way every time |
Step 6: Decide Your Posting Policy Before You Scale
Before you build any automation or write a workaround, place your group on two axes: how many internal transfers you genuinely run in a week, and whether your entities truly need separate accounting files or only look like they do. Those two questions sort almost every group into a clear answer, and they matter more than any tool choice.
If the entities could sit in one file, keeping them as cost centres and skipping inter-entity posting entirely removes the whole problem; a clean accounting integration and GL mapping does more for close accuracy than automating a posting you did not need to make. If the entities are genuinely separate and the transfer volume is high, the manual burden is real, so agree a single internal transfer price and a posting policy before you add the next store rather than after. Low volume with separate files is the one case where posting by hand for now is the honest answer.
Start with one count: how many internal deliveries cross an entity boundary in a typical week. If it is a handful, post them by hand and move the finance team's attention somewhere higher-value. If it is dozens, decide your internal transfer price and your posting policy now, because retrofitting either across live multi-entity Xero ledgers once the group has grown is far harder than agreeing them once, early, while the structure is still small enough to change.
