SAP S/4HANA Audit Modernization

Detection speed

Real-time

From periodic to continuous

Entry point

Native capability

No new license required to start

BIS start

3 to 5 rules

Before scaling the deployment

Reading time

30 min

SAP S/4HANA reference environment

This page addresses S/4HANA-specific capabilities: Fiori, BIS, and the GRC suite. The monitoring workflow and the automation principle described here apply in any ERP environment. Specific tool names and configuration paths are SAP-specific. Oracle and Microsoft Dynamics environments have equivalent capabilities under different names.

What Changes With S/4HANA

Three dimensions of change that directly affect what audit can do and what it needs to do differently.

Data Architecture

In-memory processing and the Universal Journal

S/4HANA's HANA in-memory database processes transactions in real time rather than batch. The Universal Journal (ACDOCA) consolidates what were previously separate FI and CO tables into a single document-level record. This means audit can query the complete financial transaction record -- including cost object, profit center, and business area -- from a single table. Fiori provides the browser-based interface to that data without ABAP development. Embedded analytics deliver the analytical layer directly in the system.

Monitoring Possibilities

Real-time GRC, native BIS, and direct data access

The architecture change enables monitoring that ECC could not support at scale. GRC runs SoD and access monitoring in real time rather than in scheduled batch jobs. BIS applies machine learning to transaction data continuously rather than on an extraction cycle. Fiori provides direct access to validated data models without extraction, transformation, and load overhead. The latency between a transaction occurring and audit being able to see it compresses from weeks to hours or minutes.

Audit Requirements

New skills, new access patterns, new scope areas

The same architecture that enables continuous monitoring also requires audit to understand the new data structures. ACDOCA replaces BSEG and BSAK as the primary financial document table. MSEG and EKBE remain for logistics, but their relationship to ACDOCA creates new cross-module query patterns. Audit functions that learned SAP against ECC data structures need to re-map their query logic. Functions that had no direct data access before are learning both the tool and the data structure simultaneously.

The Monitoring Workflow

Four steps that define how continuous monitoring operates -- from data access through exception closure.

Step 1

Configure Data Access

Establish read-only audit access to the relevant Fiori apps and underlying data models. Confirm which tables are accessible through which apps. Document the access pathway -- which role grants access, what data model it reads, and who the data owner is. Validate that the data model returns complete results by reconciling a sample query against a known transaction. Data access that has not been validated is not reliable evidence.

Configuration decisions

Identify the Fiori apps relevant to the target process area -- AP monitoring starts with F0718 (Manage Journal Entries) and the Supplier Invoice List app.
Confirm read-only authorization: F-KO (display vendor documents), F-LF (display accounts payable), and BSEG/BKPF display access at minimum.
Validate completeness: run a population query for the last completed period and reconcile the count to the GL account balance. If counts do not reconcile, escalate before building monitoring logic on top of incomplete data.

Step 2

Define Detection Rules and Thresholds

Write the detection logic before building any query or rule. What condition is being detected? What data field identifies it? What threshold makes an exception actionable rather than noise? Who owns the exception when it fires? What does resolution look like? These questions must be answered on paper before the first BIS rule or Fiori query is configured. Detection logic written without threshold definition produces either too many exceptions to review or too few to be useful.

Threshold design principles

Set thresholds based on the prior period distribution of the underlying metric -- not on an arbitrary dollar amount or percentage. A threshold that works for a $50M AP ledger will not work for a $500M one.
Test the threshold against historical data before going live. Count how many exceptions the rule would have generated in the last six months. If it is more than the team can review in a week, tighten the threshold or add a secondary filter.
Document the threshold and the rationale in the monitoring program file. Thresholds that are not documented will be forgotten and cannot be defended.

Step 3

Review Exceptions and Escalate

Exception review is where audit judgment is applied. Each exception requires a human decision: is this a finding, a false positive, or a known condition that has been documented and accepted? The review workflow needs to be defined before monitoring goes live -- not improvised after the first exception list appears. A well-designed exception review workflow closes most items in the first review cycle. Items that cannot be closed require escalation with a documented reason.

Review workflow design

Assign a primary reviewer and a backup for each monitoring routine. If only one person can review exceptions, the routine stops when that person is unavailable.
Define the escalation trigger explicitly: what makes an exception a finding rather than a false positive? Document this threshold in the monitoring program file so any reviewer can apply it consistently.
Set a maximum review cycle length -- typically one to two weeks for most routines. Exceptions that age beyond the review cycle without disposition are a workflow failure, not a finding volume problem.

Step 4

Close and Document

Every exception must have a documented disposition: false positive, finding escalated, finding closed by management, or accepted risk with documented rationale. This documentation serves two purposes. First, it demonstrates that the monitoring routine is being operated with discipline -- not generating lists that no one reviews. Second, it builds the evidence base for the next threshold adjustment cycle.

Documentation standard

Use a consistent format for exception disposition: exception ID, detection date, reviewer, disposition category, disposition date, and notes. A spreadsheet works at early stages. A ticketing system is better as volume grows.
Review the false positive rate at the end of each quarter. A false positive rate above 40 percent means the threshold needs to be tightened. A rate below 5 percent may mean the threshold is too narrow to catch real exceptions.
Document findings separately from false positives and use the finding record to feed the annual audit risk assessment. Monitoring findings are evidence of where control gaps actually exist -- not just where they might exist.

Fiori for Audit

The Fiori apps relevant to audit work, what they access, and how to configure a monitoring workspace without IT development.

Fiori is the browser-based interface layer for S/4HANA. For audit, the relevant apps are the ones that provide read access to transaction data -- the AP, GL, purchasing, and inventory apps that surface the population-level data underlying each use case in the audit universe. The key distinction is between analytical apps (which display aggregated data) and factsheet and list apps (which display transaction-level records).

Audit-relevant Fiori apps do not require custom development. They require role configuration -- specifically, the addition of appropriate read-only business roles to the audit user's profile. This is an IT configuration task, not a development task. The conversation with IT is about role assignment, not about building anything new. Most of the apps described below are standard Fiori apps delivered with S/4HANA and activated as part of the standard implementation.

Financial Accounting

Key Fiori Apps for FI Audit

Manage Journal Entries (F0718): full journal entry population with filter by user, posting date, document type, and amount. Supplier Invoice List: AP invoice population with vendor, date, amount, and payment status. Customer Invoice List: AR invoice population. G/L Account Line Items: general ledger transaction detail by account. These four apps cover the primary FI use cases without any custom configuration.

Procurement

Key Fiori Apps for MM Audit

Manage Purchase Orders: full PO population with status, vendor, amount, and approval history. Manage Supplier Invoices: invoice population with three-way match status. Goods Receipt / Invoice Receipt Account: GR/IR clearing balances. Vendor Master: vendor record population with bank account details. These apps provide the data foundation for the MM use cases in the audit universe without extraction.

Sales

Key Fiori Apps for SD Audit

Sales Order Fulfillment: order-to-delivery pipeline with exception highlighting for blocked and delayed orders. Display Billing Documents: invoice population with pricing condition detail. Credit Management Overview: customer credit status, exposure, and override history. Manage Customer Returns: return authorization and credit memo population. These apps surface the pricing and credit risk use cases from the SD section of the audit universe.

Configuring the Workspace

Building a Monitoring Launchpad

Fiori allows creating a custom launchpad group -- a collection of tiles organized by monitoring area. For audit, a launchpad with AP, GL, Procurement, and SD tiles provides a single starting point for all routine monitoring work. The launchpad requires no development -- only the addition of the relevant tile catalog entries to the audit user's role. Once configured, any auditor with the appropriate role can access the full monitoring workspace from the same starting point.

BIS in Practice

Business Integrity Screening -- what it does, how rules are configured, what the exception workflow looks like, and why starting with three to five rules is the right approach.

BIS is SAP's native anomaly detection module. It runs continuously against transaction data using configurable detection rules and machine learning models. Unlike Fiori, which requires an analyst to run a query, BIS runs on a schedule and delivers exceptions to a review queue automatically. The analyst reviews what BIS surfaces rather than running queries to surface it.

BIS is frequently licensed as part of S/4HANA and not activated. Activation requires IT to configure the BIS system connection, define the data scope (which company codes, which transaction types), and set up the alert queue. This is a configuration task measured in days, not a development project measured in months. The question to ask IT is whether BIS is licensed -- not whether it can be configured.

Rule Categories

What BIS Detects Natively

BIS ships with pre-built detection rules across the primary financial process areas: accounts payable (duplicate invoices, vendor with employee data matches, payments to inactive vendors), procurement (POs created after invoice, split PO sequences), general ledger (round-number entries, off-hours postings, entries by users without typical GL access), and accounts receivable (write-offs above threshold, credit memos without returns). Most audit-relevant use cases in FI and MM have a corresponding native BIS rule that requires configuration rather than development.

Starting Small

Three to Five Rules Before Scaling

The right BIS deployment starts with three to five rules in the highest-risk area -- typically AP or procurement -- and runs them for a full quarter before expanding. This approach establishes the exception review workflow, calibrates the threshold settings, trains the reviewer on BIS output format, and produces a documented track record of findings before the scope increases. Deploying twenty rules in the first quarter almost always produces an exception volume that overwhelms the review workflow and results in exceptions aging without disposition.

Machine Learning Layer

How BIS Uses ML to Reduce Noise

BIS includes a machine learning layer that learns the normal transaction pattern for each entity -- each vendor, each user, each cost center -- and scores deviations from that pattern. This produces entity-level anomaly scores rather than simple rule-based flags. An AP posting by a user who has never posted to a particular vendor before scores higher than the same posting by a user who posts to that vendor weekly. The ML layer reduces false positives as the model learns the organization's baseline -- which is why the first quarter of BIS operation typically produces more noise than subsequent quarters.

Exception Queue

What the BIS Workflow Looks Like

BIS delivers exceptions to a managed alert queue in the SAP system. The reviewer accesses the queue through a Fiori app, reviews each alert with a link to the underlying transaction, applies a disposition (finding, false positive, or accepted risk), and documents the rationale. The queue tracks aging, so exceptions that are not reviewed within the defined period are visible to the audit manager. The workflow runs entirely within the SAP system -- no external tracking spreadsheet is required if the Fiori exception management app is configured.

The Automation Principle

Continuous monitoring does not replace audit judgment. It changes what audit judgment is applied to. In a manual testing environment, audit judgment is applied at every step: which vendors to test, which invoices to pull, which transactions to examine. Most of that judgment is spent on selection rather than on evaluation.

In a monitoring environment, the selection problem is addressed by the detection rule. BIS identifies which transactions meet the anomaly criteria. The auditor applies judgment to the exception list: is this a finding? Is it a known condition that has been documented? Is it a false positive that suggests the rule threshold needs adjustment? The judgment is the same quality -- it is applied to a much better-curated set of transactions.

This distinction matters for two reasons. First, it addresses the concern that monitoring is auditing by algorithm -- that it removes professional judgment from the process. It does not. It compresses the time spent on selection and expands the time available for evaluation. Second, it defines what a monitoring program needs to produce: not a list of anomalies, but a list of anomalies that has been reviewed by a person who applied a documented judgment standard to each one.

A monitoring program that generates exceptions no one reviews is not continuous monitoring. It is a scheduled query that generates unanswered questions. The workflow design -- who reviews, by when, using what standard -- is what makes the detection capability into a functioning audit program.

Return to the playbook Playbook Overview →

See where Chapter 1 fits in the full playbook arc and what chapters follow

What Changes With S/4HANA

The Monitoring Workflow

Fiori for Audit

BIS in Practice

The Automation Principle

Related topics