SAP to Salesforce Migration: SOX Compliance Guide
Salesforce is a CRM platform, not a financial ERP, and this is not a system-of-record replacement — treat any plan that frames it that way as mis-scoped. What actually happens under this heading is one of two things: a company moving quote-to-cash's front end (opportunity management, CPQ, contract creation) from SAP Sales & Distribution or SAP CRM onto Salesforce while SAP stays the financial system of record downstream, or a company migrating Salesforce Billing/Revenue Cloud processes that touch revenue recognition into or out of an SAP-fed process. The SOX-relevant surface here is narrower than a full ERP migration but sharper in one specific place: revenue recognition. Anything in the order-to-cash chain that determines when and how revenue is recognized — contract terms, pricing approval, discount authorization, billing triggers — is ICFR-relevant the moment it feeds the general ledger, regardless of which system captures it first. This guide covers keeping those controls intact as quote-to-cash moves onto Salesforce and interfaces back into SAP.
Before you start
- ·Explicit process boundary documented: which quote-to-cash steps move to Salesforce (opportunity, quote, contract, possibly billing) versus which remain in SAP (revenue recognition, GL posting, financial close), signed off by Internal Audit
- ·Current-state SAP control matrix for the in-scope revenue-adjacent controls: discount and pricing approval, contract modification approval, credit hold/release, and the order-to-cash SoD matrix
- ·Salesforce security model design workshop (profiles, permission sets, and if used, Salesforce Shield or a comparable audit-trail tool) with Internal Audit present, not just a CRM administrator working from a sales-enablement brief
- ·Interface design finalized for the Salesforce-to-SAP data flow (order, contract, or billing data landing in SAP for revenue recognition and GL posting), including what triggers the transfer and how failures are detected
- ·Revenue recognition policy reviewed against the new process flow to confirm which system captures the data points (contract start/end dates, performance obligations, variable consideration) that ASC 606 five-step analysis depends on
Migration steps
Draw the process boundary before designing any Salesforce security
Walk the full quote-to-cash flow and assign each step explicitly to Salesforce or SAP post-migration. This is the step most teams skip because it looks obvious from the project kickoff deck — but 'obvious' scope decisions made in a sales-enablement conversation routinely miss the revenue-recognition-relevant steps that Internal Audit actually cares about. Get written sign-off on the boundary before role design starts.
Map SAP's SD/pricing controls to Salesforce's approval and permission model
SAP pricing and discount approval controls typically run through condition records, release strategies, or workflow tied to authorization objects. Salesforce enforces equivalent controls through approval processes, validation rules, and permission sets — a materially different mechanism. Rebuild each control explicitly: a discount-threshold approval that required a release strategy in SAP needs an equivalent Salesforce approval process with the same threshold and approver logic, not a generic 'manager approval' step that loses the specific dollar or percentage trigger.
Design Salesforce SoD around the order-to-cash conflict matrix, not CRM role templates
Out-of-the-box Salesforce profiles and permission sets are built for sales productivity, not SoD enforcement — a standard 'Sales Manager' profile will often bundle quote creation, discount approval, and contract modification into one role by default. Rebuild permission sets from the SoD matrix outward: who can create a quote must be separated from who can approve a discount above threshold, and both must be separated from who can modify a signed contract.
Build and test the Salesforce-to-SAP interface as a control point, not just an integration
The handoff of order, contract, or billing data from Salesforce into SAP for revenue recognition and GL posting is where a control gap most often hides. Define a reconciliation control — total contract value or order value in Salesforce reconciled against what lands in SAP — with a named owner and defined frequency, and test it under realistic volume and with deliberately malformed records before go-live, not just clean sample data.
Validate revenue-recognition data capture explicitly
Confirm that every data point your ASC 606 analysis depends on — performance obligations, contract start and end dates, variable consideration terms, standalone selling price — is captured accurately in the new process and transfers to SAP without manual re-entry or approximation. A quote-to-cash redesign that loses fidelity on contract terms creates a revenue-recognition risk even if the dollar totals reconcile.
Re-provision access role by role, gated by the rebuilt SoD ruleset
Provisioning under deadline pressure defaults to 'give the sales team what they need to hit the ground running,' which routinely means broad permission sets granted without an SoD check. Require every Salesforce permission-set assignment to pass the SoD ruleset before activation, with exceptions routed to a documented decision, exactly as you would for an ERP role.
Run a full control test across the Salesforce-to-SAP chain before closing the project
Test the complete flow — quote creation, discount approval, contract modification, interface handoff, revenue recognition in SAP — as one connected test, and compare the outcome against the pre-migration SAP-only control matrix. This is the evidence that quote-to-cash controls, not just data, survived the platform change.
Where SOX continuity breaks
- ·Salesforce framed internally as 'replacing SAP' for sales, leading teams to assume revenue-recognition controls moved with it when they actually still live in SAP — creating an unowned gap at the interface
- ·Out-of-the-box Salesforce profiles used as-is, bundling quote creation, pricing approval, and contract modification into a single role with no SoD boundary
- ·Discount and pricing approval thresholds re-implemented as generic Salesforce approval steps that lose the specific dollar or percentage triggers the original SAP release strategy enforced
- ·Interface between Salesforce and SAP treated as a one-way data push with no reconciliation control, so contract or order value discrepancies surface only at quarter-end close
- ·Revenue-recognition-relevant contract data (performance obligations, variable consideration) simplified or dropped during the Salesforce process redesign because the sales team didn't know it was audit-relevant
After the cutover
After cutover, run at least one full quarter-end close with the Salesforce-to-SAP interface reconciliation tested on every batch rather than sampled, and have Internal Audit or the revenue-recognition control owner review a sample of contracts end-to-end through both systems. Once results are clean, retire any interim manual reconciliation and update the order-to-cash section of the ICFR control matrix to reflect the new system boundary.
Common questions
No. Salesforce is a CRM platform; it does not perform general ledger accounting, revenue recognition determination, or financial close. This migration typically moves the front end of quote-to-cash (opportunities, quotes, contracts, sometimes billing) onto Salesforce while SAP remains the system of record for revenue recognition and financial reporting.
Book an assessment
Get migration-specific SOX control continuity guidance for SAP to Salesforce.
Book an Assessment →