0

Section: Credit/Risk Management

SAP AG 1999

(C) SAP AG TASD41 7-1

0.2
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

0.3
Payment Differences - Disputed Items

Customizing: Financial Accounting - Incoming payments

Difference reason Disputed

01 Yes
02 No

Incoming payments TILIA Corp.

Open items $12,000

Incoming payments $11,000
Difference $1,000 Reason 01

CCA data CCA data

Tilia Corp. Incoming Tilia Corp.

payments
Receivables: $12,000 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

0.4
Payment Differences - Undisputed Items

Customizing: Financial Accounting - Incoming payments

Difference reason Disputed

01 Yes
02 No

Incoming payments TILIA Corp.

Open items $12,000

Incoming payments $11,000
Difference $1,000 Reason 02

CCA data CCA data

Tilia Corp. Incoming Tilia Corp.

payments
Receivables: $12,000 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

0.5
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: $12,000
Special commitments: $- 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

0.6
Process Chain for Payment Card Processing

Order
Authorization
Clearing
Card house
info

Outbound Check validity

delivery of authorization
Authorization
Settlement

Billing Acc. doc.

document Authorization
information
Card Card
info 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

0.7
Payment Card Authorization with an External
System

Authorization Clearing
house

POS

Settlement

Billing Acc. doc.

document
Authorization
information
Card Card
info 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

0.8
Payment Card Data in the Customer Master record

Card type Card number Default Block reason Valid from Valid to

VISA 4100000000000001 X 01.01.1997 31.12.2002

MC 5100000000000008 01.01.1996 31.12.2001

Best Bank VISA

4100 0000 0000 0001

Valid from 01/97 to 12/2002 Euro Bank MC

K. King
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

0.9
Data Transfer to the Clearing House

SAP standard interface

Converter Converter Converter

1 2 3

Clearing Clearing Clearing

house house house
1 2 3
SAP AG 1999

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

0.10
Authorization

One day before delivery creation

Valid for 14 days
Next material availability date
Order entry
by schedule line

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

0.11
Settlement(1)

Invoice #900001 Customer 58759 Sales revenue

Customer: 58759 50 50 50
King
100
VISA 4100000000000001

Order value $50

Debiting of clearing house

Automatic offsetting entry account and posting of sales
to the customer account revenue
Invoice #900105

Customer: 98775 Customer 98775 Clearing house

Kaiser
VISA 4200000000000000 100 100 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

0.12
Settlement (2)

B Clearing house Interimbank account

E
F 50
O
R 100
E

The cumulative value is

Postings to the clearing posted to the Background
house account are cumulated corresponding interimbank processing
and credited account
#5584

A
F Clearing house Interimbank account Settlement triggered via
T interimaccount
E 150
50 150
R
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