Section: Credit/Risk Management
 SAP AG 1999
(C) SAP AG
TASD41
7-1
Payment Differences and Special Commitments:
Business Scenario
 Sometimes there are deviations between the
amount of the incoming payments and the existing
receivables. When posting the residual items, your
employees enter a difference code. Here, disputed
residual items should not influence the
commitments in credit management.
 Some customers make payments for orders. These
incoming amounts should reduce the amount of
credit limit used.
 SAP AG 1999
(C) SAP AG
TASD41
7-2
Payment Differences - Disputed Items
Customizing: Financial Accounting - Incoming payments
Difference reason
01
02
Disputed
Yes
No
Incoming payments TILIA Corp.
Open items
$12,000
Incoming payments $11,000
Difference
$1,000
CCA data
Tilia Corp.
Reason 01
CCA data
Incoming
payments
Receivables: $12,000
Tilia Corp.
Receivables: 0
 SAP AG 1999

For each company code, difference reasons are determined to manage payment differences.
Difference reasons are used, for example, when the cash discount period has been exceeded, when an
unauthorized cash discount is claimed, or if the customer has simply made an error in calculation.

You indicate for each difference reason whether payment differences should result in disputed items.
Disputed items do not raise the total receivables within credit management due from a customer.

When you carry out a credit check against the oldest open items and the percentage of open items
with a certain number of days in arrears, the system does not take disputed items into account. For
more information see the chapter on Automatic Credit Control.
(C) SAP AG
TASD41
7-3
Payment Differences - Undisputed Items
Customizing: Financial Accounting - Incoming payments
Difference reason
01
02
Disputed
Yes
No
Incoming payments TILIA Corp.
Open items
$12,000
Incoming payments $11,000
Difference
$1,000
CCA data
Tilia Corp.
Reason 02
CCA data
Incoming
payments
Receivables: $12,000
Tilia Corp.
Receivables: $1,000
 SAP AG 1999

In this example, the receivable in credit management remains at the level of the outstanding
receivable because the difference reason is not disputed (for example, an error in calculation by the
customer).
(C) SAP AG
TASD41
7-4
Receivables from Special G/L Transactions
Customizing: Financial Accounting - Incoming payments
Account type:
D = Customer
Special general ledger indicator: A = Payment
Credit limit relevance:
x
Tilia Corp.
Payment : $2,000
CCA data
Tilia Corp.
Receivables:
Special commitments:
$12,000
$- 2,000
Total commitments
$10,000
 SAP AG 1999

Special general ledger transactions represent special transactions in accounts receivable and accounts
payable, which cannot be shown in the usual way in the sub-ledger account. Examples include down
payments and bill of exchange posting.

The “Credit limit relevance” indicator ensures that the system takes posting into account when the
credit limit check is carried out for special general ledger transactions (in other words, this value is
included in total commitments).
(C) SAP AG
TASD41
7-5
Process Chain for Payment Card Processing
Order
Authorization
Clearing
house
Card
info
Outbound
delivery
Check validity
of authorization
Authorization
Settlement
Billing
document
Acc. doc.
Authorization
information
Card
info
Card
info
 SAP AG 1999

Payment card processing supports the following functions:
 A payment card plan is assigned to the sales order at header level. This plan contains information
such as the card number, the card type and the authorization data.
 When the delivery is created, a validity check is carried out for the authorization. If the
authorization is no longer valid, or if an increase in quantity requires an increase in value, then the
user is required to carry out authorization again in the sales order.
 The payment card data is copied to the billing document from the order.
 The payment card data and authorization data are forwarded when the billing document is
transferred to Financial Accounting. In Customizing, you can configure the system so that
additional data needed for settlement is transferred from SD to FI when procurement cards are
involved.
 Transactions with payment cards can be posted to deviating accounts (see the field Account
determination for payment cards when controlling the billing types).
 The final settlement process is carried out via the clearing house on the basis of this information.
(C) SAP AG
TASD41
7-6
Payment Card Authorization with an External
System
Authorization
Clearing
house
POS
Settlement
Billing
document
Card
info
Acc. doc.
Authorization
information
Card
info
 SAP AG 1999

This form of processing takes place in Retail. The Point-of-Sale (POS) is the point at which the
goods are paid for (usually the cash register).

No sales or shipping documents are created.

When using Point-of-Sale systems, authorization is carried out in an external system.

The relevant data is imported to the R/3 System. The billing document is created in the R/3 System.
(C) SAP AG
TASD41
7-7
Payment Card Data in the Customer Master record
Card type
Card number
VISA
4100000000000001
MC
5100000000000008
Best Bank
Default Block reason Valid from Valid to
X
01.01.1997 31.12.2002
01.01.1996 31.12.2001
VISA
4100 0000 0000 0001
Valid from 01/97 to 12/2002
K. King
Euro Bank
MC
5100 0000 0000 0008
Valid from 01/96 to 12/2001
K. King
 SAP AG 1999

Payment card data can be stored in the payer master record via the Payment transactions screen
(Payment cards button).

Here, you specify the payment card type (for example, VISA), the payment card number, and the
validity periods for this card.

A card can also be entered as a default card. This will then appear in the F4 Help for order
processing.

If a card is blocked, the blocking reason can also be entered for the corresponding payment card
(purely for information purposes, has no effect on the block in the order).

When you enter payment cards in the customer master, the following checks are carried out:
 The system checks the validity of the card number, provided the corresponding check routines are
maintained in Customizing for that card type.
 The system also checks whether this card has already been entered in a different customer master
record. An identical card cannot be entered for more than one customer.
(C) SAP AG
TASD41
7-8

Clearing houses issue authorizations for orders and are also responsible for settlement.

A transparent interface to external systems allows the merchant to transfer and receive data.

In the standard R/3 System, function CCARD_AUTH_SIMULATION is provided as a template for
creating user-specific authorization functions.

The standard system also contains function CCARD_SETTLEMENT_SIMULATION, for creation
of user-specific settlement functions.
(C) SAP AG
TASD41
7-9
Authorization
One day before delivery creation
Valid for 14 days
Next material availability date
by schedule line
Order entry
0
1
2
3
4
Days
Authorization horizon
Validity period (14 days)
 SAP AG 1999

Authorization is usually carried out in the order at header level. In other words, new authorizations
must always be created through the order.

Using checking groups, you can set requirements in Customizing, that control under what
circumstances authorization is to be determined. You can then set the system so that authorizations
are carried out only for complete orders.

Depending on the checking group, you can also specify the authorization horizon (in other words,
when authorization is to be determined).

If you use authorization requirement 1 provided in the standard system, authorization is triggered
when you save the order. Authorization requirement 2 is provided for background processing.

The checking groups must be assigned to the sales document types.

In the example above, an order has been entered today and is to be paid for using a VISA card.
Authorization is to be carried out one day before delivery creation and will be valid for 14 days.

The next material availability date according to the schedule line is in three days. This means that the
authorization process must be carried out in two days time, according to the authorization horizon
specified.

The authorizations in the order are used in billing. A status in the order displays which authorizations
have already been used.

Note:
You can use the checking groups in Customizing to control whether preliminary authorizations
(value 0, if the current date is outside the authorization horizon) are to be carried out in order to
check the correctness of the card data.
(C) SAP AG
TASD41
7-10
Settlement(1)
Invoice #900001
Customer:
Customer 58759
58759
King
50
Sales revenue
50
50
100
VISA 4100000000000001
Order value
$50
Automatic offsetting entry
to the customer account
Invoice #900105
Customer: 98775
Kaiser
Debiting of clearing house
account and posting of sales
revenue
Customer 98775
VISA 4200000000000000
100
100
Clearing house
50
100
Order value
$100
 SAP AG 1999

When accounting documents are being created from transferred billing documents that include
payment card data, the following postings are made:
 Debit and credit postings to the customer account
 Posting of the sales revenue
 Posting of receivables to the interim account of the clearing house

This posting process can be explained in that the authorization guarantees the receivable and the
clearing house represents the relevant partner for payment.

An interim account should be created for every clearing house so that the condition technique can be
used to carry out posting to the relevant account (all receivables paid with VISA and MC posted to
the interim account of the GZS; all receivables paid with AMEX posted to the interim account for
the AMEX clearing house, and so on).
(C) SAP AG
TASD41
7-11
Settlement (2)
B
E
F
O
R
E
Clearing house
50
100
Postings to the clearing
house account are cumulated
and credited
A
F
T
E
R
Interim bank account
Clearing house
50
150
The cumulative value is
posted to the
corresponding interim bank
account
Interim bank account
Background
processing
#5584
Settlement triggered via
interim account
150
100
 SAP AG 1999

At regular intervals, the individual postings can be cumulated in the interim account for the clearing
house and posted as a full value to the corresponding interim bank account.

Settlement with the clearing house is triggered via this interim bank account.

This account now contains the receivables from the clearing house for which payment is now
expected. The receivables were transmitted via a settlement run.

The background processing number can be used for assignment purposes during incoming payments.

The interim bank account is cleared upon payment of the receivables by the clearing house.
(C) SAP AG
TASD41
7-12