How internal controls are set up in finance and ERP systems

Most of this process lives outside the ERP. The board and management set governance, ethics and risk appetite in charters, policies and minutes. The finance system carries the parts that can be enforced: user roles, approval limits, matching tolerances, budget checks, and the ledger structure that controls are later tested against.

Governance and ethics sit in documents

The board and audit committee are established through charters and terms of reference. No module configures them. What the system sees is their output: approved delegation of authority, signed-off policies and the risk appetite statement that later becomes numbers in configuration.

The code of ethics is usually held by legal or HR. Annual attestations often run through an HR platform or a governance, risk and compliance tool. Finance rarely owns this. It does depend on it, because conflict of interest declarations feed vendor approval and procurement reviews.

Roles turn into security design

Assigning responsibility for controls has two layers. On paper, a control owner is named for each control in the matrix. In the ERP, responsibility becomes security roles, approval workflows and segregation of duties rules.

The security design is where intent most often gets lost. A policy may say the person who creates a supplier cannot also pay it. The system only enforces that if the roles were built to keep those transactions apart and someone checks for conflicts when access is granted. Many organisations run a separate access governance tool for this. Others rely on periodic exports and a manual review, which is weaker but common.

Objectives and risks live in a control matrix

Process objectives and their risks are normally recorded in a risk and control matrix. Each row links a risk to a control, an owner, a frequency and the evidence expected. Some teams keep this in a governance tool. Plenty still use spreadsheets.

The matrix is only useful when every control on it can be traced to something real. That might be a configured setting, a report someone reviews, or a manual sign-off with a stored record.

Risk tolerances become configuration

This is where the ERP does the heaviest lifting. Tolerances agreed by management are entered as system parameters. Typical places include:

• Approval limits by role or cost center, routing larger items to more senior approvers.
• Matching tolerances between purchase order, receipt and invoice amounts, so small differences pass and large ones stop for review.
• Budget checks on defined segments of the chart of accounts, set to warn or to block when spending would exceed what is available.
• Spend limits on projects and cost centers, plus rules for closing them so nothing new posts afterwards.

Someone has to own each parameter. When a tolerance changes, the change should be approved and logged the same way a policy change would be.

Master data and ledger structure carry controls too

Supplier and customer records are a common fraud route, so creation and changes to them are usually restricted and reviewed. Bank detail changes in particular tend to need independent verification outside the system.

The general ledger structure matters as well. Account classifications, required attributes and segment validation rules decide what can be posted and how it can be reported. A loose chart of accounts makes detective controls harder, because reviewers cannot isolate the activity they need to look at.

Evidence for review and audit

Controls are only as good as the evidence behind them. Finance teams prepare process narratives, sometimes called cycle memos, that describe how each process runs and where controls sit. Auditors send prepared by client requests for reports, samples and configuration screenshots. Findings lead to documented adjustments and remediation plans.

System reports help here: change logs on configuration, user access listings and workflow approval histories. Teams that cannot pull these reports easily end up rebuilding evidence by hand each audit.

Questions to ask the people who run it

What is written down and what happens on a busy day often differ. Useful questions include:

• When an invoice fails a match, who actually releases it, and do they look at the reason?
• Has anyone been given extra access temporarily that was never removed?
• Which approvals happen by email outside the workflow, and why?
• If a budget check blocks a transaction, what is the usual workaround?
• Who can change a tolerance or approval limit, and when was one last changed?
• Which controls in the matrix does nobody recognise as part of their job?
• Where do reviewers tick a report as checked without opening the detail?
• How are supplier bank changes verified when the requester is in a hurry?

Where setups commonly drift

Drift usually starts with good intentions. A tolerance is widened during a system go-live to keep invoices flowing and never tightened again. A role is cloned for a new hire and inherits rights nobody reviewed. Budget checks get switched from blocking to warning because of one difficult month.

Reorganisations cause a different problem. Cost centers and approvers move, yet workflows still point at people who have left or at structures that no longer exist. Control owners named in the matrix may have changed jobs without anyone reassigning the control.

Before changing this process, compare the matrix, the configuration and the evidence side by side. Where the three disagree, the configuration usually tells the truth about what is enforced, and the people running the process tell the truth about what is done.

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.