Independent IFS Cloud practice · Supply Chain
Why “we’ll catch it at month-end” is too late and what to do instead
Key takeaways
- The cost of an exception is not fixed — it compounds every day between when the record changes state and when a human learns it changed.
- A monthly review catches everything eventually, but by month-end the small problem from day one has usually become several bigger ones.
- This is not about working harder or reviewing more often. It is about shrinking the gap between the state change and the alert.
- A same-day Custom Event on the two or three exception types that hurt most removes the need to catch anything at month-end at all.
A delivery date passes on the 3rd. The buyer is tied up today, the material isn't critical, and we've heard this from the operations team: “we will catch it at month-end.” Month-end arrives. The exception report shows twelve late deliveries. Three are now critical. One has already stopped a production line. The buyer spends two days firefighting instead of the one hour it would have taken to check on the 4th. This is not a story about a lazy review process — the monthly report did exactly what it was built to do. It is a story about latency: the distance between a record changing state in IFS Cloud and a human finding out about it. This article covers why that distance compounds, how to see the real cost of it, and how to shrink it without adding more meetings or more reports.
1.Why does “we’ll catch it at month-end” persist?
Monthly review is inherited from an era of batch reporting, when a report was expensive to run and the finance calendar was the only rhythm a business had. It survives because it is a real, working cadence — it does catch everything eventually — and because nobody has had to prove, with a number, that the delay itself has a cost.
The judgement that a given exception is “not critical today” is made in the moment, with no evidence about how it will look in three weeks. Nobody owns the daily exception list, because it is treated as someone else’s report rather than a live risk. So it waits, along with everything else that seemed fine on the day it was postponed.
2.What does detection latency actually cost?
The cost of catching an exception on day one is not the same as catching it on day twenty-eight. Every day it sits unaddressed, the cost compounds along several dimensions at once.
- Shrinking recovery window. The supplier or the buyer has less time to fix the problem the longer it sits unnoticed — a same-day nudge and a three-week silence are not the same conversation.
- Rising production risk. A late delivery that was harmless in week one can become the thing that stops a line by week four, once slack in the schedule runs out.
- Firefighting hours. A one-hour check on day one becomes two days of expediting, escalation calls and rework once the exception has multiplied into several related ones.
- Eroding customer patience. A customer told about a delay early tolerates it far better than one who finds out only when their own delivery is already late.
A day-one fix costs an email. A month-end fix costs two days, a stopped line, and a harder conversation with the customer.
3.How do you shrink the gap in IFS Cloud?
Every exception that shows up on a month-end report already existed as a state change in IFS Cloud on the day it happened — a delivery date passed, an order stayed unconfirmed, a stock level fell below minimum. The report does not create that information; it simply waits a month to surface it. The same state change can trigger a Custom Event the day it occurs, which means the report and the alert are reading identical data, just at very different latencies.
The practical question is not whether to build same-day detection for everything — that would recreate the alert-storm problem in a different shape. It is choosing the two or three exception types where the cost curve is steepest, and closing the gap there first, following the same trigger-and-action pattern used across the SCM automations for IFS Cloud.
4.Periodic review versus real-time exception detection
Both approaches surface the same underlying facts. They differ in exactly one dimension — and that dimension is where the cost lives.
| Periodic (month-end) review | Real-time exception detection | |
|---|---|---|
| Detection lag | Up to one full month | Same day the state changes |
| Cost per exception | Compounded by delay | Closer to the base cost |
| Who is affected | Whoever inherits the backlog | The person who can still act on it |
| Scalability | Gets harder as volume grows | Runs the same regardless of volume |
| Trust in the number | Reactive, arrives as a surprise | Expected, arrives while fixable |
Keep the month-end report for what it is genuinely good at: a trend view and a sanity check. Do not ask it to be the thing that catches a problem while it is still cheap to fix — that job belongs to the exception the moment it happens, exactly as covered for one specific case in unconfirmed purchase orders in IFS.
5.How do you roll this out safely?
Shrinking detection latency is not a big-bang project. It is picking the highest -cost exceptions first and proving the model before it spreads.
- Rank your exceptions by cost curve. Ask which two or three exception types get measurably worse the longer they sit — those are the ones worth same-day detection first.
- Define the trigger condition precisely. Agree exactly what state change counts, so the alert fires on the same event the month-end report would have flagged, just earlier.
- Run a dry-run digest. Log what would have fired for two to three weeks and compare it against what actually surfaced at the last month-end — the overlap validates the rule.
- Tune for noise before going live. Adjust thresholds and recipients so each alert earns attention rather than getting filtered out on reflex.
- Expand coverage gradually. Add the next exception type only once the first is trusted and acted on, not ignored.
Because each rule is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework, none of it is core modification — it stays update-safe and avoids the upgrade tax while quietly making the month-end report shorter every cycle.
6.Frequently asked questions
Doesn’t same-day detection just create alert fatigue?
Only if it is built for every exception at once. Starting with the two or three highest-cost types, and tuning thresholds during a dry-run period, keeps volume low enough that each alert still gets read and acted on.
Does this replace the month-end report?
No. The month-end report stays useful as a trend view and a sanity check on totals. Real-time detection takes over the job of catching individual exceptions while they are still cheap to fix — a job the monthly cadence was never fast enough to do.
How do we choose which exceptions to automate first?
Look at last month’s exception report and ask which items were mild on day one and severe by month-end. Those with the steepest cost curve over time give you the best return for closing the detection gap first.
Is this update-safe?
Yes. Each rule is built with standard Custom Events, Workflows and PL/SQL inside the IFS Extensibility Framework — no core modification, so nothing here is at risk from the next R1/R2 release.
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 paying the month-end price
If your team is still catching exceptions once a month, the cost of that delay is already visible in last month’s firefighting hours. On a 30-minute call I’ll help you rank your exceptions and map the two worth fixing first — fixed price, dry-run before anything goes live.