Restaurant POS and ERP: Recipes, KDS, Waste, Branch Finance, and FBR

A restaurant order touches more systems than the guest sees. The POS captures the sale, the kitchen prepares it, inventory provides ingredients, purchasing replenishes stock, tender is collected, finance closes the branch, and applicable invoices follow FBR requirements.

Disconnected tools create unexplained food cost, repeated entry, slow closing, and weak control.

Model the restaurant

Set up:

• Company and branch
• Revenue center
• Terminal and cashier
• Menu, category, and modifier
• Recipe and yield
• Ingredient and unit conversion
• Kitchen station
• Table, takeaway, delivery, and aggregator channel
• Tender
• Tax and service treatment
• Shift and closing

Version recipes and prices with effective dates.

Order to kitchen

The workflow includes:

1. Create the order.
2. Apply menu, price, modifier, promotion, and tax rules.
3. Route items to the correct KOT or KDS station.
4. Track accepted, preparing, ready, served, cancelled, or returned.
5. Complete tender.
6. Post sale, stock, and finance.
7. Submit applicable external invoice data.

Test changes after preparation starts, split bills, partial voids, complimentary items, and delivery cancellation.

Recipe and food cost

Recipes need:

• Ingredient quantity
• Unit conversion
• Yield
• Preparation loss
• Substitute policy
• Modifier effect
• Effective date
• Branch variation

Theoretical usage equals completed sales multiplied by active recipe quantity. Compare it with actual issues, production, waste, transfers, and physical count.

Do not change recipes merely to make variance disappear.

Purchasing and central kitchen

For multi-branch groups, connect:

• Branch demand
• Central-kitchen production
• Transfer request
• Dispatch and receipt
• Batch and expiry
• Purchase request
• Supplier receipt
• Quality and rejection

Oyo can prepare replenishment using projected demand, stock, lead time, pack size, and expiry. Approval applies by quantity and value.

Wastage

Capture reason, item, quantity, stage, branch, shift, approver, and evidence.

Separate:

• Preparation waste
• Spoilage
• Overproduction
• Guest return
• Damage
• Staff meal
• Quality rejection

Oyo’s variance review can compare theoretical and actual usage, but a kitchen manager investigates the physical cause.

Voids, discounts, and refunds

Control:

• Role limits
• Reason
• Original transaction
• Preparation state
• Manager approval
• Customer tender
• Stock and accounting effect
• FBR correction where applicable

Monitor patterns by user, terminal, branch, item, and time. Treat a flag as an investigation lead, not proof of wrongdoing.

Branch closing

Reconcile:

• Sales by channel
• Tender
• Cash count
• Delivery aggregator
• Discounts
• Voids
• Refunds
• Open tables
• Stock and waste
• FBR status

Oyo’s closing review can assemble evidence and route differences. It should not hide a cash variance with an unsupported entry.

Oyo reviews

Closing Oyo review: Prepare tender, cash, void, refund, and submission exceptions.

Waste Oyo review: Compare recipe usage, stock movement, waste, and sales.

Purchasing Oyo review: Prepare branch and central-kitchen replenishment.

FBR exception Oyo review: Classify and route rejected or pending submissions.

Start in observation mode. Require approval for actions that affect money, stock, price, or compliance.

FBR readiness

Confirm applicability and current requirements through FBR primary guidance. Test normal sales, discounts, returns, cancellations, outages, reference and QR output, duplicate prevention, and daily reconciliation.

Use “integration support” until approved-route and production evidence exists.

Key measures

• Order cycle time
• Kitchen preparation time
• Order accuracy
• Food cost
• Theoretical-to-actual variance
• Waste
• Average bill
• Discount and void rate
• Cash variance
• Branch close time
• Stockout
• Submission exception rate

Demo checklist

Run:

• Dine-in order with modifiers
• Kitchen routing
• Partial void
• Delivery order
• Recipe consumption
• Waste
• Branch closing
• Cash variance
• FBR timeout
• Oyo review approval and audit

Menu and recipe change control

Treat a menu launch as a controlled release. Product, kitchen, procurement, finance, branch operations, and POS owners should approve the relevant fields.

Before activation, confirm:

• Menu name and channel
• Recipe version
• Modifier behavior
• Kitchen station
• Portion and yield
• Cost
• Price
• Tax
• Promotion eligibility
• Branch availability
• Effective time

Run a complete test order. Confirm KDS routing, ingredient usage, tender, receipt, accounting, and external-invoice behavior. Keep the prior recipe and price for historical reporting.

Delivery and aggregator reconciliation

Delivery orders may begin outside the POS. Define which system owns menu, price, discount, status, cancellation, customer charge, commission, and settlement.

Reconcile:

• Orders received
• Orders accepted
• Completed orders
• Cancelled and refunded orders
• Gross sales
• Customer discounts
• Platform-funded discount
• Restaurant-funded discount
• Commission and fee
• Tax
• Net settlement
• Bank receipt

Oyo can assemble unmatched cases, but finance approves entries and disputes.

Central kitchen production

Translate branch demand into a controlled production plan. Use forecast, confirmed request, current branch stock, central stock, batch, expiry, capacity, and transfer lead time.

Record raw-material issue, prepared output, yield, waste, batch, quality status, dispatch, and branch receipt. Maintain unit conversion between recipe units, production packs, and branch-use units.

Do not count central-kitchen production and branch recipe consumption twice. Define the inventory point where intermediate product becomes a branch ingredient.

Physical count and variance

Count high-value and high-variance items frequently. Record opening, receipt, transfer, theoretical usage, approved waste, staff meal, return, and closing physical quantity.

Classify differences by timing, unit conversion, recipe, portion, receiving, waste, or unexplained cause. Oyo can rank cases and show evidence. A manager confirms the root cause and any adjustment.

Branch opening and closing checklist

At opening, verify terminals, menus, prices, tenders, KDS stations, network, printer, critical stock, and unresolved prior exceptions.

At closing:

1. Close open tables and orders.
2. Reconcile tender by terminal.
3. Count physical cash.
4. Review voids, discounts, refunds, and complimentary items.
5. Reconcile delivery channels.
6. Review stock and waste exceptions.
7. Review FBR status.
8. Approve or assign every difference.

Retain the approver and evidence.

Permissions

Separate cashier, server, kitchen, manager, inventory, purchasing, finance, and administrator access. Limit price overrides, complimentary items, returns, cash adjustments, recipe changes, and master-data changes.

Review access when staff change branch or role. Never share cashier accounts. The audit record should identify the actual user and terminal.

Implementation data

Prepare branch, revenue center, terminal, user, menu, modifier, recipe, ingredient, unit, supplier, opening stock, tender, tax, promotion, and delivery-channel data.

Start with a representative branch. Include busy periods, delivery orders, returns, and outage behavior. Reconcile sales, tender, stock, and accounting each day before expanding.

Acceptance test pack

Test:

• Normal dine-in, takeaway, and delivery
• Modifier and price override
• Kitchen reroute
• Item unavailable after order
• Partial void after preparation
• Full refund
• Promotion
• Split tender
• Network outage
• Printer failure
• Delivery mismatch
• Recipe variance
• Central-kitchen transfer
• Cash difference
• FBR rejection
• Duplicate event

Every test checks customer output, kitchen status, stock, tender, accounting, external response, permissions, and audit.

Go-live measures

Review order time, kitchen time, cancelled items, discount, void, refund, food variance, waste, cash difference, delivery mismatch, FBR exception, closing time, and support cases by branch.

Do not expand Oyo authority while data, recipe, tender, or branch-closing differences remain unstable.

Follow the guest order through every state

A restaurant order is a chain of commitments. Model the states that matter: opened, sent, acknowledged by the kitchen, in preparation, ready, served or handed over, paid, closed, voided, refunded, or cancelled.

State changes need accountable users and timestamps. If a guest changes a modifier after preparation begins, the kitchen should see the revision and the system should retain the original instruction. If one item is unavailable, the branch needs a controlled choice to substitute, remove, or cancel it without losing the rest of the order.

Different channels can use different service states, but they should resolve to the same financial and inventory records. A delivery platform status alone should not close an order in the ERP. The completion event, tender expectation, platform fee, cancellation reason, and later settlement must agree.

Oyo’s order-flow review can flag stuck tickets and conflicting states. The manager decides whether to remake, refund, contact the guest, or correct the channel record.

Design the kitchen queue for decisions

Kitchen screens should make work visible, not add noise. Route each item by branch, revenue center, service channel, station, recipe, modifier, and preparation sequence. Define when a station accepts an item, when it marks it ready, and how a completed item joins the final order.

Track queue age and exceptions separately from average preparation time. An average can look healthy while a small group of tickets waits too long. Daypart, station load, item complexity, and order size give necessary context.

When a station is overloaded, an Oyo review may recommend throttling a channel, marking an item temporarily unavailable, changing a promised time, or moving work where the approved operating design permits it. These are customer-facing decisions. The shift manager should approve the action and the system should record its duration and affected channels.

Reduced-motion website demonstrations can show the same sequence as a static trace: new order, station acceptance, exception, manager decision, completion, and receipt.

Build recipes from measurable units

Recipe control starts with units. Purchasing may buy kilograms, production may prepare a batch, and the branch may consume grams or portions. Every conversion needs an owner, effective date, and tested rounding rule.

Use subrecipes for sauces, dough, marinades, gravies, and prepared ingredients when their production and storage are managed separately. Record expected input, expected yield, usable output, holding life, and approved variance. A changed yield should not rewrite the cost or usage history of prior sales.

Theoretical usage is an investigation baseline. It combines sold menu items, recipe versions, modifiers, approved staff meals, production, transfer, waste, and return. It is not a substitute for physical count.

Oyo’s recipe-cost review can surface cost changes from ingredient prices, yield, or portion assumptions. Product and finance owners review the evidence before changing a menu price, recipe, or margin target.

Reconcile delivery channels as a settlement ledger

Treat each external channel as a counterparty. Store its order reference, restaurant reference, branch, gross amount, discount funding, tax, commission, delivery fee, adjustment, cancellation, refund, net settlement, and payment date.

Reconciliation should match at three levels:

1. Order count and lifecycle
2. Financial components
3. Bank receipt

Do not post one net bank amount as sales. The ledger needs gross revenue and each approved deduction. A missing order, duplicate order, changed commission, late refund, or short settlement enters a dispute queue with source evidence.

Oyo can group differences by likely cause and prepare a dispute file. Finance approves any journal, write-off, or counterparty claim. Old unresolved differences need ageing and escalation, otherwise a busy channel can hide material leakage behind high sales volume.

Plan dayparts without confusing forecast and fact

Breakfast, lunch, dinner, weekends, events, weather, delivery promotions, and local traffic can change demand. Keep the forecast version and assumptions visible. Compare it with actual orders, mix, preparation load, ingredient use, and waste.

The branch can translate an approved forecast into prep quantities, central-kitchen requests, staff planning inputs, and purchasing signals. The ERP should show where a manager changed the suggestion and why.

Forecast accuracy belongs beside availability and waste. A low forecast may cause lost sales, while an aggressive forecast may create waste. The useful question is not whether the model was right in isolation. It is whether the branch made a better, explainable preparation decision with the information available at the cutoff.

Protect tender and cashier lifecycles

Assign each terminal, shift, cashier, and cash drawer where the operating model requires it. Record opening float, sales by tender, paid-outs, refunds, cash drops, closing declaration, counted cash, and approved difference.

Cashiers should declare before seeing the expected amount if blind close is part of policy. Managers need separate authority for drawer reopening, tender correction, refund, and write-off. Shared accounts weaken both accountability and investigation.

Digital tenders also need reconciliation. A successful terminal message, payment-provider record, POS order, settlement file, and bank receipt may arrive at different times. Keep pending, failed, reversed, and settled states distinct. Oyo can gather mismatches, but finance decides the accounting treatment.

Put evidence beside every Oyo review proposal

Oyo’s restaurant review should show the exact operational record behind its recommendation:

Approval should be renewed when the amount, tender, recipe, order status, or external response changes. A completed action needs a receipt. A failed action needs an owner, retry rule, and safe stop.

Run a complete Friday-night simulation

Choose a high-volume period and simulate real friction. A dine-in table changes one modifier, a delivery channel sends a duplicate event, a menu item becomes unavailable, a kitchen station falls behind, and an invoice submission times out. Later, one digital payment reverses and the cash drawer closes with a small difference.

The team should be able to trace each event from source to resolution. The duplicate must not create a second order. The unavailable item needs a customer and kitchen outcome. The timeout must not create a duplicate invoice. The payment reversal and cash difference need separate finance queues.

This test connects service, kitchen, inventory, payment, compliance support, and accounting. It also exposes whether an Oyo review merely reports a problem or can prepare a governed action with evidence, permission, approval, execution receipt, and recovery.

Related Oyo guides

• FBR POS integration in Pakistan
• Supermarket ERP and POS

Sources and further reading

• FBR digital-invoicing FAQ
• FBR POS booklet
• GS1 foodservice resources
• Odoo restaurant POS documentation

Run one branch closing

Bring a menu, recipe, tender report, waste sheet, and closing exception to an industry demonstration.

Book a restaurant demo