The count
Count the cash. Once.
Staff enter each denomination on the shift sheet. The counted total adds itself up as they type.
Variance
The gap has a number.
Expected is the opening float plus cash sales, less banking and petty cash. Actual is what was counted.
Submitted is submitted.
What the record keeps.
Every deposit keeps its bank, reference number and source.
Petty cash vouchers arrive summed by category.
A closed day refuses edits to the expenses under it.*
* An expense dated to a day that already has a close record cannot be amended or deleted.
Numbers, with their baselines.
Ten denomination rows total themselves as the till is counted.¹
Four sections roll up into one close screen.²
One close per restaurant per day, held by the database.³
Zero edit paths exist on a submitted close.⁴
- ¹ Rows on the shift count sheet: ₹500, ₹200, ₹100, ₹50, ₹20, ₹10, ₹5, ₹2, ₹1 and coins.
- ² Cash session, daily banking, store expenses and the variance note, on one page with one submit.
- ³ A unique constraint on restaurant and close date, enforced in Postgres rather than in the app.
- ⁴ The close record grants select and insert only. There is no update and no delete.
Questions? Answers.
Does it need a POS integration?
No. The cash sales figure is entered on the close screen and the expected amount recomputes from it.
Who can submit a close?
A manager or above. The role is checked on the server for both reading and submitting the close.
Can a submitted close be edited?
No. The day is frozen with its constituent rows kept alongside it, so the figures stay as submitted.
What happens to an expense dated to a closed day?
The edit is refused. Moving an expense onto a closed date is refused for the same reason.
Does the shift till close as well?
Yes. Submitting the close also closes a still-active cash session at the counted total.
Take the next step.
Who it is for