# Interface Monitoring and Reconciliation for Treasury Systems Source: https://gravam.com/blog/interface-monitoring-and-reconciliation Author: Tan Gravam Published: 2026-07-23 Reviewed: 2026-08-19 Summary: Treasury interfaces fail silently and partially. Monitoring proves each ran; reconciliation proves the data arrived intact. How to design both from the start. **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](https://gravam.com/blog/treasury-integration-patterns-files-apis-middleware): the [ERP to the TMS](https://gravam.com/blog/designing-erp-tms-integration), 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](https://gravam.com/blog/disaster-recovery-business-continuity-treasury), 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 — one that lands in a proper [exception-management queue](https://gravam.com/blog/treasury-exception-management) with an owner and a clock, rather than in someone's inbox. > Monitoring without reconciliation gives false comfort: the dashboard is green because the feed _ran_, while it quietly moved the wrong data. Reconciliation without monitoring misses the feed that never ran at all. You need both, on every interface that matters. ## 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. The identical trap appears one layer up in AI systems, where a dashboard of aggregates cannot answer the only question anyone ever asks — [what happened to this record, on this day](https://gravam.com/blog/production-ai-observability). - **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. Bank reconciliation is the workflow I most often see redesigned — [taken apart end to end here](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation), including which parts must stay deterministic. - **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. *** _See also [ERP-TMS integration](https://gravam.com/blog/designing-erp-tms-integration) and the [reference architecture](https://gravam.com/blog/reference-architecture-for-corporate-treasury)._ ## Questions this article answers **Q: 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. **Q: 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. **Q: 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.