OTC-01

Control Description

Changes to key fields in the customer master table (such as bank details, tax indicators, and address data) take two people to complete; one to enter, and a second to approve.

Risk

One person acting alone could alter customer data or direct remittances to fraudulent bank accounts without oversight

Implementation Details

Implementation Details
Step 1: Configuration

• SPRO - IMG - >Implementation Details
Step 1: Configuration

• SPRO - IMG - > Financial Accounting->Accounts Receivable and Accounts Payable->Customer Accounts->Master Data->Preparations for Creating Vendor Master Data->Define Sensitive Fields for Dual Control(Customers)

•Action: Add the key fields you want to protect (e.g., Bank Account Number (Bank Account: KNBK-BANKN), Bank Key: KNBK-BANKL, Terms of Payment: KNB1-ZTERM etc)

Step 2: Day-to-Day Operations & Process Flow
Once configured, the day-to-day workflow follows a strict multi-step process:

• The Entry (Maker Action):

◘User A accesses a customer master record and alters a designated sensitive field—for instance, changing the bank account number
◘Upon saving, the system issues a warning message indicating that the changes require confirmation. The modifications are written to the database, but a temporary payment block is automatically placed on the customer account.

• The Review and Approval (Checker Action):

◘User B opens the confirmation app or transaction (such as Confirm Customer List / transaction FD08 / FD09
◘ User B can choose to Confirm or Reject the changes. If Confirmed, the temporary payment block is automatically lifted, and normal business operations resume. If Rejected, the system rolls back or flags the modification, maintaining baseline security.

Test Procedures

A) Test of Design (ToD)
• Inspect the system configuration via the SPRO path:
SPRO - IMG - > Financial Accounting->Accounts Receivable and Accounts Payable->Customer Accounts->Master Data->Preparations for Creating Vendor Master Data->Define Sensitive Fields for Dual Control(Customers)

• Verify that key risk-relevant fields (e.g., Bank Account Number KNBK-BANKN, Bank Key KNBK-BANKL, and Terms of Payment KNB1-ZTERM) are explicitly flagged as sensitive in the control table

B) Test of Operating Effectiveness (ToOE)
• Objective: Test that the configured dual-control mechanism operates as intended in practice, preventing unapproved changes from taking effect and successfully blocking payments until a second independent user approves the modification

• Test Steps:

◘ Entry (Maker Action): Log in as User A (Maker). Access a test customer master record (via transaction BP or XD02) and alter a protected sensitive field, such as changing the bank account number (KNBK-BANKN). Save the changes.

◘System Response Check: Verify that SAP issues a system warning stating that the customer changes have not yet been confirmed.

◘ Inspect the customer master record to confirm that a temporary payment block has been automatically applied to the account.

◘ Attempt to approve the change using User A's credentials to confirm that the system blocks self-approval.

◘ Approval (Checker Action): Log in as User B (Checker/Independent User). Open the confirmation transaction (FD08 / FD09) or the corresponding Fiori app (Confirm Customer List).