Stock Ledger Builder & Count Reconciliation

The stock ledger still builds — it just tells you exactly what it assumed. For every SKU the opening balance is resolved in three steps: (1) if your opening stock CSV has a value for that SKU, it is used as-is and earlier transactions are not replayed, because they are already baked into that figure; (2) if not, every transaction dated before your start date is accumulated to back-calculate the opening balance; (3) if there are no earlier transactions either, the opening is 0 and an “Opening 0 assumed” badge stays pinned to the top of the results — it never collapses or hides. That badge matters: if your stock in out register only covers one month, a closing balance built on a zero opening is a movement total, not real stock on hand.

A negative balance is arithmetic telling you the data is wrong, so the tool never quietly rounds it up to zero — hiding it would hide the cause. It reports the first moment the running balance crosses below zero, with the row number, the date and the balance at that instant, because everything after that point is already unreliable. The usual causes, in order of frequency: a receipt was never entered (goods arrived but the paperwork didn't), an issue was double-counted from a duplicate voucher, or a date was mistyped so an issue sorts ahead of the receipt that covers it. Start at that first negative row and walk backwards — the missing document is almost always within a few days of it.

Variance quantity = counted − book closing. A positive figure means you hold more than the ledger says (an unrecorded return, or an issue booked that never shipped); a negative figure means stock is missing (shrinkage, breakage, mis-picks, or a receipt booked to the wrong SKU). The variance amount is the variance quantity times the most recent purchase unit price found for that SKU — and if your file has no unit price column, the amount is left blank and labelled “no price” rather than shown as 0, because a fake zero would sort your biggest problem to the bottom of the list. Rows are ranked by absolute variance amount (falling back to absolute quantity) so the money follows the standard inventory reconciliation drill: reconcile, re-count the outliers, trace the cause, then post an adjustment.

It scans the whole date column before deciding, instead of guessing per row. If any row has a first field above 12 (e.g. 25/01/2026), the column can only be DD/MM/YYYY; if any second field is above 12, it can only be MM/DD/YYYY. When a file is genuinely undecidable — every value is 12 or lower — it falls back to your browser's locale and, either way, prints “Reading dates as DD/MM/YYYY” in a banner above the results with a dropdown to override it. YYYY-MM-DD, YYYY.M.D, DD.MM.YYYY, YYYYMMDD and Excel serial numbers are all handled by explicit rules, never by the browser's own date parser, which silently reads the same string differently on different machines. The same column-wide scan decides whether 1.234,56 or 1,234.56 is your number format.

Because guessing a conversion rate is how a stock ledger goes silently wrong. If one SKU arrives in BOX and ships in EA, only you know whether a box is 6, 12 or 24 — so the tool keeps a separate running balance per SKU + warehouse + unit and raises a “mixed units” alert instead of inventing a multiplier. Normalise the unit in your source data, or read the balances separately. On privacy: your file never leaves this tab. There is no upload, no server and no account — parsing, the running balance and the count reconciliation all run in your browser's own memory, which is why this works for item costs and volumes that your security team would never let you paste into an online 재고수불부 or 재고실사 대사 service. Only your column mapping, closing period and format preferences are remembered locally; the transactions and count results are never stored.