SAP Solution in Detail

SAP Financial Supply Chain Management

RECEIVABLES MANAGEMENT WITH SAP® FINANCIAL SUPPLY CHAIN MANAGEMENT

2

© Copyright 2007 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in

any form or for any purpose without the express permission of

SAP AG. The information contained herein may be changed

without prior notice.

Some software products marketed by SAP AG and its distributors

contain proprietary software components of other software

vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are

registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex,

MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries,

xSeries, zSeries, System i, System i5, System p, System p5, System x,

System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere,

Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+,

OpenPower and PowerPC are trademarks or registered

trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are

either trademarks or registered trademarks of Adobe Systems

Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks

of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame,

VideoFrame, and MultiWin are trademarks or registered

trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered

trademarks of W3C®, World Wide Web Consortium,

Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc.,

used under license for technology invented and implemented

by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver,

Duet, PartnerEdge, and other SAP products and services

mentioned herein as well as their respective logos are trademarks

or registered trademarks of SAP AG in Germany and in several

other countries all over the world. All other product and

service names mentioned are the trademarks of their respective

companies. Data contained in this document serves information-

al purposes only. National product specifications may vary.

These materials are subject to change without notice. These

materials are provided by SAP AG and its affiliated companies

(“SAP Group”) for informational purposes only, without

representation or warranty of any kind, and SAP Group shall

not be liable for errors or omissions with respect to the materials.

The only warranties for SAP Group products and services

are those that are set forth in the express warranty statements

accompanying such products and services, if any. Nothing herein

should be construed as constituting an additional warranty.

3

CONTENTS

Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

SAP Biller Direct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

SAP Biller Direct: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Processes Supported by SAP Biller Direct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Display of Bill and Account Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Payment of Bills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Maintenance of Master Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Functions in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Java as Presentation Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Java Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Log Functions and Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Authentication and Authorization of Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Master Data of Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Notification of Account Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Selecting Open Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Bill Display and Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Displaying the Bill and Payment History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Payment Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Stopping Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Offsetting Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Link to SAP Cash and Liquidity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Integration with SAP Dispute Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Clerk Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Additional Business-to-Business Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

SAP Dispute Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

SAP Dispute Management: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Processes Supported by SAP Dispute Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Management of Payment Deductions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Dispute Cases Reported by Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Functions in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

The Dispute Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Process Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Dispute Case Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Customer Correspondence and Internal Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Enhancement Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

4

SAP Collections Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

SAP Collections Management: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Processes Supported by SAP Collections Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Collection of Receivables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Control of Receivables Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Data Synchronization and Creation of Work Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Functions in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

The Work Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Processing of Receivables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Promises to Pay, Dispute Cases, Resubmissions, and Customer Contacts . . . . . . . . . . . . . . . . . . . . . 29

Collection Strategies and Collection Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Organizational Structures and Business Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Data Synchronization and Creation of Work Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Enhancement Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

SAP Credit Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

SAP Credit Management: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Processes Supported by SAP Credit Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Creditworthiness Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Credit Limit Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Functions in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Organizational Structures and Business Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Scoring and Risk Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Credit Limit Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Credit Exposure Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Events and Follow-On Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Release of Blocked Orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Credit Manager Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Connection of External Credit Information Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Integration with Other Applications of SAP FSCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Enhancement Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

–

5

• SAP Collections Management: an application you can use for

system-supported creation of work lists for collecting outstanding

receivables on time. SAP Collections Management enables the

collection specialist to have personal contact with unpunctual

debtors, which considerably increases the probability of receiving

payments on time. This approach differs from dunning.

• SAP Credit Management: an application you can use for cross-

company management and control of customer-related credit

ratings. SAP Credit Management provides you with a highly

flexible scoring mechanism and makes decisive contributions

to increasing the transparency of credit decisions across systems

and to minimizing credit risks.

The following material describes the range of functions of the

individual applications of SAP FSCM and how they work in more

detail.

Given the background of volatile economic conditions, many

companies regard receivables and credit management as increasingly

important. Efficient processing of payment reductions, proactive

management of outstanding receivables, comprehensive control

of credit relationships, and innovative integration of end customers

in the order-to-cash process can reduce the number of days that

sales are outstanding, optimize the balance sheet structure, and

minimize any potential risk from customer items. SAP® Financial

Supply Chain Management (SAP FSCM) is a set of applications

that helps companies organize their receivables and credit man-

agement within the SAP ERP Financials solution. With SAP FSCM,

SAP focuses on helping organizations optimize working capital

and financial supply chains.

The SAP FSCM set of applications contributes to optimizing cash

flows based on accounts receivable accounting. The set includes:

• SAP Biller Direct: an application you can use to display account

and bill information and the related payments electronically

(electronic bill presentment and payment). SAP Biller Direct helps

customers interact by providing various self-services for end cus-

tomers. The services help you manage receivables and credit faster

and with better cost-efficiency.

• SAP Dispute Management: an application you can use when

processing receivables-related dispute cases that have arisen

because of authorized and unauthorized payment deductions.

With SAP Dispute Management, you have support for efficient

paperless and cross-departmental processing of such dispute

cases and for integration of the customer into the dispute process.

EXECUTIVE SUMMARY

6

SAP Biller Direct: Overview

With SAP Biller Direct, you can display information on accounts,

bills, and payments electronically (electronic bill presentment

and payment). Business partners can display account balances

from finance and accounting along with bill data from billing

systems (for example, the sales and distribution functionality of

the SAP ERP application). Customers can view their open items

and any possible credits over the Internet, and they can set the

credits against outstanding receivables. The particular advantages

of SAP Biller Direct you enjoy include:

• Considerably lower transaction costs for bill processing

• Improved liquidity planning

• Simplified payment, settlement, and reconciliation processes

• Reduced arrears

• Increased customer loyalty

• Huge potential for cross- and up-selling

• Improved customer management

SAP Biller Direct supports both the “push” and “pull” principles.

An e-mail informs the bill recipient about changes to the account

balance (new bills or credits) according to the push principle.

The recipient can then access the Web page or portal of the biller

to display or download the bill and account data according to the

pull principle. The recipient does not have to install any SAP

software to access this information – a Web browser is sufficient.

SAP Biller Direct also supports you with self-service functions,

such as changing address or bank master data, granting or with-

drawing the authority for automatic debits, and registering com-

plaints and questions about bills. Tight integration of SAP Biller

Direct with SAP Dispute Management enables such functions.

SAP Biller Direct includes two components: the front end that is

created using JavaServer Pages (JSPs) and the back end that is

implemented using conventional ABAP™ programming language

tools. That means that you can use SAP Biller Direct with the

familiar SAP software you already use to perform accounts receiv-

able accounting and contract accounts receivable and payable and

when you work with various solution portfolios (SAP for Public

Sector, SAP for Media, SAP for Utilities, SAP for Telecommunica-

tions, and SAP for Insurance). The application is also integrated

with the SAP Cash and Liquidity Management application, so that

when you release or pay bills, you automatically update the cash

management position and the liquidity forecast.

Processes Supported by SAP Biller Direct

Display of Bill and Account Information

Customers or vendors can use a Web browser to view the bill and

account information of their customer or vendor account. A user

login to SAP Biller Direct processes an event in the contract accounts

receivable and payable software or in a business add-in in accounts

receivable accounting. The software reads and summarizes the

open items for a business partner or customer in bill items. You

can display the bills due in the Internet account along with the

bill text, the bill amount, any remaining payable amount, and

the due date. In the bill overview, the application returns a bill

format to the business add-in or the event. You can display or

download the bill details in different formats, depending on the

billing source system. The formatting options include comma-

separated values (CSV), Portable Document Format (PDF),

HTML, and XML. You can also access the optical (bill) archive.

Payment of Bills

Your customers can select one or more bills in SAP Biller Direct

and pay them with various payment methods, such as debit memo

or credit card. Users then enter a payment method, bank details,

or payment card number in the open items that relate to the selected

bill. They also enter a payment group in contract accounts receiv-

able and payable. The payment group is a 10-digit number that is

unique to the related business partner data. Once a user has entered

the payment methods in the open items, the dunning program no

longer affects the items. When the billing company starts the

payment program (payment run), the user works with SAP Biller

Direct to select all open items that have been released for auto-

matic debit and whose due date has been reached. This approach

means that the payment run also determines the payment amount

that the biller collects.

SAP BILLER DIRECT

7

SAP Biller Direct also supports partial payments, which clear only

part of the original bill amount due. When you work in accounts

receivable accounting, you determine how to treat partial payments.

You can decide not to clear the original receivable and create a

new document instead (follow-on document with reference to

original document). As an alternative, you can treat partial payments

as a residual item and decide to write off the old receivable and

post the difference to the customer account as a residual item.

The discount calculation depends on the posting logic. For a partial

payment in contract accounts receivable and payable, you split

the open item and assign a payment grouping only to the partial

amount released. The clearing control in contract accounts

receivable and payable stores information you can use to deter-

mine which open items belong to which bill and to view the payment

amount arranged for payment by the customer.

Maintenance of Master Data

Your customers can add or change bank or payment card data in

SAP Biller Direct. If they add new bank or card master data, the

application performs an internal plausibility check. For example,

the application can validate the bank code and account number

(if the customer has implemented a current bank master file).

It can also use the check digit on a credit card to determine

whether a credit card number belongs to the correct credit card

organization (for example, MasterCard).

When customers add new bank or card details, they can assign

any name to the details. The application immediately enters the

new bank or credit card master data for the customer or business

partner. Customers can also use a check mode to park and check

later changes to master data. In this case, the clerk must confirm

the changes with the biller before the changes can take effect.

In addition to changing bank or payment card data, customers

can grant or withdraw authorization for debit memos, maintain

address data, and define preferred methods of communication

for SAP Biller Direct.

Functions in Detail

Java as Presentation Layer

The SAP Biller Direct application includes an ABAP portion that

handles the application logic and a Java portion that handles the

presentation layer. The presentation layer uses JSPs so that end

customers require only a Web browser to display data. The Java

portion is created in accordance with the Model View Controller

(MVC2) approach, a generic design model that separates the user

interface from the business process logic and the data. JSPs create

HTML pages dynamically. Just like Java Servlets, JSPs are a method

for creating the presentation layer of a Web application. They are

generally used for simple creation of the HTML and XML output

of the Web server. Servlets are application programs written in

Java, implemented in normal Java classes, and compiled in Java.

However, JSPs are Java commands that are integrated in HTML

documents. At runtime, a servlet is generated from the JSP files

and executed on the Web sever just like any other servlet.

Your customers can adapt JSPs to meet their needs – for example,

to copy the branding of an existing Internet page. The MVC2

approach has an advantage: it completely decouples the JSP from

the logic on which it is based and from data storage; the user can

change the JSPs without affecting the logic or data storage. This

approach also ensures that the JSP contains virtually no Java coding.

Web designers can change the JSP without the help of Java developers.

Customers can also use the JSP standard design delivered by SAP

and change the cascading style sheets that are delivered with it to

adapt SAP Biller Direct to the company’s own Internet page.

Figure 1: User Interface for SAP® Biller Direct

8

The architecture of SAP Biller Direct enables simple integration

with an existing Web or portal infrastructure from SAP. You need

a servlet engine to execute servlets and JSPs on the Web server.

The engine is a virtual Java machine that can execute specific object

methods that are designated as servlets. A virtual Java machine is a

Java interpreter that can execute the Java byte code generated

and, as a result, the Java program on a computer. A servlet engine

is also a component of the Java 2 Platform Enterprise Edition–

compatible SAP NetWeaver® Application Server component that

is required for running SAP Biller Direct.

Java Connector

The Java connector (JCo) uses a remote function call (RFC), an

SAP communication protocol, to connect the SAP Biller Direct

application (which runs on the Java servlet engine) to the SAP

back end. The JCo provides Java developers with a class library to

integrate ABAP components by using this protocol. You use the

JCo as a tool kit that enables communication between Java and

ABAP components. The business logic remains in the BAPI® pro-

gramming interface. Users employ the interfaces and methods to

call business objects, such as bills, in SAP software. The JCo sup-

ports bidirectional connections between the worlds of Java and

ABAP: a Java client can call a BAPI interface in the SAP back end

and an ABAP program on the Java server. The JCo provides high-

performance RFC middleware based on Java Native Interface and

supports synchronous, transactional, and queued RFC

connections.

You can use connection pooling to process all read accesses to

the SAP back end that do not change data. SAP NetWeaver Appli-

cation Server manages the existing RFC connections to the SAP

software. When you use connection pooling, an RFC connection

to SAP NetWeaver Application Server is not immediately discon-

nected when it is no longer needed (when a user logs off). Instead,

it is stored in a pool of existing RFC connections and reused for

the next access. This approach has the following advantages:

• Maximum performance because repeated, time-consuming

opening and closing of connections (logon and creation of a

role area in the SAP software) is no longer necessary.

• The burden on the SAP back end is minimal.

• Your customer can set up the maximum number of connec-

tions on the Web server and has complete control over the

maximum load on the back end as a result of Internet inquiries.

To enable the use of pooled connections, you must create an

anonymous service user with its own authorization profile in the

SAP software. You must assign this profile all the authorizations

necessary for the back-end processes.

You use an RFC connection for the logged-on user to execute all

write accesses that change the database in the SAP software. This

approach meets the requirements of audit security. These types

of access include transactions like payment of bills, complaints,

or stopping payment. The named connection creates a separate

RFC connection for each user of SAP Biller Direct. The connec-

tion exists only as long as the individual user action (for example,

partial payment of a bill) does and is then disconnected. With this

variant, you can be sure that all authorization checks are carried

out under the logged-on user and that all change documents are

stored under the actual user. All user-specific system parameters

are assigned the values of the user that is logged on.

9

Enterprise System Architecture

SAP NetWeaver® Application Server

Open items management

SAP NetWeaver Application Server

Front end forSAP Biller

Direct(Java)

Contract accountingAccounts receivable

SAP® Dispute Management

Javaconnector

Billing application(customer

relationship management,

billing, or sales and distribution)

Optical invoicearchive

Web Server Browser

Biller Customer

Fir

ew

all

Fir

ew

all

SS

L +

HTTP

S

SS

L +

HTTP

S

Figure 2: Architecture of SAP Biller Direct

Named connections consume more resources (such as network

connections and memory) than pooled connections do, because

several users cannot share a named connection. Constant creation

of back-end connections and logging on to the SAP software means

that the named connection operates more slowly than pooled

connections and that it increases the load on the system. Using

both access methods for SAP Biller Direct represents a reasonable

compromise between performance and security requirements.

Most accesses are read accesses (for example, account display) and

therefore require only pooled connections. You require named

connections for the rarer write accesses.

Log Functions and Reporting

With SAP Biller direct, you log all the principal activities of users

to ensure that pooled connections can be audited. The logged

activities include logging on to the system, displaying a bill, (par-

tial) payment of a bill, or canceling a payment. As soon as one of

these events occurs, a log entry is created. For each combination

of event type and company code, the system administrator can

define whether an event type is logged and how many days log

entries are stored. The administrator can also decide to log the

oldest, newest, or all entries for each user and document. The

administrator’s decision can reduce the volume of data. Generally,

users are more interested in whether a document has changed

than in how often it has been displayed. If the administrator

chooses the option of the oldest entry, only one log entry would

show when the document was first displayed. The option for

the newest entry would show when the user last displayed the

document.

You can also set a deletion deadline and delete superfluous log

entries with a reorganization job that you schedule periodically.

You have the following reporting options:

• Display all log entries for each user

• Display all log entries for each document

You can also extract log entries in business intelligence and use

them to analyze user behavior.

Transfer ofbill data

10

Authentication and Authorization of Users

You require authentication of every customer who calls SAP Biller

Direct from an Internet browser. You can use various technical

options to accomplish this task.

In one option, you create each Internet user as an SAP user (SU01

user) in the SAP back end. For the sake of better performance and

simpler maintenance, you create users without their own autho-

rization data and that refer to a reference user. Internet users

receive their authorizations exclusively from this SAP reference user.

They do not have roles or a profile in the SAP software. The soft-

ware does not permit separate logons of reference users and

holds them in main memory. The reference user has its own roles

and profile. The Internet user of SAP Biller Direct receives the

resulting authorizations.

To reflect the different authorizations of Internet users (for example,

a customer cannot make partial payments or pay with a credit card),

you group together Internet users with the same authorization

and create a reference user for each group. The reference user

contains the authorization profile that corresponds to this group.

All users in this group refer to the corresponding reference user in

their master data, without having their own authorizations.

You can perform authentication in SAP Biller Direct in one of

two ways:

• Enter the user name and password of the SU01 user of the

SAP software

• Transfer a single sign-on ticket (SAP SSO2)

Users who have already logged on to a portal and then call SAP

Biller Direct from the portal do not need to log on again, provided

that the portal supports SSO2 tickets. In such cases, the portal

has already authenticated the user. SAP Biller Direct receives the

authentication information as an X.509 certificate issued by the

portal system (for example, the SAP NetWeaver Portal compo-

nent). You can use SAP Biller Direct to evaluate the SSO2 ticket

and grant users direct access to their account and bill data

without any need for additional passwords.

Once the user has been authenticated, you can determine the

relevant business partner (in contract accounts receivable and

payable) or customer (in accounts receivable accounting). You

have three options for finding the right business partner or

customer.

The first option is to enter the number of the customer or busi-

ness partner as a reference in the user master record (SU01 user).

With the second option, you use the Central person technical

object to draw the one-to-one connection between user and

business partner. This technology is used in several different

solution portfolios and in the SAP Customer Relationship

Management (SAP CRM) application, which ensures seamless

integration with SAP Biller Direct.

If you have assigned several business partners to one user, the

software does not mix the data and displays the information of

only one business partner. This approach means that you cannot

have one user access several contract or customer accounts.

However, within a portal application, you can transfer a business

partner or customer number (request parameter) when access-

ing SAP Biller Direct. In such a case, the application checks to see

if the master record includes the business partner number. How-

ever, you cannot assign separate authorizations to individual

business partners.

Because you can assign several contract accounts to one business

partner in contract accounts receivable and payable, the application

displays all the contract accounts.

In the second option, you can store the users in an external

directory service that is synchronized with the Lightweight

Directory Access Protocol (LDAP), if you do not need to manage

the Internet users in the SAP landscape itself.

11

In the third option, you can store users in the user management

engine (UME) database that is part of SAP NetWeaver Application

Server. In both cases, the SAP back end stores only a few reference

users (including their authorization profiles); the LDAP directory

or UME database stores the actual Internet users. If more than

100,000 users are to access SAP Biller Direct, you should seriously

consider the second and third options.

Master Data of Participants

You can define the participation of business partners or custom-

ers in SAP Biller Direct in their master data when you work with

contract accounts receivable and payable and with accounts

receivable accounting. If no settings are present, a conventional

paper bill is sent. You must also maintain the required recipient

addresses (short message service [SMS] or e-mail address) in the

master data of the customer or business partner.

When you perform accounts receivable accounting, you must

maintain additional details in the company code segment of the

master data. Here, you can define the period in which customers

participate in SAP Biller Direct, which business transactions

about which customers should be notified, the communications

medium (SMS or e-mail), and when the notification occurs. The

permissible settings include the following:

• From and to date of participation in SAP Biller Direct

• Notification by SMS or e-mail

• Notification of credits, bills, or both

• Notification immediately, weekly, or monthly

When you work with contract accounts receivable and payable,

you make these settings in the contract accounts rather than

in the business partner. You can define the notification type in

more detail, along with information about whether the customer

will also receive a paper bill. You can make these settings only if

you have already defined the customer’s participation in SAP

Biller Direct in the business partner master data. You can make

the following settings in the contract account master data:

• Notification by SMS or e-mail

• Notification of new credits or new bills

• Additional dispatch of a paper bill

Your customers can enter their own data with an Internet

browser so that they receive bills electronically and select their

communication preferences.

Your customers can also request a user for SAP Biller Direct

(passive enrollment). They fill out an application online in the

Web application or send the request to the biller in writing. The

accounting clerk responsible can work with a work list as an

internal message to access and approve the online request from

the customer. The biller can also use programs in contract accounts

receivable and payable and in accounts receivable accounting to

inform business partners or customers by using the Internet

service (active enrollment). The biller can print (and send) the

enrollment information or send it directly by e-mail.

Notification of Account Changes

Your customers who use SAP Biller Direct to display their account

and bill information can automatically receive information about

account changes. New bills or credits can trigger the changes.

You use different concepts with accounts receivable and payable

and with accounts receivable accounting. With accounts receiv-

able accounting, you use message determination from the sales

and distribution functionality of SAP ERP. With contract accounts

receivable and payable you access the print workbench and cor-

respondence by using two contract accounts receivable and

payable events. The transmission types supported include SMS

messages for cell phones and e-mails (encrypted if necessary). In

the latter case, customers receive an e-mail that contains general

details of the bill and perhaps a hyperlink that they can use to

access the biller’s portal. The biller does not have to send a paper

bill.

When you work with contract accounts receivable and payable,

you use the print workbench to create customer notifications.

You use correspondence to send the notifications to customers

immediately, periodically, or, if necessary, repeatedly. You can

use the print workbench to print simply structured letters and to

print forms whose layout is based on a complex data hierarchy.

You can also use it for mass printing of forms. The functionality

integrates text processing from standard SAP software. You can

12

use the functionality to prepare the data and forward it to the

output medium or to provide the form data with a raw data

interface. In that case, external systems pay out and print the

forms.

Correspondence enables creation of written material for the

business partner based on individual requests (such as account

information) and mass requests (such as bill printing). You must

be able to identify the bills and credits that arise in billing so that

you can inform the business partner. Identification occurs by

defining primary and subtransactions that specify the business

transactions that lead to a notification. When you work with SAP

Biller Direct, you create correspondence for specific events or

periodically. You generally create event-controlled correspondence

with a business transaction (such as a dunning notice). You use

periodic creation for correspondence that occurs regularly (such

as bills) or individual correspondence requests (such as account

statements).

With accounts receivable accounting, you use output determi-

nation in the sales and distribution functionality of SAP ERP to

send notifications. Output determination supports you with dif-

ferent functions for purchasing, dispatch, transport, and billing

output. It is part of the output control in the functionality and is

used to exchange information with internal and external part-

ners. Participants in SAP Biller Direct are notified when new

credits and bills are posted – according to an output type. The

form of the output type depends on the frequency of dispatch

(immediately, weekly, or monthly). A separate output type

controls each level of frequency.

If SAP Biller Direct is to inform the customer about new postings,

the output procedure first performs checks to see if the customer

participates in electronic billing at all. The application uses the

communication preferences of the customer to determine whether

to send the notification immediately or asynchronously. You

can use text processing functionality and Smart Forms to create

output forms.

Selecting Open Items

You can assign various statuses to an item in contract accounts

receivable and payable or accounts receivable accounting:

• Open

• Cleared

• Collectible (set when a payment method or bank details are

entered)

• Payment instruction submitted

If a customer calls SAP Biller Direct, a bill reads and summarizes

the open items of the customer or contract account. In the real

world, a bill is not always exactly one open item. Instead, several

open items usually relate to a bill. The billing system (for exam-

ple, the sales and distribution functionality of SAP ERP) provides

the number of open items and groups them into one bill in contract

accounts receivable and payable and accounts receivable account-

ing. If a bill consists of several amounts that are partially cleared

or open, the front end creates different posting items. One line

can have several open items.

Bill Display and Download

You use the accounting interface to transfer bill data from the

billing system to contract accounts receivable and payable or

accounts receivable accounting. The source systems can include

the sales and distribution functionality of SAP ERP, industry-

specific billing applications (such as SAP for Utilities), or the

billing engine. You also have access to the optical (bill) archive.

A user logon first processes an event in contract accounts receiv-

able and payable or a business add-in in accounts receivable

accounting. Bill items read and summarize the open items for a

business partner or customer. You can display the bills due in the

Internet account along with the bill text, the bill amount, any

remaining payable amount, and the due date. In the bill over-

view, the billing application returns a bill format to the business

add-in or the event. You can display or download the bill details

in different formats, depending on the billing source system.

Options include CSV, PDF, HTML, and XML.

13

You use output control in the sales and distribution functional-

ity of SAP ERP to print bills. You determine the print program

and the corresponding text processing form or Smart Form from

the output type. The sales and distribution document must con-

tain output to be printed. If a bill has already been printed once,

an output record already exists. You can use the output record

to call the print program. If no output record exists, you must

create one and then access the corresponding routine of the

print program.

You have three options for accessing billing documents in the

sales and distribution functionality of SAP ERP:

• You can adjust the print program so that the print result is not

sent to a printer (or the spool). Instead, the text processing

form is converted from output text format (OTF) to PDF. OTF

consists of legible characters and describes the prepared text

for a specific output device. The PDF data flow is then returned to

the calling Web transaction and the Internet browser. The PDF

document is displayed with Adobe Acrobat Reader on the user’s

PC. The user can now print the document locally or save it.

• If the bill has already been archived, you can use an optical

archive to display the document. The archive Web server can

be accessed directly from the Java application with SAP software.

As a further option, you can access the optical archive with

SAP ArchiveLink® software. SAP ArchiveLink is a communica-

tion interface between SAP software and external components

and is integrated in the basis of the SAP software.

• You can access bills and payments with the bill raw data in the

sales and distribution tables. The data is transferred to a stan-

dard interface of SAP Biller Direct and formatted as a JSP page.

If you want to display bill details from other billing industry sys-

tems (such as SAP for Utilities and SAP for Telecommunications),

you can also use the options noted above. You can display PDF

documents from optical archives using the variants described

above, you can use the print program (conversion of text pro-

cessing forms from OTF into PDF or conversion of Smart Forms

into PDF, HTML, or XML), and you can provide raw data and

create a JSP page for non-SAP billing systems.

Your customer can download bills in CSV, PDF, or XML format.

You can also use a digital signature from the biller on the outgoing

bills and provide the signature for download.

Displaying the Bill and Payment History

When you release the bill, the status of the open items changes

from Open to In progress. The items no longer appear in the list of

bills due but in the bill history. However, if the provided payment

has not been made, the customer can reverse the bills that have

been released and arranged for collection at any time (see below).

Figure 3: Display of Payment History

After the payment run, the status of the bill changes again – from

In process to Processed. If customers now look at their Internet

accounts, they see the bills with this status in the bill history.

Customers can use numerous display variants. SAP Biller Direct

also enables customers to display paid bills. In the detail view,

customers can see which payments or credits were used to pay

the bill. Customers can also analyze their payments and see which

payments or credits paid specific bills.

14

Payment Methods

SAP Biller Direct provides you with a variety of payment methods.

For the automatic debit (direct debit) payment method, the pay-

ment run posts a clearing document (to a cash clearing account),

and marks the items selected for payment as completed (Cleared).

These actions clear the balance of the customer or contract

account. The subsequent payment media print program runs

after the payment run and creates the payment media for the

bank (different in each country).

For the credit card payment method, SAP Biller Direct provides

you with a communication interface to external financial service

providers, such as banks or credit card companies, with a payment

card interface (PCI). The PCI first uses an RFC to create the con-

nection between the SAP software and external authorization

software. SAP data (such as card type and trader ID) is converted

into the format of the relevant financial service provider. The

authorization of the card data (the comparison of the customer’s card

data with the data processing system of the financial service pro-

vider) can occur in real time. The SAP software stores the answer

(positive or negative) with an authorization number. SAP Biller

Direct supports both “hard” and “soft” authorization. Hard

authorization means that the trader can enter the required debit

amount. This approach makes good sense if the financial service

provider continually monitors the credit card limit. Soft authori-

zation transmits a notional amount (for example, a U.S. dollar)

and then checks the validity of the card.

SAP Biller Direct also supports the credit card check digit, and

you can configure the input field so that the number is visible,

invisible, or even a mandatory-entry field. Contract accounts

receivable and payable and accounts receivable accounting do

not store the check digit, so that the customer must enter the

number for each payment transaction.

The payment run itself then behaves just as it would for automatic

debit. It clears the contract account and posts to a card report

account. Instead of using the payment media print programs,

you use a separate program to handle settlement with the credit

card company. After the payment run, you use a payment card

settlement program to create a payment card data medium that

is sent to the credit card company or a defined processor over

the PCI.

Contract accounts receivable and payable supports direct payers,

in other words payers who use SAP Biller Direct to display their

bills and then pay them offline (by check or bank transfer). If a

Web application user selects an item for payment by check or

transfer, you can create a payment advice note automatically for

the item in contract accounts receivable and payable. However,

you do not enter a payment method in the open items, which

means that dunning activities are not affected. If the customer

cancels the bill through SAP Biller Direct, you use contract accounts

receivable and payable to delete the payment advice note. The

confirmation screen of SAP Biller Direct displays the number of

the generated payment advice note for the customers as a refer-

ence number that they can enter in the note to payee of the transfer

medium or check. For incoming payments, the payment advice

note information facilitates automatic assignment of payments

to open items.

Stopping Payments

As long as the payment run has not been executed, your customer

can cancel payments that have been released. Customer cancella-

tion of a payment removes the bank or credit card details, the

payment group (only with contract accounts receivable and pay-

able), and the payment method from the items concerned. Items

that were split because of partial payments remain split but invis-

ible to the customer. However, customers cannot use Internet

functions after the payment run to cancel clearing to make the

cleared items open again. For all document changes made, SAP

Biller Direct creates change documents so that you can trace

all changes to the status of an item.

Offsetting Credits

With SAP Biller Direct, you can offset credits against open items,

which means that credits are always treated as open items. You

enter the same payment method in the open items and the credit

15

and the same payment group in contract accounts receivable and

payable. The payment program finds both items, groups them into

the same payment group, and clears them both.

The application selects the available credits for the customer auto-

matically, based on the due date. For example, you cannot offset

a credit that is due on January 15 with a bill that is due on December 1.

You can make additional settings in customizing to enable cus-

tomers to select credits for offsetting or to pay out credits. Such a

payment can be made only in agent mode (contract accounts

receivable and payable).

Link to SAP Cash and Liquidity Management

When you post a document in contract accounts receivable and

payable or accounts receivable accounting, you update SAP Cash

and Liquidity Management. Accordingly, the liquidity forecast

and the cash management position are always up-to-date. You

can define a cash management group in the contract account

master record for updating the liquidity forecast. With this

approach, you can consider contract accounts with automatic

debit authorization separately from the contract accounts of

direct payers. The application suggests a cash management group

when you enter a document. When a document is posted, you

are supported with derivation of a cash management level that

gives information on the origin of the cash flows. For example,

the cash management level helps you determine if the document

is a bill or a purchase order.

Status changes in the open items can also affect cash management.

If a customer has seen or rejected a bill or approved a payment,

you can change the cash management group or level. The update

of the cash management item is related to the document change,

so that the cash management group or level changes not only in

the document, but also in the planned totals. In contract accounts

receivable and payable, you use a customer exit to define which

cash management change is to be reset by the payment of a bill

(and whether such a payment is relevant for cash management).

The customer exit is integrated in the document change, so that

change documents are also written.

Integration with SAP Dispute Management

SAP Biller Direct is integrated with SAP Dispute Management so

that your customers can create dispute cases directly from SAP

Biller Direct. They can create dispute cases for partial payments

and for the entire bill. Integration enables your customers to:

• Enter a reason code

• Create an initial note

• Select customer contact data

• View the status of a dispute case

• Communicate with the dispute case department using notes

• Upload or download attachments

Internal dispute case processing can begin after a dispute case has

been created in the SAP software.

Figure 4: Creating a Dispute Case in SAP® Biller Direct

16

Clerk Mode

The design of SAP Biller Direct not only supports customer self-

service, but also clerks within a company (for example, in a call

center). The clerk can first search for customer or contract accounts

of customers by entering the address data of the required customer.

After displaying the bills to be paid, the clerks can receive customer

orders for incoming or outgoing payments. Contract accounts

receivable and payable also supports cash payments. Employee

actions are logged in the same manner as customer actions.

Clerks also use clerk mode to enter the relevant payment meth-

ods, bank or card data, and the payment group in the open items.

For payment transactions, the clerks can also print receipts for

customers or send them receipts. The receipts contain information,

such as the name and address of the customer, the date, amount,

and currency of the payment, the paid bills, and the payment

group number.

Additional Business-to-Business Functions

You can configure SAP Biller Direct and accounts receivable

accounting to support a variety of business-to-business scenarios.

Configuration includes balance display, balance confirmation,

and the creation and changing of payment advice notes.

You can display the balance for the last six or twelve months –

it is not tied to a fiscal year. The initial screen displays a monthly

summary and is separated into receivables and payments. Customers

who require more detailed information can drill down to line

item level. The user can also perform or send a balance confirmation,

contest the balance, or save or print the balance list locally with

Microsoft Excel.

With SAP Biller Direct, you have a clearly structured display of

payments already made and of open bills. Users can make assign-

ments themselves, enter a comment if there are variances, and

send the completed assignments to their business partners. A pay-

ment advice note is then created in accounts receivable account-

ing. Users can display the payment advice notes that they have

created and that have not been posted by the biller. As long as the

payment advice note has not been posted in accounts receivable

accounting, users can edit or delete the payment advice notes.

Once users delete the payment advice notes, the bills and payments

reappear in the list of open items.

17

SAP Dispute Management: Overview

The SAP Dispute Management application supports you in

processing receivables-related dispute cases. Such cases can be

triggered by:

• Unauthorized payment deductions

• Nonpayment

• Receivables-related customer complaints

SAP Dispute Management supports internal company processing

of such dispute cases and integration of the customer in the process.

Many companies overwhelmingly perform this process outside

of their enterprise resource planning (ERP) system. In a typical

process, they create a new dispute case manually in a document

that is on a department server. Information from colleagues in

other departments is then requested by e-mail, telephone, or inter-

office mail. Keeping deadlines for confirmation of information

involves a great deal of manual outlay in terms of time and resources.

The information supplied is often available only locally on the

accounts receivable employee’s computer or stored in paper files,

making it unavailable to all parties involved in the dispute. Only

a time-consuming process can handle the evaluation of the number,

status, and reasons for the dispute case. This example indicates

the enormous potential for increased efficiency within this process.

With SAP Dispute Management, your company can process the

dispute in a structured and highly efficient manner. Companies

create every dispute case automatically or manually, depending

on what triggered the case or the communication channel. The

dispute case itself is a kind of electronic file that stores all the rel-

evant information for the dispute in a structured manner. The

postings you make in accounts receivable automatically update

the dispute case, so that accounts receivable always represents

the current status of the customer items in dispute. The dispute

case is the central store of all information that can be viewed by

the relevant employees. Dispute case attributes show employees

the processing status at a glance, along with a summary of the

reason, the current processor, and other information. You can

use a note function for accurate documentation of the individual

steps undertaken to resolve the dispute. The integration of SAP

Dispute Management with the SAP Business Workflow tool

enables easy integration of employees in other departments

involved in processing. This approach lets you significantly

reduce processing times. You can escalate critical dispute cases

to higher levels of management. You can also inform your cus-

tomer about the status and the result of dispute case processing –

at the touch of a button or automatically. The application pro-

vides you with standard evaluations to facilitate transparency

across the entire process, and, by evaluating the causes, supplies

infor mation showing which internal processes can be improved.

Processes Supported by SAP Dispute Management

Management of Payment Deductions

Payment deductions become visible at the level of the vendor dur-

ing incoming payment processing. The display of payment deduc-

tions generally occurs automatically, whether the deductions are

taken by electronic bank statement, lockbox processing, or check

presentation. In the case of payment deductions, accounting

clerks must undertake postprocessing to create the correspond-

ing residual items and assign reasons for discrepancies to them.

They can also post incoming payments manually or automati-

cally and create residual items for payment deductions in the same

way. In either case, they can create dispute cases for the residual

items that represent payment deductions. Accounting clerks can

create a dispute case during postprocessing of automatic process-

ing or during processing of a manual incoming payment process-

ing. They can also start a program (after incoming payments

processing) that automatically creates dispute cases for the residu-

al items. The application derives the reason for the dispute case

from the reason code, provided that it is available. Clerks can

then start the actual process for resolving the dispute case. Depend-

ing on the reason for the dispute case and other criteria specific

to the particular company, employees from widely differing

departments become involved in processing the case. All employ-

ees involved in the processing document the result of their

SAP DISPUTE MANAGEMENT

18

investigations or any decisions made in the notes for the dispute

case, so that all the steps taken to resolve the dispute are clearly

understandable to all involved parties.

For dispute cases involving payment deductions, it is absolutely

essential that a clearing posting for the residual items in dispute

trigger the case (see “Process Integration”). If the dispute case was

justified, you grant the customer a credit memo that is cleared

against the residual items. You can create the credit memo in the

billing system or directly in accounting. If the payment deduction

proves to be unjustified, you can request the residual items from

the customer. The related correspondence requests that the

customer pay the disputed amount. You can also use SAP

Collections Management to request payment from the customer.

If the customer makes payment, you clear the residual items

against the payment. You can escalate critical dispute cases to

senior management. If you deem the disputed residual item

uncollectible, you can write it off automatically.

You can keep the customer informed of the status of the dispute

by e-mail, fax, or letter throughout the dispute process or include

the customer in the process by requests for information.

Dispute Cases Reported by Customers

Dispute cases can arise for payment deductions or when the

customer informs the vendor about a disputed receivable. The

relevant contact persons in accounts receivable, employees in a

dispute management department, or customer contacts made

during collections management report such dispute cases. You

create a dispute case for the invoice or bill concerned from the

line item display or from SAP Collections Management and

document the reason given by the customer.

Your customer can also create a dispute case using SAP Biller

Direct. Once the customer has created a case, the processing and

resolution of the case is identical to that of dispute cases for

payment deductions.

Functions in Detail

The Dispute Case

The dispute case is a separate object in SAP Dispute Management.

It consists of dispute case attributes, an electronic case record, a

note editor with a note history, an application log, and various

other functions.

Dispute case attributes provide the user with an overview of the

dispute case. They show the customer, amount, and reason for

the dispute case; the current processor; and the status of the case.

The application fills some of the attributes with data automatically,

including the Customer, Company code, and Amount fields, such as

Disputed amount. Users can set other attributes to document the

process status. Customers can include their own attributes in the

dispute case along with standard attributes. This approach gives you

the ability to include additional organizational information in the

dispute case.

The Case record contains a folder structure that you can use to

link SAP objects and other documents. By default, the application

contains a structure with the following folders:

• Business partner

• Disputed objects

• Resolved objects

• Items assigned during clearing

• Other objects

• Various

You can enhance the case record in the project and adapt it to user

and process requirements. You can link SAP objects, such as

document items, billing document, customer, documents of

various document categories, and archived documents. The

application automatically links the disputed open items to be

resolved in the folder along with document items that led to

clearance of the disputed items. It also links the master record of

the customer automatically, along with the billing document, if

available (sales and distribution functionality of SAP CRM). You

19

can also use the case record to link other documents to the dispute

case, such as scanned, handwritten documents, or to manage

other attachments. In this manner, all information required for

resolving the dispute case is available in structured form to all

employees involved in the processing. You also use the case

record for additional documentation of the result of dispute

case processing.

The notes portray dispute case processing in chronological order.

Employees use them to document the results of their investigations,

notify others about the decisions made, or to communicate with

other employees involved. Note categories help users to structure

notes. Examples of note categories can include:

• Description of the problem

• Result

• Concluding comments

You can also use notes as text modules for customer

correspondence. You can designate specific note categories as

externally usable in customizing.

You can use the following functions to process the dispute case:

• Add disputed items to the dispute case

• Transfer contact data of the contact person from the customer

master record to the dispute case

• Request correspondence for the customer

You call the functions with function keys. You can develop

additional functions during the implementation project and make

them accessible with a function key.

Process Integration

SAP Dispute Management supports you during processing of

receivables-related dispute cases. Integration with accounts

receivable is therefore a critical factor in successful improvement

of this process.

Integration with accounts receivable involves two important

considerations:

• Creation of dispute cases from transactions in accounts

receivable

• Update of dispute cases from transactions in accounts

receivable

Figure 5: Dispute Case

20

You can view unjustified payment deductions when posting incoming

payments. Users can create dispute cases directly from the posting

of incoming payments. Users can also create dispute cases directly

from the postprocessing of electronic account statements and

from lockbox files. For payment deductions that have arisen from

the import or postprocessing of electronic bank statements or

lockbox files, you can enable automatic creation of dispute cases.

You can exactly control the amount limit, customers, and discrepancy

reason for which you want to create dispute cases.

Incoming payments processing, the line item list, account main-

tenance, and document display offer options to create dispute

cases.

When you create a dispute case, the application automatically places

the disputed items in the Disputed items folder of the dispute case

record. It simultaneously enters the disputed receivables amount

in the Original disputed amount and Disputed amount fields.

Incoming payments, credit memo clearing, and other clearing

transactions relating to disputed items update the dispute case.

You link the clearing documents in the relevant file folder of the

Case record for the dispute case and update the Amount fields. The

Disputed amount is reduced by the clearing amount. At the same

time and depending on the clearing type, the Credited, Paid, or

Manually written off fields are updated with the clearing amount.

The Original disputed amount remains the same to document the

amount of the originally disputed receivable. You can finally

close a dispute case after all of the disputed items have been cleared,

making the Disputed amount zero.

Dispute Case Processing

Two groups of people are usually involved in dispute case processing:

experts in the accounts receivable department and employees of

other departments who are included in the processing, depend-

ing on the case. SAP Dispute Management provides each group a

different work environment.

Employees in the accounts receivable department are responsible

for processing disputed receivables. Some companies have a

separate organizational unit to handle this situation. Other

companies regard dispute case processing as the responsibility

of collections and credit management employees. SAP Dispute

Management uses the term “coordinators” to refer to employees

responsible for dispute case processing. The application provides

a separate attribute in the dispute case for the coordinator role.

You enter the user name of the employee responsible here. The

coordinator is responsible for ensuring that a case is processed

within the allotted time. The coordinator usually determines

which other colleagues should be included in the processing

and the process flow. Moreover, the coordinator is the central

contact person for all questions regarding the dispute case.

Whenever the coordinator is also responsible for the current pro-

cess step, the coordinator is simultaneously the processor of the

dispute case. The application provides a separate dispute case attribute

for the processor just as it does for the coordinator. You enter the

user name here.

Figure 6: Creation of a Dispute Case for a Payment Deduction During Incoming Payment Processing

21

The employees responsible for dispute case processing work in

the dispute case organizer, which supports you with the following

functions:

• Predefined, role-dependent dispute case search

• Freely defined dispute case search

• Display or change of dispute cases

• Mass changes to dispute case attributes

• History

• Resubmission

The predefined dispute case search enables users to create a list of

dispute cases to which they are assigned either as coordinators or

processors. As an alternative, users can define their own dispute

case search. You can use the dispute case attributes as search criteria

and search variants for searches run frequently. The dispute case

search provides you with a list of dispute cases that correspond to

the search criteria. You can sort the list, filter it, or format it

differently. Users can navigate from the list directly to the display

and processing of a dispute case.

Processors create a note to document the result of processing

and can save the result by setting a status and a reason. They can

download additional documentation that contributes to the

resolution of the case to the folder of the case record as an attach-

ment. Likewise, they can link other SAP objects or assign archived

objects to the case.

Companies typically include other employees in dispute case

processing. If help is required from another colleague, the colleague

must be assigned to the dispute case. You can also set a processing

deadline for the colleague. An employee can use a note to request

information required from another employee. If you then assign

the dispute case to a different processor, the application automatically

removes the dispute case from the previous processor’s list of dispute

cases.

As soon as you set a new employee (outside of collections and

credit management) as the processor of the dispute case (occasional

processor), an e-mail notifies the employee of the assignment.

The application creates a workflow task at the same time. The

workflow task appears in the processor’s SAP Business Workflow

in-box under the heading of “dispute management.” The processing

Figure 7: Dispute Case Organizer Figure 8: Dispute Case Processing in SAP® Business Workflow – Upload of Documents

22

deadline that you have set is visible in this overview. The employee

can select the appropriate workflow task and then navigate to

simplified dispute case processing. Simplified processing directly

from the workflow covers the following functions:

• Overview of the most important dispute case attributes

• Link to the dispute case and to the billing document or invoice

• Creation and display of notes

• Uploading or downloading of documents

Once a processor has documented the result, the processor can

return the case to the coordinator or forward it to a different

processor. The processor usually returns the case to the

coordinator as the central contact person. The coordinator sees

the case in the dispute case organizer once again in the

predefined search for the processor role and triggers the next

processing step as necessary. Figure 9 illustrates such a workflow.

Customer Correspondence and Internal Escalation

During dispute case processing, your company often must get in

touch with a customer. To simplify such communication, the

dispute case provides you with the contact data of the contact

person at the customer’s company. The processor of the dispute

case can contact the customer by telephone and use a special

note category to create a note with the result of the telephone

call. With SAP Dispute Management, the processor can also contact

the customer by letter, fax, or e-mail, all of which is described as

customer correspondence.

• Read e-mail• Access workfl ow in-box and

execute work item• Confi rm late delivery• Return dispute case to Sally

• Assign John Miller asnext processor

• Ask John Miller toconfi rm late delivery

• Create work item and sende-mail infrom John

• Assign Tom Busy as next processor

• Ask Tom to decide about dispute• Create work item and send

e-mail• Read e-mail• Access workfl ow in-box

and execute work item• Decide that credit memo

should be granted• Return dispute case to

Sally

• Assign Hans Doe as next processor• Ask Hans to post credit memo• Create work item and send e-mail

• Read e-mail• Access workfl ow in-box

and execute work item• Post credit memo• Return dispute case to

Sally

John Miller –shipping clerk

Sally Smith –dispute manager (coordinator)

Tom Busy –account manager

Hans Doe –accounts

receivable clerk

Figure 9: Workflow Processing

1

2 3

4

56

23

There are two types of customer correspondence: contact

created automatically by the application and contact initiated

manually by the processor.

A user can create correspondence automatically when creating

or closing a dispute case. You can make appropriate settings to

inform customers automatically when the status of a dispute

case has changed. For example, if the status shows that the dis-

pute case has been decided in favor of the customer, you can notify

the customer that a credit memo for the disputed amount will

be issued.

In addition to correspondence created automatically, the proces-

sor can request correspondence while processing the case. The

processor can decide to whom correspondence is to be sent, the

correspondence type used (e-mail, fax, or letter), and which

form is to be selected. Further, the processor can use certain

notes as a text module to structure each document individually.

The processor can also add an attachment to an e-mail.

During implementation, you can design forms for the corre-

spondence to meet any company-specific requirements. The

application always provides all the data from the dispute case for

the form layout, including all attributes, and links it to SAP

objects such as a billing document. The text of the form can

include the data in a variety of ways.

Users can also escalate critical dispute cases within the company.

Users enter a reason for the escalation in the dispute case, which

means that the senior manager responsible is notified of the

escalation by e-mail.

Reporting

Reporting in SAP Dispute Management enables you to analyze

dispute case processing in detail. You can use such analysis as a

starting point for improvements in the process. Key figures, such

as the average duration of dispute cases per reason or the average

disputed amount, indicate areas where processing can be expe-

dited. A thorough investigation of the reason for dispute cases

enables you to take preventive measures that reduce the number

of dispute cases.

Reporting enables you to monitor customer behavior closely in

the disputed receivables area and to improve processing. Which

customers, for example, regularly underpay bills without justifi-

cation? What reasons are given? You can also analyze the overall

effect of disputed receivables on receivables management. With

appropriate analysis, you can answer questions such as “How

long do disputed receivables remain outstanding compared with

receivables that are not disputed?” or “Can the time they are

outstanding be reduced by preventive measures?”

Reporting also enables you to measure the productivity and suc-

cess rate of the department responsible for dispute case process-

ing. How many dispute cases are processed by each employee on

average? Could improvements in the process and software sup-

port reduce the period outstanding? Comprehensive reporting

can help you answer to these questions.

Figure 10: Manually Requested Correspondence

24

You have access to reporting within the SAP NetWeaver Business

Intelligence (SAP NetWeaver BI) component. Reporting is based

on the following data: all disputed case attributes, the linked

disputed amounts of financial accounting (with their related

clearing documents), and the accounts receivable line items.

This data is linked together in special data models and is available

so that you can define your own reports for SAP Dispute Man-

agement. The sample reports delivered by SAP provide an ideal

template for defining your own reports. You can also publish

all reports to the Web and can make them available to users

in Web applications.

Enhancement Options

SAP Dispute Management offers you various options for enhanc-

ing the application without modification and in customizing.

Many SAP customers take advantage of the option of defining

their own dispute case attributes to manage dispute cases and for

reporting. Most often, companies include organizational units

such as the sales organization or the profit center as an additional

attribute in the dispute case.

To automate the process to the greatest degree possible, you can

implement business add-ins that are used to populate dispute

case attributes automatically. For example, you can determine

the processor or coordinator of the case based on the reason or

customer care relationship. You can even populate new case

attributes automatically. For example, you can derive the sales

organizational units from the billing document related to a payment

deduction and store them as an attribute value in the case.

Moreover, you can enhance the screen for creating dispute cases

from accounts receivable by using business add-ins and develop

separate logic for writing off dispute cases.

You can also enhance the case record. Separate folders for certain

documents make it easier for you to upload attachments for dispute

cases and help make the dispute case more transparent.

Figure 11: Example of a Web Application for Evaluating the Results of Dispute Case Processing by Reason

25

SAP Collections Management: Overview

When you perform conventional accounts receivable accounting,

you manage receivables as open items. If open items are overdue,

you use the dunning program to send dunning letters to remind

customers of their obligation to make payment.

You can use the SAP Collections Management application to manage

your receivables more proactively. With this approach, your

receivables clerks contact customers directly (in addition to or

instead of dunning) to collect receivables on time. Contact can

even occur before the due date to increase the chance of the

incoming payment being on time. The greatest challenge for

this kind of proactive receivables management is in selecting and

prioritizing which customers you wish to contact personally.

The selection must reflect considerations of credit risk, financial

goals, and customer relationship management. Unless you have

sufficient system support, employees in accounts receivable must

perform this task themselves, or the collection manager specifies

which customers to contact and assigns employees to make contact.

If employees select and prioritize customers themselves, they lose

time they could spend on productive activities, and the company

might not contact customers or work with a uniform procedure

for selection and prioritization. Call lists are usually created outside

of the ERP system from lists on departmental servers or by spe-

cial software that must operate along with the ERP system. Inte-

gration with accounts receivable does not occur at all or only at a

rudimentary level. This kind of receivables management does not

reflect incoming payments, clearing postings in accounts receivable,

dispute cases, or changes to risk class and credit limit.

SAP Collections Management is closely integrated with accounts

receivable accounting software from SAP. Flexible rules let your

company create work lists for collection specialists automatically

according to a wide range of viewpoints. The list prioritizes the

customers to be contacted. Employees can concentrate solely on

customer contacts – significantly increasing productivity.

The definition of collection strategies lets the collection manager

respond flexibly to the various aspects of collecting open receiv-

ables and to meet financial targets efficiently. Reporting shows

how well the receivables management department is performing

and provides an impetus for improving the process with SAP

Collections Management.

Processes Supported by SAP Collections Management

Proactive receivables processing covers three processes:

• Collecting receivables

• Managing and monitoring the collection of receivables

• Synchronizing data and creating work lists

Collection of Receivables

A collection specialist performs the collection of receivables process.

A work list is created automatically for each collection specialist

on a daily basis (see “Data Synchronization and Creation of Work

lists”). The work list includes all customers to be contacted –

arranged in order of priority. The collection strategy you assign

to the customer determines the prioritization of the customers

in the work list (work list items).

To prepare the customer contact, the collection specialist needs

information about the necessity of the contact. The specialist

must also consider the customer’s account and previous customer

contacts. For an overview of the current status of the customer

account and the collection rules fulfilled by the customer, the

collection specialist can view the work list. By navigating to the

process receivables function, the collection specialist can display

the detailed view of the customer. The view lists open invoices

(with a status) for the customer. The collection specialist can also

display an overview of previous customer contacts that contains

information on the results of previous contacts with specific

contact persons at the customer’s company. The specialist can

also see promises to pay, dispute cases, and resubmissions that

arose from customer contacts.

SAP COLLECTIONS MANAGEMENT

26

To make the contact, the collection specialist uses the contact data

of the contact person at the customer’s company as displayed in

the process receivables function. The collection specialist enters

the results of the customer contact in the application:

• If a customer promises to pay open invoices, the collection

specialist creates promises to pay for the invoices specified.

• If the customer disputes an invoice, the collection specialist

can create a dispute case for the invoice.

• If the collection specialist cannot reach the contact person, or

the contact person requests that the collection specialist call

back, the specialist can create a resubmission. On the date specified,

the customer reappears on the work list.

Finally, the collection specialist uses the application to summa-

rize and document the customer contact in full. The collections

specialist then returns to the work list and prepares the next

customer contact there.

Control of Receivables Management

The collection manager performs the control of receivables man-

agement process. The collection manager is responsible for ensuring that

receivables are collected according to the financial targets of the

company. The process covers the following tasks.

The collection manager defines the criteria (collection rules) to

use for analyzing customers and prioritizing them for receivables

management. The collection manager defines collection strate-

gies and enters them into the application. The collection manager

can create different strategies depending on the customer group,

region, or receivables management organization. The application

analyzes and valuates all customers according to the strategy

assigned to them and, depending on the valuation, includes

them in the work list. The more rules that apply to a customer,

the higher the customer’s priority in the work list. Accordingly,

collection strategies are the basis for automatic creation of work lists.

The collection manager also defines which collection groups

collect receivables with a given collection strategy. The collection

manager determines which employees are assigned to a given group.

If an employee is absent, the collection manager can enter a substi-

tute for each employee who then takes over the work list items.

Collection managers are responsible for successful collection of

receivables. To monitor this process on a daily basis, they can dis-

play the work list items for all collection groups assigned to

them. Using work list statistics, they can evaluate how many

work list items have been completed, how many are still open,

and how many successful or unsuccessful customer contacts

have already occurred. If necessary, they can then redistribute

work list items between collection specialists for more even dis-

tribution of the workload and to ensure that high-priority items

are processed quickly.

Data Synchronization and Creation of Work lists

This process is a prerequisite for collecting receivables. The pro-

cess steps generally run automatically; an administrator moni-

tors the steps. The process covers the following process steps:

• Replicate customer master data

• Transfer data from accounts receivable (accounts receivable

accounting) to SAP Collections Management

• Create work lists

• Monitor processes

SAP Collections Management works with the business partner

from SAP. The application automatically replicates customer

master data to business partner master data. The application

immediately synchronizes changes to customer master data or

business partner master data. Regularly scheduled reports add

data specific to SAP Collections Management to the replicated

business partner master data. The application creates a separate

role for the business partner master record. A manager assigns a

collection group and collection specialist to the customer.

27

To create work lists, the software transfers data for open items,

last payments, and certain key figures from the customer master

record to tables in SAP Collections Management. The software

converts the customer numbers into the numbers of the repli-

cated business partners. The initial data transfer includes all

data for companies (company codes) relevant for collections

management. Subsequent transfers involve only data changes.

The data transferred from accounts receivable serves as the foun-

dation for the creation of the work lists. The process selects and

valuates all customers with open items. It creates a work list item

and assigns it to the collection specialist for every customer who

fulfills the collection rules defined in the business partner master

record. Administrators can distribute unassigned work list items

to all collection specialists in the collection group assigned to the

business partner master record.

System administrators have access to tools for monitoring the

master data replication and for creating the collection role of

business partners and work lists.

Functions in Detail

The Work list

The application generates a work list every day for each collec-

tion specialist, based on the collection strategies already in force.

The work list is the main work area of the collection specialist. It

contains references to all the customers that the employee

should contact in the course of the day – in order of priority.

The starting point for every customer contact is an overview of

all collection rules that the customer has fulfilled, including the

points achieved per rule. The overview explains the reasons and

priorities for the customer contact (see Figure 12).

A great deal of information in the work list provides an overall

picture of the customer that is useful to the employee in preparing

a customer contact. The information includes data from accounts

receivable, such as the outstanding amounts, credit, receivables,

highest dunning level, and the latest dunning date. You can format

the outstanding amounts in a due date grid (see Figure 13).

Figure 12: Work list of Collection Specialist: Valuation According to the Collection Strategy of a Specific Customer

Figure 13: Due Date Grid of Outstanding Amounts for a Customer

28

The work list contains other key figures for existing promises to

pay, resubmissions due, last customer contact, and the collection

rule with the highest valuation. The amount to be collected is a

particularly important key figure for the collection specialist. This

key figure states the maximum amount the employee can collect

from the customer in the course of the customer contact based

on the applicable strategy. The collection specialist can use it as

an objective for a customer contact.

The work list also offers key figures from SAP Dispute Manage-

ment and SAP Credit Management. It states the amount disput-

ed, the risk class, and the credit limit utilization. You can flexibly

define the layout of the work list with the required fields during a

project. Individual users can adapt it as and when necessary.

For incoming customer calls, the collection specialist can use a

search function to display the relevant customer account and to

document the contact. No work list item for the customer is required.

The work list integrates data from various applications and

details the customers to be contacted in order of priority. This

approach increases efficiency and saves time in two critical areas of

collection management: selecting and prioritizing customers and

preparing the customer contact. The collection specialist can

concentrate on contacting the customer.

In addition to the work list for the collection specialist, collection

managers can display the work list items of all collection groups

for which they are responsible. The work list statistics inform them

of how many work list items have been assigned to an employee

for each priority and how many of the items have been dealt with

in the course of the day. The statistics also show the number of suc-

cessful and unsuccessful contacts for work list items. If employees

are unexpectedly absent or the statistics indicate a necessity,

the collection manager can redistribute work list items to others

in the collection group to distribute the workload evenly or

otherwise ensure that employees deal with high-priority items

promptly.

Processing of Receivables

To contact a customer, the collection specialist selects a work list

item and navigates to the customer’s detail view, which displays

various tab pages with information. The most important tab page

contains all open invoices for the customer and the status of the

open invoices. The application reads and then displays the line

items from accounts receivable in real time. The application links

all line items with the same invoice reference to the Invoice logi-

cal object, because the collection specialist references this invoice

as the object for the customer contact. This approach makes oper-

ation of the system simpler for employees without specialized

accounting experience. The application displays data from SAP

Collections Management and SAP Dispute Management for each

invoice from accounts receivable. The invoice overview enables

the collection specialist to see which part of the invoice is open;

whether anything has already been paid or credited and how much;

and promises to pay, dispute cases, and dunning notices for the

bill or invoice. An invoice history details which incoming payments,

credit, and other clearing postings have been made for the selected

invoice. Users can navigate from the invoice history to the rele-

vant documents in accounts receivable software. Additionally,

the collection specialist can display promises to pay and dispute

cases for a selected invoice.

29

The application highlights credit memos without an invoice ref-

erence, such as overpayments, and displays them separately in total,

with an option to display individual documents.

If the customer promises to pay any invoices in the course of a

phone call, the collection specialist can select the corresponding

invoice(s) and enter a promise to pay in the application, which

immediately updates the invoice status. If the customer disputes

an invoice, the collection specialist can create a dispute case for

the invoice, which simultaneously triggers the dispute process

for the case.

The Payments tab page lists all payments made since the date entered.

The payment history offers users an overview of all items that

the incoming payment has cleared. Other tab pages show the exist-

ing Promises to pay or Dispute cases for the customer’s open invoices.

Users can display or change promises to pay here. They can display

dispute cases and have access to a list of all invoices that are affected

by the dispute case.

A separate tab page for previous Customer contacts records the

history of the contacts with the customer. The tab page details

the contact result and the first line of the note, along with the

contact date and time and the contact person. Users can display

the entire note, a list of dispute cases, promises to pay, and

resubmissions created during the contact (see Figure 15).

The collection specialist can access an overview of open resub-

missions, which serves as a reminder to deal with activities still

outstanding.

Promises to Pay, Dispute Cases, Resubmissions, and

Customer Contacts

The collection specialist documents the outcome of a customer

contact in the collections management system. The collections

specialist can use various options, depending on the progress of

the contact.

The collection specialist creates promises to pay submitted by the

customer by selecting the invoice(s) for which payment is prom-

ised and then entering the promised payment day, the promised

amount, the contact person, and a note (optional). The applica-

tion determines and proposes the promised amount automatically

from the parts of the invoice that are still open. The user can over -

write the amount. If the customer proposes a different amount, the

Figure 14: Creating Promises to Pay for Selected Invoices

Figure 15: Overview of Previous Customer Contacts

30

collection specialist can enter this amount and automatically

distribute it to the invoices, for example, by using the due date.

The collections specialist can also enter an amount for each

invoice manually. The application creates a separate promise to

pay for each invoice when the collections specialist saves it and

monitors whether the promise is kept. If you have configured

the application appropriately, it excludes invoices with open

promises to pay from dunning up to the promised payment

day plus any days’ grace granted.

The application supports users by having incoming payments

update promises to pay in real time as follows:

• If the customer pays the agreed-upon amount within the time

promised, the promise to pay receives the status of Kept.

• If the customer pays only part of the amount promised within

the time agreed, the promise to pay receives the status of Partially

kept. For payments that come in after the promised payment

date, the promise to pay updates only the Paid and Paid on fields.

• If no incoming payment is posted within the time agreed for

the invoice, a daily valuation run assigns the promise to pay the

status of Broken. Broken promises to pay mean the assignment

of a corresponding collection rule in the collection strategy

and that the customer appears repeatedly in the work list and

is contacted again. The collection specialist can use the infor-

mation available to notify the customer of the broken promise

to pay. If the customer makes a new promise to pay, the collec-

tion specialist creates another promise to pay. The application

sets a higher level automatically when this situation occurs to

document how often a customer has already made a promise

to pay for the same invoice. Companies can use this information

to increase the priority in the work list if there is a further

failure to make payment. The information continues to be

available in reporting.

• If a customer does not pay an invoice because of a dispute the

customer has initiated, the collection specialist can create a

dispute case for the invoice. This feature requires implementa-

tion of SAP Dispute Management and SAP Collections Manage-

ment. The user enters a note in the case along with the dispute

case reason to document the dispute case. The case can then

be processed.

Promises to pay and dispute cases document confirmations from

the customer for certain invoices. By creating a resubmission, the

collection specialist can influence when a customer appears in the

work list again and whether the customer should not appear in

the work list until then – despite fulfilling other collection rules.

This approach enables the collection specialist to react to situations

where the contact person at the customer’s company is on vaca-

tion and there is no point to making phone calls during this period.

In this instance, the collection specialist creates a resubmission,

enters the date of return as a resubmission date, and chooses

No contact until resubmission. Entry of a reason for resubmission

and a brief note document the reason for the resubmission (see

Figure 16). As soon as the resubmission date has been reached, the

work list once again displays the customer, the resubmission

date, and the reason. Following the customer contact, the

collection specialist must set the resubmission to completed.

Figure 16: Create Resubmission

31

Once the customer contact has been completed, the collection

specialist navigates back to the work list. The application requests

that the collection specialist document a summary of the result

of the customer contact. Even an unsuccessful contact should be

documented to measure performance and productivity.

The application proposes most of the data for documenting the

contact on the screen. The data includes the contact date, con-

tact time, contact type, and a standard note that relates to the

promises to pay, dispute cases, and resubmissions created during

the contact. The employee simply selects a contact result and

can then add information to the predefined note or overwrite it

(see Figure 17). The contact result that the user selects determines

whether the work list item is set to completed, which removes it

from the work list. For statistical reasons, it also determines

whether the customer contact was successful, meaning that the

contact person was reached. The user can define a variety of

contact results in customizing (for example, customer reached

or left message on answering machine).

Collection Strategies and Collection Groups

A collection strategy consists of company-specific rules used as a

basis to determine which customers must be contacted from a

receivables management point of view. All customers are ana-

lyzed and valuated according to the strategy assigned to them

and, depending on their valuation, included in the work list. The

more rules that apply to a customer, the higher the customer’s

priority in the work list. Collection strategies therefore provide

the basis for the automatic creation of work lists.

Collection managers define the collection strategy for their

areas. Creating a collection strategy is easy. Collection managers

select rules relevant for their strategy from a list of predefined

collection rules. They then assign the desired characteristics to

the rule. An example illustrates this process:

• Collection rule: total of all items overdue for n days

• Parameterization: total of all items overdue for 10 days – total

amount greater than US$1,000.

The rule text always reflects the result of parameterization,

which means that it is always comprehensible for the user.

Collection rules refer to data from accounts receivable, SAP

Collections Management, SAP Dispute Management, and SAP

Credit Management. These rules are delivered with SAP soft-

ware. The following rules serve as examples:

• Risk class

• Total of all items overdue for n days

• Amount of an individual item overdue for n days

• Total of all items due within n days

• Amount of an individual item due within n days

• Credit limit utilization

• Amount to be collected

• Broken promises to pay

• Total of amounts from dispute cases to be collected

• Dunned amount still to be collected n days after dunning

Figure 17: Customer Contact

32

When the user has assigned all relevant rules for the strategy, the

application distributes valuation points for each rule. Then points

are assigned to a customer when a rule is fulfilled. Consequently,

the rules themselves are prioritized. The total of all valuation points

gives the maximum valuation of the strategy. The application sets

the points earned by a customer during the valuation in propor-

tion to the maximum valuation of the strategy. The application

uses this procedure to derive the customer’s priority in the work list.

The collection manager not only defines the collections strategy,

but also determines which collection group collects the receiv-

ables and with which strategy. The collection manager assigns

every employee to one or more groups. All employees in a group

collect according to the same strategy, which means they can be

compared with each other.

Organizational Structures and Business Partners

SAP Collections Management uses the business partner from

SAP in a specific role. Users define a collection profile for the

business partner in this role for SAP Collections Management.

Consequently the business partner participates in collections

management (see Figure 19). How the customer is to be treated

in SAP Collections Management is derived from the profile.

Figure 18: Collection Strategies

Figure 19: Business Partner in SAP® Collections Management

In addition to collection rules, the strategy also defines the cur-

rency of the customer valuation and the currency used to display

the amounts in the work list. The strategy also contains the

number of due date periods for the due date grid and the num-

ber of days per period. Companies can also use the strategy to

determine how to proceed with receivables before the due date

for net payment. Collection managers can include receivables in

the valuation before their due date for net payment, for example,

if they wish to consider receivables due in the next three days for

a customer contact. They can also include a due date for cash dis-

counts in the calculations and use the strategy to define how

many tolerance days are to be taken into account following a

dunning notice to calculate the amount to be collected.

33

If the definition of the collection profile groups all company

codes (companies) into one collection segment, the customer

is treated in the same way across all company codes. Because a

collection group is assigned to the business partner for each col-

lection segment, only one collection group is responsible for the

customer in all companies and contacts the customer based on

the collection strategy assigned to the group. Conversely, if the

collection profile groups company codes into collection segments

per region, support exists for an approach that uses a shared

service center. A group that works with its own strategy is

responsible for each collection segment that represents a region

with several company codes. A local collection profile, however,

would assign each company code to one separate segment.

Mixed forms are also supported. Because several collection

segments can be managed at the same time, users can assign

different collection profiles for each customer or customer

group and therefore enable following a variety of approaches in

receivables management.

The assignment of a group to the collection segment of a busi-

ness partner also automatically determines which collection

strategy is used to valuate the customer. Moreover, the collection

manager can assign a specific collection specialist from the col-

lection group to the customer. This employee then automatically

receives all work list items for the customer in the relevant

collection segment (see Figure 20).

Figure 20: Connection Between Organizational Structures and Business Partners

Company code Germany

Company code UK

Company code U.S

Collectionsegment

global

CollectionsegmentEurope

Collectionsegment

U.S

Collectionprofileglobal

Collectionprofile

regional

Businesspartner 1,000

Businesspartner 1,001

Business partner 1,002

Segment global

Segment Europe

Segment U.S

Segment Europe

Segment U.S

Specialist Duffy

Group Europe

Specialist Parker

Group U.S. East

Specialist Duffy

Group Europe

Specialist Smith

Group VIPStrategy

Specialist Duffy

Group Europe

Specialist Duffy

Group Europe

Specialist Miller

Group U.S. West

Strategy

Strategy

Strategy

Strategy

34

If required by the payment behavior, the collection manger can

temporarily assign the business partner to a different collection

group with a different collection strategy. If the payment behavior

improves, the original group and collection specialist can once

again be responsible for collecting receivables.

Data Synchronization and Creation of Work lists

Because SAP Collections Management uses the business partner

from SAP, customer master data must be synchronized with

business partner data. The application performs synchronization

automatically with the cross-application function for master

data synchronization (customer-vendor integration). As soon as

a user creates customer master data, it is replicated in business

partner master data. The contact persons for the customer become

separate business partner records with a connection to the business

partner master record that represents the customer. Regularly

scheduled reports add data specific to SAP Collections Manage-

ment to the replicated business partner master data. The reports

ensure that the required collection profile is assigned to the business

partner and that the correct collection group (and optionally a

collection specialist) is entered in the business partner master

record at the level of the collection segment. Business add-ins

enable creation of separate rules on how such assignments are

made.

Work with SAP Collections Management requires you to transfer

data from accounts receivable to SAP Collections Management.

You can transfer open items, last payments, and certain key fig-

ures from the customer master records. The software converts

customer numbers into the numbers of the replicated business

partners.

The initial data transfer includes all data for companies (com-

pany codes) relevant for collections management. Subsequent

transfers involve only data changes. The data transferred to SAP

Collections Management serves as the basis of the work list. To

ensure that the work list is up-to-date, the data must always be

transferred again before creation of the work list, which should

always be created daily. During creation of the work list, the applica-

tion valuates the customer based on the collection strategy

assigned to the customer. Because the valuation can be both

comprehensive and time consuming, the application offers par-

allel processing for creating the work list, meaning that you can

start several jobs in parallel. This approach significantly reduces

the time needed to create the work list. If customers fulfill the

collection rules of the collection strategies assigned to them, the

application creates a work list item for the customer and assigns

it to the collection specialist defined in the business partner mas-

ter record. If no collection specialist has been assigned, distribu-

tion logic can be used. The logic might mean equal distribution

across the specialists in a group to distribute the work list items.

You can distribute unassigned work list items to all collection

specialists in the collection group assigned to the business partner

master record.

System administrators have access to tools for monitoring the

master data replication and for creating the collection role of

business partners and work lists.

Reporting

Reporting with SAP Collections Management supports analysis

in the following areas.

Analysis of Work lists

As soon as a new work list has been created for the following day,

you can transfer the processed work lists to SAP NetWeaver BI.

The main purpose of work list analysis is to measure perfor-

mance and productivity at various levels within the organization.

For example, you can evaluate how many work list items have

been assigned to a collection specialist, a collection group, or col-

lection segment and the percentage of items that have been com-

pleted for each priority. You can also evaluate the percentage of

the amount to be collected that has actually been processed dur-

ing the day by customers making promises to pay for invoices or

by requesting that collection specialists resolve disputed invoices.

Examining this data over a period allows you to draw conclusions

about the effectiveness of the collection strategies selected and

the ongoing productivity of the receivables management area.

35

Analysis of Customer Contacts

Customer contacts in SAP NetWeaver BI are a kind of snapshot.

They contain the exact data that was entered in the software

during creation of the customer contact. If contacts have been

made while processing the work list, the collection strategy and

collection group are also available to you for evaluation.

An analysis of customer contacts enables you to evaluate the

number of contacts made for each collection specialist, group, or

segment and the result. You can also determine the amount

promised and the number of promises to pay obtained during

customer contacts along with the disputed total amount and

number of dispute cases. The reports also indicate the percentage

of unsuccessful customer contacts and the average number of

times a customer must be contacted to be reached. This information

enables you to analyze the effort invested in each customer with

SAP Collections Management.

Analysis of Line Items in Connection with Organizational

Structures in SAP Collections Management

This type of analysis enables you to evaluate line items in accounts

receivable in connection with organizational structures in SAP

Collections Management. Analysis of the due date grid is of vital

importance in this area. The due date grid divides open items in

accounts receivable in a time grid and according to their net due

date. The current date is the key date for the division. You can

evaluate the due date grid for each collection segment, collection

group, or collection specialist. You can also use the company

code, business partner, and customer as characteristics for drill-

down. You can derive useful information from this analysis for

collection strategies. For example, if a large number of the open

items in a collection segment have been due for longer than 60

days, the collection strategy should pay more attention to the

collection of old receivables.

Analysis of Invoices and Promises to Pay

SAP Collections Management logically links all items with the

same invoice reference to an invoice (see “Processing Receivables”).

The invoices and their related promises to pay are a part of the

analysis for evaluating invoices and promises to pay.

To support you in evaluating promises to pay, you have access to

all the attributes of a promise to pay, including the amount prom-

ised, the date for which payment was promised, and the level

and state of the promise. Reporting links this data with the data

of the promised invoice. This data includes the invoice amount,

the payment date, and the due date for net payment. In addition

to the days in arrears up to the payment of the invoice and the

promise to pay, reporting determines the period outstanding for

each invoice. You can also set the number of invoices due in a

period in relation to the promises to pay entered in this period

and perform statistical evaluations. The statistical evaluations

can examine the average number of promises to pay per invoice,

the percentage of promised invoices, or the percentage of

promises to pay that were kept.

With SAP Collections Management, you can evaluate invoices

only or combine evaluation of invoices and promises to pay.

The most important evaluation here sorts the receivables by age.

The application divides the invoices of a customer along a time

grid using the invoice date. As is the case with the due date grid,

organizational units from SAP Collections Management and

accounts receivable are available to you for various evaluation

levels.

Enhancement Options

You can use flexible customizing settings and enhance SAP

Collections Management without making modifications. The

following lists some examples.

36

Many companies often require automatic assignment of the

correct collection profile, suitable collection group, and a specific

collection specialist to business partners based on specific rules.

You make the assignment within two reports that are executed

periodically. You can use business add-ins to enhance or even

replace the parameters predefined in the reports with company-

specific rules.

The flexible design of SAP Collections Management also allows

you to transfer fields from documents in the SAP ERP Financials

solution or customer master data into the SAP Collections Man-

agement application to enhance the work list or to create new

collection rules. You can add new fields with modification-free

enhancement of tables by customer includes and by implement-

ing business add-ins that import the fields when sending the data

from accounts receivable to SAP Collections Management. You

can create new basic rules, the foundation of the collection rules

available to the user, by implementing a business add-in.

You can not only enhance the work list with new fields but also

enhance the invoice overview in the process receivables function

with additional fields from accounts receivable or dispute case

attributes. Two customer includes are available to you for this

purpose.

You also have access to business add-ins that can achieve the

following enhancements:

• Calculation of the amount to be collected that differs from the

standard formula

• Creation of a note that differs from that in the standard system

when creating a customer contact

• Creation of a rule for distributing work list items where no collec-

tion specialist has been entered in the business partner master

data

37

SAP Credit Management: Overview

Your company can use the SAP Credit Management application

to monitor and control the risk of customers defaulting on pay-

ments. Potential customer insolvency represents a continuing

risk that fluctuates depending on the industry concerned and its

location. Your company should completely avoid the possibility

of lost receivables in the event of customer insolvency or at least

keep the risk to a defined limit. The overall risk that your com-

pany’s receivables portfolio represents should be kept transparent,

and you should be able to evaluate it at any time. But it is also

important not to jeopardize potential business with customers

because of an inaccurate credit risk assessment.

You can achieve these objectives with various functions of SAP

Credit Management. A scoring function enables you to assess the

payment default risk of a business partner according to defined

and uniform criteria. You can use differentiated credit limit

management to define upper limits for potential losses on receiv-

ables. Constant monitoring of the utilization of credit limits

from order processing to delivery, billing, and incoming payment

(order-to-cash process) ensures that the credit limits you have

defined are never exceeded without explicit approval. Further-

more, you can perform additional credit checks based on defined

risk indicators during the order-to-cash process. You can use SAP

Credit Management to make the credit decision automatically.

You can analyze the overall risk-related view of the receivables

portfolio and the operational view of the degree of credit limit

utilization by individual customers.

Additional capabilities, such as workflow-supported credit limit

request processing, management of relevant key figures taken

from risk assessment aspects for each customer, and the option

of integration with SAP Collections Management and SAP Dis-

pute Management make SAP Credit Management an extremely

useful application with a high return on investment.

You can work with a single system landscape with SAP Credit

Management as part of SAP ERP or with a distributed system

landscape that connects diverse customer management and

finance systems (SAP and non-SAP) to the central SAP Credit

Management system.

Online integration of external credit information providers of

size further enhances the SAP Credit Management application.

Processes Supported by SAP Credit Management

Creditworthiness Check

You can use SAP Credit Management to check the creditworthi-

ness of a customer for a particular business event within an order-

to-cash process. Creating or changing a customer order is an

example of an event. You automatically perform the creditworthi-

ness check during creation of the order with the data of the

order being created. The application then checks to see if, when

added to the existing credit exposure of the customer, the cur-

rent order value exceeds the credit limit defined for the business

area concerned and the company as a whole. If such is the case,

the sales clerk receives a message, and the order can be blocked if

the configuration settings allow. A block stops further processing

on the logistical side, making an additional procedure necessary

(see “Release of Blocked Orders”). If required, you can perform

other steps to check the credit. For example, you can check the

absolute amount of the order value or the dunning level of the

customer already reached – leading to a block of the order, if

necessary.

Other events for the creditworthiness check include the creation,

change, and entry of a goods issue for a delivery. These events are

of particular importance because the creditworthiness of a cus-

tomer might deteriorate between the creation of the order and

later events. A customer order that initially had a positive credit

check should not be delivered without further action in such a

case.

SAP CREDIT MANAGEMENT

38

The related document and a central log store the results of each

creditworthiness check. You can easily use both for later reference.

The SAP Credit Management application supports you by pro-

viding the creditworthiness check as an enterprise service. The

check is therefore available to everyone in a distributed system

landscape. Even non-SAP applications can access it, providing

that the necessary entry parameters have been populated. Final-

ly, using the enhancement technologies provided by SAP (such

as business add-ins), you can implement accesses from the SAP

application to check additional events.

Credit Limit Request

With SAP Credit Management, you can calculate credit limits

according to defined rules and criteria and then assign them to

business partners. However, it is often prudent not to assign a

credit limit automatically. SAP Credit Management supports you

here with a credit limit request process. With this process, a sales

employee can create a request for a specific customer, for exam-

ple. The sales employee simply enters the customer and desired

credit limit on the entry screen. The application adds any exist-

ing data for this customer from SAP Credit Management, such as

risk class or previous credit limit. The sales employee can also

add notes or documents to the request as attachments. The credit

limit request is then forwarded to the person responsible in a

workflow as a file. During processing, users can enhance the

request and initiate inquiries for the requester. Finally, the soft-

ware automatically transfers the approved credit limit to the

master data of the business partner in SAP Credit Management.

You then use the new credit limit amount for future

creditworthiness checks.

The application documents the entire process so that it is abso-

lutely clear who last approved a particular limit for a customer,

the information used for the approval, and when approval was

given. The user’s authorization profile can define the user’s

ability to approve credit limits – only up to a specified amount,

if necessary.

Functions in Detail

Organizational Structures and Business Partners

You use the credit segment as the basic organizational element of

SAP Credit Management. Credit segments correspond to areas of

your company that demonstrate a certain level of autonomy.

Examples would include different divisions, distribution chains,

or national companies. You define a credit limit for each credit

segment and customer. If you must define credit limits for specific

distribution chains for a customer, for example, you can assign sep-

arate, specific credit limits to a customer in the telephone sales and

store retailing distribution chains. You would then have to define

a separate credit segment for each distribution chain.

When you use SAP Credit Management, you store data on the

customers being monitored as business partners. The advantage

here is your ability to manage a single, central credit account for

each customer, even if the customer is located in a distributed

system landscape and possibly in several systems connected to

SAP Credit Management.

The master data specific to credit management includes general

data that exists only once for each business partner – the credit

profile of the business partner. Other master data depends on the

business partner and credit segment – the credit segment–specific

master data. For example, you use the credit profile to define the

score, the calculation formula for determining the score (score-

card), the risk class, the check rules for the credit check, exter-

nally obtained credit information, classification characteristics,

other special identification, and information about existing col-

lateral. The master data you store for each business partner and

credit segment contains the credit limit, the calculation formula

for automatically determining the credit limit, the current utili-

zation of the credit limit (credit exposure), the line items from

which the credit exposure is created, the blocking indicator rea-

son, and information about existing collateral.

39

The business partner in SAP Credit Management also contains

generic master data attributes of a business partner, such as

name, address, organizational data, and financial information.

You can maintain business partners directly in SAP Credit Man-

agement. However, most companies restrict such maintenance

to the credit management–specific attributes if SAP Credit Man-

agement is not the leading master data system. You can maintain

business partners with single maintenance or mass maintenance

(for example, to replace the existing calculation formula for deter-

mining the score with a new calculation formula for a group of

business partners). You then perform the mass changes to a large

number of business partners in a single step.

You can then work in relationship management to assign the

responsible credit analyst to a business partner.

The change history makes changes to the score, risk class, or

credit limit transparent to users at all times.

Scoring and Risk Classes

You can store scorecards for calculating the score for business

partners in SAP Credit Management. If needed, you can create a

very flexible and multilevel structure that defines how to link

and weigh individual variables in the scorecard. You can define

any number of scorecards. For scoring, you assign one scorecard

to the individual business partner.

The credit manager uses a formula editor to create a scorecard

and can select from a wide variety of variables and functions.

Calculation of a scorecard can include master data attributes for

the business partner (such as legal form, age, or financial key figures),

data for the customer’s payment behavior, and externally

obtained credit information.

The application stores the result of the calculation as a score in

the master record of the business partner with a validity period.

You can define the range of the score key figure as you wish. The

score supports you with a measure of the credit loss probability

of the business partner. The application can also determine a risk

class derived from the score. The risk class is primarily used to

segment the business partner. You can select payment conditions

or dunning procedures depending on the risk class of the busi-

ness partner. In reporting, you use the risk class for a structured

display of the customer portfolio or the total credit exposure.

Credit Limit Management

You can define a credit limit for each business partner and each

credit segment – manually or automatically. If you define the

limits manually, you would use a credit limit request (see the sec-

tion on processes in “SAP Credit Management”) or directly maintain

the master data of the business partner.

If you define the limits automatically, you can flexibly define a

calculation formula for each business partner with a formula edi-

tor. You can use numerous master data attributes and business

partner–specific key figures available for the definition. The score

calculated by the software and the risk class of the business part-

ner are usually important variables for calculation of the credit

limit.

You can define a separate credit limit for each credit segment.

The application monitors the segment to make sure that it is not

exceeded. Credit segment 0000 is particularly important. It helps

you establish a group credit limit for a customer, which can be

less than the total of the individual limits. In the real world, a

customer might not yet have reached the defined credit limit for

a particular credit segment but easily have reached it for the

group as a whole. A creditworthiness check would then return

a negative result.

Finally, you can use the hierarchies of business partners to map

credit limits. You set a subordinate business partner in relation-

ship to a higher-level business partner. You define a credit limit

for both. If you perform a creditworthiness check for the subordi-

nate business partner, the application checks that credit limit first

and then the credit limit of the higher-level business partner. You

can use an unlimited number of hierarchy levels.

40

Credit Exposure Update

You can use the support offered by SAP Credit Management to

update credit exposures from customer orders, deliveries, billing

documents, and open items from accounts receivable accounting.

You map the exposures with credit exposure categories. You can

distribute the total credit exposure of a business partner across

the partial credit exposures of the various credit exposure catego-

ries. With the approach, processing of a complete business process

increases or decreases the individual credit exposure values in the

respective credit exposure categories. The order credit exposure

is increased when you create an order. The order credit exposure

is correspondingly reduced and the credit exposure from deliver-

ies increased if an order is delivered. The exposure is reduced again

when you create the billing document. Finally, the credit exposure

is reduced to zero when the open items on the customer account

are paid in accounts receivable accounting. You can use SAP Credit

Management to store line items for credit exposure management.

However, the line items do not cover all the attributes of the docu-

ments from the source systems. They cover only the attributers

relevant to the credit check, such as credit amount, due date, or

secured amounts.

In a distributed system landscape, you update credit exposure

values from various decentralized sales, logistics, or finance sys-

tems in a central instance of SAP Credit Management. This

approach gives you an overall view of the credit exposure situa-

tion of the business partner. You always use the current credit

exposure value, which is stored centrally, for a creditworthiness

check.

From a technical viewpoint, the credit exposure update is imple-

mented as an enterprise service, so that credit exposure values

from non-SAP applications can report to a central instance of

SAP Credit Management.

Events and Follow-On Processes

SAP Credit Management supports you by making processes and

workflows as automatic as possible, so that the credit management

department can use its time to focus on more proactive credit

management.

The events and follow-on processes provided by SAP Credit

Management are important parts of this support. Depending on

configuration, certain events trigger specific follow-on processes.

The follow-on processes might cause another event to occur,

which would trigger another follow-on process. For example, if

an external information provider updates the version of credit

information already obtained over an XML interface to SAP

Credit Management online, the update entry might contain a

changed external credit rating. The change to the external credit

rating represents an event that can trigger the recalculate score

follow-on process. If the follow-on process results in a changed

value, the change might trigger the derive risk class again, recal-

culation of credit limit, and start workflow to credit analyst

follow-on processes. This example would involve a high level

of automation but would still notify the credit analyst, who has

an option to intervene manually.

You define which events trigger which follow-on processes or

workflows with customizing of SAP Credit Management.

Release of Blocked Orders

If a creditworthiness check blocks customer orders, you must

decide how to proceed. Your options include rejecting the order,

rechecking the creditworthiness later, and releasing the order (in

a multilevel approval process, if necessary). SAP Credit Manage-

ment supports processing the blocked orders with enhanced ana-

lytical functions. When selecting the order, the credit analyst

responsible obtains the most comprehensive picture of the data

of the business partner – from a credit management viewpoint.

Consequently, the credit analyst can make a decision quickly,

based on the specific situation.

41

Credit Manager Portal

SAP Credit Management works on the SAP NetWeaver platform;

you can use it as a completely Web-based application using SAP

NetWeaver Portal. Credit managers and credit analysts can con-

figure a role-based user interface suited to their particular needs.

It can contain all the transactions, evaluations, information, and

applications they require to perform their daily work.

Reporting

SAP Credit Management offers you a variety of options for evalu-

ations and reports. From a technical viewpoint, you can access

them in the credit management online transaction processing

(OLTP) system and in SAP NetWeaver BI (an online analytical

processing [OLAP] system), for which specific credit management

content has been defined. You can use the following evaluations:

• Early warning lists to help you select any business partners for

whom the next creditworthiness check for a business transac-

tion has a high probability of being negative – for example,

because the credit limit has almost been reached. If such business

partners have already been identified, you can undertake

proactive measures to prevent reaching the credit limit. For

example, your company might be able to intensify collection

of receivables.

• Master data lists for the business partner at the level of the

credit profile and credit segment. You can restrict the lists to

business partners who have been marked as needing special

attention.

• Historical evaluations of credit profile and credit segment data.

You can use these evaluations to make the score of a business

partner transparent over a longer period of time.

• Portfolio analyses to help classify total credit exposure data

according to country or risk class. How high is the total credit

exposure in a particular risk class or a particular country?

• Key figure evaluations to analyze payment behavior of business

partners

• Credit exposure evaluations that provide business partner mas-

ter data and a due date grid for open items

• Logs of the creditworthiness checks that have occurred and of

credit exposure updates

Figure 21: Processing of Orders Blocked by a Credit Check Figure 22: Portfolio Display of Total Credit Exposure by Risk Class

42

Connection of External Credit Information Providers

You can connect external information providers and credit

agencies to SAP Credit Management over XML interfaces.

You can collect information individually for a business partner

or by mass import for a group of business partners. For example,

you might collect current information on all active business

partners for whom the validity of information collected in the

past has expired.

In addition to the information you receive when you initiate the

call from SAP Credit Management, the application supports other

scenarios based on XML communication with external informa-

tion providers. You can use SAP Credit Management to receive and

then process update entries that the external information provid-

er supplies proactively (see “Events and Follow-On Processes”). If you

do not have the unique identification key used by the information

provider in the company information area, you can search with

XML. The external information provider returns a hit list that

the credit analyst can use to select the correct business partner

online and transfer the unique identification key to the business

partner master record.

You can configure the interfaces specifically for different provid-

ers. The application saves the relevant information as an attached

document in the business partner master record. Moreover, depend-

ing on the configuration, you can transfer the data required from

the information directly to the master data attributes of the busi-

ness partner in SAP Credit Management. The attributes are stored

in a structured form and remain available to users as input parameters

to calculate the score or credit limit.

Integration with Other Applications of SAP FSCM

SAP Credit Management can deliver data that is processed by

other applications of SAP FSCM and use data from other SAP

FSCM applications. For instance, a collection rule in SAP Collec-

tions Management takes into account the particular risk class of

a business partner that is defined in SAP Credit Management.

You can consider the relationship of credit exposure and credit

limit (utilization) for a business partner within the valuation of a

collection strategy.

You can configure SAP Credit Management so that your compa-

ny can deduct the disputed amount in a dispute case with a spe-

cific status or reason from the current credit exposure during the

credit check – in whole or in part.

System Architecture

Your company can operate SAP Credit Management as a central

system for customer credit risk monitoring and control within a

distributed system landscape. You connect systems that process

business transactions relevant to SAP Credit Management with

the SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI)

component. Enterprise services are called to exchange data for

credit exposure updates or creditworthiness checks. In technical

terms, the systems exchange XML messages. Within a pure SAP

landscape, the calls have already been configured. This open

approach makes it easy for your company to integrate non-SAP

systems. The technical basis used to integrate individual systems

is also used to integrate external information providers.

Customer

Sales

Distribution

SAP CRM

Non-SAPsystem

SAPNetWeaver®

XI

SAPNetWeaver

XI

SAPNetWeaver

XI

SAPNetWeaver

XI

Businessaccounting(accountsreceivable)

SAP® Credit Management

Integration

Credit case

Credit limitmanagement

External creditinformation system

(D&B)

SAP NetWeaverBusiness

Intelligence

Creditanalysis

SAP NetWeaverPortal

Credit manager portal

Figure 23: System Architecture of SAP Credit Management

Information flow

Real time

43

Enhancement Options

Comprehensive customizing helps you adapt the processes and

functions within SAP Credit Management to meet the specific

requirements of your enterprise.

You can enable modification-free enhancements implement

requirements that standard SAP software does not support. For

example, you can define additional rules (credit-check steps)

within the creditworthiness check or other functions for the

score and credit limit calculation formulas that are not delivered

with the application.

Additional enhancements include:

• Addition of other attributes to the business partner in SAP

Credit Management

• Determination of customers on negative and positive lists

• Evaluations of external credit information

• Selection criteria for mass processing of business partners

• Adaptation of the results of a credit-check step

• Adaptation of the credit exposure values sent to SAP Credit

Management

• Adaptation of the payment behavior summary of a business

partner sent to SAP Credit Management

• Calculation for the payment behavior summary

• Publication of events

Technically, these enhancements are mapped as business add-ins,

so you do not lose them when you upgrade the application.

44

Financial supply chain management represents a major area of

process innovation and improvement for enterprises in a broad

range of industries. The last several decades have seen little

im provement in the areas of billing, accounts receivable, collec-

tions, dispute resolution, credit scoring and cash management.

Today, many businesses see these functions as a prime area for

process improvement and a source of greater cost-savings.

SAP is the best-positioned provider of ERP software in the industry

to address the needs of financial supply chain manage ment. The

SAP FSCM set of applications helps companies organize their

receivables and credit management within the SAP ERP Financials

solution. With FSCM, SAP focuses on helping organi zations optimize

working capital and financial supply chains. Our comprehensive

set of solutions is designed to work as a seamless extension of

both SAP and non-SAP systems in finance, customer relationship

management, supplier relationship management, and operations.

SAP FSCM optimizes the financial and information flows within

a company and between business partners. It contains the

following applications.

SAP Biller Direct, which allows billers to send and customers to

receive invoices electronically, making invoicing more efficient.

Suppliers can also use it to access account information over the

Internet.

SAP Dispute Management, which offers functions for processing

receivables-related dispute cases. It helps you streamline your

dispute processes by bringing them online, instead of using the

cumbersome, paper-based processes that are common today.

SAP Collections Management, which supports the evaluation,

identification, stratification, and prioritization of accounts from

a risk management and a customer relationship management

perspective to collect outstanding receivables on time.

SAP Collections Management enables the collection specialist to

have personal contact with unpunctual debtors, which consi-

derably increases the probability of receiving payments on time.

SAP Credit Management, which helps you set up a company-wide

and consistent credit policy, including highly flexible customer

scoring mechanisms and automatic calculation and assignment

of customer-specific credit limits. SAP Credit Management makes

a decisive contribution to increasing the transparency of credit

decisions across systems and to minimizing credit risks.

SUMMARY

45

Customers who have implemented SAP FSCM typically cite the

following business drivers as reasons for their decision:

• Improved rate of days sales outstanding

• Improved customer satisfaction with invoicing and payments

• Faster collection rates

• Improved ability to score customer credit ratings

• Increased cash utilization

• Improved integration between treasury and accounting

• Lower total cost of ownership

46

47

www.sap.com/contactsap

50 084 522 (07/05)