How Inventory Ledger Tracking Works in Part Manager Pro

When the System and the Shelf Disagree

You walk to bin B-04, expecting 8 of SKU X. You count 6. The system says 8. Two units are unaccounted for.

The next question is the one that matters: when did the bin drop from 8 to 6, and under what actions? If your inventory is tracked as a single number that gets overwritten — the way a spreadsheet cell works — that question has no answer. The cell only knows the last value typed into it. There is no record of the path from 8 to 6, no record of who touched it, no timestamp, no reason.

Part Manager Pro answers that question by tracking inventory as a ledger instead of a counter. Every change to every quantity in your operation is a separate line in the ledger, with a name and a timestamp attached. When the shelf and the system disagree, the ledger is what tells you why.

This guide walks through how PMP’s inventory ledger works, how it stays fast despite recording every movement, and how the same record powers reservations, audits, and marketplace sync.

What a Ledger Looks Like

Here’s the ledger view for a single SKU at a single bin, covering one week of activity:

Read top to bottom, the bin started at 0, received 10, fulfilled two orders (totaling 4 units removed), transferred 2 to bin C-12, and was adjusted down by 2 with a stated reason. Current quantity: 2 units.

The ledger is the source of truth for that count. Nothing else needed to be stored — the current quantity is derived from the line items that produced it. If you ever need to ask “how did this bin get to 2?”, the answer is sitting right there, attributed to the actors who put it there.

This is the same structure that financial accounting uses for a bank balance: the balance is not stored as a number that gets overwritten when money moves. It is calculated from the deposits, withdrawals, and transfers that produced it. PMP applies that same structure to your parts.

Counter vs. Ledger — One Number vs. Full History

A counter answers one question: how many do I have right now?

A ledger answers that and four more:

• How did I get to that number? Every change is a recorded line item.
• Who was involved? Each line carries the user (or the automation engine) that produced it.
• When did each change happen? Every line is timestamped to the second.
• Why did the change happen? Each line carries a reference — an order, a transfer, a receipt — or a free-text reason for adjustments.

A counter overwrites itself every time something changes. A ledger preserves every state the count has ever held. That difference compounds: by the time you need to investigate a discrepancy, a counter has nothing to investigate. A ledger has the entire path.

For a single bin handling a few movements a week, the difference looks small. For a parts operation handling thousands of movements a month across dozens of locations and multiple sales channels, the difference is the whole game.

Movements That Land in the Ledger

Every change to every quantity in PMP falls into exactly one of four categories:

• ADD — stock comes in. A receipt, a return from a customer, a part pulled from a donor unit. The ledger records a positive quantity at a specific location.
• REMOVE — stock goes out. A pick for an order, a write-off for a damaged part, an item consumed in a repair. The ledger records the quantity leaving a specific location, and PMP refuses to remove more than the location actually holds.
• TRANSFER — stock moves between locations. A part goes from intake to bin A-06, or from a backstock shelf to the packing station. The ledger records two linked rows — one negative at the source, one positive at the destination — tied together with a shared reference ID. Total quantity across your operation stays the same.
• ADJUST — a correction. A cycle count reveals a discrepancy, or a data entry error needs fixing. Adjustments can be positive or negative, and they always require a reason — that reason becomes the explanation in the ledger forever.

Every movement that has ever happened in your operation fits one of these four shapes. This guide stays focused on the ledger as a structure. A separate guide will walk through each of the four movement types with concrete shop-floor scenarios — receipts arriving, picks for orders, transfers between locations, and reasoned adjustments after a cycle count — showing what each one looks like to the operator on the floor and how it reads back in the ledger.

The Snapshot — A Cache You Can Always Rebuild

If the ledger is the source of truth, you might wonder: does PMP add up thousands of rows every time someone checks a quantity?

No. PMP maintains a real-time snapshot alongside the ledger. The snapshot is a current-state summary — every item at every location, with its quantity right now. When you look up a part, you’re reading the snapshot. It’s instant.

The relationship between the two is the important part:

• The ledger is the source of truth. It’s permanent and complete.
• The snapshot is a fast cache, derived from the ledger.

Every time a ledger entry is written, the snapshot updates in the same operation — they stay in sync automatically. And because the ledger is complete, the snapshot can always be recalculated from scratch if it ever needs to be. If the snapshot ever disagrees with the ledger (which shouldn’t happen, but engineering for “shouldn’t” is how systems stay reliable), the ledger wins. Always.

This split is why ledger-based tracking does not slow your operation down. You get the speed of a counter and the accountability of a ledger from the same system.

Reservations — Available vs. On Hand

Having 8 units on the shelf does not always mean you can sell 8.

If three of those units are already promised to pending orders, you can actually sell five. PMP tracks this distinction explicitly:

• On hand — the physical count at your locations (from the snapshot).
• Reserved — units claimed by orders that have not shipped yet (see reservation).
• Available — on hand minus reserved.

When an order is allocated, PMP creates a reservation against the item. That reservation reduces the available quantity immediately — before anyone walks to a bin. This is how overselling is eliminated. If you have 8 units and 9 orders come in across eBay and Shopify, units 1 through 8 get reserved. Order 9 gets flagged for attention, not fulfilled with a part you don’t have.

The reservation does not lock a specific bin. A picker can pull the part from any location that has it. The reservation just guarantees the quantity exists somewhere in your operation.

When Something Looks Wrong — Walking the Ledger Back

Back to the bin we opened with: B-04, expected 8, counted 6, two unaccounted for.

With a ledger, the investigation is concrete instead of speculative. Pull the SKU’s history at B-04 for the past week and read the lines:

• Receipt of 10 on Monday — check, that’s where the stock came from.
• Two orders shipped (Tuesday and Wednesday) — check, those match the marketplace records.
• Transfer of 2 out to C-12 on Thursday — check, those should now be in C-12. Walk to C-12 and confirm.
• No adjustment. No removal. No reason for the count to be 6 instead of 8.

You now know two things you didn’t know five minutes ago: the bin should hold 8, and there is no recorded explanation for it holding 6. That tells you the right next step — investigate the floor (was a unit knocked into the wrong bin? was a pick recorded at the wrong location?), and once the cause is identified, post an ADJUST entry with a reason. The reason becomes part of the ledger forever. Six months from now, anyone asking “what happened on Friday at B-04?” sees the answer in plain language.

The ledger does not solve the discrepancy on its own. It does the next-most-valuable thing: it eliminates guesswork from the investigation, narrows the search to where the missing evidence is, and gives you a permanent record of what you concluded once the count is reconciled.

This same structure underpins the broader audit trail in PMP, which combines the inventory ledger with two other layers — field-level change history and automation activity records — to answer questions about who edited records, what stock moved, and what the automation engine did, all in one place.

Common Questions

Is the ledger ever overwritten or deleted?
No. Existing ledger entries are permanent. A correction is recorded as a new entry (an ADJUST with a reason), never as an edit to an old one. Six months from now, the original entry and the correction both still exist, in order.

What happens if a marketplace sync edits an item’s quantity?
Marketplace syncs do not edit ledger entries. When the automation engine detects drift between PMP and a channel — the channel’s count and PMP’s count having moved out of agreement — the resolution path posts new ledger entries with the appropriate source tag, never an in-place edit. The original entries stay in place; the reconciling entries explain what the system did and why.

How fast is the ledger to query for a single SKU’s history?
Reads against a single SKU’s ledger history are fast — the ledger is indexed by item and location, and a typical history read returns in milliseconds. The snapshot handles “current quantity” lookups separately, so the ledger never sits in the hot path for a quantity check.

What’s the difference between a transfer and a remove + add?
A transfer is structurally one logical movement, recorded as two linked ledger rows that share a reference ID. A separate REMOVE followed by a separate ADD would be two unrelated movements with no link between them. The shared reference is what lets you trace a transfer back to its origin and confirm both halves landed.

Can adjustments be made without a reason?
No. PMP requires a reason on every ADJUST entry. The reason is part of the permanent ledger row — it cannot be edited later, and it shows up in any future investigation of that location’s history.

Why This Matters for Your Operation

A counter tells you what you have right now. A ledger tells you what you have, how you got there, and who was involved at every step. The first answer is enough to ship today’s orders. The second is what you need when something looks wrong, when a customer disputes a shipment, when a cycle count surfaces a drift, or when you’re reconciling marketplace quantities against the shelf.

Your snapshot stays fast. Your reservations prevent overselling at allocation time. Your audit trail ties back to the same entries the ledger produces. One system, one source of truth, no contradictions between the channel, the shelf, and the report.

See It in Action

If you are tracking inventory in a spreadsheet today and reconciling counts between channels at the end of every week, the ledger approach eliminates that gap entirely. We can show you what your own shop’s history would look like — using your SKUs, your bin layout, your marketplace channels — without slides.

→ See how a real order moves through this same ledger: From Order to Doorstep — the order lifecycle
→ See the broader audit story: Who Changed What, When, and Why
→ Walk through PMP with us: See the Ledger in Action | See the Full Feature Set

Written by the PMP team. The same engineers who built the system explain how it works — no marketing filter.