Procurement

Central Kitchen Requisitions: One Supplier Order From Many Branches

Curran Dye

September 6, 2026

Purchase orders for a central kitchen, generated on approval from six branches' requisitions

Many Branch Requisitions, One Order Per Supplier

Consolidating branch requisitions into central kitchen supplier orders means every branch raises its own structured supply request, the central kitchen aggregates those lines into one demand view, and on approval the platform groups them by supplier and generates a single purchase order for each supplier per delivery date. Many requests go in, and one clean order per supplier comes out, with items from different suppliers never mixed into the same order.

The distinction that matters is the direction of travel. Branches raise requisitions into the central kitchen, and the central kitchen sends consolidated orders out to suppliers. The goal is not to place one order faster. It is to stop turning dozens of separate branch requests into supplier orders by hand every ordering cycle, by letting the requisition data carry through to the purchase order without a manual rebuild step in the middle.

The same branch demand rebuilt by hand in three hours versus auto-grouped into five supplier orders on approval

Why the Export and Rebuild Loop Breaks Down

The pain is specific and common. Branches place their orders, someone exports the combined item list, and then rebuilds the actual purchase orders by hand so each supplier gets the right lines. On a spreadsheet and a shared folder this holds together for two or three sites. Past that it becomes unsustainable: the person doing the collation is re-keying numbers the branches already entered, the combined list is stale by the time the orders go out, and any mistake in the rebuild lands as a wrong delivery.

The cost is quiet but real. A group running this manually can spend around three hours a cycle exporting and rebuilding orders that the requisition data already contained. None of that work adds anything the branches did not already supply. It is pure re-entry, and it is the first thing consolidation removes.

The manual consolidation loop where six branches order, the list is exported, and each supplier order is rebuilt by hand every cycle

From Branch Requisition to Consolidated Demand

The inbound half of the flow is where the collation stops being manual. Branches raise requisitions on web or mobile, adding quantities, notes, and photos, and each line can carry its preferred supplier. Because every branch feeds the same system, the central kitchen gets a consolidated multi-outlet view of demand, so the same item requested by different branches lines up in one place and the total is already summed before anyone opens a supplier order. Supy's restaurant procurement software is built around this aggregation.

The same milk, beans, and cups requested across sites collapse into one line per item, with the branch quantities still visible behind the total:

Item	City Centre Branch	Harbour View	Total ordered
Whole Milk 2L	24	18	42 units
Arabica Beans 1kg	15	12	27 kg
Oat Milk 1L	20	16	36 units
Takeaway Cups 12oz	500	400	900 units

That consolidated view is what a stack of separate branch spreadsheets can never give you: procurement can see cross-outlet demand before committing to any order. The mechanics of turning that combined demand into one order per supplier are covered in depth in our guide to consolidated purchase orders for restaurant groups.

How Approved Lines Group Into One Order Per Supplier

Between the requisition and the purchase order sits an approval step, and it is there on purpose. A requisition is a request, not a commitment to spend, so it passes through a configurable approval ladder, up to five approvers deep and triggered by branch and order value, before it can become a purchase order. This is what separates demand capture from the spend decision, and the full mechanics are covered in our guide to multi-level purchase order approval.

Once approved, the grouping is automatic. The platform sorts every approved line by supplier and generates one consolidated order per supplier per delivery date. Items from different suppliers are never mixed, and one supplier is never split across several small orders. That output rule is what protects the thing manual collation quietly loses: volume leverage. Splitting a supplier across many little orders, or padding an order with lines that belong elsewhere, erodes the pricing you negotiated. Each finished order then goes out the way that supplier expects, by email, messaging, or a direct integration, which we cover in sending purchase orders to suppliers.

Forty eight requisition lines across six branches become five consolidated supplier orders, one per supplier per delivery date

Your First Move

If your central kitchen still exports and rebuilds orders by hand, the first step is not new software habits, it is two pieces of setup. Map each item to its preferred supplier, and set your branch requisition permissions and approval thresholds. Get those two right and the consolidation happens on its own: the moment branches order, every line already knows which supplier it belongs to and who has to approve it, so approval is the last manual touch before five clean supplier orders exist. Because consolidation is also what defends your volume pricing, it is worth knowing where your food cost sits before and after you tighten the flow. Our food cost calculator gives you that baseline in a couple of minutes.

Book a Demo with Supy - consolidating branch requisitions into one supplier order

Get weekly insights and tips delivered straight to your inbox.

Ready to optimize your restaurant operations?

Book a demo



Blog

Our operational insights





No items found.

Your questions  answered

Everything you need to know about Supy — from setup to integrations, pricing, and daily use. If it’s not covered here, just ask.

What does it mean to consolidate branch requisitions into a supplier order?

It means each branch raises its own structured requisition, the central kitchen aggregates every line into one demand view, and on approval the system groups those lines by supplier and generates a single purchase order for each supplier. Instead of one person exporting a combined list and rebuilding each order by hand, the requisition data carries straight through to the purchase order. Many separate branch requests go in, and one clean, correctly grouped order per supplier comes out, with items from different suppliers kept in separate orders.

How is a requisition different from a purchase order?

A requisition is an internal request to buy something, raised by a branch or location. A purchase order is the committed order that goes to the supplier. Keeping them separate matters because it lets demand be captured freely at branch level while spend stays controlled: a requisition can be reviewed, edited, or rejected before it ever becomes a commitment. Only once a requisition passes approval does it convert into a purchase order, which is the point where money is actually committed and the supplier is contacted.

Why should each supplier get one consolidated order per delivery date?

Because mixing suppliers or splitting one supplier across several small orders costs you money and creates reconciliation work. One consolidated order per supplier per delivery date means the supplier receives a single clean order, your negotiated volume pricing holds, and matching the later delivery and invoice back to the order is straightforward. Splitting the same supplier across many partial orders fragments that volume and multiplies the documents your team has to reconcile, which is exactly the mess consolidation is meant to remove.

Do branches lose control when requisitions are consolidated centrally?

No. Branches still raise their own requisitions with their own quantities, notes, and preferred suppliers, so local knowledge is captured at the source. What changes is that the central kitchen sees all of that demand in one view and handles the supplier ordering. Branches keep control of what they request, and the group gains control of how it buys. An approval ladder sits between the two, so requests are visible and reviewable rather than being committed to spend automatically. If anything, branches get a faster acknowledgement, because their requests flow into a live shared queue instead of a folder someone has to remember to open.

How does an approval ladder fit into the flow?

The approval ladder sits between the requisition and the purchase order. A requisition can route through up to five approvers, triggered by which branch raised it and the order value, before it is allowed to become a purchase order. This keeps demand capture open at branch level while keeping the spend decision controlled and auditable. Higher value requests can require more senior sign off, and nothing turns into a committed supplier order until it has cleared the approvals set for that branch and value.

What happens to items that have no preferred supplier set?

Those lines still appear in the consolidated demand view, but they cannot be grouped automatically until a supplier is assigned, because grouping is done by supplier. The practical fix is to set a preferred supplier per item during setup, so every requisition line already knows where it belongs the moment it is raised. Items left without a supplier are the usual reason a consolidation looks incomplete, so a quick check that every regularly ordered item has a preferred supplier is worth doing before you rely on the flow.

Can a central kitchen consolidate requisitions from many branches at once?

Yes, that is the core of the flow. A multi site operator aggregates pending demand from every branch into one consolidated procurement view, without logging into each site separately, and can review, approve, reject, or batch process requisitions from a single screen filtered by location, category, status, and date. From that one view the approved lines convert into consolidated supplier orders in bulk, which is what lets one central team purchase for a whole group of branches without handling each requisition one at a time.