How debt and investment management is set up in finance and ERP systems

Most organisations split this work across two places. A treasury management system, or a treasury module inside the ERP, captures deals, checks them against limits and values them. The general ledger receives the resulting journals. Banks, dealing platforms and confirmation services connect at the edges and feed both.

Where the work lives

Smaller finance teams often run treasury from spreadsheets and bank portals. Postings go into the ERP by manual journal. That works until the book of borrowings and deposits grows, or until an auditor asks who approved a deal and when.

Larger teams usually adopt a dedicated treasury platform. Some ERPs include one. Others need a separate product linked by interface. The deciding factor is rarely features. It is who owns the system and whether the ERP team will support deal-level data inside the ledger environment.

The usual design separates duties along front, middle and back office lines. Dealers enter trades. A risk or control function monitors limits and exposures. Operations staff confirm, settle and account. Each role gets its own permissions, and a good setup prevents the person who booked a trade from also releasing its payment.

Master data that holds it together

Most failures trace back to static data. Before any deal is entered, the system needs records for counterparties, banks, legal entities, bank accounts, instruments and settlement instructions.

The investment policy usually turns into configuration here. Approved counterparties, credit ratings, maximum tenors and concentration limits become fields and rules. Issuer exposure is tracked by linking each security to its issuer and parent group, so that holdings across funds and entities roll up correctly. If the policy changes and nobody updates the limit tables, the system keeps enforcing the old rules without complaint.

Bank relationship data matters too. Signatories, fee schedules, facility agreements and covenant terms are often held outside the system in shared folders. Pulling them in makes covenant testing and fee analysis far less painful.

From deal to settlement

A trade is keyed in or imported from a dealing platform. The system checks it against limits and flags breaches for approval. A confirmation arrives from the counterparty, often electronically, and is matched against the booked deal. Unmatched confirmations sit in a queue for someone in operations to chase.

Once matched, the deal generates payment instructions. These usually flow to the bank through a payment hub or direct connectivity. Inbound settlement shows up on bank statements, which are reconciled automatically against expected cash flows where the matching rules allow.

Liquidity management draws on the same data. Daily cash positioning combines opening bank balances, maturing deals and forecast flows from payables and receivables. Many teams still finish this view in a spreadsheet because the forecast feeds from operating units are unreliable.

Foreign currency and interest rate deals

Spot and forward FX trades follow the same lifecycle as money market deals. Swaps, options and interest rate derivatives add complexity. They need market data for valuation, which means daily rate and curve feeds from a data vendor.

Where hedge accounting applies, the system must link each hedge to its underlying exposure and keep documentation of the hedge relationship. Effectiveness testing is sometimes automated and sometimes done outside the system. Either way, the designation records need to survive audit.

Accounting and reporting

The treasury system usually acts as a subledger. It calculates accruals, amortisation of premiums and discounts, revaluations and realised gains or losses, then sends summarised journals to the ledger. Account mapping rules sit in the treasury system, which surprises ERP teams who expect to control them.

Period end is where the design gets tested. Valuations must be run on the correct date with the correct market data. Interfaces must complete before the ledger closes. Intercompany loans need matching entries on both sides, and they often disagree because each entity books them differently.

Standard reports cover debt maturity profiles, investment holdings by issuer, counterparty exposure, interest expense and income, and covenant positions. Treasury reports for management and accounting reports for the close are frequently built separately and do not always reconcile.

Questions to ask the people who run it

Written procedures describe the intended flow. Daily practice usually has workarounds. These questions tend to expose them.

• Which deals are entered outside the system, and how do they reach the ledger?
• When a limit is breached, who approves it, and is that approval recorded anywhere?
• How often do confirmations fail to match, and what is the usual cause?
• Where do settlement instructions come from, and who can change them?
• Which valuations are calculated in the system and which in spreadsheets?
• What happens when the market data feed fails on a valuation date?
• Who keeps the policy limits in the system aligned with the approved policy document?
• How are intercompany loan differences found and resolved at month end?
• Which reports does the treasurer actually use, and which were built and then abandoned?
• If one person were away for a fortnight, which tasks would stop?

What tends to need attention

Changes here often focus on the visible front end, such as dealing screens and dashboards. The harder problems usually sit in master data ownership, interface timing and the handoff between treasury and the accounting team. Any redesign should map who changes each data item, which system holds the authoritative version and how the ledger learns about it. Getting that right makes the reporting trustworthy, and it is the part auditors look at first.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.