When treasury approval rights drift away from written policy

A frequent failure is drift between treasury policy and practice. Approval limits and system access get widened for a short-term reason and never narrowed. The procedure still describes dual control, so nobody looks. It surfaces through an audit sample or reconciliation break. The fix is remapping access to authority.

How the drift begins

It almost never starts with bad intent. An approver goes on leave during a busy close. Someone on the cash team is given release rights in the banking platform so payments keep moving. The request is approved by email, the change goes through, and the deadline is met.

Nobody files a ticket to take the access back. The person who granted it moves on. Later, a new bank portal or payment module goes live, and roles are copied from the old setup, including the temporary ones. Now the exception is baked into the configuration.

Over time, more of these pile up. A delegation letter signed for a project is still on file. A treasury analyst can both create a payee and release a payment to it. The authority matrix in the policy says otherwise, but the matrix lives in a document and the access lives in a system. Those are maintained by different teams who rarely compare notes.

Why the documents hide it

Treasury procedures are often written well and revised badly. The cycle memo describes how a payment file is prepared, checked and certified. It reads as though separation of duties is intact. Auditors receive the memo, test a sample, and usually find the steps were followed on paper.

The gap sits between the steps. A file can be prepared and certified by the same login if that login holds both roles. The memo never says who holds which role. It assumes the security setup matches the policy, and nobody owns the job of proving that assumption.

How it gets noticed

Sometimes an external auditor pulls user access listings alongside the payment sample and spots a name in both the preparer and approver columns. That is the lucky case.

More often the signal is indirect. The cash reconciliation throws up an item nobody can explain, and tracing it leads to a payment released outside normal hours by someone not on the approver list. A bank relationship manager asks why a particular user keeps appearing on high-value releases. A new controller reads the policy, then sits with the team for a day and sees the process run differently.

Quality checks on disbursement schedules can catch it too, if they look at who certified and not only what was certified. Most checks look only at amounts and payees.

Questions to ask the people who run it

The people doing the work know where the shortcuts are. They are usually relieved to be asked, provided the questions do not sound like an accusation.

• When the usual approver is away, what actually happens to a payment that needs releasing?
• Has anyone been given access "just for now" that they still have?
• Can anyone on the team set up a new payee and also send money to it?
• Which steps in the written procedure get skipped when the deadline is tight?
• Where do delegation letters get kept, and who checks whether they have expired?
• When the banking platform was last changed, who decided which roles carried over?
• If a payment went out wrong, how would the team find out, and who would they tell first?

Listen for hesitation and for phrases like "technically" or "in theory". Those words usually sit right on top of the gap.

Fixing it without stopping payments

Start by pulling every user and role from each system that can move cash: the banking portals, the payment module of the ledger, any treasury workstation. Lay that beside the authority matrix and the current delegation letters. Every mismatch goes on a list with an owner.

Do not remove all excess access in a single sweep. Payments will stall and the team will find new workarounds by the afternoon. Agree a cover arrangement for each removed right first, so absence no longer forces an emergency grant.

Then revise the procedure to name roles, not just tasks. State which role prepares, which approves and which certifies, and that no login may hold conflicting pairs. Write the system security requirements alongside it, so the configuration has a written standard to be tested against. Temporary access should carry an end date in the system itself, not in someone's memory.

Finally, fix the governance question that let this happen. Someone in treasury must own the comparison between policy and access, and that duty belongs in the scope document, not in a side email.

Keeping it fixed

Build an access review into the regular control calendar and have it signed by treasury, not by IT alone. IT can confirm who has a role. Only treasury can say whether they should.

Add a line to the disbursement quality checks that compares the certifier against the preparer. Make any system change that touches payment roles go through treasury sign-off before it goes live.

When auditors ask for documentation, send the access listing with the cycle memo. Pairing them forces the comparison every time, and a future drift shows up while it is still small.

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.