Upload
ravikanthv
View
1.840
Download
4
Embed Size (px)
Citation preview
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)