The Manufacturing Inventory Ledger in EDGEBIC: Stock as History, Not a Number

A manufacturing inventory ledger records every stock movement as one immutable, signed entry, and computes on-hand by adding them up. Positive quantities are receipts into stock. Negative quantities are issues out of it. Nothing is ever edited or deleted, so the balance you see always comes with the evidence behind it. That is the foundation the planning layer of EDGEBIC by User Solutions is built on, and it is a deliberate design choice rather than an accounting habit.

Most shop systems store on-hand as a number on the item record. It is fast to read and impossible to defend. When the number is wrong (and it always eventually is) there is nothing to investigate. This post explains what a ledger is, what each entry carries, and what the design buys you once demand netting and projected balances start reading it. For the full planning picture including projected balances, forecasts, and the master schedule, start with the inventory and planning pillar.

Why a Ledger Instead of a Stock Number

Think of the difference between a bank balance and a bank statement. The balance answers one question. The statement answers every question you will actually be asked: where did the money go, when, on whose authority, and does the total add up.

Stock behaves the same way. In EDGEBIC, on-hand for a product is the sum of that product's ledger entries. Full stop. There is also a cached quantity on the item record so grids and dropdowns can render instantly, but that cache is never written on its own: it is recomputed from the ledger sum inside the same database transaction as every posting. An integrity check exists precisely to catch any product where the cache and the ledger sum have drifted apart, which is the signature of code (or a person) writing the number directly.

This gives you three things a stored number cannot:

• Traceability. Every movement names its cause. A receipt from a completed build order carries that order's identity. A consumption posted by the scheduler carries the order it satisfied.
• Reconstructability. You can rebuild the balance at any past date by summing entries up to that date, which is what the projection uses to anchor a historical view.
• Correction without erasure. A wrong entry is cancelled by an opposite entry, so the record of the mistake and the record of the fix both survive.

If your inventory discipline today is a spreadsheet plus a monthly count, the concepts in inventory management for manufacturers map cleanly onto this model, with the ledger doing the part the spreadsheet cannot.

What One Entry Actually Contains

A ledger entry is not just a quantity and a date. Each row carries enough context to answer "why did this happen" without opening another screen.

The distinction between effective date and transaction time matters more than it looks. Effective date is the planning bucket: a receipt keyed to the day the material actually landed. Transaction time is when someone told the system. Backdating a receipt to the correct planning day does not falsify when it was entered, because both are on the row.

Cost rides along too. Each receipt updates the product's moving average cost using the standard weighted-average calculation, and the entry stores the unit cost that applied at that moment. A valuation report run against last quarter therefore uses last quarter's costs rather than today's.

The Two Directions Stock Moves

Only two things ever happen to stock, and both come from a clear cause.

Receipts (stock in). The headline case is a make-to-stock build finishing. When a planner marks a build-to-inventory order complete, a receipt posts for the order quantity with the comment "Build to Inventory", and it commits in the same save as the status change. There is a guard against posting twice: if a live receipt already exists for that order, the second attempt is skipped, so clicking Complete twice cannot double your stock. Manual receipts (a purchase arriving, a customer return) post the same way from the Adjustments pane.

Issues (stock out). The headline case here is the scheduler deciding that existing stock covers a demand. That decision posts a single issue for the consumed quantity with the comment "Schedule Transaction", pegged to the order it satisfied. Manual issues cover the rest: a kit pull, a scrap disposal, a sample draw.

Adjustments sit alongside both as a third type for count corrections, and opening balances give a new product its starting position exactly once. The mechanics of each, including which fields to fill and which sign convention applies, are covered in how to record receipts, issues and adjustments.

Reversal: How the Ledger Handles Being Wrong

Nothing in the ledger is deleted, so corrections take a specific shape. Reversing an entry does two things at once: it marks the original as reversed, and it appends an inverse entry that references the original by number, with a comment naming what it cancels.

Both rows stay forever. They net to zero. The running balance returns to where it was before the mistake, and the history shows the mistake and its repair as separate, dated facts.

This runs automatically at the points where it matters:

• Reopening a completed build order reverses its receipt, so stock drops back to the pre-completion level.
• Deleting an order reverses everything pegged to it, receipts and issues alike, before the order row goes. The ledger rows survive the deletion with their order link cleared, which means an order can vanish from the job list while its inventory history remains readable.
• Rescheduling an order that consumed stock reverses only its consumption (never its build receipt) before the engine re-decides. That ordering is what makes rescheduling repeatable: however many times you rerun, at most one live consumption exists for an order at any moment.

That last point is the quiet workhorse. It is explained in full, with the entry-by-entry arithmetic, in how EDGEBIC nets demand against stock.

What the Ledger Makes Possible Downstream

A ledger is not an end in itself. Three capabilities read from it directly, and none of them would be trustworthy against a stored number.

Netting. Before committing machine hours to an order, the engine asks whether stock already covers the demand. It seeds its availability from the ledger sum, and decrements as each order consumes, so two orders in one run can never claim the same units. The narrative version with three orders and 80 units on hand is in the consume-from-stock walkthrough.

Projection. The projected available balance calendar anchors its opening figure on the ledger sum before the window starts, then rolls forward. For buckets entirely in the past, it uses realised ledger movement rather than the plan, which keeps history honest even when the plan has since changed. See projected available balance explained.

Promising. Available-to-promise starts from physical on-hand now, which is again the ledger sum, not a planning figure. That is what makes an ATP answer defensible to a salesperson.

Whether a movement was posted by hand or by the scheduler is recorded on the entry, so you can separate the two when you audit. The transaction history and integrity checks post covers the misconfigurations that make a ledger stop matching the shop floor, and how each one announces itself.

Where Build Policy Fits

Whether a completed order posts a receipt at all depends on its build policy. A make-to-stock order posts into inventory. A make-to-order order ships to the customer and touches inventory only if it consumed stock on the way in. The policy is set per product and can be overridden on any single order, which is covered in make to stock vs make to order.

There is one configuration trap worth naming here because it is invisible: a product can be set to make-to-stock and still have its stocked flag switched off. It then looks configured, but no receipt posts, no netting happens, and on-hand stays at zero indefinitely. The integrity report flags exactly that combination.

What the Ledger Deliberately Does Not Do

Knowing a system's edges is as useful as knowing its capabilities, and two are worth stating plainly.

It is not a warehouse management system. Each entry carries a bin location, defaulted from the product's own default location, and a lot code. That is enough to record where stock nominally lives and to stamp a lot reference on a receipt. It is not per-transaction bin and lot control with directed putaway, pick paths and lot genealogy. If your compliance regime requires full lot traceability through assemblies, treat that as a separate question and raise it early rather than assuming the field name implies the capability.

It is not a purchasing module. Ledger entries can peg to a manufacturing order, a schedule row and a routing step, and a purchase order reference exists on the record. What creates and manages those purchase orders sits outside the planning layer today, so a receipt from a supplier is entered as a movement with the purchase reference in its comment rather than raised from an approved order.

Neither limit stops the ledger doing its job for scheduling, which is to give netting, projection and promising a figure they can defend. Both are worth naming so that nobody discovers them in month three.

The Practical Takeaway

Ask three questions of any system that claims to track inventory. Can it tell you what the balance was on a date two months ago? Can it show you which job consumed a given quantity? Can it prove that a correction happened without hiding what it corrected? A ledger answers all three by construction. A number in a field answers none of them.

If your parts move through both stock and the shop floor, and you want the schedule to know which is which, the ledger is where that starts. Bring an export of your item master and a month of stock movements to a demo and ask User Solutions to show the netting and projection running against your own data.

For the broader platform picture, see the complete guide to EDGEBIC. For how planned inventory turns into real machine time, the scheduling engine guide picks up where this post ends.