Settling Bills, Payments & Splits in Meztezz

The kitchen fired the food, the guest enjoyed the meal, and now they’re asking for the bill. Everything you did on the billing screen was rehearsal for this moment — the actual exchange of money. This is also the moment most POS systems get fiddly: the guest wants to split the bill three ways, one person is paying half in UPI and half in cash, another is putting it on the company credit tab, and the last one wants a printed copy with the GSTIN visible.

This guide is an exhaustive walkthrough of how Meztezz settles a bill — how the payment screen reads, what each of the six payment methods does, how split tenders and partial payments behave, what a re-printed bill looks like, and the single most important distinction in the whole product: “paid” is not the same as “completed”. It picks up where Taking Orders & Sending to the Kitchen left off — if you haven’t read that one yet, start there; this post assumes you already know how a KOT is fired and what the F6 button on the billing screen does.

💡 Where this lives in the app. The payment screen is a modal that opens on top of the billing screen when you press F6 (or its labelled variant — see Part 2). You don’t navigate to it from a menu; you arrive at it because there’s an order ready to settle.

The Walkthrough at a Glance

Part	What you’ll learn
1. Before You Take a Payment	Prerequisites — settings, customer master, printer, permissions.
2. Opening the Payment Screen	The four ways `F6` gets you here and what each does on the way in.
3. Reading the Payment Screen	Total / Paid / Due, the “Payments Made” list, the method grid, the amount field.
4. The Six Payment Methods	Cash, UPI, Card, Wallet, Credit, Complimentary — and what’s special about each.
5. Split Tenders — Paying in Multiple Methods	The guest wants half-UPI half-cash; how to ring it up.
6. Partial Payments — Closing the Bill in Stages	When the guest pays some now and the rest later.
7. Bill Preview & Printing	Print preview, the mandatory-receipt setting, token slips, counter copies.
8. When a Bill Is Truly Closed — Paid vs. Completed	The single most important distinction in the product.
9. When Payment Goes Wrong — Cancelling & Re-collecting	The “needs repayment” state and the recall flow.
10. Reference Numbers & Audit Trail	What gets captured per payment and why it matters at month-end.
11. Bill Line Order, Round-Off & Currency Symbols	India vs. non-India bill anatomy.
12. Honest List of What Meztezz Doesn’t Do (Yet)	Limits we’d rather you know in advance.
13. A Few Habits That Save You Later	Small disciplines that pay back during a busy shift.

Part 1 — Before You Take a Payment

A clean settlement depends on a handful of things being right in your settings before the guest walks up to the counter. Five minutes here saves you the awkward “the system won’t let me…” conversation later.

Prereq	Where it’s configured	Why it matters here
Billing & Tax setup	`Settings → Billing & Tax`	Tax regime, tax-inclusive pricing, service charge and packaging defaults all determine the Total you’re collecting.
Payment methods enabled	`Settings → Payments` (Credit is toggled in `Settings → Credit / Khata`)	Toggle UPI, card, wallet and the rest. Anything you switch off here disappears from the payment-method grid.
Card networks list	`Settings → Payments`	The networks shown in the card sub-picker (Visa, Mastercard, RuPay, Amex…) come from this list. Edit once, used everywhere.
Customer master	`More → Masters → Customers`	Required for the Credit method — credit is always against a named customer, never anonymous.
Printer assignment	`Settings → Printer`	If you want a thermal receipt to print at settle-time, a bill printer must be assigned and reachable.
User permissions	`Settings → Roles` (and `Settings → Users` to assign them)	The actions in this guide are role-gated. Taking a payment needs `payment:process` (with per-method variants `payment:process_cash`, `payment:process_card`, `payment:process_upi`); cancelling a tender needs `payment:refund`. Cashiers usually have process; refund is normally a manager-only action.

If any of these is missing or wrong, fix it now, not at the counter with a queue building behind the guest.

💡 Credit needs both a setting and a customer. The Credit method only appears in the payment-method grid when both the Credit toggle in Settings → Credit / Khata is on and the order has a named customer attached. If you’re expecting to see Credit and it isn’t there, check both.

Part 2 — Opening the Payment Screen

You don’t have a separate “go to payments” menu. The payment screen opens from the billing screen, and the precise behaviour depends on what kind of order it is.

2.1 The Four `F6` Paths

Recall from the previous post that F6 is the context-aware primary button on the billing screen. Here’s what it does on the way to opening the payment screen:

Order type / state	F6 label	What `F6` actually does
Dine-In	`Pay (Complete Order)` for an existing order; bare `Pay` only on a brand-new order	Opens the payment screen. Anything still unsent in the cart won’t be on the bill — fire the KOT with `F5` first.
Takeaway / Delivery Prepaid (new)	`Pay & Send to Kitchen`	Fires the KOT and opens the payment screen in one go. Money first, food next — the standard prepaid flow.
Delivery COD	`Pay`	Same as dine-in. You fire the KOT with `F5`, the rider takes the food, you re-open and settle when they return.
Partially-paid bill	`Pay Remaining`	Opens the payment screen with the remaining balance pre-filled. See Part 6.

In all four cases, what opens on top of the billing screen is the same modal. The only thing that differs is whether a KOT was just fired and whether the Due number has been partly knocked down already.

2.2 What Happens the Instant the Screen Opens

A few useful things happen automatically so the cashier can ring up the most common case (cash, exact amount, dine-in) in three keystrokes:

Cash is pre-selected as the payment method.
The amount field is pre-filled with the Due balance — the most common case is “collect the whole remainder”, so the cashier doesn’t have to type it again.
For cash, the Received field is also pre-filled with the same amount — exact-tender being the default. If the guest hands over more than the bill, the cashier overtypes the Received field and the Change to give line updates live.
If the grand total is exactly zero (a fully-discounted comp or a zero-rupee adjustment), Meztezz switches the method to Complimentary automatically — you cannot accidentally take ₹0 in cash.

The cursor lands on the Add Payment button so the very next key — Enter or Space — closes the bill.

Part 3 — Reading the Payment Screen

The modal is laid out in three vertical bands. Once you know what each one is for, the rest of the post is mostly detail.

3.1 The Summary Card — Top

Three lines, always present:

Total — the grand total of the bill, exactly as it will print. Includes tax and charges.
Paid — the sum of everything already taken on this order. Shown in green with a minus sign so the arithmetic reads top-to-bottom.
Due — the remainder. Shown in green if zero (the bill is fully paid), in primary colour if anything is still outstanding.

For a brand-new settlement, Paid is ₹0 and Due equals Total. For a split tender mid-collection, Paid climbs as you add each tender and Due counts down — see Part 5.

3.2 The Payments Made List — Middle

As soon as the first payment is added, a small list appears showing each completed tender on this bill in order:

Cash       Rs. 1,200.00
UPI        Rs.   800.00

This is the cashier’s running ledger inside the modal — useful when settling a four-way split because the guest can see exactly what’s been put down. The list does not appear at all until the first payment is recorded.

3.3 The Payment Form — Bottom

This is where the work happens, and it stays visible until Due hits zero. The form has four parts:

Payment Method grid — six tiles (filterable; see Part 4), each with a keyboard shortcut shown in the corner: C Cash, D Card, U UPI, W Wallet, R Credit. Complimentary has no shortcut — it’s auto-selected when applicable.
Amount — pre-filled with the remaining due. Editable; for splits you’d type the partial amount the guest is paying via this method.
Method-specific fields — for cash, a Received field and live Change calculator; for card, a Card Network dropdown; for card/UPI/wallet, an optional Reference Number field; for credit, a free-text Notes field instead.
Add Payment button — commits this tender. Auto-focused on open so the common case is keyboard-only.

The whole form re-renders depending on which method is selected — there’s no separate “cash screen” vs. “UPI screen”, just the same form with different fields shown.

Part 4 — The Six Payment Methods

All six are first-class citizens — you can mix any of them in a single bill (see Part 5). Here’s what’s special about each.

4.1 Cash — `C`

The default. The two specifics:

Received amount. Cash has an extra field — Received — for the actual notes/coins handed over. The Change to give line below it updates live. The form refuses to commit if Received is less than Amount. If the guest gives exact change, do nothing: the pre-fill already matches.
Reference number. Not used. Cash is its own paper trail.

💡 Round-off is part of the Total, not part of the cash logic. If your bill has a 23-paise rounding adjustment (see Part 11), it’s already reflected in the Due number — the cashier collects the rounded figure. You should not have to do mental math on the floor.

4.2 UPI — `U`

UPI is a one-shot tender — the guest scans, the money lands, you record it. Two specifics:

Reference number field is shown — record the UPI transaction reference (the 12-digit RRN, or the UPI app’s transaction ID). This is what makes the payment auditable when you reconcile against your bank statement at month-end. It’s optional in the form but a habit worth enforcing.
No amount-mode quirks. Type the amount the guest is paying via UPI; press Add Payment; done.

4.3 Card — `D`

Card behaves like UPI plus a card-network sub-picker.

Card Network dropdown — populated from Settings → Payments → Card Networks. Pick the network the swipe machine reported (Visa, Mastercard, RuPay, Amex, etc.). This is what powers the “card sales by network” view in your reports.
Reference number — the approval code or last 4 digits from the swipe machine slip, as your operational discipline requires. Optional in the form, strongly recommended in practice for chargeback disputes.
Amount behaves like UPI — partial amounts are allowed, no Received line.

4.4 Wallet — `W`

Paytm, PhonePe wallet, GPay wallet, restaurant-specific wallets — anything that isn’t UPI or a card swipe but isn’t cash either. Same form as UPI: amount + optional reference number.

4.5 Credit (Khata) — `R`

This is the “put it on the tab” method, and it has more rules than the others because it’s the one that can lose you money if abused.

Customer required. The Credit tile only appears in the grid when the order has a named customer. If you forgot to attach a customer at billing time, the tile is hidden — go back, attach a customer (More → Masters → Customers), then reopen the payment screen.
Eligibility check. As soon as you select Credit and type an amount, Meztezz calls the eligibility service for that customer. If the customer’s outstanding balance plus this amount would exceed their credit limit (set in the customer master), the Add Payment button is disabled and the form explains why. You can either lower the amount, take part of it in cash, or get a manager to raise the limit.
Notes — a free-text field (labelled simply Notes) for “what is this credit against” — e.g. Diwali bonus, Per agreement with HR. Captured on the payment record so the receivables report tells you not just how much, but why.
Credit balance can go negative. If a customer has paid in advance and then a bill is partly settled against that advance, their balance is negative (meaning you owe them). The dashboard reports handle this honestly; do not “fix” a negative balance by clamping it to zero.

💡 Khata is not a discount. A credit payment is still revenue — the tax is collected, the bill is closed, the kitchen is paid. The only thing different is when the money arrives. Don’t treat credit as a soft “we’ll deal with it later” — chase your receivables on a weekly cadence and your Khata customers will respect the system.

4.6 Complimentary — (no shortcut)

The zero-rupee close. Used when the bill needs to settle for legitimate audit reasons but no money will change hands — full-comp tasting menu for an influencer, staff family meal, owner’s table. (Its tile in the grid is labelled Comp.)

Auto-selected when the grand total is zero. If you’ve discounted the entire bill to ₹0, the modal opens with Complimentary already chosen and the amount field is hidden (fixed at 0). When it’s selected, the action button reads Mark as Comp rather than Add Payment.
Refuses non-zero amounts. If the grand total isn’t zero, the form blocks the close. Comping a portion of a bill is a discount operation on the billing screen, not a payment method.

Part 5 — Split Tenders — Paying in Multiple Methods

This is the “two friends, half on UPI half on cash” case. The mechanics are simple once you see them: you just add more than one payment.

5.1 The Loop

For a bill of Rs. 2,000 where the guest wants Rs. 800 in UPI and Rs. 1,200 in cash:

Press F6. The modal opens with cash pre-selected and the amount pre-filled at 2,000.
Press U (or tap UPI). The method switches; amount stays at 2,000.
Edit the amount down to 800. Optionally record the UPI reference.
Press Add Payment.
The Payments Made list now shows UPI Rs. 800.00. Due is now Rs. 1,200, the form resets to cash, amount pre-filled at 1,200.
Press Add Payment again. Done.

The screen detects fully-paid the moment Due hits zero and switches the bottom of the modal from the payment form to the Print & Complete actions.

5.2 What Counts as a “Split”

There’s no separate “split mode” to enter. Any payment that doesn’t equal the full Due is a split — and the next round of the form picks up the remainder. You can mix any number of methods on a bill — half a dozen separate small UPI taps if that’s what the table wants. Each is its own payment row in the database, which means each appears separately in your “payments by method” report.

5.3 Splitting by Item vs. by Amount

A split tender (what this post is about) splits the money that pays a single bill across multiple methods. A split bill — actually printing two separate bills for the same table so two people can pay separately — is a different operation done on the billing screen via the table split flow described in Tables & Reservations. Once each new bill exists as its own order, you settle each one with its own F6.

💡 Pick your split level deliberately. If two guests want one combined bill paid two ways, that’s a split tender. If they want two separate bills (each with their own GSTIN, each printable separately), that’s a split bill — and it has to happen before you settle.

Part 6 — Partial Payments — Closing the Bill in Stages

Sometimes a tender that was already recorded on a paid bill has to come off — the card swipe is reversed, the guest disputes a method after the fact. When that happens to a bill that was fully paid, it re-opens with a balance still due: a partially-paid bill. (Note this is not how an in-progress settlement works — taking part of the money and stopping leaves the order active, not partially-paid; see below.)

6.1 Putting a Bill into Partially-Paid State

There’s really only one way a bill lands here: cancel a tender on a bill that was already paid in full. Taking a partial tender on an open order and walking away does not create a partially-paid bill — the order simply stays active, with whatever tenders you’ve recorded, and it does not show up in Needs Repayment.

The partially-paid state appears only when an already fully-paid order has one of its tenders cancelled. Cancelling a tender lives in the Order History sheet, not in the payment modal, and only when the order is already paid or completed (see Part 9 for the exact steps). The moment a tender on a paid bill is voided, the bill’s Due re-opens and the order flips to partially paid — which is where it surfaces for repayment.

6.2 What the Order Looks Like Afterwards

On the billing screen, the table (for dine-in) stays occupied — payment is not done, so the table is not done.
On the Recall sheet (F4), there’s a new section labelled Needs Repayment showing every bill in this state (each row carries a PARTIAL or REPAY badge). Tap to re-open the order’s payment screen.
The F6 button on a recalled partial reads Pay Remaining so it’s obvious what’s about to happen.
The amount pre-fill inside the modal is the remaining due, not the full bill.

6.3 The “Split Payment Cancelled” Notice

Because a partially-paid bill always comes from a cancelled tender, the next time the modal opens you’ll see an amber banner at the top:

⚠ Split payment cancelled. Collect the remaining balance to complete this order.

It’s a nudge, not a block — you can take the remainder normally; the banner just explains why this isn’t a fresh settlement.

Part 7 — Bill Preview & Printing

The receipt is the closing act of the transaction. Meztezz gives you several controls so the right paper ends up in the right hands.

7.1 Print Preview — Before You Commit

If the print-preview setting is on (Settings → Printer → Print Preview), the modal shows a preview pane immediately after the last tender is added — a faithful rendering of the thermal-printer output as it will look on paper. The cashier can:

Confirm and print — commits the print job to the assigned bill printer.
Print without preview next time — if your floor wants to skip the preview to settle faster, switch it off in settings.

The preview uses the exact same layout the printer will use, including Rs. (ASCII-safe) for currency and the bill line order described in Part 11.

7.2 Require Receipt Print

In some setups (small restaurants who want a paper trail by default), the Require Receipt Print setting (Settings → Billing & Tax) is on. With it on, the modal will not close until either the receipt has been printed or it’s been explicitly skipped with manager approval. This prevents the “we forgot to give them the bill” failure mode that loses GST credit at audit time. Off by default for restaurants that don’t want it.

7.3 Token Slip

If your operation uses tokens (typical for takeaway counters and quick-service formats), Meztezz can print a small token slip alongside the bill. The token slip shows the token number (auto-assigned), the order items, and the time — it’s the slip the guest carries to the counter to collect their food. The token is captured on the order record itself so re-printing later still shows the original number.

7.4 Counter Copy

Some kitchens want a non-tax counter copy of the bill — a working copy that stays at the counter for handoff coordination. Meztezz can print it as part of the same close-out if enabled in settings.

7.5 Re-printing After Close

If the bill is already paid and you need another copy — guest lost their receipt, accountant wants a duplicate — the Order History sheet has a Reprint Bill action on every paid/completed order. Re-printing doesn’t change anything in the database; it just renders and sends the same bytes again.

Part 8 — When a Bill Is Truly Closed — Paid vs. Completed

This is the most important distinction in the whole product, and it’s the one that trips up almost every new owner. Read this section twice.

8.1 The Two States

Status	What it means	What still has to happen
Paid	The money has been received in full. All tenders add up to the Total, Due is zero.	The kitchen may still be cooking; the table may still be occupied; the guest may still be eating.
Completed	Everything is done — food delivered, table released, audit trail closed.	Nothing. The order is final.

Most takeaway and delivery flows go paid the moment the money hits the system (because the guest paid up front), but only become completed when the food is actually handed over. Most dine-in flows reach paid before completed because the cashier swipes the card while the kitchen is still plating dessert.

8.2 Why It Matters

Reports treat them as distinct states for a reason. “Sales completed today” is not the same number as “money collected today” — the former is operational, the latter is financial. A prepaid breakfast delivery sold at 11:55 PM and fulfilled at 12:05 AM the next day is paid yesterday, completed today. Both views are correct; they just answer different questions.

The paid-vs-completed status is preserved on every order, all the way up to the cloud. (Note that the dashboard’s headline sales figure counts both paid and completed orders together — it’s a “money committed” number, not a “kitchen finished” one.) If a row of numbers ever looks off, ask yourself which status it’s counting — that’s usually where the gap lives.

8.3 The Table-Release Rule

For dine-in orders, the table stays occupied until the order is completed, not when it becomes paid. So a settled bill alone doesn’t free the table. Completion happens automatically once two things are both true: the order is fully paid, and the kitchen has finished all of its KOTs (marked them done on the KDS). There’s no separate “mark complete” button on the billing screen — when the last KOT closes on a paid order, Meztezz completes the order and frees the table on its own. If you ever wonder “why is this table still red after I took the card?”, it’s almost always because a KOT is still open in the kitchen.

💡 A paid bill is not a closed bill. If your front-of-house thinks “card swiped = table free”, you’ll end up double-seating tables on a busy Saturday night. The close-out is: take payment → print the bill → make sure the kitchen closes out its KOTs. The table frees itself the moment the last KOT is done on a paid order.

Part 9 — When Payment Goes Wrong — Cancelling & Re-collecting

Real life: the card swipe failed but the cashier already pressed Add Payment, the guest realises they wanted to pay differently, a manager comp’d something post-facto. The cancel-and-recollect path exists for these.

9.1 Cancelling a Single Tender

Tender cancellation does not live in the payment modal — the Payments Made list there is read-only. It lives in the Order History sheet, and only on an order that’s already paid or completed. Open the order in Order History, find the payment row, and tap the small × beside it (the × only shows when the order is paid/completed and you hold the refund permission). That opens a confirmation:

Reason — pick from a fixed list of five: Customer changed payment method, Incorrect amount, Duplicate payment, Customer request, Other. This list is built into the screen — it isn’t configurable in masters and isn’t shared with KOT cancellations.
No manager PIN. There’s no PIN prompt — just the reason dropdown and a confirm. Who can do it is gated by the payment:refund permission, so it’s normally a manager-level action.

On confirm, the tender is reversed. The bill drops back into partially paid, and the amber banner from Part 6 appears the next time the modal opens.

9.2 The Recall Sheet — Picking It Back Up

A payment-cancelled bill appears under Needs Repayment in the Recall sheet (F4) — same sheet that lists held orders. Tap the row → the modal opens with the remaining due and a button labelled Pay Remaining. Take whatever method the guest wanted in the first place; the previous (cancelled) tender is out of the way.

9.3 What’s Not a Cancel

A successful card swipe that the guest then refunds at home. That’s a chargeback, handled outside Meztezz with your acquirer.
A cash discrepancy at end-of-day. That’s a cash reconciliation issue — handled at Day Close (the post after refunds, coming soon).
Cancelling the whole paid bill. That’s a refund — covered in the next post in this series, Refunds, Cancellations & Edits After Save.

Part 10 — Reference Numbers & Audit Trail

Every payment that hits the database carries more than just an amount.

Captured per payment	When	Why it matters
Method	Always	Drives “sales by payment method” reports.
Amount	Always	Self-evident.
Received amount	Cash only	The difference becomes change given — useful for till reconciliation.
Reference number	UPI / card / wallet	The thread that links a Meztezz payment to your bank statement / settlement report. (Credit doesn’t use this field — it has its own Notes capture below.)
Card network	Card only	Drives “card sales by network” and is needed for MDR reconciliation.
Notes	Credit only	The “why” line for receivables, e.g. Per HR agreement.
Cashier	Always	The user logged into the terminal when the payment was added. Used by the audit trail and the cash report.
Time	Always	When the tender was added (not when the bill was opened).

None of these are optional database columns — the audit trail is the same shape for every payment, and the cloud dashboard expects them in that shape. The reference fields are form-level optional (you can leave them blank), but the discipline of filling them — at least for non-cash tenders — is what makes month-end reconciliation a 10-minute job instead of a 4-hour job.

Part 11 — Bill Line Order, Round-Off & Currency Symbols

A few details about what the printed bill actually says.

11.1 The India Bill Line Order

A bill printed by Meztezz under the India tax regime always lists lines in this order:

Subtotal
Discount
Service Charge
Packaging
CGST
SGST
VAT (Liquor)            <- only if alcohol on the bill
Loyalty Redemption      <- only if redeemed
Round Off
Total

This order is deliberate and matches what Indian tax auditors expect to see. The two non-obvious bits:

Discount sits above tax because tax is calculated on (subtotal − discount) — Section 15(3)(a) of the CGST Act. The discount line is shown so a customer (or an inspector) can verify the tax base.
Loyalty Redemption sits below tax because loyalty is a payment in tax law, not a trade discount. It does not reduce the tax base; it reduces what the guest owes after tax.

11.2 Non-India Bills

Restaurants on a Simple VAT or US Sales Tax regime see a similar order with the dynamic tax components in the middle and no Round Off line (round-off is a India-specific convention to keep cash drawers tidy). Loyalty Redemption still sits below tax.

11.3 Currency Symbols — Two Different Symbols, One Number

Meztezz uses two symbols on purpose:

₹ (Unicode rupee) — everywhere on screen. The billing screen, the payment modal, the reports.
Rs. (ASCII-safe) — on every thermal printout. Thermal printers in Indian restaurants run on a wide variety of code pages and many do not handle the ₹ glyph reliably; Rs. always prints.

You shouldn’t need to think about this — the right symbol is chosen automatically for the surface. If you ever see a ? or a blank box where a price should be on a printed bill, it almost always means an old thermal printer is trying to render ₹; switch the printer’s character mode in Settings → Printer and you’re back to normal.

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

We’d rather you know in advance.

No guest-side self-pay at the table. The cashier (or the captain) drives the payment screen. Guest-scan-and-pay at the table (the QR-pay-yourself flow) is on the roadmap, not in this guide.
No partial cash refund at settle-time. If the guest overpaid and wants change in a different method — paid Rs. 500 cash and wants Rs. 200 back on UPI — that’s not a tender split, that’s a refund operation. Handle it via the refunds flow (see the upcoming Refunds, Cancellations & Edits After Save post), not inside the payment modal.
No automatic tip allocation. A tip line on the bill is not built in. Many restaurants don’t want one (service charge is the convention); for the ones that do, add it as a separate menu item priced at Re. 0 and let the cashier set the amount on the line.
One credit payment per customer, not per bill. If the same customer eats with you twice in a week and you ran both on credit, those are two payment rows on two orders — there is no single rolling tab object per customer. The customer’s outstanding balance in the master is the sum; that’s the right number to look at.
No multi-currency. A single restaurant operates in one currency. Foreign-currency tendering (rare in India, common in some hotel F&B setups) is not supported.
No invoice number override. Invoice numbers are auto-assigned in the configured sequence; you can’t manually pick one for compliance reasons.
No retroactive split. Once a bill has been paid in full and the order is paid/completed, you cannot retroactively re-split the tenders. If the cash drawer needs re-balancing, do it at day-close, not by editing past bills.
Loyalty earn-rate is set in masters, not at the modal. You can’t bump up a single customer’s points on a single bill from the payment screen. Bump the customer’s tier or run an offer instead.

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 13 — A Few Habits That Save You Later

Always attach a customer before settling on credit. Cashiers will sometimes try to “fix it later”; in practice it’s never done. No customer → no Credit method → an honest cash entry.
Treat reference numbers as mandatory in practice, optional in the form. Make it a cashier-training rule: every UPI gets the RRN, every card swipe gets the approval code. Month-end reconciliation becomes a ten-minute job.
Don’t let “paid” become “completed” by neglect. Completion (and the table freeing) follows automatically once a paid order’s last KOT is closed on the KDS — so train your kitchen to actually mark KOTs done. A table that stays “occupied” after payment almost always has a KOT still open on the kitchen screen.
Use split tender liberally; use split bill only when the guests genuinely want separate invoices. Split tender is one bill, many payments — clean. Split bill is many bills, each with their own GSTIN — heavier; reserve it for actual business needs.
Keep your card-network list curated. Long dropdowns slow the cashier; bad data slows your monthly close. Five card networks covers almost every Indian restaurant. (The tender-cancel reasons are a fixed built-in list, so there’s nothing to maintain there.)
Set Require Receipt Print to on for the first three months. It’s annoying for the cashier; it’s protective for the owner. Once your floor is disciplined, switch it off.
Reconcile cash at day-close, not at every shift change. The reconciliation surface is the day-close tab — that’s the right place. We’ll cover the whole closing ritual in the End-of-Day post.
Walk a held / partially-paid bill before you go home. Press F4, scan both lists. Anything still sitting there at midnight is something the morning shift will have to puzzle out cold.

Stuck? We’re Here to Help

If any of this didn’t behave the way the guide describes — a payment method that won’t show up, an eligibility check that’s refusing a credit you know is fine, a printer that’s previewing but not printing, a partial that’s stuck in Needs Repayment — 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 settlement rhythm is steady, the next chapter is the awkward conversations: Refunds, Cancellations & Edits After Save — how to handle “actually, take that off” and “we billed it wrong” without breaking reports or stock. We’ll publish that one next. 🎉