Incoming Invoices at Shared Service Centres

Incoming Invoices at Shared
Service Centers
Applies to:
Business Process Expert, Business Process Management, Business Rules Management, SAP Business
Workflow. For more information, visit the Business Process Expert homepage.
Summary
Introducing a design for the automated processing of any type of high volume incoming records to a shared
service center, using as an example the Accounts Payable invoice handling scenario. Without getting
involved in the technology, this article describes what's involved in automating data entry, where best to
invoke business rules, how to manage exception handling (with escalation for expert or stakeholder input)
and requirements for meaningful analysis.
Author: Philip Kisloff
Company: Capgemini
Created on: 30 January 2009
Author Bio
Philip is a SAP Mentor and long time R/3 consultant. For the largest part of his career he
specialized in SAP Business Workflow, but his energies have broadened into all areas of
business process modeling, integration and automation management.
SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com
© 2009 SAP AG 1

Incoming Invoices at Shared Service Centers
Table of Contents
Introduction .........................................................................................................................................................3
Process Overview ...........................................................................................................................................4
Incoming Data Records ......................................................................................................................................5
Straight-Through- Processing.........................................................................................................................6
Data Validation.............................................................................................................................................................6
Data Enrichment ..........................................................................................................................................................7
Exception Handling .........................................................................................................................................8
Exception Wrapping.....................................................................................................................................................8
Exception Messages....................................................................................................................................................8
Exception Escalation..................................................................................................................................................10
Process Analysis...........................................................................................................................................12
Afterword.......................................................................................................................................................13
APPENDIX 1: Summary of benefits for invoice automation processing. .........................................................14
APPENDIX 2: Invoice processing problems requiring manual intervention.....................................................15
Disclaimer and Liability Notice..........................................................................................................................16
© 2009 SAP AG 2

Introduction
System automation is pervasive throughout modern business, yet invoice processing, one of the most
important business process of all, remains a largely manual process in respect to data entry. Despite the
advent of electronic invoicing, created when networked suppliers “flip” an electronic purchase order, paper
invoicing is still the preferred format. As a result, for many organisations the entire accounting process
hinges around a piece of paper in a myriad of different formats.
It is not uncommon for the total internal costs of raising a purchase order, confirming receipt and processing
the invoice can exceed the value of the purchase itself. For such a high volume, time constrained and
important business process, there is compelling value in automating the purchase to pay lifecycle, and this
has largely been done by many companies. Nevertheless, no matter how much has been done already,
there will always be ways to generate greater efficiencies and optimisation.
One of the ways to reduce the costs of back-office functions such as Accounts Payable (A/P) is the creation
of a “shared service centre” (SSC). The promise of this concept is to centralize and hopefully make more
efficient those activities that are repeated throughout geographically or otherwise dispersed independently
operated subsidiary business functions. However, unless the risks are properly managed, threats to the SSC
model come from two directions, both ironically inherent in the business case for its set up.
Firstly, the SSC concentrates a lot of work for itself. In A/P, for example, the invoices received for may reach
tens of thousands a month. Bearing in mind there is a fixed deadline for processing (in this case the invoice
due date) there will be physical limitations in the number of people that can enter these invoices without
some form of automation (shortage of desk space and car parking limits headcount in my experience).
Secondly, because the business functions are dispersed, a pretty good way to send and track issues will be
required. Without this mechanism, issues will not be resolved quickly enough, but just as importantly, it will
be difficult to identify and therefore optimise poorly performing business processes or indeed identifying and
correct non-compliance to mandated business processes.
Another avenue taken to improve the efficiency involves the use of Intelligent Data Capture (IDC)
applications to automatically extract data from scanned paper invoices. The paper invoice is scanned and
the IDC tool – using Optical Character Recognition (OCR) engines – identifies and extracts the appropriate
data fields from document image.
What is presented here is a design for the automated processing of high volume incoming invoices to a
shared service centre. However, I have purposely tried not to get drawn into describing the technology or
even customer-specific business logic and instead have tried to focus on the business process management
for such a system. Because of this generalist approach I hope it will be applicable for any type of incoming
data records that need to be automatically entered into a system (when I refer to an invoice instead of an
incoming data record, I’m giving a specific example from the A/P process, although I use both terms
interchangeably). A major part of the solution also involves how best to handle the inevitable exceptions in a
high-volume automated process, particularly for a de-centralised and “business-partnership-structured”
organisation. For a summary of the benefits of invoice automation, please refer to Appendix 1.
© 2009 SAP AG 3

Process Overview
For those unfamiliar with the Purchase to Pay business process, allow me to give a brief introduction, from
the perspective of the A/P function working in a shared service centre and the existing workflows already
available. In the diagram below (Fig. 1) there are four main steps.
1. Create a Purchase Order. This is done by one of the subsidiary business units, and involves raising
a Purchase Order to be sent directly to the supplier. There is no SSC involvement, other than
supporting the PO release workflow and agent approval hierarchy.
2. Receive goods (or services). Again, this activity is performed outside the SSC.
3. Process the invoices. This involves centrally receiving the invoices and manually scanning the
document (or receiving images and OCR data from 3rd
party scanning bureau) and then performing
invoice verification against the PO. It is managing and improving the efficiency of this step that is the
substance of this article.
4. Make payment run. To allow this to happen, price/quantity differences which have blocked the
invoice for payment are released after approvals gathered by a third workflow.
Figure 1: Overview of the Purchase-to-Pay Lifecycle highlighting SAP standard workflows
© 2009 SAP AG 4

© 2009 SAP AG 5
Incoming Data Records
The diagram in Fig.2 below is a pictorial representation of two discrete but inter-related processes. The first,
Straight Through Processing (STP), is what we hope will happen when data is sent for uploading into our
system. We hope they'll update the system without the need for manual intervention. The second process,
Exception Handling, will happen regretfully but also inevitably, so we better accept that this is just as
important as the first process and not some "throw-over-the fence" activity for someone else to complete.
Just a note of attribution for the notation in Fig 2: I'm using component shapes inspired by the folks at
Enterprise Integration Patterns1
, gratefully made available under the Creative Commons Attribution2
license.
I think these shapes are a very good way of conveying the intricacies of a business process while still at an
overview level, avoiding the unnecessary vigor of a formal notation.
Figure 2: Automated data input: Straight-Through-Processing and Exception-Handling
1
http://www.eaipatterns.com/eaipatterns.html
2
http://creativecommons.org/licenses/by/3.0/

Symbol Description
Incoming data record, described by one or more attributes
Attribute for good data records that are ready for input.
Attribute for a poor data record that will be first rejected and then re-submitted after
exception escalation.
Attribute for enriched data, such as SAP vendor master ID, or tax code.
Attribute for exception messages linked to the incoming data record.
Table 1: Explanation of symbols in Fig. 2
Straight-Through- Processing
The process starts with incoming data records arriving for validation. In the A/P example these would be
paper invoices, scanned using OCR technology, and the information from the invoice written to a
table, linked via ArchiveLink to an image of the document. To show the STP process graphically, the
diagram in Fig. 2 starts with two separate invoices: a good one, with a green-striped attribute; and one bad,
with the red-striped attribute. Both invoices start their journey by having their data validated.
Data Validation
OCR is never 100% accurate, any field values which cannot be extracted automatically, or are extracted with
a low confidence level, are verified and amended by the 3rd
party service provider. For data validation against
SAP data, one decision to be made is where the data validation takes place. If it occurs with the 3rd
party
service provider, then interfaces need to be established to export reference data outside the company.
The solution discussed here assumes all incoming data records have all business data validation done in
SAP. If a step reveals a problem with the data, and ends with an exception condition, then this incoming data
record is filtered from the flow together with any exception messages. Errors such as misreading a number
may then simply be corrected by visual inspection of the corresponding attached scanned image. More
serious errors may need communication with other people to help solve.
© 2009 SAP AG 6

© 2009 SAP AG 7
Data Enrichment
Even though almost all Finance applications have standard interfaces to upload invoice documents, these
interfaces expect certain ‘base line’ data – such as vendor number, PO line number, tax code etc, which is
not normally included on an invoice3
. Therefore, business rules are needed to derive those missing data
items needed by the application and this process is called data enrichment.
The ideal place for applying business rules for data enrichment is after data validation. Before this point,
simple one-to-one relationships with master data have been identified, and easily identifiable problems
filtered out for exception handling. I would characterize the major advantages of using a business rules
management system as follows:
• Decoupling of the processing logic from the technical implementation, ensuring easier maintenance
for changing requirements. Tuning the STP process is therefore much easier.
• Creating business rules is the ultimate in modularization, and protects a company’s investment
should there be a change in the solution technology calling the business rule.
• Direct user involvement in the formulation of business rules, therefore reducing errors. For example,
NetWeaver Business Rules uses a combination of flow diagrams and spreadsheet-like tables to
capture the logic, and these are ideal formats to share with key knowledge experts from the A/P
function.
• For tax code derivation specifically, it enables opening up of the responsibility for maintenance to
outside accountancy professionals. Tax codes are a specialist area, and it may be beyond the
capabilities of the in-house team to keep abreast of all the relevant legislation.
After either step in the STP workflow, any erroneous results would be logged and the process aborted for the
exception handling procedures to try and manually identify and correct the error. Of course, even if the
incoming data record passes through all the most rigorous checks a customer has time to devise, it still has
to update into the SAP system databases via the business application. This is not always a forgone
conclusion, and errors must be trapped here as well, for dealing within the exception handling part.
3
Vendor determination seeks to match quoted bank details or VAT number (but if neither present a search by postcode) to a vendor
master record and cross check against the vendor used in PO. Invoice line items need may need to be matched to PO line items and
the quantities then allocated. Tax code determination is based on country-specific legislation by tax rate and the intended use of the
purchase based on the account assignment in the PO.

© 2009 SAP AG 8
Exception Handling
This part has actually two steps, and follows the escalation path for problems that can be solved within the
shared service centre itself by the A/P staff, to those issues that need to be communicated in a traceable
manner to the remote business operating functions (the ones creating the POs, for example). In generic
terms the split can be seen as between service support and business stakeholders, and this is how it is
described in the diagram.
How many exceptions are likely to be encountered? You may be surprised to learn, but in my experience
with paper invoices, over two thirds of the invoices fail to be processed automatically, and require some form
of manual correction. That seems like a high failure rate, but one should be realistic4
. In this respect I am
reminded of those fair ground bagatelle-type games which are played by dropping a ball or coin into a case
which contains an arrangement of pins, deflecting its downward path to a random compartment at the
bottom. The invoice is scrutinized by so many different validation and other rules that an incoming data
record has many many chances to get deflected before reaching a hoped-for outcome.
It is arguable that for the majority of incoming data records to go “straight-through” requires not more
validation and business rules, but focusing instead on the analysis and handling of processing errors. The
errors must be captured in such a way that business intelligence can be extracted as to their cause, and that
their resolution is as quick and easy as possible. For example, is a single vendor failing to calculate tax
correctly, or quote a tax rate on the invoice? Or does a user raising a PO always do so incorrectly? The
handling of errors must be as efficient as possible, to minimize delays, and is acheived by wrapping the
presentation of the exception in a way that enhances human interaction.
Exception Wrapping
The term “exception wrapping” here means presenting to someone supporting the process the exception in
such a way that it assists resolution or escalation. It’s not just the case of sending an email message, but
using a notification that lays out together the invoice image, the errors and the data fields ready for
correction, and also all the actions necessary for any subsequent step. The message is sent to the correct
team by routing based on workflow agent determination rules, but should also be viewable from a worklist
available to all parties. Conceptually, there must always be the following five generic options available to all
users responsible for handling the exception in order to further process the incorrect incoming data record:
1. Reject processing entirely. The incoming data record is discarded with no more ado.
2. Return the item to sender. Here I’m introducing the concept of the quality chain. If it is the
responsibility of the sender to follow a certain format, the option to bounce back for the originator to
correct must always be available.
3. Re-submit for processing back into the workflow. This would normally be done after some
correction has been made which will now allow success.
4. Process the incoming data record manually. This option is required as a fall-back when the
automatic processing is deficient in some respect5
.
5. Escalate to another support area. Again relevant to the quality chain concept. Those responsible
for the correctness of objects referenced by the incoming records must be held to account!
Exception Messages
The exceptions reported to the first level support can be divided into four main areas, with each area
differentiated by its cause or response. This approach may seem like an exercise in redundant classification,
but it has a subtle yet generally welcomed purpose of conveying to the user handling the exception both the
context of the problem, and the approach to be used in its resolution. A summary of the four classes of
exceptions that can exist are shown in Table 2.
4
For a (partial) list of issues that can prevent invoice automation succeeding without manual intervention, please see Appendix 2.
5
For posting an invoice without the Early Archiving workflow scenario (i.e. directly from the exception wrapper), timing the assignment of
the scanned image to the posted invoice before the blocked price/quantity event triggers the unblocking approval workflow requires
special consideration. A resolution to this issue may be the subject of a future SDN weblog.

Alerts are a class of exceptions that can only be detected in the source system, but only handled by manual
processing in the receiving system. Alerts will cause the data item to skip straight for exception handling, and
as any changes or actions would not be detected automatically, it requires manual acknowledgment
(effected for example by ticking a check box associated with this alert so that the data import can be
reprocessed). An example of an alert is a covering letter than should be scanned along with the invoice.
Warnings also cause the incoming data record to skip straight to exception handling, and require manual
acknowledgment. However, warnings are different from alerts because they are generated from data
validation. Warning are different from errors because there is nothing wrong with the incoming data record as
such, and so can’t be solved directly, but instead they indicate that internal communication is required with
someone responsible elsewhere. Good examples of warning exceptions are when an invoice is received
referencing a PO in which a flag has been set to “notify clerk” or the VAT number on the invoice does not
match the VAT stored in the vendor master record.
The remaining exceptions are both true errors: they were detected either during pre-posting validation or
actual data posting. Errors are classed as a data validation type when they can be resolved simply by
correcting the incoming data record and re-submitting it back into the workflow process. Posting errors occur
when data validation failed to detect any errors but the posting still failed. Often in these cases it is necessary
to manually process the incoming data record through the corresponding application, getting closer to the
exception issue by seeing the error reported again in its screen context as in the transaction dialog.
MESSAGE ICON Purpose
ALERT Alerts are additional messages from sending system for a
corresponding incoming data record, to be dealt with in the receiving
system. Requires manual acknowledgement before processing can
continue.
WARNING Warnings are generated from checking business rules and master
records, but instead of correcting the incoming data record, a
referenced object must be amended (see exception escalation). To be
manually acknowledged before processing can continue.
DATA
VALIDATION
ERROR
Only reported in the exception wrapper, never stored. Elimination of
this class of errors from analysis of business rules and master records
can only be achieved by correcting the relevant incoming data record
fields. Linked to audit messages (which are stored).
POSTING
UPDATE
ERROR
Posting errors – the final decision on posting success lies with the SAP
interface and any errors are reported under here.
Table 2: Exception categories indicating trigger and action.
For completeness, I’ll mention two additional message categories that are extremely useful to consider
despite neither types of message being displayed to the user.
1. Information messages are related to alerts as they can only originate from the sending system, but
they need not be displayed to the user as they simply convey information necessary for the correct
functioning of the business rules in the receiving system. A typical use of such information messages
is for flagging the OCR detection of a key phrase on a paper invoice. The information they convey
could have alternatively been included as check fields in the incoming data record, but then any
additional fields required after go-live would require a change to the master data record definition.
2. Audit messages work together with data validation error messages in table 2. Data validation errors
are the only class of exceptions that are not stored because of the risk of spurious errors being
recorded which are a direct result of a single incorrect field earlier in the validation process. For
© 2009 SAP AG 9

example, if an error occurs from an incorrect company code, all sorts of checks requiring company
code as an input parameter would also report as data validation errors. During exception handling,
the user simply has to correct the entry to this field for the subsequent checks to work. Nevertheless,
to maintain an audit of the error, when a correction is made to a field in the incoming data record, the
original and changed fields are logged together in the audit message.
Exception Escalation
A lot of the time the A/P personnel are not themselves able to resolve an exception, because a query has to
be logged with the supplier or the responsibility with the error lies somewhere else, perhaps to do with the
PO creation. Whatever the reason, an email or telephone call is a bad solution. Although it is quick, and
worth a try, unless there is an immediate answer then the hundreds of other exceptions likely to be present in
a high volume business process will swamp the team. To manage the escalation of exceptions to those
people required to assist in the resolution, some form of service ticket should be created.
There are many different products offering service desk functionality. I chose to build mine based on CA-NO
notifications as the framework. It had the advantage of being exploitative about existing SAP investments,
and it was rewarding to make a generic application fit the specific business requirements, closer perhaps
than anything else available at that time. For a fuller exposition of the theoretical basis underpinning the use
of notifications, please refer to my 2006 article How to structure difficult-to-automate business processes. To
expand on the principles outlined in that earlier article, I’ve describe how the exception escalation process
would work with the aid of a hypothetical user instruction matrix shown in Fig. 3 below.
Figure 3: Instructions for handling exception escalation with generic notifications.
The first thing to say about Fig. 3 is that its intended audience is both the Shared Service Centre and the
subsidiary to which an exception will be escalated. The first column indicates the different functionalities of
the notification that should be performed. The following columns, read from left to right, indicates what should
be done in the notification by first the SSC, then the subsidiary in response, and finally the SSC when a
conclusion is reached.
Secondly, notifications make use of Status Management, Business Partners, and Catalogs, and this provides
important control and reporting measures for the escalation process. During an implementation of the status
management functionality, there is the ability to define your own user statuses for scenario-specific
© 2009 SAP AG 10

© 2009 SAP AG 11
purposes. However, system statuses are fixed in SAP, and so provide a general overview of the process.
The system statuses and business partners used here are:
1. Outstanding. The notification is created to log or temporarily save the details of a problem that has
not yet been sent anywhere. The problem is categorized by a catalogue number (see Appendix 2 for
example entries applicable to A/P invoice processing) Both the Vendor business partner is entered to
enable easy identification when they ask where a payment is up to (the vendor’s invoice number
should also be entered somewhere) and A/P org unit as the Team Responsible business partner.
2. In Process. Setting this status would trigger a workflow to forward the notification to a user in the
subsidiary. The user is stored as a Coordinator business partner. This person may simply be a point
of contact for receiving such enquires. Changing the user for the Coordinator again will trigger
another workflow to send the notification to this new user.
3. Closed. The notification has been received back from the subsidiary and judged by the SSC to have
been responded to satisfactorily. Note that if the electronic signature action is called, the business
partner Coordinator is automatically changed to Approver (keeping the same user ID) and this also
triggers another workflow to send the notification back to the A/P team.
In our scenario, user statuses have also been defined for two distinct processes, “queries” and “approvals
requiring electronic signature” (represented as blue or red bullet points respectively in the Fig. 3). Before
releasing the notification (system status: In process), the user status has to be changed from “initial” to either
“Query” or “Requires Approval”. If an approval is required, the notification with the associated scanned
image has to be rejected or accepted with an electronic signature that prompts for user ID and password.
Finally, with respect to closing a notification, it can be seen that the subsidiary cannot change the status.
This limitation is of capital importance and this is part of the quality chain mentioned before in the allowed
options for the exception wrapper. For notifications that require approval, even though an electronic
signature is supplied, there is the question of whether the correct person has performed this service. Here, it
is the SSC’s responsibility to appraise themselves that that requirement was satisfied
6
.
For queries, while the subsidiary may feel they have responded adequately, it is the originator who has the
only say-so as to if they accept the response, otherwise they bounce it right back to the Coordinator. Thus
giving inadequate replies to queries does not absolve subsidiaries of further interest in the matter as it will
always be reported that the exception is still in process under their name, which is exceedingly useful when
accountability needs to determined.
I hope I have shown is that having clear options, unambiguous responsibilities, and unequivocal end-points
are the irreplaceable structures that are needed for process control. Please excuse my ending sentences
with a preposition, but to summarize: status management deals with where a process is up to; business
partners deals with who the process is with; catalogues allow a flexible way to describe what the problems
are.
6
This has special interest in the case of invoices presented without a PO. Although the invoice automation process requires a PO for
STP, and as a pre-requisite a “no PO, no pay” policy should be established, there can always be circumstances when a true FI invoice
needs paying, or it is too troublesome to raise a retrospective PO (a bad habit to allow to develop). In this case, exception escalation
does not have to re-create a PO approval process, as notifications give a means to capture account coding information and synergies
with the approval agents in the PO release strategy are possible with non-PO approval authorisation. A way to tackle this issue may be
a subject of a future BPX weblog.

© 2009 SAP AG 12
Process Analysis
There are three types of processing monitoring that supports a business process, and it’s important not to
get confused between them. Knowing what to achieve for each one will save valuable development time in
getting back the right types of results.
The first type of monitoring supports operational requirements and can be provided by a worklist. The
concept of the worklist is that it is a combination of interactive workflow monitoring tool with the same
functionality as an individual’s work item inbox. It can display more than one person’s workload in one list.
For this it must check appropriate authorizations and logging of changes to enable team working. It includes
both completed and pending workitems, and can filter on the incoming data record’s current position in the
workflow. It has a search ability for all necessary data record attributes, but also cross-references the
identity and status of the referenced objects, such as PO, posted invoice or notification used for escalation.
The second type of monitoring is used to generate statistics or Key Performance Indicators (KPI) to support
compliance with Service Level Agreements (SLA). A typical KPI you will see would be defined as “Number
and percentage of problem invoices by reason code” or “Number of problem invoices received without a PO”.
While these statistics are indeed important in measuring performance or establishing compliance to SLAs,
they do not on their own point to in what place the process can be improved. A priori assumptions are made
on what areas the KPIs are to collect their stats. Surely the objective for the third type of performance
monitoring must be the identification of the root causes of errors that can litter the value-chain. Table 3
collects together the metrics described in this article. What is needed next is to summarize the major time
delaying problems, their ranking, and then provide a drill-down capability to identify the specific cause7
.
Incoming data records Exception Wrapper Exception Escalation Timings
Object references
(vendor, PO etc)
Actual problem
message
Query catalog codes Document Date (on
invoice)
Message classes Handling action Business Partners Incoming record import
timestamp
Closure status
(OK pay, No pay)
Released timestamp
Non-approval reason
catalog code
Closed timestamp
Posting date (for
invoice)
Table 3: Characteristics and Key Figures (derived from timings) for Performance Analysis
7
Pareto analysis can be used for quality improvement, based on the recognition that a large majority of problems are produced by a few
key causes. The analysis is conducted by first categorizing all the different types of problems. Then two graphs are constructed, super-
imposed over each other.
1. A bar chart of the frequency of a particular category, ranked in descending order.
2. A point graph of the % that each category contributes to the overall total (of all the different issues).
The graph is usually read at the 80% mark to distinguish those 20% of categories with the highest ranks that should be focused upon.

Afterword
This article has been both narrow in the subject matter and hopefully universal in the BPX skills exampled.
It’s has been perhaps too exacting in some areas, while too vague in others, for which I acknowledged those
shortcomings. Several topics ended on the “cutting-room floor”, the after images remaining as footnotes to
the text. Nevertheless, the narrative thread I hope is clear. In my opinion, the aim of a business process
management system is to structure, to assist, to control, and ultimately to reveal.
© 2009 SAP AG 13

APPENDIX 1: Summary of benefits for invoice automation processing.
Supplier's benefits
• Faster payment through quicker invoicing and approval methods (see figure 3)
• Better service through online dispute handling
• Improved cash position through reduced supplier payment receipts
Payer's benefits
• Strategic business information is available by using more detailed data
• More productive staff by reducing manual data entry and allowing two and three-way matching of
receipts to purchase orders, and matching data to contracts
• Reduced processing costs and automation of business rules to send incomplete invoices back to
the supplier
• Cash discounts are available for more timely invoice payment
Invoice
Document
Date
Date of
postal
delivery
Date incoming
data records
received
Posting Date
Payment
approval
date
Payment
date
Auto- posting or
handle exception
Auto- posting and
handle exceptionCentralized
scanning
Unblocking W/F
Figure 3: Key milestones for invoice handling (timescales not to scale)
© 2009 SAP AG 14

APPENDIX 2: Invoice processing problems requiring manual intervention.
(Not a complete list!)
01 Logistics invoice received without PO number
02 PO incomplete or deleted
03 PO not released
04 Wrong PO number is quoted
05 Requires PO increase
06 Closed PO
07 Not a legal invoice
08 Unauthorised invoice or credit note
09 BACS required but no bank details given
10 Vendor does not exist in master records
11 Duplicate invoice
12 Resolve blocked invoice
13 Credit note to be forwarded for approval
14 Wrong VAT or not shown on invoice
15 Total amount on invoice not match items
16 Wrong withholding tax or not on invoice
17 Invoice scanned incorrectly
© 2009 SAP AG 15

© 2009 SAP AG 16
Disclaimer and Liability Notice
This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not
supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade.
SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document,
and anyone using these methods does so at his/her own risk.
SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or
code sample, including any liability resulting from incompatibility between the content within this document and the materials and
services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this
document.

Incoming Invoices at Shared Service Centres

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Incoming Invoices at Shared Service Centres

Similar to Incoming Invoices at Shared Service Centres (20)

Incoming Invoices at Shared Service Centres