What is interface monitoring in treasury systems?

Interface monitoring is the discipline of confirming that each interface between systems — ERP to TMS, bank statements in, payments out — actually ran and completed as expected, and alerting an owner when it didn't. It answers 'did the feed run?' Without it, a feed that silently fails to run isn't noticed until a position is wrong or a payment is missed.

What is the difference between interface monitoring and reconciliation?

Monitoring answers 'did the interface run and complete?' Reconciliation answers 'did all the data arrive intact?' A feed can run successfully but transfer only part of the data, or transfer it with errors — monitoring alone wouldn't catch that. Reconciliation uses control totals (record counts and amount sums, sent vs received) to prove completeness and integrity. You need both.

How do you reconcile system interfaces?

Use control totals: compare the number of records and the sum of amounts sent by the source against what the target received and processed, for every interface run. If a source sends 1,000 items totalling a known amount and the target books fewer or a different total, the reconciliation flags a break to be investigated. Build this into the interface rather than doing it manually after the fact.

Interface Monitoring and Reconciliation for Treasury Systems

Interface monitoring proves each interface ran and completed; interface reconciliation proves all the data arrived intact. Treasury interfaces need both, because they fail silently and partially — and a feed that quietly doesn't run, or transfers only part of its data, surfaces as a wrong cash position or a missed payment days later. The interfaces that cause the worst damage aren't the ones that fail loudly; they're the ones that fail quietly. Monitoring and reconciliation are how you make silent failure impossible.

Why interfaces fail silently

A treasury landscape is a web of feeds: the ERP to the TMS, bank statements in, payments out, market data. Each is a point where something can go wrong — a job doesn't run, a file is late or malformed, a downstream system is down, a feed transfers 998 of 1,000 records. None of these announces itself. The system doesn't crash; it just has slightly wrong or missing data. And because a cash position built from a partial statement looks like a cash position, the failure is invisible until someone can't reconcile it or a payment doesn't land.

Monitoring: did it run and complete?

The first question is existence. For every interface, you need to know it ran when it should, and completed successfully — and to be alerted when it didn't. That means:

A schedule or expectation for each feed (this runs at this time / before this event).
Detection of a run that's missing, late, or ended in error.
An alert to a named owner — not a log entry someone might read.

Monitoring catches the "the feed didn't run" and "the feed errored" cases. But a feed can run successfully and still be wrong — which is where reconciliation comes in.

Reconciliation: did the data arrive intact?

The second question is completeness and integrity. The tool is control totals: the source records how many items and what total amount it sent; the target records how many it received and processed; you compare them, every run.

Source sent 1,000 AP items totalling €10,000,000. Target booked 1,000 totalling €10,000,000. ✓ balanced. Target booked 998 totalling €9,900,000. ✗ break — investigate before trusting the position.

Counts catch missing records; amount sums catch corrupted or altered values. Together they turn a silent partial failure into a caught, investigable exception.

Alerting and ownership

Detection is worthless if no one acts. Every monitored interface and every reconciliation break needs a named owner and an alert that reaches them — a channel they actually watch, with enough context to act. A break that lands in an unread log is the same as no monitoring at all. This is as much an operating-model decision as a technical one.

Statement and payment reconciliation specifically

Two flows deserve particular rigour:

Bank statements in. Confirm you received a statement from every account for the day, and that opening/closing balances are internally consistent. A missing statement means a wrong position.
Payments out. Reconcile what you instructed (pain.001) against the acknowledgements and status (pain.002) — so you know each payment was accepted and settled, not silently rejected.

Build it in, don't bolt it on

The cheapest time to add monitoring and reconciliation is when you design the interface; the most expensive is after a wrong number has already reached the board. Make control totals and run-monitoring part of every interface's specification, alongside the data and format — not a manual check someone remembers to do.

What usually goes wrong

Green-dashboard comfort. Monitoring that shows feeds ran, with no reconciliation, so partial data passes unnoticed.
Alerts no one owns. Breaks logged but not routed to a person who acts.
Manual, after-the-fact reconciliation. Someone eyeballs it "when there's time," until the one time they don't.
Skipping statement completeness. Not checking that a statement arrived from every account, so a missing feed silently understates cash.

Monitor that every interface ran, reconcile that every one moved its data intact, route breaks to an owner who acts — and the silent, partial failures that quietly corrupt a treasury landscape stop happening.

Part of the Treasury Systems Architecture guide. See also ERP-TMS integration and the reference architecture. The newsletter sends one finance-systems pattern every two weeks.