Complete Guide to Usage Management in Salesforce Revenue Cloud (2026 Update)

2026 Update: This article has been rewritten for the current state of Salesforce Revenue Cloud Usage Management. Key changes include commit products (now a major topic of their own — see our dedicated commit products guide), the T+3 drawdown waiting period, the Manage Usage Resources UI behavior, and the live wallet pattern for real-time balance visibility.

Usage Management is the Salesforce Revenue Cloud feature that lets you sell a subscription product whose price depends on how much the customer consumes — not just on how long they are subscribed. Cloud platforms, API providers, telecom carriers, and AI companies all use some flavor of usage-based billing, and Revenue Cloud provides the data model and pricing engine that makes it work inside Salesforce.

This guide walks through the complete lifecycle — from building an anchor product with granted allowances, through metering consumption events, aggregating usage, drawing down commits, and finally generating an invoice that combines the flat subscription fee with overage charges. We will use a running Robotics Inc. scenario: a fictional robotics cloud platform that sells AI compute time and data storage to industrial customers.

What You Will Learn

• The full Usage Management data model — every object and how they connect
• How to set up an anchor product with tokenized resource pricing
• The end-to-end lifecycle from quote to invoice, including the T+3 drawdown behavior
• Where commit products fit and when to reach for them
• The implementation gotchas that waste days of troubleshooting

The Robotics Inc. Scenario

Throughout this guide we will build out the Robotics AI Platform — a cloud product that Robotics Inc. sells to customers who train and deploy computer-vision models for industrial robotics. The product has two usage dimensions: Compute Time (measured in hours of GPU runtime) and Data Storage (measured in gigabytes of model data at rest). Both consume a common unit of account called AI Tokens, priced at $1.00 per token. The subscription sells for $24,000 per year and includes a bundled allowance of 100,000 AI Tokens.

When larger customers want to lock in a better rate, Robotics Inc. offers a separate commit product for a negotiated dollar-per-token price. That is a separate topic covered in the dedicated commit products article — for this guide we focus on the base usage model.

The Key Objects in Usage Management

Usage Management is one of the wider data models in Revenue Cloud. These are the objects you will interact with on every implementation.

Object	Purpose
UnitOfMeasureClass	Groups related units (Time, Data, Currency, Token). Has a Type picklist.
UnitOfMeasure	The actual units — Hour, GB, Token, USD. Belongs to a class.
UsageResource	The thing being metered — “Compute Time”, “AI Tokens”. Has a category (Usage, Token, Currency).
Product2 with UsageModelType	The sellable product. Values: Anchor, Pack, Commit, CommitmentSpend, CommitmentQuantity.
ProductUsageResource (PUR)	Junction object linking a product to a usage resource. Carries TokenResourceId for tokenized pricing.
ProductUsageGrant (PUG)	Defines the grant — how many units are included, and whether overage is chargeable. Type is Grant or Commit.
RateCard / RateCardEntry	The pricing records. Rate cards are Base, Tier, or Attribute; entries set the per-unit rate.
RateAdjustmentByTier	Child of RCE for tiered pricing — holds the tier bounds and adjustment type (Percentage, Amount, Override).
UsageResourcePolicy (URP)	Defines aggregation, frequency, overage, and commitment behavior per resource.
ProductUsageResourcePolicy (PURP)	Per-product override of the URP — where commit products attach their commitment policy.
UsagePrdGrantBindingPolicy	Design-time binding declaration — Self or Target. Only valid on Anchor and Pack products.
TransactionJournal	Raw usage events from the customer’s workload.
UsageSummary / UsageRatableSummary	Aggregated and rated consumption per period.
UsageBillingPeriodItem	The liable summary that feeds invoice generation.

Setting Up a Tokenized Anchor Product

We will build the Robotics AI Platform step by step. The full implementation touches ~25 records, but they fall into six logical phases.

Phase 1 — Foundation: UoM Classes and UoMs

Before anything else, ensure the UnitOfMeasure.Type picklist has values deployed — it ships empty. You need values like Count, Currency, Time, Data. Then create UoM classes for each dimension your product meters: a Time class for hours, a Data class for gigabytes, a Token class for AI tokens, and a Currency class for USD. Each class produces one or more UoMs.

Gotcha: UoMs must be activated before the UsageResource that references them. Activation order is one-way — Draft → Active → Inactive, no going back — so test carefully in a scratch org before deploying to production.

Phase 2 — Usage Resources

Each metered dimension becomes a UsageResource record. Robotics Inc. creates three: Compute Time (Category=Usage, class=Time, default UoM=Hour), Data Storage (Category=Usage, class=Data, default UoM=GB), and AI Tokens (Category=Token, class=Token, default UoM=Token).

The Token-category resource is the pivot that makes a tokenized anchor work. Compute Time and Data Storage will reference it through TokenResourceId on their PURs, telling the rating engine “when this resource is consumed, convert it to tokens first.”

Phase 3 — The Product

Create the product with UsageModelType=Anchor. Assign a Product Selling Model (typically “Term Annual” using SellingModelType=TermDefined, PricingTerm=1, PricingTermUnit=Annual). Add a PricebookEntry on the Standard Price Book at your list price — $24,000 in our example. Assign the product to a catalog category so reps can find it in the product browse.

Note: There is no “Usage” value in the ProductSellingModel.SellingModelType picklist. Use TermDefined, Evergreen, or OneTime. The usage behavior comes from Product2.UsageModelType, not from the selling model.

Phase 4 — PURs and PUGs

Create three PURs on the product, one per resource. The Compute Time and Data Storage PURs carry TokenResourceId=AI Tokens. The AI Tokens PUR has no TokenResourceId — it is the destination.

Then create three PUGs:

• Compute Time Grant: Quantity=0, OverageChargeable=Yes (no free compute, all chargeable)
• Data Storage Grant: Quantity=0, OverageChargeable=Yes
• AI Tokens Grant: Quantity=100,000, OverageChargeable=Yes (100k included allowance per subscription term)

Set ValidityPeriodTerm=1 ValidityPeriodUnit=Month on the compute and storage PUGs for monthly refresh. The token grant on the anchor typically runs for the whole term — set validity period to null.

Phase 5 — Rate Card

Create a RateCard with Type=Base, then link it to the Standard Price Book through a PriceBookRateCard record (note: the field is PriceBookId, not Pricebook2Id). Add three RateCardEntry records:

Resource	Rate	Rate UoM	Meaning
Compute Time	10	Token	10 tokens per compute hour (PPU)
Data Storage	1	Token	1 token per GB of storage (PPU)
AI Tokens	1.00	USD	$1.00 per token (PPP)

The first two are PPU (Price Per Usage) — they convert raw usage into tokens. The third is PPP (Price Per Pool) — it converts tokens into dollars. At rating time, the engine walks this chain automatically: Compute hours → Tokens → USD.

Phase 6 — Policies and Binding

Create the policy records: a UsageOveragePolicy (“Default Overage” with OverageChargeable=Yes), a UsageResourceBillingPolicy (“Monthly Sum Aggregation”), and a RatingFrequencyPolicy (RatingPeriod=Monthly). Then create one UsageResourcePolicy per resource linking those policies to the resource. Finally, create ProductUsageResourcePolicy records (PURPs) per PUR — one per Compute/Storage with overage plus aggregation plus rating frequency, and one for AI Tokens with just the overage (the Token category does not accept aggregation or frequency).

The last piece is the UsagePrdGrantBindingPolicy: one record on the anchor product with GrantBindingType=Self. This tells Revenue Cloud that the anchor consumes its own grants. Without this record, the Manage Usage Resources UI shows empty resource tables on the quote.

Activation Order Matters

All the records above are created with Status=Draft. Activating them is a one-way trip, and the order is strict. Run this activation pass via anonymous Apex:

1. Activate UnitOfMeasureClass records
2. Activate UnitOfMeasure records
3. Activate UsageResource records — Token-category resources first, then Usage-category
4. Activate ProductUsageResource records — Token PURs first
5. Activate ProductUsageGrant records
6. Activate RateCardEntry records

Important: Activating out of order produces “Select an active unit of measure” and similar validation errors. The dependency chain is UoM → Resource → PUR → PUG → RCE.

Refreshing Decision Tables

Every new usage product or rate card entry requires a decision table refresh before the rating engine can resolve it. Miss the refresh and products appear invisible to the rating engine — or show up with blank rates in the Manage Usage Resources UI.

The decision tables you need to refresh fall into three groups:

• Rate Card resolution: Rate_Card_Entries_2, Rate_Card_Entry_Resolution_Entries_2, Pricebook_Rate_Card_Decision_Table, Price_Book_Entry_Decision_Table_v2
• Tier adjustments: Rate_Adjustment_by_Tier_Entries_2, Tier_based_Rate_Adjustment_by_Rate_Card_Entry_ID, Rate_Adjustment_by_Tier_Resolution_Decision_Table
• Asset/Binding lookups: Asset_Rate_Card_Entry_Resolution_V2, Asset_Rate_Decision_Table_V2, Binding_Object_Rate_Card_Entry_Resolution_V2

Fire each refresh via the REST action /services/data/vXX.X/actions/standard/refreshDecisionTable. Each returns a Status of “Queued” — the actual refresh runs asynchronously, typically within 30-60 seconds. If you skip the tier-specific tables, commit products in particular will render with blank rate adjustments in the UI even though the data is correct.

The Quote-to-Invoice Pipeline

Once the product is built and activated, the runtime lifecycle has seven stages. This is where Revenue Cloud’s usage management feels different from a plain subscription product.

1. Quote and Order

The sales rep adds the anchor to a quote. Because the product is flagged as usage, the Manage Usage Resources button becomes available on the quote line, showing the grants and rates the customer is getting. When the quote is ordered and activated, Revenue Cloud creates the supporting runtime records: an Asset for the subscription line, a UsageEntitlementAccount (the wallet container), and a tree of UsageEntitlementBucket records that hold the grant balances. Billing schedules are created for both the anchor subscription (flat fee) and each usage resource (overage tracking).

2. Usage Ingestion via TransactionJournal

The customer’s workload generates usage events. Each event arrives in Revenue Cloud as a TransactionJournal record with UsageType=UsageManagement, a reference to the anchor asset, a usage resource, a quantity, and a unit of measure. Events pile up at Status=Pending.

3. Aggregation via Summarize

Click Summarize on the Transaction Journals list view (or wait for the scheduled flow). This invokes the Create_Usage_Summary_v3 data pipeline, which aggregates pending TJs into UsageSummary records. Pending TJs flip to Processed and get a reference to the new summary. UsageSummary.ConsumptionUnits populates immediately.

UI quirk: Clicking Summarize or Calculate Rate in a scratch org frequently throws a “Sorry to interrupt / CSS Error” modal. The batch still fires — verify by querying the UsageSummary records. This is a known quirk that does not affect data integrity.

4. Rating via Calculate Rate

Click Calculate Rate on the Usage Summaries list view. The rating engine runs the configured Rating Procedure, producing UsageRatableSummary records with populated NetUnitRate and TotalAmount. If a commit is bound to the asset, UsageRatableSumCmtAssetRt junction records get auto-generated to record the commit rate applied.

This step also updates the UsageEntitlementBucket.ProvisionalBucketBalance and its rolled-up TotalProvisionalBalance — the live view of how much of the grant the customer has consumed. This is the field to read for real-time wallet balance displays.

5. T+3 Drawdown (the waiting period)

This is the stage that surprises everyone. Revenue Cloud deliberately delays the “committed” drawdown — the update to UsageSummary.DebitedUnits and UsageEntitlementBucket.BucketBalance — by three days after the ratable period end. The stated reason is to accommodate late-arriving transaction journals; in practice, it means the standard Asset Wallets UI shows the committed balance, not the live consumption, until T+3.

You can adjust this through the waitingPeriod input on the Create_Usage_Summary_v3 DPE definition. Set it to 0 for immediate drawdown in test environments. In production, the three-day window is also the deadline beyond which late TJs are ignored.

6. Liable Summary

After T+3, the Create_Liable_Summary_v3 DPE creates UsageBillingPeriodItem records flagged Status=Ready for Invoicing. These are the invoice-ready records — one per billing period, containing the final overage quantity and amount.

7. Invoice Generation

The Invoice Scheduler picks up the Ready-for-Invoicing liable summaries and merges them with the anchor’s base subscription billing schedule into a single customer invoice. The liable summary flips to Invoiced.

A key nuance: usage-related billing schedules never reach “completely billed” status the way a flat subscription schedule does. Usage billing schedules stay open past their end date to accommodate late usage and amendment orders that tie to the same binding instance.

Rating Procedures Setup (One-Time Per Org)

Two things need to be configured once per Revenue Cloud org before any rating can happen at quote time or drawdown.

1. Clone a Rating Procedure from the Expression Set Templates. For simple usage products, the Default Rating Procedure works. For products with commits or negotiated rates, use the Negotiable Rating Procedure.
2. Clone and assign a Rating Discovery Procedure. Setup → Revenue Settings → Set Up Usage Rating → pick the cloned Discovery Procedure. Without this assignment, rating never fires at quote time and the Manage Usage Resources UI shows blank rates.

The Rating Procedure itself is not globally assigned — it is invoked via the Discovery procedure’s output or through pricing procedures. This is different from the main pricing procedure, which does have a global Revenue Settings slot.

Where Commit Products Fit

Everything above describes an anchor product — the base subscription that carries grants and overage. When customers want to prepay for discounted consumption, that is a separate product family: Commit Products. They mirror the anchor’s resource structure but carry a Commit-type PUG instead of only Grant PUGs, they use a Tier rate card instead of Base, and they come in three flavors: Token Commit, Monetary Commit (Commitment Spend), and Quantity Commit.

We cover the full commit product data model, the three token commit pricing patterns (EACH, FLAT, TIER), and the rating behavior in our dedicated article: Commit Products in Salesforce Revenue Cloud: Token, Spend, and Quantity Commits Explained.

The Live Wallet Pattern

A common gap in the standard experience: the Asset > Wallets tab UI reads committed-balance fields (BucketBalance, ConsumedEntitlement), which only update at T+3. Customers and reps want to see real-time consumption.

The solution is a custom Lightning Web Component (LWC) that reads UsageEntitlementBucket.TotalProvisionalBalance — the rolled-up live balance — and displays it alongside the committed balance. The LWC queries the bucket tree for a given asset or account and computes percent consumed against the original grant quantity. This pattern ships in many Revenue Cloud implementations and is one of the reusable accelerators that transform the standard UI into something sales and customer success teams actually want to use.

Gotchas That Waste Implementation Time

• UoM Type picklist ships empty. Deploy values (Count, Currency, Time, Data, etc.) as metadata before creating any UoM records.
• No “Usage” value in ProductSellingModel.SellingModelType. Use TermDefined, Evergreen, or OneTime. Usage behavior lives on Product2.UsageModelType, not the selling model.
• PricebookEntry needed in every pricebook the quote uses. If the quote uses a custom pricebook (say “Robotics Inc.”), the product needs PBEs in both the Standard Pricebook and that custom pricebook — otherwise the product is invisible in the product browse.
• Token PUR activation order matters. Activating a Usage-category PUR that references a Token-category PUR before the Token PUR is active produces: “You must create a Product Usage Resource with the same Product and a Usage Resource of category Token before creating this record.”
• PriceBookRateCard uses PriceBookId, not Pricebook2Id. Every other object uses Pricebook2Id — this one breaks the pattern.
• UsageAggregationPolicy is not the real API name. It is UsageResourceBillingPolicy. The UI label is “Usage Aggregation Policy” but the API name is different, which catches everyone who queries by sObject name.
• Transaction Journals require View All Records. The profile-level permission is needed to even access the TJ list view.
• Standard Asset Wallets UI lags by T+3. If the business needs real-time consumption, build a custom LWC on the provisional fields.

Related Resources

• Commit Products in Salesforce Revenue Cloud: Token, Spend, and Quantity Commits Explained — deep dive on the commit product family
• Pricing Procedures in Salesforce Revenue Cloud — how the pricing engine resolves list price, discounts, and rate card lookups
• Setting Up Revenue Cloud from Scratch — prerequisites for any usage product implementation
• What is Salesforce Revenue Lifecycle Management (RLM)? — the broader framework usage management sits inside

Conclusion

Usage Management in Revenue Cloud is a wide data model, but the logic is consistent once you see the pattern. A product has resources, resources have grants, grants have rates, rates produce consumption events, and consumption events flow through aggregation → rating → drawdown → invoice. Every object in the model exists to express one variation of that pipeline.

The biggest mindset shift from traditional subscription billing is the T+3 waiting period and the separation between provisional balance (live) and committed balance (post-drawdown). Build your internal tooling around that split and you will have a Revenue Cloud usage implementation that actually matches what sales and customer success teams need day to day.