Why an End-Product Confirmation Does Not Consume Stock

In EDGEBIC by User Solutions, reporting produced quantity on a job's end product posts a receipt into inventory and issues nothing back out. No matching consumption, no offsetting entry, no round trip. That asymmetry looks like an omission until you work through what the alternative would say, and then it reads as the only defensible option.

This is the rule at the center of production confirmation, and getting it wrong quietly corrupts both the plan and the stock figure.

The Tempting Symmetry, and Why It Fails

The reasoning that leads people astray is short and sounds sensible: a confirmation puts stock on the books, stock gets consumed by jobs, therefore the confirmed units should be consumed too.

Follow it through on an order for 100 with 50 reported. You would post a receipt of 50, then an issue of 50. The on-hand movement nets to zero. The ledger carries two rows describing a journey the units never took: made, then eaten by the job that made them. And the remaining quantity, the whole reason for reporting in the first place, has to come from somewhere else anyway, because the two entries canceled each other out.

Now state the world plainly instead. Fifty exist, and fifty remain to be built. That is one fact about stock and one fact about work. It maps onto one receipt and one subtraction, not two ledger rows that annihilate.

So the receipt stands alone and raises on-hand, exactly as it should, because those fifty units really are in the plant. The remaining build is reduced by arithmetic in the scheduler rather than by a transaction in inventory.

Yield Statement Versus Stock Statement

The clean way to hold the distinction is to ask what the number is a statement about.

A yield statement is about the order's own output. A stock statement is about a component's availability. The dialog is the same in both cases and the difference in what happens afterwards is total. That split is covered in confirming a sub-assembly versus the end product.

The sub-assembly's eventual issue is not a counterexample. When a parent build draws a component out of stock, that is ordinary bill-of-material consumption, and the product being issued is not the product being built. See how a sub-assembly feeds its parent job.

What Confirming 50 of 100 Looks Like in the Ledger

One row. That is the whole inventory footprint of an end-product confirmation on a non-stocked product.

The cost line deserves a note. A confirmation records units, not a purchase, so it does not carry a unit cost and does not move the product's moving-average cost. Letting a planner's yield report drift the costing of a part would be a strange thing for a progress entry to do.

To read these entries for a part, use how to audit the inventory ledger for a part.

The Distinct Entry Type Is Doing Real Work

A confirmation is a positive movement, and so is the automatic finished-goods receipt a make-to-stock job posts when it is marked complete. It would be easy to record both as the same kind of entry. They are deliberately kept apart, and the reason is a failure that would be nearly impossible to trace.

Completion is guarded so a job cannot receive its finished goods twice. That guard looks for an existing completion receipt on the job. If confirmations were recorded as ordinary receipts, the guard would find one, conclude the job had already been received, and return early.

The consequence: a job for 100 with 40 confirmed would land 40 units in inventory and the remaining 60 would never be received at all. Nothing would error. The shortage would appear weeks later as inventory that is quietly light by exactly the unconfirmed quantity, with no obvious cause.

With the types kept distinct, completion counts what has been confirmed and posts only the difference.

Every row lands on 100. The confirmations move the timing of when stock appears, never the total.

The Stocked-Product Round Trip

One behavior surprises planners and is worth stating before it does.

If the finished product is a stocked item, the receipt your confirmation just posted is ordinary on-hand from that instant. Nothing reserves it for the order that produced it. So on the next run, consume-from-stock netting sees available stock and allocates it, and the order that made those units is usually the order that needs them.

Order 5, confirm 2:

remaining after confirmation   5 - 2 = 3
stock available                2   (the confirmation's own receipt)
consumed from stock            2   -> a real issue posts
remaining to build             1
on-hand after the run          0

The planner reports 2 produced and then watches those 2 get drawn back out. This is not the self-consume the design forbids. The issue is a genuine allocation of units that already existed to an order that needs them, and the arithmetic still lands correctly: one unit left to build.

What This Means Day to Day

Three things to carry.

Reporting production raises stock. If your finished part is stocked, expect the on-hand figure to move the moment you press Report, before anything is scheduled or completed.

Reporting production never depletes anything. If you see an issue appear against the finished product after a confirmation, it came from netting allocating stock to an order, not from the confirmation itself.

Completing after confirming is safe. The totals reconcile. There is no double count to watch for and no manual adjustment to make.

The Bottom Line

A confirmation on the end product is a statement about yield, and yield does not consume itself. One receipt, no issue, a smaller remaining build, and a completion step that tops up only what was never reported. Keep those four facts together and the ledger reads correctly on the first pass.

For the wider execution loop see the shop floor execution guide, and for the platform itself, EDGEBIC.