What a good inventory log records (and what most of them miss)
Every inventory system shows you a number. Fewer show you how the number got there. That second part, the log, is what you reach for the moment the number looks wrong, and it’s only as useful as what it bothered to write down. A log that says “Stock changed” with no name, no reason and no before-and-after is barely better than no log at all.
This guide is a checklist. It covers what every line in an inventory log should capture, the two kinds of change most logs forget, and a few rules that keep a log trustworthy and readable once it has thousands of lines in it. Use it to judge the system you have today, whether that’s software, a spreadsheet or a clipboard on a nail.
The six things every line needs
Think of each log line as a tiny incident report. If any of these is missing, there’s a question it can’t answer.
- Which item. Obvious, but it has to survive renames and deletions. A line that points at “item 214” is useless once item 214 is gone.
- What changed. Which bucket (on the shelf, on order, out for delivery, damaged) or which detail of the item.
- By how much, or from what to what. A movement needs the amount, with its unit (“−2.5 kg”, not “−2.5”). An edit needs the old value and the new one.
- Who. A named person, not “admin” or a shared tablet login. If everyone signs in as the warehouse, the log can only ever say the warehouse did it.
- When. An exact timestamp, recorded by the system rather than typed by a person at the end of the shift.
- Why, and through what. An optional reason (“spoiled in transit”, “cycle count”) and the channel: by hand, after a scan, from a received order, from an assembly build, or by an AI assistant.
Most systems get the first five for stock movements. The sixth is where logs quietly fail: a −12 with no reason looks identical whether it was a sale, a spill or a theft, and that’s exactly the difference you needed to know.
The first thing most logs miss: edits
Logs tend to track quantities and ignore everything else about an item. But some of the most expensive mistakes are edits, not movements:
- A threshold moved. Someone lowers a warning level from 18 to 2 to stop an annoying alert. Three weeks later you run out and nobody was warned. Without an edit log, the alert “just stopped working”.
- A unit was relabelled. “Can” becomes “Case”, and every count since means something twelve times larger. Spotting when that happened is the difference between a five-minute fix and a recount.
- A cost changed. Your stock valuation jumps overnight. Was it real, or did someone type an extra zero into the unit cost?
- A supplier was swapped. Reorders start going to the wrong vendor and nobody remembers changing it.
An edit line needs the same who-and-when as a movement, plus the before and after values. “Warning level: 18 → 2, by Sam, Tuesday 8:57” ends the mystery in one line.
The second thing: deletions
Deleting an item is the most destructive thing anyone can do in an inventory system, and in many tools it’s also the most silent. The item disappears and, often, its history goes with it. That’s backwards. The moment an item is deleted is the moment you most want to know who did it, what it held at the time and what had happened to it before.
A good log treats a delete as one more event: a line that names the person and the item, with the item’s past left intact. Better still, the delete can be undone, because “oops” is the most common reason things get deleted.
Rules that keep a log trustworthy
Lines are never edited, only added
If a log line can be edited, the log proves nothing. Mistakes happen, so the fix is a new line that corrects the old one. The trail then shows both the error and the correction, which is exactly what an auditor, a manager or your future self wants to see.
The system writes the line, not the person
Who and when should come from the sign-in and the clock, not from a field someone fills in. Self-reported logs drift toward whatever is convenient to report.
Every path writes to the same log
Stock moves through manual edits, scans, received orders, builds and, increasingly, AI assistants. If any of those paths skips the log, the log has a blind spot exactly where someone will eventually look.
Rules that keep a log readable
A log you can’t read is a log nobody reads. Two habits help a lot:
- Collapse noise, never meaning. If one person taps +1 five times in a minute, one +5 line tells the same story with less scrolling. But a change with a reason, or an edit, deserves its own line every time.
- Describe compound actions in words. “Used to build 2 × Sourdough loaf” on a flour line explains a removal that would otherwise look like shrinkage.
And the log has to leave the system when you need it to: an export with a date range for the accountant, or a filterable list when you’re hunting for one change in a busy month.
A quick audit of your current setup
Pick one item that had a busy week and try to answer these from your records alone:
- Who made the last three changes to its quantity, and why?
- What were its warning level and unit cost a month ago?
- If someone deleted it this morning, could you tell who, and get it back?
- Which of its changes were made by an AI assistant or an integration rather than a person?
If any answer is “we’d have to ask around”, that’s the gap. Spreadsheets are a common culprit: version history records cell edits, but not who moved which item for what reason, and it’s easy to lose in a copy or an export. We go deeper on that trade-off in signs you’ve outgrown spreadsheets.
In Simple Inventory, every item keeps this kind of log automatically: stock movements with amounts, units and optional reasons, edits with before-and-after values, deletions with the person who made them (and a Restore button), and AI changes labelled as AI. Lines can’t be edited, and the whole history exports to CSV. See the audit trail feature for what each line looks like.
Keep reading: why inventory logging matters more than your count, how to trust AI changes to your inventory, and an audit trail for every unit.