Section 05 of 06 CPQ + Billing Revenue Cloud

Billing & Revenue Recognition

A deep comparison of invoice generation, payment orchestration, ASC 606 revenue recognition, and ERP integration across Salesforce CPQ Billing (blng__ namespace) and the native Revenue Cloud billing engine. Targeted at architects and senior consultants evaluating or migrating between platforms.

5.1

Use Case, User Journey & Personas

When Billing & Revenue Recognition Is Needed

Core Use Cases

Invoice generation from activated orders or billing schedules
Payment collection — credit card, ACH, wire, direct debit
Revenue scheduling & deferral for multi-period contracts
ASC 606 / IFRS 15 compliance (SSP allocation, standalone selling price)
Credit memos & adjustments for cancellations/amendments
Dunning workflows & collections management

Triggering Signals

Revenue is recognized over time (SaaS, subscriptions, professional services)
Multiple performance obligations on a single contract
Variable consideration or usage-based components
ERP-independent billing that keeps revenue data in Salesforce
Automated invoicing without manual AR intervention
Customer self-service payment portal requirements

Internal Personas

⚙️

Billing Admin

Configures billing rules, treatments, invoice runs, and payment gateway setup

💰

AR / Finance Team

Monitors invoice aging, applies payments, manages exceptions and write-offs

📊

Revenue Accountant

Reviews rev rec schedules, validates ASC 606 allocation, approves journal entries

📬

Collections Manager

Oversees dunning queues, escalation workflows, and dispute resolution

🛠️

System Administrator

Maintains tax engine integrations, gateway credentials, scheduled job health

External Personas

🏢

Customer — Invoice Recipient

Receives PDF invoices via email or views them in the self-service customer portal; raises disputes or requests credits

💳

Customer — Online Payer

Makes payments via Experience Cloud portal; manages stored payment methods (card, ACH) and views payment history

CPQ Billing — Order-to-Cash Journey

Order Activated

SBQQ__Order

→

Billing Schedule Created

blng__BillingSchedule__c

→

Invoice Run (Batch)

blng__InvoiceRun__c

→

Invoice Generated

blng__Invoice__c

→

Payment Method Charged

blng__PaymentMethod__c

→

Payment Applied

blng__PaymentAllocation__c

→

Revenue Schedule Created

blng__RevenueSchedule__c

→

Rev Rec Entries Posted

blng__RevenueDistribution__c

Revenue Cloud — Order-to-Cash Journey

Order Activated

OrderItem / Asset

→

Billing Policy Applied

BillingPolicy

→

Invoice Generated (Event-Driven)

Invoice / InvoiceLine

→

Payment Orchestration

Payment / PaymentMethod

→

Rev Rec Schedule

RevenueSchedule

→

Finance Transactions

FinanceTransaction

→

ERP Sync

Platform Events / APIs

ℹ️

Key Architectural Difference

Salesforce CPQ Billing is a separate add-on product installed in the blng__ namespace — it is not part of CPQ (SBQQ) and requires its own licensing, installation, and configuration. Revenue Cloud billing is natively integrated into the RC data model with standard object names (no custom namespace), resulting in tighter platform cohesion but a different migration path for existing Billing customers.

💡

Key Takeaway — 5.1

Both platforms cover the full order-to-cash lifecycle, but CPQ Billing relies on scheduled batch invoice runs whereas Revenue Cloud is event-driven, eliminating the "next batch window" delay. For high-volume or real-time billing requirements, RC's architecture provides a meaningful operational advantage.

5.2

Licensing Requirements

CPQ + Salesforce Billing Stack

Salesforce CPQ — separate SKU from CRM; per-user license
Salesforce Billing — additional add-on, not bundled with CPQ; per-user Billing license required for users who generate/manage invoices
Payment Gateway Connector — Stripe, Adyen, CyberSource, Braintree integrations are add-on packages; some require separate ISV licensing
Tax Engine Add-ons — Avalara AvaTax or Vertex O Series connector packages; third-party subscription costs apply
Revenue Recognition Module — included within Salesforce Billing license but must be explicitly enabled via permission sets
Advanced Approvals — separate Billing-tier feature for invoice approval workflows

Revenue Cloud Billing Stack

Revenue Cloud Base — includes core billing (invoice generation, basic payment, rev rec) within RC license tier
Revenue Cloud Advanced — adds payment orchestration, advanced dunning, complex multi-currency billing, enhanced ERP connectors
Payment Processing — native payment gateway framework included; specific gateway connectors may require add-on packages
Tax Integration — native TaxTreatment object supports Avalara/Vertex; connector licensing still required for third-party engines
ERP Connector (MuleSoft / RC Accelerator) — FinanceTransaction + Platform Event–based sync; MuleSoft Anypoint license may apply
Experience Cloud for Self-Service Portal — separate EC license for customer-facing invoice/payment portal

⚠️

Common Licensing Trap

Many organizations buy Salesforce CPQ and assume billing is included — it is not. Salesforce Billing is a separate product that must be quoted, purchased, and installed independently. Confirm entitlements in your order form before beginning implementation. Revenue Cloud consolidates CPQ + Billing under a single RC license, which is one of the primary commercial drivers for migration.

Capability / Feature	Billing Add-on	RC Base	RC Advanced	ERP Required
Invoice generation (scheduled)	✓	✓	✓	✗
Event-driven invoice generation	✗	✓	✓	✗
Basic payment collection	✓ (gateway add-on)	✓	✓	✗
Payment orchestration (retry, routing)	~ (custom)	~	✓	✗
Revenue recognition (ASC 606)	✓ (Billing lic.)	✓	✓	✗
Multi-SSP allocation	~ (complex config)	~	✓	✗
Dunning & collections automation	~ (Flow/Process)	~	✓	✗
Native tax calculation	✗ (add-on only)	~	✓	✗
ERP journal entry sync	✗ (custom/MuleSoft)	~	✓	✓
Customer payment portal	~ (EC add-on)	~ (EC add-on)	~ (EC add-on)	✗

💡

Key Takeaway — 5.2

CPQ Billing requires assembling multiple licensed add-ons (CPQ + Billing + gateway connector + tax engine) from different product families. Revenue Cloud consolidates these under a single RC license tier, reducing procurement complexity. However, advanced capabilities (payment orchestration, multi-SSP, ERP sync) still require the RC Advanced tier or MuleSoft licensing — validate against your specific contract before scoping.

5.3

Data Model

CPQ Billing — Custom Objects (blng__ namespace)

blng__Invoice__c

Invoice header — the primary billing document sent to the customer

blng__Account__c — customer account lookup
blng__InvoiceStatus__c — Draft / Posted / Cancelled / Error
blng__DueDate__c — payment due date
blng__TotalAmount__c — total invoice amount
blng__Balance__c — outstanding balance after payments

Billing-Specific

blng__InvoiceLine__c

Individual line items on an invoice; tied to Order Product

blng__Invoice__c — parent invoice
blng__OrderProduct__c — source order item
blng__ChargeAmount__c — line charge
blng__TaxAmount__c — calculated tax

Billing-Specific

blng__BillingSchedule__c

Created from Order, defines timing and frequency of invoice generation

blng__OrderProduct__c — linked order line
blng__BillingRule__c — billing rule applied
blng__NextBillingDate__c — next invoice trigger date
blng__BillingScheduleStatus__c — Active / Closed

Billing-Specific

blng__BillingTreatment__c

Product-level billing rules — how and when to bill a specific product

blng__BillingRule__c — parent billing rule
blng__BillingType__c — Advance / Arrears / Immediate
blng__InvoiceRunRule__c — frequency config

Billing-Specific

blng__BillingRule__c

Top-level rule governing when billing is triggered and invoice cadence

blng__InitialBillingTrigger__c — Order Activation / Date
blng__CancellationBillingTrigger__c — immediate / end of period

Billing-Specific

blng__PaymentMethod__c

Tokenized payment method stored per account (card, ACH, bank transfer)

blng__Account__c — customer account
blng__PaymentType__c — Credit Card / ACH / Check
blng__GatewayToken__c — gateway reference token
blng__AutoPay__c — auto-charge flag

Billing-Specific

blng__Payment__c

Payment record; created when a charge is captured or a manual payment recorded

blng__Account__c — payer account
blng__PaymentAmount__c — total payment captured
blng__Status__c — Processed / Declined / Refunded
blng__GatewayDate__c — gateway processing date

Billing-Specific

blng__PaymentAllocation__c

Junction object linking a Payment to specific Invoice Lines; drives balance calculation

blng__Payment__c — source payment
blng__InvoiceLine__c — target invoice line
blng__AllocationAmount__c — amount applied

Billing-Specific

blng__RevenueSchedule__c

Revenue recognition schedule header; created from Invoice Line

blng__InvoiceLine__c — source invoice line
blng__RevenueScheduleStatus__c — Active / Closed
blng__RecognitionRule__c — straight-line / event-based

Billing-Specific

blng__RevenueDistribution__c

Individual revenue recognition entries — one per recognition period

blng__RevenueSchedule__c — parent schedule
blng__RecognitionDate__c — period date
blng__RevenueAmount__c — recognized revenue amount
blng__RevenueDistributionStatus__c — Posted / Unposted

Billing-Specific

blng__CreditNote__c

Credit memo issued to reduce outstanding balance; generated on cancellation or adjustment

blng__Account__c — customer account
blng__CreditNoteStatus__c — Draft / Posted / Applied
blng__TotalAmount__c — credit amount

Billing-Specific

blng__TaxIntegration__c

Tax engine bridge configuration — Avalara AvaTax or Vertex O Series connector settings

blng__TaxEngineProvider__c — Avalara / Vertex / Native
blng__ServiceEndpoint__c — API endpoint URL
blng__CompanyCode__c — tax engine company code

Billing-Specific

Revenue Cloud — Standard Billing Objects (no namespace)

Invoice

Native invoice object — no custom namespace; fully integrated with RC data model

AccountId — customer account
Status — Draft / Posted / Cancelled
DueDate — payment due date
TotalAmount — total invoice value
BillingAccountId — billing account (may differ from sold-to)

RC-Standard

InvoiceLine

Invoice line items; references OrderItem or AssetStatePeriod

InvoiceId — parent invoice
OrderItemId — source order product
ChargeAmount — line charge
TaxAmount — calculated tax via TaxTreatment

RC-Standard

BillingSchedule

Billing schedule linked to an Asset or OrderItem; drives event-driven invoice creation

BillingPolicyId — governing billing policy
NextBillingDate — next event trigger date
Status — Active / Suspended / Cancelled

RC-Standard

BillingPolicy

Top-level billing configuration object — defines billing cadence, triggers, and invoice grouping rules

BillingFrequency — Monthly / Annual / Usage
BillingDay — day of month for invoicing
InvoiceGroupingOption — per-order / per-account
AutoPayEnabled — auto-charge flag

RC-Standard

BillingTreatment

Product-level billing behavior — advance vs. arrears, proration rules

BillingType — Advance / Arrears / Immediate
ProrationType — Daily / Monthly

RC-Standard

PaymentMethod

Stored payment method (card token, ACH routing) per account or contact

AccountId — customer account
Type — CreditCard / ACH / BankTransfer
GatewayToken — tokenized reference

RC-Standard

Payment

Payment capture record; supports multiple payment applications

AccountId — payer account
Amount — captured amount
Status — Processed / Declined / Refunded
PaymentMethodId — method used

RC-Standard

PaymentApplication

Links a Payment to one or more Invoices or Invoice Lines (RC equivalent of blng__PaymentAllocation__c)

PaymentId — source payment
InvoiceId — target invoice
AppliedAmount — allocation amount

RC-Standard

RevenueSchedule

ASC 606 revenue recognition schedule; generated from InvoiceLine or Asset

InvoiceLineId — source invoice line
RecognitionRule — Straight-Line / Percent-Complete / Event
Status — Active / Completed

RC-Standard

RevenueTransaction

Individual revenue recognition entries within a schedule; RC equivalent of blng__RevenueDistribution__c

RevenueScheduleId — parent schedule
RecognitionDate — period date
Amount — recognized revenue amount
Status — Posted / Unposted / Reversed

RC-Standard

FinanceTransaction

ERP bridge object — represents a journal-entry-ready financial event for downstream GL sync

TransactionType — Invoice / Payment / RevenueRec / CreditNote
AccountingDate — posting date
DebitAmount / CreditAmount — debit/credit amounts
Status — Pending / Exported / Error

RC-Standard

TaxTreatment

Native tax configuration object; supports Avalara/Vertex integration or simple rate-based tax

TaxEngine — Avalara / Vertex / Native
TaxCode — product tax classification code
TaxExemptionCode — exemption handling

RC-Standard

🔄

Migration Mapping: blng__ → Revenue Cloud

CPQ Billing Object (blng__)	Revenue Cloud Equivalent	Migration Notes
`blng__Invoice__c`	`Invoice`	Field mapping required; Status picklist values differ
`blng__InvoiceLine__c`	`InvoiceLine`	Direct 1:1 mapping; tax fields renamed
`blng__BillingSchedule__c`	`BillingSchedule`	Event-driven model — NextBillingDate logic changes
`blng__BillingTreatment__c` + `blng__BillingRule__c`	`BillingPolicy` + `BillingTreatment`	Two blng objects collapse into two RC objects but with different hierarchy
`blng__PaymentMethod__c`	`PaymentMethod`	Gateway token format may differ per connector version
`blng__Payment__c`	`Payment`	Status picklist values and gateway response fields differ
`blng__PaymentAllocation__c`	`PaymentApplication`	Object renamed; relationship to InvoiceLine slightly different
`blng__RevenueSchedule__c`	`RevenueSchedule`	Direct equivalent; recognition rule field mapping required
`blng__RevenueDistribution__c`	`RevenueTransaction`	Object renamed; Status values differ (Unposted → Pending)
`blng__CreditNote__c`	`CreditMemo`	Functionality equivalent; application logic differs
`blng__TaxIntegration__c`	`TaxTreatment`	RC uses product-level TaxTreatment vs. global integration record
(no equivalent)	`FinanceTransaction`	New RC object — enables native ERP sync without custom middleware

💡

Key Takeaway — 5.3

The data models are conceptually equivalent — every blng__ object has a direct RC counterpart. The key advantage of RC is the elimination of the custom namespace, which reduces integration complexity, simplifies SOQL queries, and improves platform maintainability. The addition of FinanceTransaction as a native ERP bridge is the most architecturally significant new object in the RC model.

5.4

Automations

CPQ Billing Automations

Invoice Run Batch Job — scheduled Apex batch (blng__InvoiceRun__c) processes all billing schedules due for invoicing; can be run manually or on a cron schedule
Payment Gateway Triggers — Apex triggers fire on Invoice Posted status to initiate charge via gateway API; response written back to blng__Payment__c
Revenue Recognition Batch — nightly/monthly batch posts blng__RevenueDistribution__c entries for scheduled periods
Dunning Automation — Flow or Process Builder sends reminder emails on aging thresholds; escalation to Collections team via Task/Case creation
Credit Note Generation — triggered on Order cancellation or amendment; auto-creates blng__CreditNote__c and reverses revenue distributions
Tax Calculation — callout to Avalara AvaTax or Vertex on invoice creation; tax amounts written to blng__InvoiceLine__c.blng__TaxAmount__c

Revenue Cloud Automations

Event-Driven Invoice Generation — no batch required; Invoice is generated automatically when billing schedule event fires or trigger condition is met
Payment Orchestration Flows — native Flow-based orchestration handles retry logic, payment method fallback, gateway routing rules
Policy-Based Rev Rec — recognition schedules generated automatically from BillingPolicy; RevenueTransaction records posted on accounting date
ERP Sync via FinanceTransaction + Platform Events — FinanceTransaction records published as Platform Events for downstream ERP consumption without custom middleware
Automated Dunning Flows — native Dunning management with configurable escalation levels, communication templates, and hold/dispute flags
Native Tax Calculation — TaxTreatment object supports real-time tax calculation; Avalara/Vertex integration is tighter and configuration-driven rather than code-driven

Automation Type	CPQ Billing Approach	Revenue Cloud Approach	Advantage
Invoice generation trigger	Scheduled batch (`blng__InvoiceRun__c`); batch window delay of minutes to hours	Event-driven; invoice generated immediately when billing event fires	RC — real-time
Payment charging	Apex trigger on Invoice Post; custom gateway callout logic	Native payment orchestration Flow; configurable retry & routing	RC — no-code config
Revenue recognition posting	Nightly batch job; `blng__RevenueDistribution__c` records posted in bulk	Policy-driven automatic posting; `RevenueTransaction` created on accounting date	Comparable
ERP journal entry sync	Custom MuleSoft / REST integration; no native bridge object	`FinanceTransaction` + Platform Events; configurable ERP connector	RC — native bridge
Dunning / collections	Flow/Process Builder–based; aging thresholds trigger email alerts	Native Dunning Management with escalation levels and hold flags	RC — native
Tax calculation	Apex callout on invoice creation; error handling is custom	Config-driven `TaxTreatment`; Avalara/Vertex adapter built into RC	RC — less code
Credit note / cancellation	Triggered by Order cancellation Flow; Apex reversal logic required	Native CreditMemo generation; auto-reversal of RevenueTransactions	RC — native
Invoice approval workflow	Standard Approval Process or Advanced Approvals add-on	Flow-based approval with native Invoice status management	Comparable
Usage-based billing aggregation	Custom Apex + usage data ingestion; no native aggregation	Usage Summaries + native aggregation rules in BillingSchedule	RC — native
Multi-currency conversion	Standard Salesforce multi-currency; Billing handles conversion on invoice	Native multi-currency with exchange rate management in BillingPolicy	Comparable

💡

Key Takeaway — 5.4

Revenue Cloud's event-driven invoice architecture and native FinanceTransaction ERP bridge eliminate two of the most common pain points in CPQ Billing implementations: batch job management and custom ERP integration middleware. For architectures requiring real-time invoicing or tight ERP coupling, RC provides a significantly lower total-cost-of-ownership automation model.

5.5

Configuration (Architect Setup Level)

Effort estimates reflect architect-level setup complexity for a standard mid-market deployment. Estimates assume a greenfield implementation with no legacy data migration.

Configuration Task	CPQ Billing Effort	RC Effort	Notes
Billing rule / treatment setup	High	Medium	CPQ requires configuring `blng__BillingRule__c` + `blng__BillingTreatment__c` per product with many inter-related fields; RC's `BillingPolicy` is more guided via setup UI
Invoice template design	Medium	Medium	CPQ uses Visualforce/HTML templates via `blng__InvoiceDocument__c`; RC uses LWC-based invoice rendering — both require front-end skill
Payment gateway integration	High	High	Both require gateway package installation, credential setup, named credentials, and gateway-specific field mapping. RC has a more standardized adapter pattern but complexity is similar
Tax engine integration (Avalara / Vertex)	Medium	Medium	Both require installing the connector package, configuring tax codes on products, and mapping company codes. RC's `TaxTreatment` is slightly more declarative
Revenue recognition policy setup	High	Medium–High	CPQ Billing rev rec requires understanding recognition rules, distribution methods, and posting schedules across multiple objects; RC provides a more guided setup wizard but multi-SSP scenarios remain complex
ERP integration	Very High	High	CPQ requires fully custom MuleSoft/REST integration; RC's `FinanceTransaction` + Platform Events provides a standardized data model but still requires ERP-side development and field mapping
Dunning workflow setup	Medium	Medium	CPQ relies on standard Flow with aging field criteria; RC's native Dunning Management is more feature-rich but has a steeper learning curve for first-time configurators
Multi-currency billing	High	High	Both require Advanced Currency Management + careful handling of exchange rate timing on invoices and rev rec entries. Testing effort is substantial on both platforms
Invoice scheduler configuration	Medium	Low	CPQ requires configuring and monitoring the Scheduled Invoice Run batch job; RC is event-driven — no scheduler configuration needed, eliminating a recurring operational concern
Credit note / adjustment setup	Medium	Medium	CPQ requires configuring credit note triggers and revenue reversal logic; RC's native CreditMemo handles reversal automatically but requires policy configuration for proration
Usage-based billing configuration	Very High	High	CPQ has no native usage aggregation — requires custom objects and Apex; RC provides Usage Summaries and native aggregation rules, substantially reducing custom code
Customer payment portal (Experience Cloud)	High	High	Both require Experience Cloud setup + custom LWC components for invoice display and payment entry. RC's standard objects simplify the data access layer slightly

ℹ️

Effort Scale Reference

Low = 1–3 days | Medium = 1–2 weeks | High = 3–6 weeks | Very High = 6+ weeks including testing. All estimates assume an experienced Salesforce billing architect and do not include UAT or data migration.

💡

Key Takeaway — 5.5

RC reduces configuration effort most significantly in three areas: billing rule setup (guided UI vs. multi-object configuration), ERP integration (native FinanceTransaction vs. fully custom), and invoice scheduler management (event-driven vs. batch job monitoring). The largest residual complexity areas — payment gateway integration, multi-currency, and ERP development — remain High effort on both platforms.

5.6

Customization (Common Additions)

CPQ Billing — Common Customizations

Custom Invoice PDF Templates — HTML/Visualforce templates rendered via blng__InvoiceDocument__c; often requires custom CSS for brand compliance and Apex for dynamic data merging
Apex Triggers for Complex Billing Logic — triggers on blng__BillingSchedule__c or blng__Invoice__c for custom proration, tiered usage calculations, or cross-product billing rules
Custom Payment Processing Middleware — when native gateway connectors are insufficient; full custom Apex callout to payment processor with custom error handling and retry logic
Custom Dunning Flow Overrides — complex escalation trees (dispute holds, account suspension, partial payment plans) often require Apex-backed Flow actions
ERP Integration via MuleSoft or Custom REST — most Billing implementations require a full custom integration layer to push invoice, payment, and rev rec data to SAP, NetSuite, or Oracle; typically the highest-effort customization in the stack
Custom Revenue Recognition Rules — Apex-based recognition rule overrides for milestone billing, percentage-of-completion contracts, or variable consideration scenarios not supported by standard rec rules

Revenue Cloud — Common Customizations

Custom Invoice Rendering via LWC — Experience Cloud–based invoice display components; LWC replaces Visualforce for customer-facing templates; allows reactive UI without Apex page controllers
Complex Rev Rec Overrides via Flow — multi-SSP allocation overrides, variable consideration adjustments, and contract modification (ASC 606 catch-up) logic implemented in autolaunched Flows
Multi-Currency Billing Customizations — exchange rate override logic, functional currency reporting, and invoice currency locking at contract inception; typically requires custom fields + Flow on BillingPolicy
Custom ERP Connector Patterns — while FinanceTransaction provides the standard bridge, custom field mapping, account segment derivation (cost center, GL code), and error retry patterns are still implementation-specific
Advanced Tax Calculation Overrides — jurisdiction-specific tax exemption logic, marketplace facilitator rules, and tax certificate management require custom TaxTreatment extensions or Apex callout overrides
Usage Data Ingestion Pipeline — custom APIs or MuleSoft flows to ingest metered usage data into UsageSummary records for aggregation-based billing

🚫

Anti-Patterns: Common Billing Setup Mistakes

⚠️ CPQ Billing Running Invoice Runs too frequently — scheduling Invoice Runs every hour creates massive batch job contention, governor limit pressure, and orphaned billing schedule locks. Run at daily or business-period intervals appropriate to your SLA.
⚠️ CPQ Billing Storing raw card numbers or gateway credentials in custom fields — never store PAN data in Salesforce fields. Always use tokenized blng__PaymentMethod__c.blng__GatewayToken__c references. PCI DSS scope creep is a significant risk in custom payment implementations.
⚠️ Both Bypassing the billing/rev rec object model for ERP integration — directly reading Invoice/RevenueDistribution data from custom SOQL in integration middleware, rather than using the FinanceTransaction (RC) or dedicated ERP events (CPQ), creates brittle integrations that break on platform upgrades.
⚠️ Revenue Cloud Not configuring BillingPolicy before activating Orders — in RC, BillingPolicy must be associated to the product/contract before Order activation. Retroactively applying a BillingPolicy to activated orders requires data remediation and can result in missed billing events.
⚠️ Both Manually editing Posted invoices — modifying a Posted blng__Invoice__c or RC Invoice directly (rather than issuing a credit note and re-billing) corrupts the audit trail and breaks ASC 606 compliance. Always use the platform-supported credit/re-bill pattern.
⚠️ CPQ Billing Using a single global BillingRule for all products — applying one BillingRule to all product types (one-time, subscription, professional services) creates incorrect invoice timing and proration. Define distinct BillingTreatments per charge type.
⚠️ Revenue Cloud Overriding RevenueTransaction records via DML in triggers — RC's revenue engine expects to own the lifecycle of RevenueTransaction records. Custom DML manipulation outside of platform-supported overrides causes reconciliation errors and breaks the FinanceTransaction export pipeline.
⚠️ Both Ignoring multi-currency exchange rate timing — using the current exchange rate (rather than the contract inception rate) for revenue recognition in multi-currency contracts produces ASC 606 non-compliance. Lock exchange rates at the BillingSchedule or Contract level at inception.

Customization Need	CPQ Billing Pattern	Revenue Cloud Pattern
Invoice PDF / HTML rendering	Visualforce page bound to `blng__InvoiceDocument__c`; Apex controller for dynamic merge fields	LWC component in Experience Cloud; data fetched via wire adapters from `Invoice` / `InvoiceLine`
Complex billing logic override	Apex trigger on `blng__BillingSchedule__c` before/after insert; may require queueable for async operations	Record-triggered Flow on `BillingSchedule` with Apex action for complex logic; prefer Flow-first
Payment retry / fallback	Custom Apex queueable; no native retry framework — must handle all gateway error codes manually	Payment Orchestration Flow with native retry config; gateway error codes mapped to Flow branching
ASC 606 multi-SSP allocation	Apex-based custom rec rule override; complex formula logic for standalone selling price allocation	Autolaunched Flow invoked by RevenueSchedule creation; SSP tables stored as custom metadata
ERP data push	MuleSoft ESB or custom REST callout from Apex; full custom field mapping and error handling	`FinanceTransaction` Platform Event subscription by ERP connector; standardized schema reduces mapping effort
Usage metering ingestion	Custom `UsageData__c` object + Apex aggregation to drive billing schedule quantity updates	Native `UsageSummary` object; REST API endpoint for metering system to push aggregated usage data

💡

Key Takeaway — 5.6

Revenue Cloud shifts billing customization from primarily Apex-driven to Flow-first with Apex as an escape hatch, reducing the dependency on Salesforce developers for billing configuration changes. The biggest reduction in custom code comes from the native payment orchestration framework and the FinanceTransaction ERP bridge. However, complex ASC 606 scenarios (multi-SSP, variable consideration, contract modifications) remain highly customized on both platforms — architect involvement is required regardless of the billing engine chosen.