Administrative organization in R/3 typically works with static authorization and segregation of duties. However, strict application of these principles in low headcount organizations is difficult and can lead to a lack of proper control. Dual control offers an effective tool to provide four-eye control on all sensitive changes to customer and vendor master records, while allowing a more widespread authorization for non- sensitive corrections.

Classic guidelines for the separation of duties within accounts receivable (FI-AR) and accounts payable (FI-AP) master data maintenance focus on payment- and credit-related fields in vendor master records:

Users should not be allowed to create and modify master records and post transactions at the same time. Users who can maintain vendor master records and post transactions (invoices and payments) could create a fake vendor record and pay a fictitious invoice without detection. If these duties were separated, this fraud could only be accomplished with the collusion of two personnel. Another example is replacing a vendor bank account number with a privately owned bank account and entering fake invoices.

Credit management should be separated from master record maintenance in FI-AR. This prevents the master record clerk from creating a fake customer master record and granting credit to it, allowing uncontrolled shipments to nonexistent customers.

These guidelines work well in organizations that have large enough headcounts in finance to distribute and segregate tasks, but what if you are running a lean administration? I will explain the use of dual control in R/3 as a method that guarantees four-eye control even in smaller companies. Dual control achieves the same results as full segregation and prevents the everyday occurrence of circulating passwords and user IDs.

Although this functionality (which defines sensitive fields in Customizing) has been available for quite some time, I have not seen it used frequently, presumably because it is not well known. I will give you the basics on its use and customizing. After you implement it, an authorized clerk can still change a sensitive field as defined in Customizing. However, the change only takes effect after an authorized colleague has approved it.

So how does dual control work? I will focus on the case of vendor master data management, which often creates bottlenecks. For example, when one master data officer needs to make all the changes, vacations and unexpected absences can cause delays. The solution in some organizations is lax security and broad authorization profiles, which are open to abuse. Although in the past this might have seemed acceptable, it opens the possibility of fraud and will not be accepted in a security audit today.

The standard SAP dual control principle offers an efficient way out of this conundrum. R/3 makes it possible to split master data maintenance into two separate actions: change and approval of change. Both actions can never be performed using the same user ID. Two persons, reducing the risk of fraud, always check a change of sensitive fields and the changes themselves no longer have to be made by a single master data officer. The master data officer can focus on approving sensitive changes, while changes to non-sensitive fields no longer need to go through a lengthy approval process. Instead, the same person can make and approve changes to non-sensitive fields, as shown in Figure 1:

• Clerk 1 changes a bank account field in the vendor master. The result is that the payment to the vendor is blocked.
  
  
• Clerk 2 approves the field change. The result is that the payment run goes through.

Figure 1

How dual control works

How to Customize the Method

To customize the functionality, use menu path Financial Accounting>Accounts Receivable and Accounts Payable> Vendor (or customer) Accounts>Master Records> Preparations for Creating Vendor Master Records> Define Sensitive Fields for Dual Control. This takes you to a selection screen in which you can enter one or more sensitive fields (Figure 2).

Figure 2

Customizing sensitive fields

If you click on New entries, you can add entries. From a drop-down list (F4), all fields contained in the vendor master on the general and company code level are available. You should be careful not to overdo it because changing a sensitive field leads to a temporary payment block for vendors/customers. As an example, I selected the bank account number (LFBK-BANKN) to prevent the replacement of a real vendor account with a fraudulent one (Figure 3).

Figure 3

Defining the bank account number as a sensitive field

You can define fields in the customer or vendor master as sensitive. Note that sensitive fields cannot be specified at company- code level but are always valid for all company codes.

How the First Accounting Clerk Changes a Sensitive Field

The effect of these settings becomes apparent once somebody changes a sensitive field. In my example, the bank account from a vendor is updated via XK02 (change vendor master). After you save the new data, a pop-up screen appears (Figure 4).

Figure 4

Pop-up after changing a sensitive field

The help text (click on the question mark) provides the user with information on what is the matter (Figure 5).

A user might want to try to confirm the transaction without asking another person. However, if transaction FK08 (menu path Master records>Confirmation of change>Single or List) is executed by the same person that made the change, this leads to an error message (Figure 6).

Figure 6

Error message results

The long text explains that somebody else should confirm changes to the sensitive field (Figure 7).

Until this change is confirmed, others cannot display the proposed change with XK03. The system reacts with a message that Changes to the master record need to be confirmed. Also, the vendor is excluded from the payment run.

How the Unconfirmed Change Affects the Payment Run

The basic vulnerability with changes to vendors is related to payments. As long as changes are not confirmed, an invoice from a changed vendor cannot be paid. In the standard F110 payment run, all invoices due for payment that will not be included in the payment appear in the exception list.

If the responsible person double-clicks to see what is the matter, a pop-up message informs him or her that unconfirmed changes are in the master record (Figure 8).

Figure 8

Pop-up message in the payment run F110

This information appears also in the invoice details (Figure 9). A note is added stating, Unconfirmed change to master record.

Figure 9

Details of an unconfirmed change on a due invoice in the payment program F110

This method prevents unwanted changes in vendor master records. However, little or no use is made of the payment program in the case of customers. For sensitive changes to customers, the confirmation transactions, especially the confirmation list FD09, should be used.

How the Second Accounting Clerk Confirms the Change

Changes to sensitive fields can be confirmed through a list transaction (FK09, FD09) or for individual master records (FK08, FD08). Lists can be restricted through a selection screen (Figure 10).

Figure 10

Details of an unconfirmed change on a due invoice in the payment program F110

After you make your selection, you see a list of vendor/customer records that have been changed (Figure 11).

Figure 11

List of changed master records

Selecting one of the changed master records provides you with a sub-screen on which you can review the changes (Changes to sensitive fields button). The clerk authorized to confirm changes can reject or confirm the change (Figure 12). After confirmation, the traffic light in the list screen turns green.

Figure 12

Details screen to confirm sensitive changes

After changes have been confirmed, payments can be made again to this vendor. This way of working requires that the confirmation transactions (FK09, FD09) are executed daily. Alternatively, a company could use workflow to alert those authorized to confirm that a change to a sensitive field is made. Using workflow, you can represent the whole business process with all the people involved. If, for example, a bank account number is changed, then the system automatically informs the employee authorized to confirm the change. The employee receives a work item that can be processed directly from the R/3 inbox.

R/3 provides two standard reports to monitor and check changes to customer or vendor master records periodically. For changes in the customer master records, the menu path is Accounting> Financial Accounting>Accounts Receivable>Information system>Reports for accounts receivable>Master data> Display changes to customers. For changes in vendor master records, the menu path is Accounting>Financial Accounting> Accounts Payable> Information system>Reports for accounts payable>Master data>Display changes to vendors.

These reports provide a selection screen to select the range of vendors or customers (Figure 13). The result is a detailed list of all changes to customer or vendor master records. The report shows who made the change, and in case of a sensitive field, who confirmed it. See, for example, the change in the bank account details in Figure 14.

Figure 13

Selection screen for changes to vendor master data

Figure 14

Example of a reported change in the bank data for a vendor