Closing the Day in Ten Minutes: How We Think About Designing an End-of-Day Report

It's 10:40 pm on a Saturday in Diwali week. A garment shop in Surat has just pulled the shutter halfway down. The owner has the cash drawer open, the UPI app on his phone, and two staff waiting to go home. He wants three answers before he locks up: did the money match, what sold, and who sold it. (This is a composite example, not a real shop.)

If those answers take an hour and a calculator, the end-of-day report has failed, however many charts it has.

We build VyaparNext by Smart Byte Labs, garment shop billing software made in Surat. This post isn't a tour of our screens. It's how we think about designing a closing report that a tired shop owner can read in ten minutes, and the questions we'd ask of any system that claims to have one.

The report has one job

A closing report isn't analytics. Analytics can wait for Monday morning. The closing report has to settle tonight, while the people who made the sales are still in the shop and can still remember the odd bill.

So we design backwards from three questions:

1. Does the money match? Totals, and how they were paid.
2. What sold? Down to the size and colour, not just the design.
3. Who sold it? So a gap can be traced to a person's bills, not argued about.

Anything that doesn't help answer one of those three moves to another screen.

1. Totals come from bills, never from typing

The first rule is boring and it matters most: the day's total is the sum of the bills, not a number someone types in. If a cashier keys the evening total into a register or a spreadsheet, the report is only as good as that typing.

In VyaparNext, every sale is a bill, and every bill prints as a tax invoice (one tax rate). The day-end total rolls up from those bills. There's no separate "total" field to drift away from what actually happened at the counter.

The design question we keep coming back to is payment mode. A busy counter takes cash, Google Pay and PhonePe, sometimes on the same bill. VyaparNext records the payment mode on the bill, but the software doesn't see the shop's bank account. The owner still matches the UPI part against the UPI app, and the cash part against the drawer. A good report makes that match quick by keeping each mode's total separate and easy to find. It shouldn't pretend to have done the match for you.

2. Top items, at the variant level

"Kurti A sold 40 today" sounds useful. It isn't, at 10:40 pm, when you're deciding what to reorder before Dhanteras. "Kurti A, M maroon sold 9 and there are 2 left" is.

In the previous post on variants we argued that stock lives on the variant (one size in one colour), never on the design. The closing report should follow the same rule. VyaparNext's end-of-day sales reporting shows top SKUs, and in a garment shop a SKU is a size and colour, because each one has its own barcode tag.

Two smaller design choices we think about:

• Pieces or rupees? The item that sold the most pieces isn't always the one that left the most money. A report can show both; the owner decides which one drives the reorder.
• Short lists beat long tables. The top ten is something you'll actually read before going home. The full list can be exported.

3. Staff breakdown needs logins first

"Who sold it?" sounds like a report feature. It's really a login feature. If three people bill on one shared login, no report can tell them apart, however well it's designed.

That's why VyaparNext gives each cashier their own login, with owner, manager and cashier roles, and the end-of-day report includes a breakdown by staff member. The point isn't a leaderboard. It's that when the drawer is ₹500 short, you look at one person's bills for the evening instead of everyone's whole day.

A rough way to picture what the closing view rolls up (illustrative only, not VyaparNext's schema):

// Illustrative only: a way to think about it, not our code.
type Bill = {
  number: string;
  staffLogin: string;          // who billed it
  lines: { sku: string; qty: number; amount: number }[];
  payments: { mode: "cash" | "upi"; amount: number }[];
  createdAt: string;           // device time, India
};

type DayClose = {
  date: string;
  totalsByMode: Record<string, number>;   // matched by a person, not the software
  topSkus: { sku: string; qty: number; amount: number }[];
  byStaff: { staffLogin: string; bills: number; amount: number }[];
};

Everything in DayClose is computed from bills. Nothing in it is typed.

4. Offline and more than one counter

A garment counter has to keep billing when the internet drops, so the report can't depend on the network either. On POS Lite, which is free on one counter, bills and stock changes save on that device, so the day's bills are all there whether or not Wi-Fi was working.

Once a shop runs two counters, timing matters. Cloud Sync, the paid add-on for offline billing software with cloud backup, syncs about every hour. It merges bills, purchases, returns and edits, and recalculates stock across devices. It isn't instant. So the question we'd ask of any multi-counter setup is: when you close, have the last hour's bills from the other counter arrived yet? A simple habit helps: let sync run after the last bill, then read the closing numbers.

5. When the shop also has a website

This is where the end of the day changes most, and it depends on how the website is set up.

• A website on its own (Launch Store) is a managed online store with its own admin and order management, including returns and exchanges. It doesn't include the counter POS. So closing means two places to look: the counter's report and the website's orders. That's fine for a shop that's mostly online, or that keeps separate stock for the website.
• Counter and website on one catalogue (Connected POS + Website) is the plan where both channels draw from one stock count. The maroon M that sold online at 9 pm comes off the same stock count the counter uses, so the closing stock figure is one number, not two numbers to reconcile at midnight.

Even with one catalogue, a few design questions are worth asking, of us or of any system:

1. Can the owner see counter sales and website orders separately as well as together?
2. How is a website order counted that's placed today but paid, packed or returned tomorrow?
3. Does "top items" mean the counter, the website, or both?

There's no single right answer. A shop that makes most of its sales at the counter wants a different closing view from one that ships most of its orders. What matters is that the report says which one it's showing.

Where VyaparNext's plans fit

From the live pricing page (checked 3 Nov 2026; all prices + GST):

• POS Lite: free to start, on one counter. Billing, purchases and stock stay on that device, with no automatic cloud sync.
• Cloud Sync: ₹299/month + GST, about hourly sync across counters, with a 14-day free trial.
• Connected POS: ₹599/month + GST, a hosted backend for the till with Cloud Sync included, also with a 14-day free trial.
• Launch Store / Brand Store: the shop's own online store. For the first 25 stores, VyaparNext builds it for a one-time ₹25,000 development fee + GST, and the ₹1,499/month server and maintenance charge is free for year 1. After that, ₹1,499/month + GST (or ₹14,999/year + GST).
• Connected POS + Website: counter and website on one catalogue and one stock. The same first-25 offer applies: a one-time ₹25,000 development fee + GST, and the ₹1,999/month charge is free for year 1. After that, ₹1,999/month + GST (or ₹19,999/year + GST).

Eligibility for the trials and the launch offer is confirmed at checkout. If you only bill at one counter today, POS Lite is enough. The website question only matters once a website is selling the same pieces.

Five questions to ask any closing report

Whether you're building one or choosing POS software for garment shops:

1. Is every total computed from bills, with nothing typed in?
2. Are payment modes kept separate, so cash and UPI can each be matched by a person?
3. Do top items show size and colour, not just the design?
4. Does each staff member bill on their own login, so "who sold it" is a fact?
5. With more than one counter or a website, does the report say what it includes and when it was last synced?

If a system answers all five clearly, closing really can take ten minutes.

Start free with POS Lite on one counter, or book a free demo on WhatsApp: [phone]. More at vyaparnext.com.

Previously in this series: One Catalogue, Two Channels: How We Think About Sharing Stock Between the Counter and the Website.