H2.8.1 User Documentation AR

Global Process Management System
User Documentation
Process: F-6 Accounts Receivable End-User Documentation Accounts Receivables
Approval Date: 01.08.2006 Review Date: 01.02.2007
Written By: Guillermo Atencio Approved By: Andreas Hehle
P 1 I 119
END-USER DOCUMENTATION
ACCOUNTS RECEIVABLES
CHAPTER 3
Change log
Content Type of change Update for

Collection process Section added H2.4
Dunning block Additional detail added H2.5
Bad debt provision Concept change for local and group valuation. H2.5
Valuation area changed. Update of process.
Cheque process Add chapter regarding cheque treatment H2.5
Cross company Section added H.2.8.1
processes
Valid on day of print 13/07/2006 09:12:00 - For internal use only -
9494 Schaan Liechtenstein
Process: F-6 Accounts Receivables End-User Documentation Accounts Receivables
P 2 I 119
TABLE OF CONTENTS
CHANGE LOG...................................................................................................................1
3.1 Customer Master Data............................................................................6

3.1.1 Account Groups Overview.................................................................................6
3.1.2 Partner functions...............................................................................................8
3.1.3 Customer Master Record segments................................................................13
3.1.3.1 General data............................................................................................................ 13
3.1.3.2 Company code data................................................................................................. 13
3.1.3.3 Sales and distribution data.......................................................................................14
3.1.4 Customer master record creation....................................................................14
3.1.5 Maintain Customer Master Record separately for the sales area...................14
3.1.5.1 General data............................................................................................................ 15
3.1.5.2 Sales data................................................................................................................ 15
3.1.5.3 Billing document....................................................................................................... 16
3.1.6 Maintain all segments of Customer Master Record at the same time (“Maintained
centrally”).........................................................................................................19
3.1.6.1 General data............................................................................................................ 20
3.1.6.2 Sales data................................................................................................................ 22
3.1.6.3 Company data......................................................................................................... 23
3.1.6.4 Interest calculation................................................................................................... 26
3.1.6.5 Reference data........................................................................................................ 27
3.1.6.6 Payment transactions.............................................................................................. 28
3.1.6.7 Payment data........................................................................................................... 28
3.1.6.8 Payment advice notes.............................................................................................32
3.1.6.9 Correspondence...................................................................................................... 33
3.1.6.10 Insurance................................................................................................................. 39
3.1.7 Maintain Customer Master Record separately for the finance area................41
3.1.8 Create with reference......................................................................................41
3.1.9 Create an already available customer master record for a new sales area....41
3.1.10 Displaying a customer master record..............................................................41
3.1.11 Changes in a customer master record............................................................42
3.1.12 Displaying changes in a customer master record............................................43
3.1.13 Comparing customer master records..............................................................44
3.1.14 Blocking a customer master record.................................................................44
3.1.15 Blocking a Customer Account of a Business Partner......................................45
3.1.16 Unblocking Customer Master Records............................................................45
3.1.17 Deleting a customer master record.................................................................45
3.1.18 Head offices and branches..............................................................................47
3.1.18.1 Link between Branch Accounts and Head Office Account.......................................47
3.1.18.2 Line Item Display..................................................................................................... 48
3.1.18.3 Correspondence...................................................................................................... 49
3.1.18.4 Local Payment......................................................................................................... 50
3.1.19 One-time customers........................................................................................51
3.2 FI Invoices/Credit Memos.....................................................................53

3.2.1 Overview......................................................................................................... 53
P 3 I 119
3.2.2 Procedure........................................................................................................54
3.2.3 Closing the document......................................................................................60
3.3 Accounts Receivable Payment Application.......................................63

3.3.1 Overview......................................................................................................... 63
3.3.2 Payment – clearing and payment differences.................................................63
3.3.2.1 Concept................................................................................................................... 63
3.3.2.2 Tolerance groups..................................................................................................... 63
3.3.2.3 Partial and Residual Payments................................................................................65
3.3.2.4 Overpayment........................................................................................................... 66
3.3.3 Payment methods...........................................................................................69
3.3.3.1 Bank payments........................................................................................................ 69
3.3.3.2 Direct Debit (LSV).................................................................................................... 71
3.3.3.3 Cheque.................................................................................................................... 72
3.3.3.4 Credit Cards............................................................................................................. 75
3.3.3.5 Lockbox................................................................................................................... 75
3.3.3.6 Bill of Exchange....................................................................................................... 75
3.4 Dunning Process...................................................................................77

3.4.1 Overview......................................................................................................... 77
3.4.2 Dunning Block.................................................................................................78
3.4.2.1 Dunning Block at Customer Account Level..............................................................79
3.4.2.2 Dunning Block at Invoice Level................................................................................79
3.4.2.3 Transaction Behavior upon removal of dunning block.............................................80
3.4.3 Dunning Procedure.........................................................................................81
3.4.4 Dunning Process.............................................................................................82
3.4.5 Generate Dunning...........................................................................................83
3.4.5.1 Process flow............................................................................................................ 83
3.4.5.2 Work flow................................................................................................................. 84
3.4.5.3 Selection criteria for exemptions from dunning........................................................86
3.4.5.4 View Dunning History............................................................................................... 86
3.5 Collection Process................................................................................87

3.5.1 Collection Process Overview...........................................................................87
3.5.2 Establishing Delinquency................................................................................87
3.5.3 Due Date Analysis...........................................................................................87
3.5.4 Dunning Procedure as a Collection Tool.........................................................88
3.5.5 Accounts Receivable Reports.........................................................................89
3.5.6 Collection Process...........................................................................................91
3.5.7 Collection Credit Master Data..........................................................................92
3.5.7.1 Collection Credit Master Data..................................................................................93
3.6 Bad Debt Reserve.................................................................................94

3.6.1 A/R Trade - Classification................................................................................94
3.6.2 Collectible accounts receivable.......................................................................95
3.6.3 Reclassification of Doubtful accounts receivable............................................96
3.6.4 Calculation of Bad Debt Reserve....................................................................98
3.6.4.1 General Overview.................................................................................................... 98
3.6.4.2 The valuation......................................................................................................... 100
3.6.4.3 SAP R/3 system valuation areas...........................................................................100

P 4 I 119
3.6.4.4 SAP R/3 system bad debt reserve calculation.......................................................101

3.6.5 Reporting in BW............................................................................................103
3.6.6 Write-off’s of Accounts Receivable................................................................103
3.6.7 Residual item.................................................................................................104
3.6.8 Resetting of cleared items.............................................................................104
3.7 Hilti Center Sales.................................................................................105
3.8 Cross Company processes................................................................105

3.8.1 Customer Sales via CW of different MO (GPMS-Scenario 2323.01)............105
3.8.2 Replenishment between 2 plants of different MOs (GPMS-Scenario 2263.01)105
3.8.3 Errorhandling Idoc.........................................................................................105
3.9 Period Closing A/R..............................................................................106

3.9.1 Overview....................................................................................................... 106
3.9.2 Review unbilled deliveries.............................................................................106
3.9.2.1 Release Invoice List............................................................................................... 106
3.9.3 Billing documents blocked for Accounting.....................................................107
3.9.4 Unsolved incoming payment differences.......................................................107
3.9.5 Suspense account.........................................................................................108
3.9.6 Doubtful accounts and bad debt reserve calculation.....................................108
Information Systems..............................................................................................109
3.9.7 Information Systems......................................................................................109
3.9.8 Accounts Receivable Information Systems...................................................109
3.9.9 Information Systems......................................................................................110
3.9.9.1 Customer Balances................................................................................................110
3.9.9.2 Customer Items..................................................................................................... 111
3.9.9.3 Master Data........................................................................................................... 112
3.9.10 Report Transaction Navigation......................................................................113
3.10 Employee sales...................................................................................114
3.11 Instant message..................................................................................114
3.12 PO verification.....................................................................................115
3.13 Bounced cheques...............................................................................115
3.14 UID-Nr. Check......................................................................................115
3.15 D&B interfaces......................................................................................115

P 5 I 119
CURRENT CHANGES
Chapter Comment Release

Hilti Center Sales Added Chapter about Cash Journal H2.1
Residual item Added to the AR documentation H2.8.1
Resetting of cleared items Added to the AR documentation H2.8.1
Employee sales Added to the AR documentation H2.8.1
Instant message Added to the AR documentation H2.8.1
PO verification Added to the AR documentation H2.8.1
UID-Nr. Check Added to the AR documentation H2.8.1
D&B interfaces Added to the AR documentation H2.8.1

P 6 I 119
3.1 Customer Master Data
3.1.1 Account Groups Overview
A master record depends on the account group.

Following account groups are defined and available:
Table 1: Account Group with description
Account From number To number Description

group
CPD CPD_A00000 CPD_ZZZZZZ Walk in customer (e.g. CPD_AT2763)
ZHIL All Hilti internal customers (e.g. HAG, IVV,
Plants, MO’s) Frango numbers
ZVEN All Hilti external vendors (e.g. Allied vendors,
DP-vendors, MRO-vendors, national
vendors...)
ZPLA All Hilti internal ship from addresses (external
alphanumeric number)
ZASS ASSET ASSET9 Asset
0001 10000000 99999999 Sold to party
0002 10000000 99999999 Ship to addresses
0003 10000000 99999999 Payer
0004 10000000 99999999 Bill to address
0005 10000000 99999999 Prospect
0006 1 999 Competitor
0012 10000000 99999999 Hierarchy node
ZHTS Hilti TS Van
ZCON 10000000 99999999 Construction Project
ZDCU 10000000 99999999 Denied customer
ZFTC 10000000 99999999 First time customer
Z005 100000 2899999 MSA Prospect
Z006 100000 2899999 MSA Construction Project
ZAG1 10000 14999 Hilti Agents (ship to party)
ZAGT 10000 14999 Hilti Agents
ZARG 10000000 99999999 Consortium/ARGE
Account group ZCPD and ZHIL will be created and then maintained centrally by Hilti AG!

P 7 I 119
For account group ZVEN there is a difference between local vendor and global vendor. Each
vendor, which is a direct productive (DP) vendor or delivers more than one Hilti Market
Organisation has to be created centrally in Hilti AG.
A company deals with different natural and legal persons during business transactions: A
customer orders goods from your company. All roles, a natural or legal person can assume,
are represented by business partners in the SAP R/3 System. You enter data on business
partners with whom your company has a business relationship in master records. Master
records contain all data necessary for processing business transactions. This is known as
master data. Due to the importance of the accuracy of the master records data for the
organization for an adequate and timely processing of the business transactions, this chapter
covers customer master record in regards to the process of Billing and Account Receivables.
A business partner can be a customer and a vendor at the same time if, for example, your
customer also supplies goods to you. In this case, both a customer master record and a
vendor master record must be created for the business partner. You would then have to create
a link between the master records by entering the vendor number in the customer master
record and the customer number in the vendor master record.
A customer master record has three segments:
1) A segment with General Data on the client level. This data can be accessed throughout
the whole organization.
2) A segment with Company Code Specific Data on the company code level.
3) In addition, because the sales and distribution department stays in contact with a customer
and has to know specific data about this customer, a Sales Area segment can be created
for each customer.
Picture 1: Customer master record segments

P 8 I 119
For customers whom you only supply once or rarely, you can create a special customer master
record, the master record for "one-time accounts". In contrast to other master records, no data
specific to a single customer is stored in the one-time master record, since this account is used
for more than one customer. The customer-specific entries such as address and bank details
are not entered until the document for the transaction is entered into the system.
A customer master record:
 Is the only master data element for A/R

 Must be created for all company codes that wish to sell to that customer
 Share the same general data for all company codes
 Credit management history is a subsection of the master record, where the particulars
of the customer’s credit is managed
 Sales data and line items can be accessed directly from the master record.
3.1.2 Partner functions
You assign partner functions when you create a master record for a business partner. The
diagram shows partner functions, which are used for sales and distribution processing within
Hilti:
SP sold-to-party
SH ship-to-party
Business
TS Sales Rep. partner
BP bill-to-party
PY Payer
Picture 2: Partner functions
Sold-to Party
Contains data on sales, such as the assignment to a sales office or a valid price list
Ship-to Party
Contains data for shipping, such as unloading point and goods receiving hours
Bill-to Party
Contains the address and data on document printing and electronic communication
Payer
Contains data on billing schedules and bank details

P 9 I 119
TS
Sales representative assigned to the customer
In most cases, the company or person who places an order can be the same company or
person (e.g. legal entity) who receives the goods and the invoice and pays. Because this
customer assumes all partner functions, you create one master record for the customer. You
create a customer master record for the sold-to party in which you enter data required for the
other partner functions. On these cases, customer number for all respective partner functions
remains a unique number.
SAP standard customer account number assignment
Internal customer account # = SD partner function
Functions in Sales Area:

Arakawa AG
Buchsstrasse
Derived PY - Payer is 10000031
SP - Sold-to is 10000031
Wien SH - Ship-to is 10000031
automatically BP - Bill-to is 10000031
Cust# 10000031
As long as the same legal entity is playing all SD partner functions
Template_ddmmyy
3 Name
GPD/H2 Project
Picture 3: Customer account assignment
The partner determination procedure specifies the partner functions that are allowed or
mandatory for processing a particular business transaction (e.g. a sales order) as well as the
layout of the documents to be sent out to the customer. The customer account number in the
document layout on these cases will remain the same, as example shows:

P 10 I 119
SD Partner Functions: One legal entity = One customer account #
Customer account # on customer document layout

Assigned automatically by the system depending on the SD partner function the legal entity is
playing
As standard:
Quote - sold-to
Order - sold-to
Cust# 10000031 All Cust omer documents layout used the
Delivery - ship-to same customer account number:
Invoice - payer Cust# 10000031
Dunning Letter - payer
Cust. Statement - payer
Templ ate_d dmmyy

4 Na me
GP D/H2 P roj ect
Picture 4: Customer account assignment – customer playing all business partner

roles
However, in some cases, a subsidiary office can place an order and its head office can pay the
invoice. In this case, you divide partner functions among the different offices. You need a
corresponding number of customer master records. In one master record you enter, for
example, the address of the sold-to party for correspondence, in the other, the address of the
ship-to party for delivery.
You establish a link between the partner functions in the customer master record of the sold-to
party by entering the customer number of the respective partner functions. On these cases the
customer will have as many numbers for customer master records as many partner functions
the customer is playing. For example:

P 11 I 119
SD Partner Functions: Example - More than one customer account #
Arakawa 1
Test Branch Street
Arakawa AG Wien
Buchsstrasse Cust# 10000120
Wien Functions in Sales Area:
SP - Sold-to is 10000120
Cust#
PY - Payer is 10000031
10000031 SH - Ship-to is 10000120
BP - Bill-to is 10000120
Z1- Primary TS is 10002
SP - Sold-to is 10000031 Arakawa 2 Arakawa 2 Site 1
PY - Payer is 10000031 Test Branch Street SH - Ship-to is 10000122
SH - Ship-to is 10000031 Feldkirch
Z1- Primary TS is 10002 Cust# 10000121

Arakawa 2 Site 2
Might be one legal entity, SP - Sold-to is 10000121
PY - Payer is 10000031 SH - Ship-to is 10000123
e.g. KA SH - Ship-to is 10000121
Z1- Primary TS is 10002
Template_ddmmyy
3 Name
GPD/H2 Project
Picture 5: Customer account assignment – customer playing more than one

business partner role
For a better understanding how the business partner determination affects the customer
account number and document layout, a description of the document flow of some of these
documents is shown bellow:
Order Doc. Flow & SD Partner Functions in Example
Order Entry Credit Check Delivery Invoicing
Transaction VA01 VKM1 VL01N VF01
Entered 10000120
Customer Sold-to
Derived automat.
Internal Cust. 10000120 10000031 10000123 10000031

Account # Ship-to Derived automat. Payer Ship-to Payer (open items)
10000031
Bill-to (invoice)
Document Delivery
Sales Invoice
output note
order
Template_ddmmyy
6 Name
GPD/H2 Project
Picture 6: Customer account assignment – document flow

P 12 I 119
For Hilti customer account number is “sold-to-party” account number.
Customer account number
Customer account number should be used in document layout
Customer Account Sold-to-party All CRM documents

1) number
2) Include additional text field in CRM document depending on the different SD partner function
Different payer Different Ship-to
Arakawa 1 Invoice Arakawa 2 Site 2 Delivery

Test Branch Street
Test Branch Street
Feldkirch Customer account number: 10000121
Wien Customer account number: 10000120
Ship-to Reference number: 10000123
Payer Reference number: 10000031
Template_ddmmyy
7 Name
GPD/H2 Project
Picture 7: Customer account number – sold to party

P 13 I 119
3.1.3 Customer Master Record segments
3.1.3.1 General data
General data is independent of company code, sales area, and purchasing organization and is
therefore valid for business partners for all company codes, all sales areas, and all purchasing
organizations. It includes:
 Company name
 Address
 Telephone number
General data is not limited to information used by both Financial Accounting and Logistics. The
unloading point, for example, is unique for a customer and is only relevant for Sales and
Distribution. However, because it is not part of the sales and distribution organization of your
company, it is not sales and distribution data. It is general data.
If you edit a master record using the customer or vendor number without specifying a sales
area, a purchasing organization, or a company code, the system displays only general data
screens.
The department that creates the master record for a business partner also enters general data.
If Financial Accounting creates the master record, it must also enter general data, such as the
address. When Logistics then enters data, the general data for the business partner exists.
Logistics can display the general data.
3.1.3.2 Company code data
The company code data is defined separately for individual company codes. This data is only
relevant to Financial Accounting, and includes:
 Account management data

 Payment transaction data
 Correspondence data (Dunning)
 Insurance data
If you edit a master record, you must specify the customer number and company code to
access the screens containing company code data.
You can only invoice a business transaction if the data on the payer partner function is entered
in the Financial Accounting view.

P 14 I 119
3.1.3.3 Sales and distribution data
A sales area is a specific combination of sales organization, distribution channel and division.
The data for one customer can differ for each sales area, channel and division. This data is
only relevant to Sales and Distribution, and includes:
 Pricing data
 Delivery priority
 Shipping conditions
 Partner functions
If you edit a customer master record, you must enter the customer number and the sales area
in order to access screens containing sales and distribution data.
You can only process sales and distribution transactions, for example, a sales order, after
entering the sales and distribution data for a customer.
3.1.4 Customer master record creation
The system offers separate functions for creating and maintaining customer master records
depending on the requirements of the MO. Customer master records are used by both the
Financial Accounting (FI) component and the Sales and Distribution (SD) component. A
customer master record can be created and maintained either together or separately as
follows:
 Separately for the company code

 Separately for the sales area (order processing, shipping, and billing information
about the customer)
 Centrally for both the company code and sales area in one step
There are three different ways of processing master records since they are often created and
maintained by different departments. In some MO’s, accounting and sales personnel maintain
the general area together and their own areas separately. In other companies, customer
master records are maintained centrally.
It is easiest to create customer master records centrally to ensure that they are set up
correctly. However, in the case that SD creates their segment of the master record and then FI
creates their segment of the master record, report RFDKAAG00 can be run to identify
incomplete or duplicate master records to make the necessary corrections.
3.1.5 Maintain Customer Master Record separately for the sales area
To create a new customer master record separately for the sales area please refer to the
following BPP:
P 15 I 119
Transaction code: VD01

..\H2_Transactions_BPP\BPP_H20_VD01_Create_Customer.doc
Whenever a customer master record is created and maintained using this transaction code in
the SD module, you can enter only data that is relevant to Sales and Distribution, therefore
only access to general data and sales data screens will be possible.
Please refer to above mentioned BPP for further details on data entry.
3.1.5.2 Sales data
Please refer to BPP for transaction code VD01 for details on data entry on sales, shipping
conditions and partner functions. Further details in regards to the Billings & Accounts
Receivables process are mentioned bellow.
Billing and accounting information relevant to the customer is stored here in regards to special
types of billing, delivery and payment terms, account assignment and taxes:

P 16 I 119
Picture 8: Customer master record – sales area segment – Billing information
3.1.5.3 Billing document
 Subs. Invoice processing: Indicates if the invoices for manual post processing should be
printed out.
 Rebates: Indicates whether a customer may be granted a rebate
 Price determination: If the master record represents a node in a customer hierarchy, the
pricing indicator determines whether the node is relevant for pricing.
 Invoice dates: Identifies the calendar that determines the schedule of billing dates for the
customer. If, for example, a customer wants to consolidate the invoices you send out, you
can predefine the billing schedule in a calendar in the system. During billing, the system
automatically proposes the appropriate billing date from the calendar. Field is not used with
current release.
 Invoice list dates: Identifies the customer's factory calendar that is used during the
processing of invoice lists. An invoice list is a list of invoices (single or collective) that you
create for the customer either periodically or on predefined dates. The periods and dates
are defined in the customer's factory calendar.

P 17 I 119
 Incoterms: Specify certain internationally recognized procedures that the shipper and the
receiving party must follow for the shipping transaction to be successfully completed. For
example, if goods are shipped through a port of departure, the appropriate Incoterm might
be: FOB ("Free On Board"). You can provide further details (for example, the name of the
port) in the secondary Incoterm field: FOB Boston, for example. The following are a list of
the Incoterms available for Hilti:
Picture 9: Billing information – Incoterms types
Incoterms can also be specified or modified at item level once the sales order is being
entered in the system.
 Terms of payments: Key for defining payment terms composed of cash discount
percentages and payment periods. Terms of payment provide information for:
 Cash management
 Dunning procedures
 Payment transactions
Terms of payments must be specified for the customer at the moment of creation of the
master record. .
Please, note that master records have separate areas for maintaining payment terms in
Financial Accounting and Sales. You can specify different terms of payment keys in each

P 18 I 119
of these areas. When you then enter a business transaction, the application in question will
use the key specified in its area of the master record.
The following is an example of the available terms of payments in the system:
Picture 10: Billing information – payment terms
 Account assignment group: The system uses the account assignment group as one of
the criteria during the automatic determination of revenue accounts. The following account
assignment groups are available in the system:

P 19 I 119
Picture 11: Billing information – account assignment
 Tax classification: Specifies the tax liability of the customer, based on the tax structure of
the customer's country. You can use the tax classification to specify, for example, whether
a customer is liable for sales taxes, such as VAT or state sales taxes.
3.1.6 Maintain all segments of Customer Master Record at the same time
(“Maintained centrally”)
To create a new customer master record centrally when the Accounts Receivable functions are
shared please refer to the following BPP:
Transaction code: XD01
..\H2_Transactions_BPP\BPP_H20_XD01_Create_Custo_Complete.doc
Whenever a customer master record is created and maintained centrally, access is given to
general data company data and sales data. Creating a customer master record centrally
involves entering data for both accounting and sales in one step through the Sales and
Distribution (SD) application component.

P 20 I 119

Whenever customer master record is maintained centrally, in addition to the SD general data
entered about the customer, payment transaction (e.g. bank details) details may also be
created on one single step.
 Entering bank details: For each customer, you can specify as many banks as you require.
You need the bank details of a customer if you intend to use the payment program to
collect payment from your customer (for example, if you have automatic debit
authorization). To enter bank details in the customer master record, enter the bank country,
the bank key, and the bank account number in the general data area. For control
purposes, the system then displays the name of the bank.
 The fields Country and Bank key serve to clearly identify a bank in the SAP system. With
these keys you can enter further bank data, such as the address. When you enter your
customer's bank details, the system checks whether master data already exists for this
bank. If not, the system goes to the maintenance screen for bank master data.
There will be also the possibility in the next future to use a new functionality to update
automatically all Customer Bank’s Details in Customer Master. To performe this transaction
you need to have authorization in XD02 (change Customer Master) and in batch input session
(SM35).
The possibility starting from the bank statement using FEBA
See ..\H2_Transactions_BPP\BPP_H20_FEBA_Bank_Statement_Processing.doc
To upload all customer bank information using the following program
See
..\H2_Transactions_BPP\BPP_H20_Advance_Bank_Information_in_Customer_Master.doc
Advantages, when the update is done:

- the matching because of the bank statement is done faster then without the bank
information of the customer. The program to do the clearing is first looking for the bank
information and compares the bank statement bank information for a transaction and
the customer master. If the bank information is equal the open items are searched with
the reference. That saves time.
- legal steps can be taken more quick when the bank information is available
- change to direct debit payment method is easier

P 21 I 119
Picture 12: Customer master record – general area segment – Bank details
information
 Bank data and payment cards: If you want to change or add to the bank master data,
position the cursor on the appropriate bank and choose Bank data. The system displays
the dialog box for entering and maintaining master data. You can enter details about
customer’s payment cards under Payment cards.
 Alternative payer: In case bank collections are not to be made via the customer who owes
the receivables, account number of the customer for whom automatic payment
transactions are to be carried out can be assigned. The same applies to refunds of
payables. If you wish to enter an alternative payer, you must first create a customer master
record for the alternative payer. You also require the authorization of this alternative payer
to collect from his or her account by direct debit.
An alternative payer can also be entered in the document by indicating an address or bank
details, which differ from the master record, for automatic payment transactions for
postings to this business partner.
You can specify an alternative payer in both the general and the company code area of the
master data. If you specify an alternative payer in the general data, that alternative payer is
valid for the customer in all company codes. If you specify an alternative payer in both
areas, the specification in the company code area takes precedence.

P 22 I 119
In exceptional cases, it may be necessary to enter the payer only in the document. You
can choose this option by selecting the Payer in document indicator in the general data
area. When you enter a document, there is a field on the screen in which you can enter an
alternative payer. If this field is selected, the system displays a screen for the payer´s
master data.
The system always uses the entry that is most specific. This means that if you enter a
payer in the document, this always has priority over the entry in the master record.
3.1.6.2 Sales data
In addition to the fields mentioned if the Customer Master Record is created and maintained
separately for the sales area, two additional fields are available:
 Credit control area: is an organizational entity, which grants and monitors a credit limit
(maximum amount granted a customer as credit) for customers. In Hilti there will be a 1:1
relationship between company code and credit control area.
 Payment guarantee process: The customer payment guarantee procedure determines

which payment guarantee procedure the system automatically uses when you create a
sales document for the customer. The following are the payment guarantee available:

P 23 I 119
Picture 13: Payment guarantee procedure
3.1.6.3 Company data
The following fields are available to define the account management details in the company
data area segment in regards to:
Accounting information
 Reconciliation account: You use this field to indicate G/L accounts as being reconciliation
accounts. The reconciliation account in G/L accounting is the account, which is updated
parallel to the subledger account for normal postings (for example, invoice or payment).
An example of reconciliation accounts in the system is shown bellow:
Picture 14: Reconciliation accounts
 Head office: This field contains the account number of the head office. Please note that
this account number is only specified for branch accounts. All postings for which the
account number of the branch is specified, are automatically posted to the head office
P 24 I 119
account. The account number of the branch affected is noted in the line items. No line
items or balances are managed in the branch account if this field is selected.
 Authorization: This field allows extended authorization protection for particular objects.
Field is not used with current release.
 Release group: The release approval group can be freely assigned. You use it to classify
vendors and customers, which means that the release approval group can be defined for
vendors and customers. By using the release approval group, you can determine release
approval paths and those people with release approval. Field is not used with current
release.
 Sort Key: You can specify the sort sequence of the line items by entering a key in the Sort
key field in the account master record. This key specifies how the Assignment field is to be
filled in the line items that are posted to the customer account. When you call up the line
item display, the system sorts the line items according to the contents of this field. You can
change the sort sequence in the line item display. The system uses a standard sort
sequence for displaying line items. Among other things, it sorts the items according to the
content of the Allocation field. This field can be filled either manually or automatically (by
the system) when a document line item is entered. For this purpose, the system requires
rules that determine which information is to be taken from the document header (e.g.
customer number) or from the document line item (e.g. document number) and placed in
the field. The rules can be stored in the master record of an account, which enables you to
determine the standard sort sequence on an account-specific basis.
In the below example, in the customer master record, key 003 has been entered in the
SortKey field for the layout rule Document date. When you display line items, the system
displays all amounts posted to this account in ascending order according to document
date, providing no different entry has been made in the Assignment field during posting.

P 25 I 119
Picture 15: Sort Key field layout
The table for assignment rules already contains layout rules.
You can change the keys for layout rules in the master record at any time. The new layout
rule takes effect from the time the change is made: When you display line items, all items
posted after the change are sorted according to the new layout rule.
You can define the sort sequence for an account when you create or change the account.
 Cash management group: In cash management, customers and vendors are allocated to
planning groups by means of an entry made in the master record. This feature is used for
planning purposes to reflect the correct cash flow. The system gives by default cash
management group R4 – Receipts from customers 3 rd party, but the following groups can
be assigned:
Picture 16: Planing groups

P 26 I 119
 Value adjustment Key: The value adjustment key controls the way the open items are
processed during individual value adjustment. In other words, how the classification of the
Receivables is maintained in the Master Data. The following value adjustment keys have
been defined in the system:
Picture 17: Value adjustment key
System will filled in value G1 “Collectible and undisputed A/R” by default and changes require
manual intervention.. For further details on value adjustment key, please refer to chapter 3.6
bad debt reserve.
3.1.6.4 Interest calculation
 Interest indicator: In order to calculate interest on G/L or customer accounts, the interest
calculation report references the interest indicator from the account master record. The
most important specifications for interest calculation are stored in this indicator, such as the
rules used for calculating interest and the interest rate. Interest can be calculated on
customer accounts in two ways: Account balance interest calculation or calculation of
interest on arrears. All accounts that you want to be included in the interest calculation run

P 27 I 119
must have an entry in the field Interest indicator in their master record. If you want to block
an account for interest calculation, you should remove the interest indicator.
 Interest cycle: In this field you enter a number of months, which determines how often the
interest calculation program is to be run. However, it is only necessary to make an entry in
this field if you are planning to have the system determine the interest calculation period
automatically. The interest calculation period always refers to the field Key date of last
int.calc. You can also define an interest calculation frequency under an interest indicator.
However, the entry in the master record has higher priority.
 Last key date: After the interest calculation program has been run in the background, it
enters in this field the upper limit of the interest calculation period. This date is used by the
system to automatically determine the interest calculation period for an account.
 Last interest run: In this field the report enters the system date of the last balance interest
calculation run. This information is necessary in order to determine whether interest must
be calculated for items with a value date in the past. These are items which are posted to a
period for which interest has already been calculated. You can find more information on
this special case in the program documentation.
3.1.6.5 Reference data
 Previous account number: If you renumber customers and/or vendors when

implementing the FI System, you can store the previous master record number in this field.
Customer account numbers from legacy system should be stored here.
 Buying group: This field contains the buying group account number. This account number
is only specified for members of the buying group. The members are independent
customers, in contrast to branches of a central office. The buying group is used for
reporting purposes only. You can, for example, generate an account statement with line
items for all members and for the buying group. Field is not used with current release.
 Personnel number: The personnel number is the only feature within a client which is
unique to an employee. You have to enter a personnel number before you can display and
maintain an employee's master data and time data. Field is not used with current release

P 28 I 119
3.1.6.6 Payment transactions
Picture 18: Customer master record – company code area segment – payment
transactions
3.1.6.7 Payment data
 Payment terms: Data can be entered in the field for the terms of payment key in various
ways as you enter a business transaction:
In most business transactions, the system defaults the key specified in the master record of
the customer/vendor in question. In some transactions (for example, credit memos),
however, the system does not default the key from the master record. Despite this, you can
use the key from the customer/vendor master record by entering "*" in the field.
Regardless of whether or not a key is defaulted from the master record, you can manually
enter a key during document entry at:

P 29 I 119
 item level in sales orders

 header level in purchase orders and invoices
 Credit memo payment terms: To have the system default terms of payment for credit
memos, you have to make an appropriate entry here. Credit memos in this context can be
credit items posted to a customer account or debit items posted to a vendor account. Field
is not used with current release
 Bill of exchange charges payment terms: Terms of payment which are automatically
copied into a bill of exchange charges debit. These terms of payment can vary from the
usual terms for invoices for goods and services. Field is not used with current release
 Time until check paid: Use this field to record the number of days which usually pass until
the vendor has cashed your check. Field is not used with current release
 Tolerance group: In this activity you define the tolerances for customers/vendors. The
tolerances are used for dealing with payment differences and residual items that may arise
when payment clearing is carried out. Tolerances can be specified in one or more
tolerance groups and assign a tolerance group to each customer/vendor using the master
record. For each tolerance group the following can be specified:
 Tolerances, up to which payment differences arising from open item clearing can be
automatically posted to expense or revenue accounts
 The treatment of terms of payment for residual items if they are to be posted during
clearing
If you want to use the same tolerances for several customers or vendors, you can group
them together using the tolerance group code. You simply define the tolerances under a
tolerance group code and then enter that code in the master records of the customers or
vendors that should be assigned those tolerances. Tolerance groups must be defined by
the MO.
By grouping your business partners under tolerance group codes, you can assign different
tolerances to different groups of business partners. For instance, all your major customers
could be assigned the same tolerances, which are more lenient than those assigned to
new customers. Extraordinary business partners could be assigned special tolerances that
are defined under a separate code (e.g. Key accounts).
Please note that tolerance groups can be defined separately for users and business
partners. The system checks both limits when clearing open items. The lowest limit always
has priority. Tolerance groups should be defined by the MO on a local level.
 Known/negotiated leave: Rules can be defined for a specific customer for issuing
invoices within the leave period of the customer. The objective is to take the leave period of
the customer into account when setting the due date for the invoices. In some countries
like Spain, companies usually close completely and for quite some time within the holiday
period. No invoices are processed during this time. To avoid open invoices being dunned

P 30 I 119
during this time or cash discounts expiring, the vendor makes arrangements with his/her
customers regarding the leave period (invoice issue rules). Invoices are settled either
before the start of the vacation, after the end of the vacation or partly before and partly
after. In addition, the business partners agree that interest will be paid accordingly, or that
different conditions will apply for cash discount. The use of this field is not contemplated for
current H2.0 release. Therefore it should be left blank.
 AR pledging indicator: This indicates in the master record that a customer should be
involved in the accounts receivable factoring procedure. The indicator is automatically
transferred to the line item during posting but can also be entered manually. The use of this
field is not contemplated for current H2.0 release, therefore it should be left blank.
 Payment methods: List of payment methods which may be used in automatic payment
transactions with this customer/vendor if you do not specify a payment method in the item
to be paid.
If you do specify a particular payment method in the item to be paid, this specification has
priority over the specifications in the master record. You may also specify payment
methods in the item, which are not listed in the master record. A list of available payment
methods in the system is shown:

P 31 I 119
Picture 19: Customer master record – general area segment – payment methods
 Alternative payer: Account number of the customer for whom automatic payment
transactions are to be carried out. The account number is only needed if bank collections
are not to be made via the customer who owes the receivables. The same applies to
refunds of payables. Please note that the specification in this field only applies to this
company code. There is another field in which you can enter an alternative payee for all
company codes. As mentioned before, if both fields are filled, the specification for the
company code has priority.
 Bill of exchange limit: Maximum amount, which may be issued on a bill of exchange if it is
to be used in payment transactions with the customer/vendor. Field is not used with current
release
 Single payment indicator: If this indicator is set, every customer/vendor open item is paid
separately during automatic payment transactions. This means that open items are not
grouped together for payment. Field is not used with current release
 Payment advice by EDI: This indicator specifies that the customer/vendor should be sent
all payment advice information by EDI.

P 32 I 119
 Payment block key: Block key used to block an open item or an account for payment
transactions, mostly for vendors.
 House Bank Key: This indicator specifies the bank details about the bank to be used for
automatic transactions. The banks with which your MO maintains a bank account are
referred to as house banks. These banks are defined in the system under a house bank
key (bank ID). All the accounts that are maintained at these banks are stored under this
account ID. For each bank account, a G/L account has been created in the SAP system.
 Grouping Key: The grouping key is used in cases where you do not want all the open
items of a customer or a vendor to be paid together but rather you want only those items
which belong together to be grouped into a single payment. A maximum of three fields
from the open items are defined for every grouping key; the contents of these fields must
correspond in order that the open items can be paid together. Field is not used with current
release
 Next payee: The account number of the customer to whom the check is to be addressed.
Only relevant for use in the USA (remit to address). The company code-dependent next
payee must be defined as a partner. Field is not used with current release
 Lockbox key: Lockbox identification to which the customer is to make payments. Only
relevant for use for HNA. Field is not used with current release, needs customization.
3.1.6.8 Payment advice notes
 Selection rules: A selection field which is to lead to the clear identification of the open
item is determined from the various fields of the payment advice item (document number,
billing document number, reference document number, etc) according to the selection rule
in each individual payment advice item. Two selection sequences for payment advises
have been defined currently in the system:
 S001
 S002

P 33 I 119
Picture 20: Selection Sequence for Payment advices
3.1.6.9 Correspondence
 Dunning procedure indicator: This field contains the key for the dunning procedure for a
specific customer. A list of the dunning procedures available in the system is as follows:

P 34 I 119
Picture 21: Dunning procedure
The system fills the dunning procedure ZSTX by default, which covers the standard for a Hilti
customer.
 Dunning recipient: Account number of the customer who is to be the recipient of the
dunning letters. The account number is only needed if dunning letters are not sent to the
customer who owes the receivables.
 Last dunned on: Date on which the last dunning notice was made.
 Dunning clerk: Identification code for the accounting clerk dealing with dunning letters.
Using this identification code, the accounting clerk whose name is printed on the dunning
letters is determined. Please note that if this field is not filled, then the entry from the
Accounting clerk field is used. Codes for dunning/accounting clerks are maintained in the
IMG, as the following table shows:

P 35 I 119
Picture 22: Accounting Clerks determination
 Dunning block: Key which reflects the reason for a dunning block indicator. Dunning
blocks in the master record enables you to prevent an account from being dunned. Enter a
blocking key in the field Dunning block in the master record. There are texts stored for the
blocking keys; these explain the reason for the block. A dunning block can also be entered
at an item level. Blocked accounts or items are not included in the dunning run and are
printed in an exception list with the reason for the block. The following list include the
available dunning blocks in the system:

P 36 I 119
Picture 23: Customer master record – company code area segment – Dunning block
 Legal dunning procedure: Date on which a legal dunning procedure was initiated. If the
Legal dunning procedure field in the master record contains a date, this means that the
account is involved in a legal dunning procedure. The relationship between this date and
the dunning date does not affect how the account is processed.
 Dunning level: Dunning level of the customer/vendor, which was reached by the last
dunning run.
 Grouping key: The grouping key represents a rule according to which the open items of
the account are to be grouped together for dunning notices. The grouping key is used in
cases where you do not want the open items of a customer or a vendor to be dunned
together but rather want to create several dunning notices for an account. You must define
one field from the open items for each grouping key. All items which have the same
contents in this field are then grouped together in a single dunning notice.
 Dunning areas: Are used if several organizational units are responsible for carrying out
dunning within one company code. These organizational units are referred to as dunning
areas. The dunning area can correspond, for example, to a profit center, a distribution
channel, a sales organization or a business area. The individual dunning areas can use
different procedures or the same dunning procedure.

P 37 I 119
Picture 24: Customer master record – company code area segment – Dunning areas
The dunning areas with the required dunning procedures are to be entered into the
customer or vendor master record if you use different dunning procedures. Otherwise,
the system uses the standard dunning procedure. The dunning area is then entered in
the line item. The system enters the dunning area into the master record automatically
with the corresponding data.
For further information in dunning, please refer to dunning chapter 3.4
 Customer Correspondence: As shown in the attached table, all the relevant fields related
to the customer correspondence are filled here:

P 38 I 119
Picture 25: Customer master record – company code area segment –

Correspondence information
 Hilti Accounting Clerk: Identification code for the accounting clerk. The name, telephone,
fax number and e-mail address of the accounting clerk defined by this identification code
can be used in the payment program for correspondence and reporting (for example, open
item lists, customer statements, etc).
 Account at customer: This field contains the account number Hilti is listed under at the
customer.
 Accounting Clerk at customer information fields: Field to include the name or

identification code, phone number, fax number and e-mail address of the accounting clerk
at the customer.
 Bank statement - Indicator for periodic account statement: You can store an indicator
in the master record so that the system includes an account when creating periodic
account statements. By defining different ID's, you can divide customers into groups with
different account statement intervals. For example:

P 39 I 119
Picture 26: Customer master record – company code area segment – Indicator for
periodic customer account statements
 Decentralized processing: In the case of using the head offices and branches
functionality, this key indicates that payment transactions and dunning notices are created
for the branch. Select this indicator only if this account is a head office account. See further
details in separate topic “Head offices and branches” bellow.
 Payment advice notices indicators: Select these indicators whether or not you would like
the system to create a payment notice when you post to the customer account on which
cleared items are shown. In addition, indicators are also available to determine whether a
payment notice is to be created for the sales, accounting or legal department when posting
to the customer account.
3.1.6.10 Insurance
Although not used at the moment, information relevant to insurance for a customer master
record can be maintained in the following information tab:

P 40 I 119
Picture 27: Customer master record – company code area segment – Insurance
information

P 41 I 119
3.1.7 Maintain Customer Master Record separately for the finance area
To create a new customer master record separately for the Finance please refer follow the
following path:
Accounting > Financial Accounting > Accounts Receivables > Master records > Create >
Transaction code: FD01
Or refer to the following BPP:

..\H2_Transactions_BPP\BPP_H20_FD01_Create_Credit_Info.doc
Whenever a customer master record is created and maintained using this transaction code in
the FI module, you can enter only data that is relevant to accounting and Accounts
Receivables, therefore only access to general data and company data screens will be
possible. Explanation of the different fields is the same as explained previously on this chapter.
3.1.8 Create with reference
If a customer master record already exists with similar data, you can use this one and cut
down on the time taken to enter data.
Enter the number of the customer whose master record you wish to use as a reference in the
Customer field in the Reference screen area of the entry screen.
If you only enter the customer number in the reference section, the system will only copy the
general data into the new customer master record. If you also enter data on the sales area, the
sales and distribution data will also be copied. Only data, which can be identical for both
master records, is copied. For example, address and unloading points are not copied, while
country, language and account group are. You can change all copied data.
3.1.9 Create an already available customer master record for a new sales area
If you create a customer master record for a customer, for which a customer master record
already exists in another sales area, then use the customer that has already been created as a
reference. In this case you do not need to enter the general data for the second master record
again.
3.1.10 Displaying a customer master record
Both the accounting and sales departments use a customer master record. You can display
either the general and company code data (the accounting data) or the entire customer master
record (with sales data). Employees in the sales department can display the data about order
processing, shipping, and billing for a customer.
P 42 I 119
To display a customer master record maintained for sales and distribution please use the
following path:
Choose Logistics > Sales and distribution > Master data > Business partners > Customer >
Display > Transaction code: VD03
To display a customer master record complete maintained centrally please use the following
path:
Accounting > Financial Accounting > Accounts Receivables > Master records > Maintain
centrally > Display > Transaction code: XD03
Or from the SD module choose as follows:
Logistics > Sales and distribution > Master data > Business partners > Customer > Display
>Transaction code: XD03
To display a customer master record maintained for Finance please use the following path:
Accounting > Financial Accounting > Accounts Receivables > Master records > Display >
..\H2_Transactions_BPP\BPP_H20_FD03_Disply Master Record.doc
3.1.11 Changes in a customer master record
Changes in a customer master record can be made either together or separately as follows:
 Separately for the company code
 Separately for the sales area (order processing, shipping, and billing information
about the customer)
 Centrally for both the company code and sales area in one step
To make changes to a customer master record maintained centrally when the Accounts
Receivable functions are shared please refer to the following BPP:
Transaction code: XD02
..\H2_Transactions_BPP\BPP_H20_XD02_Change_Customer.doc
Whenever a customer master record is maintained centrally, access is given to general data
company data and sales data.

P 43 I 119
To make changes to a customer master record maintained in the sales area please refer to the
following BPP:
Transaction code: VD02
..\H2_Transactions_BPP\BPP_H20_VD02_Change_Customer_Sales_Area_Data.doc
To make changes to a customer master record maintained in the Finance area please refer to
the following BPP:
..\H2_Transactions_BPP\BPP_H20_FD02_Change_Customer_Master_Record.doc
3.1.12 Displaying changes in a customer master record
You can display all changes which have been made in a customer master record (accounting
data and sales and distribution data). You can display changes in the display mode and in the
change mode. You can also use the Display changes function to display changes to customer
master data for more than one customer.
If you need special information on a customer master record, such as the name of the user
who created the customer master record, or the sales areas, you can display these.
To display changes in a customer master record in the SD module please use the following
path:
Display changes > Transaction code: VD04
To display changes in a customer master record complete maintained centrally please use the
following path:
centrally > Display changes > Transaction code: XD04
Or from the SD module choose as follows:
Logistics > Sales and distribution > Master data > Business partners > Customer > Display
changes > Transaction code: XD04
To display changes in a customer master record in Finance please use the following path:
Accounting > Financial Accounting > Accounts Receivables > Master records > Display >

P 44 I 119
..\H2_Transactions_BPP\BPP_H20_FD04_Customer Account Changes.doc
To display changes in several customer master records in the SD module please use the
following path:
Display changes > Transaction code: OV51
3.1.13 Comparing customer master records
Customer master records are created and maintained in Financial Accounting and in Sales
and Distribution. In some cases, a customer master record may have been created for a
customer in SD but not in FI and vice versa. There is a program, which determines which
customer records have been maintained in one of these applications but not in the other.
To compare customer master record in the Finance module please use the following path:
Choose Accounting > Financial Accounting > Accounts Receivables > Master records >
Compare > Transaction code: F.2D
To compare customer master record in the SD module please use the following path:
Display changes > Master Data comparison > Transaction code: OV50
3.1.14 Blocking a customer master record
A customer master record can be blocked, for example, when you want to temporarily stop
business relations with a customer.
In Accounts Receivable you can block a customer account so that postings are no longer
made to that account. You have to block a customer account before marking a customer
master record for deletion, for example. You would also block a customer that you use only as
an alternative dunning recipient, so that nobody can post to that customer by mistake.
To block a customer master record in the SD module please use the following path:
Block > Transaction code: VD05
To block a customer master record maintained centrally (preventing both posting and order
processing) please use the following path:
centrally > Block > Transaction code: XD05

P 45 I 119
To block a customer master record in Finance (so that postings are no longer made to that
account) please use the following path:
Accounting > Financial Accounting > Accounts Receivables > Master records > Block >
3.1.15 Blocking a Customer Account of a Business Partner
To block the customer master record of a sold-to party, for example, use the following steps.
The procedure is the same for the other partner functions (e.g. ship-to, bill-to, etc). To block a
customer account of a Business Partner please use the following path:
Logistics > Sales and distribution > Master data > Business partners > Hierarchy nodes >
Transaction code: VD05 Block/Unblock .
Enter the number of the sold-to party (or other partner function) you would like to block. If you
do not specify a sales area, you can set a general block for all sales areas on the following
data screen. If you specify a sales area, you can set the blocks for selected sales areas.
Select a sales order block, a delivery block or a billing block or all of them by using the
appropriate keys.
3.1.16 Unblocking Customer Master Records
You can cancel a block in a customer master record by removing the block indicators. First use
the same steps as for blocking, as described above. As soon as you access the data screen
Block/Unblock Customer: Details screen, you can remove the existing block indicator and save
the master record. You receive a message that the changes have been made. The block is
canceled.
You can also block a customer master record in the customer master record itself by selecting
Extras -> Blocking data in the customer master record change mode, and then entering the
appropriate keys on the subsequent screen.
3.1.17 Deleting a customer master record
You mark a customer master record for deletion if, for example, you no longer maintain
business relationships with the customer. By using the deletion indicator you mark the
customer master record, so that the corresponding reorganization program later recognizes
this master record and deletes it from the file.
The master record of a customer account cannot be archived immediately. The system first
has to check whether the following requirements have been met:

P 46 I 119
 The account must not contain any transaction figures in the system. Transaction figures
from previous years that have not been archived will also prevent the system from deleting
the account master record.
 The account must be marked for deletion in its master record.
The master record is only deleted after all dependent data has been deleted. Customer master
records no longer needed are then archived. When data is archived, it is extracted from the
SAP database, deleted, and placed in a file. You can then transfer this file to an archive
system.
To mark a customer master record for deletion in the SD module please use the following path:
Transaction code: VD06 Flag for deletion
To mark a customer master record for deletion maintained centrally please use the following
path:
centrally > Transaction code: XD06 Mark for deletion
To mark a customer master record for deletion in Finance please use the following path:
Accounting > Financial Accounting > Accounts Receivables > Master records > Transaction
code: FD06 Mark for deletion

P 47 I 119
3.1.18 Head offices and branches
In some industries, branches of a company sell their goods independently but the accounting
for these sales is performed centrally (at the head office). You can represent this type of
organizational structure in the system by using head office and branch accounts.
First you need to create head office and branch accounts. The sales orders are managed in
the branch account. The sales and transaction figures, however, are not posted to this account
but rather automatically to the head office account. Payments are cleared centrally by the head
office, meaning that outgoing payments can be made for several branches in one step, using
the head office account.
Picture 28: Head office and branches
3.1.18.1 Link between Branch Accounts and Head Office Account
To link branch accounts to a head office account, you must enter the number of the head
office account in the Head office field in the branch account master record. This field is
contained in the company code area of the master record, as mentioned before on this
chapter.

P 48 I 119
head-office account number
The head office account can be any customer account except one-time accounts or branch
accounts themselves. Branch accounts and head office accounts must belong to the same
company code.
3.1.18.2 Line Item Display
When you are entering the parameters for line item display, you should note the following: for
head office accounts, enter the key 004 in the field Sort key. This instructs the system to
display the line items for the head office account sorted by branch.

P 49 I 119
head office account sorted by branch.
3.1.18.3 Correspondence
You can set up your system to cater for written correspondence with customers
 for the head office, broken down per branch or

 for each branch individually.
If you want to create correspondence (such as dunning notices and account statements) for
the individual branches instead of the head office, you have to select the Local processing field
(decentralized processing) in the customer master record of the head office on the Create
Customer: Correspondence screen.

P 50 I 119
local processing field
You can also define payment methods in the master records of the branches and head offices.
For example, if you want to have certain payment methods for particular branches, enter these
in the master records of the branches concerned and do not enter any payment method in the
head office master record. If you enter payment methods in both head office and branch
master records, all payment methods are possible.
3.1.18.4 Local Payment
Unless you specify otherwise, where an organization has both a head office and branches, the
payment program pays via the head office: This means that the information required by the
payment program is taken from the master record of the head office. Postings are always
made to the head office account.
If you want payments to be processed locally, you must mark the field Local process in the
master record of the head office. The payment program then pays separately for each branch.
All specifications, such as the bank details and the address, are determined from the master
record of the branch. There are two ways to define the payment methods for local processing:
P 51 I 119
 If you want to arrange separate payment methods for each branch, you should enter these
in the branch master records only.
 If all the branches of an organization use the same payment methods, enter these in the
head office master record only.
If payment methods are defined in both the branch and head office master records, the
branches can use any of these methods.
3.1.19 One-time customers
Business partners who have a business transaction with the MO only once are called one-time
customers and one-time vendors. You do not have to create a master record for one-time
customers or one-time vendors because you do not need this master record after the business
transaction, and it uses space. A collective master record for a dummy customer has been
created that only includes data for all one-time customers in a certain MO. The customer
number on this case has been defined as customer “CPD” as the example shows:
Picture 32: One-time Customer account master record

P 52 I 119
If a one-time customer or walk-in customer orders goods from your MO, use the customer
number of the collective master record when processing the sales order. When you post to a
one-time account, the system automatically goes to a master data screen. On this screen, you
enter the specific master data for the customer, which is stored separately in the document.
This includes only name, address, and contact information.
For further information on usage of one-time customer please see related chapter in Hilti
Center cash sales.

P 53 I 119
3.2 FI Invoices/Credit Memos
3.2.1 Overview
You can use this function to enter incoming or outgoing invoices or credit memos. With this
transaction you can enter, hold park and post documents with a minimum amount of entries.
All trade invoices or credit memos have to be created through the SD Module (Sales and
Distribution) per order entry. This includes credit memos for returns, repair, but also sales to
employee’s etc. Only special cases should be entered in the FI Module such as IC services or
distinguished other operational income like misc. rent, patent & licenses, insurance claims, etc.
Asset Sales should be entered in a special procedure, which is explained in Chapter 5.3.4.1.
Please note that the FI invoice transaction cannot create a printout of an invoice and requires
subsequently a manually created voucher.
If an invoice is created in SD, certain sales document related characteristics will be transferred
to the profitability analysis module (CO-PA). Such characteristics are customer information,
product, quantity, price and discount, etc. Whereas the invoice is created in the FI module,
only the characteristics that are specifically assigned in the invoice item line will be transferred
into the CO-PA.
You can access the menu through SAP Easy Access > Accounting > Accounts Receivables >
Document Entry. There you will have the following choices of Enjoy transactions:
 FB70 – Invoice
 FB75 – Credit Memo
 FV70 – Park/Edit Invoice
 FV75 – Park/Edit Credit Memo
 F-22 – Invoice general (same concept, but different layout of screen)
Links to BPP’s ..\H2_Transactions_BPP\BPP_H20_FB70_Customer_Invoice_Manual.doc and

..\H2_Transactions_BPP\BPP_H20_FB75_Customer_Credit_Memo_Manual.doc
Generally the concept is the same for all these entry forms. The difference is that depending
on which form you chose, one part of the entry is already suggested. You can still change the
possibilities while entering the data.

P 54 I 119
3.2.2 Procedure
The first time you carry out this transaction, a dialog box appears prompting you to enter a
company code. Enter the company code required for your invoices or credit memos. For all
future document entry transactions, the system defaults this company code automatically.
You can follow the different sheets on the screen that lead you through the entry.
I. Basic Data
The following fields are required entries:
 Customer/Vendor account number

 Invoice date
 Posting date
 Reference: required because the payment gets applied by this field
 Invoice Amount
 Calculate Tax and Tax code: the tax code can also be entered on each individual item
line.
 Line items: with the off-set Account and Cost center if required
II. Optional entries:
 Currency: The system proposes the local currency defined in Customizing. You can also
have the system propose either no currency, or the last currency used, by defining this in
editing options. Once you confirmed the entry, you cannot change the currency any more.
 Changing the leading company code: If the receivable is to be posted in a different

company code to the one proposed, you have to define the new company code using >
Edit > change company code. Note that if you have already entered data, you will lose
them!

P 55 I 119
 Changing the transaction: In the field transaction, you can choose whether you want to
enter an invoice or a credit memo. You can also change the transaction during document
entry. If you change the transaction, this generally changes the document type.
Picture 33: Change Invoice / Credit Memo
To adjust that the balance of the posting is zero, the line item also has to be changed
accordingly.
Picture 34: Change Invoice / Credit Memo
 Calculating taxes: The tax code has to be entered on an item level. By using the Tax tab
in the header of the invoice entry, the system will propose you this tax code on the line
item. Though the tax code on the line item can be overwritten. As soon as you have
confirmed this screen with ENTER, the tax codes can only be changed on the item level.
That means that a mass change is not possible any more.
If you want the system to calculate the tax automatically when posting, select the
Calculate tax flag and do not enter a tax amount.
If you want to use the amount from the invoice, enter a tax amount manually and deselect
the Calculate tax flag.
Note that the tax code must match with the G/L account (e.g. incoming or outgoing tax
depending on the G/L account). Otherwise you will get an error message and you cannot
post the entry.
If you press enter, the most important master data for the customer will be displayed. You can
therefore check immediately whether the vendor is correct. In addition, the payment terms are
also displayed. You have the option to change this for the individual invoice.

P 56 I 119
You can easily switch to different screens and input fields like Customer Master Data and
Account information (open items).
Picture 35: Enter customer invoice – Basic Data
Picture 36: Item Line Details

P 57 I 119
III. Details
On the Sheet Detail you can see or edit some more detail, such as listed below:
 G/L Reconciliation Account: This field is only for information purposes and cannot be
changed
 VAT Registration Number
 Dunning information: You can overwrite dunning information on the invoice level. This
has a higher priority to the master data information. If this field is empty, SAP takes the
information defined in the Customer Master data.
Picture 37: Enter customer invoice - Details
IV. Payment
SAP suggests the following payment conditions that were defined in the Customer Master
data. They can be overwritten. Note that if so, they only apply to this individual invoice/credit
memo.
 Payment terms
 Payment block
This feature is important in case of a credit note that should not be paid out, but applied to
outstanding invoices.

P 58 I 119
Picture 38: Enter customer invoice - Payment
V. Tax
No further entries
VI. Notes
You can make further notes on this sheet.

P 59 I 119
Picture 39: Enter customer invoice - Notes
VII. Local Currency
This sheet gives a summary of the currency calculation for this invoice. The example shows an
invoice of 500 GBP
Picture 40: Enter customer invoice – Local Currency

P 60 I 119
3.2.3 Closing the document
After you have entered the document, you can carry out any of the following functions:
 Simulate: A document overview appears in which you can select various options for data
preparation.
 Hold: Document entry is interrupted, and you can continue at a later point in time. If you
have entered a document long text or item long text for a document, this text is lost if you
hold the document
 Park: You can also park a document. That means prepare the document, but do not post
it. To recall the document you can chose different ways:
If you know the customer, chose SAP Easy Access > Accounting > Financial Accounting >
Accounts Receivables > Account > FBL5N Display/change line items. Then select parked
items as Type.

P 61 I 119
Picture 41: Customer Account selection
Chose Edit > Change in the menu to change the parked items. You will see that a new
sheet is added that is called Workflow, which shows the status of the parked item.

P 62 I 119
Picture 42: Edit parked customer - Workflow
The parked item can be any time changed and posted. To list all parked items proceed as
follows: Chose SAP Easy Access > Accounting > Financial Accounting > Accounts
Receivables > Account > FBL5N Display/change line items
Select parked items only and no customer account. Sort by St (Cleared/open items display) –
click on “St” and then click on
This will give you a list of all parked items. Make sure that there are no parked items at the
month end closing.

P 63 I 119
3.3 Accounts Receivable Payment Application
3.3.1 Overview
The Accounts Receivable application component records and manages accounting data of all
customers. When creating an SD invoice, the systems updates automatically the FI module
with all details required in the General Ledger such as Customer no., Reference no., Payment
terms, Invoice amount, etc. The invoices in the G/L will be on a total amount, but not have any
line item level information.
The payment program lets you handle both outgoing and incoming payment. It is flexible
enough to allow you to define/customize those payment features that vary from country to
country such as payment method, payment for or data carrier specifications. Though, the
handling procedures are similar for all different country specifications.
SAP provides different application for payment, which can be country specific. In general the
process of applying the payment to the invoices is the same for all incoming payments.
Therefore Chapter 3.3.2 will give you the details how to apply payments and the possibilities
available if payment differences occur. This is the choice of each MO according to legal issues
and country specific preferences. Chapter 3.3.3 will cover the different ways of payment into
the system.
3.3.2 Payment – clearing and payment differences
3.3.2.1 Concept
No payments will be directly posted from the bank/cash account to the customer account, but
over a clearing account to guarantee the reconciliation of the bank account. All reconciling
items (e.g. if a payment is not applicable to a customer account) should be on the clearing
account. Payments that are applicable to a customer should be on the customer account as a
payment to account in order to not unjustified block a customer account for new orders.
Bank / Credit Card Clearing Acct Customer Acct
I) Invoice 1000
II) Customer Payment 1000 1000
III) Bank Statement 1000 1000
IV) Clearing Report F-03 Direct Clearing

3.3.2.2 Tolerance groups Or FEBA
Payment differences arise during clearing if a customer has made an underpayment, or has
made an unauthorized deduction for cash discount and the difference is within, or exceeds
defined tolerance limits.
P 64 I 119
Depending on the amount of the receivables, you define how payment differences should be
treated.
If the difference is immaterial, you usually clear the receivable and post the difference. You
can define how payment differences should be posted. The system allows defining tolerance
groups. That means that
 If the payment differences are within the tolerance limits, the system automatically adjusts
the cash discount or posts the difference to a separate gain or loss account. You have
defined the amount to which differences should be posted in this way. Specify tolerance
amounts and percentage limits. (see example Picture 1):
Picture 43: Customer/Vendor Tolerances - Details
The tolerance group is assigned to the customer master data (see Chapter 3.5.1.2.3).
 If the payment difference exceeds the tolerance limits, you can process the payment as a
partial payment or enter a residual item for the difference. Please see the following
Chapter.

P 65 I 119
Or you can write-off the difference manually. An approval process should be defined, so
that the accounting clerk depending on his position can write off small differences up to a
defined amount. Please see more detail in Chapter 3.3.2.3 Partial and residual payments.
See also Payment with Small Balance Write/Off

..\H2_Transactions_BPP\BPP_H20_F-28_AR_PMT_Small_Bal_WO.doc
Picture 44: Automatic Clearing of Customer Accounts
3.3.2.3 Partial and Residual Payments
If a payment difference exceeds the tolerance limit, you have the choice between partial or
residual payments on the customer account.
It is recommended to classify the payment with the corresponding reason code. Reason codes
are on country level and can be defined by the MO. A reason code can be defined as an
information field only, or with an automatic transaction to another account of the payment
difference. This will allow tracking of the disputed items and the same reporting.
I. Partial Payments

P 66 I 119
With a partial payment, the payment will be posted to the account as a separate line, but with a
reference to the paid invoice. For calculation of the bad debts reserve, these items will be set
against each other and only the net value will be taken into consideration. No discount
deduction will be made, even if the payment is made within tolerated time for settlement
discounts.
VIII. Residual Payments
With a residual payment, the open item will be cleared and a new item will be created. The net
due date will remain the same as the original invoice due date. Any valid settlement discounts
will automatically be written off to the G/L account 858100 Settlement discounts-Customer
including the posting of the tax correction to the relevant tax account.
See ..\H2_Transactions_BPP\BPP_H20_F-28_AR_PMT_Residual.doc
3.3.2.4 Overpayment
An overpayment of the customer will be handled like a partial or residual payment. A special
reason code should be defined for overpayments for customers. You have the following
choices to apply the overpayment:
See also ..\H2_Transactions_BPP\BPP_H20_F-28_AR_PMT_Overpayment.doc, beginning at
point 1.6
 Block for payment

If further investigations have to be done or the payment will remain on the customer
account as an open item, you can set a manual payment block on the invoice/payment or
on the customer in the customer master data. Using the later means that the payment
block is used for all items of this customer and no refund can be made.
 Offset against other open items: The overpayment can also be offset against other open
items. This is done in Transaction SAP Easy Access > Financial Accounting > Accounts
Receivable > Account > F32- Clear. See also ..\H2_Transactions_BPP\BPP_H20_F-
32_Clear.doc
 Refund: Local authorization procedure may be defined in order to prevent for non-justified
refunds. In order to create a refund to the customer, the following points have to be
checked before releasing the refund for payment:
1. Payment term: If an immediate refund to the customer should be created, you need to
set the due date of the payment manually on today’s date. This is done on the item
level (Transaction FBL5N > double click on line item > click on button for change item >
change payment terms to 00 – you will get a warning that the due date is in the past –
click enter).
2. Payment methods: In the customer master data, the bank account and the payment
methods have to be defined. See Chapter 3.1

P 67 I 119
3. Bank Details: If the refund is via bank wire, the bank details have to be entered in the
master data. See Chapter 3.1
4. Release payment block: Check that there is no payment block, neither on invoice
level nor in the customer master record.
Now, you are ready to release the refund for payment. If several invoices and credit memos
should be offset from one customer, you can enter all the reference numbers into the selection
of the payment run and the system will assign them automatically and only release a payment
over the open amount. See also
..\H2_Transactions_BPP\BPP_H20_F110_Auto_Pmt_Transaction.doc
You can use the page “Free selection” to select specifically a selection criteria such as
reference number, etc. (see Picture 3).

P 68 I 119
Picture 45: F110 – automatic Payment Transaction – free selection

P 69 I 119
3.3.3 Payment methods
3.3.3.1 Bank payments
In several countries, bank statements are processed through automatic uploads. There are
two different kinds of bank statements, which are either a summary bank statement with a
separate list of the detailed payment information (scenario 1) or a detailed bank statement with
all payment details (scenario 2). Each bank account has a specific clearing account, which
should be balanced to zero. All open items that are not yet applicable to the corresponding
customer/invoice have to be reconciled on these accounts.
Scenario 1: Summary bank statement and separate detail information
Bank / Credit Card Clearing Acct Customer 1
I) Invoice I) 1000
II) Customer Payment II) 1000 II) 1000
II) 600
III) Bank Statement III) 1600 III) 1600
Customer 2
I) Invoice I) 600
II) Customer Payment II) 600

P 70 I 119
Scenario 2: Detailed Bank Statement
Bank / Credit Card Clearing Acct Customer 1
I) Invoice I) 1000
II) Customer Payment II) 1000 II) 1000
II) 600
III) Bank Statement III) 1000 III) 1000

III) 600 III) 600
Customer 2
I) Invoice I) 600
II) Customer Payment II) 600
For the upload of the bank statement, see Chapter 6.3.3 and ff., for bank clearing account
Chapter 6.3.2 and for periodical clearing of G/L Accounts Chapter 6.2.3.3.
Local customizing sets the parameter for applying the payment to the customer/ invoice. Below
is an example for a manual bank statement Transaction SAP Easy Access > Financial
Accounting > Banks > Incomings > Bank Statement > FF67. The system automatically applies,
if Customer, Reference doc no and the amount are identified clearly.
Picture 46: Upload Bank Statement – Error Log
If the system does not find an automatic rule, you need to post-process the payment in
transaction SAP Easy Access > Financial Accounting > Banks > Incomings > Bank Statement
> FEBA. This application offers another selection of applying rules respectively search
criteria’s. You can also process line items and apply manually.

P 71 I 119
Picture 47: Upload Bank Statement – Error Log
3.3.3.2 Direct Debit (LSV)
In certain countries, payments can be done through direct debit. That means that the customer
sends us an entitlement that we can charge his bank account directly with the invoice. We
have to send an order to the bank to trigger the payment. The procedure is as follows:
 Entitlement from Customer available: Depending of the local legal requirements, an

entitlement form the Customer has to be available in order to define this payment method.
 Bank information and payment transaction code complete: Check in the Customer
master data that valid bank account information and the payment transaction code for
direct debit are entered. See also
..\H2_Transactions_BPP\BPP_H20_FD02_Prep_Cust_Master_Record_For_Direct_Debit_.
doc
 Run automatic payment transaction: If the previous points are complete, you can run the
automatic payment transaction SAP Easy Access > Financial Accounting > Accounts
Receivables > Periodic Processing > F110 – Payments.
Select payment type A Direct Debit in Pmnt meths to isolate only this transaction.
See also ..\H2_Transactions_BPP\BPP_H20_F110_Auto_Pmt_Transaction.doc
The payment proposal will be posted to the Customer account and the corresponding Bank
clearing Account (Account 18300x). Once the bank is credited, the bank clearing account will
be offset against the payment.

P 72 I 119
3.3.3.3 Cheque
Post incoming cheques via F-28

This method is used when there are just a few cheques within the year and no automatic bank
statement is received.
For check payments use the transaction SAP Easy Access > Financial Accounting > Accounts
Receivables > Document entry > F-28 – Incoming payment. As reference number enter the
check number. This will be used for automatic clearing of the bank account and the bank
clearing account. And also select the correct bank clearing account according to the bank
where you will cash the check.
The Transaction Code for Check payments on the bank statement is ICHQ. This code will
assure that the correct clearing account will be considered in order to reconcile the redeemed
checks.
See also ..\H2_Transactions_BPP\BPP_H20_F-28_AR_PMT_In_Full.doc
Post incoming cheques via FF68- cheque deposit list

This method is used when there a lot of cheques in an organization that need to be processed.
Cheques can be received in HC too but sent to HQ for posting. They are not processed in HC
directly.
Example 1) Transaction ZH2Y, Cheque deposit list screen variant ZH2AU

With the posting rules set up in that example cheque postings are not credit management
relevant The original posting is cleared with cheque deposit list posting.
Posting scheme example 1

P 73 I 119
Payments and reverse process - cheque with transfer account
Cheque deposit list screen variant ZH2AU + Transaction ZH2Y

No special ledger is used. The open item is immediatelly cleared when check deposit list is posted.
1 Original sale to customer

2 Cheque receipt and foreward that to bank (another cheque deposit account is not used in that example) (FF68)
3 Bank statement - bank account increase (FEBA)
4 Information that cheque is bounced
in case no bank statement is received with deduction:
5 Reset clearing of bank statement (3) (FBRA)
6 Reverse and reset clearing/posting of cheque receipt with reversal code 21 to have an effect on credit management (FBRA)
in case of bank statement is received see example 2:
Result: Customer account remains open items again
AR GL
standard recon. acc. Revenue

Customer 150000 700000
1 1000 1000 2 1 1000 1000 2 1000 1

6a 1000 6a 1000
with immediate clearing of the offset side

Bank clearing acc Bank acc
183xyy2 183xyy0
2 1000 1000 2 3 1000 1000 6b

6b 1000 1000 6a
Bank clearing acc

18xyy4
2 1000 1000 3 for Bank-accts: x = 3 or 4

yy = 01 - 99
Example 2) Transaction Z26B, Cheque deposit list screen variant ZH2F2

With the posting rules set up in that example cheque postings are credit management relevant
as long as the real payment via bank statement is received. (e.g. used in MO FR) Till the
payment is received the original posting is cleared via cheque deposit list posting but a new
open item (SLI posting) is generated that is shown in special liabilities in FD32 credit
management.
Posting scheme example 2:

P 74 I 119
Cheque process and reverse after having debited our Bank account
Cheque deposit list screen variant ZH2F2 + Transaction Z26B

Special ledger indicator N is marked as credit management relevant. Therefore that posting is shown as special liability in FD32 credit management.
Prerequisit is that customer account or bank reference is known from the bank statement file. Cheque number has to be received back in bank statement file.

2 Cheque receipt and foreward that to bank - special G/L indicator 'N' two step posting (FF68)
2a D bank clearing account / C customer
2b D customer SLI / C bank clearing account
3 Bank statement - bank account increase - ICH2 two step posting with bank statement (FEBA)
3a D bank main account / C bank clearing account
3b D bank clearing account / C customer SLI
4 Bounced cheque via Bank statement XCH2 - bank account decrease to have the Bankstatement ending balance synchronised; only posted on Bank clearing (FEBA)
5 Bounced cheque via FBRA resets the posting 2a with a reversal code which ensures credit risk treatment (FBRA)
AR GL

Customer 150000 700000
1 1000 1000 2a 1 1000 1000 2a 1000 1

5 1000 5 1000
2b 1000 1000 3b

18xyy4 18xyy0
2a 1000 1000 2b 3a 1000 1000 4
3b 1000 1000 3a
4 1000 1000 5
standard recon. acc.

open cheques
150015
for Bank-accts: x = 3 or 4
2b 1000 1000 3b yy = 01 - 99
Example 3) Transaction Z26E, Cheque deposit list screen variant ZH2F2

With the posting rules set up in that example cheque postings are credit management relevant
as long as the real payment via bank statement is received. (not used in any organization until
now) The payment clears the original posting. Via cheque deposit list a SLI posting is done
that shows the cheque as still open. Because the SLI is not marked credit management
relevant this posting is not shown in special liabilities in FD32 credit management.
Note: The SLI posting needs to be cleared manually at month end.
Posting scheme example 3:

P 75 I 119
Cheque process and reverse after having debited our Bank account
Cheque deposit list screen variant ZH2F2 + Transaction Z26E

Special ledger indicator N is not marked as credit management relevant. Therefore that posting is not shown as special liability in FD32 credit management.
Prerequisit is that customer account or bank reference is known from the bank statement file. Cheque number has to be received back in bank statement file.

2 Cheque receipt and foreward that to bank - special G/L indicator 'N' (FF68)
3 Bank statement - bank account increase - ICHR two step posting with bank statement (FEBA)
3a D bank main account / C customer
3b D customer SLI / C bank clearing account
4 Bounced cheque via Bank statement - bank account decrease to have the Bankstatement ending balance synchronised; only posted on Bank clearing (FEBA)
5 Bounced cheque via FBRA resets the posting 3a with a reversal code which ensures credit risk treatment (FBRA)
AR GL

Customer 150000 700000
1 1000 1000 3a 1 1000 1000 3a 1000 1

5 1000 6 1000
3b 1000 1000 2

18xyy4 18xyy0
2 1000 1000 3b 3a 1000 1000 5
4 1000 1000 4
standard recon. acc.

open cheques
150015
for Bank-accts: x = 3 or 4
3b 1000 1000 2 yy = 01 - 99
..\H2_Transactions_BPP\BPP_H25_FF68_Creation_cheque_deposit_list.doc
Post incoming cheques via payment card ZCHK

This method is used when there a few cheques in an organization that need to be processed.
Cheques can be received in HC too and will be processed in HC directly.
An GL transfer account is assigned to payment card ZCHK. When the money is received on
the bank account then the bank statement contains that money and a two step posting will be
done via bank main account, bank clearing account and cheque transfer account.
3.3.3.4 Credit Cards
In H2.0 the Credit Card is foreseen only for HC Sales so far. Therefore see Chapter 3.7.
3.3.3.5 Lockbox
This feature is country specific for the U.S. and will therefore be tested and documented in a
later release.
3.3.3.6 Bill of Exchange
For Bill of Exchange, the same procedure as with check payments will be used. Due to the low
number of bill of exchange, the tracking of the due dates should be maintained manually
outside of the system. The document should be entered in transaction SAP Easy Access >
P 76 I 119
Financial Accounting > Accounts Receivables > Document entry > F-28 – Incoming payment.
As reference number enter the number of the Bill of Exchange. This will be used for
automatic clearing of the bank account and the bank clearing account. Important is to enter the
correct bank clearing account for the corresponding bank of remittance.
The Transaction Code for payments per Bill of Exchange is IBEM (Incoming Bill of Exchange)
on the bank statement.
See also ..\H2_Transactions_BPP\BPP_H20_F-28_AR_PMT_In_Full.doc

P 77 I 119
3.4 Dunning Process
3.4.1 Overview
To assist with collection on accounts that are in arrears, there is an automated dunning
program that can be run. The process can be customized to the local requirements, e.g.
dunning periods, levels of dunning letters etc. In order to set up the dunning run, several steps
have to be defined first. The flow chart below shows the different steps to generate a dunning
run. You can set up different dunning procedures. This allows that you can define different
dunning procedures for the different customer (e.g. key accounts).
Set system parameters Create Dunning Generate

Dunning Process Dunning
Procedures
The following list shows what step is done and who is responsible:
Steps Responsible
Set system These are basic settings for Customizing - PCC
parameters dunning and are made during the
kernel build-up e.g. dunning areas,
dunning block reasons
Create Dunning Predefined dunning procedures Customizing – PCC
procedures specifying how customers are
dunned. For each procedure, the SPRO > Financial
user defines: Accounting > AR-AP >
 number of dunning levels Business Transactions >
 dunning frequency Dunning > Dunning
 amount limits Procedure > Define Dunning
 text for the dunning notices Procedure
Dunning Process Based on dunning procedure Credit / Accounts
assigned to the customer/vendor in Receivables clerk
the master data, the system selects
the mailing frequency, the type of
notice etc.
Generate Dunning Creation of proposal and dunning Credit / Accounts
run including print-out and update Receivables clerk
of master record

P 78 I 119
3.4.2 Dunning Block
A dunning block can be applied at the customer account or invoice transaction level. This
block will prevent the customer account from receiving dunning notices. If the block is applied
at the invoice level, dunning notices will still be generated to the customer for delinquent
invoices but will omit any invoice with a dunning block applied.
Available dunning block reasons in H2

Complete list of dunning block reasons:
Specific dunning block reasons created for Hilti:
Bloc Text
k
5 5 days grace for complaint resolving
C Complaints not resolved
G Governement
I Intercompany accounts
K Key accounts
L Black list
S Agents / Resellers
T Transfer to ext. Agency / legal action
The other blocking reasons in the list were already provided by SAP.

P 79 I 119
Short description of dunning block reasons
“A” dunning block reason
This block is automatically created on billing document level when the customer is flagged as
invoice list customer. All the billing document created within one month (if the invoice list is set
to monthly) are blocked for dunning because the invoice will be sent out just at month end. The
block will be automatically removed again when the invoice list was generated.
“C” dunning block reason
That block is automatically determined when a complaint for a particular billing document is
created. Depending on the subtype which is chosen in complaint handling (ZCCN) a dunning
block on line item level will be set or not.
When the complaint is closed and a solution was proposed to the customer then the dunning
block is removed after a certain period of time. This grace period is 5 days (only) at the
moment.
“T” dunning block reason
That block will be set automatically when the billing document was sent to court or legal action
is taken. The last dunning level is reached for most of these documents. The trigger to set that
block is the generation of the file for external collection.
All other dunning block reasons have to be set and removed manually. It is possible to set that
on billing document level or customer level. The differentiation of the dunning blocks is made
to have better transparency about the blocking reasons.
3.4.2.1 Dunning Block at Customer Account Level
The dunning block may be applied at the account level through the Transaction FD02 (SAP
Easy Access > Accounting > Financial Accounting > Accounts Receivables > Master Records
> FD 02 – Change). See also Chapter 3.1.6.3.
Within the Company Code data > Correspondence, the dunning information can be located
and modified. There can be various reasons to apply the dunning block at the account level.
These will be indicated by the block code that is chosen and can include complaint items.
3.4.2.2 Dunning Block at Invoice Level
The dunning block may be applied at the invoice level through the Transaction FBL5N –
Display/Change Line Items (SAP Easy Access > Accounting > Financial Accounting >
Accounts Receivables > Account > FBL5N – Display/Change Line Items).

P 80 I 119
At the line level, you can specify which open invoice to apply the block and again indicate the
reason by the application of a specific character. This character will be displayed on the line
items after the block is applied.
3.4.2.3 Transaction Behavior upon removal of dunning block
When the dunning block has been removed, the cycle resumes at the stage it was ended. For
example, if dunning had progressed to stage 2 prior to the block being applied, once it is
removed, dunning proceeds to stage 3.

P 81 I 119
3.4.3 Dunning Procedure
Creating the dunning procedures means to define how the dunning process has to run.
Therefore different procedures can be defined depending on frequency of dunning, number of
dunning levels and text for the dunning notices
Usually the MO’s have 1 dunning procedure for standard customers and 1 dunning procedure
for key accounts. But if you don’t think that this is necessary to split customers, it is easier to
only have one dunning procedure.
The key parameters are defined for each dunning procedure and the following information is
needed:
 Dunning interval in days: How many days between each dunning level (in that exemple,
10 days). Determination at which intervals the allocated accounts are to be dunned. During
every dunning run, the system then checks whether the run date is at least this number of
days since the date of the last dunning run. If this is not the case, then a new dunning
notice cannot be created even if new items have become overdue on the account or
individual items have changed their dunning level. This accumulates the overdue items
instead of sending dunning notes in a daily basis for different line items but the same
customer.
 Number of dunning levels: Determines the highest dunning level in a dunning procedure.

P 82 I 119
 Total due items from dunning level: Total due items from dunning level (at which
dunning level do we claim all due items to the customer, meaning all due items will be
printed on the dunning level)
 Number of days arrears and grace days: The minimum days in arrears are the days at
least on item in this account must be delinquent and/or minimum number of days in
between changes of dunning level for a customer the account will not be dunned.
Picture 48: Days arrears and grace days
In the above example, Invoice #4 has more days in arrears than the minimum days in arrears.
Therefore the account will be dunned. The dunned items are Invoices 1, 3, and 4. Invoice 2 will
not be dunned because it is within the grace period.
 Line item grace periods: Number of days for grace period (used in the calculation of
number of days of late payment.
Then, for each dunning level the following criteria’s need to be defined:
:
 Days in areas : Number of days of overdue that determine the dunning level (in that
exemple, when an open item is overdue between 3 days and 12 days, this is level 1.
Between 13 days and 22 days, this is level 2…etc).
P 83 I 119
 Interest indicator: You enter an interest calculation indicator here if you want dunning
interest to be calculated for this account (detailed information needs to be provided, if you
activate that functionality).
Charges and Minimum amounts: Charges and Minimum amounts can be entered in this
feature. The settings here are depending from the currency and the dunning procedure. For
each dunning level, define if there are costs that we are charging the customer per dunning
letter.
For example, if a customer owes us for that dunning level only 1 USD, we are not going send a
dunning letter because the cost of dunning is higher and it doesn’t worth it.
 Always dun: Indicates that a dunning notice is still printed even if no change has been
made to the dunning proposal since the last dunning run (this is usually setup at the last
dunning level).
 Print all items: This indicator determines that all open items are to be printed in the
dunning notices that have this dunning level. The dunning level of the dunning notice is the
same as the highest dunning level of the items in the notice. This is usually flagged for all
levels.
 Payment deadline: Not used


Dunning Text: Depending on MO and customer/vendor reminder you can chose different
dunning texts for a dunning procedure and each dunning level.
There are 4 different texts-blocks that are flexible / free definable per MO’s on each dunning
letter per dunning procedure and dunning level, such as:
 Z_9999_DUNN_REF_TO (where 9999 is the company code number) : this one is usually
filled with contact information (AR clerk name, telephone…)
 Z_9999_DUNN_GENERIC_TXT (where 9999 is the company code number) : this one can
be used for a temporary text for an event in the MO (not often used in other MO’s)
P 84 I 119
 Z_9999_DUNNBOT* (where 9999 is the company code number) : this one is printed at the
bottom at the letter and is usually used for “greetings”.
 Z_9999_DUNNTITLE* (where 9999 is the company code number) : this is the title of each
dunning letter like (“First reminder” or “Nota Informativa”).

Here are an example from MO-Spain :
Level 1 = “Nota Informativa”
Level 2 = “Relacion deuda pendiente”
 Z_9999_DUNN* ((where 9999 is the company code number) : this is the main text of the
letter.
Here are exemple from MO-Spain :

Level 1 : Los informamos que en nuestro sistema aparecen como vencidas y pendientes
de pago las facturas que se detallan abajo. Cualquier consideración que estime oportuna
comunicarnos referente a las mismas le rogamos que se ponga en contacto con nosotros,
preferiblemente a través de correo electrónico a: cuentasclientes@hilti.com o en el
teléfono.
Level 2 : Nos constan como vencidas y pendientes de pago las facturas detalladas abajo.
Les requerimos a su pago inmediato previo al cálculo de intereses de demora autorizados
por la legalidad vigente.
Here are exemple from MO-Sweden :

Level 1 : The invoices listed below remain outstanding on your account. We must now
inform you that, unless we receive your remittance within the next 10 working days from
the date of this letter, we shall commence legal proceedings against you for recovery of
this outstanding debt. If there is a problem with the invoice, please contact us immediately.
Please ignore this letter and accept our apologies if your remittance has crossed with this
letter in the post.
Here are exemple from MO-US :

Level 1 : Just as a reminder, the following invoices are now due.
Level 2 : We have not received a response to our requests for payment on the items listed
below.
Level 3 : It is urgent that you contact us to discuss your past due invoices.
3.4.4 Dunning Process
Based on the dunning procedure that is established in master data at the account level,
notices will generate. With this procedure, you control not only if notices are generated, but
which dunning procedure is used for each customer/vendor. See also Chapter 3.1.6.3
Correspondence.

P 85 I 119
Changes to the master data can be made in Transaction FD02 (SAP Easy Access >
Accounting > Financial Accounting > Accounts Receivables > Master Records > FD02 –
Change). See below the picture.
Picture 49: Change Customer: Company code data
The other field entries are optional:
 Dunning Recipient: Dunning notices may be generated to mail to different partners as

established on the account. The Bill to, Sold to, and/or Payer may be indicated as the
dunning recipient. If this field is empty, the notice defaults to the owner of the receivables,
which is the payer.
 Dunning Block: See above in Chapter 3.4.2.1 about Dunning block on Customer Account
level.
 Dunning Level: Dunning Level of the customer/vendor, which was reached by the last
dunning run. The dunning program sets the dunning level automatically when the customer
or vendor receives a dunning notice.
 Grouping Key: The grouping key represents a rule according to which the open items of
the account are to be grouped together for dunning notices. The grouping key is used in
cases where you do not want the open items of a customer or a vendor to be dunned
together but rather want to create several dunning notices for an account. You must define
one field from the open items for each grouping key. All items, which have the same
contents in this field are then grouped together in a single dunning notice. With credit
memos, ensure that the contents in this field match those in the same field in the invoice; if
P 86 I 119
this is not the case, the items will either be included in a different dunning notice or will not
be dunned at all.
3.4.5 Generate Dunning
3.4.5.1 Process flow
The dunning run can be divided into five steps for clarity. See the picture below.
First step is account selection (selection of the parameters). In this step, the system checks all
accounts which have been entered in the parameters as criteria. If they fulfil the criteria, they
are considered in the dunning run. If not, they are skipped. The criteria established includes
both the dunning procedure, which was entered in master data, and the date of the last
dunning run.

P 87 I 119
1. Account 2. dunning 3. dunning 4. print-out

selection line items accounts
5. updating of the master

data (e.g. dunning level)
Picture 50: The five steps to create a dunning notice
The second step is the dunning line items. In this step, the system checks items on the
selected accounts to see if they are overdue and on which dunning level they should be
dunned. The receivables are reviewed that are due at the due net date. Usually the payment
terms of a credit memo do not apply to dunning.
The third step is the dunning accounts. In this step, the system checks if it is necessary to dun
the account and if so, on which dunning level. This means also prepare the dunning letters
that will be printed in step 4.
In the fifth step master data will be updated. This is triggered automatically through the
dunning run.
3.4.5.2 Work flow
The dunning notice is generated through the Transaction F150 (SAP Easy Access >
Accounting > Financial Accounting > Accounts Receivables > Periodic Processing > FD02 –
Change). You can generate a dunning proposal, create individual or collective dunning runs,
and view the history from this transaction.
For the single work steps see
..\H2_Transactions_BPP\BPP_H20_F150_Consolidated_Dunning.doc

P 88 I 119
SAP offers the following special features:
 Dunning proposal: We recommend highly doing a dunning proposal before the real
dunning run. This one can be viewed and/or changes can be done to the accounts
(Transaction FD02) and Invoices (Transaction FBL5N). Then you have to first delete the
old proposal and rerun the new proposal or final print out.
 Individual dunning notice: In addition to using the conventional dunning run, in which all
overdue items are dunned according to their selection criteria, you can also dun individual
customers or vendors separately. The program only checks the account of the business
partner concerned for items to be dunned and issues a dunning notice where required.
 Dunning of one-time account: You can dun a one-time account just like any other
business partner account. All the items for a one-time account that have the same address
are grouped in one dunning notice. The dunning date and level are updated in the item,
not in the account master record.
 Dunning Currency: If all the open items in an account have been posted in the same
currency (either local currency or a foreign currency), the dunning program uses this
currency. Otherwise, the dunning program uses the local currency of the company code.
The items are displayed in document currency in the dunning notice, and the totals in local
and foreign currency.
 Dunning for head office/branch relationships: If your customer or vendor has both a
head office and branch offices, dunning notices are sent to the head office. However, you
can also send dunning notices to the branch offices.
 Cross-company code dunning: You can combine the overdue items for one customer or
vendor from several company codes in one dunning run, and issue the items in one
dunning notice.

P 89 I 119
3.4.5.3 Selection criteria for exemptions from dunning
The following reasons will trigger that the accounts or invoices will be exempted from dunning:
 Dunning block on account level or on invoice level: as described in earlier in Chapter

3.4.2
 Customers with direct debit: If the payment method is set on incoming payment method
like direct debit, the customer will not receive a dunning notice, because the payment is
triggered by creating a payment run (see Chapter 3.3.3.2). The exemption is if these items
have a payment block. Then the system will include the items for dunning.
 Business partners with a credit balance: One of the parameters checks that the
customer account is > 0. If the customer account has a credit balance, it will not be
dunned. This rule applies even if the credit note/payment is not yet due.
 Accounts in legal dunning procedure: If a legal dunning procedure has been entered in
the customer/vendor master record, a further dunning notice is usually only sent when
further account movements have occurred. If you wish to send a dunning notice although
no further account movements have occurred, in customizing where defining dunning
procedure, this can be set for the individual procedure.
3.4.5.4 View Dunning History
The dunning history provides you with information on all of the dunning runs you have
executed and the dunning notices you have sent (overdue items, dunning totals, and so on). If
required, you can also select by account type, company code, and/or customer or vendor. You
can view the history in Transaction F150 – view dunning history.

P 90 I 119
3.5 Collection Process
3.5.1 Collection Process Overview
This process is necessary to pursue collection of invoices that have exceeded their due date
and are now in arrears. As outstanding and uncollected receivables can have a strong
influence on a company’s success it is necessary to develop a standard collection process.
Through utilisation of this process, external customer accounts with past due invoices can be
identified, the payment history reviewed, and the customer contacted for payment.
3.5.2 Establishing Delinquency
Within each credit control area is an organisational unit that specifies and controls the credit
limit for the customer. For each credit control area, it is the information maintained in master
data that is relevant to the collection process. In addition to the credit limit, other relevant data
includes risk category, limit per order, horizon date, payment terms, and dunning procedure.
These areas are maintained in Credit Management but affect Sales & Distribution through the
processing of sales orders
Refer to Credit Management transaction FD32: Customer Credit Management for central data
input. Navigate to FD32 by Accounting, Financial Accounting, Accounts Receivable, Credit
Management, Master Data, Change. Within central data the credit control area data is input
and maintained.
It is possible to specify credit data centrally for consolidated companies. This centralised data,
such as risk category and credit limit is then valid for all member companies. This means that
open order values and receivables of all member companies are managed in one common
credit management account.
Regardless if the account is consolidated or independent, the collection process relies on the
established credit limits, payment terms, delinquency, and dunning procedure code to monitor
past due invoices and enabling collection.
Additional information and procedural steps for customer credit management information can
be found in the following BPP (Business Process Procedure):
..\H2_Transactions_BPP\BPP_H20_FD32_Credit_Management.doc
3.5.3 Due Date Analysis

P 91 I 119
A due date is established at the time the invoice is created based on the payment terms
maintained in master data for the specific customer account or at the transaction level. Days in
arrears apply from the baseline date for payment. In other words if the terms of payment are
30 days net, then the system only starts to calculate days in arrears in 30 days time. By
specifying the number of days, you can determine by how many days the oldest open invoice
is in arrears. Based on payment terms, the due date is calculated from the invoice date
establishing the number of days late.
3.5.4 Dunning Procedure as a Collection Tool
To assist with collection on accounts that are in arrears, there is an automated dunning
program that can be run. In the customer’s company code data, there is an area to choose a
dunning procedure. Once the dunning procedure has been identified on a customer account,
when the dunning program is ran, notices will be generated to those accounts that are
delinquent. Choose the appropriate code using in transaction FD02 – Change Customer
Company Code Data in company code data on the correspondence tab. This can be
navigated by Accounting, Financial Accounting, Accounts Receivable, Master Records,
Change.
It is the intent of the dunning program that after all parameters have been entered the
generation of dunning notices will be automatic. Entering parameters in the dunning program
provides information on how it has to run. The dunning run then selects the accounts,
examines them for overdue items, checks to see if they have to be dunned, and assigns
dunning levels to them. All dunning data is stored in a list called a dunning proposal that can
be reviewed prior to notice generation.
The dunning proposal can be edited, deleted, and recreated as often as necessary. If desired,
the dunning run can be followed directly by the printout of dunning notices. If one step dunning
notices are printed, the dunning data is immediately updated in the master records and
associated documents. The dunning procedures can be defined by the following parameters:
 Dunning interval in days

 Minimum days in arrears after which a notice will be sent
 Grace periods per line item
 Interest calculation indicator (where applicable)
 Minimum amount or percent of overdue items
 Minimum amount to be reached to calculate interest (where applicable)
Once the dunning procedure is chosen at the company code level, the customer will
automatically receive dunning letters for any open invoices that are in arrears requesting
immediate payment. The minimum days in arrears are the days at least one item in this
account must be delinquent or the account will not be dunned.

P 92 I 119
Picture 51: Invoice Grace periods – Minimum days in arrears on account
In the above example, Invoice #4 has more days in arrears than the minimum days in arrears.
Therefore the account will be dunned. The dunned items are Invoices 1, 3, and 4. Invoice 2 will
not be dunned because it is within the grace period.
The dunning letter will include open invoices that are in arrears beyond the grace period and
that do not have a dunning block. The dunning block is applied on the open item list to indicate
there is a pending complaint, dispute, or other situation that will exempt that particular invoice
from collection.
3.5.5 Accounts Receivable Reports
Using the FI info system you can analyse due dates, the DSO, and overdue items. Within
Accounting, by following the navigation path of Financial Accounting, Accounts Receivable,
Information Systems, Reports for Accounts Receivable Accounting you will gain access to
available reports as they pertain to customer balances.
 Accounts Receivable Information System

 Customer Balances in Local Currency
 Customer Sales
 Transaction Figures: Account Balance
For the collection process, information can be accessed through transaction code
S_ALR_87012167 - the Accounts Receivable Information System. Within this transaction for
due date search, different criteria can be selected to pull different invoice lists. Following are a
few areas on which you can search and pull invoices based on due date and delinquency.
These are all fields maintained on a company code level in master data by customer.
 Company Code
 Business Area
 Country
 Risk Category
P 93 I 119
 Credit Representative Group

 Control Area
 Dunning level
 Accounting Clerk
 Industry
 Planning Group
 Reconciliation Account
These header fields are then broken into sub fields to further narrow the search by set criteria.
Within each of each category, sub categories exist and must be chosen to better identify the
target accounts.
 Group
 Control Area
 Company Code
 Business Area
Picture 52: Accounts Receivable Information systen path
If your company code has established groups of credit representatives that are responsible for
the credit management of specific customers, it is the credit representative group on which you
would search for individualised lists of delinquent accounts. For another individualised list of
delinquent customers, the accounting clerk may also be used if established at the account
level.

P 94 I 119
For a broader list of delinquent accounts, begin the search on the company code, and then
narrow further based on the credit control area. This report will consolidate delinquent
accounts based on the credit control area within the company code for review and collection.
Once the criteria have been chosen by which the due date analysis is to be compiled, the
report can be run. This provides a list of customers with delinquent invoices that require
collection efforts. Within this accounting report, other sort functions can be performed.
Picture 53: Due Date analysis report
3.5.6 Collection Process
Once the list of delinquent accounts is identified, the collection process can begin. Prior to
contacting the customer, a review of all open items should be performed. From the report,
double click on the account you wish to review. This changes the view to the customer line
item display.

P 95 I 119
By viewing the customer line item display, contact can be made that includes all past due
transactions, not just the oldest. By navigating within the Accounts Receivable Information
System report, the customer line item detail can be displayed. For direct navigation access
outside of the A/R report, Refer to transaction code FBL5N: Customer Line Item Display or
navigate by Accounting, Financial Accounting, Accounts Receivable, Account, Display/Change
Line Items.
While reviewing the customer line item display, previous payments will be displayed for
potential billing complaints or parked payments. It is important to briefly view all open invoices
to ensure activity has not transpired on the invoice to prevent collection effort.
Picture 54: Customer Line item display
3.5.7 Collection Credit Master Data
The process of collection entails customer contact to inquire about payment status for
delinquent / in arrears invoices. In order to contact the customer for collection, customer
master data must be accessed. From the main tool bar, in environment choose account master
data. There are several pieces of information within master data that are useful for collection.
The following categories can be located for each customer in master data:

P 96 I 119
 Customer Name
 Customer Account Number
 Customer Address
 Customer Phone Number
 Customer Fax Number
 Control Area
 Risk Category
 Credit Rep Group
 Internal / External review dates
 Credit Limit detail
 Open delivery / order details
 Payment History
In order to be well informed prior to contacting the customer, a quick review of the customer
master data should be completed. It is an indicator of the customer size, past payment cycles,
and the last contact information. If after review it is determined the customer should be
contacted, the phone number or address is provided.
This information can be accessed through the Accounts Receivable Information System report
then from the customer line item detail with direct navigation to the account master data or
refer to transaction code FD03 – Display Customer. Navigate by Accounting, Financial
Accounting, Accounts Receivable, Document, Display.
3.5.7.1 Collection Credit Master Data
From the account master data, other useful areas can be accessed. During contact with the
customer, questions may arise concerning deductions, discounts, interest, line items, or
payment history. All these areas of concern can be easily accessed for the specific customer
through easy navigation from master data and/or line item display.

P 97 I 119
3.6 Bad Debt Reserve
3.6.1 A/R Trade - Classification
As per Financial manual Accounts Receivable Trade are classified as follows:
a) Collectible and undisputed Accounts receivable

This category contains all Accounts Receivable that are collectible and undisputed. For
this category, a bad debts reserve should be calculated for overdue items as defined in
below mentioned table.
b) Doubtful Accounts receivable

The collection of these receivables is doubtful. These receivables should be reserved
individually, irregardless of which aging category applies to them.
c) Reserve for bad debts (adjustment to a) and b) above)
The classification of the Receivables is maintained in the Master Data > Company Code Data
> Account Management as Value Adjustment key field (See description of master records,
chapter 3.1.5). As default the validation should be G1 Collectible and undisputed A/R and
changes require manual intervention.
V.A. Key Purpose

G1 Collectible and undisputed A/R
G2 Doubtful A/R
G3 Manual
G4 Collectible and undisputed A/R (MO FR specific) same valuation as G1

P 98 I 119
3.6.2 Collectible accounts receivable
The collection of such receivables is undoubted and probable. The customer accounts of this
group of A/R have the value adjustment group in the customer master data G1 (Picture 1). A
Bad Reserve should be calculated for past due receivables as explained in Chapter 3.6.4.
Picture 55: Display Customer: Company code data – Customer with undisputed
receivables

P 99 I 119
3.6.3 Reclassification of Doubtful accounts receivable
If the collection is doubtful (e.g. when legal procedure against a not paying customer starts), a
reclassification in the Balance sheet has to be made. The reclassification has to be maintained
in the following steps:
I. Adjustment in the Customer Master Data (individually and manually by customer

account)
a) Set Value Adjustment field to G2 Doubtful A/R
b) Set Order/Delivery Block on the Customer Account
II. Run reclassification in Transaction F101 Receivables/Payables
..\H2_Transactions_BPP\BPP_H20_F101_AR_Doubtful.doc

P 100 I 119
Procedure
I. Adjustment in the Customer Master Data
When you consider a customer as doubtful and uncollectable, change the Value Adjustment
field into G2. This has to be done in the Customer Master Data > Company Code Data >
Account Management (Picture 2).
Picture 56: Display Customer: Company code data – Doubtful customer
Note that this field does not block the Customer Account automatically. This has to be
done manually in another step. Please see Chapter 3.1.5 Customer Master data.
Transactions FD05 – VD05 – XD05
II. Reclassification of Doubtful Accounts in the Balance Sheet
The reclassification of the doubtful accounts receivables in the Balance Sheet is done
as a collective posting. That means that one total amount is reclassified per period and
the subledger accounts (customer account) do not change. The reclassification occurs
from the G/L account 150 010 Doubtful A/R to the G/L account 150 004. The posting is

P 101 I 119
done for all customer accounts classified as doubtful (G2) together every period. In the
next period the posting is reversed and a new posting should be made.
150 004 A/R Trade

Adjustment Account for 150 010 Doubtful A/R
doubtful
30.11.2001 100 100
01.12.2001 100 100
31.12.2001 100 100
In the SAP R/3 system, in order to post the account receivable amount concerning doubtful
customers, the following procedure has to be performed.
Note that the Reconciliation account selects the A/R trade accounts only.
Start SAP Easy Access > Accounting > Financial Accounting > Accounts Receivables >
Periodic Processing > Closing > Regroup > F101 Receivables/Payables (Balance
Sheet Supplement – OL– Analysis
BPP: ..\H2_Transactions_BPP\BPP_H20_F101_AR_Doubtful.doc
The Balance Sheet Key Date determines the cut off date for the open items in the Balance
Sheet that has to be considered in the reclassification.
3.6.4 Calculation of Bad Debt Reserve
3.6.4.1 General Overview
If a particular receivable is doubtful or if it is unlikely you will ever recover it, you must create a
bad debt reserve, or write the debt off. Also for past due invoices, a reserve has to be booked
according to the following table. As a result, the total account receivable is reported at the
estimated settlement value.
The bad debt reserve has to be calculated and posted for both groups (collectible and doubtful
account receivable). However, the valuation (G1, G2) is according to group rules. For local
requirements that differ from the group standard, local groups can be defined (e.g. D1 (MO DE
collective AR), D2 (MO DE doubtful AR).
value valuation days percentage valuate Usage

adjustment key area manually
Organisations that do not have valuataion differences between group and

P 102 I 119
local rules
G1 X1 31 12,5 ARS + local
G1 X1 91 25 ARS + local
G3 X3 0 0 X ARS + local
Organisations that have valuataion differences between group and local rules
G1 D1 1 1 local
G1 D1 31 1 local
G1 D1 91 25 local
G1 D1 181 30 local
G1 D1 361 40 local
G2 D2 0 100 local
G3 D3 0 0 X local
G1 F1 31 8 local
G1 F1 91 12 local
G1 F1 181 26 local
G1 F1 361 80 local
G4 F4 1 26 local
G4 F4 360 65 local
G4 F4 720 82.6 local
G2 F2 0 82.6 local
G3 F3 0 0 X local
G1 Y1 31 12,5 ARS
G1 Y1 91 25 ARS
G1 Y1 181 50 ARS
G1 Y1 361 100 ARS
G2 Y2 0 100 ARS
G3 Y3 0 0 X ARS
G4 Y1 31 12,5 ARS
G4 Y1 91 25 ARS
G4 Y1 181 50 ARS
G4 Y1 361 100 ARS
The bad debt reserve is posted to the following accounts based on the valuation:
valuation area reconciliation account adjust. account target account
Organisations that do not have valuataion differences between group and local
rules
X1 150000 150109 480003
X2 150000 150119 480003
X3 150000 150109 480003
Organisations that have valuataion differences between group and local rules
D1 150000 5150109 5480000
D2 150000 5150119 5480000
D3 150000 5150109 5480000
F1 150000 5150109 5480000
F2 150000 5150119 5480000
P 103 I 119
F3 150000 5150109 5480000

F4 150000 5150109 5480000
Y1 150000 150108 480000
Y2 150000 150118 480000
Y3 150000 150108 480000
3.6.4.2 The valuation
There can be also country specific legal requirements concerning the amounts (percentages)
that should be posted as the bad debt reserve (different valuation classes with different
percentages applied to those classes). The bad debt reserve for country specific legal
requirements will be booked on local valuated accounts.
NOTE:
 The customer accounts showing credit balances are not taken into consideration for the
Bad Debt reserve calculation. They will be reclassified to other A/P.
 Customer accounts showing a net receivable to Hilti, however including unmatched credit
memos – the credit should be matched with the corresponding invoice or in case matching
is not possible, the credit is assigned to the oldest unpaid invoice (Finance Manual,
paragraph 150 Accounts Receivable Trade).
 The accounts receivable balance is, when using the following procedure in SAP, adjusted
by the relevant portion of the refundable value-added tax.
 Provisions for estimated sales returns and credits not yet issued to customers should not
be included in the calculation of the accounts receivable reserve (Finance Manual,
paragraph 150 Accounts Receivable Trade).
 Receivables for which the risk of non-payment is not borne by the reporting Company (e.g.
guaranteed export receivables) should not be included in the calculation of the reserve
(Finance Manual, paragraph 150 Accounts Receivable Trade).
3.6.4.3 SAP R/3 system valuation areas
As was said above, there are 3 groups of customers recognized in the system – undisputed
G1 (and G4 specific for MO FR), doubtful G2 and manual adjusted G3. The percentages applied to the
overdue open items for the bad debt calculation are different for the 2 value adjustment keys
(G1 and G2). And local legal requirements can differ from the group reporting. Therefore,
different valuation areas are customized in the system.
Valuation
area Description
Organisations that do not have valuation differences between group and local
rules
X1 AR regular (local+group)
X2 AR doubtful (local+group)
X3 AR manually (local+group)
Organisations that have valuation differences between group and local rules
P 104 I 119
D1 MO DE AR regular (local)
D2 MO DE AR doubtful (local)
D3 MO DE AR manually (local)
F1 MO FR AR regular (local)
F2 MO FR AR doubtful (local)
F3 MO FR AR manually (local)
F4 MO FR AR regular with special percentages (local)
Y1 Group AR regular (ARS)
Y2 Group AR doubtful (ARS)
Y3 Group AR manually (ARS)
There is a possibility to have more groups of customer accounts if country specific legal rules
require such grouping or in case such regrouping would be necessary for internal purposes.
Valuations areas X1, X2 and Y1, Y2 respect the group rules that are stated in the above
mentioned table.
For valuation e.g. D1, D2, the percentages of the balances for the different aging categories
used for the reserve calculation can be defined by the MO and will be customized during the
implementation.
3.6.4.4 SAP R/3 system bad debt reserve calculation
To perform the bad debt reserve calculation for both A/R Trade and Doubtful A/R, the
valuation runs have to be performed. Basically, the following four different valuation runs have
to be created and run:
I. Valuation run for A/R Trade undisputed according to group rules

II. Valuation run for A/R Trade undisputed according to the local requirements (if
appropriate)
III. Valuation run for Doubtful A/R Trade according to group rules
IV. Valuation run for Doubtful A/R Trade according to the local requirements (if
appropriate)
V.
BPP: ..\H2_Transactions_BPP\BPP_H20_F107_Bad_Debt_Reserve.doc
Enter the following transaction: SAP Easy Access > Accounting > Financial Accounting >
Accounts Receivable > Periodic Processing > Closing > Valuate > F107 – Further valuations
Prerequisite: The selection and update on the customer master is done already regarding
certain criteria.
Organisations that have different valuation rules between group and local law
1. F101 - Regrouping doubtful / normal AR
Group rules
2. F107 - One valuation run with valuation area Y1 for normal AR (customer master - value adj.
key G1 (and G4 for MO FR specific)
P 105 I 119
3. F107 - One valuation run with valuation area Y2 for doubtful AR (customer master - value
adj. key G2)
Local rules
4. F107 - One valuation run with valuation area e.g. D1 for normal AR (customer master -
value adj. key G1)
5. F107 - One valuation run with valuation area e.g. D2 for doubtful AR (customer master -
value adj. key G2)
Organisations that do not have different valuation rules between group and local law
1. F101 - Regrouping doubtful / normal AR
Group and local rules
2. F107 - One valuation run with valuation area X1 for normal AR (customer master - value adj.
key G1
3. F107 - One valuation run with valuation area X2 for doubtful AR (customer master - value
adj. key G2)
To check the results you can use the following transactions:
 SAP Easy Access > Accounting > Financial Accounting > Accounts Receivable >
Account > FBL5N Display/change line items
 Chose the open item list and double click on the line item that you want to see the
details.
 > Environment > Valuation > Display valuation
There is another possibility to see the bad debt reserve on item level by changing the layout.
Go into FBL5N Customer Line Item Display and select the following technical fields (all of them
are named “Valuation difference” > click with the right mouse > choose “show technical field
name”)
Field
Table name technical name FBL5N Valuation Description
BSB
V BWSHB1 1-U_BWSHB1 X1 A/R Regular (local+group)
BSB
V BWSHB2 1-U_BWSHB2 X2 A/R Doubtful (local+group)
BSB
V BWSHB3 1-U_BWSHB3 X3 A/R Manually (local+group)
BSB
V BWSHB4 1-U_BWSHB4 Y1 Group A/R Regular (ARS)
BSB
V BWSHB5 1-U_BWSHB5 Y2 Group A/R Doubtful (ARS)
BSB
V BWSHB6 1-U_BWSHB6 Y3 Group A/R Manually (ARS)
Depending wether you have the same rules for local and group (X1 to X3) or you have
different rules for local and group (Y1 to Y3) you select the fields.
The local bad debt reserve (D1 to D3, F1 to F3) you will not see on the open item list.

P 106 I 119
Example: MO-AT with different rules for local and global (Y1 to Y3), the fields
 1-U_BWSHB4
 1-U_BWSHB5
 1-U_BWSHB5
Valuation adjustment G1 >due to the days overdue 12,5% bad debt reserve net
Valuation adjustment: G2 > 100% bad debt reserve net
3.6.5 Reporting in BW
The information from the bad debt valuation will be loaded into BW for further analysis. The
sequence is defined as follows:
1. Load all calculated values in BW regarding the schedule time the organisations submitted in
the Excel file. (full load)
Transfer_of_Bad.Debt_values_into_BW.xls
2. Load all changed values again in BW. Frango deadline is always at the 5th working day at
the month in 2005. That means afterwards no changes should be done that have an effect on
the reported result. Closing of the periods will be done at the same time. (difference load)
3. If necessary, BW team needs to be contacted to ask for an additional upload whenever

there was a change after the Frango deadline.
3.6.6 Write-off’s of Accounts Receivable
When doubtful accounts are deemed to be uncollectible, they should be charged against the
accounts receivable reserve. This should only happen according to local requirements (e.g.
letter from the lawyer) through a manual booking with the following coding:
150 000 Accounts Receivable 150 119 Doubtful A/R Trade Reserve
P 107 I 119
100 100
0 0
Different reason code can be used to post these write offs.

P 108 I 119
3.6.7 Residual item
Please see following document
H2.5_User_documentation_ZFIRESITEM.doc
3.6.8 Resetting of cleared items
ZFBRA_reset_of_clearing.doc

P 109 I 119
3.7 Hilti Center Sales
Please have a look on separate documentation
H2.5_HiltiCenter_Cash_Sales.doc
3.8 Cross Company processes
3.8.1 Customer Sales via CW of different MO (GPMS-Scenario 2323.01)
Cross_Company_customer_order.xls
3.8.2 Replenishment between 2 plants of different MOs (GPMS-Scenario

2263.01)
Cross_Company_stock_transfer.xls
3.8.3 Errorhandling Idoc
Errorhandling_IDOC.doc

P 110 I 119
3.9 Period Closing A/R
3.9.1 Overview
Before closing a period, several checks should be done. This should prevent that the SD
module and the FI module will have difference. The consequence would be a difference
between the Finance module and the CO-PA Profitability analysis module, because the SD
module will feed the later one (see process flow in Chapter 3.2.1 FI Invoices). The steps are as
follows:
1 Review unbilled deliveries Release any invoices that have been shipped
but not yet billed.
Release Invoice List
2 Review billing documents blocked for Due to certain criteria’s SD documents can get
Accounting blocked for Accounting.
3 Unsolved Incoming Payment
differences
4 Suspense Account Diverse Clearing Accounts should be
reconciled so that only the differences due to
the time lag between bank statement and
detail upload are reflected in their balance
5 Doubtful Accounts Receivable and
Bad Debt Reserve Calculation
3.9.2 Review unbilled deliveries
Because of the above mentioned value flow, it is important to check that all unbilled deliveries
are consistent and properly handled. This concerns mainly the special billing types such as:
 Deferred Billing
 Monthly Billing
 Invoice List
The invoice printing should be schedule automatically over night. In case that this does not
happen, activate the invoice print-out through transaction FV04 – Process billing due list
manually. See also Chapter 2.1.5.2
3.9.2.1 Release Invoice List
All invoices are generated in a batch job overnight. An exception is the Invoice List. The
Invoice List has to be released manually and printed on month end. The invoice data will be

P 111 I 119
transferred from SD into FI with each invoice created, but with a dunning block (A). Once the
Invoice List is released and the document is printed at month end, the following information is
updated:
 Dunning block will be removed

 The reference number of all invoices will be updated to the Invoice List number.
This will allow matching payments and searching for invoices.
 Change due dates to the Invoice List due date.
How to release the Invoice List see Chapter 2.1.6. Invoice List.
3.9.3 Billing documents blocked for Accounting
In the following cases, the billing documents are blocked for release to the accounting
department. See also Chapter 2.1.7 Integration with Accounting:
 Billing document incomplete: This occurs if e.g. the customer master record of the payer
has not yet been maintained by the accounting department. The report Transaction F.2D –
Sales – Accounting will give a list with the sales partner that should be maintained. You will
find this report on SAP Easy Access > Accounting > Financial Accounting > Accounts
Receivables > Master Records > Compare > Transaction F.2D Sales – Accounting. See
Chapter 3.1.4 Customer master record creation.
 Errors in pricing: If the pricing is not correctly set up for a new material, e.g. if the
accounting key is not defined with the corresponding condition type.
 Errors in account assignment: Errors can occur if a new material is set up, but the
account assignment is not fully defined. This can be related to the account assignment
group of the payer or the account assignment group of material (Customizing Transaction
code VKOA)
 Manual block on accounting documents: In the creation of the invoice, a manual block
for accounting documents can be set. Even though this feature should not be used, it is a
possibility for errors. To unblock a billing document see Chapter 3.1.16.
In order to prevent differences between the SD module and FI module, the report Transaction
FVX3 – Blocked billing documents should be run. For proceeding see
..\H2_Transactions_BPP\BPP_H20_FX3_Release Billing Doc for Accounting.doc
3.9.4 Unsolved incoming payment differences
For clearing the incoming payment differences, see Chapter 3.3.2 Payment – clearing and
payment differences.

P 112 I 119
3.9.5 Suspense account
The Clearing Accounts for Incoming payments have to be reconciled. Best practice they
should only have a balance due to time difference between receipt of payment (time of
applying on customer account) and incoming payment on bank statement. Therefore any
unsolved differences should be cleared.
3.9.6 Doubtful accounts and bad debt reserve calculation
For the Calculation and Handling of doubtful accounts and bad debt reserve calculation see
Chapter 3.6 Bad Debts Reserve.

P 113 I 119
Information Systems
3.9.7 Information Systems
The financial information system enables you to run evaluations for the general ledger,
accounts receivable, and accounts payable.
The Financial Accounting application component is the primary database of the financial
information system. This application is a central data pool that collects all accounting data from
within an organization. The function of the financial information system is to evaluate this
extensive database online and display the information on the screen in an easy-to-read form.
Within the accounts receivable and payable information system, you can analyze individual
operational areas as often as you require. You can evaluate, among other things, payment
history, cash discount history, currency exposure among customers and vendors, or aging
reports.
You can use the Information System for Accounts Receivable to execute customer evaluations
online, structured according to your own requirements. Due date analysis, payment history
evaluations, and DSO figure calculations are just some of the functions you can perform. You
can summarize or breakdown the data produced in these reports - from open item display to
the customer credit management data - to whatever degree you require.
3.9.8 Accounts Receivable Information Systems
You can access the Information Systems report menu by Accounting, Financial Accounting,
Accounts Receivable, Information Systems Reports for Accounts Receivable.
A section of reports in this transaction is navigated through use of one or more report trees. A
report tree is a hierarchical structure containing various reports and lists generated by reports.
To access information within the tree, you must click on the file folder and continue expanding
the files to the detailed level to reach the criteria by which you wish to sort.
The data that appears in the Information Systems lists is obtained from many sources and can
be searched on by differing criteria to determine the status of the customer.
The various sources of information include customer master record, oldest item detail, credit
overview information, and both the FI and SD Information systems.

P 114 I 119
Picture 57: Sources of information
3.9.9 Information Systems
Within Accounting’s Information Systems reporting, there are three different categories of
report types.
 Customer Balances
 Customers: Items
 Master Data
Within each of these, there are multiple report options. These reports will pull lists by which
you can review, evaluate, and investigate customer detail information.
3.9.9.1 Customer Balances
Within Customer Balances, the reports are run through utilization of the report tree hierarchy
as well as query execution. The options under customer balances are as follows.
 Accounts Receivable Information Systems

P 115 I 119
 Customer Sales
 Transaction Figures: Special Sales
 Transaction Figures: Sales
Within Information Systems for Accounts Receivable, the hierarchy tree opens to provide the
following multiple search options:
 Accounts Receivable Information System

 Due Date Analysis
 Payment History
 Currency Analysis
 Overdue Items
 DSO Analysis
 Terms Offered/Taken
Picture 58: Accounts Receivable Information Path
3.9.9.2 Customer Items
Within Customer Items, the reports run through query execution only. Following are the
standard customer items report options

P 116 I 119
 Due Date Analysis of Open Items
 List of Customer Open Items for Printing
 Open Items – Customer Due Date Forecast
 Customer Evaluation of OL Sorted List
 Customer Payment History
 Customer Open Item Analysis by Balance of Overdue Items
 List of Cleared Items for Printing
 List of Down Payments Open on Key Account Date Customers
Within each report, there are many fields by which the query can be executed. Both, customer
account number and company code, appear as options in all reports.
Each query can be more defined or more widely expanded based on other specifics. For
example, the narrow search parameter of customer account can be expanded to a wider
search on the company code only, pulling a list of all customers meeting the search criteria.
3.9.9.3 Master Data
Within Customer Master Data, the reports run through query execution only with the absence
of the hierarchy tree option. Following are the standard master data report options
 Master Data
 Customer Lists
 Address List
 Display Changes to Customers
 Display / Confirm Critical Customer Changes
 Customer Master Data Comparison

P 117 I 119
3.9.10 Report Transaction Navigation
All reports can be accessed by the transaction codes listed on the following table or through
the navigation path Accounting, Financial Accounting, Accounts Receivable, Information
Systems Reports for Accounts Receivable.
Customer Balances Customer

Items
Report Name: Transaction Code: Report Name: Transaction Code:
A/R Information Systems S_ALR_87012167 Due Date Analysis Open Items S_ALR_87012168
Customer Balance - Local Cur S_ALR_87012172 List of Open Items for Printing S_ALR_87012173
Customer Sales S_ALR_87012186 Open-Customer due date forecast S_ALR_87012175
Transaction Figures: Balance S_ALR_87012169 Customer evaluation of OL Sorted S_ALR_87012176
Transaction Figures: Special S_ALR_87012170 Customer Payment History S_ALR_87012177
Transaction Figures: Sales S_ALR_87012171 Customer Open Item Analysis/Overdue S_ALR_87012178
List of Cleared Items for Printing S_ALR_87012198
List of Down Payments Open-Key Acct S_ALR_87012199
Accounts Receivable Information Master

Systems Data
Report Name: Transaction Code: Report Name: Transaction Code:

Due Date Analysis S_ALR_87012167 Customer Lists S_ALR_87012179
Payment History S_ALR_87012167 Address List S_ALR_87012180
Currency Analysis S_ALR_87012167 Display changes to Customer S_ALR_87012182
Overdue Items S_ALR_87012167 Display Critical Changes S_ALR_87012183
DSO Analysis S_ALR_87012167 Customer Master Data Comp S_ALR_87012185
Terms Offered/Taken S_ALR_87012167
Picture 59: Accounts Receivale Reports
As previously stated, the report A/R information systems is an upper level report within the
Customer Balances option list. This is the report category that utilizes the hierarchy tree. To
gain access to the sub-reports found within this tree, click on the file folder and continue
expanding the tree in the area of focus.
Once accessing the actual customer information within the report, double click on the customer
to be taken into the Customer Line item Display (transaction code FBL5N). From here, there
are many other navigation options available by utilizing the menu or mouse navigation tools.
P 118 I 119
Following is an overview of the complete report options and categories:
 Accounts Receivable Information Systems
 Due Date Analysis
 Payment History
 Currency Analysis
 Overdue Items
 DSO Analysis
 Terms Offered/Taken
 Customer Sales
 Transaction Figures: Special Sales
 Transaction Figures: Sales
 Due Date Analysis of Open Items
 List of Customer Open Items for Printing
 Open Items – Customer Due Date Forecast
 Customer Evaluation of OL Sorted List
 Customer Payment History
 Customer Open Item Analysis by Balance Overdue Items
 List of Cleared Items for Printing
 List of Down Payments Open on Key Account Date Customers
 Master Data
 Customer Lists
 Address List
 Display Changes to Customers
 Display / Confirm Critical Customer Changes
 Customer Master Data Comparison
3.10 Employee sales
Employee_sale_Salary deduction.doc
3.11 Instant message
H2.8_User_documentation_Instant_message_for_creditrep.doc

P 119 I 119
3.12 PO verification
H2.7_User_documentation_PO_verification.doc
3.13 Bounced cheques
H2.7_User_documentation_bounced_cheques.doc
3.14 UID-Nr. Check
H2.8.1_User_documentation_UID_NR_check_MO_AT.do
3.15 D&B interfaces
H2.7_D&B_interfaces.doc


H2.8.1 User Documentation AR

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

H2.8.1 User Documentation AR

Uploaded by

Copyright:

Available Formats

Global Process Management System

Content Type of change Update for

3.1 Customer Master Data............................................................................6

3.2 FI Invoices/Credit Memos.....................................................................53

3.3 Accounts Receivable Payment Application.......................................63

3.4 Dunning Process...................................................................................77

3.5 Collection Process................................................................................87

3.6 Bad Debt Reserve.................................................................................94

Valid on day of print 13/07/2006 09:12:00 - For internal use only -

3.6.4.4 SAP R/3 system bad debt reserve calculation.......................................................101

3.7 Hilti Center Sales.................................................................................105

3.8 Cross Company processes................................................................105

3.9 Period Closing A/R..............................................................................106

3.10 Employee sales...................................................................................114

3.11 Instant message..................................................................................114

3.13 Bounced cheques...............................................................................115

3.14 UID-Nr. Check......................................................................................115

3.15 D&B interfaces......................................................................................115

Valid on day of print 13/07/2006 09:12:00 - For internal use only -

Chapter Comment Release

Valid on day of print 13/07/2006 09:12:00 - For internal use only -

3.1 Customer Master Data

3.1.1 Account Groups Overview

A master record depends on the account group.

Table 1: Account Group with description

Account From number To number Description

Valid on day of print 13/07/2006 09:12:00 - For internal use only -

A customer master record has three segments:

Picture 1: Customer master record segments

Valid on day of print 13/07/2006 09:12:00 - For internal use only -

A customer master record:

 Is the only master data element for A/R

3.1.2 Partner functions

Picture 2: Partner functions

Valid on day of print 13/07/2006 09:12:00 - For internal use only -

SAP standard customer account number assignment

Internal customer account # = SD partner function

Functions in Sales Area:

As long as the same legal entity is playing all SD partner functions

Picture 3: Customer account assignment

Valid on day of print 13/07/2006 09:12:00 - For internal use only -

SD Partner Functions: One legal entity = One customer account #

Customer account # on customer document layout

Templ ate_d dmmyy

Picture 4: Customer account assignment – customer playing all business partner

Valid on day of print 13/07/2006 09:12:00 - For internal use only -

SD Partner Functions: Example - More than one customer account #

Functions in Sales Area:

Picture 5: Customer account assignment – customer playing more than one

Order Doc. Flow & SD Partner Functions in Example

Order Entry Credit Check Delivery Invoicing

Transaction VA01 VKM1 VL01N VF01

Internal Cust. 10000120 10000031 10000123 10000031

Picture 6: Customer account assignment – document flow

Valid on day of print 13/07/2006 09:12:00 - For internal use only -

For Hilti customer account number is “sold-to-party” account number.

Customer account number

Customer account number should be used in document layout

Customer Account Sold-to-party All CRM documents

Different payer Different Ship-to

Arakawa 1 Invoice Arakawa 2 Site 2 Delivery

Picture 7: Customer account number – sold to party

Valid on day of print 13/07/2006 09:12:00 - For internal use only -