# Nonstandard contract approval: a worked case | SourceX

Canonical: https://refer.sourcex.si/guides/nonstandard-contract-approval-exception-examples
Last updated: 2026-10-18

The records that explain a contract exception are the ones that show its shape: the original approval route, the term that broke it, the recall and resubmission, each new approver's decision and condition, the executed order, and a note on what happened after signing. A discount approval on its own records a number. A nonstandard approval records a judgment, and the sequence below shows where that judgment lives and which system keeps each piece.

This worked case belongs to the [nonstandard contract approval guide](/guides/workflow-nonstandard-contract-approval), which covers what to inventory before a CPQ migration. Here we follow one deal from the first approval to the outcome, then turn it into a way to spot similar cases at a client.

## The case at a glance (Illustrative)

Illustrative and invented for this page. A fictional 290-person logistics software company is preparing a three-year renewal for a large shipper.

| Element | In this case |
|---|---|
| Deal | Three-year renewal, multi-site shipper |
| Standard term that applied first | 18% discount, inside the deal desk's 20% limit |
| Exception | Customer adds a clause committing the vendor to deliver a carrier-rate API within the year |
| Why it is an exception | A future product commitment sits outside the deal desk's authority |
| Approvers pulled in | VP of Product and general counsel |
| Condition set | "Commercially reasonable efforts" wording, no penalty |
| Checked outcome | API shipped seven months later; customer confirmed in a business review |

## Six steps, six records

Each step names the decision, who made it and the record it left. The record column is what a company would need to keep for the case to explain itself years later.

1. **Original route, day 1.** The quote carries an 18% discount. The company's matrix lets the deal desk approve up to 20%, so the deal desk manager approves the same day. *Record:* an approval step on the quote with a timestamp.
2. **The change, day 9.** Late in negotiation, the shipper's procurement team adds the API delivery clause. The contract manager logs the redline in the contract tool. *Record:* a redline version with the new clause and its author.
3. **Recall and reroute, day 9.** A product commitment is outside the deal desk's authority, so the quote is recalled and resubmitted, now requiring the VP of Product and the general counsel. *Record:* a recall on the first approval and a new approval request on the resubmitted quote version.
4. **Conditional decisions, days 10 to 12.** Product approves on condition that the clause says "commercially reasonable efforts" with no penalty. Legal accepts the softened redline. *Record:* two approval steps with comments, and a second redline version.
5. **Execution, day 15.** The customer signs the revised language and the order is booked against the approved quote version. *Record:* the executed agreement and an order that references that quote version.
6. **Outcome, month 7.** A customer success note records that the API shipped and the customer confirmed it in a business review. *Record:* an outcome note on the account, tied to the commitment.

On Salesforce-based quoting, the approval steps in steps 1, 3 and 4 are the kind of history exposed through the ProcessInstanceHistory object, which shows all steps and pending requests associated with an approval process. Whether a given company still has them depends on what happened to the quote records since.

## The matrix the deal ran against

The exception only makes sense next to the rules in force at the time. This is the Illustrative matrix behind the case.

| Term on the quote | Route under the matrix | Approvers | Record it leaves |
|---|---|---|---|
| Discount up to 20% | Deal desk | Deal desk manager | Approval step with timestamp |
| Discount above 20% | Finance | CFO or delegate | Approval step with comment |
| Nonstandard legal term | Legal | General counsel | Redline version plus approval comment |
| Commitment about future product | Product and legal | VP of Product, general counsel | Recall, resubmission and two approval steps |

If the company has changed its matrix over the years, each version matters. Without the version in force on day 9, nobody can say whether the reroute was required or a precaution. The [deal desk approval page](/data-types/deal-desk-approval-process) covers routine approvals as a record type.

## Why the middle of the case is the evidence

Steps 2 to 4 carry the value: the moment a standard deal became nonstandard, who was pulled in, and the condition they set. Steps 1, 5 and 6 frame it, showing what was normal before and what happened after.

This is the same pattern that makes other exception records useful, such as [accounts payable exception handling](/data-types/accounts-payable-exception-handling-process): a problem, the reasoning applied, the authority that acted and a checked result. In contract approval, it is rarer than it looks, because most quotes never leave the standard route.

## How the trail breaks

Three common failures turn this case into noise:

- **The recall is lost.** If the migration keeps only the final quote version, the history shows two approvals with no reason for the second.
- **The field values are gone.** Without Field Audit Trail, Salesforce keeps field history for up to 18 months, or up to 24 months via the API. A discount edited several times in an older deal may show only its final value.
- **The redline is orphaned.** If the contract tool stores no quote ID, the second redline can be matched to the approval only by customer name and date. The [cross-system map for these records](/guides/nonstandard-contract-approval-records-across-systems) shows which keys usually carry the join.

None of these failures is the company's fault; they come from tools scoped for quoting, not for explaining past decisions.

## Spotting similar cases at a client

A RevOps consultant can recognize the pattern without opening a quote. Ask the revenue operations head:

- "Roughly how many quotes a year are recalled and resubmitted after a term changes?"
- "Which approval routes involve product, legal or finance, rather than the deal desk alone?"
- "Do approval comments record conditions, or only approve or reject?"
- "Is there anywhere a commitment made in a contract is tracked after signing?"
- "Has the approval matrix changed, and are the old versions kept?"

If several answers are yes, the company likely holds cases like this one. Record the answers as metadata, then use the [referral brief template](/resources/nonstandard-contract-approval-referral-brief-template) for the introduction. The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Approval records quote customer terms, so what can be licensed stays unknown until SourceX's rights review; some companies also need board consent, covered on [whether licensing data requires board approval](/questions/does-licensing-data-require-board-approval). More for this audience is on the [RevOps consultants page](/for/revops-consultants).

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a client's recalled and rerouted quotes still carry their approval comments, [register as a partner](/register), check the company against [who qualifies](/who-qualifies), and read the [program terms](/terms) before you introduce the revenue operations head and the CEO, who decides.

## Sources

- https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_processinstancehistory.htm
- https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/tracking_field_history.htm
- https://refer.sourcex.si/terms