How internal control operation and monitoring is set up in finance and ERP systems

Most finance teams run internal controls as a mix of rules configured inside the ERP and checks performed by people around it. The system blocks or flags transactions automatically. Staff review reports, sign off reconciliations and test samples. A separate owner tracks deficiencies until they are fixed.

Controls built into the system

The strongest controls are the ones the software enforces without anyone remembering to do them. Typical examples sit in purchasing and payables. An invoice is matched against the purchase order and the receiving record. Tolerance amounts define how far they can differ before the invoice stops. Anything that fails validation lands in a hold queue and cannot be paid until someone with authority releases it.

Budget checking works the same way. The ledger is set up with a control structure, usually by organization, project or program. Each transaction is checked against what remains available for that segment, and the system either warns or refuses the posting. Public sector bodies often run this as a hard stop tied to legal limits on spending.

Other configured controls are quieter. Role design keeps one user from creating a vendor and paying it. Approval workflows route entries above a threshold to a manager. Closed periods refuse new postings. Account attributes restrict which cost centres or funds a given account can be combined with.

Controls run by people

Some checks need judgment, so they stay manual even in a well configured system. Reconciliations are the main group. Bank balances are agreed to the ledger. Payroll summaries from the payroll system are agreed to what was posted. Fixed asset registers are compared with ledger balances, and subledgers are tied to control accounts.

Reviews make up the rest. A controller scans manual journals. Credit staff look at receivable ageing and decide which debts to chase or refer for collection. A security administrator confirms that user access still matches each person's job. The evidence for these usually lives in a reconciliation tool, a governance module or, in many teams, shared spreadsheets with sign off columns.

How monitoring is organized

Everything hangs off a control matrix. Each line names the risk, the control, its owner, how frequently it runs and what evidence proves it ran. Process narratives, sometimes called cycle memos, describe the flow around each control so a tester can follow it.

Testing happens in layers. Owners often self assess first. An internal control team or internal audit then picks samples and inspects the evidence independently. External auditors later request much of the same material, so teams that store evidence cleanly as they go have an easier year end.

System reports feed the monitoring too. Useful ones show changes to tolerance settings, users holding conflicting roles, holds released without comment and postings made with elevated access.

When a control fails

A failed test becomes a logged deficiency. It gets a severity rating, a root cause and a remediation plan with a named owner. The fix might be a configuration change, a rewritten procedure or simply training. If the failure let an error through, an adjusting entry is recorded and documented for the auditors.

The item is not closed when the fix is made. It is closed after the control has operated again and passed a retest.

Where documented design and daily practice drift apart

Gaps tend to appear in familiar places. Tolerances get widened during a busy close and never narrowed. Approval rights are delegated to whoever is available. Hold queues are cleared in bulk to hit a payment run. Reconciliations are signed by the preparer with no reviewer. Emergency access granted for a project stays in place. Payments made outside the system skip every configured check.

Questions to ask the people who run the process

• Which tolerance and approval settings have been changed since the matrix was last updated, and who approved the change?
• Who releases items from the payment hold queue, and are any released without investigating the cause?
• Are there payments or journals that bypass the ERP, such as urgent wires or uploads from spreadsheets?
• When a reconciliation has an unexplained difference, what actually happens to it?
• Which controls are performed by a single person with no backup when that person is away?
• Does the evidence kept today match what the control description says is kept?
• Which open deficiencies have remediation plans that have quietly stalled?

Before changing the process

Map every control that touches the step being redesigned. A new workflow, a migrated vendor master or a simplified approval chain can switch off a preventive control without anyone noticing. Agree the replacement with the control owner, update the matrix and narratives, and let the auditors know early so their testing reflects the new design.

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.