ERP Integration: The Approach That Actually Works

I spent July watching a client struggle with their ERP integration strategy. They had Shopify feeding orders to their ERP. They had their ERP pushing inventory back to Shopify. They had payment processors, accounting software, logistics platforms, all plugged in via webhooks and polling scripts scattered across different servers.

It worked. Mostly. Until something didn't—a payment integration failed silently, inventory got out of sync, and nobody knew which system of truth was authoritative. Then it took a week to untangle.

I've seen this pattern dozens of times. Business leaders see ERP as the hub—everything flows through it. But the integration architecture is usually point-to-point spaghetti. It works until it doesn't, and when it fails, the blast radius is unpredictable.

There's a better way.

The Hub and Spoke Problem

The classic ERP integration mistake: every external system tries to talk to the ERP directly. Shopify sends orders. Accounting software pulls general ledger. Logistics platforms grab shipment data. Payment processors verify transactions.

On paper, that sounds reasonable. Everything goes through the hub.

In practice, you're creating a spaghetti diagram where the ERP becomes a bottleneck and every integration failure cascades unpredictably. If your payment processor goes down, does the order get stuck? Does it retry? Does it create duplicate accounting entries?

More importantly, you've tightly coupled your ERP to every external system. Swap out your payment processor? You need to update ERP integration code. Change logistics providers? Same thing. The ERP becomes a ball of mud.

What I've learned is that the hub-and-spoke approach works only if you have a really sophisticated integration layer. Most teams don't.

Event-Driven Architecture as Insurance

The approach that actually works: think of the ERP as a system that emits events, not a system that coordinates everything.

When an order is placed in the ERP, it emits an "order created" event. That event goes into a queue. Systems that care about that event subscribe to it. Inventory management listens. Shipping systems listen. Accounting systems listen. Each system processes the event independently.

The benefit is decoupling. If your shipping integration is down, the order still gets created. The event sits in the queue. When the shipping system comes back up, it processes the backlog.

This also gives you an audit trail. You have a log of every event that happened and when. You can trace why something went wrong—not by interrogating three systems, but by reading the event log.

We've started building ERP systems with this architecture from the start. Instead of integration being an afterthought, it's foundational. The ERP is an event emitter. Third-party systems are event consumers.

Synchronization Without Consistency Problems

One of the scariest moments in ERP integration is when two systems have different views of the truth. The ERP says inventory is 100. Shopify says inventory is 95. Which one is right?

With an event-driven approach, you fix this by being explicit about data ownership. The ERP owns the inventory database. Shopify reads from it. When inventory changes in the ERP, it emits an event. Shopify listens and updates its cache.

This creates a clear hierarchy without losing decoupling. You know what the authoritative data source is for each piece of information. You know how systems should be updated. You can reason about consistency.

The risk comes when systems try to own the same data. When Shopify owns order fulfillment status and the ERP owns it and your logistics platform owns it, you have a problem. Three systems, three truths, no way to reconcile.

Event-driven thinking prevents that. You choose one system as authoritative for each piece of data. Everything else is downstream.

Handling Integration Failures Gracefully

July is a good month to think about this because it's mid-year, and usually by mid-year you've had at least one integration failure that caused real damage.

With point-to-point integrations, a failure in one integration can poison the entire system. A payment processor returns an error. Your retry logic is buggy. Now the order is stuck in limbo. The customer was charged but the ERP thinks they weren't.

With event-driven architecture, you have a fallback: the event log. If the payment system is temporarily down, the event sits in the queue. Your payment integration keeps retrying. Once it comes back, it catches up. There's a clear recovery path.

This requires thinking carefully about idempotency—making sure the same operation can be replayed safely. But that's a worthwhile engineering constraint because it makes failures recoverable instead of catastrophic.

What We're Building Now

For new ERP systems, we're treating integration as a first-class concern, not an afterthought. This means:

Event emission is built in. Every significant state change in the ERP produces an event. Order created. Inventory adjusted. Payment received.

We have a message queue (we use RabbitMQ or Kafka depending on scale). External systems can't pull directly from the ERP. They subscribe to events.

We have integration adapters for common systems—Shopify, Stripe, logistics providers. Each adapter has its own retry logic, its own error handling, its own state. If an adapter fails, it doesn't take down the ERP.

We have monitoring and alerting. If events are piling up in a queue because a consumer is down, we know immediately.

We have an audit trail. We can see every event that happened and why.

This architecture is more complex than point-to-point integration. But it's more reliable, more maintainable, and more resilient to failures.

The July Realization

A lot of teams go into Q3 realizing they need to add integrations their ERP wasn't designed for. The existing system is coupled. Adding another system means another point-to-point integration. The spaghetti grows.

If you're planning an ERP implementation, start with the integration architecture. Don't treat it as something you'll figure out later. By the time you need it, you'll either have built it right from the start, or you'll be rebuilding it under time pressure.

That's the difference between integrations that work and integrations that just barely hold together.