SAP Business One Salesforce integration is the connection between the system where a deal is won and the system where the order, the stock, the invoice and the payment are controlled. Done properly it is not field mapping — it is a set of agreements about identity, ownership and failure, made before anything is built. Business partners, items, orders, invoices and payments — each with one owner and one direction.
Twopir Consulting is a Salesforce Partner with 12+ years and 500+ clients behind its CRM-to-ERP work — connecting commercial systems to operational truth so sales, finance and operations read the same order, the same stock figure and the same invoice.
Built for CRM ↔ ERP Operations
None of these are exotic failures. They are what happens when two systems that both believe they own the customer are connected without anyone deciding which one is right.
Sales creates an account, finance creates a business partner, and nothing links them. Six months later nobody can answer which record is right, and every report that joins revenue to pipeline is quietly wrong.
A closed opportunity becomes a sales order when somebody re-keys it. That is a delay measured in hours, a transcription error rate nobody tracks, and an order desk that becomes the bottleneck exactly when the business is growing.
Availability lives in SAP Business One by item and warehouse. If it only reaches sales as a spreadsheet emailed on Monday, Thursday's quote is fiction — and the credibility cost lands on the rep, not on the system.
Invoices and incoming payments post in the ERP. Without them in Salesforce, a rep opens a renewal conversation with an account that is ninety days overdue, and finance chases in a channel sales never sees.
The integration times out, the job runs again, and SAP now holds two orders for one deal. This is the single most expensive failure mode in ERP integration, and it is entirely preventable — but only if idempotency was designed in from the start.
Errors go to a log file rather than to a person. The gap between the failure and the discovery is where reconciliation work is created, and it is usually discovered by whoever is closing the books.
SAP Business One Salesforce integration is the automated exchange of customer, product, pricing, order, delivery, invoice and payment data between Salesforce and SAP Business One, so that a commercial event in the CRM becomes a controlled transaction in the ERP and the financial result comes back. It is a revenue-infrastructure decision before it is a technical one.
The two systems are not peers doing the same job. Salesforce is where demand is created, qualified and won: accounts, contacts, opportunities, quotes, activity and forecast. SAP Business One is where the business is actually run: business partners, items and inventory, sales and purchasing documents, invoicing, payments and the general ledger. SAP describes it as an ERP for small and midsize companies, deployable on-premise or in the cloud and running on either SAP HANA or Microsoft SQL Server — and SAP reported in December 2025 that more than 83,000 customers and 1.2 million users run it across more than 170 countries.
So the integration is a translation, not a copy. A Salesforce Opportunity is not a Sales Order; it is the business event that causes one. Getting that distinction right — and deciding exactly when the process crosses from CRM into ERP — is the design work. Field mapping is what happens afterwards.
Who this is for: manufacturers, distributors, wholesalers and product businesses that run SAP Business One as the operational backbone and Salesforce as the commercial front end. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges. If you are weighing the same question for a different ERP, the equivalent work for Salesforce and NetSuite follows the same spine with a very different object model.
Where this sits: Twopir's wider CRM practice is on Salesforce consulting, and the SAP Business One overview is on SAP Business One and Salesforce. The rest of this cluster goes deeper: integration services for what an engagement covers, where the scope stops and what it costs in time; implementation for the project that puts Salesforce in alongside B1; integration architecture for the patterns and the six decisions that are expensive to reverse; and data synchronization for object-by-object direction, ownership, cadence and conflict rules. If your buyers are manufacturers or distributors, Salesforce for manufacturing is the industry view of the same revenue infrastructure.
This is the conversation every SAP Business One and Salesforce project has in its first week. The direction column is the important one: it names which system is allowed to change the value, which is the decision that prevents most sync problems before they exist.
| Salesforce | SAP Business One | Direction | What has to be true |
|---|---|---|---|
Account Id | Business Partner CardCode | SF → SAP | Match on an agreed external key, never on company name. Create the business partner when no match exists, then store the returned CardCode back on the account. |
Contact ContactId | Contact Person on the Business Partner | SF → SAP | Contacts hang off the business partner in SAP Business One, so the account must resolve to a CardCode before a contact can be written at all. |
Product ProductCode | Item ItemCode | SAP → SF | The ERP owns the catalogue. Items, unit of measure and item status flow into the price book so reps quote a SKU that exists. |
| Price Book Entry | Price List | SAP → SF | Pricing is an ERP decision in almost every B1 landscape: price lists, customer-specific pricing and discount rules resolve in SAP and surface in Salesforce read-only. |
| Opportunity / Quote (Closed Won) | Sales Order DocEntry · DocNum | SF → SAP | Not an equivalence — a transformation. The CRM stage change is the business event; the sales order is the ERP transaction it triggers, with header and lines built from the quote. |
| Opportunity Line | Sales Order Line | SF → SAP | Quantity, unit price and discount map per line, each resolved to an ItemCode, a warehouse and a tax code before the document is allowed to post. |
| Order status field | Delivery | SAP → SF | Picking, packing and despatch happen in the ERP. The CRM gets status and dates so a rep can answer 'where is my order' without an ERP licence. |
| Invoice record | A/R Invoice DocEntry | SAP → SF | Invoice number, date, amount and status land on the account and the originating opportunity, which is what makes revenue reporting in Salesforce trustworthy. |
| Payment status | Incoming Payment | SAP → SF | Paid, part-paid and overdue land in the CRM so a rep sees an unpaid invoice before the renewal call rather than after the escalation. |
| Inventory field or external object | Item stock by warehouse | SAP → SF | Availability is computed from ERP stock per warehouse under an agreed rule. Often the best candidate for a live read rather than a copy. |
| Cross-reference fields | User-Defined Fields U_SalesforceId | Both | The identity spine. SAP holds the Salesforce id in a UDF, Salesforce holds the CardCode, and no process anywhere matches on a name. |
This map is the starting point, not the deliverable. Every landscape changes at least three rows of it — a B1 instance with company databases per legal entity, a localisation that adds mandatory tax fields, an approval rule that stops a sales order posting, or a business that raises the order on quote acceptance rather than on Closed Won. The direction and the owner of every row are decided in the design workshop and signed off before anything is built. Field-level direction, cadence and conflict rules are covered in depth on SAP Business One Salesforce data synchronization.
Four different pieces of work, four different buyers, and a boundary between configuration and custom development that almost no competitor page will state. Here is where ours sits.
The part almost nobody sells separately, and the part that decides whether the rest works. It produces a document, not a demo.
Building the flows themselves, on the Service Layer, the DI API or an iPaaS platform — whichever the design actually calls for.
Configuration, not code: the CRM has to be shaped so the integration has something valid to send. This is where most ERP integrations are actually won or lost.
Where configuration ends and development begins. We draw that line explicitly, before the estimate, so nobody discovers it halfway through a sprint.
An integration is a running system, not a project deliverable. Somebody has to own the queue on the Tuesday after go-live.
If an integration is already running and failing, the first engagement is usually a review rather than a rebuild — and often the answer is a fix, not a replacement.
There is no single correct connector, and a partner who names one before hearing your volumes and your scope is selling rather than advising. These are the real options and what each is genuinely good at.
SAP Business One's REST and OData API, and the right default for anything new. Version 1 sits at /b1s/v1/ on OData v3; version 2 sits at /b1s/v2/ on OData v4. SAP deprecated OData v3 as of Feature Package 2405 and recommends v2, so new builds should target it. SAP's Service Layer reference
The original COM-based interface, running on Windows next to the B1 installation. Still the right answer for established on-premise add-ons and for the handful of operations the Service Layer does not expose — but it is a local component, not a web API, so it shapes where your integration has to run.
A SOAP service wrapped around the DI API, built for multiple concurrent clients. It exists to solve the DI API's single-session problem, which is why packaged connectors often use it — APPSeCONNECT, for example, publishes both a DI Server and a Service Layer integration package for Salesforce.
SAP's own integration framework for SAP Business One. Worth considering when documents must be routed between several company databases or transformed through multiple hops inside the SAP estate before they ever reach the CRM.
MuleSoft, Jitterbit, Workato, Celigo and Boomi all connect the two. What you are buying is not the connector but the retry, queueing, cross-reference storage and monitoring. We are neutral on which: see MuleSoft, Jitterbit and Workato.
For a narrow scope, Salesforce can call the Service Layer directly. Apex callouts authenticate through a Named Credential so no endpoint or secret sits in code — the pattern Twopir used in its published CRM-to-ERP order sync build.
Salesforce's OData 2.0 and 4.0 adapters expose external data as External Objects without copying it into the org. For high-cardinality, fast-moving ERP data such as stock by warehouse, reading live often beats syncing. Salesforce Connect setup
The event-driven side of the Salesforce boundary. Change Data Capture and Platform Events let the CRM publish a change once and let the integration consume it, instead of polling every record every fifteen minutes and hoping the window was wide enough.
Choosing between them is an architecture decision with cost and operating consequences for years. SAP Business One Salesforce integration architecture walks through the patterns, the trade-offs and the six decisions that determine whether the integration survives its second year.
Five phases. The parallel run is the one clients try to cut and the one we will not skip, because it is the only phase that proves the integration is right rather than merely finished.
We look at the real systems, not the diagram: which SAP Business One version and database, how many company databases, which localisation, how the CRM is actually used, and how bad the duplicate problem is on both sides. Ends with a findings document.
Object by object, field by field: direction, system of record, cadence, transformation and the conflict rule. Nothing is built until the business signs this off, because reversing an ownership decision after go-live is expensive.
A Salesforce sandbox against a copy of the SAP company database. Flows, transformations, the cross-reference store, the error queue and the sync-status fields are all built here, with the failure paths tested as deliberately as the happy path.
Both processes run side by side on real transactions and we reconcile the two outputs daily until they agree. Discrepancies at this stage are cheap; the same discrepancies after cutover are an audit finding.
A dated switch with a rollback path, then a hypercare period where we hold the error queue, then a handover — to your team with documentation and training, or to us under a managed run agreement.
Every number below comes from a published Twopir case study and keeps the scope that case study states. These are CRM-to-ERP engagements rather than SAP Business One projects specifically — we would rather say so than dress one up — but the mechanics are the ones a B1 integration needs: customer upsert against a stored ERP identifier, CPQ lines mapped to ERP order lines, idempotent writes that never create a second document, and master-data uniqueness enforced at the point of entry.
Every closed deal used to be typed into the ERP a second time by hand. Now one button on the opportunity creates the customer, the sales order and the invoice, and if somebody presses it twice nothing duplicates — it updates what is already there.
Salesforce CPQ to MYOB Advanced: customer upsert by stored ERP card ID, CPQ line items mapped to ERP order lines, idempotent PUT sync, and the ERP invoice written straight back onto the Salesforce record.
Before, onboarding a trade customer took two weeks of manual work — data entry, approvals spread across email threads, account setup scattered across systems. Now a customer can register, get approved and be ready to order within three days.
Shopify, Salesforce and QuickBooks joined into one automated flow: registration and approval, real-time customer and product sync, order and fulfilment status, and invoice generation straight into accounting. Delivered in 16 weeks across five phases.
Five things that decide whether an SAP Business One and Salesforce integration is still trusted a year after go-live.
Said plainly, because it changes who does what: Twopir Consulting is a Salesforce Partner. We design and build the integration layer, the Salesforce side of it and the operating process around it. Your SAP Business One partner keeps the ERP, the localisation and the licensing. Most of our SAP Business One work runs alongside an incumbent B1 partner, and the engagement is better for it — the two sides of the boundary each stay with the team that owns them.
The question that sinks CRM-to-ERP projects is not "how do we move this field", it is "who is allowed to change it". We run an ownership workshop first and write the answer down object by object: who creates a business partner, who may edit a price, who wins when both systems changed the same record in the same hour.
Order, invoice and payment traffic is financially significant, so retries cannot create second documents. Every write we build carries an external reference, checks whether the SAP document already exists before creating one, and logs the resulting DocEntry against the source record. Failures land in a queue somebody actually owns.
SAP Business One is not a small S/4HANA. Its customers and vendors are both Business Partners keyed by CardCode; its documents carry an internal DocEntry and a human-facing DocNum that are not interchangeable; its extension model is User-Defined Fields and Objects. We build against those, and we will tell you when a requirement needs your B1 partner rather than us.
We sell no integration platform, so we have no reason to recommend one. Sometimes the right answer for a single low-volume flow is direct Apex callouts and no licence at all, and we will say so — the same way we will say when a packaged AppExchange connector covers your scope more cheaply than a bespoke build.
It is the automated exchange of customer, product, pricing, order, delivery, invoice and payment data between Salesforce and SAP Business One. Salesforce owns the commercial process up to the point a deal is won; SAP Business One owns the transaction from that point on. The integration is what carries a won deal into the ERP as a controlled document, and carries the financial result back.
The important part is that it is a transformation rather than a copy. A Salesforce Opportunity is not an SAP Sales Order — it is the business event that triggers one, and the rules that decide when and how that happens are specific to your business.
Business Partners (customers and vendors, keyed by CardCode), Items (keyed by ItemCode), price lists and warehouses, and the document chain: Sales Quotation, Sales Order, Delivery, A/R Invoice and Incoming Payment. Documents are addressed internally by DocEntry and shown to people as DocNum — the two are not interchangeable and an integration that confuses them will eventually update the wrong record.
Most landscapes also add User-Defined Fields on the business partner and item to hold the Salesforce record id, which is what makes matching deterministic instead of a fuzzy comparison of company names.
No, and treating them as the same skill is a common and expensive mistake. SAP Business One is a distinct product with its own object model and its own integration mechanisms. Its documents are addressed by DocEntry and DocNum, its customers and vendors are both Business Partners keyed by CardCode, and its modern API is the Service Layer, an OData service — none of which maps onto S/4HANA or ECC experience.
So when you are evaluating partners, ask specifically about SAP Business One. A team that has integrated S/4HANA will not automatically know what a User-Defined Object is or why a sales order will not post until the warehouse and tax code resolve.
Yes, and it is the most common shape we see. SAP Business One deploys on-premise or in the cloud and runs on either SAP HANA or Microsoft SQL Server, so a large share of B1 landscapes sit inside a company network rather than on the public internet.
That makes connectivity an explicit design item rather than an afterthought. The Service Layer has to be reachable by whatever runs the integration, which usually means a reverse proxy or gateway with TLS, an allow-list of source addresses, a service account scoped to the objects in the mapping, and a middleware agent installed inside the network if the platform supports one. None of this is exotic — it just has to be agreed with whoever runs the network before the build starts, not during it.
Both are legitimate and the honest answer depends on volume and scope. One flow, low volume and a single company database can be built directly with Apex callouts to the Service Layer against a Named Credential — fewer moving parts, no platform licence, and it stays supportable as long as the scope stays small.
Once you have several document flows, more than one SAP company database, or a real need for replay and error queues, an iPaaS hub earns its licence: the retry, queueing, monitoring and cross-reference storage come with the platform instead of being written from scratch. We are tool-neutral about which one — we have delivered on MuleSoft, Jitterbit and Workato, and we will recommend the cheapest thing that meets the requirement.
A first production flow — accounts to business partners, plus one document flow such as Closed Won to sales order — is normally a six to ten week engagement, including a parallel run. A full quote-to-cash scope covering items, pricing, orders, deliveries, invoices and payments is usually three to four months.
Those are our planning ranges, not a quote, and three things move them more than anything else: how clean the master data is on both sides, how many SAP company databases are in scope, and how quickly one person can be made accountable for each object. For comparison, the published Twopir engagement closest to this shape — commerce, CRM and accounting joined into one flow — ran 16 weeks across five phases.
No, and we say so up front. Twopir Consulting is a Salesforce Partner and a HubSpot Partner. On SAP Business One we build against the documented APIs — the SAP Business One Service Layer, the DI API and the DI Server — and we work alongside whichever SAP Business One partner supports your ERP.
In practice that division is a feature rather than a compromise. Your B1 partner owns the ERP, its localisation and its upgrades; we own the integration, the Salesforce side and the operating process around both. If you have no B1 partner, we can work directly with your internal SAP administrator instead.
Most of this work starts with something already running. A typical first engagement is a review: we read the existing mappings, watch a week of real traffic, reproduce the failures, and come back with the small number of changes that actually stop them.
The causes repeat. Two one-way syncs with no agreement on who wins. Matching on customer name instead of a stored identifier. Retries that create a second sales order instead of finding the first. Errors written to a log nobody reads. Those are fixable without replacing the platform, and we will say so if that is the answer.
Twopir Consulting designs, builds and operates the integration between SAP Business One and Salesforce — and works alongside your existing SAP Business One partner rather than around them. We help growing and mid-market companies solve complex CRM, integration, and business system challenges.
Speak with a team that has connected CRMs to ERPs in production, not just in a demo org
