Who Knows What in Treasury Policies and Procedures

The policy owner knows what the board approved and why. The people executing payments and trades know where procedures bend under pressure. Accounting knows which balances never reconcile. IT knows who can actually release money. Trouble starts where that knowledge never meets.

The policy owner

The treasurer or head of treasury holds the reasoning behind each limit. Counterparty caps, investment criteria and the approval matrix all came from somewhere: a past loss, a lender covenant, a board member's concern. That history rarely makes it into the written policy. When someone later proposes loosening a rule, nobody else can say whether the original risk still exists.

The policy owner usually does not know how the procedures are performed day to day. They see exceptions only when someone escalates them.

The execution team

Analysts and payment staff know the workarounds. They know which bank portal times out before a release is complete. They know which approver is always travelling, so a deputy signs. They know that a certain urgent supplier payment gets pushed through by phone.

None of this is hidden out of bad intent. It is how the work gets done when the documented path is too slow. But each workaround quietly rewrites the control, and the policy owner believes the old version still holds.

Accounting and reconciliation

The controllership team sees the result of every treasury action once it hits the ledger. They know which bank accounts carry unexplained differences month after month. They know which receipts arrive without enough detail to match to an invoice, and which adjustments get booked to clear a balance.

This is often the earliest evidence that a procedure has drifted. Yet accounting tends to treat these items as their own clean-up work. They seldom report them back to treasury as a process failure.

Systems and security

IT holds the truth about access. The treasury policy may say two people must approve any payment above a threshold. The system may let one user create, approve and release the same file, because a role was copied from a departed employee.

Security staff understand user provisioning and logging. What they often lack is any sense of which treasury functions are sensitive. A request to grant release rights can look as routine to them as a request for report access.

Auditors and control reviewers

Internal audit and compliance reviewers know what the documentation says and what a sample of transactions showed. They have seen the cycle memos and the evidence prepared for external auditors. They know which findings recur.

Their view is periodic. A procedure can pass review in one quarter and be bypassed for the rest of the year. Reviewers also tend to test the control as written, so a workaround that never appears in the documents may never be sampled.

Business units

Operating teams know their own cash needs before treasury does. They know a large supplier payment is coming, or that a customer will pay late. When that information arrives at the last minute, treasury breaks its own procedures to cope.

Where the gaps cause damage

The worst failures sit between pairs of roles. A policy limit and a system permission that disagree can go unnoticed for years, because the policy owner reads one and IT manages the other. A reconciliation break that accounting clears with a manual entry may be the only trace of a payment released outside procedure.

Revisions cause their own trouble. A procedure gets updated after an audit finding, but the change reaches only the people in the meeting. The bank mandate still lists old signatories. The system workflow still routes to a former approver. The new procedure exists on paper while the old one runs in practice.

Monitoring tends to measure what is easy to count, such as whether approvals were recorded. It rarely asks whether the approver understood what they were signing.

Questions to ask the people who run it

The documented procedure is the starting point. These questions reveal what actually happens.

• When a payment is urgent, what steps get skipped, and who decides?
• Who has release rights in each banking platform today, and when was that list last checked against the policy?
• Which bank accounts are hardest to reconcile, and what usually causes the difference?
• If an approver is unavailable, who signs instead? Is that person named anywhere in writing?
• What happened after the last audit finding? Which systems and bank mandates were changed to match?
• Which rule in the current policy does nobody remember the reason for?
• How much notice do business units give before a large outflow, and what does treasury do when that notice is missing?
• Are there any payments or transfers set up by phone or email with a bank, outside the normal platform?
• Who reads the exception reports, and has anything ever been done because of one?

Ask each role separately. The answers will not match, and the differences show exactly where the process needs work before any redesign begins.

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.