Costing in Real Time: Multi-Warehouse Inventory, ATP & Layered COGS

Ask most inventory systems a simple question — "what did this sale actually cost me?" — and the honest answer is "we'll know at month-end." Stock moves in real time, but cost lags behind it, estimated now and reconciled later. LedgerQ closes that gap. Inventory in LedgerQ is built so that cost is computed from real costing layers at the moment of goods issue — not estimated — and posted to the general ledger as the stock moves. Margin and COGS stay accurate continuously, instead of being recomputed weeks after the fact.

In summary: LedgerQ tracks stock by location as on-hand, reserved, and available, so you promise only what's genuinely free. Every receipt creates a cost layer at its actual base-currency cost; issuing stock consumes those layers by the product's method — FIFO, weighted-average, standard, or specific — and posts the real consumed cost as COGS atomically. Foreign-currency costing fails closed rather than guessing, and a built-in control reconciles the ledger against physical stock.

To see why that matters, it helps to walk through it in order: how you promise an order you can actually fill, where cost comes from, why posting it in real time beats waiting, and how you know the ledger still matches the shelf.

Can I actually promise this order?

The most basic question in any sales conversation is also the easiest to get wrong: can I actually deliver what I'm about to sell? On-hand quantity alone won't answer it. The 40 units sitting in the warehouse might already be spoken for by three other open orders. Sell against that raw number and you've oversold.

LedgerQ answers the question by tracking stock at four levels per location — on-hand, reserved, allocated, and available. When a sales order needs stock, the quantity is reserved against real inventory, and that reservation is persisted — so when you later ship or cancel, the system finds it. "Available to promise" is then a real figure: what's genuinely free to commit is on-hand minus what's already reserved, across every location, not a hopeful reading of the raw on-hand count. The result is a promise you can keep, not a guess.

That promise is only as good as the visibility behind it, which is why LedgerQ tracks stock down to the finest grain:

• Multi-warehouse, with hierarchical locations and transfer workflows between them.
• Batch and lot tracking, so you can trace which batch a unit came from.
• Serial-number tracking — individual item traceability, one unit at a time.
• Reorder points per product, so a low-stock signal is tied to a threshold you set rather than eyeballed.

Real-time visibility across every warehouse, batch, and serial number is what makes the "available" figure trustworthy rather than aspirational.

Where does COGS actually come from?

Once you've promised the order and you ship it, something has to decide what that shipment cost. This is where averaged shortcuts quietly distort your books.

LedgerQ keeps inventory as cost layers. Each receipt creates an auditable layer at the price you actually paid. When goods are issued, the product's own costing method decides which layers to consume — and LedgerQ supports four:

• FIFO draws from the oldest layers first.
• Weighted-average blends the layers into a moving average cost.
• Standard costing values issues at a pre-set standard and books the difference to a variance, so you can see where actual cost diverged from plan.
• Specific costing consumes the exact layer for the exact unit — the right fit when serial or batch identity matters.

The point is that cost of goods sold is computed from those real layers at the moment of goods issue — the actual money you spent on the units leaving the building — not a rough estimate to be trued up later. An expensive lot and a cheap one don't get smeared into a single fictional number; the method you chose consumes the layers you actually hold. And because each product sets its own method, a raw-material line and a finished-goods line can each be costed the way that's right for it.

What happens to cost when currency is involved?

There's a subtlety here that's easy to miss and costly to get wrong. In a multi-currency setup, cost has to respect the currency the goods were actually bought in. LedgerQ handles both ends of that:

• On receipt, inventory is translated to your base currency at the receipt-date rate and the cost layer is created at that base-currency cost — so the layer carries a stable, comparable value.
• On issue, if a foreign layer has no base-currency cost to draw on, LedgerQ refuses the issue rather than booking it at a raw foreign amount. A fail-closed guard beats a silently wrong COGS: collapsing a foreign layer into an assumed base rate misstates margin the moment exchange rates move.

Cost layers also absorb landed cost. Freight, customs, and insurance can be allocated across a receipt by value, quantity, or weight — with a double-count guard so the same charge can't be loaded twice — and any layer shortfall surfaces as a warning rather than a silent gap. The upshot is that the cost sitting in each layer is the true cost of getting those goods onto your shelf, foreign purchases included. (If FX is a big part of your operation, the multi-currency mechanics are worth reading alongside this.)

Why post to the GL in real time instead of at month-end?

Now tie it together. Stock has moved, the layered cost is known at that instant, so LedgerQ posts it then. A goods receipt posts inventory against GR-IR clearing and updates on-hand and average cost; a goods issue consumes the cost layers and posts the actual COGS in one atomic unit — and if any part fails, the whole thing rolls back and on-hand is restored, so a half-posted movement can never leave the books and the shelf disagreeing. Issues also respect a period guard, so a movement can't post into a closed period behind the close's back.

This is the difference between two ways of running a ledger. In the periodic model, inventory and COGS drift out of sync all month; you book estimates, then run a recompute that snaps everything back to reality and, often, surprises you. In the real-time model, every movement carries its own correct, balanced accounting entry as it happens. The GL is never more than a transaction behind the warehouse — which is exactly what makes it part of the same authoritative ledger every report reads from.

How do you know the ledger still matches the shelf?

Real-time posting is only trustworthy if you can prove the ledger and the physical stock haven't quietly diverged. LedgerQ ships a reconciliation control for exactly that: it compares the GL inventory leg, the cost-layer subledger, and the stock-level value, and flags any drift between them. Instead of discovering at year-end that the inventory account and the warehouse have wandered apart, you have a standing check that surfaces the discrepancy while it's small. Adjustments, when you make them, post to the GL rather than living as an untracked note — the books reflect the shelf, not last quarter's belief about the shelf.

Why does this change the decisions you make?

The reason to care about any of this isn't accounting tidiness — it's the quality of the decisions you make on top of the numbers. A margin figure you trust today tells you which products to push and which to reprice, while there's still time to act. An "available" number that reflects real, persisted reservations lets a salesperson commit to a delivery date without crossing their fingers. A COGS computed from the actual layer — in the actual currency, landed cost included — means the profitability of a deal is real, not an artifact of an averaging assumption that month-end will quietly correct. That accuracy carries straight through to online channels too, where marketplace orders post their own GL entries against the same costed stock.

Periodic costing tells you what happened. Real-time, layered costing tells you what's happening — and that's the version you can steer by.

Frequently asked questions

Which inventory costing methods does LedgerQ support? Four: FIFO (oldest layers first), weighted-average (a moving blended cost), standard costing (issues valued at a preset standard with the difference booked to a variance), and specific costing (the exact layer for the exact unit). Each product sets its own method, and the engine consumes real cost layers when stock is issued.

When is cost of goods sold calculated — at sale or at month-end? At the moment of goods issue. LedgerQ consumes the actual cost layers and posts the real consumed cost as COGS atomically as the stock moves, not as a month-end estimate that gets trued up later. If the posting fails at any step, it rolls back and restores on-hand, so the ledger and the shelf never disagree.

How does LedgerQ handle inventory bought in a foreign currency? Receipts translate to your base currency at the receipt-date rate, and the cost layer is created at that base-currency cost. On issue, if a foreign layer has no base-currency cost to draw on, the system refuses the issue rather than booking a raw foreign amount — a fail-closed guard that keeps FX movement from silently misstating COGS. Landed costs like freight and customs are allocated into the layers too.

What is Available-to-Promise, and how is it different from on-hand? On-hand is the raw quantity in the warehouse; available-to-promise is what's genuinely free to sell — on-hand minus quantities already reserved against open orders, across every location. Because reservations are persisted, the available figure reflects real commitments, so you can promise a delivery date without overselling.

How do I know the inventory ledger still matches physical stock? A built-in reconciliation control compares the GL inventory leg, the cost-layer subledger, and the stock-level value, and flags any drift between them. It turns "are the books and the warehouse still in agreement?" into a standing check that catches discrepancies early, instead of a year-end surprise.