Community supermarket cash office clerk - daily payment reconciliation tool; paste the POS batch and the WeChat Pay / Alipay settlement files, match by reference number first with amount-and-time fallback, four exception tables out, and the data never leaves the browser

You are a coding agent. Build a single-file HTML
tool for a community-supermarket cash office
clerk to reconcile the day's takings: match the
POS transaction export against the WeChat Pay
and Alipay merchant settlement files and surface
the exceptions.

Inputs (three paste boxes plus one manual field,
each with a one-line example on the page):
1. POS transaction export (CSV text): time /
   receipt or ticket number / amount / tender
   (cash / WeChat / Alipay / split)
2. WeChat Pay merchant settlement file (CSV
   text): transaction time / transaction ID /
   amount / status (paid / refunded)
3. Alipay settlement file (CSV text): same
   fields
4. Actual cash total (one number, typed in)

Processing logic:
- Matching priority: reference number first;
   where numbers do not correspond, fall back
   to tender + amount + time (within +/-
   [time tolerance] minutes, adjustable on the
   page)
- Refunds reconcile in the opposite direction:
   POS refunds pair with platform refunds, and
   mismatches there get their own category
- Split-tender transactions (part cash, part
   WeChat) are broken out by tender and matched
   separately, rows flagged "split"
- Transactions straddling midnight (23:50
   sale, 00:10 settlement) are dated by
   transaction time - state the dating rule on
   the page

Output (a printable reconciliation page):
- Three header lines: POS expected totals
   (split by tender) / each platform's
   settlement total / cash variance
- Exceptions in four separate tables:
  (1) in POS, not in platform
  (2) in platform, not in POS
  (3) amount mismatch (both reference numbers
      and the difference shown)
  (4) refund mismatches
- On a clean day, print one line - "all four
  exception tables empty" - and nothing else

Implementation constraints:
- One HTML file, zero external dependencies,
  works offline
- Settlement data is sensitive: all processing
  stays local - no uploads, nothing written to
  localStorage; refresh clears everything
- The CSV parser tolerates the header rows and
  summary rows each platform exports, skipping
  non-data lines; a parse failure names the
  offending line ("line 12 does not look like
  data") instead of rejecting the whole file

Forbidden:
- No accounts, no cloud backup
- No guessing at causes - the tool lists the
  fact (which transaction, present where, off
  by how much); whether it is a receipt problem
  or a system problem is the clerk's judgment
- No charts; tables are enough

Why it is written this way

The hard part of daily reconciliation is never arithmetic; it is matching. POS ticket numbers and platform transaction IDs come from different numbering systems, amounts collide constantly, and timestamps drift (payment confirmation arrives minutes after the sale). Hence the two-tier rule - reference number first, amount-plus-time fallback only where numbers fail, with a tunable tolerance. Return-feed delays differ per POS installation, so hard-coding one number guarantees mismatches.

Four separate exception tables instead of one list, because the next step differs completely by type: "in POS, not in platform" usually means the payment never succeeded while a receipt printed - go find the customer; "in platform, not in POS" may be a missed scan or worse, the most serious kind; "amount mismatch" is often a partial refund; "refund mismatch" is the process tail. Dumped into one list, the clerk re-sorts it daily by hand - the four tables do that sorting for her.

"Nothing in localStorage" and "works offline" are the same coin: settlement files carry the time and amount of every transaction, which is sensitive operating data. The tool must run on the old back-office machine with no internet, and it must not leave that data sitting in the browser overnight. Done-and-discarded sounds inconvenient but matches how paper reconciliation already works - today's exceptions get handled today; the tool should not teach a worse habit.

"No guessing at causes" is a fence for the coding agent. Left alone, the finished tool will gleefully label each exception "possible missed scan" or "possible network delay" - and one wrong label sends the clerk down the wrong trail. The tool arranges facts; judgment stays human.

Variables