Independent IFS Cloud practice · Supply Chain
Why “it’s in the system” isn’t the same as “it’s confirmed”
Key takeaways
- An order sitting in Released with no supplier confirmation is a promise you have not actually received — but on screen it looks exactly as settled as one that was.
- The pattern repeats across document types: unconfirmed purchase orders, sales orders without real coverage, receipts nobody reconciled against an invoice.
- The gap was never the data. The information sat in a projection the whole time, waiting for someone to ask. The gap was attention.
- The cost is not the late part or the missed shipment — it is the run of days you spent believing something was on its way when it never left.
“It’s in the system” is one of the more dangerous sentences in a supply chain, because it is almost always true and almost never the point. The order is in the system. The line is there, the date is there, the part number is there. What the sentence quietly skips is whether anyone on the other end — a supplier, a warehouse, an accounts team — has actually acted on it. A record existing and a record being confirmed are two different facts, and IFS Cloud, like most ERPs, will happily show you the first without ever forcing the second. This article is a companion piece to a deep look at one specific version of this problem, unconfirmed purchase orders. Here the goal is broader: to name the pattern itself, show it recurring across a few document types, and make the case that “assumed” and “confirmed” deserve to be treated as structurally different states, not shades of the same one.
1.Why do records get read as confirmed when they are only assumed?
A screen does not distinguish intent from acknowledgement. A purchase order in Released state looks identical whether the supplier accepted it an hour ago or never saw it at all. A sales order with a promised date looks identical whether the material behind it is actually allocated or whether the coverage check silently failed. A goods receipt sitting in the system looks identical whether it was ever reconciled against the matching invoice or is quietly waiting for someone to notice it was not. In every case the record exists, so the human eye reads “exists” as “settled,” and moves on to the next line.
This is not a data quality problem. The fields are correct; the state is accurately recorded. It is an attention problem wearing a data problem’s clothes — the record correctly shows an unconfirmed state, and the failure is that nobody built a mechanism to notice that specific state and treat it differently from a confirmed one. Left alone, the two categories blur together on every screen and every report until the day the difference becomes very visible, very fast.
2.What does the assumed-versus-confirmed gap actually cost?
The visible cost is always downstream — a late part, a missed shipment, a surprise invoice mismatch. The real cost sits earlier, in the days that passed while everyone believed the record was further along than it was:
- Lost lead time. Every day spent believing an unconfirmed order is moving is a day of real lead time you cannot get back once the truth surfaces.
- False coverage. A sales order that looks covered but is not means a promise made to a customer on the strength of a record, not a fact.
- Reconciliation debt. Receipts nobody matched to an invoice pile up quietly, then surface all at once at month-end as a scramble instead of a routine.
- Misplaced confidence. Reports built on top of assumed-confirmed records inherit the false certainty, so decisions made from them are only as good as an assumption nobody flagged.
The cost is not the late part. It is the run of days you spent believing something was on its way when it never left.
3.How do you tell assumed from confirmed inside IFS Cloud?
The information was never missing. Every one of these examples — purchase order confirmation, sales order coverage, receipt-to-invoice matching — lives in an IFS Cloud projection today, correct and current, the moment the state changes or fails to. What is missing is a standing question asked of that data: which of these records are sitting in a state that looks final but structurally is not?
The practical test is the same across document types. Pick the state that should be temporary — released-but-unconfirmed, promised-but-uncovered, received-but-unmatched — and ask how long a record is allowed to sit there before someone should be told. If the honest answer is “indefinitely, because nobody is watching that specific state,” you have found a record category that is assumed rather than confirmed, and a candidate for the same detection pattern the unconfirmed-PO article covers in detail.
4.Trusting the screen versus verifying the state
Trusting the screen means reading “exists in the system” as “confirmed,” and finding out otherwise only when a downstream deadline forces the question. Verifying the state means a rule stands between the record and the assumption, checking specifically for the unconfirmed case and surfacing it before it becomes a deadline problem.
| Trusting the screen | Verifying the state | |
|---|---|---|
| When the gap surfaces | At the deadline | Days or weeks earlier |
| What triggers a look | A downstream failure | A defined threshold on age or state |
| Who notices first | Whoever is affected by the failure | Whoever owns the record |
| Applies across document types | Inconsistently, ad hoc | Same pattern, every type |
| Cost of the gap | Paid in full, late | Paid small, early, or avoided |
The mechanics of building that verification — the threshold, the dry-run, the escalation — are the same regardless of which document type you start with. For purchase order confirmation specifically, the full breakdown, including the exact table structure and rollout steps, is covered in unconfirmed purchase orders in IFS.
5.How do you roll this out across more than one document type?
Treat this as a pattern to apply, not a single fix to deploy once. The same five steps work whether the record in question is a purchase order, a sales order, or a goods receipt.
- Name the assumed state. For each document type, define precisely what “looks settled but is not confirmed” means — released-but-unacknowledged, promised-but-uncovered, received-but-unmatched.
- Pick one document type first. Do not roll out the pattern everywhere at once. Start with the one costing the most, usually purchase order confirmation.
- Run detection in dry-run. Log what would have been flagged over a real period before anything is sent to anyone.
- Escalate to the record owner, not everyone. The buyer for POs, the planner for coverage, the AP clerk for receipts — keep ownership specific.
- Extend to the next document type. Once the first is proven and trusted, apply the same pattern to the next candidate on the list.
Every instance of this pattern is built inside the IFS Extensibility Framework — standard Custom Events, Workflows and PL/SQL — so extending it to a new document type is additive, not a rebuild, and stays update-safe as it grows.
6.Frequently asked questions
What is the difference between an assumed record and a confirmed one?
An assumed record exists in the system and looks settled — the fields are filled in and the state seems final — but no external party or downstream check has actually acknowledged it. A confirmed record has that acknowledgement recorded against it explicitly, so its state can be trusted rather than inferred.
Is this the same issue as unconfirmed purchase orders?
Unconfirmed purchase orders are the clearest single example of this pattern, and get their own full breakdown elsewhere on this site. This article is the broader version — the same gap shows up in sales order coverage, receipt-to-invoice matching and other document types, not only purchasing.
Which document type should we tackle first?
Start with whichever assumed-state gap is costing the most today, which for most distribution and manufacturing businesses is unconfirmed purchase orders. Prove the pattern there, then extend it to sales order coverage or receipt matching once the mechanics and trust are established.
Does this require a data cleanup project first?
No. The data is already correct — it accurately shows the unconfirmed state. What is missing is a rule that notices that specific state and tells someone, so this is a detection and escalation exercise, not a data quality project.
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 reading “in the system” as “confirmed”
If you suspect one or more document types in your operation carry this gap, a 30-minute call is enough to name the candidates and map which one to prove first — fixed price, dry-run before anything sends.