Two Switches, One Procedure: Why Salesforce Makes You Configure a Pricing Procedure in Two Places !
If you work with Salesforce Revenue Cloud / Salesforce Pricing, you’ve probably seen setup steps that ask you to “select a Pricing Procedure” in two pages. That can feel redundant—and it’s easy to wonder which one actually drives your quotes or invoices.
TL;DR
Salesforce shows an “OR” in the Salesforce docs 'Select a Pricing Procedure' because you can select your Pricing Procedure from either:
- Salesforce Pricing Setup (for quoting runtime), or
- Revenue Settings → Set Up Salesforce Pricing (for the revenue/transaction runtime).
If you only use one runtime, updating one place is enough.
If you run end-to-end Quote → Order → Invoice → Revenue, set the same procedure in both so quoting math and downstream billing/recognition stay in lockstep.
The mental model: two runtimes touch price
- Quoting runtime (what sellers use): runs the price waterfall—base price → adjustments → discounts → taxes—while you configure/price/quote.
- Revenue/transaction runtime (what ops/finance rely on): references the same procedure when processing transactions, orchestration, billing, and recognition.
Same recipe, two entry points. That’s why there are two places to pick it.
What each page actually controls
Salesforce Pricing Setup (Quoting)
- Sets the default pricing recipe & procedure used in the quote/order UI.
- Drives immediate math your sellers see: price waterfall, discounts, taxes.
Revenue Settings → Set Up Salesforce Pricing (Revenue/Transactions)
- Declares the canonical default for the transaction/billing side.
- Also where you enable Procedure Plan Orchestration if you’ll route different procedures by criteria (product family, region, transaction type, etc.).
The “OR” in the docs: when one page is enough
Salesforce’s instructions present an OR because each page can bind the runtime that depends on it.
- Quoting-only scenario (POC/sales sandbox):
Use Salesforce Pricing Setup only. - Transaction/billing-only scenario (finance testing, back-office jobs):
Use Revenue Settings only. - Most real implementations (Quote → Order → Invoice → Revenue):
Set both to the same procedure. The selectors are not auto-linked.
Why many teams still set both (the design rationale)
- Decoupled change windows
You can roll quoting changes first (for sales) and flip the revenue selector later (post close) without disrupting finance. - Context routing at scale
Revenue Settings hosts Procedure Plan Orchestration. If you route different procedures by context, the revenue runtime must know the canonical default and the routing rules—even as quoting keeps functioning. - Beyond the quote
Transactions, orchestration, billing, and recognition reuse the procedure. The revenue runtime needs an explicit selection to stay deterministic.
Step-by-step: introducing a new Pricing Procedure
Choose the path that matches your scope. For full quote-to-cash, do both paths.
Path A — Quoting-only
- Clone (or build) your Pricing Procedure.
- Go to Setup → Quick Find → Salesforce Pricing → Salesforce Pricing Setup.
- In Select a Pricing Procedure, pick your cloned procedure.
- Sync pricing data, open a test quote, re-price, and review the price waterfall.
Path B — Revenue/transactions-only
- Clone (or build) your Pricing Procedure.
- Go to Setup → Quick Find → Revenue Settings → Revenue Settings.
- In Set Up Salesforce Pricing, pick your procedure as the Default Pricing Procedure.
- If you need routing, enable Procedure Plan Orchestration and add Procedure Plan Definitions.
Path C — End-to-end (recommended for production)
Do Path A + Path B with the same procedure, then validate quote math and a downstream transaction in a single flow.
Important cloning & context notes (easy to miss)
- Assign a custom context definition when saving the clone (if you’re using one).
- The procedure’s Start Date must be later than the Effective From date of its context definition—otherwise runtime resolution can fail.
- After edits, Sync pricing data so the new definition is used by the quoting engine.
- Keep a consistent timezone/date policy so “Effective From” comparisons are predictable across environments.
Quick validation workflow (5 minutes)
- Quote math check
- New quote → add a test product → click Calculate.
- Confirm the expected price waterfall (base → adjustments → discounts → taxes).
- Transaction check
- Convert to order (or trigger your transaction flow).
- Run the orchestration step(s) used in your org.
- Confirm the same totals are used in billing/recognition and that any Procedure Plan routing matched the expected criteria.
- Edge-case check
- Try a line that triggers a different context value (e.g., region or product family).
- Verify the correct procedure fires (if routing is enabled).
Common pitfalls & fixes
| Symptom | What’s wrong | Fix |
|---|---|---|
| Quote UI still shows old math | Only Revenue Settings updated | Also set Salesforce Pricing Setup |
| Transactions differ from quotes | Only Pricing Setup updated | Also set Revenue Settings |
| Procedure won’t resolve | Start Date ≤ context Effective From | Move Start Date later than Effective From |
| Routing doesn’t change procedure | Orchestration not enabled / rules incomplete | Enable Procedure Plan Orchestration + add Definitions |
| Recent edits don’t show | Data not synced | Sync pricing data and retest |
Governance tips
- Deployment choreography:
- Flip Salesforce Pricing Setup during a sales-friendly window.
- Flip Revenue Settings after finance closes the period.
- Feature flag mindset: Keep Procedure Plan Orchestration off in prod until routing is validated in a full sandbox.
- Explainability: Enable the price waterfall and capture screenshots for UAT playbooks and training.
“We pick the same pricing procedure in two places because there are two parts of the process—quoting and revenue. If we use both, we set both, so the price the customer sees is the price we bill and recognize later.”