Adobe Commerce ERP Integration
Connect Adobe Commerce to SAP, Microsoft Dynamics, NetSuite and eight more ERPs, so stock, prices and orders match in both places.
Evrig has more than 17 years of experience building ERP integrations and has delivered them for many clients.
Adobe Commerce ERP integration links your storefront to your ERP so inventory, pricing, orders and customer data sync without manual entry. You can build it on Adobe Commerce APIs, use the ERP's native ecommerce features, or start from a prebuilt connector. Which route fits depends on your ERP, your customizations and how fresh each data type must be.
Why connect Adobe Commerce to your ERP
Your ERP knows what you own, what it costs and what a customer owes. Your storefront knows what people want to buy. When the two don't talk, someone fills the gap by hand, and that someone makes mistakes at 5 p.m. on a Friday.
Across our ERP projects, four gains show up first on the storefront side:
Fewer ordering mistakes
The store shows current availability and pricing, so shoppers can't order what is out of stock or get charged a wrong price
Workflow automation
Fulfillment, inventory restocking and new product introductions run without someone re-keying data
Customer self-service
Buyers see their order history, credit limits and buying trends in one place
Better reporting
The ERP sees online sales and customer data, so leadership reads one picture of the business
In the back office, the team stops reconciling spreadsheets, finance sees each sale in the ledger without re-keying, and buyers can plan stock closer to real demand.
What to sync first.
Start with inventory, product data, pricing and order status. For each one, we agree up front which system owns it, how often it updates and who maintains it. Skip that decision and you end up with two systems that each claim to be right.
What data moves between Adobe Commerce and your ERP
Not every record needs the same speed. Product descriptions can wait an hour. A price or a stock count cannot. This is the split we use on most projects. Your business model may change the directions, so we confirm each row in discovery.
| Data | Direction | Typical pattern | How much lag is acceptable |
|---|---|---|---|
| Products and items | ERP to Commerce | Batch, hourly or nightly | High |
| Customer accounts | ERP to Commerce | Batch, hourly or nightly | High |
| Stock and inventory | Both ways | Event-driven or real-time | Low |
| Pricing | Both ways | Event-driven or real-time | Low |
| Orders | Commerce to ERP | Real-time on submit | None |
| Order status and shipping details | ERP or OMS to Commerce | Set per workflow | Depends on what you promise customers |
Where you run a separate order management system, order status and tracking usually come from it rather than the ERP. We map that source once, so customers never see two different statuses.
The risk of batch-only sync.
A product discontinued in the ERP at noon stays orderable until a midnight job runs. That is why we batch the catalog and use events or live calls for stock and price.
Why events matter.
Adobe Commerce can publish more than 700 events, such as an order placed or a product saved, to outside systems. We use these to push changes the moment they happen instead of polling on a timer.
Four ways to integrate, and when each one fits
There are four realistic routes. Most of our projects use one as the backbone and borrow from another where it saves time.
| Approach | Fits best when | Watch out for |
|---|---|---|
| Prebuilt connector from the Adobe Commerce Marketplace | A maintained connector exists for your ERP and version, and your processes are close to standard | Heavy customization on either side. Connectors assume a standard data model |
| Back-office integration starter kit with App Builder | You want a custom build that starts with onboarding, data mapping, validation and connection monitoring already in place | It speeds up the plumbing. You still decide which system owns each data type |
| Middleware layer (App Builder, MuleSoft or a custom API layer) | B2B with live pricing or availability, several connected systems, or ERP and Commerce upgrades on different schedules | Treat it as a product with its own tests and releases. It is the part that changes most over time |
| Direct point-to-point API calls | Small scope, one ERP, few data types, a team ready to maintain it | Direct links get brittle once the two systems upgrade on different cycles |
Our position.
If you expect to change your ERP, add a PIM or an OMS, or run more than one storefront, build the middleware layer from day one. A point-to-point link is cheaper in month one and more expensive in month eighteen. If your ERP has a maintained Marketplace connector and your order-to-cash flow is standard, buy it and spend the saved budget on testing.
What the starter kit gives you.
Adobe's starter kit runs on App Builder with serverless functions and I/O events. It ships with scripts for onboarding, data mapping and validation, plus dashboards to watch each integration. We use it when it fits and extend it with your business rules, retries and alerts.
B2B decisions that shape every ERP integration
Whichever ERP you run, it usually holds the master data for products, pricing, customers and stock. We treat every project as an ownership question first and a coding question second: which system owns what, how each data type flows, and where the business logic lives.
| Topic | What we see across ERPs | What we plan for |
|---|---|---|
| Product data | ERP item records carry units of measure, warehouses, item groups and classifications that Commerce does not have. Mapping them is a translation, not a copy | A field-level mapping document before any build |
| Customer link | The ERP customer number ties every order, quote and invoice back to the right account | Store it on the Commerce company account from day one |
| Live availability | Many ERPs can calculate a confirmed quantity and delivery date, not just a stock count. Commerce has no built-in batching or caching for these calls | One batched call per cart, cached for a few minutes, in the middleware |
| Live pricing | Contract prices, volume breaks and customer-specific discounts often live in the ERP's pricing engine. Commerce has no built-in place to show a price calculated elsewhere | Front-end work wherever a price appears, plus a fallback when the ERP is unreachable |
| Speed | Every live call to the ERP adds time to the page | Measure it early and set a performance budget |
| Shared catalogs | Commerce custom pricing is a fixed price per SKU. Layered ERP price rules do not map natively | Resolve complex pricing in the ERP or middleware and write flat values into Commerce |
| Company hierarchies | Available from Adobe Commerce B2B 1.5. Catalogs, pricing and credit limits do not pass down to child accounts | Assign each company account its own catalog, price setup and credit limit |
| Quotes and POs | Negotiable quotes and approval rules are native in Commerce. An approved PO becomes an ERP sales order with the Commerce PO number as reference | Test quote to order to ERP sales order end to end before UAT |
| Deployment | Adobe Commerce PaaS, SaaS and Adobe Commerce Optimizer handle the catalog differently | Confirm your deployment model before designing anything |
Your ERP version matters.
The sync patterns open to you depend on which modules and release you run and which APIs or events it exposes. Listing these is our first step on every project.
We build a mapping matrix early.
For every B2B buyer: ERP customer number, Commerce company account, shared catalog, pricing source. One clear row each. Ambiguity here causes pricing errors in production that are hard to trace.
ERP systems we connect to Adobe Commerce
Evrig has more than 17 years of experience building ERP integrations and has delivered them for many clients. Whichever system you run, the questions are the same: who owns the data, how fast must it move, and what happens when one side is down.
Each ERP exposes its data differently, so the sync design starts from what your ERP offers. The table shows the interface we usually connect through and what typically moves. Exact options depend on your product edition and version.
| System | Type | How we usually connect | What we typically sync |
|---|---|---|---|
| SAP (ECC, S/4HANA) | ERP | IDoc, BAPI and RFC, OData services, SAP Integration Suite, or a Marketplace connector for S/4HANA | Material master, customers, stock with available-to-promise, pricing through order simulation, sales orders, invoices |
| Oracle NetSuite | Cloud ERP | SuiteTalk REST or SOAP web services and RESTlets | Items, inventory by location, customers and price levels, sales orders, fulfillments, invoices |
| Microsoft Dynamics 365 | ERP | Dynamics 365 APIs and OData endpoints, or a Marketplace connector | Products, inventory, customer accounts and credit limits, price lists, orders, shipments |
| Epicor Kinetic and Prophet 21 | ERP | Kinetic REST API and P21 API | Items, multi-location stock, customer-specific pricing, quotes, orders, shipment tracking |
| Infor (CloudSuite, M3, SyteLine) | ERP | Infor ION and product APIs | Items, inventory, customers, pricing, orders, shipments |
| IFS | ERP | IFS Cloud REST and OData APIs | Parts, inventory, customers, pricing, customer orders, deliveries |
| QAD | ERP | QAD APIs and integration services | Items, inventory, customers, pricing, sales orders, shipments |
| Odoo | ERP | Odoo external API (XML-RPC or JSON-RPC) | Products and variants, stock, customers, price lists, sales orders, invoices |
| Acumatica | Cloud ERP | Acumatica contract-based REST API | Stock items, warehouse quantities, customers, price classes, sales orders, shipments |
| Sage (Intacct, X3, 100/300) | ERP and accounting | The API of your Sage product, which differs by edition | Customers, items, stock, orders, invoices, payments |
| ERPNext | Open-source ERP | Frappe REST API | Items, stock by warehouse, customers, price lists, sales orders, invoices |
Cloud, on-premises or hybrid changes the design.
An on-premises ERP behind a firewall needs a secure route out, such as a VPN or an on-site agent. A cloud ERP brings API rate limits. Either way, we size the integration for your peak traffic and order volume, not your average day.
Your ERP is not on this list?
If it exposes an API, file exchange or a database interface, it can be connected. Send us the product name and version.
How an integration project runs
Every integration we deliver follows the same six steps, whichever ERP you run.
01
Goals and workflows. We start with what the business needs the integration to do: omnichannel selling, adding B2B or direct-to-consumer, cross-border markets. Then we document the workflows behind those goals, including checkout steps like availability checks, payment and fraud checks.
02
Data ownership map. For inventory, product data, pricing and order tracking we agree the system of record, how often each updates and who maintains it.
03
Architecture and infrastructure. Connector, starter kit, middleware or direct API, sized for your traffic and transaction volume, and for a cloud, on-premises or hybrid setup. Subscription and installment payment tools get planned in at this stage, not later.
04
Build and test. End-to-end tests cover the unhappy paths: ERP unavailable, partial shipments, failed order submission, stale cache. Where pricing or availability comes live from the ERP, we test latency against a stated budget.
05
Agreed SLAs for data flows. We write down how fast each data type must arrive, allowing for your ERP's normal response times, planned maintenance and slowdowns during month-end or heavy reporting.
06
Support. A named contact on your side and ours for the life of the integration.
What drives the cost
Here are the cost drivers up front, so you can judge any quote, ours included.
- Age of the systems. Older ERP or ecommerce versions need extra work to connect to current software.
- Customization. The more either side is modified, the less a standard connector helps.
- Number of data domains. Catalog-only sync is a smaller job than catalog, stock, pricing, customers and orders.
- Real-time requirements. Live availability and price lookups need custom middleware logic and front-end work at every place they appear.
- Data variety and quality. Different formats across systems add mapping and cleanup.
Planning an Adobe Commerce ERP integration?
For Adobe Commerce integration with your ERP, contact Evrig.
Frequently asked questions
Connect ExpertTalk to an engineer about your ERP
Tell us which ERP you run and which data is giving you trouble.
Send the ERP name and version, your Adobe Commerce edition and what breaks today. You will get a straight answer on whether a connector, the starter kit or a middleware build fits, including when the answer is "you don't need a custom project".