What a restaurant's day-end report must show — eight lines, every night.
How much was sold, how payments were recorded, how many bills were issued, what was discounted or refunded, what is in the drawer and which orders stayed open. Sales and cash collected are not the same number: reconcile the report and the drawer separately.
A monthly report arrives after the money has already moved.
A monthly P&L tells you the restaurant made less than it should have. A day-end report tells you which night, and on that night the memory is still fresh: who was on the till, which table argued about the bill, why there were four voids. Leaks in a small restaurant are small and daily (a discount here, a parcel not billed there) and they are invisible at month scale and obvious at day scale.
It also has to be quick. If the close takes half an hour, it gets skipped on the busy nights, which are the nights that matter. The eight lines below fit on one screen, and the EasyKOT Desktop App produces most of them by itself.
Check these eight lines first.
| # | Line | What it tells you | Where EasyKOT shows it |
|---|---|---|---|
| 1 | Bill sales, and collections by tender: cash, UPI, card | Bill sales follow the bill's trading date. Cash, UPI and Card follow the trading day each payment was captured, so they can differ when a check is paid and closed on different days. The cash figure should match the drawer, and UPI should match your bank app in the morning. | Dashboard → Reports (payment mix), and the morning email (cash, UPI, card, total) |
| 2 | Bills issued: count and the invoice numbers they span, per Desktop App | A gap in the series is either a walkout that never got a bill or a bill that was pulled. Either way you want to know tonight, not at GST filing. | Desktop App → Orders → Day close: "Bills issued today", with a gap warning |
| 3 | Discounts: total, and who applied each | If discounts are repeatedly high, check the reasons and approvals first. An offer, a wrong entry or a training gap can all explain the pattern. | Dashboard → Reports (the day's total); the PIN that applied it is on the ledger, not on a screen yet |
| 4 | Voids of fired food: with the reason and who removed it | Cooked food written off is real cost. Three "wrong item rung" on one shift is a training problem; three "kitchen cannot make it" on one dish is a stock problem. | Reason on the check; who removed it on the ledger; day-close write-offs in Reports |
| 5 | Refunds and reprints | Money going back out, and copies of bills: the two documents a fraud needs. Low and explained is fine; unexplained is not. | Refunds in Reports; reprints stamped DUPLICATE and recorded on the ledger |
| 6 | Cash: expected vs counted | Opening float + cash sales − paid-outs = expected. The count is done first, blind. The difference is the line you actually care about. | Phone cash box: float, paid-outs, count, variance |
| 7 | Open and auto-closed checks: the loose ends from service | At the cutoff, eligible synced bills join sales as Paid · Auto closed without adding cash, a payment or a loss. Actual collections remain separate, so you can still see what needs a real decision. | Dashboard → Orders or Day close; the offline Desktop App Day close still handles the leftovers on its side |
| 8 | Top dishes and dead dishes | Not a control, a decision: what to prep more of tomorrow, what to take off the menu at the end of the month. | Reports → Menu performance, grouped by Item, Category or Variant |
Review Orders → Day close in the Desktop App.
In the Desktop App the close lives on the Orders screen. It lists the checks left over from a service that already finished, the empty ones (a stray tap: discard them in one press) apart from the ones with food on them, and the bills issued today per Desktop App with their first and last number. If a number is missing from the series, it says so, in the strongest voice on the screen. Tonight's open tables are deliberately not on it; they are still tonight's.
A check with food on it and no payment recorded gets one question: did the money come in? Add the payment, keep it as Paid · Auto closed, or say the guest did not pay. Only that last answer writes the food off, and it takes a reason and a manager's PIN. That is deliberate friction: the write-off is on the record with a name, instead of a table quietly zeroed at 1am by whoever was closing.
If nobody runs that routine, EasyKOT still classifies eligible synced bills at the configured cutoff as Paid · Auto closed. Their bill value counts in sales, but no cash, payment or loss is invented. The owner dashboard's optional Day close reviews one business date's bills and actual collections, and can count the current cash shift. A later real payment or refund reconciles with the bill instead of being counted twice.
Raat 12:40 ka bill kal ka nahi hai. EasyKOT's trading day starts at 4am by default, and you can move it between midnight and 6am in the dashboard's Settings: reports, order numbers and the kitchen's open-ticket window all follow it. A restaurant that closes at 1am should never see its night split across two dates.
Count first, then compare.
The order matters. Count the drawer first, write the number down, then look at what the Desktop App expected. If the cashier knows the target before counting, the count will match the target: that is not dishonesty, it is how people count. Blind first, compare second, is the one habit that makes the cash line mean something.
- Expected = opening float + cash sales − paid-outs (the vegetables bought from the drawer, the auto fare). Paid-outs need a slip and, on the phone, a manager's PIN.
- Counted = what is physically there, denominations written down.
- Variance = the difference. A few rupees is change; a pattern is a problem. The phone's cash box records all three for the shift.
UPI needs no physical count, but the UPI amount recorded in the report is still a payment-marking total. Match it with settled receipts in your own merchant or bank app before treating it as collected. The staff theft post is about exactly that.
The owner gets the morning summary on their phone.
The owner is often not at the shop at closing time. The dashboard sends the day's summary prepared from 08:00 store time for the previous trading date (orders, average order, cash, UPI and card, the total collected and net sales before GST) so the money lines are read over the first chai, not reconstructed on the weekend, and the four Reports families carry the rest. The guide owner reports and the daily summary shows the email and the Reports screens; the day close guide is the button-by-button version of the close above.
None of this needs the internet at the shop. The Desktop App closes the day on its own database. Summary preparation starts from 08:00 independently of the automatic-close cutoff and uses what has synced by then. An open business window is marked provisional, and later offline facts catch up in Reports. Three months free, no card, if you want to see your own eight lines tomorrow morning.
Straight answers.
Day end report kya hota hai?
What time does the day end for a restaurant that closes at 1am?
Why should the cash count be blind?
Do I need to be at the shop to read it?
Does the report show who gave a discount or voided a bill?
What if a table was left open at night?
Run it 3 months, then pay for it.
Three months free, full product, no card. Made in India, for the counter: built inside a running restaurant.