4-eye-prin­ciple for cri­ti­cal mas­ter­da­ta changes in SAP®

Changing masterdata for vendors is a process in SAP® just certain users should have access to. In addition to the possibility of restricting access to this area with the SAP® authorization concept, SAP® also provides an option to implement a simple 4-eye-principle for critical masterdata changes. As this turns out to be a bit hidden in the customizing, this blogpost has a closer look at that.

Changes of cri­ti­cal mas­ter­da­ta

The parts of vendor masterdata that are seen as critical are personal interpretation and dependent on the process within your organization. In most cases at least the fields with direct effect to outgoing payment flows are seen as critical, like: 

  • Bank account information (more than one field)
  • Alternative payees (available in general masterdata as well as in company code specific data).
  • Indicator of using alternative payees for that vendor on document level.

If the user has appropriate authorizations, he can – without any additional security checks – easily change these critical fields. This can lead to serious problems during the process if something was entered incorrect, or simply allow misuse if the change has been done by purpose.

Cus­to­mi­zing the 4-eye-prin­ci­ple

The customizing of an SAP® system provides a simple process to maintain a 4-eye-principle for vendor masterdata changes. In this specific case, 4-eye-principle means, that a second SAP® user has to review and authorize changes that a user made in the system.

You can access these setting via the customizing worklist (Transaction “SPRO”). Click your way through that menu tree and the items “Financial Accounting”->”Accounts Receivable and Accounts Payable”->”Vendor Accounts”->”Master Data”->”Preparations for Creating Vendor Master Data”->”Define sensitive fields for dual control (vendors)”.

Picture 1 - Customizing Menu Tree SAP

Within this customizing screen the user now can easily add fields, which are seen as critical, to the 4-eye-principal (e.g. the “Alternative payee” on company code level, field is named LFB1-LNRZB).

Picture 2 - Defining critical fields

If you do not have access to the customizing transaction SPRO, but you want to see what fields are defined and activated for the 4-eye-check, it is possible to look this up in table T055F.

Con­se­quen­ces when chang­ing mas­ter­data

If an user with proper access changes data of a vendor by modifying a field that is declared as critical, SAP® creates an annotation for that record and requests an approval by a second user.

Picture 3 – Change message transaction XK02

The approval of the masterdata modification is done with transaction FK08 (Single confirmation) or FK09 –(List Confirmation). Doing this the user can restrict the list to just those changes he is able to confirm, as he cannot approve for his own changes of course.

Picture 4 –Confirmation Vendor Changes

The consequences for the Purchase-to-Pay process are as follows:

  • New changes for that vendor account cannot be performed. The system creates a message and requests a confirmation of the old changes first. (Abb. 5)
  • Purchase orders for that vendor can be processed without any limitation.
  • Financial postings can be done for that vendor as well (even manually posted payments).
  • The vendor will be listed as an exception during the proposal run of the automatic payment run.

Picture 5 – Message when trying to access an already blocked vendor with transaction XK02

Picture 6 – Exception list payment run proposal

Picture 7 – Exception detail payment proposal

The effects shown above highlight two aspects in my opinion:

  1. It only makes sense to use this functionality for fields and data that directly effects the automatic payment run of SAP® (e.g. bank account, payment methods), as it does not affect other process steps anyway.
  2. It is highly recommended that the automatic payment run including payment proposal is used consequently within SAP®. A manual clearing of invoices outside of SAP® with a posting in the system afterwards (a so-called “Manual Payment”) stays a high risk within the process.

Im­pact on the da­ta

Interesting to know for data analysts who want to systematically audit the blocking and confirmation of vendors, is the fact, that SAP® takes minutes of that. This is done in global vendor master data table LFA1 by using the field CONFS. It is populated with the value of „1“, if such a block exists. The additional fields UPDAT and UPTIM provide exact information about day and time of the last change or confirmation.


It is obvious that the 4-eye-principal that SAP® has implemented here is only rudimentary. Nevertheless it is a starting point to at least have critical changes confirmed by a second person. The simplicity this control can be implemented within SAP® enables all companies to introduce it in a very quick and low-price approach.

Comments (0)
Be the first who comments this blog entry.
Blog login

You are not logged in. Please log in to comment this blog entry.

go to Login