Restaurant Group Purchasing: When Each Site Is a Separate Entity

One Account or One Per Entity: The First Decision
When a restaurant group holds several legal entities, the first purchasing decision is structural: run one shared operating account for the whole group, or provision each legal entity as its own account. The right answer depends on how separate your entities really are in law, banking and tax, not on how the group feels day to day.
The pressure to share one account is understandable. It looks simpler, and a group that grew one site at a time rarely stops to redraw its buying structure. But the moment two legal entities sit behind a single customer record, purchase orders start naming the wrong buyer and supplier invoices post against the wrong company. Untangling that by hand every month is slower and riskier than setting the structure up correctly once. The table below is the quick version of the decision.
| What changes | One shared account | One account per entity |
|---|---|---|
| Purchase orders | All POs raised under one company name | Each entity raises its own POs |
| Supplier billing | Supplier sees one payer; per-entity terms get lost | Each entity keeps its own account number and terms |
| Invoice posting | High risk of posting to the wrong entity | Invoices map to the entity that ordered |
| Adding a brand | New brand bolted onto the existing account | New entity provisioned on its own |
| Best fit | One legal entity, many sites | Several legal entities under one group |
If every site trades under a single legal entity, a shared account is the right call and your controls belong at outlet level. If the sites are genuinely separate companies, read on: the rest of this guide is about setting each one up so purchasing, billing and stock stay clean across the group.
Why One Purchase Order Cannot Span Two Legal Entities
A purchase order is a commitment from one legal buyer to one supplier. It carries a single company name, a single tax registration and a single set of payment terms, so it cannot represent two entities at once. This is not a software limit you can configure away; it is what a purchase order is. Any attempt to make one account buy on behalf of two companies just moves the problem to the invoice.
So do not try to raise cross-entity purchase orders. Instead, let each entity raise its own POs under its own name, and consolidate demand a level higher, at the planning stage, rather than on the order itself. Supy gives each entity a consolidated multi-outlet view of its requisitions and one-tap PO generation, so buying for all the sites inside one entity stays fast without forcing two companies onto one document. Where you want group-wide volume on a single supplier line, that is a separate pattern covered in consolidated purchase orders for restaurant groups, which handles many sites inside one entity, not many entities.

Provisioning a New Brand as Its Own Entity, Not a Bolt-On
When a group opens a new brand as a separate legal entity, provision it as an independent account with its own suppliers, tax registration and users from day one. Retrofitting separation after invoices have already posted to a shared account is far harder than starting clean, because you are then unpicking history as well as changing the setup.
Provisioning an entity properly is a short, ordered job. Register the brand as its own account, attach its own supplier contacts and delivery schedules, and set its own approval chain and spending policies before the first order goes out. Supy supports up to five sequential approvers triggered by branch and order value, and spending policies scoped to specific locations and people, so each entity enforces its own buying rules. A three-tier group, outlet and location hierarchy then keeps every entity isolated in its own records while the group still sees across all of them.

Billing Supply Between Your Own Entities Without Manual Math
Groups with a central kitchen or commissary run into a second problem: one of your entities supplies another, so you need to bill between companies you both own. Doing that by re-pricing and journaling every transfer by hand does not scale past a handful of sites, and it is where inter-entity numbers most often drift.
The mechanism that removes the manual step is a price list per receiving entity. Supy lets a supplying entity maintain separate price lists per customer group, with cost-plus, markup or fixed pricing per group, so each receiving entity is invoiced automatically at the agreed price. You set the rule once; the invoices follow it. The stock side of a central-kitchen transfer and the internal-invoicing detail are their own topic, covered in central kitchen transfer pricing and internal invoicing; here the point is simply that inter-entity billing should be a rule, not a monthly spreadsheet.

Keeping Invoices From Posting to the Wrong Entity
Invoices mispost for one reason above all others: two entities share one account or one supplier record, so the system has no clean way to know which company an invoice belongs to. Scope every account, supplier and credit note to a single entity and the ambiguity disappears, because each document already carries the company that ordered it.
Supy enforces that credit notes are scoped to a single operator account, so one brand's supplier credits never mix with another's. Each entity receives supplier invoices to its own inbox, where they are matched against that entity's own purchase orders, and each entity syncs to its own accounting ledger through Supy's 75+ integrations. That is how an invoice ends up on the right company's books by default instead of being corrected by hand after the fact. It also removes the reconciliation work that shared accounts quietly create. You can see the buying side of this in Supy's restaurant procurement software.

Which Setup Are You Running?
Start from one question: is each site its own legal entity? If the answer is no, one entity trading across many sites, a shared account is right and your effort belongs at outlet level, in approvals, spending limits and inter-site stock transfers. If the answer is yes, several separate companies, provision each entity on its own account, scope its suppliers and credit notes to that entity, and use per-customer-group price lists for any supply that moves between them.

The mistake almost every multi-entity group makes is deciding this by default rather than on purpose, then paying for it in month-end journals. Pick the branch you are in, set the structure once, and purchasing stays clean as the group adds its next brand.


.jpg)

