A solution can detect the right exception and still leave the team with an inefficient control process. The problem is often not the rule itself. It is the architecture around it.
SAP data is copied into another platform. Reviewers return to SAP because the alert does not contain enough business context. Decisions are recorded somewhere else, and the final evidence is stored in a separate repository. Detection is automated, but the process surrounding it remains fragmented.
In architecture discussions, control libraries and dashboards often receive attention before anyone asks who will maintain the interfaces, where reviewers will find the missing context, or where the official control record will be retained. Those questions matter because architecture determines data freshness, security, access, review effort, and the work that remains after go-live.
Continuous controls monitoring is one part of a broader internal controls automation model. It uses defined rules and scheduled or ongoing analysis to identify exceptions closer to the underlying business event. It does not necessarily mean real-time monitoring. The right frequency depends on the risk, data volume, control logic, and the organization’s ability to investigate and resolve the cases generated.
Monitoring finds the case. The operating model determines what happens next: investigation, review, decision, follow-up, documentation, and evidence.
The following five questions help Finance, Internal Controls, Internal Audit, and SAP teams look beyond the feature list and assess the architecture behind continuous controls monitoring software.
Start by asking where the rule actually runs.
The logic can execute directly within SAP, on data replicated to another environment, or in a separate application that connects to SAP through APIs, interfaces, or connectors. Each model supports valid use cases. The location of the logic still affects timing, integration effort, access management, and the business context available during review.
A reviewer rarely needs only the field that triggered an exception. The investigation may also require the original document, related line items, change history, user details, timestamps, organizational information, and supporting documentation.
Where the rule runs is therefore not a technical footnote. It determines how easily the reviewer can understand the case and make a defensible decision.
A periodic completeness review may work well on a defined schedule. A time-sensitive activity may need to run more frequently. The architecture has to support both the intended frequency and the full review process.
Where the control logic runs in SAP, teams should also ask how data volume, job scheduling, parallel processing, and production-system load are managed. An embedded approach avoids data replication, but the controls still need to be designed and scheduled so that they do not interfere with operational processing. External architectures do not remove this question entirely, because extraction jobs can also place load on the source system.
A monitoring solution can read data directly within SAP, replicate selected data to another environment, or retrieve information through APIs, interfaces, and integration services.
Replication and integration are legitimate design choices, but neither is operationally neutral.
One common approach in SAP environments is to replicate data through an extractor that connects to SAP by RFC. This is a well-established mechanism, but it introduces its own operating and authorization questions.
The connection requires a technical user with the necessary RFC and data-access authorizations. Where the same connection supports several extractions, the user may need access to a broader set of functions or tables than any individual control requires. Generic table extraction may also not apply the same application-level authorization checks and business logic as the SAP transactions or applications through which users normally access the data. It is therefore worth asking who owns the technical user, how its authorizations are scoped and reviewed, and how failed, delayed, or incomplete extractions are detected before the control result is used.
Data and security. What data is transferred or exposed? Does the solution receive complete records or selected fields? Where is the data stored, how is it encrypted, who can access it, and how are retention and deletion handled?
Integration and reliability. How current is the data? How are failed, delayed, duplicated, or incomplete transfers detected? Who manages service accounts, credentials, certificates, API permissions, rate limits, interface versions, and error handling?
Cost and ownership. Which middleware, API gateways, connectors, network changes, cloud services, or other infrastructure are required? Who monitors the interfaces and supports them after go-live? Which additional licensing, security-review, and operating costs arise?
APIs can reduce the need to copy large volumes of data, but they still create dependencies. Availability, permissions, authentication, version changes, and error handling become part of the control operating model.
Every additional integration point is another component that has to be governed and monitored. This is not an argument against replicated or API-based architectures. It is a reason to understand the complete operating model before selecting one.
A notification is not the control case. It only tells someone that there is something to review.
The reviewer still needs the relevant business context, a clear responsibility, a status, a place to record comments and decisions, timestamps, follow-up activities, and supporting documentation.
When an exception is detected in one system, reviewed in another, and supported by evidence stored in a separate repository, the organization recreates much of the manual process it intended to remove.
A workable architecture connects detection, review, decision, follow-up, and evidence. A control owner or auditor should be able to revisit the case later and understand what happened without reconstructing the sequence from emails, screenshots, notifications, and disconnected files.
Controls often depend on company codes, business units, process ownership, local responsibilities, review permissions, and access restrictions.
A global organization may use one control objective while individual entities apply different thresholds, schedules, reviewers, or exclusions. The architecture should support that model without creating a parallel organizational and authorization structure that has to be maintained separately.
Where a separate platform is involved, teams should ask how users, role changes, substitutions, leavers, company-code restrictions, and review responsibilities are synchronized with SAP and the organization’s identity-management processes. Single sign-on helps, but the more important question is whether the authorization model remains understandable, maintainable, and auditable.
Continuous controls monitoring initiatives sometimes start in Internal Audit. That can be a useful catalyst because Internal Audit sees recurring issues across processes and has a strong interest in identifying risks earlier. The long-term operating model still needs to be agreed before go-live.
Where the exceptions relate to controls owned by Finance or another business function, the process owner normally needs to own the control objective, parameters, review, and follow-up. Internal Controls or Compliance can define standards and support consistent implementation. SAP or IT operates the technical environment. Internal Audit can initiate the discussion, challenge the design, use the results in audit work, or independently assess the control.
The exact allocation depends on the organization’s governance model. What matters is that ownership is accepted before the first control cases are generated. A technically functioning control without a clear business owner is not a sustainable operating model.
The software license is only one part of the operating model.
A solution may also require a separate application platform, database, cloud tenant, middleware, API gateway, connectors, service accounts, monitoring tools, backups, patching, upgrades, and dedicated support responsibilities.
Ask the vendor to describe the model in practical terms. Who configures the controls and changes the parameters? Who manages users and authorizations? Who monitors failed jobs and interfaces? Who renews certificates and rotates credentials? What happens when a connected system or API is unavailable? How are upgrades coordinated when SAP, the middleware, or the monitoring platform changes?
A lower initial software price can still lead to a more expensive and complex operating model when several integrations and parallel workflows have to be maintained.
The relevant question in an evaluation is therefore not simply whether an integration is technically feasible. It is who builds it, who secures and operates it, how failures are monitored, and what additional responsibilities it adds to the control operating model.
Let’s chat and find the best strategy for yourbusiness! It’s about individual expert advice tailored to your business needs. Tools are only as good as their application. We don’t leave you alone with your solutions, we help you get the most out of them.
I have come across this type of case more than once. An FI document is posted and later reversed by the same user after a defined number of days.
A separate monitoring or analytics platform detects the case and displays the document number, amount, posting date, and reversal date. That is enough to flag the exception, but not enough to review it.
The reviewer also needs the original and reversal documents, line items, posting and reversal users, timestamps, reversal reason, company code, period status, and related supporting documentation.
If that information was not transferred, the reviewer has to return to SAP and reconstruct the business context. If it is extracted through an API, the review depends on the interface being available and on the reviewer having the appropriate access rights.
This is a familiar challenge in data analytics more broadly: the analysis identifies the exception, but the reviewer still has to return to the source system to understand what actually happened.
The detection is correct. The architecture still determines how much work is required to understand the case, document the decision, and retain the evidence.
For that reason, a solution demonstration should show the complete journey from the original SAP event to the final control record, not only the exception list.
A workable architecture should provide:
The best architecture is not necessarily the one with the longest feature list. It is the one that keeps the complete control process understandable, secure, auditable, and manageable after go-live.
An SAP-embedded approach is not limited to processes that begin in SAP. Many upstream and subsidiary systems transfer accounting-relevant transactions, postings, or master data to SAP. Where the information required for the control is available in SAP, remQ can assess the resulting transaction even when the process started elsewhere.
Additional integration is needed when material process steps, approvals, or risk-relevant information remain exclusively outside SAP and are not otherwise made available to the control. In that situation, remQ can assess what is visible in SAP, but it cannot evaluate the complete end-to-end process without access to the missing information.
For example, a procurement platform may manage the request and approval process while the resulting invoice is posted in SAP. remQ can assess the invoice and posting data available in SAP. If the approval information remains only in the procurement platform, that information must be made available through an interface when it is required for the control.
Organizations with several ERP systems or controls that depend heavily on data held outside SAP may therefore require additional integrations or a system-independent monitoring layer. The right architecture depends less on where a process starts and more on where the information needed for the control is available.
remQ supports continuous controls monitoring as part of a broader internal controls automation model. It is deployed as an SAP add-on and executes its core control logic within the customer’s existing SAP environment. For the core control execution and review process, it does not require a separate application platform, data replication, or an API-based integration layer. It also uses the existing SAP authorization and transport model and provides more than 120 ready-to-use controls, together with the option to implement customer-specific control logic.
Because remQ runs natively in SAP, integrations can build on the mechanisms available in the customer’s SAP landscape. A separate integration platform is not required for the control itself, although existing middleware can be used where it is already part of the customer’s architecture. Outbound calls to external services and interfaces to downstream systems are both possible, and both have been implemented in customer environments.
Sanctions screening is one example. It is offered as a separately licensed module built on remQ because it relies on an external screening service and API usage. The control runs in SAP, the limited identifying information required for the screening is transmitted to the external provider, and the result is returned to remQ for further processing.
Integration also works in the other direction. In one implementation, every remQ alert created a corresponding ticket in the customer’s ticketing system and transferred the relevant information, allowing the case to enter the organization’s existing follow-up process. The official control record, including the review, decision, and evidence, remained in SAP. The same integration capabilities can be used where other external information is required or where control results need to be passed to downstream systems. The design depends on the information required by the control and the customer’s existing SAP and integration architecture.
remQ: Controls | Compliance | Monitoring provides comprehensive business transaction monitoring, internal controls automation, and compliance management.
.png)
No. Some controls run frequently, while others are more appropriate on a daily, weekly, monthly, or quarterly schedule. The frequency should reflect the risk, data volume, processing time, and timing of the related business process.
No. Some solutions execute within SAP, while others use replicated data or connect through APIs and interfaces. The important point is to understand how the selected approach affects data freshness, security, infrastructure, integration, review context, and operating responsibility.
An RFC-based extraction requires a technical user with the necessary RFC and data-access authorizations. The scope, ownership, and periodic review of those authorizations therefore become part of the control environment. Organizations should also define how failed, delayed, or incomplete extractions are identified before the resulting control information is relied on.
Any analysis consumes resources in the system where it runs. The relevant factors are the data volume a control reads, its frequency, and its scheduling. Controls are typically planned together with the teams responsible for system operations, in the same way as other scheduled jobs.
Next step: Use these five questions during your next solution evaluation, or schedule an architecture discussion with VOQUZ Labs.
