Independent IFS Cloud practice · Supply Chain
The quiet cost of “we will check tomorrow” — and the fix that does not rely on discipline
Key takeaways
- Deferred exception checks feel harmless one at a time — pushed to tomorrow because something louder needs attention today.
- The cost is invisible because it is distributed: a day here, a day there, across fifty orders and twelve months.
- This is not a discipline problem — the urgent always beats the important when the important is only a date in a system.
- Escalation logic that raises the important to urgent — visible, timed, owned — closes the gap without asking anyone to be more disciplined.
A delivery is due today. The buyer means to check it. Then a supplier calls about a different order and the call runs long. A quality issue on the shop floor needs someone right now. The check moves to tomorrow. Tomorrow, the same thing happens again: another fire, another reason, another day added to the queue. By Friday the delivery date was four days ago and nobody has looked at it. Nothing here counts as negligence. It is prioritisation working exactly as designed — the urgent has a person asking for it, and the important has only a date sitting quietly in IFS. The cost of this pattern is real, but it stays invisible, because it is distributed one day at a time across fifty orders and twelve months. This article covers why deferral happens, what it actually costs, how to see it in IFS Cloud, and how to fix it without asking anyone to be more disciplined than they already are.
1.Why does the check keep moving to tomorrow?
Deferral is not a character flaw. It is what happens when every open exception competes for the same finite attention, and the loudest one always wins. A supplier on the phone, a machine down, an angry email from a customer — each of these has a person attached to it, asking in real time. A purchase order sitting three days past its confirmation date has no one asking. It waits patiently in a queue, and patience is exactly what lets it slip.
The system reinforces the pattern. Most screens show the exception as a line in a list, not as an event demanding a response. There is no ring, no red banner, no name attached to the delay — just a date that quietly falls further behind the current one. Buyers who are conscientious about the loud problems are, by definition, the same people too busy to go looking for the quiet ones. The check does not fail because someone is careless. It fails because nothing in the workflow makes it compete on equal terms with whatever is happening right now.
2.What does a deferred check actually cost?
The arithmetic of deferral is deceptively small at the level of one order. A day slips, someone catches it a day late, the shipment still arrives, mostly on time. Multiply that by fifty open orders running at once and twelve months of the same daily trade-off, and the accumulated days of inaction stop looking small:
- Accumulated slippage. A day deferred here and a day deferred there add up to weeks of unmanaged lead time nobody planned for.
- Exceptions caught late. The check that would have caught a real problem on day one now catches it on day four, after the window to act cheaply has closed.
- Downstream compounding. A late catch on one order pushes into scheduling and transport booking, so one deferred check produces several delayed decisions.
- Service level erosion. No single delay looks catastrophic, but the pattern is exactly what turns a supply chain that absorbs disruption into one that amplifies it.
The cost never shows up as a line item called “deferred check.” It shows up as a late shipment, an expedite fee, or a customer call — three steps removed from the day someone meant to look and did not.
3.How do you see it in IFS Cloud?
IFS Cloud already has everything needed to see deferral, because every open exception carries an age. A purchase order past its confirmation date, a requisition waiting on approval, a delivery running late — each one has a created date and a current date, and the difference between them is the story. What is missing is not data; it is a place that turns “days since flagged” into something someone has to act on before it grows another day older.
Run the numbers today and the picture is usually more sobering than anyone expects — not the count of open exceptions, but the average age of the ones still open, and the tail of orders that have been sitting for a week or more. That tail is where the real cost lives, and it stays invisible in any dashboard that only reports the current snapshot rather than how long each item has been waiting.
4.Manual recall versus automated escalation
The fix is not a reminder to try harder tomorrow. It is closing the gap between how urgent things get attention and how important things get attention, using the same trigger-and-action pattern behind other Custom Events in IFS Cloud: watch the age of the exception, and the moment it crosses a threshold, turn it from a quiet line into an alert with a name attached.
| Manual recall | Automated escalation | |
|---|---|---|
| Runs when | Whenever something louder isn’t happening | On a schedule, every day |
| Coverage | Whatever is left after today’s fires | Every open exception, every buyer |
| Visibility | A date sitting in a list | A named alert with an age and an owner |
| Owner | Whoever happens to notice | Assigned by rule, every time |
| Fails when | Exactly the busy days it matters most | Never — it does not compete for attention, it demands it |
This does not remove judgement from the buyer. It removes the requirement that the buyer remember to apply that judgement on a day already full of louder problems.
5.How do you roll it out safely?
Roll this out the same way you would any exception rule: prove it before anyone depends on it.
- Agree the threshold. Decide how many days an exception can sit before it needs an escalation, and let it differ by order type — a late confirmation on a critical part deserves a shorter fuse than a routine reorder.
- Run in dry-run. Log what would have fired for two weeks without sending anything. The list usually reveals how many days are already being lost before anyone acts.
- Tune recipients and cadence. Decide who is alerted first — the buyer, then a supervisor after a further delay — and cap how often the same order can escalate.
- Pilot on one team. Turn it on for a single buyer or category, watch a full cycle, then widen it once the behaviour is proven.
- Review after a month. Check which thresholds fired too often, which never fired, and adjust — the rule should get quieter over time, not louder.
Because the whole thing runs on standard Custom Events and Workflows inside the IFS Extensibility Framework, there is no core modification for the next release to break. It is update-safe, and it avoids the upgrade tax entirely.
6.Frequently asked questions
Is deferring a check really a discipline problem?
No. It is what happens when every exception competes for the same attention and the loudest one wins by design. The fix is structural, not motivational: give the important item the same visibility the urgent one already has.
How is this different from just training buyers to check more often?
Training assumes the constraint is knowledge or willpower. The constraint is usually time and competing signals. An escalation rule changes what competes for attention instead of asking buyers to fight the same losing battle with more resolve.
Won’t an alert for every late check just add more noise?
Not if it is thresholded and capped. The rule fires once an exception crosses an agreed age, not on every minor delay, and a frequency cap stops the same order escalating repeatedly. Dry-run first shows you the real volume before anything goes live.
Is this update-safe?
Yes. It is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, so the next R1/R2 release has nothing here to break.
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 losing days to tomorrow
If deferred checks are quietly costing you days across dozens of open orders, a dry-run week will show you the real scale for the first time. On a 30-minute call I’ll map the escalation to your exception types — fixed price, dry-run before anything sends.
