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

Financial policies live partly on paper and partly in the system. The written policy sits in a document library or intranet. The enforceable parts are configured inside the ERP: the chart of accounts, posting rules, asset settings, approval workflows and user roles. Most real control comes from that configuration.

Where the written policy sits

The accounting policy manual is usually owned by the controller or a technical accounting team. It covers revenue recognition, capitalisation, accruals, reserves and similar judgement areas. It is typically published on an intranet page or a controlled document repository, with a version history and a named approver.

The trouble is that the manual and the system are maintained by different people. Finance edits the document. A systems team edits the configuration. Nothing forces the two to stay aligned, so they drift.

Accounting policy turned into configuration

Much of what a policy says gets translated into ERP settings. The chart of accounts is the clearest example. Account classifications, categories and the attributes attached to each account (cost centre, project, fund, entity) decide what can be reported later. A policy that says a certain cost must be tracked by programme only works if the account demands that attribute at posting.

Fixed asset policy behaves the same way. Asset classes carry default depreciation methods, useful life settings and the general ledger accounts they post to. The capitalisation threshold is sometimes a hard rule in the purchasing or asset module. Just as often it is a line in the manual that clerks apply by eye.

Accruals and estimated liabilities tend to sit somewhere in between. Recurring accrual templates and reversal rules can be configured. The judgement about what to accrue usually stays manual, captured in a journal and supported by a spreadsheet.

Manual journals deserve attention. Most systems route them for approval, but the routing logic varies widely. Some approve by amount, some by account range, and some only check that preparer and approver are different people.

Approval limits and delegation

The delegation of authority starts life as a board-approved or executive-approved document. It sets who may commit spend, approve invoices, release payments and post journals, and up to what level.

In the ERP this becomes an approval matrix inside workflow. Purchase requisitions and orders route by value and cost centre. Invoices that fail matching against the order and receipt route to a named approver. Payment runs need release by someone outside the accounts payable team. Role design underpins all of it, because segregation of duties is enforced through what each role can and cannot do.

Approval hierarchies are often pulled from the HR system's reporting lines. That works until reorganisations, acting managers and vacancies leave gaps that someone patches by hand.

Common financial systems and shared data

Organisations with several entities or acquired businesses usually aim for one ledger design and one set of master data. Vendor, customer, asset and account master records are governed centrally, with a request process for new entries. Where full consolidation onto one platform has not happened, a common chart of accounts is mapped across systems and the mapping table becomes a policy artefact in its own right.

Subledgers for assets, payables and payroll feed the general ledger either in detail or in summary. Which one is chosen shapes how reconciliations are done and how much drill-down is available at close.

Service-level agreements

Where a shared service centre or outsourced provider runs transaction processing, the policies are backed by service-level agreements. These define turnaround for invoices, payment accuracy, close deadlines and escalation routes. They are usually tracked in a ticketing tool or a monthly scorecard, not in the ERP itself. Their link to the accounting policies is often weaker than people assume.

How compliance is checked

Internal control teams document each cycle in narrative memos and test key controls against them. Auditors request evidence that a configured control actually operated. When findings arise, the adjustments and policy updates are logged, but closing the loop into system configuration is a step that frequently stalls.

Questions to ask the people who run it

• When the policy manual last changed, who updated the system to match, and how did they know to do it?
• Which approval limits are enforced by workflow, and which depend on someone noticing?
• How are approvers kept current when people leave, go on leave or change roles?
• What happens to an invoice or journal that the workflow cannot route?
• Is the capitalisation threshold set in the system, or applied by judgement at entry?
• Which accounts allow posting without the attributes the policy says are required?
• Who can create a new general ledger account or vendor, and who reviews that request?
• Are there emergency or override roles, and when were they last used?
• Which spreadsheets sit outside the ERP but feed figures into it?
• What did the most recent audit finding change in practice, as opposed to on paper?

The answers usually reveal a set of informal rules that keep the process working. Any change to policy or configuration needs to account for them, or they will quietly reappear.

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.