Event-Driven ERP: Real-Time Integration

In many businesses the ERP sits at the centre of a web of point-to-point connections: the web shop polls it for stock, the CRM pulls orders every hour, the warehouse system receives nightly files and finance exports spreadsheets. Each connection works until volumes grow, timing matters or one system goes down, and then delays and inconsistencies spread. An event-driven ERP approach changes the pattern: when something meaningful happens, such as an order confirmed, stock adjusted or invoice posted, the ERP publishes an event, and every interested system reacts to it. This guide explains what event-driven ERP integration is, when it is worth adopting, how to design events and publish them reliably, and how to introduce it gradually, with a worked example.

Polling versus events

AspectPolling and batch filesEvent-drivenTimelinessAs fresh as the last runNear real timeLoad on the ERPRepeated queries, even when nothing changedWork only when something happensCouplingEach consumer knows the ERP's tables or API in detailConsumers depend on agreed event formatsAdding a new consumerNew integration against the ERPSubscribe to existing eventsFailure handlingFailed runs often need manual rerunsEvents queue until consumers recover

Polling is not wrong. For data that changes rarely or reports that run nightly, it remains simple and adequate. Events earn their place where timing matters, several systems need the same changes, or polling is straining the ERP.

When an event-driven ERP makes sense

• Several systems need to know about the same business events, such as orders, shipments and stock changes
• Delays cause real problems, such as overselling, late shipping notices or sales working from stale data
• Polling loads the ERP noticeably or hits API limits
• You plan to add more systems over time and want each to plug in without new point-to-point work
• Your ERP is custom or extensible enough to publish events, or exposes change notifications

If the ERP is a packaged product without event support, change data capture from its database or an integration layer that detects changes can produce events on its behalf, with care about supported approaches.

Designing events

Good events describe business facts, named in the past tense: OrderConfirmed, StockAdjusted, InvoicePosted, CustomerCreditHoldChanged. Each event should carry:

• A unique event ID, so consumers can ignore duplicates
• The event type and a schema version
• The time it occurred
• The identifiers of the records involved
• Enough data for most consumers to act without calling back to the ERP, but not the whole database record

Avoid events that simply mirror database writes, such as "row updated in table X"; they tie consumers to the ERP's internal structure and break whenever it changes. Agree event definitions with the teams that consume them, document them in one place and version them. Changing an event's meaning without notice breaks every subscriber at once.

Publishing events reliably

The classic failure is an ERP that saves a change to its database and then fails to publish the event, or publishes an event for a change that was rolled back. A widely used remedy is the transactional outbox: the ERP writes the event into an outbox table in the same database transaction as the business change, and a separate publisher reads the outbox and sends events to the message broker, marking each as sent. If publishing fails, the event stays in the outbox and is retried. A simplified, untested illustration of the publisher:

import json, time

def publish_outbox(db, broker, batch_size=100):
    while True:
        rows = db.fetch_all(
            "SELECT id, event_type, payload FROM outbox "
            "WHERE sent_at IS NULL ORDER BY id LIMIT %s FOR UPDATE SKIP LOCKED",
            (batch_size,),
        )
        for row in rows:
            broker.publish(topic=row["event_type"], key=str(row["id"]),
                           body=json.dumps(row["payload"]))
            db.execute("UPDATE outbox SET sent_at = now() WHERE id = %s", (row["id"],))
        db.commit()
        if not rows:
            time.sleep(1)

Because a crash can occur after publishing but before marking an event as sent, the same event may be published twice. That is acceptable as long as consumers are idempotent, which they should be anyway. Message brokers offer acknowledgements and persistence to avoid losing messages in transit; RabbitMQ's reliability guide describes these features.

Consuming events

Each consuming system subscribes to the events it needs, processes them idempotently using the event ID, handles ordering where it matters by comparing timestamps or versions, and sends repeatedly failing events to a dead letter queue for investigation. Our guide to the webhook queue covers the same consumer disciplines for events arriving from SaaS applications.

Worked example: events for a wholesale business

Suppose a wholesaler runs a custom ERP connected to a web shop, a CRM, a warehouse management system and a marketplace. Nightly files and hourly polling cause overselling and late order updates. The team defines these events:

EventPublished whenConsumersOrderConfirmedOrder passes credit and stock checksWarehouse system, CRMStockAdjustedAvailable quantity changes for a product and warehouseWeb shop, marketplace connectorShipmentDispatchedWarehouse confirms dispatchCRM, customer notification serviceInvoicePostedInvoice created in finance moduleCRMCustomerCreditHoldChangedCredit hold set or releasedCRM, web shop

The ERP writes each event to an outbox in the same transaction as the change, and a publisher sends them to a message broker. The aim is for the web shop and marketplace to reflect stock changes within seconds rather than once an hour, and the team measures the delay from ERP change to channel update to confirm it. Nightly reconciliation compares stock levels between the ERP and each channel, catching anything missed. The team introduces StockAdjusted first, because overselling is the most costly problem, and adds the others over three months. The details are this wholesaler's choices, shown to illustrate the approach.

Introducing events gradually

Introducing an event-driven ERP does not require a big-bang rebuild. Start with the one business event that causes the most pain, publish it reliably, move one or two consumers onto it and keep the old integration running in parallel until the new path is proven. Then add events one at a time, retiring each old polling job or file transfer once its replacement has run cleanly for a few weeks. Keep periodic reconciliation even after events are in place; it is the safety net that catches anything events miss.

Common mistakes

• Publishing events outside the database transaction, so events and data disagree
• Events that expose internal table structures rather than business facts
• Changing event formats without versioning
• Consumers that are not idempotent
• Dropping reconciliation once events are live
• Trying to convert every integration at once

For planning the wider ERP project, see our guide to custom ERP implementation.

Frequently Asked Questions

What is an event-driven ERP?

An ERP that publishes business events, such as orders confirmed or stock adjusted, so connected systems react to changes as they happen instead of polling for them.

What is the transactional outbox pattern?

Writing an event into an outbox table in the same database transaction as the business change, then publishing it separately, so events are never lost or sent for rolled-back changes.

Does an event-driven ERP replace batch integrations entirely?

Not necessarily. Batch and polling remain fine for slow-changing data and reports. Events suit time-sensitive changes needed by several systems.

How do consumers handle duplicate ERP events?

By processing idempotently, using each event's unique ID to ignore events already handled.

Connect your ERP in real time

We design event-driven integrations for custom ERPs, with reliable publishing, idempotent consumers and reconciliation. See our custom app development services, or talk to us about your ERP.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.