Ecommerce orders into ERP: 4 integration architectures

An ecommerce integration is a small piece of software with an outsized failure radius. When it works, nobody thinks about it. When it fails, a customer has paid for something the warehouse does not know about, finance is holding revenue it cannot recognise, and the number in the storefront and the number in the ERP disagree — which means that for some period, nobody in the company knows what was actually sold.

There are essentially four architectures for getting orders from a storefront into an ERP. All four are in production at real mid-market companies right now. All four are correct choices in some circumstance and disastrous in others, and the failure is almost never the code — it is a mismatch between the architecture chosen and the volume, channel count and error tolerance of the business running it.

This article sets out the four, the point at which each one breaks, and how to tell which one you should be running.

Why this matters

Three forces have made this decision harder for mid-market companies than it was five years ago.

Channel count has grown faster than integration budgets. A company that sold through one storefront now sells through a storefront, two or three marketplaces, possibly a B2B portal, and a social channel. Each has its own order schema, its own settlement model, and its own idea of what a customer is. An architecture that was adequate for one channel is often quietly inadequate for five.

Order volume is spiky, not linear. Mid-market ecommerce is seasonal, promotional and increasingly campaign-driven. A batch integration comfortable at a steady 200 orders a day may not survive 3,000 in an afternoon — and peak trading is precisely when failure is most expensive.

Customer expectations now include the back office. Real-time stock availability, accurate delivery promises and immediate order-status visibility are all functions of how fast and how reliably the ERP and the storefront agree. Integration latency has become a customer-facing attribute.

At a glance: the four architectures

Broadly: option 1 is where most mid-market companies should start, option 3 is where most end up, option 2 is where most get stuck, and option 4 is right less often than its advocates suggest.

The four in detail

1. Native connector.
A pre-built integration, usually maintained by the storefront vendor, the ERP vendor or a third party. Fastest to deploy — weeks rather than months — and cheapest by a wide margin. The trade-off is that you inherit someone else's model of how an order should flow.

It fails in three ways. Your business logic exceeds what the connector exposes: a pricing rule, a tax treatment, a fulfilment split it was not designed for. Channel count grows and you find yourself running three connectors with three different error-handling behaviours and no consolidated view. Or the vendor's roadmap diverges from your needs, and you are waiting on a feature that may never arrive.

2. Point-to-point custom build.
Direct bespoke code between two systems. Total control, exactly the logic you specified. This is the right answer when a single channel is strategically critical and its logic is genuinely unusual — and there is a maintaining engineer.

The failure is arithmetic. Each new system multiplies the connections, and each connection carries its own retry logic, credential handling and error reporting. A price-list change touches every build. Documented understanding lives with whoever wrote it, and mid-market companies rarely retain that person for the life of the integration. This is the architecture we most often find companies trapped in, precisely because it worked so well for the first channel.

3. Integration platform.
A central platform brokers all channels: transformation in one place, consistent error handling, retry logic, monitoring and an audit trail. Adding a fourth channel becomes configuration rather than a project. For a mid-market company running multiple channels with changing requirements, this is usually the correct architecture, and it is where our own client work concentrates — typically on an integration platform Atypical Tech partners with, with AI agents handling exception classification and routing rather than dumping failures into a queue nobody reads.

Its failure mode is organisational. Because flows are easy to create, they proliferate. Within two years an undocumented layer of business logic exists that nobody fully understands, which is the same problem as option 2 wearing better clothes. Platforms need ownership, naming conventions, documentation and periodic review — governance, not technology.

4. Event-driven middleware.
Systems publish events; consumers subscribe independently. Genuinely the right answer at high volume with spiky traffic and multiple consumers of the same order event — a warehouse system, a fraud check, an analytics pipeline, a customer notification service all reacting to one order.

It fails on organisational maturity more than technology. Event-driven architecture demands people comfortable with eventual consistency, idempotency and replay, and mid-market teams often do not have them and cannot hire them. It also fails when the business has not internalised what eventual consistency means: "the order exists but the stock figure has not caught up yet" is a legitimate state in this architecture and an unacceptable one to a finance director who has not been told.

What to be honest about

The architecture is rarely the binding constraint. More integrations fail on data quality and error handling than on architectural choice. If the storefront can create a customer record the ERP will reject, no architecture saves you.

Nobody wants to fund error handling. The happy path is perhaps 60% of the work; the remaining 40% is what happens when payment succeeds and the order fails, when a product does not exist in the ERP, when a marketplace sends a partial refund. Projects that skip this ship on time and consume operations staff indefinitely afterwards.

Migrating architectures is expensive and usually necessary. Moving from point-to-point to a platform means running both in parallel, reconciling, and cutting over during a non-peak period. It is a real project. It is also the correct decision more often than clients want to hear.

Real-time is not always right. Real-time order sync is usually correct. Real-time inventory sync to every channel can generate load and race conditions disproportionate to its value; a short buffer with reservation logic often serves customers better than true real-time.

Agents help with exceptions, not with architecture. An AI agent that classifies failures, resolves mechanical ones and routes the rest with context attached materially reduces the operational cost of any of these four options. It does not make a bad architectural fit good.

Decision framework: choosing your architecture

Run in order. Stop at the first match.

1. Do you have one or two mainstream channels, standard order logic, and no immediate plan to add more?
Use a native connector. Do not build. The engineering you would spend is better spent elsewhere, and you can migrate later if the constraint arrives.

2. Do you have one channel that is strategically critical with genuinely unusual logic, and a maintaining engineer on staff for the foreseeable future?
A point-to-point build is defensible. Document the mapping externally, and set a review trigger: the moment a second channel is planned, revisit.

3. Do you have three or more channels, or requirements that change more than once or twice a year?
Use an integration platform, and assign a named owner before the first flow is built. Most mid-market companies reading this article are in this row.

4. Do you have high spiky volume, multiple independent consumers of order events, and engineers who have run event-driven systems before?
Event-driven middleware is appropriate. If you meet the first two conditions but not the third, use a platform and revisit in a year — do not learn this architecture during peak season.

5. Are you currently on point-to-point with more than two channels?
Your architecture is the problem regardless of anything above. Plan a migration to a platform, sequenced outside peak trading, running in parallel with reconciliation until you are confident.

6. All of the above resolved and orders still failing?
The issue is data quality or error handling, not architecture. Instrument the failures, categorise them for a fortnight, and fix the top three categories — which will usually be master data mismatches rather than integration faults.

Indicative cost and effort

Assumes a single ERP instance and a mid-market transaction profile. Complex tax treatment, multi-entity structures, or marketplace settlement reconciliation extend these. Get a quote for a scoped estimate.

Frequently asked questions

Can we start with a native connector and migrate later?
Yes, and for most companies that is the right sequence. Reduce the migration cost now by documenting your order-flow logic outside the connector's configuration, so that when you migrate you are not reverse-engineering your own business rules.

How do we handle marketplace settlements?
Separately from order integration, and deliberately. Marketplace payouts arrive net of fees, batched across many orders, on the marketplace's schedule — reconciling them to individual orders is a distinct problem requiring its own matching logic. Treating it as part of the order integration is a common and expensive mistake.

Should inventory sync be real-time?
Usually not strictly real-time. A near-real-time update with a reservation buffer serves customers better than true real-time, which is prone to race conditions when two channels sell the last unit within the same second. What matters is that overselling is prevented, and reservation logic does that more reliably than update speed.

What happens to orders that fail integration?
This is the question that separates a working integration from a fragile one. Failed orders must land somewhere visible, with the reason attached, an owner, and a defined resolution path — not in a log file. If your current answer is "someone notices," you have an error-handling gap regardless of architecture.

Do we need a data warehouse as well?
For reporting, eventually, yes — but not as part of this. Order integration is an operational flow; analytics is a separate concern. Combining them tends to produce an integration optimised for reporting that is unreliable operationally.

How quickly can one of these architectures actually be implemented?
Depends which one. A stopgap CSV or manual bridge is days; a proper native connector or middleware integration is typically 6–12 weeks. The real-time sync architecture is often the fastest to stand up technically — a certified partner like Stacksync can have bidirectional order sync running in a matter of weeks — but it still needs the mapping and exception-handling decisions from the sections above settled first, or you have automated the wrong flow quickly instead of the right one slowly.

Closing — Next steps

The four architectures are not a maturity ladder. A single-channel business running a native connector well is in better shape than a five-channel business running four bespoke builds, regardless of which looks more sophisticated. The only question worth asking is whether your architecture matches your channel count, volume profile and error tolerance today, with a plausible path to where you will be in two years.

A practical starting point: count your channels, count your integration connections, and pull a fortnight of failed orders with reasons. Those three numbers will tell you which row of the framework you are in, and whether the real problem is architecture or data.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication.

• Oracle NetSuite, integration and SuiteTalk documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• Gartner, research on integration platforms and iPaaS (largely client-access) — https://www.gartner.com
• European Commission, VAT in the Digital Age (ViDA) — digital reporting and e-invoicing requirements affecting cross-border ecommerce — https://taxation-customs.ec.europa.eu
• Agencia Tributaria (Spain), Suministro Inmediato de Información (SII) — https://sede.agenciatributaria.gob.es
• Atypical Tech engagement experience, mid-market ecommerce and ERP integrations across Iberia
• Stacksync, real-time integration and sync platform blog — https://www.stacksync.com/blog