Discounts, Offers, Coupons & Happy Hours in Meztezz

Every restaurant gives money away. The question is whether it gives money away on purpose, with the owner’s knowledge and the right paperwork, or by accident — through a cashier who keyholes “10% off” on every third bill because it’s faster than explaining why not. A discount system is really a control system: it makes generosity visible, taxable correctly, and reportable so an owner can see what’s working and what’s leaking. That’s the lens for this post.

This guide walks through every way Meztezz lets you take money off a bill — line-level discounts, whole-bill discounts, configured offers, coupon codes a guest brings to the counter, and happy-hour rules that fire on the clock — plus the single rule that ties them all together: only one promotion mechanism applies to a bill at a time. It picks up after Settling Bills, Payments & Splits (the billing screen is where every lever lives) and runs alongside the GST treatment covered in End-of-Day: Day Close, Z-Report & Cash Reconciliation.

💡 Where these live in the app. All five mechanisms — item discount, bill discount, offers, coupons, happy hours — live on the billing screen on the main terminal. Offers are configured under Settings → Offers (the tab is titled “Offers & Promotions”); discount reasons are seeded and coupon codes arrive via sync, so neither is authored on the terminal. There’s a dedicated Discounts report on the cloud dashboard at Reports → Discounts.

The Walkthrough at a Glance

Part	What you’ll learn
1. The Mental Model — Three Levers, One at a Time	The five mechanisms grouped into three buckets, and why only one fires per bill.
2. Item-Level Discount — The Cashier’s Quick Fix	Long-press a line, percentage or flat, manager PIN if it crosses the threshold.
3. Bill-Level Discount — Apologies, Manager Comps & Promotions	The whole-order lever, the reason dropdown, the approval gate.
4. Discount Reasons — The Two-Minute Setup That Pays Back Forever	Why “Other” should be the exception, not the rule.
5. Manager PIN, Caps & Who’s Allowed	Two settings, one PIN, one “Comp” rule.
6. Offers — When the Promotion Should Be a Rule, Not a Keystroke	The six offer types and what each is for.
7. Configuring an Offer — The Common Patterns	Days, times, order types, minimums, customer rules.
8. Happy Hours — Offers With a Clock	The same engine, the time-window twist.
9. Coupons — A Code Your Customer Brings to the Counter	Validation, expiry, per-customer limits.
10. The Stacking Rule — Why You Can Only Pick One	The single hardest-coded rule in the discount engine.
11. Tax, GST & What Each Lever Touches	Section 15(3)(a) in plain English, and where each lever lands on the invoice.
12. Loyalty Is Not a Discount — A Small Clarification With Big Consequences	Why redeeming points is a payment, not a trade discount.
13. What Refunds and Cancels Do to a Discounted Bill	Offer re-evaluation, BOGO halves, refund proportions.
14. Discounts on the Bill, in the KOT, and in the Reports	What prints, what shows on screen, what the dashboard surfaces.
15. Captain App, Aggregators & Other Edge Cases	Where discounts can and can’t be applied.
16. Honest List of What Meztezz Doesn’t Do (Yet)	Limits to know before you build a marketing plan around them.
17. Habits That Save You Later	Five disciplines that keep the discount line honest.

Part 1 — The Mental Model — Three Levers, One at a Time

Five mechanisms sounds like a lot. It collapses neatly into three buckets, and the bucketing is what makes the rest of the post easy to keep straight.

Bucket	Mechanism(s)	Who decides
Manual discount	Item-level discount, bill-level discount	The cashier (often with manager approval) at the moment of billing.
Configured promotion	Offers (BOGO, combo, volume, category, first-time, happy hour)	The owner, ahead of time, via `Settings → Offers`. Offers auto-apply when conditions match; the cashier can also pick a matching offer from a list.
Coupon	Coupon codes the customer presents	The code is created off-terminal (seeded or synced in); the customer types or shows it; the cashier validates it on the bill.

The single most important sentence in this post: only one of these three buckets applies to a given bill. You cannot put a manual discount and an offer on the same bill. You cannot redeem a coupon and apply a manual discount on the same bill. The terminal blocks every combination in the app. For one specific pairing — a manual discount and an offer — the database also has a trigger that rejects it as corrupt data even if something tried to sneak it through sync. Coupon exclusivity (coupon-plus-manual, coupon-plus-offer) is enforced in the app rather than by that trigger, because a coupon’s discount is stored in the same field as a manual discount.

Why so strict? Because stacking rapidly becomes impossible to reason about (does the 10 % bill discount apply before or after the BOGO freebie? Before or after the coupon’s percent off?), impossible to report on cleanly (which line in the discount report does each portion belong to?), and impossible to defend at audit time. The single-lever rule is the unglamorous discipline that keeps the discount column on your monthly report meaningful.

Loyalty redemption sits outside this trio entirely — it’s a payment method, not a discount. Part 12 returns to that.

Part 2 — Item-Level Discount — The Cashier’s Quick Fix

The line-level discount exists for the small, line-specific case: a dish came out wrong, a guest’s mango lassi was undrinkable, the kitchen sent the wrong protein. The fix is one line, not the whole bill.

2.1 Applying One — Billing Screen → Long-press a Cart Line

Long-press (or right-click) the line in the cart. The Item Discount sheet opens. You see:

The item name and the current price for that line.
A type toggle — Percentage (%) or Fixed (₹).
Quick-pick buttons — 10 %, 20 %, 25 %, 50 % for percentage; ₹20, ₹50, ₹100, and a fourth button showing half the line total as a rupee amount (e.g. ₹120 on a ₹240 line) for fixed amount.
A reason dropdown (see Part 4), with an Other option for the catch-all case.
A Comp button at the bottom (covered in Part 5).

Tap a quick pick or type a custom amount, choose a reason, hit Apply. The line shows the discounted total in the cart, with the reason printed underneath the line.

2.2 What Item Discount Touches

The line subtotal goes down by the discount amount.
The bill’s tax base goes down by the same amount (the line’s taxable value drops, so the GST on that line drops too — Section 15(3)(a) CGST treats discounts as reducing the value of supply).
On the printed bill the amount folds into the single Discount line near the totals (see Part 14.1) — it isn’t printed as a per-line sub-line.
The cloud dashboard records it under manual discounts, separate from the offer-discount bucket.

2.3 What It Doesn’t Touch

Service charge, packaging fee, and delivery fee are computed on the full bill (not the discounted subtotal) — discounts only reduce the goods value, never the operator’s charges. This is intentional and matches the legal treatment.
Modifiers on the discounted line (e.g. Extra Cheese on a half-price pizza) are not separately discounted unless you also tap them — usually they should be, but the system doesn’t assume.

Part 3 — Bill-Level Discount — Apologies, Manager Comps & Promotions

The whole-bill lever is for everything that isn’t tied to one specific item — a regular guest, a soft-launch promotion, an apology for a slow service night, a manager’s discretionary “look after them” gesture.

3.1 Applying One — Billing Screen → Apply Discount

Tap Apply Discount in the billing header (next to the Settle button). The Bill Discount modal opens with:

The current subtotal (after any item-level discounts).
A type toggle — % or Flat.
Quick-pick buttons — 5 %, 10 %, 15 %, 20 %; or ₹50, ₹100, ₹200, ₹500 for flat.
The reason dropdown (Part 4).
A threshold warning banner if the resulting amount will require manager approval (Part 5).

Tap the value you want, pick a reason, hit Apply. The cart’s total recomputes live. Tax recomputes on the new, lower base. The discount shows as a clearly labelled Discount line on the bill, with the reason in the line just below.

3.2 Why It’s Separate From the Item-Level Lever

You might be wondering why both exist. Two reasons:

Reporting clarity. The dashboard breaks discount usage down by lever — line vs bill — so an owner can tell whether the kitchen is making mistakes (line discounts spiking) or the staff is over-generous on whole bills (bill discounts spiking). One number wouldn’t tell that story.
Audit traceability. A line discount is tied to one specific cart line and its reason; a bill discount is tied to the order as a whole. When you’re chasing “why was this bill discounted?” three months later, the level you applied it at is itself a clue.

You can have multiple item-level discounts on the same bill (one per line that needed one). You can also have one item-level discount and a bill-level discount on the same bill — that’s not stacking offers, it’s two different cashier-applied corrections. What you cannot do is mix any of these with an offer or a coupon — that’s the rule from Part 1 and the deep dive is in Part 10.

Part 4 — Discount Reasons — The Two-Minute Setup That Pays Back Forever

Both the item and bill discount sheets force a reason. The reason list comes pre-seeded, and knowing what’s on it day one pays back every month at report time.

4.1 The Seeded Reason List

The terminal ships with a fixed set of discount reasons, read-only on the terminal (there’s no on-device editor — the billing sheets simply read the list). Each reason carries:

A label (what the cashier picks). The seeded set is: Regular customer, Manager discretion, Delayed service, Special occasion, Promotion, Staff meal, Complimentary, and Other.
A requires approval flag (some reasons always need manager PIN regardless of amount — Manager discretion, Staff meal, and Complimentary are seeded that way).

You don’t curate this list on the terminal; it’s the same eight reasons everywhere. That keeps the report groupings consistent across terminals, and Other is there for the genuine edge case that none of the others fit.

4.2 Why It Matters

Every discount in your monthly report is grouped by reason. Delayed service spiking week-over-week is an operational signal (something is going wrong in service). Manager discretion spiking is a different signal (one specific manager being generous on their shifts). Promotion spiking is good news (your Tuesday promotion is working). One field, three different conversations — and you can’t have any of them if every discount is labelled Other.

The discipline: train the team to pick the closest seeded reason and keep Other for the genuine edge case. The list itself is fixed, so the work is habit, not setup.

Part 5 — Manager PIN, Caps & Who’s Allowed

Discounts are the easiest way to make a bill walk out the door for less than it should. The controls in Meztezz are deliberately blunt and easy to explain.

5.1 The Caps — `Settings → Security`

There’s no separate “Limits” screen. The discount controls live in the Security tab, under its Discount Controls section.

Cashier Discount Limit. A percent (default 10 %) — the highest discount a cashier can apply before a manager PIN is required. Set it for the staff, not the manager; managers approving with a PIN aren’t bound by it.
Discount Approval Threshold. Shown here too (the rupee amount above which any discount needs approval — covered in 5.2).

Under the hood there’s also a flat-amount ceiling: if no maximum discount amount is configured, the discount modal falls back to a ₹5000 cap, so a cashier can’t unilaterally take more than that off any single bill.

5.2 The Approval Threshold

Discount approval threshold (default ₹500). If the amount of the discount (not the bill total — the amount taken off) exceeds this, a manager PIN is required before the discount is applied. The modal asks for the PIN inline; an unknown or wrong PIN blocks the discount.

The threshold lets routine Customer complaint discounts of ₹50 or ₹100 happen at speed without paging the manager, while genuinely large takes (anything over your threshold) always get a second pair of eyes. Set it to roughly the size of a typical small comp at your restaurant.

5.3 The “Comp” Button — Always Manager-PIN

Both the item and bill discount sheets have a separate Comp button. Comp is 100 % off — the line or the bill goes to zero. Because it’s the bluntest discount possible, it always requires manager PIN, regardless of any threshold, with a free-text reason mandatory. Cooperative restaurants tend to use Comp for things like Owner table, Staff meal, Influencer comp — not for routine customer goodwill.

5.4 What’s Not There

There’s currently no per-cashier discount cap (you can’t say “Asha can comp ₹500 but Vikram can only comp ₹100”). All caps are restaurant-wide. If you need to constrain a specific cashier, the practical workaround is to set the threshold low and let manager PIN be the per-cashier gate.

Part 6 — Offers — When the Promotion Should Be a Rule, Not a Keystroke

A manual discount is a one-off. An offer is a rule that the owner sets up once and the system enforces every time the conditions match. The point isn’t to save the cashier a keystroke — it’s to make the promotion reportable as itself, and to take the negotiating-with-the-guest pressure off the cashier.

The six offer types Meztezz ships:

Type	What it does	Typical example
BOGO	Buy one of item X, get one of item Y free (Y may equal X).	”Buy one Butter Chicken, get one Naan free.”
Combo	A defined set of items together sells at a fixed combo price.	”Pasta + Garlic Bread + Soft Drink = ₹399.”
Volume	A discount kicks in once the bill (or quantity) crosses a threshold.	”10 % off when the bill is over ₹1000.”
Category	A flat percent off every item in a category.	”20 % off all desserts.”
First-time	An offer that only applies to a customer’s first order (looked up by phone).	“15 % off your first delivery order.”
Happy hour	Any of the above, but only fires inside a configured day-and-time window.	”30 % off beers, Mon–Thu, 5 PM–8 PM.”

Each is a rule, not a keystroke. The owner sets the conditions and, by default, the offer auto-applies when a bill matches (you can turn auto-apply off per offer if you’d rather the cashier pick it deliberately). The promotion is recorded under its own name, not as “manual discount – other”.

Part 7 — Configuring an Offer — The Common Patterns

You configure offers under Settings → Offers (tap Create Offer). The fields are roughly the same across the six types; what differs is which fields matter.

7.1 The Common Fields

Field	What it controls
Name	What the cashier sees and what prints on the bill (Combo Tuesday, Beer Happy Hour, Welcome 15). Keep it short and human.
Type	One of the six in Part 6.
Discount value	A percent or a flat amount, depending on the type.
Max discount cap	Optional ceiling — “give 30 % off but never more than ₹500” — to prevent a giant order from running away with the promotion.
Minimum order amount	The bill must be at least this much for the offer to apply.
Applicable days	Which days of the week (Mon–Sun checkboxes).
Applicable hours	Start and end time (24 h) — for happy hours and other windows.
Applicable order types	Dine-in, takeaway, delivery — any subset.
New customers only	Restricts the offer to customers without prior orders (looked up by phone).
Usage limit	Total times this offer can be redeemed across all customers.
Per-customer limit	How many times a single customer can use it.
Valid from / valid until	The window in which the offer is even visible.
Auto-apply	On by default — the offer applies itself whenever a bill matches. Turn it off if you’d rather the cashier pick it deliberately.
Priority	If multiple offers qualify, the one with higher priority sorts to the top of the cashier’s pick list.
Items / categories	Which items the offer applies to (BOGO: buy item, free item; category: which categories; combo: which items make up the combo).

7.2 The Pattern Most Restaurants Land On

If you have nothing today and want to start, this is a sensible first three offers to set up:

Volume — 10 % off bills over ₹1500. Drives ticket size, predictable, easy to explain to the team.
First-time — 15 % off the first order. Drives new-customer acquisition, especially on delivery and aggregator-adjacent business. Per-customer limit = 1.
Happy hour — your slow window. If your bar dies between 4 PM and 6 PM, a “30 % off bar menu, weekdays only” offer is exactly the lever for it.

Run those three for a month, look at the dashboard’s Discounts report, and decide what to add or kill from there. Three real offers used a thousand times each tells you more than thirty offers used twice.

7.3 The Anti-Patterns

A few patterns that look smart but produce noise:

Twenty offers, none of them used. Cashiers stop scrolling and apply Other – manual discount instead.
Offers with the same conditions and different discounts. The priority field tries to disambiguate, but cashiers still pick wrong sometimes. Merge.
Offers that should be a permanent price change. If “20 % off all desserts” runs forever, that’s actually a price drop — change the prices, retire the offer.

Part 8 — Happy Hours — Offers With a Clock

Happy hour isn’t a separate system; it’s an offer with applicable days and applicable hours set. Everything in Part 7 still applies — the type field is just happy_hour, and the time window is what makes it qualify.

A few practical notes the offer screen doesn’t shout about:

The clock is the terminal’s clock. Make sure the terminal date/time is correct, especially after a power cut or a manual reboot. A terminal that thinks it’s 2 PM when it’s actually 6 PM will miss your evening happy hour silently.
The window is inclusive at both ends. The terminal compares the order time to the start and end as HH:MM (hours and minutes — seconds don’t enter into it). A 5 PM–8 PM window covers everything from 17:00 through 20:00, and an order placed exactly at 8:00 PM still qualifies. Set the end time to the last minute you want included.
Order creation time is what counts. If a guest sits down at 7:55 PM and orders at 8:05 PM, happy hour is over for them. There’s no “they walked in during happy hour, honour it” leniency — and that’s intentional, because otherwise the rule becomes a judgement call and cashiers will lean different ways.
Happy hour does not stack with anything else. A guest already on a manual discount or a coupon doesn’t also get happy hour. Pick the better one (the cashier sees both options and picks the one with the larger discount value).

Part 9 — Coupons — A Code Your Customer Brings to the Counter

A coupon is an alphanumeric code (e.g. WELCOME15, MEZTEZZ500) that the guest types or shows. Unlike an offer (which the cashier picks from a system-suggested list), a coupon needs the guest to know it exists.

9.1 Where Coupons Come From — Not Authored on the Terminal

There’s no coupon-creation screen on the terminal. Coupons are defined off-device — seeded or pushed in via sync — and the terminal only validates, applies, and removes them at the counter. So the things a coupon carries (its code, discount type and value, minimum order amount, valid-from / valid-until window, eligible order types, total usage limit, and per-customer limit) are all set wherever the coupon is authored, not on the billing terminal. From the terminal’s side, the relevant action is redeeming the code, covered next.

9.2 Redeeming One — Billing Screen → Apply Coupon

The cashier taps Apply Coupon, types the code the guest provided, taps Check. The system validates:

Code exists, is active, isn’t expired.
Bill meets the minimum.
Order type is eligible.
Usage and per-customer limits haven’t been hit.
(If the coupon is restricted by phone) the customer’s phone matches the eligible list.

If everything passes, the coupon’s discount is applied to the bill. If anything fails, the cashier sees a clear, specific reason (“Coupon has expired”, “Minimum order amount is ₹X”, “You have already used this coupon”) rather than a generic error.

9.3 Coupons vs Offers — When to Use Which

The right question is who needs to know the promotion exists?

Offer — anyone walking in. The cashier sees it and applies it. Use offers for Tuesday Combo Night, Happy Hour, 15 % off first-time delivery.
Coupon — only the customer who has the code. Use coupons for Influencer code, Welcome-back-email code, Festival giveaway. The code is the gate.

If everyone walking in qualifies, it’s an offer. If only specific people qualify and they prove it with a code, it’s a coupon.

Part 10 — The Stacking Rule — Why You Can Only Pick One

This is the single hardest-coded rule in the discount engine, the one that’s worth reading twice.

10.1 What Doesn’t Stack

A manual discount (item or bill) and an offer cannot coexist on the same bill. The terminal blocks the second one, and this is the one combination the database also guards: a trigger rejects any order row that carries both a manual discount amount and an offer discount amount, even if some custom integration tried to push it through sync.
An offer and a coupon are treated the same way at the bill level — the cashier picks the lever they want, not both. This exclusivity is enforced in the app’s billing logic rather than by that trigger, because a coupon’s value is stored in the same field a manual discount uses.
Two offers do not stack — the applicable-offers sheet says, in plain English, “Only one offer can be applied at a time”.

10.2 What Does Stack

A few things are not in the “one promotion at a time” rule and are easy to muddle:

Multiple item-level discounts on different lines of the same bill — those are fine, because they’re treated as line-level corrections, not bill-level promotions.
One item discount on one line, plus a bill-level discount on the whole bill — also fine, because both are manual corrections from the same cashier-keystroke bucket.
Loyalty redemption with an active offer or coupon — fine, because loyalty is a payment method (Part 12), not a discount, so it lives outside the trio.

The clean way to think about it: “manual corrections” are one bucket and can co-occur freely within that bucket. “Promotions” (offers + coupons) are another bucket, and only one promotion lever fires per bill, ever. Loyalty is in a third bucket entirely (payments).

10.3 Why Not Just “Best of Both”?

A common request is “if a guest qualifies for two offers, give them whichever is bigger automatically”. Two reasons we don’t:

Audit lineage: when only one offer is recorded, every rupee of discount has a single, named source. A “best-of” combine would record a compound discount whose reasoning is hard to reconstruct months later.
GST defensibility: under Section 15(3)(a), a discount must be “duly recorded in the invoice issued in respect of such supply”. A single named offer is duly recorded; a synthetic best-of is messier to defend.

When two offers qualify, the cashier sees both in the picker (sorted with the larger discount first by default) and picks one. The picker shows the rupee value so the guest can see the choice. If you wanted a “best of” UX, build a habit: cashier always picks the top of the sorted list.

Part 11 — Tax, GST & What Each Lever Touches

Discounts in India are governed by Section 15(3)(a) of the CGST Act — a discount that’s recorded on the invoice at the time of supply reduces the value of supply, and tax is computed on the reduced value. Meztezz follows this exactly.

11.1 The Bill Computation Order

For an Indian GST regime, the calculation chain on every bill is:

1. Subtotal (sum of item lines × quantity)
2. − Discount (item-level totals + bill-level)
3. + Service Charge (computed on full subtotal, not discounted)
4. + Packaging / Delivery (computed on full subtotal, not discounted)
5. + CGST (on the discounted goods value)
6. + SGST (on the discounted goods value)
7. + VAT (on liquor, if any)
8. − Loyalty Redemption (a payment, not a discount)
9. ± Round Off
10. = Final total

Read step 2: the discount lands before tax is calculated. Read step 3 and 4: service charge and packaging are not reduced by the discount — they’re on the full subtotal. Read step 8: loyalty is subtracted after tax, because it’s a tender, not a price adjustment.

11.2 Which Lever Reduces the Tax Base

Item-level discount — yes, the line’s taxable value goes down, so the GST on that line goes down with it.
Bill-level discount — yes, the whole bill’s taxable value goes down, so the GST totals go down with it.
Offer discount — yes, treated as a discount on the bill (the offer is named in the invoice, satisfying the “duly recorded” requirement).
Coupon discount — yes, same as an offer.
Loyalty redemption — no. Loyalty is a payment method; the tax was already computed on the full goods value. (Part 12 explains why this matters.)

The principle, in plain words: anything that reduces the price the customer agrees to pay for the goods reduces the tax base. Anything that substitutes one form of payment for cash does not.

11.3 Service Charge, Packaging & Delivery — Not Discounted

Service charge (the optional 5–10 % SC that some restaurants levy on dine-in), packaging fee (the per-order or per-item fee on takeaway/delivery), and delivery fee are deliberately computed on the full pre-discount subtotal. The reasoning is operational: those fees represent your real cost (the staff time the service charge funds, the box the food goes into, the rider’s fee). Discounting the food doesn’t reduce that cost — so the fees stand. The bill makes this transparent; the line shows the SC computed on the gross amount.

If you want a different policy (“service charge should also drop when we discount”), it isn’t currently configurable. Most Indian restaurants follow the not-discounted convention, which is why it’s the default and only option.

Part 12 — Loyalty Is Not a Discount — A Small Clarification With Big Consequences

This is short but matters disproportionately because it’s the single most common misunderstanding when accountants look at the bill for the first time.

When a guest redeems loyalty points (or store credit) on a bill, the redemption appears as a Loyalty line below the tax lines, not as a discount above them. The bill total — the customer-payable amount — is reduced. But the tax is computed on the full goods value, not on the loyalty-net amount. The customer paid the tax in cash + points; the points just substituted for cash.

The legal reasoning is straightforward: loyalty points were earned on prior taxable purchases (where tax was paid). Treating them as a discount on this purchase would amount to tax relief on a prior sale, which the law does not permit. So in Meztezz, loyalty redemption is plumbed as a tender (payment method), not as a trade discount.

The practical implication for an owner:

A bill with a ₹100 loyalty redemption and no discount still shows the full GST in the dashboard’s tax report — and that’s correct.
The dashboard’s Discounts report does not include loyalty redemptions. Loyalty has its own tab.
A guest cannot “stack” an offer with loyalty in the sense of getting both as a trade discount — they get the offer’s discount on the price, and the loyalty redemption on the payment side. Both can apply to one bill because they’re in different buckets.

The full treatment of loyalty — earning, expiry, redemption rules — is the subject of the next post in this series.

Part 13 — What Refunds and Cancels Do to a Discounted Bill

Cancels and refunds were covered in Refunds, Cancellations & Edits After Save. A few discount-specific wrinkles worth pointing out.

13.1 Voiding a Single Line on an Offer Bill

If a BOGO offer was applied (buy one Butter Chicken, get one Naan free) and the guest voids the Butter Chicken before paying, the freebie Naan is also pulled — the offer no longer qualifies. The cart silently re-evaluates and the Naan goes back to its normal price (or comes off the bill entirely if the guest doesn’t want it any more). Same logic for combo offers: take one piece out of the combo and the whole combo price collapses back to à la carte.

This re-evaluation happens on the billing screen, before settlement. After settlement, the rules in the Refunds post take over — voids become same-day corrections, refunds become next-day credit notes.

13.2 Refunding a Discounted Bill

A refund of a discounted bill is proportional by default. If the bill was ₹1000 with ₹200 discount (net ₹800 paid), and you refund 50 % of the order, the refund is ₹400 (50 % of the net) — not ₹500 (50 % of the gross). The customer paid ₹800, so half of that is what comes back. The credit note records the discount line proportionally too.

13.3 Coupon Usage and What Restores It

A coupon’s usage count is restored only when the cashier removes the coupon from the bill before settlement — at that point the count is decremented and the customer can use it again. It is not restored when a settled bill is later cancelled or refunded: those flows free up an offer’s usage slot, but a spent coupon stays spent. So if a single-use welcome code needs to be given back, remove it before the bill is settled; once the bill is paid, cancelling or refunding it won’t return the code to the customer.

Part 14 — Discounts on the Bill, in the KOT, and in the Reports

14.1 On the Printed Bill

The printed bill does not break discounts out per line. Manual discounts (item-level and bill-level) collapse into a single Discount line near the totals, labelled with the reason when there is one — e.g. Discount (Delayed service) -Rs. 150, or just Discount -Rs. 150 if no reason is carried.
A coupon folds into that same line, shown as the reason — e.g. Discount (Coupon: WELCOME15) -Rs. 100.
An offer prints as a single generic Offer Discount line near the totals (the offer’s name does not appear on the printed bill) — e.g. Offer Discount -Rs. 199.
There are no per-item discount sub-lines and no separate FREE / BOGO annotation line on the printed bill — a BOGO or combo simply lands in the Offer Discount total.
The GST lines below show tax computed on the discounted goods value — the customer can see they’re not being taxed on the gross.

14.2 On the KOT

The KOT (the slip the kitchen receives) shows the line, the quantity, and the modifiers — that’s it. The kitchen doesn’t need to know that the line was discounted or that it’s a BOGO freebie; the dish to be cooked is the same. This is deliberate: the kitchen flow stays independent of the pricing flow.

14.3 In the Reports

The cloud dashboard’s Reports → Discounts tab is the owner’s headline view, with:

Manual discounts vs offer discounts — the two headline buckets, kept separate on purpose. A coupon’s value lives in the manual-discount field, so it counts inside the manual bucket; it shows up distinctly in the by-reason breakdown below, not as a separate third number.
Discount count and average discount per order — useful for spotting drift.
Revenue impact — gross sales before discount, and the effective discount rate as a percentage of gross.
Discount by reason — each reason’s count, amount and share of the total (this is where coupon codes and individual reasons surface).
Top discounted orders and a daily breakdown (manual vs offer per day).

The terminal also has its own Discounts report (More → Reports → Discounts), but the cloud view aggregates across outlets and is the one most owners live in. Walk through it weekly; the data is most useful when it’s fresh in memory.

Part 15 — Captain App, Aggregators & Other Edge Cases

15.1 The Captain App Doesn’t Apply Discounts

The captain app (the tablet a captain uses on the floor to take orders) shows the cart, the running total, and any discounts/offers that the main billing terminal has already applied — but the captain cannot apply, change, or remove a discount from the floor. All discount actions go through the main billing terminal (and through manager PIN where required). This is intentional: discount control is a cashier-or-above responsibility.

15.2 Aggregator Orders (Zomato / Swiggy)

Aggregator-originated orders carry their own pricing — the platform’s discount has already been applied before the order reaches Meztezz. Meztezz does not double-apply restaurant offers on top of an aggregator’s promotion; the order arrives at the platform-agreed price and is treated as such. If you need to apply a restaurant-side offer on an aggregator order, the answer is “no” — that would let the platform and the restaurant both pay for the same promotion, which is never what you want.

15.3 Online Orders (Direct Phone / QR)

Direct phone orders and QR-ordering orders run through the same billing screen and respect the same discount rules. Offers configured as applicable_order_types including delivery or takeaway will surface for those orders; offers restricted to dine-in won’t.

15.4 Split Bills

If a bill is split (covered in Settling Bills, Payments & Splits), discounts already applied to the whole bill are split proportionally across the split portions. You don’t get a chance to re-allocate the discount — it follows the goods. If you want a different allocation, void the split and re-do the math on the cart.

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

So you don’t build a marketing plan around something that isn’t there:

No multi-offer stacking. One promotion per bill — described at length in Part 10. If a “10 % off + combo” combination is critical to a launch, build a single offer that bakes both into the discount value.
No per-cashier discount caps. Caps are restaurant-wide. Per-staff limits aren’t yet a setting.
No automatic best-of-offer selection. When two offers qualify, the cashier picks; the system doesn’t auto-apply the larger one.
No customer-specific personalised coupons beyond what you can do with per-customer usage limits. A coupon code is global; you can’t generate one-off codes per customer URL.
No referral discount mechanic. “Refer a friend, both get ₹100” isn’t a first-class flow.
No gift cards. Pre-purchased balances that can be spent later aren’t supported (loyalty / store credit is, but with different mechanics — see the next post).
No A/B testing of offers. Two competing offers fight for share in the picker; there’s no controlled experiment infrastructure.
No service charge / packaging discounting toggle. Discounts only reduce goods value, never charges. If you need a configurable policy, it isn’t there.
No discount on tax itself. You can discount the goods (which reduces tax); you cannot discount the GST line.
No scheduled future offer activation beyond valid_from. An offer can have a start date, but there’s no preview-and-publish staging — the offer goes live exactly when valid_from hits.

Part 17 — Habits That Save You Later

Five disciplines that keep the discount line honest.

Keep your reasons short and use Other only for genuine edge cases. Five to eight active reasons. Review quarterly. A discount report grouped by Other is a report that tells you nothing.
Set the discount approval threshold to a number that matches your typical small comp. Too high and large discounts slip through unchecked; too low and your cashier is constantly calling the manager for ₹50 grants. ₹500 is a reasonable starting point; tune from a month of data.
Build offers, not habits. If you find yourself routinely applying a 10 % bill discount on Tuesdays, that’s an offer waiting to be configured. Offers report cleanly; habits hide in the manual-discount bucket.
Prune offers monthly. Look at the By offer report. Anything used zero times in 30 days should probably be retired or reworked. Twenty stale offers is twenty distractions for cashiers in the picker.
Review the discount line on your Z-Report every night. It’s one number. If it’s bigger than yesterday and you didn’t change anything, ask why before you forget what happened today.

If any of this didn’t behave the way the guide describes — a coupon that won’t validate, a happy-hour offer that didn’t fire when you expected, a manager PIN that’s being asked for at the wrong threshold, a discount that didn’t reduce GST on the bill, or two offers fighting in the picker — 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 discount discipline is steady, the next chapter is the one that turns one-time guests into regulars and unpaid tabs into tracked money: Customers, Credit Balance & Loyalty — the customer master, store credit, loyalty points, and how the repeat-customer data flows from POS to cloud. We’ll publish that one next. 🎉