Amendment Scenarios
An amendment quote starts from the last processed contract. That starting point controls which edits go through, which are blocked, and how changes get represented once made.
Behavior depends on whether the offering already existed on the contract (inherited) or was introduced in this amendment (added).
| Action | Inherited offering | Added offering | Change state |
|---|---|---|---|
| Update quantity | Yes | Yes | Updated |
| Change billing frequency | Blocked | Yes | Added |
| Change subscription timing | Blocked | Yes | Added |
| Edit a one-time charge from the original contract | Blocked | N/A | N/A |
| End an offering group early | Yes | Yes | Updated |
| Remove an offering | Conditional | Yes | Removed |
| Revert an offering group | Yes, group level only | N/A | No change |
| Create a ramp | Blocked | Yes | N/A |
| Edit a segment ending before the amendment date | Blocked | Yes | N/A |
| Amend a previously amended contract | Yes | Yes | Updated |
How an amendment quote is initialized
Creating an amendment reads the last processed contract and builds a new quote from it, with two things running side by side:
- What you see and modify in the amendment quote
- Each edit is classified against the contract snapshot
- Change states drive how processing runs
- A preserved snapshot of the contract before this amendment
- Used for diff calculation and pricing impact
- The baseline the system compares against, read-only
Changes have to resolve against subscription and billing state that already exists, which is why amendment edits feel more constrained than building a new quote.
Change states
Every offering in an amendment gets one of these. Each one drives what gets created, updated, or ended when the amendment is processed.
| State | When it applies | On processing |
|---|---|---|
| No Change | Offering carried forward, nothing modified | Contract and billing state unchanged |
| Added | New offering, didn't exist on the prior contract | New subscription or billing schedule created |
| Updated | Inherited offering with changed quantity, pricing, or timing | Existing subscription modified, lineage kept |
| Removed | Offering excluded from the amended state | Offering ends, stays visible in the quote for diff |
Example: Seat increase + new module
| Offering | Existing contract | After amendment |
|---|---|---|
| Platform seats | 100 | 125 (updated) |
| Support package | annual | no change |
| Analytics module | new (added) | |
| Onboarding fee | $20k one-time | contract history |
Seats go through as updated — same subscription, new quantity. Analytics is added. Onboarding is contract history and can't be rewritten in the amendment.
Inherited vs. added
Most blocked edits come down to this. The same field behaves differently depending on where the offering came from.
- Was on the contract before this amendment
- Has an existing subscription behind it
- Quantity and commercial terms: editable
- Billing frequency, subscription timing: protected
- Segments before the amendment date: read-only
- New, no prior subscription
- Timing, frequency, structure: all editable
- Marked added throughout processing
Example: Same field, different behavior
| Field | Inherited offering | Added offering, same amendment |
|---|---|---|
| Quantity | 100 → 125 ✅ | Set freely ✅ |
| Billing cadence | Annual → monthly ❌ | Editable ✅ |
| Why | Subscription structure is locked | No prior subscription to protect |
How specific actions behave
| When | Result |
|---|---|
| You remove an offering | Marked removed, stays visible in the quote |
| You shorten the contract term after removing | Removed group stays frozen, unaffected by the term change |
| Amendment is processed | Offering closes out on the contract |
| Removal on an offering with no subscription lineage | Blocked — system can't map the removal safely |
Still showing after removal?
Removed offerings stay visible so the system can represent what changed. The offering is in removed state, retained for the diff, and won't continue after processing.
| When | Result |
|---|---|
| You revert an inherited offering group | All changes on that group reset to contract baseline, every edit on the group, not just the last |
| Revert on a ramp segment directly | Not supported, revert works at group level only |
| Revert on a newly added offering | Not applicable, added offerings have no baseline to restore |
| Group is already at inherited baseline | Revert has no effect |
Revert vs. editing a field
Use revert when you want to abandon all changes on a group and go back to exactly what was on the contract. For fixing one specific value, edit the field directly.
| When | Result |
|---|---|
| Edit a one-time charge from the original contract | Blocked, it's committed contract history |
| Add a new one-time charge in this amendment | Allowed, marked added |
| Segment ends before the amendment date | Read-only, falls before the amendment boundary |
Why original one-times are locked
Once a one-time charge is part of the processed contract, editing it in place rewrites committed history. Add a new line to the amendment to represent the change instead.
| When | Result |
|---|---|
| Create a ramp on an amendment | Blocked on all offerings, inherited or added |
| Ramp exists from the original contract | Carried forward, quantity is editable per segment |
| Revert directly on a ramp | Not supported, revert at the group level instead |
Ramp creation belongs on the originating quote
Amendments are for modifying existing structure. If a ramp is needed, it should be on the quote before the contract is processed.
| When | Result |
|---|---|
| Shorten the contract term | Active offering groups may have their final segment updated to align. If all end early, the processed contract can become canceled at the latest offering end date. |
| Extend the contract term in a later amendment | Offerings ended early in a prior amendment stay ended, they don't stretch to match the new term. |
| Amend again after cancellation | Supported, initializes from the last processed state. |
Extending term doesn't revive ended offerings
If a prior amendment intentionally ended an offering early, a later term extension won't bring it back. Reintroduce it explicitly in the new amendment.
Example: Earlier end dates are preserved across amendments
| Amendment 1 (processed) | Amendment 2 | |
|---|---|---|
| Contract | Jan 1 – Dec 31 | Term extended: to Dec 31 |
| Platform | Ended: Sept 30 | Stays ended Sept 30 |
| Add-on | Ended: Oct 15 | Stays ended Oct 15 |
| Result | Contract now ends Oct 15 | Neither auto-extends |
Common questions
Why can I change quantity but not billing frequency on an existing offering?
Quantity is a commercial attribute the amendment is designed to change. Billing frequency is part of how the existing subscription runs and can't be changed in place. On a newly added offering it's editable because there's no prior subscription behind it.
I removed an offering. Why is it still in the quote?
Removed offerings stay visible in removed state because the system uses that for diff calculation. It won't continue after processing, it's just retained for the diff. The removal worked.
Why can't I edit the one-time charge from the original contract?
It's part of the processed contract and the system treats it as history. Add a new line to the amendment to represent the commercial change instead.
I extended the contract term. Why didn't the offerings that ended early come back?
Those early ends came from a prior amendment and the system preserves that. To restore those offerings, add them explicitly in the new amendment.
Why did revert change more than the one thing I edited?
Revert resets the whole offering group to its contract baseline, every change on that group. For a single field correction, edit the field directly.
Why is removal blocked on this offering?
Removal requires the system to map the change to the underlying subscription model. If the offering has no subscription lineage and wasn't added in this amendment, removal isn't supported.
If something's not behaving as expected
- Inherited or added? Always the first check. Different rules apply to each.
- Does the segment end before the amendment date? If yes, it's read-only, behind the amendment boundary.
- Is it a one-time from the original contract? Those can't be edited in place. Add a new line for the change.
- Still showing after removal? Expected, it's in removed state for the diff, not still active.
- Did a contract term change affect offering groups? Shortening can move final segment ends. Extending won't revive offerings ended in a prior amendment.
- Is this a delete, an early end, a removal, or a revert? They're different operations. Using the wrong one is the most common cause of changes that seem not to stick.
Updated 11 days ago