How to Audit the SAP S/4HANA Record-to-Report Cycle

Practical Audit Controls for the SAP S/4HANA Record-to-Report Cycle

Most finance audits focus on the final reports.

That is too late.

If you want reliable financial reporting in SAP S/4HANA, you need to look earlier. At posting periods. At journal entry controls. At field status logic. At validation rules. At asset settings. At master data. At who can post, who can reopen a period, and who can change document fields after the fact. The balance sheet only tells you the ending story. The controls tell you whether the story can be trusted.

I have seen finance teams with excellent close discipline still struggle because SAP S/4HANA was left at default settings that did not match the business. I have also seen the opposite. A well-configured environment cut period-end stress sharply because errors were prevented before they became close issues. That is the real promise of a strong record-to-report design. Fewer surprises. Better evidence. More confidence in the numbers.

This article sets out a practical framework for auditing the SAP S/4HANA record-to-report cycle. It covers statutory and managerial reporting, enterprise structure, master data, security, common configurable controls, useful reports, and the technical details auditors and GRC teams actually need. As requested, I include transaction codes, relevant tables, key technical field names, and plain-language descriptions.

Understanding the core framework for a SAP S/4HANA record-to-report audit

The record-to-report cycle is different from the other major SAP cycles.

Purchase-to-pay acquires goods and services. Order-to-cash converts demand into cash. Forecast-to-stock supports inventory and production. Record-to-report does something more fundamental. It converts all those underlying transactions into information that management, lenders, regulators, and auditors use to judge the business.

That makes the risk profile unique.

Component 1: Record-to-report is both a reporting process and a control aggregation process

The financial statements are not created by one process. They are the output of many processes converging. Procurement posts liabilities. Sales creates receivables. Asset accounting posts depreciation. Treasury affects bank balances and valuation. Manual journal entries close the gap between economic reality and system timing.

That means the record-to-report audit is partly about financial accounting configuration and partly about whether upstream activity gets represented completely and accurately.

Original implementation tip: Do not audit record-to-report as if it begins with journal entries. Start with the question, “What events should be reflected in the books by this date?” That framing catches timing and completeness issues faster.

Component 2: SAP S/4HANA reduces some risks and sharpens others

SAP S/4HANA brings the Universal Journal, tighter FI-CO integration, more real-time data, and better reporting structures. It also changes where some risks appear. Greater speed means less tolerance for weak close processes. More real-time reporting means poorly controlled master data has faster consequences.

The system helps. It does not think for you.

Original implementation tip: In S/4HANA migrations, challenge every inherited control from SAP ERP. Some are still useful. Some are now redundant. Some are weaker because the process changed underneath them.

Component 3: The strongest controls are usually layered, not single-point

A closed posting period helps. A validation rule helps. A workflow approval helps. A change log review helps. None of these alone solves the full problem of posting integrity.

The most reliable environments layer preventive, detective, and monitoring controls around the same risk.

Original implementation tip: For each material record-to-report risk, design at least one preventive control and one detective or monitoring control. This avoids false confidence when one layer fails.

What Changed in SAP S/4HANA for Record-to-Report

If you are coming from SAP ERP, several changes affect your audit approach for the record-to-report cycle.

The Universal Journal (table ACDOCA) merges financial accounting and controlling into a single data source. Traditional general ledger master data from financial accounting has been merged with cost element master data from controlling, eliminating the risk of inconsistencies and the need for duplicate creation. Time-dependent attributes can now be added to general ledger account numbers and descriptions, creating an audit trail between old and replacement accounts without mining the Changes to G/L Accounts report.

Central Finance centralizes all finance and accounting transactions on a single platform, including transactions from other SAP and non-SAP systems. Real-time consolidation (RTC) was introduced to eliminate data replication to SAP BPC, but has been sunset and replaced by SAP S/4HANA Finance for group reporting since version 1909.

Predictive accounting, currently specific to sales, predicts profitability of incoming sales orders. Advanced compliance reporting, now called the SAP Document and Reporting Compliance framework, replaces numerous legacy country-specific reports. SAP Note 2480067 lists the reports being retired and their replacements. If your organization still uses old reports, they will not reflect recent legal changes.

SAP S/4HANA introduces the ability to upload journal entries from Microsoft Excel templates. The traditional park and post functionality has been replaced with three SAP Fiori apps: Verify General Journal Entries (for requestors), Verify General Journal Entries Inbox (for processors), and Verify General Journal Entries Outbox (for processors). The F_BKPF authorization objects still technically allow traditional park and post settings where users get a 77 pre-enter activity value instead of 01 create, but standard Fiori apps no longer provide a park option. This technique remains available only through the SAP GUI.

Original implementation tip: Check whether your organization is still using reports scheduled for retirement under SAP Document and Reporting Compliance. Run SAP Note 2480067 against your report inventory. I found an organization using a legacy VAT return report that had not been updated for two years of regulatory changes. Their quarterly VAT filing was technically non-compliant because the report excluded transaction categories that new legislation required. The replacement report in the SAP Document and Reporting Compliance framework handled these categories correctly. Nobody had migrated because nobody knew the old report was being phased out.

Record-to-Report Risks That Drive Your Audit Scope

The business impact of risks within financial reporting can be severe. Reporting is tied to regulatory and contractual obligations carrying fines and prohibitions for non-compliance.

Insufficient reporting structures. The organizational model, chart of accounts, and SAP S/4HANA structures must support the capture and reporting of transactions required by financial reporting rules. If configured structures do not allow appropriate categorization, compliance becomes difficult regardless of other process controls.

Inaccurate postings. SAP automatically completes accounting entries for many transactions, but other postings rely on user input. Accounting estimates like reserve calculations may be based on SAP data but posted manually. User errors during these processes create incorrect general ledger postings.

Incomplete general ledger processing. Transactions put on hold or parked will not be posted. Incomplete documents where SAP detects missing information remain off the books. Interface failures during nightly processing runs can go undetected. A batch of invoices sitting on a clerk's desk awaiting processing never reaches the system.

Postings to the wrong accounting period. Near period end, specific rules govern which period receives a transaction. Even quantitatively accurate postings made to the wrong period create technically inaccurate reporting.

Uncollectable receivables overstating accounts receivable. Organizations allowing credit purchases face credit risk. Accounts receivable balances appearing as assets on the balance sheet require collectability assessment for accurate reporting.

Inaccurate or incomplete management reports. Cost center or profitability information can affect financial accounting transactions indirectly. Management uses this data for determinations that lead to manual journal entries or adjustments.

Unauthorized document changes. If changes made after initial approval do not receive the same level of scrutiny, unauthorized or inaccurate transactions can reach the general ledger.

Fraudulent transactions. The ACFE estimates that corporations lose 5% of revenue to fraud on average. Whether through earnings manipulation or outright theft, fraudulent transactions cause financial reporting to fall out of compliance.

Understanding the Enterprise Structure for Financial Reporting

The enterprise structure defines how your organization operates in SAP. It affects both reporting (many reports allow filtering by enterprise structure element) and security (numerous authorization objects have field values tied to organizational units). Changes post-implementation are time-consuming and sometimes require reimplementation.

Enterprise structure configuration is accessed through SAP Reference IMG, Enterprise Structure, where organizational units are defined and then assigned to create the hierarchy.

Company (table T880) is the organizational unit representing a single legal entity or group of legal entities. It is the parent for accounting consolidation. SAP S/4HANA delivers a default company G0000.

Credit control area is the organizational unit managing customer credit checks and limits. There is a one-to-many relationship between credit control area and company codes, with the constraint that all company codes in a credit control area use the same currency. Default is 0001.

Company code (table T001) represents a legal entity used for statutory reporting. It contains a segregated set of general ledger accounts, transactions, and audit trails that can generate relevant reports for external reporting. Journal entries are posted to a specific company code. The company code identifier is any four alphanumeric characters. SAP S/4HANA delivers 40 template company codes for common countries.

Business area is used for internal reporting, typically representing a department. Journal entries can be posted to a business area in addition to the mandatory company code. Default is 0001.

Functional area is used for expense-related allocation in cost-of-sales accounting, covering areas like marketing, R&D, sales, and administration. Functional areas are assigned to cost centers.

Segment is a controlling concept representing a portion of a company able to produce external financial statements. It is part of the profit center master record and derived during posting from the assigned profit center.

Profit center (table CEPC) is a managerial accounting element for tracking revenue and expenses by management-oriented organizational view. Profit centers are modeled in a hierarchy and represented by a 10-character alphanumeric code. Their data is considered master data and does not require transport during maintenance.

Cost center (table CSKS) defines where in the organization an expense originates. Like profit centers, cost centers are modeled in a hierarchy with 10-character alphanumeric codes. Their data is also master data.

Controlling area (table TKA01) is the primary organizational unit for managerial accounting. Internal allocations are performed within a controlling area. It can have a one-to-one or one-to-many relationship with company codes. All company codes in a controlling area must use the same operating chart of accounts. Default is 0001.

FM area is used for cash budget management and funds management with a one-to-many relationship to company codes.

Original implementation tip: During every record-to-report audit, verify that the enterprise structure matches the actual legal and operational structure of the organization. I have seen company codes that were created during implementation for entities that were subsequently divested, still active in the system with open posting periods. I have seen business areas that no longer correspond to any operational unit because a reorganization occurred two years after go-live and nobody updated the SAP structure. These mismatches create reporting risks because transactions can be posted to organizational units that no longer have meaningful business owners reviewing them.

Key Configuration Concepts for Auditors

Chart of Accounts

The chart of accounts (table T004) groups general ledger accounts. There is a many-to-one relationship between company codes and the operating chart of accounts used for financial and cost accounting. Additional charts may be country-specific (statutory) or consolidation-related (group chart of accounts).

View chart of accounts configuration through transaction SPRO, navigating to SAP Reference IMG, Financial Accounting, General Ledger Accounting, Master Data, G/L Accounts, Edit Chart of Accounts List. Double-click the relevant chart of accounts. A flag indicating the chart is blocked for adding GL accounts at the company code level is used for centralized GL management.

Fiscal Year Variant

The fiscal year variant (table T009) defines the accounting year characteristics including number of periods, whether periods follow the calendar year, and whether the year is consistent from year to year. Special periods for closing activities can be defined. Company codes are assigned to a single fiscal year variant.

View configuration through transaction SPRO, SAP Reference IMG, Financial Accounting, Financial Accounting Global Settings, Ledgers, Ledger, Fiscal Year and Posting Periods, Maintain Fiscal Year Variant. Select the variant and double-click Period Texts (for calendar month periods) or Periods (for non-calendar periods).

Posting Period Variant

The posting period variant (table T001B) sets which periods accept accounting entries for defined ranges of general ledger accounts. Open periods accept entries. Closed periods do not. A posting period variant can be assigned to one or many company codes, allowing synchronized opening and closing.

Master Data: What Drives Transaction Processing

General Ledger Account Master

General ledger account master data has two categories: chart of accounts data (applying regardless of company code) and company code data (specific to each company code).

View chart of accounts data through transaction FSP3. Key fields include the account type (balance sheet or income statement), the financial statement structure assignment, and language-specific keywords.

View company code data through transaction FS03. Key fields include the field status group assignment (which determines what fields are required, optional, or suppressed when posting to the account), the posting currency, and the tax category. Field status groups can differ by company code, meaning the fields required when posting to the same account can vary between company codes.

Profit Center Master

View through transaction KE53. Profit center master data is time-dependent with start and end dates. Every profit center is assigned to a controlling area and associated with company codes. A dummy profit center receives profit-related postings that cannot be automatically assigned to another profit center for later reallocation.

The standard hierarchy (viewable in transaction KCH6N) must contain all profit centers in the controlling area and defines the roll-up structure. Authorization groups can be added to limit who can interact with profit center data.

Cost Center Master

View through transaction KS03. Similar to profit centers but can be locked for actual postings or planning. The standard hierarchy (viewable in transaction OKENN) must contain all cost centers in the controlling area. Authorization groups restrict maintenance access.

Banking Master

View through transaction FI03. Bank accounts are associated with a country key and bank key. In some countries, the bank account number serves as both bank key and account number.

Original implementation tip: Pay particular attention to the dummy profit center during your audit. If the dummy profit center accumulates large balances, it means postings are not being correctly assigned to operational profit centers. Management decisions based on profit center reporting will be distorted because the dummy center is absorbing costs or revenues that belong elsewhere. Query the profit center master for the dummy indicator and then check the balance of that profit center through profit center reporting. A high dummy profit center balance is a red flag for configuration gaps in profit center derivation rules.

Security Considerations for Record-to-Report

Restricting Postings to Functional Areas

Most general ledger postings occur automatically through daily transaction processing without users recognizing the background accounting entries. Goods receipts post to inventory and recognize payment obligations. Shipments subtract from inventory and trigger customer payment expectations. Some transactions require manual posting, and this ability should be limited because manual postings create data error exposure.

At minimum, restrict general ledger postings by company code using authorization object F_BKPF_BUK (Accounting Document: Authorization for Company Codes). Additional restrictions apply through F_BKPF_BLA (Accounting Document: Authorization for Document Types), F_BKPF_GES (Accounting Document: Authorization for Business Areas), F_BKPF_KOA (Accounting Document: Authorization for Account Types), and F_BKPF_BES (Accounting Document: Authorization for Accounts).

When auditing, verify not just that these authorization objects are assigned to roles, but check whether wildcard values have been granted. If postings are restricted by account type but users hold asterisk values, the restriction provides no practical control.

Limiting Access to Powerful Transactions

Several transactions within the record-to-report process carry disproportionate risk and should be limited to very few personnel.

Transaction F-60 and transaction OB52 open and close accounting periods. Transaction S_ALR_87003642 provides an alternative path. Transaction F.80 performs mass reversal of accounting documents. Transaction FS06 deletes (rather than fully depreciates or retires) assets. Transaction OKP1 locks planned and actual transactions for a controlling area. Transaction CFIN_CO_DOC_CRCT reverses and reposts controlling documents.

Use transaction SUIM to query which users hold authorizations for these transactions. Beyond restricting access, monitor usage independently of the group authorized to perform these functions.

For organizations seeking the strongest control posture, remove these abilities from all standard roles and grant them only at time of need through a firefighter process using SAP Access Control's Emergency Access Management. Once the process is completed and verified, access is removed again.

Authorization Objects for Master Data Control

General ledger account authorization objects control who can create, change, delete, block, and unblock GL master records. F_SKA1_KTP (GL Account: Authorization for Charts of Accounts) restricts by chart of accounts. F_SKA1_BUK (GL Account: Authorization for Company Codes) restricts by company code. F_SKA1_BES (GL Account: Account Authorization) optionally restricts by account number. F_SKA1_AEN (GL Account: Change Authorization for Certain Fields) optionally restricts to defined fields.

Profit center authorization objects include K_PCA_PRC (Profit Centers, restricted by controlling area), K_PCA_MD (Profit Center Master Data, restricted by controlling area and profit center combination), K_PCA_PCA (Responsibility Area Profit Center, restricted by actions and cost elements), and K_PCAP_SET (Planning Hierarchy, restricted by controlling area).

Cost center authorization objects include K_CCA (General Authorization Object for Cost Center Accounting, restricted by defined actions), K_CSKS (Cost Center Master, restricted by controlling area and cost center), and K_CSKS_SET (Cost Center Groups, restricting standard hierarchy maintenance).

Banking authorization objects include F_BNKA_BUK (Banks: Authorization for Company Codes), F_BNKA_MAN (Banks: General Maintenance Authorization), and F_BNKA_MAO (Banks: General Maintenance Authorization by Country).

Original implementation tip: When auditing GL master data security, verify that a controller in one company code cannot change accounting data for all company codes. I have found organizations where the F_SKA1_BUK authorization object was granted with wildcard values across all company codes to every user in the accounting department. The intent was to allow account inquiries across the enterprise. The result was that every accountant could modify GL master data for every legal entity. Separate display and maintenance roles. Grant company code-specific values for maintenance roles. Use wildcard values only for display roles, and only if cross-company code visibility is a legitimate business requirement.

Testing Common Controls: Posting Period Management

The most common control for preventing journal entries from posting to the wrong period is the open and close posting period mechanism.

How Posting Periods Work

An open period accepts postings. A closed period does not. Since SAP S/4HANA is real-time, automated journal entries post as the underlying business event occurs. Manual entries should be posted in the period they occur. Typically only the current period is open, with a brief overlap at period end when both the closing period and the new period may be open simultaneously.

Posting periods are opened and closed through transaction F-60 or transaction OB52. Both effectively edit table T001B (Permitted Posting Periods) directly. Entries are organized by account type: S for general ledger, D for customer, K for vendor, A for assets, M for materials, and the plus sign representing all account types.

SAP S/4HANA allows significant granularity. Periods can differ by account type. They can differ by general ledger account number range within an account type. An Authorization Group field can limit which users can post to open periods, restricting access from all authorized journal entry posters to only those users granted the specific authorization group through security.

To determine which posting period variant is assigned to each company code, run transaction OBY6, double-click the company code, and review the Pstng period variant field in Processing Parameters.

The Internal Controls Maturity Model Applied to Posting Periods

At maturity level 1, SAP S/4HANA issues an error message if the posting date corresponds to a closed period. This is inherent functionality.

At level 2, the responsible party closes the current period and opens the new period as part of a documented periodic closing accounting policy.

At level 3, data validation rules issue a warning if the journal entry date differs from the posting period date by more than a defined number of days, with workflow triggered to ensure approval is recorded.

At level 4, the responsible party periodically reviews table log entries for table T001B and verifies that the prior period was closed in the expected timeframe, that any reopening of a prior or future period is supported by appropriate documentation and approvals, and that journal entries made during any reopened window have been authorized. Exceptions are reviewed with the accountable party.

At level 5, an automated daily process notifies the accountable party of any journal entries posted to a period outside the current posting period. The control is flagged as deficient if the accountable party does not enter a defined reason code within the configured response period.

Testing Posting Period Controls

First, verify the posting period status by viewing the posting period variant through transaction F-60 or OB52, or querying table T001B directly.

Table T001B (Permitted Posting Periods) contains the fields BUKRS (company code), RLDNR (ledger), BKONT (account type), VONKT (from account), BISKT (to account), OPVON (period 1 from), OPBIS (period 1 to), OPJVN (year period 1 from), OPJBS (year period 1 to), OPGVN (period 2 from), OPGBS (period 2 to), OPGJV (year period 2 from), OPGJB (year period 2 to), and AUESSION (authorization group).

Second, verify whether posting periods were updated according to the closing policy. This requires table logging to be active. Run transaction SCU3, click Analyze Logs, enter T001B as the table, set the time period, set Evaluation to Tables, and execute. The log shows when each field was changed, by whom, and the old and new values. If the log shows that posting periods were open for the entire previous year until the middle of the current month, you have identified a significant control gap.

Third, perform outcome-based testing. Table BKPF (Accounting Document Header) captures the CPU date (the server clock date at time of creation) in field CPUDT. Compare CPUDT against the posting date in field BUDAT. Any document where the posting period implied by BUDAT differs from the posting period implied by CPUDT represents a posting to a non-current period. Documents where BUDAT is in a future period are particularly suspicious.

BKPF contains the fields BUKRS (company code), BELNR (document number), GJAHR (fiscal year), BLART (document type), BLDAT (document date), BUDAT (posting date), MONAT (fiscal period), WAERS (document currency), USNAM (user who entered the document), TCODE (transaction code used), CPUDT (entry date on server), CPUTM (entry time on server), and BSTAT (document status where blank is normal, V is parked, and S is noted item).

Original implementation tip: I have encountered organizations that do not have table logging active for their production client. Without table logging on table T001B, there is no realistic way to determine when posting periods were opened or closed during the audit period. You can see the current state but cannot prove it was the same state last month. If table logging is disabled, document this as a limitation in your working papers and consider whether you can rely on the posting period control at all. The control exists, but the evidence to test it does not.

Common Observations on Posting Period Controls

Lack of effective monitoring. Organizations have policies for when periods should open and close but rarely monitor whether it happens on schedule.

Lack of documentation supporting period reopening. When a closed period is reopened, the justification and the specific entries made during the window are frequently undocumented.

Unique posting period variants for each company code when company codes follow similar closing cycles. This creates unnecessary maintenance burden. Grouping company codes with similar patterns under a shared posting period variant reduces effort.

No use of authorization groups near period close. Many organizations do not understand the authorization group field in the posting period table. Using it allows you to enforce the policy of restricting entries in the days before close, moving it from a policy employees should follow to a control SAP enforces.

Testing Common Controls: Journal Entry Data Input Errors

Automatic Account Determination

One of the best ways to reduce data entry errors is to remove the human. SAP S/4HANA enables this through automatic account determination configured in multiple IMG locations. A full list of options can be found by searching for "account determination" and "automatic posting" within the IMG.

Account determination uses transaction keys, three-character identifiers for accounting-relevant activities. Transaction keys are inherent to SAP S/4HANA and cannot be customized. They are hidden from end users and visible only during configuration or review.

For foreign currency exchange rate differences, navigate through transaction SPRO to SAP Reference IMG, Financial Accounting, General Ledger Accounting, Periodic Processing, Valuate, Foreign Currency Valuation, Prepare Automatic Postings for Foreign Currency Valuation. Six standard transaction keys handle exchange rate difference postings. For example, the KDW transaction key handles payment differences related to alternative payment currencies.

Double-click the transaction key to see the GL accounts configured to receive postings. Verify that the assigned accounts are appropriate based on your accounting policy.

Be aware that account determination can potentially be disabled. In SAP ERP, checkboxes existed that could disable specific transaction keys even when accounts were defined. If you see an unchecked Account Determination checkbox for a transaction key, assume account determination is disabled unless testing proves otherwise.

Field Status Configuration

Field status groups determine which fields are required, optional, suppressed, or display-only when posting to an account or entering master data. They are assigned to field status variants, which are assigned to company codes.

For example, if your organization uses both financial accounting and controlling, requiring a cost center for expense postings ensures controlling data is captured. This field is not required by default because SAP does not assume every organization uses controlling.

To audit field status, identify all assigned field status variants, determine which fields should be required for each (requiring a VAT tax ID for a US-only business partner makes no sense), and review settings within each variant separately. Work with a power user involved in field status maintenance, as the number of configuration locations makes it easy to miss variations.

Data Validation Rules

Data validation rules check entry against both simple and complex criteria. They can be applied across financial accounting, cost accounting, asset accounting, consolidation, and funds management. Rules can apply at the document header, line item, or whole document level.

Access validation rules through transaction GGB0 or through the IMG at Financial Accounting, Special Purpose Ledger, Tools, Maintain Validation/Substitution/Rules, Maintain Validation.

Each validation step has three components. The prerequisite defines the "if" condition determining whether the step applies. The check defines what correct data should look like. The message defines SAP's response when data fails the check. Message options include Cancel (cancels the document without correction), Error (prevents saving until corrected), Warning (allows user to save or update), and Information (displays a message box only). The message configuration can also trigger workflow.

Good starting points for validation rules include error messages for postings to accrual accounts mid-period, error messages for invalid account combinations (debit to depreciation offset by credit to cash), error messages for company code postings with inappropriate business areas, warning messages with workflow for reserve account postings outside normal ranges, and warning messages for capitalization postings with expense-type descriptions.

The distinction between error and warning matters. Error messages prevent saving even for legitimate rare transactions. If the condition occurs every several years, an error message with temporary rule modification may be appropriate. If it occurs once or twice a year, a warning with workflow approval provides better balance.

Document Tolerance Groups

Tolerance groups limit the maximum amount of an accounting document that can be posted by a user within a company code. They are defined by a four-character alphanumeric code assigned to a company code, with user IDs then assigned to the tolerance group.

Two critical points about tolerance groups.

The blank tolerance group (with no four-character code) is the default. It applies to any user not explicitly assigned to a named tolerance group. This is the most important tolerance group in your system and should be the most restrictive.

Tolerance values are defined by the combination of tolerance group and company code. Two company codes assigned to the same tolerance group do not necessarily have the same tolerance values because amounts are in company code currency.

View tolerance group assignments to company codes and the related values through transaction SPRO, navigating to SAP Reference IMG, Financial Accounting, Financial Accounting Global Settings, Document, Tolerance Groups, Define Tolerance Groups for Employees. Double-click each tolerance group and company code combination to see the configured values.

The user-to-tolerance-group mapping uses specifically named user IDs, not user groups, roles, or HR job titles. This means configuration must be updated whenever accounting staff changes through hire, transfer, or termination. Any new accountant not explicitly mapped inherits the blank tolerance group.

Financial accounting tolerance groups also define thresholds for open item processing including maximum open item line item amounts, maximum cash discount percentages, and maximum permitted payment differences expressed as the lesser of a configured amount or percentage of total value. When tolerance values are defined at multiple levels (user, GL account, customer or vendor account group), SAP S/4HANA uses the most conservative value.

Maximum Exchange Rate Differences

Configure maximum exchange rate differences by company code and by currency pair. If a user enters an exchange rate differing by more than the threshold from the SAP exchange rate table, the system issues a warning message.

View company code settings through transaction SPRO, SAP Reference IMG, Financial Accounting, Financial Accounting Global Settings, Global Parameters for Company Code, Currencies, Maximum Exchange Rate Difference, Define Maximum Exchange Rate Difference per Company Code.

View currency-specific settings through the same path, selecting Define Maximum Exchange Rate Difference per Foreign Currency.

When both settings exist, SAP uses the more conservative value. A 10% company code threshold with a 7% USD-specific threshold means USD transactions trigger at 7%.

The default message behavior is a warning. Your organization can change this to an error by modifying message area F5, message type 212 from W to E. Message types can also be set for specific user IDs, allowing one authorized user to proceed with a warning while all others receive an error.

Original implementation tip: The five most common observations I find on data input error controls are incomplete account determination (not all available procedures defined, forcing manual entry), field status left at default values (rushing the implementation or using low-cost integrators), no data validation rules (sometimes due to lack of awareness that the capability exists), only a single tolerance group (missing the opportunity to differentiate by role), and the blank tolerance group being the least restrictive (creating the exact problem I described in this post's opening paragraph). If the blank tolerance group allows trillion-dollar postings and your named tolerance group allows million-dollar postings, every unmapped user gets the least control. Set the blank tolerance group to the most restrictive values.

Testing Common Controls: Unauthorized Manual Journal Entries

Controls over journal entry approval fall into three categories: the Verify General Journal Entries Fiori apps, classic SAP Business Workflow through transaction SWDD, and flexible workflow management through transaction SWDD_SCENARIO.

For cloud deployments, SAP Workflow Management replaces the on-premise flexible workflow. Flexible workflow management adds conditional workflows triggered by defined criteria, ad hoc workflows for one-off scenarios, and reusable templates.

Because workflow is custom code developed for your organization's specific scenarios, there is no universal "auditing workflow" procedure. Sit down with a workflow specialist to walk through configuration. Verify that workflow tasks and assignments match organizational policies. Ask about maintenance procedures when employees move in or out of departments.

Common observations on journal entry approval controls include workflows not defined for all manual journal entries (some entries never trigger approval and post directly), workflow getting stuck because an approver is absent without a delegate (creating posting timing issues), workflow rules not updated when approval policies or delegation of authority change, and workflow routed to the wrong individual due to personnel changes or name confusion during coding.

Testing Common Controls: Asset Valuation

Asset Class Configuration

Asset classes drive default values for depreciation, account determination, and screen layouts. View asset class configuration through transaction SPRO, SAP Reference IMG, Financial Accounting, Asset Accounting, Organizational Structures, Define Asset Class. The key settings to verify are the account determination procedure, screen layout rule, inventory inclusion checkbox, and treatment of assets under construction.

Depreciation key values associated with asset classes for a chart of depreciation are configured at SAP Reference IMG, Financial Accounting, Asset Accounting, General Valuation, Depreciation Areas, Determine Depreciation Areas in the Asset Class. The DepKy field contains the depreciation key. The Use field contains useful life in years. The Per field captures additional fiscal periods. Verify that keys and useful lives are consistent with company policy. Configure minimum and maximum useful lives to minimize data entry errors.

Asset Retirement Transaction Types

View retirement transaction types at SAP Reference IMG, Financial Accounting, Asset Accounting, Transactions, Retirements, Define Transaction Types for Retirements. The Deactivate Fixed Asset flag should be set for all retirement types unless there is a compelling business reason otherwise. When set, a retirement posting that results in zero acquisition value automatically sets the retirement date and changes the asset status to Deactivated.

Low-Value Asset Thresholds

View LVA configuration at SAP Reference IMG, Financial Accounting, Asset Accounting, General Valuation, Amount Specifications, Specify Max. Amount for Low-Value Assets and Asset Classes. The LVA Amount column shows the maximum acquisition value. The MaxLVA Pur column shows the maximum purchase order amount. Verify both against your asset accounting policies.

Original implementation tip: The most common asset-related audit observation is failure to configure available options. Organizations leave depreciation defaults unconfigured, do not set the deactivate flag on retirement types, and do not define minimum and maximum useful lives. This forces manual entries and checks for processes that SAP can automate, increasing error risk. On one audit, I found an asset retirement transaction type that did not have the Deactivate Fixed Asset flag set. When assets were retired through that type, they remained active in the asset register with zero book value. Nobody monitored for this condition. Eighteen months of retirements were sitting in the register as active assets with zero value, distorting the asset count reports used for insurance and property tax calculations.

Other Configurable Controls Worth Testing

Company Code Productive Indicator

One of the final steps before go-live should be setting the productive indicator for each company code. Once set, deletion functions intended for development and testing environments are prevented even if a user has the authorization to run them.

Test through transaction SPRO, SAP Reference IMG, Financial Accounting, Financial Accounting Global Settings, Global Parameters for Company Code, Set Company Code to Productive. Company codes with a checkmark in the Productive column are set correctly. Only template and unused company codes should lack this flag.

I have noted a missing productive indicator in nearly half of the SAP S/4HANA audits I have conducted. If you find company codes lacking this flag, perform exposure testing. Check whether any user IDs can run transaction AS91 (Create Old Asset), AS92 (Change Old Asset), or OABL (Reset Posted Depreciation). Check access to programs SAPF019 (Delete Master Data), SAPF020 (Reset Transaction Data), and SAPF023 (Reset Bank Data) through authorization object S_PROGRAM or S_PROGNAM. If any active user had access during the period, determine whether these transactions or programs were actually executed using security audit log data.

Document Change Rules After Initial Posting

Changing a posted document affects the audit trail. The general rule is to reverse the original and post a correction. SAP S/4HANA inherently prevents changes to amounts, currency, GL accounts, posting periods, company code, and business area. But configuration controls changes to other fields, and can allow changes even to documents in closed periods.

Review through transaction SPRO, SAP Reference IMG, Financial Accounting Global Settings, Document, Rules for Changing Documents. Select either Document Change Rules Document Header or Document Change Rules Line Item.

The default configuration for the document header text field allows changes even for documents in closed periods. While changing the description does not affect financial statement numbers, approvers typically use the description to determine appropriateness. I question this default in most organizations.

For each field, the Field Can Be Changed flag indicates whether changes are permitted. Stipulations for changing define the conditions under which changes are allowed, such as only when the line item is not closed or only for specific document types.

Enabling Optional Authorization Objects

Financial accounting contains optional authorization objects that can be enabled for additional access restriction. View through transaction SPRO, SAP Reference IMG, Financial Accounting, Financial Accounting Global Settings, Authorizations. Settings exist for business area display authorizations, document type display authorizations, and profit center authorization by controlling area.

Additional Procedures and Considerations

Optimizing the Closing Process

The closing process involves dependencies and potential for error. SAP S/4HANA provides the SAP Financial Closing cockpit with centralized task lists, automated process control, Fiori analytical apps for KPI monitoring, and a robust audit trail. Third-party tools like BlackLine remain common for automating reconciliations and the financial close process itself.

Resolving Parked and Held Documents

Parked and held journal entries do not update GL accounts until posted. Run the Compact Document Journal (transaction S_ALR_87012289) with the Parked Documents option checked. Held documents can only be seen by the user who created the hold. Communicate to all employees before period close to clear holds.

Confirming Receivables and Payables Balances

Transaction F.17 generates customer confirmations. Transaction F.18 generates vendor confirmations. Both support balance notifications, balance requests, and balance confirmations with selection criteria including balance ranges, recent postings, and random sampling. Despite full system support, this functionality is rarely used.

Useful Audit Reports

Change Reports

Transaction FS04 displays changes to GL accounts. From the main menu, selecting More, Environment, Multiple Display allows running without specifying a specific account. The report shows old and new values for every change including deletion flags, field status group changes, and account assignments.

Transaction S_ALR_87012293 displays changes to accounting documents. Pay attention to changes to recurring entry documents, which post automatically over time. If using park and post, select Docs which were once parked to verify the poster made no other changes.

Transaction S_P00_07000008 displays bank master data changes. Since banking changes should be minimal, the entire report should be reviewable.

Incomplete Information Reports

Transaction SM13 with Canceled status shows update terminations where accounting documents did not fully post. Double-click entries for processing detail and error messages. Ensure terminations are investigated and resolved promptly.

Transaction AUVA shows incomplete assets with various levels of incompletion. Follow up on items to ensure appropriate postings before period close.

Potential Issue Reports

Transaction S_ALR_87012342 shows gaps in document numbers. Gaps can result from number range changes, deleted documents, update terminations, or failure to apply SAP Notes. Every gap should have a reasonable explanation.

General Information Reports

Transaction AW10N displays fixed asset details. Transaction S_ALR_87011964 displays assets by asset class. Transaction S_ALR_87012048 displays asset transactions. Transaction FB03 displays journal entries. Transaction FAGLB03 displays GL balances. Transaction FAGLL03H browses GL line items.

Management Tips for Record-to-Report Audits

Original implementation tip on outcome-based testing: Move beyond control configuration testing to outcome-based testing. For posting period controls, query table BKPF and compare field CPUDT (actual server date at time of posting) against field BUDAT (user-entered posting date). Any material difference means the document was posted to a period other than the current one at the time of entry. This full-population test catches problems that configuration-based testing misses, including situations where the period was briefly reopened and then closed before your audit.

Original implementation tip on message configurability: Most messages in SAP S/4HANA have configurable behavior. The default behavior of exceeding the maximum exchange rate difference is a warning. Your organization could change this to an error by modifying message area F5, message type 212 from W to E. Message types can also be set for specific user IDs. This flexibility is powerful but creates audit risk. A message configured as a warning in production can be bypassed by any user. Verify the message type for every control-relevant message, not just the existence of the underlying configuration. A control that warns but does not prevent is fundamentally different from one that prevents.

Original implementation tip on SAP Note awareness: SAP continuously updates functionality and retires legacy features. SAP Note 2141732 acknowledges that anyone who can open or close posting periods can do so across every posting period variant, affecting all company codes in the system. The resolution is "None." SAP Note 2480067 lists reports being retired under the Document and Reporting Compliance framework. Your audit should include a step to verify that your organization monitors relevant SAP Notes and has a process for evaluating their impact on controls and reporting.

Original implementation tip on tolerance group management: The user-to-tolerance-group mapping in table TPARA (or accessed through the tolerance group configuration) uses literal user IDs. There is no integration with role assignment, HR organizational data, or any dynamic grouping mechanism. Every new hire, transfer, or termination requires manual configuration update. Build a reconciliation process that periodically compares the list of user IDs authorized to post journal entries (from table AGR_1251 through the F_BKPF_BUK authorization object) against the list of user IDs mapped to tolerance groups. Any user with posting authorization but no tolerance group mapping defaults to the blank tolerance group. If the blank tolerance is not the most restrictive, you have an uncontrolled exposure.

SAP S/4HANA Audit Program: Record-to-Report Cycle

Audit Objectives

This audit program provides a structured approach for evaluating the Record-to-Report (R2R) cycle in an SAP S/4HANA environment. The program is designed for auditors, compliance professionals, and finance specialists who need to assess the reliability, integrity, and accuracy of financial reporting processes. The primary objectives are to:

• Evaluate the design and operating effectiveness of controls over financial reporting

• Assess configuration settings that impact the completeness and accuracy of general ledger postings

• Review master data controls and security configurations that protect financial information

• Validate period-end closing procedures and reporting integrity

• Identify control weaknesses and provide recommendations for remediation

This program follows a risk-based approach consistent with COSO Internal Control Framework, COBIT 2019, and common external audit practices. The procedures should be tailored to your organization's specific risk profile, regulatory requirements, and system complexity.

---

Section 1: Understanding the SAP S/4HANA Record-to-Report Environment

1.1 SAP S/4HANA Specific Features Impacting R2R

Audit Objective: Understand the unique SAP S/4HANA features that affect financial reporting and identify any related risks.

Background: SAP S/4HANA introduces significant changes to financial accounting compared to legacy SAP ERP systems. The Universal Journal (table ACDOCA) combines financial and managerial accounting into a single data source, eliminating reconciliation gaps between modules. Additional features include Central Finance, Real-time Consolidation (being sunset), SAP S/4HANA Finance for group reporting, predictive accounting, and advanced compliance reporting (now SAP Document and Reporting Compliance).

Audit Procedures:

• Identify which SAP S/4HANA-specific financial features are implemented:

  • Universal Journal (should be standard in S/4HANA)

  • Central Finance (if applicable)

  • Real-time consolidation or SAP S/4HANA Finance for group reporting

  • Predictive accounting

  • SAP Document and Reporting Compliance

• Review SAP Note 2480067 to identify any legacy reports that have been retired and replaced

• Verify that the organization is using current, supported reports for statutory reporting

• Assess whether the migration to SAP S/4HANA has introduced any new risks or control gaps

• Review documentation of financial processes that leverage new S/4HANA functionality

---

Section 2: Risks in the Record-to-Report Cycle

Audit Objective: Identify and understand the key risks affecting financial reporting integrity.

Risk Categories and Audit Focus:

Risk Category	Description	Audit Focus
Insufficient reporting structures	Organizational model, chart of accounts, and other structures not configured to support required reporting	Review enterprise structure configuration; assess whether structures support financial reporting requirements
Inaccurate postings	User errors during manual postings or incorrect automatic postings	Test account determination, field status, validation rules, and posting tolerances
Incomplete general ledger processing	Parked documents, held documents, or interface failures prevent complete posting	Review procedures for parked/held documents; assess interface monitoring
Postings to wrong accounting period	Transactions recorded in incorrect periods, affecting period-end balances	Test posting period controls; analyze period-end activities
Uncollectable receivables	Accounts receivable overstated without adequate allowance	Review credit management and period-end valuation procedures
Inaccurate management reports	Cost center or profitability information errors affecting management decisions	Assess cost and profit center controls; review allocation processes
Unauthorized document changes	Changes to posted documents without proper approval or audit trail	Review document change rules; analyze change logs
Fraudulent transactions	Intentional misstatement or theft	Review segregation of duties; analyze unusual transactions

---

Section 3: Enterprise Structure Review

Audit Objective: Verify that the enterprise structure supporting financial reporting is appropriately configured and aligned with organizational and legal requirements.

3.1 Financial Accounting Organizational Units

Background: The enterprise structure defines how your organization is represented in SAP S/4HANA for financial reporting. Key elements include company, company code, business area, functional area, consolidation business area, FM area, segment, profit center, cost center, and controlling area.

Audit Procedures:

• Using Transaction SPRO, navigate to SAP Reference IMG • Enterprise Structure • Definition • Financial Accounting

• Review the following organizational units for appropriate configuration:

Company:

• Verify that companies are properly defined and reflect legal entities or consolidation groups

• Confirm that SAP-preset company G0000 is used appropriately or replaced with organization-specific companies

• Review company assignment to company codes

Company Code:

• Obtain a listing of all company codes using Transaction OBY6

• Verify that each company code represents a valid legal entity requiring separate statutory reporting

• Review company code global parameters for appropriateness:

  • Chart of accounts

  • Fiscal year variant

  • Country key

  • Currency

  • Posting period variant

• Confirm that template company codes have been properly configured or replaced

Credit Control Area:

• Review credit control area configuration (Transaction OB45)

• Verify that company codes are appropriately assigned to credit control areas

• Confirm consistent currency usage within each credit control area

Business Area and Consolidation Business Area:

• Review business area definitions (Transaction OX03)

• Assess whether business areas are used appropriately for internal reporting

• Verify consolidation business area configuration if used

Functional Area:

• Review functional area definitions (Transaction OKBD)

• Confirm assignment to cost centers is appropriate

• Verify that functional areas support cost-of-sales accounting requirements

FM Area:

• Review FM area definitions if funds management is in scope

• Verify assignment to company codes

Controlling Area:

• Review controlling area configuration (Transaction OX06)

• Determine whether controlling area has one-to-one or one-to-many relationship with company codes

• Verify that all relevant company codes are assigned to the controlling area

• Confirm that operating chart of accounts is consistent across assigned company codes (for cross-company code cost accounting)

Segment and Profit Center:

• Review segment definitions (Transaction KEns5)

• Verify that segments are properly assigned to profit centers

• Review profit center standard hierarchy (Transaction KCH6N)

• Confirm that all profit centers are included in the standard hierarchy

Cost Center:

• Review cost center standard hierarchy (Transaction OKENN)

• Verify that cost centers are properly assigned to profit centers

• Assess whether cost center groups support management reporting needs

Common Findings:

• Company codes not aligned with legal entity structure

• Inconsistent chart of accounts across company codes in same controlling area

• Missing or incomplete standard hierarchies

• Business areas used inconsistently affecting reporting

• Profit centers not properly mapped to segments for external reporting

---

Section 4: Master Data Review

Audit Objective: Assess the controls over master data that impacts financial reporting, including general ledger accounts, profit centers, cost centers, and banking master data.

4.1 General Ledger Account Master Data

Background: General ledger master data exists at two levels: chart of accounts data (applicable across all company codes using that chart) and company code data (specific to individual company codes). Control-related settings in master data can be changed in production without transport, requiring strong change management.

Audit Procedures:

• Using Transaction FS00 or FSP0/FS01, review a sample of general ledger accounts

• For each sample, verify:

  • Account group assignment (affects field status and number range)

  • Account type (balance sheet, profit and loss, etc.)

  • Financial statement item assignment

  • Reconciliation account status (for subledger accounts)

  • Currency settings

  • Tax category (if applicable)

  • Open item management flag (for accounts requiring clearing)

  • Line item display flag (for accounts requiring detailed transaction display)

  • Field status group assignment (determines required/optional fields during posting)

  • Authorization group (if used to restrict access)

• Review time-dependent general ledger account functionality (Transaction FS00, time-dependent data tab)

• Verify that any account changes during the audit period were properly authorized

• Using Transaction FS04, review changes to general ledger accounts for the audit period

• For significant changes, trace to supporting documentation and approvals

Key Authorization Objects for GL Accounts:

Authorization Object	Purpose
F_SKA1_KTP	Restrict modifications by chart of accounts
F_SKA1_BUK	Restrict modifications by company code
F_SKA1_BES	Restrict modifications by account number
F_SKA1_AEN	Restrict modifications to specific fields

4.2 Profit Center Master Data

Audit Procedures:

• Using Transaction KE53, review profit center master data

• For a sample of profit centers, verify:

  • Valid dates (time-dependent data)

  • Responsible person

  • Profit center group assignment

  • Segment assignment

  • Company code assignment

  • Dummy profit center flag (if applicable)

• Review the profit center standard hierarchy (Transaction KCH6N)

• Verify that all profit centers are included and properly structured

• Using Transaction KEPCA, review changes to profit center master data

• Assess security over profit center maintenance (see Section 5)

Key Authorization Objects for Profit Centers:

Authorization Object	Purpose
K_PCA_PRC	Restrict modifications by controlling area
K_PCA_MD	Restrict modifications by controlling area, profit center, or hierarchy node
K_PCA_PCA	Restrict actions to cost elements of profit centers
K_PCAP_SET	Restrict modifications to planning hierarchies

4.3 Cost Center Master Data

Audit Procedures:

• Using Transaction KS03, review cost center master data

• For a sample of cost centers, verify:

  • Valid dates (time-dependent data)

  • Cost center category

  • Cost center group assignment

  • Profit center assignment

  • Company code assignment

  • Currency settings

  • Lock indicators (for actual postings or planning)

• Review the cost center standard hierarchy (Transaction OKENN)

• Verify that all cost centers are included and properly structured

• Using Transaction KSH3N, review changes to cost center master data

• Assess security over cost center maintenance (see Section 5)

Key Authorization Objects for Cost Centers:

Authorization Object	Purpose
K_CCA	General authorization for cost center accounting
K_CSKS	Restrict modifications by controlling area and cost center
K_CSKS_SET	Restrict maintenance of cost center groups and standard hierarchy

4.4 Banking Master Data

Audit Procedures:

• Using Transaction FI03, review banking master data

• For a sample of house banks and bank accounts, verify:

  • Country key and bank key

  • Bank account number and control key

  • Alternative payee (if applicable)

  • Grouping code for payment runs

• Using Transaction S_P00_07000008, review changes to banking master data

• Verify that bank account changes are properly authorized and documented

• Assess security over banking master data (see Section 5)

Key Authorization Objects for Banking:

Authorization Object	Purpose
F_BNKA_BUK	Restrict modifications by company code
F_BNKA_MAN	General maintenance authorization
F_BNKA_MAO	Restrict maintenance by country

---

Section 5: Security Considerations for R2R

Audit Objective: Evaluate security controls that protect financial processes and data from unauthorized access or manipulation.

5.1 Restricting Postings and Critical Transactions

Audit Procedures:

• Using Transaction SUIM, identify users with authorization to post journal entries

• Verify that appropriate segregation of duties exists between:

  • Journal entry preparers and approvers

  • Master data maintainers and transaction posters

  • Period-end closing personnel and routine transaction processors

• Review assignment of authorization objects for journal entry posting:

  • F_BKPF_BUK - Restrict by company code

  • F_BKPF_BLA - Restrict by document type

  • F_BKPF_GES - Restrict by business area

  • F_BKPF_KOA - Restrict by account type

  • F_BKPF_BES - Restrict by specific general ledger accounts

• Identify users with access to powerful transactions:

  • F-60 or OB52 - Open/close posting periods

  • S_ALR_87003642 - Open/close posting periods (alternative)

  • F.80 - Mass reversal of accounting documents

  • FS06 - Delete assets

  • OKP1 - Lock actual/planned transactions for controlling area

  • CFIN_CO_DOC_CRCT - Reverse and repost controlling documents

• For users with access to powerful transactions, verify:

  • Business justification exists

  • Access is limited to appropriate personnel

  • Usage is monitored by independent parties

  • Emergency access procedures (firefighter) are in place for highly critical functions

5.2 Restricting Master Data Changes

Audit Procedures:

• Review security settings for general ledger account maintenance (see Section 4.1 for authorization objects)

• Verify that only authorized personnel can create, change, or block general ledger accounts

• Assess whether account maintenance is appropriately segregated from transaction posting

• Review security for profit center maintenance (see Section 4.2)

• Review security for cost center maintenance (see Section 4.3)

• Review security for banking master data (see Section 4.4)

5.3 Segregation of Duties Analysis

Audit Procedures:

• Obtain the organization's SoD matrix for financial processes

• Verify that the matrix includes critical combinations such as:

  • GL account maintenance and journal entry posting

  • Customer master maintenance and accounts receivable processing

  • Vendor master maintenance and accounts payable processing

  • Asset master maintenance and asset transaction posting

  • Period-end closing activities and routine transaction processing

• Identify users with conflicting access

• For users with SoD conflicts, determine whether mitigating controls exist

• Assess the effectiveness of mitigating controls

---

Section 6: Configurable Controls - Posting Period Management

Audit Objective: Verify that controls over posting periods are properly configured and operating effectively to prevent postings to incorrect accounting periods.

6.1 Understanding Posting Period Configuration

Background: Posting periods are controlled through posting period variants (table T001B), which define which periods are open for posting by account type. The most common method for opening/closing periods is through Transactions F-60 or OB52.

Audit Procedures:

• Identify the posting period variant assigned to each in-scope company code using Transaction OBY6

• Review the posting period status for each variant using Transaction OB52 or F-60

• Document the current open periods by account type (see Figure 6.5 in source material for account type definitions)

• For each posting period variant, verify that:

  • Only appropriate periods are open (typically current period only near period-end)

  • Special periods (13-16) are only open during closing activities

  • Authorization groups are used appropriately to restrict posting privileges during sensitive periods

• If table logging is enabled, review changes to table T001B during the audit period using Transaction SCU3

• For any period when prior periods were reopened, document:

  • Date and time of change

  • User ID making the change

  • Duration the period remained open

  • Journal entries posted during that window

6.2 Testing Posting Period Controls

Maturity Model Assessment:

Maturity Level	Controls to Test
Level 1	System prevents posting to closed periods (inherent functionality)
Level 2	Documented period closing process with defined responsibilities
Level 3	Warning messages or workflow for entries dated significantly from current period
Level 4	Regular monitoring of T001B table log entries; documentation of period reopening approvals
Level 5	Automated monitoring with notifications and deficiency tracking

Audit Procedures:

• Test inherent control: Attempt to post a test journal entry to a closed period (should receive error message)

• Review period closing documentation to verify that periods are closed according to policy

• If warning messages or workflow are configured, test that they operate as designed

• Review monitoring evidence for table T001B changes

• Using data analytics, identify journal entries where:

  • Posting date (BKPF-BUDAT) differs from CPU date (BKPF-CPUDT) by more than expected

  • Posting date falls in a future period

  • Posting date falls in a period that was reopened after initial closing

Common Findings:

• Table logging not enabled, preventing monitoring of period changes

• No documentation supporting reopening of closed periods

• Authorization groups not used to restrict posting near period-end

• Posting period variants not grouped by similar closing cycles

---

Section 7: Configurable Controls - Journal Entry Data Integrity

Audit Objective: Assess controls designed to ensure journal entries are complete and accurate, including automatic account determination, field status, validation rules, and posting tolerances.

7.1 Automatic Account Determination

Background: Automatic account determination tells SAP S/4HANA which general ledger accounts to post to for specific transactions (transaction keys). This reduces manual entry errors and ensures consistency.

Audit Procedures:

• Identify which transaction keys are relevant for in-scope processes

• Common transaction keys include:

Transaction Key	Description
KDW	Payment differences - alternative payment currency
KDF	Payment differences - cash discount
KDR	Payment differences - rounding
KDB	Payment differences - bank charges
KDA	Payment differences - alternative payee
KDC	Payment differences - correction posting

• Using Transaction SPRO, navigate to the relevant account determination configuration (e.g., Financial Accounting • General Ledger Accounting • Periodic Processing • Valuate • Foreign Currency Valuation • Prepare Automatic Postings for Foreign Currency Valuation)

• For each transaction key, verify:

  • Account determination is enabled (checkbox selected)

  • Appropriate general ledger accounts are assigned

  • Debit and credit accounts are properly differentiated where applicable

  • Accounts align with organizational accounting policies

• Review whether account determination is configured for all available transaction keys where automation would be beneficial

Common Findings:

• Account determination not configured for all available transaction keys

• Manual postings required where automation could reduce errors

• Account determination disabled despite accounts being defined

• Inconsistent account assignments across company codes

7.2 Field Status Configuration

Background: Field status groups define whether fields are required, optional, suppressed, or display-only during data entry. Proper configuration ensures critical data is captured.

Audit Procedures:

• Identify field status variants assigned to in-scope company codes (Transaction OBY6)

• Using Transaction SPRO, navigate to Financial Accounting • Financial Accounting Global Settings • Document • Maintain Field Status Variants

• For each relevant field status variant:

  • Review field status groups assigned

  • For critical fields (e.g., cost center, profit center, business area, tax code), verify they are set to "Required Entry" where appropriate

  • For fields not used by the organization, verify they are set to "Suppress"

  • Assess whether field requirements are consistent across similar account types

• Test field status configuration by creating a test journal entry and verifying required fields enforce data entry

Common Findings:

• Field status left at default values (fields optional when should be required)

• Critical fields not required for expense postings

• Fields not used by organization not suppressed, causing data entry clutter

• Inconsistent field requirements across company codes without business justification

7.3 Data Validation Rules

Background: Data validation rules (Transaction GGB0) allow organizations to define custom checks on journal entry data beyond standard system edits.

Audit Procedures:

• Using Transaction GGB0, review all active validation rules for financial accounting

• For each validation rule, examine:

  • Prerequisite conditions (when the rule applies)

  • Check conditions (what must be true)

  • Message configuration (Cancel, Error, Warning, Information)

  • Workflow triggering (if applicable)

• Assess whether validation rules address known risk areas:

  • Invalid account combinations

  • Postings to accrual accounts outside period-end

  • Unusual posting amounts

  • Inconsistent document header text

• Test a sample of validation rules by creating test entries that should trigger the rule

• Verify that message behavior (error, warning, etc.) operates as designed

Common Findings:

• Data validation not used despite recurring data entry errors

• Validation rules configured with error messages that are too restrictive

• Validation rules with warning messages not monitored

• Message text not helpful to users, reducing effectiveness

7.4 Posting Tolerance Groups

Background: Posting tolerance groups limit the maximum amount of accounting documents and define tolerances for open item processing.

Audit Procedures:

• Using Transaction SPRO, navigate to Financial Accounting • Financial Accounting Global Settings • Document • Tolerance Groups • Define Tolerance Groups for Employees

• Review tolerance groups assigned to company codes (see Figure 6.10 in source material)

• For each tolerance group (including the blank/default group), review:

  • Maximum document amount

  • Maximum line item amount

  • Maximum cash discount percentage

  • Maximum payment difference (amount and percentage)

• Verify that the blank (default) tolerance group is the most restrictive

• Review user assignment to tolerance groups using Transaction OB57

• Select a sample of users with journal entry posting authority and verify they are assigned to appropriate tolerance groups

• Test tolerance enforcement by creating a test journal entry exceeding the configured maximum

Important Consideration: Tolerance values can also be set at the general ledger account, customer, and vendor level. SAP S/4HANA applies the most conservative (lowest) value.

Common Findings:

• Only a single tolerance group used, missing opportunity for differentiated controls

• Blank tolerance group less restrictive than named groups (users inadvertently have higher limits)

• Default SAP values (e.g., trillion-dollar limits) not updated to reasonable amounts

• User assignments to tolerance groups not maintained as personnel change

7.5 Maximum Exchange Rate Differences

Background: Configuration can limit acceptable exchange rate differences, issuing warnings when user-entered rates deviate significantly from system rates.

Audit Procedures:

• Using Transaction SPRO, navigate to Financial Accounting • Financial Accounting Global Settings • Global Parameters for Company Code • Currencies • Maximum Exchange Rate Difference

• Review settings by company code (Figure 6.17)

• Review settings by foreign currency (Figure 6.18)

• Verify that configured percentages are reasonable given currency volatility

• Where multiple settings apply, verify the most conservative value is effective

• Test configuration by creating a test journal entry with an exchange rate exceeding the configured difference

Message Configuration: Review message area F5, message type 212 configuration (can be changed from Warning to Error if desired)

Common Findings:

• Maximum exchange rate differences set the same for all currencies (ignoring volatility differences)

• Default values not reviewed or updated

• Message type not configured appropriately for organizational risk tolerance

---

Section 8: Configurable Controls - Manual Journal Entry Approval

Audit Objective: Assess controls ensuring manual journal entries are properly reviewed and approved before posting.

8.1 Understanding Journal Entry Approval Options

Background: SAP S/4HANA supports multiple journal entry approval methods:

• SAP Fiori apps: Verify General Journal Entries (requestor/approver)

• Classic SAP Business Workflow (Transaction SWDD)

• Flexible Workflow Management (Transaction SWDD_SCENARIO or Manage Workflow app)

• SAP Workflow Management (for cloud deployments)

Audit Procedures:

• Determine which journal entry approval method(s) are used by the organization

• Obtain documentation of workflow design and configuration

• Review workflow rules to verify:

  • Appropriate approval limits are configured

  • Approvers are correctly assigned based on organizational hierarchy

  • Special conditions (e.g., amount thresholds, account types) trigger appropriate approval paths

  • Segregation exists between preparer and approver

• Test workflow by creating a test journal entry requiring approval

• Verify that:

  • Entry routes to correct approver

  • Approver receives notification

  • Approval/rejection functions properly

  • Posting occurs only after final approval

• Review procedures for maintaining workflow assignments when employees change roles

• Using Transaction SWI1 or SWI5, review workflow logs for the audit period

• Identify any stuck workflows and assess resolution timeliness

Alternative Testing: If Verify General Journal Entries apps are used, verify that users do not have direct posting authority through other transactions (SAP GUI or other Fiori apps)

Common Findings:

• Workflow not defined for all manual journal entries

• Workflow approvals bypassed through direct posting transactions

• Workflow rules outdated (approvers no longer in role)

• Workflow gets stuck due to missing delegates or system issues

• No monitoring of workflow completion rates

---

Section 9: Configurable Controls - Asset Valuation

Audit Objective: Verify controls over asset master data and transactions to ensure proper asset valuation.

9.1 Asset Class Configuration

Background: Asset classes define default values for assets, including account determination, screen layouts, depreciation rules, and useful lives.

Audit Procedures:

• Using Transaction SPRO, navigate to Financial Accounting • Asset Accounting • Organizational Structures • Define Asset Class

• Select a sample of asset classes relevant to the audit

• For each asset class, review:

  • Account determination procedure (ensures proper GL accounts for asset transactions)

  • Screen layout rule (determines field requirements)

  • Inventory indicator (whether asset appears in standard inventory lists)

  • Treatment of assets under construction (if applicable)

• Using Transaction SPRO, navigate to Financial Accounting • Asset Accounting • General Valuation • Depreciation Areas • Determine Depreciation Areas in the Asset Class

• For each asset class, review depreciation area assignments:

  • Depreciation key

  • Useful life (years and periods)

  • Minimum and maximum useful lives (if configured)

  • Screen layout variant

• Verify that depreciation keys and useful lives are consistent with organizational policies

• Test asset creation by creating a test asset and verifying default values populate correctly

9.2 Low-Value Asset Configuration

Background: Low-value assets (LVAs) are fully depreciated in the year of acquisition. Configuration defines maximum amounts for LVA treatment.

Audit Procedures:

• Using Transaction SPRO, navigate to Financial Accounting • Asset Accounting • General Valuation • Amount Specifications (Company Code/Depreciation Area) • Specify Max. Amount for Low-Value Assets + Asset Classes

• Review LVA maximum amounts by company code and depreciation area (see Figure 6.22)

• Verify amounts align with organizational capitalization policies

• Test that system prevents posting to LVA asset classes above the configured maximum

9.3 Asset Retirement and Transfer Configuration

Audit Procedures:

• Using Transaction SPRO, navigate to Financial Accounting • Asset Accounting • Transactions • Retirements • Define Transaction Types for Retirements

• Review retirement transaction types:

  • Verify "Deactivate Fixed Asset" flag is set (ensures assets are deactivated when value reaches zero)

  • Review "Retirement with Revenue" and "Post gain/loss to asset" flags for consistency with accounting policies

• Using Transaction SPRO, navigate to Financial Accounting • Asset Accounting • Transactions • Transfer Postings • Define Transaction Types for Transfers

• Review transfer transaction types for appropriate configuration

• Test retirement and transfer transactions to verify system behavior matches configuration

Common Findings:

• Asset classes not configured with appropriate depreciation defaults

• Low-value asset maximums not configured or not enforced

• Retirement transactions not set to deactivate assets

• Minimum/maximum useful lives not configured to prevent data entry errors

---

Section 10: Additional Configurable Controls

10.1 Company Code Productive Indicator

Background: Setting the productive indicator prevents certain deletion functions in production company codes.

Audit Procedures:

• Using Transaction SPRO, navigate to Financial Accounting • Financial Accounting Global Settings • Global Parameters for Company Code • Set Company Code to Productive

• Verify that all active company codes have the productive indicator checked (see Figure 6.23)

• For any company codes without the indicator, perform exposure testing:

  • Identify users with access to deletion transactions:

    • AS91 (Create Old Asset)

    • AS92 (Change Old Asset)

    • OABL (Reset Posted Depreciation)

  • Identify users with access to deletion programs:

    • SAPF019 (Delete Master Data)

    • SAPF020 (Reset Transaction Data)

    • SAPF023 (Reset Bank Data)

  • If security audit log is enabled, check whether these transactions/programs were executed

Common Findings:

• Company code productive indicator not set (observed in nearly half of audits)

• Deletion transactions possible in production environments

• No monitoring of deletion activities

10.2 Document Change Rules

Background: Configuration determines which document fields can be changed after posting, and under what conditions.

Audit Procedures:

• Using Transaction SPRO, navigate to Financial Accounting • Financial Accounting Global Settings • Document • Rules for Changing Documents

• Review Document Change Rules for Document Header and Line Items

• For critical fields, verify change rules are appropriate:

  • Fields affecting accounting integrity should not be changeable

  • Text fields may be changeable, but consider restrictions for closed periods

  • Approval-related fields should maintain audit trail

• Test document changes for a sample of posted documents to verify configuration is effective

• Review change logs (Transaction S_ALR_87012293) for unauthorized or unusual changes

Common Findings:

• Default settings allow changes to document header text even in closed periods

• No review of document change logs

• Changes made after approval without additional authorization

10.3 Additional Authorizations

Audit Procedures:

• Using Transaction SPRO, navigate to Financial Accounting • Financial Accounting Global Settings • Authorizations

• Review whether optional authorizations are enabled:

  • Business area display authorizations

  • Document type display authorizations

  • Profit center authorizations by controlling area

• If enabled, verify that authorization objects are properly assigned in roles

---

Section 11: Period-End Closing Procedures

Audit Objective: Assess the effectiveness of period-end closing processes and procedures.

11.1 Closing Process Documentation

Audit Procedures:

• Obtain the period-end closing checklist or procedure documentation

• Verify that closing procedures include:

  • Review and posting of parked/held documents

  • Reconciliation of subledgers to general ledger

  • Foreign currency valuation

  • Accrual postings

  • Depreciation runs

  • Opening/closing of posting periods

  • Key report reviews

  • Management review and approval

• If using SAP Financial Closing cockpit, review configuration and usage

• If using third-party tools (e.g., BlackLine), review integration and controls

11.2 Parked and Held Documents

Background: Parked or held documents do not update general ledger accounts until posted, potentially causing incomplete financial statements if not resolved before period close.

Audit Procedures:

• Review procedures for identifying and resolving parked documents

• Run the Compact Document Journal report (Transaction S_ALR_87012289) with Parked Documents option

• Identify all parked documents as of period-end

• For significant parked documents, investigate whether they should have been posted in the period

• Held documents can only be seen by the user who created them; verify that communication reminds users to clear holds before period close

11.3 Reconciliation Procedures

Audit Procedures:

• Review reconciliation processes for:

  • Accounts receivable subledger to general ledger

  • Accounts payable subledger to general ledger

  • Asset subledger to general ledger

  • Bank accounts to external statements

  • Intercompany accounts

• Obtain reconciliation evidence for the audit period

• Verify that reconciling items are investigated and resolved timely

• Assess whether independent review of reconciliations occurs

11.4 Confirmation Letters

Background: SAP S/4HANA includes functionality for generating accounts receivable and accounts payable confirmations (Transactions F.17 and F.18).

Audit Procedures:

• If confirmations are used, review the selection criteria and sample methodology

• Verify that confirmation process is documented and consistently applied

• Review confirmation results and follow-up on exceptions

---

Section 12: Audit-Relevant Reports

Audit Objective: Identify and utilize SAP S/4HANA reports that support audit procedures and ongoing monitoring.

12.1 Reports Identifying Changed Data

Report	Transaction	Use
Changes to G/L Accounts	FS04 (Multiple Display)	Identify changes to general ledger master data
Display of Changed Documents	S_ALR_87012293	Identify changes to accounting documents
Display of Bank Changes	S_P00_07000008	Identify changes to banking master data

Audit Procedures:

• Run change reports for the audit period

• Select a sample of changes for detailed review

• Verify changes were properly authorized and documented

• Pay special attention to:

  • Deletion flags added or removed

  • Changes to sensitive fields (bank accounts, payment terms)

  • Changes made by new or terminated employees

12.2 Reports Identifying Incomplete Information

Report	Transaction	Use
Update Terminations	SM13 (Canceled status)	Identify documents that failed to post completely
Incomplete Assets	AUVA	Identify assets missing required data

Audit Procedures:

• Run SM13 with Canceled status to identify update terminations

• Investigate any update terminations and verify timely resolution

• Run AUVA to identify incomplete assets

• Follow up on incomplete assets to ensure proper period-end inclusion

12.3 Reports Identifying Potential Issues

Report	Transaction	Use
Gaps in Document Numbers	S_ALR_87012342	Identify missing document numbers

Audit Procedures:

• Run document number gap report for relevant document types

• Investigate any gaps for:

  • Number range changes

  • Deleted documents (investigate further)

  • Update terminations

  • Known SAP Notes

12.4 Other Useful Reports

Area	Transaction	Use
Assets	AW10N	Display fixed asset details
Assets	S_ALR_87011964	Display assets by asset class
Assets	S_ALR_87012048	Display asset transactions
GL Entry	FB03	Display journal entries
GL Balances	FAGLB03	Display general ledger balances
GL Line Items	FAGLL03H	Browse general ledger line items

---

Section 13: Summary of Key Transaction Codes

Transaction	Purpose
OBY6	Company code global parameters
OB52	Open/close posting periods
F-60	Open/close posting periods (alternative)
FS00/FS04	GL account master data and changes
KE53/KE55	Profit center master data and changes
KS03/KSH3N	Cost center master data and changes
FI03/S_P00_07000008	Bank master data and changes
SUIM	User information system (security reporting)
SCU3	Table logging display
GGB0	Data validation rules
OB57	Tolerance group assignment to users
RSPFPAR	Profile parameter display
SM13	Update termination monitoring
AUVA	Incomplete assets
S_ALR_87012342	Document number gaps
F.17/F.18	Customer/vendor confirmations
S_ALR_87012289	Compact document journal (parked documents)

---

Section 14: Common Audit Findings Summary

Based on the source material, the following findings are commonly observed in SAP S/4HANA record-to-report audits:

1. Posting Period Management

   • Table logging not enabled, preventing monitoring of period changes

   • No documentation supporting reopening of closed periods

   • Authorization groups not used to restrict posting near period-end

2. Journal Entry Data Integrity

   • Account determination not fully configured

   • Field status left at default values

   • Data validation not used despite recurring errors

   • Tolerance groups not appropriately configured (blank group less restrictive)

   • Maximum exchange rate differences not tailored to currency volatility

3. Manual Journal Entry Approval

   • Workflow not defined for all entries

   • Workflow rules outdated

   • No monitoring of stuck workflows

4. Asset Valuation

   • Asset classes not configured with appropriate depreciation defaults

   • Low-value asset maximums not configured

   • Retirement transactions not set to deactivate assets

5. Company Code Productive Indicator

   • Indicator not set for productive company codes

   • Deletion transactions possible in production

6. Document Change Rules

   • Default settings allow changes to document header text in closed periods

   • No review of document change logs

7. Master Data Security

   • Excessive users with master data maintenance authority

   • No segregation between master data maintenance and transaction posting

---

Section 15: References and Additional Resources

• SAP S/4HANA Security Guide (current version)

• SAP Note 2480067 - Retired reports and replacements

• SAP Note 608835 - Table logging performance

• SAP Note 1653464 - SAP recommends table logging

• SAP Note 2141732 - Posting period variant security limitations

• COBIT 2019 Framework (ISACA)

• COSO Internal Control Framework

---

Making Your Record-to-Report Audit Count

Organizations that audit the record-to-report cycle by checking whether posting periods are currently closed and whether a few tolerance groups exist produce findings that confirm current state but miss the control gaps that create real risk. A posting period was open for eight months last year. The blank tolerance group allows trillion-dollar postings. Data validation rules do not exist. Account determination is incomplete. These are the findings that lead to material misstatement risk, and they require testing that goes beyond current-state observation.

Organizations that apply the maturity model, test historical state through table logging, perform outcome-based analysis against the full transaction population, and validate that every configurable control matches policy and operates as designed produce audits that genuinely reduce financial reporting risk. Their findings drive measurable improvement. Their reports become the foundation for control optimization rather than compliance artifacts that collect dust.

The integrity of your financial statements depends on the integrity of the controls in the system that produces them, and the integrity of those controls depends on whether anyone actually tested them properly.

What maturity level would you assign to your organization's SAP S/4HANA record-to-report controls today, and what specific configuration change would move you to the next level?

---

About the Author

The SAP frameworks, tools, taxonomies, and implementation guidance described in this article are part of the applied research and consulting work of Prof. Hernan Huwyler, MBA, CPA, CAIO. These materials are freely available for use, adaptation, and redistribution in your own SAP management and audit programs. If you find them valuable, the only ask is proper attribution.

Prof. Huwyler serves as AI GRC ERP Consultancy Director, AI Risk Manager, SAP GRC Specialist, and Quantitative Risk Lead, working with organizations across financial services, technology, healthcare, and public sector to build practical AI governance frameworks that survive contact with production systems and regulatory scrutiny. His work bridges the gap between academic AI risk theory and the operational controls that organizations actually need to deploy AI responsibly.

As a Speaker, Corporate Trainer, and Executive Advisor, he delivers programs on AI compliance, quantitative risk modeling, predictive risk automation, and AI audit readiness for executive leadership teams, boards, and technical practitioners. His teaching and advisory work spans IE Law School Executive Education and corporate engagements across Europe.

Based in the Copenhagen Metropolitan Area, Denmark, with professional presence in Zurich and Geneva, Switzerland, Madrid, Spain, and Berlin, Germany, Prof. Huwyler works across jurisdictions where AI regulation is most active and where organizations face the most complex compliance landscapes.

His code repositories, risk model templates, and Python-based tools for AI governance are publicly available at https://hwyler.github.io/hwyler/. His ongoing writing on AI Governance and AI Risk Management appears on his blogger website at https://hernanhuwyler.wordpress.com/

Connect with Prof. Huwyler on LinkedIn at linkedin.com/in/hernanwyler to follow his latest work on AI risk assessment frameworks, compliance automation, model validation practices, and the evolving regulatory landscape for artificial intelligence.

If you are building an AI or SAP governance program, standing up a risk function, preparing for compliance obligations, or looking for practical implementation guidance that goes beyond policy documents, reach out. The best conversations start with a shared problem and a willingness to solve it with rigor.

Primary keyword: SAP S/4HANA record-to-report audit

Secondary keywords: SAP journal entry controls audit, SAP financial reporting controls, SAP posting period controls, SAP general ledger master audit, SAP record-to-report cycle, SAP financial close controls, SAP S/4HANA asset accounting audit, SAP controlling master data audit, SAP document change controls, SAP financial compliance audit