Hotpot restaurant cash office clerk - supplier month-end reconciliation tool: have a coding agent build a single-file page where delivery notes, returns, free goods, and the vendor's bill meet, and settle what to actually pay

You are a coding agent. Build me a single-file HTML "supplier
month-end reconciliation" tool for a hotpot restaurant's cash
office - double-click to open in a browser, no network, no
installs, no external resources of any kind (no fonts, icons, or
CSS frameworks).

Part 1 - Workflow (build exactly this; do not invent a new one)
1. The clerk creates a reconciliation: supplier name, statement
   period (start and end date)
2. Enter "our records": pasted from the receiving-slip summary -
   each line item / quantity / unit price / unit; support both
   row-by-row entry and pasting text, splitting columns on tabs
   or commas; rows that won't split go to an "unrecognized" area
   for manual confirmation, never silently dropped
3. Enter "supplier statement": same structure
4. Click "Reconcile": match the two sides on item name + unit,
   then show the line-by-line result

Part 2 - Line classification (every line falls into exactly one
bucket)
1. Matched: item, quantity, and price agree on both sides -
   totals into "confirmed payable"
2. Quantity mismatch: same item, same price, different quantity -
   show the amount and quantity gap; the clerk checks the
   receiving slip, then clicks "ours is right / theirs is right"
3. Price change: same item, different unit price - show both
   prices, the gap, this period's total volume for the item, and
   the money at stake; the clerk marks "accept the new price /
   negotiate"
4. One-sided: on ours but not theirs (usually an uncredited
   return), or on theirs but not ours (usually free goods billed,
   or a missing receiving slip) - flag each line with four
   attribution options: "return credit / free goods / recover
   slip / negotiate"

Part 3 - Settlement math
- Three figures always on screen: confirmed payable (matched
  lines plus accepted price changes), pending amount (absolute
  total of every undecided line), and this month's suggested
  payment = confirmed payable
- Three-state ruling per line: accept / reject / negotiate.
  "Export reconciliation confirmation" unlocks only when every
  line is ruled; if "negotiate" lines remain, list them in a
  reminder dialog but do not block

Part 4 - Data and export
- Everything in localStorage; one reconciliation per supplier,
  switchable and deletable (with a confirm dialog)
- Two exports: the reconciliation confirmation (CSV: item / our
  qty / their qty / price / ruling / attribution) and a
  differences sheet (unmatched lines only, for sending back to
  the supplier)
- A standing one-line warning next to Export: clearing browser
  data wipes all records

Part 5 - Error handling
- Item matching tries exact first; failures retry with trimmed
  spaces, case folding, and common unit aliases (jin/kg,
  case/carton). Lines matched only loosely carry a "fuzzy match"
  badge prompting the clerk to confirm it is the same goods
- Multiple rows of the same item (split deliveries) are summed
  per side before comparing; comparing row-to-row directly would
  produce false mismatches
- No hidden corrections to any total - a one-cent gap displays
  as a one-cent gap; rounding lives in the display layer only,
  calculations keep raw values

Interface: single column, desktop-first (the clerk works at a
desk), results table filterable by bucket. Deliver one complete
HTML file with all CSS and JS inlined, plus a usage note under
two hundred words, in Chinese only.

Why it is written this way

The classic failure of reconciliation tools is ruling on behalf of humans. When delivery notes and statements disagree, "where it differs" is mechanical - software computes that fast and flawlessly; "whether we accept it" is commercial - whether the supplier honors that return, whether that price change gets renegotiated is not the clerk's call. So this tool splits computing from judging completely: the mechanical half is fully automatic, the judgment half is a three-state toggle on every line, and neither crosses into the other. Plenty of tools die on an "auto-prefer-our-side" feature - it silently spends your negotiating chips inside an exported report.

The four buckets follow how discrepancies actually arise: matched, quantity, price, one-sided. "One-sided" stands alone because it hides two mistakes pointing in opposite directions - on ours but not theirs is usually an uncredited return (costs you money if unchased); on theirs but not ours is usually free goods that got billed (costs you money if unchecked). Lumped together as "differences," human attention slides toward whichever half is worth more, and the other half walks.

"Suggested payment = confirmed payable" is a position statement: the recommended payment is neither the supplier's statement total nor our records' total, but the part nobody disputes. Pay the undisputed amount first, park the disputed lines for negotiation - that is the steadiest card a cash office holds in month-end talks. Paying nothing turns every difference into confrontation; paying in full waives the entire audit.

Fuzzy matching is allowed but must wear a badge - that is scar tissue. Supplier statements will never spell item names the way receiving slips do ("fresh tripe" versus "tripe (fresh)"), so exact-only matching makes a tool unusable; but silent fuzzy matching will eventually merge two different goods into one line - fresh duck blood and set duck blood differ twofold in price. Fuzzy matching may exist, flagged on every line for a human to confirm: that is the discipline automation owes to dirty data.

Variables