Refunds, Cancellations & Edits After Save in Meztezz

Real restaurants run on improvisation. The guest changes their mind after the captain has already called the order. A cashier rings the wrong item at the wrong table. A dish goes back to the kitchen because it isn’t right. A whole bill needs to come off because the table walked out unhappy and the manager comp’d it. None of these are edge cases — they’re a normal Tuesday.

This guide walks through every way Meztezz lets you pull something back after it’s been saved, and — crucially — what each path costs you in stock, tax and audit trail. Pulling things back is allowed; doing it silently is not. Every cancel, void or refund leaves a footprint, and that footprint is the difference between a clean monthly close and an awkward conversation with your accountant. It picks up right after Settling Bills, Payments & Splits — if you haven’t read that one, the paid vs. completed distinction in Part 8 of it is a prerequisite for understanding this one.

💡 Where these live in the app. All the actions in this post live on the billing screen — there’s no separate “refunds” menu. You arrive at them by tapping a sent item in the cart, tapping a KOT in the KOT display panel, or pressing the Cancel Order action on an active or recalled order. The look of the dialog changes depending on what state the order is in, but it’s always the same screen.

The Walkthrough at a Glance

Part	What you’ll learn
1. The Three Things You Might Actually Be Doing	Cancel vs. Void vs. Refund — the only mental model you need.
2. Before You Try to Pull Something Back	Reason lists, manager PINs, permissions, Z-Report status.
3. The Decision Tree	Order state + business date → which regime opens automatically.
4. Cancelling a Whole KOT	When the entire ticket needs to disappear from the kitchen.
5. Voiding an Item Line	One dish from a multi-item KOT — sent and unsent flows.
6. Cancelling an Active or Held Order	No money has changed hands; clean rollback.
7. Voiding a Paid Bill — Same Day	The “we billed wrong, same shift” case. Full and partial. Credit note included.
8. Refunding a Paid Bill — Different Day	After the day rolls over. Same credit note; prior-period adjustment if the day is closed.
9. Picking the Refund Method	Same-as-original, Cash, Card or UPI — for the whole refund.
10. Stock, Tax & Reports — What Each Action Touches	The downstream footprint matrix.
11. Who’s Allowed to Do What	Manager PIN rules, permission grants.
12. What the Kitchen and the Floor See	The “no silent cancel” guarantee.
13. Honest List of What Meztezz Doesn’t Do (Yet)	Limits we’d rather you know in advance.
14. A Few Habits That Save You Later	Small disciplines that pay back at month-end.

Part 1 — The Three Things You Might Actually Be Doing

There are dozens of buttons and dialogs in this area, but only three real operations. Get these straight and the rest of the post is mostly form fields.

Operation	When it applies	What it does to money
Cancel	The order is still active or held — nothing has been paid.	Nothing — there’s no money in the system yet.
Void	The order is paid/completed, and today is still the same business day as the order.	Reverses the payment, generates a GST credit note, money goes back via the chosen refund method.
Refund	The order is paid/completed, and the business day has rolled over.	Reverses the payment, generates a GST credit note, money goes back via the chosen refund method.

A few words make all the difference:

Cancel is free. There is no money to give back, no tax to reverse, no credit note to print. The order simply ceases to exist for the kitchen and the books.
Void and Refund are the same operation on a paid bill — reverse the tender, generate a GST credit note, return the money. There’s only one mechanism under the hood. The difference is purely the label Meztezz puts on it and which tax period the credit note lands in.
The label switches on business date. If the order is from today’s business day, the dialog calls it a Void; if it’s from a previous business day, it calls it a Refund. Either way you get a credit note — the tax law (and your auditor) require it for any reversal of a paid GST invoice.
The one real consequence of the date: a refund against an order from a closed day is recorded as a prior-period adjustment in today’s Z-Report, so yesterday’s close stays sealed.

Meztezz picks the label for you automatically based on the order’s state and date — you don’t have to choose. But you should know which one you’re in, because the reporting differs.

Part 2 — Before You Try to Pull Something Back

Five things should be true before you find yourself in a “we need to cancel this” moment with a guest standing in front of you.

Prereq	What it is	Why it matters here
Cancel reasons list	A fixed built-in list: `Customer cancelled`, `Wrong order`, `Kitchen error`, `Items unavailable`, `Customer no-show`, `Other`.	Drives the reason dropdown on item and order cancels. (The whole-KOT cancel dialog uses a slightly shorter built-in variant — same idea, minus `Customer no-show`.) Picking `Other` opens a free-text field. There’s no master screen to edit this list.
Refund reasons list	A fixed built-in list: `Customer returned item`, `Wrong item served`, `Quality issue`, `Item not as described`, `Other`.	Used in the void/refund flow. Pick the most accurate one — these roll up in your refund report. `Other` opens a free-text field.
Manager PINs	`Settings → Users`	Cashiers cannot self-approve a refund. Every refund needs a manager-level PIN.
Role permissions	`Settings → Roles`	The actions in this post (`kot:cancel`, `order:cancel`, `order:void`, `payment:refund`) are role-gated. Cashier role usually has none of the refund actions; owner/manager has all.
Z-Report status	`Reports → Day Close`	A refund of an order whose Z-Report has already been closed is allowed but warned — it records as a prior-period adjustment. You should know whether today’s Z-Report is open or closed before you start.

The reason lists are built in — you can’t add your own entries. If Other is the most-used entry on your cancel report at month-end, lean on the specific reasons that are in the list before reaching for Other — a typed-out free-text reason is harder to roll up than a fixed label.

💡 Manager PINs are not theatre. The cashier-asks-the-manager rhythm is the single most effective control against shrinkage in a busy restaurant. Don’t share PINs, don’t disable the PIN prompt, and don’t have one PIN that “everyone knows”. A manager standing at the till for ten seconds is the cheapest fraud-prevention system you’ll ever buy.

Part 3 — The Decision Tree

When you press a cancel action in Meztezz, the dialog that opens reads the order’s state and date in the background and configures itself. Here’s the tree it walks, so you know what to expect when you tap.

Is the order paid/completed?
├── No  → Cancel mode.
│        Manager PIN required only if any KOT
│        has reached preparing / ready / completed.
│
└── Yes → A GST credit note is generated either way.
          Manager PIN always required.
          Is the order's business date == today?
         ├── Yes → Labelled "Void".
         │        Credit note lands in today's books.
         │
         └── No  → Labelled "Refund".
                  Credit note lands in today's books;
                  if the day's Z-Report is closed, it's
                  recorded as a prior-period adjustment.

The dialog header changes label accordingly — Cancel Order vs. Void Order vs. Refund Order — so the cashier always knows which label they’re committing to. The action button at the bottom also reflects it: Cancel, Full Void / Partial Void, or Full Refund / Partial Refund. Remember: Void and Refund are the same operation underneath; the header is just telling you whether the order is from today’s business day or an earlier one.

The “is the order’s business date today” check uses business date, not calendar date. If your restaurant’s day rolls over at 5 AM (typical for places open late), a 2 AM order is still part of yesterday’s business — pulling it back at 6 AM is labelled a Refund, not a Void.

Part 4 — Cancelling a Whole KOT

A whole KOT cancel is for the “send it again, fresh” case — the kitchen got confused, the paper smudged, the wrong table number went on the ticket. Everything on that one KOT comes back; everything on other KOTs of the same order stays.

4.1 How to Get to It

From the KOT Display Panel (the side panel introduced in the Taking Orders post):

Find the KOT in the list.
Tap the three-dot menu → Cancel KOT.

The Cancel KOT dialog opens with a reason picker (the built-in cancel reasons + Other, which opens a free-text field) and — if the KOT has already advanced past pending — a manager PIN field.

4.2 What Happens Underneath

The KOT is marked cancelled, and its item lines come off the bill. The cancellation is preserved in the audit log (cashier, reason, time) rather than being left behind as live “cancelled” rows.
The cancellation is logged in the audit trail with cashier, manager (if PIN was used), reason, and timestamp.
Stock handling depends on KOT status at the moment of cancellation:
- KOT still pending (kitchen hasn’t started) → no stock was deducted yet, so inventory is unaffected — there’s nothing to put back.
- KOT already ready (food was prepared) → stock was deducted at the ready transition and is not put back; a wastage record is created instead. The reasoning is honest: the food was physically made, so the ingredients are genuinely gone.
The KDS shows the KOT greyed out with a “Cancelled” callout; a cancel slip prints at the assigned station printer.

4.3 What It Doesn’t Touch

Cancelling a KOT does not cancel the order — as long as other items remain. If the order had three KOTs (tandoor, bar, main kitchen) and you only cancel the tandoor KOT, the bar and main kitchen items are untouched. The order continues; the bill still reflects everything that wasn’t cancelled.

The one exception: if the KOT you cancel was the order’s only remaining one — so nothing is left on the bill — Meztezz cancels the order too and releases the table (dine-in). There’s no empty zero-item order left hanging around.

If you want to send the same items again, just add them to the cart and press F5 — they’ll go out on a new KOT with a fresh KOT number.

Part 5 — Voiding an Item Line

Sometimes you don’t want to scrap the whole KOT, just one dish on it. The guest ordered a paneer tikka, didn’t like it, you’re taking it off the bill. This is an item-line void — one row of the cart, not the whole ticket.

5.1 The Two Sub-Cases

Where the item is in its life cycle determines which permissions apply:

Unsent line (above the divider) — nothing has been fired to the kitchen yet. The line was a draft; deleting it is a one-tap action with no PIN, no reason, no audit trail beyond the order’s normal change log.
Sent line (below the divider) — the kitchen has seen this item. The line is locked; to remove it you go through the Cancel Item dialog.

For the second case, tap the line in the cart → Cancel Item. The dialog asks:

Reason — from the built-in cancel-reasons list (+ Other with a custom-text field).
Manager PIN — required when the KOT carrying this item has advanced past pending. If the KOT is still pending (kitchen hasn’t started), no PIN is needed.

5.2 What Happens

The single item line is marked cancelled (not the whole KOT — the rest of the KOT continues).
The bill recalculates and the cancellation is logged. (A printed cancel slip prints for a whole-KOT cancel — see Part 4 — but not for a single-item cancel, and the kitchen-display screen doesn’t grey out an individual cancelled row.)
Stock follows the same logic as in Part 4: pending → nothing was deducted, so no change; ready → wastage.
The bill subtotal and tax recalculate live in the cart.
If the item was tied to an offer (e.g. “buy 1 get 1 free”), the offer is re-evaluated — pulling one half of a BOGO out drops the offer discount automatically.

5.3 Quantity Voids

If a line is quantity 3 and you only want to refund 1, the dialog has a quantity picker. The math is line-aware: you can void 1-of-3 cleanly; the remaining 2 stay on the bill with proportional tax.

Part 6 — Cancelling an Active or Held Order

The whole order needs to come off. The table is leaving without ordering, the takeaway customer walked off, a held order has been abandoned. No money has been collected, so no money has to be returned.

6.1 How to Get to It

From the open order on the billing screen: header menu → Cancel Order. (For held orders, recall them first via F4, then cancel.)

The dialog opens in Cancel mode — header reads “Cancel Order”, action button reads “Cancel”. You’ll see:

Reason + custom-text-when-Other.
Manager PIN — required if and only if any KOT on the order has already advanced past pending. A brand-new order with one pending KOT can be cancelled by the cashier without a PIN; an order where the bar has already poured drinks needs a manager.

6.2 What Happens

The order status flips to cancelled.
Every KOT on it is cancelled (same Part 4 stock rules per KOT — pending restores, ready becomes wastage).
The table (for dine-in) is released to available immediately.
The audit trail records the cancellation with cashier, manager, reason, time.
Nothing tax-related happens because no tender was ever recorded.

6.3 What About Item-Level Discounts or Offers Already on the Cart?

Discounts and offers on an active order disappear with it — they were never “spent”. The discount counters don’t move. Loyalty earn rules don’t trigger (since no payment was taken).

Part 7 — Voiding a Paid Bill — Same Day

The bill has been settled and the day hasn’t rolled over yet. You realise the cashier billed it wrong, the guest disputed something legitimate at the door, or a manager retroactively comp’d a portion. This is the Void regime.

7.1 How to Get to It

From the order — either still on the billing screen, or recalled from Order History if it’s already closed: header menu → Cancel Order. The dialog opens, reads the order is paid/completed, sees today is still the same business date, and switches itself to Void mode — header reads “Void Order”.

7.2 Full Void vs. Partial Void

The dialog gives you two choices:

Full Void — the whole order, all tenders reversed, table released (dine-in), audit trail recorded.
Partial Void — opens a sub-dialog where you tick the specific items (and optionally Service Charge / Packaging) to void. The order itself stays paid for the rest of the items.

Both require a manager PIN — without exception. Both require a reason (from the refund-reasons list).

For partial void, the sub-dialog shows the bill with each line and quantity, two toggles for Service Charge and Packaging, and a running “Void Amount” total at the bottom. The math respects the original tax base — voiding a Rs. 200 dish on a 5% tax bill returns Rs. 210 (the dish + its tax), not Rs. 200.

7.3 What’s Different from a Refund

Mechanically, nothing. A same-day Void runs the exact same operation as a different-day Refund — it reverses the tender, generates a GST credit note, and returns the money. The word “Void” only signals that the order belongs to today’s business day. So:

A GST credit note is still generated. Any reversal of a paid GST invoice gets a credit note referencing the original bill; the same-day case is no exception.
Tax is reversed in today’s books. Today’s GST output figure goes down by the voided amount, via the credit note.
It’s still your current business day. Because the order is from today, there’s no prior-period adjustment to worry about — the credit note simply sits in today’s Z-Report alongside the original sale.

Money still has to physically go back to the guest. See Part 9.

Part 8 — Refunding a Paid Bill — Different Day

Same operation as Part 7 — but the order is from a previous business day. The day’s Z-Report has either already been closed, or it has rolled over but not been closed yet. Either way, the original sale is “in the books”; we can’t pretend it didn’t happen.

8.1 How to Get to It

Same path: Order History → open the old order → header menu → Cancel Order. The dialog reads the order is paid/completed, sees the business date is in the past, switches to Refund mode — header reads “Refund Order”.

If the order’s Z-Report has already been closed, you’ll see an amber warning at the top of the dialog telling you the Z-Report for that date is already closed, and that the refund will appear as a prior-period adjustment in today’s Z-Report.

This is a warning, not a block. You can proceed; the refund just lands in today’s accounts as a prior-period adjustment rather than re-opening a closed day.

8.2 Full Refund vs. Partial Refund

Same choice as same-day void:

Full Refund — the whole bill comes back, full credit note for the full amount.
Partial Refund — pick specific items (and SC / Packaging toggles), refund only those. Credit note is for the partial amount.

Both require a manager PIN. Both require a reason from the refund-reasons list.

8.3 What’s Different from a Void

Mechanically, the credit note and tax reversal are identical to a same-day Void — Meztezz generates a GST credit note for both. The one thing different here is the period: because the original sale belongs to a previous business day, the reversal is recorded as a prior-period adjustment in today’s books.

A GST credit note is generated. It carries the original invoice number as a reference, the partial-or-full amount, the tax components reversed (CGST / SGST / VAT-liquor depending on what was on the bill). (Same as a same-day Void.)
Today’s books, not yesterday’s. Yesterday’s Z-Report stays unchanged. Today’s GST output figure goes down by the credit-note amount, recorded as a prior-period adjustment. This is what Section 34 of the CGST Act requires; Meztezz follows it.
The Refunds report on the cloud dashboard picks the credit note up automatically. It’s broken down by reason, by method, by authorising manager — see the cloud-dashboard post (coming later in this series).
For liquor items, VAT reversal happens in the same credit note alongside the GST reversal. They’re shown on separate lines because they’re separate tax instruments.

8.4 The “Same Day” Edge

What counts as “same day” is the business date, not the calendar date. Either way you get a credit note — the label and the reporting period are what change. If your day rolls over at 6 AM:

An order placed at 11:55 PM yesterday and pulled back at 1 AM today → still same business day → labelled Void; credit note in today’s books.
An order placed at 11:55 PM yesterday and pulled back at 7 AM today → different business day → labelled Refund; credit note in today’s books, recorded as a prior-period adjustment if that day’s Z-Report is closed.

The rollover hour is set in Settings → System → Business Day → Business Day Starts At. Once you’ve picked it, stick to it — your accountant builds their workflow around it.

Part 9 — Picking the Refund Method

Both voids and refunds end with the question: how is the money going back to the guest? The dialog has a Refund Method dropdown that mirrors the payment-method grid from the Settling Bills post.

9.1 The Choices

Method	When to pick it	Notes
Same as original payment	Reverse using the same tender mix the guest used.	The default. If the guest paid part cash and part UPI, this preserves that split automatically. If the original was Credit (the Khata), this routes the refund straight back to their credit balance — no physical money moves.
Cash	Returning physical notes from the till.	Reduces today’s cash drawer; expect the discrepancy at day-close.
Card	Reversing on the swipe machine (or as a credit to the card).	Capture the approval / reference code.
UPI	Sending the money back via UPI.	Record the UPI reference number for reconciliation.

There’s no separate “Wallet” or “Credit” entry in the dropdown — those four options are the whole list. A credit/Khata refund happens automatically when the original tender was credit and you leave the method on “Same as original payment”; it isn’t something you pick from the menu.

9.2 The Refund Method Applies to the Whole Refund

The Refund Method control is a single dropdown — there’s no split allocator that lets you send part of one refund via cash and part via UPI. Whatever you pick applies to the entire refund amount.

If the guest originally paid part cash and part UPI and you leave the dropdown on Same as original payment, Meztezz returns the money in that same per-tender mix. If instead you want the whole thing back through one channel — say the manager won’t reopen the till after counting, so you push everything back over UPI — pick UPI and the full refund goes out that way. Either way it’s one decision for the whole refund, not a line-by-line split. This still matters at day-close: if any of it goes back as cash, the cash drawer needs to know, and your end-of-day balance has to reflect what actually left the till.

9.3 What if the Original Was Credit?

If the original bill was paid against the customer’s credit (the Khata), the refund goes straight back to their credit balance by default — no cash, no UPI, no physical money movement. Their balance goes up by the refunded amount (or, if they were carrying a negative balance for an advance, becomes less negative).

Part 10 — Stock, Tax & Reports — What Each Action Touches

A single table of the downstream footprint. Pin this to your manager’s wall.

Action	Stock	Tax	Money	Where it shows in reports
Unsent line removed	No impact (nothing went out).	No impact.	No impact.	Nothing — never reached the books.
Cancel sent item — KOT pending	No impact (not yet deducted).	No impact (no tax was committed).	No impact.	Order-edit log only.
Cancel sent item — KOT ready	Wastage record (not put back).	No impact.	No impact.	Wastage report; Order-edit log.
Cancel whole KOT — pending	No impact (not yet deducted).	No impact.	No impact.	KOT log.
Cancel whole KOT — ready	Wastage records.	No impact.	No impact.	Wastage report; KOT log.
Cancel active/held order	Per-KOT (same rules above).	No impact (no payment was taken).	No impact.	Cancelled-orders report.
Same-day Void (paid)	Already deducted at KOT-ready; no reversal.	Reversed via a GST credit note in today’s books.	Refund issued via chosen method.	Refunds report; Tax-reversed KPIs; Credit-notes register.
Different-day Refund (paid)	Same as above — no stock reversal, food was made.	Reversed via a GST credit note in today’s books (prior-period adjustment if the day is closed).	Refund issued via chosen method.	Refunds report; Tax-reversed KPIs; Credit-notes register.

Two non-obvious bits worth calling out:

Once food is made, stock does not come back. This is the “no phantom stock returns” rule. If the kitchen prepared the dish, the ingredients are gone — restoring them in the inventory would lie to your stock reports. We record it as wastage instead. If the kitchen hadn’t started, no stock was deducted in the first place, so there’s nothing to reverse.
Voids and refunds are the same operation — both produce a GST credit note in today’s books. The only difference is the label and the reporting period: a refund against a closed prior day is recorded as a prior-period adjustment. There is no path that re-opens yesterday’s books — and that’s deliberate.

Part 11 — Who’s Allowed to Do What

The permissions are role-gated. You manage who holds each permission under Settings → Roles, and you set each user’s PIN under Settings → Users — they’re two separate tabs. Defaults below — change them to your operation’s discipline, but think before you loosen anything.

Action	Permission key	Default cashier role	Default manager / owner role
Remove an unsent line	(none — implicit in cart edit)	✅	✅
Cancel item — KOT pending	`order:cancel`	✅	✅
Cancel item — KOT ready or later	`order:cancel` + manager PIN	PIN required	✅
Cancel whole KOT — pending	`kot:cancel`	✅	✅
Cancel whole KOT — ready or later	`kot:cancel` + manager PIN	PIN required	✅
Cancel active/held order — all KOTs pending	`order:cancel`	✅	✅
Cancel active/held order — any KOT past pending	`order:cancel` + manager PIN	PIN required	✅
Void paid order (same day)	`order:cancel` / `order:void` + manager PIN	PIN always required	✅
Refund paid order (different day)	`order:cancel` / `order:void` + manager PIN	PIN always required	✅
Reverse a tender / issue the refund money	`payment:refund` + manager PIN	PIN always required	✅
Partial void / partial refund	`order:cancel` / `order:void` + manager PIN	PIN always required	✅

The rule of thumb: anything that takes food back from the kitchen, or money out of the till, needs a manager PIN. Cancelling a draft cart line doesn’t; voiding a paid bill does.

Part 12 — What the Kitchen and the Floor See

The “no silent cancel” guarantee. Every cancellation produces an output the kitchen can see, so nothing disappears without explanation.

12.1 The KDS

If your kitchen runs a Kitchen Display Screen (covered in Part 8 of the Taking Orders post), a cancelled KOT shows up as a cancelled (red) card on the board, so a chef glancing at the pass can see it’s been pulled. (The card flips state as a whole; the KDS doesn’t strike through individual lines or play a sound on a cancel.)

12.2 The Station Printers

When you cancel a whole KOT, a small cancel slip prints at the assigned station printer. Headed “KOT CANCELLED”, it shows the original KOT number, the station, the table/order, the cancelled item(s) and quantities, the reason, and a “Cancelled by” name. The chef gets the same information twice — on screen and on paper — which is the right amount of redundancy in a noisy kitchen.

12.3 The Captain App

The captain who sent the original order sees it reflected as cancelled on their order list — the cancellation reason and time sync across with it. They can communicate it to the guest without walking back to the kitchen.

12.4 The Cloud Dashboard

Cancellations sync up to app.meztezz.com along with everything else. The owner reviewing yesterday’s operations from home sees every cancel with the cashier, the reason and the time — without having to call the manager.

12.5 The Bill Itself

For a void or refund, the original bill is unchanged in your historical records — re-printing it later still shows what was on it at the time of sale. The credit note (for refunds) is a separate document with its own number, referencing the original invoice. This is the structure GST audits expect.

Part 13 — Honest List of What Meztezz Doesn’t Do (Yet)

We’d rather you know in advance.

No “undo cancel”. Once an item, KOT or order is cancelled, that decision is final — you can’t restore it with a single button. To put the items back, add them again to a fresh cart. The cancellation entry stays on the audit trail.
No retroactive stock restoration for ready-KOT cancels. The wastage-vs-restore rule is fixed: if the kitchen marked it ready, the ingredients are wastage forever. This is intentional honesty; we won’t add a “restore anyway” toggle.
No editing a paid bill. You cannot change the items, quantities or pricing on a bill once it’s paid. The path is: void/refund the bill in full → re-create with the correct items. This preserves the audit trail (the wrong bill exists, was voided, and the new one references it via its reason).
No refund-to-different-customer. A refund goes back to the same customer (or the same anonymous till). You can’t refund Customer A’s bill to Customer B’s credit balance.
No partial cancel of a single item line. The line is the unit. If a line has quantity 3 and you want to cancel 1, the dialog has a quantity picker — that works. You cannot split a line into separate cancelled/active halves with different reasons.
No re-opening a closed Z-Report. A Z-Report, once closed, is closed. A refund of an order from a closed day lands in today’s books with a credit note; yesterday’s day-close stays sealed.
No automatic refund-to-card via the swipe machine. Meztezz records that you’ve chosen “Card” as the refund method; the actual reversal on the card network is something you do on the swipe machine itself. We log the reference number you enter for audit, but we don’t talk to the bank’s API.
No cross-outlet refund. A refund happens at the same outlet as the original sale. You cannot refund a bill from Outlet A by handing back cash at Outlet B’s till.
Tip line on the bill. Mentioned in the previous post — still not built in. Means there’s no “void the tip but keep the food” partial path for tips specifically.

If any of these are deal-breakers for your operation, write to us. We prioritise feature work based on what real restaurants ask for, and a clear we need X because Y message goes a long way.

Part 14 — A Few Habits That Save You Later

Pick the most specific reason, not Other. The reason lists are built in (you can’t add your own), but they cover the common cases — Quality issue, Wrong item served, and so on. The reason you pick is the reason that rolls up in your monthly refund report. Reaching for Other and free-typing gives you nothing to group on at month-end.
Train cashiers to call a manager before the swipe, not after. The PIN prompt is supposed to be the manager standing at the till for ten seconds, not the cashier hunting them down after the fact. Build the muscle memory.
Reconcile cash refunds at day-close, every day. A cash refund leaves the till; the till count needs to know. Don’t carry over discrepancies — find them on the day they happen.
Don’t bypass the void path for a “small” error. If you billed Rs. 50 extra and the cashier just hands the guest Rs. 50 from the till “to fix it”, your sales report says you sold Rs. 50 more than you did, and your till is short by Rs. 50. Do the partial void. Always.
Use Quality Issue as your “food sent back” reason, not Other. Quality Issue is what your kitchen will look at to see which dishes are coming back most often. “Other” tells the kitchen nothing.
Print the credit note alongside the original bill when refunding across days. GST audits expect to see them paired. The dialog offers to print both — say yes.
Set a habit of settling disputes within the same business day whenever possible. A same-day void and a next-day refund are the same operation and both produce a credit note — but the same-day case keeps everything in one business day, with no prior-period adjustment to explain at close. If a guest disputes a bill at the door, void it there, don’t tell them “we’ll refund tomorrow”.
Review your wastage report weekly. Ready-KOT cancellations show up there. A spike in wastage often means the kitchen is mis-firing — not that customers are mis-ordering. Use the report to find the operational issue.

Stuck? We’re Here to Help

If any of this didn’t behave the way the guide describes — a refund that’s stuck waiting for a PIN, a credit note that didn’t print, a stock report that doesn’t match what you expected after a cancel, or a refund that landed in the wrong business day — drop us a line at bazimat@gmail.com or contact us. Tell us which Part you’re on and what you’re seeing; we’ll usually have you sorted in a single back-and-forth.

Once your cancel-and-refund discipline is steady, the next chapter is the close-of-day ritual: End-of-Day: Day Close, Z-Report & Cash Reconciliation. We’ll publish that one next. 🎉