Article map
ERP and treasury platforms hold different but connected parts of the financial lifecycle. ERP records commercial obligations, accounting and master data. Treasury manages cash, funding, investments, financial risk, payments and bank interaction. When integration is weak, teams rekey transactions, maintain inconsistent masters and reconcile status through spreadsheets.
Strong integration does not require one system to own everything. It requires clear domain ownership, stable identifiers, canonical data, status feedback and reconciliation. This article presents an architecture that connects obligations, execution and accounting without creating uncontrolled dependencies.
1. Define systems of record by domain
The architecture should state which system is authoritative for legal entities, bank accounts, counterparties, invoices, payment proposals, treasury instruments, market data, bank transactions and ledger entries.
Authority can be distributed. ERP may own vendor and invoice; treasury may own debt and hedge deals; a bank message evidences payment status. The important point is that each field has a defined owner and controlled update route.
Ambiguous ownership creates circular interfaces and last-write-wins errors.
2. Use stable shared identifiers
Legal entities, accounts, counterparties, instruments, payments and journal batches need stable identifiers that survive transmission and status return.
Mapping tables should be governed and effective-dated. One entity can have different codes in multiple ERPs, but the treasury platform should map them to a canonical identity.
Identifiers enable traceability and idempotency. Relying on name, amount and date makes duplicate detection and reconciliation fragile.
3. Design a canonical integration model
A canonical model defines business concepts independently of source-specific fields. It can represent obligation, payment, account, transaction, deal, accounting entry and status consistently.
Source adapters transform ERP data into the canonical model; target adapters transform it into the treasury or bank requirement. This reduces point-to-point logic and supports multiple ERPs.
The canonical model should preserve source reference and optional detail rather than force all systems into the lowest common denominator.
4. Integrate master data before transactions
Transactions cannot be reliably processed if entity, account, counterparty, currency and chart-of-account mappings are missing or inconsistent.
Master-data interfaces should include status, validity dates and approval. A closed bank account should not remain eligible for payment. A new legal entity should not generate transactions before mappings and authority are complete.
Failed master synchronisation should block or quarantine dependent transactions rather than produce an unknown-code workaround.
5. Move approved obligations with control context
Payment proposals should carry source approval, invoice or obligation references, beneficiary identifier, amount, currency, due date, payment method and legal entity.
The treasury platform should know whether it may rely on ERP approval and which additional controls remain, such as beneficiary change, account selection, duplicate and liquidity approval.
Manual extraction and re-upload break lineage. Where files are necessary, they should retain unique references and validation.
6. Return status to the source
ERP users need to know whether an obligation was received, rejected, approved, transmitted, accepted, settled or returned. Status feedback prevents duplicate resubmission and improves supplier communication.
Status should be line-level where possible. A batch accepted by the bank can contain rejected transactions.
The source system should not mark an invoice paid based solely on file transmission. Settlement or defined bank status should trigger the appropriate update.
7. Integrate bank actuals for reconciliation and forecasting
Bank balances and transactions can flow through treasury into ERP or directly to a reconciliation layer. The design should avoid duplicate ingestion and inconsistent enrichment.
The bank record should link to payment, receipt, deal or unknown transaction. Classified actual cash can update forecast variance while accounting entries post to ERP.
Unmatched bank items need ownership and status visible to both treasury and finance.
8. Connect treasury instruments to accounting
Debt, investment, FX and derivative records may generate accruals, settlements, valuations and journal entries. The interface should carry instrument, accounting event, date, entity, account, currency, amount and approval.
Accounting rules and chart mappings should be versioned. A journal should be traceable to the deal and calculation version.
ERP rejection should return to treasury as an exception; journals should not disappear into a technical file directory.
9. Choose batch or event-driven patterns deliberately
Scheduled batch is efficient for high-volume periodic data. Event-driven integration is valuable where status or decision latency matters, such as payment acknowledgement or intraday balance.
The choice should consider volume, service deadline, source capability, failure recovery and cost. “Real time” is not a control objective by itself.
The architecture can combine both patterns while presenting one lifecycle.
10. Enforce idempotency and duplicate protection
Every business event should have a unique identifier. Processing the same message twice should not create a second payment, deal or journal.
Retry mechanisms should know whether failure occurred before or after target acceptance. Reconciliation of counts and control totals adds protection for batch interfaces.
Manual resubmission should use controlled replay rather than creating a new unrelated file.
11. Validate structure and business meaning
Technical validation checks schema and required fields. Business validation checks active entity, permitted account, known counterparty, currency, date, balanced journal and source approval.
Errors should be reported with field and reason in language users can act on. A generic “interface failed” message creates delay.
Accepted warnings and mapping overrides should be evidenced and reviewed for recurrence.
12. Secure the interface lifecycle
Data may contain bank details, employee information, commercial terms and financial positions. Encryption, authentication, least privilege and controlled secrets are required in transit and at rest.
Service accounts should not have broad interactive access. Credentials and certificates need rotation and monitoring.
Non-production environments should use protected test data. Production support access should be logged and time-bound.
13. Monitor business completeness
Monitoring should compare expected and actual records, counts, values and deadlines. A technically successful zero-record file may be a business failure.
For payments, monitor source count through bank settlement. For journals, reconcile debit and credit totals and ERP posting. For statements, compare expected accounts and dates.
Dashboards should identify which entity or amount is affected and which team owns resolution.
14. Plan recovery and replay
Runbooks should define how to restart, replay, reconcile and confirm downstream state. The system should preserve checkpoints and original messages.
Recovery should avoid duplication and out-of-sequence processing. A master-data message may need to complete before dependent transactions are replayed.
Periodic tests should simulate partial failure, not only total outage.
15. Test end-to-end business scenarios
Testing should follow representative lifecycle: create invoice, approve, send payment, receive bank status, settle, receive statement, reconcile and post accounting.
Negative cases should include changed beneficiary, duplicate file, unknown account, partial batch rejection, late statement, ERP posting failure and interface retry.
Parallel testing should compare values and status, not merely file counts.
16. Govern change across systems
An ERP field change can break treasury mapping; a treasury workflow change can alter source status. Change governance should identify interface dependencies, version contracts and test owners.
Release calendars should account for bank and ERP blackouts. Emergency fixes need retrospective review and documentation.
Interface documentation should be generated or updated as part of deployment, not left to project memory.
Define non-functional requirements by financial consequence
Interface design should specify availability, latency, throughput, recovery, security, retention and observability for each business service. A payment-status update before cut-off may need minutes; a monthly reference file may tolerate hours. Setting the same requirement everywhere wastes cost or leaves critical flows under-protected.
Capacity testing should include peak payment runs, month-end journals and large statement histories. Recovery tests should examine partial processing and target state, not merely restart. Security requirements should cover service identities, encryption, secrets, data minimisation and support access. These qualities determine whether the integration is usable under real operating conditions.
Create a reusable multi-ERP template
Groups with several ERPs should avoid bespoke logic for every instance. A template can define canonical entities, accounts, obligations, statuses and journals; required source fields; validation; acknowledgements; error handling and reconciliation. Local adapters map to the template while approved country-specific data remains available.
The template should include onboarding evidence and conformance tests. Deviations need owner, rationale and upgrade plan. This approach allows treasury to scale without pretending every ERP is identical and prevents local customisation from becoming permanent ungoverned architecture.
Practical illustration: connecting payment and accounting status
An ERP sends an approved supplier batch with unique invoice and payment references. Treasury validates beneficiary and liquidity, transmits the payments and returns line status. One line is rejected by the bank for a closed account and remains unpaid in ERP.
The corrected beneficiary follows independent verification and the replacement payment links to the original invoice. After settlement, the bank debit matches the payment and ERP clears the liability. No user rekeys the amount, and the rejected line does not disappear inside a successful batch total.
Implementation checklist
ERP–treasury integration should include:
- domain-level system-of-record decisions;
- stable shared identifiers and governed mappings;
- canonical business data with source retention;
- master-data synchronisation before transactions;
- approved obligation and control context;
- line-level status feedback;
- bank actuals for cash, forecast and reconciliation;
- instrument-to-accounting lineage;
- deliberate batch and event patterns;
- idempotency, totals and safe replay;
- structural and business validation;
- encrypted, least-privilege service access;
- expected-versus-actual business monitoring;
- recoverable sequencing and checkpoints;
- end-to-end positive and negative testing; and
- cross-system change governance.
Common integration failures
Common failures include unclear source of truth, mapping entities by name, sending payments without status return, marking invoices paid at transmission, building duplicate statement feeds, retrying without idempotency and monitoring only whether a file moved.
Another failure is creating direct custom logic between every ERP and bank. The resulting estate becomes expensive to change and difficult to explain.
Closing perspective
ERP–treasury integration should connect commercial obligation, liquidity decision, bank execution and accounting outcome. It succeeds when each system retains the role it is best placed to perform while identifiers, status and evidence travel across the boundary.
A governed canonical layer, reliable feedback and end-to-end reconciliation remove manual reconstruction and give treasury and finance one explainable lifecycle from source to settlement.
Frequently asked questions
What data should flow between ERP and treasury?
Common flows include legal entities, accounts, counterparties, approved obligations, payments, forecasts, debt or hedge accounting entries, bank statements, settlement status and reconciliation results.
Which system should be the source of truth?
Source of truth should be assigned by data domain. ERP may own invoices and ledger, treasury may own deals and liquidity decisions, while bank data evidences settlement. The systems should not compete for the same field without governance.
Should ERP–treasury integration be real time?
Use event-driven integration where decision speed and status matter, and scheduled batch where volume and timing permit. The key is defined service levels, completeness and recoverability—not real time for every flow.