What "Posting" Actually Means in Business Central Inventory

“Did it post?” gets asked constantly around Business Central, and it’s usually answered with a screen that said “done” or a document that changed status. That’s a reasonable shorthand, but “posting” names something considerably more specific and worth understanding on its own terms — because the honest answer to “did it post” is “look at what got written,” not “did something happen that looked like success.”

Two kinds of entries, always together

Every inventory transaction — a purchase receipt, a sales shipment, a production output, an adjustment — posts two different kinds of entries when it posts at all. A quantity entry, recorded as an item ledger entry, reflects the change in how much of an item exists in inventory. A value entry, recorded separately, reflects the change in what that inventory is worth. One or more value entries exist for every item ledger entry — a single quantity movement can carry more than one value component, for instance a direct cost and an overhead cost booked as two separate value entries against the same one item ledger entry.

These aren’t two views of the same fact; they’re genuinely separate records, created together as a byproduct of posting an item journal line — whether that line was created directly on the Item Journal page or indirectly, by posting a purchase order, sales order, or any other document that ultimately reduces to journal lines under the hood. The path to the journal line varies constantly across Business Central’s many documents. What doesn’t vary is that a real post produces both entry types, tied together by a third.

The third entry: what links an increase to its matching decrease

Item application entries are the mechanism that connects an inventory increase to the specific decrease it eventually satisfies — a purchase receipt to the sale that later consumes it, for instance. This linkage is what lets Business Central’s costing engine carry a specific cost forward from the moment stock came in to the moment it went back out, rather than treating cost as a single average that ignores which units actually moved together.

Watching it happen, with real numbers

Microsoft’s own documentation walks through a small, concrete example worth reproducing because it makes the abstraction click. Post a purchase of 10 units at a direct unit cost of 7 and an overhead rate of 1, on January 1. Three things get written: one item ledger entry (quantity +10), two value entries against that same item ledger entry (a direct-cost entry of 70, an indirect-cost entry of 10), and one item application entry recording that this receipt is available to satisfy a future outbound quantity of 10.

Two weeks later, sell all 10 units. A second item ledger entry is created (quantity -10), a value entry against it (-80, the full cost carried forward), and a second item application entry — this one linking the new outbound entry back to the original inbound entry, quantity -10, closing the loop between the specific receipt and the specific sale that consumed it.

Neither transaction, on its own, touches the general ledger. That happens on a separate, later step.

The same shape covers labor and machine time, not just stock

The item ledger entry / value entry pair isn’t only for goods moving in and out of a bin. Production and assembly orders consume labor and machine time as well as material, and Business Central posts that time using the same basic shape: capacity ledger entries and resource ledger entries record the time consumed, and value entries against those entries carry its cost into the general ledger alongside the material cost, through the identical reconciliation step described below. A production order’s posting isn’t a fundamentally different mechanism from a purchase receipt’s — it’s the same quantity/value pairing, applied to hours of machine time instead of units of an item.

Reconciling with the general ledger is a distinct, later act

At regular intervals — daily for some companies, less often for others — a batch job (Post Inventory Cost to G/L) takes the value entries accumulated in the inventory ledger and posts them into the general ledger, so the two ledgers agree for financial-reporting purposes. Continuing the example: running that job creates matched debit/credit general ledger entries for the inventory account against the direct-cost, overhead, and COGS accounts, all carrying the same posting dates as the value entries they came from. A dedicated table — G/L – Item Ledger Relation — records exactly which value entry produced which general ledger entries, so the connection between an inventory transaction and its financial-statement effect is always traceable, not inferred.

The practical point: an item ledger entry existing does not mean the general ledger has been updated yet, and a company that reconciles infrequently can have real, correctly posted inventory transactions sitting for days before their value entries reach the G/L. That’s a normal, designed lag, not a sign anything is broken.

Why the item ledger, not a status field, is the real answer

Because a real post always produces an item ledger entry — reliably, regardless of which document or journal triggered it — the item ledger is the one place a genuine quantity change is guaranteed to show up. A document’s on-screen status changing, a confirmation dialog closing, or a mobile app displaying “posted” are all downstream signals about a post; none of them is the post. The only way to know a quantity genuinely moved is to look at whether the item ledger entry that would prove it actually exists, with the quantity and item it should carry.

This matters most exactly when something has gone wrong somewhere in the chain — a network hiccup between an app and Business Central, a session that appears to hang, a batch job that’s still running. In every one of those situations, “the screen said success” and “an item ledger entry exists” can come apart, and only one of those two facts is the one worth trusting. It’s also worth stating the reverse, because it’s just as easy to get backwards: the absence of a new item ledger entry isn’t automatically a failure either. A physical inventory count that finds no variance is a completely legitimate, successful count — and Business Central deliberately posts it to a different ledger entirely rather than writing a zero-quantity item ledger entry that would mean nothing. What that specific case looks like, and why it trips up naive verification logic, is its own topic — see cycle counting vs. physical inventory, explained.

Posting isn’t one code path — it’s one guaranteed outcome

It’s worth resisting the instinct to think of “posting” as a single button or a single subroutine somewhere in Business Central. A purchase receipt posts through purchase-posting logic; a sales shipment through sales-posting logic; a warehouse receipt or shipment through their own warehouse-posting logic layered on top of those; a production order through yet another path for output and consumption. Each of those routes is genuinely different code, reached from a different document, often with its own validations and side effects along the way (see why a warehouse receipt isn’t the same as a purchase receipt for exactly how two of these paths diverge). What’s constant across every single one of them is the outcome: a real post always yields the same shape of quantity-and-value entries described above, however it got there. Knowing that shape is what makes it possible to judge, from outside any specific document type, whether a transaction actually posted — rather than trusting whichever document’s own status field happens to be in front of you.

Where this goes next

See item tracking in Business Central, explained for the parallel case where a tracking number can look attached without genuinely being written to the record Business Central’s posting logic reads — the same “what actually got written, not what looked like it happened” discipline, applied to lot and serial numbers instead of quantities. And see cycle counting vs. physical inventory, explained for the specific, easy-to-misjudge case of a count that posts correctly to the wrong ledger from a naive checker’s point of view.

Key terms

New to the vocabulary? Item ledger entry, Warehouse Entry, and Posting are defined in the glossary.

Further reading — Microsoft Learn

Design Details: Inventory Posting — the full worked example this article is based on, including the general ledger reconciliation step and the G/L – Item Ledger Relation table.