How to Change an Item's Standard Cost in SyteLine
how do I change the standard cost of an item in SyteLine
Also searched as
- syteline update standard cost without running cost rollup
- syteline recost inventory to new standard cost
- difference between standard cost and average cost syteline
- how to override an item standard cost syteline
Short answer
You can edit an item's standard cost fields directly on the Items form, or let Cost Rollup calculate it from the BOM and routing. Either way, the new cost only affects future transactions until you run Recost Inventory, which revalues on-hand quantity and posts the difference to the standard cost variance account in GL.
Applies to: Infor SyteLine 8.03/8.04/9.x and CloudSuite Industrial (CSI) 10.x, sites configured for Standard costing.
Update the cost and revalue inventory
- 1Confirm the site is on Standard costing (Sites form, Costing Method), not Average, before editing cost fields manually.
- 2Open the Items form, find the item, and go to the costing tab that shows the standard cost elements (material, labor, burden, service, overhead).
- 3For manufactured items, prefer Cost Rollup over manual edits so the cost reflects the current BOM and routing and labor/burden rates.
- 4For purchased items or a quick correction, type the new value directly into the relevant standard cost field and save the record.
- 5Open Recost Inventory (Costing / Item Costing area) and select the item, item range, or product code you just changed.
- 6Review the preview, which shows old cost, new cost, on-hand quantity, and the total inventory value change before you commit anything.
- 7Run Recost Inventory. It updates the item's inventory value and posts the delta to the standard cost variance GL account for the period.
- 8Check open jobs and open PO lines that still reference the old cost. Recost Inventory revalues stock, not in-flight WIP or open order costs.
- 9Re-run Cost Rollup afterward if you only made a manual edit, so the next scheduled rollup does not silently overwrite your change.
Why a direct edit is not the whole story
Editing the standard cost field on the Items form changes what the system will use for new transactions going forward: new job cost estimates, new PO price variance comparisons, and new sales margin calculations. It does not touch the value already sitting in inventory. If you have 500 units on hand at the old cost and you just change the cost field, your inventory ledger and your item master are now out of sync until you revalue.
That is exactly what Recost Inventory is for. It is the standard SyteLine utility that takes the new standard cost, multiplies it by on-hand quantity by warehouse, and posts the difference as a journal entry to the cost variance account defined in your GL control setup. Skipping this step is the number one reason plants end up with an inventory value on the balance sheet that does not match what the item master says the unit cost should be.
Manual edit versus Cost Rollup
Manual edits are appropriate for purchased items where you are simply correcting a typo, reacting to a known vendor price change ahead of the next full rollup, or setting an initial cost for a new part number. They are risky for manufactured items because the standard cost is supposed to be a derived number: material cost rolled up from the BOM component costs, labor and burden calculated from the routing and the work center rates, and overhead applied per your overhead allocation rules.
If you hand-edit a manufactured item's cost and then someone runs a routine Cost Rollup later, your manual number gets silently replaced by whatever the BOM and routing produce. If that surprises finance because they were relying on the manual figure, you get an unexplained cost variance at the next transaction. The safer pattern for manufactured items is to fix the BOM, routing, or rate that is wrong, then run Cost Rollup so the number is traceable back to its inputs.
Reading the cost variance after Recost Inventory
After you run Recost Inventory, pull up the GL detail for the standard cost variance account for that period. The line should tie out to (new cost minus old cost) times on-hand quantity for every item and warehouse combination you recosted. If it does not tie out, check whether the item exists in multiple warehouses with different on-hand quantities that were recosted in separate runs, or whether a transaction posted between your preview and your commit and changed the on-hand quantity mid-stream.
Also check that you recosted every warehouse the item lives in. It is a common miss to recost the main plant warehouse and forget a consignment or a satellite warehouse holding the same item, which leaves that location's inventory value stale until the next full-item Cost Rollup and Recost Inventory cycle sweeps it up.
Sites > Costing Method (confirm Standard, not Average)
Items > [item] > standard cost elements tab
Costing > Cost Rollup (derives cost from BOM/routing)
Costing > Recost Inventory > select item/range > preview > commit
Open jobs, open POs, and average-cost sites
Recost Inventory changes the value of what is already on the shelf; it does not retroactively change the cost basis on an open job that has already consumed material at the old cost, or on an open PO line whose price variance calculation was set at order entry. Those will true up naturally as the job closes or the PO receipt posts, but do not expect a single Recost Inventory run to make every open document consistent overnight.
If the site is configured for Average costing instead of Standard, none of this applies the same way: average cost recalculates automatically with each receipt and issue based on a moving weighted average, and there is no manual standard cost field to edit or Recost Inventory step to run. Confirm the costing method on the Sites form before you start, because editing a cost field that the system is going to recalculate anyway wastes time and can be confusing to whoever reviews the change later.
Common pitfalls
- !Editing a manufactured item's standard cost by hand and forgetting that the next Cost Rollup will overwrite it, producing a surprise variance.
- !Changing the cost field but never running Recost Inventory, leaving inventory value and item master cost out of sync.
- !Recosting only the primary warehouse and missing a satellite or consignment warehouse holding the same item.
- !Not checking the costing method (Standard vs Average) on the site first, and trying to manually set a cost that Average costing recalculates automatically anyway.
- !Assuming Recost Inventory also revalues open job WIP or open PO price variance; it only revalues on-hand inventory value.
How an ERP-grounded AI assistant handles this
ERPray, grounded on your SyteLine cost tables and GL control setup, can answer "which items were recosted last period and did the variance post to the right account" in a sentence, and flag manufactured items whose standard cost was hand-edited outside a Cost Rollup so finance is not surprised later. It will not run Recost Inventory for you, but it removes the manual cross-checking between Items, Recost Inventory history, and the GL variance account.
Frequently asked questions
Does changing the standard cost field affect past transactions?
No. It only affects new transactions, job estimates, and margin calculations from that point forward. Historical transactions keep the cost that was in effect when they posted.
Can I recost just one warehouse and not others?
Yes, Recost Inventory can be scoped by item, item range, or product code, and it processes on-hand quantity by warehouse, so you can target a single location if you know the cost change applies there specifically.
What happens if I run Recost Inventory but the cost didn't actually change?
Nothing posts. The utility compares old cost to new cost and only generates a variance entry where there is a difference, so running it on unchanged items is harmless.
Why did Cost Rollup produce a different number than I expected?
Cost Rollup pulls live data from the BOM component costs, the routing operations and work center rates, and your overhead allocation setup. If any of those changed since the last rollup, the result changes too, even if you did not touch the item directly.
Related
How to Run a Cost Rollup in SyteLine
Run Item Cost Rollup from Product Definition > Costing > Cost Rollup, select the site and item range, run it in Simulate mode first to review variances, then run it live to post new standard costs to Item records and the Costed Bill of Material.
How-toHow to Handle Landed Cost and Voucher a PO Receipt in SyteLine
Landed cost charges such as freight, duty, and brokerage are added against the PO or the receipt, allocated across the received line items by value or quantity, and rolled into the item's received cost before it is vouchered. Vouchering itself is the 3-way match between PO price, receipt quantity, and vendor invoice, and mismatches beyond your tolerance percentage get held for review instead of posting automatically.
Error fixFixing SyteLine's 'transaction out of balance' GL posting error
This posting error means SyteLine tried to create a general ledger journal entry where total debits do not equal total credits, which the GL will not accept. The most frequent causes are a missing or misconfigured account in the automatic account determination setup (COA mapping), currency rounding on multi-currency transactions, or a source transaction (inventory, job cost, AP/AR) that only partially calculated its cost or tax components before posting.
AdvancedHow to Improve SQL Server Performance for a Slow SyteLine ERP System
Most SyteLine performance complaints trace back to a handful of SQL Server issues: stale statistics, missing indexes on high-churn IDO tables, blocking caused by the default isolation level, and IDO Runtime connection pool exhaustion. Working through those systematically, with DMV evidence, resolves the majority of slow system tickets faster than guessing at application-layer causes.
Error fixFixing SyteLine's 'Object reference not set to an instance of an object' error
This is a generic .NET NullReferenceException surfacing through the SyteLine IDO Runtime, not a SyteLine-specific error code. It almost always means a form, script or IDO method referenced a field, row or object that came back null, usually after a customization, a missing related record, or a view/IDO method call before the form finished loading. Turn on detailed client logging and check the most recent customization or form event first.
Error fixDiagnosing and fixing SyteLine session timeout errors
SyteLine session timeouts come from one of three independent layers: the IDO Data Service session timeout on the app server, the IIS/application pool idle timeout for the web (Mongoose Web) client, or a load balancer/proxy idle timeout in front of a CloudSuite hosted environment. Fixing the wrong layer is the most common mistake - you need to identify which layer is actually expiring the session before changing anything.
AI for ERPAI for Infor SyteLine and CloudSuite Industrial
Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.
Stuck on Infor SyteLine (CloudSuite Industrial)?
Talk to engineers who work inside Infor SyteLine (CloudSuite Industrial) every week, and who build private AI that answers these questions from your own ERP data.