Amendment Scenarios
Amendments: what's editable, what's not, and why
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 |
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
How specific actions behave
| 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 |
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.
| 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 |
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.
| 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 |
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.
| 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 |
Amendments are for modifying existing structure. If a ramp is needed, it should be on the quote before the contract is processed.
| 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. |
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.
Common questions
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 about 2 hours ago