Salesforce-native revenue recognition automating ASC 606 at transaction scale.
RightRev is a revenue recognition automation platform built natively on Salesforce, designed to take rev-rec out of spreadsheets for companies with contract volume and pricing complexity that break manual processes. It consumes orders, amendments, and billing events, applies ASC 606 treatment — performance obligations, allocation, deferrals — and produces the revenue schedules, waterfalls, and journal entries accounting teams post to the GL. Buyers are controllers and revenue accountants, particularly in organizations already running quote-to-cash on the Salesforce platform.
Which of the capability map's modules RightRev covers — each links to the module's own page, with every tool that supports it.
| Module | Phase | Depth | Note |
|---|---|---|---|
| Run Revenue Operations | |||
| Revenue Recognition (ASC 606) | Financial Operations | Core | Automated performance obligations, SSP allocation, and recognition schedules from order and usage data. |
| Deferred Revenue Management | Credit & Compliance | Core | Deferred revenue balances and waterfall reporting maintained continuously as contracts change. |
Scored against UsagePricing's Revenue recognition & close rubric v1.0 (0 weak · 1 adequate · 2 strong), assessed July 2026. Requirements we couldn't verify from public material stay unscored — never guessed. Read the method.
| Requirement | Score | Why |
|---|---|---|
| ASC 606 engine Are performance obligations, SSP allocation, and modifications first-class? | 2 · Strong | Purpose-built five-step engine from the RevPro lineage. |
| Usage & variable consideration Can it recognize consumption revenue at transaction granularity? | 2 · Strong | Consumption and usage-based recognition is the explicit design target. |
| Deferred revenue waterfall Is the deferred balance auditable as a roll-forward, not a plug? | 2 · Strong | Automated schedules with waterfall reporting. |
| Multi-entity & multi-book Can it hold entities, currencies, and parallel books (GAAP/IFRS) together? | 1 · Adequate | Multi-currency support; consolidation stays in the ERP. |
| Close & journal automation Do recognized numbers land in the GL and the close checklist automatically? | 1 · Adequate | Journals hand off to the ERP for posting. |
| Audit drill-down Can an auditor walk from a journal line back to the source transaction? | 1 · Adequate | Contract-level support with lineage into source quotes. |
| Source-system connectivity Does billing/CRM/payment data arrive without custom pipelines? | 1 · Adequate | Salesforce-native ingestion; other sources via integration. |
The Salesforce-native architecture is the distinctive choice: revenue recognition happens on the same platform as CPQ and billing data, so contract changes flow into rev-rec without integration middleware, and it pairs naturally with Salesforce Revenue Cloud deployments. It is also built for transaction volume and usage-based models, where recognition has to keep pace with consumption events rather than a monthly invoice batch.
Platform fee, sales-quoted.
It depends on where complexity lives. ERP rev-rec modules handle straightforward subscription schedules; they strain under high transaction volume, usage-based recognition, and frequent amendments. A dedicated engine like RightRev acts as a revenue subledger that does the heavy computation and posts summarized entries to whatever GL you run.
The forcing functions are audit readiness and model complexity — typically approaching or past the first audited financials with usage-based, multi-element, or high-volume contracts in the mix. If revenue closes involve accountants rebuilding waterfall spreadsheets every month, that is the signal the automation pays for itself.
By overlap on the capability map — computed, not curated.