Bakery inventory count specialist - the four-column day-end reconciliation tool: whichever SKU misses, the receipts come out the same night

Build me a single-file HTML day-end reconciliation tool for a bakery
count specialist or store manager to run after close: per SKU, check
"opening + baked - sold - other outflows = expected closing" against
the quick close count, and surface every SKU that misses, the same
night. Double-click to open, works offline.

Per-SKU entry, five columns (four feed the math, one is the
comparison):
- Opening: yesterday's closing text, copied out with one click at
  the end of yesterday's check, pasted in today; or typed by hand
- Baked today: output logged by oven batch - per batch or as a
  total, either way
- Sold today: POS line detail pasted in bulk, at minimum name and
  quantity columns; after pasting I confirm the column mapping
  myself - nothing computes until I do
- Other outflows: shrink, staff use, markdown transfers out -
  name / quantity / destination
- Quick count: the after-close physical figure

Math and behavior:
- Expected closing = opening + baked - sold - other outflows;
  gap = quick count - expected closing
- Any SKU with a non-zero gap highlights, with all four columns
  shown - off by one, and the display tells you whether baking was
  under-logged, a sale went unscanned, or an outflow went unbooked
- Prepacked items in pieces, fresh-loose items by weight: both
  units live in one table with a marker, and no total is ever
  computed across units
- "Check it again" is the main scenario: after digging through the
  receipts, editing any cell recomputes every gap live
- One-click copy of the unresolved list (name / gap / four columns)
  as plain text, formatted to paste straight into a message to the
  store manager
- When the check is done, one-click copy of every SKU's closing
  figure (name / quantity) as plain text; tomorrow it pastes back
  in as opening - carry-over runs on copy-paste, not on storage

Hard requirements:
- Single file, no external dependencies, no network requests of any
  kind
- If pasted POS data has the wrong column count or column order,
  error loudly in the UI and name the offending rows - never
  silently compute on misaligned data
- No accounts, no local storage, refresh clears everything, today's
  check dies with today - this is deliberate, do not add
  persistence on your own initiative
- No preset "industry average" numbers anywhere; the SKU list, unit
  markers, and every figure come from entry, maintained by the user
  inside the page

Why it is written this way

What makes a bakery different is that the reconciliation identity holds every day: bake today, sell today means opening + baked - sold - outflows = closing can be checked tonight, not just at month-end. And variance decays overnight - receipts hit the trash, oven-batch memories merge, and by Friday nobody can say whether Thursday's third batch ever reached the counter. A month-end count investigates thirty cold cases at once; a day-end check investigates one hot case while the receipts are still in the drawer. Shops skip the daily check not because the arithmetic is hard but because the four numbers live in four places - this tool only does the hauling, and leaves the judgment to whoever pulls the receipts.

An unresolved row must show all four columns, because "off by one" carries no information by itself: without knowing which column is short, you can only guess. Laid side by side, baking short by one points at an unlogged batch, sold long by one points at an unscanned item at the register, an empty outflow cell points at an unbooked toss. The reconciliation sheet is the diagnosis sheet - that is the tool's whole reason to exist: not to compute the gap, but to locate it.

Two units share one table and never mix: prepacked counted in pieces, fresh-loose weighed - pasting a POS quantity into a weight column is the classic failure of this kind of sheet, and mixed units produce a plausible, balanced-looking number that is pure fiction. Live recompute on every edit exists for the "check it again" loop: the real rhythm of day-end is reconcile, pull receipts, fix one number, reconcile again, and the tool has to survive that second pass without making its user re-enter the day. Opening carries over as pasted text for the same purpose - no number gets stored, but nobody re-types the opening balances either.

No persistence is deliberate - the same defensive line as the deli conversion calculator and the reorder calculator: ask a coding agent for a tool and it ships a "complete solution" with localStorage and a settings page. Day-end reconciliation is a use-and-discard scenario; last night's stale rows leaking into tonight's check is worse than not having the tool. The loud error on misaligned pastes is the other floor: silent mis-parsing is the worst failure a reconciliation tool can have - it would report "all balanced" against shifted data, the receipts would stay in the drawer, and the variance would overnight in someone's head.

Variables

This prompt has no blanks to fill in; the SKU list and unit markers are maintained by the user inside the tool.