SAP Audit Guidefor Expenditure

This audit guide is designed to assist the review of expenditure processes that rely upon automated controls in SAP systems.

The specific areas examined in this guide are relevant configurables, transactions, authorizations and reports in the Materials Management (MM) module and Accounts Payable (FI-AP) sub-module of SAP.

The guide provides instructions for assessing application-level controls in the following areas of the procure-to-pay process:

Vendor Master Data

Purchasing

Invoice Processing

Payment Processing

The guide is delivered using clear, non-technical terms to enable financial and operational auditors to successfully navigate the complexities of SAP security. Other volumes of this guide deal with SAP controls in areas such as Financial Accounting, Revenue, Inventory, Human Resources and Basis.

Vendor Master DataVendor master records include general data such as address, contact information and banking data, company-code leve l data such as account assignments, and purchasing-level data such as delivery terms. Therefore, when reviewing vendor master records, it is important to bear in mind that certain types of data can vary between company codes and purchasing organisations. The latter are procurement groups within Logistics. SAP can be configured with multiple groups covering different plants or companies or a single purchasing organisation covering all companies in a client. Purchasing organisations can be reviewed via table T024.

Vendors are assigned to specific account groups that determine, among other things, required, optional and suppressed fields during master data input and numbering ranges. Configured groups should be reviewed through transaction OBD3. Default groups include vendor (0001), invoicing party (0006) and one-time vendors (CPD). The use of one-time vendor accounts should be tightly controlled since they allow name, address and bank data to be entered during invoice entry. This removes the segregation between

ExpenditureSAP Audit Guide

2vendor and invoice entry which increases the risk of fraudulent payments. Standard practice is to disable the one-time vendor group. However, in cases where there is a business need to process payments to one-time vendors, there should be a regular review of invoices processed against the group. This can performed through transaction FBL1N, filtering by account groups using dynamic selections.

Within the General and Company Code areas of each vendor record, the Alternate payee field should be suppressed. If enabled, SAP could route payments intended for a vendor to alternate suppliers in the master file. The Payee in document field should also be suppressed since this will enable users to enter alternate name, address and bank information during invoice entry. Permitted alternate payees can be viewed in table LFZA.

SAP will not perform a check for duplicate vendors during data entry by default. This must be configured in the Implementation Guide (IMG). Message number 144 in the F2 group should be enabled. This will enable a system check at the address level when a new record is created in the vendor master. The check will not interfere with batch processing for vendor changes as long as the Extended log option is selected.

Changes to master records are automatically logged by SAP. There are a number of standard reports that should be periodically reviewed to ensure changes are authorized and accurate. This includes Display of vendor changes (RFKEPL00), List of new vendors (RFKKVZ00), and Display of bank account changes (RFKABL00).

Access to functions used to maintain the vendor master should based on role requirements and segregated from the ability to enter and edit purchase orders, goods receipts and invoices. The specific transaction codes and authorization objects are listed in Table A. Relevant a u t h o r i z a t i o n o b j e c t s i n c l u d e C _ T C L A _ B K A , M_LFM1_EKO, and F_LFA1_APP/ BEK/ BUK/ GEN/ GRP/ AEN with activity levels 01 (create) 02 (change) and 05 (block/ unblock) and 06 (delete).

As of Release 4.5A, SAP supports dual control for critical master data fields. This should be implemented for sensitive fields related to areas such as banking information and alternate payees. If enabled, the system will block payments against a vendor when a sensitive field is

changed until the change is confirmed by a designated approver.

This is configured through IMG - Financial Accounting - Accounts Payable - Vendors Accounts - Master Data - Preparations for Creating Vendor Master Data - Define Sensitive Fields for Dual Control (Vendors).

TRANSACTION DESCRIPTION

FK01 Create Vendor (Accounting)

FK02 Change Vendor (Accounting)

FK05 Block/ Unblock Vendor (Accounting)

FK06Mark Vendor for Deletion (Accounting)

MK01 Create Vendor (Purchasing)

MK02 Change Vendor (Purchasing)

MK05 Block/ Unblock Vendor (Purchasing)

MK06Mark Vendor for Deletion (Purchasing)

XK01 Create Vendor (Centrally)

XK02 Change Vendor (Centrally)

XK05 Block Vendor (Centrally)

XK06 Mark Vendor for Deletion (Centrally)

XK07 Change Vendor Account Group

KEP8 Create Operating Concern

Table A: Vendor Master Transactions

3PurchasingPurchase order documents can be assigned to a single vendor or contain line items split across multiple suppliers. They can be generated automatically from agreements and requisitions or entered manually. During manual entry, the input attributes for certain critical fields should be set to mandatory (input required). Other fields, such as payment terms and GR indicators, should be set to display-only. GR indicators determine whether a goods receipt is required before an invoice is processed. This can be enabled at either the field status level or within the item category configuration. Field settings in PO documents should be reviewed through IMG - Materials Management - Purchasing - Purchase Order - Define screen layout at document level.

SAP release procedures should be enabled to ensure electronic authorization of purchase orders prior to processing. Release strategies can be configured with single or multiple managers within purchasing organisations and should be closely analyzed through IMG Materials Management Purchasing Purchase Order Release Proc for Purch Orders Define release procedure for POs Workflow. Note that POs may not be subject to release requirements if they are based on approved purchase requisitions. Also, in some versions of SAP, release procedures control only the communication of purchase orders and do not prevent goods receipts, invoice processing and payments against unapproved orders. In such cases, receipts and invoices processed for unreleased orders should be monitored and investigated. This can be performed through standard reports available through Information Systems Logistics Purchasing.

Source lists should also be enabled to block the procurement of material from unapproved suppliers. Transactions ME06 and ME0M can be used to generate reports that display source lists associated with items in the materials master. A sample of POs can then be traced back to source lists to ensure that items are procured from approved vendors.

Table B lists all transactions related to creating, changing or releasing outline agreements, requisitions, purchase orders and stock transports. Access to these functions should be restricted. This includes authorization objects M_EINK_FRG, M_BEST_BSA/ EKG/ EKO/ WRK, M_ANFR_BSA/ EKG/ EKO/ WRK and M_BANF_BSA/ EKG/ EKO/ FRG/ WRK.

TRANSACTION DESCRIPTION

ME21/ ME21N, MEPO

Create Purchase Order

ME22/ ME22N, MEPO

Change Purchase Order

ME24/ ME24N Maintain Purchase Order Supplement

ME25 Create Purchase Order, Vendor Unknown

ME27 Creation of Stock Transport Order

ME28 Collective Release of Purchase Order

ME29/ ME29N Release Purchase Order

ME31 Create Outline Agreement

MEMASSPO Mass Change of Purchase Orders

ME32 Change Outline Agreement

ME34 Maintain Outline Agreement Supplement

ME51 Create Purchase Requisition

ME52 Change Purchase Requisition

ME54/ ME54N Release Purchase Requisition

ME55 Collective Release of Purchase Requisition

Table B: PurchasingTransactions

Invoice ProcessingBy design, SAP does not prevent users from entering invoices against alternate suppliers in the vendor master. The system will issue a warning message but will not block a payment request. Therefore, it is important to prevent user input in the vendor number field during invoice verification. However, payments can be routed to alternate suppliers even if invoices are posted to the account of a vendor specified in the underlying purchase order. This is performed through the Different payee field. In this scenario, SAP will post the invoice to the account of the vendor with whom the purchase was placed, but the payment program will credit the payment to the bank account of a different payee. The alternate payee does not require a vendor master record. SAP will select payees that are the most specific. Therefore, payees specified in documents have priority over payees specified in the vendor master.

4SAP does not subject invoices processed through AP to the same level of scrutiny as those processed through MM

Field status variants for document types such as RE (PO invoice) and KR (non-PO invoice) should be closely reviewed in the FI area of IMG.

SAP can be configured to perform a check for duplicate invoices during invoice entry based on vendor, currency, company code, gross amount, vendor invoice number, and invoice date. It can display either a warning or error message depending on settings selected in customizing. The latter option will block the invoice. Checks against vendor invoice number, invoice date and company code should be unchecked since vendors may submit duplicate invoices with different invoice references and dates. The Chk double inv option must be selected in the Payments in Accounting screen of each vendor master record for SAP to enable the duplicate invoice check.

For PO invoices, SAP should be configured to perform a three way match between purchase orders, good receipts and invoices during invoice verification. When enabled, the system will check for item, quantity and price variances between documents by line item against predefined tolerance levels. SAP will block the entire invoice if a threshold is exceeded, not just individual line items. Matching conditions and thresholds are configured through tolerance keys using transaction OMR6 (Tolerance limits: Inv Verification). The tolerance key item amount without order reference should be activated and set to an upper limit of zero. If this control is not enabled, SAP will process invoices without a valid PO through Logistics.

Non-PO invoices should be processed exclusively through FI AP, not MM. SAP does not subject invoices processed through FI AP to the same level of scrutiny as those processed through MM. Therefore, organisations should restrict the number of vendors processed through FI AP and consider using SAP workflow such as park and post functionality to enforce electronic authorization for non-PO invoices.

Organisations using Evaluated Receipts Settlement (ERS) do not use a three way match process since SAP automatically generates an invoice based on a two-way match between the PO and goods receipts. If organisations have elected to use ERS, they should ensure that the ERS parameter has been selected in all the relevant vendor records. This will subject all line items on a PO to ERS. However, ERS can be overridden if items have been set to non-ERS in purchasing info records. Therefore, it is important to ensure that items and not just vendors are set to ERS, and changes to the ERS parameter in both areas are reviewed and approved.

There are a number of key reports that should be regularly monitored by organisations. This includes the List of GR/IR balances report. The GR/IR account is a container for uncleared items and is used to track variances between receipts and invoices, receipts without invoices and invoices without receipts. This and other related reports are available through Information System Accounting Financial Accounting Accounts payable Report Selection.

5Access to invoice entry, edit and deletion transactions should be restricted. For SAP Release 4.6C and above, this includes MIRO (Enter Incoming Invoice), MIR7 (Park Invoice), MR8M (Cancel Document), MIRA (Fast Invoice Entry), MIR6 (Invoice Overview), MRBR (Release Blocked Invoices), MRRL and MRRS (Evaluated Receipt Settlement), FB01 (Post Document), FB02 (Change Document), F-43/ FB50 (Direct Invoice Entry). For earlier releases, it should include MRHR (Enter Invoice), MRHG (Enter Credit Memo), MR01 (Process Incoming Invoice), MR02 (Process Blocked Invoice), MR08 (Cancel Invoice Document), as well as the previously mentioned FI transactions The authorization objects M_RECH_EKG and M_RECH_SPG with activity level 02 are required to release blocked invoices.

Payment ProcessingInvoices that have successfully passed through invoice verification procedures are stored as open documents in SAP. They are automatically processed by the payment program on or before the due date, depending upon whether the system is configured to take advantage of any early payment discounts offered by vendors. Payments can be output as checks or transferred as payment orders directly to designated banks for processing through EDI. Maximum thresholds for payment amounts can be defined in the program parameters. SAP will generate an error message when the amount is exceeded and block the payment batch, generally referred to as payment lots. Invoices are closed and assigned a clearing document number when paid. The system automatically updates the appropriate sub-ledger and general ledger accounts after processing.

Payment runs are performed through the Automatic Payment Program which is accessed through transactions F110 and F111. This can be found in the menu path for Periodic Processing in Accounts Payable. Users require authorization objects F_REGU_BUK and F_REGU_KOA to schedule and edit payments. F_REG_BUK is also used by transaction FBZ0 (Display/ Edit Payment Proposal). After selecting F110, users enter a run date and assign a batch or lot reference. Once parameters for areas such as company code, posting date, payment method and vendor accounts are updated, the payment program will run automatically either immediately or during a scheduled date and time. Pre-run reports known as payment proposals are generated by the system and should be reviewed closely. Also, they should be reconciled to post-payment logs.

While payments are automatically pulled from cleared invoices, SAP does allow manual checks to be created and printed during a payment run. Access to this function should be tightly safeguarded. This includes transaction FCH5 (Manual Cheque Payments) and authorization objects F_PAYR_BUK and F_KKCMK with activity levels 01, 02, 05, 06, 10, 11, 17 and 43. Manual checks are created, edited, replaced, voided and deleted through Check Management functions in Accounts Payable - Payments.

Access to manual check entry should be restricted

Layer Seven Security

Webwww.layersevensecurity.comEmailinfo@layersevensecurity.comTelephone1 888 995 0993

Address Westbury Corporate CentreSuite 1012275 Upper Middle Road EastOakville, Ontario L6H 0C3, Canada

About Us

Layer Seven Security specialize in SAP security. The company serves customers across the globe to protect SAP systems against internal and external threats and comply with industry and statutory reporting requirements. It fuses technical expertise with business acumen to deliver unparalleled implementation, consulting & audit services targeted at managing risks in contemporary SAP systems.

Layer Seven Security employs a distinctive approach to SAP risk management that examines and manages vulnerabilities at the platform, application, program and client level. Through partnerships with leading software developers, the company is able to develop SAP systems with defense in depth and perform integrated security assessments that improve the quality and lower the cost of SAP audits. Layer Seven Security leverage leading SAP-certified solutions to provide comprehensive and rapid results covering risks in every component of SAP landscapes.

Copyright Layer Seven Security 2012 - All rights reserved.

No portion of this document may be reproduced in whole or in part without the prior written permission of Layer Seven Security.

Layer Seven Security offers no specific guarantee regarding the accuracy or completeness of the information presented, but the professional staff of Layer Seven Security makes every reasonable effort to present the most reliable information available to it and to meet or exceed any applicable industry standards.

This publication contains references to the products of SAP AG. SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius and other Business Objects products and services mentioned herein are trademarks or registered trademarks of Business Objects in the United States and/or other countries.