How to Audit the SAP S/4HANA Order-to-Cash Cycle

Practical Audit Controls for the SAP S/4HANA Order-to-Cash Cycle

Revenue problems rarely begin in the income statement.

They begin earlier. In customer master data. In pricing conditions. In credit limits. In copy control. In blocked deliveries that no one resolves. In incomplete sales documents that sit too long. In manual overrides that looked harmless at the time.

That is why a strong SAP S/4HANA order-to-cash audit is never just a sales process walkthrough. It is a control review across sales, shipping, billing, receivables, customer master data, pricing, credit management, and the handoff into financial accounting.

I have seen organizations with healthy top-line growth discover margin leakage only after audit tested pricing overrides and free-of-charge processes in detail. I have also seen teams with good commercial discipline still struggle because customer business partner data, incompleteness procedures, or credit checking were only partially configured. The process looked fine on paper. The exceptions told a different story.

This article gives you a practical framework for auditing the SAP S/4HANA order-to-cash cycle. It covers new S/4HANA features, enterprise structure, master data, security, common configurable controls, high-value reports, and the technical details needed for a serious audit or GRC review. As requested, I include transaction codes, tables, authorization objects, and field-level references where they are relevant.

Understanding the core framework for a SAP S/4HANA order-to-cash audit

The order-to-cash cycle is where commercial reality meets system control.

Customers place orders. The business promises price, quantity, and timing. Goods or services are delivered. Billing happens. Cash is collected. Revenue is recognized. It sounds linear. It rarely is.

Component 1: Order-to-cash is operational first, but financially consequential

Unlike record-to-report, where the risks are often overtly compliance focused, order-to-cash is operational at the front end. Missed orders, pricing errors, duplicate orders, credit failures, incomplete deliveries, and billing delays all start as process failures.

But they do not stay operational. They flow into revenue, receivables, collections, customer satisfaction, and management reporting.

Original implementation tip: When scoping order-to-cash audits, do not divide risks into “commercial” and “financial” too early. Pricing, credit, and delivery controls can hit both at once.

Component 2: SAP S/4HANA improves customer and credit data models, but raises expectations

SAP S/4HANA changed key parts of the cycle:

• Business Partner replaced classic customer master handling as the unified model.
• FSCM Credit Management replaced the classic ERP credit model.
• Pricing data structures were streamlined.
• Settlement management replaced legacy rebate processing in most scenarios.
• Revenue recognition moved to SAP Revenue Accounting and Reporting.

These changes improve flexibility and integration. They also mean old audit approaches may miss the real control points.

Original implementation tip: In upgrades, ask the business and the SAP team separately which legacy transactions and reports are still being used. Old habits around obsolete reports and transactions are common after conversion.

Component 3: The strongest O2C controls reduce both error and discretion

Many order-to-cash issues come from too much freedom at the wrong point in the process. Manual price override. Weak duplicate checks. No mandatory reference for credits. Credit checks on some document types but not others.

High-performance control design limits preventable discretion and leaves only justified exceptions for review.

Original implementation tip: Every manual override path in O2C should have a reason for existence, a limited user population, and a review process. If one of those is missing, the path is too weak.

What Changed in SAP S/4HANA for Order-to-Cash

Several changes from SAP ERP affect your audit approach.

Customer master data is now part of the business partner function. The business partner model centralizes management of basic data, roles, and addresses for persons and organizations. SAP Note 2265093 lists the old transactions and reports no longer applicable for customer master data in SAP S/4HANA, including details on the conversion from customer master to business partners.

SAP ERP credit management has been replaced by FSCM credit management with an advanced credit rule engine, workflow events, and automatic master data updates. SAP Note 2270544 lists the retired transactions and reports with details on functionality changes, business values, and recommended transition actions. SAP Note 2207394 shows how dynamic credit control configuration through transaction OVA8 differs between SAP ERP and SAP S/4HANA. SAP Note 2761313 contains configuration details for maintaining credit checks in SAP S/4HANA when FSCM credit management is activated. SAP Note 2561725 describes how the credit management function has been simplified.

The pricing data model has been streamlined, eliminating a legacy table and removing historically concatenated fields. SAP Note 2267308 lists updated tables and data elements. Verify your organization uses updated table names and fields in pricing-related data analysis.

SAP ERP sales and distribution rebate processing is no longer available and has been replaced by settlement management. SAP Note 2267377 lists the transactions no longer in use.

Revenue recognition functionality has moved from sales and distribution to SAP Revenue Accounting and Reporting, supporting IFRS 15 and local GAAP adaptations. SAP Note 2267342 lists old transactions and reports no longer applicable, with references to additional notes 2777486, 2733866, 2582784, 2227824, and 2225170.

Original implementation tip: Run SAP Note 2270544 against your current transaction and report inventory to verify your organization has migrated to the new credit management functionality. I found an organization still using legacy credit management transactions eight months after their SAP S/4HANA upgrade. The transactions still functioned but were not receiving updates or patches. Their credit limit change monitoring relied on a legacy report (transaction S_ALR_87012215) that no longer exists in SAP S/4HANA. The replacement reporting through FSCM (transaction RMPS_AUDIT) had never been configured. For eight months, nobody monitored credit limit changes.

Order-to-Cash Risks That Drive Your Audit Scope

The business risks in the order-to-cash cycle are primarily operational, but the link between sales and distribution and financial accounting creates compliance-relevant risks as well.

Missed sales opportunities from failure to capture customer information completely, late data entry, or inaccurate interpretation.

Inaccurate quotations from wrong product selection, incorrect pricing, or failure to limit quotation duration. These lead to missed opportunities or obligations at unwanted price points.

Pricing errors from complex condition maintenance, manual entry mistakes, or incomplete updates to pricing tables. SAP S/4HANA contains powerful pricing options. Power creates complexity.

Unauthorized rebates and discounts applied through transactions not intuitively associated with pricing. Free-of-charge deliveries intended to replace damaged shipments can be used to give preferred customers additional goods at reduced effective prices. Customer credits, if inappropriately used, allow pricing manipulation.

Duplicate order processing when controls over order entry fail to detect that an order has already been entered or started as part of a quotation.

Missed delivery dates from failure to account for backorders, inaccurate due date entry, or slow resolution of sales document blocks.

Late or missed billing from incomplete data entry preventing billing document creation. Depending on contract terms, this results in late payments, missed interest income, or reduced collectability.

Customer non-payment resulting in lost revenue and misstated accounts receivable when credit management controls are insufficient.

Revenue not recognized when allowed due to blocked billing documents or other conditions preventing creation of appropriate accounting entries.

Inaccurate customer activity reporting from data quality issues like duplicate customers skewing business intelligence and management decisions.

Fraudulent transactions including diversion of goods, unauthorized preferential treatment, or manipulation to reach sales bonus targets. The ACFE estimates corporations lose 5% of revenue to fraud on average.

Original implementation tip: When scoping your order-to-cash audit, focus first on controls added or modified after go-live. The implementation team typically subjects original configurations to rigorous testing. Document types, pricing conditions, and copy control rules added after go-live rarely receive the same scrutiny. Query table TVCPF (Billing Copy Control) and compare current entries against your go-live baseline. New entries represent configurations that may never have been audited. The credit memo document type I described in the opening of this post was added through a change request that included functional testing but no control review.

Understanding the Enterprise Structure

The order-to-cash enterprise structure defines the organizational units through which sales, delivery, and billing occur. Configuration is accessed through SAP Reference IMG, Enterprise Structure, under the Sales and Distribution folders.

Primary Organizational Units

Sales organization is the entity responsible for selling materials and services. Each sales organization has its own customer and material master data, conditions, and pricing. A sales organization maps to exactly one company code. Multiple plants can be assigned to one sales organization. Sales organizations are represented by a four-character alphanumeric key. Configuration options affecting controls include whether the sales organization uses its own sales document types or shares them, an internal customer number for intercompany sales, and whether rebate processing is active.

Distribution channel is the method by which goods and services reach customers, such as retail, wholesale, or direct sales. A distribution channel can be assigned to one or more sales organizations and distribute from one or more plants. Represented by a two-character alphanumeric key. No configuration directly affects internal controls.

Sales office optionally represents geographies or regions. Sales offices have addresses and can hold employees. Available as a selection criterion for sales document lists but not for delivery or billing documents. Represented by a four-character alphanumeric key.

Sales group optionally associates with one or more sales offices and can hold employees. Available for sales document selection but not delivery or billing documents. Represented by a three-character alphanumeric key.

Important note about the Hide In configuration checkbox present on many enterprise structure elements: this checkbox only controls whether the item appears on the input help dropdown list. It does not deactivate the item. The organizational unit remains valid and usable by typing the key directly into the selection screen.

Assignment Configuration

Sales organization to company code establishes the link to financial accounting. A sales organization maps to exactly one company code.

Division to sales organization creates a many-to-many relationship. Each division can have customer-specific agreements for partial deliveries, pricing, and payment terms.

Sales area is the combination of sales organization, distribution channel, and division. It can only be configured after distribution channels and divisions have been assigned to sales organizations.

Sales organization, distribution channel, and plant maps distribution channels within sales organizations to plants.

Business area account assignment creates rules defining what business area receives postings during sales transactions. This is account determination for business areas. For organizations using financial accounting with sales and distribution, enable this configuration to prevent manual entry mistakes.

None of these assignments directly create internal controls, but they indirectly enforce control by defining approved combinations. Combinations not defined in the enterprise structure assignment will produce an error message if a user attempts to create a sales, delivery, or billing document using them.

Key Concepts: Conditions and Access Sequences

Two concepts are fundamental to understanding order-to-cash pricing in SAP S/4HANA.

A condition represents a pricing-related rule. One condition type might calculate unit price multiplied by quantity equals extended price. Another might identify taxable line items and apply the relevant tax rate. Conditions can consider factors like customer, product, date of purchase, and scale quantities. Condition master data is extremely complex and integral to the entire order-to-cash process.

An access sequence is a configurable item that sets which condition records have priority. A customer-specific condition record takes precedence over a price list for a general customer grouping, which takes precedence over the standard material price.

Master Data: Business Partners, Conditions, and Credit

Business Partner Data for Customers

In SAP S/4HANA, customer master records are part of the business partner function. Customer data includes general data (applying to all business partner roles), sales-related data (used by sales and distribution), financial accounting data (used for accounts receivable), and collections data.

Display business partner data through transaction BP. Key fields for audit include the following.

Account Group (visible on the Customer: General Data tab). The account group determines the number range and the field status group configuration dictating which fields are required, optional, suppressed, or display-only. Ensure customers are assigned to the correct account group.

The business partner record itself also has an account group assigned at creation. To see it after creation, select Extras, Create/Change from the main menu in the BP display.

Authorization Group (visible in the General Data section of the Customer: General Data tab, and separately on the Control tab of the business partner record). The customer-level authorization group works with authorization object F_KNA1_GRP to limit which employees can interact with specific customers. If blank, any employee with customer business partner role security can access the data. The business partner-level authorization group on the Control tab works with authorization object B_BUPA_GRP. Authorization groups can also be assigned to sales organization-specific customer data on the Orders tab.

Alternate Payee (on the Customer: Payment Transactions tab of company code-specific data). This optional field redirects payments to another business partner. Intended for related entities where payment goes to a corporate parent instead of a subsidiary. Can be used for nefarious purposes if an unauthorized entity is entered. Verify all alternate payees during your audit, ideally with independent customer confirmation.

In SAP S/4HANA, the previously high-risk Alternative Payer in Doc flag has been improved. The flag is no longer user-editable and only activates if a Permitted Payee list has been created. Payments can only be redirected to actual business partners on the permitted list, not to free-form text entries as in SAP ERP.

Deletion Flag and Archiving Indicator. Company code-specific and sales organization-specific data can have a Deletion Flag. Business partner general data can have an Archiving Indicator. Both trigger archiving on the next archiving run (the deletion flag does not actually delete data). If set, the related posting blocks should also be set. SAP S/4HANA issues a warning message if attempting to post to a customer with these flags, but the warning can be bypassed by pressing Enter. A common audit test identifies customers with deletion flags or archiving indicators but without corresponding posting blocks.

Reconciliation Account (on the Customer: Account Management tab). Defines the GL account updated whenever the subledger receives an invoice or payment posting. Validate that entries are appropriate and that all customers expected to have postings have been assigned a reconciliation account.

Additional fields warranting audit attention include payment terms (affecting payment timeliness), Incoterms (affecting revenue recognition timing), proof of delivery settings (also affecting revenue recognition), blocking indicators (creating process bottlenecks if unresolved), and shipping tolerances defining whether overdelivery or underdelivery is allowed.

Duplicate Customer Detection

SAP S/4HANA introduces fuzzy matching for duplicate detection, using inexact matching more likely to catch duplicates where minor differences like periods or abbreviations cause exact matches to fail. Configure through SAP Reference IMG, Service, Master Data, Business Partner, Activate and Configure Duplicate Check.

Condition Records

Pricing is determined by condition prioritization rules based on combinations of customer, material, price list, currency, scale quantities, and discount structures. View condition records through transaction VK33, which offers display options including material prices, discounts and surcharges, freight and taxes, and specific condition types.

When auditing conditions, verify effective dates (conditions are typically time-bounded), units of measurement (a UoM error dramatically impacts pricing), scale quantities (particularly where different thresholds produce different unit prices), and that review controls exist for mass price updates or condition changes.

Credit Master Data

Credit master data in SAP S/4HANA consists of credit profile and credit segment data. The credit profile includes rules, scores, ratings, risk class, notes, collateral, and check procedures. The credit segment includes credit limit, credit exposure, and payment behaviors.

In SAP ERP, credit limits were assigned at the credit control area. In SAP S/4HANA, credit limits are assigned at the credit segment level in the business partner.

A credit segment can be assigned to multiple credit control areas. One credit control area maps to multiple company codes. One company code maps to multiple sales organizations. A business partner can be associated with multiple credit segments, with a main segment serving as the parent.

View credit segment configuration through transaction SPRO: SAP Reference IMG, Financial Supply Chain Management, Credit Management, Credit Risk Monitoring, Master Data, Create Credit Segments. Key configuration includes whether credit checking occurs at the segment level, the main segment level, or both, and whether activity in the segment contributes to the main segment total.

When the Add. Contribution to Main Credit Segment field is unchecked for any segment, verify the business rationale. An unchecked field means activity in that segment does not count toward the main segment total, potentially allowing a customer to accumulate credit exposure across segments beyond what the main segment limit would otherwise allow.

Risk classes are assigned to business partners based on credit scores. They allow different behaviors and reactions to credit checks based on risk level. Risk class thresholds are fully customizable.

Original implementation tip: Verify that all buying-related business partners are associated with a credit segment and that credit limits have been defined. On one audit, I found 340 active customer accounts with no credit segment assignment. These customers had been created through a mass migration during the S/4HANA upgrade, and the migration tool did not automatically create credit segment data. For 14 months, these customers placed orders with no credit checking of any kind. The total outstanding receivables for these customers exceeded $4.2 million, including $600,000 over 90 days past due. The credit management team assumed all customers had been migrated with credit data because they had been told the migration was "complete."

Security Considerations

Restricting Transactions to Functional Sales Areas

Segregate the ability to create and maintain data by sales area, sales organization, distribution channel, and division.

Authorization object V_KNA1_VKO (Customer: Authorization for Sales Organizations) restricts customer data by sales organization, distribution channel, and division. Authorization object V_KNA1_BRG (Customer: Account Authorization for Sales Area) restricts by customer authorization group. Authorization object V_VBAK_VKO (Sales Document: Authorization for Sales Organizations) restricts sales activities by sales organization, distribution channel, and division. Authorization object V_VBAK_AAT (Sales Document: Authorization for Sales Document Types) restricts by sales document type.

If users are granted wildcard values for any field in these authorization objects, question why the restriction is not applied. A wildcard in the division field of V_VBAK_VKO means sales users can create orders across all divisions regardless of their actual responsibility.

Limiting Access to Powerful Transactions

Restrict the following transactions to a small number of personnel:

Transaction XD99 (mass maintenance of customer data). Transaction BP with delete activity for deleting customer master data. Transaction UKM_MASS_UPD3 (mass changes to customer credit limits). Transaction UKM_MASS_UPD2 (mass changes to customer credit scores). Transaction BP with unblock activity for unblocking business partners. Transaction UKM_MY_DCDS (unblocking sales orders with credit blocks, replacing SAP ERP transaction VKM1 though VKM1 can still be used as a workaround). Transaction FB75 (customer credit memos).

Because transaction BP is used for all business partner maintenance, you cannot simply remove it. Control is achieved through specific ACTVT values in business partner authorization objects that determine who can delete, block, and unblock.

Report PROFGEN_CORR_REPORT_2 (Exchange of Obsolete Transactions in Role Menu) provides a list of new, obsolete, and replaced transactions in your SAP S/4HANA instance. Run this report to verify your security roles do not contain obsolete transactions.

Beyond restricting access, monitor usage of these transactions independently of the group authorized to perform them. Few organizations have effective monitoring of powerful transaction usage for authorized users.

Authorization Objects for Master Data Control

Business partner authorization objects include B_BUPA_ADR (addresses, including employee addresses), B_BUPA_ATT (authorization types based on any field value), B_BUPA_BNK (bank data, including employee bank data), B_BUPA_FDG (field groups restricting specific fields), B_BUPA_GRP (authorization groups), and B_BUPA_RLT (roles restricting business partner role maintenance).

Customer-specific authorization objects include F_KNA1_BED (accounts authorization by customer range), F_KNA1_APP (application authorization restricting to sales or company code data), F_KNA1_BUK (company code authorization), F_KNA1_GRP (account group authorization), F_KNA1_AEN (change authorization for specific fields), V_KNA1_BRG (account authorization for sales area by customer authorization group), and V_KNA1_VKO (authorization for sales organizations by sales organization, distribution channel, and division).

Credit management authorization objects include F_KNKK_BED (accounts authorization by customer range), F_KNKA_KKB (authorization for credit control area), F_KNKA_AEN (change authorization for specific credit fields), and F_UKM_SGMT (authorization for credit segment display and maintenance).

Pricing condition authorization objects include V_KONH_VKO (authorization for sales organizations by sales organization, distribution channel, and division), V_KONH_VKS (authorization for condition types), and V_KONG_VWE (authorization for generating condition tables).

Original implementation tip: During a security review of order-to-cash authorization objects, I discovered that the pricing condition authorization object V_KONH_VKS was granted with wildcard values for condition type to 23 users. This meant every one of those users could maintain any pricing condition type in the system, including discount conditions, surcharge conditions, and freight conditions. Only four of those users had any business reason to touch pricing. The remaining 19 had the authorization because the role they were assigned was originally designed as a "sales power user" role during the implementation, and nobody revisited its scope after go-live. Restrict V_KONH_VKS to specific condition types relevant to each user's actual responsibility.

Testing Common Controls: Missing Data Entry in Critical Fields

Incompleteness Procedures

The most common way to add required fields in sales and distribution is through incompleteness procedures. Unlike field status groups (which prevent saving), incompleteness procedures are delayed required fields. A document can be saved with incomplete data, but downstream documents cannot be created until the missing data is entered. This design accommodates situations where data may not be available at order entry (like the weight of a custom-manufactured item) but is needed before delivery.

The maturity model applied to this risk spans five levels.

At level 1, SAP S/4HANA issues an error message if inherently required fields are empty and prevents further processing based on default incompleteness procedures. This is out-of-the-box functionality.

At level 2, incompleteness procedures have been customized to the organization's business process requirements, with warning messages configured for fields critical to downstream processing.

At level 3, the responsible party periodically reviews the Incomplete SD Documents report (transaction V.00) for items incomplete for more than a defined number of days.

At level 4, the responsible party reviews incomplete documents over a defined age with the related party and the corporate controller to ensure appropriate accruals for items with financial impact.

At level 5, an automated daily process notifies the accountable party of incomplete documents exceeding defined SLAs and flags the control as deficient if no reason code is entered within the configured response period.

Testing Incompleteness Procedures

View incompleteness procedure configuration through transaction SPRO, navigating to SAP Reference IMG, Sales and Distribution, Basic Functions, Log of Incomplete Items. Select the incompleteness group (sales document header, sales document line item, etc.), click the Procedures folder, select the procedure, and click the Fields folder.

The configuration shows which fields are included, whether each triggers a warning message on save, and the status and sequence attributes controlling processing behavior.

Verify that incompleteness procedures are assigned to the correct document types. Procedures can be assigned to six categories: sales document types, item categories, schedule line categories, partner functions, delivery types, and delivery item categories.

If an incompleteness procedure designed for standard orders is assigned to a cash sale document type, question whether the required fields make sense. A cash sale requiring payment terms in the incompleteness procedure is illogical if payment is received at the point of sale.

Customer-related business partner master data uses field attributes (field status groups) rather than incompleteness procedures. View through transaction SPRO, SAP Reference IMG, Cross Application Components, SAP Business Partner, Business Partner, Basic Settings, Field Groupings. Select Configure Field Attributes per BP Role or Configure Field Attributes per Business Partner Type.

In SAP S/4HANA, the default value for most fields is "Not spec." (not specified), a new attribute not available in SAP ERP where the default was "optional." The "Not spec." value makes it impossible to determine whether the implementation team intentionally chose not to require the field or simply never made a decision. During implementation, every field should receive a positive determination. A field showing "Not spec." in production indicates incomplete configuration and should appear in your audit report.

Original implementation tip: The most common observation on data completeness controls is that field status groups and incompleteness procedures were left at default values. This happens frequently with accelerated implementations or low-cost system integrators. The consequence is reliance on policies and manual reviews to catch missing data, which increases both error risk and ongoing cost. On one audit, I found that the incompleteness procedure for return orders did not include the customer reference field. Return orders were created without reference to the original order number, making it impossible to systematically match returns to original sales. The returns team spent an estimated 200 hours per quarter manually researching which original orders corresponded to each return.

Testing Common Controls: Pricing and Revenue Recognition Accuracy

Copy Control Rules

Copy control configurations copy data from upstream documents (sales orders) to downstream documents (deliveries, billing documents). Properly configured copy control "controls" document creation by automatically determining values and optionally preventing user changes.

Key copy control transactions provide direct access to configuration:

Transaction VTAA: Sales document to sales document (quotation to order).
Transaction VTLA: Sales document to delivery document.
Transaction VTFA: Sales document to billing document.
Transaction VTFL: Delivery document to billing document.
Transaction VTFF: Billing document to billing document (original bill to credit).

For each copy control configuration, key fields to verify include the Billing Quantity indicator (determining how quantity is calculated, such as order quantity minus previously invoiced quantity), the Pos./Neg. Quantity indicator (positive or negative), the Pricing Type (determining whether price is copied unchanged, redetermined, or manually entered), and the Price Source (determining where the price originates).

Common Billing Quantity values include A (order quantity minus previously invoiced quantity) and B (delivery quantity minus previously invoiced quantity). Common Pricing Type values include D (copy price unchanged from source document) and C (copy manual price elements and redetermine others like taxes). A blank Price Source means the price is copied from the order.

Because copy control configurations easily number in the thousands when considering every billing document type, sales or delivery document type, and item category combination, performing a complete audit of each is impractical. If original implementation documentation exists, compare current settings against the go-live baseline. Take a snapshot of table TVCPF (all billing-related copy control rules) during your audit for future comparison.

The Update Document Flow setting in copy control rules for sales and delivery documents controls whether the related documents appear in the document flow trail. This setting is configurable and can be turned off, which removes documents from the audit trail visible through transaction ALO1. Question any configuration where document flow is disabled. An external auditor using document flow to verify the relationship between sales documents would consider missing documents a red flag.

Pricing Procedures

The pricing procedure determines which condition types apply and in what order, how subtotals appear, and how discounts and surcharges are calculated.

The determination path works as follows. Based on the sales area, sales document type, and customer, SAP determines the pricing procedure. View this determination through transaction SPRO, SAP Reference IMG, Sales and Distribution, Basic Functions, Pricing, Pricing Control, Define and Assign Pricing Procedures.

Within the pricing procedure, condition types are processed in sequence. Each step defines a condition type, whether it is required, and whether it allows manual entry. View pricing procedure details through the same IMG path.

For each condition type, SAP checks the assigned access sequence. View access sequences and their associated condition tables to understand the search priority. The system continues checking condition records in the order specified by the access sequence until the first match is found. That match determines the price.

Condition Type Risk: Manual Override

One of the highest-risk settings on a condition type determines whether manual entries can override the system-calculated price. View condition types through transaction V/06.

The Manual Entries field has several values. D (Not possible to process manually) and B (Automatic entry has priority) are the most restrictive. Any other value allows manual entry or override. Manual override should only be expected where automated calculation is not possible or practical, such as judgmentally determined price reductions.

For condition types where business reasons require manual updates, configure price change tolerances through transaction SPRO: SAP Reference IMG, Sales and Distribution, Basic Functions, Pricing, Pricing Control, Define Condition Types, then selecting Define upper/lower limits for conditions. Manual changes are only permitted within defined upper and lower limits.

Run the built-in pricing procedure check through transaction SPRO, SAP Reference IMG, Sales and Distribution, Basic Functions, Pricing, Pricing Control, Define and Assign Pricing Procedures, then choosing Check Settings for Pricing Procedures. This identifies procedures with warning or error messages in their configuration.

Run the condition type check through the same IMG path under Define Condition Types, choosing Check settings for condition types. This identifies condition types with mismatched fields.

Pricing Account Determination

After validating how quantity and pricing flow to delivery and billing documents, verify that appropriate GL accounts receive revenue-related postings.

Step 1: Identify account determination procedures associated with billing document types. Navigate through transaction SPRO to SAP Reference IMG, Sales and Distribution, Basic Functions, Account Assignment/Costing, Revenue Account Determination, Define and Assign Account Determination Procedure, then Assign Account Determination Procedure.

Step 2: Determine the condition types associated with each procedure. Select the procedure, double-click Control data.

Step 3: Determine the access sequences associated with each condition type. Navigate to Define Access Sequences and Account Determination Types, select Define Access Sequences, select the condition type, and double-click the Accesses folder.

Step 4: Determine the GL accounts that receive postings. Navigate to Assign GL Accounts and double-click the relevant table. Verify that the GL accounts are appropriate for each type of pricing activity.

This process is significantly more complex than standard financial accounting account determination. Work with a pricing specialist for your first pricing account determination audit.

Original implementation tip: The most common pricing-related observation is excessive manual override capability with insufficient monitoring. I have seen organizations where 12 condition types allowed manual override, but only two had documented business justification. The remaining ten were left at default configuration during implementation. Additionally, copy control rules created after go-live frequently contained incorrect pricing type values. One organization added a new billing document type for service invoices with Pricing Type set to blank (meaning prices would be newly determined) instead of D (copy unchanged from order). Service invoices were being repriced at current rates instead of the rates agreed at order entry, creating both overcharges and undercharges depending on whether rates had increased or decreased since the original order.

Testing Common Controls: Customer Credit Management

Credit Checking During Sales and Delivery

SAP S/4HANA can verify customer credit at multiple points during the order-to-cash process. Configuration can be applied to any sales document type and any delivery document type.

For sales document types, options include simple credit checking (checking at document save against a defined credit limit) and automatic credit control (extending beyond order value to consider open orders, late payment history, and other attributes). Automatic credit control can result in warning messages, error messages, or delivery blocks.

For delivery document types, credit checking specifies the points in the delivery or goods issue process where additional checks occur.

Testing Credit Check Configuration

Determine whether credit checking is enabled for each relevant document type. Run transaction SPRO, navigate to SAP Reference IMG, Financial Supply Chain Management, Credit Management, Integration with Accounts Receivable Accounting and Sales and Distribution, Integration with Sales and Distribution, Assign Sales Documents and Delivery Documents. Separately select Set Credit Limit Checks for Sales Document Types and Set Credit Limit Checks for Delivery Types.

The Check Credit field values include options for simple credit checks with warning messages and automatic credit control. For automatic credit control, view initial settings through transaction OVA8, double-clicking the desired combination of credit control area, risk category, and credit group.

The reaction field in OVA8 determines behavior. A value of A indicates a warning message with a credit block. Other values may produce only warnings without blocks.

For SAP S/4HANA enhanced credit checking rules, view through transaction SPRO, SAP Reference IMG, Financial Supply Chain Management, Credit Management, Credit Risk Monitoring, Credit Limit Check, Define Checking Rules.

The most common observation on credit management is failure to apply credit checking to all relevant sales and delivery document types. This occurs most frequently when organizations add document types after go-live. Every new sales and delivery document type should be evaluated for credit check assignment as part of the change management process.

Testing Common Controls: Returns and Credit Controls

Mandatory Reference Documents

Documents in SAP S/4HANA can require a reference to another document before they can be created. For returns, the ideal reference is the original sales order or delivery document. Many document types do not require references by default.

View reference document requirements for sales document types through transaction SPRO, SAP Reference IMG, Sales and Distribution, Sales, Sales Documents, Sales Document Header, Define Sales Document Types. Double-click the document type. The Reference Mandatory field shows whether a reference is required and to what type of document.

View reference requirements for delivery document types through transaction SPRO, SAP Reference IMG, Logistics Execution, Shipping, Deliveries, Define Delivery Types. The Order Required field in the Order Reference section shows whether a sales order, purchase order, or other reference is required.

Note that upon initial implementation, the reference mandatory field often cannot be set to mandatory because source documents may reside in the legacy system. After sufficient time for SAP S/4HANA to become the book of record, many organizations forget to change this flag. This is one of the most common and most easily preventable audit observations I encounter.

Automatic Blocking

All order-to-cash document types can be configured with blocking indicators. These blocks require a user with specific security authorization to release them, creating a form of segregation of duties where the document creator cannot also release it.

Sales document types can have sales document blocks, delivery blocks, and billing blocks configured directly in the document type definition.

Delivery document blocks are configured separately through transaction SPRO, SAP Reference IMG, Logistics Execution, Shipping, Deliveries, Assign Blocking Reasons to Delivery Types. Multiple blocking reasons can be assigned to a single delivery type. Some blocks are set automatically (like credit limit blocks), others are set manually (like political reasons blocks). Verify with your teams which are automatic and which are manual.

Billing document blocks are configured at SAP Reference IMG, Sales and Distribution, Billing, Billing Documents, Define Blocking Reason for Billing.

Original implementation tip: The most common observation on returns and credits is reliance on manual policies rather than mandatory reference document configuration. Making reference documents mandatory is a straightforward configuration step. It eliminates the risk that an employee creates a credit memo or return without linking it to the original transaction. A credit memo without a reference to a specific billing document has no systematic validation that the credit amount does not exceed the original invoice. A return without a reference to a specific delivery has no systematic verification that the returned items were ever shipped. Configure reference mandatory for every return and credit document type once your legacy migration period has ended.

Additional Procedures Worth Testing

Order Entry Completeness and Timeliness

For organizations accepting manual orders through fax, mail, or email, log all incoming orders and periodically reconcile the log against SAP entries. Auditors compare order receipt dates against SAP entry dates, so mechanisms ensuring timely entry are valuable. Watch for duplicate entries when customers submit orders through multiple channels.

Duplicate Detection in Master Data

Periodically review customer and material master data for duplicates using creative matching criteria. For materials, search by same name or description, similar name with same plant, same dimensions and weight, or same bill of material details. For customers, search by similar names, same phone or email, or same postal code and street number combination. If duplicates are found, research whether undesired conditions like credit overextension or payment misapplication have occurred.

One-Time Customer Monitoring

Controls for one-time customers are typically less stringent than for standard customers. Periodically monitor one-time customer usage to ensure processing matches expectations (low dollar amounts, low transaction frequency). Select one-time customers from the customer list through transaction RFDKVZ00_AUDIT.

Customer Payment Monitoring

Reconcile bank accounts used for customer payment collection and resolve all reconciling items promptly. Review accounts receivable aging reports and investigate amounts outstanding beyond acceptable periods.

Useful Audit Reports

Change Reports

Transaction VK13 displays changes to pricing conditions. Select a specific condition or use More, Environment, Changes, Change Report for all conditions. Apply reasonable date filters. Running these reports with open date ranges in a system live for several years produces unmanageable volumes.

Transaction XD04 displays changes to customer-related business partner data. From the main menu, select More, Environment, Multiple Display. Filter by general data changes, company code-specific changes, or sales organization changes. Focus on fields like customer name, address, payment terms, and deletion flags.

For customer credit change reporting, SAP ERP transaction S_ALR_87012215 no longer exists in SAP S/4HANA. FSCM changes can be reported through transaction RMPS_AUDIT. The replacement is not as straightforward for isolating credit limit changes specifically.

Incomplete Information Reports

Transaction F.2D with the selection parameter Not created in Fin. Accounting identifies customers with sales activity but no financial accounting record. The reverse (financial accounting record but no sales record) is expected only for migrated customers not expected to do future business.

Transaction V.00 shows documents with incomplete data across different incompleteness categories. Filter by sales area, user, or transaction. For aging analysis, use Change Layout from results, select the Filter tab, add Created On to Filter Criteria, and set date ranges. Pay attention to patterns in the Created By field. Employees appearing with disproportionate frequency may need additional training.

Transaction VF04 (Maintain Billing Due List) shows orders not yet invoiced, ordered by expected billing date. At period end, these items impact revenue recognition. Verify sufficient justification exists for each.

Transaction V.15 shows backorders. Transaction VL06 provides the delivery monitor for overall delivery process status.

Customer Receivables Reports

Transaction S_ALR_87012168 provides customer open items analysis as of a given date, filterable by business partner and company code.

The Credit Exposure List report shows customers near or over their credit limit. Set the utilization percentage to identify customers at specific thresholds (110% for those over limit, 95% for those approaching limit). Results include the percentage of credit used.

General Information Reports

Transaction VK13 displays specific condition records. Transaction V/LD displays pricing reports with dropdown selection. Transaction VA03 displays sales documents. Transaction VL03N displays outbound deliveries. Transaction VF03 displays billing documents. Transaction ALO1 displays complete document flow for a transaction, showing all related sales orders, deliveries, returns, billings, cancellations, and payment receipts on a single screen.

Tips for Order-to-Cash Audits

Original implementation tip on post-go-live document types: Every new sales document type, delivery document type, and billing document type added after go-live should be reviewed against the same control checklist used during implementation. That checklist should include credit check assignment, reference document requirements, blocking indicators, incompleteness procedure assignment, copy control configuration, and pricing procedure determination. I maintain a standard 12-point control verification template for new document types. Without it, the change request process focuses on functional requirements and ignores control configuration. The result is the scenario I described at the beginning of this post.

Original implementation tip on pricing condition monitoring: Build a periodic review process for pricing conditions that compares current conditions against authorized price lists. Select a sample of sales orders each month, recalculate pricing outside of SAP based on the organization's pricing policy, and compare against what the customer was charged. Any discrepancy indicates either a condition error, a copy control problem, or a manual override that should be investigated. Your external auditor will perform this test. Self-auditing with the same procedure gives you advance warning of issues and reduces external audit effort.

Original implementation tip on free-of-charge delivery monitoring: Free-of-charge deliveries are legitimate functionality for replacing damaged shipments. They are also a mechanism for giving preferred customers additional goods at no cost, effectively creating unauthorized discounts outside the pricing structure. Monitor free-of-charge delivery volume by sales representative, customer, and product. Unusual patterns, particularly high volumes to specific customers from specific representatives, warrant investigation. This is the type of finding that rarely appears in a standard controls-based audit but emerges immediately when you analyze transactional data.

Original implementation tip on credit limit change evidence: In SAP ERP, transaction S_ALR_87012215 provided a clean report of credit limit changes. SAP S/4HANA removed this report without providing an equivalent replacement. Build a compensating monitoring process using change document tables CDHDR and CDPOS. Filter CDHDR on OBJECTCLAS values relevant to credit management, join with CDPOS, and filter on FNAME for credit limit fields. Extract this data monthly and review changes for authorization and appropriateness. Without this compensating control, credit limit changes go unmonitored.

SAP S/4HANA Audit Program: Order-to-Cash Cycle

Audit Objectives

This audit program provides a structured approach for evaluating the Order-to-Cash (O2C) cycle in an SAP S/4HANA environment. The program is designed for auditors, compliance professionals, and operations specialists who need to assess the reliability, integrity, and effectiveness of sales, delivery, billing, and collections processes. The primary objectives are to:

• Evaluate the design and operating effectiveness of controls over sales order processing, pricing, delivery, billing, and accounts receivable

• Assess configuration settings that impact the completeness and accuracy of order-to-cash transactions

• Review master data controls and security configurations that protect sales and customer information

• Validate credit management processes and procedures for mitigating customer non-payment risk

• 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, industry requirements, and system complexity.

---

Section 1: Understanding the SAP S/4HANA Order-to-Cash Environment

1.1 SAP S/4HANA Specific Features Impacting Order-to-Cash

Audit Objective: Understand the unique SAP S/4HANA features that affect order-to-cash processes and identify any related risks.

Background: SAP S/4HANA introduces significant changes to order-to-cash functionality compared to legacy SAP ERP systems. Key changes include the business partner approach for customer master data, Financial Supply Chain Management (FSCM) credit management replacing classic credit management, streamlined pricing data models, settlement management replacing rebate processing, and SAP Revenue Accounting and Reporting replacing traditional revenue recognition.

Audit Procedures:

• Identify which SAP S/4HANA-specific order-to-cash features are implemented:

  • Business partner for customer master data

  • FSCM credit management

  • New pricing data model (see SAP Note 2267308 for table changes)

  • Settlement management for rebates (see SAP Note 2267377 for retired transactions)

  • SAP Revenue Accounting and Reporting (if IFRS 15 compliance is required)

• Review SAP Notes related to retired transactions and functionality:

  • SAP Note 2270544 - Credit management transactions retired and replaced

  • SAP Note 2267308 - Pricing table changes and data elements

  • SAP Note 2267377 - Rebate processing changes and settlement management

  • SAP Note 2267342 - Revenue recognition changes and SAP Revenue Accounting and Reporting

  • SAP Note 2265093 - Customer master data changes and business partner approach

• Verify that the organization is using current, supported functionality and has properly migrated from legacy transactions

• Review documentation of order-to-cash processes that leverage new S/4HANA functionality

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

---

Section 2: Risks in the Order-to-Cash Cycle

Audit Objective: Identify and understand the key risks affecting order-to-cash processes and related financial reporting.

Risk Categories and Audit Focus:

Risk Category	Description	Audit Focus
Missed sales opportunities	Failure to fully capture customer information, late data entry, or inaccurate interpretation	Review customer data completeness; assess order entry timeliness procedures
Inaccurate quotations	Incorrect pricing, product selection, or quotation duration	Test quotation-to-order copy control; review pricing condition accuracy
Pricing errors	Manual entry errors, incomplete condition maintenance, or incorrect condition access sequences	Review pricing condition configuration; test pricing calculation accuracy
Unauthorized rebates and discounts	Use of discounts not intended by management	Review condition type configuration; monitor manual price overrides
Duplicate orders	Processing same order multiple times	Assess duplicate checking procedures; review order entry controls
Missed delivery dates	Failure to account for backorders, inaccurate due dates, or unresolved blocks	Review delivery block monitoring; assess backorder processes
Late or missed billing	Missing required information preventing billing	Test incompleteness procedures; review billing due list monitoring
Payment reconciliation issues	Inability to tie payments to orders	Review cash application processes; assess accounts receivable aging
Insufficient credit but goods shipped	Credit deterioration between order and delivery	Test credit check configuration at delivery; review credit exposure monitoring
Revenue not recognized when allowed	Blocked billing documents or incomplete processing	Review billing document blocks; assess period-end revenue recognition procedures
Inaccurate customer activity reporting	Duplicate customers or incorrect master data	Test duplicate customer detection; review customer master data quality
Fraudulent transactions	Diversion of goods, unauthorized credits, or manipulation to reach targets	Review segregation of duties; monitor high-risk transactions

---

Section 3: Enterprise Structure Review

Audit Objective: Verify that the enterprise structure supporting order-to-cash processes is appropriately configured and aligned with organizational and operational requirements.

3.1 Sales and Distribution Organizational Units

Background: The enterprise structure defines how your organization is represented in SAP S/4HANA for sales and distribution processes. Key elements include sales organization, distribution channel, division, sales area, sales office, sales group, and assignments to company code and plant.

Audit Procedures:

• Using Transaction SPRO, navigate to SAP Reference IMG • Enterprise Structure • Definition • Sales and Distribution

• Review the following organizational units for appropriate configuration:

Sales Organization:

• Obtain a listing of all sales organizations using Transaction OVX5

• Verify that each sales organization represents a logical selling entity

• Review sales organization configuration:

  • Sales document type assignment (can share with other sales organizations or have own)

  • Intercompany customer number (for intercompany sales)

  • Rebate processing active/inactive flag

• Confirm that each sales organization is assigned to exactly one company code (Transaction OVX3)

Distribution Channel:

• Review distribution channel definitions (Transaction OVX6)

• Verify that distribution channels reflect how goods reach customers (retail, wholesale, direct, etc.)

• Confirm that inactive or unused distribution channels are appropriately managed

Division:

• Review division definitions (Transaction OVX7)

• Verify that divisions reflect product lines or business segments

• Confirm that customer-specific agreements can be properly managed by division

Sales Area:

• Verify that sales areas (combination of sales organization, distribution channel, and division) are properly defined (Transaction OVX4)

• Confirm that all required sales area combinations exist for business operations

Sales Office and Sales Group (if used):

• Review sales office definitions (Transaction OVX1)

• Review sales group definitions (Transaction OVX2)

• Verify that sales offices and groups are appropriately assigned to reflect geographic or team structures

Assignments:

• Verify sales organization to company code assignment (Transaction OVX3)

• Verify division to sales organization assignment (Transaction VOR1)

• Verify sales organization, distribution channel, and plant assignment (Transaction OVX9)

• Review business area account assignment rules (Transaction OVX8) if used for automatic business area determination

Important Consideration: The "Hide in" checkbox in configuration screens merely prevents the item from appearing in dropdown lists—it does not deactivate the item. Items with this flag checked can still be used by manually typing the key.

Common Findings:

• Sales organizations not aligned with business operations

• Missing sales area combinations required for business processes

• Inconsistent assignments causing processing errors

• Business area account assignment not configured, requiring manual entry

---

Section 4: Master Data Review

Audit Objective: Assess the controls over master data that impacts order-to-cash processes, including business partners (customers), condition records (pricing), and credit master data.

4.1 Business Partner (Customer) Master Data

Background: In SAP S/4HANA, customer master records are managed through the business partner functionality. Customer data exists at three levels: general data (applicable across all business partner roles), company code-specific data (financial accounting), and sales area-specific data (sales and distribution). Control-related settings can be changed in production without transport, requiring strong change management.

Audit Procedures:

• Using Transaction BP, review a sample of customer business partner records

• For each sample, verify:

General Data (Customer Role):

• Account group assignment (determines number range and field status) - see Figure 7.1

• Authorization group (if used to restrict access) - see Figure 7.1

• Archiving indicator (should have corresponding posting blocks if set) - see Figure 7.5

• Business partner account group (can be viewed via Extras • Create/Change) - see Figure 7.2

• Business partner authorization group (Control tab) - see Figure 7.3

Company Code-Specific Data (Financial Accounting):

• Reconciliation account (proper general ledger account assignment)

• Payment terms (affect payment timing)

• Alternate payee (if populated, verify appropriateness) - see Figure 7.4

• Deletion flag (should have corresponding posting block if set) - see Figure 7.5

• Posting block (should be set if customer should not have activity)

• Dunning data (if collections in scope)

Sales Area-Specific Data (Sales and Distribution):

• Sales organization, distribution channel, division assignment

• Sales district (if used)

• Customer pricing procedure

• Delivery priority

• Shipping conditions

• Incoterms (affect revenue recognition timing)

• Proof of delivery required flag (affects revenue recognition)

• Order combination (partial delivery settings)

• Delivery and billing blocks

Additional Fields for Consideration:

• Customer account group (affects field status)

• Authorization group for sales area data (V_KNA1_BRG authorization object)

• Payment terms (sales area level, may override company code terms)

• Tolerance groups (overdelivery/underdelivery)

• Using Transaction XD04, review changes to customer master data for the audit period (More • Environment • Multiple Display) - see Figure 7.35

• For significant changes, trace to supporting documentation and approvals

Key Authorization Objects for Customer Master:

Authorization Object	Purpose
B_BUPA_ADR	Restrict address modifications
B_BUPA_ATT	Restrict by field values
B_BUPA_BNK	Restrict banking data modifications
B_BUPA_FDG	Restrict field group modifications
B_BUPA_GRP	Restrict by authorization group
B_BUPA_RLT	Restrict by business partner role
F_KNA1_BED	Restrict by customer account range
F_KNA1_APP	Restrict by application (sales vs. company code)
F_KNA1_BUK	Restrict by company code
F_KNA1_GRP	Restrict by account group
F_KNA1_AEN	Restrict changes to specific fields
V_KNA1_BRG	Restrict by customer authorization group for sales area
V_KNA1_VKO	Restrict by sales organization, distribution channel, division

Common Findings:

• Deletion flags set without corresponding posting blocks

• Alternate payees not periodically reviewed for appropriateness

• Inconsistent assignment of payment terms across customers

• Duplicate customer records not identified or merged

• Authorization groups not used to segregate customer data access

4.2 Condition Records (Pricing Master Data)

Background: Pricing conditions determine the prices, discounts, surcharges, and taxes applied to sales documents. Condition records are effective-dated and can be highly complex, with access sequences defining priority rules.

Audit Procedures:

• Using Transaction VK13 or VK33, review a sample of pricing condition records - see Figure 7.6

• For each sample, verify:

  • Validity dates (beginning and end dates are appropriate)

  • Unit of measurement (consistent with material master)

  • Scale quantities (if volume-based pricing)

  • Condition amount or percentage

  • Customer/material combinations (if applicable)

• Using Transaction VK13 with change reporting, review changes to condition records during audit period (More • Environment • Changes • Change Report)

• For significant changes (e.g., mass updates, unusual discounts), trace to supporting documentation

• Review access sequences (Transaction V/07) to understand pricing priority rules - see Figure 7.15

• Verify that customer-specific conditions take precedence over general conditions where intended

• Review condition types (Transaction V/06) for high-risk settings - see Figure 7.24

  • Manual Entries field: Values other than B (automatic priority) or D (no manual processing) allow manual overrides

  • Upper/lower limits: If configured, verify limits are reasonable

Key Authorization Objects for Conditions:

Authorization Object	Purpose
V_KONH_VKO	Restrict by sales organization, distribution channel, division
V_KONH_VKS	Restrict by condition type
V_KONG_VWE	Restrict generation of condition tables

Common Findings:

• Manual overrides allowed without monitoring

• Condition validity dates not maintained (expired conditions still active)

• Mass price changes without independent review

• Access sequences not aligned with business pricing strategy

4.3 Credit Master Data

Background: SAP S/4HANA credit management (FSCM) provides enhanced capabilities for managing customer credit risk. Credit master data includes credit profile (risk class, scores, rules) and credit segment data (credit limits, exposure, payment behavior).

Audit Procedures:

• Using Transaction BP (Credit Management tab), review a sample of customer credit master records

• For each sample, verify:

  • Credit segment assignment - see Figure 7.7

  • Credit limit amount (reasonable based on business)

  • Risk class assignment - see Figure 7.9

  • Credit scores (if automatically or manually assigned)

  • Main segment designation (for customers with multiple segments)

• Review credit segment configuration (Transaction SPRO • Financial Supply Chain Management • Credit Management • Credit Risk Monitoring • Master Data • Create Credit Segments) - see Figure 7.8

  • Verify that "Add. Contribution to Main Credit Segment" settings are appropriate

• Review risk class definitions (Transaction SPRO • Financial Supply Chain Management • Credit Management • Credit Risk Monitoring • Master Data • Define Risk Classes)

  • Verify that risk classes align with credit policies

  • Confirm that credit check reactions (error, warning) are appropriate for each risk class

• Using Transaction RMPS_AUDIT, review changes to credit management data during audit period

Key Authorization Objects for Credit Management:

Authorization Object	Purpose
F_KNKK_BED	Restrict by customer account range
F_KNKA_KKB	Restrict by credit control area
F_KNKA_AEN	Restrict changes to specific fields
F_UKM_SGMT	Restrict credit segment display/maintenance

Common Findings:

• Customers not assigned to credit segments

• Credit limits not periodically reviewed or updated

• Risk classes not configured or inconsistently applied

• Credit checking not enabled for all relevant document types

---

Section 5: Security Considerations for Order-to-Cash

Audit Objective: Evaluate security controls that protect order-to-cash processes and data from unauthorized access or manipulation.

5.1 Restricting Transactions and Data by Sales Area

Audit Procedures:

• Using Transaction SUIM, identify users with authorization to create and maintain sales documents

• Verify that appropriate segregation of duties exists between:

  • Sales order entry and pricing maintenance

  • Customer master maintenance and sales order processing

  • Credit limit maintenance and order release

  • Delivery processing and billing

• Review assignment of authorization objects for sales processing:

  • V_KNA1_VKO - Restrict customer master by sales organization, distribution channel, division

  • V_KNA1_BRG - Restrict customer master by authorization group

  • V_VBAK_VKO - Restrict sales document processing by sales area

  • V_VBAK_AAT - Restrict sales document processing by document type

  • V_VBAK_APM - Restrict by division (verify not using wildcard * without justification)

5.2 Limiting Access to Powerful Transactions

Audit Procedures:

• Identify users with access to powerful order-to-cash transactions:

Transaction	Description	Risk
XD99	Mass customer maintenance	Unauthorized mass changes
BP (with delete authority)	Delete customer master	Loss of audit trail
UKM_MASS_UPD3	Mass credit limit changes	Unauthorized credit increases
UKM_MASS_UPD2	Mass credit score changes	Misrepresentation of risk
BP (with unblock authority)	Unblock business partners	Bypass credit controls
UKM_MY_DCDS / VKM1	Release credit blocks	Bypass credit decisions
FB75	Enter customer credit memos	Unauthorized credits

• 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

• Run the Exchange of Obsolete Transactions in Role Menu report (PROFGEN_CORR_REPORT_2) to identify obsolete SAP ERP transactions that should be removed from roles

5.3 Establishing Controls and Security over Master Data

Audit Procedures:

• Verify that the ability to change customer master data is limited to a core group of employees

• Review security for customer master changes (see authorization objects in Section 4.1)

• Verify that the ability to change pricing conditions is limited to authorized personnel (see Section 4.2)

• Verify that the ability to change credit master data is limited to authorized personnel (see Section 4.3)

Common Findings:

• Excessive users with access to powerful transactions

• No monitoring of powerful transaction usage

• Segregation of duties conflicts between order entry and pricing

• Customer master maintenance not appropriately segregated

---

Section 6: Configurable Controls - Missing Data Entry in Critical Fields

Audit Objective: Assess controls designed to ensure complete and accurate data entry in sales, delivery, and billing documents.

6.1 Incompleteness Procedures

Background: Incompleteness procedures are a configurable control in sales and distribution that issue warnings and prevent subsequent document processing when critical fields are missing. Unlike field status groups (which enforce at time of entry), incompleteness procedures allow delayed entry but block downstream processing until fields are populated.

Maturity Model Assessment:

Maturity Level	Controls to Test
Level 1	Inherent required fields and default incompleteness procedures only
Level 2	Customized incompleteness procedures aligned with business requirements
Level 3	Periodic review of Incomplete SD Documents report (Transaction V.00)
Level 4	Management review of aged incomplete documents with financial impact assessment
Level 5	Automated monitoring with SLA tracking and deficiency flagging

Audit Procedures:

• Using Transaction SPRO, navigate to Sales and Distribution • Basic Functions • Log of Incomplete Items

• Review incompleteness groups (sales document header, sales document line item, delivery header, delivery line item, etc.)

• For each relevant incompleteness procedure, review the fields configured - see Figure 7.10

  • Verify that fields critical to your business processes are included

  • Assess whether status and sequence settings are appropriate

  • Review message type configuration (warning vs. information)

• Verify that incompleteness procedures are properly assigned:

  • To sales document types - see Figure 7.11

  • To item categories

  • To schedule line categories

  • To partner functions

  • To delivery types

  • To delivery item categories

• Using Transaction V.00, run the Incomplete SD Documents report for the audit period - see Figure 7.36

  • Apply aging analysis to identify documents incomplete for extended periods

  • Investigate root causes for aged incomplete documents

  • Review management's monitoring evidence

• For customers, review field attributes for business partner master data:

  • Using Transaction SPRO, navigate to Cross Application Components • SAP Business Partner • Business Partner • Basic Settings • Field Groupings

  • Review Configure Field Attributes per BP Role or per Business Partner Type - see Figure 7.12

  • Pay special attention to fields marked "Not spec." (no decision made on field requirement)

  • Verify that critical fields (address, payment terms, etc.) are properly configured as required

Common Findings:

• Incompleteness procedures left at default values

• Critical fields not included in incompleteness checks

• No periodic review of incomplete documents

• Business partner field attributes marked "Not spec." (no implementation decision)

• Aged incomplete documents not investigated or resolved

---

Section 7: Configurable Controls - Price and Quantity Errors

Audit Objective: Assess controls designed to ensure accurate pricing and quantities in sales, delivery, and billing documents, including copy control, pricing procedures, and account determination.

7.1 Copy Control Rules

Background: Copy control defines how data flows from upstream documents (quotations, sales orders) to downstream documents (deliveries, billing documents). Proper configuration ensures quantities and prices are accurately transferred.

Audit Procedures:

• Review copy control rules for key document flows:

Document Flow	Transaction	Focus
Quotation → Sales Order	VTAA	Verify quantities and prices copy correctly
Sales Order → Delivery	VTLA	Verify delivery quantity calculation - see Figure 7.22
Sales Order → Billing	VTFA	Verify billing quantity and price sources - see Figure 7.17
Delivery → Billing	VTFL	Verify billing quantity and price sources - see Figure 7.20
Billing → Billing (credit)	VTFF	Verify credit memo copy rules

• For each copy control rule, review key settings:

  • Billing Quantity field - Values determine quantity calculation (A = order quantity less invoiced, B = delivery quantity less invoiced, etc.) - see Figure 7.18

  • Pricing Type field - Values determine price determination (A = copy, B = copy and redetermine, C = copy manual and redetermine others, D = recalculate) - see Figure 7.19

  • Price Source field - Values determine source of price (blank = order, A = material master, B = condition record) - see Figure 7.21

  • Update document flow field - Should be set to allow document flow visibility; blank indicates disabled, which should be questioned - see Figure 7.22

• For delivery document copy control, verify that quantity calculations are appropriate for business processes

• If implementation documentation exists, compare current settings to go-live configuration

• Consider taking snapshots of configuration tables (e.g., TVCPF for billing copy control) for future comparison

Common Findings:

• Copy control rules not copying appropriate quantities or prices

• Document flow disabled, preventing audit trail visibility

• Post-implementation changes not properly tested

• Custom copy control rules not documented

7.2 Pricing Procedures and Condition Types

Background: Pricing procedures define the sequence of condition types applied during sales document pricing. Access sequences determine priority rules for condition record selection.

Audit Procedures:

• Run built-in pricing procedure checks:

  • Transaction SPRO • Sales and Distribution • Basic Functions • Pricing • Pricing Control • Define and Assign Pricing Procedures

  • Select "Check Settings for Pricing Procedures"

  • Run for relevant pricing procedures; investigate any warnings or errors

• Run built-in condition type checks:

  • Transaction SPRO • Sales and Distribution • Basic Functions • Pricing • Pricing Control • Define Condition Types

  • Select "Check settings for condition types"

  • Investigate any errors (e.g., mismatched reference condition type and calculation condition type) - see Figure 7.23

• Review pricing procedure determination:

  • Using Transaction V/08, review how pricing procedures are assigned based on sales area, document type, and customer - see Figure 7.13

  • Verify that appropriate pricing procedures are used for different sales scenarios

• Review pricing procedure configuration:

  • Using Transaction V/06, review condition types within each pricing procedure - see Figure 7.14

  • Verify that condition types appear in correct sequence

  • Check manual entry settings for each condition type

  • Review condition type configuration for high-risk settings:

    • Manual Entries - Values other than B or D allow manual overrides - see Figure 7.24

    • Upper/lower limits - If configured, verify limits are reasonable

• Review condition type access sequences:

  • Using Transaction V/07, review access sequences for key condition types - see Figure 7.15

  • Verify that access priorities align with business rules (customer-specific before general)

  • Review search criteria for each access - see Figure 7.16

Common Findings:

• Manual overrides allowed on condition types that should be automatic

• Access sequences not aligned with business pricing strategy

• Pricing procedure checks reveal configuration errors

• Condition type checks reveal inconsistencies

7.3 Pricing Account Determination

Background: Pricing account determination defines which general ledger accounts receive postings from sales transactions. The configuration follows a multi-step process similar to pricing procedures.

Audit Procedures:

• Identify account determination procedures assigned to billing document types:

  • Transaction SPRO • Sales and Distribution • Basic Function • Account Assignment/Costing • Revenue Account Determination • Define and Assign Account Determination Procedure

  • Select "Assign Account Determination Procedure" - see Figure 7.25

  • Document which account determination procedure is used for each billing document type

• Review condition types associated with the account determination procedure:

  • Select the account determination procedure and double-click "Control data" folder - see Figure 7.26

  • Document condition types used (e.g., KOFI for revenue, KOFK for controlling)

• Review access sequences for account determination condition types:

  • Transaction SPRO • Sales and Distribution • Basic Function • Account Assignment/Costing • Revenue Account Determination • Define Access Sequences and Account Determination Types

  • Select "Define Access Sequences"

  • Select condition type and double-click "Accesses" folder - see Figure 7.27

  • Review search criteria for each access (e.g., customer group, account key)

• Verify general ledger account assignments:

  • Transaction SPRO • Sales and Distribution • Basic Function • Account Assignment/Costing • Revenue Account Determination • Assign GL Accounts

  • Select the relevant table (e.g., table 002 for customer group/account key)

  • Verify that general ledger accounts are appropriate for the transaction type - see Figure 7.28

Common Findings:

• Account determination not configured for all revenue-related condition types

• General ledger account assignments inconsistent with accounting policies

• Complex pricing account determination not fully documented

• Insufficient review of account determination changes

---

Section 8: Configurable Controls - Customer Credit Risk

Audit Objective: Assess controls designed to mitigate customer non-payment risk through credit management configuration.

8.1 Credit Check Configuration

Background: SAP S/4HANA uses FSCM credit management for credit checking, replacing classic credit management. Credit checks can be configured for sales document types and delivery document types, with options for simple checking or automatic credit control.

Audit Procedures:

• Verify that credit checking is enabled for relevant document types:

  • Transaction SPRO • Financial Supply Chain Management • Credit Management • Integration with Accounts Receivable Accounting and Sales and Distribution • Integration with Sales and Distribution

  • Select "Assign Sales Documents and Delivery Documents"

  • Review "Set Credit Limit Checks for Sales Document Types" - see Figure 7.29

  • Review "Set Credit Limit Checks for Delivery Types"

• For each document type, review the credit check value:

  • Blank = no credit check

  • A = simple credit check (warning message if insufficient credit)

  • B = simple credit check (error message if insufficient credit)

  • C = credit management (automatic credit control) - see Figure 7.30

• Review automatic credit control settings:

  • Transaction OVA8 (for SAP ERP compatibility, but note SAP S/4HANA uses FSCM)

  • In SAP S/4HANA, navigate to: Financial Supply Chain Management • Credit Management • Credit Risk Monitoring • Credit Limit Check • Define Checking Rules

  • Review checking rules by credit control area, risk class, and credit group - see Figure 7.31

  • Verify that reactions (error, warning, block) are appropriate for each risk class

• Review SAP Notes related to credit management changes:

  • SAP Note 2207394 - Differences in dynamic credit control between SAP ERP and S/4HANA

  • SAP Note 2761313 - Configuration details for FSCM credit management

  • SAP Note 2561725 - Simplified credit management in S/4HANA

Important Consideration: In SAP S/4HANA, only FSCM credit management is available; classic dynamic credit control is no longer supported.

Common Findings:

• Credit checking not enabled for all relevant sales and delivery document types

• Post-implementation document types added without credit checking

• Credit check reactions not aligned with risk class

• No periodic review of credit check configuration

---

Section 9: Configurable Controls - Returns and Credits

Audit Objective: Assess controls designed to prevent inappropriate returns and credits, including mandatory reference documents and blocking indicators.

9.1 Mandatory Reference Documents

Background: Requiring reference documents for returns and credits ensures that credits are linked to original sales, reducing the risk of unauthorized or erroneous credits.

Audit Procedures:

• Review sales document types for mandatory reference settings:

  • Transaction SPRO • Sales and Distribution • Sales • Sales Documents • Sales Document Header • Define Sales Document Types

  • Double-click the relevant sales document type (e.g., returns, credit memo requests)

  • Review the "Reference mandatory" field - see Figure 7.32

  • Values include: (blank) = no reference required, 1 = quotation, 2 = sales order, 3 = scheduling agreement, 4 = contract, A = inquiry, B = billing document, etc.

• For credit memo document types, verify that reference to a billing document is required (value M or appropriate setting)

• Review delivery document types for mandatory reference settings:

  • Transaction SPRO • Logistics Execution • Shipping • Deliveries • Define Delivery Types

  • Double-click the relevant delivery document type (e.g., returns delivery)

  • Review the "Order Required" field in the Order Reference section - see Figure 7.33

  • Verify that appropriate reference (e.g., sales order) is required

Important Consideration: During initial implementation and for a period after go-live, mandatory reference may not be possible if source documents exist in legacy systems. After sufficient time has passed, this setting should be updated to mandatory.

9.2 Blocking Indicators

Background: Document blocks prevent further processing until reviewed and released, providing a segregation of duties between document creation and approval.

Audit Procedures:

• Review sales document type blocking settings:

  • In the same sales document type configuration screen, review:

    • Sales Document Block (header level block)

    • Delivery Block (in Shipping section)

    • Billing Block (in Billing section)

• Review delivery document type blocking reasons:

  • Transaction SPRO • Logistics Execution • Shipping • Deliveries • Assign Blocking Reasons to Delivery Types

  • Verify that appropriate blocking reasons are available for each delivery type - see Figure 7.34

  • Review which blocking reasons are automatically set (e.g., credit blocks) versus manually set

• Review billing document blocking reasons:

  • Transaction SPRO • Sales and Distribution • Billing • Billing Documents • Define Blocking Reason for Billing

  • Verify that appropriate blocking reasons are configured

• Test that users creating documents with blocks cannot release them without appropriate authorization

• Review monitoring procedures for blocked documents

Common Findings:

• Reference documents not mandatory for returns and credits

• Post-implementation document types added without mandatory reference

• Reliance on manual policies instead of system-enforced controls

• Blocked documents not monitored or resolved timely

• No segregation between document creators and block releasers

---

Section 10: Additional Procedures and Considerations

10.1 Order Entry Completeness and Timeliness

Audit Procedures:

• Review procedures for logging and tracking manual orders (fax, mail, email)

• Select a sample of manual orders and verify they were entered timely

• Compare order received date to system entry date

• Review procedures to prevent duplicate entry of orders received through multiple channels

• Assess whether order confirmations are sent to customers to verify accuracy

10.2 Duplicate Master Data Detection

Audit Procedures:

• Review procedures for detecting duplicate material masters:

  • Same name or description

  • Similar name with same supply area and plant

  • Same dimensions and weight

  • Same bill of material details

• Review procedures for detecting duplicate customer masters:

  • Similar names

  • Same phone number, email, or communication details

  • Same numeric portion of address (postal code + street number)

• For any duplicates identified, investigate whether any undesired conditions have resulted

• Review periodic reports or automated tools used for duplicate detection

10.3 Pricing Condition Verification

Audit Procedures:

• Review procedures for validating pricing conditions:

  • Quality assurance over pricing changes

  • Periodic verification of key condition records

  • Review of customer pricing complaints for trends

• Select a sample of sales orders and verify pricing against published price lists or contracts

• Document any discrepancies and review resolution

• If self-auditing procedures exist, verify that evidence is maintained for external audit reliance

10.4 One-Time Customer Monitoring

Audit Procedures:

• Using Transaction RFDKVZ00_AUDIT, identify one-time customers

• Review activity for one-time customers:

  • Transaction volumes and amounts

  • Frequency of use

  • Compliance with policies (low dollar, low volume)

• Investigate any unusual patterns

10.5 Customer Payment Monitoring

Audit Procedures:

• Review bank reconciliation procedures for customer payment accounts

• Verify that reconciling items are resolved timely

• Review accounts receivable aging reports (Transaction S_ALR_87012168)

• Investigate amounts outstanding beyond policy terms

• Review procedures for following up on past due accounts

---

Section 11: Audit-Relevant Reports

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

11.1 Reports Identifying Changed Data

Report	Transaction	Use
Changed Documents for Conditions	VK13 (More • Environment • Changes • Change Report)	Identify changes to pricing conditions
Display Changes to Customers	XD04 (More • Environment • Multiple Display)	Identify changes to customer master data - see Figure 7.35
Credit Management Changes	RMPS_AUDIT	Identify changes to credit management data

Audit Procedures:

• Run change reports for the audit period with reasonable date filters

• Select a sample of changes for detailed review

• Verify changes were properly authorized and documented

• Pay special attention to:

  • Mass changes

  • Changes made by new or terminated employees

  • Changes to sensitive fields (credit limits, payment terms, alternate payees)

11.2 Reports Identifying Incomplete Information

Report	Transaction	Use
Customers Missing Data	F.2D	Identify customers not created in financial accounting or sales and distribution
Incomplete SD Documents	V.00	Identify documents with incomplete data - see Figure 7.36
Billing Due List	VF04	Identify orders not yet invoiced
Backorders	V.15	Identify sales document delivery status
Delivery Monitor	VL06	Monitor delivery processing

Audit Procedures:

• Run incomplete documents reports with aging analysis

• Investigate root causes for aged incomplete documents

• Review period-end billing due list for items affecting revenue recognition

• Review backorders and delivery exceptions for operational impact

11.3 Customer Receivables Reports

Report	Transaction	Use
Customer Open Items	S_ALR_87012168	Analyze accounts receivable aging
Credit Exposure List	See Figure 7.37	Identify customers near or over credit limits

Audit Procedures:

• Run customer open items analysis as of period-end

• Investigate significant past due amounts

• Run credit exposure list to identify customers exceeding credit limits

• For customers over limit, review whether additional orders were processed and how

11.4 Other Useful Reports

Area	Transaction	Use
Pricing	VK13	Display specific condition records
Pricing	V/LD	Display pricing reports (use dropdown)
Sales	VA03	Display sales documents
Deliveries	VL03N	Display outbound deliveries
Billing	VF03	Display billing documents

---

Section 12: Summary of Key Transaction Codes

Transaction	Purpose
BP	Business partner (customer) master
XD04	Customer master change analysis
VK13/VK33	Condition record display
V/06	Condition type configuration
V/07	Access sequence configuration
V/08	Pricing procedure determination
VA03	Sales document display
VL03N	Delivery document display
VF03	Billing document display
VTAA	Copy control: sales doc to sales doc
VTLA	Copy control: sales doc to delivery
VTFA	Copy control: sales doc to billing
VTFL	Copy control: delivery to billing
VTFF	Copy control: billing to billing
V.00	Incomplete SD documents
VF04	Billing due list
OVA8	Automatic credit control (legacy)
F.2D	Customers missing data
S_ALR_87012168	Customer open items
RMPS_AUDIT	Credit management changes
UKM_MY_DCDS / VKM1	Release credit blocks
XD99	Mass customer maintenance
UKM_MASS_UPD3	Mass credit limit changes
UKM_MASS_UPD2	Mass credit score changes
FB75	Customer credit memo entry

---

Section 13: Common Audit Findings Summary

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

1. Missing Data Entry Controls

   • Incompleteness procedures left at default values

   • Business partner field attributes marked "Not spec." (no implementation decision)

   • No periodic review of incomplete documents

   • Aged incomplete documents not investigated

2. Pricing and Quantity Errors

   • Manual overrides allowed on condition types without monitoring

   • Access sequences not aligned with business pricing strategy

   • Copy control rules not copying appropriate quantities or prices

   • Document flow disabled, affecting audit trail

3. Credit Management

   • Credit checking not enabled for all relevant document types

   • Post-implementation document types added without credit checks

   • No periodic review of credit limit configuration

   • Credit exposure not monitored

4. Returns and Credits

   • Reference documents not mandatory for returns and credits

   • Reliance on manual policies instead of system-enforced controls

   • Blocked documents not monitored or resolved

   • No segregation between document creators and block releasers

5. Security and Segregation of Duties

   • Excessive users with access to powerful transactions

   • No monitoring of powerful transaction usage

   • Segregation conflicts between order entry and pricing

   • Customer master maintenance not appropriately segregated

6. Master Data Quality

   • Deletion flags set without corresponding posting blocks

   • Alternate payees not periodically reviewed

   • Duplicate customer records not identified

   • Authorization groups not used to segregate data access

7. Period-End Processing

   • Billing due list not monitored before period close

   • Revenue recognition impacted by blocked billing documents

   • Customer open items not reviewed for collectability

---

Section 14: References and Additional Resources

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

• SAP Note 2270544 - Credit management transactions retired

• SAP Note 2267308 - Pricing table changes

• SAP Note 2267377 - Rebate processing and settlement management

• SAP Note 2267342 - Revenue recognition changes

• SAP Note 2265093 - Customer master and business partner approach

• SAP Note 2207394 - Dynamic credit control differences

• SAP Note 2761313 - FSCM credit management configuration

• SAP Note 2561725 - Simplified credit management in S/4HANA

• COBIT 2019 Framework (ISACA)

• COSO Internal Control Framework

---

This audit progr

Making Your Order-to-Cash Audit Count

Organizations that audit the order-to-cash cycle by confirming that credit management exists and that pricing conditions are populated produce audits that verify the obvious while missing the gaps that create real exposure. A new document type without credit checking. A condition type allowing manual override with no monitoring. Copy control rules that do not copy pricing from the source document. Reference documents not required for credit memos. These are the findings that lead to revenue leakage, fraud, and misstated receivables, and they require testing that goes beyond surface-level configuration review.

Organizations that verify every document type against a control checklist, trace pricing from condition record through access sequence through pricing procedure to GL account, test copy control for quantity and price accuracy, and monitor transactional patterns for anomalies produce audits that genuinely reduce order-to-cash risk. Their findings prevent losses before they accumulate. Their reports give management actionable intelligence about where the process is breaking down.

The integrity of your revenue depends on the integrity of the controls governing every step from order entry to cash collection, and the weakest control in that chain is almost always the one that was added after go-live without anyone checking whether it had the same protections as the original.

What was the last sales or billing document type added to your SAP S/4HANA system, and does it have the same credit checking, reference requirements, and blocking controls as your original document types?

---

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 order-to-cash audit

Secondary keywords: SAP sales and distribution audit, SAP pricing controls audit, SAP credit management audit, SAP customer master data audit, SAP order-to-cash controls, SAP incompleteness procedures audit, SAP copy control audit, SAP billing controls audit, SAP FSCM credit management audit, SAP revenue recognition audit.