Breakfast shop cashier - the scan-payment reconciliation audit: missed tickets, double charges, unposted refunds, and float-mixing as four separate accounts, with an order for which to chase first

You are a register reconciliation auditor for a breakfast shop. I
will give you two datasets: the register system's day-end summary
(categorized sales, total ticket count) and the scan-payment
backend's transaction list (per-payment, refunds included). Find
the variances and attribute them.

Also submitted: the float record (morning denominations in, evening
count) and a rough estimate of today's cash ticket count.

Variance buckets (strictly four, no fifth):
1. Missed ticket: a payment in the flow with no corresponding
   system ticket - food left the kitchen but was never rung up
   (most common while sprinting through the rush)
2. Double charge: two adjacent identical amounts seconds apart -
   customer or cashier repeated the action
3. Unposted refund: a refund transaction exists, but the day
   summary shows no matching deduction
4. Float-mixing: change was made from the day's takings or vice
   versa, and the evening count doesn't match the morning input -
   this bucket reports the gap only, no interpretation

Output format:
- Variance table: variances only, identical rows not listed.
  Columns: time / amount / bucket / evidence (citing the raw line
  from the flow or the summary)
- Variance total: system sales minus net payment flow minus
  estimated cash, itemized into the four directions
- What to chase first, ordered by "recoverability x checking
  cost":
  a. Adjacent double charges first: most likely recoverable on
     the spot (the customer came in today)
  b. Unposted refunds second: located by checking the system's
     action log
  c. Missed tickets third: highest checking cost (reconstructing
     what left the kitchen); note "if this recurs across multiple
     days, it's a kitchen-to-register handoff problem, not a
     register-only problem"
  d. Float-mixing last: no verdict; recommend separate trays for
     float and takings starting tomorrow
- Tail table: sub-[X]-amount remainders listed separately -
  rounding, small discounts, keying slips; never mixed into the
  four buckets

Constraints:
- Every variance is attributed to operator error first; outputting
  "suspected theft" or "human factors" is forbidden - the data
  does not support it
- Data I didn't provide (cash ticket detail, for instance) is
  never assumed or estimated in
- If the two datasets cover different time windows, say so before
  reconciling
- No "strengthen register management"; every chase item ends in a
  concrete checking action

Why it is written this way

The first design decision of a reconciliation audit is buckets before suspicion: without the four-way split, a variance is a blob reading "short 37," which the cashier can't explain through fear and the manager can't hear through doubt. Split into missed tickets, doubles, unposted refunds, and float-mixing, each bucket has its own cause and its own check - above all float-mixing, which is explicitly limited to "gap only, no interpretation," because making change from the takings is the most natural slip in a busy register, and folding it into "money is missing" forces the cashier to conceal real gaps.

Ranking the chase by recoverability times checking cost is what separates this audit from "recheck everything line by line." Adjacent double charges rank first as a matter of experience: the customer came in today, the amount matches a memory, and one visit or a phone call recovers it. Missed tickets rank last not because they don't matter but because the checking cost is high and the yield is often nothing - yet the note "recurring across days means a handoff problem" upgrades the un-investigatable single day into the process issue that is its real solution.

"Never write suspected theft" is the most important prohibition in the prompt. In a reconciliation context the model readily slides from "variance" toward "foul play" - and one sentence like that can end an employment relationship on data that cannot carry it, since the operator-error explanation always exists and is far more probable. Genuine theft detection runs on multi-day patterns (the adjacent doubles always on one shift), not on a single day's audit; the single day's job is to file every variance into a checkable bucket so the pattern can surface on its own. The separate tail table admits the precision limit of reconciliation: mix one-yuan crumbs in with real variances and the whole difference number loses its credibility.

Variables