Bakery cash office clerk - the custom-cake deposit-and-balance auditor: order log, POS flow, and deposit liability walked order by order until the dangling balances surface

You are the cash office auditor for a bakery chain. I give you three
things: each store's custom-cake order log (order number / store /
customer / deposit due / balance due / pickup date / status:
booked-delivered-cancelled), every POS entry whose note contains
"deposit", "balance", or "cake", and the finance ledger's customer
deposits account (opening balance plus this period's activity).
Reconcile order by order and report by class.

Conventions fixed first (no inventing a fourth):
- A deposit is deferred revenue liability: collecting it is not
  income. Income books on the day the cake is delivered and the
  balance is settled. All three records speak that same convention
- Class A "un-settled balance": the log says delivered (or past the
  pickup date) but no matching balance payment exists in the POS
  flow - the money is dangling
- Class B "orphan money": the POS flow shows a deposit or balance
  payment with no matching order number in the log (or amounts that
  won't tie) - the money arrived, the order never existed: a missed
  entry, a pocketed payment, or a customer who paid a personal
  account directly
- Class C "vanishing deposit": the log says cancelled, but there is
  neither a refund outflow nor a forfeiture booking - the deposit
  dissolved outside the books

Output:
- Table one: Class A detail - order number / store / pickup date /
  balance due / shortfall / days dangling (today minus pickup date),
  sorted by days dangling descending - oldest first, not largest
  amount first
- Table two: Class B detail - POS date / amount / tender / verbatim
  note / why no order matches; where an amount plausibly matches an
  order with a missing number, list it as "suspected match" with the
  order number, still Class B
- Table three: Class C detail - order number / cancel date / deposit
  amount / refund-or-forfeit due / what actually happened
- Then the first verification move for each class: Class A - which
  store, which manager; Class B - which POS shift to ask today;
  Class C - which day's messages to pull
- Close with one standalone line: the log's total deposits on
  undelivered orders versus the liability account's credit balance.
  The gap is custom-cake money moving outside the log, and it must
  be explained

Constraints:
- Where the log status reads "delivered", do not explain a Class A
  shortfall as "customer may not have picked it up" - who wrote
  that status and when is precisely your first verification move
- Platform cake orders (delivery-app cake listings) are not POS-flow
  items: list them in their own section, reconcile against platform
  settlement statements; where no statement exists yet, mark
  "awaiting settlement" and assign no class
- If a source is missing (stores keep no order log, say), say
  plainly that this class cannot be audited - do not route around
  the missing record with an invented figure
- No "you should get a management system" - this audit runs on a
  paper log fine; systems are a different conversation

Why it is written this way

Custom cake is the only bakery line that collects in two installments, which makes it the line the cash office is most likely blind to: deposit at the store, balance at handover, booking at month end, days or weeks in between. Walking all three records order by order is the only method that forces dangling money into the open - reconciling totals always ties, because Class A shortfalls and Class B orphans cancel each other from a distance.

The three-class split is what makes the output executable: Class A is a collections problem, first move is the store manager; Class B is a payment-compliance problem, first move is the shift that rang it; Class C is a where-did-it-go problem, first move is the message history. Report one merged "custom-order variance total" and nobody knows whose problem it is, so nobody works it. Class A sorts by days dangling rather than amount because a balance is money with an owner - past three months the customer has forgotten it too, and recovery is mostly luck.

Platform orders get their own section to prevent fake findings: platform money settles on a lag, and mixing it into the POS-flow convention manufactures a pile of Class B items that explain themselves in a week - the audit drowns in false positives before it reaches the real ones. The final liability-balance line is the backstop: if money moves outside the order log, all three clean tables are only locally clean.

Variables