Salesforce Revenue Cloud does the front of the revenue stack: quoting, ordering, billing, revenue recognition. It does not handle the general ledger, accounts payable, accounts receivable reconciliation, or the dozen other functions that an ERP system provides. Most B2B businesses run both: Revenue Cloud for the customer-facing motion, NetSuite or SAP or Oracle Financials for the financial system of record.
The integration between the two is one of the most operationally important pieces of the Revenue Cloud implementation. The decisions about which events flow when shape monthly close speed, cash reconciliation accuracy, and audit readiness.
The events that need to flow
Salesforce-to-ERP:
- Invoice posted. Revenue Cloud generated an invoice. ERP needs to know to add it to Accounts Receivable.
- Payment received (if cash handled in Salesforce). Customer paid. ERP needs to update AR and post cash receipt.
- Credit memo issued. Customer was refunded or credited. ERP needs to reduce AR.
- Revenue recognized. Revenue Schedule entry fired. ERP needs to post the corresponding journal entry.
- Customer master sync. New customer created in Salesforce. ERP needs the customer record to issue invoices against.
ERP-to-Salesforce:
- Payment received (if cash handled in ERP). Payment recorded in ERP. Salesforce needs to update the invoice status.
- Customer credit hold or status changes. Customer is on credit hold. Salesforce sales motion should know before quoting.
- GL postings (for reconciliation). Salesforce reconciles its records against ERP postings.
Each event has different timing requirements, different data volumes, and different failure handling needs.
Pattern 1: Real-time event-driven
Salesforce events fire to the ERP as they happen. Invoice posted in Salesforce produces an immediate API call to ERP creating the AR Invoice. Payment received fires an immediate update.
Pros:
- Data sync is near-instant. The ERP shows current state.
- Stakeholders looking at ERP see what Salesforce shows.
- No batch window delay.
Cons:
- Tight coupling between systems. If the ERP is unavailable, Salesforce operations can be affected.
- Retry logic must be robust. Network failures, ERP downtime, and rate limits all require handling.
- Higher API call volume to the ERP. Cost and rate limit implications.
When to use:
- Programs where cash flow speed matters and AR delays are unacceptable.
- High-transaction-volume businesses where batch delays accumulate.
- Customer-facing portal scenarios where ERP-side status (paid, credit hold) needs to be visible immediately.
Pattern 2: Batch nightly
Salesforce events accumulate during the day. A nightly job exports the day's events as a batch file. ERP imports the batch in its overnight processing window.
Pros:
- Simple, robust. Batch failures are rerun. No coupling between Salesforce uptime and ERP uptime.
- Lower API volume. Cheap.
- Aligns with traditional ERP batch processing models.
Cons:
- Data sync is up to 24 hours delayed. Stakeholders looking at ERP see yesterday's state.
- Cash reconciliation lags by a day.
- Real-time customer-facing scenarios (e.g., "show me what I owe right now") are not supported.
When to use:
- Programs where 24-hour delay is acceptable.
- Lower-volume businesses where the daily batch is small enough to be manageable.
- Risk-averse implementations where simplicity beats freshness.
Pattern 3: Hybrid
Critical events flow real-time. Less-critical events flow batch. Each event type is classified by its time-sensitivity.
A typical hybrid map:
| Event | Pattern |
|---|---|
| Invoice posted | Real-time |
| Payment received | Real-time |
| Credit memo issued | Real-time |
| Customer master create/update | Batch (nightly) |
| Revenue Schedule entries (for GL posting) | Batch (monthly close) |
| Reporting data refresh | Batch (weekly) |
The hybrid pattern is the most common in production. Operational events that drive customer experience (invoicing, payment) flow real-time. Master data and reporting flow batch.
Pros:
- Balance of speed and simplicity.
- Real-time where it matters, batch where it does not.
Cons:
- More moving parts than a single-pattern setup.
- Each event needs explicit pattern assignment and corresponding implementation.
Reconciliation: the operational requirement
Whichever pattern is used, the two systems will drift. Reconciliation is the discipline that catches drift before it becomes audit findings.
Monthly reconciliation:
- For each invoice in Salesforce, confirm the corresponding AR record in ERP.
- For each payment in ERP, confirm the corresponding update in Salesforce.
- For each Revenue Schedule entry, confirm the corresponding GL journal entry.
Variances investigated and resolved. The process should be automated where possible; the manual version is a finance person spending days each month on it.
A reconciliation report that runs nightly is even better. Drift surfaces within 24 hours instead of at month end.
Customer master sync: the underappreciated complexity
Customer master data sync is the integration point that produces the most ongoing issues. The complexity:
- Same customer might have different IDs in Salesforce (Account ID) and ERP (Customer Number).
- Customer addresses, contacts, and credit terms live in both systems but should be authoritative in one.
- Customer hierarchies (parent-child) need to align between systems.
The right pattern: pick one system as the source of truth for each customer attribute. Salesforce typically owns contact, address, and sales-related fields. ERP typically owns credit limit, payment terms, and tax registration.
The integration syncs the attributes in the right direction. A change in the owning system propagates to the other. Changes in the non-owning system are rejected or logged for review.
Common ERP integration mistakes
Five patterns Sapota has seen in audits:
- Real-time everywhere. Every event fires real-time including master data updates. API costs balloon. ERP rate limits hit during peak hours.
- No reconciliation. Salesforce and ERP drift for months. Discovered at year-end audit. Reconstruction effort.
- Customer ID mismatch. Same customer has different IDs in the two systems with no canonical mapping. Manual lookups every time data needs to flow.
- Failure handling absent. ERP unavailable, Salesforce keeps trying, queue backs up. No alerts until users complain.
- No idempotency. Same event fires twice (network retry, manual replay). ERP posts duplicate invoice. Manual cleanup.
What good ERP integration looks like
A Salesforce Revenue Cloud ERP integration that holds up:
- Hybrid pattern with classification documented per event type.
- Real-time events with idempotency keys to prevent duplicates.
- Batch events with retry handling and failure alerts.
- Customer master with explicit source-of-truth per attribute.
- Nightly reconciliation report with documented variance threshold.
- Monthly closer reconciliation against ERP GL entries.
- Disaster recovery plan for extended ERP downtime.
ERP integration is one of the most operationally important parts of Revenue Cloud and one of the most easily under-scoped during implementation. Sapota's Salesforce team treats ERP integration as a multi-week workstream with explicit event mapping, reconciliation design, and failure handling on every implementation.
Designing or auditing ERP integration for Salesforce Revenue Cloud? Sapota's Salesforce team holds the Revenue Cloud Consultant credential and handles NetSuite, SAP, and Oracle integration on production engagements. Get in touch ->
See our full platform services for the stack we cover.
