Accounts Receivable (A/R)

Account receivable components deals with your customers and receivables, from both the
FI and SD perspectives, as with A/P all postings and transactions are also updated in G/L in
real time, the G/L is always up to date with the A/R sub-ledger. It comes with functions for
managing incoming payments (includes payment card), open-item clearing and interest
calculation. Its dunning program helps you to remind your customers of their payments
due, the automatic payment program can also be used to help with debit down payments. It
is also integrated with SD which helps you to administer and manage credit and other
associated risks. We will be covering the following, some of the topics are similar to what
we discussed in A/P

 Customer account master data

 Business transactions
 Credit management
 Interest calculation
 Dunning
 Reporting

Customer Master Data

We will start with the master data, a customer is a business partner who owes a receivable
to you and may be one of many business types, sold-to-party, consumer and customer. The
master records identifies the customer and also controls how you manage the business
transactions. There are three distinct segments within the customer master record general
data (applicable to both company code and sales area), company code data (reconciliation
account, interest indicator, terms of payment, payment methods, house bank, tolerance
group and dunning procedure) and sales area data (sales, shipping, billing and partner
functions).

You need at least one account group defined for the customer master records, again we
need to create number ranges and field status for the account groups. I am not going to go
into much detail on how to create the number groups as this should now be familiar to you
(see accounts payable master data), use transaction code XDN1,

Also I will not cover in detail the account groups as this is similar to the vendor accounts
groups that we have already discussed, use transaction code OBD2 and you will see the left
hand screenshot, you can also use transaction code OVT0 to define or change customer
account groups which when you drill down you will see the right hand screenshot, this is
mainly used by the SD department as you can configure additional parameters such as text
procedures, SD-related data (customer pricing procedure, output determination procedure)
and indicator if the customer is a competitor, sales partner, default sold-to-party, consumer
or prospect.

We then can assign the number ranges to the customer account groups, we will use
transaction code OBAR,
Again as with A/P we can add clerks to our customer, use transaction code OB05, use the
correspondence tab as per the screenshot below

We as can also define the sensitive fields as we did with A/P, if the system blocks an
account from payment you or an authorized person may confirm the changes individually
(transaction code FD08) or for a number of customers (transaction code FD09), use
transaction code S_ALR_87003378 to define the sensitive fields
You can evaluate your customers by industries, you use transaction code OB44 to define
the industries and then assign them to the customer master data in the general tab.

Customer Master Data Creation

You can create customer master data both centrally or both in the company code and sales-
area in a single step, or separately in company code and sales-area. You can also create the
customer with or without reference to an already existing customer. It is important that you
create a reconciliation account to ensure that the A/R postings are updated in the G/L. You
can also have details on an alternative dunning recipient, alternate payer, clearing vendor
and customer, grouping of business partners belonging to a single corporate entity. To
create a master record for accounting alone we will use transaction code FD01, for creating
master data records in SD alone use the below table

Transaction
Business partner type
Create Change
Competitors V+22 VD02
Contact Person VAP1 VAP2
Customer VD01 VD02
Forwarding Agent V-11 FK02
Hierarchy V-12 VD02
Sales Partner V+23 VD02
Sales Personnel VPE1 VPE2
Sales Prospect V+21 VD02

To create a master record centrally we will use transaction code XD01,

You can also create one-time customers by using the appropriate customer group account
like 0099 where all the fields have been set to optional status, the data for the customer will
be stored in the document.

You can delete customer master records using transaction code OBR2, you can use also use
transaction code VD06, however you will not be able to delete a customer if there is any
transactional data for that account and you also will not be able to delete any productive
customers (use transaction code OBR3 to remove the productive state). You can link
vendor and customers however if you delete the master records you must delete the
reference first, start the program SAPF047 to generate link information of such referenced
records before actually carrying out the deletion.

You can also delete transactional data from a specific ledger (transaction code
FAGL_DEL) or delete all the transactional data from a company code using the IMG, I
have a section on this in the accounts payable section.

Business Transactions

Like A/P we need to configure the system to handle the various business transactions, for
example you may want to process the incoming payments in certain ways when the
payments are not adequate to clear the outstanding open items or you may want to process
credit limits using a workflow. We will start with the terms of payment again this is similar
to A/P, we will use transaction code OBB8,
Similar to cash discount base settings done for incoming invoices we need to set these up
using transaction code OB70,

Now we will define the tax accounts for the outgoing payments, we will define the G/L
accounts for the various tax transactions (such as MW1) for various codes (O), I0, etc). we
will use transaction code OB40, on the initial screen double click on sales tax 1 and enter
the chart of accounts, use the new entries button and enter the below G/L accounts for each
of the tax codes, see below screenshot

Incoming Payments
You will need to configure the following, again we have covered most of this in the A/P
outgoing payments section

 account definitions for cash discount

 payment differences
 exchange rate differences
 rounding differences
 bank charges
 posting keys
 tolerance groups
 payment block reasons

To define the accounts for cash discount for your customer you can use transaction code
OBXI,

The accounts for overpayment and underpayment have already been defined in the A/P
outgoing payments section, we will use the same G/L accounts for posting payment
differences arising out of all customer transactions.

We will transaction code OBXK to define the accounts for bank charges as we did in the
A/P section.

We will leave the postings keys as defined in the system already, but in this case you will
use "08" as the debit key for payment clearing with incoming payment which will be
credited in the system using posting key "15", similarly you will account for payment
differences by creating residual items using the debit key "06" and credit key "16", you can
use transaction code OBXH to view or change the keys if you wish
You can enable translation posting which means you will post the translation gain/loss
when clearing open items in a foreign currency, we will use transaction code OB66, the
translations are posted if the items to be cleared have already been revalued once during
foreign currency valuation. The SAP system posts the difference to a separate translation
account with the offsetting entry posted to a clearing account. We already enable the
translation posting in the A/P section.

We will again use the G/L accounts that we created in the A/P section for any rounding
differences, the same goes for the payment block reasons.

Below is a summary table

Auto A
Transaction
Task Explanation detrm
Code
transc
Define accounts for cash used for any cash discount received when clearing open
OBXI SKT
discount items
Define exchange rate
see G/L accounting open item clearing
differences
Define accounts for
used for rounding differences OB00 RDF
rounding differences
Define accounts for
bank charges used for any bank charges OBXK BSP
(Customers)
define revenue and expense accounts so that over/under
Define accounts for
payment differences within tolerance limits during OBXL ZD
over/under payments
automatic adjustment posting
You can define or change difference tolerance groups that we created in A/P as per
Datadisk Mobility, again we use transaction code OBA3

Payments with Credit Cards

There are several functions for processing payments via credit cards (credit/debit cards),
you need to maintain the card types, card categories, plan types, payment block reasons.

The central settings you need to decide to use for your company are

 Determining to retain (or not) a customer line item in the accounting document
when data is sent from SD to FI
 Specifying document types for settlement (or unsuccessful settlement) of card
outstanding by the card company

We will use transaction code OBZH to configure the settings for the payment card,

 retain cus.item - the line items will be retained in the accounting document when
transferring data from SD to FI. The system recreates the receivables from a
customer automatically (by resetting cleared items) so that they can be processed
further in the dunning or payment program. The system can clear this when the
document is posted. If you do not select this then the system will replace the
customer line item with a receivable from the payment card transactions in the
corresponding G/L account.
 document type (settled document) - AB will be used in clearing the open items in
the G/L account and generating line items in a cash clearing account
 document type (resetting clearing) - AB will be used for resetting clearing
transactions when the settlement was unsuccessful
 text id and mail text - used for inputting standard text as settlement response
 define index - to have settlement runs number entered in the already cleared
customer lien items so that you can use the information in evaluations
Then we assign the G/L account to the cash clearing account, a G/L account is required to
record all the receivables that you may report to the credit card companies using a
settlement program that posts or clears the reported open items against the cash clearing
account. Assign a G/L account per credit card type for recording open items to a cash
clearing account. We will use transaction OBZI

Down Payment Received

To manage the customer down payments (and down payment requests) we need to define
the reconciliation accounts for the required special G/L transactions, tax accounts for
different tax types and accounts for output tax clearing, we first define the reconciliation
accounts for customer down payments as the posting can be automatically made to this
account instead of a normal receivables reconciliation account. For each of the account
types (D for customer) and special G/L indicator (A, F, T, etc) combinations you need to
maintain the required G/L accounts, we will use transaction code OBXR (customer) or
OBYR (vendor) , special indicator F is used for down payments (see right-hand screenshot)
and can only be selected for the F indicator as part of the standard system you cannot select
this checkbox for any other down payment indicator, you can use transaction code F-47 to
post a down payment request.

We next define the G/L account for tax clearing, we will use transaction code OBXB,

Credit Management

You need to setup a credit management system which will allow you to monitor, administer
and control credit to your customers, without managing the credit you will have problems
in collecting the receivables that are due, SAP credit management is integrated with both FI
and SD, you can also use the credit management with just the FI component which can help
with credit checks and credit evaluation. The static and dynamic credit checks together with
automatic notifications will enable you to setup the system for any given credit
management situation. The credit control area (attached to a company code) is at the heart
of the credit management, it uses groups, credit risk categories and credit representatives
for effective control.

We have already touched on credit control in my Enterprise section, we created 3 credit

control areas we will now continue from there and discuss the settings that are required to
configure the system for credit management
  Additional credit control and company code assignment
 Preliminary settings for credit management
 Groups (customer credit groups or credit management groups)
 Risk categories
 Credit representative groups
 Credit representatives
 Intervals for days in arrears

First we will confirm that our company codes are assign to the credit control areas, we will
use the IMG as per the screenshot below

You can then assign the company codes to the credit control areas

The preliminary settings are client-specific and include the procedure parameters for credit
check and Days Sales Outstanding (DSO) calculation, we will use transaction code OBZJ

 read a/r summary - the FI system reads the A/R summary data (instead of the
current database) during credit checks, in sales order processing from decentralized
SD system
 read a/r summary from an external system - will enable the data for credit check
to be transferred to FI via RFC if there is no A/R summary data or it is obsolete
 create a/r summary - creates the A/R summary in the central system, the A/R
summary data contains all the information on a credit management account in
summarized form for a credit control area that is necessary for the credit check in
 SD, use this as the system can read this data much faster than repeatedly reading the
open items.
 all children - this will make the system consider both the data of the credit account
(parent) and all the customers (children) assigned to that credit account in arriving
at the total sales per day.
 current balance - DSO is more closely related to the current balance than the
average balance, use this so that the system uses the current balance in arriving at
the DSO figures
 months - the number of previous months that will be taken into account when
arriving at the DSO, the normal practice is to have 3 months as the number of the
previous period

The table below describes the settings you need to make in centralized and decentralized
environments when you are optimizing performance

Distributed Environment
Details/Field
Decentralized SD system Central FI System
Read A/R summary Yes Yes/No
Read A/R summary from an external system
Yes/No No
person
Create A/R summary No Yes

You can group your customers into credit groups based on certain criteria like domestic
customers, overseas purchasers or institutional customers. Once you have defined the
groups you can enter them under the cust.cred,group field under the internal data while
maintaining the credit details for a customer. We will use transaction code OB12
Now we will define the risk categories, they are defined per credit control area, we will use
transaction OB01

Lets now define the credit representative groups which can be used to group customers who
will be served by employee(s) assigned by that group, you will maintain this group for each
customer in the customer master record, you again need to maintain these groups for each
credit control area, we will user transaction code OB02

By assigning credit representatives to each of the credit representative groups you make
sure that each of the employees is responsible for that group of customers in managing
credit, you can also allocate a partner function to each combination of credit representative
group and credit control area, we will use transaction code OB51, you need do repeat for
each credit representative group to created above

 funct - select the appropriate function such as KB (credit representative), KM

(credit manager), KO (credit coordinator)
 co - select so as to copy the credit representative into the document
 pers.no - the personnel number of the employee you plan to use as the credit
representative
Use days in arrears interval to segregate customer open items by due date in all company
codes per credit control area, the system displays the days in arrears according to the define
intervals, in the (credit limit) overview transaction (transaction code F.31). You can also
use these intervals to determine the "cash discount 1 due date" or the net due date (asset
value date = 2) is to be taken as the due date. You can define up to to five day limits so
there is a maximum of six intervals. We will use transactions code OB39

 RfDte - the reference date for interval, 1 - cash discount 1 due date, 2 - due date for
net payment

You can perform two types of credit checks static or dynamic, these are define for any valid
combination of credit control area, risk category and document credit group (the group that
combines the order and delivery types so that all business transactions are treated the same
as regards credit check) you can also define how the system acts if the check fails either
with a error or a warning.

this is also know as a simple credit check which imposes a condition that a customer's credit
Static credit open deliveries plus open invoices plus A/R open items) may not exceed the credit limit, rest
limit check control area this check is carried out when you create or change sales documents, you will us
configure the settings
this is made up of both a single and dynamic limit, the dynamic part limit includes undelivere
Dynamic
open-order value that is calculated on the shipping date and stored in an information structure
credit limit
(credit horizon) specified in days, weeks or months, with the condition that the total value sh
check
limit, you can specify a particular horizon date in the future (21 days for example)
You can check the customer credit limits using transaction code FD32, if the credit limit is
breached then you cannot save the order if an errors messages is displayed or if a warning
is displayed then you can save the order it will be blocked. A credit representative uses
information functions like credit overview, credit master list, early warning list (transaction
code FCV3) and account analysis to process blocked orders either for the blocked SD
document list (transaction code VKM1), or the mail box (transaction code SO01) and
decides to release the order, when the order is released the system creates a delivery,
generates the billing document and posts the A/R, the customer then pays the invoice and
the A/R is posted in the system.

Interest Calculation

I have already discussed the global and other related settings for interest calculation relating
to account balance interest in the G/L accounting section, we need to make another setting
for item (arrear) interest calculation, you can configure this in several ways, calculating
interest only on cleared items or open items, on all clearing transactions or transactions
excluding uncleared credit memos, on debits, or on debits and credits, we will specify the
settings for selection of items and interest calculation besides making additional
configuration for subsequent processing of interest and output control, we will user
transaction code OB82, you can see the two indicators that have been configured below

 selection of items - this block allows you to select the items that the interest
calculation will be applied too
 calendar type - you can have B for bank calendar 30/360 or J for 30/365 as the
calendar for interest determination
 transfer days - the days that will be required to realize an incoming payment in the
bank, this will not have any impact on the open items.
 tolerance days - enter the days that you offer to your customers to pay off the
payables when an item becomes, but without attracting interest
 amount limit - the amount limit beyond which only the system will create an
interest settlement
 no interest payment - select this if you don't want an interest payment

The table below shows you the different situations when a tolerance day has been applied
 Effective Overdue
Open Item Tolerance Days Remarks
(Days)
3 days
5 -2 No interest is charged, but item is classified as due
overdue
10 days Interest will be charged for 10 days, since even after
5 5
overdue still overdue
Not considered for interest calculation. Note that the
not yet due 5 NA
the due date of an item which is not due.

The below screenshot's show the two interest indicators, indicator one calculates the
interest on all open and cleared items but not on the items paid before the due date,
indicator two will calculate interest on all open and cleared items and will calculate interest
on items paid before the due date, we will use the bank calendar for each indicator, we have
also allowed one transfer day

The settings for the item interest calculation is almost the same as above, the settings will
have an effect in the other activity or vice versa, if you have selected the option that no
cleared items should be included for interest calculation it will have no effect on the
settings that you made in the other activity, we will use the IMG
Again we will define two indicators

 item selection - self explaining

 always calculate int from net dte - the system will calculate the interest only as of
the due date for net payment
 ref date - enter the value date as the reference date, for all net payments this will be
the baseline payment date
 output control - you can select the print form to print the interest calculated, you
should supply also supply a number range for the form, you can define interest
forms using transaction code SE71
 post interest - in item interest the system posts the calculated interest in the update
run of the interest program
 posting with invoice ref - the system creates a separate line item for each invoice
for which interest is calculated
Dunning

To remind your customers to pay (payment reminder) is called dunning in SAP, you can
determine formats by using appropriate dunning text to vary the tome of the reminders to
match the severity of overdue payments. You can configure the dunning program to dun
customers as well as vendors (if there is a debit balance resulting from a credit memo), the
program selects the overdue open items, determines the appropriate dunning level for the
items and account, generates a dunning notice in a dunning run, and saves the dunning data
including the last dunned date, last-used dunning level and others, you can dun
customers/vendors automatically or make selective dunning.

The dunning process is as follows

1. Maintaining dunning parameters (such as execution date and dunning run identifier)
that will identify a dunning run is the starting point, other parameters include the
dunning date that needs to be printed in the dunning notice, the posting cutoff date
for selection of documents, the company codes, etc, you can save and display the
logs to see if there were any errors, also you can see the dunning list which contains
the accounts items that were selected for the run.
2. the second step creates the dunning proposal, where the programs determines the
accounts and items in the dun, the system checks the dun.procedure and last dunned
in the customer master, determining whether the arrear date falls in the past in order
to consider them for the current run. It also checks the the entry dunning block in
the customer master, if not blocked then these accounts are considered as released
for dunning in the current run. The program procedures to process the open items of
accounts that have been released but that were posted to on or before the date
 entered in the field documents posted up to, it then determines if any of them are
blocked for dunning, if not then it ascertain whether an item is overdue according to
the date of issue, base date, payment conditions and grace period. Then for open
items that have been released for dunning the program determines the appropriate
dunning level based on the number of days an item has been overdue, it sets the
highest dunning level to the account to the highest dunning level of an open item of
the account, even if there are different dunning levels associated with the different
open items. The highest dunning level determines the dunning text. The program
now checks each of these eligible to ascertain whether the customer/vendor has a
debit balance, considering all the open overdue items thus selected in that account.
3. The dunning program now creates the dunning proposal list containing the accounts
with the open items that are selected for the current dunning
4. You can then edit the dunning proposal list so as to manually raise or lower the
dunning level of an item or account, and block or unblock an item or account or
document from being dunned.
5. Now you can print the dunning notices, you can use the same form or different
forms with varying different dunning text, you can use a legal dunning form which
will normally be used as the final notice, you can restart printing or optically
archive the dunning notices while the same is being printed.

Now we understand what happens in the background we need to configure the dunning
settings which will include

 Dunning keys
 Dunning block reasons
 Dunning forms
 Dunning procedures
 Company code dunning control
 Dunning areas

Lets start with the dunning keys, the company code independent dunning keys limit the
dunning level item for an item, besides enabling you to control the display of line items
separately in a dunning notice, you can define the maximum dunning level (no more than 9)
per dunning key, we will use transaction code OB17

Now we define the dunning block reasons for this we will transaction code OB18,
Next we define the dunning forms, you can use either SAPScript or SAP smart forms as the
dunning forms. If you want to make changes copy the originals and make the changes to
the copies, you can have different forms that have different line displays (with or without
printing the interest charges) and different totals layouts per dunning level, you can use
transaction code SE71, the standard dunning forms are F150_DUNN_01 (without interest)
and F150_DUNN_02 (interest), you should copy these and then make changes to the
copies.

In the below screenshot I have copied F150_DUNN_01 to ZF150DUNN_ML_US1 (ML is

multi-level) which will be used later, you can copy some more for SL (single level) and LD
for (legal dunning), you then change the dunning form as you please

The dunning procedure is the heart of the dunning program, company code independent it
controls and determines the appropriate dunning interval, dunning level and the grace
periods for due-date determination, you can also configure the procedure for the dunning
charges to be levied besides the dunning notice to be used. You can use a single or multiple
dunning procedure with each level using different dunning text and dunning form if
required.
We will create two dunning procedures for the Datadisk Mobility company, we will use
transaction code FBMP, in the below screenshot you can see i Have already created the
dunning produced DD4U, lets see how I configured it

The initial create screen we have the following

 dun.procedure - the dunning procedure name

 dunning interval in days - the minimum number of days between two successive
dunning runs, unless the number of days has passed the system will not select the
account for dunning, even if there are overdue items in the account
 no of dunning levels - the highest dunning level required for the procedure, you can
have a maximum of nine
 total due items from dunning levels - you display and print the total of all the due
items, at a specific dunning level
 min.days in arrears (acct) - used to provide a grace period, it will be used to check
if an item after becoming due has crossed the number of days entered here so as to
include or exclude that account for the current dunning run. This option affects the
account at least one open item of the account must fulfil this condition
 line items grace period - the system uses this parameter to arrive at the dunning
due date and not the line item due date, the system will not consider any item with
its days in arrears less than or equal to this number as due for the current dunning.
 interest indicator - used for interest calculation on the arrears
 public hol.cal.id - will ensure that the payment date due printed on the dunning
notice does not fall on a holiday, in which case it will print the next date
 standard transaction dunning - you can ensure that only the standard and not the
special G/L transactions are included in the dunning
 dunning even for credit account balance - this check the account balance and
creates dunning notices only when the account balance is debit
 ref.dunning procedures for texts - the dunning procedure from which the dunning
forms will be referenced to when you print the dunning notices
Now we configure the dunning levels, the dunning level will determine the dunning text to
be printed on the dunning notice as well as the dunning form,

 days in arrears - in the below screenshot dunning the system will default here for
the different dunning levels, it will be 0 for the first level, 15 days for the second
level (0+15), 30 days for the third level (15+15) and 45 days for the forth level
(30+15), if you have specified any grace days the system will prompt the days in
arrears for dunning level 1 being equal to the value entered for the grace period, this
will then be added to the other dunning levels, for example if the grace days is 2
then level one will be 0+2, level two would be 2+15, etc, also see the below table.
 calculate interest - interest will be calculated on the dunning level
 always dun - this will indicate to the system to print dunning notices, even if you
have not made any change to the dunning proposal since the last dunning run, you
should always select this for the highest level
 print all items - will print all open items (except blocked ones) with the same
dunning level
 payment deadline - the system will add the number of days entered here to the
dunning runs dates when creating the payment deadline that will be printed on the
dunning notice, public holidays will be accounted for.
 always dun on legal dun procedure - issues a dunning notice even if there is no
movement in the account since the last dunning, with legal dunning the system only
prints a notice only when there are movements in the account.

Dunning interval in Line item Grace Days in arrears for dunning le

Days periods 1 2 3
15 0 15 30
15 2 2 17 32
Next we define any charges, you can use absolute amounts or a percentage, you can also
specify different currencies if you use the same dunning procedure for different company
codes.

Next we define the minimum amounts, again for a specific currency.

Next we setup dunning areas, sort variants as well as designing a particular company code
that will run on the behalf of other company codes in a cross-company code dunning.

 by dun ar - dunning is performed by dunning area

 by dun lev - dunning is performed by dunning level
 ref co code - the company code from which you will use the dunning form as
reference, the company codes will all use the same dunning text and layout
 sort.MHNK - sorting variant
 sort. MHND - sorting line variant
 dun CoCd - used for cross company code dunning, enter the company code to dun
on behalf of all the other company codes in the corporate group, the advantage is
that you can send a single dunning notice to each of the companies.

Now we setup the dunning texts, we select the dunning forms we created earlier and the list
name (required to store the dunning notices in separate lists in the spool) per dunning level
for the normal and legal dunning procedures. if you need to generate a payment advise
select the adv checkbox, you can also enter a form id for the payment medium.

Create the remain dunning procedures for the other company codes, see Datadisk Mobility
company

Now we need to create the standard text (sender details, header, footer, logo, etc) for the
dunning forms we will use transaction code S_ALR_87001305, you will need to create the
standard texts using transaction code SO10, the SF fields are for smart forms.
Now we will define the interest rates that the dunning program will use, we will use
transaction code OB42

You can also define dunning areas which we mentioned earlier, normally dunning is
perform per company code, the advantage of using a dunning area is that you may be able
to use different dunning procedures for different dunning levels. You can configure
different dunning procedures for different dunning areas or a single dunning procedure for
all the dunning areas

 if you need to dun by dunning areas but do not require more than one dunning
procedures, then you just need enter the dunning procedure in the customers master
record. The system will pick this up when you enter the dunning area in a line item.
 If you want to make use of different dunning procedure for different dunning areas
then you make the dunning area and dunning procedure assignments, indicating
what combination is to be used for a given dunning level, in the customers master
records.

You can use transaction code OB61

You can use transaction code OBL6 to review a dunning procedure against a company
code

The results is very detailed and spans several pages

Reports
SAP provides you with standard evaluations and drill-down reports for A/R, for each
evaluation you may then define evaluation types including payment history, DSO analysis
and terms offered and terms taken. Use transaction code OBDF to view or change to match
your exact reporting requirements.

You can access account receivable information using the transaction code
S_ALR_87012167