Shopify inventory adjustment reasons: a taxonomy that produces reports, not excuses
The seven native Shopify adjustment reasons are too coarse to report on. A sub-code taxonomy for damage, returns, shrinkage, and corrections — with a table.
InventoryX is in development and not available today. ClearStock is the live Shopify app.
Shopify gives you seven inventory adjustment reasons and expects them to carry the story of why your stock changed: Correction, Count, Damaged, Promotion or donation, Received, Return restock, and Theft or loss. Seven buckets keeps the audit trail from being blank, and is far too coarse to answer the question you will actually ask — where did the loss come from, and is it getting worse? "Damaged" covers a crushed carton, a unit broken on the shop floor, and a case that hit its expiry date: different causes, different owners, different fixes.
The fix is not more native reasons — you can't add any. The fix is a controlled vocabulary that lives in the adjustment note, mapped to the native reason at the moment of entry, so every entry is both legal in Shopify and specific enough to report on.
The native list, and what each one is for
As of November 2026, the reason list is fixed, and the choice is made at edit time:
| Reason | Use it for | What the history shows |
|---|---|---|
| Correction | A genuine record error — the number was wrong, not the stock | "Inventory correction" |
| Count | A physical count changed the quantity | "Inventory manually counted" |
| Damaged | Units that exist but cannot be sold | "Damaged" |
| Promotion or donation | Samples, giveaways, influencer seeding, charitable stock | "Promotion or donation" |
| Received | Units arriving from a supplier | "Inventory received" |
| Return restock | Customer returns going back into sellable stock | "Items restocked" |
| Theft or loss | Known or suspected loss with no sellable unit left | "Theft or loss" |
One mechanical detail that undermines the whole system if you let it: editing a quantity with Set to and no reason selected records the change as "Manually adjusted". That phrase is audit-speak for "we will never know." A reason is not a formality; it is the only thing standing between a trail and a list of numbers. (Adjust by always shows the movement, like "Moved to Safety stock", even without a reason — which is its own kind of incomplete.) The mechanics are covered in depth in the inventory adjustments guide.
Why seven buckets can't produce a shrinkage number
Three structural problems, and none of them is Shopify's fault:
Damage is four different problems. Inbound freight damage is a carrier or supplier claim. Warehouse damage is a handling process. Expiry is a buying and rotation decision. Broken-on-display is a merchandising reality. Booked as one reason, they average into a number nobody can act on.
Returns hide the real cost. "Return restock" implies the unit came back sellable. In practice some are resellable, some need repackaging, some are damaged, and some are the wrong item entirely. Restocking a damaged return at the Return reason moves a loss into stock and delays it by a month.
Correction becomes the junk drawer. Because Correction is the default and feels harmless, everything lands there — case-vs-each mistakes, app sync errors, the unit a staff member gave away, the shortfall nobody investigated. The default is always the busiest reason in a store with no policy, and that is precisely the pattern the taxonomy exists to break.
The taxonomy: seven native reasons, one controlled code list
Put the sub-code at the start of the adjustment note, in a fixed format — CODE — short description — so it is greppable in exports and readable in the history. Keep the list to codes you will actually use.
| Native reason | Sub-code | Use when | What the report tells you |
|---|---|---|---|
| Damaged | DMG-IN |
Damage found at receiving, before shelving | Carrier/supplier claim volume; fix is packaging or a claim habit |
| Damaged | DMG-WH |
Broken in the warehouse or stockroom | Handling process; often clusters by shelf or by person |
| Damaged | DMG-EXP |
Past expiry, best-before, or seasonal write-off | Buying depth and rotation; the most preventable bucket |
| Theft or loss | LOSS-EXT |
Confirmed or strongly suspected external theft | Store layout, tagging, high-value placement |
| Theft or loss | LOSS-INT |
Staff-related loss, investigated and documented | Access controls, permissions, and process — handle with care |
| Theft or loss | LOSS-CAR |
Carrier loss or non-delivery after dispatch | Claims and carrier choice; needs a tracking reference in the note |
| Theft or loss | LOSS-UNK |
Unexplained variance from a count, no cause found | Your true unknown; watch the trend, not the single entry |
| Promotion or donation | PROM-SMP |
Samples sent to buyers, press, or wholesale prospects | Marketing spend that was never in the marketing budget |
| Promotion or donation | PROM-INF |
Influencer or affiliate seeding | Cost per campaign, at cost |
| Return restock | RET-SEL |
Returned unit inspected and returned to sellable stock | Return rate and resale recovery |
| Return restock | RET-REP |
Needs repackaging or cleaning before resale | Labour cost hiding inside returns |
| Correction | COR-UOM |
Case-versus-each or unit-of-measure error | Whether your buying or receiving uses the wrong unit |
| Correction | COR-KEY |
Keying or transposition error | Training and double-check needs |
| Correction | COR-SYS |
App sync, marketplace, or integration wrote the wrong number | Which integration to audit |
| Count | CNT-CYC |
Scheduled cycle count | Accuracy trend by ABC class |
| Count | CNT-FULL |
Annual stock take | Baseline reset; comparable year over year |
Two rules keep this usable. Never invent a code mid-adjustment — a code written once and never again is noise; add codes in the monthly review if a real pattern needs one. And the note names the thing: DMG-IN — 3 units crushed, carton 4 of 6, PO 2026-118 is evidence, while DMG-IN alone is a category.
Returns deserve their own rule
Returns are where reason discipline pays the most, because the default behavior is wrong in both directions. The rule that holds up:
- Inspect before adjusting. A return that arrives and gets restocked sight-unseen is a promise that the next customer may not thank you for.
- Sellable →
RET-SEL, quantity back to available. - Sellable after work →
RET-REP, and count the labour somewhere, because repackaging is the hidden cost of a generous return policy. - Unsellable → do not use Return restock at all: receive the return through your returns flow and adjust with Damaged and
DMG-*, so the loss is booked where it happened rather than laundered through inventory.
The dollar difference is not trivial. A store processing 400 returns a month at an average cost of $14 has $5,600 of stock moving through this decision monthly; getting 10% of the classification wrong is $560 booked in the wrong place.
Reporting: what to look at monthly
Three views, each with a specific trigger, all filterable in the Inventory adjustment changes report (availability depends on your plan, as of November 2026):
- Reason mix by month. If Correction exceeds Count, your trail is documenting mistakes rather than stock. If Correction is dominated by
COR-UOM, you have a units problem, not an accuracy problem. - Damaged by sub-code, in dollars at cost.
DMG-INrising means claims, not carelessness.DMG-EXPrising means you are buying too deep for the shelf life. LOSS-UNKas a share of counted units. This is your unexplained rate — the number that says whether the shrinkage prevention stack is working. Watch the trend across quarters, not the individual entry.
One more filter worth setting up: by staff member and by location. Not to accuse anyone, but because a cluster is a question with a timestamp, and a question with a timestamp is a conversation you can have without guessing. The same filtering is what makes an inventory audit possible without a full investigation.
The policy, in five lines
Five rules, one page, and they cost nothing to adopt:
- No quantity edited without a reason — "Manually adjusted" in the log is a coaching moment, not a rounding error.
- Received stock enters through purchase orders or transfers, never as a manual adjustment.
- Damaged and Theft or loss entries get a one-line note the same day, naming the item, quantity, and reference.
- Returns are inspected before restocking; unsellable returns are booked as Damaged.
- Sub-codes are chosen from the printed list; new codes are added in the monthly review, not invented in the moment.
That is the whole system: a fixed vocabulary, a properly used note field, and one person reviewing the mix monthly. It costs nothing and turns the trail you already have into the report you have been missing.
Common questions
What are the inventory adjustment reasons in Shopify? Seven, fixed as of November 2026: Correction, Count, Damaged, Promotion or donation, Received, Return restock, and Theft or loss. You pick one at the moment of the edit; the history displays the reason, and using "Set to" without one records the entry as "Manually adjusted."
Can I add custom adjustment reasons in Shopify? Not natively — the list is fixed. The workable substitute is a sub-code in the adjustment note (for example DMG-IN — 3 units crushed, PO 2026-118), mapped to the closest native reason. Exports and the adjustment report can then be filtered or grepped by that prefix.
Which reason should I use for a customer return? Return restock only if the unit is going back into sellable stock after inspection. If it is damaged, repackage-only, or unsellable, book it with Damaged so the loss is recorded where it occurred.
What's the difference between Correction and Count? Count means a physical count changed the quantity — the stock was there or wasn't, and counting found the truth. Correction means the record itself was wrong: a keying error, a case-versus-each mistake, an integration writing a bad number. Using Count for record errors hides your data-quality problem inside a counting metric.
How do I report on adjustment reasons over time? The Inventory adjustment changes report filters by reason, SKU, location, staff, app, and date range, which is where reason mix and trends come from (plan-dependent). Export it monthly if your plan doesn't include it, because the per-product history only covers the last 180 days.
Next step
Print the sub-code list, tape it next to the packing bench, and enforce it for two weeks before judging it. Then pull one month of adjustments and sort by reason: the largest bucket is the process that needs the fix, and it is almost never the one you expected.