Interview Questions and Answers for SAP Accounts Receivable

1. Explain ‘Customer/Vendor Master Records?

2. Who is an ‘Alternate Payee’?
3. What is the ‘Trading Partner’ concept?
4. Explain ‘Tolerance’ in Transaction Processing?
5. What is ‘Dual Control’ in Master Records?
6. What is a ‘Bank Director’ in SAP?
7. What is a ‘House Bank’?
8. Explain a ‘Sales Cycle’ in SAP?
9. Explain ‘Automatic Account Assignment’ in SD?
10. Outline ‘Credit Management’ in SAP?
11. What is a ‘Credit Check?
12. Differentiate ‘Static Credit Check’ from ‘Dynamic Check?
13. List the Reports in ‘Credit Management?
14. How does ‘Partial Payment’ differ from ‘Residual Payment’?
15. What is ‘Payment Advice’?
16. Describe ‘Lockbox’ Processing?
17. How can ‘Reason Codes’ Help with Incoming Payment Processing?
18. What is ‘Dunning’ in SAP?
19. What is a ‘Dunning Procedure’?
20. What is the ‘Dunning Area’?
21. Describe the ‘Dunning’ Process?
22. Can you ‘dun’ customers across ‘Clients’ in a Single ‘Dunning Run’?
23. What differentiates one ‘Dunning Level’ from another?
24. How many ‘Dunning Levels’ can be defined?

1. Explain ‘Customer/Vendor Master Records?

There are three categories of data maintained in a typical master record for a customer:
�� General Data
�� Company Code Data
�� Sales Area Data (for customers)/Purchasing Organization Data (for vendors)

General Data includes general information such as account number, name, telephone,
bank information, trading partner, vendor (if the customer is also a vendor), group key,
bank key, bank account, alternate payee, etc., which are common to all the Company
Codes using this master. Company Code Data comprises terms of payment, payment
methods, tolerance group, clearing with vendor, dunning data (dunning procedure,
dunning recipient, dunning block, dunning clerk, etc.), reconciliation account, sort key,
sales area (purchasing organization in the case of vendor master), head office, etc.
Except for sales (purchasing) related information, all other details are usually
maintained for the finance people who can also access the sales data when the master
is maintained ‘centrally.’

Sales Area Data in the Company Code area of a Customer master record contains the
following:
�� Order-related data (sales district, sales office, sales group, customer group, etc.)
�� Price-related data (pricing group, pricing procedure, etc.)
�� Shipping data (shipping strategy, delivery priority, etc.)
�� Billing data (payment terms (different from the payment terms maintained at the
Company Code level), account assignment group, etc.)

Purchasing Organization Data in the Company Code area of a Vendor master record
contains the following:
�� Conditions (order currency, payment terms, Incoterms, minimum order value, etc.)
�� Sales data (a/c with Vendor)
�� Control data (as in the screen shot below)

During creation of a master record, the system checks for ‘duplicates’ for the same
customer which is achieved by the system through the ‘Search-Id’ (Match Code)
configured on the customer’s address information.

As in the case of the GL account master record, the creation of the customer/ vendor
master record is also controlled by the ‘Account Group,’ which is called ‘Customer
Account Group/Vendor Account Group’ (CPD/CPDL/KREDI/LIEF) and controls the
numbering of customer/vendor master records, field status, whether an account is a
regular one or a ‘One Time’ account, etc.

Open table as spreadsheet Activity in Accounting Centrally

Customer Vendor Customer Vendor
Create FD01 FK01 XD01 XK01
Change FD02 FK02 XD02 XK02
Display FD03 FK03 XD03 XK03
Block/Unblock FD05 FK05 XD05 XK05
Mark for Deletion FD06 FK06 XD06 XK06

2. Who is an ‘Alternate Payee’?

A customer who pays on behalf of another customer is known as an ‘Alternate Payee’
(or Alternate Payer). Though the alternate payee pays on behalf of another, the system
maintains all the transaction details in the account of the original customer. Designating
‘alternate payee’ does not absolve the customer of his/her obligation for payment.

The ‘alternate payee’ can be maintained in Client-specific data or in the Company Code
area. When maintained in the Company Code area you can use that payer only in that
Company Code; if defined at the Client level you can use it across all Company Codes.
There are three ways to ‘select’ the alternate payee when an invoice is processed:

1. The alternate payee (say, 1000) entered in the customer master record is the one
selected by the system as the default.
2. When there is more than one alternate payer (say, 1000, 1900, 2100, etc.) defined for
a single customer in the master record (you will do this by clicking on the ‘allowed payer’
button and create more than one payer), you may select a payer (say, 2100) (other than
the default, 1000) while processing the invoice. Now the system will ignore the alternate
payer (1000) coming from the master record.
3. If you have put a check mark in the ‘individual entries’ check box in the ‘alternate
payer in document’ section in the customer master record, then this will allow you to
propose a new alternate payer, say, 3000 (other than those already defined in the
system). Now, after defining this alternate payer you can use it to process the invoice. In
this case, the alternate payer (3000) takes precedence over the payers (1000 and 2100)
in step 1 and 2 above.

3. What is the ‘Trading Partner’ concept?

The ‘Trading Partner’ concept is used to settle and reconcile ‘inter-company
transactions,’ both sales and purchases. This is generally achieved by entering the
Company-ID (not the Company Code) to which a customer belongs in the ‘trading
partner’ field under the tab ‘Account Control’ in the customer master record. You can do
a similar entry in the vendor master record.

4. Explain ‘Tolerance’ in Transaction Processing?

‘Tolerances’ are defined in the system to facilitate dealing with the differences arising
out of accounting transactions and to instruct the system on how to proceed further.
Normally, you define tolerances (either in ‘absolute terms’ or in ‘percentages’) beyond
which the system will not allow you to post a document should there be a difference.

In SAP, tolerances are defined per Company Code and there are several types:
�� Employee tolerance
�� Customer/vendor tolerance
�� GL account clearing tolerance

You will define an ‘employee tolerance group’ in the system and assign the employees
to these groups.

While defining the tolerance group you will specify:

1. Upper limits for various posting procedures

�� Amount per document
�� Amount per open account item
�� Cash discount, in percentage
2. Permitted payment differences
How much over or under payment an employee is allowed to process. This is defined
both in absolute values and in percentages. Besides defining the above two, at the
Company Code level, you will also define similar tolerances for customer/vendor
tolerance group. Once defined, each of the customers (vendors) is assigned to one of
these groups. Here also, you define the ‘permitted payment differences’:
While processing, the system compares the tolerance of an employee against the
customer tolerance (or vendor tolerance or the GL) and applies the most restrictive of
the two.

5. What is ‘Dual Control’ in Master Records?

‘Dual Control’ helps to prevent unauthorized changes to the important and ‘sensitive’
fields in the master records in the system. (All such sensitive fields are defined in the
Table T055F when customizing the application. And these fields are defined per
Company Code and per Client.) Consider, for example, a sensitive field such as
‘payment block’ in a vendor master record. When a user changes this field’s content,
the system requires another user (usually of higher authority) to approve this change
and an audit trail is maintained of all such changes. Unless ' the change is approved, in
this example, this particular master is blocked by the system for considering the same in
the next ‘payment run.’

Open table as spreadsheet Activity Customer Vendor

Display changes (accounting area) FD04 FK04
Display changes (centrally) XD04 XK04
Confirm changes, individually FD08 FK08
Confirm changes, in a list FD09 FK09

6. What is a ‘Bank Director’ in SAP?

SAP stores the master data (details such as bank key, bank name, bank country, bank
address, and so on) relating to the banks in the ‘Bank Directory’ (Table: BNKA).
Remember, the ‘bank masters’ are not created in the application but in the
implementation side using the IMG. (Of course, you can also create the bank master in
the application side in FI-TR and not in FI-GL or AP or AR.) However, if you are in the
process of creating a master record for a vendor or a customer and you enter some
bank details, which the system does not find in the ‘Bank Directory,’ then the system
automatically brings in the relevant screens for you to maintain and update the bank
details in the bank directory.

You may create the bank directory in two ways:

1. Manually (IMG path: Financial Accounting>Bank Accounting>Bank Accounts>Define
‘House Banks’)
2. Automatically (by importing the bank details using a special program)

7. What is a ‘House Bank’?

A ‘House Bank’ is the bank (or financial institution) in which the Company Code in
question keeps its money and does the transactions from. A house bank in SAP is
identified by a 5 character alphanumeric code. You can have any number of house
banks for your Company Code, and the details of all these house banks are available in
the ‘bank directory.’

Each ‘house bank’ in the system is associated with a country key (U.S., IN, etc.)
representing the country where the bank is located, and a unique country specific code
called a ‘bank key.’ The system makes use of both the ‘country key’ and the ‘bank key’
to identify a ‘house bank.’
�� For each of the ‘house banks,’ you can maintain more than one bank account;
each such account is identified by an account ID; i.e., Chek1, Check2, Pybl1, etc. Here,
‘Chek1’ may denote Checking account 1, ‘Pybl1’ may denote Payables account 1, and
so on. You may name the accounts in a way that it is easily comprehensible. The
‘Account ID’ is referenced in the customer/vendor master record and it is used in the
payment program by the system.
�� For each ‘account ID’ you will also specify the bank account number (maximum
length of this identifier is 18 characters). You may name this in such a way that it is also
easily comprehensible.
�� For each ‘bank account number’ so defined in the ‘house bank,’ you need to create
a GL account master record, and while doing so you will incorporate the ‘house bank id’
and the ‘account id’ in that particular GL master record.

8. Explain a ‘Sales Cycle’ in SAP?

A ‘Sales Cycle’ comprises all activities including quotation/inquiry, sales order, delivery,
billing, and collection.

The following are the various processes within SAP that complete a sales cycle:
Typically, the following are the documents created during a sales cycle:
�� Inquiry
�� Quotation
�� Sales Order
�� Delivery Note
�� Goods Issue
�� Order Invoice
�� Credit/Debit Note

9. Explain ‘Automatic Account Assignment’ in SD?

During goods issue in the sales cycle, the system is usually configured to update the
relevant GL accounts automatically and to create the relevant accounting documents.
This customization in IMG is also called material account assignment and is achieved
through a number of steps as detailed below:
1. Determine ‘valuation level’ (Company Code or plant).
2. Activate ‘valuation grouping code’ and link it with the ‘chart of accounts’ for each
‘valuation area.’
3. Link ‘valuation class’ with ‘material type’ (FERT, HAWA, HALB, etc.) with the ‘account
category reference’ (combination of valuation classes).
4. Maintain ‘account modification codes’ for ‘movement types.’
5. Link ‘account modification codes’ with ‘process keys’ (transaction/event keys).
6. Maintain a GL account for a given combination of ‘chart of accounts’+ ‘valuation
grouping code ‘+’ account modification code ‘+’ valuation classes.’

The process of Automatic Account Determination is as follows:

1. Depending on the ‘plant’ entered during goods issue (GI), the ‘Company Code’ is
determined by the system which in turn determines the relevant ‘Chart of Accounts.’
2. The plant thus entered in goods issue determines the ‘valuation class’ and then the
‘valuation grouping code.’
3. The ‘valuation class’ is determined from the ‘material master.’
4. Since the ‘account modification code’ is assigned to a ‘process key’ which is already
linked to a ‘movement type,’ the ‘transaction key’ (DIF, GBB, AUM, BSX, etc.)
determines the ‘GL account’ as posting transactions are predefined for each ‘movement
type’ in ‘inventory management.’

10. Outline ‘Credit Management’ in SAP?

‘Credit Management’ helps to determine credit limits of customers, aids in the creation
of ‘credit check’ policies, as well as helps companies monitor and evaluate their
customers. This is a cross-functional responsibility in SAP, covering both the Sales and
Distribution and Financial Accounting modules. As in the case of any automated
process such as dunning, payment, etc., credit management in

SAP requires certain prerequisites be defined beforehand:

1. Customer master data has been created both in SD and FI.
2. Credit control area has been defined and assigned to a Company Code.

SAP makes use of the concept ‘credit control area’ for credit management. As explained
elsewhere, the credit control area is an organizational element defined to which one or
more Company Codes are attached. In the case of customers defined under more than
one Company Code, they may fall under different credit control areas. But note that:
�� A Client can have more than one credit control area, but the converse is not true:
one credit control area cannot be assigned to more than one Client.
�� A credit control area can be assigned to more than one Company Code, but the
converse is not true: one Company Code cannot be assigned to more than one credit
control area.
While defining the credit limit for a customer:
�� You will define a maximum limit per credit control area (Example: Credit Control
Area AAAA->USD 500,000, Credit Control Area BBBB ->USD 200,000)
�� You will define a global maximum limit for all credit control areas put together
(USD 600,000)
3. Credit data (per credit control area ‘maximum limit’ as well as the ‘total’ for all areas,
in the control data screen) for the customer has been created.
4. Risk categories have been defined and assigned to customers.
5. Credit groups (document credit group) for document types have been defined.
Document credit groups combine order types and delivery types for credit control.
6. Defined, in SD, at what time (when order is received or when a delivery is made, etc.)
the credit check should happen.

The credit management process starts when a sales order is entered in SD. Imagine
that this results in exceeding the credit limit defined for the customer. Now:
a. The system creates three comparison totals considering
(1) open receivables,
(2) sales order values, value of goods to be delivered and the billing document value
from SD,
(3) special GL transactions (e.g., ‘down payments’ and ‘bills of exchange’).
b. Based on (a) above the system throws an
(1) error message and prevents saving the order or
(2) a warning message, and the system does not prevent saving, but the order is
‘blocked.’
c. The Credit representative, using information functions (SD information system, FI
information system, credit overview, credit master list, early warning list, oldest open
item, last payment, customer master, account analysis, etc.), processes this blocked
order either (1) from the ‘blocked SD documents list’ or (2) the mailbox, and releases
the order, if necessary.
d. Delivery is created, the billing document is generated and posted, and A/R is
updated.
e. Customer pays the invoice and A/R is posted.

11. What is a ‘Credit Check?

A ‘Credit Check’ is defined for any valid combination of the following:
�� Credit control area
�� Risk category
�� Document credit group

12. Differentiate ‘Static Credit Check’ from Dynamic

Check?
Under ‘Static Credit Check,’ the system calculates the credit exposure of a particular
customer as the total of:
�� Open order (delivery not yet done)
�� Open delivery (value of deliveries yet to be invoiced)
�� Open billing documents (not transferred to accounting)
�� Open items (AR item not yet settled by the customer)
Customer’s credit exposure is not to exceed the established credit limit.
The ‘Dynamic Credit Check’ is split into two parts:
�� Static limit: Total of open items, open billing, and open delivery values.
�� Dynamic limit (Open Order Value): The value of all undelivered and partially
delivered orders totalled and stored on a time-scale in the future (10 days, 1 week, etc.)
known as a ‘horizon date.’ During the ‘dynamic credit check,’ the system will ignore all
orders beyond the ‘horizon date.’ The sum total of ‘static’ and ‘dynamic’ limits should not
exceed the credit limit established for the customer.

13. List the Reports in Credit Management?

SAP provides you with the following Reports in Credit Management:

 RFDKLI10 Customers with missing Credit Data

 RFDKLI20 Re-organization of Credit Limit for Customers
 RFDKLI30 Short Overview of Credit Limit
 RFDKLI40 Overview of Credit Limit
 RFDKLI41 Credit Master Sheet
 RFDKLI42 Early Warning List (of Critical Customers)
 RFDKLI43 Master Data List
  RFDKLI50 Mass change of Credit Limit Data
 RVKRED06 Checking Blocked Credit Documents
 RVKRED08 Checking Credit Documents which reach the Credit Horizon
 RVKRED09 Checking the Credit Documents from Credit View
 RVKRED77 Re-organization of SD Credit Data

14. How does ‘Partial Payment’ differ from ‘Residual

Payment’?
When processing the ‘incoming payment’ to apply to one or more of the ‘open items’ of
a customer, there may be a situation where the incoming payment is more than the
‘tolerances’ allowed. In this case, you can still go ahead and process the payment by
resorting either to a Partial Payment or a Residual payment.

A Partial payment results in posting a credit to the customer’s ‘open item,’ but leaves
the original item intact. As a result, no open item is cleared. During partial payment, the
system updates the ‘invoice reference’ and ‘allocation’ fields. In contrast to a partial
payment, the Residual payment clears the particular ‘open item’ against which the
payment is applied. However, since there are not enough amounts to clear the entire
open item, the system creates a new open item, which is the difference between the
original invoice item and the payment applied. Note that the new invoice/open item
created by the system will have the new document date and new baseline date though
you can change these dates.

15. What is ‘Payment Advice’?

‘Payment Advice’ helps in the automatic searching of ‘open items’ during the ‘clearing’
process to find a match for an ‘incoming payment.’ This is possible because you can
use the ‘payment advice’ number instead of specifying parameters in the ‘selection
screen.’ A typical payment advice may contain details such as document number,
amount, currency, reason for underpayment, etc. The payment advices are of various
categories; the first 2 digits of the payment advice number help to differentiate one
payment advice from another:

 Bank advice
 EDI advice
 Lockbox advice (created during the clearing process, available in the system
whether clearing was successful or not)
 Manual advice
 Advice from a bank statement

Most of the payment advices are deleted as soon as the clearing is successful in the
system.

16. Describe ‘Lockbox’ Processing?

‘Lockbox’ processing (configured in the FR-TR module) of incoming payments is used
predominantly in the United States. Here, the bank receives the checks from customers
as incoming payments, creates payment advice for each of these customer check
payments, and informs the payee of the payment, in BAI file format. This lock box file is
sent to the payee who imports the details into the system using this electronic file. The
system updates the payments into the GL by way of ‘batch input’ processing.

17. How can ‘Reason Codes’ Help with Incoming

Payment Processing?
‘Reason Codes’ configured in the system help to handle the ‘payment differences’ of
individual open items in an invoice (either using payment or advice or in the normal
course). To each of the reason codes, you will define the ‘posting rules’ and the GL
accounts in the IMG. Once done, when there is a payment difference against a
particular open item, the system looks for the reason code:

�� When the ‘charge-off indicator’ has been set for that reason code, then the system
posts the payment difference to a GL account. When this indicator is not set, then a new
open item is created for the payment difference.

�� When ‘disputed item indicator’ has been set, then the system ignores these line
items when counting for the customer’s credit limit.

18. What is ‘Dunning’ in SAP?

The SAP System allows you to ‘dun’ (remind) business partners automatically. The
system duns the open items from business partner accounts. The dunning program
selects the overdue open items, determines the dunning level of the account in
question, and creates dunning notices. It then saves the dunning data determined for
the items and accounts affected. You can use the dunning program to dun both
customers and vendors. It may be necessary to dun a vendor in the case of a debit
balance as a result of a credit memo. Dunning is administered through a Dunning
Program, which uses a dunning key (to limit the dunning level per item), a dunning
procedure, and a dunning area (if dunning is not done at the Company Code level).

19. What is a ‘Dunning Procedure’?

SAP comes equipped with a number or ‘Dunning Procedures,’ which you can copy, or
you can create your own:

A dunning procedure controls:

 Dunning interval/frequency
  Grace days/minimum days in arrear
 Number of dunning levels (at least one level)
 Transactions to be dunned
 Interest to be calculated on the overdue items
 Known or negotiated leave, if any, which needs to be considered when selecting
the overdue items
 Company Code data such as

(a) Is dunning per ‘dunning area’?

(b) Is dunning per ‘dunning level’?
(c) Reference Company Code,
(d) Dunning Company Code, etc.

 Dunning forms/media to be selected for the dunning run

20. What is the ‘Dunning Area’?

The ‘Dunning Area’ is optional and is required only if dunning is not done at the
Company Code level. The Dunning area can correspond to a sales division, sales
organization, etc.

21. Describe the ‘Dunning’ Process?

The ‘Dunning Process’ involves three major steps:
1. Maintaining the parameters for the dunning run
2. Creating/editing the dunning proposal generated by the system
3. Printing dunning notices

1. Maintaining Dunning Parameters

As the first step in dunning, you need to maintain certain parameters, which identify the
current dunning run. Entering the date of execution and the dunning run identifier is the
starting point, after which you will continue to maintain other parameters such as:
i. Dunning date to be printed on the notice
ii. Document posted up to
iii. Company Code
iv. Account restrictions (optional)

Now, you can save the parameters and display the log generated (to see if there were
any errors), the dunning list (list of accounts and items), and some dunning statistics
(blocked accounts/items, etc.).

2. Creating a Dunning Proposal

Once scheduled, the ‘dunning program’ prepares the ‘dunning proposal’ as described
below:
a. The Dunning Program determines which accounts to dun:
i. System checks the fields ‘Dunn procedure’ and ‘Last dunned’ in the customer master
record to determine whether the arrears date or the date of the last dunning run lies far
enough back in the past.
ii. Checks whether the account is blocked for dunning according to the dunning block
field in the customer master record.
iii. Program processes all open items relating to the accounts thus released in
(ii) above that were posted to this account on or before the date entered
in the field ‘Documents posted up to.’
iv. Program checks all the open items, as released in (iii) above, in an
account to decide:
�� Is the item blocked?
�� Is it overdue according to the date of issue, the base date, the
payment conditions, and the number of grace days granted?
v. Program then proceeds to process all open items thus released in (iv):
�� How many days the item is overdue
�� Which ‘dunning level’ for a particular open item
vi. The program determines the highest ‘dunning level’ for the account based on (v)
above. The highest ‘dunning level’ determined is stored in the master record of the
account when you print the letters. This ‘dunning level’ determines the ‘dunning text’
and a ‘special dunning form,’ if defined.
vii. The program then proceeds to check each account:
�� Does the customer/vendor have a debit balance with regard to all open overdue
items selected?
�� Is the total amount to be dunned and the percentage of all open items more than
the minimum amount and percentage defined in the ‘dunning procedure’?
�� Is the ‘dunning level’ for the account or the overdue items higher than it was for the
last ‘dunning run’? If not, are there new open items to be dunned (with a previous
dunning level of 0)? If not, does the ‘dunning procedure’ for this level specify that
dunning be repeated?
b. The program creates the dunning proposal list
c. Edit dunning proposal list
i. You can edit the Dunning Proposal to:
�� Raise or lower the ‘dunning level’ of an item
�� Block an item from being dunned
�� Block an account for the current ‘dunning run’ or remove the block
�� Block an account in the master record for dunning or remove the block
�� Block a document for dunning or remove the block
ii. You can view the sample print out to ascertain how the printed notice will look
(a maximum of 10 notices can be seen on the screen).
iii. You may also display ‘logs’ to see the changes made in the editing earlier, as a
confirmation of what you wanted to change in the system generated proposal earlier. If
necessary, you can go back and change the proposal.

3. Print Dunning Notices

You can use a ‘single form’ or ‘multiple forms,’ which will have different text, based on
the ‘dunning levels.’ There may also be a requirement to use a completely different form
for ‘legal dunning.’ Once the print option is activated, the program prints the notices, and
the dunning related information such as ‘dunning level,’ ‘last dunned,’ etc., are updated
in the customer/vendor masters. SAP provides the option of optically ‘archiving’ the
notices as the system prints the dunning notices. There is also a provision to re-start the
printing if it is interrupted before completing the printing.

22. Can you ‘dun’ customers across ‘Clients’ in a

Single ‘Dunning Run’?
No. All the data processing is carried out per Client.

23. What differentiates one ‘Dunning Level’ from

another?
The ‘Dunning Level’ determines the ‘dunning text’ and (if one is required) a ‘special
dunning form.’ The ‘dunning program’ determines what ‘dunning level’ should be used in
the ‘dunning run.’ The dunning level so determined is stored in the master record of the
account when the ‘dunning letter’ is printed. The dunning level may also determine
whether there will be some ‘dunning charges.’

24. How many ‘Dunning Levels’ can be defined?

You may define up to nine dunning levels. If there is only one dunning level, then it is
called a ‘payment reminder.’