The inventory list template: one stock-on-hand list for counts, insurance, and taxes
An inventory list template you can fill from a Shopify export: the static stock record that counts, insurance claims, and tax season all depend on.
InventoryX is in development and not available today. ClearStock is the live Shopify app.
The spreadsheet you built to trigger reorders is a good tool. It is also the wrong document for three of the four people who will ever ask about your inventory: the insurance adjuster after a pipe bursts, your bookkeeper at year-end, and the lender who wants to know what the stock in the back room is worth. They don't care about velocity or reorder triggers. They need a dated record of what you own, where it sits, and what it cost — the static stock record, and it deserves its own file rather than a neglected tab.
This article gives you the column spec for that record, a filled example, and the routine that keeps it true. One partition up front so the tools don't blur into each other: the count sheet is the artifact you carry while counting, and the reorder sheet decides when to buy. The inventory list is neither. It is the state of the world, written down on a date — and when the date matters most, it's the only document that does the job.
What the static stock record is
Three jobs, one file:
- Counts. Every count needs a before and after. The list holds the last counted quantity and its date, so the next count starts from a known baseline instead of from hope.
- Insurance. After a fire, theft, or flood, the claim rests on proving what you owned, how much, and what it cost — on or before the loss date. Insurers and adjusters generally ask for exactly that: dated quantities, costs, and evidence of ownership such as supplier invoices. Your specific policy language wins any conflict, but the record is what a claim is built from.
- Taxes and the books. Year-end inventory value on the balance sheet, COGS reconciliation, and — in some states — inventory property tax filings all trace back to a dated stock list valued at cost.
What it deliberately does not contain: sales rates, reorder triggers, or suggested quantities. Those live in the reorder sheet, and mixing the two is how a record meant to be trustworthy ends up edited for convenience.
The columns that matter
| Column | What goes in it | Why it exists |
|---|---|---|
| SKU (per variant) | Your own code, one row per variant | The join key to Shopify, POs, and the count sheet |
| Product & variant | Readable name | Adjusters and accountants are humans reading under stress |
| Category | Your taxonomy | Segments the review; keeps value analysis honest |
| Location | Bin or location name as Shopify knows it | Multi-location stores need per-location rows |
| Unit cost (replacement) | What one unit costs you to replace today | Insurance and valuation run on cost, not retail |
| Qty on hand (book) | Shopify's number on the export date | The baseline the next count checks against |
| Qty counted + date | Last physical count and when it happened | The trust anchor of the whole document |
| Condition | Sellable / damaged / pending disposition | Separates claim-eligible stock from write-off candidates |
| Replacement value | Unit cost × counted qty | The number adjusters and lenders actually ask for |
| Receipt ref | Supplier invoice number or PO | Proof of ownership for a claim |
| Notes | Anything a stranger would need | The 2 a.m. context that saves a week of emails |
Two conventions carry most of the value. First, value at replacement cost, not retail: claims and balance sheets settle on what the stock cost you, and mixing retail into the same column corrupts both. If you want a retail figure for floor planning, give it its own column. Second, every row carries a date — the export date for book quantities, the count date for counted quantities. An undated inventory list is a rumor.
Filling it from a Shopify export
You never key this file from scratch. Start from the system that already knows the quantities:
- Export your catalog from Shopify admin → Products → Export. For a single-location store the product export carries inventory quantities; with multiple locations, quantities come per-location in Shopify's inventory CSV instead (Shopify Help Center, accessed November 2026).
- Keep the raw export in its own tab, untouched. Build the list in a second tab so every refresh is a paste, not a rebuild.
- Add the columns Shopify can't give you: counted quantity, count date, condition, receipt refs, notes.
- Save with the date in the filename —
stock-list_2026-11-02— because versioning is what makes the file admissible as history rather than a snapshot.
A filled example
Pin & Peak Supply sells enamel pins, phone stands, and hiking socks. Their November stock list, after a count on November 2:
| SKU | Product & variant | Location | Unit cost | Qty counted (Nov 2) | Condition | Replacement value |
|---|---|---|---|---|---|---|
| HNS-WAL-03 | Phone stand, walnut | Backroom A2 | $4.10 | 214 | Sellable | $877.40 |
| HNS-WAL-03B | Phone stand, walnut (scuffed) | B-grade bin B1 | $4.10 | 23 | Damaged-pending | $94.30 |
| EPN-OWL-01 | Enamel pin, owl | Backroom A4 | $0.92 | 1,830 | Sellable | $1,683.60 |
| EPN-FOX-02 | Enamel pin, fox | Backroom A4 | $0.92 | 2,415 | Sellable | $2,221.80 |
| HKS-TRC-L | Trail crew sock, L | Stockroom C1 | $6.40 | 348 | Sellable | $2,227.20 |
| Total | $7,104.30 |
The arithmetic is deliberately visible: 214 × $4.10 = $877.40, and so on down to a total replacement value of $7,104.30 as of November 2. Notice what the file did in one stroke: the 23 scuffed stands sit in their own row with their own condition, so a claim or a year-end audit sees the true sellable position (214) and the blemished stock (23) separately. One blended row would have muddied both conversations.
The three jobs, in order of urgency
Insurance comes first, because it's the job you can't do retroactively. A claim after a loss asks: what did you own, how much, what did it cost, and can you prove ownership? The list answers the first three; the receipt refs and your stored invoices answer the fourth. The records a claim requires — and what policies actually pay — are covered properly in the inventory insurance guide; the list is the spine those records attach to.
Taxes and bookkeeping come second. The same file, summed, is your year-end inventory value input — which then feeds cost-of-goods reconciliation and, in states that levy property tax on inventory, the filing itself. The methods behind computing the value number are owned by the inventory value calculation guide; the list supplies the dated quantities those methods consume.
Counts come third, and they're cyclical: every count session ends by writing results back into this file — counted quantity, count date, condition changes. The counting ritual itself (who counts, in what order, with what sheet) belongs to the inventory count sheet template, not here.
Keeping it true
A static record decays silently, so the routine is event-driven rather than ambitious:
- Quarterly: full refresh from a fresh export, plus a version-dated save.
- After every count: write results back the same day, while the count team remembers the anomalies.
- After any warehouse move, supplier change, or cost update: refresh unit costs — a list valued at last year's costs misstates every downstream number.
- Offsite copy, always. The disaster that triggers a claim is the same disaster that can eat the file; a cloud copy is part of the record's job.
- One owner. A list everyone can edit is a list nobody signs. Name the person whose count dates are the truth.
The fill-it mistakes to avoid are predictable: stale unit costs, retail values in the cost column, counted quantities without count dates, and location rows that no longer exist in Shopify. All four surface the first time someone external actually reads the file — which is the worst possible time to discover them.
Common questions
Is an inventory list the same as an inventory count sheet? No. The count sheet is the working artifact for a counting session — printable, organized by bin, with blanks to fill. The inventory list is the standing record that holds the last counted quantities, dates, and values between counts. The count sheet feeds the list; the list tells the next count what it should find.
Should I value the list at cost or at retail? At cost — specifically replacement cost — for insurance and accounting, because claims and balance sheets settle on what the stock costs you. Retail belongs in a separate column, if you keep it at all. A single blended value column is the most common structural mistake in these files and it corrupts both audiences at once.
How often should I update my inventory list? Quarterly at minimum, plus after every physical count and any material change: a new location, a supplier cost change, a warehouse move. Update the dates every time — an update without a new date stamp doesn't count as an update, because the file's entire value is being dated history rather than a floating snapshot.
Can this be the same file as my reorder spreadsheet? Keep them separate. The reorder sheet changes weekly by design and contains velocity math that would clutter a claim document; the stock list changes quarterly and must read as a clean statement of fact. Same workbook is fine — separate tabs, never merged columns. (The reorder spreadsheet owns the full division of labor.)
What will an insurance claim actually ask for? A dated inventory list with quantities and unit costs, evidence of ownership such as supplier invoices or POs matching the receipt references, and often photos. Claims adjusters generally value stock at cost. Your policy's documentation requirements win any conflict, so read them once — then make sure this file satisfies them before you need it.
Next step
Build the file this week from a fresh export — columns as specced above, raw export in a second tab, date in the filename — and fill the counted columns from your most recent count, however old it is. Then schedule the next count using the count sheet template, and read the records an insurance claim requires so the receipt-reference column gets filled with something a claim could actually use.