10 record-to-report tips in SAP ECC for audit compliance

Prevent segregation of duties conflicts

Appropriate segregation of duties (SoD) is important in the financial reporting process. Insufficient SoD can lead to unapproved journal entries that require time to correct and resolve or undetected errors that potentially lead to poor management decisions based on inaccurate information or even outright fraud. An example of SoD to avoid conflict is when a person given the responsibility to post in SAP General Ledger transactions should be able to create or maintain FI master data. Similarly, the person given the responsibility to post abnormal or high-value General Ledger transactions shouldn't be allowed to approve them.

Restrict postings to functional areas

A large majority of General Ledger postings occur through normal daily transaction processing in SAP ECC, often without the user recognizing the accounting entries created in the background. For example, goods receipts post items to inventory or expense and recognize an obligation to pay suppliers for those items. Similarly, shipments to customers subtract from inventory and trigger an expectation of customer payments. Common transactions like these occur every day without any need for a user to go into FI and post directly to General Ledger. Inevitably, however, some transactions require manual posting, and thus, some accounting users need to create journal entries. This ability should be limited because manual postings bring the risk of human error.

Limit access to powerful transactions

You should assign powerful transactions to a limited number of people and control them via authorizations. Even if these functions are never used, the ability of a user to perform these transactions poses risks to the organization and raises audit concerns. A few of these transactions include the ability to open and close accounting periods (transaction: S_ALR_87003642), the ability to perform mass transaction reversals (transaction: F.80) or the ability to post to periods that most users find blocked for posting (authorization object: F_BKPF_BUP).

Restrict changes to customer credit master records

Credit management is also crucial to accounting and financial reporting, and special accounting rules apply to valuing accounts receivable. For example, if a customer is only able to pay half of what it owes a company, then the value of the customer receivable is what the company reasonably expects to receive and not the full value. Because of this, customer credit management is closely managed by the finance department in many companies.

Restrict changes to vendor accounting-related master records

Specific information, such as vendor reconciliation accounts and bank data, can be important for both internal control and fraud prevention.

Similarly to customer records, vendor master records also contain important accounting-related data. Specific information, such as vendor reconciliation accounts and bank data, can be important for both internal control and fraud prevention. As such, maintenance over certain vendor master data fields is important to financial reporting. If a company is also using the SAP Materials Management purchasing subcomponent, it will generally use the subcomponent to centrally manage vendor master data, with specific permissions related to accounting details. Vendor data can also be managed directly in FI. From an SoD perspective, entry and maintenance of accounting-related vendor details should be kept separate from the purchasing function.

Restrict changes to banking master records

Bank account information is highly susceptible to fraud. SAP ECC provides a variety of mechanisms to restrict changes to bank master records. You can set security or authorization permissions to restrict changes to a bank account, credit control area and specific fields in credit management.

Define important fields as required entry

By default, the fields that the system requires for transaction processing or master data entry may not be all the fields needed to fully process business transactions. You need to configure it to flag situations where additional information may be required to help ensure a high level of data integrity. For example, you can make the reconciliation account field entry mandatory, thereby ensuring that, whenever a posting is made, a real-time posting is automatically made in the related General Ledger reconciliation account.

Create General Ledger validation checks

Beyond ensuring that data is entered in specific fields, the system also validates data entry based on simple or complex criteria. While the system already contains many standard edit and validation checks, additional validation or substitution rules can strengthen financial reporting controls. Data validation for General Ledger entries helps limit the possibility of error and can minimize opportunity for fraud and abuse.

Set reasonable posting tolerance levels

A good early step is to use the SAP ECC posting tolerance functionality. Defining the posting tolerances lets you limit postings to a maximum amount -- dollar or percentage -- for a single document or a single line item within a document. Defining a posting tolerance, while leaving the tolerance group blank, creates a rule that applies to all users. Then, establish a tolerance group for a limited set of users with the ability to exceed standard limits, while, at the same time, restricting these users from posting clearly erroneous transactions. The tolerance levels defined in a default SAP installation are substantially higher than the typical postings by most organizations -- in the hundreds of millions of dollars -- and, therefore, auditors often look to ensure that settings have been changed from the default.

Implement Park and Post

To ensure that all manual postings to General Ledger receive a secondary review, companies can implement a technique called Park and Post. To implement Park and Post, configure SAP ECC so users who have the ability to create General Ledger entries cannot also post those entries. A second group of experienced and knowledgeable users who do not have the ability to create General Ledger entries would then review each parked document and post those they deem appropriate. For the Park and Post technique to be effective -- and pass audit scrutiny -- the review process has to be consistent, reliable and not merely a formality.