Know what should be in every drawer—and why.

A practical POS cash-up procedure

1. Assign the physical till to the right register. Before counting, confirm that the screen names the register staff are actually using. The database session is register-specific; the physical handling procedure must preserve that same boundary. If two tills are mixed after opening, software cannot reconstruct which bills belonged to which session.

2. Count the starting float by denomination. Enter quantities rather than one mental total. The bill-and-coin grid makes the count reviewable and reduces arithmetic outside the system. Confirm the expected starting amount before opening the drawer for sales.

3. Record non-sale movement when it happens. Use cash adds when money is deliberately placed into the drawer and cash drops when it is removed. Enter the denomination quantities and use the note for the reason your operating policy requires. Cash adds and cash drops require the register-management permission; they are not general cashier controls.

4. Keep refunds attached to drawer movement. Cash refunds reduce the physical drawer, so LiftedPOS posts a matching cash drop against the open session. The transaction report and the drawer log serve different accounting questions: one describes the customer transaction, while the other explains money moving through the till.

5. Stop taking cash before the final count. Establish a clear operational cutoff, then count all bills and coins. Enter the physical quantities on the Close tab and review counted cash and the over / short preview. Resolve obvious counting mistakes before submitting the close.

6. Close the session and retain the result. On submission, the server recomputes the money rather than trusting a browser-provided total. The stored opening cash, expected cash, closing cash, variance, cashier, and timestamps give the operator a session record to investigate when the result needs follow-up.

Why the server calculates the final over/short

A browser preview is useful feedback, but it is not an accounting control. LiftedPOS receives denomination quantities, validates that they are non-negative whole counts, converts them into currency values, and uses half-up rounding for the final money fields. The final expected cash and closing variance are recomputed within the close transaction.

The close operation also takes a lock on the register row. That makes concurrent requests line up around the same authoritative state: two people cannot legitimately open the same register session at once, and two close requests cannot both finalize the same open drawer. This is a database concurrency control, not a promise that staff can ignore physical till custody.

Cash permissions should match the operating policy

The system distinguishes ordinary tender activity from register-management actions. Cash adds and cash drops are restricted to employees with the register-management permission. That lets a merchant decide which roles can change the expected drawer outside of sales and refunds.

Software permissions work best with a written procedure. Decide who may open a register, who may add change, when a mid-shift drop is required, what note is expected, who counts at close, and who investigates a variance. LiftedPOS records the session activity; the merchant supplies the physical custody and escalation policy.

Fail closed when cash has no open drawer

The register workflow does not treat an open drawer as optional metadata. In the SPA sale path, a cash transaction without an open drawer is rejected. The offline-sync path applies the same boundary: offline transaction synchronization is cash-only, but it still needs the selected register's current open session.

That behavior protects POS register reconciliation from an easy failure mode—sales accumulating while the drawer session has no known starting point. It does not guarantee uninterrupted offline operations under every device or network condition. Merchants should validate the exact browser, workstation, register assignment, and reconnection sequence used in the store.

How to evaluate cash register closing software

Use a realistic test rather than a perfect demo count. Open a register with a known float. Complete cash sales and a cash refund. Record one cash add and one cash drop with notes. Attempt a cash sale on a register with no open drawer and confirm that it stops. Then count the first drawer with a deliberate variance and close it.

Review whether an operator can answer five questions from the result: Which register was open? Who opened it? What events changed expected cash? What was physically counted? What was the final over / short? Then repeat with two browser sessions trying to close the same register. The second action should not create a second valid close.

Finally, test the physical operation: drawer assignment, shift changes, change orders, drop timing, refund custody, network loss, closing access, and variance escalation. A good POS calculation is the center of the procedure, not a substitute for one.

Connect drawer controls to the rest of the operation

Employee permissions determine who can perform sensitive register actions. Transaction reporting explains the sales and refunds behind the day. Industry workflows determine when cash changes hands—at a retail counter, convenience register, restaurant closeout, bar, cafe, smoke shop, vape shop, or liquor store. The drawer session supplies a register-level physical cash record alongside those operational views.

LiftedPOS software is $100 per month for the first station and $50 per month for each additional station. Standard hardware is $499.99 per station to purchase or $39.99 per month to lease. Payment processing, implementation scope, and specialized hardware are separate. The live demo is the fastest way to see whether the current register behavior matches your policy.