How-toInfor LNCommon / Cost Calculation

How to calculate item cost prices in Infor LN

Question
how to calculate item cost prices in Infor LN

Also searched as

  • infor ln cost price calculation and simulation
  • infor ln standard cost update process
  • infor ln cost component structure explained
  • how does infor ln roll up manufacturing cost

Short answer

Infor LN calculates an item's cost price by rolling up material, labor, machine, subcontract and overhead costs defined against cost components, using the item's bill of material and routing as the calculation base for manufactured items and purchase price for bought items. The calculation can run in simulation mode to preview the result or in update mode to actually change the item's standard cost, which then drives inventory valuation and variance reporting going forward.

Applies to: Infor LN Enterprise Edition, Common / Cost Calculation module

Run a cost price calculation for an item or item set

  1. 1Common > Item Data > Cost Prices > Cost Components: confirm the cost components defined for the company (material, labor, machine, subcontract, overhead) are set up as needed before running any calculation.
  2. 2Confirm the item's bill of material and routing are current for manufactured items; the calculation rolls up exactly what these structures define, including any obsolete or inactive components.
  3. 3Common > Cost Calculation > Cost Price Calculation and Simulation: select the item(s), warehouse, and calculation method (single-level or multi-level, depending on whether sub-assembly costs should be recalculated or taken as-is).
  4. 4Run the calculation first in simulation mode, which produces a cost breakdown by component without updating the item's live standard cost.
  5. 5Review the simulated result against the current standard cost, checking for unexpected swings that usually indicate a stale BOM, routing rate, or purchase price.
  6. 6Investigate and correct the source data (BOM quantity, routing time, resource rate, or purchase price) rather than accepting an implausible number.
  7. 7Re-run simulation until the result is validated, then run the same session in update mode to write the new cost price to the item.
  8. 8Confirm the effective date and whether the update should apply immediately or at a future date, since some sites time cost updates to a period boundary.
  9. 9Reconcile inventory valuation after an update run, since a standard cost change on items already in stock generates a revaluation entry to Financials.

Cost components and why the breakdown matters

LN does not store a single cost number; it stores cost by component (material, labor, machine, subcontract, overhead, and any company-specific components configured). This breakdown is what makes variance analysis useful later: a purchase price change shows up as a material variance, a routing time change as a labor or machine variance, instead of one opaque total drifting for an unclear reason.

Overhead components in particular are usually applied as a rate or percentage defined at the work center or item group level, not entered per item, so an overhead swing across many items at once almost always traces back to one rate change rather than dozens of individual item edits.

Single-level vs multi-level calculation

A single-level calculation takes the cost of sub-assemblies and purchased components as they are currently recorded and rolls up only the top level's own BOM and routing. A multi-level calculation recalculates every sub-assembly's cost from its own BOM and routing first, then rolls that fresh cost up through the parent, which is the correct choice whenever a lower-level component's cost has changed and you need the change to propagate.

Running single-level after a lower-level change will silently understate or overstate the parent's cost because it is still using the old sub-assembly figure; this is one of the more common causes of a cost calculation result that does not match expectations.

From cost price to inventory valuation

Once a cost update runs, the new standard cost applies to new transactions going forward, but existing on-hand inventory valued at the old cost typically requires a separate revaluation step to bring book value in line, generating its own integration transaction to Financials. Sites that skip this step end up with inventory value on the balance sheet that no longer matches the item's current standard cost times on-hand quantity.

Purchase price variance and manufacturing variance reporting both depend on the standard cost being current; a stale cost price makes every subsequent variance report noisy and hard to act on.

Common pitfalls

  • !Running an update calculation directly without reviewing a simulation first, and only noticing an error after inventory has revalued.
  • !Using single-level calculation after a sub-assembly cost changed, which leaves the parent item's cost stale.
  • !Forgetting that an inactive or superseded BOM component still gets costed if it has not been properly ended on the BOM.
  • !Not reconciling inventory revaluation to Financials after a cost update, leaving the general ledger out of step with the item master.
  • !Changing a routing rate or overhead percentage without re-running cost calculation for all affected items, leaving some items on stale cost.
  • !Confusing standard cost with the sales price or last purchase price, which are separate fields entirely.

How an ERP-grounded AI assistant handles this

ERPray can pull the current cost breakdown by component for an item and flag when it looks stale relative to the item's BOM, routing or last purchase price, without a cost accountant manually cross-checking each source. It can also explain in plain terms why a specific item's cost changed between two calculation runs by comparing the component-level detail, which is usually the tedious part of a variance investigation.

Frequently asked questions

What is the difference between simulation and update mode?

Simulation calculates and displays the result without changing the item's live standard cost, useful for validating source data first. Update mode writes the calculated cost to the item and, for items already in stock, typically triggers a revaluation to Financials.

Why did my cost calculation not change even though the purchase price changed?

Check whether the item's costing method actually references the current purchase price versus a fixed standard purchase cost field, and confirm the price change was saved and effective as of the calculation date.

Does cost calculation account for scrap or yield loss in the routing?

Yes, where scrap percentage or yield is defined on the routing operation or BOM component, the calculation factors it into the effective quantity and cost, so an unrealistic scrap percentage will distort the calculated cost.

How often should cost price calculation be re-run?

Most manufacturers run it on a defined cycle (monthly or quarterly) plus whenever a significant BOM, routing, or purchase price change occurs, rather than continuously, since a cost update triggers a revaluation that finance needs to plan for.

Related

How-to

How to process a sales order to invoice in Infor LN

In Infor LN a sales order moves from order entry to cash through four linked steps: create and approve the Sales Orders session, release the order lines to Warehousing so a warehouse order is generated, confirm the outbound shipment, and then run the invoicing session that composes and posts the sales invoice to Financials. Each step hands off through an integration document, so a stuck invoice almost always traces back to a missing or unconfirmed step earlier in the chain.

How-to

How to set up and run a project in Infor LN PCS

Infor LN's Project Control System (PCS) manages engineer-to-order and project-based work as a structured hierarchy: a project header, a work breakdown structure (WBS) of activities, a budget or estimate against that structure, and actual cost and progress booked back against the same elements. Getting the WBS and budget structure right before any transaction posts is what makes project cost reporting usable later.

How-to

How to close a financial period in Infor LN

Closing a period in Infor LN is not a single click; it requires clearing every module's outstanding integration transactions into Financials first, reconciling each subledger (AR, AP, inventory, WIP) to the general ledger, and only then closing the period through Periods and Fiscal Years, which blocks further posting to it. Skipping the reconciliation step and closing early is what causes stuck or orphaned transactions that have to be reopened and reworked later.

How-to

How to process inbound and outbound warehousing orders in Infor LN

Infor LN Warehousing splits every physical movement into inbound (goods arriving, mainly from purchase orders) and outbound (goods leaving, mainly for sales orders), each driven by its own warehouse order type. Inbound runs through intake, inspection if required, and put-away; outbound runs through order release, picking, packing and shipment confirmation, with each stage updating the order status other modules watch.

Advanced

How to diagnose and fix a slow Infor LN session

A slow Infor LN session is usually caused by an unindexed or overly broad database query, unarchived data bloating a transaction table, or resource pressure on the Java application tier, and occasionally by a recently added custom DAL2 handler. The fix starts with isolating which tier the delay is actually in rather than guessing at a solution.

Error fix

Infor LN bshell Process Stuck at 100% CPU: How to Diagnose and Fix It

A bshell process pinned at 100% CPU on the Infor LN application server almost always means one session is stuck in a 4GL loop, scanning an unindexed table, or waiting on a database lock. End the session from the Sessions Monitor first, then kill the OS process only if that fails, and check for a blocking database transaction before assuming it is a bug.

AI for ERP

AI for Infor LN: Sessions, BODs, and Engineer-to-Order Work

Add grounded AI to Infor LN 10.x or CloudSuite: natural-language answers over sessions and BODs, agents for project and engineer-to-order work, on-prem options.

AI for ERP

AI shop floor assistant for operators working inside your ERP

An on-prem AI copilot answers operator questions against your ERP work instructions, travelers, and routings in plain language, at the machine, without a screen full of menus.

Stuck on Infor LN?

Talk to engineers who work inside Infor LN every week, and who build private AI that answers these questions from your own ERP data.