quote → cash
EN/FR Contact

Pattern · Integration

Keeping the ERP boundary clean

Decide what Revenue Cloud owns and what the ERP owns, before the integration decides for you.

Salesforce docs documented by SalesforceField experience observed on a real orgRecommended pattern what we recommendTo verify unverified

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