Manage financial policies and procedures: who knows what, and where the gaps bite

Policy owners know the rules and why they exist. Approvers know budgets and people. Processors know the workarounds. System owners know what the software truly enforces. Trouble starts when each group assumes the others share its knowledge, most often around approval limits, account setup and service agreements.

The policy owner

The controller or technical accounting lead writes the accounting policies. This person understands the standard behind each rule, the audit history that shaped it, and which judgments are deliberate. A capitalisation threshold, for example, may reflect a past finding about asset records that nobody else remembers.

What this person often lacks is a view of daily volume. A policy that reads well can create a queue of exceptions on the processing floor. Publishing a policy does not mean anyone has read it. Treating publication as adoption is the most common mistake made from this seat.

Budget holders and approvers

Managers who approve spend know things finance cannot see from the ledger. They know which supplier is mid-dispute, which project is about to be cancelled, and whose request deserves a second look. They also know how to stay just under a limit by splitting a purchase.

They rarely know what their signature commits them to. Many approvers believe they are confirming that the work was done. The policy may say they are confirming budget, coding and business purpose as well. That mismatch turns approval into a formality.

Processors in the shared service

The people matching invoices to orders and receiving reports hold the most practical knowledge in the process. They know which vendors always invoice before goods arrive. They know which approvers answer quickly, and which cost centres get coded wrong every month. They keep private lists of fixes that never reach the policy owner.

When a policy changes, these people are usually told last. Their workarounds then collide with the new rule, and nobody notices until a payment goes out wrong or a reconciliation breaks.

The people who configure the systems

Whoever maintains the general ledger classifications and the routing rules in the common financial system knows what is actually enforced. A written approval limit means little if the workflow lets a user with the right role approve anything. Account attributes set years ago may still drive reports that management reads without question.

This group often implements requests literally. If a policy is ambiguous, the configuration will carry that ambiguity into every transaction, silently.

Auditors and internal control staff

Control reviewers know where findings have landed before and what evidence will satisfy the next review. They write the cycle memos and respond to client document requests. That gives them a clear picture of the documented process, and sometimes only that picture.

They may not see the manual journal vouchers that bypass normal routing, or the informal approvals given by email when someone is on leave.

Where the gaps cause damage

Approval limits are the sharpest point of friction. The policy owner sets them, the system owner configures them, approvers work around them, and processors chase the exceptions. Each sees a different version of the same control.

Service-level agreements with a shared service centre cause a quieter kind of harm. Finance negotiates turnaround targets without knowing how many invoices arrive incomplete. The service team then meets its targets by rejecting work back to requesters, and the business experiences the agreement as obstruction.

Account structure is the slow one. When new categories are added without telling the people who prepare financial statements, mapping breaks and someone patches it by hand at period end. That patch becomes undocumented practice, and the next auditor asks about it.

Audit adjustments close the loop badly. Findings get fixed in the ledger, but the policy and the system setup that produced them often stay unchanged.

Questions to ask the people who run it

The written procedure is a starting point. These questions tend to surface what really happens.

• When an invoice exceeds a limit, who signs it in practice, and how is that recorded?
• Which rules in the policy manual get broken most often, and why?
• What do approvers believe they are confirming when they click approve?
• Which manual journals are routine, and who reviews them?
• What does the system allow that the policy forbids?
• Who heard about the last policy change, and how?
• Which service targets get met by sending work back?
• Where is a spreadsheet doing a job the system should do?
• After the most recent audit finding, what changed besides the balance?
• Who would notice first if an account mapping broke?

Ask processors and approvers separately. Their answers often disagree, and the disagreement shows where the next change needs the most care.

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.