At a Glance
Module purpose: Per-transaction valuation engine that computes COGS on outgoing stock and updates cost basis on incoming stock under FIFO or Weighted Average · Audience: Finance, Inventory Controller, Auditor · Key entities/tables:tb_period_snapshot, FIFO cost layers,AverageCostTracking,JournalEntry, costing/calculation-methods · Sub-pages: 11
The Costing module is the valuation engine of the inventory ERP. It consumes the stream of stock movements produced by the Inventory module and, for every outgoing transaction, computes the Cost of Goods Sold (COGS) charged to a department or revenue centre; for every incoming transaction, it updates the cost basis of the affected balance. The engine runs per-transaction rather than as a periodic batch — a GRN line that posts at 14:02 is costed at 14:02, so balances and valuation stay in step with quantities.
Two cost-flow assumptions are supported, configurable per product (or globally): FIFO, which preserves each receipt as a distinct lot and consumes the oldest lot first, and Weighted Average Cost (WAC), which blends every receipt into a single rolling average. The engine exposes the same inputs and outputs in both cases — a costed quantity, a unit cost, a journal entry, and a refreshed balance valuation — so downstream consumers (recipe costing, financial reporting, variance analysis) do not need to know which method a given product uses.
Outputs land in three places: stock balances carry an up-to-date currentCost and totalValue; outgoing movements (ISSUE, WRITE_OFF, TRANSFER from an inventory location) carry the realised COGS that feeds the GL; and the period-end snapshot locks the valuation that the balance sheet and food-cost reports consume. Detailed FIFO vs. WAC algorithms, numerical examples, and the trade-offs between the two methods are covered in the sub-page below — this landing page only orients.
Inventory valuation is a regulated activity. Both IFRS (IAS 2) and US GAAP (ASC 330) accept FIFO and Weighted Average as permissible cost-flow assumptions, but they require the choice to be applied consistently per product class and disclosed in the financial statements. The costing module is therefore an audit-facing component: every COGS figure must be traceable back to a specific receipt (FIFO) or a specific moving-average computation (WAC), and the trail has to survive an external audit cycle.
Operationally, costing is where food cost control lives. Plate cost, recipe profitability, and menu-engineering decisions all read from this module. If the costing engine drifts — stale lots, missed waste write-offs, incorrect average recomputation after a return — every downstream margin number drifts with it. Hospitality groups typically run on tight food-cost margins, so a one-or-two-percentage-point error in valuation translates directly into a noticeable P&L miss. This module is the contract between physical inventory movements and the financial picture the business steers by.
(prevQty × prevAvg + receivedQty × receivedCost) / (prevQty + receivedQty). Issues are costed at the average prevailing at the time of issue; ending inventory and COGS both reflect the same blended cost.| Role | Responsibility |
|---|---|
| Finance | Owns the valuation policy: chooses FIFO or WAC per product class, reconciles inventory sub-ledger to the GL, signs off period-end valuation. |
| Inventory Controller | Ensures the inputs the engine relies on are clean: lot dates, receipt costs, adjustment cost bases, waste write-offs. Investigates valuation variances. |
| Auditor | Verifies that the costed COGS and ending inventory tie back to source receipts and that the costing method is applied consistently across periods. |
Cross-module flow:
Master configuration:
../carmen/docs/costing/../carmen-inventory-frontend/../carmen-turborepo-backend-v2/../carmen-turborepo-backend-bruno/../carmen-inventory-frontend-e2e/