---
title: "Change of Customer Order after confirmation"
date: 2026-09-07
description: "A confirmed sales order gets a quantity or date amended, but the promise made to the customer is never re-checked. The gap surfaces at delivery."
author: "Dariusz Myśliwiec"
intro_image: "https://ifs-erp.consulting/images/articles/sales-order-changed-after-confirmation-ifs-cloud-en-a6790e31.webp"
fulltext_image: "https://ifs-erp.consulting/images/articles/sales-order-changed-after-confirmation-ifs-cloud-en-a6790e31.webp"
categories:
  - name: "How IFS Cloud ERP Transforms Business Operations Supply Chain AI and Legacy System Migration"
    url: "https://ifs-erp.consulting/ifs-cloud.md"
tags:
  - name: "IFS Cloud"
    url: "https://ifs-erp.consulting/tags/ifs-cloud.md"
---

# Change of Customer Order after confirmation

![Change of Customer Order after confirmation](https://ifs-erp.consulting/images/articles/sales-order-changed-after-confirmation-ifs-cloud-en-a6790e31.webp)

Independent IFS Cloud practice · Sales

 
## The order you confirmed, and the change nobody re-promised

 You confirmed the order to the customer: this quantity, this date. Later someone edits the line. A quantity moves, a date slips, a part is swapped. IFS Cloud accepts the change, because editing a confirmed order is allowed and often necessary. What it does not do is mark that the promise the customer is holding has quietly stopped matching the order in the system. The customer waits for what they were told. The warehouse ships what the record now says. The difference between the two surfaces at delivery, when it is too late to have the conversation that should have happened when the line changed.

 **Key takeaways**

 
- A confirmed sales order carries a promise. When a line is amended after confirmation, IFS Cloud updates the order but does not signal that the confirmed promise and the current order have diverged.
- This is not an [unconfirmed sales order](https://ifs-erp.consulting/ifs-cloud/unconfirmed-sales-orders-ifs-cloud). There the order was never confirmed. Here it was, and then it changed underneath the confirmation.
- It is also different from a [promise gap at order entry](https://ifs-erp.consulting/ifs-cloud/high-fidelity-discrete-order-promising). That gap is visible when the order is taken. This one opens up later, after everyone has moved on.
- Left unseen, it becomes a [late or wrong delivery](https://www.ifs-erp.com/en/blog/metric-that-lies-on-time-delivery-ifs-cloud) the customer never agreed to, and it reads as a service failure rather than a change that was never communicated.
- The confirmation and the current line values both live in IFS Cloud, so a read-only monitor can compare them and flag confirmed orders whose key terms changed after the promise was given.

  ## 1.Why a confirmed order can change and nobody tells the customer

 A confirmation is a moment: at that point the order said one thing and the customer was told it. After that the order is a live record that many hands can touch. Planning reschedules a line to match supply. A rep adjusts a quantity after a call. A part is substituted. Each edit is a reasonable thing to do, and IFS Cloud is right to allow it. None of these edits carries an obligation to go back to the customer, because the system does not treat the edit as breaking a promise. It just treats it as an update.

 So the order and the promise drift apart. The record is current and correct. The customer’s understanding is current and correct as of the confirmation. Both are internally consistent, and neither knows the other has moved. Nothing sits between them asking whether this particular change is one the customer needs to hear about.

 The silent change is not a broken process. It is a normal edit that happened to alter a promise, with no step that separates the edits worth a phone call from the ones that do not matter.

  ## 2.Not every change to a confirmed order needs a call. These do.

 Amending a confirmed order is routine. The value is in separating the harmless edits from the ones that changed what the customer is expecting.

 
| What you see | What it usually points to |
| --- | --- |
| Confirmed delivery date moved later after confirmation | A promise the customer still holds at the old date, now unmet unless someone tells them. |
| Confirmed quantity reduced or a line removed after confirmation | A short shipment against what was agreed, likely to surface as a complaint or a query at delivery. |
| Part or item substituted on a confirmed line | A different product than the one confirmed, which the customer may or may not accept. |
| Repeated post-confirmation edits on orders to the same customer | A pattern that erodes trust in your confirmations, not a one-off adjustment. |

 The first row is the quiet one. The date moved for a good internal reason, the order is accurate, and the customer is still planning around the date you confirmed. A rep looking at the order sees a valid delivery date and no reason to act. Compare the confirmed date to the current one, and the broken promise is right there to be fixed with a call.

  ## 3.Comparing the confirmed promise to the current order

 The confirmed values and the current line values are both available through standard OData projections, so they can be read without touching a record. Detection compares what was confirmed to what the order says now and looks for two things:

 
1. **Key terms that changed after confirmation** - where the date, quantity or item on a confirmed line no longer matches what was promised, so the orders that moved under their confirmation surface as a short list.
2. **Whether the customer was told** - flagging the changed orders so the account owner can decide which need a call, rather than assuming an edit and a communication are the same event.

 Because it is a [read-only monitoring pattern](https://www.ifs-erp.com/en/blog/read-only-odata-monitoring-ifs-cloud), it runs beside sales and writes nothing back to IFS. It adds no object inside the client system, and a standard R1 or R2 release does not touch it, because it only reads standard projections. It hands the rep a short list of confirmed orders that changed, and the call on which customer needs to hear about it stays with the person who owns the account.

  ## 4.Rolling it out without noise

 - **Start with your key accounts** - a silently changed promise costs the most where the relationship matters most, so watch those first.
- **Dry-run first** - log which changed orders would have been flagged across a full period before a single alert reaches a rep.
- **Two lenses** - one for dates that slipped after confirmation, one for quantities or items that changed.
- **Read only, no footprint** - standard OData reads, nothing written back, no new object inside IFS Cloud.

 [See the SCM Automation Pack](https://www.ifs-erp.com/en/applications/scm-automation-pack) [Book a 30-minute fit call](https://ifs-erp.consulting/contact)

  ## 5.Frequently asked questions

 Does IFS Cloud not track that a confirmed order changed? It records the current state of the order and allows confirmed lines to be edited, which is by design. What it does not do on its own is compare the current line to what was confirmed and raise the ones that diverged, or distinguish an edit from a communication to the customer. That comparison, and the reminder that the customer may not know, is the gap this monitoring fills.

   How is this different from a promise gap at order entry? A promise gap at entry is visible the moment the order is taken, when the wanted date and the planned date do not match. This is later and quieter: the order was confirmed cleanly, everyone moved on, and only afterwards did an edit move a term the customer was already holding. It needs the confirmed value checked against the current one, not a check at entry.

   Are you saying confirmed orders should never be changed? No. Changing a confirmed order is often the right thing to do when supply or the customer's needs move. The aim is to make sure a change that alters the promise gets seen, so the account owner can decide whether the customer needs to be told, rather than the change slipping through silently and surfacing as a delivery the customer did not expect.

   Does this monitoring write anything to IFS Cloud? No. The confirmed values and the current line values are read through standard 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 of hands-on work 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.

  ## Keep the promise and the order in step

 Tell me which accounts feel it most when a confirmed order changes without a call. On a 30-minute fit call I’ll show you how the SCM Automation Pack reads your confirmed values and current lines, flags the orders whose promise changed after confirmation, and does it read-only, with a dry-run period before anything reaches a rep.

 [Book a 30-minute fit call](https://ifs-erp.consulting/contact)