A 30-Minute Audit for Finding CPQ Pricing Rules Gone Stale

Start by listing every discount approval rule, pricing tier, and override permission currently configured in your CPQ tool, in one place, not scattered across several admin screens. This alone often surfaces the first problem: rules that reference a product or tier that's since been discontinued or renamed, which means the rule silently stopped doing what it was built to do the moment the underlying product changed.

Compare the discount percentage that currently triggers manager or finance approval against whatever leadership last formally agreed to. It's common to find these have drifted apart, either because a threshold was quietly adjusted to reduce approval friction during a busy quarter and never reverted, or because a new pricing tier was added without anyone updating the corresponding approval rule to match it.

CPQ tools often accumulate override permissions the same way CRMs accumulate custom fields: granted for a specific, reasonable exception at the time, never revoked once the exception passed. Check who currently has permission to override an approval requirement or apply a discount beyond a standard tier, and confirm each one against a current, valid business reason. A former employee's override permission sitting active is a common and easily missed finding here, and it's the kind of gap that looks obvious in hindsight but rarely gets caught without a deliberate check like this one.

Pick a handful of quotes from the last quarter and manually trace them through the current pricing rules to confirm the approval chain they should have triggered actually matches what happened. A quote that should have required finance sign-off but didn't is worth investigating immediately, since it usually points to either a misconfigured rule or an override that shouldn't have been used for that specific case. Pick quotes from more than one rep and more than one product line, since a rule that works correctly for a standard configuration can behave differently once a bundle or a nonstandard term length is involved.

For example, suppose a quote for a bundled product went out with a deeper discount than the standard tier allows, yet no finance approval was recorded. Tracing it might show that the bundle was created after the approval rule was written, so the rule never covered it. The fix is not just adding that bundle to the rule. Also check every other product created since the rule was last edited, because the same gap probably affects them. Record what you found and who approved the correction.

Once the audit is done, get an explicit sign-off from whoever owns pricing strategy that the current rules match current policy, with a documented date. That sign-off becomes the baseline for the next audit, and it means the next person to review this can trust that everything checked out as of a specific date rather than having to re-verify the entire matrix from scratch every time.

The audit comes down to these steps, in order:

1. List every active discount approval rule, pricing tier and override permission in one place.
2. Compare the discount level that triggers approval against what leadership last formally agreed to.
3. Review who holds override permissions and confirm each one still has a current, valid business reason.
4. Trace a handful of recent quotes through the rules, choosing more than one rep and more than one product line.
5. Get a dated sign-off from whoever owns pricing strategy that the rules match current policy.

A gap found during this audit isn't automatically an emergency, but it does need a fast decision: either the current rule was wrong and needs correcting to match actual policy, or the current practice has quietly become the new policy and the documentation needs updating to reflect that. Resist the instinct to silently patch the rule without deciding which of those two is true, since guessing wrong means the same gap reopens the next time someone touches that part of the pricing configuration.

Flag any gap involving a discount that already went out to a live customer to finance immediately, separate from the broader governance fix, since that's a distinct conversation about whether the existing deal needs to be revisited rather than only a forward-looking configuration issue.