Deutsch (Deutschland) 
Polski (PL) 
Independent IFS Cloud practice · Supply Chain
Unconfirmed purchase orders in IFS: the silent margin leak and the automated fix
Key takeaways
- An unconfirmed purchase order in IFS is an order the supplier may never have acknowledged, and you discover it only when the goods do not arrive.
- The cost is a slow leak: late deliveries, expediting fees, stock-outs and eroded margin, none of it labelled on the P&L.
- They pile up because confirmation is a manual chase, which is skipped when buyers are busy and invisible until it hurts.
- A Custom Event escalation (supplier email plus buyer alert after X days, with dry-run and a frequency cap) closes the gap and stays update-safe.
Every purchasing team has them: purchase orders raised, sent, and then sitting unacknowledged. On the screen they look like progress. In reality an unconfirmed purchase order in IFS is a promise nobody on the supplier side has agreed to. The order may be in a queue, misrouted, or simply unseen, and because the record shows the order exists, everyone assumes it is in motion. The truth surfaces at the worst moment: the line stops, the customer chases, and the buyer is now expediting at a premium to recover a week that was lost silently. This article covers why they accumulate, what they actually cost, how to detect them, and how to automate the fix without creating an alert storm.
1.Why do unconfirmed POs pile up?
Order confirmation is treated as the supplier’s job, so no one on your side owns the follow-up. When a supplier does not acknowledge, the omission is invisible: there is no error, no red screen, just a field that stays empty. Buyers who are meant to check it are the same people fighting today’s fires, so the check is the first thing dropped on a busy morning.
Volume makes it worse. A buyer managing hundreds of open lines cannot eyeball which handful never came back confirmed. Across sites and buyers the discipline varies, and there is no record of who checked what. The result is a slowly growing pool of orders that look live but may not be moving at all.
2.What does an unconfirmed PO actually cost?
The damage is downstream, which is why it is easy to miss the cause. A confirmation gap converts, step by step, into hard money:
- Late deliveries. A day lost to a silent order is a day added to lead time you did not plan for.
- Expediting. Recovering the lost time means premium freight and rush fees, so margin is spent to fix a check that took seconds.
- Stock-outs. Goods that arrive late arrive after you needed them, stopping a line or a shipment.
- Margin erosion. The expedite fee, the idle line and the unhappy customer all land on the same order, and none of it is labelled “unconfirmed PO”.
The leak is silent precisely because the cost never appears next to the cause. You see the freight bill; you do not see the missed confirmation that caused it.
3.How do you detect them in IFS?
The data is already in IFS. A purchase order carries its state and its dates, so an unconfirmed order is simply one that has passed a sensible age without a confirmation recorded against it. You can surface that today by filtering open purchase orders on state and order age - anything released but unconfirmed beyond, say, three to five days is your working list.
That manual query is a fine start and a poor system of record. It only helps on the days someone remembers to run it, it has no owner, and it leaves no audit trail of who was chased and when. Detection you have to remember to perform is detection that fails on the busy days, which are exactly the days it matters most.
4.Manual chase versus automated escalation
The automated approach uses a standard Custom Event: it watches for orders that stay unconfirmed past a threshold and fires an action (an email to the supplier and an alert to the buyer) without anyone running a report. It is the same trigger-and-action pattern behind every scenario in the SCM automations for IFS Cloud, and the mechanics are covered in Custom Events in IFS Cloud, explained.
| Manual chase | Automated escalation | |
|---|---|---|
| Runs when | Someone remembers | Continuously, on schedule |
| Coverage | Whatever the buyer had time for | Every order, every site |
| Owner | Unclear | Buyer, by rule |
| Audit trail | None | Logged action per order |
| Fails when | Busy, holidays, sick leave | Never sleeps |
Two controls keep the automation safe. A dry-run mode logs every message that would be sent, so you validate the list before a single email reaches a supplier. A frequency cap ensures one stuck order escalates once, then respects a cool-down, so it never reaches the same supplier ten times in a day. The same discipline protects related rules such as supplier price-change alerts.
5.How do you roll it out safely?
Do it in order, and let the data set the thresholds rather than a guess.
- Agree the threshold. Pick the day count and states that define “unconfirmed” for your suppliers. Different categories may warrant different limits.
- Run in dry-run. Let the event log its would-be actions for a test week. Read the list; it usually reveals the true scale for the first time.
- Tune recipients and cap. Confirm who is emailed and who is alerted, and set the frequency cap so escalations inform rather than nag.
- Go live on a subset. Enable for one buyer or site, watch a cycle, then widen once behaviour is proven.
- Review and adjust. After a month, check what fired and what changed, because thresholds are settings, not stone.
Because the whole thing is built inside the IFS Extensibility Framework (standard Custom Events, Workflows and PL/SQL), it is update-safe. There is no core modification for the next release to break, so you avoid the upgrade tax entirely.
6.Frequently asked questions
What counts as an unconfirmed purchase order in IFS?
It is a released order with no supplier confirmation recorded against it after a reasonable age, typically a few days. The order looks active on screen, but nobody on the supplier side has acknowledged it, so there is no guarantee it is being worked.
How many days should trigger an escalation?
There is no universal number. Three to five days suits many suppliers, but critical or long-lead categories may warrant tighter limits. The dry-run week shows your real distribution, so you set the threshold on evidence rather than a guess.
Will suppliers be annoyed by automated emails?
Not if it is capped. The frequency cap means each stuck order escalates once and then waits out a cool-down, so no supplier is chased repeatedly. Most suppliers welcome a clear, timely nudge over a frantic call once the goods are already late.
Is this update-safe?
Yes. The escalation is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, with no core modification. Nothing here is the kind of customisation that the next R1/R2 release quietly breaks.
7.About the author
Dariusz Myśliwiec: 18 years of hands-on IFS practice (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Independent practice based in Kraków, delivered remotely across Europe and globally. You talk to the consultant who builds it, not a sales layer.
Selected clients: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.
IFS is a registered trademark of IFS AB; this practice is not affiliated with IFS AB.
Stop the silent leak
If you suspect unconfirmed orders are costing you and cannot yet prove it, a dry-run week will show you the scale for the first time. On a 30-minute fit call I’ll map the escalation to your suppliers, with a fixed price and a dry-run before anything sends.
