Independent IFS Cloud practice · Business process optimisation Goods receipt, inspection and put-away in IFS Cloud: finding stock that arrived but cannot be…
Independent IFS Cloud practice · Business process optimisation Delivered but not invoiced in IFS Cloud: finding customer order lines that left the warehouse…
Independent IFS Cloud practice · Business process optimisation Sales orders below cost in IFS Cloud: how margin shows on the order line, why a loss-making…
Independent IFS Cloud practice · Business process optimisation Customer order types in IFS Cloud: deciding which steps of the order flow run on their own Every…
Independent IFS Cloud practice · Business process optimisation Reorder points in IFS Cloud: classify the parts first, then let the job calculate A reorder…
ERP Advisory & Strategy When Does an Independent IFS Consultant Really Add Value? Sometimes the most valuable person on an ERP project is the one who isn’t…
The ERP is a Foundation, Not the Brain Most consultants are still trying to sell the «all-in-one» dream. It is a mistake that buries companies under a mountain…
Executive Summary In the modern enterprise, inventory is a paradox. It is listed as a current asset on the balance sheet, yet in operational reality, it often…
Independent IFS Cloud practice · Business process optimisation
Goods receipt, inspection and put-away in IFS Cloud: finding stock that arrived but cannot be used
Outside Receive into Inventory, a delivery booked as arrived is not yet stock in a stock location. In IFS Cloud the receive case on the purchase order line decides which steps stand between the dock and that location. This article follows them as the IFS Cloud documentation (release 25R2) describes them, and shows where receipts stall.
Key takeaways
The receive case sets the route: Receive into Inventory ends at Register Arrivals, and the cases with arrival or QA locations add inspection, a move into stock or a transport task.
The receipt line status shows where a delivery waits. "To be Inspected" needs inspection results, "To be received" needs a move into stock, and the purchase order line stays Arrived until the goods are in stock.
For inventory parts, inspection results must be entered before the quantity can move into a stock location.
Without putaway zones for a part, the Inventory Putaway page states that putaway finds no locations.
1.What are the steps from arrival to stock in IFS Cloud?
Goods receipt in IFS Cloud starts when a receipt line is entered as arrived on the Register Arrivals page, and the route to stock depends on the receive case.
Receive case
Route
Status after arrival
Receive into Inventory
Parts go directly to a stock location. Not allowed if mandatory create analysis is set in IFS/Quality Management.
Received
Receive into Arrival
Parts go to an arrival location and must be moved to stock.
To be received
Receive into Arrival, Perform Putaway
Parts go to an arrival location, then the system finds the best location and creates transport tasks.
Not stated on the pages I read
Receive into Arrival, Inspect at Arrival
Inspection at the arrival location, then results are entered and parts move to stock.
To be Inspected
Receive into Arrival, Inspect at QA
Parts move to an inspection location, are inspected, then move to stock.
To be Inspected
Receive into QA, Inspect at QA
Parts are received directly into an inspection location and inspected before moving to stock.
To be Inspected
The three inspect cases are not supported for shipment order receipts. The statuses are documented as follows. "To be Inspected" is set when arrival is entered and an inspection demand exists, and the source order line becomes Arrived. "To be received" means goods sit in an arrival or inspection location, and the purchase order line stays Arrived. "Received" means all goods are in stock, and the order line becomes Closed. In my reading, an order line that stays Arrived marks an unfinished receipt.
In my reading, inspection demand exists when Qty to Inspect is above zero, taken from the inspection code of the receive case or from the control plan in IFS/Quality Management. Results go into the Register Inspection Results dialog, opened from Inspection Management or the Receipt page. An entry is complete when approved, scrapped and returned quantities together equal Qty to Inspect. Inventory Putaway ranks candidate locations and a transport task carries out the move, but only in the flows the Inventory Putaway page lists: the Perform Putaway receive case, the receipt and move overviews, shop order and production schedule receipts, and general moves. In Receive into Arrival the move to stock goes through Move Into Stock.
2.Why do goods get stuck between arrival and stock?
Goods stall in IFS Cloud wherever a documented step needs a person or a setup value that is missing. The causes below come from the 25R2 pages.
Inspection results not entered - a line in "To be Inspected" cannot send inventory parts to stock without them.
Partial inspection reports - the remaining quantity stays open until results are fully reported.
No move into stock - with Receive into Arrival the parts must be moved to stock.
Transport task not executed - after Perform Putaway the next step is to execute the transport task.
Putaway finds no location - zones must be set up for the part, and a part with no height cannot use a location with a defined height. If quantity remains after all zones, an information message informs the user.
Blocked locations - the receipt rules include Receipts blocked, Receipts to occupied blocked, and mix rules for part number, condition code and lot batch number.
Quality Management gates - a required analysis does not block receipt, but a confirmed analysis is needed before goods can move into stock.
The pages I read do not state how planning, reservation or customer orders treat quantity sitting in an arrival or QA location. They state that parts in arrival or QA locations are Supplier-Owned when the Ownership Transfer Point is "Receipt into Inventory". In my reading, a delivery in either waiting status is physically present but not yet in a stock location, so test on your own system how your reservation and planning treat it.
3.How do you find stuck receipts?
Stuck receipts are found by listing receipt lines whose status is not yet Received and looking at how long each has sat there. The Receipts and Receipt pages are the documented places for receipt lines, and the pages I read do not describe their columns or default filters, so check which fields your release offers.
What you see
What to check first
Line in To be Inspected
Whether Qty to Inspect is above zero, who owns the inspection step, and whether a partial report left a remainder.
Line in To be received
Whether the goods are still in an arrival or inspection location and whether the move into stock was started.
Purchase order line stays Arrived
The receipt lines behind it, because the order line closes when all goods are in stock.
Transport tasks left open
Whether they were executed, directly or through a warehouse task.
Customer return not closed
Whether the RMA line is Partially Received and the parts were received on Register Arrival.
In my practice the useful question for each row is age, and the pages I read give no threshold, so set one per part group and supplier. A scheduled read-only query answers the same question, as read-only OData monitoring describes, and order states that need attention covers the wider pattern.
4.How do you clear a stuck receipt?
A stuck receipt is cleared by completing the step its status points to, on the documented pages and dialogs.
To be Inspected: open Inspection Management or the Receipt page and use Register Inspection Results. Enter the To Inspect and Approve quantities, and scrap or return per cause for faulty parts.
To be received: move the parts into stock with the Move Into Stock page.
Open transport task: execute it directly or through a warehouse task.
No location found: correct the setup. Putaway zones must be set up for the part, and dimension rules with missing values can leave no location.
Wrong receipt: a receipt can be cancelled at any point and restarted from the source order arrival. A purchase order receipt cannot be cancelled once an invoice is matched, once parts are scrapped or returned, or when the link between the receipt line and the stock location is broken, so undo scrapping or returns first.
Customer returns follow the Register Arrival page as well. Inventory parts are scrapped by an inspection on the Receipt page with a scrapping cause, and the RMA header is set to Completed after all returned parts are received into inventory or scrapped. The article RMA and customer returns in IFS Cloud covers that side in detail.
5.How do you stop receipts from stalling again?
Receipts stop stalling when each waiting status has a named owner, an age limit and a check that reports breaches. What follows is the author's practice, built on the documented behaviour, and it is not an IFS procedure.
Choose the receive case per part group on purpose. The case sets the steps between dock and stock, so inspect cases belong to parts with a real quality reason.
Name an owner per waiting status. Quality owns "To be Inspected", and the warehouse owns "To be received" and transport tasks.
Set an age limit per status. The pages I read give none, so agree one with the people involved and write it down.
Check putaway setup when a part is created.
Replace the weekly review with an exception check.Exception routing sends the line to its owner when it breaches the limit.
What is the difference between Receive into Arrival and Receive into Inventory in IFS Cloud?
With Receive into Inventory, parts go directly to a stock location at arrival registration and the receipt line is Received. With Receive into Arrival, parts go to an arrival location and must be moved to stock, and the line is To be received until then.
Why is my receipt line stuck in To be Inspected?
The line is waiting for inspection results. For inventory parts, results must be entered before the quantity can move into a stock location. They are entered in the Register Inspection Results dialog, and a remainder stays open until approved, scrapped and returned quantities equal Qty to Inspect.
Why does IFS Cloud putaway not find a location for a part?
The Inventory Putaway page names these causes. Putaway zones must be set up for the part, and open-interval or unset-dimension rules can leave no available location. Receipt rules on locations and validation of storage requirements can also block the transaction.
How are customer returns received in IFS Cloud?
Returned material is received on the Register Arrival page. Inventory parts to be scrapped are scrapped by an inspection on the Receipt page, with a scrapping cause, and the RMA header becomes Completed after all parts are received into inventory or scrapped.
7.About the author
Dariusz Myśliwiec brings 18 years of hands-on work with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Find where your received goods wait
Tell me which deliveries feel slowest to become usable stock. On a 30-minute fit call we can look at your receive cases, the statuses that collect receipt lines, and your putaway setup, and decide who should own each waiting step.
Independent IFS Cloud practice · Business process optimisation
Delivered but not invoiced in IFS Cloud: finding customer order lines that left the warehouse without an invoice
A delivered customer order line without a customer invoice is revenue that has not been billed, while, in the standard flow, the cost of the goods is already booked. The IFS Cloud documentation gives several separate reasons why a delivered line may wait for an invoice. This article lists them with sources and shows where to look and how to keep the gap closed.
Key takeaways
The documentation calls this state outstanding sales: cost of goods sold is posted and the sales postings are not yet created.
Whether invoicing is manual or automatic depends on the order type; in the documented example the customer invoice must be created manually.
A delivered line can wait for documented reasons: pending delivery confirmation, a block from invoicing, Provisional Price, shipment invoicing that waits for a Closed shipment, or an invoice type that does not match the run.
An age threshold and a named owner for every manual invoicing step are my practice; the pages I read describe no such setting.
1.What does delivered but not invoiced mean in IFS Cloud?
Delivered but not invoiced means a customer order line has been delivered and no customer invoice exists for it yet. The Customer Order Invoicing page states that goods have to be fully or partially delivered before invoicing, and that the order can be invoiced either manually or automatically, depending on the order type settings.
The View Outstanding Sales activity gives the accounting description: customer order lines that are delivered but not yet invoiced, where cost of goods sold has been posted and the sales postings are still pending, evaluated by company, site, customer order or sales part.
In the standard flow, stock has left and its cost is in the ledger, while the revenue is not recorded and the customer has not been asked to pay. Because delivered lines of a partly delivered order are invoiced and more can follow, in my reading such an order can carry invoiced and waiting lines at once, so a check at order level is too coarse.
2.Why does a delivered line stay without an invoice?
A delivered line stays without an invoice when a documented condition for invoicing is not met, or when the step that creates the invoice has no one assigned to run it. The table lists the conditions I found, with the release of each page.
Cause
What the documentation says
The order type stops before invoicing
Stop After marks the events performed manually. In the documented example, with Report Picking and Print Delivery Note selected, the invoice must be created manually (25R2).
Delivery confirmation is pending
An order that requires delivery confirmation must be confirmed before an invoice is created (25R2). The Confirm Deliveries option sits on the Customer Order/Order Details tab (26R1).
The order or line is blocked from invoicing
Orders or lines blocked from invoicing cannot be invoiced (25R2), and such a line cannot be delivery confirmed (26R1).
Provisional Price is enabled
You cannot create invoices for lines with the Provisional Price setting enabled, because the price is temporary (25R2).
The shipment is not Closed
Shipment invoicing runs on Closed shipments, and the shipment type can create the invoice automatically (26R1). For a connected order, control passes from the order type to the shipment type (25R2).
The invoice type does not match the run
Create Customer Order Invoice requires invoice type Normal Invoice. Collective invoicing requires a customer setup that allows it (25R2).
Part of the order is delivered
Delivered lines are invoiced, and a charge connected to a part order line waits until that line's quantity is delivery confirmed (25R2).
An advance invoice exists
Orders with an advance invoice are excluded from shipment invoicing and must be invoiced through the normal create invoice option (26R1).
The Credit Control page covers a case that is easy to assume the other way round. An order that fails the credit check is set to Blocked and cannot be processed further, with one exception: an invoice can still be created for anything that is ready for invoicing. By that page, a credit hold is not a reason for a delivered line to stay uninvoiced.
I would look at the first row before the others, because it describes a line that can be invoiced and waits for a person. The person who runs Create Invoice for that order type has to act, so name that person.
3.How do you find delivered lines that have no invoice?
You find delivered lines without an invoice with two views: the accounting view in the standard Outstanding Sales page, and an age-based view of delivered lines that you define yourself.
Start with Outstanding Sales. The View Outstanding Sales activity opens the Outstanding Sales list page and allows different dates for cost of goods sold and sales postings.
Know its blind spot. With Delay Cost of Goods Sold to Delivery Confirmation enabled, cost is posted at confirmation and then counts as an outstanding sale (26R1). In my reading, a line delivered but not yet confirmed has no posted cost, so check the Delivery Confirmation of Customer Orders page separately.
Define the aging view. Take delivered and partially delivered lines with no invoice and count the days since the latest delivery. Group them by order type, because the order type points to the likely cause.
Sort by cause. For each group, ask whether the line could be invoiced today. A yes marks a process gap; a no points to a row in the table.
The aging view can run as a read-only query against the OData projections; the reasoning is in read-only OData monitoring in IFS Cloud. Confirm every field in your own $metadata, because the pages above name none for this.
4.How do you clear the backlog once you have the list?
You clear delivered, uninvoiced customer order lines by removing the cause first and creating invoices second, because an invoice run over lines that are still blocked leaves the same lines behind.
Stop After before invoicing - create the invoices on the Create Customer Invoices page, or in bulk with the Batch Create Customer Invoices task assistant, where parameters specify which invoices to create (25R2). Whether the batch can be scheduled is not stated, so confirm it locally.
Confirmation pending - report it on the Delivery Confirmation of Customer Orders page. Lines blocked for invoicing, or with Incorrect Delivery Confirmation set to Yes, cannot be confirmed (26R1).
Blocked from invoicing - the pages I read do not say who sets or clears an invoicing block on a single line, so agree that locally. A credit block does not have to be released to create the invoice for lines that are ready (25R2).
Collective customers - run Create Collective Customer Invoices (25R2).
Shipment not Closed - shipment invoicing runs on Closed shipments, so close it, and review whether the shipment type should create the invoice automatically (26R1).
Before a large run, I would agree the invoice date and period with finance and warn sales. That is a working habit, not a documented step.
5.How do you keep the gap from reopening? (author's practice)
In my practice, delivered, uninvoiced customer order lines stop accumulating when every manual invoicing step has a named owner and a limit on how long a delivered line may wait.
Name an owner for each order type that leaves Create Invoice to a person, including the day the run happens.
Set an age limit per cause. A line awaiting delivery confirmation can wait longer than a line with no obstacle.
Send the exception to the person who can act. A message to the invoicing owner when the limit passes finds the line while the delivery is fresh, as argued in exception routing versus reporting.
Keep legitimate waits in a separate view. Provisional Price lines, confirmations within their limit and shipments not yet Closed are expected, and listing them as exceptions teaches users to ignore the message.
Re-check after each order type change, because a change to Stop After alters who does what.
The pages used here are for IFS Cloud 25R2 and 26R1, as marked. Behaviour can differ between releases, so confirm each point for the release you run, starting with Create Customer Order Invoice (25R2).
What does delivered but not invoiced mean in IFS Cloud?
Delivered but not invoiced means a customer order line has been delivered and no customer invoice exists for it. The IFS Cloud documentation describes this state as outstanding sales: order lines where the cost of goods sold has been posted and the sales postings have not yet been created.
Where can I see delivered but not invoiced orders in IFS Cloud?
The View Outstanding Sales activity opens the Outstanding Sales list page, which shows outstanding sales by company, site, customer order or sales part. In my reading, lines awaiting delivery confirmation under the delayed cost option need a separate check.
Why can a delivered customer order line not be invoiced?
The documentation names pending delivery confirmation, an order or line blocked from invoicing, Provisional Price enabled, shipment invoicing that waits for a Closed shipment, and an invoice type that does not match the activity.
Does a credit block stop a delivered order from being invoiced?
According to the Credit Control in Customer Order page, an order that fails the credit check is set to Blocked and cannot be processed further, except that an invoice can be created for anything ready for invoicing.
7.About the author
Dariusz Myśliwiec brings 18 years of hands-on work with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Find out which delivered lines are waiting for an invoice
Tell me which order routines you suspect. On a 30-minute fit call we can walk through your order types, the Stop After settings and the aging of delivered lines, and decide who should own each manual invoicing step.
Independent IFS Cloud practice · Business process optimisation
Sales orders below cost in IFS Cloud: how margin shows on the order line, why a loss-making order gets through, and how to find it
A customer order line can carry a price below the cost of the part, and the pricing documentation describes no check that stops it. This article covers what the IFS Cloud documentation says about contribution margin, how a below-cost order comes about, how to find the lines already in your data, and how to design a check that catches the next one on the day it is entered.
Key takeaways
The documentation defines contribution margin as the difference between the sales price and the inventory value, calculated per sales unit and shown per unit, per order line and per order.
The Analyze Contribution Margin page states that the analysis is done manually by the user and has no system effects. It reports a margin, and it does not stop an order.
The pricing documentation says a manually entered price on a customer order line has the highest priority, and I found no comparison with cost.
In my practice, prevention means a margin rule, a scheduled measurement and routing of exceptions to the person who can change the price.
1.What is a below-cost order in IFS Cloud, and where does margin show?
A below-cost order is a customer order line whose net amount is lower than the cost of the goods on it, so the line has a negative contribution margin. The IFS Cloud documentation describes contribution margin on the Analyze Contribution Margin page: it is the difference between the sales price and the inventory value, calculated per sales unit, and the page shows it per unit, as a total per order line and as a total per order.
Customer discounts and the order discount are part of the calculation, and an Extra Discount field lets you test a further discount. The documentation pages I fetched do not name a Cost or Margin column on the Customer Order Line page, so I cannot give its exact label in 25R2 or 26R1. An IFS Community thread mentions a COST field on the line, but it is a user post, so check which fields your release exposes.
2.Why does a below-cost order get through?
A below-cost order gets through because the documented price entry and margin analysis include no stop. The Pricing page describes a source ladder for an order line (agreements excluded from auto-pricing, campaigns, agreements, price lists, the sales part price) and states that a manually entered price on the line has the highest priority. It describes no warning or block for a price below cost or below a margin threshold. That is a statement about the page, so test your own release.
Reading the documented pricing behaviour, I see these routes to a low or negative margin.
Manual price - a price typed on the line wins over every automatic source, according to the Pricing page.
Manual or stacked discount - a manually entered discount percentage overrides automatic discount fetching. With the multiple-discounts strategy set per site, up to two sources can apply to one line.
Stale price source - prices are tied to valid-from dates, and the Pricing page warns that prices retrieved by order date may be out of date today. The cost moves, and the price list or agreement may not.
Price effective date - with the Delivery Date pricing method and automatic update enabled, changing the wanted delivery date updates the price effective date after confirmation, and discounts are updated per the price sources. In my reading, this can also re-price the line, so test it on your configuration.
Frozen price - the documentation says Recalculate Price/Currency reruns the price logic, including the current valid price list, and is not available when Price Freeze is enabled on the line. So a frozen line cannot be recalculated after the list or the cost has moved.
The documentation I fetched does not say whether a cost change updates base prices, price lists or open order lines. In my view, assume it does not until you have tested your configuration.
3.How do you find lines sold below cost?
You find below-cost order lines by comparing the net amount of each open line with its total cost and listing the lines where the result is below your threshold.
Route
What the documentation says
Contribution Margin analysis for one order
Shows margin per unit, per line and per order, including customer and order discounts, with an Extra Discount what-if field. Manual, no system effects.
Business intelligence fact for customer order lines
The 26R2 documentation page for the fact lists NET_AMOUNT_BASE, TOTAL_COST ("Total Cost in Base Curr CO Line") and measures such as Profit Margin %. Its Profit Margin Goal is described as "Hard coded to 0.1", a modelling default.
My illustration extends the documentation's quotation example (price 300, part cost 150, a 50% margin). Apply a 55% total discount and the net is 135, the contribution is minus 15 and the margin is about minus 11%. This is arithmetic, not system data, and the line looks like an ordinary discounted line until net is put next to cost.
Cut the list by price source: the BI fact exposes Price Source, Price Source ID and Price List No. If a cluster of lines shares one agreement, start with that agreement. If your release also records manual prices as a price source, which I could not confirm, a cluster there points to the entry process.
The cost figure needs care. A 2023 IFS Community thread, written by users with no IFS reply, says the line cost is an average of current inventory cost buckets and can disappear for a used-up lot under cost per lot batch. I treat that as a hypothesis to test. Write the cost basis into the report definition.
4.How do you fix a below-cost line that is already on an order?
You fix a below-cost line by first finding out which of the causes in section 2 produced it, because the correction differs. These are the levers; the first, second and fourth rest on the documentation, and the third is my advice.
Stale price list or agreement. Correct the source. The Pricing page advises changing price lists, current and old ones, with great care, and it lets you enable review of base price updates so that lines wait in Planned status until reviewed. For expired agreements, see customer price agreement expiry.
Recalculate the open line. Recalculate Price/Currency reruns the price logic and checks the current valid price list, and it requires a saved line with Price Freeze disabled. A frozen line needs a decision on whether the price is an agreed commitment.
Manual price or discount. This is a commercial decision. Ask the account owner whether the price was intended and record the answer on the order.
Price already confirmed to the customer. Changing it after confirmation has its own consequences, covered in orders changed after confirmation.
5.How do you stop the next one? (author's practice)
A below-cost order is stopped by a written margin rule, a scheduled comparison of net amount with total cost, and an owner for each exception. The approach below is my own practice, not an IFS procedure.
Write the rule down. Decide what counts as an exception: below cost, below a floor margin by product group, or below a floor for a customer segment. Keep the cost basis in the definition.
Name the deliberate cases. Free of Charge lines, samples and approved loss leaders get a recorded reason.
Measure on a schedule. Compare net amount with total cost on every open line daily, and again after any change to a price list, agreement or cost set.
Route to the person who can act. A line created from a manual price goes to the sales owner. A line created from a price source goes to whoever maintains that source. The argument is in exception routing instead of reporting.
One limit applies: the check shows a line is below your threshold, and the account owner decides whether the price was wrong. Measure the share of alerts that proved true and tune the rule on it.
I found no statement in the IFS Cloud documentation that blocks or warns on a customer order line priced below cost. The Pricing page says a manually entered price on the line has the highest priority and describes no cost or margin check, and the Analyze Contribution Margin page says the analysis is done manually and has no system effects. Test your own release.
How is contribution margin defined on a customer order in IFS Cloud?
The documentation defines contribution margin as the difference between the sales price and the inventory value, calculated per sales unit. The Analyze Contribution Margin page shows it per unit, per order line and per order, includes customer discounts and the order discount, and offers an Extra Discount field to test a further discount.
Why did a line become below cost after the price list was correct?
Several documented behaviours can leave a line with an old price or change it after entry. Price Freeze makes Recalculate Price/Currency unavailable, a typed price has the highest priority, and under the Delivery Date pricing method with automatic update enabled, changing the wanted delivery date after confirmation updates the price effective date and the discounts.
Can I recalculate the price on an existing order line?
Yes, with conditions. The Recalculate Price/Currency activity reruns the price logic for the line, including a check of the current valid price list. The line must be saved and Price Freeze must be disabled. A recalculated price can differ from the original if the price list has changed.
7.About the author
Dariusz Myśliwiec brings 18 years of hands-on work with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Agree a margin rule and an owner for below-cost lines
Tell me how your prices are set today: price lists, agreements, manual entry. On a 30-minute fit call we can agree a margin rule, a cost basis and an owner for each type of exception, so a below-cost order is seen on the day it is entered.
Independent IFS Cloud practice · Business process optimisation
Customer order types in IFS Cloud: deciding which steps of the order flow run on their own
Every customer order in IFS Cloud has an order type, and the order type decides how much of the order flow happens without a person: release, reservation, picking, delivery, invoicing. Changing it needs no development, only a decision about where a human should stand in the flow, and it is easy to leave at whatever the first project configured. This article explains what the order type controls, what each setting does according to the IFS Cloud documentation, and how to use it to remove waiting from the flow.
Key takeaways
Every customer order requires an order type. It controls which steps run automatically and which are manual, and whether shipment inventory, consignments and priority reservations apply.
The Stop After field marks the events that are performed manually. Selecting fewer events produces a more automatic flow, and the documentation lists eleven events from Release Order to Print Invoice.
Priority Reservation reserves at order entry, and if inventory is insufficient the order line cannot be saved. The line is either reserved or refused at entry.
An order type header cannot be deleted once saved, and only its description can be changed, so the design deserves some thought before the first one is created.
The default order type on the customer helps keep the flow consistent at entry, because the user does not have to choose.
1.What does the customer order type control in IFS Cloud?
The documentation says that order types control the customer order process, and that each order type maps to one customer order routine the company uses. A routine is a way of working, for example stock items shipped from one warehouse, goods staged before loading, or service orders. Different routines need different amounts of human attention, and the order type is where that difference is written down.
An order type needs a code and a description. Two types are preset, Normal (NO) and Service Order (SEO), and the service management process requires the second. Their settings and descriptions can be changed. Creating or modifying order types is an administrator task.
The order type is attached in one of two ways. You can enter it on the order, or you can set a default order type on the customer record. The default is used automatically at order entry and can be changed before the order header is saved. If there is no default, the user has to type the short code.
2.How does the Stop After field shape the flow?
On the IFS Cloud customer order type, the Stop After field marks which events are performed manually. The documentation gives one example: selecting Report Picking and Print Delivery note makes delivery and invoice creation manual, while the other steps run automatically. The documentation does not state the default settings, so check what your own order types contain before you change anything.
Event
Documented effect
Release Order
Changes the planned order to Released after entry and approval.
Print Order Confirmation
Prints a confirmation for the customer. The customer record determines whether one is printed.
Reserve Order
Reserves inventory, unless that is done manually or through priority reservation.
Create Pick List and Print Pick List
Creates the pick list, then prints it.
Report Picking
Confirms quantities and source inventory locations.
Deliver Order
Records the delivery and reduces the inventory balance.
Create Delivery Note and Print Delivery note
Creates the delivery note, then prints it.
Create Invoice and Print Invoice
Creates the customer invoice for the delivered order, then prints it.
In the documented example and in both documented rules (Priority Reservation and Use Shipment Inventory), the step after the selected event is the one that waits for a person. Read in the documented order, the events form a chain, and in my reading a stop is a hand-over to a person that lasts until that person acts. That is useful where a human adds judgement, for example checking a picked quantity. It is waste where the person only presses the button that the system could have pressed.
3.What do Priority Reservation, Consignment and Shipment Inventory add?
Priority Reservation - the order is reserved at entry and gets a higher priority than other orders. If inventory is insufficient, the order line cannot be saved. Without this option, Print Order Confirmation must be in Stop After, so that reservation is done manually.
Consignment - Order Specific creates a new consignment when the order is saved. Add To Existing adds the order to a matching consignment, one with the same customer, site, order currency and delivery terms, and creates a new one if none is Open. No Consignment creates none, and the order can be connected to one manually.
Use Shipment Inventory - after picking, orders move to a shipment inventory location to be staged before delivery. When it is selected, the flow should stop after Print Pick List, because report picking must be done manually.
Two remarks in the documentation affect the design. Consolidated pick lists have their own settings, which override the order type for shipment inventory, pick list printing and pick reporting, and pick reporting is always manual with them. And in multi-site environments the documentation recommends dedicated order types to distinguish multi-site orders.
In my view, Priority Reservation deserves particular care. A refused line at entry tells the salesperson about the shortage at the moment of entry, and so moves the reaction to that point. Where reservation is not instant, lines can wait without supply, which is the situation described in sales orders without coverage.
4.How do you design order types so the flow loses its waiting time?
My approach has five steps. It is built on the documented behaviour and is not an IFS procedure.
List your real routines first. Write down the ways orders actually move through your company. Each routine that needs a different set of manual steps is a candidate for its own order type. Routines that need the same steps share one.
For every manual step, name the person and the reason. If nobody can say what judgement the person adds at a stop, the stop is a candidate for removal.
Keep the number of types small. Each type has to be explained to users and cannot be deleted once saved, so a type that few orders use adds maintenance for little gain.
Set the default on the customer. Then the routine is chosen by the customer's profile and not by whoever enters the order that day.
Change one type at a time and watch the flow. Move a stop later, and look at what shows up downstream. A step that used to be checked by hand may start to fail quietly.
The last point is the real risk of automation. When a step that a person used to supervise becomes automatic, the person's supervision disappears with it. That is a process-drift problem, described in process drift after go-live, and the answer is to replace the supervision with a check that reports exceptions, not with a weekly review, as discussed in exception routing instead of reporting.
An example of the thinking, for illustration only: a company ships stock items from one warehouse, stages some orders before loading, and also runs service orders. That is three routines, two of them on preset types if the plain stock routine uses Normal and the service routine keeps Service Order. The staged routine selects Use Shipment Inventory and stops after Print Pick List, as the documentation advises. The plain stock routine has no stop before invoicing, so picking, delivery and invoice creation do not wait for a person. Your own stops depend on who can do what, and that has to be agreed with the people involved.
5.What should you check in an existing configuration?
What you see
What to check first
Orders wait after picking for days
Whether the order type stops after Report Picking, so that Deliver Order waits for a person, and whether anyone is assigned to act on it.
Invoices are created late
Whether the order type stops after Print Delivery note, which makes invoice creation manual in the documentation's own example.
Users keep choosing the wrong order type
Whether the customer has a default order type.
Lines are refused at entry for lack of stock
Whether the order type has Priority Reservation, which refuses a line when inventory is insufficient.
Staged orders are reported as picked without a person
Whether Use Shipment Inventory is selected and the flow stops after Print Pick List, as the documentation advises, and whether consolidated pick lists are in use, because their settings override the order type for shipment inventory and pick reporting.
Multi-site orders are mixed with domestic ones
Whether dedicated order types exist for multi-site orders, as the documentation recommends.
Order types set the flow after entry, but the promise made at entry can still change later. When an order changes after the customer has been told, see orders changed after confirmation. When the cost of checking steps by hand is the question, the cost of manual monitoring puts a number on it.
The primary source is the IFS Cloud documentation page Customer Order Type (25R2). Behaviour can differ between releases, so check the page for the release you run.
A customer order type is a setting that every customer order requires and that controls the customer order process. It decides which steps run automatically and which are manual, and whether shipment inventory, consignments and priority reservations apply. Each order type maps to one customer order routine that the company uses.
What does the Stop After field do on the IFS Cloud customer order type?
The Stop After field marks the events that are performed manually. Selecting fewer events produces a more automatic flow. In the documentation's example, selecting Report Picking and Print Delivery note makes delivery and invoice creation manual, and the other steps run automatically. In that example, the step after each selected event becomes manual.
Can I delete or rename an order type?
An order type header cannot be deleted once it is saved, and only its description can be changed. The preset types Normal (NO) and Service Order (SEO) can have their settings and descriptions changed, and the service management process requires the Service Order type. Creating or modifying order types is an administrator task.
How do I make sure users pick the right order type?
Attach a default order type to the customer. The default is used automatically at order entry, and the user can still change it before saving the order header. Without a default, the user has to enter the order type's short code manually.
7.About the author
Dariusz Myśliwiec brings 18 years of hands-on work with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Find where your order flow waits for a person
Tell me which order routines feel slowest. On a 30-minute fit call we can look at your order types, their Stop After settings and customer defaults, and decide which stops add judgement and which only add delay.
Independent IFS Cloud practice · Business process optimisation
Reorder points in IFS Cloud: classify the parts first, then let the job calculate
A reorder point is only as good as the group of parts it was calculated for. Inventory Planning and Replenishment (IPR) in IFS Cloud classifies parts by value, movement and lifecycle stage, and calculates a lot size, a safety stock and an order point for them. In my view the classification is the part that decides the result: if every part gets the same parameters, a fast mover and a part nobody has issued for a year are treated alike, and the second one ends up in the aging report.
Key takeaways
IPR is an inventory control solution based on reorder points. IFS positions it for independent demand, mainly distribution and spare parts, and it can run alongside Kanban and MRP.
Parts are classified three ways: ABC by volume value, frequency by issue transactions per month, and lifecycle (Introduction, Mature, Decline, Expired). The planning parameters are then set per combination.
The job calculates four things: lot size, safety stock, order point and next order date. Models are chosen for demand, safety stock, lot size and order point, from Manual to statistical ones.
Values are inherited from Company down to Supplier, and the lower level overrides the higher one, so the most specific rule wins.
The classification can be overridden on the part until a locked-until date. After that date the history takes over again.
1.What problem does Inventory Planning and Replenishment solve?
Parts with independent demand are not driven by a production plan, so there is nothing to explode and nothing for MRP to net. Someone, or something, has to decide when stock is low enough to reorder and how much to order. With no MRP behind these parts, the decision falls to whoever orders them, in practice a planner with a spreadsheet, which is the pattern described in the shadow spreadsheet running a factory.
IPR moves the decision into the system. A part is planned this way when its Planning Method on the inventory part is set to B for reorder-point planning. The documentation lists two prerequisites besides that: accurate and complete basic data, and, for a switchover, the "Import Inventory Part Daily Issues" assistant, which can load historical issue data so the first classification has something to work with.
2.How are parts classified, and why does it come first?
The step is called Perform ABC, Frequency and Lifecycle Classification, and it runs on issue history. Three views of the same part are produced.
Classification
Based on
Classes
ABC
Volume value: the part's inventory value multiplied by its issued quantity
A, B, C. By default 80%, 15% and 5% of turnover within the asset class or site
Frequency
Issue transactions per month, compared with limits set per site or asset class
Fast, Medium, Slow and Very Slow Movers
Lifecycle
Stage boundaries, set as offsets per site or asset class
Introduction, Mature, Decline, Expired. Parts move between stages automatically
A classification matrix is created for each lifecycle stage and each site and asset class combination. The asset class is the grouping you choose, for example spare parts against raw materials. It is also where seasonality is set, and where the Classification Periods field decides how many months of history the classification reads.
Four details are easy to miss. The ABC ranges are global, so the same percentages apply to every part that IPR plans. And on the ABC Classes page, a system administrator can change the percentages, but the accumulated total of all classes must be 100% or the page cannot be saved. According to the 25R2 page, a new part record gets class C until an ABC analysis has been run, and the calculation is not carried out for configured parts.
The classification can be overridden on the Inventory Part page until a locked-until date. After that date it reverts to history. The documentation gives new parts with a forecast but no sales history as an example: you set the class yourself for a defined period.
3.What does the job actually calculate?
Four outputs: the lot size (the quantity proposed when replenishment is needed), the safety stock (the buffer for demand variation), the order point (the level at which replenishment is due) and the next order date, which assumes consumption follows the forecast.
What is modelled
Models in the documentation
Demand
Forecast (from IFS Demand Planning), Yearly Prediction (field Pred Year Cons Qty), or History
Safety stock
Manual, Time Coverage, Historical Uncertainty (uses the service rate), Mean Absolute Error (uses the Demand Planning error)
Lot size
Manual, Time Coverage, Economic Order Quantity. Max Order Cover Time, Durability and Min, Max and Multiple lot sizes also apply
Order point
Manual or Lead Time Driven. For slow movers: Slow Movers by Lifecycle or Lead Time, and Croston by Lifecycle or Lead Time
The inputs behind them are lead times, ordering cost, the inventory interest rate, the service rate, available quantities and demand. Lead-time variation is taken from historical order occasions, so it reflects how replenishment actually arrived.
The documentation does not describe the sequence of the IPR job, the default service rate values, or exactly how the results are written back to Inventory Part Planning Data. Treat those as things to confirm in your own system before you rely on them.
4.Which rule wins when several levels define a value?
Parameters can be set at several levels, from the top: Company, Site, the ABC, frequency and lifecycle combination, Asset Class, Commodity Group, and Supplier. Lower-level values override higher-level ones.
My suggestion for a start: a few rules at the top that cover everything, then exceptions only where a part group behaves differently. A value set at Supplier level beats one set at Site level without anyone needing to touch the parts.
In my experience the same inheritance is also how a setting gets forgotten: a value placed low in the hierarchy keeps winning after the reason for it has gone.
5.Where does reorder point planning go wrong in practice?
These are conclusions from the documented behaviour and from reviews of how companies run planning, not features IFS Cloud raises on its own.
What you see
What to check first
Parts that should be planned this way show no proposals
The Planning Method on the part is not B, so IPR never looks at it.
Many new parts sit in class C
No ABC analysis has run since they were created. New parts get class C until it does.
Seasonal parts get a low order point in the season
Classification Periods on the asset class covers too few months, or seasonality is not set.
A part keeps an old class long after its demand changed
A manual override with a locked-until date far in the future.
Order points rise and stock ages
Safety stock and lot size models are too generous for slow movers, and the extra stock shows up later in the stock aging report.
The pattern behind four of the six rows is that a parameter was right on the day it was set. After go-live nobody owns the question of whether it is still right, which is the subject of process drift after go-live.
6.How do you introduce it without disturbing the warehouse?
These steps are my recommendation, not an IFS procedure.
Start with one asset class. Pick a group of parts with real issue history and a planner who knows them.
Run the classification and read it. Check that the A parts are the ones the business already calls critical. If they are not, look at what drives the volume value and at the Classification Periods setting.
Compare proposals with current practice for one full replenishment cycle, or one season for seasonal parts. Do not order from the proposals yet. Note where they disagree with what the planner did and why.
Choose the simplest model that holds. Manual and Time Coverage are easier to explain to a buyer than Croston. Move to a statistical model for a class only where simple rules keep missing.
Give the overrides an owner and an expiry. Every locked-until date and every low-level rule needs a name next to it and a review date.
Steps two and five are a checking job, not a configuration job: which parts have a class that no longer matches the demand, and which overrides have outlived their reason. A read-only monitoring pattern can produce that list without writing anything back to IFS Cloud.
No. The documentation describes IPR as a solution for independent demand, mainly distribution and spare parts, and says it can run alongside Kanban and MRP. A part is planned by IPR when its Planning Method is set to B for reorder-point planning.
What are the default ABC classes in IFS Cloud?
The system ships with three classes: A at 80%, B at 15% and C at 5% of turnover value within the asset class or site. A system administrator can change them on the ABC Classes page, as long as the cumulative total stays at 100%. Parts are ranked by volume value, which is the part's inventory value multiplied by its issued quantity.
Can I override the classification of a single part?
Yes. Classification values on the Inventory Part page can be set manually until a locked-until date. After that date the classification returns to what the history says. The documentation names new parts with a forecast but no sales history as the case it is meant for.
How much history does the classification use?
The Classification Periods field on the asset class sets the number of months of issue history to read. Seasonality is also set on the asset class, so in my view seasonal parts are best grouped in their own asset class.
8.About the author
Dariusz Myśliwiec brings 18 years of hands-on work with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Check your reorder points against how the parts really move
Tell me which part groups cause the most stock-outs or the most aged stock. On a 30-minute fit call we can look at how they are classified today, which parameters were set at which level, and whether IPR is the right tool for them.
When Does an Independent IFS Consultant Really Add Value?
Sometimes the most valuable person on an ERP project is the one who isn’t afraid to challenge it.
An independent IFS consultant shouldn’t simply help you implement, upgrade, or support your ERP system. They should help you make better decisions about it.
5 Key Situations Where Independent Expertise Makes a Difference
01
Unbiased Technical Opinions
An independent consultant can challenge assumptions, question proposed approaches, and recommend what is right for your business rather than what simply fits a vendor’s delivery model.
02
Simplifying Complex Environments
Over time, customisations, integrations, and workarounds accumulate. An outside perspective helps identify what delivers true value, what creates technical debt, and where simplification is possible.
03
Specialist Expertise On-Demand
You may not need another full-time hire. You might need deep IFS expertise for a specific upgrade, migration, technical review, performance tuning, or optimization project.
04
Getting ERP Projects Back on Track
Delays, unexpected technical issues, or user resistance quickly get expensive. Experienced external expertise pinpoints root causes and refocuses efforts on critical priorities.
05
Filling Internal Skill Gaps
IFS environments involve specialised requirements across integrations, custom code, reporting, data, and upgrades. The right specialist fills that exact gap precisely when you need it.
💡 The Biggest Benefit: Independent Candor
Perhaps the single greatest advantage is having a partner willing to tell you what you may not want to hear.
“Do you really need that customisation?”Distinguishing essential custom requirements from unnecessary technical complexity.
“Is the ERP actually the problem?”Identifying whether issues stem from software limits or underlying business processes.
“Should this process change first?”Ensuring operational workflows are optimized before configuring automated tools.
“Are you ready to migrate?”Evaluating data health, team preparation, and operational readiness before launching.
Those questions can be uncomfortable in the moment, but they prevent costly mistakes later.
Most consultants are still trying to sell the «all-in-one» dream. It is a mistake that buries companies under a mountain of technical debt. In a modern architecture, IFS Cloud should not function as the primary intelligence processor. Its job is to be the untouchable System of Record, the single source of truth, not a frantic decision-making hub.
Cramming decision logic into the ERP core is the fastest way to kill your upgrade path and lose your competitive edge.
Clean Core is Mandatory, Not Optional
Maintaining a Clean Core strategy requires brutal discipline. Financial transactions, control, and compliance must stay inside IFS. However, workflow orchestration and predictive analytics belong outside. This separation is the only way to deploy updates instantly without risking a total ecosystem collapse every time a new version is released.
Intelligence vs. The Ledger
You must distinguish between record-keeping and intelligence. The ERP, acting as the ledger, protects the value of your data. AI systems build that value by optimizing supply chains or predicting failures before they happen. If your IFS configuration tries to do both, it becomes a bottleneck instead of an engine.
The real challenge isn’t whether ERP is dying. The challenge is how fast you can offload intelligence from your central system.
In the modern enterprise, inventory is a paradox. It is listed as a current asset on the balance sheet, yet in operational reality, it often behaves as a liability. It consumes working capital, occupies expensive square footage, risks obsolescence, and masks inefficiencies in planning and production. The Stock Aging Report (or Inventory Aging Analysis) is the definitive analytical instrument used to resolve this paradox.
For IT Directors, Supply Chain Managers, and Manufacturing Leaders, the Stock Aging Report is not merely a list of items and dates; it is a diagnostic tool that reveals the health of the entire demand-supply ecosystem. This article provides a comprehensive, deep-dive analysis of the Stock Aging Report, exploring its structural architecture, its role in financial governance, its application in manufacturing workflows, and the cross-functional processes required to transform this data into liquidity.
Part 1: The Anatomy of Stock Aging
Defining the Metric
At its core, stock aging measures the length of time an inventory item has been held within the company’s possession.1 While this sounds trivial, the complexity lies in the definition of «possession» and «time» within an ERP context.
For a Supply Chain Manager, age typically begins at the moment of Goods Receipt (GR). For a Manufacturing Manager dealing with Work in Progress (WIP), age might reset upon the completion of a production phase. For the IT Manager architecting the data warehouse, the challenge is defining whether age is tracked at the SKU level (average weighted age) or the Batch/Serial level (specific identification).
The Standard Bucketing Logic
The universal language of stock aging is the «bucket.» These are time intervals that categorize inventory based on its dormancy.
0 – 30 Days: Fresh stock, actively flowing.
31 – 60 Days: Standard cycle stock.
61 – 90 Days: Watchlist items; turning slower than optimal.
A sophisticated business process never relies on static templates. The definition of these buckets must adapt to industry verticals. For a perishables distributor (FEFO: First Expired, First Out), «old» might be 7 days. For an aerospace manufacturer holding strategic spare parts, «old» means 5 years.
The Technical Architecture
For IT Directors, the implementation of a Stock Aging Report demands hard decisions regarding data lineage and granularity.
FIFO vs. Weighted Average Logic:
If the ERP system uses a Weighted Average Cost method, calculating the physical age of the stock requires a FIFO (First-In, First-Out) assumption layer in the reporting tool. The report must assume that the first unit sold was the first unit bought, even if the system averages the cost. This forces complex SQL queries or BI modeling that reconstructs the inventory layer stack.
The Internal Movement Fallacy:
A frequent failure in designing these reports is the «reset» error. When stock is transferred from Warehouse A to Warehouse B, poorly configured reports reset the «Receipt Date» to the transfer date. This falsifies the data, making dead stock look fresh. The IT architecture must track the Original Receipt Date across internal supply chain nodes to preserve data integrity.
Performance vs. Real-Time:
Calculating aging on a dataset of millions of SKUs with complex transaction histories destroys system performance. Best practice dictates creating a snapshotted «Inventory Fact Table» updated nightly, rather than running live aging queries against transactional tables during peak business hours.
Part 2: The Financial Dimension – Working Capital and Valuation
The Cash Conversion Cycle (CCC)
The Stock Aging Report is the primary input for calculating the Inventory Period component of the Cash Conversion Cycle.
$$CCC = Days Inventory Outstanding + Days Sales Outstanding — Days Payable Outstanding$$
When the report shows a skew toward the 180+ day buckets, it mathematically proves that the company is over-producing or effectively financing its customers, trapping cash required for R&D or debt reduction.
Provisions for Obsolescence
Financial standards (IFRS/GAAP) demand inventory valuation at the Lower of Cost or Market (LCM).2 The Stock Aging Report serves as the primary evidence document for auditors.
The Provision Matrix: Companies establish policies where inventory in specific buckets triggers an automatic financial provision. Stock > 360 days is often provisioned at 100% (value written to zero on the P&L).
The Impact: This protects the company from inflated asset valuation, but it hits Net Income immediately. SCM and Sales managers face immense pressure to move stock before it hits the aging bucket defined by Finance.
Part 3: Supply Chain Management Applications
Root Cause Analysis of Slow Movers
When the report highlights a swell in the 90 – 180 day bucket, the SCM Manager must switch from monitoring to aggressive diagnostics. The report identifies three distinct types of aging inventory:
The Long Tail SKU: Items added to the catalog to be a «one-stop-shop» but lacking sufficient demand frequency.
Action: Rationalize the SKU portfolio. Halt procurement entirely.
The Bullwhip Victim: Inventory accumulated due to a forecasted spike in demand that never materialized.
Action: Review demand planning algorithms and safety stock parameters.
The Supplier MOQs: Stock existing solely because the supplier imposed a Minimum Order Quantity (MOQ) exceeding the annual consumption rate.
Action: Renegotiate MOQs or switch to a distributor model for these parts.
Procurement Governance
The Stock Aging Report belongs inside the Purchasing module of the ERP. A robust setup triggers a hard block on Purchase Requisitions for items that already have quantity sitting in the >90 day bucket. This prevents the «buying robot» phenomenon where automated MRP runs generate orders for items that are technically in stock but ignored because they reside in a different location.
Warehouse Optimization
Old stock is never high-velocity stock. It has no right to occupy premium warehouse space.
Golden Zone Management: The «Golden Zone» (waist-to-shoulder height, near shipping docks) is strictly for fresh, fast-moving goods.
The Aging Migration: Use the Aging Report to drive tasks that move >180 day stock to upper racks or off-site storage. This ruthlessly improves picking efficiency for active SKUs.
Part 4: The Manufacturing Perspective
Raw Material (RM) Aging
For the Manufacturing Manager, aging Raw Materials pose a severe quality risk.
Shelf-Life Management: In industries like chemicals or pharmaceuticals, RM aging is a hard compliance issue. The report must be coupled with Batch Blocking logic. If a batch of resin is aged > 6 months, the system must outright prevent it from being issued to a Shop Order.
Design Change Conflicts: High aging on specific components proves a failure in Engineering Bills of Materials (EBOM) transitions. If Engineering releases «Revision B», «Revision A» components stop moving immediately. The Aging Report is the first signal of a botched Phase Out plan.
Work in Progress (WIP) Aging
This remains the blind spot of the organization. Most aging reports lazily focus on Warehouse stock. «WIP Aging» identifies the actual bottlenecks on the shop floor.3
The Black Hole: If a Shop Order sits open for 45 days in a manufacturing cycle that requires 3 days, that material is aged. It screams quality failure, missing components, or undocumented machine breakdown.
Process: IT must generate a specific «WIP Aging Report» tracking the exact time elapsed since the Shop Order release date.
MRO (Maintenance, Repair, and Operations)
Spare parts for production machinery (MRO) possess extremely low turnover but high strategic value.
Insurance Stock: A motor for a main production line might sit on the shelf for 3 years. If the Aging Report treats this as Obsolete and recommends scrapping, the factory faces catastrophic downtime risk.
Segmentation: The Business Process must tag MRO items distinctively (e.g., ABC-XYZ analysis) to exclude them from aggressive aging reduction targets.
Part 5: From Data to Process – Implementation Strategies
Implementing a culture of inventory health requires far more than generating a PDF. It requires enforcing a cyclical business process.
1. The Monthly S&OP Review
The Stock Aging Report is a mandatory, unskippable agenda item in the Sales & Operations Planning (S&OP) meeting.
The Process: Review the «Top 10 Value» items in the >90 day bucket.
Accountability: Force an owner for each line item.
Sales Owner: «I will run a promotion to clear this.»
Production Owner: «I will rework this into a sellable product.»
Procurement Owner: «I will execute a return to the vendor.»
2. The Reserve Logic Implementation
For IT and Finance, automating the provision process removes human hesitation and guarantees accuracy.
Logic:
If Age > 180 days AND Last Usage Date > 90 days: Flag as Slow Moving.
If Age > 360 days: Flag as Obsolete.
ERP Action: These flags must prevent the system from using these items in standard MRP calculations (Netting). It forces the planner to manually intervene, stopping the system from blindly assuming this stock is healthy.
3. Data Cleansing
High aging is frequently a symptom of Ghost Inventory: items the system thinks exist, but physically do not due to theft or counting errors.5
Process: The Cycle Counting strategy must be weighted. Items appearing in the >360 day bucket take priority for physical counting to confirm existence before any financial decision is executed.
Part 6: Remediation Strategies
Once the report identifies the aging liabilities, the business executes a disposition strategy. This forces SCM, Sales, and Manufacturing to collide and resolve the issue.
1. Return to Vendor (RTV)
The most financially advantageous option.
Requirement: High data agility. You must catch the aging trend early (e.g., at 60 days) to negotiate a return while the product remains current for the supplier.
2. Rework / Cannibalization
For Manufacturing Managers.
Scenario: Finished goods (FG) that refuse to sell.
Action: Disassemble the FG to recover the high-value components (Raw Materials) that actually move in other products. This reduces the aging value despite incurring labor costs. The Aging Report calculates the true Net Recoverable Value.
3. Fire Sales / Discounting
Scenario: Seasonal or expiring goods.
Process: The Aging Report dictates an unforgiving discount curve.
60 Days: 10% off.
90 Days: 25% off.
120 Days: Liquidation pricing.
4. Scrapping / Recycling
The absolute last resort.
Process: Physically destroying goods to reclaim space and eliminate tax/insurance burdens on the dead asset.
IT Role: Ensure the Scrap Reason Code in the ERP distinctly captures Obsolescence, forcing the loss to be analyzed in future demand planning cycles.
Stop Running Cloud Systems with Legacy Mindsets
The Stock Aging Report acts as the harsh conscience of your supply chain. It relentlessly exposes the gaps between what you planned to sell and the reality of your market execution.
Treating this data as a passive, month-end PDF means your system architecture has already failed. During a proper IFS Cloud ERP implementation, we do not just migrate old reports; we engineer automated defense mechanisms against dead working capital. By exploiting native IFS Lobbies and Workflows, we configure the ERP to actively block the procurement of slow-moving items and force disposition decisions before the stock rots on the shelf.
{semanticux}
If your current integration partner merely mapped your 1990s spreadsheet logic into a modern cloud environment, you are burning cash. You require an architecture that dictates supply chain discipline, not one that passively records your financial leaks.
Stop Guessing. Start Controlling.
Your ERP should work for your balance sheet, not against it. We rebuild broken supply chain architectures, ensuring your system forces liquidity rather than hoarding dead assets.
When weaponized properly, aging data transitions from a static accounting requirement into a ruthless engine for liquidity. The objective is never just to measure the age of the stock. The objective is to force the organization into a state of perpetual, profitable flow.
Stock Aging & Inventory Health FAQ
How does stock aging impact the company’s financial statements?
Stock aging directly impacts the Cash Conversion Cycle (CCC) and net income. As inventory ages, it increases Days Inventory Outstanding (DIO), trapping working capital that could be used for growth. Furthermore, financial standards (IFRS/GAAP) often require that aged stock be written down to the Lower of Cost or Market, creating an immediate expense provision that reduces profitability.
What is the WIP Blind Spot in aging analysis?
Most aging reports focus solely on warehouse stock, ignoring Work in Progress (WIP). The blind spot occurs when shop orders remain open for extended periods (e.g., 45 days for a 3‑day cycle). This usually indicates quality failures, machine breakdowns, or missing components, yet it escapes standard inventory audits.
Why is Weighted Average costing a challenge for aging reports?
If your ERP uses Weighted Average Cost, the system doesn’t inherently track which specific physical unit is left. To calculate accurate aging (physical flow), the IT architecture must overlay a FIFO (First-In, First-Out) assumption layer. This reconstructs the inventory stack to assume the oldest units were sold first, even if the financial costing is averaged.
Should all inventory aged over 360 days be scrapped?
No. Distinct handling is required for MRO (Maintenance, Repair, and Operations) items. Critical spare parts, like a main line motor, may sit for years (Insurance Stock) without being obsolete. These items must be segmented (e.g., via ABC-XYZ analysis) to prevent them from being erroneously flagged for scrapping or aggressive reduction.
What are the standard strategies to remediate high-aging inventory?
Once identified, aging stock should be addressed using a tiered disposition strategy:
Return to Vendor (RTV): Best for items 60 – 90 days old (requires high data agility).
Rework/Cannibalization: Disassembling finished goods to recover valuable raw materials.
Fire Sales: Implementing a discount curve (e.g., 10% off at 60 days, 25% at 90 days).
Scrapping: The last resort to stop tax/insurance costs on dead assets.
What is Predictive Obsolescence?
Predictive obsolescence moves beyond reporting what is old to predicting what will become old. Using AI/ML, the system analyzes current stock against forecasted demand to flag risks (e.g., Batch XYZ has an 85% probability of hitting the 180-day bucket). This allows procurement to cancel orders or sales to run promotions before the inventory becomes a liability.
×
Need Expert Guidance?
We've helped hundreds of businesses succeed. Get a free consultation to discuss your project requirements.
