Risk is an omnipresent driving force in all business activities. It requires producing information about the probability of different outcomes in the decision-making process. The assurance services improve the quality of this information across business activities (AICPA, 1996). Assurance, provided by internal and external auditors and many other parties, is the objective examination of evidence to perform an independent assessment over business activities. It adds credibility to the information, from the statutory financial reporting to other non-financial information in environmental and social reports. Assurance is the confidence of what needs to be controlled is actually being controlled in practice.
Since the board is responsible for ensuring that there are robust internal control arrangements across the whole organization, assurance is also a key compliance issue. Moreover, most codes for good corporate governance require the board to attest the effectiveness of the internal control and risk management systems.
There are tools to coordinate and to maximize how to provide assurance services. Assurance maps visually link the assurances from all the providers to the risks that affect the organizational objectives. They explain how the assurance activities (x-axis) apply to key risks in sequential business activities (y-axis). The assurance activities are usually arranged by the three lines of defense or the five lines of assurance models. The maps provide a quick and clear view of processes and risks to the board, in order to ensure a consistent management, oversight and reporting under a common methodology and language. Assurance maps promote the collaboration between departments while being cost effective.
Keys to making decisions on assurance
The primary objective of the assurance mapping is to detect areas of gaps and duplications in assurance efforts between departments. These maps quickly reveal the level of assurance oversight to alleviate low-value and redundant auditing efforts.
In order to join efforts for a strong GRC function, the risk methodology, particularly related to the taxonomy and the rating scales, should be standardize to express a common and holistic view. It allows the coordination and the interaction between business owners and assurance providers.
With the purpose of identifying processes with missing or unnecessary assurance efforts, the risk exposition can be linked to each process to assess if the assurance costs are justified (“reasonable assurance” for the risk tolerance). When too much assurance is concentrated in one process, the causes for these efforts should be understood before reassigning controls and responsibilities across departments.
When combining assurance programs and coordinating activities, the responsibilities defined by the policies or the audit chapter should be updated. The assurance map is a tool to update and coordinate departmental responsibilities, but not a policy by itself.
Besides combining assurance efforts for duplicated tasks, or reassigning controls on gaps, the communication on issues and action plans for remediation should flow across all the departments. Removing a department to assure a process does not imply that it no longer receives information about the trust and quality of the related information and its controls.
An assurance map in practice
As an example, the following map details the process steps and their risks for a simplified financial month-end closing in a SAP company. This process-based map consolidates controls and risks from assurance providers to assess how much coverage is achieved and needed. It combines the three line of defense model with a standard SAP process for a closing compatible for SOX or COSO compliance.
The assurance level rating represents the quality and the level of evidence by each department.
H High Assurance: assurance is detailed and cyclically conducted, the amount of audit evidence reduces risks to a low level (eg. low material accounting misstatement risks), controls are in place and adequately mitigate risks, policies are in place and communicated, IT/BI tools are deployed to automatize controls and to report red-flagged transactions, and performance metrics are closely monitored
M Medium Assurance: assurance is not cyclically performed, controls are not in place to cover some risks, policies are not fully in place or communicated, manual controls are not automated
L Low Assurance: low or none assurance, significant concerns over the adequacy of the controls in place in proportion to the risks; few policies in place
Get the latest in corporate governance, risk, and compliance on Twitter
The importance of risk and compliance has dramatically increased over the last years to improve corporate governance. Organizations are addressing the governance challenges, primarily as a consequence of regulatory requirements, business transformation, emerging risks and large scandals in corporate governance. Many organizations are struggling to focus their risk and compliance programs to meet stakeholders’ expectations.
A large number of GRC services and solutions are currently available from large and niche consulting firms to support an integrated control model. A GRC platform is offered as a transparent system of collaboration to orchestrate control activities across business. While organizations can fairly deal with the “G”, the “R”, and the “C” as independent departments, the integration of them was proven to be difficult, leading to control gaps, redundancies, inefficiencies and conflicts. A plethora of GRC modelling proposals exists both in the commercial arena and in the research community (Racz et al., 2010). Business intelligence has the ability to easily model control objectives and to address holistic risks.
The integration of controls, protocols, key indicators and reports into a GRC platform facilitates the automated detection of risks and the audit of compliance procedures. A major issue about this approach is inflexibility to maintain the control repository for a complex and dynamic environment while using a single solution. The diversity of emerging risks requires a grounded approach to support a “compliance by design” model. Business intelligence allows the GRC departments to model the control framework to produce breach alarms, monitor performance and simply assurance.
The capability to capture and to change control requirements through a common GRC modeling framework facilitates the management of the controls and the enterprise applications. Business process management, as a common framework for business intelligence, allows enforcing corporate compliance and meeting control objectives. It helps to link what need to be done (nominative compliance approach) with how the control activities should be performed by the business process owners (descriptive internal audit approach). It is essential, then, that business, compliance, and control objectives are jointly designed to converge in common rules (Shazia at al., 2007). Regulations, compliance and internal control directives are complex and vague. These mandates of permissions and prohibitions, often written in legalese or technical jargon, are translated by subject experts into rules for a single control repository. These rules can trigger violation alarms and control remediation protocols that may surface at runtime.
Example: U.S. anti-boycott laws scenario
This scenario shows a set of simple rules to integrate control actions with compliance risks in a company under SAP and business intelligence.
A GRC platform based on business intelligence allows organizations to easily maintain and adjust their compliance requirements to highlight control violations and report key compliance indicators.
Get the latest in corporate governance, risk, and compliance on Twitter
The most visited post in my blog covers the 20 most critical conflicts that you may find in SAP auditing, SOX testing and user security controls. After several years of fine-tuning the user conflict matrix and having SAP HANA released, I expand this post by listing the 100 most critical and frequent segregation of duties incompatibilities. This list helps in simplifying the user reviews by internal auditors, functional roles and access security professionals while explaining the risk which may result in operational fraud.
This is the list which you are welcome to get as a MS Excel file,
VA01 Create Sales Order and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
F.80 Mass reversal of documents and F-60 Maintain Table: Posting Periods are incompatible since the user may open accounting periods previously closed and make postings after month end.
VA01 Create Sales Order and VD01 Create Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and VD02 Change Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and FD02 Change Customer (FI) are incompatible since assets may be disposed at less than the true value.
VA01 Create Sales Order and FD01 Create Customer (FI) are incompatible since assets may be disposed at less than the true value.
VA02 Change Sales Order and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and F-30 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
F.80 Mass reversal of documents and OB52 C FI Maintain Table T001B are incompatible since the user may open accounting periods previously closed and make postings after month end.
VL02N Change outbound delivery and F-22 Enter customer invoice are incompatible since the user may create/change a delivery and create/change an invoice.
XK01 Create Vendor (Centrally) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VA02 Change Sales Order and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and VL02N Change outbound delivery are incompatible since the user may create/change sales orders and deliveries to hide the misappropriation of goods.
VF01 Create Billing Document and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VL01N Create outbound delivery with order ref and F-22 Enter customer invoice are incompatible since the user may create/change a delivery and create/change an invoice.
VA01 Create sales order and F-32 Clear customer are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
XK01 Create Vendor (Centrally) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD02 Change customer (centrally) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
MIGO Goods Movement and MM01 Create Material are incompatible since the user could create or change a fictitious receipt and create/change a material document to hide the deception.
Get the latest in corporate governance, risk, and compliance on Twitter
XD01 Create customer (centrally) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
XD01 Create customer (centrally) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VA01 Create sales order and VL01N Create outbound delivery with order ref are incompatible since the user may create/change sales orders and deliveries to hide the misappropriation of goods.
VF01 Create Billing Document and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA02 Change Sales Order and VD01 Create Customer (SD) are incompatible since assets may be disposed at less than the true value.
FK01 Create Vendor (FI) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VA02 Change Sales Order and VD02 Change Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and F-26 Incoming payments fast entry are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VA02 Change Sales Order and FD02 Change Customer (FI) are incompatible since assets may be disposed at less than the true value.
XD01 Create customer (centrally) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
XD02 Change customer (centrally) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
XK01 Create Vendor (Centrally) and VD01 Create Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated. If the same person can process both items, unauthorized changes could be made and possibly not detected. Th.
XD02 Change customer (centrally) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VD01 Create customer (sales) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
FK02 Change Vendor (FI) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XK01 Create Vendor (Centrally) and VD02 Change Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-26 Incoming payments fast entry are incompatible since the user may create a customer and then post payments against the customer.
XK01 Create Vendor (Centrally) and FD02 Change Customer (FI) are incompatible since assets may be sold to non-existent or fraudulent customers.
VD02 Change customer (sales) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
FD02 Change customer (accounting) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VA02 Change Sales Order and FD01 Create Customer (FI) are incompatible since assets may be disposed at less than the true value.
MK01 Create Vendor (MM) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
FK01 Create Vendor (FI) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VF01 Create Billing Document and VD01 Create Customer (SD) are incompatible since assets may be disposed at less than the true value.
VA02 Change sales order and F-30 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
XD02 Change customer (centrally) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
ME21N Access to Create Purchase Order and ABAA Unplanned Depreciation are incompatible since assets may be acquired at an overvalued or undervalued price and then depreciated. Unplanned depreciation, manual depreciation, and asset value write-ups are processed incorrectly or without authority to proceed.
MK02 Change Vendor (MM) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VF01 Create Billing Document and VD02 Change Customer (SD) are incompatible since assets may be disposed at less than the true value.
VF01 Create Billing Document and FD02 Change Customer (FI) are incompatible since assets may be disposed at less than the true value.
XD02 Change customer (centrally) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated. If the same person can process both items, unauthorized changes could be made and possibly not detected.
XK01 Create Vendor (Centrally) and FD01 Create Customer (FI) are incompatible since assets may be sold to non-existent or fraudulent customers.
VA01 Create sales order and F-51 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK02 Change Vendor (FI) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
XK02 Change Vendor (Centrally) and XD01 Create Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
F.80 Mass reversal of documents and SCMA Schedule Manager: Scheduler are incompatible since the user may open accounting periods previously closed and make postings after month end.
XD02 Change customer (centrally) and F-26 Incoming payments fast entry are incompatible since the user may create a customer and then post payments against the customer.
FD01 Create customer (accounting) and F-30 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VD01 Create customer (sales) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VF02 Change Billing Document and XD01 Create Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VD02 Change customer (sales) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
MK01 Create Vendor (MM) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VD01 Create customer (sales) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
FD02 Change customer (accounting) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
ME21N Access to Create Purchase Order and ABZU Write-up are incompatible since assets may be acquired at an overvalued or undervalued price and then depreciated. Unplanned depreciation, manual depreciation, and asset value write-ups are processed incorrectly or without authority to proceed.
XD01 Create customer (centrally) and F-51 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VD02 Change customer (sales) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
MK02 Change Vendor (MM) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
VF01 Create Billing Document and FD01 Create Customer (FI) are incompatible since assets may be disposed at less than the true value.
FD02 Change customer (accounting) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VA02 Change sales order and VL02N Change outbound delivery are incompatible since the user may create/change sales orders and deliveries to hid the misappropriation of goods.
FK01 Create Vendor (FI) and VD01 Create Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
XD01 Create customer (centrally) and F-39 Clear customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated. If the same person can process both items, unauthorized changes could be made and possibly not detected. Th.
VA01 Create sales order and FBCJ Cash journal are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
XK02 Change Vendor (Centrally) and XD02 Change Customer (Centrally) are incompatible since assets may be sold to non-existent or fraudulent customers.
ME21N Access to Create Purchase Order and ABMA Manual Depreciation are incompatible since assets may be acquired at an overvalued or undervalued price and then depreciated. Unplanned depreciation, manual depreciation, and asset value write-ups are processed incorrectly or without authority to proceed.
VA02 Change sales order and F-32 Clear customer are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK01 Create Vendor (FI) and VD02 Change Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
VD01 Create customer (sales) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VF02 Change Billing Document and XD02 Change Customer (Centrally) are incompatible since assets may be disposed at less than the true value.
VA01 Create sales order and F-52 Post incoming payments are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK01 Create Vendor (FI) and FD02 Change Customer (FI) are incompatible since assets may be sold to non-existent or fraudulent customers.
FD01 Create customer (accounting) and VL02N Change outbound delivery are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VA01 Create sales order and FF/4 Interface for check deposit data entered externally are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VD02 Change customer (sales) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VA01 Create sales order and F-04 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VD01 Create customer (sales) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated. If the same person can process both items, unauthorized changes could be made and possibly not detected. Th.
FD02 Change customer (accounting) and VL01N Create outbound delivery with order ref are incompatible since the user may create a customer and delivery goods to that customer, thereby misappropriating goods.
VA01 Create sales order and FB05 Post with clearing are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
VA01 Create sales order and FF/5 Post check deposit data entered externally are incompatible since the user may create/change a sales order and process incoming payments inaccurately/fraudulently, potentially resulting in losses to the company.
FK02 Change Vendor (FI) and VD01 Create Customer (SD) are incompatible since assets may be sold to non-existent or fraudulent customers.
VL02N Change outbound delivery and F-30 Post with clearing are incompatible since the user may create fictitious/incorrect delivery and enter payments against these, potentially misappropriating goods.
FD01 Create customer (accounting) and F-32 Clear customer are incompatible since the user may create a customer and then post payments against the customer.
VD01 Create customer (sales) and F-26 Incoming payments fast entry are incompatible since the user may create a customer and then post payments against the customer.
XD01 Create customer (centrally) and FBCJ Cash journal are incompatible since the user may create a customer and then post payments against the customer.
XD02 Change customer (centrally) and F-51 Post with clearing are incompatible since the user may create a customer and then post payments against the customer.
VD02 Change customer (sales) and F-29 Post customer down payment are incompatible since the user may have the ability to enter or modify down payments for customers and the user may have the ability to create or modify customer account information should be segregated. If the same person can process both items, unauthorized changes could be made and possibly not detected.
A risk-based approach to SAP segregation of duties The top 100 most critical segregation of duties conflicts in SAP Segregation of Duties Fraud Risks & Solutions Security SOD Segregation of Duties SOD Conflicts and Role Based Authorization in SAP SAP Segregation of Duties SOX 404 and Risks
Risk specialists and auditors often fail to consider collusion in their fraud risk assessments. According to the ACFE, when two or more people are involved in a fraud scheme, the median losses quadrupled those from single perpetrators. In addition, collusive fraud is one of the most difficult types of risks to identify. In this post, I am discussing about collusive schemes and measures to prevent them.
When one employee has permission to make a transaction and other employee has the right to approve the same transaction, fraud may exist if they collude with each other. Some collusive schemes may involve redirecting payments, creating false invoice payments, asset misappropriations or creating non-purchase payments. These schemes can be done “bellow the radar” since insiders usually know well the company controls and loopholes, and they can plan the scheme better.
Besides effective segregation of duties practices, mitigation measures involve disclosure of vendor relationship by directors and employees, monitoring by business intelligence software and reporting unwillingness to share duties.
There are several business intelligence tools to detect and report transactions with collusion risks. Generally, they match the execution of critical transaction codes in SAP or other ERP with email or phone communications between related users in a short time. Some research was recently done to test collusion scenarios and its results were positive to properly identify transactions involving collusion risks. Data mining was also tested to be accurate to detect collusive fraud networks. To be effective, both business intelligence and data mining tools have to link ERP information with other databases (emails, call logs, business directories)
Fraud 2.0 is here to stay.
Get the latest in corporate governance, risk, and compliance on Twitter
The IT department is well aware of SOX IT controls. However, this department may also assist in providing information for business cycle testing to comply with SOX. It is important that IT and SAP process owners know that to expect from these audits. Some auditors would not have the access privilege or the knowledge to perform data extractions in SAP. In this case, they need the IT assistance. In this post, I explained that a SOX auditor usually covers in reviewing processes based on SAP.
1- Incompatible SAP Accesses for a Business Process
A SOX auditor would ask for a list of users with access to critical transactions. The definition on critical transactions depends on each company and process. However, most of the critical accesses are related to posting, creating and approving key transactions. Customized transactions (Y and Z) are also reviewed when involving high risk approvals. Manual tasks (eg. signing checks or approving reconciliations) are usually added to this analysis. Please refer to my post listing the most common Segregation of Duties Conflicts in SAP for further details.
2- Inconsistencies in SAP Master Files
A SOX auditor would ask for master files to check inconsistencies. Most of this audit process relates to applying filters in the same table or linking different tables. SOX auditors need to control the standardization of business processes and flows. For instance, SOX auditors would review customer credit limits (RF02L), tolerance keys (T169G), customer/vendor masters (eg. addresses, banks, duplications, payment terms, tax codes), and exchange rates (TCURR).
3- Inconsistencies in SAP Parameters
SOX auditors would ask for some parameters in SAP. Typically, they would need to assure that the 3-way match is set, the posting periods are limited in time, the approval flows are reasonable (parking and approving FI documents), and the approver delegations (FMWF_MDRUL) follow internal guidelines, etc.
4- Inconsistencies in custom interfaces to SAP
SOX auditors would walkthrough and test SAP interfaces with external applications (generally related to eBanking and eBusiness). They would be concerned about data integrity and security.
Get the latest in corporate governance, risk, and compliance on Twitter
In this post, I am summarizing the process on how taxes are managed in SAP and its involved reports. SAP is able to manage different taxation systems to comply with local regulations. Generally speaking, taxation systems can be related to input taxes (taxes on purchases) and output taxes (taxes on sales). Consumption taxes included by those systems can be classified as value added tax, taxes on sales or usage, country specific additional taxes, and withholding taxes. In the case of other complex types of taxations, SAP provides an interface to support third party software to determine local tax allocations.
SAP follows a logic to calculate taxes consisting of an access sequence and a condition type. The access sequence arranges condition tables to be used according to the field contents (eg. first calculate the VAT, then the withholding VAT). The condition table is the model to calculate the tax amount (eg. percentage on the total sale value or fixed amounts). Both tables create a tax procedure for each country. An account key links the tax procedure to the posting in the GL accounts. SAP has a number of predefined account keys.
The tax code (FTXP, tables T007a / s) is the main link to calculate, verify and post taxes for each country. Each tax code is assigned to country specific tax procedure to enter a G/L from a document (eg. Invoice or sales order). SAP includes predefined tax code templates for each country (including the relationship between the tax types (Sales Tax) with tax rates. SAP needs the posting keys, rules to determine the account (tax code or account key) and operative tax accounts to automatically assign taxes.
In addition, SAP can process single level taxes (eg. VAT in Europe, South Africa and Australia) and multi level taxes by jurisdictions (eg. state or city specific, US, Brazil, India). In order to adjust the access sequences to the multi level taxes, jurisdiction codes are created to determine the local tax rate. In conjunction with a tax code, a jurisdiction code determines the amount of tax (and is breakdown among jurisdictions). Jurisdiction codes are made up of multiple levels: state (first 2 digits), county (next 3 digits) and city (last 3 digits).
Tax categorization in SAP involves several modules. In SAP SD, it specifies if a customer is liable of sales taxes for each country in the pricing process. In SAP MM, it specifies the applied tax at a material, plant and account category level in the sales process. In SAP Fi, the G/L master record specifies whether or not a posting without tax is allowed. The tax category determines which type of tax should be applied (e.g. input tax only). Customers and vendors are defined as either taxable or tax-exempt.
Standard tax reports in SAP are country specific and pre-defined to meet the standards set up by those countries. There are several useful reports to control how revenue taxes are set:
J1I2 Display Sales Tax Register by entering company code, posting date (fiscal year), ledger and condition type
Report RFUMSV00 Advance Return for Tax on Sales/Purchases
FTXA Display a Tax Code, SAPMF82T Report to Generate FTXP
FMBGUL S Sales Tax List, RFFMBGA Report to Generate FMBGUL
FMBG3 Display Input Tax Adjustments
FO8D Display Input Tax Distributions
GJVA Advance Tax Report
SOX audits require checking that incompatible tasks and system rights are assigned to different individuals in order to avoid any conflict of duties. Segregation of duties (SOD) has always been an important component of the control environment because its impact in fraud prevention and the alignment between IT and the business. SOD enhances the IT principle of minimal privilege. Both manual tasks (eg. approvals by signature) and system roles should be included in these audits. The type and number of conflicts between transactions are always a challenge for SOX scoping . For instance, there are more than 150 high risk incompatibilities reported by SAP. In the business practice, it may be hard to understand the risks associated to a reported conflict.
Even SAP provides an extensive framework for maintaining role-based security (eg. RSUSR008, RSUSR009), several tools to simplify the audit process have been launched (eg. Virsa, Approva and CSI). All these complexity was a challenge for the compliance function to create solid policies and to educate staff regarding SOD.
I created a list with the top 20 most critical segregation of duties conflicts in SAP to help in this process. I included both the incompatibility of transactions and the fraud/error risk for SOX compliance. I selected the most sensitive transactions, the riskier and more frequent situations and their reported incompatibilities.
For the complete list of high risk SOD conflicts in SAP: http://www.box.net/shared/am4bsvi8i5
CR04 Process CRM Sales Order + SD02 Delivery Processing = A user could create a fictitious sales order to cover up an unauthorized shipment.
CR04 Process CRM Sales Order + CR07 CRM Billing = Inappropriately create or change sales documents and generate the corresponding billing document in CRM.
CR05 Service Order Processing + CR06 Service Confirmation = Enter fictitious service orders for personal use and accept the services through service acceptance. The user could prompt fraudulent payments. In addition spare parts could be fraudulently issued from inventory as a result of the confirmation.
SR01 EBP / SRM Vendor Master + SR03 EBP / SRM Invoicing = Maintain a fictitious vendor and enter an invoice to be included in the automatic payment run.
FI03 Bank Reconciliation + SR03 EBP / SRM Invoicing = A user can hide differences between bank payments and posted AP records.
SR01 EBP / SRM Vendor Master + SR07 EBP / SRM PO Approval = Create a fictitious vendor or change existing vendor master data and approve purchases to this vendor.
SR01 EBP / SRM Vendor Master + SR09 EBP / SRM Maintain Org Structure = Create or maintain fictitious vendor and manipulate the organizational structure to bypass approvals or secondary checks.
AR02 Cash Application + FI03 Bank Reconciliation = Allows differences between cash deposited and cash collections posted to be covered up.
MM04 Goods Movements + MM02 Enter Counts – IM + MM04 Clear Differences – IM = Accept goods via goods receipts and perform an IM physical inventory adjustment afterwards.
MM04 Goods Movements + MM03 Enter Counts & Clear Diff - IM = Accept goods via goods receipts and perform an IM physical inventory adjustment afterwards.
PR01 Vendor Master Maintenance + AP02 Process Vendor Invoices = Maintain a fictitious vendor and enter a Vendor invoice for automatic payment.
PR01 Vendor Master Maintenance + PR02 Maintain Purchase Order = Create a fictitious vendor and initiate purchases to that vendor.
PR02 Maintain Purchase Order + MM03 Enter Counts & Clear Diff - IM = Inappropriately procure an item and manipulating the IM physical inventory counts to hide.
FI03 Bank Reconciliation + AP02 Process Vendor Invoices = Can hide differences between bank payments & posted AP records.
PR04 PO Approval + MM02 Enter Counts - IM + MM04 Clear Differences – IM = Release a non bona-fide purchase order and the action remain undetected by manipulating the IM physical inventory counts.
PR01 Vendor Master Maintenance + PR05 Purchasing Agreements = Risk of entry of fictitious Purchasing Agreements and the entry of fictitious Vendor or modification of existing Vendor especially account data.
AP01 AP Payments + FI03 Bank Reconciliation = Risk of entering unauthorized payments and reconcile with the bank through the same person.
PR02 Maintain Purchase Order + MM02 Enter Counts - IM = Inappropriately procure an item and manipulating the IM physical inventory counts to hide.
PR04 PO Approval + MM03 Enter Counts & Clear Diff - IM = Release a non bona-fide purchase order and the action remain undetected by manipulating the IM physical inventory counts
AP04 Manual Check Processing + FI03 Bank Reconciliation = Risk of entering unauthorized manual payments and reconcile with the bank through the same person.
SD01 Maintain Customer Master Data + AR01 AR Payments = Create a fictitious customer and initiate payment to the unauthorized customer.
SD01 Maintain Customer Master Data + AR05 Maintain Billing Documents = User can create a fictitious customer and then issue invoices to the customer.
During my experience working in auditing with SAP, I have compiled a series of useful SAP T-Codes by business cycles that I would like to share. I found it very useful as reference for tracking and control monitoring. They are mostly related with SAP display functions and they cover the frequently used transactions for auditing.
I used this cheat list in different presentations and training sessions. I have always received a very positive feedback about this.
