Cash management

Cash management is available on plans that include the feature.

#Sessions

Cash. A cash session is one drawer, at one branch, opened by one person.

• Open with a starting float — the cash you put in.
• Close with a counted amount.

Restro compares the counted amount to what it expected — the float, plus cash sales, plus pay-ins, minus pay-outs and cash refunds — and records the variance. A session with a variance is not an error to hide; it is the number the whole feature exists to produce.

Cash and movements taken while a terminal was offline count towards the expected amount as soon as they are taken, so the running total on the till is the cash in the drawer whether or not the network is up.

Cash refunds come out of the open drawer and reduce the expected amount. Card sales taken on a terminal never count as cash, so a card-heavy shift does not inflate what the drawer should hold.

Cash sales are the cash actually taken, not the value of orders that happened to be paid in cash. A bill split part cash and part card only puts its cash share in the drawer, which is what you will count. See Taking payment for how a bill is split.

#Movements

During a session you can record:

• Pay-in — cash added to the drawer that is not a sale.
• Pay-out — cash removed: a supplier paid in cash, a float moved.
• Drop — cash taken to the safe mid-shift.

Every movement takes a reason and is attributed to whoever made it.

#The X and Z report

The X report is a mid-shift snapshot of an open session. The Z report prints when you close it.

Both list the float, cash sales, cash refunds, tips, movements and the reconciliation — and they break out voids and comps on separate lines. Those two look identical to a cashier and completely different to your food cost, so they never share a total.

#After an outage

Cash taken while a terminal was offline belongs to the drawer that was open when the customer paid, not to whichever drawer happens to be open when the sale finally syncs. Each sale carries its capture time, and it is filed by that.

Two things follow from this:

• A drawer will not close while sales are still queued. A Z report counted without them would be wrong by exactly the amount still in the queue, so the close button waits and says how many orders are outstanding. Reconnect, let them send, then count.
• A session that was already closed is recounted if a sale arrives late. The expected amount and the variance are rewritten from the ledger, so the cash is where you counted it and the outage adds no variance of its own. A variance that survives this is a real counting error, which is the whole point of the number.

A drawer opened while offline reaches the server with the rest of the queue. It cannot be closed until it does, because there is nothing on the server to close yet.

#Closing with a large variance

On a terminal, a drawer that is out by more than a small rounding amount cannot be closed quietly. The cashier has to give a reason, and a manager has to approve it with their PIN. The activity log then names both — the cashier who counted and the manager who signed it off.

#Who can do what

cash:read sees sessions and reports. cash:manage opens, closes, and records movements. Cashiers and supervisors have both; accountants have read only.

#Reconciling

Close the session at the end of every shift, not the end of the day. A variance on a four-hour session is traceable; a variance across sixteen hours and three people is not.