ORIGINAL RESTAURANT INVESTIGATIONS
Restaurant evidence lab: trace the answer back to the records
A result is useful when you can explain how it was reached. Follow four restaurant questions from small input files to a decision, change an assumption, and check which conclusion survives.
The complete methods and expected answers are available below. JavaScript adds optional scenario controls.
How to reproduce a case
- Download its CSV files and the expected results. Keep an untouched copy.
- Import monetary values as signed integer cents. Divide by 100 only for display. Import record IDs as text.
- Apply the explicitly stated scope, dates and matching rules. A different definition can produce a different answer.
- Compare intermediate steps before comparing the final number. Record an unresolved difference rather than inventing its cause.
The samples work in a spreadsheet or independent script. They are not compatible uploads for the Zomato/Swiggy settlement analyser. For a supported file-processing demonstration, use the existing INR settlement demo and its JSON samples. Read the data dictionary, formulas and reuse permission.
Read the file and column reference
| File | Columns | Meaning in this exercise |
|---|---|---|
| payout-ledger.csv | id, kind, cents | ID identifies a constructed ledger record; kind names its component. Sum signed cents after resolving identical or conflicting IDs as described in Case 1. |
| reported-payout.csv | payout_id, currency, reported_cents, bank_cutoff | The stated payout is separate from the component calculation. bank_cutoff is the inclusive date for the baseline bank review. |
| bank-credits.csv | id, date, cents | Each ID identifies one supplied bank credit. The date controls inclusion; cents is money received. The case assumes these rows belong to its one payout. |
| stock-inputs.csv | daily, leadDays, reviewDays, safety, onHand, inbound, pack, lifeDays | Daily use is kg/day; leadDays, reviewDays and lifeDays are days. All other quantities are kg. onHand means usable stock and inbound means confirmed incoming stock for this simplified case. |
| return-visits.csv | id, customer, date | ID identifies one visit event; customer is a fictional grouping key. Date is a calendar date, not a timestamp. Only observations through the stated coverage end are available. |
| cash-opening.csv | date, currency, opening_cents | The balance is available before the dated movement rows begin. It is not another customer receipt. |
| cash-events.csv | id, date, description, cents | Positive cents add cash and negative cents remove it. Order by date, then ID for these records; this file has one event per listed date. |
| expected-results.csv | case, metric, value, unit | Each row names one baseline metric. Read unit before comparing value: money uses USD cents, stock uses physical quantities, and the feedback rate is a percentage. |
The JSON download contains the same case inputs. The results CSV records the baseline; scenario changes need their own recalculation. These field names are our teaching schema, not a provider's data dictionary.
Case 1: a later bank credit does not explain a calculation gap
The question: an invented restaurant sees USD 10,000 of starting sales, a reported payout of USD 7,480 and only USD 4,500 in its bank review. Which difference can it explain?
The six ledger rows include two identical copies of record L04. The repeat has the same ID, label and amount. Keep one copy; if any copy disagreed, stop and resolve the conflicting records before choosing a value. After that check, five distinct rows remain.
| Record | Component | Signed amount |
|---|---|---|
| L01 | Restaurant sales | 10,000.00 |
| L02 | Refund | −500.00 |
| L03 | Platform fee | −1,800.00 |
| L04 | Merchant discount | −300.00 |
| L05 | Settlement credit | +100.00 |
Independent calculation: 10,000 − 500 − 1,800 − 300 + 100 = USD 7,500. The report is USD 20 lower. A missing bank credit cannot explain that calculation difference. The case supplies no adjustment for the USD 20; leave it unresolved.
At the October 6 cutoff, bank record B01 supplies USD 4,500. Record B02 is dated October 8 and supplies USD 2,980. Once that later receipt is included, bank cash matches the reported USD 7,480. The report still differs from the calculation by USD 20. A payment status, an amount match and a component reconciliation answer different questions.
The bank rows are supplied as already assigned to this invented payout. The exercise does not prove that association from bank references. In your own records, matching amounts alone cannot establish which payout a receipt belongs to.
What to do with your own records
Confirm outlet, currency, cycle and the meaning of the starting sales figure. Match each actual adjustment to evidence and each bank credit to a payout reference. The simplified case has no tax classification, currency conversion, chargeback, invoice timing or opening balance. Add those only when supported by your records. Never relabel an unexplained difference as a fee, theft or a recoverable tax amount.
Build a month-end reconciliation · Handle repeated and conflicting records · Choose a payout investigation
Case 2: connect kilograms to whole purchase packs
The question: a kitchen forecasts 6 kg a day, waits two days for delivery and reviews orders every three days. It wants 5 kg of safety stock. Usable stock is 12 kg, confirmed inbound stock is 3 kg and the supplier's pack contains 5 kg. What does this particular order-up-to rule suggest?
- Target: 6 × (2 + 3) + 5 = 35 kg.
- Inventory position: 12 + 3 = 15 kg.
- Positive shortage: 35 − 15 = 20 kg.
- Whole packs: round 20 ÷ 5 upward = 4 packs, containing 20 kg.
- Post-order stock position: 15 + 20 = 35 kg.
For a four-day usable-life allowance, forecast use is 6 × 4 = 24 kg. The post-order position exceeds that simplified allowance by 11 kg. This is a prompt to review pack size, arrival dates and lot expiry, not a food-safety approval or an instruction to discard 11 kg.
Change the pack to 7 kg while keeping daily use at 6 kg: three packs contain 21 kg, bringing the position to 36 kg. The review quantity becomes 12 kg. The pack-rounded result can exceed the target. You cannot round down just to make a cost estimate look convenient.
Check the rule before using the number
Every quantity must use the same unit. The model assumes the inbound quantity is usable and arrives in time. It does not reserve stock for committed orders, allocate separate expiry lots, consider storage limits or model supplier minimums. “PAR” and “reorder point” can describe different policies; this case states its own order-up-to formula. Confirm which policy your kitchen uses.
Plan multiple stock items · Check recipe quantities and yield · Review supplier and receiving evidence
Case 3: count returning customers with a fair observation window
The question: does a small visit log support a 14-day repeat-visit rate? The log contains 17 visits by ten fictional customer IDs. A visit is the unit recorded here; it is not a verified person, an order or a measure of profit.
Use the first observed visit for each ID, not a claim that the customer has never visited before. At October 22, customers F01–F08 have complete 14-day observation windows. F09 first appears October 15 and F10 first appears October 20, so both are excluded from that denominator. F10's quick second visit does not make its incomplete window complete.
| Customers | Outcome | Reason |
|---|---|---|
| F01, F02, F03, F06, F08 | Five returners | Later visit falls after first date and within 14 days, inclusive |
| F04, F07 | No observed return | No second visit in the log |
| F05 | No return within window | Second visit is 15 days after first |
| F09, F10 | Excluded | Less than 14 days of follow-up |
The answer is 5 ÷ 8 = 62.5%, with two incomplete observations excluded. Dividing five returners by 17 visits mixes units. Including customers simply because they returned early can also bias the result. Neither number proves that a complaint response, discount or menu change caused loyalty.
Observation coverage ends October 22, 2026. Choose that date or an earlier cutoff. A later date would require additional observed records; the absence of later visits in this file does not prove that customers failed to return.
Interpret the change carefully
A shorter window can change both who qualifies and which returns count. A later cutoff can mature a customer without adding a new visit. In this exercise, that comparison is valid only while both cutoffs remain within the log's stated observation coverage. Compare cohorts with matching definitions and exposure periods before making a business claim. The log has no customer consent, identity-resolution, acquisition-source, complaint or intervention data; it cannot establish those facts. Use authorised pseudonymous records for your own analysis and protect the underlying identities.
Turn feedback into a defined improvement · Trace order accuracy and refunds · Understand public review practices
Case 4: positive month-end cash can hide a payment-day shortfall
The question: an invented business begins with USD 1,200. Its four-week closing balances are positive. Can it pay every bill on time?
The October 2 receipt adds USD 1,600 and the October 3 payment removes USD 900, leaving USD 1,900. A USD 2,200 supplier bill is due October 9. The next receipt, USD 1,400, is dated October 11. At the October 9 step, the running balance reaches −USD 300. Later receipts bring closing cash to USD 1,500. The closing amount does not remove the earlier need for USD 300.
Keep the opening balance separate from receipts. Add each signed event once, in date order. This small file has one event per listed date; a real day's multiple payments require an intraday order or an explicit conservative assumption. None of the receipt dates is a platform payout promise.
A scenario is not an agreed term
Moving the supplier bill after the October 11 receipt raises the lowest balance to USD 1,100 while leaving closing cash unchanged. This only shows timing sensitivity. It does not authorise late payment, prove the supplier will agree, recommend borrowing or include financing costs. Confirm actual terms, restricted cash, overdraft access, tax dates and commitments separately. If dates are uncertain, show that uncertainty explicitly.
Build a longer cash forecast · Apply a manual AED cash-calendar method · Separate opening spending from runway
Where the evidence comes from
- Constructed records and expected answers
- Food Data Extractor created these fictional records to expose a duplicate ledger entry, two separate payout differences, whole-pack rounding, incomplete follow-up windows and payment timing. The downloadable JSON and CSV files contain the inputs. Expected answers are arithmetic consequences of the stated rules, not observations about restaurant performance.
- Provider and legal facts
- The cases intentionally assume no real platform fee schedule, licensing threshold, payment cycle, tax rate or food-safety limit. The linked guides identify current primary sources where those facts matter. A source discussing a method does not validate every assumption chosen in our model.
- How these examples are produced
- Writing and code use software and AI assistance. Calculation rules, downloadable records, worked steps and limits are published so readers can inspect them. The publisher is responsible for corrections. No independent accountant, regulator or restaurant operator is claimed to have endorsed these examples. See the editorial process.
- Reuse and feedback
- You may copy, adapt and redistribute the fictional sample files with attribution to Food Data Extractor. This permission does not extend to platform trademarks or third-party material. To report an error, send the case name, record ID and calculation step through Support; do not send customer records or credentials.
Download all case inputs as JSON · Download all baseline answers · Inspect the calculation code · Browse existing workbooks and templates