Connecting IoT Data to Your ERP: Integration Patterns That Work

A few months after an IoT platform goes live, the complaint is almost always identical: "the data is good, but we still retype it into the production system." An operator reads the IoT dashboard on one screen, then enters the same numbers into the ERP on another. Two sources of truth, two chances to mistype, and monthly reports that never quite reconcile.

Integration removes that work. But integration designed carelessly becomes a maintenance burden that never ends. The difference comes down to a handful of decisions made early.

Decide the direction of travel first

Before any technical discussion, answer one question: who tells whom? Three entirely different directions:

• IoT → ERP. The most common. Energy consumption, machine running hours, and output flow into costing or maintenance modules.
• ERP → IoT. Production schedules, batch numbers, and shift targets flow into the platform so sensor data has context. Without it, a chart only shows "consumption is up" and cannot explain that a different product was running.
• Bidirectional. The most useful, and the one demanding the most care — particularly about which system wins when the two disagree.

Most integration messes begin by skipping that last question.

Do not send raw data into the ERP

The first temptation is to stream every sensor reading into the ERP. This is wrong for two reasons. ERPs are not built for second-resolution time series, and no business process needs that resolution anyway.

What an ERP needs is numbers that already mean something: total kWh per work order, machine hours per shift, units completed, or average temperature across a batch. Aggregation happens in the IoT platform, and only the result crosses over. Data volume drops sharply, and the numbers arriving are immediately usable.

Two delivery patterns

Scheduled pull over OpenAPI. The ERP or an integration layer calls the platform API on a schedule — say at the end of each shift — asking for a summary of that period. This is the simplest pattern and the easiest to diagnose: if something goes wrong, repeat the call. It suits nearly every reporting need.

Event-driven push over MQTT. The platform emits a message the moment something happens — a batch completes, an alarm fires, a threshold is crossed. Latency is low and there is no wasted polling. The consequence is that the receiving system must tolerate the same message twice; a network that drops and reconnects will resend.

The rule of thumb: scheduled pull for summaries and reporting, event-driven push for anything demanding a fast reaction.

Four things that decide whether an integration survives

• Consistent identity. The same machine must carry the same identifier in both systems. If the ERP calls it "MC-014" and the platform calls it "Injection Machine 3", build the mapping table at the start — not three months in.
• Explicit time zones. Store in UTC, display in local time. A seven-hour offset discovered in month-end reporting is an expensive thing to trace.
• Tolerance for repeats. Every message needs a unique identifier so the receiver can discard duplicates. This is what separates an integration you can leave running from one that needs watching.
• Defined failure behaviour. If the ERP is down for two hours, what happens to the data that should have been sent? The right answer is queue and resend, not silently lost.

Securing the integration path

Every integration is a new door into core company systems, and that door is often built once and then forgotten. Four things to settle at the start:

• Separate credentials per integration. Do not reuse the administrator account humans log in with. If one key leaks, the blast radius must be containable without disrupting everything else.
• Least privilege. A reporting integration only needs read access. Granting write "in case we need it later" is unnecessary risk.
• Rotatable keys. Ensure credentials can be rotated without taking the integration down. A system that requires reinstallation to change a key will, in practice, never have its key changed.
• Call logging. Who called what, and when. Without this, tracing the source of a wrong number in the ERP can take days.

Start with one number, not the whole system

Integrations that begin by mapping every module almost always slip by months. The approach that works is to pick one number with obvious value — kWh per work order, for instance — and carry it through until it is genuinely used in a decision. Once that single path has been stable for a month, the next one moves far faster because the pattern, authentication, and error handling already exist.

How INCLUDE handles it

IncludeApps exposes an HTTP OpenAPI and MQTT for data in both directions, so other systems can pull summaries or receive events without direct database access. Raw data stays in the platform; only aggregated numbers cross into the ERP.

If your ERP is a legacy system without a usable API — a very common situation — that bridging layer has to be built. The Software Development and System Integrator practices within INCLUDE services cover this work, including asset identity mapping and error handling that rarely make it into the original project scope. For where the application layer sits in the wider architecture, see our guide to IoT & AIoT platforms in Indonesia.