Treasury policies and procedures: what software can run and what stays with people

Software can already watch whether treasury procedures are followed and can draft revisions and audit evidence. Approving policy and deciding who may move cash stay with people. None of it holds up until bank account records, user access lists and policy limits are complete, current and stored as data.

Where software earns its place

Monitoring is the strongest case. A treasury management system or a rules engine can compare every executed payment, transfer and hedge against the limits the policy sets. Counterparty exposure, signatory authority, tolerance between approved and paid amounts: each can be checked on every transaction. Sampling is no longer necessary. Breaches surface the same day. Nobody has to wait for a quarterly review.

Reconciliation fits well too. Matching bank statements to the ledger and flagging unexplained differences is repetitive work that machines do reliably once the account mapping is clean.

Access reviews are another good candidate. A script can pull user lists from the bank portals, the treasury system and the ERP, then test them against the role matrix. It will find people who can both create and release a payment. It will also find leavers who still hold tokens. Finding them by hand is slow and easy to get wrong.

AI tools help with the writing. They can draft a procedure from a recorded walkthrough and compare procedure text against the published policy to find contradictions. They can also assemble the cycle memos and evidence packs auditors ask for. Publishing and attestation tracking belong in a workflow tool that records who read which version and when.

Where a person has to decide

Scope and governance are judgment calls. Someone has to decide which entities treasury covers, which risks it owns and how much risk the board will accept. A model can summarise options. It cannot carry accountability for the choice.

Policy approval works the same way. The signature means something only because a named person can be asked to explain it.

Control design needs experience. Deciding whether a control is strong enough depends on how the team actually behaves under pressure, and no document captures that. When monitoring flags an exception, a person must judge it. Sometimes a payment outside the rules was a legitimate emergency. Sometimes it was the first sign of fraud.

Audit findings call for root cause analysis before anyone rewrites a procedure. Software will happily patch the symptom. Security requirements also stay human. That covers who holds bank administration rights, how independent approval is enforced and how tokens are issued and revoked. Tools can propose a design, but a person who understands the threat must own it.

What the data must look like first

Start with a bank account inventory that is genuinely complete. It should list every account, every mandate and every authorised signatory, with an owner responsible for keeping it current. Most automation failures in treasury trace back to an account nobody knew about.

Policy limits need to exist as structured parameters. A limit buried in a paragraph of prose cannot be tested. Each threshold should have a value, a scope and an effective date.

User identities must be joined across systems. If the bank portal knows someone by an email address and the ERP knows them by an employee number, access testing produces noise.

Counterparty identifiers should be consistent between the treasury system and the ledger. Exception history matters as well. Each flagged event needs a recorded outcome and reason, otherwise there is nothing to calibrate alerts against and the team learns to ignore them.

Procedure documents need owners and version history before any AI drafting starts. Feeding a model a folder of conflicting drafts produces confident nonsense.

Questions to ask the people who run it

• When a payment is urgent and the usual approver is away, what actually happens?
• Which bank portals do you log into that are not listed in the procedure?
• Are there spreadsheets you keep outside the treasury system to track limits or exposures?
• Who tells you when someone leaves, and how quickly do their bank tokens get cancelled?
• Which steps in the written procedure do you skip, and why?
• When an auditor asks for evidence, where do you go to find it?
• Has a limit ever been breached deliberately, and who signed off afterwards?
• Which controls do you trust least?

The answers usually reveal workarounds that the documented process hides. Those workarounds are where automation will break first. Each one has to be either formalised or removed before a tool is switched on.

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.