Home / admin / usage-based-pricing-setup
usage-based-pricing-setup
Usage-based pricing in Revenue Cloud: metered billing, usage records, rating, tiering, consumption schedules. NOT for choosing a CPQ pricing method (List, Block, Cost Plus Markup, Percent of Total) - use admin/pricing-model-design. NOT for legacy Salesforce Billing (blng__) schedules and invoice runs - use admin/billing-schedule-setup.
Open the skill folder on GitHub
Usage-Based Pricing Setup
Activate when configuring Revenue Cloud usage-based (consumption / metered) pricing: products billed by API calls, gigabytes, seats-per-day, kWh, or any consumed unit. Distinct from CPQ flat-rate discounting — usage-based pricing calculates charges from post-sale telemetry and runs rating on top of raw usage records.
Before Starting
- Confirm Revenue Cloud + usage-based entitlement. Consumption Schedules, Usage Summary, and rating are part of Revenue Cloud, not base CPQ. License the correct SKU.
- Identify the telemetry source. Usage records arrive from: product platform (most common), external metering service (Stripe Metering, Chargebee), data warehouse, or manual CSV. Schema and cadence define the ingestion.
- Define the rating model. Tiered (different price per tier), volume (all units at the tier's price), overage (flat to cap, then per-unit), prepaid pool (drawdown) each have distinct configuration and testing needs.
Core Concepts
Consumption Schedule
A ConsumptionSchedule defines the rating rule: Type (Range or Slab), RatingMethod (Tier or Volume), and ConsumptionRate children with LowerBound, UpperBound, Price, PricingMethod. Attached to a Product2.
Usage records
UsageTransaction or UsageRecord (naming depends on release) carries quantity, timestamp, product, subscription. Rated into BilledUsage or an equivalent object on a scheduled cadence.
Rating and invoicing
Scheduled rating evaluates unrated usage against the Consumption Schedule, writes priced usage records, and feeds the invoice engine. Idempotency matters — re-running rating must not double-charge.
Prepaid pools
For "buy 1M API calls, drawn down monthly," a prepaid pool tracks balance. Usage decrements the pool; overage triggers a different rate. Uses SubscriptionUsageEntitlement patterns depending on release.
Common Patterns
Pattern: Tiered pricing with monthly invoice
Product has a Consumption Schedule with three tiers. Usage ingested daily from product telemetry via REST API. Nightly rating job converts unrated usage to priced usage. Month-end invoice run aggregates, posts, and emails.
Pattern: Prepaid pool with overage
Customer purchases a 10M-call annual bundle. Usage drains the pool across the year. At 100% consumption, overage rate kicks in. End of term: any unused balance is forfeited or carries forward per contract.
Pattern: Real-time usage visibility for customers
Customer portal LWC shows current month usage, remaining pool, and projected overage. Data comes from the aggregated UsageSummary object, not raw UsageRecord — same reason as rebate snapshots: performance and stability.
Decision Guidance
| Situation | Recommended Approach | Reason |
|---|---|---|
| Flat per-unit pricing | Simple Consumption Schedule, Range type | Simplest, well-supported |
| Discount tiers with cumulative volume | Volume rating method | All units priced at top tier |
| Commit + overage | Prepaid pool with overage rate | Matches common SaaS contracts |
| Real-time customer dashboard | UsageSummary rollup, not raw records | Performance |
| Usage from external meter | Integration via Bulk API or Platform Events | Decouples rating from source |
Recommended Workflow
- Confirm Revenue Cloud license and usage-based entitlement; ensure Consumption Schedule objects are exposed.
- Model the product catalog: identify each metered product, its rating method, and pricing tiers.
- Build Consumption Schedules and attach to Product2 records; include effective-dated schedules for future price changes.
- Design the usage ingestion pipeline: schema, volume, cadence, idempotency, retry policy.
- Validate end-to-end with sample usage: ingest → rate → invoice → verify amounts against contract math.
- Build
UsageSummaryrollups; expose in customer portal with real-time (or near-real-time) totals. - Build reconciliation and finance controls: invoice approval, GL mapping, dispute handling.
Review Checklist
- [ ] Consumption Schedules validated against contract math
- [ ] Usage ingestion idempotent across retries
- [ ] Rating job tested with month-end volume
- [ ] Overage and prepaid pool logic tested with edge cases
- [ ] Customer-facing dashboard shows accurate usage vs entitlement
- [ ] Finance approval and GL mapping in place
- [ ] Dispute/credit process documented
Salesforce-Specific Gotchas
- Re-rating is easy to fire twice. Rating jobs that do not check
IsRated/Ratedflags will create duplicate priced records on retry; design idempotency explicitly. - Consumption Schedule effective dating is strict. A mid-month price change requires a new schedule version with proper effective dates; retroactive changes re-rate the whole period.
- High-volume usage can overrun storage. Millions of
UsageRecordrows balloon Salesforce storage; plan for archival (big objects or external warehouse) before go-live.
Output Artifacts
| Artifact | Description |
|---|---|
| Consumption schedule catalog | Per-product rating rules and effective dates |
| Ingestion pipeline spec | Source, schema, cadence, idempotency controls |
| Rating + invoice runbook | Monthly cycle procedure |
| Customer visibility component | LWC reading from UsageSummary |
Related Skills
architect/revenue-cloud-architecture— upstream deal structureadmin/integration-pattern-selection— usage ingestiondata/data-archival-strategies— long-term usage archive