Closing a Cash Drawer: What Should Your POS Count, Compare and Escalate?

A cash-closing screen should compare an actual count with an explainable expected amount. It should not make a discrepancy disappear by filling the count with the number the software hoped to find. Before commissioning a POS integration, agree what belongs in each drawer session and who may resolve a difference.

This is a workflow brief, not an accounting policy or evidence of fiscal compliance. Have your accountant approve the posting and correction rules for the systems and jurisdiction you actually use.

Begin with the drawer, session and opening float

Identify which physical drawer is being counted and which session its movements belong to. A business-wide daily sales figure is not a substitute for that scope. Decide how a shift handover works if the drawer stays open while the operator changes.

The Odoo 19 POS workflow documentation tells users to check the opening cash amount when opening the register. For your project, specify who confirms that opening amount and what happens if the physical float differs from the suggested figure. A value carried forward from yesterday is not automatically a new observation.

Keep cash sales separate from other payment methods in the explanation. The useful question at closing is what should physically be in this drawer, not how much customers paid across every channel.

Record money that moves without a sale

A fictional shop removes cash from the drawer for safekeeping during a busy afternoon. If that removal is ignored, a later count can look like a shortage even though the money has a known destination.

Odoo documents Cash In/Out for transactions not associated with a sale, including direction, amount and reason. Use that as a product example when specifying your own movement record. Decide who can record a removal, what supporting reference is needed and who confirms custody when money leaves the drawer.

Do not create a fictitious sale or refund merely to make the closing total fit. Transfers, genuine customer payments and later corrections need the accountant-approved treatment. Keep unexplained movements visible for review rather than inventing a reassuring reason.

Make counting an observation, not a copied expectation

Odoo's closing screen shows expected amounts grouped by payment method and allows entry of the numbers of coins and notes. The documentation also describes a shortcut that fills the cash field with the expected cash amount.

Those are different ways to populate a field. If your operating procedure requires a physical count, a copied expected amount does not prove that someone performed it. Decide whether the shortcut should be available and how staff distinguish a denomination count, a directly entered total and an assumed amount.

Require an explicit uncounted state. A confirmed empty drawer and an untouched count field should not both appear as zero. If a recount is needed, retain who entered the observations and why the result changed. These are proposed acceptance requirements, not claims about Odoo's audit history.

Give a difference a decision owner

Agree the permitted closing procedure for a shortage or surplus. Is a recount required? Can the operator submit the difference for review? Which person can approve closing, and does the approval explain the actual discrepancy or merely acknowledge that it remains unresolved?

Odoo documents a configurable maximum difference; when that configured limit is exceeded, the user is instructed to contact a manager to approve closing. That illustrates an escalation control, not the right threshold for your shop or proof that every discrepancy is fraud.

Keep the observed count, expected basis and approval distinguishable. Do not let an approving manager silently overwrite the count to remove a warning. Ask your accountant how unresolved differences and later corrections should reach the accounts.

Demonstrate a complete closing story

Use synthetic transactions in the acceptance criteria. Open with a confirmed float, record a cash sale and a non-cash sale, record a legitimate cash removal, count the drawer and review the resulting comparison. Then try a missing count, a recount and a difference requiring approval.

Also test a close action whose result is uncertain after a connection failure. Staff should inspect the existing session outcome before trying a potentially repeated closing or posting. This is a requirement to demonstrate, not a promise of automatic recovery by the cited product.

Bring the drawer procedure and accountant-approved handover to a POS or workflow integration discussion. The deliverable is an explainable closing record with responsibility for exceptions, not a screen that always ends in a matching number.