Order-to-cash design
Salesforce ERP integration. Design the handover first, then automate it.
Most Salesforce-to-ERP projects fail as process decisions long before they fail as interfaces. Cloudmaven works out where your CRM should stop and your ERP should take over, covering quoting, pricing, sales order and invoicing, then connects the two with our own Salesforce connector on eUnify, our integration platform.
We design the process, not just the interface
The handover between Salesforce and your ERP is a set of decisions about where each step of order-to-cash belongs. We put those decisions in writing before anyone configures anything.
Our own connector, on our own platform
Built and maintained by Cloudmaven on eUnify, our integration platform, rather than licensed from a third party and passed on to you with its own support queue.
ERP-neutral by architecture
eUnify sits above the systems rather than inside one of them. Our deepest experience is on NetSuite, where this runs in production. We implement and support Business Central, Dynamics 365 Finance & Operations, SAP S/4HANA Cloud Public Edition, Lensing and iplicit alongside it.
Every mapping documented, every transfer logged
Designed to answer your auditor’s questions, not only your pipeline reporting.
The gap between Salesforce and your ERP is a process problem before it is a technical one
Almost nobody designed the arrangement they are working with. Salesforce was rolled out for sales. The ERP was set up for accounting. What sits between them is not an architecture. It is an export, a PDF, a message in a channel, and someone entering the same figures a second time.
When companies decide to fix this, the instinct is to buy a connector. That is the right tool for the wrong first question. A connector moves whatever you tell it to move. It cannot tell you whether the discount your sales team approved in a quote should be a price rule in the ERP or a line-level override, whether the sales order should be created at Closed-Won or at signed contract, or which system owns the customer record when both have one.
Those are the decisions that determine whether order-to-cash runs cleanly afterwards. Get them wrong and you have automated a process that was already broken, faster, and now with an audit trail proving it.
So we start there. We map how the handover actually runs today, agree where each step belongs, write it down, and only then build the interface that executes it.
What the project actually delivers
- A written handover design before any configuration begins
- Closed-Won to sales order without manual re-entry
- Invoice and payment status visible back in Salesforce
- Entity-specific routing across subsidiaries, as a rule rather than a judgement call
Where your CRM should stop and your ERP should take over
There is no universal answer, but there is a defensible one for your business. Most disagreements between sales and finance come from never having made the call explicitly. Here is where we usually land.
Stays in Salesforce
- Lead, opportunity and forecast
- Quote and CPQ
- Discount approval
- Renewal and upsell, fed by ERP data
- The price list, mirrored from the ERP rather than mastered here
The cut line
Contract or order confirmation. The commercial commitment is fixed and the fulfilment obligation begins.
Belongs in the ERP
- Product catalogue and price master
- Sales order
- Credit check and credit limit, surfaced back in Salesforce
- Fulfilment, delivery and project delivery
- Invoicing and revenue recognition
- Payment status and dunning, surfaced back in Salesforce
And when we recommend otherwise
The split above is our starting position, not a template. Here is each step with the reasoning and the exceptions.
Lead, opportunity, forecast
Belongs in: Salesforce
Why: This is what the CRM is for, and finance has no reason to touch it.
Exception: Effectively never.
Product catalogue and price list
Belongs in: ERP (mastered), mirrored into Salesforce
Why: The ERP has to invoice what was sold. If pricing is mastered in the CRM, every price change becomes a reconciliation.
Exception: Highly configurable or usage-based products where the CRM catalogue is genuinely richer.
Quote and CPQ (Configure Price Quote)
Belongs in: Salesforce
Why: Quoting is a sales activity and belongs where the seller works. Discount and approval logic sits here.
Exception: Complex bundles, project pricing or contract manufacturing where the costing model only exists in the ERP.
Discount approval
Belongs in: Salesforce
Why: The approver is a sales manager, not an accountant. Finance needs the outcome, not the workflow.
Exception: Where a margin threshold requires a CFO sign-off. Then approval is mirrored, not moved.
Contract or order confirmation
The cut line. This is the natural boundary. The commercial commitment is fixed and the fulfilment obligation begins.
Sales order
Belongs in: ERP
Why: The sales order is the document fulfilment, revenue recognition and the audit trail all hang off.
Exception: Rarely. A sales order created in the CRM is the single most common source of two versions of the truth.
Credit check and credit limit
Belongs in: ERP
Why: Only the ERP knows the open balance and payment history.
Exception: Result surfaced back in Salesforce so sales sees it before quoting, never re-implemented there.
Fulfilment, delivery, project delivery
Belongs in: ERP
Why: Stock, resources and costs live here.
Invoicing and revenue recognition
Belongs in: ERP
Why: Non-negotiable for audit and statutory reporting.
Payment status and dunning
Belongs in: ERP, surfaced in Salesforce
Why: Finance runs it; sales needs to see it so it stops chasing customers who have already paid.
Renewal and upsell
Belongs in: Salesforce, fed by ERP data
Why: A renewal is a sales motion, but it needs the real contract and billing history behind it.
The value is not in the answers. It is in having made each call deliberately, with sales and finance in the same room, and written it down where a new controller can read it in two years.
The six decisions that shape your order-to-cash
These come up in almost every assessment. If you can answer all six today, and sales and finance give the same answer, you probably do not need us for the design. Only for the build.
01
Where does CPQ live, and what does it hand over?
Quoting usually belongs in Salesforce. The question that gets skipped is what a quote actually hands over. Is it line items and quantities, or also discount logic, payment terms, billing schedule and delivery commitments? When only the total crosses the boundary, finance finds out what was agreed at the point the invoice is disputed.
02
Who owns the product and price master?
If both systems maintain their own product records, they will diverge. Not as a risk, as a certainty. One system masters, the other mirrors. In an order-to-cash design that is almost always the ERP, because it is the system that has to invoice what was sold and recognise the revenue.
03
At which step is the sales order created, and what triggers it?
Closed-Won is the usual trigger and often the wrong one. If your business signs contracts, receives purchase orders or takes deposits, the commercial commitment becomes real at one of those points, not when a seller moves a stage. The trigger has to match the point at which you are willing to recognise an obligation, and it should be one event, not a person deciding case by case.
04
Who owns the customer record, and what happens to duplicates?
Sales creates accounts freely; finance cannot. Every integration project runs into the same question. What happens when a new Salesforce account matches an existing ERP customer with an open balance? This needs a documented matching rule and a defined exception path before go-live, not a decision made under pressure in week three.
05
Where does credit control sit, and when does it interrupt the deal?
The ERP holds the open balance and the payment history. If the credit check only happens when the order reaches finance, sales has already promised a delivery date. Surfacing credit status in Salesforce before the quote goes out changes the conversation from a blocked order into a normal commercial one.
06
Which event starts invoicing and revenue recognition?
Order, delivery, milestone, subscription period. This is where an order-to-cash design touches accounting policy directly, and it is the reason we run these workshops with finance in the room rather than only with RevOps. Under IFRS 15 or ASC 606 the answer is not a preference.
What you get out of it
The output of the assessment is a written handover design. It shows the process end to end, the cut line marked, each of the six decisions answered with the reasoning behind it, and the data objects that have to move in each direction. It is deliberately readable by someone who is not in the project. Your Managing Director, your auditor, or the controller who joins next year.
It also stands on its own. If you take it and build the interface with your existing IT partner, it still did its job.
What changes in your order-to-cash
From opportunity to cash collected. One process, one audit trail.
What the designed handover looks like once it is running. The cut line sits between steps 3 and 4.
01
Opportunity and quote
The seller configures, prices and discounts in Salesforce, against product and price data mastered in the ERP.
02
Approval
Discount and margin approvals run in Salesforce, under the thresholds finance has agreed.
03
Commitment
The customer accepts. This is the trigger event you defined, not a stage somebody dragged a card into.
The cut line. CRM hands over, ERP takes ownership.
04
Sales order
Created in the ERP with line items, quantities, pricing, terms and the correct legal entity. Credit status is checked against the real open balance.
05
Fulfilment or delivery
Handled in the ERP, with status returned to the Salesforce record so sales can answer “where is my order” without an ERP login.
06
Invoice and revenue recognition
Raised in the ERP on the event your accounting policy specifies.
07
Payment and dunning
Payment status flows back to Salesforce, so nobody chases an account that settled two weeks ago.
Every transfer is logged against its source record. Anything that does not match a rule goes to a person in an exception queue rather than being posted on a best guess.
Where order-to-cash usually breaks, and what fixes it
Six failure patterns we see on nearly every assessment. If more than two of them sound like your month-end, the cut line is in the wrong place.
Cloudmaven and eUnify, a generic iPaaS, or building it yourself?
Most companies arrive at this decision from one of three directions. It is worth naming them plainly rather than comparing feature lists.
Keep the manual handover
Company profile
Low order volume, one entity, still manageable by hand.
Who designs the process
Nobody. It grew.
Who owns it afterwards
Your team, informally.
Finance visibility
Manual review still works.
Audit trail
Email history, hard to reconstruct.
Effort to change later
None, but the manual cost is permanent.
What it costs you
No project cost, recurring manual cost.
Generic iPaaS or point connector
Company profile
One-directional need, for example accounts only.
Who designs the process
You do, before you configure.
Who owns it afterwards
An external platform vendor with its own login and its own support queue.
Finance visibility
Basic record sync.
Audit trail
Varies by vendor, often one-directional.
Effort to change later
Reconfiguration inside a third-party tool.
What it costs you
Licence fee plus configuration.
Cloudmaven and eUnify
Company profile
Multi-entity group, full order-to-cash in scope.
Who designs the process
We do it with you, and it is a deliverable.
Who owns it afterwards
The same team that designs your finance architecture.
Finance visibility
Quote, order, invoice and payment status end to end.
Audit trail
Full transfer history plus mapping documentation.
Effort to change later
Handled by the team that built it.
What it costs you
One-off project investment, then declining running cost.
In a joint discovery session we assess your current Salesforce and ERP setup without pre-committing you to a solution, including the case for leaving the manual handover exactly as it is, if your volume does not justify a project. If what you actually need is a single field sync, a lighter tool is the right answer and we will say so.
We start with a no-obligation assessment of your current process. It shows what moves automatically today, what still gets re-typed, where the cut line sits by accident rather than by design, and what the risk looks like if a key person is out for a month.
Core capabilities
Cloudmaven and Salesforce ERP integration
We do not open this conversation with the connector. We open it with your order-to-cash process, your entity structure and the reports you are accountable for, because the connector is a means to that end, not the point of it.
Cloudmaven is a CFO advisory firm and an ERP implementation partner for growing, internationally structured companies across Switzerland, Germany and beyond. We spend most of our time inside finance processes, so the question of where the CRM should stop is one we have to answer on nearly every project anyway.
Our integrations run on eUnify, the integration platform we build and maintain ourselves, including our own Salesforce connector. That matters for one practical reason. When your entity structure, tax treatment or revenue recognition changes, the team that has to reflect it in the ERP is the same team that maintains the interface. And because eUnify sits above the systems rather than inside one of them, the same Salesforce side can be connected to a different ERP without starting again.
We are not a Salesforce implementation partner and we are not positioning ourselves as one. If your CRM itself needs work, we will say so and work alongside your existing Salesforce partner rather than trying to replace them. Our responsibility starts where the deal is won and the financial process begins.
Our services
Consulting first, build second.
The case your management team will ask you for
Finance usually sees this problem long before there is a business case for fixing it. And the questions that decide whether the project is approved are rarely technical ones.
We answer these in writing, with your figures, as part of the assessment, in a form you can take into your own approval process without us in the room.
- What does it cost, and how many months until it has paid for itself?
- What does another twelve months of the current process cost, in hours, in working capital, in late reporting?
- What happens to day-to-day operations during the changeover?
- What if it goes wrong, and where is the fallback?
- Why not simply add two more people in order processing?
Cloudmaven in Figures
16+
Locations worldwide (Europe, EMEA, America, Asia)
30+
Countries in which we operate
120+
consultants and engineers
350+
satisfied customers
600+
projects
Companies that already rely on our portfolio
Clients across our ERP, EPM and integration portfolio.
FAQs
What is a Salesforce ERP integration?
It is a defined data flow between Salesforce and your ERP system, built on an agreed process design. Customer, quote and order data move from the CRM into the ERP; invoice and payment status move back, under documented mapping rules, with every transfer logged instead of re-typed.
At what point should the process leave Salesforce and move into the ERP?
At the point the commercial commitment becomes firm, usually order confirmation or contract signature. Everything up to that point is a sales activity; everything after it creates a fulfilment and accounting obligation. The exact trigger depends on how you contract, which is one of the six decisions we work through in the assessment.
Should CPQ stay in Salesforce or move to the ERP?
Usually it stays in Salesforce, because quoting belongs where the seller works. The exception is complex bundles, project pricing or configure-to-order products where the costing model only exists in the ERP. There, quoting from the CRM produces prices the ERP cannot honour. What matters more than the answer is that pricing is mastered in one place and mirrored, not maintained twice.
Where should the sales order be created?
In the ERP. Fulfilment, revenue recognition and the audit trail all hang off the sales order, and an order created in the CRM is the most common reason two systems stop agreeing. The CRM should show the order and its status; it should not own it.
Which ERP systems do you connect Salesforce to?
Our deepest experience is on NetSuite, including NetSuite OneWorld, where this runs in production. We also implement and support Microsoft Dynamics 365 Business Central, Dynamics 365 Finance & Operations, SAP S/4HANA Cloud Public Edition, Lensing and iplicit. Because the Salesforce side of the connector sits on eUnify, our integration platform, the ERP side is the part that changes per project. We scope that per engagement and will tell you plainly during discovery what is pre-built and what is not.
Do we have to move off Salesforce?
No. We are not a Salesforce implementation partner and we are not trying to become your CRM vendor. Our work starts where the CRM hands over to finance.
Why not use a generic integration platform, or build it in-house?
Both are legitimate. A generic platform is often quicker to switch on for a narrow, one-directional sync. An in-house build gives you complete control, at the price of owning it permanently. Our argument is narrower than “we are better”. The team that designs your finance architecture also owns the connector, so when your entity structure, tax treatment or revenue recognition changes, one team handles both sides of it.
What will our auditor say about automated postings?
This is usually the first question, and it should be. Nothing posts without a source record. Every mapping rule is documented, every transfer is logged with a timestamp, and anything that does not match a rule goes to a person rather than being posted on a best guess. The process documentation your auditor will ask for is a project deliverable, not something we assemble afterwards on request.
What does it cost?
It depends on how many pipelines, entities and financial data points are in scope. We scope it during the assessment and quote for the first stage, so you decide on the second stage with real numbers rather than an estimate.
Can we start with a small scope?
Yes, and most companies should. A typical first stage covers the handover design plus account and order sync in one direction, for one entity. Invoice and payment status back into Salesforce, and additional entities, follow once the first stage is live and stable.
What if we change ERP system in two years?
That is an argument for putting the integration in a layer above the systems rather than inside one of them. The process design and the mapping documentation survive a platform change; only the ERP-side connection is rebuilt. If the assessment suggests the real constraint is the ERP rather than the interface, we will say so. That is a separate conversation, and our ERP evaluation is free and independent.
What happens to the business while it is being changed over?
Nothing stops. We run the new flow in parallel against live orders before cutover, so the existing process stays in place until the new one has demonstrably produced the same result. The fallback path is agreed in writing before go-live.
Would we be better off consolidating CRM into our ERP instead?
Sometimes, yes, and it is a genuinely different question from this one. If you are weighing keeping Salesforce against running CRM natively in your ERP, our NetSuite CRM page argues the other side of it. We are happy to make either case on its merits.
