Generative AI in eCommerce: How Can eCommerce Brands Leverage Generative AI?
Category
Apps and Integrations
Review asked whether daily CSV exports are still a real behaviour in 2026. Fair challenge. At $2M–$50M GMV the more common broken state is a connector that half-works, not a spreadsheet, and leading with CSV risks reading as dated to that reader. The intro below leads with the range of broken states instead. Manual processes do persist – Rocketline’s documented starting point was reps managing orders and pricing by hand – so it stays in, as one case rather than the premise.
There is a moment in most growing stores where somebody quietly becomes the integration.
Sometimes it is literal: a person exporting orders each morning and re-keying them into the ERP. More often it is subtler. A connector that works until someone adds a product variant. An app nobody owns that silently stopped syncing in March. A finance team reconciling two systems by hand at month end because neither one is trusted.
That is what eCommerce ERP integration projects are actually trying to fix. Not a strategy gap – a set of small daily failures nobody has owned long enough to price.
The difficulty is that almost everything written on this topic is published by a company selling an ERP-connected platform or an integration product. Their answer to “should we integrate?” is structurally always yes, and always through them.
We build custom integrations, and we still tell clients to use the native connector when the native connector will do. This guide is written from that side of the table.
Most of the specifics come from two builds: a BigCommerce B2B platform synced bi-directionally to NetSuite, and a Magento 2 estate spanning 49 retail locations running against Microsoft Dynamics NAV. Where something is not from our own work, the post says so.
Key Takeaways
- eCommerce ERP integration is not one connection. It is four separate data flows – orders down, inventory up, customers and pricing across, fulfillment and financials back – each with its own cost and its own failure mode.
- ERP, CRM and order management systems are not interchangeable. Deciding which system is authoritative for each record is the architecture decision; everything else is implementation.
- The hardest variable is rarely your storefront. It is your ERP’s version and API surface, and the gap between a modern REST or OData interface and an older file-drop bridge is the difference between weeks and months.
- If your SKU is not the same string in both systems, you do not have an integration project yet. You have a data hygiene project.
- Three routes exist: native connector, iPaaS subscription, custom build. Most merchants under roughly 5,000 orders a month with standard flows should take the first one.
- The most expensive failure is silent. On one BigCommerce B2B platform we maintain, adding real-time monitoring and automated alerts cut potential disruptions by 85%.
- Sequence the flows. Shipping one direction end to end beats scoping all four and delivering none.
What is ERP integration, and what does it mean for eCommerce?
ERP integration is the automated exchange of data between an enterprise resource planning system and another business system. In eCommerce, that other system is your storefront: an order placed online appears in the ERP without anyone re-typing it, and a stock level changed in the ERP appears on the storefront without anyone uploading a file.
That definition sounds obvious. What it hides is that “the data” is not one thing, and the two systems disagree about who owns it.
ERP integration, CRM integration and order management are three different problems
These get used interchangeably in briefs and then produce wildly different quotes. They are different systems owning different records.
| System | Owns | Why it matters for the build |
|---|---|---|
| ERP | Inventory, financials, purchasing, cost, the item master | Usually the authoritative source for stock and price. Most integration disputes are really disputes about this |
| CRM | Contacts, accounts, opportunities, marketing history | Overlaps with the ERP on customer records. Deciding which one wins prevents a permanent sync loop |
| OMS | Order lifecycle, allocation, routing, split fulfillment | Sits between store and ERP when order logic is more complex than either system handles alone |
If your project is really about customer and marketing data rather than stock and financials, it is an eCommerce CRM integration and should be scoped as one.
If physical retail locations are in scope, eCommerce POS integration is a third data source with its own reconciliation rules.
For the wider picture of how ERP sits alongside CRM, PIM, POS and warehouse systems, our overview of eCommerce integrations maps the whole stack.
The four sync directions most guides treat as one thing
Ask three vendors to quote “an ERP integration” and you will get three prices for three different scopes. This is why. Each of these is a separate build with its own logic, edge cases, and way of going wrong.
| Direction | What moves | The hard part |
|---|---|---|
| Orders down | Storefront order → ERP sales order | Mapping discounts, taxes, shipping and gift cards onto ERP line items designed for a sales rep, not a checkout |
| Inventory up | ERP stock levels → storefront availability | Deciding how stale is acceptable, and what happens in the window between the last sync and the next one |
| Customers and pricing | ERP accounts, price lists, catalog → storefront | B2B tiered and contract pricing, which almost never maps cleanly onto storefront price fields |
| Fulfillment and financials back | ERP shipments, tracking, invoices, credit memos → storefront | Partial shipments, split fulfillment, and returns processed in the ERP that never told the storefront |
You do not have to build all four. Most merchants get the majority of the value from the first two, and a surprising number never need the fourth.
When you need eCommerce integration with ERP – and when you don’t
The honest trigger is not revenue. It is the point where manual reconciliation costs more than the integration would, or where the error rate starts reaching customers.
Three signals you are past that point: someone’s job description includes moving data between systems; you have oversold stock more than once because the storefront did not know something shipped; or your finance close is late because order data arrives in batches.
Three signals you are not there yet: your order volume still fits comfortably in a daily batch; your catalog is small and stable; or you are about to replatform. That last one matters more than people expect. Building an integration against a storefront you are replacing in six months is money you will spend twice.
The readiness test: five questions before anyone scopes anything
Run these before you take a single vendor call. Two of them regularly stop projects.
- Does your ERP have a documented REST or OData API on the version you are running, or does your version require a file drop, an ODBC bridge, or a Windows-only client library?
- Is your SKU the identical string in both systems, including case and separators? If not, this is a data project before it is an integration project.
- Who owns the master record for price and for inventory? Write the answer down. Two teams answering differently is the most common cause of a rebuild.
- What is your acceptable inventory staleness window – five minutes, an hour, overnight? This single number changes the architecture and most of the cost.
- Do you have a non-production ERP instance to test against? Without one you are testing in the system that runs your business.
Question two is the one that stops projects. Catalog and SKU discipline is a prerequisite, not a phase, and it is usually an eCommerce PIM conversation.
What gets connected in an ERP eCommerce integration
Orders down: from checkout to sales order
The storefront creates an order; the ERP needs a sales order. For a simple direct-to-consumer store that is close to a field mapping exercise.
It stops being simple at bundles and kits, where one storefront line becomes several ERP lines; at mixed-tax baskets; at discounts applied at basket level in the store and line level in the ERP; and at anything sold as pre-order or backorder. Each is a decision, not a mapping.
Orders placed outside the storefront are their own problem. On the Surplus Furniture build, offline orders across 49 locations were disconnected from Magento entirely, so customers could not pay online for a phone or in-store order and finance had no automated reconciliation. We built a secure bi-directional API between Magento, Dynamics NAV and the payment gateway: scheduled jobs detect orders with outstanding balances, the customer receives a verified checkout link, and completed transactions write paid and outstanding balances back to NAV across every location in real time.
Inventory up: the flow that costs you customers
This causes the most customer-facing damage and gets the least design attention. The core question is what happens in the gap between syncs, because that gap is where overselling lives.
Surplus Furniture is the clearest example we have. Without real-time stock synchronisation between Dynamics NAV and Magento, clearance items at zero stock stayed visible and purchasable on the frontend. The result was failed orders, refund requests and avoidable strain on fulfillment. The fix was an automated sync module that continuously monitors ERP stock levels and removes out-of-stock items from the storefront without anyone touching it.
Multi-warehouse allocation makes it harder again. If the ERP holds stock across three locations and the storefront shows one number, someone must decide the rule for producing that number, and whether it reserves, buffers, or exposes everything. That decision belongs with whoever owns eCommerce warehouse management, not with the integration developer.
Customers, pricing and catalog: where B2B budgets go
For direct-to-consumer stores this flow is often optional. For B2B it is usually the entire reason for the project.
Contract pricing, customer-specific price lists, credit limits and account hierarchies live in the ERP and have no native equivalent in most storefront price models. This is where custom work concentrates, and it is why B2B integrations cost more than the equivalent D2C build.
On the Rocketline build this was the project. Their NetSuite instance held a web of interconnected pricing logic – customer-specific rates, quantity thresholds, product-level exceptions – and replicating it meant building a rules engine inside BigCommerce rather than mapping fields. Pricing tables recalculate in real time by customer role, category and quantity. Getting it wrong would not have been a bug; it would have been a revenue and trust problem.
If your buyers procure through a punchout catalog, that adds another layer on top, and it is worth reading how it fits the wider B2B eCommerce picture before scoping.
Fulfillment and financials back: closing the order-to-cash loop
Tracking numbers, invoices, credit memos and returns flowing back to the storefront so the customer account page tells the truth.
Partial and split shipments are the complication. An order shipped from two warehouses on two days produces two ERP fulfillments and one storefront order that has to represent both without confusing the customer or double-charging shipping. This is the flow people mean when they ask which ERP handles order-to-cash best, and the answer is usually less about the ERP than about who owns the order state machine.
Where an eCommerce order management system fits
Not every merchant needs one. An order management system earns its place when order logic outgrows what the storefront and ERP handle between them – typically multi-channel selling, allocation rules across several warehouses, split and partial fulfillment, or heavy returns volume.
The practical test: if you are writing complex allocation and routing logic into the integration itself, you are building an OMS badly. At that point an order management system for eCommerce sits between the two, owns the order lifecycle, and lets the ERP go back to being the financial and inventory system of record.
For merchants running several storefronts or channels, visibility usually needs solving before more automation does. That is closer to the multi-platform eCommerce dashboard work we have done than to a point-to-point sync.
EDI and ERP integration for wholesale buyers
If you sell to large retailers or distributors, some trading partners will not use your storefront at all. They will send EDI documents – purchase orders, advance ship notices, invoices – and expect them mapped into your ERP on their schedule and their format.
EDI ERP integration runs parallel to the storefront sync rather than through it, and it is worth naming in scope early. Discovering a mandated EDI requirement from a major account halfway through a storefront project is a common and expensive surprise.
ERP integration by platform: Shopify, BigCommerce, Adobe Commerce and WooCommerce
The storefront is usually the easier half of the problem, but the platform still sets real constraints on how you build.
Shopify ERP integration: custom apps, webhooks, and getting locations right first
A custom app on the Admin GraphQL API, webhooks for order events, and bulk operations for large catalog or inventory pushes. Shopify Flow can trigger simple handoffs on Plus.
Two constraints shape the build. API rate limiting pushes you toward bulk operations and a queue rather than per-record calls. And inventory is tracked per location, so your ERP warehouse model has to map onto Shopify locations before anything else works – get that wrong and every downstream flow inherits the error.
NetSuite is the most commonly paired ERP here, and established connectors exist for that combination. That is exactly the case where you price the connector before pricing a build. Where custom wins on Shopify is when several systems have to stay consistent with each other, as in the custom Shopify platform with multi-system integration we built for a fundraising client. Our Shopify Plus development team handles that class of work.
BigCommerce ERP integration: the cleanest API surface of the four
Strong REST and GraphQL APIs, generous rate limits relative to peers, and a catalog API that handles write-back well. This is generally the least painful platform for ERP work, particularly for B2B, where price lists and customer groups are first-class concepts rather than workarounds.
It is also where most of our own ERP work sits. Rocketline runs BigCommerce B2B Edition synced to NetSuite. Generation Pet runs a BigCommerce Enterprise B2B storefront whose checkout logic and ERP integration are handled by a custom third-party server. Two very different architectures on one platform, which is a fair signal of how much room BigCommerce leaves you.
For the wider set of connections this platform supports, see our guide to BigCommerce integrations, or our BigCommerce development services if you are scoping a build.
Magento and Adobe Commerce ERP integration: most control, heaviest build
Integration happens through REST, GraphQL, or a custom module, and for anything high-volume the work should run asynchronously through message queues rather than in the request cycle. Adobe Commerce also has the richest native B2B feature set of the four, which can reduce how much pricing logic you replicate.
Magento is where our Dynamics NAV work sits. Our Surplus Furniture Magento 2 optimization and ERP integration project runs 49 retail locations with independent inventory, location-based pricing and interconnected data flows, integrated bi-directionally with NAV and the payment gateway. The platform absorbed a custom multi-step checkout with store-specific pickup rules, an automated inventory reconciliation module, and a dynamic pricing engine spanning all 49 storefronts – the kind of extension our Magento development team relies on and most platforms do not allow.
WooCommerce ERP integration: cheapest to start, hardest to scale
The REST API is capable, but WordPress cron is not a reliable scheduler for a business-critical sync. Anything beyond a few hundred orders a day needs an external worker or queue running outside WordPress, and budgeting for that from the start avoids a rebuild at month six.
WooCommerce can carry serious B2B operations, as our enterprise WooCommerce B2B transformation shows, but the integration layer is the part that has to be engineered rather than configured, which is why our WooCommerce development team scopes it separately from the storefront.
Which ERP you run changes the build more than which storefront
This is the section most guides skip, and it is the one that determines the timeline. Two rows below are first-hand. The other four describe published integration surfaces, and we would rather say so than imply otherwise.
| ERP | Integration surface | What it means for the build |
|---|---|---|
| NetSuite – first-hand | SuiteTalk REST and SOAP, RESTlets, SuiteScript | Mature and well documented. On our BigCommerce B2B build the constraint was never the API surface – it was governance and concurrency limits, which shaped the batching strategy more than any other decision |
| Microsoft Dynamics – first-hand | Dynamics 365 Business Central: native REST and OData v4, AL extensions. Older NAV installs: web services and custom endpoints | On our Magento 2 build against NAV, the work was bi-directional and real-time across 49 locations. Business Central is cleaner again; the older the NAV install, the more you build around rather than with |
| Acumatica | Contract-based REST API, cloud-native | Modern and consistent; usually a straightforward build |
| SAP Business One | Service Layer (OData) or the older DI API | Depends heavily on version and on cloud versus on-premise. Service Layer is the path you want; DI API work is materially slower |
| Sage | Varies by product – Intacct, X3, 100, 200 and 300 differ substantially | Do not scope “Sage” as one thing. Confirm the exact product and version before estimating |
| Epicor | Kinetic REST API on current releases; older versions rely on service connect | Version determines effort more than any other factor |
The pattern across all six is the same: the ERP version matters more than the ERP brand. A current cloud release of almost any of these is a reasonable build. A ten-year-old on-premise install of the same product can double the timeline.
Whichever system you are on, the integration is an eCommerce API integration underneath – authentication, rate limits, payload shape, retry behaviour and error handling. Those five things decide the effort far more than the vendor logo does. Rocketline’s and Surplus Furniture’s starting points – an aging ERP in one case, a decades-old install in the other – set their schedules more than anything on the storefront side did.
Custom build, iPaaS, or native connector: how to evaluate your options
Three routes, and the right one is genuinely often not the custom build.
| Route | Choose it when | What you give up |
|---|---|---|
| Native connector | One ERP, one storefront, standard flows, no unusual pricing or fulfillment logic. Most merchants under roughly 5,000 orders a month | Flexibility. When your requirement falls outside the connector’s model you cannot extend it |
| iPaaS platform | Several systems beyond the ERP, mostly standard flows, and an internal team that wants to own and change the logic | A permanent subscription, and a ceiling on how unusual your logic can get |
| Custom build | Non-standard business logic, B2B contract pricing, multi-warehouse allocation rules, high volume against a governed API, or a connector subscription that exceeds build cost over three years | You own maintenance. Budget for it or the integration decays |
We build custom integrations. We also tell merchants to buy the connector when the connector fits, because a custom build that replicates something you could have configured is an expensive way to arrive at the same result. The three-year total cost comparison is the honest test, and it is worth running before anyone writes a proposal.
Where custom genuinely wins is the logic no connector models: allocation rules across warehouses, contract pricing with approval workflows, a catalog where one storefront product maps to several ERP items, or a payment reconciliation flow spanning 49 physical locations. If your requirement is in that territory, our eCommerce development team scopes it as a defined build rather than an open retainer.
Not sure which route your ERP and platform actually need?
We scope that comparison before proposing a build, starting with your ERP version and data readiness.
Book a Free ConsultationWhere ERP integrations break, and the guardrails that hold
None of these are exotic. All are common, and all are cheaper to design around than to fix in production.
| Failure mode | What happens | Design around it with |
|---|---|---|
| Oversell in the sync gap | Stock sells out between two inventory pushes and the storefront keeps taking orders | A safety buffer on low-stock items, plus event-driven decrements rather than scheduled pushes alone |
| Duplicate orders on retry | A timeout triggers a retry and the ERP receives the same order twice | Idempotency keys on every write; never rely on the ERP to deduplicate |
| SKU and variant mapping drift | Someone creates a product in one system without the other, and the mapping silently degrades | A scheduled reconciliation job that reports unmatched records rather than failing quietly |
| Tax and pricing mismatch | The storefront calculates one total and the ERP recalculates another, so finance reconciles by hand | Decide which system is authoritative for totals, then pass the number rather than recomputing it |
| Silent failure | The sync stops and nobody finds out until a customer complains | Alerting on absence of expected volume, not only on errors. The single highest-value hour of work in the project |
| Backfill assumptions | Historical orders arrive with today’s date, or duplicate records already in the ERP | Treat the initial load as a separate migration with its own testing, not as the first run of the live sync |
Three of these six we have hit and fixed on named builds, which is the reason they are on the list rather than a plausible-sounding set.
The oversell row is Surplus Furniture before the integration existed: zero-stock clearance items visible and purchasable because nothing reconciled ERP stock against the frontend.
The backfill row is the Rocketline staged ERP data migration. Moving them off a decades-old ERP meant treating the initial load as its own migration – data audit, cleansing, ETL, staged replication into a controlled environment, repeated test runs before cutover. Customer roles, product hierarchies and tiered pricing attributes all had to survive intact. Running that through the live sync path instead would have meant reconciling duplicated records for months.
The silent failure row comes from monitoring a complex B2B ERP integration for Generation Pet, and it is the clearest case we have. Their BigCommerce Enterprise B2B platform depends on a custom third-party server for checkout logic and ERP integration. The original problem was not that anything was broken – it was that nobody could see server health, memory consumption or sync status until an issue surfaced customer-side. Adding real-time monitoring, automated alerts and scheduled audits took uptime to 99.9% and cut potential disruptions by 85%.
That is the argument for treating monitoring as part of the build rather than an afterthought, and for keeping eCommerce managed services on it once the project team leaves.
What ERP integration costs and how long it takes
Anyone quoting a figure before asking about your ERP version is guessing. What we can give honestly is the list of things that move the number.
- How many of the four sync directions are in scope. Each is a separate build, not a percentage uplift
- Whether your SKU and variant models already match across systems
- Your ERP version and API surface – the single largest swing factor
- Real-time versus scheduled, which decides whether you need queueing and retry infrastructure
- Edge cases in your order flow: bundles, kits, backorders, partial shipments, dropship, pre-orders, offline and phone orders
- Historical data backfill volume and quality
- Whether a non-production ERP instance exists, or has to be created
- Whether EDI trading partners are in scope, which is a parallel workstream
On sequencing, our consistent recommendation is one direction at a time, in production, with monitoring, before starting the next. Orders down first in most cases, inventory up second. Slower to plan and considerably faster to finish, because each flow surfaces edge cases that would otherwise be discovered in one large release.
For a sense of the payoff when it lands: Rocketline’s manual order processing time dropped 40% through ERP automation, with online sales up 35% and repeat B2B purchases up 60%. Surplus Furniture saw conversion rise 7.82% in the first month and order volume 18.21% in the first quarter. Both are whole-platform outcomes rather than the sync alone, but in both cases the sync is what made the rest possible.
If you are moving off a legacy ERP or storefront at the same time, treat that as eCommerce migration services work running alongside the integration rather than a step inside it.
Frequently Asked Questions
ERP integration is the automated exchange of data between an enterprise resource planning system and another business system – in eCommerce, your storefront. It replaces manual exports and re-keying with scheduled or event-driven syncs covering orders, inventory, customer and pricing records, and fulfillment data, so both systems hold the same truth without a person in between.
The measurable reasons are eliminating manual order entry, reducing oversell caused by stale inventory, and closing the books faster because order and payment data arrives continuously. The unmeasured reason is error rate. Every manual re-keying step introduces mistakes that surface later as wrong shipments, wrong invoices, or wrong stock counts.
When manual reconciliation costs more than the integration would, or when errors start reaching customers. Concrete signals: someone’s role includes moving data between systems, you have oversold stock more than once, or finance close is delayed by batch data. Wait if you are replatforming within six months – you would pay twice.
Yes. Shopify supports ERP integration through custom apps on the Admin GraphQL API, webhooks for order events, and bulk operations for large catalog or inventory pushes. Established connectors exist for common pairings such as NetSuite. The main design constraint is mapping your ERP warehouse model onto Shopify locations before anything else.
The most common in mid-market eCommerce are NetSuite, Microsoft Dynamics 365 Business Central, SAP Business One, Sage, Acumatica and Epicor. We have integrated NetSuite with BigCommerce and Dynamics NAV with Magento 2. Which system you run matters less than which version: a current cloud release integrates reasonably, an older on-premise install can double the timeline.
For SAP Business One, through the Service Layer OData interface on current versions, or the older DI API on legacy installs. The Service Layer is substantially faster to build against. Confirm your exact version and whether you are cloud or on-premise before scoping, because that single detail changes both the approach and the estimate.
Compare three routes on three-year total cost: a native connector, an iPaaS subscription, or a custom build. Score each against your non-standard requirements – contract pricing, multi-warehouse allocation, bundles, offline orders. If a connector covers your flows, take it. Custom only wins where the logic genuinely falls outside what configuration can reach.
Removing manual data entry, accurate inventory across channels, faster financial close, fewer fulfillment errors, and one reliable view of customers and orders. For B2B specifically it also makes contract pricing and account-level terms available on the storefront, which is often the whole business case rather than a side benefit.
Connecting Adobe Commerce, formerly Magento, to an ERP through REST, GraphQL, or a custom module. It offers the most control of the major platforms and the heaviest build. High-volume syncs should run asynchronously through message queues. We run a Magento 2 estate of 49 retail locations integrated bi-directionally with Microsoft Dynamics NAV.
Only when order logic outgrows what the storefront and ERP handle between them – multi-channel selling, allocation across several warehouses, split fulfillment, or heavy returns. The test is simple: if you are writing complex routing logic into the integration itself, you are building an order management system badly. Buy one instead.
It depends on which of three routes fits. Native connectors from your ERP or platform vendor suit standard single-pairing flows. iPaaS platforms suit several systems with mostly standard logic and an internal team to own it. Custom builds suit non-standard logic. Evaluate on three-year total cost, not licence price.
ERP vendors, systems integrators, iPaaS providers and eCommerce development agencies all offer it, and each has a structural bias. Vendors recommend their connector, iPaaS providers recommend a subscription. Ask any prospective partner when they would tell you not to build – an answer to that question tells you more than a capability deck.
Final Thoughts
eCommerce ERP integration is not one project. It is four data flows, a set of decisions about who owns which record, and a maintenance commitment that starts the day you go live.
The merchants who get this right do three things. They fix SKU and catalog discipline before writing any integration code. They price the native connector honestly before commissioning a build. And they ship one flow at a time with alerting on it.
The ones who struggle usually skipped the second step.
If you are weighing a custom build against a connector, our eCommerce development team runs that comparison as a scoping exercise, starting with your ERP version and data readiness. For B2B operations specifically – contract pricing, account hierarchies, bulk ordering – that conversation usually starts with our B2B eCommerce development team instead.
Related Posts
