#
Internal Controls Automation
Most organizations have a control description for manual journal entries, postings to sensitive G/L accounts, critical master data changes, or late reversals. It identifies the objective, owner, frequency, and expected evidence. The more practical question is what actually happens each time the control is due to run.
It is the third business day after month-end. A controller exports the journal entry population from SAP, saves the report parameters, applies the required filters, and sends the spreadsheet to the reviewer. The review is completed on time. In many organizations, the reviewer then dates and signs off the review, converts the documentation into a PDF, attaches the supporting files, and stores the complete package in SharePoint or a GRC repository. The control has been performed correctly, but demonstrating this during control testing or an audit still depends on manually assembling and maintaining the evidence package. The control works; the operating model around it creates the effort.
In many teams, someone downloads a report, filters it in a spreadsheet, and sends it to a control owner. Questions and clarifications move back and forth by email. Screenshots, explanations, and approvals end up in different folders and repositories. The control exists, but its execution depends on a sequence of manual steps that varies by entity, period, and reviewer.
The Internal Control Execution Gap is the distance between a control that is documented and a control that is performed consistently, efficiently, and traceably.
Over the years, I have seen many well-designed controls struggle for a very ordinary reason: the process around them was too manual. The control description was not the problem. The way the control was executed was. Documentation alone does not close that gap.
Manual control processes are widely used and, when properly designed and performed, meet control and audit requirements. The challenge is the recurring effort required to execute and document the same control consistently across company codes, countries, shared service teams, and reporting periods. As the scope grows, so does the time needed to prepare data, coordinate reviews, and maintain supporting evidence.
Timing. Periodic reviews create a time gap between the underlying event and the related control activity. The longer the cycle, the longer the exposure window.
Consistency. Thresholds, review depth, and documentation vary across entities even when the formal control description is the same.
Evidence. A completed checklist or PDF shows that a review took place. It does not preserve the context the reviewer considered or the reasoning behind the decision.
Visibility. Management sees whether a task was completed, but not necessarily which exceptions remain open, who owns them, or whether the same issue keeps recurring.
In my work with Finance and Internal Controls teams, I keep seeing the same pattern: the control itself is well designed, but the operating model around it is too manual. More time is spent preparing evidence, following up with reviewers, and maintaining documentation. The effort increases, but the level of assurance does not increase at the same rate.
Most organizations already use valuable tools around the control process, and each of them solves a real part of the problem.
These tools are useful. They simply solve a different part of the problem. The gap appears when an exception is detected and someone has to understand the case, decide what to do, and leave a record another person can follow months later. When the work is split across reports, email, spreadsheets, and file repositories, context gets lost and the evidence trail becomes harder to follow.
Internal controls automation uses defined rules and control logic to analyze relevant business data, identify exceptions, and route them into a structured review process. Automated internal controls connect the control parameters, business context, reviewer activity, decision, and supporting evidence in one traceable control case.
Depending on the risk and the process, controls can run daily, weekly, monthly, or quarterly. Where the use case supports it, they can also form part of a continuous controls monitoring approach. Automation does not change why the control exists. It changes the work required to execute it.
Analyze. Defined logic evaluates the relevant transactions, master data, or activity continuously or on a risk-appropriate schedule.
Detect. Deviations from a threshold, policy, or expected pattern create an alert rather than an unstructured report line.
Review. The responsible person receives the business context needed to assess the case: documents, amounts, users, timestamps, and before-and-after values.
Decide and follow up. Reviewers record their assessment, request clarification, escalate, approve, or initiate remediation.
Retain evidence. Each alert provides an end-to-end record of the control case, including the control parameters applied, the relevant business context, review activity, the decision, timestamps, and supporting documentation.
Reviewers still make the judgment call. Much of the surrounding work is reduced: collecting data, preparing files, following up on responses by email, and rebuilding the evidence trail for the audit.
Non-SOX environment. A monthly journal entry review relies heavily on the experience of the reviewer. Someone extracts the postings, filters for the accounts in scope, selects entries that appear unusual, and documents the assessment in a spreadsheet. The review itself can be thorough. What is rarely retained in a consistent format are the report parameters, exclusions, and rationale behind individual selections. When Internal Audit or the external auditor asks about the population or selection months later, parts of the process have to be reconstructed from files and individual knowledge.
SOX-regulated environment. When included in the SOX scope, a journal entry review forms part of internal control over financial reporting (ICFR). The process is subject to more formal and detailed documentation requirements. The team must retain evidence of how the report was generated, which selection parameters were used, how the completeness and accuracy of the report used in the control were validated, which entries were selected, and how the reviewer documented the conclusion. The problem is not missing documentation. It is the recurring effort required to generate, validate, cross-reference, and retain the report, parameter evidence, review file, and supporting documentation across every control cycle and entity.
Automated execution. The population, parameters, and selection logic are defined as part of the control design and remain connected to the resulting exceptions. Depending on the objective, the control evaluates a complete population or applies a defined, structured selection. Each alert carries the relevant posting, user, timestamp, and account context, and the reviewer decision remains attached to the case.
The benefit differs by environment. Teams without SOX-specific documentation requirements gain a more repeatable and traceable operating model. SOX-regulated teams reduce the recurring work of preparing and linking report execution evidence, parameter documentation, population validation, selection rationale, and reviewer documentation.
The control objective is unchanged. What changes is that the execution, selection, and evidence are repeatable, retrievable, and defensible.
Automation is not successful simply because a rule or algorithm runs and produces alerts. A control also needs relevant thresholds, clear ownership, and sufficient capacity to review and resolve the resulting cases.
A control producing 60 relevant cases a month gets reviewed. The same control producing 600 gets ignored, even when every case is technically correct. An unattended alert is not evidence that a control is operating. It can create a false sense of coverage because the risk is detected but never assessed.
Automation is the wrong starting point when the control objective is unclear, the underlying data is unreliable, no one owns the exceptions, or the organization cannot manage the findings. Those issues must be resolved as part of the control design.
For organizations using SAP, continuous controls monitoring keeps the analysis close to the operational environment, where the relevant transactions, master data, change documents, authorizations, and document flow already exist. This reduces handoffs and lets reviewers investigate an exception without rebuilding the case in a separate workspace.
remQ is deployed as an SAP add-on. It executes control logic, alerts, reviews, and evidence management within the existing SAP environment, without requiring a separate application platform or middleware. It uses the existing SAP authorization and transport model, with remQ-specific authorizations assigned to the relevant users.
A second example involved one of the most common controls in Finance: the review of vendor bank master data changes. The organization had introduced a formal approval process for requested changes across its global operations.
Some time after the process had been implemented, Internal Audit identified a critical gap. The changes had been approved, but no control verified whether the bank details ultimately recorded in SAP matched the approved request. The approval process was in place. The verification in the system of record was not.
The finding led to significant internal and external effort to investigate previous changes and strengthen the control process. The underlying check was straightforward, but the missing verification step had remained undetected.
An approved request is not evidence that the approved value is the value recorded in SAP.
In this case, remQ provided the missing control step. As an SAP add-on, it identifies bank master data changes after they have been recorded in SAP and routes them to the responsible reviewer for verification and documentation. The review therefore focuses on what was actually changed in SAP, rather than only on what had previously been requested or approved.
Uncomfortable answers do not mean the control objective is wrong. They point to an operating model that needs redesign.
There is no need to automate an entire control framework at once. Good first candidates combine a material risk, recurring manual effort, reliable data, repeatable logic, and a clear owner for exception review.
Start with a small set. Measure whether the expected cases are identified, refine the parameters with the reviewers, and document the reduction in recurring manual effort. Once the operating model works, extend it across entities and processes.
Internal controls automation should be implemented as a change to the existing control process, not as a separate technical exercise. A 90-day plan provides a practical structure for moving priority controls from agreed design through testing and into production while keeping control owners and reviewers involved throughout.
Days 1-30: Select the controls for the first wave. Confirm the control objectives, scope, parameters, owners, and review responsibilities.
Days 31-60: Configure the controls and run the initial tests in SAP using the relevant business data. Compare the results with the existing control process, verify that the expected cases are identified, and refine thresholds, exclusions, parameters, and responsibilities where necessary.
Days 61-90: Complete user acceptance testing and approve the controls for production use. Depending on the customer’s governance model, involve Internal Controls, Internal Audit, or both early enough to review the implementation approach and build acceptance before go-live.
The objective of the first 90 days is not to automate as many controls as possible. It is to establish a tested, repeatable, and clearly owned control operating model that improves coverage and reduces recurring manual effort.
In an implementation running in 2026, Finance led an initiative to automate parts of the internal control system after recurring accounting issues and observations by Internal Audit and the external auditor showed that the existing control operating model needed to be strengthened. The organization activated five ready-to-use controls and commissioned around twenty additional controls because its processes differed from a standard corporate setup. It also replaced several controls that had previously been developed separately in SAP. The aim was to create one consistent system for control execution, review, and documentation instead of maintaining a growing number of isolated solutions. The controls now run automatically on defined schedules, and responsible reviewers assess and document the resulting exceptions.
The organization did not commission the additional controls simply to build a larger catalog. Several checks had not been performed before because extracting and combining the data manually was not practical. Other controls already existed, but as separate SAP developments with their own processes and documentation.
Bringing these controls into one platform expanded the organization’s control coverage and replaced separate solutions with a consistent way to run, review, and document controls.
A ready-to-use control library speeds up the start. It should not dictate the final design. The controls still have to reflect the organization’s actual risks, processes, and responsibilities.
Internal controls automation moves recurring work such as data extraction, exception identification, review, and evidence preparation into a defined system process. Reviewers still make the decisions, but they no longer have to rebuild the control from reports, spreadsheets, and emails every time it is performed.
No. Automation identifies and organizes exceptions. Responsible reviewers still assess the business context, decide on follow-up, and document their reasoning.
The best candidates are recurring controls that use structured data, follow clear rules, and require substantial manual effort. They also need an owner who can review the exceptions and act on the findings.
Yes. Some checks are skipped because extracting and combining the underlying data manually is not practical, not because the risk is considered acceptable. Automating the data work can make those controls feasible for the first time.
remQ retains alerts, the control parameters applied, reviewer decisions, comments, timestamps, and supporting documentation as part of the control case. This reduces the need to assemble or reconstruct evidence after the review.
Next step: Watch the six-minute remQ demo.
Hast Du Fragen oder möchtest Du etwas hinzufügen? Hinterlasse uns bitte eine Nachricht! Deine Nachricht wird per E-Mail an uns übermittelt und nicht veröffentlicht.
.png)
