During my experience as an SAP auditor, I've compiled a practical reference of key SAP transaction codes (T-Codes) organized by business cycle. These are particularly useful for tracking, control monitoring, and audit testing. Focused primarily on display and reporting functions, they cover the most frequently used transactions for auditors.

I've shared this cheat sheet in numerous presentations and training sessions, consistently receiving strong positive feedback from participants.

Procurement – Supply Chain
ME23 : Display Purchase Order
FBL1 : Display Vendor Line Items
XK03 : Display vendor (centrally)
FK10 : Vendor Account Balance
MK03 : Display vendor (Purchasing)
VL03 : Display Delivery
KO03 : Display Internal Order
FCH2 : Display Payment Document Checks

Sales – Order Fulfillment
FD10 : Customer Account Balance
FBL5 : Display Customer Line Items
VF03 : Display Billing Document
VA03 : Sales Orders
VA05 : List of Sales Orders
VF05 : List of Billing Documents
KSB1 : Cost Line Items for CoCe
VD03 : Display Customer (Sales)
VT03N : Display Shipment
ME2L : Purchase Orders by Vendor
ME2M : Purchase Orders by Material

Asset Management
IE03 : Display Equipment
MI03 : Display Physical Inventory Document
AS03 : Display Asset Master Record
AR01 : Call Asset List
IH10 : Display Equipment

Finance & Controlling
FBV3 : Display Parked Document
FB03 : Display Document
KSB1 : Cost Line Items
KE5Z : Profit Center: Actual Line Items
FS10 : Balance GL
KCH3 : Display profit center hierarchy
FBL3 : Display G/L Account Line Items
KS03 : Display Master Cost Center
FBU3 : Display Intercompany Document

Inventories
MB03 : Display Material Document
MM03 : Display Material
MB51 : Material Doc. List
CKMB : Display Material Ledger Document
MD04 : Display Stock/Requirements Situation
MC.9 : Material Analysis / Stock
MMBE : Stock Overview

System
VL03N : Display Outbound Delivery
SP01 : Spool Request
SP02 : Spool - Output Device LOCL Wide Report
SE16 : Data Browser
SM35 : Batch Session: Overview
SMX : Own Jobs

Article by Prof. Hernan Huwyler, MBA, CPA, CAIO
AI GRC Director | AI Risk Manager | Quantitative Risk Lead
Speaker, Corporate Trainer and Executive Advisor

Top 10 Responsible AI and Risk Management by Thinkers360

Essential SAP Transaction Codes For Auditing: A Comprehensive Reference By Business Cycle

Why Transaction Code Fluency Matters For SAP Auditors

Effective auditing in an SAP environment requires the auditor to navigate the system with the same fluency as the business users whose activities are under review. Transaction codes are the entry points to every function in SAP, and an auditor who cannot locate, display, and analyze transactional data directly within the system is dependent on information prepared and filtered by the auditee, which compromises the independence and completeness of the audit.

This reference compiles the most frequently used SAP transaction codes for internal audit, SOX testing, compliance monitoring, and control verification, organized by business cycle. The codes are predominantly display transactions, meaning they allow the auditor to view data without modifying it. This distinction is important because auditors should generally operate with display-only access to production systems, and authorization profiles assigned to audit users should restrict access to display functions to prevent inadvertent or unauthorized changes to live data.

The reference covers both SAP ECC and, where applicable, the equivalent or replacement transactions in SAP S/4HANA. Organizations that have migrated or are migrating to S/4HANA should note that many classic transactions remain functional in the S/4HANA environment through backward compatibility, but several have been deprecated and replaced by new transactions or SAP Fiori applications. The S/4HANA implications are addressed within each business cycle section where relevant changes affect audit procedures.

Procure To Pay

The procure-to-pay cycle encompasses vendor management, purchasing, goods receipt, invoice verification, and payment processing. It is one of the highest-risk areas for fraud and financial misstatement and therefore one of the most heavily audited business cycles in any SAP environment.

ME23N displays individual purchase orders including header data, line items, conditions, delivery schedules, and the complete document history. This is the current standard transaction for purchase order display, having replaced the older ME23 transaction. Auditors use ME23N to verify authorization levels, pricing conditions, vendor selection, and whether purchase orders were created before or after the goods or services were received.

ME2N provides a flexible purchase order list with multiple selection and filter criteria, enabling auditors to extract purchase order populations for analysis by date range, purchasing organization, vendor, material group, or account assignment. This transaction is more versatile than the older list transactions for generating audit samples.

ME2L lists purchase orders by vendor, allowing the auditor to review the complete purchasing relationship with a specific supplier over a defined period. This is particularly useful for identifying concentration of spend with specific vendors or unusual purchasing patterns.

ME2M lists purchase orders by material, enabling the auditor to trace purchasing activity for a specific item across vendors and time periods. This transaction supports price comparison analysis and helps identify whether the organization is obtaining competitive pricing.

ME2K lists purchase orders by account assignment category, which is useful for identifying purchase orders charged to specific cost centers, internal orders, or projects. Auditors use this transaction to verify that expenditures are assigned to the correct organizational units and that approval authorities correspond to the account assignment.

MIR4 displays posted invoice documents from the invoice verification process. Auditors use this transaction to verify that invoices match purchase orders and goods receipts through the three-way matching process, to identify price variances, and to examine invoice blocking and release procedures.

FBL1N displays vendor line items, providing a complete view of all financial postings against a vendor account including invoices, payments, credit memos, and clearing entries. This is the current version of the vendor line item display, replacing the older FBL1 transaction. The N-version provides enhanced filtering, sorting, and layout capabilities that support more efficient audit analysis.

FK10N displays the vendor account balance, showing the aggregate balance and transaction summary for a vendor across company codes and fiscal years. Auditors use this to identify vendors with unusual balances, credit balances that may indicate overpayments, or aged open items that may indicate disputed transactions.

XK03 displays vendor master data centrally, including general data, company code data, and purchasing data in a single view. In S/4HANA, vendor master data is maintained through the Business Partner framework using transaction BP. Auditors should be aware that the transition to Business Partner consolidates customer, vendor, and other partner data into a single master record, which changes the navigation path and the authorization objects required for access. The older transactions MK03 for purchasing-specific vendor data and FK03 for financial accounting vendor data remain functional in S/4HANA but will eventually be fully deprecated.

VL03N displays outbound delivery documents, allowing the auditor to verify delivery quantities, dates, picking and packing status, and goods issue postings. In the procure-to-pay cycle, delivery documents are relevant when the organization manages inbound deliveries from vendors or when reverse logistics processes are in scope.

KO03 displays internal order master data, including the order type, responsible cost center, settlement rules, and status. Auditors review internal orders to verify that cost collection objects are properly configured and that settlement rules direct costs to the correct receiving objects.

FCH2 displays payment document checks, providing details of check payments including check numbers, amounts, payees, and encashment status. This transaction is relevant for auditing the payment disbursement process and for identifying checks that have been voided, reissued, or remain outstanding beyond expected clearing periods.

MRBR releases blocked invoices. While this is a processing transaction rather than a display transaction, auditors should be aware of it because the release of blocked invoices is a control point in the procure-to-pay cycle. Auditors can review the population of blocked and released invoices using report MIR6, which lists invoices in the invoice verification workflow.

Order To Cash

The order-to-cash cycle encompasses customer management, sales order processing, delivery, billing, and accounts receivable. This cycle is critical for revenue recognition, credit management, and the prevention of fictitious revenue and customer fraud.

VA03 displays individual sales orders, including header data, line items, pricing conditions, delivery status, and billing status. Auditors use this transaction to verify pricing accuracy, discount authorization, credit limit compliance, and whether orders were processed in accordance with the organization's sales policies.

VA05 lists sales orders by various selection criteria including date range, customer, sales organization, and order type. This transaction enables auditors to generate order populations for sample selection and trend analysis.

XD03 displays customer master data centrally, including general data, company code data, and sales area data. As with vendor master data, S/4HANA consolidates customer master maintenance into the BP transaction. The older module-specific transactions VD03 for sales and distribution customer data and FD03 for financial accounting customer data remain available but are being progressively deprecated.

FD10N displays the customer account balance, showing aggregate balances and transaction summaries across company codes and fiscal years. Auditors use this to identify customers with unusual balances, debit balances in credit accounts, or aged receivables that may indicate collection problems or revenue recognition issues.

FBL5N displays customer line items, providing the complete financial posting history for a customer account. This is the current version replacing the older FBL5. Auditors use this transaction to review invoice and payment activity, identify unusual clearing patterns, and trace individual transactions from order through collection.

VF03 displays billing documents, allowing the auditor to verify invoice amounts, pricing conditions, billing dates, and accounting entries generated by the billing process. The relationship between the sales order, delivery, and billing document forms the core audit trail in the order-to-cash cycle.

VF05 lists billing documents by various selection criteria, enabling auditors to generate billing populations for analysis and sample selection.

VT03N displays shipment documents, providing logistics detail about how goods were physically transported to the customer. Auditors may review shipment documents to verify that deliveries were actually shipped and to identify discrepancies between shipping records and billing documents.

Inventory And Materials Management

The inventory cycle encompasses material master management, goods movements, physical inventory, and inventory valuation. Inventory is a significant account for most manufacturing, distribution, and retail organizations and is subject to specific audit procedures for existence, completeness, and valuation.

MM03 displays material master data, including basic data, purchasing data, accounting data, and plant-specific data. Auditors review material master records to verify valuation class assignments, standard costs, and inventory management indicators that affect financial reporting.

MB03 displays individual material documents, which record every goods movement in the system including goods receipts, goods issues, transfer postings, and physical inventory adjustments. Each material document generates a corresponding accounting document, and the audit trail between these two documents is fundamental to inventory accuracy.

MB51 lists material documents by various selection criteria including date range, material number, plant, movement type, and user. This is one of the most important audit transactions for inventory because it enables the auditor to analyze the complete population of goods movements and to identify unusual movement types, off-hours postings, or movements processed by unauthorized users.

MIGO is the primary transaction for goods movement processing in current SAP versions. While it is a processing transaction, auditors should understand its functionality because it is the transaction through which goods receipts, goods issues, and transfer postings are executed. Display functions within MIGO allow the auditor to review goods movement documents with full detail.

MI03 displays physical inventory documents, including the count results, differences between book and physical quantities, and the status of the physical inventory process. Auditors use this transaction to verify the completeness and accuracy of cycle counting and year-end physical inventory procedures.

MMBE provides a stock overview for a material, showing current quantities across all plants, storage locations, and stock types including unrestricted, quality inspection, and blocked stock. This transaction is essential for verifying the existence and classification of inventory balances.

MD04 displays the stock and requirements situation for a material, showing the current stock position alongside planned receipts and requirements. Auditors may use this transaction to assess whether inventory levels are reasonable relative to demand and to identify materials with excess or obsolete stock positions.

CKMB displays material ledger documents, which record the actual cost flows associated with materials when the material ledger is activated. In organizations that use actual costing, this transaction is relevant for verifying inventory valuation adjustments at period end.

CKM3N displays the material price analysis, showing the price determination and variance allocation for a material in a specific period. This transaction is particularly important in organizations using the material ledger for actual cost determination, as it reveals the components of inventory valuation including purchase price variances, production variances, and exchange rate differences.

Asset Management

The asset management cycle encompasses the creation, capitalization, depreciation, transfer, and retirement of fixed assets. Fixed assets represent a significant balance sheet account for capital-intensive organizations and are subject to audit procedures for existence, completeness, valuation, and proper classification.

AS03 displays asset master records, including the asset class, cost center assignment, capitalization date, useful life, depreciation terms, and current book values. Auditors review asset masters to verify that capitalization policies are correctly applied and that depreciation parameters are consistent with the organization's accounting policies.

AR01 and S_ALR_87011990 generate asset listing reports that provide a complete inventory of fixed assets with their current values, accumulated depreciation, and net book values. These reports are the starting point for existence and completeness testing of the fixed asset register.

AW01N displays the asset explorer, providing a comprehensive view of an individual asset's values, depreciation, and transactions across all depreciation areas and fiscal years. This is one of the most useful audit transactions for fixed assets because it consolidates all financial information about an asset in a single view.

IE03 displays equipment master records, which contain the technical and maintenance-related data for physical assets. In organizations where equipment records are linked to asset master records, auditors can use this transaction to trace the relationship between the technical asset register and the financial asset register.

IH08 displays the equipment list, enabling auditors to generate populations of equipment records for comparison against the fixed asset register. Discrepancies between the equipment list and the asset register may indicate unrecorded assets, ghost assets, or incomplete retirement processing.

MI03 also applies to the physical inventory of assets when organizations conduct physical verification of fixed assets, though this function is more commonly associated with inventory counting.

ABAV and ABAVN are the transactions for asset retirements by scrapping. While these are processing transactions, auditors should be aware of them because asset retirements are a critical control point for verifying that disposed assets are removed from the register at their correct values and that any gains or losses on disposal are properly recorded.

Finance And General Ledger

The finance and general ledger cycle is the central audit domain because it encompasses all financial postings, period-end adjustments, intercompany transactions, and the production of financial statements. The general ledger is the ultimate consolidation point for all business cycle transactions.

FB03 displays individual financial documents, including the posting date, document type, line items, amounts, and the user who posted the document. This is the most fundamental financial audit transaction and is used to verify the accuracy and authorization of every type of financial posting.

FBV3 displays parked documents, which are financial documents that have been entered into the system but not yet posted. Parked documents represent pending transactions that may or may not be posted and are relevant to the audit because they may contain period-end adjustments, disputed entries, or transactions awaiting authorization.

FBL3N displays general ledger line items, providing the complete posting history for any GL account. This is the current version replacing the older FBL3. Auditors use this transaction extensively for substantive testing, analytical procedures, and the identification of unusual journal entries. The ability to filter by posting date, document type, user, and amount makes this transaction one of the most powerful analytical tools available to the auditor in SAP.

FAGLL03 displays line items in the new general ledger. Organizations that have activated the new GL functionality or migrated to S/4HANA use this transaction instead of or in addition to FBL3N. The new GL provides enhanced capabilities for segment reporting, document splitting, and real-time consolidation that affect how the auditor analyzes financial data.

FS10N displays general ledger account balances by period, providing the opening balance, total debits, total credits, and closing balance for each fiscal period. Auditors use this transaction for analytical review procedures and for reconciling account balances to the financial statements.

FBU3 displays intercompany documents, showing the financial postings that result from transactions between company codes within the same corporate group. Intercompany transactions are a significant audit focus because they must be eliminated in consolidation and because transfer pricing and intercompany margin are subject to regulatory scrutiny.

KSB1 displays cost line items for cost centers, providing the detailed posting history for management accounting objects. Auditors use this transaction to analyze overhead costs, verify cost allocations, and identify unusual charges to specific cost centers.

KE5Z displays profit center actual line items, enabling auditors to review the financial performance of profit centers and to verify that revenues and costs are assigned to the correct organizational units for segment reporting.

KS03 displays cost center master data, including the responsible manager, company code assignment, hierarchy assignment, and activity type indicators. Auditors review cost center masters to verify that the management accounting structure is consistent with the organizational structure and that cost center assignments in transaction data are reasonable.

KCH3 displays the profit center hierarchy, which defines the organizational structure used for internal management reporting and segment reporting. Auditors review the hierarchy to understand how financial results are aggregated for reporting purposes and to identify any structural anomalies that could affect the accuracy of segment disclosures.

OB52 displays and maintains the posting period configuration. This transaction controls which accounting periods are open for posting and is a critical control for the financial close process. Auditors should verify that posting periods are opened and closed in accordance with the organization's close calendar and that access to OB52 is restricted to authorized financial controllers.

S_ALR_87012332 and related standard SAP reports in the S_ALR series provide financial statement reports, trial balances, and other standard financial reporting outputs. The specific report numbers vary by organizational configuration but are essential tools for the auditor's analytical review procedures.

Treasury And Cash Management

Treasury operations encompass bank account management, cash positioning, payment processing, and financial instrument accounting. These functions involve direct control over cash and financial assets and therefore require specific audit attention.

FF7A displays the cash management position, showing expected cash inflows and outflows by value date. Auditors review this transaction to assess liquidity risk and to verify that cash forecasting procedures are functioning correctly.

FBL1N and FBL5N are also relevant to treasury auditing for the review of payment and receipt transactions against vendor and customer accounts respectively.

FCHI displays check information, allowing the auditor to review the status and history of checks including issuance, encashment, voiding, and reissuance. This transaction complements FCH2 and is useful for reconciling the check register against bank statements.

FF67 displays bank statement postings, enabling the auditor to review how electronic bank statements have been processed and reconciled within the system. Automated bank statement processing is a key control in the cash management cycle, and auditors should verify that the reconciliation rules are correctly configured and that exceptions are reviewed and resolved on a timely basis.

User Access And Security

The audit of user access, authorization controls, and segregation of duties is fundamental to every SAP audit engagement. Access controls determine who can execute which transactions and who can access which data, and weaknesses in the access control framework can undermine every other control in the system.

SUIM is the User Information System and is one of the most important transactions for SAP auditing. It provides a comprehensive set of reports for analyzing users, roles, profiles, authorizations, and transactions. Auditors use SUIM to identify users with critical authorizations, to analyze segregation of duties conflicts, to determine which users have access to specific transactions, and to review changes to user assignments over a defined period.

SU01D displays user master records, including the user's assigned roles, profiles, authorization groups, user type, validity dates, and logon data. Auditors review user masters to verify that access assignments are consistent with the user's job responsibilities and that terminated or transferred employees have had their access appropriately modified or revoked.

SU53 displays the last authorization check failure for the current user, showing the authorization object and field values that caused an access denial. While primarily a troubleshooting tool, auditors can use this transaction to understand the authorization logic applied to specific access attempts.

PFCG is the role maintenance transaction. In display mode, auditors use PFCG to review the composition of roles, including the transactions, authorization objects, and organizational values assigned to each role. Role design is the foundation of the access control framework, and auditors should evaluate whether roles are designed according to the principle of least privilege and whether they create segregation of duties conflicts when assigned in combination.

AGR_1251 and AGR_USERS are database tables, accessible through SE16N, that auditors frequently query to analyze role-to-authorization and role-to-user assignments across the entire system. These table queries are more efficient than reviewing individual roles through PFCG when the audit requires a system-wide analysis of access assignments.

Change Management And System Administration

Auditing the change management process and system administration functions is essential for verifying the integrity of the SAP environment itself. Changes to system configuration, programs, and master data are the mechanisms through which controls can be established, modified, or circumvented.

SE16N is the general table display transaction, providing read-only access to any transparent database table in the system. Auditors use SE16N extensively for direct data extraction when standard reports or transactions do not provide the required level of detail. Access to SE16N should be carefully controlled because it provides access to all data in the system without the application-level security restrictions that govern individual transactions.

SCU3 displays table change logs, showing changes made to customizing and configuration tables. This transaction is critical for auditing the change management process because configuration changes can modify the behavior of controls, posting rules, and business logic throughout the system.

SM21 displays the system log, which records system events, errors, and warning messages. Auditors review the system log to identify unauthorized access attempts, system errors that may indicate data integrity issues, and administrative events that warrant investigation.

SM37 displays the job overview, showing all scheduled and completed background jobs in the system. Auditors use this transaction to verify that critical batch processes such as payment runs, posting runs, and interface jobs have executed successfully and on schedule. Unauthorized or unscheduled batch jobs may indicate unauthorized processing.

SM04 displays the user overview, showing all users currently logged into the system. While primarily an operational monitoring tool, auditors may use this transaction to verify that concurrent logon restrictions are enforced and to identify unusual logon patterns.

SM35 displays the batch input session overview, showing data transfer sessions that have been recorded or are pending execution. Batch input sessions are used for mass data uploads and changes, and auditors should review them to verify that mass changes to master data, financial postings, or configuration data have been properly authorized and executed.

SP01 and SP02 display spool requests and output device assignments respectively. Auditors review spool management to verify that sensitive reports and financial data are printed only to authorized output devices and that spool retention and deletion policies are consistent with data security requirements.

STAD displays individual transaction step statistics, providing detailed information about which users executed which transactions at which times. This transaction provides the granular usage data needed to verify whether users have actually executed specific transactions, which is essential for detective SoD monitoring. Access to STAD requires basis-level authorization and should be coordinated with the IT administration team.

SM20 and RSAU_READ_LOG display the security audit log, which records security-relevant events such as logon attempts, failed authorization checks, transaction starts, and RFC calls. The security audit log is a critical detective control and a primary source of evidence for investigating suspected unauthorized access. Auditors should verify that the security audit log is activated, that it captures the events relevant to the organization's security policy, and that it is retained for a period consistent with audit and regulatory requirements.

SAP GRC Access Control

Organizations that use SAP GRC Access Control have access to additional transactions and tools that are specifically designed to support audit and compliance activities.

GRAC_SPM or the Fiori equivalent provides access to the Emergency Access Management (formerly Firefighter) log review, showing all activities performed by users under elevated emergency access. Auditors should review these logs to verify that emergency access was used only for its stated purpose, that activities performed under emergency access were subsequently reviewed by the designated controller, and that emergency access sessions were terminated within the authorized time window.

GRAC_EAM provides access to the Access Risk Analysis functionality, which automates the identification of SoD conflicts across the user population. Auditors should verify that the SoD ruleset is current, that risk analysis is performed regularly, and that identified conflicts are documented with either remediation actions or approved mitigating controls.

NWBC or the SAP Fiori Launchpad in S/4HANA provides access to the GRC dashboards and workflow interfaces that manage access requests, risk analysis results, and remediation tracking. Auditors should evaluate whether the workflows are configured to enforce the organization's access provisioning policies and whether the approval chains reflect appropriate segregation between the requestor, the approver, and the security administrator.

S/4HANA And Fiori Considerations For Auditors

Organizations operating on SAP S/4HANA should be aware that the audit transaction landscape is evolving. Many classic ECC transactions remain functional through backward compatibility, but SAP's strategic direction is to replace them with Fiori applications that provide role-based, browser-based access to the same underlying data.

For auditors, the most significant implications are as follows. The Business Partner transaction BP replaces the separate customer and vendor master display transactions including XK03, XD03, MK03, FK03, VD03, and FD03. Auditors working in S/4HANA must navigate the Business Partner framework to access master data, and the authorization objects governing access have changed accordingly.

Fiori applications carry different authorization objects than their classic GUI counterparts. An audit of user access and SoD in an S/4HANA environment that analyzes only classic transaction code authorizations will produce incomplete results. The SoD ruleset must include the Fiori app authorizations to provide a complete picture of user access.

Embedded analytics in S/4HANA provide real-time reporting capabilities that can supplement or replace some of the standard SAP reports traditionally used in audit. Auditors should familiarize themselves with the analytical capabilities available in their organization's S/4HANA environment, as these tools may provide more efficient access to the data needed for analytical procedures and continuous monitoring.

The simplification of data structures in S/4HANA, including the elimination of aggregate tables in finance and the convergence of financial accounting and management accounting into a single table (ACDOCA), affects how auditors query and analyze financial data. Direct table queries that were valid in ECC may require modification in S/4HANA to reflect the new data model.

From Transaction Codes To Audit Intelligence

A comprehensive transaction code reference is a necessary tool for any SAP auditor, but it is not sufficient by itself. The value of knowing which transaction to use depends on the auditor's ability to interpret the data it reveals, to connect findings across business cycles, and to evaluate whether the controls embedded in the system are designed and operating effectively.

Transaction codes provide access to data. Audit intelligence comes from understanding the business processes that generate the data, the control objectives that the data should satisfy, the fraud and error scenarios that the data may reveal, and the regulatory and financial reporting implications of any anomalies identified. The auditor who approaches SAP with this integrated perspective transforms a reference list into a systematic audit methodology.

When I first began auditing SAP systems, I kept a folded sheet of paper in my notebook with about forty transaction codes on it. That sheet grew into the cheat sheet many of you have seen in my training sessions. Over the years, the most common question I got was never "which code do I type?" It was "okay, I'm in the transaction, now what do I actually look at, and what does a problem look like?"

That question is what this expanded edition answers.

Every control below follows the same rhythm: why the control matters, which transactions and reports to run, how to run the test step by step, what a red flag looks like, and a real-world style example you can picture. The controls are ordered by importance, starting with the ones that, if broken, make every other control unreliable, and moving toward the more specialized checks.

The guidance draws on SAP's own documentation (SAP Help Portal, the SAP Security Baseline Template, the S/4HANA simplification list), the DSAG audit guidelines for SAP, ISACA's SAP audit and control publications, the IIA's GTAG series, PCAOB standards AS 2201 and AS 2401, COSO's 2013 framework, the ACFE's 2024 Report to the Nations, and the U.S. Department of Justice's September 2024 update to its Evaluation of Corporate Compliance Programs. Where a transaction behaves differently in S/4HANA than in ECC, I say so, because in 2025 most audit teams are straddling both worlds. ECC mainstream maintenance ends in 2027, S/4HANA 2023 is the current long-term release, and a lot of production systems are somewhere in between.

One housekeeping note. Your audit user should carry display-only access. Every transaction in this guide can be executed in display mode or is a pure report. If you find yourself able to save something, stop and get your access corrected. An auditor who can change production data has already created a finding.

How To Read Each Control

Element	What it tells you
Control objective	The plain-English promise the control is supposed to keep
Audit type	SOX ITGC, SOX process control, financial statement, fraud, anti-corruption, operational
Run this	The validated transaction codes and standard reports
Test procedure	The click-by-click approach, written for someone who is not a Basis administrator
Red flags	What "wrong" looks like on the screen
Example	A short scenario drawn from patterns that show up in practice

Part One: Who Can Do What (Access Controls)

If you only have one day in an SAP system, spend it here. Access is the control beneath every other control. A perfect three-way match means nothing if the accounts payable clerk can also change the vendor's bank account.

Control 1 Nobody Should Hold the Keys to the Whole Kingdom

Control objective: No user in production holds unrestricted authorization (SAP_ALL, SAP_NEW, or equivalent wide-open custom profiles) outside a documented and monitored exception.

Audit type: SOX ITGC, fraud

Run this: SUIM, RSUSR002 (via SA38 or SUIM), SU01D, SE16N on tables USR02, AGR_USERS, UST04

Test procedure

Open SUIM (User Information System). Expand User → Users by Complex Selection Criteria → By Profiles. Enter SAP_ALL, execute. Repeat for SAP_NEW. This gives you the list of users with the profiles assigned directly.
Profiles can also arrive indirectly through roles. In SUIM, use Roles → By Authorization Values, search for authorization object S_TCODE with value *, and separately for S_USER_GRP with activity *. This catches custom "super" roles that were built to avoid the obvious SAP_ALL flag.
For each user found, open SU01D and read the Logon Data tab. Note the user type. Dialog users with SAP_ALL are your headline finding. System or communication users with SAP_ALL are a finding too, but they are usually interface accounts and the remediation conversation is different.
Ask for the exception documentation. Each name on your list needs a business owner, an approval, and a date for removal or a compensating control such as security audit log review.

Red flags: Dialog users from the business, not IT, with SAP_ALL. Consultants whose contracts ended a year ago. A "temporary" assignment with no end date. Generic accounts like ADMIN2 or INTERFACE_OLD that nobody can explain.

Example: In one mid-sized manufacturer, three finance users had SAP_ALL because a go-live consultant had granted it "just until stabilization." Stabilization had ended four years earlier. One of those users had since moved to treasury and could create vendors, post invoices, and release payments. Nothing improper had happened, but under SOX the control was ineffective regardless of outcome.

Control 2 Standard Users Locked Down and Password Rules That Mean Something

Control objective: Default SAP accounts are secured and password and session parameters meet company policy.

Audit type: SOX ITGC, IT review

Run this: RSUSR003 (via SA38), RZ11, RSPARAM (via SA38), TU02, SECPOL, SE16N on USR40

Test procedure

Run report RSUSR003. It checks the standard users SAP*, DDIC, EARLYWATCH, SAPCPIC, and TMSADM in every client and tells you whether they still have default passwords and whether they are locked. Green is good. Red means someone can log in with a password printed in public documentation.
In RZ11, look up each of these parameters and record the current value:
- login/no_automatic_user_sapstar should be 1 (prevents the SAP* backdoor when the user record is deleted)
- login/min_password_lng should meet policy, and SAP's own baseline recommends at least 8 with complexity, many companies now use 12
- login/fails_to_user_lock typically 5 or fewer
- login/password_expiration_time typically 90 days or less
- rdisp/gui_auto_logout a defined value in seconds, not 0
- rec/client should be ALL or list the production client, which matters for Control 28
If the company uses security policies, open SECPOL in display mode and confirm which policy is attached to sensitive users in SU01D.
Check TU02 for recent parameter changes. A parameter that was tightened the week before your fieldwork tells its own story.

Red flags: SAP* unlocked with the default password in the production client. Password expiration set to 0 (never). Parameters that differ between the production and development systems in the wrong direction.

Example: A retailer passed its password policy review every year because the policy document said 90 days. Nobody had ever pulled RZ11. The parameter was 0. Passwords had never expired since the 2011 go-live.

Control 3 Segregation of Duties You Can Prove, Not Just Assert

Control objective: No single user can complete an end-to-end transaction that allows them to both commit a fraud and conceal it.

Audit type: SOX ITGC and process control, fraud, anti-corruption

Run this: SUIM, SE16N on AGR_USERS, AGR_1251, AGR_TCODES, ST03N, STAD, SAP GRC Access Control risk analysis (if licensed)

Test procedure

Agree the conflict pairs with management before you start. The classic SAP conflicts that matter most:
- Create or change vendor master (XK01/XK02/FK01/FK02, or BP in S/4HANA) and post vendor invoice (FB60/MIRO) or run payments (F110/F-53)
- Create purchase order (ME21N) and post goods receipt (MIGO) and post invoice (MIRO)
- Maintain customer credit limit (FD32 or UKM_BP) and release blocked sales orders (VKM1)
- Create asset master (AS01) and post asset retirement (ABAVN)
- Maintain users (SU01) and maintain roles (PFCG)
- Post journal entries (FB50/FB01) and maintain posting periods (OB52)
If GRC Access Control is in place, request the latest risk analysis run and the ruleset version. Confirm the ruleset includes Fiori app authorizations, not only classic transaction codes. In S/4HANA a user can post a journal entry through the "Manage Journal Entries" app without ever touching FB50.
If GRC is not in place, do it the manual way. In SE16N, pull AGR_TCODES (which transactions sit in which roles) and AGR_USERS (which users hold which roles). Join them in a spreadsheet and flag users whose combined roles contain both sides of a conflict pair.
Do not stop at "can do." Check "did do." ST03N (Workload → Transaction Profile) shows which transactions were actually executed and by whom over the retained period. STAD gives the same detail but usually only for the last day or two. If a user holds a conflicting combination but has only ever executed one side, the risk is lower and management may accept a monitoring control instead of a role change.
For every conflict left in place, obtain the mitigating control and test it as you would any other control. "The manager reviews a report monthly" needs the report, the sign-off, and evidence that exceptions were followed up.

Red flags: Users with more than one conflict pair. Role names like Z_FINANCE_ALL or Z_TEMP_GOLIVE. A GRC ruleset last updated before the S/4HANA migration. Mitigating controls that reference reports nobody runs.

Example: A shared services center had a clean GRC dashboard. When I pulled AGR_TCODES, a composite role for "AP Senior" contained both FK02 and F110 because someone had added FK02 to fix a single user's problem and forgot to remove it. The GRC ruleset had been updated to exclude that role from analysis "temporarily." Two years earlier.

Control 4 People Who Left Should Not Still Be Logging In

Control objective: Access is removed promptly for terminated employees and adjusted for transfers; dormant accounts are disabled.

Audit type: SOX ITGC, fraud

Run this: RSUSR200 (via SA38 or SUIM), SU01D, RSUSR100N, SE16N on USR02

Test procedure

Obtain the HR termination list for the period from the HR system (or PA20 if HR is in SAP).
Run RSUSR200 with Users with no logon in the last 90 days and separately pull all users. Export.
Match terminated employees to SAP user IDs. For each match, open SU01D and check the Valid To date and the lock status. Compare the lock date to the termination date. Your policy will define the window; most companies say same day, or within one business day.
Run RSUSR100N (change documents for users) for the terminated user IDs. This shows exactly when the lock was applied and by whom, which is the evidence you need.
For dormant accounts still active, ask why. Interface users are a valid reason. "We forgot" is not.

Red flags: A terminated user with a logon after the termination date. Accounts unlocked after being locked. Users with a Valid To of 31.12.9999 who left in 2023.

Example: A controller resigned in March. Her account was locked in March. It was unlocked in April by the IT help desk because "the new controller needed her reports" and was never locked again. The old controller never used it. But for eight months, a former employee's credentials could post journal entries.

Control 5 Emergency Access Is Really for Emergencies

Control objective: Elevated "firefighter" access is granted only for approved reasons, used only for the stated purpose, logged, and reviewed by an independent controller.

Audit type: SOX ITGC, fraud

Run this: SAP GRC Access Control Emergency Access Management (GRAC_SPM for firefighter logon; the Consolidated Log Report in the GRC web front end), or in systems without GRC: SM20 / RSAU_READ_LOG, STAD

A validation note: The original cheat sheet mapped GRAC_EAM to Access Risk Analysis. That is not quite right. In GRC 10.x and 12.0, GRAC_SPM is the centralized firefighter logon, /GRCPI/GRIA_EAM is the plug-in equivalent, and the auditor's review happens in the Consolidated Log Report under Reports and Analytics in NWBC or the Fiori launchpad. Access Risk Analysis is a separate work center, and batch analysis runs through GRAC_BATCH_RA. SAP's cloud successor is SAP Cloud Identity Access Governance.

Test procedure

Pull the list of firefighter IDs and their assigned owners and controllers. Confirm that no user is both a firefighter and their own controller.
Select a sample of firefighter sessions from the Consolidated Log Report. For each, read the reason code and the free-text justification, then read the actual transactions executed. They should match. A session opened to "fix a stuck IDoc" that also ran FK02 and F110 is your finding.
Confirm the controller reviewed each log within the policy window (often 5 business days) and that the review left a trace: a workflow approval, a comment, something.
If there is no GRC, review who holds the equivalent emergency roles and pull RSAU_READ_LOG (S/4HANA and NetWeaver 7.50+) or SM20 (older ECC) for those user IDs during the period. Without the security audit log switched on, there is no emergency access control at all; there is only emergency access.

Red flags: Firefighter sessions that run for days. The same reason code on every session. Controllers approving logs in batches of 50 at month-end. Firefighter IDs used by the same person every week for "emergencies."

Part Two: Is the General Ledger Telling the Truth (Financial Reporting Controls)

Control 6 Manual Journal Entries Get the Scrutiny the Standards Demand

Control objective: Manual and non-routine journal entries are authorized, supported, and free from management override.

Audit type: Financial statement (AS 2401 / ISA 240 requirement), SOX process control, fraud

Run this: FB03, FBL3N, FAGLL03, S_ALR_87012287 (Document Journal), S_ALR_87012289 (Compact Document Journal), S_ALR_87012291 (Line Item Journal); in S/4HANA the Audit Journal Fiori app; SE16N on BKPF, BSEG, ACDOCA

Why this is the heart of a financial audit: Both the PCAOB and the IAASB require auditors to test journal entries specifically for management override, because that is how the big frauds were done. SAP makes this easier than most systems if you know where to look, because every posting carries the user ID, the entry date, the posting date, the document type, and the transaction code that created it.

Test procedure

Define your population. Run S_ALR_87012287 or query BKPF (S/4HANA: ACDOCA, which combines FI and CO in one table) for the fiscal year and company codes in scope. You want the following fields at minimum: document number, document type, posting date, entry date (CPUDT), entry time, user (USNAM), transaction code (TCODE), reference, header text, amount.
Separate automatic from manual. Document types tell you the source: SA is the general manual journal, KR/KZ are vendor invoice and payment, DR/DZ customer invoice and payment, RE MM invoice receipt, WE/WA goods receipt and issue, RV billing, AA asset postings, ZP payment program. Your manual population is mostly SA plus anything posted through FB50, FB01, F-02, or FBV0 (posted from parked). Check the TCODE field rather than trusting document type alone; companies sometimes misuse types.
Apply risk criteria to the manual population. The criteria that consistently surface problems in SAP:
- Posted on weekends or outside business hours (entry time)
- Posting date more than a few days before entry date (backdating into an open prior period)
- Round amounts, especially at thresholds like 9,900 or 49,500
- Posted by users outside finance, by IT users, or by users who also approve
- Posted to revenue, reserves, intercompany, or suspense accounts
- Header text blank, "adjustment," "per JL," or "reclass" with no reference
- Reversed within days (look for documents with a reversal reference)
- Posted in the last three days of the period or in special periods 13 to 16
For your sample, open each document in FB03. Read the line items, the header (Document Header button shows user, entry date, transaction), and the attachments through the Services for Object button. Trace to the support outside SAP: the calculation, the approval email, the workflow.
In S/4HANA, the Audit Journal app bundles the document journal, changed documents, number range gaps, and duplicate invoices into one place and lets you filter by all the criteria above without building your own query. It is worth asking for access to this app specifically.

Red flags: A senior finance user posting large SA entries at 11 p.m. on the last day of the quarter with the text "true-up." Entries that exactly bring a metric over a threshold. An unusual volume of postings by a single user in special period 13.

Example: A quarter-end SA entry of 2,400,000 to a "deferred revenue" account, posted at 10:48 p.m. by a director, reversed on day two of the next quarter. Each entry had support. Together, they moved revenue between quarters to hit guidance. The pattern only became visible when entry date, entry time, and reversal reference were laid side by side.

Control 7 Closed Periods Stay Closed

Control objective: Accounting periods are opened and closed on schedule and only authorized users can post to prior or special periods.

Audit type: SOX process control, financial statement

Run this: OB52 (display), SE16N on T001B, SCU3 for change history, SU53 to interpret authorization group behavior

Test procedure

Open OB52 in display mode (or table T001B). For each posting period variant, note the "from" and "to" periods for account types S (GL), K (vendors), D (customers), A (assets), M (materials). Compare to the close calendar. If you are testing in May and period 3 is still open for account type S, ask why.
Look at the AuGr (authorization group) column. SAP allows a second interval, open only to users holding that authorization group in object F_BKPF_BUP. This is the legitimate way to let controllers post late adjustments. Confirm who holds the group through SUIM → Users by Authorization Values.
Check who can change OB52 at all: SUIM → Users by Transaction → OB52, and separately authorization object S_TABU_DIS for the relevant table group.
Pull the change log for T001B in SCU3 for the year. You should see periods opening and closing in a predictable monthly rhythm. A period reopened, a posting made, and the period closed again within an hour is a classic override pattern.

Red flags: Twelve periods open at once. OB52 changeable by end users in the business. Reopen-post-close sequences with no approval. Special periods left open indefinitely.

Control 8 Parked, Reversed, and Recurring Entries Are Not Hiding Anything

Control objective: Documents that sit outside the normal posting flow are reviewed, approved, and cleared appropriately.

Audit type: Financial statement, fraud

Run this: FBV3 (display parked document), FBV0 (post/delete parked, note access), FBL3N with document status filter, FB08 / F.80 (reversal, note access), FBD3 (display recurring document), F.14 / F.15 (recurring entry execution and list), FBRA (reset cleared items, note access)

Test procedure

Parked documents. At period end, run FBV3 or FBL3N with the Parked items indicator for the last day of the period. Parked documents are not in the ledger. A large parked customer credit memo at year-end that gets posted on January 2 is a cutoff issue; a large parked vendor invoice that is never posted is an unrecorded liability. Read the park date, the amounts, and who parked them.
Reversals. From your BKPF or ACDOCA extract, filter for documents with a reversal reference (field STBLG populated) and their reversing documents. Look for reversals across period boundaries, reversals of documents posted by the same user, and high reversal rates by user. In FB03, the header of a reversed document shows the reversal reason code, which should be a business explanation, not a generic default.
Recurring entries. Run F.15 to list the recurring entry originals and FBD3 to display any one of them. Recurring entries post automatically each period via F.14. Confirm each still has a business reason, an owner, and an end date. Recurring accruals that outlive the contract they were meant for are a common source of overstated liabilities.
Reset cleared items. Anyone who can run FBRA can un-clear a paid invoice and pay it again. Confirm access is limited and, if the security audit log is on, look for FBRA executions.

Red flags: Parked documents older than 30 days. A reversal reason of "01 - Reversal in current period" on 100 percent of reversals. Recurring entries dated from a prior ERP implementation. FBRA executed by AP clerks.

Control 9 No Gaps in the Story: Document Numbers and Duplicate Invoices

Control objective: Document number ranges are continuous, and the same vendor invoice is not recorded twice.

Audit type: Financial statement, fraud, SOX process control

Run this: S_ALR_87012342 (Gaps in Document Number Assignment), S_ALR_87012341 (Invoice Numbers Allocated Twice), SNRO / FBN1 (display number range status), OMRDC (display duplicate invoice check configuration)

Test procedure

Run S_ALR_87012342 for the company code and fiscal year. SAP assigns document numbers sequentially, so gaps are unusual. Small gaps happen legitimately (update terminations, buffering). Large or frequent gaps in manual document types warrant an explanation and a look at SM13 for failed updates.
Run S_ALR_87012341. It lists vendor invoices where the same reference (vendor invoice number) appears more than once for the same vendor. Each hit needs a look in FBL1N to see whether both were paid.
In OMRDC (display only), check whether the duplicate invoice check is set to compare company code, reference, and invoice date. If the check is switched off for a company code, ask why. Also check the vendor master (XK03, Payment Transactions tab, "Check double invoice" flag); the system-level setting does nothing for vendors where the flag is blank.
Supplement with your own analysis from the FBL1N export: same vendor, same amount, invoice dates within 30 days, different reference. Fraudsters and honest vendors alike vary the reference by a trailing letter or a dash.

Red flags: Duplicate check disabled. Vendors with "check double invoice" blank in the master. Pairs of identical invoices where one was paid by check and one by wire.

Control 10 GL Account Master Data and Reconciliation Accounts Are Stable

Control objective: Changes to the chart of accounts and to critical account settings are authorized and reviewed.

Audit type: SOX process control, financial statement

Run this: FS00 (display), FSP4 / FSS4 (changes to GL account at chart and company code level), S_ALR_87012308 (Display Changes to G/L Accounts), OB_GLACC11/12/13 (S/4HANA collective display)

Test procedure

Run S_ALR_87012308 for the period. It lists every field change on every GL account with old value, new value, user, and date.
Focus on the settings that change behavior: Reconciliation account for account type (turning it on or off lets users post directly to a subledger control account), Post automatically only (turning it off opens inventory and GR/IR accounts to manual postings), Open item management, Blocked for posting, and Field status group.
For a sample, confirm the change request and approval.
Cross-check in FBL3N: are there manual SA postings to accounts that should be automatic only? If yes, the flag was off at some point, whether or not it is on today.

Red flags: Reconciliation flag removed from the AP control account for a day. New accounts created in the last week of the quarter and used once.

Control 11 The Trial Balance Actually Ties to the Financial Statements

Control objective: The financial statements are derived completely and accurately from the general ledger.

Audit type: Financial statement, SOX

Run this: FS10N (ECC classic GL balances), FAGLB03 (new GL / S/4HANA balances), S_ALR_87012277 (G/L Account Balances), S_ALR_87012284 (Financial Statements), S_ALR_87012301 (Totals and Balances); Fiori "Trial Balance" app in S/4HANA

Test procedure

Run S_ALR_87012284 with the financial statement version management uses. Export. Reconcile to the reported balance sheet and income statement, line by line. Differences almost always sit in consolidation adjustments or in "top-side" entries outside SAP, both of which are exactly what you want to find.
For each material account, open FAGLB03 or FS10N, drill from the period balance into line items, and confirm the drill-down works and reconciles. The ability to drill from statement to balance to line item to document is your evidence that the audit trail is intact.
Compare the financial statement version in OB58 (display) to last year's. Accounts reassigned between line items change presentation without changing the ledger.

Red flags: Statement lines with no account assignment (unassigned accounts appear in a "not assigned" node at the bottom of S_ALR_87012284). Material amounts in suspense or clearing accounts. Top-side adjustments that recur every quarter.

Part Three: Following the Money Out (Procure-to-Pay and Disbursement Fraud)

The ACFE's 2024 Report to the Nations puts billing schemes at the top of asset misappropriation frauds, and vendor master manipulation is the mechanism behind most of them. This part is where fraud, SOX, and anti-corruption reviews overlap the most.

Control 12 Vendor Bank Account Changes Are the Single Most Dangerous Master Data Field

Control objective: Changes to vendor payment details are independently verified before the next payment runs.

Audit type: Fraud, SOX process control, anti-corruption

Run this: XK03 / FK03 (ECC), BP (S/4HANA), S_ALR_87012089 (Display Changes to Vendors), S_ALR_87012090 (Display/Confirm Critical Vendor Changes), FK08 / FK09 (confirmation of sensitive field changes), SE16N on LFBK (ECC vendor bank), BUT0BK (S/4HANA business partner bank), CDHDR / CDPOS (change documents)

Test procedure

Run S_ALR_87012089 for the period, all vendors, all fields. Export. Filter for these fields: bank account number, bank key, IBAN, SWIFT, payee (alternative payee), payment method, payment terms, and payment block. In S/4HANA, bank changes live in the business partner and appear under the BP change documents, but the report still picks them up.
Check whether the company has activated dual control for sensitive fields (configured in customizing, results visible in S_ALR_87012090). When active, a bank change by one user blocks the vendor for payment until a second user confirms in FK08 or FK09. Confirm the confirming user is a different person from the changer. If dual control is not active, the compensating control is usually a callback procedure to the vendor at a known phone number; sample the callbacks.
Take every bank change and look at the next payment in FBL1N (filter document type ZP or KZ, dates after the change). The payment after a bank change is the transaction a fraudster is waiting for.
Query LFBK or BUT0BK for the same bank account number appearing under multiple vendors. Two unrelated suppliers sharing a bank account is either a factoring arrangement or a problem.
Compare vendor bank accounts and addresses against employee bank details (HR infotype 0009, visible in PA20 if HR is in SAP, otherwise an HR extract). Employee-as-vendor matches need a business explanation.

Red flags: Bank changes by the same user who posted invoices for that vendor. Changes made on Friday afternoon and reversed the following week after a payment ran. Vendors whose bank country differs from their address country with no explanation. Bank changes requested by email (business email compromise remains the most common payment fraud vector according to the FBI's annual IC3 reports).

Example: A vendor's bank account was changed to a personal account at a bank in a different state. The change was made by an AP supervisor. The next payment was 187,000. The supervisor reversed the bank change three days later. The only trace was S_ALR_87012089, which nobody had run in two years.

Control 13 Three-Way Match Works and Blocked Invoices Are Released by the Right People

Control objective: Invoices are paid only when they agree to a purchase order and a goods receipt within approved tolerances; exceptions are released by someone independent of the buyer.

Audit type: SOX process control, fraud, operational

Run this: ME23N, MIR4, MIR6 (Invoice Overview), MRBR (Release Blocked Invoices, display access), OMR6 (tolerance limits, display), MB5S (GR/IR balances), ME2N with selection "Goods receipt but no invoice" and vice versa

Test procedure

In OMR6 (display), note the tolerance keys and limits, especially PP (price variance) and DQ (quantity variance). Compare them to policy. A 10 percent price tolerance with no absolute ceiling lets a 400,000 invoice come in 40,000 over the PO without a block.
Run MIR6 for the period with the Blocked indicator. Then run it again for released invoices. In MRBR (display), review who released blocked invoices. The releaser should not be the buyer on the PO or the person who posted the invoice.
Select a sample of released invoices. In MIR4, open each, and use Follow-On Documents to see the accounting entry and PO History to see the goods receipt. Confirm the block reason was resolved (a PO price update, a credit memo, a corrected GR) rather than simply overridden.
Check in ME23N whether the PO has "GR-based invoice verification" ticked on the Invoice tab of each line and whether the goods receipt indicator is set. If GR is not required, you have two-way match, which is fine for services with a documented approval but not for physical goods.
Run ME2N with the "Goods receipt but no invoice" selection to see received-not-invoiced items (an accrual completeness check) and MB5S for the GR/IR account balances.

Red flags: One user releasing 90 percent of blocked invoices. Blocks released within minutes of being set. PO price changed after the invoice arrived to make the variance disappear (visible in ME23N → Environment → Header Changes). POs created after the invoice date, which means the PO is a formality, not a control.

Control 14 Purchase Orders Are Not Split to Dodge Approval Limits

Control objective: Purchasing commitments are approved at the right level and not artificially fragmented.

Audit type: Fraud, anti-corruption, operational

Run this: ME2N, ME2L, ME2K, ME23N (Release Strategy tab), CL20N / CL24N (display release classification, optional), SE16N on EKKO / EKPO

Test procedure

Pull all POs for the period from ME2N or table EKKO. Sort by vendor and creator. Look for clusters: the same vendor, the same requester, several POs within a few days, each just below a release threshold (find the thresholds on the Release Strategy tab of any PO in ME23N, or ask purchasing for the release matrix).
Use ME2L to see the full picture for suspicious vendors and ME2K to see POs by cost center or internal order, which reveals which budget holder benefits from the splitting.
Also flag POs created and released by the same user (release strategy misconfiguration or a self-approval role), and POs with a large number of subsequent value increases (ME23N → Environment → Item Changes).

Red flags: Five POs to the same consultant totaling 48,000 when the approval threshold is 10,000. POs approved by users on vacation (their SAP session was open, or credentials were shared). "Framework" or blanket POs with no ceiling.

Example: A facilities manager issued eleven POs to a single contractor over three weeks, each between 9,200 and 9,900. The threshold requiring director approval was 10,000. The contractor was his brother-in-law. ME2L showed the pattern in under five minutes.

Control 15 The Payment Run Is Controlled and Manual Payments Are the Exception

Control objective: Payments are executed through the automatic payment program with proposal review; manual and one-time payments are rare, justified, and approved.

Audit type: Fraud, SOX process control, anti-corruption

Run this: F110 (display parameters, proposal, and logs), FBZP (payment program configuration, display), FBL1N filtered by document type (ZP = payment program, KZ = manual payment), F-53 / F-58 / FBCJ (manual payment transactions, note access), FCHN (Check Register), FCH2 (Display Check via Payment Document), FCH8 / FCH9 (cancel payment / void check, note access), S_ALR_87012086 (Vendor List, filter one-time accounts)

A validation note: The original list described FCHI as check information display. FCHI actually maintains check lots (the number ranges for check stock). The check register the auditor needs is FCHN.

Test procedure

In F110, select a sample of payment runs. Review the parameters (company codes, payment methods, next payment date), the proposal log, the exception list, and who edited the proposal versus who scheduled the payment. Editing a proposal (adding or removing invoices) and then running it should be two different people.
In FBZP (display), review payment method settings, particularly maximum amounts per payment method and whether the "payment medium" outputs go to a controlled location.
From FBL1N, split the year's payments into ZP (automatic) and KZ (manual). Manual payments should be a small percentage. Review every KZ payment above your threshold: who posted it, to whom, why not through F110.
Run S_ALR_87012086 and filter for one-time vendor account groups (typically CPD). One-time vendors carry no master data, so the payee name and bank account are typed on each invoice. That is convenient for a fraudster. Review volume, amounts, and repeated payees.
Run FCHN for the check register. Look for voided checks (FCH9) and reissued checks, gaps in check numbers, and checks outstanding for more than 90 days. FCH2 takes you from a payment document to its check.
Look at cash payments in FBCJ (cash journal). Cash is where bribes, kickbacks, and petty theft live. Pull all cash journal postings above a low threshold and read the recipient and purpose.

Red flags: Manual payments to vendors that also receive automatic payments. One-time vendor payments to the same payee name repeatedly. Checks voided and reissued to a different payee. A payment run scheduled outside the normal calendar by an unusual user.

Control 16 Bank Statements Are Reconciled Inside the System, and Exceptions Are Cleared

Control objective: Every bank transaction is matched to a book entry promptly; unmatched items are investigated.

Audit type: Financial statement, fraud

Run this: FF_5 (import electronic bank statement), FEBAN (ECC post-processing), FEB_BSPROC (S/4HANA post-processing), FF67 (manual bank statement), FEBA_BANK_STATEMENT (display), FF7A (Cash Position), FF7B (Liquidity Forecast), FI03 (bank master), FI04 (bank master changes), FI12 / FI12_HBANK (house bank configuration); Fiori "Manage Bank Statements" and "Cash Position" apps in S/4HANA

A validation note: FF67 is the manual bank statement entry transaction. Electronic statements are imported with FF_5 and post-processed with FEBAN (ECC) or FEB_BSPROC (S/4HANA). If your client says statements are "automatic" but the activity is all in FF67, the process is manual.

Test procedure

For each material bank account, open the statement processing overview (FEBAN / FEB_BSPROC) as of period end. Items still open and unposted are your unreconciled items. Age them. Anything more than a few days old should be on management's exception list.
Compare the bank statement closing balance to the GL bank account balance in FAGLB03 / FS10N. Differences should be fully explained by the open items above.
Check who can maintain the interpretation rules and house bank settings (FI12). Someone who can change a posting rule can redirect where incoming cash is credited.
Review FI04 for changes to bank master data, and FI03 for banks that look unusual (a "bank" at a residential address, or a bank key that does not match the country).
Use FF7A for a sanity check: does the cash position reflect the balances the treasurer reports?

Red flags: Unreconciled items in the bank clearing account that roll forward every month. A cash receipt posted to a suspense account then transferred manually to a customer. Manual FF67 entries adjusting the reconciliation at period end.

Control 17 GR/IR and Accrual Completeness

Control objective: Goods received but not invoiced are accrued; the GR/IR account is cleaned regularly and adjustments are approved.

Audit type: Financial statement, SOX process control

Run this: MB5S (GR/IR Balances), MR11 (GR/IR Account Maintenance, note access and history via MR11SHOW), F.13 (Automatic Clearing, log), FBL3N on the GR/IR account

Test procedure

Run MB5S at period end. Positive and negative balances by PO show goods received awaiting invoice and invoices awaiting goods. Age them.
Review MR11 adjustments in the period through MR11SHOW. MR11 writes off GR/IR differences to the expense or inventory account, which means an MR11 posting can bury an over-receipt or an overpayment. Each significant write-off needs a reason and an approver.
Confirm the automatic clearing run (F.13) is scheduled and its log shows normal results.

Red flags: GR/IR items older than 180 days. Large MR11 write-offs by the person who receives goods. F.13 not run for months.

Part Four: Following the Money In (Order-to-Cash and Revenue)

Control 18 Credit Limits Are Real and Credit Holds Are Not Overridden Casually

Control objective: Sales orders exceeding credit limits are blocked and released only by authorized credit personnel.

Audit type: Financial statement (allowance for doubtful accounts), operational, fraud

Run this: FD32 (ECC credit master, display), UKM_BP (S/4HANA credit management), VKM1 (Blocked SD Documents), VKM4 (all released documents), OVA8 (automatic credit control settings, display), FBL5N, FD10N

Test procedure

In OVA8 (display), read the credit check settings. Is the check active for the relevant risk categories and order types? Is the reaction "warning" or "error"? A warning does not block anything.
Run VKM4 for the period to see released documents, with the releasing user. Cross-check in SUIM who holds VKM1 authorization. Sales personnel releasing their own customers' credit blocks is a classic SoD conflict.
Sample customers with large receivables in FD10N. In FD32 or UKM_BP, compare the credit limit to the exposure and to the last credit review date. In FBL5N, look at payment behavior.
Check for customers with credit limit changes just before large orders.

Red flags: Credit limits raised by a sales user. "Unlimited" credit limits for a mid-sized customer. Releases concentrated at quarter-end.

Control 19 Everything Shipped Gets Billed, and Nothing Is Billed Early

Control objective: Revenue is recorded completely (all deliveries are billed) and in the correct period (nothing is billed before it ships, and nothing ships and is billed before the customer has control).

Audit type: Financial statement, SOX process control, fraud

Run this: VF04 (Billing Due List), VL06O (Outbound Delivery Monitor), VFX3 (Release Billing Documents to Accounting), VF05 (List of Billing Documents), VA05 (List of Sales Orders), VF03, VL03N, VA03, V.23 (sales documents blocked for billing)

Test procedure

Completeness. Run VF04 as of period end. Everything on that list has been delivered but not billed. Each item is unrecorded revenue (and possibly an unrecorded receivable). Age it.
Accounting release. Run VFX3. This lists billing documents that exist in SD but have not posted to FI, usually because of an account determination error or a posting period problem. These are invoices the customer may have received but the ledger does not show. At quarter-end, this list should be empty.
Cutoff. From VF05, take the last 20 billing documents before period end and the first 20 after. In VF03, use Document Flow to see the delivery and goods issue dates. Billing date before goods issue date is a cutoff exception. For bill-and-hold or consignment arrangements, ask for the specific accounting analysis.
Blocked for billing. Run V.23 for orders held from billing and read the reasons.
Delivery without goods issue. In VL06O, look for deliveries created but not posted as goods issue for more than a few days. Product may be sitting on the dock, or the delivery is fictitious.

Red flags: Spike in billing on the last day of the quarter with goods issue in the next quarter. Billing documents released to accounting manually in bulk after period end. Deliveries to the same address as the sales rep.

Control 20 Credit Memos, Returns, and Manual Pricing Are Approved

Control objective: Reductions to revenue and non-standard pricing are authorized and reasonable.

Audit type: Fraud, financial statement, anti-corruption (discounts as disguised kickbacks)

Run this: VA05 (filter order types for credit memo requests, returns, free-of-charge deliveries), VF05 (billing types G2 credit memo, RE returns, L2 debit memo), VF03, VK13 (display condition records), VK12 change history via table KONH / KONP, PRCD_ELEMENTS (S/4HANA pricing conditions)

Test procedure

Run VA05 for credit memo request and return order types. Sort by creator and by customer. Credit memo requests usually carry a billing block that requires release; check who released.
In VF03, open a sample of credit memos and read the Order Reason. "Price adjustment" and "goodwill" with no reference to a dispute are worth a question.
Manual pricing: in VA03, the Conditions tab shows condition types. Manually entered conditions are flagged (the "manual" indicator). Extract from PRCD_ELEMENTS (S/4HANA) or KONV (ECC) the orders with manual price overrides and compare the discount percentage against policy and against the sales rep's commission.
Free-of-charge orders and samples: VA05 by order type. Quantities to distributors and to public-sector customers deserve a specific look for anti-corruption purposes.

Red flags: One sales rep with triple the credit memo rate of peers. Manual discounts that push pricing exactly to a customer's requested number. Free goods to a government hospital ahead of a tender.

Control 21 Customer Master Changes and Receivables Aging

Control objective: Customer master changes are controlled; receivables are aged, monitored, and provided for.

Audit type: Financial statement, fraud

Run this: XD03 / FD03 (ECC), BP (S/4HANA), S_ALR_87012182 (Display Changes to Customers), FBL5N, FD10N, S_ALR_87012168 (Due Date Analysis for Open Items), S_ALR_87012178 (Customer Open Item Analysis by Balance of Overdue Items), F150 (dunning history)

Test procedure

Run S_ALR_87012182 for the period and look at changes to payment terms, dunning block, dunning procedure, reconciliation account, and address. Extended payment terms and dunning blocks applied by sales users are ways to hide a customer who is not paying.
Run S_ALR_87012178 as the aging. Reconcile the total to the AR control account in FAGLB03. Test the aging buckets by picking items and confirming the invoice date in FBL5N.
Look at credit balances in FD10N (customers who have overpaid or been double-credited) and at unapplied cash in FBL5N (payments not matched to invoices; a lapping scheme leaves a trail here).
Review dunning: F150 history for whether dunning actually runs and whether specific customers are excluded.

Red flags: Receivables aged over 180 days with no allowance. Customers with the sales rep's phone number in the master. Unapplied cash growing quarter over quarter.

Part Five: Inventory (Existence, Valuation, and Shrinkage)

Control 22 Sensitive Movement Types Are Watched

Control objective: Goods movements that bypass normal purchasing and sales processes are authorized and explained.

Audit type: Fraud, financial statement, operational

Run this: MB51 (Material Document List), MIGO (display mode), MB03 (ECC only; obsolete in S/4HANA, use MIGO), MMBE, MB52, MB5B, SE16N on MSEG / MKPF (ECC) or MATDOC (S/4HANA)

A validation note: In S/4HANA, MB03 and the whole MB0x/MB1x family are on the simplification list and replaced by MIGO. MB51 continues to work and reads the new MATDOC table.

Test procedure

Run MB51 for the period with these movement types, individually or as a list:
- 561 / 562 — initial stock entry and reversal. There is no reason to post an initial stock entry after go-live except a legacy migration or a plant opening.
- 501 / 502 — goods receipt without a purchase order. Inventory appears from nowhere with no vendor obligation.
- 551 / 552 — scrapping. This is where stolen inventory is written off.
- 201 / 202 — goods issue to cost center. Inventory consumed with no production or sales order.
- 309 — transfer posting material to material. A way to reclassify obsolete stock as good stock or the reverse.
- 701 through 708 — physical inventory differences.
- Z-movement types — custom types; ask what each does.
Add the user, the date, the time, and the reason code to the layout. Sort by user and by value (use MB51 with the "Accounting Documents" option to see the value, or MB5B for stock on a date).
Sample and trace to approvals: scrapping should have a scrap authorization, goods issue to cost center should have a requisition, 501 receipts should have an explanation.
Look for reversals: a 551 followed by a 552 for the same material and quantity is either a mistake or a test of whether anyone is watching.

Red flags: Scrapping concentrated in one storage location and one user. Weekend movements. Movement type 501 used to bring in returned goods that were credited to the customer twice.

Example: A warehouse lead scrapped 3 to 5 cartons of a high-value electronics component each week under movement type 551 with reason code "damaged." Over 18 months, 190,000 of product left through the loading dock with clean paperwork. MB51 filtered by movement type 551 and sorted by user made the pattern obvious in one screen.

Control 23 Physical Counts Are Complete and Differences Are Explained

Control objective: Book inventory is verified against physical inventory, differences are investigated, and adjustments are approved.

Audit type: Financial statement, fraud, operational

Run this: MI03 (display physical inventory document), MI20 (List of Inventory Differences), MI24 (Physical Inventory List), MIDO (Physical Inventory Overview), MI07 (post differences, note access), MB52 (Warehouse Stock), MB5B (Stock on Posting Date)

Test procedure

Run MIDO for the year to see which materials and storage locations were counted and which were not. Compare the coverage to policy. Cycle-count programs that never reach high-value or slow-moving items are common.
Run MI20 for counted documents with differences. Look at the count-versus-book variance in quantity and value. Confirm the recount and approval for differences above threshold, and who posted the adjustment (MI07). The counter and the poster should be different people.
In MI03, check for count documents that were opened, never counted, and deleted or left open across period end (stock is frozen only if the freeze indicator is set).
For a year-end observation, use MB52 for the book quantities on the count date, and MB5B if you need a historical date.

Red flags: Counts posted with zero differences on 100 percent of items in a large warehouse (someone typed the book quantity). Recounts always "resolve" the difference to zero. The same person counts and posts.

Control 24 Inventory Is Valued Correctly and Price Changes Are Controlled

Control objective: Inventory is carried at the correct cost; manual price changes and lower-of-cost adjustments are authorized.

Audit type: Financial statement, SOX process control

Run this: MB5L (List of Stock Values: Balances), CKM3N (Material Price Analysis), CKMB, MR21 / MR22 (manual price change and debit/credit, note access), CKMPCD (display price change documents), CK11N / CK13N (cost estimate), MRN0 / MRN1 / MRN2 (lowest value determination), MC46 / MC50 (slow-moving and dead stock, LIS-based; still runs in most S/4HANA systems but the Fiori "Slow or Non-Moving Materials" app is the intended replacement)

Test procedure

Run MB5L at period end. It compares the inventory subledger (material valuation) to the GL inventory accounts. Any difference is a direct financial statement issue and usually points to manual postings on the inventory GL account (check Control 10 and FBL3N).
Pull CKMPCD for the period to see every manual price change (MR21) and value adjustment (MR22). Each one moves inventory value without a physical movement. Review the user, the amount, and the approval.
In CKM3N (if material ledger is active, which it is by default in S/4HANA), open a sample of high-value materials and look at the price determination and the variance components. Understand whether actual costing is closing properly.
Run MC46 for slow-moving stock and compare to the obsolescence reserve. Then check whether MRN0/MRN1 (lowest value) were run and how the result was used.

Red flags: MR21 price increases right before year-end on materials with large quantities. MB5L differences carried forward. Slow-moving stock reports that management has never seen.

Part Six: Fixed Assets (Existence, Completeness, Depreciation)

Control 25 The Asset Register Is Complete, Depreciating, and Free of Ghosts

Control objective: Capital expenditures are capitalized correctly, assets exist, depreciation runs, and disposals are recorded.

Audit type: Financial statement, SOX process control, fraud

Run this: AS03, AW01N (Asset Explorer), AR01 (Asset List), S_ALR_87011963 (Asset Balances), S_ALR_87011990 (Asset History Sheet), S_ALR_87012050 (Asset Acquisitions), S_ALR_87012052 (Asset Retirements), S_ALR_87012054 (Intracompany Transfers), S_ALR_87012056 (Directory of Unposted Assets), S_ALR_87012037 (Changes to Asset Master Records), AFAB (depreciation run, note access), AFBP (Depreciation Posting Log), S_ALR_87012936 (Depreciation Simulation), KOB1 (internal order line items for AUC), IH08 (Equipment List), ABAVN / ABAON (retirement, note access), AJAB / AJRW (year-end close and fiscal year change)

Test procedure

Rollforward. Run S_ALR_87011990 (asset history sheet) for the year. It gives opening balance, acquisitions, retirements, transfers, depreciation, and closing balance by asset class. Tie the closing net book value to the GL. Tie the acquisitions to S_ALR_87012050 and retirements to S_ALR_87012052.
Additions. From S_ALR_87012050, sample additions. In AW01N, look at the transactions and the capitalization date. Trace to the PO or the AUC settlement. Look at asset class and useful life against policy. Ask whether repairs and maintenance are being capitalized (compare the asset description to the vendor and the GL account).
Construction in progress. For assets under construction, run KOB1 on the investment orders or filter the history sheet on the AUC class. Age the balances. AUC that never settles is either an abandoned project that should be impaired or a deliberate deferral of depreciation.
Depreciation. Check AFBP to confirm the depreciation run posted every period. Use S_ALR_87012936 to recalculate depreciation and compare it to what posted. In AW01N, look at individual assets for manual depreciation adjustments.
Existence. Run AR01 or S_ALR_87011963 and select a sample to physically verify. Run IH08 for the equipment list and match it to the asset register; equipment with no asset, or assets with no equipment, need explanation. Run S_ALR_87012056 for asset master records with no postings (created but never capitalized), a housekeeping issue that can also hide fictitious assets waiting for a posting.
Retirements. From S_ALR_87012052, review the gain or loss on each retirement and who posted it. Scrapping of fully depreciated assets is routine; scrapping of a nearly new asset with no proceeds is not.
Master changes. Run S_ALR_87012037 for changes to useful life, depreciation key, and cost center. A useful life extended from 5 to 15 years cuts depreciation expense by two-thirds.

Red flags: Depreciation not run for a period. Useful lives changed in bulk before year-end. Assets located at a cost center that closed years ago. Retirements posted by the same user who created the asset.

Part Seven: Intercompany

Control 26 Intercompany Balances Agree and Are Eliminated

Control objective: Transactions between group companies are recorded symmetrically, reconciled, and eliminated in consolidation.

Audit type: Financial statement, anti-corruption (intercompany is a favored channel for moving funds to a jurisdiction where bribes are paid)

Run this: FBU3 (Display Cross-Company Code Transaction), OBYA (intercompany clearing account configuration, display), FBICR3 (Intercompany Reconciliation, ECC), ICMR apps in S/4HANA (Intercompany Matching and Reconciliation), FBL3N filtered by trading partner, S_ALR_87012287 with trading partner field

Test procedure

In OBYA, note the clearing accounts configured between each company code pair. Then run FBL3N on those accounts. Open items are unreconciled intercompany.
Run the reconciliation report (FBICR3 in ECC or the ICMR matching app in S/4HANA) at period end. Review the unmatched items and their aging.
Check that the trading partner field (VBUND) is populated on intercompany postings. Without it, consolidation cannot eliminate correctly. A query on BSEG or ACDOCA for the intercompany accounts with VBUND blank finds the gaps.
Read the descriptions on large intercompany management fees, royalties, and "services." Anti-corruption investigators have repeatedly found that payments to third-party agents in high-risk countries were funded through intercompany charges labeled as consulting or marketing support.

Red flags: Intercompany differences written off to other income. Management fees to a subsidiary with no employees. Round-number intercompany loans repaid in cash.

Part Eight: Change Management and IT Operations (The Other Two ITGC Pillars)

Control 27 Production Is Locked and Changes Come Only Through Transports

Control objective: No direct changes to programs or configuration in production; all changes go through a controlled path with approval and testing.

Audit type: SOX ITGC

Run this: SCC4 (client settings, display), SE06 (system change option, display), STMS (Import History), SE03 (transport tools, display), SE09 / SE10 (transport requests), SE16N on E070 / E071 / TMSBUFFER

Test procedure

Open SCC4, double-click the production client. Under Changes and Transports for Client-Specific Objects, the setting should be No changes allowed. Under Cross-Client Object Changes, it should be No changes to Repository and cross-client Customizing objects. Take a screenshot; this is the single most important ITGC screenshot in SAP.
Open SE06, choose System Change Option. The global setting should be Not modifiable. Also review the namespace and software component settings.
In STMS, open Import History for the production system for the period. Export the list of transports with date, user, and description. Select a sample and trace each back to the change ticket, the approval, the test evidence, and the separation between developer, tester, and importer. The person who imports to production (usually a Basis role) should not be the developer.
Look for transports imported outside the release calendar, at unusual hours, or with the "overwrite originals" or "ignore predecessor" options. Look for the same user across development and import.
Ask about the exception process: were SCC4 or SE06 ever opened during the year? If the security audit log is active, look for SCC4 and SE06 executions. Table logging on T000 (Control 28) also captures SCC4 changes.

Red flags: SCC4 set to "Changes without automatic recording." Transports imported by a developer account. A change request with 400 objects described as "misc fixes."

Control 28 Table Logging Is On and Direct Table Edits Are Visible

Control objective: Changes to customizing and sensitive master tables are logged and reviewable; direct table maintenance in production is restricted.

Audit type: SOX ITGC, fraud

Run this: SCU3 (Table History), RZ11 for parameter rec/client, SE13 (table technical settings, display, "Log data changes" flag), SE16N_CD_KEY and SE16N_CD_DATA (SE16N change logs), SUIM for SM30, SM31, SE16N, SE38, SA38, SE37 access and for S_TABU_DIS / S_TABU_NAM with change activity, S_DEVELOP with debug activity

Test procedure

Check rec/client in RZ11. If it is OFF, table logging is disabled and SCU3 will be empty regardless of what the table settings say. SAP's Security Baseline Template expects it on for production.
In SCU3, run Analysis of Changed Customizing Objects and Tables for the period. Focus on tables that drive controls: T001B (posting periods), T003 (document types), T169G (tolerance limits), T043T (payment tolerances), T042 (payment program), T000 (client settings), TSTC (transaction codes). Any change should map to a transport or a documented emergency change.
Through SUIM, find who can change tables directly with SM30 / SM31 and who holds S_TABU_DIS or S_TABU_NAM with activity 02 for sensitive table groups. In production, this list should be very short.
Query SE16N_CD_KEY for the period. SE16N writes a change log when someone uses it with edit capability. The old &SAP_EDIT trick was disabled by SAP in 2010, but the logging table remains a good place to check whether anyone found another route.
Check who holds S_DEVELOP with object type DEBUG and activity 02 (debug with replace). This authorization lets a user change variable values at runtime and bypass any check in any program. In production, nobody in the business should have it, and IT holders should be under emergency access.

Red flags: rec/client OFF. Developer debug-replace in production. Tolerance table changed the day before a large invoice and changed back after.

Control 29 The Security Audit Log Is On, Configured, and Reviewed

Control objective: Security-relevant events are recorded, retained, and monitored.

Audit type: SOX ITGC, fraud, anti-corruption (the log is the evidence source for every investigation)

Run this: RSAU_CONFIG (S/4HANA and NetWeaver 7.50+; SM19 in older ECC), RSAU_READ_LOG (SM20 in older ECC), SM21 (System Log), SM18 (delete old logs, note access), RZ11 for rsau/* parameters

Test procedure

Open RSAU_CONFIG (or SM19). Confirm the log is active, which clients and users it covers (the recommendation is all clients, all users, with a filter to capture at least: logon successes and failures, transaction starts, report starts, RFC calls, user master changes, and all events for critical users like SAP*, DDIC, firefighter IDs, and interface users). The DSAG guidelines and SAP's own baseline publish recommended filter sets.
Check retention. Ask how long files are kept and whether they are forwarded to a SIEM. Ninety days of local retention with no forwarding is a weak position for a company subject to investigations.
Run RSAU_READ_LOG (or SM20) for a sample period and confirm the log actually contains events. An "active" configuration writing to a full file system produces nothing.
Confirm somebody reviews it. Ask for the last three review sign-offs and the exceptions raised.
Read SM21 for the period for repeated failed logons, lock-outs of critical users, and "user SAP* logged on" entries.

Red flags: Audit log inactive in production. Filters excluding the users with the most access. Log files deleted with SM18 by the same administrators the log is meant to watch.

Control 30 Batch Jobs and Interfaces Run Correctly and Only When Scheduled

Control objective: Critical automated processes (payment runs, depreciation, billing, interfaces) execute completely, on schedule, under controlled user IDs, and failures are handled.

Audit type: SOX ITGC (operations), financial statement completeness

Run this: SM37 (Job Overview), SMX (own jobs), SM36 (define job, note access), SM35 (Batch Input Sessions), SM58 (Transactional RFC errors), WE02 / WE05 / BD87 (IDoc monitoring), SXMB_MONI (PI/PO messages, where applicable), SM13 (update records), SM12 (lock entries)

Test procedure

In SM37, select all jobs for the period with status Cancelled. Review the critical ones (payment run F110 steps, depreciation RAPOST2000, billing RV60SBAT, interface jobs) and confirm each cancellation was resolved and re-run. Then select jobs by job creator; jobs scheduled under a personal user ID rather than a technical batch user are a control gap because they fail when the person leaves and they are harder to monitor.
Look for jobs scheduled ad hoc (not periodic) that run programs with financial impact. SM37 shows the step program name.
In SM35, review batch input sessions processed in the period. Mass changes to vendor masters or mass postings through batch input bypass the individual-transaction approval flow. Confirm each session was authorized. Sessions with errors that were "processed in foreground" by a user mean the user manually intervened on each record.
For interfaces feeding financial data (payroll, bank, sales channels), check WE02 / BD87 for IDocs in error status and SM58 for stuck RFC calls. Errors sitting for weeks mean transactions that never reached the ledger.
SM13 shows failed updates (V1/V2). A failed update is a transaction the user thinks posted but did not.

Red flags: Payment run scheduled under a departing employee's ID. IDocs in status 51 (error) for months. Batch input sessions named "temp" processing 5,000 vendor changes.

Control 31 Sensitive Output Does Not Leak Through Spool

Control objective: Printed and spooled financial and personal data goes only to authorized devices and is retained appropriately.

Audit type: IT review, privacy

Run this: SP01 (Spool Requests), SP02 (own spool requests), SPAD (output device administration, display), SUIM for S_SPO_ACT with display of other users' spool

Test procedure

In SP01, filter for spool requests from payment runs, payroll, and vendor listings. Check the output device (SPAD shows where it physically points) and the retention period.
In SUIM, identify who can display other users' spool requests (S_SPO_ACT with a value other than the user's own). Reading someone else's spool is an easy way to see a payment file or a salary list.

Red flags: Payroll spooled to a shared front-end printer. Spool retention of 90 days for check print files. Broad S_SPO_ACT access.

Part Nine: Anti-Corruption Analytics Inside SAP

The DOJ's September 2024 update to its compliance program guidance asks specifically whether companies use their own data to detect misconduct and whether compliance has access to that data on par with the business. The SEC and DOJ have made the point concretely: in January 2024, SAP SE itself agreed to pay over 220 million dollars to resolve FCPA charges related to payments through third-party intermediaries in South Africa, Indonesia, and other markets. If the software company can miss it in its own environment, so can its customers. Here is where to look.

Control 32 Third-Party Payments in High-Risk Situations Are Visible

Control objective: Payments to agents, consultants, distributors, and government-related parties are identified, justified, and consistent with contracts and due diligence.

Audit type: Anti-corruption, fraud

Run this: FBL1N and FBL3N (by GL account), S_ALR_87012086 (vendor list with country, account group, industry), XK03 / BP, ME2L, FBCJ (cash journal), KSB1 (cost line items for cost centers such as government affairs, marketing, sponsorships), KE5Z, SE16N on LFA1 / LFB1 / BUT000

Test procedure

Build the vendor risk list. From S_ALR_87012086 or LFA1, pull all vendors with country, account group, industry key, and creation date. Flag: vendors in countries with high Corruption Perceptions Index risk, vendors created and paid within the same month, vendors with generic names ("Consulting Services Ltd"), vendors with a PO box or freight forwarder address, and vendors with no tax ID.
Pull the spend on sensitive GL accounts through FBL3N: consulting fees, commissions, marketing support, sponsorships, donations, gifts and entertainment, travel for third parties, facilitation-type expense accounts, legal settlements, and "other services." Sort by vendor and by cost center.
For payments to intermediaries, trace to the contract, the due diligence file, and the deliverable. A commission of 15 percent on a government contract paid to a vendor set up two weeks before the award is a textbook pattern.
Read the FBCJ cash journal for every company code in a high-risk country. Cash advances to employees "for customs," "for permits," or "for facilitation" need scrutiny.
Look at KSB1 for cost centers named government relations, public affairs, tender office, or similar. Look at the vendors and the texts.
Check for round-number invoices with vague descriptions, invoices without POs (FBL1N document type KR versus RE), and split invoices under local approval thresholds (Control 14).
Cross-reference employee HR data (PA20, infotypes 0002, 0006, 0009) against vendor addresses and bank accounts for conflicts of interest.

Red flags: Success fees. Payments to a vendor's affiliate in a different country than the services. "Marketing support" to a distributor that equals the discount the customer did not get. Charitable donations to a foundation linked to an official.

Example: A subsidiary paid a "logistics consultant" 4,200 per month for two years with no PO, no deliverable, and no contract in the vendor file. The vendor's address in LFA1 matched the home address of a customs official's spouse, which surfaced only because someone compared the vendor address to public records. The FBL1N pull took ten minutes; the finding took the company two years and outside counsel to close.

Control 33 Ghost Employees and Payroll Diversion

Control objective: Payroll is paid only to real, current employees at approved rates and to their own bank accounts.

Audit type: Fraud, anti-corruption

Run this: PA20 (display HR master), PA30 (note access), S_AHR_61016369 (Employee List) or your HR extract, PC_PAYRESULT (display payroll results), PC00_M99_CWTR (Wage Type Reporter), SE16N on PA0009 (bank details), PA0006 (address), PA0000 (actions)

Test procedure

Pull the employee list with hire and termination dates and compare to payroll results (PC_PAYRESULT or the wage type reporter). Employees paid after termination are the first check.
Query PA0009 for duplicate bank accounts across employees and for bank accounts that match vendor bank accounts (Control 12).
Look for employees with no address, no tax ID, no time records, and no manager, or whose master data was created by payroll staff rather than HR.
Review wage type totals period over period; a "one-time bonus" wage type appearing every month for one person is not one-time.

Red flags: Two employees, one bank account. Employees who never take vacation and have no badge activity. Payroll master changes by the person who runs payroll.

Part Ten: Making Your SAP Evidence Hold Up

A finding is only as good as the evidence behind it, and PCAOB inspections have focused heavily on how auditors validate reports they rely on (often called IPE, information produced by the entity, or EUC when it leaves the system). A few habits keep SAP evidence defensible.

Capture the selection screen. Every report above has parameters. Screenshot the selection screen before you execute so a reviewer can see the company code, date range, and filters. A vendor change report without the date range is not evidence.

Reconcile record counts. When you export from FBL3N or MB51 to a spreadsheet, note the record count and total in SAP and confirm they match the spreadsheet. ALV grids can hide filtered rows.

Prefer standard reports over custom programs. Standard SAP reports (the S_ALR series, FBL*N, MB51) are SAP-delivered and their logic is documented. A custom Z-report is itself something you must test before relying on it. If the client insists on a Z-report, run the standard equivalent alongside it once and reconcile.

Understand the data model you are querying. In ECC, financial line items live in BSEG with totals in GLT0 and index tables like BSIS/BSAS. In S/4HANA, the Universal Journal ACDOCA holds FI and CO line items together, the old totals tables are compatibility views, material documents live in MATDOC, and customer and vendor data are in the business partner tables (BUT000, BUT0BK) with LFA1/KNA1 maintained as synchronized copies. A query built for ECC will still run in S/4HANA in most cases but may not tell you what you think it does.

Ask for display, not extracts. Whenever possible, sit at the screen yourself or have the auditee execute the transaction in front of you. An emailed spreadsheet has already been through someone else's filter.

Quick Reference: Transaction Codes by Cycle

Codes marked ECC→S/4 have a noted change in S/4HANA. Everything else works the same in both.

Cycle	Transaction	What it shows	Notes
Access & Security	SUIM	User, role, profile, and authorization reports	Core audit tool
	SU01D	User master display
	PFCG	Role composition (use display)
	RSUSR002 / 003 / 200 / 100N	Users by criteria / standard user check / logon dates / user change docs	Run via SA38 or from SUIM
	RZ11 / RSPARAM / TU02	Profile parameters and change history
	SECPOL	Security policies
	ST03N / STAD	Transaction usage	STAD short retention
	RSAU_CONFIG / RSAU_READ_LOG	Security audit log	ECC→S/4: replaces SM19 / SM20
	SM21	System log
	GRAC_SPM, GRAC_BATCH_RA	GRC firefighter logon, batch risk analysis	GRC AC 10.x / 12.0; EAM logs reviewed in web front end
Change Mgmt	SCC4	Client change settings
	SE06	System change option
	STMS	Transport import history
	SCU3	Table change history	Needs rec/client ON
	SE16N	Table display	Check SE16N_CD_KEY for edit logs
	SM37 / SMX / SM36	Background jobs
	SM35	Batch input sessions
	SM58 / WE02 / BD87	RFC and IDoc monitoring
	SP01 / SP02 / SPAD	Spool and output devices
General Ledger	FB03	Display document
	FBV3 / FBV0	Parked documents
	FBL3N / FAGLL03	GL line items	ECC→S/4: also FAGLL03H, Fiori "Display Line Items in General Ledger"
	FS10N / FAGLB03	GL balances
	OB52	Posting periods
	S_ALR_87012287 / 89 / 91	Document journals	S/4: Fiori "Audit Journal" app
	S_ALR_87012341 / 42	Duplicate invoice numbers / number gaps
	S_ALR_87012284 / 277	Financial statements / GL balances
	S_ALR_87012308	GL account changes
	FBD3 / F.14 / F.15	Recurring entries
	FBU3 / OBYA / FBICR3	Intercompany	ECC→S/4: ICMR apps
	KSB1 / KS03 / KE5Z / KCH3 / KOB1 / KO03	Controlling line items and masters
Procure-to-Pay	ME23N	Display PO	Replaces ME23
	ME2N / ME2L / ME2M / ME2K	PO lists
	MIR4 / MIR6 / MRBR	Invoice display, overview, blocked release
	OMR6 / OMRDC	Tolerances, duplicate check config
	FBL1N / FK10N	Vendor line items and balances	ECC→S/4: also FBL1H
	XK03 / MK03 / FK03	Vendor master	ECC→S/4: BP
	S_ALR_87012086 / 089 / 090	Vendor list, changes, critical changes
	FK08 / FK09	Confirm sensitive field changes
	F110 / FBZP	Payment run and configuration
	FCHN / FCH2 / FCH8 / FCH9	Check register, check by payment doc, cancel/void	FCHI = check lots, not a register
	FBCJ	Cash journal
	MB5S / MR11 / MR11SHOW	GR/IR
Treasury	FF_5 / FEBAN / FEB_BSPROC	Electronic bank statement import and processing	FEB_BSPROC in S/4
	FF67	Manual bank statement
	FF7A / FF7B	Cash position / liquidity forecast	S/4: Fiori Cash Position
	FI03 / FI04 / FI12	Bank master, changes, house banks
Order-to-Cash	VA03 / VA05	Sales orders
	VF03 / VF05 / VF04 / VFX3	Billing documents, billing due list, release to accounting
	VL03N / VL06O / VT03N	Deliveries, delivery monitor, shipments
	V.23 / VKM1 / VKM4	Billing blocks, credit blocks, releases
	FD32 / OVA8	Credit master and config	ECC→S/4: UKM_BP
	FBL5N / FD10N	Customer line items and balances
	XD03 / VD03 / FD03	Customer master	ECC→S/4: BP
	S_ALR_87012182 / 168 / 178	Customer changes, due date analysis, aging
	VK13	Pricing condition records
Inventory	MM03 / MM04	Material master and changes
	MB51	Material document list	Reads MATDOC in S/4
	MIGO	Goods movement display	ECC→S/4: replaces MB03
	MMBE / MB52 / MB5B	Stock overview, warehouse stock, stock on date
	MI03 / MI20 / MI24 / MIDO / MI07	Physical inventory
	MB5L	Stock values vs GL
	CKM3N / CKMB / CKMPCD	Material ledger and price change docs
	MR21 / MR22	Manual price changes	Restrict access
	MC46 / MC50 / MD04	Slow-moving, dead stock, stock/requirements	LIS-based, on S/4 simplification list
Fixed Assets	AS03 / AW01N	Asset master, asset explorer
	AR01 / S_ALR_87011963	Asset lists and balances
	S_ALR_87011990	Asset history sheet
	S_ALR_87012050 / 052 / 054 / 056 / 037	Acquisitions, retirements, transfers, unposted assets, master changes
	AFAB / AFBP / S_ALR_87012936	Depreciation run, log, simulation
	ABAVN / ABAON	Retirements	Restrict access
	IE03 / IH08	Equipment master and list
HR	PA20	HR master display
	PC_PAYRESULT / PC00_M99_CWTR	Payroll results, wage type reporter

Pages

Useful SAP T-Code List for Auditing: The SAP Auditor’s Field Guide: Controls, T-Codes, and Review Procedures for SOX, Fraud, and Financial Reporting

Essential SAP Transaction Codes For Auditing: A Comprehensive Reference By Business Cycle

Why Transaction Code Fluency Matters For SAP Auditors

Procure To Pay

Order To Cash

Inventory And Materials Management

Asset Management

Finance And General Ledger

Treasury And Cash Management

User Access And Security

Change Management And System Administration

SAP GRC Access Control

S/4HANA And Fiori Considerations For Auditors

From Transaction Codes To Audit Intelligence

How To Read Each Control

Part One: Who Can Do What (Access Controls)

Control 1 Nobody Should Hold the Keys to the Whole Kingdom

Control 2 Standard Users Locked Down and Password Rules That Mean Something

Control 3 Segregation of Duties You Can Prove, Not Just Assert

Control 4 People Who Left Should Not Still Be Logging In

Control 5 Emergency Access Is Really for Emergencies

Part Two: Is the General Ledger Telling the Truth (Financial Reporting Controls)

Control 6 Manual Journal Entries Get the Scrutiny the Standards Demand

Control 7 Closed Periods Stay Closed

Control 8 Parked, Reversed, and Recurring Entries Are Not Hiding Anything

Control 9 No Gaps in the Story: Document Numbers and Duplicate Invoices

Control 10 GL Account Master Data and Reconciliation Accounts Are Stable

Control 11 The Trial Balance Actually Ties to the Financial Statements

Part Three: Following the Money Out (Procure-to-Pay and Disbursement Fraud)

Control 12 Vendor Bank Account Changes Are the Single Most Dangerous Master Data Field

Control 13 Three-Way Match Works and Blocked Invoices Are Released by the Right People

Control 14 Purchase Orders Are Not Split to Dodge Approval Limits

Control 15 The Payment Run Is Controlled and Manual Payments Are the Exception

Control 16 Bank Statements Are Reconciled Inside the System, and Exceptions Are Cleared

Control 17 GR/IR and Accrual Completeness

Part Four: Following the Money In (Order-to-Cash and Revenue)

Control 18 Credit Limits Are Real and Credit Holds Are Not Overridden Casually

Control 19 Everything Shipped Gets Billed, and Nothing Is Billed Early

Control 20 Credit Memos, Returns, and Manual Pricing Are Approved

Control 21 Customer Master Changes and Receivables Aging

Part Five: Inventory (Existence, Valuation, and Shrinkage)

Control 22 Sensitive Movement Types Are Watched

Control 23 Physical Counts Are Complete and Differences Are Explained

Control 24 Inventory Is Valued Correctly and Price Changes Are Controlled

Part Six: Fixed Assets (Existence, Completeness, Depreciation)

Control 25 The Asset Register Is Complete, Depreciating, and Free of Ghosts

Part Seven: Intercompany

Control 26 Intercompany Balances Agree and Are Eliminated

Part Eight: Change Management and IT Operations (The Other Two ITGC Pillars)

Control 27 Production Is Locked and Changes Come Only Through Transports

Control 28 Table Logging Is On and Direct Table Edits Are Visible

Control 29 The Security Audit Log Is On, Configured, and Reviewed

Control 30 Batch Jobs and Interfaces Run Correctly and Only When Scheduled

Control 31 Sensitive Output Does Not Leak Through Spool

Part Nine: Anti-Corruption Analytics Inside SAP

Control 32 Third-Party Payments in High-Risk Situations Are Visible

Control 33 Ghost Employees and Payroll Diversion

Part Ten: Making Your SAP Evidence Hold Up

Quick Reference: Transaction Codes by Cycle

Google