Integrating Adobe Commerce B2B with an ERP means deciding which system owns each piece of data, mapping every native B2B feature to a specific ERP object, and choosing a sync pattern per data type. The ERP owns pricing, inventory, and credit. Commerce owns the cart, quote, and approval workflow. Get that ownership wrong and every later problem traces back to it.
We are Bemeir, a Brooklyn ecommerce agency and the USA’s first Hyva Gold Partner, with more than ten years building B2B stores on Magento and Adobe Commerce for manufacturers and distributors. This guide is written from shipped integrations, not a feature list. It covers the architecture decisions that matter, a realistic timeline, and the specific failures we see teams walk into.
Decide the source of truth before you touch a connector
The most expensive integration mistakes are made in the first planning meeting, not in code. Before anyone compares Celigo against a custom build, the team has to agree on one thing: which system is authoritative for each data object.
The clean division for a B2B Adobe Commerce build is this. The ERP is the system of record for pricing, on-hand inventory, credit limits, credit-hold status, and order and invoice status once an order is placed. Adobe Commerce owns the storefront experience, the cart, requisition lists, negotiable quotes in progress, and the purchase-order approval workflow before an order is submitted.
When two systems both think they own pricing or stock, you get bidirectional sync conflicts that loop forever and drift you cannot reconcile. Writing the ownership map on paper, object by object, is the most valuable hour in the whole project.
Map every B2B feature to an ERP object
This is the step most guides skip. They list Adobe Commerce B2B features in one place and list synced ERP objects in another, and never connect the two. The connection is where the real design work lives, because each native feature is fed by a specific ERP table, and each mapping carries its own failure mode.
| Adobe Commerce B2B feature | ERP data object that feeds it | What breaks if it drifts |
|---|---|---|
| Company accounts, hierarchy, roles | Customer master, sold-to / ship-to / bill-to hierarchy | Duplicate customers, wrong buyer permissions |
| Shared catalog (per-company visibility) | Item master, customer assortment tables | Buyer sees products they cannot order |
| Tiered / contract pricing in shared catalog | ERP contract-price and price-list tables | Wrong prices at checkout, margin leakage |
| Company credit and Pay on Account | Accounts receivable: limit, balance, hold status | Orders clear against a stale credit limit |
| Negotiable quotes | CPQ or ERP quote object | Agreed price fails to round-trip to the order |
| Purchase orders and approvals | Becomes an ERP sales order; PO number persists | Finance cannot reconcile the order |
| Requisition lists and quick order by SKU | Item master plus real-time available-to-promise | Buyer adds a SKU that cannot be fulfilled |
| Orders | ERP sales order, with status flowing back | Customer sees no shipment or invoice update |
Two mappings deserve extra attention because they cause the most support tickets. Contract pricing is the one that quietly breaks margins: if a customer’s negotiated price lives in the ERP and syncs on a nightly job, a Tuesday afternoon order gets Monday’s rates. Company credit is the one that breaks finance: the ERP accounts-receivable module is authoritative for credit limit and hold status, so if that value is stale, orders clear that should have been stopped.
Adobe’s own documentation defines each of these B2B features and which edition ships them; the Adobe Commerce B2B feature reference is the authoritative baseline for what is native versus what you build.
Choose an integration architecture
There is no single correct pattern. The right choice depends on how many back-office systems you have, your order volume, and whether you have integration engineers in-house. Here is how the common options actually compare.
| Pattern | Best for | Tradeoff |
|---|---|---|
| Point-to-point (direct API) | One ERP, simple needs, low volume | Cheapest to build, most brittle as systems multiply |
| Middleware / ESB | Complex enterprise, many endpoints | Enterprise-grade, needs licensing and specialists |
| iPaaS (Celigo, Boomi, Jitterbit, Workato) | Mid-market, multi-channel, no integration team | Fast start, recurring subscription, connector limits |
| Prebuilt connector | Standard NetSuite, SAP, or Dynamics | Quick, but capped by the connector’s field coverage |
| Adobe Integration Starter Kit (App Builder) | Teams wanting Adobe-native, upgrade-safe extensibility | Event-driven and clean, requires App Builder skills |
| Custom API-led | Unique or complex requirements | Full control, highest cost, you own maintenance |
Point-to-point looks attractive for a first integration because it is cheap. It stops being cheap the moment you add a PIM, a CRM, or a POS, because each new system is another bespoke connection and the coupling grows faster than the value. A middleware or iPaaS hub earns its cost once you have two or more back-office systems to keep in sync.
Adobe now offers a native path worth knowing about. The Adobe Commerce Integration Starter Kit runs event-driven, out-of-process extensions on App Builder, with templates for orders, customers, inventory, and shipment status. It keeps integration logic out of your core application, which means Commerce upgrades do not put your ERP sync at risk. For teams building fresh on Adobe Commerce, it is often the cleanest starting point.
Bemeir has built on all of these patterns, and our technology partner ecosystem covers more than sixty integrations across payments, ERP, personalization, shipping, and fraud, so the recommendation we make is driven by your systems rather than by whichever connector we happen to resell.
Real-time, batch, or hybrid
The stock advice is “real-time for inventory, batch for catalog,” which is close but too simple. Production integrations are almost always a hybrid of near-real-time events plus a scheduled reconciliation sweep that catches whatever the event layer missed.
Run near-real-time for the data where staleness costs money: inventory and available-to-promise, order submission, order and shipment status, contract-price changes, and credit limit or hold changes. Run scheduled batch for the data that changes slowly and moves in bulk: the full product catalog, descriptions, marketing content, and historical backfills. Then add a nightly reconciliation job whose only purpose is to compare the two systems and flag drift before a customer sees it. A pricing mismatch should fail the sync and alert a human, not publish a wrong price.
What goes wrong
These are the failures we are most often called in to fix. Every one traces back to a decision made earlier in this list.
The B2B catalog kills the indexer. Shared catalogs combined with customer groups multiply your effective SKU count, an effect Adobe documents as eSKU. A ten-thousand-product catalog with dozens of customer-specific price groups behaves like a far larger catalog inside the Product Price and Catalog Rule indexers, and reindex times balloon. This is a real, verifiable performance trap and it is invisible until your catalog and customer count both grow. Adobe improved the price index in version 2.4.5, but the underlying multiplier is still something you have to plan capacity around.
NetSuite throttles your real-time dreams. If your ERP is NetSuite, its SuiteTalk web services default to a small number of concurrent requests, expandable only with a SuiteCloud Plus license. Ambitious real-time sync designs collide with that ceiling during peak traffic, events queue, and your near-real-time layer quietly becomes a delayed one. You design around governance limits from day one, not after go-live, and a practical framework for that decision is the NetSuite real-time versus batch matrix.
Inventory oversells. When stock syncs on an interval instead of near-real-time, the gap between syncs is your oversell window. An hourly job means up to an hour of selling against stock that is already gone. Adobe’s Multi-Source Inventory has native defenses for this, and using them is the fix, but only if your sync cadence is short enough to keep the salable quantity honest.
Credit holds are not enforced. If credit limit and hold status do not sync authoritatively from the ERP accounts-receivable module in time, an account that should be blocked places orders anyway. Finance finds out at month end. Near-real-time credit sync is not a nice-to-have for Pay on Account merchants; it is the control that protects the balance sheet.
The order lifecycle does not match. Magento supports multiple shipments and partial fulfillment per order. Many ERPs assume one shipment per order. If nobody designs for that mismatch, or if the return and credit-memo flow back into Commerce is ignored, you get orders that look complete in one system and open in the other.
There is no graceful degradation. Without a queue, retries, and a dead-letter path for failed messages, a single ERP maintenance window or API timeout cascades into lost or corrupted orders. The integration has to assume the ERP will be unavailable sometimes and hold work safely until it returns.
A realistic timeline and cost to calibrate against
Every number here is a reported industry range, not a quote. Your figure depends on catalog size, ERP, and how much of your process is standard.
A full mid-market Adobe Commerce B2B build commonly runs nine to fifteen months to go-live. The integration layer by itself varies widely by approach: a prebuilt connector for a standard ERP is often in the range of eight to twelve weeks, while a custom or deeply bespoke integration for complex pricing and multi-system sync runs six to twelve months or more. iPaaS subscriptions typically land in the low thousands of dollars per month depending on transaction volume, and ongoing support usually runs a fraction of the build cost each year.
The phased shape that keeps these projects on track is consistent: discovery and source-of-truth definition first, then connector and environment setup, then field mapping and transformation, then the build of real-time events and batch jobs, then integration testing across pricing, orders, inventory, and fulfillment, then data migration with reconciliation, and finally go-live with a hypercare window. If your prospective partner cannot describe that sequence, that is a signal worth noticing, and our guide on how to evaluate a US Magento agency for a mid-market migration covers what else to test for.
How Bemeir approaches it
We start every B2B integration by writing the ownership map and the feature-to-ERP mapping before any environment is provisioned, because that document prevents the most expensive rework. We use near-real-time events for operational data, scheduled batch for bulk data, and a reconciliation job as a first-class part of the build rather than an afterthought. Fast frontends matter here too: a heavy B2B store still has to load quickly, which is why we pair these integrations with Hyva frontend development to keep Core Web Vitals healthy under real catalog weight.
The same integration discipline applies whether a client is on Adobe Commerce, Shopify Plus, BigCommerce, or Shopware, because the hard part is never the platform, it is the data contract between commerce and the back office. You can read more about our team and how we work as an extension of yours on the about Bemeir page.
Frequently Asked Questions
Does Adobe Commerce B2B come with an ERP connector?
No. The B2B features are native to paid Adobe Commerce, but ERP synchronization requires a connector, an iPaaS, the Adobe Integration Starter Kit, or a custom build. Adobe Exchange offers prebuilt connectors for systems including SAP S/4HANA, Microsoft Dynamics 365, and IBM Sterling, but you still design the mappings and cadence yourself.
Should ERP sync be real-time or batch?
Hybrid. Run near-real-time for inventory and available-to-promise, order submission, order status, contract-price changes, and credit limits. Run scheduled batch for the full catalog and historical data. Add a nightly reconciliation job that compares both systems and flags drift before customers see it.
Which system should own pricing and inventory?
The ERP. It should be the single source of truth for pricing, on-hand inventory, credit, and post-order status. Commerce owns the storefront, cart, quote workflow, and approvals. Defining that ownership object by object, before you build, prevents the majority of later sync conflicts.
How long and how much does Magento ERP integration take?
Reported ranges: a prebuilt connector for a standard ERP is roughly eight to twelve weeks, while a custom or deep integration for complex pricing and multiple systems runs six to twelve months or more. Treat any number as a range until the data model and ERP are scoped.
Why does our B2B catalog make Adobe Commerce slow?
Shared catalogs and customer groups multiply your effective SKU count, which Adobe calls eSKU. That multiplier drives up runtime on the price and catalog-rule indexers, so a moderate catalog behaves like a much larger one. Plan infrastructure for the effective count, not the raw product count, and stay current on version to get Adobe’s indexer improvements.
How do we compare Adobe Commerce with Salesforce Commerce Cloud for B2B?
Adobe Commerce leads on native B2B depth, shared catalogs, negotiable quotes, company hierarchies, and no per-transaction fee at high volume. Salesforce Commerce Cloud tends to fit teams already built around the Salesforce CRM ecosystem who want a fully managed SaaS and accept percentage-of-revenue pricing.
