Four Ways to Connect Your ERP (and When Each Is Right)

Vendor material presents a dozen integration options. Architecturally there are four, and the useful skill is choosing between them per data flow rather than picking one for the whole programme.

1. Point-to-Point

Direct connections between system pairs. Two systems, one connection, a week of work, a clear owner.

Good for: a genuinely small, stable estate that will not grow.

The trap: the arithmetic. Three systems need three connections, six need fifteen, ten need forty-five. Each carries its own authentication, error handling, retry logic, mapping and monitoring, maintained by whoever built it.

The warning sign is not the count but the question. When someone asks "if we change the customer ID format, what breaks?" and answering takes a week of archaeology, you have passed the threshold. Migration is then a prerequisite for changing anything, not an architectural preference.

2. Hub-and-Spoke (Integration Platform)

Every system connects to a central broker that handles routing, transformation and retries.

Good for: most mid-sized estates. This is the sensible default.

What you are buying: connectors, a transformation engine, retry and dead-letter handling, monitoring, and a visual interface that lets non-engineers see what is running. That last item moves routine mapping changes off the engineering backlog, which is worth more than it sounds.

What you are not buying: understanding of your business logic. The connector handles authentication and wire format. It does not know that orders from your German subsidiary need different tax treatment. That logic still has to be written, tested and owned.

Evaluate on three axes: connector depth for your specific systems (a connector covering 60% of an API forces custom work for exactly the endpoint you need), the testing story (integration tests against a sandbox in CI, or manual clicking), and pricing shape — usually per task or message, so model it at three years of projected volume.

3. Event-Driven

Systems publish facts — order.created, invoice.posted — to a durable log; anything interested subscribes.

Good for: estates that need replay, an audit trail, or genuine independence between producers and consumers.

The underrated benefit is replay. When a downstream system has been writing bad records for a week, you fix the consumer and replay the window rather than reconstructing state by hand. Without an event log, that is a reconciliation project.

The cost is discipline. Events are a public contract and must be versioned like an external API. Consumers must be idempotent, because at-least-once delivery makes duplicates guaranteed rather than hypothetical. And you now operate a distributed system, which means a single business process spans several services and correlating it needs tracing you build deliberately.

Many older ERPs emit no events, so you need change-data-capture on the database or polling at the edge. Both work; both add a component that needs an owner, and CDC couples you to an internal schema the vendor may change without notice.

4. Batch File Exchange

Scheduled extracts, transfers and loads.

Good for: high-volume periodic movements where real-time adds cost and no value. Nightly general-ledger postings. Payroll. Most analytical extracts.

Dated, and still correct more often than people admit. Nobody makes a decision on a partial day's ledger, month-end close works on complete periods, and batch gives you a natural reconciliation boundary.

Choosing Per Flow

The common mistake is treating these as a maturity ladder with event-driven at the top. They are not ranked.

A useful test: ask what action a human takes when the number changes, and how quickly.

• Inventory availability shown at checkout — real-time. A stale number costs an oversell and a refund.
• Order status a customer can see — real-time or close, because the alternative is a support call.
• General-ledger postings — batch. Nobody acts on a partial day.
• Analytical extracts — batch.

If the honest answer is "they look at it next Tuesday," a nightly batch is the correct engineering decision, and defending it saves real money.

The Thing That Matters More Than the Pattern

Whichever you choose, make failure loud.

Integrations do not fail like web applications. When an integration meets data it does not recognise, it applies a default and keeps running — because stopping would halt the business. Nothing errors. Records keep being created. They are just wrong, and the typical discovery timeline is weeks, at month-end close.

Scheduled reconciliation fixes this: compare counts and value totals between systems, plus the distribution of key categorical fields against the trailing average. It produces no demonstrable feature, appears in no demo, and is the first thing cut when a programme runs late. It is also the highest-return item in the entire budget.

Full guide — canonical data models, master data, idempotency and ordering, security and cost: ERP integrations.

Frequently Asked Questions

Is event-driven always better than a hub-and-spoke platform?

No. Event-driven buys decoupling, replay and an audit trail at the cost of operating a distributed system. If you have a small stable estate with no replay or audit requirement, and nobody to own the platform, hub-and-spoke delivers most of the value with far less operational surface.

How do we decide between real-time and batch for a given flow?

Ask what a human does when the value changes and how quickly. If they act within minutes — inventory at checkout, order status — real-time earns its cost. If they look at it next week, a scheduled batch is correct and much cheaper to build and operate.

What should we check before buying an integration platform?

Connector depth for your specific systems, the testing story, and pricing shape. A connector covering most of an API will still force custom work for the endpoint you need. Pricing is usually per message or per task, so model it against three years of projected volume rather than today's.

How do we get events out of an ERP that does not emit them?

An outbox table written in the same transaction as the business change is best if you can modify the application. Otherwise change data capture on the database log works, at the cost of coupling to an internal schema and needing a translation layer to turn row changes into domain events. Polling is a last resort.

What is the single most important thing regardless of pattern?

Scheduled reconciliation between systems, including distribution checks on key categorical fields. Integrations fail silently by design, so without it your detection window is measured in weeks. It is the cheapest control available and the most frequently omitted.