Order-to-Cash Process in ERP and Salesforce

Order-to-cash is a cross-system lifecycle by design. From a Salesforce consultant perspective, Salesforce typically owns the pre-order commercial workflow, while ERP owns the post-order operational and financial workflow. Salesforce’s object model frames Opportunity as managing a sale or pending deal, and it can be synced with a child Quote. A Quote is a record of proposed prices for products and services, which positions it as commercial intent rather than a posted financial outcome.

Across major ERP vendors, order-to-cash is described as progressing from order through fulfilment into invoicing, receivables, payment, and revenue or financial accounting. For example, Oracle Cloud Order Management explicitly describes an order-to-cash flow where inventory and logistics handle scheduling and shipping, receivables prepares billing details, and Oracle Financials creates invoices, manages accounts receivable, processes payments, and manages revenue. SAP’s reference flow similarly shows outbound delivery, shipping, invoice creation based on delivery, and updates to financial accounting. Microsoft’s guidance states that invoicing posts to the general ledger and continues through receiving payment. NetSuite’s overview defines O2C as spanning order management and fulfilment, billing, payment processing, and reporting, and it explicitly notes the need to integrate functions and data across business areas.

For organizations designing the broader connection beyond O2C, our guide to integrating Salesforce with ERP systems explains the main data flows, integration methods, architecture patterns, and system considerations involved.

The architectural risks that actually break O2C integrations are well-documented in the official platform and middleware references:

Platform Events can produce duplicates, and Salesforce defines a duplicate event as having the same EventUuid with a different ReplayId and the same payload.

Event retention is bounded. Salesforce documents 72-hour durability for platform events and change data capture events when using the Pub/Sub API, and CDC messages are stored in the event bus for three days.

CDC is intended for keeping downstream systems in sync, and Salesforce cautions against using it to update the UI for many users because concurrent client limits can be hit.

Middleware retry features will replay work. Boomi’s retry schedules automatically rerun failed documents. MuleSoft’s idempotent message validator is explicitly designed to ensure only unique messages proceed, based on a unique identifier.

A correct, scalable O2C integration, therefore, needs three things more than anything else:

A clear system of record per O2C stage, enforced by field ownership rules.

Transaction boundaries that separate “commit in Salesforce” from “commit in ERP,” and that avoid cross-system false atomicity.

End-to-end idempotency and replay strategies, built around external IDs, upsert semantics, EventUuid deduplication, and a reconciliation loop for anything older than retention.

The rest of this report turns those principles into concrete tables, design rules, and failure-mode mitigations.

O2C Reference Model and System Interaction

O2C stages in this report follow the lifecycle that the enterprise systems describe, mapped onto the typical Salesforce and ERP split: Opportunity, Quote/CPQ, Order, Fulfilment, Invoice, Payment, Revenue.

ERP documentation is consistent that post-order steps have operational dependencies and accounting consequences:

Oracle describes order orchestration and downstream services, including inventory logistics (schedule, reserve, ship) and financial transactions where invoices are created and revenue is managed.

SAP’s process explicitly links outbound delivery and shipping to invoicing based on delivery, with updates to financial accounting.

Microsoft describes invoicing as creating and sending a bill and posting it to the general ledger, continuing through delivery and receiving payment.

NetSuite frames O2C as requiring integration across order management, shipping, accounts receivable, and reporting.

Oracle also documents the standard “order capture system” relationship: Order Management updates order status, order line status, and invoice status and communicates updates to the upstream order capture system. That upstream system is commonly Salesforce in CRM-led architectures.

End-to-End Flow

System Responsibilities Table

This is the concise responsibility split that aligns with both Salesforce’s object framing and ERP O2C descriptions.

System	Responsibilities in O2C	The boundary you must enforce
Salesforce	Commercial workflow: opportunities and proposed quotes.	Do not treat Salesforce totals as the posted financial truth after invoicing.
ERP (examples: Oracle, SAP, Microsoft, NetSuite)	Sales order execution, fulfilment, invoicing, receivables, payment, revenue or accounting updates.	ERP is the financial source of truth for invoices, payment applications, and revenue outcomes.
Middleware (examples: MuleSoft, Boomi	Orchestration, buffering, retries, transformations, dead-letter handling, and deduplication controls.	Middleware must not create duplicates when replaying or retrying. Use idempotency.

Data flows table

This table is intentionally concise: it lists the minimum flows that determine O2C correctness. The “why” comes from Salesforce integration patterns and ERP O2C descriptions.

Flow	Direction	Payload focus	Correlation key	Typical trigger
Customer master sync	ERP → Salesforce	Customer identifiers, bill-to/ship-to, credit flags	ERP customer ID stored in Salesforce external ID field for upsert.	ERP create or updates
Product and reference data	ERP → Salesforce	Item codes, UoM, list price basis	ERP item code and pricebook mapping	Scheduled or event-driven
Quote to order submission	Salesforce → ERP	Order intent, line breakdown, quoted pricing snapshot	Salesforce submission ID carried into ERP as an idempotency key	Quote accepted
Order status updates	ERP → Salesforce	Order status, line status, exceptions	ERP order number stored in Salesforce	ERP state transition, Oracle explicitly describes status updates back to order capture.
Fulfilment updates	ERP → Salesforce	Shipment events, delivered quantity	ERP fulfilment line IDs	Ship confirm
Invoice sync	ERP → Salesforce	Invoice header, totals, tax, status	ERP invoice ID	Invoice posted, Microsoft notes invoice posting to GL.
Payment status sync	ERP → Salesforce	Receipt applied, outstanding balance	ERP receipt ID or applied invoice ID	Payment applied to AR
Revenue indicators	ERP → Salesforce	High-level revenue recognition status is required	ERP revenue schedule IDs	Revenue event

System-of-record and ownership rules

A system-of-record model is the primary control that prevents O2C integrations from becoming circular and inconsistent. Salesforce’s integration patterns explicitly assume that the calling system tracks state based on remote responses, and for “fire and forget,” the remote system can update Salesforce in a separate transaction. Oracle’s order capture integration description similarly expects the downstream system to communicate order and invoice status back upstream.

Choosing the right ERP data synchronization model for Salesforce is equally important, as the direction, frequency, and ownership of each data flow determine how reliably CRM and ERP records remain aligned.

System-of-record table by O2C stage

The table reflects the most common enterprise split: Salesforce owns the commercial stages; ERP owns execution and financial stages. Each row includes the minimal “what Salesforce stores” rule that avoids ownership collisions.

O2C stage	System of record	What Salesforce should store	What ERP should store
Opportunity	Salesforce	Opportunity, pipeline stage, linkage to quote.	Not required
Quote/CPQ	Salesforce	Quote and quote line breakdown as proposed prices.	Optional: pricing reference or acceptance response
Order	ERP	ERP order number and last known ERP status, plus immutable submission snapshot	Sales order, orchestration states, holds and release reasons.
Fulfilment	ERP	Customer-visible fulfilment state, but derived and non-editable	Fulfilment execution, shipment and inventory movements.
Invoice	ERP	Invoice visibility fields (status, totals) without allowing overwrite	Invoice creation and posting, tax, GL impact.
Payment	ERP	Payment status and outstanding balance summaries	Receipt capture or import, application to AR.
Revenue	ERP	Revenue indicators are only needed operationally	Revenue or accounting outcomes as part of O2C completion.

Ownership rules table

This table is concise by intent: it is designed to be pasted into an integration spec and enforced in code and middleware mappings. External ID upsert and EventUuid deduplication are the guardrails because retries and duplicate events are expected conditions.

Data group	Authoritative owner	Sync direction	Write a rule in Salesforce	Collision prevention
Customer identifiers	ERP	ERP → Salesforce	Upsert by ERP customer external ID.	Never allow Salesforce to rewrite ERP identifiers
Product codes and UoM	ERP or PIM	ERP → Salesforce	Reference only; changes originate in ERP	Reject “dual maintenance”
Quoted prices	Salesforce	Salesforce → ERP	Immutable quote snapshot per submitted order	Never overwrite quote snapshot with invoice totals
ERP order status	ERP	ERP → Salesforce	Update by ERP order number external ID	Treat status changes as append-only transitions
Invoice totals and tax	ERP	ERP → Salesforce	Update by ERP invoice ID external ID	Keep billed amounts separate from quoted amounts
Event messages	Publisher	N/A	Deduplicate consumers using EventUuid.	Store processed EventUuid to prevent reprocessing

Data Ownership

Field-level rules that prevent loops

Two platform features are worth calling out because they directly enable loop prevention if you use them deliberately:

Platform Events in processes and flows can cause infinite loops if you publish the same event that starts the process. Salesforce explicitly warns about this and advises designing to avoid endless loops.

CDC includes information in the change event header, such as the origin of the change, which allows ignoring changes generated by your own client, and Salesforce documents the change event header fields.

In practice, this means every writeback from ERP should carry an origin marker and every Salesforce outbound integration should suppress republishing when it is processing an inbound update.

Integration patterns and trade-offs

Salesforce documents and names the core integration patterns, including Remote Process Invocation in both request-reply and fire-and-forget styles. Those are not academic labels. They map to concrete O2C decisions, such as whether order submission must block the user until an ERP response is returned, or whether you accept eventual consistency and show status later.

Salesforce’s event tooling comes with explicit constraints:

Platform event consumers should use EventUuid to match published and received event messages, and Salesforce documents what a duplicate event is and recommends handling duplicates.

Event durability is time-bounded. Salesforce stores platform events and CDC for 72 hours when using the Pub/Sub API, and CDC messages are stored for three days.

Salesforce positions CDC as a downstream sync tool and cautions against using it for UI updates at scale due to concurrent client limits. 

Salesforce describes the event bus as a time-ordered event log and states that it stores and delivers event messages in the order received by Salesforce. 

Middleware orchestration has its own explicitly documented behaviours:

MuleSoft defines reliability patterns as designs that provide reliable messaging even when inputs are non-transactional, and it separates reliable acquisition from business logic flow.

 MuleSoft’s idempotent message validator checks a unique ID and prevents duplicates from progressing.

Boomi retry schedules automatically rerun failed documents, regardless of whether an execution was scheduled or started manually.

Boomi’s Salesforce Platform Events connector runs in singleton mode by default in clusters, which influences high availability and throughput design.

Integration Architecture

Integration pattern comparison table

The “operational cost” column is about runtime and support burden: monitoring, replay handling, and incident response effort. The trade-offs are grounded in Salesforce’s integration patterns, event durability and duplication semantics, CDC positioning, and middleware retry and idempotency features.

Pattern	Latency	Consistency profile	Complexity	Operational cost	Typical O2C use
API real-time request-reply	Lowest	Strong immediate feedback, but only within the synchronous transaction boundary that Salesforce can sustain.	Medium	Medium. Timeouts and retries must be engineered.	Credit validation, address validation, ERP “accept order” confirmation
Platform Events	Low to medium	Eventual consistency with bounded retention and possible duplicates.	Medium to high	High. Requires dedup, replay tracking, and reconciliation.	Order submission events, fulfilment notifications, and invoice posted notifications
Change Data Capture	Low to medium	Near-real-time change stream, retained for three days; intended for downstream sync, not UI scale.	High	High. Requires initial load, plus delta processing, plus gap recovery.	Master data replication, integration, cache updates, and analytics feeds
Middleware orchestration	Medium	Depends on orchestration design; typically eventual with buffering and explicit retries.	Highest	Highest, but concentrated in one layer with DLQ and replay tools.	Multi-system orchestration across ERP, WMS, billing engines, and payment systems

Transaction boundaries, retries, idempotency, and throughput

This section focuses on the mechanics that make O2C correct under retries, duplicates, and volume.

Transaction boundaries that match actual system guarantees

Salesforce’s composite request support includes explicit behaviour for rollback when subrequests fail, using allOrNone. That is a true transaction boundary inside Salesforce, but it does not extend into ERP systems. For cross-system work, Salesforce’s integration patterns frame request-reply versus fire-and-forget specifically to set expectations about synchronous completion versus asynchronous follow-up.

A correct O2C boundary design makes these rules explicit:

Commit the commercial intent in Salesforce first, then integrate. This gives you a durable submission record that can be retried without user dependence. The need is implied by the separation between Salesforce transaction semantics and remote invocation patterns.

Treat ERP order creation as authoritative, and store the ERP order number back in Salesforce for ongoing state tracking, consistent with Salesforce’s “track state based on the response” language and Oracle’s “communicate status updates back to order capture system” model.

Retry and idempotency strategies

Idempotency is not optional in O2C, because both platform and middleware layers explicitly include retry and duplicate behaviours.

Salesforce API idempotency via upsert

Salesforce documents upsert by external ID, where the same request can create or update based on an external ID field value. For bulkified write patterns, Salesforce documents sObject Collections upsert for up to 200 records per request.

Event consumer idempotency via EventUuid

Salesforce documents EventUuid as the identifier to match event messages, and it defines duplicate events by EventUuid reuse. Consumer logic should therefore key on “already processed” state by EventUuid, not ReplayId.

Middleware idempotency and replay controls

MuleSoft’s idempotent message validator blocks duplicate message IDs by design.

MuleSoft’s reliability patterns explicitly separate reliable acquisition from processing, which is the standard design to avoid message loss when sources are non-transactional.

Boomi retry schedules rerun failed documents automatically, which increases successful completion but also increases the chance of duplicates unless endpoints are idempotent.

Throughput and volume considerations

Salesforce’s scaling guidance for data operations is explicit:

Bulk API 2.0 is recommended for data operations over 2,000 records, while smaller jobs should use bulkified synchronous calls such as Composite.

Composite sObject Collections upsert supports up to 200 records per request.

Apex and platform execution are governed by transaction limits, documented in Salesforce’s limits references. 

Event-driven throughput is constrained by retention and allocation behaviour:

Salesforce stores platform events and CDC for 72 hours when using Pub/Sub API, which defines your maximum offline recovery window without backfill.

CDC messages are stored for three days in the event bus, reinforcing the same recovery window.

Operationally, API usage limits and monitoring matter because O2C integrations can create burst traffic during catch-up and retries. Salesforce provides official guidance on monitoring API usage and limits.

Transaction boundary table

This table is intended to be implementable: each boundary becomes an integration step with defined idempotency keys and retry semantics. The guidance aligns with Salesforce’s integration pattern definitions and composite transaction rollback semantics. 

Boundary	Atomic in Salesforce	Atomic in ERP	Outbox pattern recommendation	Required idempotency key
Quote accepted	Persist submission record and snapshot; optionally use allOrNone within the Salesforce object graph.	Not applicable	Publish Platform Event after commit or enqueue middleware call	Salesforce submission ID + quote version
Order created	Store ERP order number on submission record via upsert	Create an order and return the ERP order number	ERP publishes status back to Salesforce asynchronously, consistent with fire-and-forget state tracking.	ERP order external ID
Invoice posted	Upsert invoice summary objects	Create invoice, post to GL.	ERP emits an invoice event or a status update	ERP invoice external ID
Payment applied	Upsert payment status	Apply receipts to AR	ERP emits a payment applied update	ERP receipt or applied invoice key

Failure scenarios with root causes and mitigations

The scenarios below are “real-world” in the sense that they follow documented platform and middleware behaviours that occur in production: duplicates, retention expiry, retries, and loop risks.

Duplicate orders created in ERP

What it looks like. Two ERP sales orders exist for one Salesforce submission, or one customer receives two shipments or two invoices.

Root causes. Salesforce documents that duplicate platform event messages can occur and defines duplicates via EventUuid reuse.
Middleware replay features rerun work. Boomi retry schedules rerun failed documents, which can trigger repeated order create calls if the ERP endpoint is not idempotent.
If an integration uses retries without a stable key, the same request can be interpreted as a new create each time, which is exactly what external ID upsert is designed to avoid.

Mitigations. Require a stable idempotency key on “create order” calls, and enforce uniqueness in ERP on that key, so retries become “return existing order.” This follows the same logic Salesforce uses for external ID upsert.
In middleware, deduplicate inbound events and requests using built-in idempotency filters. MuleSoft’s idempotent message validator exists specifically for this purpose.
In Salesforce, event consumers store processed EventUuid values and reject repeats. Salesforce explicitly provides EventUuid for matching and recommends handling duplicates.

Salesforce shows “submitted”, but ERP created an order

What it looks like. The user submits an order. Salesforce never receives the ERP order number. Later, ERP fulfilment and invoices exist, but Salesforce cannot correlate them.

Root causes. Request-reply integrations can fail after the remote side commits but before Salesforce receives or persists the response. Salesforce’s remote invocation patterns assume state tracking based on the response, but they do not eliminate network failure.
Event-driven writebacks expire if not consumed within retention. Salesforce stores platform events and CDC for 72 hours, which means “no consumer for three days” becomes “no event.”

Mitigations. Use a durable submission record as the source of truth for “what was asked,” and reconcile by querying ERP for any records with the submission ID stored as a foreign key, which matches the Oracle “order capture system” expectation of status updates and correlation.
Add a scheduled reconciliation job that checks any “submitted but not acknowledged” records and either replays safely (idempotently) or pulls the ERP order number and status. This is consistent with CDC being positioned as part of a downstream sync strategy rather than a full audit trail.

Missing fulfilment or invoice updates after downtime

What it looks like. Salesforce shows stale fulfilment or invoice status after a middleware outage or subscriber disconnect.

Root causes. Event durability is bounded. Salesforce documents 72-hour retention for platform events and CDC in Pub/Sub durability guidance, with CDC stored for three days.
CDC is intended for downstream sync, and Salesforce notes it is not recommended for UI updates for many users at scale, which often correlates with subscriber proliferation and fragility. 

Mitigations. Treat the event stream as a delta feed inside the retention window, and treat scheduled backfill queries as the authoritative recovery mechanism outside that window. The need for reconciliation is implied by bounded retention and CDC positioning.
Monitor consumer lag and disconnects, because the only guaranteed recovery is within retention. Salesforce provides event durability and retention documentation specifically so consumers can recover after disconnects. 

Infinite loops from event publishing

What it looks like. A flow subscribes to a platform event and republishes the same event, causing runaway executions and limit breaches.

Root causes. Salesforce explicitly warns that publishing events from processes or flows can create an infinite loop and exceed limits, and it gives a concrete example pattern.

Mitigations. Include a loop guard field or header flag, and prevent republishing when processing an event-driven update. This is the direct remedy implied by Salesforce’s warning.
When using CDC, use the change event header “origin” data to ignore changes generated by your integration client, which Salesforce explicitly positions as a use case for header data.

Pricing mismatch between the quote and the invoice

What it looks like. The customer disputes the invoice totals because they do not align with the quote.

Root causes. Salesforce CPQ price rules can update fields on the quote, quote line group, or quote line based on conditions. This enables complex pricing logic at quote time.
Oracle’s order-to-cash description includes pricing and receivables integration, including sending charge line values to receivables so charges like tax can be calculated correctly.
Microsoft’s invoice process explicitly posts to the general ledger, so invoice totals have accounting consequences that quotes do not.

Mitigations. Store “quoted” and “billed” measures separately in Salesforce and explain the variance, rather than overwriting the quote with the invoice. The separation follows from the quote being proposed prices and the invoice being posted to GL in ERP.
Reconcile pricing at two points: order acceptance and invoice posting. Oracle’s integration guidance around sending charge values to receivables highlights that charges and tax treatment can differ downstream. 

API limit exhaustion during catch-up

What it looks like. A backlog flush triggers API spikes and failures, and downstream systems miss updates or create duplicates during reprocessing.

Root causes. Salesforce documents API request limits and provides guidance for monitoring API usage and limits.
Salesforce positions Bulk API 2.0 for large jobs and Composite for smaller jobs, which is the intended lever to reduce API call pressure.

Mitigations. Throttle replay and apply backpressure using middleware queues rather than unbounded retries. MuleSoft’s reliability patterns describe reliable acquisition and decoupling of processing, which is the standard way to buffer and control throughput.
Use Bulk API 2.0 for large backfills and composite upsert for smaller, consolidated writes.

Salesforce CPQ and pricing reconciliation

This section isolates CPQ because it changes the O2C integration profile: quoting is no longer just a set of lines and a total; it becomes an executable rules engine that shapes downstream payloads.

What CPQ changes in O2C integration

Salesforce’s CPQ guidance and training make two points that matter for integration:

Price rules can conditionally update fields on the quote, quote line group, or quote line, following an if/then structure.

Salesforce CPQ extends the Contract object to store subscription-related information and creates contracts when contracting an opportunity or order with at least one renewable subscription quote line. 

From a solution-architect point of view, this means the quote output is both a pricing artefact and a long-lived subscription and entitlement artefact, and both aspects may need ERP alignment.

CPQ training also warns about pricing calculation pitfalls, such as recursive calculations and recommends safe targeting choices for price rule fields. That matters because erroneous quote calculations propagate into downstream order payloads.

Organizations that need external expertise for these architectures can also compare Salesforce ERP integration companies based on their Salesforce capabilities, ERP experience, middleware expertise, and ability to support complex cross-system workflows.

Pricing authority and reconciliation model

ERP vendors describe charge and tax calculation as part of downstream financial processing. Oracle explicitly describes sending charge and charge line values to receivables so the receivables system can calculate charges such as tax on shipping. Microsoft explicitly ties invoicing to posting in the general ledger. These descriptions imply that invoice totals are not merely informational outputs but accounting events.

A practical reconciliation model that avoids data ownership conflicts is therefore:

 Quoted amounts are owned by Salesforce and remain immutable snapshots of what was proposed and accepted. This aligns with the Quote object’s definition as proposed prices. 

Billed amounts are owned by ERP and are stored in Salesforce only for visibility, without overwriting quoted values. This aligns with ERP invoicing being posted to GL and the ERP being responsible for O2C financial completion.

Reconciliation needs explicit variance data, not silent overwrites:

Store billed totals, tax, and invoice status keyed by ERP invoice ID via external ID upsert, which is the designed Salesforce mechanism for safe retries.

Calculate variance in Salesforce reporting as billed minus quoted, and route exceptions to an operational queue if variance exceeds tolerance.

Pricing payload guidance for order submission

Because CPQ price rules can update many fields at quote time, a minimal reliable payload should include:

Product identifiers aligned to ERP item codes. NetSuite and Oracle both emphasise cross-functional integration in O2C, which in practice requires product and customer master alignment.

Pricing breakdown sufficient to explain downstream charges. Oracle’s receivables integration guidance explicitly focuses on sending charge line values so taxes and charges can be calculated correctly.

 A stable idempotency key for the submission record, because middleware retries and event duplicates are expected