Internal controls setup: what to automate and what stays human

Software already enforces spending limits, checks tolerances and assembles audit evidence. AI can draft procedures and map controls to risks. People must still form the board and audit committee, own the ethics code, assign accountability and set risk tolerance. None of it works until roles, accounts and control owners are recorded consistently.

Where software already carries the load

The most reliable automation sits inside the finance system itself. Funds control is the clearest case. Once the control structure is defined by organization, program, project or activity, the system can block an obligation or expenditure that would exceed what is available. It does this every time, without fatigue, and it leaves a record of each rejection.

Tolerance checks work the same way. The system compares obligations against commitments and expenditures against obligations. It flags any gap beyond the agreed amount. Nobody needs to eyeball these.

Cost center and project spend limits belong here too, as does the general ledger account structure. Configure them once and the system applies them on every posting. Changes to these rules should still go through an approval step, because a quietly edited rule is one of the easiest ways for a control to fail.

Audit support is the other strong area. Pulling sample transactions, attaching source documents and answering auditor requests for client-prepared listings is mostly retrieval. A well-configured tool can assemble that pack faster and more completely than a person working through shared drives.

Where AI is useful, with a reviewer

AI earns its place in the drafting work that surrounds controls. It can produce a first version of a cycle memo from system logs and interview notes. It can suggest which risks a process carries by reading its procedure documents. It can propose a mapping between existing controls and those risks, and point out risks that have no control at all.

It is also good at spotting conflicts in user access. Feed it role assignments and it will find people who can both create a payee and approve a payment to that payee.

Every one of these outputs needs a human reviewer. A draft memo can describe the documented process with confidence while missing the workaround everyone actually uses. A risk mapping can look complete and still miss the risk that matters most to this particular unit.

Decisions that belong to people

Governance cannot be delegated to a tool. Who sits on the board, who chairs the audit committee and how independent those members are: these are judgments about trust and accountability.

The code of ethics is similar. Software can host it, track acknowledgements and send reminders. Whether staff believe leadership means it depends on how leaders behave when a breach involves someone senior.

Assigning responsibility for each control is a management act. A name in a field means little unless that person has agreed to it and has the authority to act.

Risk tolerance is the hardest call. Deciding how much error, delay or loss a unit can accept involves weighing cost against exposure, and the answer shifts with strategy. A model can show the consequences of different thresholds. Choosing one is a leadership decision, and it should be written down with the reasoning behind it.

Findings from audits also need human interpretation. The tool can list adjustments. Someone must decide whether a finding points to a one-off mistake or a design flaw.

What has to be true about the data first

Automation amplifies whatever state the data is in. Before switching anything on, check these conditions.

The chart of accounts and cost center hierarchy must be consistent across units. If one division codes travel to a project and another to overhead, funds control will either block legitimate spending or let overspending through.

Tolerance amounts must live as parameters in the system. Too often they exist only in a supervisor's memory or an old email.

Every control needs a recorded owner, a description of what it prevents or detects, and the risk it addresses. Without that link, no tool can tell which risks are covered.

User access data must be current. Leavers who still hold approval rights will make any segregation analysis wrong.

Payee and payer master records need a single source and a clear change process, since so many controls depend on knowing exactly who is being paid or billed.

Finally, keep a history of exceptions and overrides. That history is what shows whether a control is working or merely present.

Questions to ask the people who run the process

Documented procedures describe intent. The people doing the work know what really happens. Ask them directly.

• When the system blocks a transaction, what happens next, and who usually clears it?
• Which approvals are given by email or in person and only recorded afterwards?
• Are there spreadsheets kept alongside the ledger to track limits or commitments?
• Who changes funds control rules or tolerance settings, and does anyone review the change?
• Which controls get skipped at period end when time is short?
• When an auditor asks for evidence, where does it actually come from?
• Does anyone hold access they no longer need, and would anyone notice?
• What would staff do if they saw a senior colleague break the ethics code?

The answers usually reveal a manual workaround or an undocumented owner. Fix those before automating, or the new system will faithfully enforce the wrong process.

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.