Designing ERP-to-TMS Integration

ERP-to-TMS integration flows reference and AP/AR data from the ERP into the treasury system, and accounting entries (and often payment status) back into the ERP's general ledger — through defined, governed interfaces that follow your system-of-record decisions. Done well, the two systems stay in step. Done as a web of ad-hoc extracts, they drift apart, and you inherit the reconciliation problem that quietly consumes finance-systems teams.

What flows between ERP and TMS

Design it as deliberate flows in both directions, anchored to the system-of-record decisions:

ERP → TMS

• Master and reference data — entities, bank accounts, counterparties, cost centres — from wherever they're mastered.
• AP / AR data to feed cash forecasting and, where relevant, payments.

TMS → ERP

• Accounting entries treasury generates — cash movements, deals, FX, interest, fees — posted to the general ledger.
• Payment status, where the ERP or a process needs it.

Each field should flow from its owner: if the ERP is the system of record for bank master data, it flows to the TMS, not the other way — and never both.

Interface design principles

• Interface-based, not point-to-point. Define interfaces with clear contracts (what data, what format, what cadence) rather than bolting on extracts whenever someone needs data. Ad-hoc extracts become undocumented spaghetti no one can safely change.
• Follow system-of-record ownership. The direction of every flow is decided by who owns the data. This prevents the classic duplicate-maintenance and drift problem.
• Idempotent and recoverable. A rerun after a failure shouldn't double-post or corrupt data; design for safe reprocessing.
• Clear cutoffs and timing. Agree when each flow runs relative to close, payment runs and the working day, so data is complete when the other side needs it.

Batch vs real-time

Choose per flow, not as a religion:

• Batch — scheduled files or jobs — suits high-volume, periodic data: end-of-day accounting, AP/AR extracts, statement imports.
• Real-time / API suits data that must be current: a payment status, an urgent balance check, an instant payment.

Most landscapes use batch for the bulk and APIs where immediacy genuinely pays. The cadence matters less than making each flow reliable, monitored and reconciled.

Reconciliation: every interface must reconcile

The rule that separates a stable integration from a fragile one: every interface carries a way to prove all the data arrived intact. Control totals — record counts and amount sums sent vs received — turn a silent partial failure into a caught exception. If an ERP sends 1,000 AP items totalling €10m and the TMS books 998 totalling €9.9m, the interface must flag it, not quietly proceed.

Error handling and monitoring

Interfaces fail — a feed doesn't run, a file is malformed, a downstream system is down. Design for it: monitor whether each interface ran and completed, alert an owner when it doesn't, and make reprocessing safe. (This deserves its own discipline — see interface monitoring and reconciliation.) An unmonitored interface is a wrong number waiting to happen.

What usually goes wrong

• Point-to-point spaghetti. Extracts built ad hoc, undocumented and unmonitored, until the landscape can't be changed safely.
• No reconciliation. Interfaces with no control totals, so partial failures surface as unexplained breaks much later.
• Unclear ownership. Both systems "own" a data domain, so they drift and you reconcile forever.
• Timing and cutoff gaps. A flow runs before its source is complete, so downstream data is subtly wrong.

Design ERP-TMS integration as governed, reconciled interfaces that follow data ownership, and the two systems stay in step. Skip that and the integration becomes the thing everyone's afraid to touch.

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