ERP Interface Monitoring: Catch Failed Flows Before Your Users Do

Go-live is behind you, training is done, and the steering committee has congratulated the project team. Three weeks later, on a Monday morning, the logistics manager discovers that the web-shop orders placed over the weekend never reached the ERP. No alert, no error message, no ticket. The interface was “green” in the integration tool: the scheduled job ran as planned, just against an empty file, because a certificate had expired upstream.

The scenario is generic, but it is one of the most common after a production release. ERP screens are tested and users are trained, while the interfaces live in a blind spot: nobody watches them until a user complains. This article lays out a minimal, practical monitoring setup that you can put in place in thirty days without buying yet another observability platform.

It builds on our guides to choosing an integration architecture and to the EDI versus REST API decision. Here we assume the flows already exist and the job is to keep them alive.

Why Interfaces Fail Silently

An ERP interface is not a single program, it is a chain: a source system, a transport (file, API, message bus, EDI), a transformation, a target system, and often an acknowledgement. Every link can fail, and most failures do not produce a visible error.

The usual causes of silence are always the same:

• Zero is not an error. A flow that processes 0 messages has not technically failed. Without an expected-volume threshold, an empty flow looks like a quiet one.
• Secrets expire. Certificates, API tokens and service-account passwords have predictable expiry dates, yet they are rarely in a shared calendar.
• Errors get swallowed. A connector that logs the error to a file nobody reads, or downgrades it to a warning, has done its technical job and missed its business one.
• Upstream changes arrive unannounced. A renamed field in the source SaaS, a new API version, a modified file format: the flow keeps running and rejects everything.
• Business rejections are mistaken for noise. An invoice refused by the e-invoicing platform or by the bank is valid data that was not accepted. If nobody receives that rejection, the invoice vanishes.
• Nights and weekends have no owner. Overnight batches and e-commerce flows run when the team is away.

The cost of an unmonitored flow rarely shows up on a budget line. It is diluted into manual re-keying, month-end reconciliations, avoidable customer chasers, late shipments and support hours spent reconstructing what happened. We do not put a number on it here for lack of a robust source, but your own post-go-live ticket history will give a credible order of magnitude.

Flow Inventory and Criticality: The Starting Matrix

You cannot monitor what you have not listed. Before choosing any tool, build a flow inventory with four mandatory attributes: criticality, expected service level, business owner and technical owner.

Flow	Direction	Criticality	Delay tolerance	Business owner	Technical owner
E-commerce orders to ERP	Inbound	Critical	A few minutes	E-commerce manager	Integration team
Customer invoices to e-invoicing platform (Peppol access point, French PA/PDP, other national network)	Outbound	Critical (legal obligation)	A few hours	Accounts receivable manager	Integration team / vendor
Invoice status updates from the platform	Inbound	Critical	A few hours	Accounts receivable manager	Integration team
Payment files to bank	Outbound	Critical	Before the daily bank cut-off	Treasurer	Integration team
Bank statements to ERP	Inbound	High	Within the day	Treasurer	Integration team
Pick orders to WMS	Outbound	Critical	Minutes	Logistics manager	Integration team
Shipment confirmations from WMS to ERP	Inbound	High	One hour	Logistics manager	Integration team
Payroll journals to general ledger	Outbound	Medium	Monthly	HR / CFO	Payroll team
Data warehouse loads	Outbound	Low to medium	Within the day	Management accounting	BI team

This matrix is a template: replace the rows with your own flows. Three rules make it useful.

1. One criticality level per flow, decided by the business, not by IT. “Critical” means: if the flow is down, an activity stops or a legal obligation is no longer met.
2. A tolerance expressed in time, not in percentages. “Orders must reach the ERP in under 15 minutes” can be monitored; “orders must arrive” cannot.
3. A name, not a team. A named owner, with a deputy.

E-invoicing flows deserve a special mention. Rejections by an e-invoicing platform or by the Peppol network are events to be treated as critical flows in their own right: a rejected invoice is not a sent invoice. Our write-up of the French e-invoicing platform outages in September 2026 shows why you must monitor what happens downstream of your ERP, not just the moment the file leaves it. For choosing the platform itself, see the e-invoicing platform selection guide.

The 7 Metrics to Monitor

A useful dashboard fits in seven metrics, applicable to almost every flow.

1. Volume. Number of messages or lines processed over a window, compared with an expected value (same weekday, same hour). Zero or abnormally low volume is the first detector of a silent failure.
2. Latency. Delay between emission at the source and acceptance at the target. Drifting latency often signals saturation before the outage.
3. Error rate. Share of failed messages over the window. Track the trend rather than the absolute value.
4. Queue depth. Depth of the queue and age of the oldest waiting message. A queue that never empties is a blocked flow, even with no errors.
5. Business rejections and technical rejections, kept apart. A technical rejection (timeout, authentication, format) belongs to the integration team. A business rejection (unknown customer, blocked item, inconsistent VAT, invoice refused by the platform) belongs to the flow owner. Mixing them in one counter guarantees nobody handles either.
6. Freshness. Age of the last successfully received data. For a flow that should run hourly, “last success 5 hours ago” is an alert, even if no run has failed.
7. End-to-end reconciliation. Comparison of totals between source and target: number of orders, sum of amounts, number of invoices. It is the only metric that detects partial losses.

Technical Monitoring vs. Business Monitoring

Metrics 1 to 4 and 6 are technical monitoring: the integration tool can produce them on its own. Metrics 5 and 7 are business monitoring: they require comparing data across systems.

This is where the difference between a green flow and correct data plays out. A flow is green when every run completes without error. Data is correct when what landed in the ERP matches what left the source. The two diverge more often than you would expect: a misconfigured filter, duplicates wrongly discarded, truncated lines, a badly converted currency.

The remedy is daily reconciliation. A scheduled query compares, for the previous day, the number and total amount of orders in the source system and in the ERP, and publishes the gap. A zero gap is normal; any gap opens a ticket assigned to the flow owner. The check is cheap, independent of the integration tool, and catches the failures technical monitoring cannot see. It follows the same logic as automated data quality controls (French): same principles, applied to flows rather than master data.

Useful Alerts: Thresholds, Noise Reduction, Escalation, On-Call

A monitoring setup that alerts too much is as useless as a silent one: after two weeks, everyone ignores the messages. Four principles prevent that drift.

Alert on business symptoms, not on isolated technical events. “No order received for 45 minutes during business hours” is an alert. “One API call failed once” is not, especially if the retry succeeded.

Define thresholds per flow and per time band. The volume expected on a Tuesday at 10 a.m. is not the volume of a Sunday at 3 a.m. Start simple: one freshness threshold per flow (“no success for X”) already covers most silent failures.

Cut noise at the source. Group repetitive alerts into one message, apply a grace period before alerting (so automatic retries can succeed), and delete any alert nobody has acted on within the month. An alert with no associated action should go.

Plan the escalation. Each criticality level has its own path:

Criticality	Channel	Response time	Escalation
Critical	On-call notification	Immediate, 24/7 for flows that justify it	Integration lead, then CIO
High	Team chat + ticket	Business hours	Flow owner
Medium / low	Ticket only, daily digest	Next business day	Monthly review

On-call is an organizational and budgetary choice, not a reflex. If a critical flow does not justify on-call cover, document the decision and the accepted risk, for example: “weekend orders will be caught up on Monday morning.” What matters is that the failure is known when it happens, and that the decision not to react is a conscious one.

Handling Errors: Retry, Dead Letter Queue, Replay, Idempotency

Detection is not enough: errors must be recoverable without a heroic intervention by an expert. Four mechanisms form the foundation.

Retry with backoff. Transient failures (network, a brief target outage) fix themselves if the flow retries with an increasing delay. Cap the number of attempts: an infinite retry on an invalid message blocks the queue and manufactures an outage.

Dead letter queue (DLQ). After the maximum number of attempts, the message is neither lost nor blocking: it is moved to a dedicated queue together with its context (timestamp, cause, business identifier). The DLQ is a metric in itself: its depth and the age of its oldest message belong on the dashboard, with an owner responsible for emptying it. A DLQ that keeps growing while nobody reads it is a graveyard, not a safety net.

Replay. Once the cause is fixed, you must be able to replay messages from the DLQ, one by one or in batches, without re-keying data. Build this mechanism before you need it, and test it: a replay that has never been exercised fails on the day it is needed.

Idempotency. Replaying must not duplicate. Each message carries a unique business identifier (order number, invoice number) and the target ignores or updates what it already has instead of recreating it. Without idempotency, a replay turns an outage into duplicate orders or payments, often costlier to clean up than the original failure.

These principles hold whatever the transport. For EDI and API exchanges, the design trade-offs are covered in our EDI vs. REST API guide.

Tools: Native and Third-Party

Before buying, look at what your ecosystem already provides. The table below lists tool families and their typical uses, unranked: the right choice depends on your ERP, your integration platform and the skills you have. Always check exact capabilities in the documentation of the version you run.

Context	Native tools to examine	What for	Limits to check
SAP	SAP Cloud ALM (integration and exception monitoring), SAP Integration Suite monitoring	Track messages, errors and replays for SAP interfaces and integration scenarios	Coverage of non-SAP systems, alerting into your on-call channels
Microsoft Dynamics 365	Azure Monitor, Application Insights, Power Platform and Azure integration logs	Alerts on metrics and log queries, dashboards	Correlation across services, log retention costs
Odoo	Server logs, scheduled actions, community job-queue modules	Detect failed jobs and replay them	Little out-of-the-box alerting, to be complemented by an external tool
iPaaS (MuleSoft, Boomi, Workato, Make, etc.)	The platform’s monitoring and alerting consoles	Track runs, errors, replay	Visibility limited to what the platform processes
Third-party observability tools	Generic log, metric and alerting platforms	Single multi-system view, correlation, shared dashboards	Integration effort, licensing, operating skills

A more important selection criterion than the brand: the tool must be able to alert on the absence of an event (freshness, zero volume), not only on the presence of an error. Many default configurations cover only the latter, which is exactly the case that is not the problem.

For an SMB, a sensible combination is often: the integration tool’s native console for execution, a scheduled reconciliation query for correct data, and a single alert channel (team chat plus ticket) to aggregate everything. For a multi-ERP group, the single view of a third-party tool soon pays for itself. The overall cost of integration is covered in our analysis of the hidden costs of SaaS and iPaaS integration.

A Template Incident Runbook for Interfaces

A runbook is a page, not a binder. It must let an on-call person who did not design the flow act within the first twenty minutes. Template to adapt:

1. Identification

• Affected flow, business owner, technical owner.
• Detected symptom (freshness alert, blocked queue, reconciliation gap).
• Estimated start time.

2. Qualification

• Technical failure or business rejection? (Check the error in the console and the DLQ.)
• Scope: all messages or a subset?
• Business impact: which activity has stopped, which legal obligation is at risk?

3. Workaround

• Documented degraded mode (manual entry, file export/import, holding messages at the source).
• Who informs users and customers, with what standard message.

4. Fix

• Common causes to check first: expired certificate or token, locked service account, upstream format change, target unavailable, quota reached.
• Fix, then test on a single message before relaunching at volume.

5. Recovery

• Replay the DLQ messages, checking idempotency.
• Run the reconciliation for the affected period and confirm a zero gap.

6. Closure and lessons learned

• Total duration, messages affected, root cause.
• Preventive action: new alert, expiry calendar, regression test.
• Update the runbook.

5 Classic Interface Monitoring Mistakes

1. Trusting the “green flow”. Trap: assuming an error-free run proves the data arrived. Consequence: partial losses discovered at month-end close. Countermeasure: daily reconciliation of counts and amounts between source and target.
2. Not alerting on missing volume. Trap: raising an alert only on an error. Consequence: an empty or frozen flow stays invisible all weekend. Countermeasure: freshness and expected-volume alerts on every critical flow.
3. Mixing business and technical rejections. Trap: a single error counter. Consequence: the integration team ignores e-invoicing platform or bank rejections, while the business ignores outages. Countermeasure: two counters, two named recipients.
4. Leaving a DLQ without an owner or a tested replay. Trap: just setting messages aside. Consequence: a queue growing silently, and a replay that fails or creates duplicates on the day it matters. Countermeasure: a named owner, a maximum tolerated age, a dry-run replay, idempotent targets.
5. Forgetting expiring secrets. Trap: certificates, tokens and service accounts missing from every calendar. Consequence: a total outage that was entirely predictable and yet still came as a surprise. Countermeasure: an inventory of expiry dates, alerts several weeks ahead, renewal built into the monthly review.

Governance: Owners, Monthly Review and the Link to AMS

Monitoring is not a project, it is a process. Three rituals keep it in shape.

One owner per flow, recorded in the inventory. The business owner decides criticality, handles business rejections and validates reconciliation gaps. The technical owner fixes outages and maintains the alerts. When someone leaves the company, the inventory is updated within the week.

A thirty-minute monthly review. Fixed agenda: incidents of the month and root causes, alerts never acted on (to be deleted), overdue DLQ items, recurring reconciliation gaps, new flows to register, certificates and tokens nearing expiry.

A contractual link to application management services (AMS). If ERP operations are outsourced, the contract must explicitly mention interface monitoring: the flow scope, response times by criticality level, access to the dashboards, and an obligation to provide a monthly review report. Without it, the AMS provider often covers only the anomalies reported by users, which is precisely what monitoring is meant to avoid. Our guide to the post-go-live ERP maintenance contract details the clauses to negotiate.

Finally, build monitoring into the change cycle: every new interface and every major change to the ERP or a connected system (vendor updates included) triggers an update of the inventory, the alerts and the runbook. The load and threshold tests run before production, described in our go-live performance testing methodology, also provide good starting values for latency thresholds.

30-Day Rollout Checklist

Week 1: see

• Build the flow inventory (source, target, transport, frequency).
• Assign criticality, tolerance and owners, with business sign-off.
• List certificates, tokens and service accounts with their expiry dates.

Week 2: detect

• Set up the freshness alert on every critical flow.
• Add the zero or abnormal volume alert on daily inbound flows.
• Separate technical and business rejection counters; treat e-invoicing platform and Peppol rejections as critical flows.

Week 3: react

• Configure capped retry, DLQ and a replay procedure on critical flows; test a real replay.
• Verify idempotency on the targets.
• Define channels, escalation and a documented on-call decision.

Week 4: harden

• Schedule daily reconciliation on the three most sensitive flows.
• Write one runbook per critical flow from the template above.
• Hold the first monthly review, delete alerts with no action, update the AMS contract if needed.

After thirty days you will not have a complete observability platform, but you will already have eliminated the costliest scenario: the one where the user discovers the failure before you do.

Going Further

Want to know the real state of your interfaces? We offer an integration audit: flow inventory, criticality assessment, review of alerting and recovery mechanisms, and a prioritized action plan. Contact us to discuss it, or subscribe to the newsletter to receive our next ERP operations guides.