B2B e-commerce integration connects your online store to the business systems behind it, so orders, account details and product data move between them instead of being retyped (Shopify). The first decision is not which connector to buy. It is which system owns each piece of data, and what happens when an update fails (commercetools).
This guide is for owners and e-commerce, sales and operations leads at manufacturers, distributors, wholesalers and brands adding B2B sales. For help connecting your store and growing the sales it brings in, see our B2B e-commerce digital marketing agency services.
Decide which system owns each record
Your systems may include:
- ERP (enterprise resource planning): runs operations and finance, such as stock, orders and invoices (commercetools).
- CRM (customer relationship management): tracks contacts and every interaction with prospects and customers (Salesforce).
- PIM (product information management): holds product content such as specifications, descriptions and documents (Akeneo).
- Warehouse or 3PL (third-party logistics) system: handles stock movements, shipping rates, tracking and returns (Shopify).
Their jobs overlap, so decide who may change each field rather than naming one system "the master" for everything. commercetools' advice is to give each piece of data one writer and make every other copy read-only (commercetools).
Illustration: a starting ownership map to adapt to your own systems.
| Information | Owned by | Sent to other systems | Business owner |
|---|---|---|---|
| Approved trade account, terms and credit | ERP, or whichever system finance approves in | Account status and buying terms | Finance |
| Contacts, sales rep and inquiry status | CRM | Qualified accounts and follow-ups | Sales |
| Specifications, descriptions and documents | PIM, or your current product content process | Approved product content | Product team |
| Stock and shipping | ERP or warehouse system | Sellable stock and shipment updates | Operations |
| Online order | Store until accepted, then the ERP | Order details and the ERP's order number | E-commerce and operations |
Match records on stable IDs, not names. A company name can change; the account number should not. Keep the legal customer, its delivery locations and the people who buy for it as separate records.
Decide the editing rules before you switch syncing on. If a sales rep changes a delivery address in the CRM, should that overwrite the approved address in the ERP, or create a request for someone to check?
What this means for you: for every field, you can name the authoritative system and the team responsible for changes.
B2B e-commerce ERP integration: plan around the accepted order
"Order placed" on your website and "order accepted" in your ERP are two different moments. Design the connection so your team can always see whether an order has reached the system that will ship it (commercetools).
Map your B2B e-commerce workflow by following one order in both directions:
- Before purchase: the store shows the right account, products, prices and stock. Decide how fresh each needs to be, and which ones need a live check.
- At checkout: the store sends the account and location IDs, product variants (such as size), quantities, units, currency, PO number and agreed terms.
- On acceptance or rejection: the ERP sends back its order number, or a clear reason for rejection with an owner to fix it.
- After purchase: shipment, invoice, cancellation and return updates flow back from the systems that own them.
These are requirements you write down. Buying a connector does not guarantee them.
What usually moves in each direction (OrderEase):
| From ERP to store | From store to ERP |
|---|---|
| Stock levels, by warehouse if you ship from several | Online orders, created as sales orders |
| Customer prices, discounts and credit limits | New customer accounts or account applications |
| Product details and unit-of-measure conversions | Changes buyers make to addresses or contacts, if you allow them |
| Order status, shipping confirmations and tracking numbers | Payment and PO references |
Orders may also arrive outside the website, by email, EDI or marketplaces. Decide whether those go through the same integration or stay a separate process.
Example: a distributor sells valves in cases of 10, but the ERP counts single valves. A buyer orders 2 cases, which must reach the ERP as 20 units of the right item. If the connection sends "2" without the unit, the ERP may accept the wrong quantity without complaint.
Some platforms store a separate price record per customer group, channel, currency and validity date, so map how your ERP price levels translate into those records (commercetools). Test the prices each account sees. Our guide to B2B e-commerce personalization covers showing each buyer the right price. Agree what happens when a contract price changes after the buyer filled the cart: does the old price stand, or does the buyer approve the new total? Finance decides the rule; the technical team builds it.
What this means for you: test whether the order means the same thing in both systems, not just whether a message arrived.
Connect the CRM and PIM without competing records
Give sales the context they need through the CRM
Decide which store activity your sales team actually needs in the CRM: a new account application, a first order, a rejected order, or order summaries.
Match each contact to the right company and location. Do not use an email address alone as the business account ID when one buyer orders for several branches. commercetools recommends one owner per type of data and a written matching rule (commercetools).
Keep "inquiry," "approved account" and "paying customer" as separate statuses if your sales process treats them differently. Otherwise reports will count an application as won business. Send follow-ups to a named rep, and test what happens when that rep is away.
Publish approved product content through the PIM
A PIM sends the product content your storefront shows, with product and variant IDs mapped consistently between systems (commercetools). Agree which fields the product team owns and which stay with finance or operations. Descriptions can go through an editorial process; contract prices and stock belong to the owners you set earlier.
Test three cases: an incomplete product, a changed variant and a discontinued item. Decide whether each is held back, shown with a warning, or blocked from ordering. An import that "succeeds" can still publish a product nobody can order correctly.
What this means for you: sales and product teams get useful data without overwriting operational decisions.
Choose an approach to e-commerce ERP integration for B2B
Four common ways to connect systems (commercetools):
| Approach | Suits you when | Avoid it as your main approach when | Work your team still owns |
|---|---|---|---|
| Ready-made connector | Your systems, versions and records are supported | Fields, versions or exceptions you need are not supported | Setup, field mapping, testing, support coordination |
| Integration platform (iPaaS) | Several systems need shared routing and data reshaping | Nobody can maintain the flows or pay the subscription | Flow rules, monitoring, changes, the vendor relationship |
| Custom API integration | A documented requirement cannot be met any other way | No one is funded to maintain the custom code | Code, security, recovery, hosting, updates |
| Scheduled file exchange | The business can live with the delay | A buying decision needs fresher data than the schedule gives | File checks, transfers, matching records, missed runs |
There are also two ways to wire it up. Point-to-point connects each system directly to each other system, which is fine for two or three systems but gets hard to manage as you add more. Hub-and-spoke routes everything through one central hub, such as an iPaaS or your commerce platform, which makes changes easier (Shopify).
An API is a way for software to request data or actions. An iPaaS (integration platform as a service) is hosted software that sits between systems and reshapes and routes data. Examples include Celigo, Boomi, MuleSoft and SAP Integration Suite (OrderEase; commercetools). These are not ranked; many setups mix them. Product content might move on a nightly schedule while orders move as they happen.
Ask every supplier to name the method for each connection. "Native integration" may cover one connector, not every record you need. Confirm system versions, custom fields, which way data flows, your busiest order volume, API limits, how fast the connection catches up after an outage, and paid add-ons. A connector that handles a standard retail order may not carry your account terms or negotiated prices, so ask to see your B2B records working.
What this means for you: choose the simplest approach your team can maintain that still handles every required flow.
Set rules for freshness, failures and monitoring
Syncing does not mean every record is always current. Shopify notes that its webhooks (automatic change notifications) can arrive out of order and that delivery is not always guaranteed, and it recommends regular reconciliation to catch missed changes (Shopify Dev Docs).
Agree how old each type of data may get. A product PDF and sellable stock do not need the same schedule. Decide what buyers see when data is older than the limit, such as ordering pausing or moving to manual review.
Ask the builder to show each of these working:
| Failure | What should happen |
|---|---|
| The ERP is offline | The order is kept, shown as pending, and the right team is alerted |
| A record is rejected | The reason is saved, an owner is named, and it can be fixed and resent |
| The same order is sent twice | The ERP recognizes it and does not create a second order |
| Updates arrive out of order | An older update cannot overwrite newer data |
| A notification is missed | Regular reconciliation finds and fixes the gap |
| Access expires | The technical owner is alerted, without account data in error messages |
Example: the ERP creates an order, but its confirmation never reaches the store. A blind retry could create a second order. Give every order a fixed reference, and make sure the ERP refuses a second order with the same reference, even when two retries arrive at once. If the store hears nothing back, check the ERP for that reference before trying again. If you still cannot tell whether the order went through, hold it for someone to investigate.
Three more risks to plan for:
- Security. Customer, price and financial data moves between systems. Ask for encrypted transfers, role-based access and audit logs (Shopify), with credentials and sensitive personal data removed or masked in those logs (OWASP).
- Updates and downtime. A system update can break a connection. Test updates in a staging copy first, and schedule them for quiet periods (OnSight).
- Older systems. If your ERP has no usable API, plan a phased approach, such as scheduled files first and a live connection later.
Then monitor the basics: how long orders sit pending, rejected records, the last successful update, and unresolved mismatches. A connection that shows "active" is not proof every flow is healthy.
What this means for you: your team can spot, own and fix a failed handoff.
Budget for it and launch one flow first
There is no useful general price for B2B e-commerce integration work, because it depends on your systems, records and rules. Ask suppliers to price the same scope, with separate lines for system access, connector or iPaaS subscriptions, field mapping, data cleanup, testing, monitoring, support and future changes. Flag charges that grow with usage or extra connections. Do not accept an estimate that leaves failure recovery or finance reconciliation undefined.
Start with one end-to-end flow using realistic test accounts and products. Prove an order can be accepted, shipped and matched in finance before you add more channels or automation. Use this checklist:
- The account and delivery location match in every system.
- Product variant, quantity and unit stay correct.
- The agreed price, currency and PO number survive the handoff.
- Operations can tell pending, accepted and rejected orders apart.
- Shipment and invoice details reach the right place, and payment status matches your B2B e-commerce payments setup.
- Duplicate, missing and rejected transfers each have a tested fix.
- Staff have monitoring access, instructions and someone to escalate to.
Train the people who will live with it, not just the project team. Sales, customer service and finance each need to know where to look when an order is stuck, and one named person per team helps colleagues adopt the new process (OnSight).
Measure against where you are today, such as manual fixes per order, order processing time, unresolved records, time from checkout to ERP acceptance, and support calls about price, stock or order status. These are things to track, not promised results.
For what your sales team needs to see from the store, see our B2B e-commerce agency page. Not sure where to start? Let's talk it through.
What this means for you: you can commission a defined flow with a budget, a test checklist and an owner.
Frequently asked questions
Which ERP is best for B2B e-commerce?
There is no single best one. NetSuite, Microsoft Dynamics, SAP, Epicor and Infor are common in B2B, and what matters is whether a tested connector exists for your version and your records, and who supports it.
Can you give an example of ERP integration?
A buyer orders 2 cases of valves on your site. The store sends the order, with the buyer's account, PO number and agreed price, to the ERP as a sales order for 20 units. The ERP confirms it, reserves stock, and later sends the shipment tracking and invoice back to the buyer's account page.
Can I keep my existing ERP?
Often, yes. Keeping it is worth evaluating before assuming you need a new one. Confirm it has an API or a usable export process, and that the proposed connection supports your version and your records (commercetools).
How long does B2B e-commerce integration take?
It depends on your systems and how much custom work is needed. A ready-made connector can shorten delivery when it supports your system version, records and exceptions. Ask each supplier for a timeline for the first working flow and for the full scope, with the assumptions behind each.
Can more than one ERP connect to the store?
It can be done, but treat it as a requirement to prove. Every record needs an ID that shows which business or system it came from, and you need a clear rule for which ERP receives each order before you choose an integration product.
Does integration require a headless storefront?
No. Connecting your business systems and building a separate storefront are different decisions. Check what your current store can already exchange before deciding the storefront itself must change.
How should returns be handled?
Name the system that approves and records returns, then decide which statuses the other systems need. Test a partial return and a refund without overwriting the original order history (commercetools).
