Manage financial policies and procedures: what to automate, what to keep human, what the data needs

Software can enforce approval limits, route journals and invoices, publish policy text and flag transactions that break the rules. People still have to decide what the policy says, negotiate service terms and judge exceptions. None of it works until the chart of accounts, user roles and approver lists are clean.

Where software already carries the load

Approval limits are the easiest win. A workflow tool or the finance system itself can hold the delegation of authority and refuse to release a payment, purchase order or manual journal above a user's threshold. It routes the item to the next approver and keeps a record of who signed. Done well, this replaces the email chains and spreadsheet sign-offs that auditors dislike.

General ledger maintenance benefits too. Validation rules can stop postings to closed or invalid accounts, block combinations of cost centre and account that make no sense, and force a reason code on adjustments. Segregation of duties checks can run continuously, catching the same person who sets up a supplier and also approves its invoices.

Publishing is mostly mechanical. A policy portal with version control can push the current text to staff, record acknowledgements and retire old copies so nobody works from last year's PDF.

AI adds value at the edges. It can answer staff questions in plain language from the approved policy text, draft summaries of a long capitalisation policy, and compare a draft against an accounting standard to point out gaps. It can also read journal and payment data and surface items that look unusual, such as round amounts posted late at night or approvals that cluster just under a limit. For audit season, it can assemble the documents requested by auditors and produce a first draft of a cycle memo from walkthrough notes. A controller should read every one of those drafts before it leaves the building.

Where a person has to stay in charge

Writing accounting policy is judgment work. Choosing how to recognise revenue on a bundled contract, where to set a capitalisation threshold or how to estimate an allowance for bad debts depends on the business model, the auditor's view and the board's appetite for risk. A model can propose wording. It cannot own the position when an auditor challenges it.

Service-level agreements with a shared service centre or an outsourced provider are negotiations between people with competing interests. Software can measure performance against the agreed terms afterwards. Agreeing those terms in the first place is a conversation.

Exceptions also need a human. When a purchase falls outside policy for a good reason, someone with authority has to accept the risk and say so on the record. Automating that approval away defeats the purpose of having a limit.

The decision to move entities onto common financial systems belongs here as well. It touches budgets, local statutory needs and staff who will resist a change to their tools. Analysis can inform it, but leadership has to make it.

What has to be true about the data first

The approval matrix in the system must match the signed delegation of authority. In many organisations these drifted apart years ago, and nobody noticed because approvals happened by email anyway. Reconcile them line by line before switching on enforcement.

The organisation hierarchy needs to be current. Workflow routes by manager and role, so leavers, acting managers and vacant posts all cause items to stall or go to the wrong person.

The chart of accounts should mean the same thing in every entity. If one subsidiary books software licences to an equipment account and another expenses them, validation rules and anomaly detection will produce noise.

Policy documents need a single owner and a single live version, each mapped to the controls that enforce it. An AI assistant trained on a folder full of conflicting drafts will give confident, wrong answers.

Questions to ask the people who run it

• When a payment is urgent and the approver is away, what actually happens?
• Which approvals are given verbally or by message and recorded later, if at all?
• Are there users who share logins or approve on behalf of someone else?
• Which policy do staff actually follow when the written one and local practice disagree?
• How often are manual journals posted to accounts the policy says should only receive system entries?
• Who finds out when someone changes role, and how long before their system access reflects it?
• What questions do staff ask finance repeatedly because the policy is unclear?
• Which service-level terms with the shared service centre are measured, and which are just assumed?

The answers usually reveal workarounds that any automation will either break or quietly preserve.

Traps to avoid

Switching on hard limits without an exception route pushes activity back into email. Splitting a purchase to stay under a limit is easy for a person and easy for software to detect, so build that check at the same time. Treat AI policy answers as a help desk, never as the policy itself, and keep the approved text as the source it must quote.

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.