How to Audit the SAP S/4HANA Purchase-to-Pay Cycle

 

Practical Audit Controls for the SAP S/4HANA Purchase-to-Pay Cycle

Few audit areas get management’s attention faster than purchase-to-pay.

The reason is simple. Cash is leaving the company. When controls are weak, the damage is usually visible in money, not theory. Duplicate payments. Overpayments. Invalid vendors. Missed discounts. Manual payments. Invoice blocks cleared too easily. Purchase orders changed after approval. Those are not abstract control concerns. They are operating losses.

That is why a strong SAP S/4HANA purchase-to-pay audit can be one of the most valuable reviews in the annual plan.

I have seen organizations recover meaningful cash just by tightening duplicate invoice checks, vendor master controls, and release strategy gaps. I have also seen teams focus too narrowly on invoice processing and miss the actual cause of the problem, which often sits earlier in the flow. In vendor setup. In purchasing info records. In source lists. In movement types. In tolerance settings. In who can create, approve, receive, and pay.

This article gives you a practical framework for auditing the SAP S/4HANA purchase-to-pay cycle. It covers the S/4HANA changes that matter, enterprise structure, master data, security, common configurable controls, and high-value reports. As requested, it includes transaction codes, relevant tables, authorization objects, and full technical names where they help the work become actionable.

Understanding the core framework for a SAP S/4HANA purchase-to-pay audit

Purchase-to-pay is where cost discipline either becomes real or falls apart.

The process starts long before payment. It begins when the business chooses a vendor, a material, a source, a price, and a buying path. It continues through requisition, approval, purchase order, goods receipt or service confirmation, invoice verification, and payment execution. Every weak point along that path can create cash leakage, reporting distortion, or fraud opportunity.

Component 1: Purchase-to-pay is a cash outflow process with both operational and fraud risk

That combination matters.

Operational risk appears in areas like:

• Late procurement
• Wrong vendor or material
• Missed discount terms
• Poor invoice matching
• Inaccurate goods receipt
• Duplicate master data

Fraud risk appears in areas like:

• Fictitious vendors
• Redirected vendor payments
• Manual payments
• Unauthorized PO changes
• Collusive source list changes
• Duplicate invoice or duplicate payment schemes

Original implementation tip: In P2P audits, map every key risk to the point in the process where the bad outcome first becomes possible. Too many reviews test the payment stage only, even though the root cause started in master data or purchasing setup.

Component 2: SAP S/4HANA improved some duplicate detection and master data logic, but did not remove the need for discipline

S/4HANA brought:

• Mandatory Business Partner use for vendor master data
• Fuzzy duplicate search capabilities on SAP HANA
• New industry-specific logistics features
• Continued flexibility in MM and FI integration

That helps. It does not replace governance.

Original implementation tip: Fuzzy search is useful. It is not a substitute for naming standards, centralized vendor governance, and periodic duplicate review.

Component 3: The strongest P2P controls usually combine preventive settings with monitoring

A duplicate invoice warning alone is not enough. A release strategy alone is not enough. A one-time vendor policy alone is not enough.

The best environments combine:

• Restrictive setup
• Approval logic
• Monitoring of changes
• Population-level analytics
• Timely follow-up

Original implementation tip: For each major cash-out risk, ask whether the organization is trying to solve it only with policy. If the answer is yes, there is probably a stronger SAP control technique available.

What Changed in SAP S/4HANA for Purchase-to-Pay

SAP S/4HANA introduces fuzzy search capabilities for detecting duplicate business partners through the SAP HANA database. SAP ERP relied on third-party applications to detect anything beyond exact-match duplicates. Configure fuzzy search through SAP Reference IMG, Service, Master Data, Business Partner, Activate and Configure Duplicate Check.

New functionality folders include returnable packaging logistics (enhanced tracking of returnable packages across locations and business partners), non-ferrous metal processing (daily price fluctuation management for metals traded on exchanges), and ATA SPEC 2000 initial provisioning (spare parts purchasing for aerospace and defense).

The Product Catalog folder has been removed and replaced by SAP Customer Experience. SAP Note 2267292 discusses the change and alternative functionality.

Vendor master data is now part of business partner functions, consistent with the customer master data migration discussed in the order-to-cash chapter. All vendor-related processing flows through transaction BP.

Original implementation tip: After every SAP S/4HANA upgrade or migration, verify that your duplicate vendor detection is actually working. On one engagement, the organization migrated from SAP ERP to SAP S/4HANA and lost their third-party duplicate detection integration in the process. The SAP S/4HANA fuzzy search capability was never configured to replace it. For 11 months, vendors could be created without any duplicate checking beyond the basic exact-match that catches identical addresses including punctuation and spacing. During that period, 47 duplicate vendor records were created. Fourteen had active purchase orders. Three had been paid for the same invoices through different vendor numbers.

Purchase-to-Pay Risks That Drive Your Audit Scope

Because the purchase-to-pay process results in cash leaving your organization, the cycle is a primary target for fraud and abuse.

Duplicate payments. SAP S/4HANA warns users about potential duplicates and the three-way match process prevents payments from exceeding what was ordered and received, but not all payments go through three-way match. Invoices entered directly in financial accounting bypass it entirely. The built-in duplicate detection is rudimentary. Organizations running multiple SAP production systems or recently live have potential for undetected cross-system duplicates.

Overpayments. Complex rebate agreements, pricing update mistakes, and inconsistent contracts across geographies all create overpayment risk. An entire service industry exists for payment recovery, confirming that overpayments are anything but abnormal. When you overpay a vendor, a surprising number remain silent. Some dispute the claim when you try to recover.

Discounts not taken. Complex discount terms, untimely data entry, and blocked documents all cause missed early payment discounts. The per-invoice impact is small. Multiplied across all purchases, the aggregate impact is real.

Inability to reconcile invoices to purchase orders or receipts. Ineffective purchasing or receiving procedures combined with partial receipts make matching difficult. Discount opportunities are lost, payables balances become questionable, and supplier relationships suffer.

Payment for damaged shipments. When quality is not verified upon receipt, payment processes before the damage is discovered. Often recoverable, but always preventable.

Liability not recognized when incurred. Blocked receiving or payment documents prevent the creation of appropriate accounting entries, causing liabilities to post to the wrong period or not at all. This affects financial reporting and management decision-making.

Purchase order changes not subject to scrutiny. The release strategy may require approval for the initial purchase order, but changes after approval may not trigger re-release if the system is not configured correctly. Someone can create a $50,000 purchase order within their authorization limit and incrementally change it to $1 million without additional approval.

Inaccurate vendor activity reporting. Duplicate vendors skew reporting and decision-making around pricing, vendor utilization, and corporate expenditures.

Fraudulent transactions. The ACFE estimates 5% revenue loss to fraud. Contract manipulation, vendor kickbacks, fictitious vendors, and diversion of payments all target the purchase-to-pay cycle.

Understanding the Enterprise Structure

The purchase-to-pay enterprise structure is accessed through SAP Reference IMG, Enterprise Structure, under the Logistics General and Materials Management folders.

Primary Organizational Units

Plant (table T001W) is a physical location within a country with its own material master data, representing where materials are produced or goods are received and shipped. Plants can represent logical segmentation within a single facility. Multiple plants can map to one sales organization. Represented by a four-character alphanumeric code. Audit risk focuses on accurate entry of the country, tax jurisdiction, and factory calendar.

Storage location is a physical place within a plant where stock is held and physical inventories are conducted. Material master data can be storage-location-specific. Represented by a four-character alphanumeric code. Audit risk focuses on address accuracy and a setting controlling goods movement restrictions: no restrictions, inventory management only by incoming transfer postings, or inventory management only by goods issue to production order.

Purchasing organization is the entity that buys or obtains goods and services, obtains quotations, and negotiates pricing and terms. Can be enterprise-wide, company-code-specific, or plant-specific, each with its own pricing and vendor master data. Reference purchasing organizations allow one purchasing organization to use pricing negotiated by another. Purchasing organizations can be subdivided into purchasing groups. Represented by a four-character alphanumeric code.

Assignment Configuration

Plant to company code establishes the link to financial accounting. A plant maps to exactly one company code.

Purchasing organization to company code establishes financial accounting linkage. A purchasing organization maps to exactly one company code.

These assignments indirectly enforce controls by defining approved combinations. Undefined combinations produce error messages when users attempt to create purchasing documents.

Key Concepts

Goods movement represents a state change for a material, either physical (moving between locations) or logical (changing classification from inspection to production-ready).

Movement type is a configurable three-character code classifying a type of goods movement. SAP-delivered types use three numbers. Custom types must start with 9, Y, or Z.

One-time vendor is a supplier business partner associated with an account group marked for one-time processing. Vendor data is entered manually with each transaction. SAP intended this for rarely-used vendors like RFQ recipients. From an audit perspective, one-time vendors should not be used for purchasing or payments. Their use makes activity reporting difficult, the audit trail is challenging, and they facilitate fraud more easily than standard vendors. SAP S/4HANA delivers two one-time account groups (CPD with internal numbering and CPDL with external numbering), but additional groups can be configured with the one-time flag.

To identify one-time account groups, check the One-Time Account field in account group configuration through SAP Reference IMG, Financial Accounting, Accounts Receivable and Accounts Payable, Vendor Accounts, Master Data, Preparations for Creating Vendor Master Data, Define Account Groups with Screen Layout (Vendors).

Logistics invoice is an invoice related to purchasing and receiving, subject to two-way, three-way, or four-way matching. Entered in materials management, not financial accounting. Once cleared through matching, it is sent to financial accounting for payment.

Master Data: Business Partners, Materials, and Source Lists

Vendor Business Partner Data

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

Account Group (on the Vendor: General Data tab) determines the number range and field status configuration. The business partner record itself also has an account group visible through Extras, Create/Change. If the vendor account group is one configured as a one-time account group, the vendor becomes a one-time vendor.

Authorization Group (in the General Data section of the Vendor: General Data tab) works with authorization object F_LFA1_GRP to restrict which employees can interact with specific vendors. If blank, any employee with vendor business partner security can access the data. The Control tab shows the business partner-level authorization group working with B_BUPA_GRP.

Alternative Payee (on the Vendor: Payment Transactions tab) redirects payments to another business partner. Verify all alternative payees during your audit with independent vendor confirmation. In SAP S/4HANA, the previously high-risk Alternative Payee in Doc flag is no longer user-editable and only activates when a Permitted Payee list has been created, limiting redirections to actual business partners on the list rather than free-form text.

Eval. Receipt Settlement flag (on the Purchasing Data tab) tells SAP to automatically generate an invoice upon goods receipt based on purchase order pricing. ERS removes the three-way match as a control point. When auditing ERS vendors, verify that compensating controls exist over purchase order creation accuracy and goods receipt verification.

Deletion Flag and Archiving Indicator. Company code-specific and purchasing organization-specific vendor data can have a deletion flag. The business partner general data can have an archiving indicator. Both trigger archiving on the next run but do not delete data. SAP issues a warning message when posting to flagged vendors, but users can bypass the warning by pressing Enter. Users can even choose to suppress the warning permanently for their session. A standard audit test identifies vendors with deletion flags but without corresponding posting blocks.

Additional audit-relevant fields include payment terms, Incoterms, tax numbers, GR-Based Invoice Verification flag (defaulting purchase orders to expect a goods receipt for three-way match), Srv-Based Invoice Verification flag (defaulting to expect a service entry sheet), and blocking indicators.

Material Master

View through transaction MM03 with more than 20 data views. Key audit fields on the Purchasing data view include the following.

Autom. PO (automatic purchase order). If checked and the vendor also has the flag set, purchase requisitions convert to purchase orders automatically without user review. Other controls must compensate for the absence of manual verification.

Unltd Overdelivery. If checked, overdeliveries of any magnitude are accepted at goods receipt. Expected only for low-value, non-perishable, high-volume goods.

Underdel. Tolerance and Overdeliv. Tolerance define the percentage by which goods receipts can differ from purchase order quantities. Receipts exceeding tolerance are rejected.

Post to Insp. Stock subjects the material to quality inspection at goods receipt.

Critical Part ensures the material is included in complete physical inventory counts when inventory sampling is used.

Source List prevents purchase order creation for the material unless a source list record exists.

On the Accounting 1 view, the Price Control field determines material valuation. S indicates standard pricing (with values in the Standard Price field). V indicates moving average or periodic unit pricing calculated automatically.

Purchasing Info Record

View through transaction ME13. Establishes the price of materials for a given supplier. Key fields include tolerance overdelivery and underdelivery percentages, the unlimited overdelivery flag, the GR-Based Invoice Verification flag, and the No ERS flag. The net price and effective price are calculated from conditions on the Conditions tab, following the same condition technique described in the order-to-cash chapter.

Source List

View through transaction ME06. Defines approved suppliers for purchasing a material into a plant. Records are effective-dated. Critical fields include Fix (preferred supplier, automatically defaulted in purchase orders), Blk (supplier blocked for the material), and MRP selection (1 for automatic assignment to MRP-generated requisitions, 2 for scheduling agreements, blank for MRP to ignore).

These fields can be manipulated to redirect purchasing to unauthorized suppliers through collusion. Regular independent review of the Changes to Source List report (transaction ME04) is essential.

Original implementation tip: Dual control over sensitive vendor fields is the single most impactful control I recommend during every purchase-to-pay audit. Through SAP Reference IMG, Financial Accounting, Accounts Receivable and Accounts Payable, Vendor Accounts, Master Data, Preparations for Creating Vendor Master Data, Define Sensitive Fields for Dual Control (Vendors), you can tag high-risk fields so that any change requires confirmation by a different user ID before it takes effect. SAP checks that the confirming user (through transaction FK08 or FK09) is different from the user who made the change. I recommend configuring dual control for bank account numbers, bank routing codes, alternative payees, phone numbers (because phone verification of a bank change fails if the fraudster also changed the phone number), and addresses (for the same reason with mail-based confirmation). Awareness of this control has increased recently, but I still find it unconfigured in roughly half the organizations I audit. The six organizations I know with losses exceeding $10 million each from bank account fraud all lacked this configuration.

Security Considerations

Restricting Transactions to Purchasing Organizations

Restrict purchasing activities by purchasing entity (field EKORG), purchasing group (field EKGRP), and plant (field WERKS) within authorization objects M_BEST_WRK (Purchase Order: Plant), M_BANF_WRK (Purchase Requisition: Plant), M_BEST_BSA (Purchase Order: Document Type), and M_BANF_BSA (Purchase Requisition: Document Type). Further restrict by document type through field BSART and by release codes through authorization objects M_BANF_FRG (Purchase Requisition: Release) and M_EINK_FRG (Purchasing: Release Authorization).

If users hold wildcard values for plant in M_BEST_WRK, question why purchasing is not restricted by plant.

Limiting Access to Powerful Transactions

Restrict the following to minimal personnel: Transaction MEMASSIN (mass maintenance on purchasing info records), transaction MEMASSPO (mass maintenance on purchase orders), transaction MSL2 (delete logs for mass changes), transactions FK08 and FK09 (confirm vendor changes for dual control), program RM06ID47 (delete archived purchasing records), transaction XK99 (mass vendor maintenance), transaction MK05 (unblock suppliers), transactions MR02 and MRBR (process blocked invoices), and movement types 561 through 566 (designed for initial stock uploads during implementation).

Monitor usage of these transactions independently of the group authorized to perform them.

Authorization Objects for Master Data

Business partner authorization objects include B_BUPA_ADR (addresses), B_BUPA_ATT (authorization types by field value), B_BUPA_BNK (bank data), B_BUPA_FDG (field groups), B_BUPA_GRP (authorization groups), and B_BUPA_RLT (roles).

Vendor-specific authorization objects include F_LFA1_GEN (central data), F_LFA1_BEK (account authorization by vendor range, optional), F_LFA1_APP (application authorization restricting to MM or FI data), F_LFA1_BUK (company code authorization), F_LFA1_GRP (account group authorization), F_LFA1_AEN (change authorization for specific fields, optional), and M_LFM1_EKO (purchasing organization in supplier master).

Material master authorization objects include M_MATE_BUK (company code), M_MATE_WRK (plant), M_MATE_MAR (material type), and M_MATE_PER (posting to prior or closed periods).

Goods receipt authorization objects include M_MSEG_BWA (movement type), M_MSEG_BWE (movement type for PO-referenced receipts), M_MSEG_WWA (plant for goods movements), and M_MSEG_WWE (plant for PO-referenced receipts). Note that SoD conflicts can exist within a single authorization object: movement type 101 (goods receipt) conflicts with movement type 102 (goods return) within M_MSEG_BWA.

Testing Common Controls: Data Input Errors

Field Selection Keys and Screen Layouts

Materials management uses field selection keys associated with screen layouts associated with document types. View configuration through transaction SPRO for each document category: purchasing info records (Purchasing Info Record, Define Screen Layout), purchase requisitions (Purchase Requisition, Define Screen Layout at Document Level), purchase orders (Purchase Order, Define Screen Layout at Document Level), contracts (Contract, Define Screen Layout at Document Level), and scheduling agreements (Purchase Scheduling Agreement, Define Screen Layout at Document Level).

Each field selection key contains multiple field selection groups, each with multiple fields set to required, optional, suppressed, or display-only. Complete audit requires identifying all screen variants, determining which fields should be required for each, and reviewing settings within each field selection key separately.

Dual Control Over Sensitive Fields

View configured dual control fields through transaction SPRO, SAP Reference IMG, Financial Accounting, Accounts Receivable and Accounts Payable, Vendor Accounts, Master Data, Preparations for Creating Vendor Master Data, Define Sensitive Fields for Dual Control (Vendors).

Run transaction FK09 with the Accounts Refused option checked to see rejected dual control changes. Red light indicators show rejections. Rejecting a change does not automatically revert the field. Someone must manually restore the original value.

Be aware that emergency access (firefighter) IDs can circumvent dual control. The same individual could make a change with their normal ID and confirm it with their firefighter ID. Consider usage of FK08 or FK09 through emergency access IDs to be suspicious activity requiring investigation.

Item Categories Linked to Purchasing Document Types

View through transaction SPRO, SAP Reference IMG, Materials Management, Purchasing, Purchase Order, Define Document Types for Purchase Orders. Select the document type and double-click the Allowed item categories folder.

Purchase Price Variance Tolerance

The PE tolerance key compares purchase order effective price against material master valuation price. View through transaction SPRO, SAP Reference IMG, Materials Management, Purchasing, Purchase Order, Set Tolerance Limits for Price Variance. Double-click the PE entry for the desired company code.

Configuration includes lower limit (favorable variance) and upper limit (unfavorable variance) sections, each with absolute and percentage options. When both are set, SAP uses the lower of the two. If the Check Limit flag is not set (Do Not Check), that section is ignored entirely.

Absolute amounts are always in company code currency. Using the same absolute value across international company codes is almost certainly a mistake due to currency value differences.

Original implementation tip: The four most common data input observations I find are field selection keys left at defaults, dual control not configured, price variance tolerance not configured, and price variance tolerances using identical upper and lower limits. The upper and lower limit distinction exists because organizations should tolerate favorable variances (vendor discounts, market price decreases) more generously than unfavorable ones. Additionally, organizations that configure only percentage limits without absolute limits expose themselves to large-value swings on expensive items (10% of $10 million is $1 million). Conversely, percentage-only limits miss large proportional swings on cheap items ($5 absolute tolerance on a $0.10 item allows a 5,000% variance). Use both percentage and absolute limits.

Testing Common Controls: Invoice Verification Tolerances

Tolerance Keys for Invoice Matching

Tolerance keys are configured at the company code level and control when invoices are blocked for payment. Key tolerance keys include the following.

AN (Amount for Item Without Order Reference) compares each non-PO-referenced line item against an absolute upper limit. Only effective in company codes where the item amount check has been activated and for item categories configured for goods receipt checking.

AP (Amount for Item with Order Reference) checks PO-referenced line items against an absolute upper limit. Same activation requirements as AN.

BD (Form Small Differences Automatically) compares the total invoice amount against the referenced purchase order. If within the absolute upper limit, differences post automatically to a small differences account.

DQ (Exceed Amount Quantity Variance) multiplies order price by the quantity difference between invoiced and received (or invoiced and ordered if not yet received). Compares against absolute limits. Allows smaller quantity variances for expensive items and larger variances for inexpensive items.

DW (Quantity Variance when GR Qty = Zero) applies when goods receipt is specified but not yet posted. Multiplies purchase order price by total quantity invoiced. If not configured, SAP blocks any invoice where no goods receipt exists for a GR-flagged item.

KW (Variance from Condition Value) checks planned delivery costs against actual delivery costs by ratio. This tolerance key addresses a specific fraud vector where vendors manipulate freight, taxes, and surcharges to circumvent three-way match controls. In one publicized case, a vendor charged the United States government nearly $900,000 in shipping for two 19-cent washers.

PP (Price Variance) calculates the difference between invoice price and order price for each item, multiplied by invoiced quantity, compared against absolute and percentage limits.

PS (Price Variance: Estimated Price) same as PP but for items flagged as estimated pricing.

LD (Blanket PO Time Limit Exceeded) blocks invoices received outside the purchase order validity period.

Testing Tolerance Configuration

View through transaction SPRO, SAP Reference IMG, Materials Management, Logistics Invoice Verification, Invoice Block, Set Tolerance Limits. Double-click each tolerance key and company code combination.

For AN and AP tolerance keys, also verify the item amount check activation and item category configuration through SAP Reference IMG, Materials Management, Logistics Invoice Verification, Invoice Block, Set Item Amount Check folder. Select Activate Item Amount Check and Set Item Amount Check separately.

Important: When both the absolute and percentage Do Not Check flags are set for a tolerance key, SAP allows any variance without blocking. This is the opposite of what many organizations assume. Setting Do Not Check does not mean "block everything." It means "check nothing."

Original implementation tip: The most common tolerance observations are incomplete key usage (organizations skip KW, leaving freight fraud undetected), identical upper and lower limits (failing to differentiate between favorable and unfavorable variances), and missing absolute or percentage values (creating blind spots for extreme values). I also find organizations with upper limit values that are less restrictive than lower limit values, which is almost always a configuration mistake since you should be less tolerant of unfavorable variances than favorable ones.

Testing Common Controls: Unauthorized Purchase Orders

Requiring Reference to Preceding Documents

Configure SAP to require purchase orders to reference a purchase requisition, RFQ, contract, or reference purchase order through functional authorizations. View through transaction SPRO, SAP Reference IMG, Materials Management, Purchasing, Authorization Management, Define Function Authorizations for Buyers, then Function Authorizations: Purchase Order.

Create a functional authorization with the W/o Reference checkbox selected. Users who should be allowed to create POs without reference receive parameter EFB with a value matching the functional authorization code. All other users receive parameter EFB with a different value.

Critical trap: Users without any EFB parameter assignment can also create purchase orders without reference. Every user ID creation procedure must include EFB parameter assignment. Users must not have access to transaction SU3 (which allows them to change their own parameters). Grant transaction SU50 (address and defaults only) instead.

To audit, query table USR05 (User Master Parameter) filtering on PARID (parameter ID) equal to EFB. Cross-reference against users authorized to create purchase orders through M_BEST authorization objects. Users with EFB values matching the W/o Reference functional authorization code, plus users without any EFB entry, can create POs without reference.

Preventing PO Quantity from Exceeding PR Quantity

By default, SAP issues a warning message (not an error) when purchase order quantity exceeds purchase requisition quantity. View the message configuration through transaction SPRO, SAP Reference IMG, Materials Management, Purchasing, Environment Data, Define Attributes of System Messages, application area 06, message number 076.

If the Cat column shows blank or W, the message is a warning and can be bypassed. Configure to E for error to prevent quantity overrides.

If multiple entries exist for the same message number, different users receive different message types based on parameter MSV in table USR05. Users with MSV parameter value matching the entry in the message configuration receive that message type. Users without MSV or with value 00 receive the default warning.

One organization's analytics revealed that purchase orders created in excess of requisition quantities resulted in cumulative purchases exceeding requisition values by $80 million in a single year.

Release Strategies

Release strategies route purchase order approvals based on configured characteristics including amount, plant, material type, and purchasing group.

Run the release strategy check report through transaction SPRO, SAP Reference IMG, Materials Management, Purchasing, Purchase Order, Release Procedure for Purchase Orders, Check Release Strategies. Colored icons indicate termination, error, warning, or information status.

Access release configuration through the same IMG path. At a basic level: characteristics define measurable attributes (like total PO value), classes assign characteristic values to define release conditions, release groups and release codes organize the approval structure, and users are assigned release authorization through M_EINK_FRG.

Release Changeability: The Most Dangerous Configuration

The release indicator configuration determines what happens when a purchase order changes after release. View through SAP Reference IMG, Materials Management, Purchasing, Purchase Order, Release Procedure for Purchase Orders, Define Release Procedure for Purchase Order, then Release Indicator.

The Chgable field controls behavior after changes to released purchase orders. Values of 4 or 1 are ideal because changes either trigger re-release or are prevented. Other values allow changes without re-release.

Consider this scenario. A buyer with a $50,000 authorization limit creates a $50,000 purchase order and releases it. If the system allows changes up to 39.99% without re-release, the buyer changes the PO to $69,995. Then to $97,986. Then $137,173. After nine changes, the purchase order exceeds $1 million. No additional approval was ever required.

Original implementation tip: The three most common release strategy observations are gaps in release strategy rules (new plants or material types added after go-live without updating release strategies, causing purchases to bypass release entirely), amount boundary errors (one strategy for up to $1 million and another from $1,000,001 to $5 million, creating a gap at $1,000,000.50), and failure to trigger re-release after changes. The incremental change scenario I described is not theoretical. I have documented it in actual audit findings. Verify that the Chgable indicator for every released status triggers re-release on value changes.

Other Configurable Controls Worth Testing

Preventing Goods Receipt Reversal After Invoice

Movement type 102 (goods receipt reversal) can be configured to prevent reversal when an invoice has already been posted against the receipt. View through transaction OMJJ, Movement Type option, reviewing configuration for movement type 102 and any custom reversal movement types. The RevGR Despite IR indicator controls this behavior.

Preventing Automatic Purchase Order Creation

Certain movement types can trigger automatic PO creation when goods arrive at a plant without a matching purchase order, if a purchasing info record exists and both the material and vendor have the automatic PO flag set. View through transaction SPRO, SAP Reference IMG, Materials Management, Inventory Management and Physical Inventory, Goods Receipt, Create Purchase Order Automatically. Review the Automatic PO flag for movement types 101 and 161 and any custom goods receipt movement types.

Account Assignment Category Controls

Account assignment categories determine how material costs are allocated. View through transaction SPRO, SAP Reference IMG, Materials Management, Purchasing, Account Assignment, Maintain Account Assignment Categories. Key fields include Acct.assg.changeable (allows changes after goods receipt and invoice), AA Chgable at IR (allows changes during invoice processing), Goods receipt indicator and GR Ind. Firm (whether the GR requirement can be removed from the PO), and Invoice receipt indicator and IR Ind. Firm (whether the invoice requirement can be removed).

If GR Ind. Firm is not checked, a user can remove the goods receipt requirement from a purchase order line item, effectively converting a three-way match to a two-way match.

Duplicate Invoice Check Configuration

For logistics invoices, SAP S/4HANA default duplicate detection checks for same vendor, same amount, same currency, same company code, same document date, and same vendor invoice number. This check is extremely precise.

View the message type through transaction OBA5, message area F5, message number 117. The default is W (warning). Configure to E (error) for the Online and BatchI columns. If these show W or blank, the duplicate check can be bypassed.

The precision of the default check means legitimate duplicates are frequently missed. If the first invoice uses US date format (10/09/2022) and the duplicate uses European format (09/10/2022), SAP does not detect the duplicate. If the vendor invoice number includes a hyphen (1234-5) and one entry strips it (12345), no duplicate is detected.

Configure broader duplicate detection through transaction SPRO, SAP Reference IMG, Materials Management, Logistics Invoice Verification, Incoming Invoice, Set Check for Duplicate Invoices. Uncheck fields like reference number, invoice date, or company code to cast a wider net.

The message type cannot differ by company code. If some company codes use precise checking (warranting error messages) and others use broad checking (warranting warnings), you must configure message types per user ID rather than globally. This becomes a maintenance burden with staff turnover.

Original implementation tip: The duplicate invoice check is a control that auditors consistently misunderstand. Many believe that SAP "checks for duplicates" and assume the check is comprehensive. The out-of-the-box check requires all six criteria to match simultaneously before triggering even a warning. A duplicate with any single field difference passes through undetected. If you keep the precise check, change the message to error. If you broaden the check by unchecking fields, keep it as a warning because false positives will increase. Either way, complement the system check with periodic analytics comparing invoice data across multiple matching criteria including bank account, amount ranges, and date proximity.

Additional Procedures Worth Testing

One-Time Vendor Monitoring

Review all invoice line items for one-time vendors through transaction FBL1N. Use dynamic selection criteria (More, Edit, Dynamic Selections) to add the account group field. Filter on your configured one-time vendor account groups. Results show all line items for the specified company code and date range. Verify that usage matches expectations of low dollar amounts and minimal volume.

Evaluated Receipts Settlement Monitoring

ERS removes the three-way match control point. Purchase order pricing errors carry directly through to payment. A miskeyed price change on a PO for an ERS vendor results in automatic overpayment or underpayment with no invoice verification step to catch it. Monitor ERS vendor activity including purchase order price changes exceeding defined thresholds. One organization I worked with discovered a $3.2 million overpayment caused by a decimal point error on a purchase order price change for an ERS vendor. The goods receipt triggered automatic payment at the incorrect price.

Manual Payment Limitation

Manual payments (those not processed through transaction F110 or the equivalent Fiori app) bypass traditional payment controls built into SAP. Financial leaders had no prior visibility that the payment was necessary. Limit manual payments severely or prohibit them entirely. If used, apply authorization limits at least as strict as those for automated payments.

Useful Audit Reports

Change Reports

Transaction XK04 displays vendor changes. Select More, Environment, Multiple Display. Filter by general data, company code data, or purchasing organization data. Focus on vendor name, address, bank account, alternative payee, and payment terms changes.

Transaction ME04 displays changes to source lists. Regular independent review is essential because source list manipulation can redirect purchasing to unauthorized suppliers through collusion.

Transaction MM04 displays changes to material master records.

Incomplete Information and Processing Reports

Transaction MIR6 shows blocked invoices requiring investigation and release. At period end, blocked invoices may represent unrecognized liabilities.

Transaction MB5S shows the GR/IR clearing account balance, identifying goods received but not yet invoiced and invoices received but goods not yet delivered. Large or aged items indicate process breakdowns.

Transaction ME2M shows purchase orders by material. Use with variant selections to identify POs created and released by the same user (testing SoD controls in practice).

Vendor Payables Reports

Transaction FBL1N shows vendor line items for analysis of open items, payments, and aging.

Transaction S_ALR_87012082 provides vendor aging analysis.

Transaction S_ALR_87012086 shows vendor payment history for evaluating payment timing and discount capture rates.

Cross-Cutting Tips for Purchase-to-Pay Audits

Original implementation tip on sundry invoice processing: The three-way match is one of the strongest controls in SAP S/4HANA. But not every payment goes through it. Invoices for utilities, taxes, and services without purchase orders are entered through invoice-only processing (historically called sundry invoices). Controls over sundry invoices are inherently weaker than three-way match. I have found organizations where accounts payable staff routinely entered invoices through the sundry process that should have gone through three-way match, because it was faster or because the purchase order had errors they did not want to fix. Monitor the ratio of invoices posted through transaction MIRO (PO-referenced) versus FB60 (non-PO). A shift toward FB60 is a red flag.

Original implementation tip on vendor bank account monitoring: Even with dual control configured, build a monthly monitoring process for vendor bank account changes. Query CDHDR and CDPOS for changes to bank-related fields in the vendor master. Cross-reference each change against the dual control confirmation log from FK09. Any bank change that was not confirmed through dual control, or that was confirmed by a user with a pattern of confirming their own changes through emergency access IDs, should be investigated immediately. The cost of a monthly review is trivial compared to the cost of a single successful bank account fraud.

Original implementation tip on release strategy testing: Do not limit your release strategy audit to reviewing configuration. Perform outcome-based testing. Extract all purchase orders from table EKKO (Purchasing Document Header) with fields EBELN (PO number), BSART (document type), BUKRS (company code), LIFNR (vendor), AEDAT (last change date), ERNAM (created by), FRGKE (release indicator), and FRGZU (release status). Identify purchase orders where the release indicator shows unreleased or partially released status. Cross-reference against the release strategy rules to determine whether these POs should have required release. Any PO that bypassed release strategy represents either a configuration gap or a process failure.

Original implementation tip on movement type 561-566: Movement types 561 through 566 are designed for initial stock uploads during implementation. They allow inventory to be posted without reference to a purchase order, effectively bypassing all purchasing controls. After go-live, access to these movement types should be removed from all users. I have found organizations where implementation movement types remained assigned to warehouse personnel years after go-live. One organization had 4,200 postings using movement type 561 in the 18 months after go-live, none of which had corresponding purchase orders. The warehouse team used them as a shortcut when goods arrived without matching purchase orders rather than resolving the root cause.

SAP S/4HANA Audit Program Purchase-to-Pay Cycle

Audit Objectives

This audit program provides a structured approach for evaluating the Purchase-to-Pay (P2P) cycle in an SAP S/4HANA environment. The program is designed for auditors, compliance professionals, and procurement specialists who need to assess the reliability, integrity, and effectiveness of purchasing, receiving, invoice processing, and payment processes. The primary objectives are to:

• Evaluate the design and operating effectiveness of controls over purchase requisitions, purchase orders, goods receipts, invoice verification, and vendor payments

• Assess configuration settings that impact the completeness and accuracy of procurement transactions

• Review master data controls and security configurations that protect vendor and material information

• Validate three-way matching processes and tolerance configurations for invoice verification

• Identify control weaknesses and provide recommendations for remediation, particularly focusing on fraud prevention and cash preservation

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

---

Section 1: Understanding the SAP S/4HANA Purchase-to-Pay Environment

1.1 SAP S/4HANA Specific Features Impacting Purchase-to-Pay

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

Background: SAP S/4HANA introduces significant changes to procurement functionality compared to legacy SAP ERP systems. Key changes include the mandatory use of business partner functionality for vendor master data, enhanced duplicate check capabilities using fuzzy search, and the removal of certain legacy functions. The business partner approach streamlines master data by reducing redundant information and optimizing system performance -4.

Audit Procedures:

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

  • Business partner for vendor master data (mandatory in S/4HANA)

  • Fuzzy search for duplicate vendor detection using SAP HANA database capabilities

  • Returnable packaging logistics (if applicable to your industry)

  • Non-ferrous metal processing (if applicable to your industry)

  • ATA SPEC 2000 for airline industry spare parts (if applicable)

• Review SAP Notes related to retired functionality:

  • SAP Note 2267292 - Removal of Product Catalog functionality (replaced by SAP Customer Experience)

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

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

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

Important Consideration: The mandatory use of business partner functionality means that traditional vendor master transactions (XK01, XK02, XK03) are no longer the primary interface. Auditors should ensure they are familiar with Transaction BP for vendor master reviews.

---

Section 2: Risks in the Purchase-to-Pay Cycle

Audit Objective: Identify and understand the key risks affecting procurement processes and related financial reporting.

Background: The purchase-to-pay cycle ultimately results in cash leaving your organization, making it particularly ripe for fraud and abuse. The Association of Certified Fraud Examiners (ACFE) estimates that corporations, on average, lose 5% of revenue because of fraud, with procurement being a common area for fraudulent activities -8-10. Unlike other cycles, findings in P2P can often be measured in tangible (and recoverable) dollars.

Risk Categories and Audit Focus:

Risk Category	Description	Audit Focus
Duplicate payments	Same invoice paid multiple times	Test duplicate invoice check configuration; analyze potential duplicate reports
Overpayments	Payments exceeding actual amounts owed	Review tolerance configurations; analyze payment history
Discounts not taken	Missed early payment discounts	Review payment term configuration; analyze payment timing
Payment for goods not received	Vendor paid without proof of receipt	Test three-way match controls; analyze GR/IR clearing accounts
Payment for damaged goods	No quality verification before payment	Review goods receipt inspection procedures
Liability not recognized	Expenses not recorded in correct period	Review GR/IR reconciliation at period-end
Unauthorized purchase orders	Purchases without proper approval	Test release strategy configuration; analyze purchase orders by approver
Purchase order changes without scrutiny	Changes after approval bypass controls	Test changeability settings in release strategies
Inaccurate vendor reporting	Duplicate vendors skewing spend analysis	Review vendor master duplicate detection procedures
Fraudulent transactions	Kickbacks, fictitious vendors, payment diversion	Review vendor master changes; analyze bank account changes; monitor one-time vendors

Audit Consideration: A curious phenomenon exists in P2P—vendors are often quick to notify you when payments are late but may remain silent when you make overpayments or duplicate payments. Some vendors may even dispute overpayment claims. This makes strong preventive and detective controls absolutely critical.

---

Section 3: Enterprise Structure Review

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

3.1 Procurement Organizational Units

Background: The enterprise structure defines how your organization is represented in SAP S/4HANA for procurement processes. Key elements include plant, storage location, purchasing organization, and assignments to company code.

Audit Procedures:

• Using Transaction SPRO, navigate to SAP Reference IMG • Enterprise Structure • Definition • Logistics - General

• Review the following organizational units for appropriate configuration:

Plant:

• Using Transaction OX10, obtain a listing of all plants

• For each plant, verify:

  • Plant name and description are accurate

  • Country key is correct (impacts tax and legal reporting)

  • Factory calendar is appropriate for the physical location

  • Address information is complete and accurate

Storage Location:

• Using Transaction OX09, review storage locations assigned to each plant

• For each storage location, verify:

  • Address information is accurate

  • Goods movement restrictions setting is appropriate:

    • No restrictions

    • Inventory management only by incoming transfer postings

    • Inventory management only by goods issue to production order

Purchasing Organization:

• Using Transaction OX08, review purchasing organization definitions

• Verify that purchasing organizations are appropriately structured (enterprise-wide, company code-specific, or plant-specific)

• Document which purchasing organizations serve which procurement purposes

Assignments:

• Verify plant to company code assignment (Transaction OX18):

  • Each plant should be assigned to exactly one company code

  • Document any plants with missing or incorrect assignments

• Verify purchasing organization to company code assignment (Transaction OX01):

  • Purchasing organizations can be associated with company codes if financial accounting is configured

  • A purchasing organization can only be associated with a single company code

Common Findings:

• Plants assigned to incorrect company codes affecting financial posting

• Storage location restrictions not configured appropriately

• Purchasing organization structure not aligned with business operations

• Missing assignments causing processing errors

---

Section 4: Key Concepts

Audit Objective: Understand key procurement concepts that impact audit procedures and control evaluation.

4.1 Goods Movement and Movement Types

Background: A goods movement represents a state change relative to a material. Movement types classify the type of goods movement (receipt, issue, transfer, return). Standard movement types are three-digit numbers; custom movement types must start with 9, Y, or Z.

Audit Considerations:

• Movement type 101 (goods receipt for purchase order) and 102 (reversal) are critical for P2P controls

• Movement types 561-566 are typically used for initial stock uploads during implementation and should be restricted after go-live

4.2 One-Time Vendors

Background: One-time vendors are supplier business partner records associated with an account group marked for one-time account processing. When used, vendor data is entered manually during transaction processing.

Audit Considerations:

• One-time vendors bypass standard vendor master controls and make activity reporting difficult

• Different "real" vendors show activity under the same business partner ID

• Audit trail is challenging to follow

• They can be an easier vehicle for fraud than normal vendors

Configuration Review:

• Using Transaction SPRO, navigate to Financial Accounting • Accounts Receivable and Accounts Payable • Supplier Accounts • Master Data • Preparations for Creating Supplier Master Data • Define Account Groups with Screen Layout (Vendors)

• Identify which account groups have the "One-Time Account" flag set (see Figure 8.1)

• Default one-time account groups: CPD (internal numbering) and CPDL (external numbering)

• Document all account groups flagged for one-time usage

4.3 Logistics Invoice

Background: A logistics invoice is related to purchasing and receiving processes and is subject to two-way, three-way, or four-way matching. Logistics invoices are entered in materials management (Transaction MIRO) and, once cleared, are sent to financial accounting for payment.

Audit Considerations:

• Logistics invoices undergo matching against purchase orders and goods receipts

• Three-way match is a key control for preventing incorrect payments -4

• Invoices entered directly in financial accounting (Transaction FB60) bypass materials management matching controls

---

Section 5: Master Data Review

Audit Objective: Assess the controls over master data that impacts procurement processes, including business partners (vendors), material master records, purchasing info records, and source lists.

5.1 Business Partner (Vendor) Master Data

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

Audit Procedures:

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

• For each sample, verify:

General Data (Vendor Role):

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

  • Note: Account groups flagged as one-time create one-time vendors

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

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

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

• Archiving indicator (should have corresponding posting blocks if set)

Company Code-Specific Data (Financial Accounting):

• Reconciliation account (proper general ledger account assignment)

• Payment terms (affect when payment is due)

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

• Alternative Payee in Document flag (now restricted to permitted payee list in S/4HANA)

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

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

• Tax numbers (may be required for tax reporting)

• Dunning data (if applicable)

Purchasing Organization-Specific Data (Procurement):

• Purchasing organization assignment

• Order currency

• Salesperson and telephone

• Terms of payment (may differ from company code terms)

• Incoterms (affect timing of expense recognition)

• GR-Based Invoice Verification flag (defaults purchase order items to expect receipt)

• Srv-Based Invoice Verification flag (defaults purchase order items to expect service entry sheet)

• Eval. Receipt Settlement (ERS) flag - see Figure 8.6

• Purchasing blocks

• Using Transaction XK04, review changes to vendor master data for the audit period (More • Environment • Multiple Display) - see Figure 8.31

• For significant changes (bank accounts, alternate payees, payment terms), trace to supporting documentation and approvals

Key Authorization Objects for Vendor 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_LFA1_GEN	Restrict general data modifications
F_LFA1_BEK	Restrict by vendor account range
F_LFA1_APP	Restrict by application (MM vs. FI)
F_LFA1_BUK	Restrict by company code
F_LFA1_GRP	Restrict by account group
F_LFA1_AEN	Restrict changes to specific fields
M_LFM1_EKO	Restrict by purchasing organization

Common Findings:

• Deletion flags set without corresponding posting blocks

• Alternate payees not periodically reviewed

• ERS flag set without appropriate monitoring procedures

• Authorization groups not used to segregate vendor data access

• One-time vendor account groups not identified or monitored

• Duplicate vendor records not identified or merged

5.2 Material Master Record

Background: The material master defines the characteristics of goods to be purchased, manufactured, and/or sold. It contains extensive data across more than 20 views in SAP S/4HANA.

Audit Procedures:

• Using Transaction MM03, review a sample of material master records

• For each sample, verify the following fields from the Purchasing data view (see Figure 8.9):

Critical Fields - Purchasing View:

• Autom. PO - If checked, SAP S/4HANA automatically creates and saves purchase orders without display when purchase requisitions are converted. Requires compensating controls.

• Unltd Overdelivery - Allows overdeliveries of any magnitude. Should only be set for low-value, non-perishable, high-volume goods.

• Underdel. Tolerance and Overdeliv. Tolerance - Define acceptable variance percentages for goods receipts. Verify values are reasonable.

• Post to Insp. Stock - Subjects material to quality inspection upon receipt.

• Critical Part - For inventory sampling; material will be included in complete count area.

• Source List - If checked, purchase orders cannot be created without a source list entry.

International Trade View (if applicable):

• Cntry/Reg of Origin - Required for global trade compliance

Accounting 1 View (see Figure 8.10):

• Price Control - S (standard price) or V (moving average price)

  • S indicates valuation based on standard pricing (Standard Price field should be populated)

  • V indicates SAP automatically calculates moving average price

• Standard Price - Verify against current market conditions

• Valuation Class - Determines GL account postings

Common Findings:

• Unltd Overdelivery flag set for high-value or perishable goods

• Tolerance percentages not aligned with business practices

• Price control settings inconsistent with accounting policies

• Source List requirement not enforced

5.3 Purchasing Info Record

Background: The purchasing info record establishes the price of materials for a given supplier. It links your material IDs to supplier information and sets procurement defaults -4.

Audit Procedures:

• Using Transaction ME13, review a sample of purchasing info records

• For each sample, verify:

General Data:

• Material-supplier relationship

• Default unit of measure

• Country of origin certificate ID and expiration (compliance risk if incorrect)

• Availability dates (start and end)

Purchasing Organization Data (see Figure 8.11):

• Net Price - Unit price after discounts and surcharges

• Effective Price - Net price considering early payment discounts and delivery costs

• Tol. Overdl. and Tol. Underdl. - Tolerance percentages for goods receipt

• Unlimited - If checked, allows any overdelivery amount

• GR-Bsd IV - If checked, expects goods receipt (enables three-way match)

• No ERS - If unchecked and vendor ERS flag set, enables automatic invoice generation

• Using Transaction ME14, review changes to purchasing info records during audit period - see Figure 8.33

• For significant price changes, trace to supporting documentation (contracts, quotations)

Common Findings:

• Price changes without supporting documentation

• Tolerance settings inconsistent with material master

• GR-Bsd IV flag not set for materials requiring receipt verification

• ERS enabled without appropriate monitoring

5.4 Source List

Background: A source list defines the approved suppliers for purchasing a material into a specific plant. Source list records are effective-dated -4.

Audit Procedures:

• Using Transaction ME03, review source list entries for a sample of materials - see Figure 8.12

• For each source list, verify:

  • Validity dates (beginning and end)

  • Fix checkbox - Only one supplier can have this checked; indicates preferred supplier

  • Blk checkbox - Blocks supplier for purchasing this material

  • MRP selection - Determines how MRP-generated requisitions are assigned:

    • 1 = Supplier automatically assigned to purchase requisitions

    • 2 = Supplier automatically assigned to scheduling agreements

    • blank = Source ignored by MRP

• Using Transaction ME04, review changes to source lists during audit period - see Figure 8.32

• Investigate any changes to Fix flags or blocked status

Common Findings:

• Fix flag changes without documentation (potential collusion risk)

• Source lists not maintained for critical materials

• Expired source lists not updated

• No regular review of source list changes

---

Section 6: Security Considerations for Purchase-to-Pay

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

6.1 Restricting Transactions by Purchasing Organization and Plant

Audit Procedures:

• Using Transaction SUIM, identify users with authorization to create and maintain purchase orders

• Verify that appropriate segregation of duties exists between -6:

  • Purchase requisition creator and purchase order approver

  • Purchase order creator and goods receiver

  • Purchase order creator and invoice verifier

  • Vendor master maintainer and purchase order creator

  • Purchase order creator and payment processor

• Review assignment of authorization objects for procurement -6:

Authorization Object	Field Values	Purpose
M_BEST_WRK	Plant (WERKS)	Restrict purchase order activities by plant
M_BANF_WRK	Plant (WERKS)	Restrict purchase requisition activities by plant
M_BEST_BSA	Document type (BSART)	Restrict purchase order by document type
M_BANF_BSA	Document type (BSART)	Restrict purchase requisition by document type
M_BANF_FRG	Release code	Restrict release of purchase requisitions
M_EINK_FRG	Release code	Restrict release of purchase orders

• Verify that users are not granted wildcard (*) access where segregation should exist

• Ensure that users with release authority have appropriate approval limits

6.2 Limiting Access to Powerful Transactions

Audit Procedures:

• Identify users with access to powerful procurement transactions -2-4:

Transaction	Description	Risk
MEMASSIN	Mass maintenance of purchasing info records	Unauthorized mass price changes
MEMASSPO	Mass maintenance of purchase orders	Unauthorized mass order changes
MSL2	Delete logs for mass changes	Destroy audit trail
FK08/FK09	Confirm vendor changes (dual control)	Approve own changes if not properly segregated
RM06ID47	Delete archived purchasing records	Destroy audit trail
XK99	Mass vendor maintenance	Unauthorized mass vendor changes
MK05	Unblock business suppliers	Bypass procurement blocks
MR02/MRBR	Process blocked invoices	Release invoices without proper review
Movement types 561-566	Initial stock uploads	Should be restricted after go-live

• 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

6.3 Restricting Goods Receipt Transactions

Audit Procedures:

• Review assignment of goods receipt authorization objects -4:

Authorization Object	Field Values	Purpose
M_MSEG_BWA	Movement type	Restrict movement types usable within a plant
M_MSEG_BWE	Movement type	Restrict goods receipts referenced to purchase orders
M_MSEG_WWA	Plant	Restrict plants for goods movements
M_MSEG_WWE	Plant	Restrict goods receipts referenced to purchase orders by plant

• Pay special attention to conflicting movement types within M_MSEG_BWA:

  • Movement type 101 (goods receipt) conflicts with 102 (goods return)

  • Users should not have both unless justified

Common Findings:

• Segregation of duties conflicts between PO creation and goods receipt -6

• Excessive users with access to mass maintenance transactions

• No monitoring of powerful transaction usage

• Movement type conflicts not identified or mitigated

• Emergency access IDs used for dual control confirmation (circumventing control)

---

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

Audit Objective: Assess controls designed to ensure complete and accurate data entry in procurement master data and transactions.

7.1 Field Status Configuration for Vendor Master

Background: Vendor business partner master data uses field attributes (field status groups) to define required, optional, or hidden fields -8.

Audit Procedures:

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

• Select "Configure Field Attributes per BP Role" or "per Business Partner Type"

• For the Supplier business partner role, review field status settings - see Figure 8.13

• Verify that critical fields are set to "Required":

  • Address: City

  • Address: Country

  • Bank account details (if applicable)

  • Payment terms

  • Reconciliation account

• Pay special attention to fields marked "Not spec." - this means no decision was made during implementation

• Document any fields that should be required but are not

7.2 Field Selection Keys for Procurement Documents

Background: Materials management uses field selection keys (similar to field status) to define required fields for purchasing documents -8.

Audit Procedures:

• Review field selection configuration for each procurement document type:

Document Type	IMG Path
Purchasing Info Records	Materials Management • Purchasing • Purchasing Info Record • Define Screen Layout
RFQs and Quotations	Materials Management • Purchasing • RFQ and Quotation • Define Screen Layout at Document Level
Purchase Requisitions	Materials Management • Purchasing • Purchase Requisition • Define Screen Layout at Document Level
Purchase Orders	Materials Management • Purchasing • Purchase Order • Define Screen Layout at Document Level - see Figure 8.14
Contracts	Materials Management • Purchasing • Contract • Define Screen Layout at Document Level
Scheduling Agreements	Materials Management • Purchasing • Purchase Scheduling Agreement • Define Screen Layout at Document Level

• For purchase orders, review field selection key ME21 (standard) - see Figure 8.14

• Verify that critical fields are set to "Reqd. entry":

  • Terms of payment

  • Currency

  • Plant

  • Material group

  • Purchasing group

• Document any fields that should be required but are set to optional

7.3 Dual Control Over Sensitive Fields

Background: Dual control requires approval for changes to high-risk vendor fields before they take effect. Changes are confirmed in Transaction FK08/FK09 by a different user than the one who made the change -8.

Audit Procedures:

• Using Transaction SPRO, navigate to Financial Accounting • Accounts Receivable and Accounts Payable • Supplier Accounts • Master Data • Preparations for Creating Supplier Master Data • Define Sensitive Fields for Dual Control (Vendors)

• Review fields designated for dual control - see Figure 8.18

• Recommended fields for dual control:

  • Bank account number

  • Bank key

  • Alternate payee

  • Payment terms

  • Reconciliation account

  • Phone number (to prevent confirmation fraud)

  • Address (to prevent confirmation fraud)

• Verify that the configuration is active (fields appear in the list)

• Using Transaction FK09 with "Accounts refused" option, review rejected changes - see Figure 8.19

• Investigate any rejected changes and verify appropriate follow-up

Important Consideration: If emergency access (firefighter) IDs are used, the same individual could potentially change and confirm a field using different IDs. Monitor emergency access usage for Transactions FK08 and FK09.

7.4 Item Categories Linked to Purchasing Document Types

Audit Procedures:

• Using Transaction SPRO, navigate to Materials Management • Purchasing • Purchase Order • Define Document Types for Purchase Orders

• Select a purchasing document type and double-click "Allowed item categories" - see Figure 8.16

• Verify that only appropriate item categories are allowed for each document type

• Document any item categories that should not be available

Common Findings:

• Field selection keys left at default values

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

• Dual control not configured for high-risk fields (bank accounts, alternate payees)

• Item categories not restricted by document type

• Reliance on manual policies instead of system-enforced controls

---

Section 8: Configurable Controls - Master and Transactional Data Input Errors

Audit Objective: Assess controls designed to ensure accurate pricing and quantities in procurement documents, including price variance tolerances.

8.1 Purchase Order Price Variance Tolerance

Background: When creating a purchase order, price variances from the material valuation price can trigger warnings or errors -8.

Audit Procedures:

• Using Transaction SPRO, navigate to Materials Management • Purchasing • Purchase Order • Set Tolerance Limits for Price Variance

• Review the PE tolerance key for each relevant company code - see Figure 8.17

• For each tolerance, verify:

Setting	Purpose
Lower Limit (Absolute)	Maximum negative variance in company code currency
Lower Limit (Percentage)	Maximum negative variance as percentage
Upper Limit (Absolute)	Maximum positive variance in company code currency
Upper Limit (Percentage)	Maximum positive variance as percentage

• Check whether limits are set to "Do Not Check" or have reasonable values

• Verify that both absolute and percentage limits are used appropriately:

  • Absolute limits protect against large swings in expensive items

  • Percentage limits protect against proportionally large swings in inexpensive items

• Verify that upper limits (price increases) are more restrictive than lower limits (price decreases)

Important Consideration: Absolute values are in company code currency. Having the same absolute value for each company code across different currencies may be inappropriate.

Common Findings:

• Price variance tolerances not configured

• Same values used for upper and lower limits (should be more restrictive for increases)

• "Do Not Check" selected for both absolute and percentage limits (tolerance ineffective)

• Absolute values not appropriate for company code currency

---

Section 9: Configurable Controls - Payments for Goods Not Received or Inconsistent with Purchase Order

Audit Objective: Assess controls designed to ensure accurate invoice processing and prevent incorrect payments, including tolerance keys and three-way matching.

9.1 Invoice Verification Tolerance Keys

Background: SAP S/4HANA uses tolerance keys to automatically block invoices that exceed defined limits or write off small differences. These controls are critical for preventing duplicate payments and overpayments -4-8.

Audit Procedures:

• Using Transaction SPRO, navigate to Materials Management • Logistics Invoice Verification • Invoice Block • Set Tolerance Limits

• Review each relevant tolerance key for all company codes:

Tolerance Key	Description	Audit Focus
AN	Amount for Item Without Order Reference	Compares each line item to absolute upper limit. Only applies if item amount check is activated.
AP	Amount for Item With Order Reference	Compares line items referenced to POs against absolute upper limit. Only applies if item amount check is activated.
BD	Form Small Differences Automatically	Automatically posts small differences to expense/income. If difference exceeds limit, invoice is blocked.
DQ	Exceed Amount Quantity Variance	Calculates variance based on order price × difference between invoiced and received quantity.
DW	Quantity Variance when GR Qty = Zero	Applies when goods receipt is expected but not yet posted.
KW	Var. from Condition Value	Compares planned delivery costs to actual costs. Critical for detecting freight and add-on charge manipulation.
LD	Blanket PO Time Limit Exceeded	Blocks payment for invoices outside PO validity period.
PP	Price Variance	Compares invoice price to order price × invoiced quantity.
PS	Price Variance: Estimated Price	For items with estimated pricing; compares invoice value to estimated order price.

• For each tolerance key, verify:

  • Upper and lower limits are reasonable and consistent with company policy

  • Both absolute and percentage values are used appropriately

  • Upper limits (unfavorable variances) are more restrictive than lower limits (favorable variances)

Important Consideration: The KW tolerance key is particularly important for detecting fraud schemes where vendors manipulate freight, taxes, and other add-ons. In one publicized case, vendors fraudulently charged the US government almost $900,000 in shipping for two 19-cent washers.

9.2 Item Amount Check Activation

Audit Procedures:

• Verify item amount check activation (required for AN and AP tolerances):

  • Transaction SPRO • Materials Management • Logistics Invoice Verification • Invoice Block • Set Item Amount Check folder

  • Select "Activate Item Amount Check" - see Figure 8.20

  • Document which company codes have the check activated

• Review item category assignments:

  • Select "Set Item Amount Check" - see Figure 8.21

  • Verify that appropriate item categories are configured for each company code

  • Note that item categories without entries will not be subject to AN/AP tolerance checks

9.3 Duplicate Invoice Check

Background: SAP S/4HANA can warn or error when duplicate invoices are entered. The standard check compares vendor, amount, currency, company code, document date, and vendor invoice number -8.

Audit Procedures:

• Check message type configuration for duplicate invoices:

  • Transaction OBA5, message area F5, message number 117 - see Figure 8.29

  • Verify that message type is set to "E" (Error) rather than "W" (Warning) for precise duplicate checks

  • If set to "W", users can bypass the warning

• Review duplicate invoice check configuration:

  • Transaction SPRO • Materials Management • Logistics Invoice Verification • Incoming Invoice • Set Check for Duplicate Invoices - see Figure 8.30

  • Document which fields are included in the duplicate check:

    • Company code

    • Vendor invoice number

    • Invoice date

    • Amount

    • Currency (hard-coded)

    • Vendor (hard-coded)

• Assess whether the check is appropriately configured:

  • Precise checks (all fields) should have error message configured

  • Looser checks (fewer fields) should have warning message and detective monitoring

  • All companies should use consistent approach due to message type limitations

Important Consideration: The standard duplicate check is very precise and may miss duplicates due to:

• Date format differences (US vs. European)

• Special characters in invoice numbers

• Leading zeros or punctuation

Common Findings:

• Not all relevant tolerance keys are in use

• Upper and lower limits not appropriately differentiated

• "Do Not Check" selected for both absolute and percentage (tolerance ineffective)

• Duplicate invoice check configured as warning instead of error

• Item amount check not activated for relevant company codes

• No detective controls for potential duplicates missed by system checks

---

Section 10: Configurable Controls - Unauthorized Purchase Orders

Audit Objective: Assess controls designed to ensure purchase orders are properly authorized, including requisition references, release strategies, and change controls.

10.1 Requiring Purchase Order Reference to Preceding Documents

Background: Purchase orders can be configured to require reference to purchase requisitions, RFQs, or contracts. This is controlled through functional authorizations -2-8.

Audit Procedures:

• Determine if purchase orders must reference preceding documents:

  • Transaction SPRO • Materials Management • Purchasing • Authorization Management • Define Function Authorizations for Buyers

  • Double-click "Function Authorizations: Purchase Order"

  • Check if any entries have "W/o Reference" checkbox selected - see Figure 8.22

Important Control Nuance:

• Users with the functional authorization code (parameter EFB with matching value) can create POs without reference

• Users WITHOUT parameter EFB can also create POs without reference (this is counterintuitive)

• Only users with parameter EFB assigned a value that DOES NOT match the functional authorization are restricted

• To audit this control:

  1. Identify users authorized to create purchase orders (M_BEST* authorization objects)

  2. Query table USR05 for these users (Parameter ID = EFB)

  3. Users who can create POs without reference are:

     • Those with EFB parameter value equal to functional authorization code

     • Those with no EFB parameter entry

  4. Users who cannot create POs without reference are those with EFB parameter value NOT equal to functional authorization code

10.2 Preventing Purchase Order Quantities Exceeding Purchase Requisition Quantities

Audit Procedures:

• Check message configuration for quantity overruns:

  • Transaction SPRO • Materials Management • Purchasing • Environment Data • Define Attributes of System Messages

  • Application area 06, message number 076 - see Figure 8.23

  • Default behavior: Warning (W)

  • If changed to Error (E), users cannot exceed requisition quantity

• Check if message is configured by user:

  • Query table USR05 for parameter ID MSV

  • Value "Z1" typically indicates error message

  • Value "00" or no entry indicates warning message

10.3 Release Strategies

Background: Release strategies route approvals based on characteristics like amount, plant, material type, and purchasing organization. They are essential for enforcing Delegation of Authority (DoA) limits -2-4.

Audit Procedures:

• Run release strategy check report:

  • Transaction SPRO • Materials Management • Purchasing • Purchase Order • Release Procedure for Purchase Orders • Check Release Strategies

  • Review results for errors, warnings, and terminations - see Figure 8.24

  • Investigate any errors (e.g., missing classes, invalid characteristics)

• Review release strategy configuration:

  • Navigate to Define Release Procedure for Purchase Orders

  • Document the characteristics used (e.g., total PO value, plant, material type)

  • Review characteristic values (e.g., "above $1 million")

  • Verify that release conditions cover all possible scenarios (no gaps)

• Check for release strategy gaps:

  • Ensure no logic gaps exist (e.g., strategy for ≤$1M and strategy for >$1M, but nothing for $1M exactly)

  • Verify that new plants or material types added post-implementation are covered

• Review release groups and codes:

  • Document release groups and associated release codes

  • Identify users assigned to each release code (M_EINK_FRG authorization object)

  • Verify that only authorized users have release capability

• Test changeability settings:

  • Navigate to Define Release Procedure • Release Indicator - see Figure 8.25

  • Review "Chgable" values for each release status - see Figure 8.26

Changeability Value	Meaning	Audit Implication
1	Change triggers new release	Good control
2	Cannot be changed	Good control
3	Change allowed, no new release	Risk - can increase value without re-approval
4	Change allowed up to defined percentage	Risk - can incrementally increase value

• Calculate cumulative risk:

  • If changeability allows 40% increases without re-release, a $50,000 PO could become $1.03M after 9 changes

  • This circumvents approval limits

Common Findings:

• Purchase order quantities exceeding purchase requisition quantities (warning message ignored)

• Release strategy gaps (new plants/material types not covered)

• Changeability settings allow value increases without re-release

• No monitoring of changes to released purchase orders

• Emergency purchases bypassing release strategy

---

Section 11: Other Configurable Controls

11.1 Preventing Reversal of Goods Receipt After Invoice Processing

Audit Procedures:

• Review movement type configuration:

  • Transaction OMJJ, select "Movement Type" option

  • Review movement type 102 (reversal of goods receipt)

  • Check "RevGR Despite IR" indicator - see Figure 8.27

  • If checked, goods receipt can be reversed even after invoice posting

• Document any custom movement types used for returns

11.2 Preventing Automatic Purchase Order Creation

Audit Procedures:

• Review automatic PO creation settings:

  • Transaction SPRO • Materials Management • Inventory Management and Physical Inventory • Goods Receipt • Create Purchase Order Automatically

  • Review "Automatic PO" flag for relevant movement types (101, 161, custom)

• This configuration allows automatic PO creation when:

  • Goods received without PO reference

  • Purchasing info record exists

  • Material and vendor have automatic PO flags set

11.3 Account Assignment Category Configuration

Background: Account assignment categories determine how material costs are allocated (e.g., to cost centers, projects).

Audit Procedures:

• Review account assignment categories:

  • Transaction SPRO • Materials Management • Purchasing • Account Assignment • Maintain Account Assignment Categories

  • Double-click relevant categories - see Figure 8.28

• Verify the following fields:

Field	Audit Focus
Acct.assg.changeable	If checked, account assignment can be changed after GR and IR
AA Chgable at IR	If checked, account assignment can be changed during invoice processing
Goods receipt	Defaults purchase order item to require goods receipt
GR Ind. Firm	If checked, goods receipt indicator cannot be changed on PO
Invoice receipt	Defaults purchase order item to require invoice
IR Ind. Firm	If checked, invoice receipt indicator cannot be changed on PO

---

Section 12: Additional Procedures and Considerations

12.1 Eliminate Duplicates from Vendor Master and Material Master

Audit Procedures:

• Review procedures for detecting duplicate vendors -2:

  • Similar names

  • Same bank account number

  • Same tax ID number

  • Same phone number, fax, email

  • Same numeric portion of address

• Review procedures for detecting duplicate materials:

  • Same name or description

  • Similar name with same supply area and plant

  • Same dimensions and weight

  • Same bill of material details

• If using fuzzy search capabilities in SAP HANA, verify configuration

• If using third-party duplicate detection tools, assess integration

12.2 Review One-Time Vendor Usage

Audit Procedures:

• Identify one-time vendor account groups (see Section 4.2)

• Using Transaction FBL1N, analyze one-time vendor activity:

  • More • Edit • Dynamic Selections

  • Add account group field

  • Filter on one-time vendor account groups

• Review one-time vendor transactions for:

  • High dollar amounts

  • High transaction volume

  • Unusual patterns

  • Multiple invoices to same "different" vendor

12.3 Monitor Evaluated Receipt Settlement (ERS) Activity

Background: ERS automatically generates invoices based on goods receipts and purchase orders, eliminating vendor invoices. This bypasses three-way match controls.

Audit Procedures:

• Identify ERS vendors (Eval. Receipt Settlement flag in vendor master - see Figure 8.6)

• Review ERS activity for:

  • Purchase order price changes (could cause incorrect automatic payments)

  • Goods receipt accuracy (errors flow through to payment)

  • Appropriate vendor selection (ERS should be for trusted vendors only)

• Monitor changes to ERS flags in vendor master (Transaction XK04)

12.4 Monitor Vendor Payments and Payment Application

Audit Procedures:

• Review bank reconciliation procedures for payment accounts

• Verify reconciling items are resolved timely

• Review accounts payable aging reports (Transaction FBL1N)

• Investigate past due amounts and disputed items

• Review payment runs (Transaction F110) for unusual patterns

12.5 Limit Manual Payments

Background: Manual payments bypass automatic payment run controls and visibility -6.

Audit Procedures:

• Review procedures for manual payments

• Identify all manual payments during audit period

• Verify they followed authorization limits (should be at least as strict as automatic payments)

• Investigate frequency and rationale for manual payments

---

Section 13: Audit-Relevant Reports

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

13.1 Reports Identifying Changed Data

Report	Transaction	Use
Display Changes to Vendors	XK04 (More • Environment • Multiple Display)	Identify changes to vendor master data - see Figure 8.31
Changes to Source List	ME04	Identify changes to source lists - see Figure 8.32
Changes to Purchasing Info Record	ME14	Identify changes to info records - see Figure 8.33

Audit Procedures:

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

• Select a sample of changes for detailed review:

  • Bank account changes (high-risk for fraud)

  • Alternate payee additions

  • Payment term changes

  • ERS flag changes

  • Source list Fix flag changes

  • Price changes exceeding thresholds

• Verify changes were properly authorized and documented

• Pay special attention to changes made by new or terminated employees

13.2 Reports Identifying Incomplete Information or Processing

Report	Transaction	Use
Vendors Missing Data	S_ALR_87010052	Identify vendors not created in financial accounting or purchasing
GR/IR Clearing	MB5S	Analyze goods receipt/invoice receipt balances - see Figure 8.34
GR/IR Account Analysis	F.19	Accounting view of GR/IR clearing

Audit Procedures:

• Run MB5S to analyze GR/IR balances - see Figure 8.34

  • Identify items with GR but no IR (accrual required)

  • Identify items with IR but no GR (potential payment without receipt)

  • Age the items using document number sequencing

  • Investigate significant or aged discrepancies

• Run F.19 to reconcile GR/IR accounts at period-end

• Verify that procedures exist to clear GR/IR items timely

13.3 Reports Identifying Potential Issues

Report	Transaction	Use
Invoice Numbers Allocated Twice	S_ALR_8701127	Identify potential duplicate invoices - see Figure 8.35
Purchase Order Price History	ME1P	Analyze price changes over time

Audit Procedures:

• Run duplicate invoice report with expanded selection ((Shift)+(F7))

• Investigate potential duplicates:

  • Exact matches (vendor, amount, date, reference) - likely true duplicates

  • Near matches (vendor, amount, similar date) - investigate further

• For recurring false positives, consider excluding specific vendors

13.4 Other Useful Reports

Area	Transaction	Use
Purchasing Info Record	ME1L	Display info records per supplier
Purchasing Info Record	ME1M	Display info records per material
Purchase Order	ME23N	Display purchase order
Goods Receipt	MIGO	Display goods receipt (replaces MB03)
Logistics Invoice	MIR4	Display logistics invoice
Accounting Invoice	FB03	Display accounting invoice
Purchase Requisition List	ME5A	List of purchase requisitions -2
Open PO List	ME2N	List of open purchase orders -2

---

Section 14: Summary of Key Transaction Codes

Transaction	Purpose
BP	Business partner (vendor) master
XK04	Vendor master change analysis
ME13/ME14	Purchasing info record display/change analysis
ME03/ME04	Source list display/change analysis
MM03	Material master display
ME5A	Purchase requisition list -2
ME2N	Open purchase order list -2
ME23N	Purchase order display
MIGO	Goods receipt display
MIRO/MIR4	Logistics invoice entry/display
FB60/FB03	Accounting invoice entry/display
FBL1N	Vendor line item display
F110	Automatic payment run
MB5S	GR/IR balance display
F.19	GR/IR account analysis
ME1L/ME1M	Purchasing info record lists
OBA5	Message type configuration
OMJJ	Movement type configuration
SE16N/SE16H	Table display (USR05 for parameters)
SUIM	User information system
XK99	Mass vendor maintenance
MEMASSIN	Mass info record maintenance
MEMASSPO	Mass purchase order maintenance
FK08/FK09	Dual control confirmation/rejection
MR02/MRBR	Blocked invoice processing

---

Section 15: Common Audit Findings Summary

Based on the source material, the following findings are commonly observed in SAP S/4HANA purchase-to-pay audits -2-8:

1. Missing Data Entry Controls

   • Field selection keys left at default values

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

   • Dual control not configured for high-risk fields (bank accounts, alternate payees)

2. Vendor Master Data Issues

   • Deletion flags set without corresponding posting blocks

   • Alternate payees not periodically reviewed

   • ERS flag set without appropriate monitoring

   • Duplicate vendor records not identified

   • One-time vendor usage not monitored

3. Price and Quantity Controls

   • Price variance tolerances not configured

   • Same values used for upper and lower limits

   • "Do Not Check" selected for both absolute and percentage (tolerance ineffective)

   • Unltd Overdelivery flag set for high-value goods

4. Invoice Verification

   • Not all relevant tolerance keys in use

   • Duplicate invoice check configured as warning instead of error

   • Item amount check not activated for relevant company codes

   • No detective controls for potential duplicates

5. Purchase Order Authorization

   • Purchase order quantities exceeding requisition quantities (warning ignored)

   • Release strategy gaps (new plants/material types not covered)

   • Changeability settings allow value increases without re-release

   • No monitoring of changes to released purchase orders

6. Segregation of Duties -6

   • Conflicts between PO creation and goods receipt

   • Conflicts between PO creation and invoice verification

   • Conflicts between vendor maintenance and PO creation

   • Emergency access IDs used for dual control confirmation

7. Period-End Processing

   • GR/IR items not cleared timely

   • Unmatched receipts not investigated

   • Un-invoiced receipts not accrued

8. Fraud Indicators

   • Bank account changes without dual control

   • Alternative payees added without review

   • One-time vendors with high transaction volume

   • Manual payments without proper authorization

---

Section 16: References and Additional Resources

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

• SAP Note 2267292 - Product Catalog functionality removal

• Chuprunov, M. (2013). Auditing and GRC Automation in SAP. Springer. -8-9-10

• COBIT 2019 Framework (ISACA)

• COSO Internal Control Framework

• Association of Certified Fraud Examiners (ACFE) Fraud Tree

Making Your Purchase-to-Pay Audit Count

Organizations that audit the purchase-to-pay cycle by confirming that release strategies exist and that tolerance keys are populated produce audits that verify configuration surfaces while missing the gaps that create real financial exposure. A release strategy with an amount boundary gap. A tolerance key with both absolute fields set to Do Not Check. A movement type from implementation still assigned to warehouse staff. Dual control not configured for bank account changes. These are the findings with dollar values attached, and they require testing that combines configuration review with transactional data analysis.

Organizations that test release strategies with outcome-based analytics, verify that every tolerance key operates as intended with correct upper and lower limits, monitor one-time vendor usage and ERS activity, and configure dual control over sensitive fields produce audits that prevent losses before they occur. Their findings carry quantifiable impact. Their recommendations are measured in recovered or prevented dollars. Their reports get attention from the board because the numbers are real.

The purchase-to-pay cycle is where audit value is most directly measurable. Every control gap has a price. Every finding can be quantified. The question is whether you find the gaps before the money leaves, or after.

What is the current dollar volume flowing through your one-time vendor accounts and sundry invoice process, and when was the last time someone verified that all vendor bank account changes went through dual control confirmation?

---

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 purchase-to-pay audit

Secondary keywords: SAP materials management audit, SAP vendor master audit, SAP duplicate payment controls, SAP invoice verification audit, SAP release strategy audit, SAP purchase order controls, SAP source list audit, SAP goods receipt controls, SAP ERS audit, SAP accounts payable controls