A B2B subscription contract is rarely a single document signed and forgotten. Over a typical 3-year customer relationship, the contract gets amended (added scope, changed terms), renewed (new term commitment), and trued-up (reconciled against actual usage). Each operation has accounting consequences, integration touchpoints, and audit requirements. The contract lifecycle is where the legal layer meets the revenue layer, and where the implementation either supports the business or creates ongoing pain.
The four states of a contract
Active. The contract is in effect. Both parties are performing.
Amended. The original contract has been modified. The amendment is itself a contract document, attached to the original.
Renewed. The customer signed for a new term. The renewal is a new contract that continues the relationship.
Expired or terminated. The contract period ended or one party canceled. Revenue ceases (or transitions to ongoing usage if applicable).
Each state transition has specific operational and accounting implications. The Revenue Cloud configuration must support all four cleanly.
Amendment patterns
An amendment changes the active contract. Three common amendment types:
Add scope. Customer adds 25 seats, adds a new module, adds a region. The original contract is unchanged; the amendment adds incremental scope. Revenue recognition for the added scope follows the original method.
Reduce scope. Customer drops a module, reduces seat count, removes a region. The original contract is reduced. The reduction has accounting implications: revenue already recognized for the dropped scope may need to be reversed if the reduction is effective retroactively.
Modify terms. Customer renegotiates the price, the discount, the payment terms, the contract length. The change applies from a specific date forward.
Each amendment type has different Quote/Order patterns. RLM's amendment flow handles all three with explicit modeling. CPQ Classic requires more manual setup.
Two amendment best practices:
- Always document the effective date. The amendment is effective from a specific date, not from when it was signed. Revenue recognition uses the effective date, not the signature date.
- Link the amendment to the original contract. The audit trail must show the chain: original contract, amendment 1, amendment 2, current state. Salesforce supports this via Contract-Amendment lookups.
Renewal patterns
A renewal extends the customer relationship into a new term. Three common renewal scenarios:
Like-for-like renewal. Same terms, same scope, new term. The original contract's end date becomes the new contract's start date. Revenue recognition continues seamlessly.
Renewal with negotiated changes. New term but different price or scope. The renewal includes the changes; the original contract ends at the renewal date.
Renewal with expansion. Customer renews and adds scope simultaneously. Common pattern in subscription businesses; treated as renewal plus same-day amendment.
Revenue Cloud's Renewal Flow Template (RLM) and Renewal Manager (CPQ Classic) automate the renewal process: generate a renewal Quote, route through approvals, sign, create the new Order. The configuration determines whether renewals are smooth or require manual intervention each time.
Two renewal practices:
- Generate the renewal Quote early. 90 days before contract expiration is typical. Gives sales and customer success time to negotiate, avoids last-minute churn from missed renewal conversations.
- Track renewal motion explicitly. A dashboard showing every contract expiring in the next 90 days, current status of the renewal motion, and the responsible owner. Renewals that fall through the cracks are usually invisible until the contract has expired.
True-up patterns
A true-up reconciles the contract terms against actual customer behavior or usage. Common scenarios:
Usage true-up. The contract included 1 million transactions per year. The customer used 1.3 million. The true-up bills for the 300,000 overage at the contracted overage rate.
Volume true-up. The contract assumed 100 users. The customer activated 130. The true-up bills for the additional 30 users.
Reconciliation true-up. End-of-year reconciliation of estimated vs actual values. Adjusts the contract amount up or down.
True-ups have specific accounting treatment. Under ASC 606, the true-up amount is recognized when it can be reliably measured (often at end of period). The Revenue Schedule must reflect the true-up as a discrete recognition event.
The configuration: a contract with true-up provisions has explicit fields for the reconciliation parameters. The true-up Order/Invoice is generated at the reconciliation event. The audit trail shows the basis for the true-up calculation.
CLM integration
Contract Lifecycle Management (CLM) tools like Conga CLM, Ironclad, or Salesforce's own CLM product handle the document side of contracts: drafting, redlining, signing, storage. Revenue Cloud handles the operational side: orders, billing, revenue.
The integration connects the two:
- Signed contract document linked to the Order in Revenue Cloud.
- Contract metadata (effective date, term, key clauses) populated in Salesforce.
- Amendments tracked in both systems with cross-references.
Without integration, the two sides drift. The legal team sees the signed PDF, the operations team sees the Order, no one can verify the two match.
Implementation pattern:
- CLM is the source of truth for the document.
- Salesforce is the source of truth for operational state (Order, Asset, Revenue Schedule).
- Both reference each other; periodic reconciliation confirms alignment.
Audit trail requirements
Auditors will trace from contract to revenue. The trail must include:
- Signed contract document (or reference to where it is stored).
- Effective date of the contract and any amendments.
- The Order Product records created from the contract.
- The Revenue Schedule entries generated from the Order.
- Any manual adjustments to the Revenue Schedule with documented reasons.
Gaps in this trail are audit findings. The configuration must support the full chain without manual reconstruction.
Common contract lifecycle mistakes
Five patterns Sapota has seen in audits:
- Amendments without effective dates. Amendment signed June 15, applied to June 1 service. The system uses the signature date, finance wants the effective date. Manual reconciliation per amendment.
- Renewals as new contracts. The renewal motion treats every renewal as a new customer. The contract history is fragmented. ARR reporting confuses new business with renewal.
- True-ups without documented basis. The true-up invoice exists but the calculation cannot be reproduced. Audit finding.
- CLM and Salesforce out of sync. Legal has one version, operations has another. Discrepancies discovered during disputes.
- No renewal dashboard. Contracts expire without renewal motion. Auto-renewals fire without sales involvement. Customer success is reactive.
What good contract lifecycle looks like
A Salesforce Revenue Cloud contract lifecycle implementation that holds up:
- Amendment flow with effective date tracking and original contract linkage.
- Renewal flow generated 90 days before expiration with clear ownership.
- True-up provisions configured with documented basis and reconciliation events.
- CLM integration with bidirectional references.
- Audit trail from contract document through Revenue Schedule.
- Renewal dashboard reviewed weekly by sales leadership.
The contract is the legal foundation of the customer relationship. The Revenue Cloud configuration is the operational implementation of that contract. When the two align, the lifecycle just works. When they drift, every quarter produces new questions about what the customer actually agreed to. Sapota's Salesforce team treats contract lifecycle as a cross-functional workstream involving legal, sales, finance, and operations.
Designing or auditing contract lifecycle in Salesforce Revenue Cloud? Sapota's Salesforce team holds the Revenue Cloud Consultant credential and handles CLM integration on production engagements. Get in touch ->
See our full platform services for the stack we cover.
