The Adobe Commerce B2B integration with an ERP is rarely “use the connector.” It is a decision about which record types sync, in which direction, on what cadence, with what conflict resolution, and how exceptions are handled. The merchants who treat the integration as a vendor configuration task end up with integrations that work for the happy path and break on the edge cases that B2B operations actually live in. The merchants who treat it as an architectural decision get integrations that scale with the business.
This piece walks through the integration patterns for Adobe Commerce B2B with the three ERPs most common at mid-market B2B scale: NetSuite, SAP Business One, and Microsoft Dynamics 365 Business Central. The framework is the version Bemeir’s Adobe Commerce team uses to architect B2B ERP integrations on real engagements; the patterns are not unique to these three ERPs but they show up most often in mid-market work.
The record types every B2B integration touches
Across ERPs, the record types that need integration treatment:
Customers and accounts. ERP master data for companies, contacts, and account hierarchies. Adobe Commerce B2B companies map to the ERP’s account structure. The mapping is rarely 1:1; ERPs often have richer account taxonomies (account types, classifications, sales rep ownership) than Adobe Commerce models natively.
Products and pricing. Product master data, SKUs, attributes, and pricing tiers. The ERP is usually the system of record for product data; Adobe Commerce consumes it for the storefront. Pricing is more nuanced because Adobe Commerce supports tier pricing, customer-specific pricing, and contract pricing patterns that need careful mapping.
Inventory. Stock levels by warehouse, available-to-promise, and committed inventory. The ERP knows the truth; Adobe Commerce needs the truth at storefront display time and at order placement time.
Orders. Adobe Commerce captures the order; the ERP fulfills it. The integration moves orders from Adobe Commerce to ERP. The reverse flow (shipments, invoices, returns) goes from ERP back to Adobe Commerce for customer-facing display.
Credit and payment terms. B2B customers have account credit limits, payment terms (Net 30, Net 60), and credit holds. The ERP is the source of truth; Adobe Commerce needs the data to enforce checkout rules.
Tax. Tax determination on B2B orders, especially across jurisdictions, often involves dedicated tax engines (Avalara, Vertex) sitting alongside the ERP. The Adobe Commerce integration coordinates with both.
Returns and credit memos. Returns initiated through Adobe Commerce flow to the ERP for credit memo creation; the customer-facing return status flows back.
Integration patterns by direction and cadence
For each record type, three architectural decisions:
Direction. ERP → Adobe Commerce (one-way), Adobe Commerce → ERP (one-way), or bidirectional.
Cadence. Real-time, near-real-time (within minutes), or batch (daily or scheduled).
Conflict resolution. When the same record is updated in both systems, who wins?
The standard pattern for each record type:
| Record type | Direction | Cadence | System of record |
|---|---|---|---|
| Customer accounts | Bidirectional with ERP as source of truth for company hierarchy | Near-real-time | ERP for master data, Adobe Commerce for storefront-specific fields |
| Products | ERP → Adobe Commerce | Near-real-time for changes, batch for full sync | ERP |
| Pricing | ERP → Adobe Commerce | Real-time on order placement (call-out), batch for catalog display | ERP |
| Inventory | ERP → Adobe Commerce | Near-real-time | ERP |
| Orders | Adobe Commerce → ERP | Real-time on order placement | Adobe Commerce captures, ERP fulfills |
| Shipments | ERP → Adobe Commerce | Near-real-time | ERP |
| Invoices | ERP → Adobe Commerce | Near-real-time | ERP |
| Credit and terms | ERP → Adobe Commerce | Near-real-time on customer activity | ERP |
These are starting points; specific engagements adjust based on operational requirements.
NetSuite-specific patterns
NetSuite integrations with Adobe Commerce are common at mid-market scale, especially for B2B distributors and manufacturers. The patterns:
SuiteTalk APIs. NetSuite exposes SOAP and REST APIs (now under the SuiteTalk umbrella). REST is preferred for new integrations.
Saved searches as integration data sources. A clean pattern is to define NetSuite saved searches that produce the integration’s view of records, then have the integration consume the saved search output. This decouples the integration from internal NetSuite structure changes.
RECORDS API for bulk operations. For bulk inventory sync or bulk price list updates, the RECORDS API is more efficient than per-record REST calls.
Common integration middleware. Celigo’s iPaaS, Boomi, MuleSoft, and Workato all have pre-built connectors for NetSuite + Adobe Commerce. For most mid-market engagements, an iPaaS handles the standard record sync and custom code handles the edge cases.
Customer hierarchy handling. NetSuite supports parent/child customers natively. Adobe Commerce B2B’s company hierarchy maps to this with some translation; the integration needs explicit handling of the parent/child relationship.
SAP Business One-specific patterns
SAP Business One is common at smaller and mid-market B2B operations. The patterns:
Service Layer API. SAP B1’s REST-style Service Layer is the integration entry point. It is functional but the operational tolerance for bursts is lower than NetSuite’s APIs.
DI API for higher-volume operations. The DI API is more performant for bulk operations but more complex to integrate.
Database-direct integration patterns (legacy). Older SAP B1 integrations sometimes hit the database directly. This is increasingly discouraged for support and upgrade reasons; new integrations should use Service Layer.
Customer pricing complexity. SAP B1’s pricing system supports special prices per customer, discount groups, and pricing periods. Mapping all of this to Adobe Commerce B2B’s pricing model requires careful translation; not every SAP B1 pricing pattern has a clean Adobe Commerce equivalent.
Stock query latency. Real-time stock queries to SAP B1 can be slower than to NetSuite. Cache stock at the Adobe Commerce side with short TTL to handle the query volume.
Microsoft Dynamics 365 Business Central-specific patterns
Microsoft Dynamics 365 Business Central is the modern Microsoft ERP for mid-market. The patterns:
OData and REST APIs. Business Central exposes data via OData v4 and via REST APIs. Both are well-documented.
Microsoft Power Automate as integration layer. Power Automate provides low-code integration between Business Central and external systems. For straightforward sync patterns, this can be an alternative to a full iPaaS.
Azure Integration Services for enterprise scale. At higher volume, Azure Logic Apps + Service Bus is the Microsoft-native integration stack and integrates cleanly with Business Central.
Dimensions and analytics codes. Business Central uses dimensions extensively for analytical reporting. The integration needs to populate the correct dimensions on incoming orders so that the data analysis on the Business Central side remains meaningful.
Customer ledger and credit handling. Business Central’s credit limit and payment terms work cleanly with Adobe Commerce B2B’s credit limit feature. The integration is typically less complex than the NetSuite or SAP B1 equivalent for this aspect.
The patterns that trip up integrations
Six categories of issue that consistently emerge:
Idempotency. Every integration message should be safe to retry. Implementing this requires unique identifiers on each message, server-side deduplication, and explicit handling of “this message is older than current state” cases. Without it, network glitches produce duplicate orders or duplicate inventory updates.
Order state synchronization. Orders move through states (pending, in process, fulfilled, shipped, invoiced, paid) and both systems can have opinions. Define the canonical state machine and which system owns each transition.
Failed integration messages. When a message cannot be processed (the customer record references a missing parent account, the product SKU does not exist on the other side), where does the message go? Dead letter queues, alerting, and manual reconciliation workflows are essential.
Backfill and full sync handling. The first sync moves all data; subsequent syncs move only changes. The transition between full sync and incremental sync is a common source of bugs.
Pricing edge cases. B2B pricing is rife with edge cases: contract pricing, volume tiers, customer-specific overrides, time-bounded promotions. Each edge case needs explicit handling or the integration produces wrong prices on those orders.
Inventory accuracy lag. Real-time inventory is impossible at scale; near-real-time with cache invalidation is the achievable target. Decide the tolerable lag and design for it.
What good integration delivery looks like
A production-grade ERP integration delivers:
Documented integration contract. Per record type, what is the field-level mapping, what is the direction, what is the cadence, what is the conflict resolution.
Observability. Every integration message logged. Failed messages alerted. Latency tracked. Backlogs monitored.
Reconciliation tooling. Periodic checks that the two systems agree on what they should agree on. Discrepancies surfaced for manual review.
Operational runbook. What to do when the integration is failing. Who is paged, what are the first three diagnostic steps, what is the rollback procedure.
Test coverage. Integration tests for the standard flows and explicit tests for known edge cases.
Bemeir builds Adobe Commerce B2B with ERP integration as a parallel workstream to the storefront build because the integration determines whether the store can actually operate at scale. The merchants who treat the integration as a configuration task ship integrations that work for demo and fail in production. The merchants who treat it as architecture get integrations that scale.
The Adobe Commerce GraphQL B2B documentation and the respective ERP API documentation provide the technical building blocks; the framework above is what bridges them to integrations that work in production. The work is well-understood; the variable is the operational rigor of the team building it.
