How internal controls compliance reporting is set up in finance and ERP systems

In most organisations, internal controls reporting sits partly in the ERP and partly beside it. The ERP holds transactions and their approval trails. A separate governance tool, or a set of spreadsheets, holds the control library alongside test evidence and open deficiencies, and every report draws from both.

Where the underlying evidence lives

The ERP is the source for anything automated. Approval workflows, posting restrictions, segregation of duties rules and system matching all leave records there. In purchasing, for example, the match between order, receipt and invoice is configured once and then logged on every document. Payment runs carry their own audit trail of who released them.

In public sector and grant funded settings, funds control is often the most heavily configured control in the system. Budget checking against organisation, program or project segments blocks or flags spending beyond authorised amounts. The rules for those checks are maintained as master data, and changes to them need their own approval record.

Manual controls live elsewhere. Reconciliations, review sign offs and management checks are usually evidenced in a close management tool, a document repository or a shared drive. This split matters. Reports that look complete often rest on a mix of system logs and attachments that nobody has tied together.

How the control library is structured

Most setups keep a register of controls mapped to risks, processes and owners. Each control has a description, a frequency, a type and a link to the accounts or assertions it protects. Cycle memos or process narratives sit next to the register and explain how a transaction flows from start to finish.

Testing is recorded against each control for a period. A tester selects samples, attaches evidence and records a conclusion. Failures become deficiencies with a severity rating, an owner and a remediation date. The deficiency log is the single most important input to every external report.

Reporting to external auditors

Auditors receive a request list, often called prepared by client or PBC items. Finance teams track these in the controls tool or in a shared tracker with due dates and owners. Typical requests include walkthrough documentation, population listings, sample support and system reports showing configuration.

Population listings are where ERP setup counts. Auditors want to know that a report extract is complete and accurate, so the query behind it should be saved, version controlled and rerunnable. After fieldwork, audit findings come back and any adjustments they require are documented and posted through normal journal approval.

Reporting to regulators, investors and exchanges

Formal assertions on control effectiveness are usually drafted by the controller's or reporting team and reviewed by legal and the audit committee. The content comes from the deficiency log, aggregated and assessed for severity. Little of this is produced by the ERP directly. It is typically assembled in the disclosure management or financial reporting tool alongside the statements themselves.

Government bodies add their own layer. Receivable and delinquent debt reports to central treasury functions, along with cost reports by program, often carry implicit control assertions about the data. Those feeds should be traced back to reconciled ledger balances before submission.

Reporting to other third parties

Lenders, customers, grantors and outsourcing partners sometimes ask for control attestations or questionnaires. These are commonly handled ad hoc by whoever owns the relationship. A better setup routes them through the controls team so answers match what has been told to auditors and regulators.

Where the organisation itself relies on a service provider, the provider's assurance reports are logged and the complementary controls they list are mapped into the register.

Reporting to internal management

Management and the audit committee usually see a dashboard: testing progress, open deficiencies by severity and overdue remediation. In mature setups this is drawn straight from the controls tool. In others, someone rebuilds it by hand each quarter, which is where errors creep in.

Questions to ask the people who run it

• When a control fails testing, what actually happens next, and who hears about it first?
• Which reports to auditors are rerun from a saved query, and which are rebuilt from scratch each time?
• Are any automated controls switched off or bypassed during close or system upgrades?
• Who can change funds control rules or approval limits, and is that change itself reviewed?
• How are third party questionnaires answered today, and does anyone check them against the deficiency log?
• Which manual controls are documented but no longer performed the way the narrative describes?
• Where does the management dashboard come from, and how long has it matched the underlying tool?

Where setups commonly fall short

The most frequent gap is the link between the ERP and the control register. Configuration changes happen in the system without anyone updating the control description, so testing checks something that no longer exists.

A second weakness is evidence scattered across personal folders. When a key preparer leaves, the trail goes with them.

Finally, external and internal reports are often prepared by different people from different snapshots of the deficiency log. Aligning them to one cut off date, owned by one team, removes much of the rework that surrounds each reporting cycle.

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.