Independent IFS Cloud practice · Data Integrity
The exception that was not an exception: why stale status data erodes trust in IFS Cloud
Key takeaways
- A false exception in IFS Cloud is a system state that never caught up with reality — a purchase order confirmed by phone, still sitting in Released state months later.
- The half day spent investigating it is not the real cost; the real cost is people quietly learning not to trust what the system says.
- It happens because closing the loop back into IFS after a verbal confirmation is a chore nobody owns — the phone call feels like the fix.
- A reconciliation rule that compares order state against downstream events — a receipt, an invoice match — catches the mismatch before a report ever raises a false alarm.
A purchase order sits unconfirmed for five days. The buyer chases it, the supplier confirms by phone, and the buyer moves on to the next fire. In IFS, nothing changes: the order stays in Released state, because a phone call is not a system update. The goods ship. The goods arrive. The receipt posts against the order. Three months later, someone runs the standing report on unconfirmed purchase orders, and this one is still on the list. Someone spends half a day chasing a shipment that already happened — pulls up the order, calls the supplier, and is told, reasonably, “we confirmed that months ago.” Both sides are right, and neither side’s data agrees with the other. This is not a purchasing failure. It is a reconciliation failure — a gap between what happened in the real world and what IFS was told happened — and it is far more common, and far more corrosive, than any single missed order.
1.Why does status data fall this far behind reality?
Confirmation happens wherever it is fastest, and the phone is faster than the system. A buyer chasing a supplier wants an answer, not a data-entry task, so the call closes the operational question and stops there. Updating IFS afterwards is a second step with no visible reward — the order already feels handled, so it drops to the bottom of the list and, more often than anyone admits, never gets done at all.
The gap widens because nothing forces it shut. IFS has no way to know a phone call happened unless someone tells it, and there is no prompt, no reminder, no consequence for leaving the status untouched. The order simply sits, technically wrong, looking correct to everyone except the one report that eventually flags it — usually long after the context that would have explained it is gone.
2.What does a false exception actually cost?
The half day spent chasing a shipment that already arrived is real money, but it is the smallest part of the bill. The larger cost builds quietly over months, as a pattern rather than a single incident:
- Wasted investigation time. Every false positive is a buyer or planner stopping real work to re-verify something that was already settled.
- Repeated false alarms. A status that never gets corrected keeps re-appearing on the same report, so the same non-problem gets investigated more than once.
- Eroding trust. Enough false alarms and people stop believing the report at all — including on the days it is right.
- Shadow records. People start keeping their own tracking outside IFS — inboxes, spreadsheets, sticky notes — because that is what they have learned to trust instead.
An exception that is not really an exception is worse than a missed one — it trains people to stop reading the next alert, including the one that matters.
3.How do you tell a real exception from a false one?
The evidence that a status is stale is usually already sitting in IFS, just not joined together. A purchase order flagged as unconfirmed that also has a receipt posted against it, a goods issue recorded downstream, or an invoice already matched, is not an open question — it is a data mismatch wearing an exception’s clothes. The report only has to compare the two facts to know the difference.
Building that cross-check turns a noisy list into a short, credible one: orders that are genuinely unconfirmed and show no downstream activity go to the top as real risk. Orders that are unconfirmed on paper but already moving get quietly closed out or flagged for a status correction instead of a phone call. The report stops crying wolf, and the people reading it start trusting it again.
4.Manual reconciliation versus automatic sync
Left alone, closing the gap between a verbal confirmation and the system record depends entirely on someone remembering to go back and fix it. A systematic rule checks the two facts against each other every time, without waiting for a report to be run or a person to notice.
| Manual | Systematic | |
|---|---|---|
| Detects the mismatch | Only if someone happens to notice | Every time the two data points disagree |
| Runs | When the report is remembered | Continuously, on schedule |
| Owner | Whoever answers the phone | The rule, by definition |
| Audit trail | None | Logged reconciliation event |
| Fails when | Busy, new starter, unaware | Never sleeps |
The point is not to remove the phone call — a verbal confirmation is often the fastest, most reasonable way to resolve a stuck order. The point is to stop treating the system update as optional. Once the two facts are checked automatically, the phone call and the record agree within minutes instead of quarters.
5.How do you roll it out safely?
Start narrow, prove it on real orders, and only then widen the scope.
- Agree the signal. Decide which downstream events count as evidence of confirmation — a receipt, a goods issue, an invoice match — for your business.
- Run in dry-run. Compare order state against those events for a test period and log the mismatches without changing anything yet.
- Decide the action. Choose whether a confirmed mismatch auto-corrects the status or simply flags it for a person to confirm.
- Pilot on one buying group. Watch a full cycle before extending the rule to every site and category.
- Review after a month. Check how many false exceptions it removed, and tune the signal list as new patterns show up.
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 is a false exception in IFS Cloud?
It is a record flagged by a report or rule as a problem — such as an unconfirmed purchase order — when the underlying situation was already resolved outside the system, typically by a phone call or email that never made it back into IFS as a status update.
Why not just tell people to update the status after every call?
Instructions get followed on the calm days and dropped on the busy ones, which is exactly when the gap opens. A reconciliation rule works regardless of how busy the buyer is, because it checks the evidence rather than relying on someone remembering an extra step.
Does auto-correcting the status risk hiding a real problem?
Not if the signal is strict. The rule only closes the gap when there is clear downstream evidence — a posted receipt or a matched invoice — not on a guess. Anything short of that evidence is flagged for a person, not silently changed.
Is this update-safe?
Yes. The reconciliation rule is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — 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 — 25+ years in ERP and supply chain, 17+ on IFS (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 training people to ignore the report
If your exception reports are quietly losing credibility, a dry-run reconciliation will show you how many of the “open” items are already closed in reality. On a 30-minute call I’ll map the signal to your data — fixed price, dry-run before anything changes.
