Manage debt and investment: what software can run and what needs a person

Software can already run much of the mechanical work in treasury debt and investment: matching confirmations, generating settlement messages, posting accruals and checking positions against limits. People still set policy, manage banks and approve any trade that changes risk. Automation fails until trade, bank and market data share identifiers and cutoffs.

Steps software handles well today

Transaction processing is the strongest candidate. Once a deal is captured, a treasury system can match the counterparty confirmation, flag mismatches and release payment instructions through the bank channel. The same holds for foreign currency spot and forward deals and for interest rate swaps. The machine does this faster than a clerk and does not tire of comparing fields.

Accounting reports follow naturally. Interest accruals, premium and discount amortization, fair value adjustments and maturity entries are all rule driven. When the deal record is clean, the journals post themselves and the subledger ties to the general ledger without manual rework.

Daily cash positioning is another good fit. Bank statement feeds arrive overnight and intraday. Software can aggregate balances, net expected flows and show where cash sits. AI models add value in forecasting receipts and disbursements with recurring patterns, such as payroll, tax runs or regular customer remittances. They struggle with one off events, and someone has to say which events those are.

Issuer exposure monitoring is largely arithmetic. A rules engine can compare holdings by issuer, sector and rating against policy limits and raise an alert before a purchase settles. That check belongs before the trade, built into the workflow, and not in a report someone reads afterward.

Steps that still need a person

Writing the investment policy is a governance act. It reflects the board's appetite for risk, the business's cash needs and what the auditors and lenders will accept. A model can draft language. It cannot own the trade off between yield and safety.

Bank and broker relationships are human work. Credit lines, fee negotiations and the willingness of a bank to help during a tight week depend on trust built over years. Software can score counterparties on service and pricing, and that scoring helps the conversation. It does not replace it.

Decisions to hedge, refinance or draw on a facility sit with people. So does reading a covenant when the business changes shape, or deciding whether a limit breach is acceptable for a short period. Exceptions in general belong here. A failed settlement, a disputed rate fixing or a confirmation that never arrives each needs someone who understands the deal and can call the other side.

Segregation of duties also shapes the split. The person who executes a trade should not be the one who confirms or settles it. Automation can enforce that separation, but a human still has to approve the release of large or unusual payments.

What has to be true about the data first

Every instrument needs a single identifier that the trading platform, the custodian, the bank and the ledger all recognise. Where each system invents its own reference, matching collapses into manual lookups.

Counterparty and bank account master data must be owned by one team and changed through a controlled process. Fraud in treasury usually enters through an altered account detail, so this record deserves more care than any forecast model.

Market data needs a known source and timestamp. Valuations, FX revaluation and exposure checks are only as good as the rates behind them. If treasury uses one feed and accounting another, the reports will never agree.

Cutoffs must line up. Bank statements, trade capture and the ledger close should share a clear definition of the end of a business day, including how weekends and other time zones are handled.

Finally, hedge documentation has to be linked to the trades it supports. Without that link, hedge accounting reverts to spreadsheets at every close.

Questions to ask the people who run it

• Which deals still get agreed by phone or chat and keyed in afterward?
• When a confirmation does not match, who chases it, and how is that logged?
• Which spreadsheets sit between the treasury system and the ledger, and who maintains them?
• How are bank account changes requested, checked and approved in practice?
• Which counterparties send confirmations in a format the system cannot read?
• Where does the rate used for month end revaluation actually come from?
• What happens when an exposure limit is breached on a busy day? Who decides it can stand?
• Which forecasts does the team trust, and which do they quietly override?
• Are there investments or facilities that live outside the main system entirely?

The answers usually reveal side channels that the documented process never shows. Those side channels are where automation projects stall, so map them before choosing tools.

Where hand-offs tend to break

The weakest points are the seams between front office capture and back office settlement, and between treasury records and the general ledger. Automating either side alone just moves the manual work to the gap between them. Fix the shared data and the controls at those seams, and the tools on either side start to deliver.

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.