Costing & Valuation — what stock is worth, and what a sale costs¶

What this covers. Every gram of food in stock carries a number: what it's worth. Every plate that leaves the line carries another: what it cost. This chapter explains where those numbers come from. It covers the weighted-average method that blends many purchase prices into one cost per item per warehouse (a live running average, plus an authoritative figure struck at the period close); the landed-cost build-up that turns a supplier invoice into a per-unit value by folding in freight, handling, and each line's own non-recoverable tax; why tax is a fact of each line, never a pot on the invoice header; how the same word "tax" means opposite things to inventory value in two regions (US sales tax you keep vs. EU VAT you get back); the difference between what you owe a vendor and what the goods are worth; and why shuffling stock between your own warehouses moves quantity around without changing total value.

1. Why a blended average, and why two of them¶

The business problem. A restaurant buys the same flour many times in a month at different prices — €0.80/kg one week, €0.95/kg the next. Sacks get tipped into one bin and commingled. When a gram of that flour ends up in a dish, what did the gram cost? You can't answer it per-sack: the sacks are indistinguishable once they're in the bin. The cost of "the next gram out" is genuinely undefined at the sack level.

The method: weighted-average cost. Weighted-average cost (WAC) means every unit on hand is treated as carrying the same blended cost — the total value of the pool divided by the total quantity in it. Buy 200 kg at €0.80 and then 500 kg at €0.848, and from then on every kilogram is worth the single blended figure, not "the old price" or "the new price." This is the standard choice for food because ingredients are fungible (one gram is as good as another) and commingled (physically mixed in one bin), so tracking the cost of each individual sack — the alternative methods that try to peel off "the oldest layer first" — is a fiction the bin can't honor. Blending also smooths week-to-week commodity swings into a stable food-cost percentage, instead of making margin lurch every time a delivery arrives at a new price.

Why two flavors of the average. The system runs the blended average at two different cadences, and the difference between them is the heart of this chapter.

	Running average (live)	Period-close average (authoritative)
When	continuously, as receipts arrive	once per period, at the close
What it is	the running claim — "what we think it's worth right now"	the authoritative valuation — "what it's actually worth"
How	re-blends the pool on every receipt	blends over the whole period, then re-spreads the value onto the counted quantity
Truth source	the book of recorded movements	the physical count (the count wins)

The running average is a perpetual figure — perpetual inventory means the on-hand and its value are kept live and correct after every single movement, not recomputed in a monthly batch. It's an honest running estimate, but it can only see what was recorded. The period count is the truth event: it sees what the book can't — theft, spoilage, over-portioning, a mis-typed delivery. The closing average re-spreads the value that should remain over the quantity that actually remains, and that re-spread is how the cost of shrinkage lands in the food-cost number. §6 walks the math.

The value lives at the warehouse. There is one cost pool, one blended average, per item per warehouse. A warehouse is the boundary value is drawn around: every unit of an item inside it carries the same cost. Inside it sit storage locations — the areas a quantity is counted in ("walk-in," "bar," "back room") — which record where the units are and carry no value of their own. You count where things are; you value where they are all priced alike. The same item therefore has a distinct cost in each warehouse: flour in the commissary store and flour in the bar store are two pools with two averages. (The restaurant — the operation whose profit-and-loss the cost is charged to — is a separate axis; it never owns a cost pool. See Scope & locations.) "Company-wide cost" is just the special case of a company that happens to run a single warehouse.

Why not one company-wide average? A single blended cost across all warehouses is tempting — one number, less machinery — and for a single-site operation it even produces the same figures. But the moment two sites buy at different prices it fails three ways at once. Say the commissary holds 100 kg of flour bought at €1.00/kg and the bar store buys 100 kg at €2.00/kg: a company-wide blend prices everyone's flour at €1.50. Now the bar's food-cost looks 25% better than what it actually pays and the commissary's looks worse — the cross-site comparison that multi-site books exist to enable is exactly what the blend averages away. A shortage at the commissary gets valued with the bar's money. And when the bar receives an expensive delivery, the reported value of the commissary's untouched stock changes — no event, no movement, yet its number moved, which makes the figure impossible to audit from that warehouse's own history. Per-warehouse pools cost nothing in exchange: aggregation is a one-way street, so any company-wide figure — total stock value, total cost of goods — is just the sum of honest per-warehouse figures, while a company-wide blend can never be split back into honest per-warehouse ones.

A dish is never stocked — its cost is one company-level number. A dish is made to order: nothing sits in a store waiting to be sold, so a dish has no warehouse and no pool of its own. Its cost is a derived roll-up, not a stored value. A dish-cost snapshot records what a dish costs to make, both cost worlds side by side: the stock-valuation figure — the active recipe exploded to its ingredient leaves, each stocked leaf priced at its company-wide blended average (total value over total quantity across every warehouse that holds it), non-stocked leaves at their latest receipt reference price — and the menu figure, the same tree priced at current item prices (taught with the price policies in Menu & catalog §5). What each snapshot saves is deliberately lean: the per-serving food/package/direct totals for each world, the recipe version priced, the date it was priced as of, and a count of any leaves that had no cost to read — never the ingredient-line breakdown, which is priced fresh on demand whenever a screen wants the detail.

This is the one place a company-wide blend is the right answer rather than a per-warehouse one. Stock value still lives at the warehouse — that is what the ledger and the close rest on. But a dish belongs to no warehouse, so pinning its stock-valuation figure to any one store's average would be arbitrary: the same dish would cost differently depending on which store you happened to pick. The company blend is the honest, stable reading of what a dish's ingredients are worth in stock. The actual cost of goods sold is a separate, warehouse-accurate fact: when the dish is sold, the sale consumes each leaf from the store it is routed to, at that store's real average cost, and that is what reaches the period close and the P&L. The dish-cost snapshot is the planning number; the ledger is the truth, and the two can legitimately differ.

The system owns freshness. A snapshot is appended when a recipe activation changes today's effective version (future-dated activations do not write history early), and a nightly sweep re-prices in both worlds every dish whose recipe is filled and active. What earns a cost is the recipe, not a place on the menu: a dish still being written has a real cost the day its card goes live, and a shop that spends three weeks finishing its menu should not find three weeks of missing history waiting for it. Only a retired dish is left alone. The sweep also catches future-dated menu changes on the morning they become effective; there is no separate date-crossing event. Re-running the sweep appends another fact row, which is harmless and gives the history needed for ingredient-level cost trends. The dish row reads the latest snapshot.

Recorded dish-cost history is facts only. A dish with no active recipe for the date is not priced at all — nothing is invented, and nothing is written. It can still be previewed: the read-only preview resolves today's active recipe, or falls forward to the smallest upcoming active version when none is effective yet, prices it the same way, and flags the answer as a projection. That preview writes no snapshot. Future costs are therefore visible to the operator without mixing projections into the history used by COGS and trend charts.

Recipe editors use the same costing ingredients without recording history. Any recipe version — including a draft that is still being authored — can be priced on demand. A dish recipe prices at the company blend, like the dish itself; a prep or item recipe — which is produced into a warehouse — prices at a chosen warehouse's average. Non-stocked rows use their active sub-recipe or latest receipt reference price, and pinned sub-recipes price their frozen tree scaled to the row quantity. The response is a read model for the editor: ingredient line costs, packaging rows, batch totals, per-serving cost, and, for prep recipes, the theoretical full cost per output base unit.

2. The two money figures on a goods receipt: what you owe vs. what it's worth¶

The business problem. When a delivery arrives, two different people ask two different questions about it, and they get two different numbers.

The accounts-payable question: how much do we owe this vendor? That's the payable — the gross figure, every charge on the invoice including all tax. It's what you write the check for, and what you tie out against the supplier's invoice.
The inventory question: how much is this stock worth in our warehouse? That's the net figure — what gets recorded as the value of the goods and feeds the blended average. It excludes any tax you'll get back from the tax authority (§4).

Every goods receipt therefore carries two distinct money totals — a gross / payable total and a net / capitalized total — and the same two figures exist on every line: each line has its own gross and its own net, and the document totals are simply the sums of its lines. The split has to live at the line because tax does (§3, §4): one line's tax can be fully reclaimable while its neighbor's is not. ("Capitalized" just means "recorded as the value of an asset you hold" — here, the stock in your warehouse, rather than an expense or a tax you'll reclaim.)

Whenever a line's tax is zero, or none of it is reclaimable — the US case (§4) — that line's two figures are equal, so it's tempting to keep only one number and use it for both. That is a genuine and expensive mistake the moment any reclaimable VAT enters the picture: if you feed the gross figure into inventory value, you capitalize tax you're going to get refunded, which overstates what the stock is worth, overstates the cost of everything made from it, and inflates the food-cost percentage. The rule that prevents it:

The blended average is fed the NET (capitalized) value, never the gross (payable) total. The gross total is for paying the vendor and matching the invoice; the net total is for valuing the stock.

3. Landed cost — turning an invoice into a per-unit value¶

The business problem. A delivery is not simply "line items at line prices." The invoice also carries shared charges — freight, handling — that belong to the goods but aren't attached to any one line; and each line carries its own tax, at its own rate. To value a single gram of flour honestly, the shared charges have to be pushed down onto each line, the line's own tax has to be split into the part you keep paying and the part you get back (§4), and the result divided by the quantity received. The all-in result is the landed cost (also called the delivered cost): the true cost of the goods once they've landed in your warehouse, not just the sticker price on the line.

The build-up. For each line on the goods receipt:

1. Subtotal             = Quantity × UnitPrice − Discount
2. + Freight/handling     (the document's shared overhead, allocated BY VALUE — each line's share of the subtotals)
3. + Non-recoverable tax  (the part of the LINE'S OWN tax you DON'T get back — see §4)
   ───────────────────────────────────────────────
   = the line's NET value  ── this is what feeds the blended average

and, in parallel, the line also rolls up to its gross / payable value (subtotal + freight share + the line's full tax) for the invoice tie-out.

Why the shared charges are allocated by value. Freight on a mixed pallet isn't truly proportional to money value — a case of saffron weighs almost nothing and a sack of potatoes weighs a lot, yet the saffron's value dwarfs the potatoes'. But allocating by value is the defensible, auditable default: it needs no per-line weight or volume figures (which invoices rarely carry), it never piles more freight onto a line than that line's own cost, and it's what the standard reference systems do unless told otherwise. Splitting freight by actual weight is a later refinement, not the starting point.

Why tax is never allocated. Freight is genuinely a document-level pot — one truck, one charge, no honest way to pin it to a line — so it has to be spread. Tax is the opposite: it is a fact of each line, set by what the line is. Real EU invoices mix rates on a single delivery — Portugal taxes most food at 6%, an intermediate band (wine, some processed goods) at 13%, and everything else at the 23% standard rate — and real US invoices mix resale-exempt food lines with taxed supplies on the same bill. A header tax pot spread by value would smear the wine's 13% onto the flour and the flour's 6% onto the wine — wrong on every line, in a way no tolerance forgives. So every goods-receipt line carries its own tax rate (or amount) and its own recoverability, and the build-up above reads the line's own figures.

Worked example — a single line. A line reads Quantity 10 × UnitPrice €5 − Discount €2 = €48.00 subtotal. The document carries €6.00 freight, and this is the only line, so it absorbs all of it. The line itself is taxed at the 23% standard rate: 23% × 48 = €11.04 of VAT, fully recoverable in the EU regime — so none of it enters the net. Net value = 48 + 6 = €54.00; gross/payable = 54 + 11.04 = €65.04. Under the US regime the same line — a taxed supply, say at 8% = $3.84, none of it recoverable — folds its whole tax into the net: net and gross coincide at 48 + 6 + 3.84 = $57.84.

From line value to per-unit cost. The number that actually feeds the blended average is the line's net value ÷ the quantity it represents, in base units. The base unit is the single canonical unit every quantity of that item is stored in — grams for a mass item, milliliters for a volume item (see Units of measure). Twenty sacks at 25 kg each is 500 kg of flour, and the per-kilogram landed cost is the line's net value divided by 500. No quantity reaches the ledger except converted to base units first, so the per-unit cost and the blended average always speak the same unit.

4. Region-adaptive tax — US sales-tax vs. EU recoverable VAT¶

The business problem. The single word "tax" means opposite things to inventory value in two tax regimes.

US (sales / use tax). A purchase for resale is exempt from sales tax; if any tax is nonetheless charged on a purchase, it is simply a cost of the goods and is folded into their value. Nothing is reclaimable. Tax you pay here makes the stock worth more.
EU (Portugal first — recoverable input VAT). Value-added tax (VAT) paid on a business purchase is reclaimable from the tax authority — it's money the authority owes you back (a receivable), not a cost of the goods. The accounting standard for inventory is explicit that stock is valued net of any recoverable tax: the cost of a purchase excludes taxes you'll get refunded. Folding reclaimable VAT into the stock value would overstate the cost of goods and the food-cost percentage.

The design: one path, with a per-line tax split. Rather than run two separate costing engines, every goods-receipt line simply splits its own tax into two parts:

the line's tax        = its own rate (or stated amount)              → a fact of the line, never a header pot (§3)
recoverable part      = the reclaimable input VAT (default: 0)       → a tax receivable, NEVER part of stock value
non-recoverable part  = the line's tax − the recoverable part        → folded into the line's net value
net (capitalized)     = subtotal + freight share + non-recoverable part → what feeds the blended average
gross (payable)       = subtotal + freight share + the line's full tax  → what you owe / the invoice tie-out

Why this collapses both regions into one path. The US case is just recoverable part = 0 on every line: the non-recoverable part equals the line's whole tax, the net value rolls all of it into the stock, and net equals gross — line by line. The EU case sets a non-zero recoverable part, which is routed off to a tax receivable and kept out of the stock value. There is no "US engine" and "EU engine" — only a per-line field that happens to be zero in one region. The receipt movement from the vendor into the warehouse always carries the net value; the recoverable VAT is booked, separately, as money owed back to you — it lands in the input-VAT receivable described in Financial boundary.

The region is a per-company setting alongside the company's currency. The exact rates and what's reclaimable are configuration — they need legal confirmation before going live, but they're settings, not a different costing method.

One currency per company. A company values its pools in a single currency, and every blended average is in that currency. Goods receipts in a foreign currency (capturing an exchange rate at receipt, then accounting for the rate drift later) are a deliberately separate, later concern — out of scope here.

5. Worked example — a two-line goods receipt, end to end¶

A goods receipt into a kitchen store (a warehouse that supplies the kitchen station), two lines, with freight and per-line VAT. We use the EU regime (Portugal) so the line-level rates are visible; the US case falls out line by line, as the contrast below shows.

Document header: freight = €30.00. There is no header tax figure — tax lives on each line (§3).

Lines:

Line	Item	Qty (unit)	Unit → base	Base qty	UnitPrice	Subtotal	VAT rate
A	Flour	20 sacks	25 kg/sack	500 kg	€20.00	€400.00	6% (food — reduced)
B	Wine	5 cases	6 × 0.75 L = 4.5 L/case	22.5 L	€20.00	€100.00	13% (intermediate)

Σ subtotals = €500.00. One delivery, two rates — exactly why tax can't be a header pot: most food sits at Portugal's 6% reduced rate, wine in the 13% intermediate band (and a cleaning supply on the same truck would be at the 23% standard rate).

Step 1 — allocate freight by value (subtotal × freight ÷ Σ subtotals):

Line A: 400 × 30 / 500 = €24.00
Line B: 100 × 30 / 500 = €6.00

Step 2 — each line's own VAT (its own rate × its own subtotal — never allocated):

Line A: 6% × 400.00 = €24.00
Line B: 13% × 100.00 = €13.00

Step 3 — recoverability (EU: both lines fully recoverable). The non-recoverable part is €0.00 on each line; the full 24.00 + 13.00 = €37.00 routes to the tax receivable, not into stock value.

Step 4 — the two money figures, per line and per document:

Line	Subtotal	+ Freight	Net (capitalized)	+ Recov. tax	Gross (payable)
A	400.00	24.00	424.00	24.00	448.00
B	100.00	6.00	106.00	13.00	119.00
Document	500.00	30.00	530.00	37.00	567.00

The document gross / payable €567.00 is what you owe the vendor and tie out against the invoice. The document net / capitalized €530.00 is what gets recorded as the value of the stock. The €37.00 in between is money the tax authority owes you back.

US contrast. Run a similar delivery under the US regime: the flour is bought for resale, so its line carries no tax at all — its net equals its gross at $424.00. Swap the wine for a case of cleaning supplies taxed at 8%: that line's $8.00 of tax is not recoverable, so it capitalizes — net = 100 + 6 + 8 = $114.00, equal to its gross. Net equals gross line by line, and for two different reasons: a tax of zero, and a tax you don't get back. There is never a recoverable pot — and there is still no header pot either: the exempt food line and the taxed supplies line each carry their own tax facts.

Step 5 — per-base landed cost (net value ÷ base quantity):

Flour: 424.00 / 500 kg = €0.848 / kg
Wine: 106.00 / 22.5 L = €4.7111 / L (≈ €3.53 a bottle)

Step 6 — update the blended average for flour at the kitchen store. The receipt movement (vendor → kitchen store) carries the net €424.00 for 500 kg. Suppose the pool opened the period with 200 kg @ €0.80/kg = €160.00. The blended intra-period cost (opening value plus this period's receipts, over the total quantity) is:

blended cost = (opening value + period receipts) / (opening qty + receipt qty)
             = (160.00 + 424.00) / (200 + 500)
             = 584.00 / 700
             = €0.834286 / kg

Every gram of flour consumed this period is now valued at €0.8343/kg — the single blended cost, fed the net €424.00.

What the net/gross discipline buys you. Had we (wrongly) blended the gross €448.00 instead, the average would be (160 + 448) / 700 = €0.8686/kg — a 4.1% overstatement of flour cost, flowing straight into the cost of every dish and the food-cost percentage, on a tax that gets refunded. That gap is exactly what valuing stock net of recoverable tax closes.

At the close, the physical count drives the final figure: if 650 kg was projected but only 640 kg counted, the closing cost re-spreads the projected value over the 640 kg actually on hand, and the 10 kg gap lands in the cost of goods sold as shrinkage (§6).

6. The two-stage close math — striking the authoritative cost¶

The running average is live all month. At the close, each warehouse strikes its authoritative figures for the period — and there are two, computed in two stages. (The close process — the count, the overages and shortages, the self-check, the blockers — lives in Period close; this chapter owns only the valuation math.)

Stage 1 — the intra-period blended cost (what consumption is valued at)¶

Everything consumed during the period — sold, transferred out, wasted, consumed internally (a staff meal, a recipe test) — is valued at one blended figure:

intra-period cost = (opening value + period receipts' net value)
                  / (opening qty + period receipts' qty + auto-correction qty)

This blends the opening value with the period's receipts into a single average, then prices every outbound flow at that one number. It is the same running average as §1, just computed once across the whole period rather than re-blended after each movement.

The net/gross discipline lives exactly here. "Period receipts' net value" is the period's receipts at their net / capitalized value — not the gross payable. Feeding gross here is the precise spot where reclaimable tax would leak into the cost of goods. The denominator is base-unit quantity, guaranteed by the convert-to-base rule (§3).

The "auto-correction quantity" folds a recorded over-receipt adjustment into the available pool before the blend, so an over-receipt is priced consistently with everything else.

Stage 2 — the value-conserving closing cost (what rolls forward)¶

Then the physical count comes in. The count wins — the counted quantity is the physical truth, not the book's projection. The quantity side is settled first: the gap posts as an overage or shortage adjustment, and each adjustment carries value the moment it posts — a shortage leaves at the running average like any other issue, and an overage enters at the running average, because found stock is stock that was already paid for, not free stock (against an empty, zero-value pool it enters at zero; only a warehouse's one opening count — the count that starts its stock-keeping — carries operator prices — see Period close). With the quantity already honest, the close's remaining job is price: re-spread the value over what actually remains, at the period's one blended cost:

closing cost  = intra-period cost
closing value = counted-qty × closing cost

The closing cost is the figure that rolls forward as next period's opening cost — so value is conserved across the period boundary, and the value of stock that is not there flows into the cost of goods sold as shrinkage rather than being carried forward as an asset. This is the authoritative weighted average, reconciled by the count. The re-spread itself is recorded as an explicit valuation entry — a value-only, append-only adjustment linked to the close that produced it — so the closing value is always reconstructible from recorded artifacts, never a silent shift.

Why found stock isn't free. Pricing an overage at the running average is the standard treatment in inventory accounting, and the reason is that count noise must net to zero across periods. Counts oscillate: this month a bin gets missed, next month it is found again. Watch the round trip:

 month 1: count misses 10 units → shortage −10 @ €1.00 → €10 charged to shrinkage
 month 2: count finds them again
   at the average: +10 @ €1.00 → €10 credited back → the round trip nets to zero ✓
   at zero:        +10 @ €0    → the price dilutes to €0.909; month 1's charge
                   stays forever; every future issue of every unit under-costs;
                   the €10 sits in stock but on no book

Found-at-zero turns oscillating noise into a one-way ratchet — losses charge the books, finds never credit them back — and the gain hides inside a quietly cheaper unit price instead of appearing as an explicit line the operator can see and the financial boundary can export. The same logic covers the real causes of an overage: a delivery line that was never recorded (the invoice was still paid), or a yield windfall (the recipes charged cost for quantity the kitchen never actually used) — in every case the found units' cost already flowed through the books somewhere, and the running average is its best estimate.

The one place this logic runs out is an empty, zero-value pool: there is no average left to speak for the find. There the model turns deliberately conservative — the find enters at zero. Value is born only in priced documents — a goods receipt, or the one opening count that starts a warehouse's stock-keeping — and a cost typed into an ordinary count would be value from nowhere. A zero-cost find understates what the pool is worth and overstates cost of goods, which is the honest direction of error; stock genuinely brought in from outside gets its value the honest way, through a goods receipt carrying its price, supplier optional.

The self-check¶

The close proves itself with a money-balance identity: opening value + receipts + overage/shortage adjustments + transfers − all consumption − shortage − closing value must come out to roughly zero. Tiny residues below a rounding tolerance are treated as noise and zeroed; a meaningful non-zero result blocks the close until it's explained. Both this close tolerance (default 0.1) and the order-vs-invoice match tolerance (default 0.05) are per-currency configuration defaults, not constants. (The blocker mechanics live in Period close.)

7. Quantity and value are tracked separately — and why transfers don't change worth¶

Quantity and value ride on separate axes. Where units physically sit and what they're worth are two distinct facts about the same stock, recorded independently. Most movements change one without dictating the other, and the clearest case is an internal transfer — moving your own stock from one of your warehouses to another.

A transfer changes quantity, not total value. Moving 10 kg of flour from the commissary store to the bar store removes 10 kg × (commissary blended cost) of value from the commissary pool and adds that same value to the bar pool. You didn't buy or sell anything — you just relocated it — so the company's total stock value is unchanged. A transfer between your own warehouses must not create or destroy value, because no economic event happened; only the location did.

The receiving warehouse re-blends. The bar store now holds more flour at a new total value, so its blended average shifts to absorb the incoming value into its own pool — re-blended exactly as if it were any other receipt, but at the sending warehouse's cost rather than a vendor's price. The receiving pool's new average is computed purely from its own contents; it doesn't matter which warehouse the goods came from.

Worked example. The bar store holds 40 kg @ €0.90/kg = €36.00. A transfer brings in 10 kg from the commissary at €0.80/kg = €8.00. No value is created: €8.00 leaves the commissary pool and €8.00 enters the bar pool. The bar store now holds 40 + 10 = 50 kg worth 36.00 + 8.00 = €44.00, so its blended average re-settles to 44.00 / 50 = €0.88/kg. Company-wide flour value is unchanged by the move; only the bar store's per-kilogram cost shifted.

This separation is what lets the system keep a per-warehouse cost pool while tracking quantity coherently across all warehouses off the same movements — and why the receiving warehouse's average is always computed from its own pool, never inherited from the source.

The commissary corollary: internal supply is always at cost. Value conservation has a consequence worth stating for groups that run a central production facility feeding several restaurants: the commissary is a cost center, never an internal vendor. A transfer of house-made dough to a satellite carries the dough at the commissary's own blended cost — there is no internal markup, no "transfer price," no profit booked between your own warehouses, because no economic event happened. (An operator who manages the commissary as a profit center applies that fiction in their accounting system, on top of the honest at-cost figures the boundary exports.) Likewise, a produced item's cost is its materials only — the production run rolls input values into the output, but commissary labor, rent, and energy are never absorbed into the dough's per-kilogram cost; overhead absorption is the operator's accountant's territory (see Recipes & production for the yield mechanics, Financial boundary for what crosses to accounting).

8. Three corners where a naive average silently goes wrong¶

A perpetual blended average is simple in the common case but produces wrong numbers in three specific corners if you're not careful. The model handles each on purpose.

On-hand driven negative. Sometimes an issue is recorded against stock the book thinks is already gone — a sale lands before its delivery was entered, a transfer or a write-off outruns its receipt — driving on-hand to zero or below. The issue is valued at the book's best price for the item — its current average — because an event that already happened must never wait for paperwork. When the late delivery arrives and lifts on-hand back up, the hole is trued up to the delivery's real price: the gap between what the issue assumed and what the goods actually cost moves to price-difference expense, recorded as a valuation entry linked to the covering delivery, and the units still on hand carry the delivery's price exactly. Why: you cannot honestly value units you don't yet have at a price you haven't paid yet; truing up at the delivery stops the earlier guess from contaminating the price of the real goods.
No backdated-average repair. A movement entered with a past business date does not rewrite history. The stock it adds is valued at the average as it stands today — the price every later movement already used — and the difference against what was actually paid is expensed on that movement's own business date, never threaded back through past costs. Why: repricing the average retroactively would cascade into every later period's cost of goods — a backdated edit would silently restate margins you've already reported. The audit trail keeps both the original and the correction (as an offsetting movement, never an edit).
Receipt price vs. invoice drift. The everyday trigger is the way goods actually arrive in the EU: a delivery comes with a delivery note, not an invoice, so the goods receipt is posted at the ordered (or estimated) prices — the stock is usable immediately — and the supplier's invoice attaches days or weeks later as a price update on the same document. (A walk-in, cash-and-carry purchase attaches its invoice at posting, in one step; the flow is in Procurement.) When the invoice price differs from what was posted, the difference is absorbed only into the units still on hand, proportionally — recorded as a valuation entry, a value-only, append-only adjustment linked to the receipt it corrects — while the rest, covering units already consumed, is expensed as a price difference. Why: you can only re-value inventory you still hold. The consumed units already hit the cost of goods at the old cost and can't be un-rung.

The thread through all three: you can only re-value stock you still physically hold. Anything already consumed has already hit the cost of goods at the cost it was given, and a later correction is expensed rather than rewritten into history.