Costing Model
The costing model decides the unit cost attached to every physical stock movement, and that one decision flows outward: into inventory valuation, into order financials, and into any figure downstream that is denominated in money. It is platform-wide rather than an inventory feature, and it rests on one principle:
Cost is derived, never stored. The ledgers hold movements; source documents hold prices. Every cost you see is computed from those two on the fly, so a corrected price or a re-dated delivery flows into every downstream figure the next time it is read. There is no stored cost to go stale and no recalculation to run.
Which model does the deriving is an organization setting, not a code path. Switch it and every cost on the platform reads under the new model, past movements included.
The four models
Every model plays the same game: arrivals stack up as layers of stock, each carrying the quantity and unit cost it arrived with, and every outflow draws from those layers. The models differ only in the order the layers are taken.
| Model | Draws first | In practice |
|---|---|---|
| FIFO | The oldest arrival | The default assumption of most stockrooms |
| LIFO | The newest arrival | Rising-price environments |
| FEFO | The soonest-expiring lot | Perishables; needs expirations on arrivals |
| Weighted average | No order; every draw takes the blended pool cost | The simplest story for finance |
How a cost is derived
Costs are computed per item, per location, by replaying that slice of the ledger in business order:
- Each arrival seeds a layer at its source cost: a purchase receipt at the price on the receipt line, a manual count adjustment at the current pool cost so it never distorts the running average.
- Each outflow draws layers in the model's order. Its unit cost is the weighted cost of what it drew, and the drawn quantity leaves the layers.
- What remains in the layers is the on-hand valuation.
Because the replay follows the business timeline, movements carry a real date and time and same-day activity costs in the order it actually happened: receive in the morning, ship in the afternoon, and the shipment draws the morning's stock.
Produced goods roll up
A manufactured item's cost is a recursion. The finished good arriving from a work order or production order costs what it consumed plus what the making cost: each consumed input is costed by the same replay (down to purchase receipts as the leaves), and the order's conversion or production cost is added per unit. Reading a sales order's margin therefore drives the whole chain, from the sale back through production to the original purchases, in one derivation.
Cost travels through transfers
A transfer does not price stock; it relocates it. The arrival at the destination inherits exactly the cost layers its shipment drew at the source, each lot with its own cost and expiration, valued as of the moment the goods left. Later activity back at the source, even a later transfer returning the same goods, can never reach back and change what already departed. Cost, lot, and expiration all travel together this way; the Lots & Expirations page covers the identity half of that story.
What sets the cost at each step
| Step | The cost that enters the layers |
|---|---|
| Purchase receipt (material or finished good) | The actual unit cost on the receipt line |
| Work order receipt | Consumed inputs, replayed, plus the conversion cost per unit |
| Production order receipt | Consumed materials, replayed, plus the production cost per unit |
| Transfer arrival | The source layers it drew, as of departure |
| Manual adjustment (up) | The current pool cost at that location |
| Sale or consumption | Nothing; outflows only draw |
Two kinds of money deliberately stay out of unit cost. Order-level costs (shipping, setup, broker fees, fulfillment, and the like) live on their order and feed that order's financials without being smeared across units. And estimates never enter the layers: an ordered-but-unreceived line carries an expected cost on the order, but only the received actuals seed stock.
When stock is short
An outflow can draw more than the layers hold at its location: a work order receipt entered before the purchase receipt it consumed, a connected sale posting against stock that has not been received yet, a transfer whose source was later edited. Posting is never blocked, because out-of-order entry is normal, but the missing units are never silently priced at zero either. They are priced at an estimate: the item's quantity-weighted average receipt cost over the organization's estimate window (Settings, Inventory, Costing), ending on the row's own date. When that window holds no receipts the engine widens to the next one, then takes the last known cost, then zero; choosing "last known cost" skips the windows. A positive adjustment with a declared cost counts as a receipt for this average.
The same rule covers stock that arrives with no cost at all. A positive adjustment with no declared cost takes the average cost of the stock already on hand at that location; when nothing is on hand there is no average to take, so it is priced at the estimate and marked, rather than entering at zero. Declaring the adjustment's cost clears the mark.
Every ledger row says how many of its units were padded and whether its cost rests on padding, its own or inherited: a produced good built from a padded consume carries the mark, and so does every outflow that later draws it. The client renders such figures in the estimate style (italic, lighter, marked "est."), the same way unbacked inventory value is shown. Nothing is stored: the next read re-derives the cost, and the mark disappears the moment the missing receipt is entered with its real date.
Estimates at placement
A placed work order, production order or conversion says what a unit of its output
should cost before anything is received. Each bought input is priced at the
quantity-weighted average of its purchase receipt lines over the module's estimate
window (Settings, Work Orders / Production Orders / Conversions, "same as inventory"
by default), ending on the placement date and at any location; a finished-goods input
(a conversion's input product, a sub-assembly a work order consumes) at its inventory
cost as of that date at the document's location; the entered conversion cost,
production cost or fee on top; and, on a conversion, the materials the repack throws
away deducted, valued from the builds behind the stock on the shelf. The reads expose
the figure per output line and per input, and roll it up in financials.
Nothing is stored. Anchoring the window on the placement date keeps the figure still: a receipt entered later moves it only when it is dated before the placement, which is the healing wanted when history arrives late. Unlike the ledger's padding, a plan never falls back to the last known cost or to zero: an input with no receipt in the window is unavailable, and so is the output built from it.
Planned against final
A work order's read lays the plan beside what the engine derived from its receipts.
Each output line carries its estimated unit cost and, once received, its final average
unit cost (the produced value over the units produced across the receipts); each
receipt shows every produced line's unit cost and value, the consumed lines beneath it
with their quantity, unit cost, value and the units no layer covered, the conversion
line and a receipt total that reconciles with the produced total; and financials
carries estimated and final with the same rows (materials, conversion, goods cost,
the overheads, and the totals beside them). A final that rests on padding is marked as an estimate
everywhere it is shown, and the mark clears when the missing receipt is entered. The
list shows the estimated total while the order is open and the final once it is
received, from one batched engine pass per page; nothing is persisted.
A production order reads the same way, with the provider's price per unit in place of
the conversion cost: the estimate adds the quoted production cost on the line, each
receipt's production cost line carries the receipt lines' own figure (the invoiced
price, editable there), and the production cost row of financials is where the quote
and the invoice meet at order level. Both reads share one reading of the engine, told
apart only by the receipt source type each module posts.
A conversion reads the same way once more, each reception standing as its own receipt
with its fee per unit as the conversion cost line. It adds the one piece nothing else
has, the loss: the materials the repack threw away, valued from the order that built
the input, sits beneath the conversion line as a deduction, so the input units used up
plus the materials the output's recipe adds plus the conversion cost minus the loss reads down to the reception
total, which equals the produced value. The loss inherits the estimate mark of the
input consume it is valued from. financials carries estimated and final with the
rows Input, Materials, Conversion cost, Loss and the total beside them; a conversion
has no overheads, so the total is the goods cost.
Where costing lands
| Consumer | What costing drives |
|---|---|
| Inventory | On-hand valuation, disposal and waste value |
| Purchase orders | The received cost that seeds the layers |
| Work / production orders | The produced-good rollup |
| Sales orders / receipts | Cost of goods sold and margin |
| Reporting | Any money-denominated total |