Amazon Inventory Tracking System: Reorder Points, Safety Stock, and Sync Gates

An inventory tracking system for Amazon FBA is three things, not one: a ledger that holds every unit in exactly one state, two computed thresholds — a reorder point and a safety stock level derived from your own sales and lead-time history — and a set of sync gates that refuse to let a stale or unreconciled number trigger a purchase order. Most sellers build only the first part, read the dashboard, and call it a system. The dashboard is an input. The system is what decides when that input is trustworthy enough to spend money on.

This guide is the method, not a product list. For software that implements it, see AMZFinder’s inventory management tools roundup and its inventory and operations workflow page. Everything below works in a spreadsheet first — the right place to prove the logic before paying for it.

What an Amazon Inventory Tracking System Actually Tracks

The commonest defect in a seller’s tracking sheet is one column called “inventory” mixing states that behave differently. Inbound units cannot be sold tomorrow; reserved units cannot be sold today. Split the number into five states:

Upstream and on-order units have no Amazon-side source of truth — they exist in your records only, which is why the system has to be a ledger you own rather than a dashboard you read. Units in Amazon’s upstream storage tier are upstream, not sellable, until they land.

Layer 1: The Ledger — One Number, One Owner

The ledger rule is non-negotiable: every state has exactly one system of record, and everything else is a view of it. If two systems can both write the “sellable” number, they will disagree, and you will settle it by guessing.

• Daily immutable snapshots. One row per SKU per day, never edited. A level tells you where you are; a series tells you how fast you are moving, which is what every formula below consumes.
• Deltas over levels. Sales velocity, receiving time, and adjustment rate are all differences between snapshots. Keep only the current level and you can compute none of them, so you end up borrowing someone else’s rule of thumb.
• An adjustment column. Lost, found, damaged, and disposed units are the reconciliation signal for gate 2 below, and unaccounted units are the raw material for a reimbursement claim.

Sixty days is the minimum useful history; ninety is better. Until then, any reorder point you compute is a placeholder.

Layer 2: Compute the Reorder Point

The reorder point answers one question: at what on-hand level must I place the next order so replenishment arrives before I run out?

Start from the derivation. Over a lead time of L days you sell roughly D̄ × L units, where D̄ is average daily demand. Order at exactly that level and — if demand and lead time both land on their averages — you hit zero on the day the shipment becomes sellable. That is the theoretical minimum, and it fails for one reason: averages are hit about half the time, so ordering at D̄ × L means roughly a 50% stockout chance every cycle. Hence:

Reorder point = (D̄ × L) + safety stock

Two Amazon-specific corrections to L:

1. L is checkout-to-sellable, not factory-to-door. It ends when units turn sellable in the FBA inventory report, not when the carrier marks delivered. Receiving and check-in sit inside your lead time; measure them from your own history (tracking FBA shipments), not from a blog post.
2. D̄ must exclude days you were out of stock. A SKU that sold zero on eleven days because it had none produces a depressed average, a low reorder point, and another stockout. Drop stockout days, or the system encodes its own past failures as forecast.

Worked example. Sixty days of clean snapshots give D̄ = 42 units/day. The last six purchase orders had checkout-to-sellable lead times of 38, 44, 41, 52, 46, and 49 days, so L = 45 days. Cycle stock = 42 × 45 = 1,890 units — the floor, not the reorder point.

Layer 3: Size Safety Stock From Your Own Variability

The percentage rules circulating in seller communities — “keep 20% extra,” “hold 30 days of cover” — are not derivations. They are one seller’s variability generalised to yours, and they under-buffer SKUs with erratic supply while over-buffering SKUs with steady supply.

The defensible version sizes the buffer from two measured variabilities. Demand over the lead time is a sum of L daily draws, so its variance is L × σ_D². But L varies too, and a long lead time costs D̄ units per extra day, contributing D̄² × σ_L². Independent variances add, so:

Safety stock = Z × √( L × σ_D² + D̄² × σ_L² )

σ_D is the standard deviation of daily demand, σ_L that of lead time in days, and Z the service-level factor you choose:

Worked example, continued. From the same data, σ_D = 14 units/day, and the six lead times have a sample standard deviation σ_L = 5.1 days.

• Demand-variability term: 45 × 14² = 8,820
• Lead-time-variability term: 42² × 5.1² = 46,570
• Total 55,390; square root = 235 units
• Safety stock at 95%: 1.65 × 235 = 388 units
• Reorder point = 1,890 + 388 = 2,278 units

Note what the arithmetic exposes: the lead-time term is 84% of total variance. This SKU’s stockout risk is a supply-consistency problem, not a forecasting problem, and better demand modelling will not fix it. Halve σ_L from 5.1 days to 2.0 by consolidating freight and booking appointments earlier, and safety stock falls from 388 to 208 units — a 46% cut in buffer capital at an unchanged service level. That is what a derived buffer surfaces and a flat percentage hides.

One boundary: the formula treats demand as roughly symmetric and independent day to day. Deal spikes, Q4, and coupon bursts break both. Run it on a de-spiked baseline and add planned event volume as a separate explicit line.

The Amazon Constraints That Break a Textbook Reorder Point

A reorder point expressed in units is an incomplete instruction on Amazon, because the constraint Amazon enforces is volumetric. Its FBA capacity management announcement states: “We’ll set capacity limits and measure sellers’ inventory usage in cubic feet (vs. number of units)” (sell.amazon.com, published 17 January 2023; checked 2026-08-10). Three consequences:

• Convert every order quantity to cubic feet before approving it. A 2,278-unit reorder point means nothing until multiplied by packed cubic volume per unit and compared against remaining capacity. Two SKUs hitting their reorder points in the same week can be individually correct and jointly impossible.
• Efficiency feeds back into the ceiling. Amazon states that “FBA capacity limits are influenced by sellers’ IPI scores, as well as other factors such as sales forecasts for their ASINs, shipment lead time, and fulfillment center capacity” (checked 2026-08-10). Over-buffering is self-punishing: it consumes capacity, drags the efficiency metric, and shrinks next period’s ceiling. See the IPI score guide and FBA restock and capacity limits.
• Extra capacity is bid for, not requested. On Capacity Manager, Amazon writes: “Sellers can request additional capacity based on a reservation fee that they specify. Requests are granted objectively, starting with the highest reservation fee per cubic foot until all capacity available under this program has been allocated” (checked 2026-08-10).

A fourth constraint hides inside the sellable number: stranded, unfulfillable, and aged units occupy capacity while contributing nothing, and aged units accrue a surcharge on top — see stranded inventory and the aged inventory surcharge. Both belong in gate 3.

Sync Gates: Five Checks Before a Number Moves a Decision

A gate is a pass/fail check with a defined action on failure. The point is not perfect data; it is making bad data stop visibly instead of propagating quietly into a purchase order.

Gate 1 — Freshness. Every state carries a timestamp. Pass if the newest snapshot is within your sync interval plus one interval of slack. On fail, block automated reordering and fall back to the last known-good snapshot with an explicit flag. A silently stale feed is more dangerous than a missing one, because it looks healthy.

Gate 2 — Reconciliation. Per SKU and period, check: closing sellable = opening sellable + checked in − sold − removed + returns restocked + adjustments. Pass if unexplained adjustments stay under a threshold you set — 0.5% of units received is a reasonable starting point, and it is your choice, not an Amazon standard. On fail, the difference is a research task: lost, damaged, or a mis-mapped SKU, often a claim.

Gate 3 — Exclusion. Recompute “available to sell” as sellable minus reserved, unfulfillable, and stranded. Pass if that figure, not the headline number, feeds your reorder point. On fail, you are forecasting against inventory you cannot sell.

Gate 4 — Lead-time truth. Recompute L and σ_L from the last six to twelve shipments at every check-in. Pass if current parameters sit within one standard deviation of the values your active reorder points were built on. On fail, recompute before ordering — a lead-time shift moves the buffer far more than a demand shift.

Gate 5 — Capacity. Convert the proposed order to cubic feet, add inbound and sellable volume, compare against your limit. Pass if the total leaves headroom for other SKUs due to reorder in the same window. On fail, stage the excess upstream or sequence by margin per cubic foot.

Run gates 1–3 on every sync, gate 4 on every check-in, gate 5 on every order approval.

Common Mistakes

• Counting reserved units as sellable. The commonest phantom in-stock reading, invisible until the SKU goes to zero overnight.
• Using supplier-quoted lead times. Suppliers quote production, not checkout-to-sellable. Quoted lead times also carry no variance, setting σ_L to zero and deleting the dominant term in the safety stock formula.
• One service level for the whole catalogue. Z is a per-SKU decision. A high-margin hero at 99% and a long-tail accessory at 90% is a rational portfolio; 95% for everything is a default, not a choice.
• Reordering on a level instead of a projection. Comparing today’s on-hand to the reorder point ignores units already inbound. Compare on-hand plus inbound plus on order.
• Never revisiting D̄ after a price change. A price move or lost Buy Box shifts demand within days while the trailing average takes weeks to catch up; the margin side of that call is in FBA fees and profit.

Implementation Checklist

1. Create one row per SKU per day with the five states, and stop editing history.
2. Accumulate 60 days of snapshots before trusting any computed threshold.
3. Compute D̄ and σ_D from stockout-free days only.
4. Log checkout-to-sellable lead time for every shipment; compute L and σ_L from the last six or more.
5. Pick Z per SKU by margin and substitutability, and write down why.
6. Compute safety stock and the reorder point, recording inputs beside outputs so a future you can audit them.
7. Record packed cubic volume per unit so gate 5 can run.
8. Implement gates 1–5 as explicit pass/fail columns, not as judgement.
9. Re-run weekly, and after any price, supplier, or capacity limit change.
10. Only once all ten steps run reliably in a spreadsheet, consider whether restock software earns its subscription. Automating an undefined process buys faster wrong answers.

One adjacent tool, since gate 2 generates its input: ReimburseOps audits FBA reimbursements from an uploaded Seller Central CSV, flagging under-reimbursed, unmatched, and inconsistently valued records. It is read-only — no Seller Central connection, no claims filed for you — and charges a flat subscription rather than a percentage of recoveries (Free $0 forever, Pro $19/month; checked 2026-07-27).

Frequently Asked Questions

How much history do I need before the formulas are trustworthy?

Sixty days of daily snapshots for demand, and at least six completed shipments for lead time. Fewer than six lead-time observations makes σ_L unstable, and since that term usually dominates safety stock, an unstable σ_L means an unstable buffer. With less history, treat the output as provisional.

Should safety stock just be a percentage of monthly sales?

That shortcut is what the derivation replaces. In the worked example a “20% of monthly sales” rule gives 252 units against a computed 95% buffer of 388 — a 35% shortfall on a SKU whose supply is genuinely erratic. On a SKU with consistent freight the same rule over-buffers. The percentage is wrong not because it is simple, but because it ignores the variability driving the risk.

Does the reorder point change during Q4?

Yes, through D̄ and usually σ_L too, since carrier and receiving times stretch under peak volume. Do not simply raise Z for the season: recompute with the higher expected demand and longer, more variable lead times, and check gate 5 first — Q4 is when a reorder point and a capacity limit are most likely to conflict.

What if my capacity limit blocks the quantity the reorder point asks for?

Sequence rather than shrink. Rank competing SKUs by contribution margin per cubic foot, fill capacity from the top, and stage the remainder upstream. Cutting every order proportionally lowers the service level on every SKU at once instead of accepting a planned stockout on the least valuable one.

Conclusion

A working inventory tracking system is not a better dashboard. It is a ledger you own, thresholds derived from your own history, and gates that stop unverified numbers from spending money. Its highest-leverage output is the one the worked example produced almost as a side effect: when the lead-time term dominates safety stock, the cheapest way to protect availability is to make supply more consistent, not to buy more inventory. You cannot see that from an inventory report — only from a system.