Within sales and distribution (SD) you can assign several partner functions to the customer account. The partner function can be used for several purposes within SD. The partner function payer is used for financial posting of the financial sales invoice; the payer is used as the customer account in the posting. Figure 1 shows a simple example of how this looks in the SAP system. The transaction used is VD02, and you can see that there are three partner functions: sold-to, bill-to, and payer. The sold-to function is the organization buying the goods or services, the bill-to function is the person to whom the invoice is sent, and the payer is the organization that pays the invoice.

Figure 1

An example of partner functions in the customer master

When an invoice is posted for sold-to 72471, the financial invoice is posted against customer 61556. Therefore, analyzing the open items in the AR module of SAP is difficult. For example, when customer 72471 calls with questions about the invoice you need to be aware that the invoice is posted under customer number 61556. Another example is when the AR department wants to analyze the payment behavior of customer 72471, this analysis is difficult because it is part of the payment behavior of customer 61556. To improve this situation there are a couple of possible solutions. This article mainly focuses on the head office functionality of the SAP system, but also alternative solutions are briefly discussed. Head office functionality is part of AR and AP.

Head Offices and Branches

One of the ways to improve the analysis of the open items in AR is to use head offices and branches.

The basic principle is that you define the invoice recipients as head offices and the sold-to parties as branches. In the SAP system branches and head offices are existing customer accounts. You actually do not classify a customer as a head office, but you only define customers as branches by assigning a head office to these customer accounts.

In Figure 2 you can see how this looks. Because this time I look at the financial customer master, the transaction code used is FD02. On the Account Management tab of the customer, I enter customer 61556 in the head office field. After I save this change, the customer 72471 is automatically defined as a branch and implicitly customer 61556 as a head office. Customer 61556 can serve as a head office for more than one branch.

Figure 2

Customer 72471 is automatically defined as a branch

Standard SAP functionality is already using branch information in the background. So if you don’t use the head office field in the customer, the SAP system fills the branch in the financial posting of the sales invoice anyway. The field branch is filled with the value of the business partner Sold-to of the sales order. In Figure 3 you can see the line item detail of the financial sales document and on the customer line item you can see that the branch is automatically filled.

Figure 3

Branch information in the financial document

Therefore, there is apparently no need to enter the head office in the customer master data. However, there is one main reason why I recommend that you fill in the head office. When you fill in the head office, transaction FBL5N is much more user-friendly for analyzing customer line items.

Transaction FBL5N

Figure 4

The warning in transaction FBL5N

If you want to see only the items posted on customer account 72471, you have to deselect the indicator called Also list line items from head office. This functionality of transaction FBL5N doesn’t work if you select more than one customer account. Therefore, it is only useful if you restrict the selection to exactly one account.

Other Effects When You Fill In the Head Office

Filling in the head office affects the SAP system in other ways. For example, consistency check, dunning, credit management, and customizing are all influenced by changes to the head office.

Consistency Check

When you enter the head office in the customer master, SAP automatically checks that you use the same customer account number as for the business partner payer. Conversely, when you change the business partner payer, SAP checks it with the value for head office. If these values are not consistent, SAP produces a warning. Figure 5 shows how this warning looks in SD. The reason for this warning is that sales invoices are booked on the payer account, whereas postings made directly in finance are booked on the head office account.

Figure 5

The warning concerning inconsistency between Payer and Head Office

Dunning

The use of branches also has an impact on the dunning process. If you want to dun the branch, it is necessary that you also define the dunning procedure in the master data of the head office. However, the dunning notices are sent to the head office. It is also possible to send the dunning notices to the branches. In that case you need to set the Decentralized processing indicator in the customer master of the payer (Figure 6).

Figure 6

The decentralized processing indicator in the customer master

The standard SAP dunning form doesn’t split the dunning form per sold-to. If you want to send a letter per sold-to, you must indicate in the dunning recipient that the dunning recipient is the payer. The field for the dunning recipient is also visible in Figure 6, but it is blank.

Credit Management

When you use credit management in SD, the check is made against the sales value of the Sold-to. Therefore, any outstanding receivable amounts are not taken into consideration as the receivables are posted on the payer account. This may affect your credit management functionality, such as blocking sales orders.

Customizing

The use of head office and the indicator for decentralized processing requires that these fields are available for input. This is controlled in the settings for the customer accounts group. These settings can be maintained with transaction OBD2.  This transaction can also be reached via the IMG menu path Financial Accounting  > Accounts Receivable and Accounts Payable > Customer Accounts > Master Data > Define Account Groups with Screen Layout (Customers).

After starting the customizing transaction, you see an overview of the available customer account groups. Select the one you want to maintain by double-clicking it. You then see the details of the account group (not shown in this article). Double-click the line for Company code data in the field status part of the screen (not shown in this article). Now you see the overview screen for the field status group maintenance (not shown). Double-click the group Account management. You see the screen shown in Figure 7. On this screen you have to set the field for Head office to optional.

Figure 7

Field status group maintenance — Account Management

For the decentralization indicator you have to return to the overview screen for the field status group maintenance and double-click the Correspondence group. On the screen you then must set the field called Local processing to optional. Because of its similarity with the Head office field, this is not shown in this article.

Other Ways to Handle Head Office and Branches

An alternative way of managing different payers or sold-tos is to define an alternative payer in the customer master of the sold-to. In the SD part of the customer master, define the sold-to also as payer, but in the financial data you define an alternative payer. Figure 8 shows that for customer 72471 the alternative payer 61556 is defined.

Figure 8

Alternative payer in the customer master

Using the alternative payer is only useful when you use automatic collection because the payment program automatically uses the alternative payer instead of the customer. For the rest the customer is behaving as if there is no alternative payer. The advantage is that in credit management the total open receivable amount of the payer is not taken into consideration. Rather, the open amount for the Sold-to is taken into consideration. The disadvantage is that people in the sales area are not always aware that the invoices are to be paid by a different partner.

Kees van Westerop

Kees van Westerop has been working as an SAP consultant for more than 25 years. He has an MBA degree in mathematics and a degree in finance. Kees has been concentrating on the financial modules, especially in general ledger accounting, cost center accounting, and consolidation. He also has a great deal of experience with rollouts of kernel systems and integrating finance and logistics.

You may contact the author at keesvanwesterop@hotmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.