SAP ERP Restaurant Stock Management: A Practitioner Guide

September 22, 2026

Written by: JJ Tan, Founder, Jelly

Key Takeaways

SAP models each restaurant site as a Plant and each internal store as a Storage Location, with valuation held at Plant level for group financial control.
Key T-codes such as MIGO, MB52 and MI07 handle goods movements, stock reporting and physical inventory counts across multi-site operations.
POS-to-SAP integration for real-time ingredient consumption is complex and costly to maintain, often requiring middleware and ongoing BOM updates.
Theoretical versus actual food cost variance must be tracked through distinct movement types for waste, staff meals and comps to keep site-level P&L reporting accurate.
Jelly provides a specialist kitchen-level consumption and food-cost layer that works alongside SAP; see how Jelly closes the margin gap.

The SAP Object Model Mapped To Restaurant Reality

SAP S/4HANA’s organisational hierarchy for logistics stock runs Client → Company Code → Plant → Storage Location. The table below maps each SAP object to its restaurant equivalent and shows what each level controls for a multi-site group.

SAP Object	Restaurant Equivalent	What It Controls
Company Code	The restaurant group (legal entity)	Statutory accounts, chart of accounts, tax registration, functional currency
Plant	Each individual site, plus the central kitchen or commissary	Stock ownership, valuation, MRP, procurement, and every plant assigns to exactly one Company Code
Storage Location	Dry store, walk-in chiller, freezer, bar store, cellar	Quantity only, and valuation lives at Plant level, so moving stock between Storage Locations inside the same Plant has no financial impact
Material	Each ingredient and each sellable menu item	Master data for procurement, costing, stock management and recipe explosion
Batch	Perishable deliveries with use-by dates	Lot-level traceability, FEFO picking, allergen and recall management, and a batch is uniquely identified by material + plant + batch number
Cost Centre	Each site’s kitchen P&L	Goods issues to cost centre (movement type 201) charge consumption directly to the site’s P&L
BOM / Recipe	The bill of materials that explodes a dish into its ingredient components	Drives theoretical consumption, MRP planning and production order component reservations

The same material can carry different values at different Plants, so Plant is the unit of physical stock ownership and valuation. Moving a pallet of olive oil from the dry store to the kitchen prep area (Storage Location to Storage Location within the same Plant) creates no accounting entry. Moving it from the central kitchen Plant to a restaurant site Plant does.

This object model forms the foundation for choosing the SAP modules and transactions that restaurant teams use every day.

SAP Modules And T-Codes For Restaurant Stock

Core SAP Module For Inventory Management Materials Management (MM) is the primary SAP module for inventory management and covers procurement, goods movements, stock reporting and physical inventory. Where bin-level warehouse control is required, such as in a large commissary or distribution centre, MM extends to WM (Warehouse Management) or, in S/4HANA, to EWM (Extended Warehouse Management). MM handles inventory value while WM/EWM handles physical bin-level stock quantities, and movement type mapping keeps the two in sync.

Key T-Codes For Restaurant Stock The following T-codes cover the day-to-day operational needs of a multi-site restaurant group.

MIGO is the primary transaction for all goods movements. Teams use it to book in a supplier delivery (movement type 101), post a goods issue to a cost centre (201), transfer stock between Storage Locations (311) or between Plants (301), and reverse incorrect postings.
MB51 provides the material document list and gives a goods movement history and audit trail for any material across any site.
MB52 is the warehouse stock report and displays current on-hand stock levels for selected plants and storage locations.
MB5B shows stock on a posting date and helps reconstruct a historical stock position for period-end reconciliation.
MI01 creates a physical inventory document to initiate a stock count at a site.
MI07 posts inventory differences after a count and adjusts system stock to match the physical count.

SAP Inventory Management Process Flow For A Multi-Site Restaurant Group

This sequence uses one consistent worked example: a 10-site UK restaurant group with one central kitchen supplying all sites.

Purchase Requisition And Purchase Order The central procurement team raises a purchase requisition (ME51N) and converts it to a purchase order (ME21N) against an approved supplier. The PO references the Plant receiving the goods, either the central kitchen or an individual site.
Goods Receipt At Site Or Central Kitchen (MIGO) When the delivery arrives, the receiving team posts a goods receipt in MIGO using movement type 101 against the purchase order. This updates inventory, creates a material document, and posts an accounting document that debits the stock account and credits the GR/IR clearing account. For perishable deliveries, batch numbers and shelf-life expiration dates (SLED/BBD) are recorded at this point.
Putaway To Storage Location Stock is assigned to the appropriate Storage Location such as dry store, chiller or freezer. Where EWM is active, MIGO triggers a transfer requirement and a transfer order guides the physical putaway to bin level.
Recipe/BOM Consumption As Dishes Are Sold A bill of materials lists the component ingredients and quantities required per unit of a finished dish. When a production or process order runs, movement type 261 posts component consumption, reduces ingredient stock and charges the cost to the order.
POS Sales Depleting Ingredient Stock POS sales data maps to SAP materials and BOM explosion converts each sold dish into ingredient consumption. In practice, this step requires middleware integration, which the next section on POS-to-SAP integration explains.
Stock Transfers Between Sites Or From The Central Kitchen The central kitchen dispatches prepared items or raw ingredients to sites via Stock Transport Orders (STOs). Movement type 641 posts the goods issue at the sending Plant, and the receiving site posts a goods receipt. For intra-site transfers between Storage Locations, movement type 311 is used.
Physical Stock Count (MI01) And Variance Posting (MI07) Site teams create a physical inventory document in MI01, enter counts, and post differences in MI07. The variance posting adjusts system stock and creates a financial entry.
COGS And Gross Profit Reporting All posted movements roll up into the group’s financial ledger and give the finance team site-level COGS and gross profit by Cost Centre.

This flow works in principle, but the step that most often breaks down is POS-to-SAP integration for real-time consumption.

POS-To-SAP Integration And Recipe/BOM Consumption

The conceptually clean version of POS-to-SAP integration works as follows: a POS sale triggers a BOM explosion in SAP, which posts a goods issue for each ingredient component and depletes stock in real time. The recommended architecture is POS → middleware → S/4HANA, operating in real time or near real time, rather than posting directly from the POS into the S/4HANA core.

Operational reality is tougher. Real-time, item-level POS-to-SAP consumption posting requires every menu item to map to a SAP material, every recipe to stay current as a BOM, and every modifier, substitution and void to be handled correctly in the middleware. Across ten sites with rotating menus, daily specials and frequent supplier changes, this mapping degrades quickly. Keeping S/4HANA clean and allowing the POS system to grow with the business footprint means offloading heavy transformation logic to middleware. That approach adds integration cost and maintenance overhead that most multi-site restaurant groups cannot sustain at kitchen level.

This integration pressure creates the pivot point for the system-of-record decision covered later.

Theoretical Vs Actual Food Cost, Waste And Variance

Theoretical food cost is calculated by multiplying units sold for each menu item by the active recipe cost per unit, then summing across all items in the period. Actual food cost measures what the kitchen genuinely consumed based on stock movements: opening inventory plus purchases minus closing inventory, divided by revenue. The gap between the two is food-cost variance.

In SAP, waste, spoilage, staff meals and comps are posted using distinct movement types or to separate Cost Centres so they do not disappear into unexplained variance.

Waste And Spoilage post as a goods issue to a cost centre (movement type 201) or as a scrapping movement (movement type 551). These postings reduce stock and charge the loss to the site’s P&L.
Staff Meals should be tracked separately from food cost and recorded as an employee benefit expense. Posting to a dedicated Cost Centre keeps the food-cost metric comparable across sites.
Comps And Voids post as goods issues to a separate cost centre so the variance bridge reflects true stock movement and keeps approved non-sales use visible.

For multi-site operators, a food cost variance under 1% is excellent, 1–2% is acceptable, 2–3% warrants investigation, and over 3% is urgent and signals a structural problem. Variance shows whether a site’s kitchen is under control, and that signal only works when recipe costs, inventory counts and POS sales data stay current and accurate.

Maintaining that accuracy becomes more complex when a central kitchen, stock transfers and batch expiry all come into play.

Stock Transfers, Central Kitchens And Batch/FEFO Management

For groups with a central production kitchen or commissary, Stock Transport Orders (STOs) provide the SAP mechanism for moving prepared items and raw ingredients to sites. The sending Plant posts a goods issue and the receiving Plant posts a goods receipt. Two-step STOs use movement type 303 at the sending Plant and 305 at the receiving Plant when goods are in transit, which gives the group visibility of stock that has left the commissary but not yet arrived at the site.

SAP EWM’s FEFO picking strategy (code C) is designated for perishable goods and the food industry. It picks the bin holding stock with the earliest expiry date (SLED/BBD) and requires batch management and shelf-life data on each batch. SAP S/4HANA also supports automatic batch determination using FEFO for transfer postings via movement type 311. The system selects the earliest-expiring batch automatically and can split quantities across batches when a single batch cannot fulfil the transfer.

SLED/BBD must be entered at every goods receipt, either manually in MIGO or automatically via inbound delivery interface, because EWM reads the batch date at warehouse order creation time and missing or incorrect dates cause the strategy to degrade silently. Batch traceability at this level also supports allergen management and product recall requirements under UK food safety legislation and gives the group a documented chain of custody from supplier delivery to site consumption.

The System-Of-Record Decision: Where SAP Stops And Jelly Starts

SAP serves as the financial system of record for group-level stock value, procurement and finance. Kitchen-level ingredient consumption requires a different system. Posting every ingredient movement manually into SAP across ten or more sites is operationally unworkable because chefs do not use SAP, BOM data degrades without dedicated maintenance, and the POS-to-SAP integration overhead rarely stays sustainable at kitchen level. Food-cost accuracy then breaks down precisely where it matters most, at the site, in real time, during service.

Jelly provides a specialist consumption and food-cost layer that sits alongside SAP and handles kitchen-level reality at scale. The architecture recommendation is explicit: use SAP for group finance and stock valuation, and Jelly for site-level consumption, recipe costing and food-cost variance. Connect the two so the numbers reconcile.

Jelly’s capabilities at the kitchen level include:

Automated Invoice Scanning Every line item of every supplier invoice is digitised automatically, which keeps ingredient costs current without manual data entry.
Live Dish Costing Recipe costs update with every new invoice, so the gross profit margin for every dish stays live. Customers report gross margin improvements of around 2 percentage points in the first three months.
Price Alert The system flags every supplier price increase or decrease and gives operators the evidence to negotiate credits or switch suppliers before the margin impact compounds.
Flash Report And Sales Mix Jelly’s Flash Report provides a daily, weekly or monthly view of GP margin, calculated from invoice costs and POS sales. Sales Mix (Menu Engineering) shows which dishes are most popular and most profitable via POS integration. Together, they give real-time margin visibility without waiting for a month-end report.
Accounting Integration Digitised invoices push directly into Xero, with Sage integration coming soon, which reduces bookkeeping time significantly.

Jelly integrates natively via real-time API with four POS systems: Square, EPOS Now, Toast and Lightspeed. POS-to-dish linking only surfaces items sold since the integration was connected, which keeps the mapping clean. Onboarding typically completes within the first week. Pricing is a flat rate of £129 per month per location with no variable charges per user or feature. Customers report food cost reductions of around 3% in the first three months.

For a broader comparison of restaurant inventory software options for UK multi-site venues, see the Best Restaurant Inventory Software For UK Multi-Site Venues comparison, and for foundational stock management principles, the Restaurant Stock Management: The Ultimate UK Guide.

Map where Jelly fits alongside your SAP setup.

Common Challenges And Pitfalls For SAP Restaurant Setups

Multi-site operators running SAP for restaurant stock consistently encounter the same set of problems.

Treating SAP As A Kitchen Tool Rather Than A Finance Tool SAP’s object model and transaction overhead are designed for financial control and statutory reporting, not for the speed and informality of kitchen operations.
Attempting Manual Posting Of Every Ingredient Movement This approach is unsustainable at scale and degrades quickly when kitchen teams work under service pressure.
Failing To Maintain Recipe/BOM Data Outdated recipe costs after supplier price changes are one of the most common causes of inaccurate theoretical food cost. When this happens, the variance report turns into noise.
Inconsistent Stock Counts Across Sites Different counting frequencies, units of measure and cutoff timings make group-level variance comparison unreliable.
Delayed Variance Reporting Operators who count stock monthly discover problems a month too late. By the time the SAP report surfaces the variance, the trading period that caused it has already closed.

Frequently Asked Questions

What Is The SAP Module For Inventory Management?

Materials Management (MM) is the primary SAP module for inventory management. It covers procurement, goods movements, stock reporting and physical inventory. Where bin-level warehouse control is required, such as in a large commissary or distribution centre, MM is extended by WM (Warehouse Management) in SAP ECC or by EWM (Extended Warehouse Management) in SAP S/4HANA. EWM adds capabilities including labour management, advanced picking strategies such as FEFO, and complex slotting, and is part of S/4HANA.

What Is The T-Code In SAP For Inventory Management?

There is no single T-code for inventory management because different tasks use different transactions. MIGO is the primary transaction for all goods movements, including goods receipts, goods issues, transfer postings and reversals. MB51 displays the material document list and provides the movement audit trail. MB52 shows current on-hand stock across sites. MB5B shows stock on a specific posting date for reconciliation. MI01 creates a physical inventory document to initiate a stock count, and MI07 posts the inventory differences after the count is entered.

How Do I Check The Stock Of Multiple Materials In SAP?

MB52 is the standard transaction for checking on-hand stock across multiple materials and multiple sites simultaneously. It can be filtered by Plant, Storage Location and material number, which makes it a practical tool for a multi-site restaurant group checking stock positions across sites. MB51 provides the underlying movement history for any material and helps when investigating why a stock balance does not match expectations.

How Does SAP Handle Recipe And BOM Consumption For Restaurants?

In SAP Production Planning (PP), a bill of materials (BOM) lists the component ingredients and quantities required per unit of a finished dish. When a production or process order is created and released, SAP explodes the BOM into component reservations. When components are physically issued to production, movement type 261 posts a goods issue for each ingredient, reduces stock and charges the cost to the production order. In SAP, process orders are used for process industries such as food and beverage, applying batch-driven, recipe-driven inventory posting logic. The accuracy of this model depends entirely on BOM data staying current. If recipe costs or yields are not updated when supplier prices change, the theoretical consumption figure becomes unreliable.

How Do You Integrate POS Sales With SAP Inventory?

The recommended architecture is POS → middleware → S/4HANA, using SAP Integration Suite (BTP/CPI), IDocs or OData APIs to pass item-level sales data from the POS to SAP via middleware. In practice, sustaining this integration at kitchen level across multiple sites requires every menu item to map to a SAP material, every recipe to be maintained as a current BOM, and every modifier, void and comp to be handled in the middleware. This overhead is significant, so many multi-site groups use a specialist consumption layer alongside SAP rather than attempting full POS-to-SAP ingredient-level posting.

How Do You Manage Stock Transfers Between Restaurant Sites In SAP?

Stock transfers between sites use Stock Transport Orders (STOs). The sending Plant posts a goods issue and the receiving Plant posts a goods receipt. For transfers where goods are in transit, such as a commissary dispatching to a site, two-step STOs use movement type 303 at the sending Plant and 305 at the receiving Plant, which gives the group visibility of in-transit stock. For transfers between Storage Locations within the same Plant, movement type 311 is used and has no financial impact because valuation lives at Plant level. Batch determination can be configured to apply FEFO automatically on transfer postings and select the earliest-expiring batch first.

Should SAP Be The System Of Record For Kitchen Stock?

SAP should be the system of record for group-level stock value, procurement and finance. Kitchen-level ingredient consumption needs a different system. The SAP object model and transaction overhead are designed for financial control and statutory reporting. Posting every kitchen ingredient movement into SAP manually is operationally unworkable at scale, and the POS-to-SAP integration required to automate it adds significant maintenance overhead. A specialist layer such as Jelly handles site-level consumption, recipe costing and food-cost variance, integrates with the POS systems operators already use and keeps ingredient costs current from invoice data automatically. The two systems serve different purposes and work best when each is used for what it is designed to do.

Conclusion: Where Your Setup Breaks Down

SAP gives multi-site restaurant groups financial control and stock valuation at group level. It handles procurement, statutory reporting, batch traceability and inter-site stock transfers with precision. As established earlier, SAP is not the kitchen system of record and cannot sustain kitchen-level ingredient consumption posting across multiple sites without significant manual effort and integration overhead.

Food-cost accuracy at site level depends on a specialist consumption and food-cost layer that keeps recipe costs current from invoice data, drives consumption from POS sales automatically, and surfaces variance in time to act on it during the trading period rather than weeks after it closes. As noted earlier, variance thresholds show when a site is under control and when structural issues need attention.

Every multi-site operator running SAP faces a specific gap between SAP and the kitchen where margin leaks away. Identifying that gap is the starting point for fixing it.

Map where your SAP and kitchen setup diverge and plan how to close the margin gap.