End-of-day reconciliation

Why are vouchers grouped under one Gift Vouchers category instead of separating issued from redeemed?

Because at EOD the question is “how much voucher liability moved today,” and the breakdown that matters operationally is voucher-as-tender (cash equivalent customers spent) versus voucher-as-product (sale of a new voucher to be redeemed later). The Gift Vouchers row in the EOD breakdown is voucher-as-tender — the dollar value of vouchers redeemed against today's sales. New voucher sales (a customer paying $200 to receive a $200 voucher) land in the Cash, Card, or Transfer row depending on how the customer paid for the voucher, not in the Gift Vouchers row.

This shape keeps the cash-drawer math honest: Cash Expected reflects the cash the till should hold, regardless of whether a voucher product was sold. Voucher liability accounting (how much outstanding voucher balance the tenant carries) is a separate report on /financials — the EOD's job is to balance the drawer, not the voucher book.

How does the EOD handle a partial-day shift change — different staff on the morning and afternoon?

EOD is closed once per day per location — the system doesn't segment a single trading day into multiple shifts at the reconciliation surface. For tenants with a true shift change (morning cashier hands off to afternoon cashier), the operational shape is for each cashier to do their own count-down at handover into a written log (or the Notes field on a draft EOD) and for the end-of-day closer to do the canonical close against the full day's tender totals. The draft EOD is the natural place for an interim count — save mid-day with the partial cash count and a note, the afternoon closer comes back to it.

The cashier-identity attribution that some tenants need (which staff closed the till when, for variance investigation) shows up on the audit trail as the submitter's user ID and timestamp. A future per-shift breakdown is on the product roadmap but isn't shipped today; the workaround for now is a per-shift cash-count log layered on top of the daily EOD.

I have three locations and the same cashier handles drawer counts at all three. Do I close them in any particular order?

No required order — each location's reconciliation row is independent. Pick the location selector for the location you're counting, complete the form, submit. Switch to the next location, repeat. The KPIs on /financials aggregate across all locations regardless of the order they were closed; the History tab on /eod shows the rows in submit-time order per location.

For tenants with location-restricted staff (cashier A only sees location A, cashier B only sees location B), each cashier closes their own location independently. The owner or manager with multi-location access sees the full set on History and on the Finance hub.

A voucher was issued today and redeemed today for the same customer. How does that show up in the EOD?

Two rows in two tenders. The voucher sale lands in the tender the customer paid with — so a cash-paid voucher purchase adds to the Cash row. The voucher redemption against the same day's purchase lands in the Gift Vouchers row (voucher-as-tender) and the rest of that sale's payment (if any) lands in the relevant cash or card row. Net effect: the voucher liability went on and immediately came off again, the EOD shows both halves transparently. This is unusual but it's clean — same-day voucher round-trips look identical to a multi-day round-trip from the EOD's perspective, which is the right shape for cash-drawer math.

The Cash Expected formula uses Opening Float + Cash Sales − Cash Refunds. What about petty-cash withdrawals during the day?

Petty-cash withdrawals aren't modeled in the EOD formula today — the drawer is treated as a closed cash system between opening float and closing float. If your store withdraws cash mid-day (for a supplier payment, a quick stock-up, change for a large note from the safe), the variance will reflect that withdrawal as a negative cash variance. The right shape is to record the withdrawal as an expense on /expenses/new with payment-method cash, and note it in the EOD Notes field. The drawer comes up short against Cash Expected by the withdrawal amount; the expense row carries the accounting.

An “in/out events” surface that lets you record drawer movements alongside the count is the cleaner long-term shape and is on the product roadmap; the cash-as-expense workaround covers the gap for now.

Cash Sales total looks wrong against the till tape

Symptom: the Cash row in Payment Breakdown doesn't match the till tape's cash subtotal for the day. Cause: two common ones. A split-tender sale where the cash portion of a voucher+cash split is being counted under Cash (correct) but the operator expected it under Split (which is the legacy shape). Or a sale was rung up as “mixed” payment_method without a voucher portion, which lands in the Split / Mixed row. Fix: click into the day's sales at /sales filtered to today, sort by payment method, and walk the cash-method sales against the till tape line-by-line. The misrouted-payment cause becomes obvious on inspection.

Submit returns “reconciliation is already closed”

Symptom: the Submit and Close Day button surfaces the already-closed error. Cause: expected. Someone (often the morning closer for the previous day; or another cashier on a shared location) already submitted today's EOD for this location. Submitted rows are terminal — re-opening would invalidate the audit trail. Fix: switch to the History tab and find the submitted row to confirm what was reconciled. If the prior close was wrong (counted under the wrong drawer, miscounted, missed a category), contact support to record an adjustment journal — the canonical fix is an adjustment entry, not re-opening the closed day. The locked-day discipline keeps the audit trail trustworthy for tax-filing season.

Variance shows huge negative number on a multi-location tenant

Symptom: Variance reads -$5,000 or similar on a tenant with multiple stores. Cause: the location selector is set incorrectly — you're counting Store B's drawer against Store A's sales. The page location-scopes both sides of the formula, but only if the location selector is right. Fix: switch the location selector to the location whose drawer you're counting; the numbers refresh. Confirm via the location badge near the heading and the location name that surfaces in the Payment Breakdown panel's caption. If you're a location-restricted staff member with access to only one location, this can't happen — the selector hides.

Today's sales aren't showing up in EOD and it's 6 PM

Symptom: the stat strip shows zero transactions despite real sales today. Cause: two possibilities. The tenant timezone may be misconfigured at /settings/business-profile — if it's set to UTC instead of Australia/Sydney, the day boundary is off by up to 11 hours and today's morning sales are landing in yesterday. Alternatively, the date picker on /eod is set to a past date (loading a History view). Fix: verify the date picker is on today. If the timezone's wrong, an owner or manager fixes it under business profile — the EOD will then pick up the right boundaries on next load. The fix doesn't retroactively re-bucket sales already recorded under the wrong timezone's day; those will be in the EOD they currently belong to and the cleanup is a manual reconciliation.

Submit fails with “Only owner or manager can close end-of-day reconciliation”

Symptom: you can view the EOD totals but the Submit button returns the role-denied error. Cause: expected. Reading totals is matrix-configurable via view_eod_totals; closing the day is a hard-role gate on owner and manager that the matrix can't loosen. The gate-shape discipline keeps the close as a security- non-configurable mutation. Fix: save as draft, hand off to an owner or manager to do the canonical close. The draft's cash counted, notes, and float entries persist so they don't need to be re-typed; the owner / manager reviews and submits.