Pattern · Integration
Keeping the ERP boundary clean
Decide what Revenue Cloud owns and what the ERP owns, before the integration decides for you.
The problem
Revenue Cloud and an ERP both have an opinion about orders, products and invoices. Without an explicit boundary, both end up partially authoritative and reconciliation becomes permanent work.
Context
An existing accounting system that finance will not replace, and a Revenue Cloud implementation that needs to own quoting and billing.
Recommended architecture
Draw the boundary at a record, not at a field. A workable split: Revenue Cloud owns everything up to the posted invoice; the accounting system owns the journal from there. The handover is the posted invoice plus its ledger assignment — which is why ledger routing is worth getting right inside Salesforce rather than in the integration.
Where an ERP must stay the system of record for orders, the inverse split also works: Revenue Cloud is used upstream for configuration and quoting only, and an existing Salesforce object continues to serve as the ERP interface. That keeps the integration untouched while the quoting experience is modernised.
Implementation
Write the boundary down as a list of records with one owner each, and have finance sign it. Every later argument about a field reduces to “which side of the line is this record on”.
Trade-offs
Keeping an existing object as the ERP interface is less elegant than a clean Revenue Cloud order, and it means two order-shaped things exist. It is often the right call anyway, because it decouples the Revenue Cloud rollout from an ERP integration project that nobody wants to reopen.
Watch out
- Decide where invoice numbering lives before the first invoice is posted. Moving it afterwards is a migration, not a setting.
Salesforce components
Salesforce resources
Architecture
Guide