Usage Based Pricing Setup

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

Recommended Workflow

1. Confirm Revenue Cloud license and usage-based entitlement; ensure Consumption Schedule objects are exposed.
2. Model the product catalog: identify each metered product, its rating method, and pricing tiers.
3. Build Consumption Schedules and attach to Product2 records; include effective-dated schedules for future price changes.
4. Design the usage ingestion pipeline: schema, volume, cadence, idempotency, retry policy.
5. Validate end-to-end with sample usage: ingest → rate → invoice → verify amounts against contract math.
6. Build UsageSummary rollups; expose in customer portal with real-time (or near-real-time) totals.
7. 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

1. Re-rating is easy to fire twice. Rating jobs that do not check IsRated / Rated flags will create duplicate priced records on retry; design idempotency explicitly.
2. 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.
3. High-volume usage can overrun storage. Millions of UsageRecord rows balloon Salesforce storage; plan for archival (big objects or external warehouse) before go-live.

Output Artifacts

Related Skills

• architect/revenue-cloud-architecture — upstream deal structure
• admin/integration-pattern-selection — usage ingestion
• data/data-archival-strategies — long-term usage archive