James Allman | JA Technology Solutions LLC
Inventory Valuation: Where the Numbers in Your ERP Come From
Two companies can buy the same goods, sell the same units, and report different cost of goods sold. The difference is a configuration choice called the cost flow assumption, and most people running reports against it could not say which one their system uses.
Ask what a warehouse full of inventory is worth and the honest answer is: it depends on an accounting policy. Not on the goods, not on the market, but on which costs the system assigns to the units that left. FIFO, LIFO, and weighted average are the three common answers, and they can produce meaningfully different cost of goods sold and ending inventory from identical operations.
This matters beyond the accounting department because the valuation method is baked into numbers operations people use every day: item margins, department gross profit, inventory value on the balance sheet, GMROI. If you have ever watched two reports disagree about the same period and the same items, there is a fair chance a costing assumption was involved.
A cost flow assumption, not a physical one
The method names mislead people into thinking about physical handling. FIFO (first in, first out) does not mean the warehouse ships the oldest case first, and LIFO (last in, first out) does not mean it ships the newest. Physical rotation is an operations discipline. The valuation method is purely about which purchase costs get attached to the units sold, regardless of which physical case went out the door.
Under FIFO, the oldest purchase costs are consumed first. Under LIFO, the newest. Under weighted average, every sale carries the running average cost of everything on hand at that moment, recalculated whenever a receipt arrives at a new cost. Same goods, same sales, three different cost histories.
The same ledger, three answers
A short ledger makes the spread concrete. Buy 100 units at 10.00 and 100 at 12.00. Sell 120. Buy 100 more at 11.00. Sell 130. Three hundred units purchased for 3,300; two hundred fifty sold; fifty remain.
FIFO charges the first sale with the hundred 10.00 units plus twenty at 12.00, and ends the period with COGS of 2,750 and fifty units on hand valued at 11.00 each: 550. LIFO charges the newest costs first and lands at COGS of 2,800 with the remaining fifty carried at 10.00: 500. Weighted average happens to land with FIFO here (2,750 and 550) because the running average works out to exactly 11.00, but that is a coincidence of round numbers, not a rule.
Every method conserves the total: COGS plus ending inventory equals 3,300 in all three cases. The methods only decide how that total splits between the income statement and the balance sheet. You can run this exact ledger, or your own, through the FIFO / LIFO / Average Cost Calculator and watch the three answers diverge line by line.
Where the method lives in your systems
In most ERP and merchandising systems the valuation method is an item-ledger or company-level configuration set during implementation and rarely revisited. Perpetual weighted average is the most common default in operational systems because it is cheap to compute: one running average per item, updated at receipt. FIFO costing requires the system to carry cost layers, which is more bookkeeping but gives receivers and accountants a cost history they can trace.
The operational consequence is that every receipt at a new cost changes future margins immediately under weighted average, while layer-based methods change them only as old layers exhaust. When a buyer asks why an item's margin moved with no retail change and no vendor change notice, the answer is often a receipt landing on the average.
The method also decides what your reporting can honestly claim. Item-level gross profit, department margin, and inventory rollups all inherit the costing assumption underneath them. A report that joins sales to current replacement cost will not reconcile to one that uses the ledger's cost layers, and neither is wrong; they are answering different questions.
Rising costs, falling costs
The directional intuition is worth memorizing. When costs are rising, FIFO consumes the old cheap layers first, so it reports lower COGS, higher margin, and higher ending inventory value. LIFO does the opposite: higher COGS, lower margin, lower inventory value. When costs fall, the directions flip. Weighted average sits between the two in both cases.
One orientation note rather than advice: LIFO is permitted under US GAAP and not under IFRS, and the choice carries tax and reporting consequences that belong with your accountant. What belongs with your systems people is making sure the configured method, the reports, and everyone's expectations agree.
Valuation meets operations: GMROI and shrink
Inventory valuation is not just a year-end accounting topic. GMROI, the margin-per-inventory-dollar measure merchants use to compare categories, divides gross margin by average inventory at cost, and both the numerator and denominator come out of the valuation machinery. A method change, or a costing bug, moves GMROI with no change in actual performance. The GMROI & Inventory Turns Calculator shows how sensitive the measure is to the inventory figure under it.
Shrink accounting leans on valuation too. Book inventory is a cost-valued number; when the physical count comes in, the difference is shrink, valued at whatever cost the method assigns. An inflated average cost from a keying error does not just distort margin, it quietly inflates the shrink number the operations team gets blamed for. The Shrink & Waste Calculator walks that book-to-physical math.
When the number looks wrong
Most inventory valuation problems I encounter are not method-choice problems, they are data problems wearing a costing disguise: a receipt keyed at case cost where the system expected unit cost, a conversion factor wrong on the item so the average absorbed a 12x error, layers corrupted by an interface that posted receipts twice, or a cost override that never got cleaned up. The method faithfully propagates whatever it is fed.
Finding those takes the same discipline as any data reconciliation: trace one item's ledger end to end, recompute what the system should have done, and compare. That is reporting and data work, and it is exactly the kind of thing I build: extraction and recomputation against the ledger, exception reports that surface items whose cost moved outside tolerance, and fixes to the interfaces that fed the bad numbers in. See custom reporting and ETL and data pipelines for how that work is shaped.
If your inventory value, margins, or shrink numbers do not behave the way this article says they should, the gap is usually findable. Ask James and describe what you are seeing; I read every conversation that comes through the chat assistant on this site, and I will follow up directly.