xMatix values stock with a perpetual costing engine that replays the inventory ledger into cost layers (one per receipt, or one pool for the average methods) and consumptions (each issue's draw against those layers). The method — FIFO, LIFO, moving average, weighted average or specific identification — is chosen by a valuation policy inside an accounting book, and the result is read on the Inventory Valuation page. This page explains the engine, the configuration that steers it, the reading surface, and the honest limits of the current implementation.
Read the screen
- 1
Company picker — valuation is per partner account and, when more than one exists, per accounting book.
- 2
Rebuild recomputes the period-balance cache the By period / By years comparisons read.
- 3
Compare by, Branches and Balance as On scope the statement exactly as on the Inventory Stock page.
- 4
Money scale — values here are shown in millions.
- 5
Qty is the on-hand quantity the layers account for; click it for the Valuation lots drill.
- 6
Value is remaining quantity × unit cost over surviving layers, less any recorded NRV write-down; the total is for the selected scope.
Inventory → Inventory Valuation shows the Valuation Statement: one row per item with Qty and Value for the selected company, and a total. The controls match the Inventory Stock page — Compare by (no comparison, by branch, by period or by years, each with a (movement) variant showing opening, change and closing), Branches and Balance as On (current, to-date presets, previous month, a fiscal-year end, custom) — plus a money-scale selector and, when the company has more than one accounting book, a book picker. Rebuild recomputes the period-balance cache the period and year comparisons read (see Inventory period balances). Clicking a value opens a drill: Valuation lots (the cost layers behind the figure, with remaining quantity and unit cost; filter to open lots or all, month/quarter/year to date or all dates) or Consumption lots (the issues that drew from those layers, with quantity, unit cost and cost amount), and View ledger where an Item Ledger page is configured.
How the engine costs stock
Every inventory posting hands its new ledger rows to the costing hook. For each affected primary book, item and branch the hook deletes the stored layers and consumptions for that scope and rebuilds them by replaying the scope's ledger movements through the resolved method:
- Cost layers (Inventory Cost Lot records): under FIFO, LIFO and specific identification, one layer per receipt with its original quantity, remaining quantity, unit cost and receipt date, linked to the ledger row that created it. Under moving or weighted average, a single pool layer whose remaining quantity is the whole on-hand balance at the running or period average cost.
- Consumptions (Inventory Cost Consumption records): one row per layer an issue drew from, with quantity, unit cost and cost amount. The rows sharing an issue's ledger reference add up to that issue's cost of goods sold, and that is the amount the engine puts on the cost journal.
Carrying value at any moment is the sum over surviving layers of remaining quantity times unit cost, less any recorded NRV write-down. Because the scope is rebuilt wholesale, stored layers cannot drift from the algorithm — but they are derived state: the ledger is the fact, the layers are its valuation.
Costing is best-effort by design. The inventory posting commits first; if costing fails for a scope — most commonly because the company has no active primary accounting book — the movement still commits and the costing error is logged. A ledger movement with no valuation rows behind it therefore means "check the book and policy", not "the stock did not move".
Costing methods
| Method | How issues are costed | Notes |
|---|---|---|
| FIFO | Oldest receipt layers consumed first. | |
| LIFO | Newest layers first. | Not permitted under Ind AS or IFRS; the book's Allows LIFO flag records the opt-in. |
| Moving average | A perpetual average recomputed at every receipt. | The engine's fallback when no policy matches. |
| Weighted average | A periodic average over the replayed window. | |
| Specific identification | Each issue costed at the exact lot it drew, keyed by the movement's item lot. | Implemented by the engine but not offered in the seeded method picker. |
| Standard cost | — | Named in the catalog; not computed by the engine. |
Accounting books
An accounting book is a valuation perspective for one company (partner account): Book Type Statutory, Tax or Management; Gaap Framework (Indian, international or US standards); Is Primary; Is Active; currency; and the opt-in flags Allows LIFO and Allows Standard Cost. Exactly one active primary book per company is the working assumption: inventory-cost posting takes the first active primary book it finds and skips costing when there is none, and only the primary book persists cost layers — a secondary book is derived by replaying the same movements and storing per-period overlay deltas. Uniqueness of the primary flag is not enforced by the model, so check it when a company's valuation looks wrong. Books belong to the Finance Setup app; where that app is not on your launcher, an administrator maintains them.
Valuation policies
A valuation policy selects the method for a scope within a book. The form has three parts:
- 1
Partner Account and Business Unit are optional scope keys; note the live posting path never supplies a business unit, so that key does not match at posting time.
- 2
Branch — one of the two scope keys (with Item) that posting-time resolution actually uses.
- 3
Three tabs: Accounting Period (this one), Item & Valuation, Controls.
- 4
Effective From / Effective To — movements dated outside the window ignore this policy, which is how a method change applies prospectively.
- 5
Accounting Book — resolution is filtered to this book before anything else; only the primary book persists cost layers.
- 6
Costing Level is a stored descriptor; it does not create batch-, serial- or location-level cost pools.
Above the tabs, Partner Account, Business Unit and Branch are optional scope keys. The Accounting Period tab holds Effective From / Effective To (the policy is ignored for movements dated outside the window, which is how a method change applies prospectively), Accounting Book (resolution is filtered to this book first) and Costing Level (a free-text descriptor of the intended cost-pool boundary — see the limits below).
- 1
Item & Valuation tab.
- 2
Item — the most specific scope key (+16); empty applies the policy to every item.
- 3
Item Group — scored +8, but the live posting path does not supply an item group, so it does not match at posting time.
- 4
Valuation Method — FIFO, LIFO, Weighted Average or Moving Average in the seeded picker; the engine compares unspaced tokens, so verify the stored value resolves.
- 5
Storage Location — a scope key the posting path never supplies; scope by item and branch instead.
- 6
Save stores the policy; no save-time validation of method vs framework or overlapping scopes runs.
Item & Valuation holds the Item and Item Group scope keys, the Valuation Method, and a Storage Location scope key.
- 1
Controls tab — the third and last part of the form.
- 2
Is Active — only an explicit off excludes the policy; deactivate rather than delete to retire a rule without changing history.
- 3
Is Default is stored but the resolver never reads it; an unscoped active policy is already the fallback.
- 4
Save — Priority is not on this form; ties between equally specific policies fall to the later Effective From when Priority is empty.
Controls holds Is Active (only an explicit off excludes the policy from resolution; deactivating is the safe way to retire a rule) and Is Default.
Resolution. For a movement, candidates are filtered to the book, to active policies and to the effective window. Each non-empty scope key must equal the movement's value; an empty key is a wildcard. Among matches, specificity wins: item +16, item group +8, storage location +4, branch +2, business unit +1. Ties go to the lower Priority number, then the later Effective From. An unscoped active policy is the book-wide fallback; when nothing matches at all the engine uses moving average. Is Default is stored but not read by the resolver — an unscoped policy already wins by having the lowest specificity.
Current limits to know before you rely on it
- Scope keys the live posting path never supplies. Inventory-cost posting resolves with book, date, company, branch and item only. Policies scoped to a business unit, storage location or item group do not match at posting time; scope by item and branch.
- Costing level does not create pools. Layers are keyed by book, item, branch and method. Setting Costing Level to batch, serial or storage location does not create separate pools; only specific identification is lot-aware, through the movement's lot.
- Method tokens. The engine compares exact tokens
FIFO,LIFO,MovingAverage,WeightedAverage,SpecificIdentification. The seeded picker offersWeighted AverageandMoving Averagewith a space; confirm the stored value resolves before relying on an average-cost policy. - Validation is not wired to save. Rules for LIFO under Ind AS / IFRS, method-versus-level coherence, effective-window order and overlapping scopes exist as helpers but nothing calls them when a policy is saved. Contradictory policies can be saved; review the set yourself.
- Priority is a field on the policy but is not on the create form's tabs.
- Net realizable value is not computed automatically. The lower-of-cost-and-NRV calculation exists as a service, but no product process runs it: Inventory NRV Assessment rows (estimated selling price, cost to complete, cost to sell, resulting NRV, write-down or reversal this run, outstanding write-down) have to be entered against the entity. What the platform does do is post them: period close posts a write-down or reversal journal for each assessment in the period that has no journal yet, flags unposted ones in its advisory checklist, and the Valuation Statement subtracts each item's latest outstanding write-down from cost to reach carrying value.
Common questions
Why isn't stock value just quantity times the latest cost?
Because cost flow matters. Under FIFO the remaining stock is valued at the costs of the latest receipts (the oldest were consumed first); under moving average at an average every receipt has shifted; under specific identification at the actual costs of the exact lots on hand. Two items with the same quantity and the same latest purchase price can carry different values. The Valuation lots drill shows the layers behind any figure, so the arithmetic is inspectable.
A movement is in the ledger but has no valuation rows — what happened?
Costing is best-effort. Check, in order: that the company has an active primary accounting book; that the policy's stored method token is one the engine recognizes; and the application logs for the costing error. Fix the cause, then post another movement for the item and branch (or re-post) so the scope is rebuilt — the rebuild replays the whole ledger for that scope, so earlier movements are picked up too.
Where do I see why an issue was costed the way it was?
The Consumption lots drill on the Valuation Statement. Every issue has consumption rows naming the layer drawn, the quantity and the unit cost — under FIFO an issue spanning two receipt layers shows two rows at two costs. Under the average methods every row points at the single pool layer, so the drill explains the average, not a specific receipt.
Can two books show different values for the same stock?
Yes — that is the point of books. The primary book is the statutory truth that posts to the general ledger; a tax or management book values the same movements under its own policies, stored as per-period overlay deltas on top of the primary. The book picker on the Valuation Statement appears when a company has more than one book.