How treasury policies and procedures are set up in finance and ERP systems

Treasury policy usually lives in an approved document set owned by the treasurer or CFO. The finance system enforces it through configuration: bank account master data, approval workflows, payment release limits, user roles and audit logs. Most of the risk sits in the gap between the written policy and those settings.

Where the policy itself lives

The governing documents are rarely held inside the ERP. A board or audit committee approves a treasury charter that sets scope. It names which entities, currencies and instruments the treasury function may touch, and who can approve exceptions. Beneath that sit specific policies covering cash management, investments, borrowing, foreign exchange and bank relationships.

These are normally stored in a policy repository or document management tool with version control and a named owner. Publication matters as much as approval. A policy that sits in a folder no one opens has no effect on how payments get released.

How policy becomes system settings

This translation step is the part most often done once and never revisited.

Bank account master data is the first place policy shows up. Each account record carries its purpose, the entity that owns it, the authorised signatories and the people allowed to change it. Opening or closing an account should trigger a workflow that matches the policy on bank relationships.

Payment approval is configured as release strategies or workflow rules. These route a payment run or a single high value transfer to approvers based on amount bands, payment type, currency or beneficiary. Dual approval for manual payments is common. So is a rule that the person who creates a payee cannot also approve payments to it.

Where a separate treasury management system exists, it holds counterparty limits, approved instrument types and dealing authorities. Deals that breach a limit are blocked or flagged. The ERP then receives settlement and accounting entries from that system through an interface.

Tolerances also encode policy. Matching rules for invoices and orders, thresholds for holding payments that fail validation and limits on early payment decisions all reflect choices someone made about acceptable risk.

Procedures, monitoring and the audit trail

Procedures describe the daily mechanics: who pulls bank statements, how cash positions are built, when disbursement schedules are certified, how failed or returned payments are handled. They often sit in desk notes or a process wiki alongside the formal policy.

Monitoring tends to rely on exception reports from the system. Typical examples cover payments released outside workflow, changes to bank details, overrides of a hold and limit breaches in the treasury system. Bank reconciliation is the backstop. Any cash movement that does not match a recorded transaction surfaces there.

Audit work draws on the same evidence. Internal audit and external auditors will ask for cycle memos, samples of approved payments and change logs for master data. When findings come back, the revision step should update both the document and the configuration. Updating only one is a frequent cause of drift.

Security requirements for treasury systems

Security is specified separately because treasury systems move cash directly. Requirements usually cover role design with clear segregation of duties, strong authentication for bank portals and payment release, and restricted access to payment files between generation and transmission. Bank connectivity, whether through direct host links or a network service, needs encryption and file integrity checks. Periodic access reviews confirm that people who changed jobs no longer hold release rights.

Public sector variations

Government bodies add another layer. Funds are set up against appropriation and fund codes before anything can be obligated or paid. The general ledger fund balance must be reconciled against the central treasury's records, with differences reclassified on one side or the other. Disbursement schedules are certified before release. Internal control reviews follow mandated guidance, and auditors issue formal requests for client prepared documentation.

Questions to ask the people who run it

What staff do often differs from what the policy says. These questions tend to expose that gap:

• When a payment is urgent, what actually happens to the approval route?
• Who can change a supplier's bank details, and is a call back to the supplier made every time?
• Which reports get checked each morning, and which ones are ignored?
• Are there bank accounts or portals that sit outside the main system?
• How are approvers covered during holidays, and does anyone share a login or token?
• When did someone last compare the approval limits in the system with the signed policy?
• Which spreadsheets feed the cash position, and who maintains them?
• What did the last audit finding lead to in practice?

What tends to break when the process changes

Changes to approval limits often get made in the policy and forgotten in the release strategy, or the reverse. New entities are added without their bank accounts joining the monitoring reports. A move to a new treasury system can quietly drop a control the old one enforced by default. Before any change goes live, trace each policy clause to the setting, report or manual check that enforces it, and confirm someone owns each one.

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.