End-of-Day: Day Close, Z-Report & Cash Reconciliation in Meztezz

A restaurant that never closes its day is a restaurant whose books slowly stop matching its till. Sales pile up, refunds drift between days, petty-cash slips appear in the drawer, and at month-end the owner spends a Sunday morning trying to reconstruct what happened. Day close exists to draw a line under each business day — sales are tallied, cash is counted, variances are explained, and the day’s numbers become immutable. Tomorrow gets a clean start.

This guide walks through the entire closing ritual in Meztezz — the Settlement Wizard, the Z-Report sections that get printed, the cash declaration by denomination, what a variance means and what to do about it, and the awkward edge cases (unsettled past days, amendments, reopening a closed Z-Report). It picks up right after Refunds, Cancellations & Edits After Save — the “credit notes land in today’s books” rule from that post is the reason the Prior Period Adjustments section exists in this one.

💡 Where this lives in the app. The whole closing ritual happens in the Day-End Settlement wizard, opened from the Day End item in the billing-header menu (the menu at the top of the billing screen). Past days live in the Z-Report History section under the Reports → Day End tab. Daily cash-drawer movements outside of sales — petty cash, change float top-ups — go in via the Cash In/Out item in the same billing-header menu.

The Walkthrough at a Glance

Part	What you’ll learn
1. Why You Close the Day	The two practical reasons; what an unclosed day costs you.
2. Before You Close	Prereqs — shift opened, refunds posted, held orders resolved.
3. The Closing Ritual at a Glance	Three steps: Review → Cash Count → Done.
4. Step 1 — Review the Z-Report	Every section of the report, in order.
5. Step 2 — Declare the Cash in the Drawer	The denomination count and the variance line.
6. Step 3 — Confirm & Close	What gets recorded, what prints, what syncs.
7. Cash In, Cash Out & Opening Cash	The moving parts of “expected cash”.
8. Variance — Excess vs. Shortage	What each direction means and what to do.
9. Catching Up on Past Days	The unsettled-days banner and how to clear it.
10. Amending a Closed Z-Report	Re-counts, mis-counts, late corrections.
11. Reopening a Closed Day	Rare, manager-gated, last-resort.
12. What Prints, What Files, What Syncs	The audit trail beyond the screen.
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 audit time.

Part 1 — Why You Close the Day

Two reasons, both practical, neither bureaucratic.

1.1 The Books Match the Till

Throughout the day, payments and refunds happen one tender at a time. By the time service ends, the cash drawer has some number of notes and coins in it, and Meztezz has some expected number based on every cash tender, every cash refund, every cash-in slip and every cash-out slip. Closing the day is the moment you compare the two — and if they don’t match, you find out today, not in a stack of receipts three weeks from now.

1.2 The Day Becomes Immutable

Once a Z-Report is closed, the day’s numbers stop moving. Refunds against that day’s bills will now land in today’s books as credit notes (Part 8 of the Refunds post). New orders can’t be back-dated into a closed day. Reports for that day will always show the same totals when you reopen them next month, next year, or at audit time. This is what your auditor expects, and what Section 35 of the CGST Act effectively requires.

1.3 What an Unclosed Day Costs You

If you skip a close, the day stays in open state. The cash drawer continues to accumulate into the next day’s expected balance; sales reports for the open day show “draft” totals that can still shift if a refund lands; the cloud dashboard shows the day as unsettled. None of this is fatal — Meztezz holds the state correctly — but the longer you wait, the harder the cash count becomes, because notes from yesterday and today are now sitting in the same drawer.

💡 Close every operating day, even nil-business days. If you were open and made zero sales (a wedding closure day, a private event with no till transactions), close the day anyway. The wizard recognises the case and shows a “Nil Business Activity” banner — but it’s informational only; a nil-business day still goes through the full Review → Cash Count → Confirm flow, cash count included. An unbroken sequence of closed days is what the books expect.

Part 2 — Before You Close

Six things should be true before you press the button. The wizard surfaces most of these as warnings on the review screen, but you’ll close faster if you check ahead.

Prereq	Where to check	Why it matters
A shift was opened	Open Shift in the user dropdown (billing header)	Opening cash (the float you started the day with) becomes the baseline for Expected Cash. No shift → opening cash defaults to zero → cash reconciliation will be off by your starting float.
All active orders are settled or cancelled	Billing screen / `F4` Recall sheet	Active orders aren’t included in the Z-Report. They carry over to the next day, which is rarely what you want.
All held orders are resolved	`F4` Recall sheet → Held section	Same as above — held orders are excluded from settlement. Either recall and settle them or cancel them.
Repayment-pending bills are collected	`F4` Recall sheet → Repayment Pending	Partial bills aren’t fully paid. Either collect the balance or move the bill to credit.
Refunds posted	Order History	If today’s bill was voided / refunded today, post it before closing. After close, the same refund becomes a different-day refund (with a credit note).
Petty cash entries logged	Cash In/Out in the billing-header menu	Every cash-in (extra float dropped in) and cash-out (kirana boy, gas top-up, raddi sale) needs to be logged. Otherwise the Expected Cash won’t match the till.

If any of these are missing, the wizard will tell you when you open it — but the close goes much faster if you’ve already taken care of them.

Part 3 — The Closing Ritual at a Glance

The Settlement Wizard walks through three steps, in this order — the progress bar at the top of the wizard labels them Review → Cash Count → Done. You can back out before the final commit; once you commit, the day is closed.

Step 1 — Review       Read the Z-Report. Confirm warnings. Proceed to Cash Count.
Step 2 — Cash Count   Count the cash in the drawer by denomination.
Step 3 — Done         Close the day. Print the Z-Report. Settlement record saved.

A fourth step — Amend — exists for closed days where the cash count was wrong and needs to be redone. That’s covered in Part 10.

The wizard auto-loads the Z-Report when it opens. If today’s report doesn’t exist yet (you haven’t opened the wizard yet today), it’s generated on the fly. If today’s report has already been closed, the wizard opens in read-only review mode — no further action is needed and you can re-print the existing slip.

Part 4 — Step 1: Review the Z-Report

This is the longest step on the screen, and the most important. Read every section before you proceed to the cash count. If anything looks wrong, the time to fix it is now, not after the day is closed.

4.1 The Status Banners

Before the report itself, the wizard surfaces context warnings:

Day already closed (green) — informational; the wizard will be in read-only mode.
Unsettled orders (yellow) — N active or held orders are not in the settlement. List the numbers and either settle or cancel before continuing.
Nil Business Activity (blue) — you opened the day but took no orders. This banner is informational only; the cash count step still runs.
Unclosed report (orange) — only on historical dates; this past day was never settled (see Part 9).
Previous day(s) not settled (orange) — only when closing today; lists up to five past dates with order counts and gross sales, plus a direct link to Z-Report History.
No shift opened (amber) — opening cash defaults to ₹0; cash reconciliation will be off by your actual starting float.

Take the warnings seriously. The “previous day(s) not settled” banner in particular is the single most common cause of “my month-end doesn’t tie out” — you wanted to settle today but five days are stuck in open state from last week.

4.2 Order Summary

A short block with the day’s order counts:

Total Orders — every order created today, including cancelled ones.
Completed — fully settled and marked complete (food delivered, table released).
Cancelled — orders cancelled outright.
Refund Amount — total refunded today, including same-day voids and different-day credit notes.
Unsettled (yellow line if > 0) — active + held orders that won’t be in this Z-Report.

4.3 Sales Summary

The financial spine of the Z-Report. Listed in the same line order your bills follow (see Part 11 of the Settling Bills post):

Gross Sales
  Subtotal
  Service Charge
  Packaging Charge
  Tax (CGST + SGST)
    Direct Orders          <- if aggregator orders also exist
    Aggregator (Dine-in)   <- separate because dine-in aggregator orders carry GST
  9(5) Exempt              <- count + amount of aggregator takeaway/delivery (exempt under Section 9(5))
  VAT (Liquor)             <- only if alcohol was sold today
Discounts
  Staff/Manual             <- discounts the cashier or manager applied
  Offers/Promo             <- discounts driven by configured offers
Loyalty Redeemed           <- only if redemptions happened
Round Off
Net Sales

A few non-obvious bits:

Aggregator tax split — dine-in orders placed through Swiggy/Zomato/etc. carry GST (Section 9(5) does not exempt them). Takeaway / delivery aggregator orders are exempt and show under “9(5) Exempt”. Your auditor needs both numbers; the Z-Report gives both.
Manual vs. Offer discounts — split because they tell different stories: high Manual means cashiers are comp-ing a lot of bills (review the audit trail); high Offers means your promo is doing its job (look at the promo’s ROI).
Loyalty Redeemed — sits as its own line because it’s a payment, not a trade discount; it doesn’t reduce the tax base.

4.4 Payment Breakdown

The day’s collections, split by tender — cash, UPI, card, wallet — followed by a separator and a Credit (Khata) line. The reason credit is shown below the totalled line:

Deferred revenue — not collected at time of sale.

This is the most-misread number on the entire report. Credit is not money in your till today. It’s revenue you booked today against customer accounts you’ll collect on later. The “Total Collected” number above the divider is what your bank statements should add up to (plus or minus any cash refunds). Everything below the divider is on the receivables ledger.

4.5 Prior Period Adjustments

This block appears only when credit notes were issued today against orders from previous dates (the different-day refund regime from the Refunds post). Each row shows the credit note number, the original order’s invoice number, the original invoice date, and the amount.

The total at the bottom is what’s been pulled out of today’s books to reverse past sales. This is also why a heavy refund day can show negative net tax — the credit notes are big enough to swamp the day’s actual sales.

4.6 Expected Cash in Drawer

The single line that drives the rest of the close:

Expected Cash in Drawer    Rs. 12,540.00
(Opening: Rs. 2,000 + Cash Sales)

This is computed as:

Opening Cash
+ Cash sales (the Cash row from Payment Breakdown)
+ Cash In entries (petty additions logged today)
− Cash Out entries (petty withdrawals logged today)
− Cash refunds issued today (the Cash portion of any same-day void)
= Expected Cash

Memorise this formula — when the variance is non-zero in Part 8, knowing which input drifted is what tells you whether to look for a missed cash-out slip, an unaccounted refund, or a genuine cash discrepancy.

4.7 Moving On

The review-step footer has just two buttons: Cancel and Proceed to Cash Count. There’s no print or preview here — printing happens after the day is closed (Step 3), via a single Print Z-Report button on the confirm/closed screen. If print preview is turned on in settings, that button shows the thermal layout on screen first; otherwise it prints straight to the assigned bill printer. We strongly recommend printing — the paper Z-Report is what gets filed in your day-end folder, and what your auditor wants to see.

Part 5 — Step 2: Declare the Cash in the Drawer

Press Proceed to Cash Count from review and the wizard switches to the cash declaration screen.

5.1 The Denomination Grid

The grid lists every cash denomination configured for your locale — for India, the ₹500, ₹200, ₹100, ₹50, ₹20 and ₹10 notes plus ₹5, ₹2 and ₹1 coins. For each denomination:

A − / + pair of buttons to nudge the count up or down.
A numeric input you can also type into directly.
A live line total (denomination × count) on the right.

The cashier (or, better, the cashier and a manager together) physically counts the drawer, enters the counts, and the wizard sums them into a Declared Total at the bottom.

5.2 The Variance Line

Right below Declared Total, two lines:

Expected Cash      Rs. 12,540.00
Variance           +Rs.      40.00     (excess cash in drawer)

Green, positive — the drawer has more cash than expected. Could be a missing cash-out slip, an under-rung sale, or a customer who left a tip in cash that went into the till.
Red, negative — the drawer is short. Could be a missed cash-in slip, a cash refund that wasn’t logged, an over-rung sale, or a genuine discrepancy.
Zero — the drawer matches the books exactly. Celebrate.

A small note (Excess cash in drawer / Cash shortage detected) appears under the variance to make the direction unambiguous in low light.

5.3 The Notes Field

A free-text notes box at the bottom. Use it. “Variance of +Rs. 40 — petty cash sale of newspaper not logged” is the kind of explanation that turns a confusing report into an explained one. The notes attach to the settlement record and show up on the printed Z-Report.

💡 Recount before you commit. A miscounted drawer becomes a real variance in the books — and amending it later (Part 10) leaves an audit footprint that an honest variance would not. If the count surprises you, count again before pressing Close Day.

Part 6 — Step 3: Confirm & Close

Press Close Day from the declare step and you reach the final confirm screen.

6.1 What You’re About to Commit

A green “Day Closed Successfully” panel previews the close, followed by:

Cash Reconciliation block — Opening Cash, Cash In, Cash Out, Expected Cash, Declared Cash, Variance.
Quick Stats — three big tiles: Completed Orders, Net Sales, Tax Collected.
Closed by — the user logged in at the terminal, with the timestamp.

6.2 What Happens on Commit

When you press the final Close Day button, in one transaction Meztezz:

Marks the Z-Report closed in the database (immutable from this point on).
Snapshots every number on the review screen into the settlement record.
Stores the declared cash, the denomination breakdown (as JSON), and your notes.
Records the cashier/manager who closed, and the timestamp.
Prints the final Z-Report slip (if a printer is assigned and the setting is on).
Triggers the auto-export (if configured — see Part 12).
Queues the closed Z-Report for sync to app.meztezz.com.

6.3 What Won’t Happen Anymore

After the close:

The day’s gross/net sales numbers are frozen. New orders cannot be back-dated into this day.
Refunds against today’s orders become different-day refunds with credit notes (see Part 8 of the Refunds post).
The Settlement Wizard for this date opens in read-only mode forever after — unless you amend or reopen.

Part 7 — Cash In, Cash Out & Opening Cash

The three moving parts of Expected Cash that aren’t sales.

7.1 Opening Cash — the Day’s Float

Set when you open the shift at the start of the day (Open Shift in the user dropdown in the billing header). Typical Indian restaurants run a float of Rs. 2,000–Rs. 5,000 in small notes and coins, so the cashier can give change from the first sale onwards. The opening cash becomes the floor of Expected Cash; if you skip opening the shift, opening cash is zero and your reconciliation will be off by your actual float.

7.2 Cash In / Cash Out — Petty Movements

Anything that adds or removes cash from the drawer outside of a sale or refund should be logged as a Cash Entry via the Cash In/Out item in the billing-header menu. The dialog lets you pick:

Cash In (green) — float top-up mid-shift, change brought in from the safe.
Cash Out (red) — kirana boy, gas cylinder delivery, raddi (scrap) collection, petty repair payment, change drop into the safe.

Each entry captures the amount, the type (Cash In / Cash Out), and a Reason picked from a fixed dropdown — Vendor Payment, Safe Drop, COD Collection, Tips, Change Fund, Petty Cash Expense, or Other. There’s also an optional free-text Notes field: the specifics above (which kirana boy, what the float top-up was for) go in Notes, with the closest dropdown reason selected. Entries appear in the day’s Cash report (the Cash Movements section) with running totals.

7.3 Why This Matters at Close-Time

Every Cash In is added to Expected Cash; every Cash Out is subtracted. If a cash-out happens but isn’t logged, your Expected Cash will be higher than the till, and you’ll see a shortage in the variance. The fix is not to “adjust the books” — it’s to log the cash-out, even after the fact, so the audit trail tells the truth.

💡 Treat the cash drawer like a bank account. Every rupee that enters or leaves should have a record — a sale, a refund, a cash-in slip, a cash-out slip. If you can’t explain a movement, log it as Cash Out with a clear reason (“Variance — unexplained”) rather than fudging the count. An honest discrepancy is debuggable; a hidden one is not.

Part 8 — Variance — Excess vs. Shortage

A non-zero variance is not a failure — it’s a clue.

8.1 Excess Cash (Positive Variance)

The drawer has more than expected. Common causes:

Cash-out not logged — kirana boy was paid but no slip was made. Fix: log a Cash Out for today before you close, or note the variance and log it in tomorrow’s entries.
Tip left in cash — guest left notes on the table that went into the till. Fix: this is real income; either run it through as a no-item complimentary settlement or log it as a Cash In with reason “Tip”.
Under-rung sale — cashier rang Rs. 380 but the bill was Rs. 400. Fix: review high-cash-handling orders in the audit log.
Wrong change given — cashier short-changed the guest. Fix: review the day’s cash transactions to see if anything stands out.

8.2 Shortage (Negative Variance)

The drawer is short. Common causes:

Cash-in not logged — owner dropped Rs. 1,000 float top-up but never made a slip. Fix: log a Cash In with the actual reason.
Cash refund not logged — guest got a refund from the till but the refund went through as UPI in the system. Fix: void and re-do the refund through the correct method, or amend the count.
Over-rung sale — cashier rang Rs. 400 but the bill was Rs. 380. Fix: same as 8.1.
Wrong change given (in cashier’s favour) — rare but happens. Fix: same as 8.1.
Genuine theft or loss — rare; the audit trail makes it relatively traceable.

8.3 What Counts as “Acceptable”

There’s no fixed tolerance — set one for your operation. A common rule for a single-cashier shift in a small restaurant: variances of ±Rs. 50 are noted, ±Rs. 200 trigger a recount, anything larger triggers a full review of the day’s audit trail before close. Tighten the limits as your team’s discipline improves.

Part 9 — Catching Up on Past Days

It happens: the manager forgot to close on Saturday and now it’s Wednesday. The wizard handles this gracefully — but you should clear the backlog before you settle today.

When you open the wizard for today, an orange banner appears if any past date is unsettled:

3 previous day(s) not settled
2026-05-23 — 87 orders (Rs. 1,42,500)
2026-05-24 — 92 orders (Rs. 1,55,200)
2026-05-25 — 78 orders (Rs. 1,28,900)

Go to Z-Report History to settle past days →

The link takes you straight to the Z-Report History section under the Reports → Day End tab — a list of all dates with a quick “Settle” action per row.

9.2 Settling a Historical Day

Pick a past date in Z-Report History → the Settlement Wizard opens for that date, in the normal Review → Cash Count → Done flow. You’ll see an Unclosed report orange banner reminding you this is a historical settlement. Cash declaration is still required (you’ll need to enter the count from the closing till of that day — hopefully written down at the time; if not, use your best estimate and note it).

9.3 The Right Order

Settle the oldest unsettled day first, then work forward to today. The reason: opening cash for a day is supposed to equal the closing cash of the previous day. If you close Wednesday before Monday, Monday’s closing cash hasn’t been recorded yet, and Tuesday’s opening cash will be wrong.

💡 The longer you wait, the harder this gets. If you missed a close yesterday, do it today. If you missed three days, do them today before you close today. There is no “I’ll figure it out at month-end” version of this that works — the closing cash of any given day is information that lives in your manager’s memory; that memory is good for about 48 hours.

Part 10 — Amending a Closed Z-Report

You closed the day. Two hours later, you re-count the till for petty cash and realise the count was off by Rs. 200. Or you find a cash-out slip in your shirt pocket from earlier. The wizard supports amendments for exactly these cases.

10.1 How to Amend

Open the Day-End Settlement wizard for the closed date → it opens in read-only review mode → an Amend Cash Declaration action is available at the bottom. The wizard switches to a recount screen identical to the declare step, with:

A Current Declared Cash line showing what’s on the books today, for reference.
The same denomination grid — but it starts empty; you re-count the drawer from scratch and enter the fresh counts.
A Reason field — required — explaining why the amendment.

Submit → the Z-Report’s amendmentCount ticks up, an amendment row is added to the history, and the new declared cash + variance replace the old ones in the report.

10.2 What the Amendment Trail Looks Like

The Z-Report carries an “Amended Nx” badge next to the Cash Reconciliation header from then on. The full amendment history is visible at the bottom of the report — each entry showing who amended, when, what changed, and the reason.

10.3 What an Amendment Doesn’t Do

Amendments only correct the cash declaration. They do not:

Change the day’s sales, tax or discount totals (those came from the orders themselves; amend those by voiding/refunding the underlying order).
Change the opening cash (that came from the shift open; can’t be moved retroactively).
Reverse credit notes already issued.

If the actual problem is “we billed a guest wrong on this closed day”, that’s a refund flow on the underlying order, not a Z-Report amendment.

Part 11 — Reopening a Closed Day

The amendment path is for small corrections. Reopening is for the rare case where the entire day needs to be re-settled — the close was done in error, against the wrong date, with all of the wrong inputs. This is intentionally rare and intentionally gated.

11.1 Who Can Do It

Only users whose role carries the manage:reopen_z_report permission. Out of the box that permission is granted to the Owner, Manager and Cashier roles — only the Waiter role lacks it by default. If you want to lock reopen down to owners alone, do it in Settings → Roles: edit each role and remove the permission from everyone except Owner. (Even with the permission, the action is still gated by a manager PIN — see below.)

11.2 What It Costs

A reopen dialog asks for:

A manager PIN (4–6 digits).
A reason — required, free-text, written into the audit trail.

On confirm, the Z-Report flips back to open state; the day re-enters the wizard’s normal flow. The reopen event is permanently logged with the user, time, and reason.

One hard limit: you can only reopen a day if no orders exist for any date after it. The moment the next business day starts taking orders, the close is locked — the wizard refuses with “Cannot reopen: N order(s) exist for dates after {date}. Day End cannot be undone once the next business day has started.” This is what protects the chain of opening/closing-cash balances. So the “reopen, then refund same-day” path in the table below only works before the following day has rung up its first order; once it has, you’re on the different-day refund (credit note) path instead.

11.3 When to Use It vs. Amend

Scenario	Right tool
Cash count was off by a small amount	Amend
Forgot a cash-in/out slip	Amend (plus log the slip in today’s entries)
Closed the day with no shift opened by accident	Reopen
Closed with the wrong cashier logged in	Reopen
Realised an order should have been refunded same-day — and no later business day has started yet	Reopen (then refund inside the day)
Realised an order should have been refunded — but on a previous date	Don’t reopen — issue a different-day refund (credit note) instead

The rule of thumb: reopen only when the close itself was wrong; amend when the close was right but a number was wrong.

Part 12 — What Prints, What Files, What Syncs

The close generates several outputs. Knowing which goes where saves your accountant a call.

12.1 What Prints

The Z-Report slip — sent to the assigned bill printer at close-time, and reprintable any time afterwards with the Print Z-Report button. The slip contains every section of the review (Order Summary, Sales Summary, Payment Breakdown, Prior Period Adjustments, Cash Reconciliation, Closed By). This is the paper your day-end folder should hold.

There’s no separate amendment slip. Amending a closed day updates the report in place and drops you back on the review screen — nothing prints automatically. The amendment shows up the next time you reprint the Z-Report: an “Amended Nx” badge by the Cash Reconciliation header plus the amendment history (who, when, what changed, the reason). So if you want a paper record of an amendment, reprint the Z-Report after you’ve made it.

12.2 What Files (Auto-Export)

If you’ve turned on auto-export in settings, the day’s close triggers a file dump to the configured location (a local folder, a synced Google Drive folder, etc.). You choose what gets exported — both the report types and the file formats:

Report types (pick any) — Day End, Sales, Item Sales, Tax, Cash Drawer, Staff, KOT, Inventory, and the Z-Report.
Formats (pick any) — Excel (.xlsx), CSV, or PDF. Each selected report is written in each selected format.

So if you tick “Day End” and “Sales” and choose “PDF” and “Excel”, you get four files. There’s no automatic “payments CSV” or “copy of credit notes” — the export is exactly the report types you selected, nothing more.

The export runs in the background after the close commits. If it fails (no internet, folder permission), the close still succeeds — auto-export is fire-and-forget, run once per close, and any failures surface as a toast. There’s no automatic retry, so if a close’s export fails, re-trigger it yourself.

12.3 What Syncs to the Cloud

The closed Z-Report and its settlement record sync up to app.meztezz.com as part of the normal sync bundle. On the cloud:

The Settle report (under Reports → More → Settle) shows the day’s settlement with its variance, flagged-warnings count, and amendment count.
The Day End report rolls up gross/net sales, tax, discounts, payment breakdown — the same numbers as the printed Z-Report.
The Refunds report picks up the day’s credit notes (with prior-period reversals broken out).

The cloud is read-only for these surfaces — you cannot re-close, amend or reopen from the dashboard. That action stays on the terminal where the full audit trail and PIN gates live.

Print the Z-Report on close.
Staple it to the cashier’s daily cash-count sheet (if you keep one) and any vendor-payment slips (cash-out backups).
File the bundle in a per-month folder.
Once a week, scan and back up the month folder.

You’ll never need the paper unless an auditor asks — but the day they do, you’ll have it.

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

We’d rather you know in advance.

No multi-cashier shift split inside one Z-Report. A single day is settled as a single block. If two cashiers ran the till on the same day, the Z-Report shows their combined numbers — it does not break down “this much from cashier A, this much from cashier B” at close-time. The Staff Performance report covers per-cashier numbers separately.
No per-terminal Z-Report. A restaurant settles per outlet, not per terminal. If you run three billing terminals, they share one Z-Report for the day.
No mid-day Z-Report. There is no “interim close” between shifts; one business day = one Z-Report. If you genuinely need a mid-day reconciliation (e.g. lunch shift vs. dinner shift cash handover), use Cash Out → safe drop + Cash In → fresh float as the rhythm; the Cash Drawer report breaks those out by time.
No automatic forced-close. If you leave the day open and run the next day’s orders, Meztezz will not auto-close yesterday. The “previous day(s) not settled” banner will nag you, but the close is always a deliberate human action.
No reopening once the next business day has started. Reopen isn’t a soft “we’ll warn you” thing — it’s a hard block. If any order exists for a date after the closed day, Meztezz refuses to reopen it (“Cannot reopen: N order(s) exist for dates after {date}…”). This protects the chain of opening/closing-cash balances. In practice it means: reopen only works for the most recent day, and only before tomorrow rings up its first order.
No support for foreign-currency cash counts. The denomination grid is single-currency, per your locale.
No partial cash declaration. You count the whole till; there’s no “I’ll declare the rest tomorrow” path.

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

Close every operating day, including nil-business days. An unbroken sequence is what the books expect.
Open the shift before the first sale. No shift = wrong opening cash = a permanent variance you’ll be explaining to yourself later.
Log cash-in / cash-out at the moment of the movement, not at close-time. A “I’ll remember at end of day” cash-out is a guaranteed variance.
Count the till twice before declaring. A miscount becomes a real number on the books; a recount costs you sixty seconds.
Have a manager present for the cash declaration. Two pairs of eyes on the till is the cheapest fraud-prevention measure in the building.
Print the Z-Report. File the Z-Report. It’s not for you — it’s for the auditor you’ll meet in two years.
Clear backlogs the day you spot them. A missed Friday close becomes much harder by the following Wednesday.
Treat the variance as information, not embarrassment. A consistent ±Rs. 20 variance probably means your cashier doesn’t have enough small change at the start of the shift. A consistent shortage on Sundays might mean a specific staff member is over-changing. The variance is telling you something — listen.
Don’t amend a Z-Report to “fix” a variance you actually owe. If the till was short Rs. 200 and a cashier owes you the money, log it as Cash In with a clear reason when they pay back, not as an amendment that pretends the count was different.

Stuck? We’re Here to Help

If any of this didn’t behave the way the guide describes — a Z-Report that won’t generate, a cash declaration that’s adding up wrong, an “unsettled orders” banner that won’t clear after you’ve settled them, an amendment that didn’t update the variance — 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 day-close ritual is steady, the next chapter widens out from the till to the storeroom: Stock & Inventory in Practice — recipes, GRNs, transfers, wastage and the rhythm that keeps your kitchen and your storeroom in agreement. We’ll publish that one next. 🎉