Learning how to use this SAP feature
When it comes to paying our vendors, SAP gives us the choice of paying them directly or paying a different person (Alternative Payee), whose information is kept in the vendor master record. This function is offered to encourage flexible payments so that, upon your vendor’s request, you, the buyer, can send the payment directly to the party that your seller owes money.
If a vendor has an alternative payee on file, the system will always pay the alternative payee rather than the original vendor. This is because the payment programme will always have access to the alternate payee’s name, address, and bank account information.
The vendor master details are split into two portions in SAP when we create a new vendor master record.
- In general
- Data for Company Code
Now, it’s crucial to keep in mind that an alternative payee can be described using both general and company code data. The alternative payee mentioned in the company code area takes precedence if you specify an alternate payee in both areas.
Screen 1 below shows the General Section of the vendor master record, which allows for the maintenance of an alternate payee. We can see that alternate payee “1014” has been designated for vendor “5200.”
To view the images below in greater detail, click on them.
Picture 1
XK03 T-Code
The Company Code Area, seen in Screen 2 below, allows for the definition of an alternate payee. We can see that alternate payee “3510” has been designated for vendor “5200.”
Picture 2
XK03 T-Code
As a result of the preceding rationale, the system will always choose the alternative payee that is established at the Company Code Level when alternative payees are defined at both the General and Company Code Levels.
This understanding is supported by the screenshots that are shown below:
We generate a FI Invoice for 580 EUR with a vendor total of 5200. The key point to take away from this snapshot is that although the SAP system has chosen vendor 5200, the bank account information actually belongs to the alternative payee, which is kept in the vendor master for vendor 5200 under the company code area.
The alternate payee ‘1014’, which was listed in the vendor master’s General Data category, was not chosen by the system. The system will only choose Alternative Payee ‘1014’ if I create this invoice with any company code other than 1000.
Picture 3
FB60 T-Code
displaying the banking information for alternative payee “3510,” which is listed under vendor “5200”‘s business code. We can observe that the vendor invoice raised above for vendor 5200 properly displays the bank key, bank account number, and bank name.
Display 4
XK03 T-Code
The sample invoice’s payment proposal is now being run.
Scanner 5
F110 T-Code
We observed that vendor 3510, who was present as an alternate payee for vendor 5200, was the recipient of the payment.
Picture 6
Payment Output from T-Code F110
Let’s learn what a “Alternative Payee In Document” is now that we have a better understanding of what alternate payees are and how they work.
Alternative Payee In Document is a field that may be found in the Vendor Master’s general data selection criteria. If this feature is enabled, payments might theoretically be issued to anyone, regardless of whether they are included in the Vendor Master. The invoice processor now has the power to modify the payment information that the system has pre-selected for payment.
For simplicity’s sake, I’ll use the same vendor, 5200, but this time I’ve only made one configuration change: I’ve enabled the “Individual Spec” field under the “Alternative Payee In Document” section for vendor 5200.
7th screen
XK03 T-Code
made a new 700 EUR invoice for the vendor’s 5200. Nothing has changed from the last invoice we handled up until this point. The alternate payee “3510” that is specified in the vendor master’s bank data is still chosen by the system. The document number for the invoice that we just saved is “1900000002.”
Dispatch 8
FB60 T-Code
Now, we run T-Code FBL1N to look for document 1900000002, which was produced by Vendor 5200. Please note the empty area that is highlighted in the picture.
Display 9
FBL1N T-Code
Now, an alternative payee for this invoice can be “Individually Set.”
10th screen
FBL1N T-Code
Any person’s bank information can now be input on this page, and when the payment proposal is executed, money will be transferred to the account listed below. The payment in this instance will be made to sample bank account “778899.”
Display 11
The information that the invoice processor manually entered into the “Individually Set” section is filled in after the new banking details are saved.
Here, it’s important to note that the system always chooses the payee who is most specific. This indicates that a payee’s entry in a document takes precedence over any payees listed in the master record. This will even replace the alternate payee that was previously being chosen by the system and is listed in the vendor master at a company code level, in our case “3510.”
Display 12
The payment proposal for the example invoice is now being run. We can see that the payee that was chosen is the one we entered as a fictitious payee.
Display 13
The payment is sent to the bank account “778899,” which we specifically specified in the document, as shown in the payment proposal output snapshot below.
As a result, in this instance, the payment was processed to the fraudulent payee rather than any of the alternative payees listed in the vendor master.
Dispatch 14
Considering what you just read, you might want to audit your vendor master to see if any vendors have “Alternative Payee In Document” enabled.
Extract Table LFA1 and look at the “XZEMP” field. If this field has an X, it signifies the vendor has “Alternative Payee In Document” enabled.
Dispatch 15
Figure LFA1
The next step is to determine if someone has taken advantage of this vulnerability in your system if you have located vendors who permit alternate payee in document.
BSEG Extract Table
The LFA1 table’s list of all the suppliers should be the input parameter. Next, search for the field labelled “XCPDD” and apply the filter as = X. This will provide you with a list of all papers on which the invoice processor manually inserted payee information.
Dispatch 16
Figure BSEG
Because we personally added the payee details in the document, document 1900000002 that we processed above is tagged as “X” under field “Individually Set” (Technical Name “XCPDD”).
Dispatch 17
Now, execute T-Code FBL1N to access the document, then click on Document Modifications to view the precise changes made by the invoice processor.
Dispatch 18
FBL1N T-Code
The New and Old values can then be contrasted.
Dispatch 19
What is a “Permitted Payee” now that we have a better understanding of “Alternative Payee” and “Alternative Payee In Document”?
A authorised payee is someone you specify in the vendor master who can receive a lawful payment, as implied by the phrase “permit.” When opposed to a “Alternative Payee In Document,” this is considerably different because payments here can only be made to a certain Predefined Vendor and not to any other party.
I’ll give you an example to help you comprehend this. Vendor 5200 in this instance is allocated as a permitted payee to Vendor 3101.
20th screen
Now, the system automatically selects the information of vendor 3510 when the invoice processor punches an invoice against vendor 5200. This behaviour is acceptable because this is how the system should operate.
Dispatch 21
Therefore, the approved payee use-case is now that the invoice processor can alter the payee details during invoice creation, but only to those that are pre-configured in the vendor master for that particular vendor.
Dispatch 22
In this instance, there are only two sources to whom the payment can be handled.
i) The alternate payee designated for vendor 5200, vendor 3510, which the system has been choosing up to this point.
ii) The “Permitted Payee” 3101 that the invoice processor can choose if he decides he does not want the payment to go to the alternative payee, which is vendor 3510
Once chosen, we can see that the invoice has been updated with the payee information.
Dispatch 23
The screenshot below demonstrates how the payee information for vendor 3101 is correctly reflected on the invoice screen above.
Dispatch 24
The following considerations should be kept in mind when working with Permitted Payees:
You must first enable the “Individual Spec” (XZEMP), which is essentially the alternative payee in document field, before you may add a permitted payee to a vendor. You cannot add a permitted payee to the vendor before that point.
Once changes have been made, retain the field “Alternative payee in document” (XZEMP) as display or on suppress and remember to alter the setting back. Failure to do so will result in the alternative payee in the document remaining active, allowing payments to be made to anyone, as shown in the blog post above.
Configuring the system
All done and dusted The vendor master’s “Alternative Payee In Document” setting is crucial since enabling it provides the processor absolute authority to edit invoices. In my opinion, this parameter should be set to suppress in order to prevent unintentional activation.
The Screen Layout for merchants can be altered to change this.
The following steps should be followed: SPRO->Financial Accounting New->Accounts Receivable and Accounts Payable->Vendor Accounts->Master Data->
Establish screen designs for vendors
The alternate payee that is maintained in the vendor master is referred to in the entry labelled “Alternative Payee Account.” Depending on your business needs, this field is typically set to either optional entry or display.
To prevent any unauthorised payments from leaving the company, the field that reads “Alternative Payee In Document” should be set to suppress.
Dispatch 25
Thank you for reading my site, I appreciate it. I sincerely hope you will make excellent use of the knowledge I’ve provided and that it will aid in enhancing the information security measures in your company. Please let me know if there is anything I missed, as a good auditor is constantly learning.