Operating and monitoring internal controls: what to automate and what to keep human

Software can run the control checks that compare one record against another, such as invoice matching, spending limits, reconciliations and access reviews. AI can sort exceptions and draft test evidence. A person must judge whether a failure is a deficiency and own the fix. Both depend on trusted source data.

Checks that software can run continuously

Any control expressed as a rule belongs in the system. Funds control is the clearest case. Once budget levels are set by organization, program or project, the ledger can block an obligation that would overspend an account. A person no longer has to remember to check the balance.

Tolerance tests also fit well. The system can confirm that an expenditure stays within the agreed tolerance of its obligation, and that the obligation stays within tolerance of its commitment. When the gap is too wide, the transaction stops.

Payment controls follow the same pattern. Matching an invoice to its order and its receiving record is mechanical work. So is holding a payment request that fails validation, netting a vendor's receivables against what is owed to it, and calculating a due date with any late payment interest. Duplicate payment scans run well after the fact as a detective layer.

Reconciliations are a strong candidate too. Cash recorded in the ledger can be compared line by line against the bank or treasury record, with unmatched items flagged. The same goes for payroll summaries against ledger postings, and for asset values in the subledger against the asset management system. Monitoring the age of receivables and undelivered orders is a report, not a judgement, and should be scheduled.

Control monitoring itself can be partly automated. Tools can pull the full population of transactions and test every one, which beats a sample when the rule is clear.

Where AI helps and where it misleads

Language models are useful for the paperwork around controls. They can draft cycle memos from walkthrough notes, assemble documents for auditor requests, and summarize why a batch of exceptions failed. They can also group unmatched reconciliation items by likely cause, which saves an analyst from reading each one cold.

The risk is confident error. A model will write a plausible narrative of a control that does not operate as described. Every AI draft of control documentation needs review by someone who has watched the control run. Treat model output as a starting point for testing. It is never evidence on its own.

Decisions that stay with a person

Deciding whether an exception is a control deficiency is a judgement. So is rating its severity and deciding whether compensating controls cover the gap. These calls carry accountability that auditors and management expect a named individual to hold.

Remediation needs people as well. Someone has to find the root cause, which is often a process design flaw or a training gap, and agree a fix with the process owner. The system can track the action. It cannot negotiate it.

Other calls also stay human: setting the tolerance levels in the first place, approving changes to funds control rules, deciding whether to refer a delinquent debt for legal action, and signing off on adjustments raised by audit findings. Approving exceptions to a hold should sit with someone who does not also enter transactions.

What the data must look like first

Automated controls fail quietly on bad master data. Before switching anything on, confirm the vendor file is free of duplicates and that bank details changes are logged with who made them. The chart of accounts and its attributes must map cleanly to reporting lines. Budget structures need to match how money is actually spent.

Approvals must leave a trace inside the system. An email approval that never reaches the ledger cannot be tested by software. User roles need to be current, since a segregation of duties check is only as good as the role table behind it.

Timing matters for reconciliations. Both sides of a match need consistent cut off dates and shared reference fields. Where the reference is free text, expect a long tail of manual matching until the field is standardized.

Finally, keep a record of every rule change. When a tolerance moves or a limit is lifted, the change log becomes part of the control evidence.

Questions for the people who run the controls

• When a payment is held, who actually releases it, and does that person check anything before doing so?
• Which control steps happen outside the system, in spreadsheets or inboxes?
• What exceptions get cleared routinely because everyone knows they are false alarms?
• Has any control been switched off or loosened during a busy close, and who decided?
• How are bank detail changes for vendors confirmed in practice?
• When an auditor asks for evidence, where does it come from, and how long does it take to assemble?
• Which reconciling items have sat open the longest, and why has nobody cleared them?
• Who fixes a deficiency once it is found, and how does anyone know the fix held?

The answers usually show a gap between the documented control and the operating one. Automate the operating one only after closing that gap.

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.