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, Everest and iplicit alongside it.
Every mapping documented, every transfer logged
Designed to answer your auditor’s questions, not only your pipeline reporting.
Cloudmaven in Figures
16+
Locations worldwide (Europe, EMEA, America, Asia)
30+
Countries in which we operate
120+
ERP and EPM employees
350+
satisfied customers
400+
Successfully implemented projects
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
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.
Read these as a starting position, not a template. 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: 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: 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
One set of figures, and you can prove it
Every record in the ERP is traceable to the Salesforce record it came from. No second version of the truth, and no undocumented step between the two systems.
The close stops depending on two people
The handover becomes a documented rule inside the system instead of knowledge in somebody’s head. Holiday and sick leave stop being a risk to the monthly close.
Cash arrives earlier
Invoices can be raised the day the order is confirmed rather than the week after. That shows up directly in DSO, which is the one finance metric that translates into cash without an argument.
Fewer manual steps, more exception handling
Recurring transactions run rule-based. Your team works on the exceptions instead of re-typing the routine ones.
Growth without proportional headcount in finance
Twice the order volume does not have to mean two more people entering it. Capacity comes from the process rather than the payroll.
Multi-entity handled by design
Orders route to the correct legal entity with the right currency and tax treatment, instead of being sorted out manually after the fact.
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.
The same order is entered twice
Sales closes it in Salesforce, finance re-enters it in the ERP. Every re-entry is another chance to introduce an error into the books. The integration transfers the record once, under rules you have approved.
What was agreed in the quote never reaches accounting
Discounts, payment terms and delivery promises are settled in the deal and arrive in finance late, or not at all. When the quote hands over its terms and not just its total, the invoice matches what the customer thinks they signed.
Sales cannot see whether the customer has paid
So a good account gets chased for an invoice it settled two weeks ago. Payment status flowing back into Salesforce prevents it, and costs nothing to maintain once it is running.
Nobody is certain which entity the order belongs to
In groups with several legal entities, allocation is made manually and inconsistently. Entity routing turns it into a rule rather than a judgement call, with the right currency and tax treatment attached.
Pipeline and revenue never quite reconcile
The forecast lives in Salesforce, the actuals live in the ERP, and a spreadsheet in between reconciles them for the board pack. A single data flow removes the spreadsheet, and with it the version of the numbers nobody can source.
The CRM has quietly become a second ERP
Order records, delivery dates and invoice fields get built in Salesforce because finance was too slow to ask. It works until it has to be audited, or until someone tries to close the year with it. Redrawing the cut line is usually a bigger relief than any connector.
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.
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?
Companies that already rely on our portfolio
Clients across our ERP, EPM and integration portfolio.
FAQs
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 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.
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.
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.
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, Everest 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.
No. This page exists precisely because Salesforce is usually working well. 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.
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.
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.
The assessment and handover design run to [XX weeks]. The build runs to [XX weeks], depending on how many pipelines, entities and financial data points are in scope. We confirm both ranges after the first conversation, not before.
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.
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.
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.
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.
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.
Talk to us about your order-to-cash handover
Have our experts map your Salesforce-to-ERP handover, with no obligation.
Get a scoped quote for your first integration stage.
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. That combination is the reason this page is written the way it is: 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.
Order-to-cash process assessment
How the handover runs today, not how the process documentation describes it.
Handover design
The cut line between CRM and ERP, documented and signed off by sales and finance together.
CPQ and pricing architecture advice
Where quoting, pricing and product mastering belong, plus sales process design for a clean ERP handover, including trigger events and approval thresholds.
Integration design and field mapping
Including mapping documentation, entity routing and multi-subsidiary configuration.
Build and configuration of the Salesforce connector on eUnify
Followed by parallel-run testing against live orders.
Go-live, hypercare and ongoing support
Hypercare through the first full monthly close, then monitoring, support and change management.
ERP evaluation
Free and independent, if the assessment shows the constraint is the ERP rather than the interface. Read more.
Core capabilities
Order-to-cash process design
The cut line between CRM and ERP, agreed and documented, with each of the six decisions answered for your business.
Quote and CPQ handover
Quote lines, discount logic and price book data mapped to ERP items, pricing and terms, so the invoice reflects what was actually agreed.
Opportunity to sales order
The trigger event you defined creates the sales order in the ERP, with line items, quantities and pricing carried across.
Invoice and payment status
Invoice, payment and credit note status returned to the Salesforce account and opportunity records.
Account and customer master data
One customer record, aligned across both systems, with defined matching and duplicate-handling rules.
Multi-entity routing
Orders allocated to the correct legal entity with the appropriate currency and tax treatment.
Sync monitoring and audit log
Complete transfer history, error handling and an exception queue that finance can see, rather than one buried in a vendor console.
Where does your order-to-cash actually stop working?
We start with a no-obligation assessment of your current process: 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.
30 minutes, no obligation.
Let our experts advise you without obligation
