# Change order vs addendum: how to record a mid-contract change in Salesforce

https://salesbond.app/blog/change-order-addendum-salesforce/
Published: 2026-10-20 · Updated: 2026-10-20

When a customer changes a signed deal (a change order, an addendum or an amendment), the Salesforce question is simple: does the change add revenue that was not in the signed deal? If it does, open a new Opportunity linked to the same account and contract. If it only corrects what you already sold (a quantity, a price, a delivery date), record it on the original Opportunity and keep the original Amount in a separate field so the history stays readable. If it removes revenue, it is a scope-down on the original, and if it removes everything, it is a cancellation, not a change. That is the whole rule. The rest of this article is about why Salesforce makes the first option safer than it looks and the second one riskier than it looks.

## Change order, addendum, amendment: what the words mean on the sales side

A **change order** changes what gets delivered under the agreement the customer already signed. An **addendum** adds something that was not in the agreement, usually with new money. An **amendment** changes the terms of the agreement itself, such as price, term length or payment schedule.

Lawyers draw their own line between an addendum and an amendment, and this article does not try to redraw it. For a sales team the useful question is narrower: after the change, does the original Opportunity still describe what we sold?

A change order looks like this. Ten licences become twelve. The onboarding moves from March to May. The agreement is the same; the numbers inside it move.

An addendum is a second module, a training package, a new site. It usually comes with a new signature, and the original scope stays as it was.

An amendment sells nothing new, but what the customer owes is now different from what they signed.

So stop arguing about the label and sort by effect. Same scope, moved numbers: change order. New scope: addendum. Same scope, new terms: amendment. Two of the three live on the original Opportunity. One deserves its own.

## The decision rule: edit, add a line, or open a new one

Ask the questions in this order.

1. **Does it add revenue that was not in the signed deal?** Open a new Opportunity. Set `Type` to Existing Business (Salesforce ships the field with example values “Existing Business or New Business”, per the [Opportunity object reference](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunity.htm) ), and point its `ContractId` lookup at the same contract; the same page describes that field as the “ID of the contract that’s associated with this opportunity.” Give it its own close date and its own stage. The original stays Closed Won with the number the customer signed.
2. **Does it only correct what was already sold?** Stay on the original. Change the line item, not the Amount field (the next section explains why), fill in the custom fields we recommend in the audit section below, and attach the customer’s written confirmation.
3. **Does it take revenue away?** Same as point 2, with a scope-down reason. If the customer walks away from the whole thing, that is a different record and a different report; we covered it in [how to record a cancelled order after Won](https://salesbond.app/blog/cancelled-order-after-won-pipedrive/), and the logic transfers from Pipedrive to Salesforce without much translation.

![Decision tree: a change to a signed deal either adds revenue (new linked Opportunity), corrects what was sold (edit the original) or removes revenue.](https://salesbond.app/wp-content/uploads/2026/10/change-order-addendum-salesforce-2.png)

The common advice is never to touch a Closed Won Opportunity. We break that rule for corrections on purpose: a correction is not a new sale, so it should not show up as one, and on deals with products Salesforce recalculates Amount from the lines anyway. New scope is different. It is a sale, so it gets its own record.

If your org runs Salesforce CPQ, the platform already leans this way. Clicking Amend on a contract creates an amendment quote and, in the same step, an amendment opportunity (Trailhead walks through it in [Contract Amendments with Salesforce CPQ](https://trailhead.salesforce.com/content/learn/modules/contract-amendments-with-salesforce-cpq/change-an-existing-contract)). That is the same path as question 1: a new linked deal, with the original left alone.

Two neighbours of this rule are easy to confuse with it. A repeat order is not a change to a signed deal, it is a new order, and it gets [one deal per order](https://salesbond.app/blog/repeat-orders-pipedrive-new-deal-per-order/) so it stays out of your win rate. An add-on that should end on the same renewal date as the main subscription is a [co-terming question](https://salesbond.app/blog/co-terming-add-ons-pipedrive/), which is about dates and renewals, not about whether the original Opportunity changes. This article is about the third thing: the signed deal itself is different now.

## What happens to Amount, close date and forecast

We do not edit Amount on a Won opportunity, because Salesforce often does not let you, and when it does, it quietly rewrites a closed period.

Start with Amount. The object reference says: “For opportunities with products, the amount is the sum of the related products. Any attempt to update this field, if the record has products, will be ignored. The update call will not be rejected, and other fields will be updated as specified, but the Amount will be unchanged” ( [Opportunity](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunity.htm)). So if your team uses products a change order is a line-item edit: `Quantity`, `UnitPrice`, `TotalPrice` or `Discount` on the [OpportunityLineItem](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunitylineitem.htm). One catch from that same page: “If this object has a revenue schedule, the Quantity and TotalPrice fields can’t be updated.” A scope change on a scheduled product means redoing the schedule, which is one more reason to keep the original line intact and add a new one where you can.

Expected revenue follows automatically. `ExpectedRevenue` is a “Read-only field that is equal to the product of the opportunity Amount field and the Probability” ( [Opportunity](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunity.htm)). Change Amount on a Won deal and the expected revenue for that close date changes with it. Nobody gets a notification. The quarter you reported last month now adds up to a different number.

Close date is the field people reach for when delivery moves. It is the wrong one. `CloseDate` is “Required. Date when the opportunity is expected to close” (same page): the date of the agreement, not the date of delivery. A line item has a `ServiceDate`, “Date when the product revenue will be recognized and the product quantity will be shipped” ( [OpportunityLineItem](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunitylineitem.htm)), and products with schedules carry their own dates on the [OpportunityLineItemSchedule](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunitylineitemschedule.htm). Moving delivery is a service-date or schedule change. The close date stays where the signature was.

The forecast is what makes the new-Opportunity option worth the extra record. `ForecastCategory` “is implied, but not directly controlled, by the StageName field,” and the same page says you can override it ( [Opportunity](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunity.htm)). A new linked Opportunity for the added scope sits in an open stage until it is signed, with its own close date, and shows up in the forecast for the period it belongs to. Added scope typed into a Won deal skips the forecast entirely and lands as closed revenue on a date in the past.

| Change | Where it lives | Amount | Close date | Forecast effect |
| --- | --- | --- | --- | --- |
| New scope added | New Opportunity, same `ContractId` | New money only | Its own | Enters as open pipeline, closes in its own period |
| Quantity or price corrected | Original, line item | Recalculated from lines | Unchanged | Closed revenue for that period changes; record the old value |
| Delivery moved | Original, `ServiceDate` or schedule | Unchanged | Unchanged | None on close; revenue timing moves |
| Scope removed | Original, line item | Down | Unchanged | Closed revenue goes down; record the reason |

## Who approves and who re-signs

Does a change order have to be signed? If it changes price or term, yes: it goes back through whoever approved the original and the customer signs again. If it only moves a date or a quantity inside the agreed scope, written confirmation from the customer is enough.

Salesforce holds that split on the [Contract object](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_contract.htm), whose `Status` runs from Draft through approval to Activated. Once a contract is activated, the reference says, “your client application can’t change its status.” That is why a price or term amendment belongs on the contract: write the new terms into `SpecialTerms` (“Special terms that apply to the contract”) or a new contract record, depending on how your legal team handles amendments. A change inside the scope stays on the Opportunity, with the confirmation attached and the reason in a field the manager can report on.

Without a signed scope to compare against, “is this inside the deal?” has no answer. That is the case for [agreeing a statement of work before the price goes out](https://salesbond.app/blog/statement-of-work-pipedrive-deals/), and it applies to Salesforce teams as much as Pipedrive ones.

## Audit trail: keeping the original value visible

Salesforce keeps history. It does not keep it where your reports look.

The [OpportunityHistory](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunityhistory.htm) object “represents the stage history of an opportunity” and includes `PrevAmount` and `PrevCloseDate`, the values before the update, with a note that records created before Winter ’21 hold null there. The [OpportunityFieldHistory](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_opportunityfieldhistory.htm) object goes wider: “Use this object to identify changes to any fields on an Opportunity,” with `OldValue` and `NewValue` per change. Both are useful when someone asks what happened to one deal. Neither helps when a manager opens the Closed Won report, because that report shows the value as it is now, not as it was signed.

Our recommendation is to add three custom fields to the Opportunity. They are not standard Salesforce fields; you create them, and you treat them as mandatory the moment a change is recorded.

`Original Amount` (custom currency field). Filled once, when the deal goes Closed Won, and never edited. On a changed deal, this is the number the customer signed and `Amount` is the number after the change. A report with both columns shows the drift at a glance.

`Change Reason` (custom picklist). Scope up, scope down, price correction, date shift. Not free text, because free text cannot be grouped.

`Change Date` (custom date field). When the customer confirmed the change, not when the rep got round to the CRM.

The order matters: fill the three fields first, then edit the line. Do it the other way round and `Original Amount` gets the new number, which defeats the the point.

A disclosure, since this is where a tool enters the picture. We build SalesBond, a sales management layer on top of the CRM a team already uses; it works with Salesforce, as well as Pipedrive, HubSpot and Zoho CRM. It checks deal and customer data in the CRM and explains what needs attention. If you keep rebuilding the list of changed deals from field history by hand, [check your CRM with SalesBond](https://salesbond.app/). The three fields above are still yours to set up; without them there is nothing for any tool to compare.

## Three cases from the same account

Say a customer signed for ten seats of a product with a twelve-month term and an onboarding package. Over the next quarter, three things happen.

In month two they ask for a second team, eight more seats. That is scope up: new revenue that was not in the signed deal, so it gets its own Opportunity. `Type` is Existing Business, `ContractId` points at the same contract, the close date is whenever they sign, and the stage reflects where the conversation is. The original Opportunity does not change. If someone asks whether this should be a separate record type, [we wrote about when that is worth it](https://salesbond.app/blog/salesforce-record-types-new-vs-renewal-opportunities/); usually it is not, and the `Type` field does the job.

Month three: they drop the onboarding package before it starts. Same scope, less of it. Fill `Original Amount` with the signed total if it is not already there, set `Change Reason` to scope down and `Change Date` to the day they confirmed in writing, then reduce the line item. `Amount` recalculates from the lines. The Closed Won total for that close date is now lower, and the report with both amount columns shows exactly by how much and why.

Then, in month four, the seats go live two months later than planned because thier rollout slipped. Nothing changed except timing. Leave `CloseDate` alone; it records when they signed. Move the `ServiceDate` on the line, or the schedule dates if the product is scheduled, and set `Change Reason` to date shift so the revenue-timing report can explain itself later.

Three changes on one account, and the signed number is still readable on every record. If you want one thing to do this week, create the three custom fields, add a validation rule so `Original Amount` and `Change Date` cannot stay blank once `Change Reason` is set, and add `Original Amount` next to `Amount` in your Closed Won report. The next change order that lands will then leave a trail a manager can read six months later without asking anyone.