AWRA OpsHub Search

Hotel & Restaurant Inventory Management in Kenya (2026)

Hospitality sells perishables through many hands at thin margins — the 2026 guide to hotel and restaurant inventory in Kenya: stores, kitchens, bars, and the daily counts that decide whether the month makes money.

Hospitality Washingtone Aura Updated 9 min read

A hotel or restaurant runs the hardest inventory problem in ordinary business: perishable stock, consumed in un-weighable portions, handled by many people, sold at margins that a few careless percentage points erase. A hardware shop that loses 3% of stock has a bad quarter; a restaurant whose food cost drifts 3 points often has no profit at all. That is why hospitality inventory is not a back-office chore — it is the P&L, counted daily.

The flow: store → kitchen → plate

Everything hinges on one structural idea: the main store and the operating outlets (kitchen, bar, housekeeping) are separate locations, and stock moves between them only as recorded issues.

  • Receiving: deliveries counted and weighed against orders — fresh produce especially, where invoiced weight and delivered weight part ways easily. Receiving against POs is the first gate.
  • The main store: locked, one storekeeper accountable, everything in and out on record — the same no-open-doors rule factories live by.
  • Issues to outlets: the kitchen requisitions for the day's expected covers; the bar draws against its par; housekeeping draws amenities — each issue recorded to its outlet.
  • Outlet stock: what each outlet holds is its responsibility until sold, used, or returned — which is what makes outlet-level variance computable.

Food cost: the number the kitchen answers to

Food cost percentage — cost of food consumed ÷ food revenue — is hospitality's master metric. The system version beats the accountant's version because it is available weekly and decomposable: opening stock + purchases + issues − closing stock, per outlet, against the revenue the POS recorded. When the percentage drifts, recipe costing and portion discipline tell you whether the problem is the menu price, the portion, the waste bin, or the back door.

Signal Likely cause First check
Food cost up, covers flat Portions drifting, waste unrecorded, or leakage Spot-weigh five plated dishes against recipe cards
Bar variance while food behaves The classic — pours, spillage "policy", own bottles Run the bar reconciliation nightly for a week
Store issues up, outlet sales flat Outlets over-drawing and stockpiling (or worse) Outlet closing counts vs their issues
Purchases up, issues flat Store receiving generously or stock aging in the cold room Receiving records vs supplier invoices; expiry walk

Daily for the dangerous, weekly for the rest

Count the high-risk items daily — meats, bar stock, seafood, cooking oil — and the full store weekly. A ten-minute daily count of twenty dangerous items catches more leakage than a monthly count of everything, because variance found today has a one-day list of suspects.

POS integration: sales must consume stock

When the POS sells a chicken burger, the system should consume the recipe — bun, patty weight, cheese slice, garnish — from kitchen stock. That link (menu item → recipe → ingredients) is what turns "we sold well but made nothing" from a mystery into a report. It also feeds purchasing: consumption by ingredient, by day of week, is the ordering forecast fresh-produce procurement needs.

Beyond F&B

  • Housekeeping stores: linen par levels per floor, amenities issued by occupancy, chemicals dosed and tracked — the quiet budget nobody audits until it doubles.
  • Maintenance stores: spares and tools with custody — the generator's fuel follows the same arithmetic as any fleet.
  • Assets: kitchen equipment, furniture, TVs — on a register with custodians, condition and movement history, verified on a rhythm. Service intervals are not part of it; keep those on a maintenance calendar.

Most of that discipline — stores, bars, purchasing and the daily counts — is what AWRA for hospitality runs as one system, with eTIMS-compliant billing on the front end. The recipes are the exception, and the honest note below is specific about it.

Stock control yes, recipes no — and that shapes everything

What AWRA OpsHub does today

  • Multi-location stock — a main store, a kitchen and a bar can each be a warehouse or location with its own on-hand position.
  • Issues between locations as stock transfers, so a store-to-kitchen movement is a recorded event.
  • Cycle counting with genuinely blind entry and variance rules that force approval beyond tolerance.
  • Batch and expiry tracking with FEFO depletion, which matters for perishables.
  • Weighted average costing with landed cost folded in.
  • Purchasing with permission-gated approval and vendor performance history.

More we can add to your workspace

  • A recipe or bill of materials of any kind. A dish cannot be defined as a set of ingredients, so theoretical usage cannot be calculated and actual-versus-theoretical variance — the core of F&B control — is not something we produce.
  • Par levels as a distinct concept. A reorder point per item is the nearest equivalent; it is not par-by-outlet.
  • A shift or service-period scoping. Counts and variance are per count session, not per shift.
  • POS-to-recipe depletion, so selling a dish depletes its ingredients. That starts with the recipe entity.

This is the honest heart of it: we are strong on where stock is and whether it is really there, and we do not do what a dish should have cost. An F&B operation whose main pain is store discipline, waste and purchasing will get real value. One that specifically wants theoretical-versus-actual food cost needs a recipe-costing tool, and we would rather you knew that now.

More we can add to your workspace

Anything above that you need, we can build for you

Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.

The operational work, which is what most commissions actually are

An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.

The module-shaped additions, which are the ones readers ask for most often

A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.

The report, document or pack nothing currently produces

The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.

Systems, rails and hardware you already run

The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.

How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.

Tell us what your operation needs

Find your real food cost

One store, one kitchen, one bar, one week — issues between locations, blind counts, and a valued variance report per outlet.

See AWRA for hospitality

Frequently asked questions

What food cost percentage should a Kenyan restaurant target?

Casual dining typically targets 28–35%; hotels with breakfast-inclusive rates and banqueting run blended numbers that need per-outlet decomposition to mean anything. The governance point is less the absolute target than the weekly trend and the explained variance — a stable 33% beats a mysterious 29%.

Do we really need to separate the store from the kitchen?

It is the single highest-leverage change in hospitality stock control. When the kitchen draws freely from the store, food cost is one undifferentiated number and accountability is nobody's. The requisition line between them is what makes kitchen variance and store variance separately visible — and separately ownable.

How do recipe cards work for a menu that changes daily?

On your own sheet, since the product holds no cards — but the method still works. Cost the stable core exactly (portions of protein, standard garnishes, bar measures) and treat a daily special as a batch: issue its ingredients to the kitchen on the record, count the portions it produced, and divide. The issue figures come from the system and are reliable; the division is yours. Precision where the volume is, pragmatism where it is not.

Can one system run multiple outlets — restaurant, bar, pool bar, banqueting?

Yes, and it should: each outlet is a location with its own issues, sales, and variance, rolling up to one food-and-beverage picture. Banqueting adds event-based issuing (provision for 200 covers, return what came back) — which is just the site-materials pattern with tablecloths.

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center