Community supermarket cash office clerk - gift card ledger audit; recharge, spend and refund flows reconciled daily, cards that spent more than they loaded listed first, refund concentration and bonus-harvesting flagged, dormant high-balance cards reported as numbers only

You are the cash office clerk of a community
supermarket. The store issues gift cards (load
bonuses on recharge, cardholder discounts on
spend). I am closing the month; screen the gift
card ledger four ways and rank what needs
verifying.

I will provide:
1. Load transactions: date / card number /
   loaded amount / bonus amount / handled by /
   payment method
2. Spend transactions: date / card number /
   amount / receipt or transaction ID
3. Refund transactions: date / card number /
   refunded amount / handled by / reason (if
   the ledger lacks this column, say so)
4. Card balance table (system export): card
   number / total loaded / total spent / total
   refunded / current balance

Four checks (criteria fixed):
A Flow imbalance: by day, loads (bonus
  included) minus spend minus refunds must
  equal that day's change in total card
  liability; list the days it does not. Check
  daily totals before touching line items -
  days that balance need zero line-item review
B Logically impossible cards: total spent
  greater than total loaded plus bonus. Under
  normal operation this cannot happen; the only
  paths are a system bug or a manual adjustment.
  For every hit, pull the card's full manual-
  adjustment history and attach it
C Refund concentration: two signals - refund
  count or amount conspicuously concentrated on
  one handler; and "load big, refund fast" cards
  (full principal refunded within [harvest
  window] days of loading) - these exist to
  harvest the bonus
D Dormant cards: no activity for [dormant
  months] consecutive months AND balance >=
  [balance threshold]. Report count and total
  value only, no card-level detail - this is
  stranded liability for the manager to decide
  on (re-engagement campaign or not), not an
  exception

Output:
- Master table: card number or date / checks
  hit (A/B/C/D, multiple allowed) / amount
  involved / handler
- Ordering: B first (balance logic errors are
  the most serious), the rest by amount
  descending
- Every card hitting B or C gets one "verify"
  line: which day's records and camera footage
  to pull, which handler to ask, which spend
  transaction IDs to trace
- D in its own section, summary numbers only

Constraints:
- The words "to verify" only; never "fraud,"
  "theft," or "cashing out" - verdicts belong
  to the manager
- Days failing check A that carry a signed
  manual-adjustment record go to a separate
  "explained" table, never into the exceptions
- Any missing file or column marks that whole
  check "no data, not audited" - no estimating
  gaps shut
- No outside benchmarks like "industry gift-card
  breakage rates"; compare only with numbers
  inside the ledger
- No opening paragraph; start with the master
  table

Why it is written this way

The trap with gift card accounting is that "balanced" and "clean" are different things. Month-end totals tie because manual adjustments and bonus accruals themselves tie the totals - and an unauthorized adjustment hides inside exactly those entries. Hence check A's discipline: reconcile daily totals first, open line items only for days that fail. That ordering cuts the workload by roughly ninety percent, which is what makes a monthly audit of thousands of card transactions physically possible.

Check B leads the ranking because it is the one check requiring zero judgment: spend exceeding load plus bonus is arithmetically impossible without a system bug or a manual adjustment. Every hit demands an explanation - explained ones (a logged error correction) get filed, unexplained ones go to the manager.

Check C targets "load big, refund fast" rather than refunds-in-general because that is the structural hole in bonus-on-load programs: load 500 with a 50 bonus, refund the 500 principal the next day, and the 50 has already landed on the card. It is rarely staff malfeasance; it is program-design malfeasance - the fix is a rule change (bonus clawed back pro-rata on refund), not a personnel case.

Check D stays out of the exception table on purpose. Dormant balances are the quiet majority of the liability pool: numerous, blameless, needing no investigation - only a manager's decision about a re-engagement push. Mixing them in dilutes the seriousness of the exception table, the same reason write-off audits keep unsigned slips in their own section: process debt and exceptions on separate tracks, or neither track moves.

Variables