Deutsch (Deutschland) 
Polski (PL) 
Independent IFS Cloud practice · Procurement
The order you placed, and the confirmation that quietly changed it
You raise a purchase order for a batch of parts, due mid-month, at the agreed rate. The supplier sends back a confirmation for a smaller quantity, a later date, and a slightly higher price. The line is recorded as confirmed, because a confirmation did arrive. Depending on your setup, nothing compares the confirmed terms with the ordered ones, so the planner sees a confirmed line and trusts it. The gap surfaces at receiving, on the invoice, or when the customer waiting on those parts calls to ask where they are.
Key takeaways
- A confirmation makes a purchase order line look settled. Depending on your setup, IFS Cloud may not check that the confirmed quantity, price and date match what you ordered, so a line can be confirmed and different from the order at the same time.
- The SCM Automation Pack’s existing rule covers purchase orders the supplier has not confirmed at all. A confirmation that disagrees with the order is a different case, and a rule for it would be an additional one built to order.
- A delivery date change you make inside IFS Cloud is yours and deliberate. A confirmation mismatch is the supplier moving the terms, recorded as if you agreed.
- A confirmed price above the order price reaches the invoice unless someone compares it with the order first.
- The ordered values and the confirmed values are recorded in IFS Cloud (worth confirming the exact projections in your environment), so a read-only monitor can compare them on the first scan after a confirmation arrives, not weeks later at goods receipt.
1.Why a confirmed line can still disagree with your order
A supplier confirmation tells the buyer the order was accepted. It captures the quantity, price and dates the supplier is committing to. Those values can differ from the order: a partial commitment, a revised lead time, a price uplift the supplier applied on their side, a minimum order quantity rounded up. Each of these is a legitimate thing for a supplier to send back.
Depending on your setup, IFS Cloud keeps the supplier’s confirmed values separately from the ordered ones (for example through supplier order responses) and marks the line confirmed; whether both sets are kept in your environment is worth checking. The rest of the process reads that status: planning can treat the confirmed date as the date, and the person approving the receipt later can assume the terms were agreed. Whether anyone in that chain is asked to compare the confirmation with the order depends on your setup and is worth checking.
Where no comparison exists, nothing sets the ordered quantity, price and date beside the confirmed ones and asks whether the difference is small enough to accept or large enough to renegotiate.
2.Which confirmation differences cost money or break a promise
A confirmation that shifts a date by a day is noise. The review separates the shifts that cost money or break a promise from the ones nobody needs to act on.
| What the confirmation shows | What it can point to |
|---|---|
| A confirmed quantity below the ordered quantity | A short commitment that leaves demand uncovered, while the line still reads as confirmed. |
| A confirmed price above the order price | A supplier-side uplift accepted by default, which becomes an overspend at invoice. |
| A confirmed delivery date past the need date | A promise to the customer or the shop floor that is already broken, before a single part has moved. |
| Confirmations with different terms from one supplier, repeatedly | A supplier who confirms different terms as a habit, and a process that never compares them with the order. |
A slipped date sits inside a status that reads as confirmed, so the planner has no reason to look again. A list of one week of confirmations shows the pattern that a buyer clearing an inbox one message at a time does not see.
3.Comparing ordered against confirmed, before goods receipt
The ordered values and the confirmed values are recorded in IFS Cloud and can be read through OData projections without touching a record (the exact projections are worth confirming in your environment). Detection runs on a schedule, with the first scan after you have set the tolerances, reads confirmed purchase order lines, and checks three things:
- Confirmed quantity against ordered quantity - where the supplier committed to less than was asked, so the shortfall is listed while there is still time to source it.
- Confirmed price against order price - where the confirmation carries an uplift, listed before the invoice locks it in.
- Confirmed date against need date - where the promise moved past the date the parts are needed, listed while the order can still be chased or resequenced.
Because it is a read-only monitoring pattern, it runs beside purchasing and writes nothing back to IFS. It adds no object inside the client system, so a release update leaves nothing of ours in your IFS to retest. Before each release I check that the standard projections it reads still match, as part of the subscription. The existing rule for unconfirmed purchase orders lists orders with no confirmation; this check would be an additional rule for confirmations that arrived with different terms. It gives the buyer a list, and the call on whether to accept or push back stays with the buyer.
4.Rolling it out without noise
- Set a tolerance - a day or a rounding penny is not a flag. Watch the shifts that cross a threshold you set.
- Dry-run first - in the first week the rule only logs what it would have listed, and nothing reaches a buyer.
- Route by type - send quantity, price and date differences to the person who acts on each, for example planning for dates and the buyer for prices.
- Read only, no footprint - standard OData reads, nothing written back, no new object inside IFS Cloud.
Related reading
5.Frequently asked questions
Does IFS Cloud warn me when a confirmation differs from the order?
Whether IFS Cloud raises a warning when a supplier confirmation differs from the order depends on your setup, which is worth checking. IFS Cloud records the confirmed values and marks the line confirmed. A supplier may confirm a different quantity, price or date, so the confirmation is valid input, and where no comparison is configured nobody is prompted to judge whether the difference is acceptable.
What does the existing rule for unconfirmed purchase orders cover?
The SCM Automation Pack’s existing rule for unconfirmed purchase orders lists purchase order lines still in Released state, with no supplier confirmation recorded, a set number of days after release. A confirmation that arrives with a different quantity, price or date is outside that rule, because the acceptance is there. Listing it would be an additional rule built to order.
Is a small difference worth listing?
No. A day of slippage or a rounding difference is noise, and a tolerance exists to leave it out. Detection lists the confirmations that cross a threshold you choose, so a buyer sees the short commitment, the price uplift, or the date past the need date, and nothing else.
Does this monitoring write anything to IFS Cloud?
No. The ordered values and the confirmed values are read through OData projections and compared outside IFS. Nothing is written back, so there is no upgrade footprint and no new object inside the client system.
6.About the author
Dariusz Myśliwiec brings 18 years hands-on with IFS (Apps 7.5–10 and IFS Cloud). IFS Certified Associate Consultant. PRINCE2® 7. Based in Kraków, delivering remotely across Europe and globally as an independent practice, so you talk to the consultant who builds it.
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 trusting confirmations you never checked
Tell me which suppliers change the terms and where a slipped date hurts. On a 30-minute fit call we check whether a rule that compares ordered and confirmed values fits your data. The SCM Automation Pack runs three rules today (unconfirmed purchase orders, late deliveries, stock below minimum), so a check for confirmations that disagree with the order would be an additional rule built to order, with a dry-run week before anything reaches a buyer.
