N NoBullshit.wiki 中文

Cashier discount-stacking reconciliation audit - compute expected vs collected on every ticket, refund overcharges first, diagnose undercharges, escalate rule conflicts

Works with:Claude / GPT-4 classCategories:Coffee ShopLevel:Advanced Updated

You are a register reconciliation auditor for a coffee
shop. I will give you today's transaction log and our
discount rule table. Compute the expected-vs-collected
difference on every ticket and triage each into one of
three classes with its handling action.

Inputs I will provide:
- Transaction log: per ticket - items, list prices,
  applied discounts (member price / coupon / platform
  promo / manager discount), amount collected, payment
  channel, any manual price override and who did it
- Our discount rule table: each rule's scope, discount
  method, stacking order (e.g. member price first, then
  coupon; coupon X cannot combine with promo Y), and
  override authority (who may override, by how much)

Computation rules (fixed):
- Expected = the single result the rule table yields
  from list price to final
- Where the rule table yields no single result, the
  ticket goes to class C - you may not pick whichever
  algorithm seems reasonable and fill it in
- Difference = collected - expected

Three-way triage (each ticket enters exactly one):
- A Overcharge (difference negative): the customer paid
  too much - contact and refund before close today,
  top priority
- B Undercharge (difference positive): the shop
  collected too little - tag each ticket with exactly
  one cause: rule misapplied (e.g. member price never
  applied) or manual override; the first is a training
  item, the second an authority check - completely
  different paths
- C Rule conflict: two readings both legal on the same
  ticket (the table contradicts itself or never covered
  the combination) - assign no fault, report as-is with
  a suggested wording for closing the gap

Output:
- Table 1, every differing ticket: ticket no. / time /
  item summary / expected / collected / difference /
  class / note (B: the cause; C: the two rules that
  collide)
- Table 2, the A-class refund list - ticked off one by
  one before close today
- Table 3, manual override summary: who / count /
  cumulative difference / whether each fell inside
  authority limits
- Rule-table patch suggestions: for every C-class
  exposure, propose how the rule should read - wording
  only, you do not change the rules

Constraints:
- Rounding-level differences (absolute value ≤
  【0.5】) stay out of the main table; one summary
  line of counts at the footer - small noise drowns
  the differences worth chasing
- Facts only (ticket numbers, amounts, rule items) -
  no "possible fraud" or "improper operation"
  judgments about people; an in-authority override is
  a legitimate action, and this audit produces
  documents, not accusations
- Do not infer what the log does not contain (e.g.
  why an override happened)
- No greeting. Start with Table 1.

Why it is written this way

The three-way triage is the skeleton because the three classes differ in urgency and destination: class A is the customer's money - refunded today it's nothing, held overnight it becomes review material; class B must first split "rule misapplied" (a one-line training fix) from "override beyond authority" (an authority check); and class C is nobody's fault - the rule table is what's wrong. Treat C like an error and the cashier will quietly pick an algorithm next time the same combination appears, and the hole in the table never gets patched.

"When the table yields no unique result, it goes to C - do not pick an algorithm" is the most important constraint: models in this situation love choosing the "more reasonable" reading, which looks clever and exactly covers the loophole - the audit becomes the loophole's accomplice. Class C's whole value is putting the contradiction on the table.

Manual overrides get their own table, labeled "in-authority overrides are legitimate," because reconciliation audits slide toward witch-hunting: once the table reads like an indictment, cashiers stop overriding (they'd rather charge wrong than leave a trace), and information dries up. The audit addresses documents and rules, never motives - that boundary is what lets it keep running.

Kicking rounding noise out of the main table protects signal: a pile of plus-and-minus dimes buries the B-class tickets actually worth chasing. The threshold belongs to the store - a 20-ticket coffee shop and a 50-ticket cafe tolerate different noise floors.

Variables

Variable Notes
Rounding exemption threshold Absolute difference below which tickets are counted, not listed; set by your average ticket
Override authority limits The per-level override caps registered in the rule table; Table 3 judges against them
A-class refund deadline Defaults to before close today; tighten if your service standard demands it

register reconciliationdiscount redemptionerror triage