SAP Invoice Management

7.5
Functional Design Document
Date: 22 January 2025
Version: 2.65

1 | 148
Table of Contents

Table of Contents 2

1 Sign Off 7

2 Purpose of Functional Design Document (FDD) 8

3 Project Assumptions 9

3.1 General 9

3.2 SAP IM 9

3.3 ICC 10

4 VIM Overview 11

5 Process Incoming Invoices 13

5.1 Scanning Paper Invoices 13

5.1.1 Process 14
5.1.2 Separation of Paper Invoices 14
5.1.3 Separation of Annexes 14
5.1.4 Colors 15
5.1.5 Scan Batch 16
5.1.6 Number of Profiles 16

5.2 PDF Invoices 17

5.3 EDI Invoices 18

5.4 Other Formats 20

5.4.1 Excel Extraction – PO Invoices (Channel EXCEL_PO) 20
5.4.2 Excel Extraction – NPO Invoices (Channel EXCEL_NPO) 20
5.4.3 Flat File Interface from Landworks (Channel LANDWORKS) 20

6 Archiving 21

7 Recognition and Validation 23

7.1 General Recognition Settings 24

7.2 Recognized Fields 24

2 | 148
7.3 Detailed Recognition Settings 26
7.3.1 Vendor Number 26
7.3.2 Company Code 27
7.3.3 Reference Number 27
7.3.4 Document Date 27
7.3.5 Gross Amount 28
7.3.6 VAT Amount 28
7.3.7 Freight Amount 28
7.3.8 Currency 28
7.3.9 Credit Memo 29
7.3.10 PO Number List 29
7.3.11 Document Header Text 30
7.3.12 Vendor Account Number 30
7.3.13 Special Handling Indicator 30
7.3.14 Vendor Item Text 30
7.3.15 Payment Reference 30
7.3.16 Assignment 30
7.3.17 Down Payment 30

7.4 Download of Vendor and PO Master Data 30

7.5 Validation 31

7.6 Training of Recognition 33

8 SAP IM Workflow 34

8.1 Document Type Determination 34

8.2 PO Flow 36
8.2.1 Process Overview 36
8.2.2 PO Workflow Dashboards 39
8.2.2.1 DP Work Item Screen 39
8.2.2.2 PO Blocked – Line Level 44
8.2.2.3 PO Blocked – Header Level 45

8.2.3 Detailed Description of the PO DP Exceptions 47

8.2.3.1 DP902: Invalid Company Code 50
8.2.3.2 DP102: Invalid Vendor for Company Code 51
8.2.3.3 DP125: Missing Invoice Date 53
8.2.3.4 DP133: Missing Vendor Invoice Reference 54
8.2.3.5 DP105: Suspected Duplicate Invoice 55
8.2.3.6 DP954: Invalid Invoice Date 56
8.2.3.7 DP104: Invalid Currency 57
8.2.3.8 DP101: Invalid PO Number 58
8.2.3.9 DP161: Company Code Mismatch 60

3 | 148
8.2.3.10 DP155: Currency Mismatch 61
8.2.3.11 DP153: Vendor Mismatch 62
8.2.3.12 DP940: PO Is Incomplete 64
8.2.3.13 DP106: PO not Released 65
8.2.3.14 DP918: Invalid Banking Information 66
8.2.3.15 DP160: PO Credit Memo Processing 67
8.2.3.16 DP110: Manual Check Needed for Indexing Lines 68
8.2.3.17 DP951: Price Discrepancy 69
8.2.3.18 DP163: GR not Done 71
8.2.3.19 DP951: Quantity Discrepancy 73
8.2.3.20 DP912: Alternative Payee 75
8.2.3.21 DP910: Withholding Tax 77
8.2.3.22 DP953: Tax Validation Required 82
8.2.3.23 DP955: Vendor Audit Required 83
8.2.3.24 DP956: Tax Audit Required 84
8.2.3.25 DP958: Address Validation for Check Vendor 85
8.2.3.26 DP108: Process PO Invoice 86

8.2.4 Detailed Description of the PO Header Workflow 88

8.3 Non-PO Flow 89

8.3.1 Process Overview 89
8.3.2 Non-PO Workflow Dashboards 91
8.3.2.1 DP Work Item Screen 91
8.3.2.2 Approval Work Item Screen 95

8.3.3 Detailed Description of the Non-PO DP Exceptions 96

8.3.3.1 DP209: Determine Expense Type 100
8.3.3.2 DP205: Invalid Company Code 101
8.3.3.3 DP201: Invalid Vendor for Company Code 102
8.3.3.4 DP223: Missing Invoice Date 104
8.3.3.5 DP233: Missing Vendor Invoice Reference 105
8.3.3.6 DP204: Suspected Duplicate Invoice 106
8.3.3.7 DP965: Invalid Invoice Date 107
8.3.3.8 DP202: Invalid Currency 108
8.3.3.9 DP920: Auto-code Accounting Information 109
8.3.3.10 DP250: Approval Required 110
8.3.3.11 DP919: Invalid Banking Information 110
8.3.3.12 DP913: Alternative Payee 112
8.3.3.13 DP911: Withholding Tax 114
8.3.3.14 DP251: Pre-approved 116
8.3.3.15 DP921: Account Information Changed During Approval 117
8.3.3.16 DP961: Tax Validation Required 118
8.3.3.17 DP962: Vendor Audit Required 119
8.3.3.18 DP963: Tax Audit Required 120
8.3.3.19 DP964: Address Validation for Check Vendor 121
8.3.3.20 DP207: Process Non-PO Invoice 122

8.3.4 Detailed Description of the Non-PO Approval Workflow 123

8.3.4.1 Parallel Line Item based Approval Process 123
8.3.4.1.1 Roles 123
8.3.4.1.2 Levels 124
8.3.4.1.3 Packs 125
8.3.4.1.4 Parallel Processing 126

4 | 148
8.3.4.1.5 Approval Process Steps 127
8.3.4.2 Level Based Chart of Authority 130

8.4 Posting Date 134

8.5 FI Document Type 134

8.6 Tax Code Determination 134

9 Process Work Items 135

9.1 Integrated Invoice Cockpit (IIC) 135

9.2 VIM Workplace 137

9.3 SAP Approval Portal 137

10 Reminder E-mails 138

10.1 Standard Reminder E-mail to the End-User 138

This e-mail will consist out of a header text and a body. 138

10.2 Workitem Notification E-mail to the End-User 140

11 Reporting 141

11.1 VIM Analytics 141

11.2 Current Liability Report 141

11.3 SAP IM Central Reporting Infrastructure 141

12 Substitution 144

12.1 Scheduled Absence 144

12.2 Unscheduled Absence 144

5 | 148
Approval for use

Delaware Name Signature Date

Consulting

Setup by: Carlos Garcia

Approved by:

Distribution

Company Name contact person

EDF Randy Freeman

EDF

Change history

Version Date Description

1.0 First version

2.1 09/08/2017 Draft Version after workshop

6 | 148
1 Sign Off

Document sign-off sheet

EDF Sign: Date:

Randy Freeman

EDF Sign: Date:

Delaware Consulting Sign: Date:

Greg Kowalik

Delaware Consulting Sign: Date:

Carlos Garcia

The purpose of this document is to obtain a sign-off on the agreed upon functionalities for the ICC v7.5 SP5 and SAP
IM v7.5 SP5 product to be implemented at EDF. The signatures above indicate agreement to the specific functionality
as documented herein. The parties agree that their signatures indicate scope freeze on this functionality and
variation from the design specified herein may result in changes to project scope, budget or schedule. As for any
other project within EDF, any changes will have to be raised through a formal change process and potentially impact
timeline and/or budget.

7 | 148
2 Purpose of Functional Design Document (FDD)

The purpose of this document is:

To provide you with a detailed explanation of the processes, exceptions, business decisions, and how
work items will be routed within the SAP IM workflow solution for PO (MM) and non-PO (FI) invoices.

To freeze the scope and define the baseline set of functionality, based on best practices,
To control scope during the implementation.
Against which mutually agreed scope changes can be defined that can affect budget and schedule.

This document is not intended to explain the complete SAP IM package or to serve as a user guide. This
information can be found in the standard SAP IM configuration and user manuals.

Some basic knowledge of the SAP Materials Management module (such as Management of Purchase
Orders, Goods Receipts, Service Entries, Invoicing) and the SAP Financial and controlling module is
assumed while reading this FDD.

8 | 148
3 Project Assumptions

3.1 General

1. Implementation will be based on

Component functionality Component name Version

SAP system SAP R/3 ECC 6.0

Archiving OTAS OTAS 16

SP3

Invoice Management SAP Invoice Management by OpenText 7.5 SP5

Invoice Extraction & Validation OpenText Invoice Capture Center 7.5 SP5

Scanning Enterprise Scan ES 16

Browser version ≥ IE9 / ≥ Firefox 17 / ≥ Chrome 22 / ≥ Safari 5.0

2. SAP ERP is based on a single SAP instance.

3. DLW consultants will be granted remote access to EDF’ systems for the duration of the project.
4. EDF is responsible for ensuring that sufficient SAP licenses and SAP GUI’s are available for all users
involved in the business process.
5. EDF is responsible for ensuring that e-mails can be sent from SAP by configuring and maintaining the
necessary outbound e-mail settings.
6. EDF has a typical three-tier system landscape which will be used for project implementation (DEV-
QAS-PRD).
7. The client will inform Delaware Consulting if a SAP upgrade will be performed during the VIM project.

3.2 SAP IM

8. Documents subject to processing via SAP IM:

 Vendor invoices
 Vendor credit memos
 Subsequent Credits & Debits
9. Standard SAP IM user interface is available in Dutch, English, French, German, Italian, Spanish,
Portuguese, simplified Chinese, Japanese, Russian, Polish, Czech, Hungarian, Romanian and Turkish.
For custom objects the required languages should be agreed upon upfront.

SAP IM user interface – List of languages that will be included in VIM package

English, French, Spanish

9 | 148
10. The payment process and follow-up will be managed outside of the SAP IM processes.
11. Documents parked outside of SAP IM will be out of scope.
12. Throughout this document the following terminology is used to refer to the proposed ‘SAP Invoice
Management by OpenText’ solution: VIM, Vendor Invoice Management, SAP IM and SAP Invoice
Management.

3.3 ICC

1. Any handwritten document cannot be processed and hence is out of scope.

2. The recognition rate is determined by the readability of the invoice image, which decreases in case:
 Handwritten notes are mentioned on the invoice (e.g. checkmarks).
 The characters are distorted when zooming in.
 Of certain types of invoice paper, such as carbon copy paper.

3. Two ICC applications

 One for US
 One for Canada
4. Minimum two ICC servers are required and can be virtualized:
 One for testing purposes. This can be configured with SAP DEV and/or QAS.
 One for the production environment. This will be set up alongside SAP PRD.

5. ICC recognizes invoices written in Dutch, English, French, German, Italian, Spanish, Portuguese,
Danish, Finnish, Norwegian, Swedish, Turkish, simplified Chinese1, Japanese2, Russian, Polish, Czech
and Hungarian.

ICC recognition – List of invoice languages included in VIM package

English, French, Spanish

6. ICC Validation Client is available in Dutch, English, French, German, Italian, Spanish, Portuguese,
simplified Chinese, Japanese, Russian, Polish, Czech, Hungarian, Romanian and Turkish. All these
languages are available by default for all fields, except for the custom fields created within the VIM
package.

1
Only the following templates can be recognized as of ICC 7.5 SP2: VAT special invoice (invoice code 1), VAT common invoice
(invoice code 6) and new template of transportation invoice (invoice code 7).
2
Only fields based on master data can be recognized, other fields can only be recognized after training.

10 | 148
4 VIM Overview

Delaware’s VIM is a pre-configured invoice management system based on the baseline SAP IM by
OpenText, as delivered by SAP. It is enriched by Delaware Consulting grounded in the best practices
obtained during the many successful project implementations.

The proposed SAP IM solution for EDF is based on VIM:

 It processes both PO and non-PO invoices from scanning to release for payment.
 It reports the progress and processing history of the invoices from scanning to release for
payment.
 It checks against a list of pre-defined exceptions.
 It offers variation in processing options, role resolution and approval levels in order to align as
close as possible to the way of working at EDF.
 It demonstrates a best practice configuration that will bring EDF the maximum benefit of the
solution.

From an end-to-end solution perspective, VIM consists of 4 major components:

 Scanning – Scan Platform
 Archiving – Archive Server
 Recognition – ICC
 SAP Invoice Management Workflow – SAP IM – VIM

11 | 148
The SAP Invoice Management Workflow is composed of ‘Baseline Invoice Processing’ and ‘Baseline
Exception Handling’:

12 | 148
5 Process Incoming Invoices

5.1 Scanning Paper Invoices

For EDF, Enterprise Scanner will not be used. AP already split the invoices, all those invoices will be
scanned on its own and they will be send through e-mail. This chapter information has been left in the
blueprint for informative purposes only, in case that at some point in time we want to enable the
Enterprise Scanner application. Everything included in chapter 5.1 is informative only.

Enterprise Scan is an application that allows you to:

 Communicate in an easy way with the scanner: starting or stopping the scanning.
 Verify the scanned images concerning the quality and the correct separation of documents or
annexes.
 Delete or correct the scanned invoice images.

Invoice

Attachment

Sample invoices with Drag & drop a separator sheet

their attachment(s) between invoice & attachment(s)

Enterprise Scan is installed on a workstation that is directly connected to the scanner (USB connection). It
is used by the scan operator.

13 | 148
 5.1.1 Process

Input

Enterprise Scan processes original invoices received in paper format. For those invoices the supported
paper characteristics (thickness, weight …) are defined by the selected scanner.

Actions

The preparation steps for the scan operator before scanning paper invoices are:
 Visual verification to check the paper invoices. In case the papers are not invoices, then they
cannot be scanned.
 Stick a barcode on the first page of each invoice.
 In case the invoices consist of a large number of pages, insert an annex separator sheet to
separate the invoice from the attachments.
 Sort the invoices in groups corresponding with the available profiles, e.g. by country.
 For practical reasons split a group in batches of about 50 pages at maximum. This will simplify
the handling.

Output

The invoice images are archived in the archive server as PDF files.

5.1.2 Separation of Paper Invoices

The paper invoices are separated based on a barcode. Hereby the type of barcode being used is crucial.
The value of the barcode can be chosen. By using a sequential number the barcode can be used as a
reference to retrieve invoices from your paper archive, e.g. during audit control.

Requirements and printing of the barcodes

The barcodes can be purchased or printed by EDF. Basically any type of printer can be used, except for
matrix printers. A good quality has to be delivered in order to ensure a correct recognition.

The recommended size should be 5 by 2 centimeters and the barcode type should be type 39, which is
easy to create in Microsoft Excel.

Positioning of the barcodes

The barcode must be stuck on the invoice with a horizontal orientation. Any other orientation will
decrease the quality of recognition or even make it impossible.

The position must be chosen in such a way that:

 No mandatory information is covered ( loss of information).
 Interference with other lines (e.g. tables) is avoided ( risk of no recognition).

5.1.3 Separation of Annexes

Annexes have to be separated by using an annex separator sheet. This sheet becomes part of the invoice
image and is interpreted by ICC. It may not be deleted by the scan operator.

14 | 148
For paper invoices the separator sheet is inserted before scanning. The recognition engine will use all
pages that precede the separator sheet. Any information on the pages that succeeds the separator sheet
will be ignored.

The annex separator sheet must be printed from the original electronic file to ensure the recognition of
it. Below is an example of a separator sheet that can be used to separate the actual invoice from the
annexes.

5.1.4 Colors

Paper invoices can be scanned in color or in black & white.

Scanning in color

Advantages:
 More accurate representation of the real invoice image.
 The image respects all annotations in color.

Disadvantages:
 The volume of a PDF or TIF file is 10 times larger:
 Typical page in black & white: 50 Kbytes.
 Typical page in color: 500 Kbytes.
 Scanning in color can be slower than scanning in black & white (depends on the scanner).
 The transfer of data is much slower.

Impact on the recognition

Scanning in color does not add any added value to the recognition and validation process: the ICC
recognition engine always converts the image (PDF or TIF, black & white or color) to a black & white TIF
image. This temporary converted image will only be used for recognition. All preceding processes will use
the original scanned version.

Recommendation

We recommend scanning incoming documents in black & white and not larger than DIN A3 size.

15 | 148
 5.1.5 Scan Batch

It is recommended to work with invoice batches. Typically a batch contains 50 pages. The advantages to
limit the number of invoices per batch are:
 The scan operator has a better overview in Enterprise Scan.
 There are fewer invoices impacted when it is necessary to rescan a batch.

After Enterprise Scan the concept of batches is no longer used. Once the invoice images have been sent
to SAP for archiving, the individual invoices of the scanned batch are listed in the VIM Analytics report. As
from this point on it is no longer possible to trace batches.

5.1.6 Number of Profiles

Enterprise Scan works with profiles. These profiles contain the settings on how:
 The invoices are scanned with Enterprise Scan (input).
 To process the invoices (process).
 To archive the invoices (output).

At EDF all newly received paper invoices will be scanned with Enterprise Scan. The scan operator chooses
the correct profile before scanning.

There are different settings for scanning:

 Single sided (SS) or double sided (DS)
 Color or black & white
 Resolution

The following takes place during the processing of the invoices by Enterprise Scan:
 Deletion of blank pages.
 Invoice separation by barcode.

After post-processing the invoices the scan operator will initiate the archiving process. Depending on the
solution there are different ways of archiving. We refer to chapter ‘6 Archiving’ for more information
about this process.

No profiles will be created, as Enterprise Scanner will not be used:

Profiles Scanner Pages Color Blank pages Resolution Format Archive document type

NA

16 | 148
5.2 PDF Invoices

Input

PDF invoices received via email can be extracted automatically from the e-mail. Two different email
address one for US and one for Canada.
All different PDF files from the same e-mail are processed as different invoices. One PDF file = One
invoice, if multiple invoices are mentioned in one PDF file, only one Doc ID is created in VIM.

All other documents in the e-mail which are no PDF files, are considered as attachments.

The body in the e-mail will be saved as an attachment for each invoice in format HTML.

Actions

In general, no manual intervention is required. All PDF invoices and other attachments are extracted from
the e-mail, which is sent to SAP IM. Every PDF file is one invoice. All other documents with a different
extension are considered as attachments and are linked to the PDF invoice prior in the e-mail.

It’s very important the first attachment in the e-mail is the PDF Invoice, followed by the other
attachments (if available).

Important Remark: the other attachments shouldn’t be send as PDF. If a vendor wants to send
attachments in PDF it should be included in the PDF invoice.

In case a vendor sends multiple invoices in one e-mail, the different invoices are considered to be
different PDF documents. If those documents are having attachments, next sequence should respected:
INVOICE1.PDF – ATTACHMENTINVOICE1.noPDF – INVOICE2.PDF – ATTACHMENTINVOICE2.no PDF –
INVOICE3.PDF…

Example:

Invoice 1: Invoice 1.pdf with AttachmentInvoice1.docx

Invoice 2: Invoice 2.pdf with AttachmentInvoice2.xlsx
If there’s no PDF in the e-mail, the attachments are not processed.

The received e-mail can be followed via SAP reporting.

17 | 148
Output

SAP IM will archive the PDF invoice + attachments and a workflow is started automatically, recognition of
the invoice data in ICC is the next step. Only the PDF invoice is send to ICC for recognition and validation.

For the attachments, below documents are foreseen.

Document Archive Documenttype

HTML (Mail Body) Z_HTM – Type HTML

For Example: Word Z_OTH – Type *

For Example: Excel Z_OTH – Type *

5.3 EDI Invoices

Remark 1 – EDI is not currently in use in EDF, VIM will be configured to use the INVOIC02 inbound idoc,
the configuration will be done, after the IDOC gets into the system which will have to be configured by
EDF when an actual interface will be set up.

Input

EDI invoices are received and converted to an IDOC. This conversion is not in scope of the SAP IM project
and is responsibility of EDF (SAP PI / PO). The IDOC to be used is an INVOIC02.

Actions

No manual intervention is required, the IDOC is automatically loaded and sent to SAP IM.
Via standard SAP reporting, the status of the IDOC can be consulted and possible problems detected.

Output

The workflow in SAP IM is started automatically in which all data from the IDOC is transferred and
converted into a readable PDF file, which is also archived. The archived document is used as invoice
image and can be consulted by the end users during the workflow process.

A human readable format of the EDI will be provided.

18 | 148
Below image is an example of the readable PDF file created by VIM for EDI Invoices:

19 | 148
5.4 Other Formats

5.4.1 Excel Extraction – PO Invoices (Channel EXCEL_PO)

An Interface will be created to start a VIM Workflow for PO Invoices based on an excel template. The
template will include the information of the invoice at line item level, and the information at header level
will be repeated to define which line items belong to the same invoice.

The program will allow to upload a single image, which will be used for all the invoices generated for this
batch.

5.4.2 Excel Extraction – NPO Invoices (Channel EXCEL_NPO)

An Interface will be created to start a VIM Workflow for NPO Invoices based on an excel template. The
template will include the information of the invoice at line item level, and the information at header level
will be repeated to define which line items belong to the same invoice.

The program will allow to upload a single image, which will be used for all the invoices generated for this
batch.

5.4.3 Flat File Interface from Landworks (Channel LANDWORKS)

There’s a current interface to post invoices in SAP (which is not being used right now, but It has already
been developed). This interface will be changed so that it generates an invoice in VIM instead of posting
the invoice directly to SAP. Initially, no approval process is foreseen for these invoices, as part of the
project scope we will just cover the migration of the posting process from SAP to VIM.

20 | 148
6 Archiving

The scan process will generate an invoice image in a predefined format, PDF. In order to consult this
image at a later stage in SAP, the invoice image must be archived. Archiving can be done in either of the
following ways:
 Via SAP program OA_UPLOAD_AND_LINK.
This requires that the invoice image files are stored in a shared folder on a server that is visible
for SAP. Running the program will retrieve the files from that folder and gets them archived.
 Via SAP transaction OAWD.
This requires that the scan operator logs on to SAP and executes the transaction OAWD.
 Via Document Pipelines.
For this solution the OpenText license ‘SAP Document Access by OpenText’ is needed. Within this
solution the invoices are archived in background. Issues can be monitored by an administrator
via a client application.

EDF uses following archiving method to upload invoice images

☐ OA_UPLOAD_AND_LINK

OAWD
✘

☐ Document Pipelines

Once archived, the invoice is registered in SAP IM and via a report the invoice can be tracked. During the
entire invoice processing flow the different components will communicate with the archive server to
retrieve the scanned invoice images.

After invoice approval and invoice payment, when SAP IM actions are finalized and thus SAP IM has
outplayed its role, the scanned invoice image remains available for the authorized SAP user who wants to
consult it from legacy SAP objects. From invoice related SAP transactions (e.g. MIR4, FB03 …), the
associated image can be displayed by using the standard SAP Global Object Services (GOS).

21 | 148
SAP IM archive document types

During the archiving the invoices are linked to a SAP IM archive document type. This document type will
be used by ICC to determine which ICC application is applicable.

EDF uses following archive document type

Z_PDF_US

Z_PDF_CA

22 | 148
7 Recognition and Validation

This step in the process will be executed by OpenText Invoice Capture Center (ICC). ICC is a product that
extends OpenText Vendor Invoice Management with automatic recognition and manual validation of
invoice data.

The ICC recognition server takes care of recognizing the invoice data. This is called the OCR part (Optical
Character Recognition). ICC communicates with SAP IM to retrieve the invoice images which are ready for
recognition. It performs the recognition and returns the result to SAP IM. This process runs in background
hence without user interaction.

The validation client is essentially the user interface in which a validator can review, verify and possibly
correct the recognized values of the metadata. When starting the ICC validation client the validator needs
to enter its SAP user credentials. Based on authorizations the system decides which set of invoices the
validator is able to process.

Below screenshot is a representation of a typical view in the ICC validation client.

The usage of the validation client is optional. It can be bypassed. Thereby making SAP IM the first and
only application to interact with incoming invoices.

23 | 148
7.1 General Recognition Settings

ICC is organized in applications. Each application can have its own preferences and field definitions with
regards to the extraction cycle, such as date formats and amount notations.

In addition the ICC application will be important for the validation cycle. The validator must select a
suitable application in the ICC validation client before he or she can start validating invoices. In this way
the validator will only process invoices that are relevant for him or her.

While choosing the number of applications it is important to identify the different receiving countries as
ICC uses region specific formatting, such as dates and numbers. This decision should be taken into
account in order to obtain an optimal recognition.

ICC application – List of countries included in VIM package

Western Europe invoice format – Austria, Belgium, France, Germany, Italy, Netherlands, Portugal, Spain, Switzerland

For EDF the applications will be based on regions. Per region an urgent application is available.

Application name Receiving region Default currency / Default language for Archive document
Date Format validation type

EDF_US United States USD – MM/dd/YYYY English Z_PDF_US

EDF_CA Canada CAD – dd/MM/YYYY English Z_PDF_CA

ICC recognition won’t recognize the invoice pages succeeding a separator sheet. In those cases where the
separator sheet would have been forgotten it is possible to skip the recognition after a certain number of
pages. This is very handy to preserve the performance of the application.

Skip ICC recognition

The recognition will be skipped after 10 pages.

A maximum of 2 hours for recognizing an invoice in ICC is possible. In case the recognition wasn’t
completed within that time frame, the system stops the recognition. Besides, ICC will try to recognize up
to 3 times the same invoice. After 3 times, the invoice gets a certain status indicating to the administrator
that he or she needs to revise the invoice image.

7.2 Recognized Fields

ICC provides you with a number of standard fields. The recognition of these fields has been optimized by
OpenText, based on their experience with a wide variety of invoices from all over the world and their
knowledge of the recognition engine. Within the VIM package we offer a set of additional fields based on
our common experience.

The following tables provide an overview of the fields foreseen within the VIM package. Each field will be
displayed in the ICC validation client for review and/or manual modification prior to sending it to the SAP
IM workflow.

24 | 148
The column ‘Recognition’ indicates how the recognition is done:
 Matching: The fields are not recognized directly from the invoice. ICC will determine the value
based on data mentioned on the invoice and matches this with the SAP master data.
 Direct: The fields are recognized directly from the invoice by looking in the close proximity of
frequently used keywords.
 Manual entry: The field is manually populated by the validator.

ICC header fields

Tab order Header field Recognition Mandatory

1 Vendor Number Matching Yes

5 Company Code Matching Yes

9 Reference Number Direct Yes

10 Document Date Direct Yes

12 Gross Amount Direct Yes

13 VAT Amount Direct No

14 Freight Amount Direct No

15 Currency Direct Yes

16 Credit Memo Direct No

18 PO Number List Matching No

19 Document Header Text Manual entry No

20 Vendor Account Number Direct No

21 Special Handling Indicator Direct No

25 | 148
ICC line item fields

EDF will not use Line Item Recognition.

Tab order Line item field Recognition Mandatory

1 PO Line Number Matching No

2 PO Number Direct/Matching No

4 Order Unit Direct/Matching No

5 Quantity Direct/Matching No

6 Unit Price Direct/Matching No

7 Tax Amount Direct/Matching No

11 Item Description Direct/Matching No

7.3 Detailed Recognition Settings

7.3.1 Vendor Number

The vendor number cannot be recognized directly from the invoice. Therefore ICC uses master data,
which is imported daily from SAP, to determine the vendor number. For this determination the vendor
data on the invoice is mapped against the master data based on a system of priorities. Each item of the
vendor data has a specific priority.

For the US vendor recognition, the Company code will not be used to restrict the vendors available for
recognition, but for the CA vendor recognition it will be used, as the Bill To information is expected.

Below the list of the priorities:

1. Priority 1 (1 item needed): VATID, RESERVE1
2. Priority 2 (1 item needed): EMAIL, FAX, IBAN, PHONE, VATID1 … VATID5, WWW
3. Priority 3 (2 items needed): BANKACCOUNT, COMPANY, STREET, SWIFT, RESERVE2
4. Priority 4 (5 items needed): BANKNAME, BANKNUMBER, CITYNAME, COMPANY1, POBOX, ZIP , ZIP1
5. Priority 5 (8 items needed): STATE

The lower the priority, the more items it requires. E.g. if a phone number has been retrieved it counts as
100% certainty; if a company name and street has been retrieved, it will not be counted as sufficient as it
needs at least 2 items of this priority.

This implies that the displayed information needs to correspond with the information present in the
database. It also needs to correspond 100%, e.g. phone number on invoice 456-789 does not correspond
with phone number in database 0456-789.

The PO number or company code will not be used for means of vendor recognition.

In ICC validation the following fields will be displayed together with the vendor number:

26 | 148
  Company name (if the Company Name does not match due to W-9s, this will harm the
recognition rate for the vendor)
 Street (if the Vendor Address does not match due to W-9s, this will harm the recognition rate for
the vendor)
 ZIP & city name
 Bank number
 Company code (For Canadian Application)

7.3.2 Company Code

The company code cannot be recognized directly from the invoice. Therefore ICC uses a recipients list
containing data of the receiving companies, which is imported during the initial setup, to determine the
company code. For this determination the company code data on the invoice is mapped against the
recipients list. The following fields are taken into account:
 Company name
 Alternative company name
 Street
 PO box
 ZIP
 City name
 Country
 VAT ID

US : Company Code will be defaulted in ICC ( Default value to be decided) and later in SAP the Company
code will be determined based on the Purchase Order Company code . For Non-PO Invoice based on the
Vendor and Account Number the Company Code will be identified . Non-PO with several lines with
different Company Codes and Account Number, the bills will be sent to Main Account Number.
If, after using these parameters the Company code was not recognized correctly, we will keep the default
company code in the invoice and manually an AP Processor will be able to select the right company code
to use.

7.3.3 Reference Number

For the recognition of the reference number ICC will use an extended list of keywords, which cannot be
modified. If the reference number cannot be recognized from the invoice, the recognition of reference
numbers can be trained.

7.3.4 Document Date

For the recognition of the document date ICC will use an extended list of keywords, which cannot be
modified, and a list of possible date formats. The formats to be used are, for US: MM/dd/YYYY, for
Canada: dd/MM/YYYY. The system will recognize other common date formats.

27 | 148
 7.3.5 Gross Amount

For the recognition of the gross amount ICC will use an extended list of keywords, which cannot be
modified. Within the VIM package different amount formats are supported. Invoices for US and Canada
will use the US amount format.

Examples:
 European amount format: 3.200,00 will be recognized as 3.20.
 US amount format: 3,200.00 will be recognized as 3,200.

7.3.6 VAT Amount

For the recognition of the VAT amount ICC will use an extended list of keywords, which cannot be
modified. Within the VIM package Western European amount formats are supported. For invoices with
another amount format the ICC validator needs to review and update the amount, if required.

The VAT amount requires the recognition of a VAT rate.

7.3.7 Freight Amount

The Freight Amount can be manually populated by the validator in ICC validation, and it can be trained.

7.3.8 Currency

For the recognition of the currency ICC will use an extended list of keywords, which cannot be modified,
in combination with a list of predefined currency list. The list can be modified and/or extended.

EUR GBP CAD MXN USD

Euros GBP CAD MXN USD

EUROS gbp cad MX$ usd

EURO £ CA Peso US$

DOLLAR

EUR Pesos $US

Mexicanos

EU US-$

E US DOLLAR

Euro US
DOLLARS

Eur US-DOLLAR

euro US-
DOLLARS

eur DOLLAR

eu $

28 | 148
 e

Eur

7.3.9 Credit Memo

For the recognition of the credit memo ICC will use an extended list of keywords. This list can be modified
and/or extended.

ICC application – List of keywords for credit memo incl./excl. in VIM package

Phrase list Exclusion list

Abbuono GUTSCHRIFT ORIGINAL Credit Suisse

Abono Gutschriftskopie Credit Agricole

Adjustment note GUTSCHRIFT (Kopie) Cash/Credit

avis de crédit Gutschrift / Credit Note: Cash/Credit Memo

avoir Gutschrift - Credit Note Cash/Credit Bill

Bonusteilabrechnung Gutschrift Nr.: Kreditor

Credit-faktuur GUTSCHRIFT NR.: Credit Du Nord

Credit adjustment Gutschrift

CREDIT MEMO GUTSCHRIFT

Credit Note kredietbrief

crédit kredit

Gutschrift-Nr. / Datum Kredietnota

GUTSCHRIFT – ORIGINAL Nota de Credito

7.3.10 PO Number List

For the recognition of the PO number(s) ICC will use the PO master data, which is imported daily from
SAP, in combination with the defined PO number range(s). Mind that PO numbers which cannot be
matched against the PO master data will not be displayed.

ICC can recognize more than 23 PO numbers, also the validator will see that more than 23 PO numbers in
his screen, however when moving the PO numbers to SAP IM only 23 PO number can be moved (due to
comma separated list in text field of 255 characters).

PO number ranges to be recognized for EDF

4500000000-4599999999
4400000000-4499999999

29 | 148
 7.3.11 Document Header Text

The document header text can be manually populated by the validator in ICC validation, and it can be
trained.

7.3.12 Vendor Account Number

The vendor Account Number can be manually populated by the validator in ICC validation, and it can be
trained.

7.3.13 Special Handling Indicator

The Special Handling Indicator can be manually populated by the validator in ICC validation, and it can be
trained, this will be included in the Payment Request form.

7.3.14 Vendor Item Text

The vendor item text can be manually populated by the validator in ICC validation.

7.3.15 Payment Reference

The payment reference can be manually populated by the validator in ICC validation.

7.3.16 Assignment

The assignment can be manually populated by the validator in ICC validation.

7.3.17 Down Payment

For the recognition of down payment ICC will use an extended list of keywords. This list can be modified
and/or extended.

ICC application – List of keywords for down payment included in VIM package

Anzahlung Avance Down payment Advance

Accompte Pro-forma Downpayment Voorafbetaling

7.4 Download of Vendor and PO Master Data

To improve the recognition of the vendor and PO data on the invoice ICC uses the master data of SAP.
This is done by downloading necessary information into staging tables, which will be transferred to the
ICC database. This way all PO related data recognition is accurate as well as the vendor recognition.

30 | 148
 Selection options available for download of vendor and PO master data

Details PO Vendor

Type of download Delta load Full load Delta Load Full load

Scheduling Daily Weekly Daily Weekly

Company codes All applicable All applicable All applicable

All applicable ones
ones ones Ones

Content All the Vendors. All the Vendors.

For Canada For Canada
including the including the
Open PO’s for a Company Code Company Code
Open PO’s for a
period of one Information, for Information, for
period of one year
year US we will not US we will not
include the include the
company code company code
information. information.

Not included Vendors with Vendors with

Closed PO's Closed PO's
deletion. deletion

7.5 Validation

Besides the use of the ICC Validation, SAP IM 7.5 also provides the alternative of performing the
validation part of the invoices directly in SAP IM, by using a point-and-click functionality.

EDF will perform the validation step in the ICC Validation client

☐ Always

☒ Selected field(s)

☐ Never

Below is only relevant if ICC Validation client is used.

For validating the recognized invoice data the validator uses the ICC validation client or SAP IM. The
validator can log on with its SAP credentials. When starting the program he or she chooses the required
application (not valid for SAP IM). Based on his or her credentials the system will only present the
invoices for which he or she is authorized and for which the archive document type is linked to the ICC
application. The validator is determined based on the archive document type, which is in most cases
determined by the region.

The validator needs to review and validate the invoices. The sequence in which incoming documents
have to be validated cannot be set. This depends on the progress of the workflow. The invoices with
status ‘Ready for validation’ are sent for validation according to a sequential number.
When validating in SAP IM directly, the validator does have the choice of sequence.

31 | 148
The validator is provided with the invoice image (‘Image view’) next to the recognition fields (‘Fields
view’). All involved fields are highlighted with a background color:
 Green: A correct value for the field is recognized or the field is optional and empty.
 Red: An incorrect value for the field is recognized or the field is mandatory and empty. An error
message will appear under the field. In this case the data needs to be manually selected to be
added.

Mind that there is no color coding if the validation is performed directly in SAP IM.

The probable cause for fields not being recognized is:

 Information does not appear on the invoice.
 Information appears on the invoice, but poor image quality prevents ICC extraction.
 Information appears on the invoice, no image quality issues, but ICC is unable to perform
extraction.

The validator can manually enter the missing value or select it on the invoice image by using the point-
and-click functionality. In this way ICC, or SAP IM, will auto-translate the value into the country specific
format (e.g. date). The validator can still force to submit blank values from ICC to SAP IM. Within the SAP
IM workflow key fields which are blank will be handled as exception.

If the default recognition is not up to standard, then the invoice can be marked for training. Consequently
the validated invoice data is sent to the SAP IM workflow for further processing the invoice and
simultaneously the invoice will be added to the training queue. For more information about the
procedure to train invoices, we refer to paragraph ‘7.6 Training of Recognition’.

The validator has three options to process the invoice:

 Submit: Once the results have been reviewed, they have to be submitted to SAP IM (‘Submit’). It
is possible to ask at the same time for the next document (‘Submit + Open’).
 Reject: It is also possible to reject a document (‘Reject’). ICC will then ask for a reject reason. The
user can select a reason or type in a new reason (free format).

Pre-populated reject reasons (defined at the beginning, reasons can be added through the course
of the project): bad image quality, invalid document (no invoice), …

Rejected documents will no longer be sent for validation. The associated SAP IM work item
will receive the SAP IM status ‘OCR validation rejected’.

 Cancel: When cancelling a document, the invoice will be presented again for validation at a next
session.

This validation is meant to be a quick visual validation and should not be used as an in depth invoice
check. This will be done later in the SAP IM workflow where the invoice is automatically checked against
the SAP master data based on the defined exceptions.
32 | 148
The validation setting can be turned off – this means that invoices will not be sent to ICC validation but
instead will pass directly to SAP IM workflow.

We recommend validating all invoices in ICC in the beginning. This to ensure the review of each invoice
for quality and completeness and to make sure that EDF's employees become familiar with the new
process. At a later stage, if there is enough confidence, this option can be reconsidered.

7.6 Training of Recognition

Training has to be performed manually in the customizing client by opening the appropriate ICC
application. Training is typically performed by a specially trained validation operator who will need local
administrator rights on the customizing client host, hence the ICC server.

The following standard fields are enabled for training:

 Document date
 Reference number
 Gross amount
 Net amount
 Vat amount
 Vat rate
 Currency
 Requester e-mail
 Payment reference

The following not standard fields will be enabled for training:

 Freight Amount
 Vendor Account Number (Customer ID)
 Special Handling Indicator

33 | 148
8 SAP IM Workflow

8.1 Document Type Determination

The scanning/recognition component will process a mixture of PO and non-PO invoices. After recognition,
all invoices are uploaded to SAP IM. As both types are handled differently within SAP IM they need to be
sorted out again into:
 PO invoices
 Non-PO invoices

In SAP IM a function module is called to decide whether the invoice enters the workflow as a PO or a non-
PO invoice. The following logic is used to make an initial estimation about the PO or non-PO workflow:

All invoices are considered to be PO invoices, except those invoices that satisfy all below conditions:
1. No PO numbers are found on the invoice.
2. The recognized vendor is indicated as FI allowed OR no vendor is recognized

There are two ways to indicate a vendor as being FI allowed:

Via table ZTSIM_NPO_VEND: If for the combination company code and vendor the column ‘FI’ holds an
‘X’, the vendor is FI allowed. If the vendor is not defined in the table, or if the column ‘FI’ is blank, the
vendor is considered not to be FI allowed.

Table ZTSIM_NPO_VEND looks like:

Company code Vendor Vendor FI PA FI Only

Account
Number
* 1000006 X X
4000 * X
3000 1000005 X

Via vendor classification: An additional classification field ‘FI vendor’ has to be defined in the vendor
master data. If the value is set to ‘Yes’, this vendor will be considered as an FI vendor. If the value is set to
‘No’, no classification is applicable and it concerns a PO vendor.

Advantages versus disadvantages

Advantage Disadvantage
Table ZTSIM_NPO_VEND Provides an overview of all ‘FI’ vendors Besides the vendor master data, this

34 | 148
 table will also need to be maintained
Vendor classification Maintenance is done in existing master More difficult to get an overview of all ‘FI’
data and not in separate table vendors

EDF uses following way to indicate a vendor as being FI allowed

☒ Table ZTSIM_NPO_VEND
☐ Vendor classification

The invoice type can still be changed during the SAP IM workflow. An invoice – initially determined
as a non-PO invoice – can be changed to a PO invoice in the course of the workflow (and vice versa).

In the following chapters, first the PO flow and then the Non-PO flow is described.

Remark – This table also will be used to identify the correct company code for the US, to be used for NPO
Invoices.

35 | 148
8.2 PO Flow

8.2.1 Process Overview

VIM includes 2 workflows for the PO Flow: the Document Processing Flow for all the exceptions that are
situated before the posting in SAP and the Blocked Flow for the exceptions triggered after the posting in
SAP. The blocked flow will not be used for EDF solution, no blocked invoices should be allowed.

The Document Type Determination rules decide that the PO workflow needs to be triggered and as a
result the related document processing (DP) workflow is started. Within the DP workflow the following
exceptions are validated:

Sequence DP Exception Background

step

1 DP902 Invalid Company Code No

2 DP102 Invalid Vendor for Company Code No

3 DP125 Missing Invoice Date No

4 DP133 Missing Vendor Invoice Reference No

5 DP105 Suspected Duplicate Invoice No

6 DP954 Invalid Invoice Date No

7 DP104 Invalid Currency No

8 DP101 Invalid PO Number No

9 DP900 Company Code Mismatch No

10 DP155 Currency Mismatch No

11 DP153 Vendor Mismatch No

36 | 148
 12 DP940 PO Is Incomplete No

13 DP106 PO not Released No

14 DP918 Invalid Banking Information No

15 DP160 PO Credit Memo Processing No

16 DP109 Unable to Determine PO Line Number Yes

17 DP110 Manual Check Needed for Indexing Lines Yes

18 DP951 Price Discrepancy No

19 DP163 GR not Done No

20 DP952 Quantity Discrepancy No

21 DP156 Unit of Measure Mismatch No

23 DP912 Alternative Payee No

24 DP910 Withholding Tax No

25 DP957 Balance Not Zero No

26 DP953 Tax Validation Required No

27 DP955 Vendor Audit Required No

28 DP956 Tax Audit Required No

29 DP958 Address Validation for Check Vendor No

30 DP108 Process PO Invoice No

Each of these checks/exceptions will be explained in detail in a next chapter. Important to keep in mind
that during the document processing workflow the invoice is not yet posted in SAP. The system will try to
post the invoice at the end in case all DP exceptions were validated successfully.

37 | 148
If all DP exceptions are validated successfully, the invoice is ready to be posted. All the invoice metadata
is used to post the invoice automatically in background using the standard transaction MIRO. Auto-
posting can have either of below two outcomes:

Auto-posting succeeds

If the balance is zero or the difference is within the SAP tolerances, the system will succeed in
automatically posting the invoice. This will result in a posted invoice.

Two situations can occur as a result of successfully posting a PO invoice:

 The invoice is free for payment. At this stage the IM workflow ends. The actual payment process
must be carried out outside SAP IM.
 The invoice is blocked for payment due to one of the standard blocking reasons: price or quantity
differences that exceed the SAP tolerance. Resolving these blocking reasons is handled by the
related SAP IM invoice line level workflow processes (see paragraph ‘Error: Reference source not
found Error: Reference source not found’).

Auto-posting fails

Auto-posting can fail because the balance is not zero and the difference is not within the SAP tolerances,
or posting period is closed …

At this stage the invoice will remain in the DP workflow and will need to be handled manually in the
exception “DP108: Process PO Invoice”, which can be seen as a fail-safe exception.

38 | 148
 8.2.2 PO Workflow Dashboards

Below an overview of the different workflow dashboards that a user can consult to process the invoices
within the SAP GUI via the Integrated Invoice Cockpit or the VIM Workplace.

Each tab is explained in detail together with the fields represented on the tab in the “Appendix 1:
Document Processing and Approval Workflow Dashboards”.

8.2.2.1 DP Work Item Screen

During the DP workflow the following dialog window is sent to the responsible user to solve the DP
exception.

The DP work item contains three major parts: the process options, the indexing screens and the detail
pane.

Process options for the current role

These are the buttons that will be configured per combination DP exception and processing role.

39 | 148
Indexing information

The indexing information contains 5 tabs representing the invoice data that was recognized from the
invoice or entered/updated during the SAP IM workflow.

Each tab is explained in detail together with the fields represented on the tab in the “Appendix 1:
Document Processing and Approval Workflow Dashboards”.

Basic Data
This screen shows the current DP exception and the document type, along with some basic header
information which was recognized from the invoice. The invoice data was initially populated from the
recognition application and possibly changed afterwards, as a result of actions taken during the SAP IM
workflow to resolve the exceptions.

Line Items
This screen represents the PO line items for the PO invoice.
 The ‘PO Reference’ tab contains the PO line items for the invoice. This data can be changed by
the user. The lines coming from the PO Number(s), as would have been presented using MIRO,
are show at the bottom.
 The ‘G/L Account’ tab allows you to easily add unplanned costs.

40 | 148
Accounting
This screen shows more accounting related data coming from the invoice, the SAP master data or added
manually.

Tax
This screen shows the tax related fields for the invoice.

If the Vendor is Withholding Tax applicable following subsections in the Tax tab become visible:

41 | 148
Process
This screen shows relevant process information, like the document type and the barcode. Also the
suspected duplicate invoices are listed on this screen.

In the part ‘Duplicate Index Records’ the system lists the invoices with which it suspects that this
invoice is a duplicate. It provides an overview of all invoices (e.g. document ID 192) that needs to be
taken into account by the AP Processor to decide whether the newly received invoice (e.g. document ID
197) is a duplicate or not.

Detail pane

Display invoice image

42 | 148
*Remark – For some invoices we will need to restrict the access to the invoice images, a customization
will have to be built to get this functionality and only allow access to the images to certain roles. We will
work together with the business to specify the restrictions that have to be applied during the image
display.

Display process/approval history log: Overview of all actions taken for this work item (comments, activity,
process type, document status, …).

Display comments log: Overview of all comments provided while processing documents.

43 | 148
8.2.2.2 PO Blocked – Line Level
During the blocked workflow the following dialog window is sent to the responsible user to solve the line
item block. The Blocked workflow will not be activated, EDF does not block invoices and will check price
and quantity issues before posting.

General info

 Current blocking reason: price of quantity.

44 | 148
  Current processing role.

Blocked document info

References to related SAP objects e.g. purchase order, goods receipt material document, SAP invoice
document (posted, registered invoice).

Process options for the current role

These are the buttons that will be configured per blocking reason per role.

Process log

A history log that gives an overview of all actions taken for this blocked work item. Amongst the log
information can be found:
 Activity
 Document status
 Actual role
 Actual agent
 Start time/date
 End time/date

8.2.2.3 PO Blocked – Header Level

During the blocked workflow the following dialog window is sent to the responsible user to solve the
header block.

45 | 148
Current processing role

For this type of workflow it will always be the AP Processor.

Blocked document info

References to related SAP objects, e.g. purchase order, goods receipt material document, SAP invoice
document (posted, registered invoice), …

Process options for the current role

Per blocked PO line (possibly 1 line with different blocking reasons) the responsible role is given handling
instructions by an authorizing role (e.g. Buyer, Receiver, …). The role can
 make a choice between the recommendations of the different authorizers for the handling of the
entire invoice
 send a line level task back to the authorizing role, indicating that the authorizer should review his
decision concerning the line item resolution.

46 | 148
 8.2.3 Detailed Description of the PO DP Exceptions

For each DP exception involved in the PO workflow the following topics are described:
 Reason why the exception is triggered.
 Involved roles with their process options, represented by a swimlane.

The process options assigned to the roles are mostly self-explanatory. Some process options are SAP IM
specific and therefore explained below:
 All referral buttons (e.g. Refer to AP Processor, Refer to Buyer, Refer for Information …)
With this option the processing agent can refer the work item to an agent within the same role
or from another role. As a result the work item disappears from the inbox of the originating
agent (the referrer) and it is delivered in the inbox of the destined agent (the referee). This
option is mainly used when the current agent disposes of too little information to further process
the work item. To use this option a comment is required prior to referring the work item.

 Apply Business Rules

The processing agent lets the system check the index data of the invoice against all the business
rules starting from the first one. This option is chosen after having changed one or more of the
index data fields in order to solve the current exception, possibly triggering a new exception in
the sequence of DP exceptions.
E.g.: If “Invalid Vendor” is triggered and the AP Processor provides the correct vendor ID in the
index data screen, executing user option ‘Apply Business Rules’ will no longer trigger the
exception “Invalid Vendor”.

 Return to Vendor
The processing agent can decide that the invoice is not to be posted due to errors. He or she can
thereby choose option ‘Return to Vendor’. As a result an e-mail template will be generated in
which the agent can still make amendments.

The invoice image can be included as attachment.

Remark: An attachment can be added at any point during the process of an invoice, during AP processing,
and during invoice approval, this attachment will be available during the whole process of the document
processing.

Once completed, the e-mail is sent to the vendor’s e-mail address known from the master data (see
below print screen). Once the e-mail has been sent out, the work item is set to obsolete and the
workflow ends.

47 | 148
Next to the process options, generic options can be defined. Each participant can have a combination of
following options:
 Change index: The agent can view and modify the recognized invoice index data. This will be
used in combination with process option ‘Apply Business Rules’ afterwards.
 Obsolete: The agent can end the process for the invoice and thus end the workflow, e.g. invalid
invoice. The status of the invoice will be set to ‘Obsolete’.
 Simulate: The agent can push this button to get an overview of all non-PO DP exceptions and an
indication whether or not the exceptions will be triggered based on the current index data. Non-
interactive exceptions executed in background are not listed in this overview.
 Bypass: The agent can bypass the current exception, thereby avoiding that the exception will be
triggered again. With this functionality the workflow can be continued, without solving the
exception. It is mandatory to provide a comment.

48 | 148
Below table gives an overview of the SAP IM roles involved in the PO DP exceptions.

Role Description Determination

AP Processor Accounts Payable personnel Key determination based on Company Code

Information Receiving role for option 'Refer for Information' Manually chosen by the user
Provider

Vendor Person(s) who is (are) responsible for Key determination based on Company Code
Maintenance maintaining (create/modify) the vendor master
data

Buyer Person(s) who is (are) responsible for creating Creator of the PO that is incomplete/incorrect;
and maintaining the purchase orders otherwise if the creator of the PO is the same as
the current referrer  predefined group of
buyers

Receiver Person(s) who is (are) responsible for receiving Role is determined in the following sequence:
goods • If there is a material defined on the first line of
the first PO in the PO list  key determination
based on plant and storage location;
• Else  creator of the purchase requisition (PR)
of the first line of the first PO;
• Else  Requisitioner defined on the first line of
the first PO in the PO list;
• Else  Buyer (= creator of the first PO in the
PO list)

Releaser Person(s) who is (are) responsible for releasing Function module (FM) to obtain the correct
the purchase orders Releaser based on the release strategy

Requisitioner Person(s) who is (are) responsible for approving Requisitioner found on the invoice;
the charges on the purchase order • Else  Requisitioner found on the PO line;
• Else  creator of the PO

49 | 148
8.2.3.1 DP902: Invalid Company Code

Exception trigger

This exception is triggered if there is no company code or an incorrect company code.

Trigger Explanation
No company This means that during the recognition phase the company code couldn’t be
code determined from the recipients list based on the company code details on the
invoice (see paragraph ‘7.3.2 Company Code’).
Possible cases
The company code details on the invoice are incorrect or incomplete.
The company code details on the invoice are not readable and thus it couldn’t be
recognized.

On top the validator did not populate the company code during the validation.
Possible cases
The validator couldn’t determine the company code based on the company code
details on the invoice.

Incorrect This means that the company code doesn’t exist in the SAP master data.
company code Possible cases
The validator manually added an incorrect company code during the validation.
(paper invoices or invoices received by e-mail)
An incorrect company code was provided. (EDI invoices)

Involved roles and options

DP902: Invalid Company Code
Initial Role Process options Change Obsolet Simulate Bypass
role index e
Apply Business Rules
AP Processor Refer to AP Processor
X X X X
(AP_PROCESSOR) Refer for Information
Return to Vendor
Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

50 | 148
8.2.3.2 DP102: Invalid Vendor for Company Code

Exception trigger

This exception is triggered if there is no vendor number, an incorrect vendor number or the vendor
number does not exist for the company code.
Trigger Explanation

No vendor This means that during the recognition phase the vendor number couldn’t be determined from
number the SAP master data based on the vendor details on the invoice (see paragraph ‘7.3.1 Vendor
Number’).
Possible cases
The vendor on the invoice is a new vendor or a one-time vendor.
The vendor details on the invoice are not readable and thus it couldn’t be recognized.
The vendor details in the SAP master data are incorrect.

On top the validator did not populate the vendor number during the validation.
Possible cases
The validator couldn’t determine the vendor number based on the vendor details on the
invoice.

Incorrect vendor This means that the vendor number doesn’t exist in the SAP master data.
number Possible cases
The validator manually added an incorrect vendor number during the validation. (paper
invoices or invoices received by e-mail)
An incorrect vendor number was provided. (EDI invoices)

Vendor number This means that the vendor number is not activated for the company code within the SAP master
doesn’t exist for data.
company code Possible cases
The wrong vendor was determined during the recognition phase. This vendor is not
activated for the company. The vendor on the invoice is active for the company code.
The wrong company code was determined during the recognition phase. This company
code is not activated for the vendor. The company code on the invoice is active for the
vendor.
The validator manually added a wrong vendor number during the validation. This
vendor is not activated for the company. The vendor on the invoice is active for the
company code. (paper invoices or invoices received by e-mail)
A wrong vendor number was provided. This vendor is not activated for the company.
The vendor on the invoice is active for the company code. (EDI invoices)
The validator manually added a wrong company code during the validation. This
company code is not activated for the vendor. The company code on the invoice is
active for the vendor. (paper invoices or invoices received by e-mail)
A wrong company code was provided. This company code is not activated for the
vendor. The company code on the invoice is active for the vendor. (EDI invoices)
The SAP master data is not correct. The vendor should be activated for the company
code.

51 | 148
 Vendor number This means that the vendor is blocked within the SAP master data.
is blocked Possible cases
The vendor is blocked for payment in the SAP master data.
The SAP master data isn’t correct. The vendor shouldn’t be blocked.
The wrong vendor was determined during the recognition phase. This vendor is blocked.
The vendor on the invoice isn’t blocked.
The validator manually added a wrong vendor number during the validation. This
vendor is blocked. The vendor on the invoice isn’t blocked. (paper invoices or invoices
received by e-mail)
A wrong vendor number was provided. This vendor is blocked. The vendor on the
invoice isn’t blocked. (EDI invoices)

Involved roles and options

DP102: Invalid Vendor for Company Code

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X
(PO_AP_PROC) Refer to Vendor Maintenance

Refer for Information

Create New Vendor (XK01)

Apply Business Rules

Vendor Maintenance
Refer to AP Processor
(VENDOR_MAINT)
Refer to Vendor Maintenance

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

52 | 148
8.2.3.3 DP125: Missing Invoice Date

Exception trigger

This exception is triggered if there is no invoice date.

Trigger Explanation

No invoice date This means that during the recognition phase the invoice date couldn’t be recognized (see
paragraph ‘7.3.4 Document Date’).
Possible cases
The document date is not mentioned on the invoice.
The document date on the invoice is not readable and thus it couldn’t be recognized.

On top the validator did not populate the document date during the validation.
Possible cases
The validator did not find the document date on the invoice.
The validator has entered an incorrect value or a document date out of range, but
incorrect values are cleared.

Involved roles and options

DP125: Missing Invoice Date

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X
(PO_AP_PROC) Refer for Information

Return to Vendor

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

53 | 148
8.2.3.4 DP133: Missing Vendor Invoice Reference

Exception trigger

This exception is triggered if there is no invoice reference.

Trigger Explanation

No invoice This means that during the recognition phase the reference number couldn’t be recognized (see
reference paragraph ‘7.3.3 Reference Number’).
Possible cases
The reference number is not mentioned on the invoice.
The reference number on the invoice is not readable and thus it couldn’t be recognized.

On top the validator did not populate the reference number during the validation.
Possible cases
The validator did not find the reference number on the invoice.

Involved roles and options

DP133: Missing Vendor Invoice Reference

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor
X Refer to AP Processor X X X
(PO_AP_PROC)
Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

54 | 148
8.2.3.5 DP105: Suspected Duplicate Invoice

Exception trigger

This exception is triggered if the invoice could be a duplicate of at least one existing invoice in the system.
The duplicate check includes all invoices processed through SAP IM as well as the invoices posted outside
SAP IM and even the invoice processed before SAP IM was introduced.

Trigger Explanation

Duplicate The duplicate check includes all invoices processed through SAP IM as well as the invoices posted
invoice outside SAP IM and even the invoice processed before SAP IM was introduced.
The duplicate check takes into account the following fields:
Vendor number
Vendor invoice reference
Gross amount

Second Check
- Vendor Invoice Reference
- Gross Amount
- Invoice Date

Possible cases
The invoice was sent for a second time by the vendor.
The invoice was scanned for a second time by the scan operator.
One or more double check fields were not correctly recognized during the recognition
phase. Coincidentally, this corresponds to one of the existing invoices.
The invoice is a new invoice, but by chance, the supplier has used the same reference
number and amount.

Involved roles and options

DP105: Suspected Duplicate Invoice

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Confirm Duplicate

Confirm Not Duplicate

AP Processor
X Apply Business Rules X X X
(PO_AP_PROC)
Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

55 | 148
56 | 148
8.2.3.6 DP954: Invalid Invoice Date

Exception trigger

This exception is triggered if the date identified in the invoice is outside of the validity range.
The validity range includes the last 12 months before the current system date, and up to 5 calendar days
after the current system date.

Trigger Explanation

Invalid Date This means that during the recognition phase the date that was recognized is outside of our valid
dates range.
Possible cases
The date format used in the invoice is different from the one used during recognition.
The invoice is very old.
The invoice was received with a future invoice date.

Involved roles and options

DP954: Invalid Invoice Date

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor
X Refer to AP Processor X X X X
(PO_AP_PROC)
Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

57 | 148
8.2.3.7 DP104: Invalid Currency

Exception trigger

This exception is triggered if there is no currency, or the currency entered is not valid. The OCR will
default the currency based on the region where the invoice was scanned, but if someone updates the
currency with a not valid value, this exception will be triggered.

Trigger Explanation

No currency This means that during the recognition phase the currency couldn’t be recognized (see paragraph
‘7.3.8 Currency’).
Possible cases
The currency is not mentioned on the invoice.
The currency on the invoice is not readable and thus it couldn’t be recognized.
The currency format is not known by the recognition system.

On top the validator did not populate the currency during the validation.
Possible cases
The validator did not find the currency on the invoice.
The validator has entered an incorrect currency, but incorrect values are cleared.

Involved roles and options

DP104: Invalid Currency

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor
X Refer to AP Processor X X X
(PO_AP_PROC)
Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

58 | 148
8.2.3.8 DP101: Invalid PO Number

Exception trigger

This exception is triggered if there is no PO number or an incorrect PO number.

Trigger Explanation

No PO number This means that during the recognition phase no PO number could be recognized from the invoice
based on the SAP PO master data (see paragraph ‘7.3.10 PO Number List’) and the vendor is not
flagged as a non-PO vendor.
Possible cases
The PO number(s) is (are) not mentioned on the invoice.
The PO number(s) on the invoice is (are) not readable and thus it couldn’t be
recognized.
The PO master data in the recognition system did not contain the PO number(s) from
the invoice.
The invoice was changed from document type non-PO to PO.
On top the validator did not populate the PO number during the validation.
Possible cases
The validator did not find the PO number(s) on the invoice.

Incorrect PO This means that the PO number doesn’t exist in the SAP master data.
number Possible cases
The validator entered manually an incorrect PO number during the validation. (paper
invoices or invoices received by e-mail)
An incorrect PO number was provided. (EDI invoices)

Involved roles and options

DP101: Invalid PO Number

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Change Doc Type

Apply Business Rules

AP Processor Refer to AP Processor

X X X X
(PO_AP_PROC) Refer to Buyer

Refer for Information

Return to Vendor

Buyer Create PO (ME21N) X

(PO_BUYER) Apply Business Rules

Refer to AP Processor

59 | 148
 Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

60 | 148
8.2.3.9 DP161: Company Code Mismatch

Exception trigger

This exception is triggered if there is a company mismatch between the invoice and one of the PO
numbers.

Trigger Explanation

Company code This means that one of the PO’s on the invoice is created for another company code than the
mismatch company code of the invoice.
Possible cases
The wrong company code was determined during the recognition phase. The PO
number(s) is (are) not created for this company code.
The wrong company code was mentioned on the invoice.
The PO number(s) on the invoice is (are) not correct.
The SAP master data is not correct. The PO number should be updated.

Involved roles and options

DP161: Company Code Mismatch

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Display PO (ME23N)

Change Doc Type

Apply Business Rules

AP Processor
X Return to Vendor X X X X
(PO_AP_PROC)
Refer to AP Processor

Refer to Buyer

Refer for Information

Display PO (ME23N)

Apply Business Rules

Buyer
Refer to AP Processor X
(PO_BUYER)
Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

61 | 148
8.2.3.10 DP155: Currency Mismatch

Exception trigger

This exception is triggered if there is a currency mismatch between the invoice and one of the PO
numbers.

Trigger Explanation

Currency This means that one of the PO’s on the invoice is created for another currency than the currency
mismatch of the invoice.
Possible cases
The wrong currency was recognized during the recognition phase. The PO number(s) is
(are) not created for this currency.
The recognized currency from the invoice is correct, but it is not the currency used on
the PO numbers.
The wrong currency was mentioned on the invoice.
The PO number(s) on the invoice is (are) not correct.
The SAP master data is not correct. The PO number should be updated.

Involved roles and options

DP155: Currency Mismatch

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Display PO (ME23N)

Apply Business Rules

AP Processor
X Refer to AP Processor X X X X
(PO_AP_PROC)
Refer to Buyer

Refer for Information

Change PO (ME22N)

Create PO (ME21N)

Buyer Apply Business Rules

X
(PO_BUYER) Refer to AP Processor

Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

62 | 148
8.2.3.11 DP153: Vendor Mismatch

Exception trigger

This exception is triggered if there is a vendor mismatch between the invoice and one of the PO numbers.

Trigger Explanation

Vendor This means that one of the PO’s on the invoice is created for another vendor than the vendor of
mismatch the invoice. The vendors from the PO considered in this exception are the invoicing party, the
vendor and the vendor mentioned on one of the condition records of the PO.
If the vendor of the invoice is the same as the vendor of the PO, but the invoicing party of the PO
is different this exception will be triggered as well.
Possible cases
The wrong vendor was determined during the recognition phase. The PO number(s) is
(are) not created for this vendor.
The recognized vendor from the invoice is correct, but it is not the vendor used on the
PO numbers; for example a transport invoice.
The PO number(s) on the invoice is (are) not correct.
The SAP master data is not correct. The PO number should be updated.

Involved roles and options

DP153: Vendor Mismatch

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Display PO (ME23N)

Change Doc Type

Apply Business Rules

AP Processor
X Return to Vendor X X X X
(PO_AP_PROC)
Refer to AP Processor

Refer to Buyer

Refer for Information

Change PO (ME22N)

Apply Business Rules

Buyer
Refer to AP Processor X
(PO_BUYER)
Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

63 | 148
64 | 148
8.2.3.12 DP940: PO Is Incomplete

Exception trigger

This exception is triggered if one of the PO numbers on the invoice is not complete.

Trigger Explanation

Not complete This means that the PO number does exist, but it could not be saved as complete due to missing
or incorrect information.
Possible cases
The PO number(s) on the invoice is (are) not correct.
The PO number is incomplete and should be updated.

Involved roles and options

DP940: PO Is Incomplete

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Change Doc Type

Apply Business Rules

AP Processor
Refer to AP Processor X X X
(PO_AP_PROC)
Refer to Buyer

Refer for Information

Change PO (ME22N)

Apply Business Rules

Buyer
X Refer to AP Processor X
(PO_BUYER)
Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

65 | 148
8.2.3.13 DP106: PO not Released

Exception trigger

This exception is triggered if one of the PO numbers on the invoice is not released.

Trigger Explanation

Not released This means that the PO number is not yet released but the PO number was already sent to the
vendor.
Possible cases
The PO number(s) on the invoice is (are) not correct.
The PO number is not released and should be released.

Involved roles and options

DP106: PO not Released

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Change Doc Type

Apply Business Rules

AP Processor
Refer to AP Processor X X X
(PO_AP_PROC)
Refer to Releaser

Refer for Information

Release PO (ME29N)

Buyer Apply Business Rules

X
PO_BUYER) Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

Assumption

The release strategy applies to purchase order (PO) level and not to purchase requisition (PR) level.

66 | 148
8.2.3.14 DP918: Invalid Banking Information

Exception trigger

This exception is triggered if there is more than a single partner bank type for the Vendor and the
currency defined. If there is only one Partner Bank Type, this exception will not be triggered and the
banking information will be defaulted to the only value in the Vendor Master.

Trigger Explanation

Non Unique This means that during the processing of the invoice, there is more than one single Partner bank
Partner Bank type for this vendor, for the specific currency received. This will not be triggered if there’s only
one Partner Bank Type defined, even if it does not start with the currency information, the bank
Type
information will be defaulted to this single value.
Information
Possible cases
Multiple Partner Bank Types for the same currency.
Multiple Partner Bank Types, and none of them for the currency of the document.
No Partner Bank Type information in the Vendor Master

Involved roles and options

DP918: Invalid Banking Information

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X
(PO_AP_PROC) Refer to Vendor Maintenance

Refer for Information

Change Vendor Master (XK02)

Apply Business Rules

Vendor Maintenance
Refer to AP Processor
(VENDOR_MAINT)
Refer to Vendor Maintenance

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

67 | 148
8.2.3.15 DP160: PO Credit Memo Processing

Exception trigger

This exception is triggered if the ‘Credit Memo’ checkbox is flagged.

Trigger Explanation

Credit memo This means that during the recognition phase one of the keywords for credit memo were found
on the invoice. This exception gives the possibility to the AP Processor to post the credit memo
manually.
Possible cases
The invoice contains one of the keywords for a credit memo and it is a credit memo.
The invoice contains one of the keywords for a credit memo, but is not a credit memo.

Involved roles and options

DP160: PO Credit Memo Processing

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Post Invoice (MIRO)

X X X X X
(PO_AP_PROC) Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

Remark

The exception is triggered to enable the AP Processor to select the correct type of PO credit memo: a
Credit Memo or a Subsequent Credit Memo (see ‘Basic Data’ tab of the DP dashboard).

68 | 148
8.2.3.16 DP110: Manual Check Needed for Indexing Lines

Exception trigger

This is a non-interactive check (no interaction from an agent is required) to derive or complete the PO
lines items automatically. The behavior of the check depends on the type of incoming invoice:

1. without line items (indexing lines)

The system will request SAP for a proposal of all the invoice-able PO lines of all PO numbers delivered
on header level. If invoice-able lines are found, the invoice - including the retrieved line item data -
will be evaluated against the subsequent business rules. Situations in which no invoice-able line could
be found are:
 ‘GR-based invoice verification’ flag is checked for a PO line and the goods receipt for that line has
not been carried out yet.
 The PO of which lines have to be retrieved is getting processed at the exact moment on which
the system tries to retrieve those PO lines.

2. with line items (indexing lines)

The system will try to complete the recognized invoice lines. An invoice line is considered to be
incomplete if at least one mandatory, expected field is empty. The mandatory line item fields are:
 For PO lines without the ‘GR-IV based’ flag checked:
- PO number
- PO item number
- Quantity
- Amount
- Unit of measurement (UOM)

 For PO lines with the ‘GR-IV based’ flag checked:

- PO number
- PO item number
- Delivery note/GR reference document
- Quantity
- Amount
- Unit of measurement (UOM)
- Net price

If incomplete lines are detected, the system will try to complete them using the available mandatory
fields in combination with the MIRO proposal of all invoice-able PO lines, which is based on the PO
numbers at header level.

69 | 148
8.2.3.17 DP951: Price Discrepancy

Exception trigger

This exception is triggered if there’s a price discrepancy between the PO and the invoice.

Trigger Explanation

Price This means that the price per unit in the PO and the price per unit invoiced does not match
Discrepancy beyond the tolerance defined.
Possible cases
The PO number(s) on the invoice is (are) not correct.
Price was changed but not updated in the PO/Contract.
Price is wrong in the invoice.

Involved roles and options

DP951: Price Discrepancy

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Display PO (ME23N)

Apply Business Rules

Wait for Credit Note (Change

to Wait status for 4 days)
AP Processor
X X X
(PO_AP_PROC) Refer to AP Processor

Refer to Buyer

Refer to Receiver

Refer for Information

Create PO (ME21N)

Change PO (ME22N)

Apply Business Rules

Buyer
X Refer to AP Processor X
(PO_BUYER)
Refer to Buyer

Refer to Receiver

Refer for Information

Receiver Post GR (MIGO)

(RECEIVER) Reverse GR (MIGO)

Create Inbound Delivery

70 | 148
 (VL31N)

Refer to AP Processor

Refer to Buyer

Refer to Receiver

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

71 | 148
8.2.3.18 DP163: GR not Done

Exception trigger

This exception is triggered if the goods receipt is not done.

Trigger Explanation

No goods receipt This means that no goods receipt is performed for one of the line items which have the ‘GR-based
IV’ flag enabled. If the ‘GR-based IV’ flag is disabled, the exception will not be triggered.
A buffer of 4 days for both Canada and US before the user is notified with the exception.
Possible cases
The PO number(s) on the invoice is (are) not correct.
The goods of the PO number are not yet received.
The goods of the PO number are already received, but it is not yet registered in SAP.

Involved roles and options

DP163: GR not Done

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Display PO (ME23N)

Apply Business Rules

AP Processor Refer to AP Processor

X X X
(PO_AP_PROC) Refer to Buyer

Refer to Receiver

Refer for Information

Create PO (ME21N)

Change PO (ME22N)

Apply Business Rules

Buyer
Refer to AP Processor X
(PO_BUYER)
Refer to Buyer

Refer to Receiver

Refer for Information

X Receiver Post GR (MIGO)

(RECEIVER) Reverse GR (MIGO)

72 | 148
 Create Inbound Delivery
(VL31N)

Apply Business Rules

Refer to AP Processor

Refer to Buyer

Refer to Receiver

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

Remark

The exception is not triggered if:

The ‘GR-based IV’ flag for the PO line is not checked or if an initial Reception has already been done, this
exception will not be triggered, instead exception “DP952: Quantity Discrepancy” will be triggered.

*Remark – Some of the people that receives the GR Not Done Exception, should not have access to the
invoice image, we will work with the business to achieve this functionality, they will have access to
everything else, but not the invoice image. We will work together with the business to define the
scenarios where this should be limited.

73 | 148
8.2.3.19 DP951: Quantity Discrepancy

Exception trigger

This exception is triggered if there’s a quantity difference between the PO and the invoice.

Trigger Explanation

Quantity This means that the quantity receipt and the quantity invoiced does not match.
Discrepancy Possible cases
The PO number(s) on the invoice is (are) not correct.
There’s a partial reception, but we are missing an additional reception.
The goods of the PO number are already received, but it is not yet registered in SAP.

Involved roles and options

DP952: Quantity Discrepancy

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Display PO (ME23N)

Apply Business Rules

Wait for Credit Note (Change

to Wait status for 4 days)
AP Processor
X X X
(PO_AP_PROC) Refer to AP Processor

Refer to Buyer

Refer to Receiver

Refer for Information

Create PO (ME21N)

Change PO (ME22N)

Apply Business Rules

Buyer
Refer to AP Processor X
(PO_BUYER)
Refer to Buyer

Refer to Receiver

Refer for Information

X Receiver Post GR (MIGO)

(RECEIVER) Reverse GR (MIGO)

Create Inbound Delivery

74 | 148
 (VL31N)

Apply Business Rules

Refer to AP Processor

Refer to Buyer

Refer to Receiver

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

75 | 148
8.2.3.20 DP912: Alternative Payee

Exception trigger

This exception is triggered if an alternative payee can be specified manually for the vendor.

Trigger Explanation

Alternative This means that within the SAP master data from the vendor:
payee Other vendor numbers are defined which can be used as alternative payee (see Figure
5: Permitted Payee).
The option is enable that another address or bank details can be specified for this
vendor (see Figure 6: Individual alternative payee).

Possible cases
The vendor from the invoice is specified with possible alternative payees.
The wrong vendor is determined during the recognition phase. This vendor is specified
with possible alternative payees. The vendor from the invoice is not specified with
possible alternative payees.
The SAP master data is not correct. The vendor shouldn’t be specified with possible
alternative payees.

Figure 1: Permitted Payee

76 | 148
Figure 2: Individual alternative payee

Involved roles and options

DP912: Alternative Payee

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Post Invoice (MIRO)

X X X X X
(PO_AP_PROC) Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

77 | 148
8.2.3.21 DP910: Withholding Tax

Exception trigger

This exception is triggered if the vendor is subjected to withholding tax.

Please ensure that our 1099 reporting vendors who have W.Tax Codes such as 01 Rents, 02 Royalties, 03
Other Income and 07 Nonemployee compensation just to name a few don’t all set flagged with this
exception.

We are currently building a 1042S process for withholding tax on vendors who don’t reside in the U.S., so
this exception trigger sounds like it will be valid for them once we incorporate it into our processes.

Trigger Explanation

Withholding tax This means that within the SAP master data from the vendor:
The vendor has a ‘Withholding Tax Code’3 (see Figure 7: Withholding tax).
Extended withholding tax is defined (see Figure 8: Extended withholding tax).

Possible cases
The vendor from the invoice is subjected to withholding tax.
The wrong vendor was determined during the recognition phase. This vendor is
subjected to withholding tax. The vendor from the invoice is not subjected to
withholding tax.
The SAP master data is not correct. The vendor shouldn’t be subjected to withholding
tax.

Figure 3: Withholding tax

3
The withholding tax code can be compared to a tax sub-category which must be taken into consideration when reporting tax to
the tax authorities.

78 | 148
Figure 4: Extended withholding tax

Involved roles and options

DP910: Withholding Tax

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Post Invoice (MIRO)

X X X X X
(PO_AP_PROC) Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

79 | 148
80 | 148
81 | 148
DP957: Balance Not Zero
Exception trigger
This exception is triggered when there’s a pending balance between the gross amount at header level
and the sum of the line items.

Trigger Explanation
Balance Not This means that there’s a pending balance between the gross amount at header level and the
Zero sum of all items
Possible cases
There are no open items for invoicing.
The invoice does not include all the open items for invoicing.

Involved roles and options

DP957: Balance Not Zero
Initial Role Process options Change Obsolet Simulate Bypass
role index e
Apply Business Rules
AP Processor Refer to AP Processor
X X X X X
(PO_AP_PROC) Refer to Buyer
Refer for Information
Apply Business Rules
Buyer Refer to AP Processor
(BUYER) Refer to Buyer
Refer for Information
Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

82 | 148
[8.2.3.22] DP953: Tax Validation Required

Exception trigger

This exception is triggered if there’s an issue with the taxes determined.

Trigger Explanation

Tax Validation This means that, for the US, there’s an inconsistency between the tax amount identified in the
Required invoice and the Tax Code included in the PO. For Canada, It means that the tax could not be
determined and someone needs to manually validate the tax code.
Possible cases
Tax amount higher than 0 on the invoice, with Non Taxable Tax code on the PO/Invoice.
Tax amount equal to 0 on the invoice, with Taxable Tax code on the PO/Invoice.
The tax could not be determined correctly.

Involved roles and options

DP953: Tax Validation Required

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X X
(PO_AP_PROC) Refer to Buyer

Refer for Information

Apply Business Rules

Buyer Refer to AP Processor

(BUYER) Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

83 | 148
[8.2.3.23] DP955: Vendor Audit Required

Exception trigger

This exception is triggered if the vendor in the invoice has to be audited

Trigger Explanation

Vendor Audit This means that the vendor in the invoice has been selected for audit purposes.
Required Possible cases
Vendor has been added to the Vendor Audit list

Involved roles and options

DP955: Vendor Audit Required

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X X
(PO_AP_PROC) Refer to Buyer

Refer for Information

Apply Business Rules

Buyer Refer to AP Processor

(BUYER) Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

84 | 148
8.2.3.22[8.2.3.24] DP956: Tax Audit Required

Exception trigger

This exception is triggered if the tax information in the invoice has to be audited

Trigger Explanation

Tax Audit This means that the vendor, company code, material group in the invoice has been selected for
Required audit purposes.
Possible cases
Tax Information in the invoice has been added to the Tax Audit list

Involved roles and options

DP956: Tax Audit Required

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X X
(PO_AP_PROC) Refer to Buyer

Refer for Information

Apply Business Rules

Buyer Refer to AP Processor

(BUYER) Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

85 | 148
8.2.3.23[8.2.3.25] DP958: Address Validation for Check Vendor

Exception trigger

This exception is triggered if there are no invoices posted to this vendor, the vendor does not have a
remit to, and the payment method is check

Trigger Explanation

Address This exception is triggered if there are no invoices posted to this vendor, the vendor does not
Validation for have a remit to, and the payment method is check
Check Vendor

Involved roles and options

DP958: Address Validation for Check Vendor

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X X
(PO_AP_PROC) Refer to Buyer

Refer for Information

Apply Business Rules

Buyer Refer to AP Processor

(BUYER) Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

86 | 148
8.2.3.24[8.2.3.26] DP108: Process PO Invoice

Exception trigger

This exception is triggered if the invoice couldn’t be automatically posted.

Trigger Explanation

No auto-posting This means that all the preceding DP exceptions (including the approval flow) were validated
successfully. SAP IM tried to automatically post the invoice, but the system did not succeed. This
exception gives the possibility to the AP Processor role to post the invoice manually in MIRO.
Possible cases
An error message was given by the SAP system that the invoice couldn’t be posted; for
example: posting period is closed.

Involved roles and options

DP108: Process PO Invoice

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

Submit for Approval

Post Invoice (MIRO)

AP Processor
X Refer to AP Processor X X X
(PO_AP_PROC)
Refer to Buyer

Refer to Receiver

Refer for Information

Create PO (ME21N)

Change PO (ME22N)

Buyer Refer to AP Processor

(PO_BUYER) Refer to Buyer

Refer to Receiver

Refer for Information

87 | 148
 Post GR (MIGO)

Reverse GR (MIGO)

Create Inbound Delivery

(VL31N)
Receiver
(RECEIVER) Refer to AP Processor

Refer to Buyer

Refer to Receiver

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

8.2.3.25[8.2.3.27]

88 | 148
 8.2.4 Detailed Description of the PO Header Workflow

Exception trigger

This workflow is triggered if for the invoice all the blocked line work items are executed and solved and at
least one of them was an authorization. This workflow will be disabled for EDF as Blocked invoices are not
in use right now.

Involved roles and options

Header Workflow

Initial Role Possible options depending on # of

role blocked lines and authorizations

Wait for Credit Note Send Back to Authorizer

AP Processor Pay as Invoiced Send Back to Authorizer

X
(AP_PROCESSOR) Cancel and Re-enter as PO Invoice Send Back to Authorizer

Cancel and Re-enter as Non-PO Invoice Send Back to Authorizer

Remark

Once the AP Processor has sent the mail using the option Wait for Credit Note, a check flag will be added
to the work item line in the inbox of the AP Processor, as shown in below picture.

89 | 148
90 | 148
8.3 Non-PO Flow

8.3.1 Process Overview

VIM includes 2 workflows for the Non-PO Flow: the Document Processing Flow for all the exceptions that
are situated before the posting in SAP and on top of this workflow we have the Approval workflow. Both
workflows are situated before the documents are posted in SAP.

The Document Type Determination rules decide that the non-PO workflow needs to be triggered and as a
result the related document processing (DP) workflow is started. Within the DP workflow the following
exceptions are validated:

Sequence DP Exception Background

step

1 DP209 Determine Expense Type Yes

2 DP205 Invalid Company Code No

3 DP201 Invalid Vendor for Company Code No

4 DP223 Missing Invoice Date No

5 DP233 Missing Vendor Invoice Reference No

6 DP204 Suspected Duplicate Invoice No

7 DP965 Invalid Invoice Date No

8 DP202 Invalid Currency No

9 DP920 Auto-code Accounting Information Yes

10 DP250 Approval Required No

11 DP919 Invalid Banking Information No

91 | 148
 12 DP913 Alternative Payee No

13 DP911 Withholding Tax No

14 DP921 Account Information Changed During Approval No

15 DP961 Tax Validation Required No

16 DP962 Vendor Audit Required No

17 DP963 Tax Audit Required No

18 DP964 Address Validation for Check Vendor No

19 DP207 Process Non-PO Invoice No

Each of these checks/exceptions will be explained in detail in a next chapter. Important to keep in mind is
that during the document processing workflow the invoice is not yet posted in SAP. The system will try to
post the invoice at the end, in case all DP exceptions were validated successfully.

An essential part of the workflow for non-PO invoices, as opposed to the workflow for PO invoices,
comprises the approval process. This separate workflow will be initiated from the DP exception “DP250:
Approval Required”.

If the invoice is completely approved by the required approvers it comes back in the DP workflow to
validate the remaining exceptions. If all DP exceptions are validated successfully the invoice is ready to be
posted. All the invoice metadata is used to post the invoice automatically in background, using the
standard transaction FB60. For certain invoices auto-posting may not be desired and therefore it can be
disabled by company code.

92 | 148
 8.3.2 Non-PO Workflow Dashboards

Below an overview of the different workflow dashboards that a user can consult to process the invoices
within the SAP GUI via the Integrated Invoice Cockpit or the VIM Workplace.

Each tab is explained in detail together with the fields represented on the tab in the “Appendix 1:
Document Processing and Approval Workflow Dashboards”.

8.3.2.1 DP Work Item Screen

During the DP workflow the following dialog window is sent to the responsible user to solve the DP
exception.

The DP work item contains three major parts: the process options, the indexing screens and the detail
pane.

Process options for the current role

These are the buttons that will be configured per combination DP exception and processing role.

Indexing information
The indexing information contains 5 tabs representing the invoice data that was recognized from the
invoice or entered/updated during the SAP IM workflow.

93 | 148
Each tab is explained in detail together with the fields represented on the tab in the “Appendix 1:
Document Processing and Approval Workflow Dashboards”.

Basic Data
This screen shows the current DP exception and the document type, along with some basic header
information which was recognized from the invoice. The invoice data was initially populated from the
recognition application and possibly changed afterwards, as a result of actions taken during the SAP IM
workflow to resolve the exceptions.

Line Items
This screen represents the accounting information for the non-PO invoice. The accounting information
can be entered on different ways:
Automatically by the system, in case the structure for the accounting lines is populated in the ‘auto-
coding configuration’ table (see exception “DP920: Auto-code Accounting Information”) for the vendor.
Manually by the accounts payable.
Uploaded by the accounts payable via a predefined file.

94 | 148
Accounting
This screen shows more accounting related data coming from the invoice, the SAP master data or added
manually.

Tax
This screen shows the tax related fields for the invoice.

If the Vendor is Withholding Tax applicable following subsections in the Tax tab become visible:

Process
This screen shows relevant process information, like the document type and the barcode. Also the
suspected duplicate invoices are listed on this screen.

95 | 148
 In the part ‘Duplicate Index Records’ the system lists the invoices with which it suspects that this
invoice is a duplicate. It provides an overview of all invoices (e.g. document ID 197) that needs to be
taken into account by the AP Processor to decide whether the newly received invoice (e.g. document ID
213) is a duplicate or not.

Detail pane
Display invoice image

Display process/approval history log: Overview of all actions taken for this work item (comments, activity,
process type, document status, ...).

96 | 148
Display comments log: Overview of all comments provided while processing documents.

8.3.2.2 Approval Work Item Screen

During the Approval workflow the following dialog window is sent to the responsible approver to consult
or modify the accounting information and approve/reject the invoice. The below example is a screenshot
of the approval dashboard within the SAP GUI.

97 | 148
 8.3.3 Detailed Description of the Non-PO DP Exceptions

For each DP exception involved in the non-PO workflow the following topics are described:
 Reason why the exception is triggered.
 Involved roles with their process options, represented by a swimlane.

98 | 148
The process options assigned to the roles are mostly self-explanatory. Some process options are SAP IM
specific and therefore explained below:
 All referral buttons (e.g. Refer to AP Processor, Refer to Buyer, Refer for Information, …)
With this option the processing agent can refer the work item to an agent within the same role
or from another role. As a result the work item disappears from the inbox of the originating
agent (the referrer) and it is delivered in the inbox of the destined agent (the referee). This
option is mainly used when the current agent disposes of too little information to further process
the work item. To use this option a comment is required prior to referring the work item.

 Apply Business Rules

The processing agent lets the system check the index data of the invoice against all the business
rules starting from the first one. This option is chosen after having changed one or more of the
index data fields in order to solve the current exception, possibly triggering a new exception in
the sequence of DP exceptions.
E.g.: If “Invalid Vendor” is triggered and the AP Processor provides the correct vendor ID in the
index data screen, executing user option ‘Apply Business Rules’ will no longer trigger the
exception “Invalid Vendor”.

 Return to Vendor
The processing agent can decide that the invoice is not to be posted due to errors. He or she can
thereby choose option ‘Return to Vendor’. As a result an e-mail template will be generated in
which the agent can still make amendments.

The e-mail template is based on (1) DP exception and (2) language in the vendor master data.
The invoice image can be included as attachment.

Once completed, the e-mail is sent to the vendor’s e-mail address known from the master data.
Once the e-mail has been sent out, the work item is set to obsolete and the workflow ends.

99 | 148
Next to the process options, generic options can be defined. Each participant can have a combination of
following options:
 Change index: The agent can view and modify the recognized invoice index data. This will be
used in combination with process option ‘Apply Business Rules’ afterwards.
 Obsolete: The agent can end the process for the invoice and thus end the workflow, e.g. invalid
invoice. The status of the invoice will be set to ‘Obsolete’.
 Simulate: The agent can push this button to get an overview of all non-PO DP exceptions and an
indication whether or not the exceptions will be triggered based on the current index data. Non-
interactive exceptions executed in background are not listed in this overview.
 Bypass: The agent can bypass the current exception, thereby avoiding that the exception will be
triggered again. With this functionality the workflow can be continued, without solving the
exception. It is mandatory to provide a comment.

100 | 148
Below table gives an overview of the SAP IM roles involved in the non-PO exceptions.

Role Description Determination

AP Processor Accounts Payable personnel Key determination based on Company Code

Information Receiving role for option 'Refer for Information' Manually chosen by the user
Provider

Vendor Person(s) who is (are) responsible for Key determination based on Company Code
Maintenance maintaining (create/modify) the vendor master
data

Requester First approver of a non-PO invoice: enter Determined based on the requester’s e-mail
accounting information and approve cost found on the invoice  in case no e-mail was
allocations found on the invoice, the AP processor can
manually choose the requester when starting the
approval workflow

Approver Subsequent approver of a non-PO invoice: Determined based on the setup and
approve cost allocations interpretation of the data in the COA

101 | 148
[8.3.3.1] DP209: Determine Expense Type
This is a non-interactive check (no interaction from an agent is required) that will determine the expense
type applicable for a non-PO invoice. An ‘expense type’ is a concept of SAP IM and it will decide whether
a non-PO invoice has to be sent through the approval flow or not.

The following expense types exist and are assigned in this check:
 ‘PA’ (Pre-approved): Invoices with this expense type are not subject to approval.

There are two ways to indicate a vendor as being ‘pre-approved’, the one that will be used for EDF is
the first one, the table ZTSIM_NPO_VEND:
 Via table ZTSIM_NPO_VEND: If for the combination company code and vendor the
column ‘PA’ holds an ‘X’, the invoice is pre-approved. If the vendor is not defined in
the table, or if the column ‘PA’ is blank, the invoice is considered not to be pre-
approved. This table is defined by company code and Vendor, It is a unique table for
Canada and US.

Table ZTSIM_NPO_VEND looks like:

Company code Vendor Vendor FI PA FI Only
Account
Number

* 1000006 X X

4000 * X

3000 1000005 X

 Via vendor classification: An additional classification field ‘PA vendor’ has to be

defined in the vendor master data. If the value is set to ‘Yes’, the invoice of this
vendor will be considered as a pre-approved invoice. If the value is set to ‘No’, no
classification is applicable and the invoice needs an approval.

Both options have advantages and disadvantages:

Advantage Disadvantage

Table It provides an overview of all Besides the Vendor Master

ZTSIM_NPO_VEND ‘PA’ vendors data, this table will also
need to be maintained.

 ‘ST’ (Standard): Invoices with this expense type are subject to approval.

If expense type ‘PA’ is not assigned, unconditionally the expense will be set to ‘ST’. This type is
defined so that the corresponding documents are subject to approval and hence the approval
flow (see paragraph ‘8.3.4 Detailed Description of the Non-PO Approval Workflow’) will be
initiated.

102 | 148
103 | 148
[8.3.3.2] DP205: Invalid Company Code

Exception trigger

This exception is triggered if there is no company code or an incorrect company code.

Trigger Explanation

No company This means that during the recognition phase the company code couldn’t be determined from the
code recipients list based on the company code details on the invoice (see paragraph ‘7.3.2 Company
Code’).
Possible cases
The company code details on the invoice are incorrect or incomplete.
The company code details on the invoice are not readable and thus it couldn’t be
recognized.

On top the validator did not populate the company code during the validation.
Possible cases
The validator couldn’t determine the company code based on the company code details
on the invoice.

Incorrect This means that the company code doesn’t exist in the SAP master data.
company code Possible cases
The validator manually added an incorrect company code during the validation. (paper
invoices or invoices received by e-mail)
An incorrect company code was provided. (EDI invoices)

Involved roles and options

DP205: Invalid Company Code

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X
(AP_PROCESSOR) Refer for Information

Return to Vendor

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

104 | 148
8.3.3.1[8.3.3.3] DP201: Invalid Vendor for Company Code

Exception trigger

This exception is triggered if there is no vendor number, an incorrect vendor number or the vendor
number does not exist for the company code.

Trigger Explanation

No vendor This means that during the recognition phase the vendor number couldn’t be determined from
number the SAP master data based on the vendor details on the invoice (see paragraph ‘7.3.1 Vendor
Number’).
Possible cases
The vendor on the invoice is a new vendor or a one-time vendor.
The vendor details on the invoice are not readable and thus it couldn’t be recognized.
The vendor details in the SAP master data are incorrect.
On top the validator did not populate the vendor number during the validation.
Possible cases
The validator couldn’t determine the vendor number based on the vendor details on the
invoice.

Incorrect vendor This means that the vendor number doesn’t exist in the SAP master data.
number Possible cases
The validator manually added an incorrect vendor number during the validation. (paper
invoices or invoices received by e-mail)
An incorrect vendor number was provided. (EDI invoices)

Vendor number This means that the vendor number is not activated for the company code within the SAP master
doesn’t exist for data.
company code Possible cases
The wrong vendor was determined during the recognition phase. This vendor is not
activated for the company. The vendor on the invoice is active for the company code.
The wrong company code was determined during the recognition phase. This company
code is not activated for the vendor. The company code on the invoice is active for the
vendor.
The validator manually added a wrong vendor number during the validation. This
vendor is not activated for the company. The vendor on the invoice is active for the
company code. (paper invoices or invoices received by e-mail)
A wrong vendor number was provided. This vendor is not activated for the company.
The vendor on the invoice is active for the company code. (EDI invoices)
The validator manually added a wrong company code during the validation. This
company code is not activated for the vendor. The company code on the invoice is
active for the vendor. (paper invoices or invoices received by e-mail)
A wrong company code was provided. This company code is not activated for the
vendor. The company code on the invoice is active for the vendor. (EDI invoices)
The SAP master data is not correct. The vendor should be activated for the company
code.

105 | 148
 Vendor number This means that the vendor is blocked within the SAP master data.
is blocked Possible cases
The vendor is blocked for payment in the SAP master data.
The SAP master data isn’t correct. The vendor shouldn’t be blocked.
The wrong vendor was determined during the recognition phase. This vendor is blocked.
The vendor on the invoice isn’t blocked.
The validator manually added a wrong vendor number during the validation. This
vendor is blocked. The vendor on the invoice isn’t blocked. (paper invoices or invoices
received by e-mail)
A wrong vendor number was provided. This vendor is blocked. The vendor on the
invoice isn’t blocked. (EDI invoices)

Involved roles and options

DP201: Invalid Vendor for Company Code

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X
(NPO_AP_PROC) Refer to Vendor Maintenance

Refer for Information

Create New Vendor (XK01)

Apply Business Rules

Vendor Maintenance
Refer to AP Processor
(VENDOR_MAINT)
Refer to Vendor Maintenance

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

106 | 148
8.3.3.2[8.3.3.4] DP223: Missing Invoice Date

Exception trigger

This exception is triggered if there is no invoice date.

Trigger Explanation

No invoice date This means that during the recognition phase the invoice date couldn’t be recognized (see
paragraph ‘7.3.4 Document Date’).
Possible cases
The document date is not mentioned on the invoice.
The document date on the invoice is not readable and thus it couldn’t be recognized.

On top the validator did not populate the document date during the validation.
Possible cases
The validator did not find the document date on the invoice.
The validator has entered an incorrect value or a document date out of range, but
incorrect values are cleared.

Involved roles and options

DP223: Missing Invoice Date

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X
(NPO_AP_PROC) Refer for Information

Return to Vendor

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

107 | 148
8.3.3.3[8.3.3.5] DP233: Missing Vendor Invoice Reference

Exception trigger

This exception is triggered if there is no invoice reference.

Trigger Explanation

No invoice This means that during the recognition phase the reference number couldn’t be recognized (see
reference paragraph ‘7.3.3 Reference Number’).
Possible cases
The reference number is not mentioned on the invoice.
The reference number on the invoice is not readable and thus it couldn’t be recognized.

On top the validator did not populate the reference number during the validation.
Possible cases
The validator did not find the reference number on the invoice.

Involved roles and options

DP233: Missing Vendor Invoice Reference

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor
X Refer to AP Processor X X X
(NPO_AP_PROC)
Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

108 | 148
8.3.3.4[8.3.3.6] DP204: Suspected Duplicate Invoice

Exception trigger

This exception is triggered if the invoice could be a duplicate of at least one existing invoice in the system.

Trigger Explanation

Duplicate The duplicate check includes all invoices processed through SAP IM as well as the invoices posted
invoice outside SAP IM and even the invoice processed before SAP IM was introduced.
The duplicate check takes into account the following fields:
Vendor number
Vendor invoice reference
Gross amount

Possible cases
The invoice was sent for a second time by the vendor.
The invoice was scanned for a second time by the scan operator.
One or more double check fields were not correctly recognized during the recognition
phase. Coincidentally, this corresponds to one of the existing invoices.
The invoice is a new invoice, but by chance, the supplier has used the same reference
number and amount.

Involved roles and options

DP204: Suspected Duplicate Invoice

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Confirm Duplicate

Confirm Not Duplicate

AP Processor
X Apply Business Rules X X X
(NPO_AP_PROC)
Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

109 | 148
8.3.3.5[8.3.3.7] DP965: Invalid Invoice Date

Exception trigger

This exception is triggered if the date identified in the invoice is outside of the validity range.
The validity range includes the last 12 months before the current system date, and up to 5 calendar days
after the current system date.

Trigger Explanation

Invalid Date This means that during the recognition phase the date that was recognized is outside of our valid
dates range.
Possible cases
The date format used in the invoice is different from the one used during recognition.
The invoice is very old.
The invoice was received with a future invoice date.

Involved roles and options

DP965: Invalid Invoice Date

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor
X Refer to AP Processor X X X X
(PO_AP_PROC)
Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

110 | 148
8.3.3.6[8.3.3.8] DP202: Invalid Currency

Exception trigger

This exception is triggered if there is no currency, or the currency entered is not valid. The OCR will
default the currency based on the region where the invoice was scanned, but if someone updates the
currency with a not valid value, this exception will be triggered.

Trigger Explanation

No currency This means that during the recognition phase the currency couldn’t be recognized (see paragraph
‘7.3.8 Currency’).
Possible cases
The currency is not mentioned on the invoice.
The currency on the invoice is not readable and thus it couldn’t be recognized.
The currency format is not known by the recognition system.

On top the validator did not populate the currency during the validation.
Possible cases
The validator did not find the currency on the invoice.
The validator has entered an incorrect currency, but incorrect values are cleared.

Involved roles and options

DP202: Invalid Currency

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor
X Refer to AP Processor X X X
(NPO_AP_PROC)
Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

111 | 148
8.3.3.7[8.3.3.9] DP920: Auto-code Accounting Information
This is a non-interactive check (no interaction from an agent is required) to pre-populate the accounting
information (G/L account, cost center, order, and WBS element, )andor profit center) on the line item
screen for non-PO invoices. To activate the auto-coding configuration you need to configure the
corresponding ranges and data. In the auto-coding a tax determination logic will be added.

Ranges

Auto-coding will only apply if for the combination company code and vendor a value was found in the
‘auto-coding configuration’ table. Open transaction ‘/OPT/SPRO’ and navigate to path ‘Vendor Invoice
Management > Document Processing Configuration > General Configuration > Automated Line Processing
> NPO Line Auto Coding > Auto Coding Determination – Data’ to maintain this table.

Company to Company Vendor to Vendor Vendor to Vendor Skip

code code Account Account stac
k

* - 1000006 - 1000006 - C

4000 - 4000 * - - C

3000 - 3000 1000005 - 1000005 - C

You can use the ‘Skip Stack’ indicator to automatically skip the coding or requester step when the
approval is triggered. The following values are possible:
 C = Skip the coding step (most common setting).
 R = Skip the coding step and the requester step.
 S = Skip the requester step. However, in case of rejection, the document is still sent to the
requester in the approval process.

Data

Maintain the detail configuration to define the accounting information that needs to be auto-coded.

G/L Cost center Order WBS element Profit Tax Code Tax
account Center Jurisdiction

400000 1000

112 | 148
8.3.3.8[8.3.3.10] DP250: Approval Required
Approval process will be initiated automatically.

8.3.3.9[8.3.3.11] DP919: Invalid Banking Information

Exception trigger

This exception is triggered if there is no banking information in contrast to the SAP vendor master data or
incorrect banking information compared to the SAP vendor master data.

Trigger Explanation

No banking This means that during the recognition phase no bank account number and no IBAN number from
information in the recognized vendor was recognized from the invoice (see paragraph ‘Error: Reference source
not found Error: Reference source not found’ & ‘Error: Reference source not found Error:
contrast to the
Reference source not found’) and multiple entries are available in the vendor master data.
SAP vendor
master data
Possible cases
The bank account number and the IBAN number are not mentioned on the invoice.
The bank account number and the IBAN number on the invoice are incorrect or
incomplete.
The bank account number and the IBAN number on the invoice are not readable and
thus it couldn’t be recognized.
The recognized vendor is wrong and thus the wrong bank account number and the
wrong IBAN number are searched on the invoice.
The SAP master data is not correct. The bank account number and the IBAN number
should be updated.

On top the validator did not populate the bank account number or IBAN number during the
validation.
Possible cases
The validator did not find the bank account number and the IBAN number on the
invoice.

Incorrect This means that

banking The bank account number and the IBAN number are different than the bank account
information number and the IBAN number of the vendor in the SAP master data.
compared to the Only the bank account number was recognized and it is different than the bank account
SAP vendor number of the vendor in the SAP master data.
master data Only the IBAN number was recognized and it is different than the IBAN number of the
vendor in the SAP master data.

Possible cases
The validator manually added a wrong bank account number and a wrong IBAN number
during the validation. (paper invoices or invoices received by e-mail)
A wrong bank account number and a wrong IBAN number were provided. (EDI invoices)
The wrong vendor was determined during the recognition phase. Within the SAP IM
workflow the vendor was replaced by the correct vendor, but the bank account number
or the IBAN number was not updated.

113 | 148
Remark

The exception is not triggered if:

 The bank account number is not mentioned on the invoice and is not maintained in the SAP
master data.
 The IBAN number is not mentioned on the invoice and is not maintained in the SAP master data.
 The bank account number is not mentioned on the invoice and there’s only one entry the SAP
master data
 The IBAN number is not mentioned on the invoice and there’s only one entry the SAP master
data

Involved roles and options

DP919: Invalid Banking Information

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X
(NPO_AP_PROC) Refer to Vendor Maintenance

Refer for Information

Change Vendor Master (XK02)

Apply Business Rules

Vendor Maintenance
Refer to AP Processor
(VENDOR_MAINT)
Refer to Vendor Maintenance

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

114 | 148
8.3.3.10[8.3.3.12] DP913: Alternative Payee

Exception trigger

This exception is triggered if an alternative payee can be specified manually for the vendor.

Trigger Explanation

Alternative This means that within the SAP master data from the vendor:
payee Other vendor numbers are defined which can be used as alternative payee (see Figure
5: Permitted Payee).
The option is enabled so that another address or bank details can be specified for this
vendor (see Figure 6: Individual alternative payee).

Possible cases
The vendor from the invoice is specified with possible alternative payees.
The wrong vendor is determined during the recognition phase. This vendor is specified
with possible alternative payees. The vendor from the invoice is not specified with
possible alternative payees.
The SAP master data is not correct. The vendor shouldn’t be specified with possible
alternative payees.

Figure 5: Permitted Payee

115 | 148
Figure 6: Individual alternative payee

Involved roles and options

DP913: Alternative Payee

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Post Invoice (FB60)

X X X X X
(NPO_AP_PROC) Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

116 | 148
8.3.3.11[8.3.3.13] DP911: Withholding Tax

Exception trigger

This exception is triggered if the vendor is subjected to withholding tax.

Trigger Explanation

Withholding tax This means that within the SAP master data from the vendor:
The vendor has a ‘Withholding Tax Code’4 (see Figure 7: Withholding tax)
Extended withholding tax is defined (see Figure 8: Extended withholding tax).

Possible cases
The vendor from the invoice is subjected to withholding tax.
The wrong vendor was determined during the recognition phase. This vendor is
subjected to withholding tax. The vendor from the invoice is not subjected to
withholding tax.
The SAP master data is not correct. The vendor shouldn’t be subjected to withholding
tax.

Figure 7: Withholding tax

4
The withholding tax code can be compared to a tax sub-category which must be taken into consideration when reporting tax to
the tax authorities.

117 | 148
Figure 8: Extended withholding tax

Involved roles and options

DP911: Withholding Tax

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Post Invoice (FB60)

X X X X X
(NPO_AP_PROC) Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

118 | 148
8.3.3.12[8.3.3.14] DP251: Pre-approved

Exception trigger

This exception is triggered if the invoice was determined as an invoice with expense type ‘pre-approved’
(PA) (see paragraph ‘8.3.3.1 DP209: Determine Expense Type’).

Trigger Explanation

Expense type PA This means that no approval is necessary for this invoice.
Possible cases
The vendor from the invoice is defined as a pre-approved vendor and thus the invoice
doesn’t need to be approved.
The wrong vendor is determined during the recognition phase. This vendor is defined as
a pre-approved vendor. The vendor from the invoice is not defined as a pre-approved
vendor.
The SAP master data is not correct. The vendor shouldn’t be defined as pre-approved
vendor.

Involved roles and options

DP251: Pre-approved

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

Post Invoice (FB60)

AP Processor
X Submit for Approval X X X
(NPO_AP_PROC)
Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

119 | 148
8.3.3.13[8.3.3.15] DP921: Account Information Changed During Approval

Exception trigger

This exception is triggered if the account information is changed during the approval workflow.

Trigger Explanation

Account This means during the approval flow a coded field (e.g. G/L account, cost center …) was changed
Information is between the initial coding by the AP Processor and the final approval by the last approver.
changed

Involved roles and options

DP921: Account Information Changed During Approval

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

Post Invoice (FB60)

AP Processor
X Show Coding Changes X X X
(NPO_AP_PROC)
Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

120 | 148
8.3.3.14[8.3.3.16] DP961: Tax Validation Required

Exception trigger

This exception is triggered if there’s an issue with the taxes determined.

Trigger Explanation

Tax Validation This means that, for the US, there’s an inconsistency between the tax amount identified in the
Required invoice and the Tax Code included in the PO. For Canada, It means that the tax could not be
determined and someone needs to manually validate the tax code.
Possible cases
Tax amount higher than 0, with Non Taxable Tax code.
Tax amount equal to 0, with Taxable Tax code.
The tax could not be determined correctly.

Involved roles and options

DP961: Tax Validation Required

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X X
(PO_AP_PROC) Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

121 | 148
8.3.3.15[8.3.3.17] DP962: Vendor Audit Required

Exception trigger

This exception is triggered if the vendor in the invoice has to be audited

Trigger Explanation

Vendor Audit This means that the vendor in the invoice has been selected for audit purposes.
Required Possible cases
Vendor has been added to the Vendor Audit list

Involved roles and options

DP962: Vendor Audit Required

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X X
(PO_AP_PROC) Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

122 | 148
8.3.3.16[8.3.3.18] DP963: Tax Audit Required

Exception trigger

This exception is triggered if the tax information in the invoice has to be audited

Trigger Explanation

Tax Audit This means that the vendor, company code, material group in the invoice has been selected for
Required audit purposes.
Possible cases
Tax Information in the invoice has been added to the Tax Audit list

Involved roles and options

DP963: Tax Audit Required

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X X
(PO_AP_PROC) Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

123 | 148
8.3.3.17[8.3.3.19] DP964: Address Validation for Check Vendor

Exception trigger

This exception is triggered if there are no invoices posted to this vendor, the vendor does not have a
remit to, and the payment method is check

Trigger Explanation

Address This exception is triggered if there are no invoices posted to this vendor, the vendor does not
Validation for have a remit to, and the payment method is check
Check Vendor

Involved roles and options

DP964: Address Validation for Check Vendor

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Apply Business Rules

AP Processor Refer to AP Processor

X X X X X
(PO_AP_PROC) Refer to Buyer

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

124 | 148
8.3.3.18[8.3.3.20] DP207: Process Non-PO Invoice

Exception trigger

This exception is triggered if the invoice couldn’t be automatically posted.

Trigger Explanation

No auto-posting This means that all the preceding DP exceptions (including the approval flow) were validated
successfully. SAP IM tried to automatically post the invoice, but the system did not succeed. This
exception gives the possibility to the AP Processor role to post the invoice manually in FB60.
Possible cases
An error message was given by the SAP system that the invoice couldn’t be posted; for
example: posting period is closed.

Involved roles and options

DP207: Process Non-PO Invoice

Initial Role Process options Change Obsolet Simulate Bypass

role index e

Change Doc Type

Apply Business Rules

AP Processor
X Post Invoice (FB60) X X X
(NPO_AP_PROC)
Refer to AP Processor

Refer for Information

Info Provider
Refer back to Referring Role
(INFO_PROVIDER)

125 | 148
 8.3.4 Detailed Description of the Non-PO Approval Workflow

The non-PO approval workflow is triggered by executing the process option ‘Submit for Approval’ in
exception “DP250: Approval Required”. Before starting the approval workflow, the AP Processor enters
the accounting information on the line item screen (cost allocations), e.g. G/L account and tax code. The
accounting information is used to determine the approvers.

Within the baseline of SAP IM there are different kinds of approval workflows:
 Parallel line item based approval
 Header based approval

The approval workflow included in the VIM package is the parallel line item based approval.

8.3.4.1 Parallel Line Item based Approval Process

8.3.4.1.1 Roles
The roles, involved in the non-PO approval workflow, are:
 Requester
o The user who requested the goods or services.
o The first user who can approve or reject the cost allocations.
o Can modify the cost allocations, for example adding the cost center.
o Determined based on the requester’s e-mail found on the invoice. In case no e-mail was
found on the invoice, the AP processor can manually choose the requester when starting the
approval workflow.

126 | 148
  Approver(s)
o The user(s) who has/have to approve or reject the invoice.
o Cannot modify the cost allocations. In case of disagreement, the invoice needs to be
rejected.
o Determined based on the setup and interpretation of the data in the COA (see paragraph
‘8.3.4.2 Level Based Chart of Authority’).

8.3.4.1.2 Levels
The line item based approval workflow is based on approval levels. For each combination of company
code and expense type, different approval levels need to be defined. These levels are defined by an
approval limit, which is the maximum approval for everybody who will be assigned to that approval level.

For each combination of company code and approval level, different approvers need to be assigned to
cost center object for which they are responsible within that level.

More than one person can be assigned to a cost objectcenter within the same level. One person can
also be assigned to several levels for several cost centersobjects.

127 | 148
Basically the system determines the approver based on the match between the accounting information
on the invoice and the COA. The system will thereby look at the combination of
 company code (company code of invoice line(s))
 expense type
 approval level
 cost center
 WBS
 Internal Orders
 Profit Center

8.3.4.1.3 Packs
The VIM 7.5 Level Based Approval workflow introduces the principle of ‘packs’.

A pack is a combination of approvable lines grouped by an assigned approver related to at least one cost
object. The pack amount is the sum of different line item amounts that are assigned to a certain
approver. How a pack is determined, is based on the COA setup.

If for a specific invoice the approver is the same for several lines, then he or she will only get 1 work item
per level. This enables you to approve all relevant lines at once, for that specific level.

This is not the case for multiple invoices. For multiple invoices the approver will get a separate work
item per invoice per level (if the approver is assigned to multiple levels).

Example 1

Approval level Assigned approver Cost object Invoice line item Result
in COA amount

Approval level 1 Jan Cost center A 20.000,00 Pack 1  value =

20.000,00

Piet Cost center B 15.000,00 Pack 2  value =

Piet Cost center C 10.000,00 25.000,00

Approval level 2 Bart Cost center A 20.000,00 Pack 1  value =

Bart Cost center B 15.000,00 35.000,00

Paul Cost center C 10.000,00 Pack 2  value =

10.000,00

In example 1 the invoice has 3 lines (20.000,00 EUR, 15.000,00 EUR & 10.000,00 EUR) with 3 different
cost centers (A, B & C).

In the COA for level 1 approval, Jan is responsible for cost center A and Piet is responsible for cost center
B and C. The system will determine the pack and the total pack amount per approver. In total 2 packs are
being created:
 Jan: Pack 1 consists of line 1  total pack amount = 20.000,00 EUR
 Piet: Pack 2 consists of line 2 and 3  total pack amount = 25.000,00 EUR

128 | 148
In level 2, according to the COA, cost center A and B are assigned to Bart and cost center C is assigned to
Paul. As the approval has to be done on a new (higher) level the system will determine new packs and
new pack amounts:
 Bart: Pack 1 consists of line 1 and 2  total pack amount = 35.000,00 EUR
 Paul: Pack 2 consists of line 3  total pack amount = 10.000,00 EUR

Whether or not a line can be finally approved (= no further approval required), depends on whether the
pack amount is lower than the approval limit for that specific level.

Example 2

Approval Approval Assigned Cost object Invoice line Pack amount Approval
level limit approver in item amount sequence
COA

Approval 22.000,00 Jan Cost center 20.000,00 Pack 1 

level 1 A value = 1
20.000,00

Piet Cost center 15.000,00

B Pack 2 
value = 2
Piet Cost center 10.000,00 25.000,00
C

Approval 50.000,00 Bart Cost center 20.000,00 Already

N/A
level 2 A approved

Bart Cost center 15.000,00 Pack 1 

B value = 3
15.000,00

Paul Cost center 10.000,00 Pack 2 

C value = 4
10.000,00

In example 2 the approval limit for level 1 approvers is 22.000,00 EUR. The following pack amounts are
determined:
 Jan: Pack 1 consists of line 1  total pack amount = 20.000,00 EUR
 Piet: Pack 2 consists of line 2 and 3  total pack amount = 25.000,00 EUR

Since the amount of pack 1 (20.000,00 EUR) is lower than the approval limit for level 1 approvers
(22.000,00 EUR), this entire pack will be finally approved. However, the amount of pack 2 (25.000,00
EUR) is higher than the approval limit for level 1 approvers (22.000,00 EUR), so this pack will need an
additional approval on a higher level.

8.3.4.1.4 Parallel Processing

Within one level packs are sent in parallel for approval. If several approvers are needed within the same
approver level, the packs (work items) are sent to all approvers at the same time. After all lines within
one level are approved, the next approval level can be processed. The same principle applies for the next
levels. Approval is completed when all lines are finally approved.

129 | 148
8.3.4.1.5 Approval Process Steps
The different steps involved in the approval process are as follows:

Step 1: Approval by Requester

When an invoice is submitted for approval, the approval workflow will start and the invoice will be routed
to the Requester. This Requester is determined based on the requester e-mail address that is either
mentioned on the invoice or added manually by the ICC Validator in ICC or the AP Processor in the DP
workflow.

The Requester will receive a workflow task in his or her inbox. When executing it, a dialog window is
displayed in which the accounting data can be entered, modified or consulted, and in which the invoice
can be approved or rejected.

In case of:
 Rejection
The workflow is routed back to the AP Processor in DP exception “DP250: Approval Required”.
The Requester will be asked to provide the reason for his rejection by means of comments.

 Approval
The workflow system will consult the COA to determine the next Approver. Whether or not the
next Approver is from the next level (Approver level) or from the same level (Requester level)
depends on whether or not all lines have been approved in the Requester level.

If the system finds an applicable Approver in the COA, the Requester will see the name of the
next Approver and the Requester can send the work item to the system-proposed Approver.

o How does the system derive the Approver?

The system determines the Approver based on the match between the financial
information entered on each line of the invoice and the COA.

When the Requester clicks on the ‘Approve’ button, the system will check if there are
still lines left that require approval within the Requester level. If that is the case, then
the system will check the COA for possible approvers in the Requester level for the
remaining lines depending on the defined cost object(s).

In example 2 here above, after Jan has approved line 1 the system will check if all lines
in that same level have already been approved. Since this is not the case, the system
will consult the COA to find an approver for lines 2 and 3 and it will suggest Piet as next
approver.

After Piet has finished the approval of line 2 and 3 in level 1, the system will check once
more if all lines in that level have been approved and if they are finally approved (= no
further approval required for that line).

Since line 1 is finally approved, the system will no longer look for a next approver for
line 1. However, line 2 and 3 still require further approval, so the system will now check
the COA for possible approvers in level 2 based on the cost centers.

Once the system has determined the next approver, it will send the invoice to Piet (who
is the last approver of level 1). He can then either agree with the suggestion and send

130 | 148
 the work item to the proposed approver or disagree and manually select a possible
approver. This possible approver must be a level 2 approver.

Step 2: Approval by Approver

Once all invoice lines have been approved by the Requester (= level 1) the work item is being forwarded
to the Approval level (= level 2), enabling the Approver to approve or reject those lines that have not yet
been finally approved.

In case of:
 Rejection

Option One Step Back Terminate Approval Process

Result The work item will be sent back to the The approval flow will be terminated and
previous approver/requester the work item will be sent to the AP
Processor in the DP flow in exception
“DP250: Approval Required”

In the VIM package the approval process is terminated, in case of rejection. The Approver will be
asked to provide the reason for rejection by means of comments.

 Approval
The invoice lines in the approver’s pack are approved for that level. If there are other lines that
require approval in that level, then the invoice will be sent to the appropriate approver. If all
lines within that level are approved, the system will check if all lines are finally approved.

Yes No

All lines finally The approval flow will stop and the The system will continue to search for
approved? invoice will be sent back to the DP the next level approver(s) until all lines
workflow to continue with the are finally approved
subsequent DP exceptions

Each role in the non-PO approval flow can provide comments prior to approving. These comments
can be consulted by the other persons in the approval chain and the comments will also be visible in the
DP flow again in case of a full rejection or in case the invoice could not be auto-posted.

131 | 148
When the user wants to approve an invoice line, the system will either show one of the two following
screens:
 Same level approval

132 | 148
  Next level approval

In the approval screen the following icons are used to indicate the line status (applies to line based
approval, all levels):

Icon Meaning Description

All lines marked with this icon can be approved by the user who
Ready for approval
has the work item

All lines marked with this icon have already been approved within
Already approved
that level

All lines marked with this icon have been fully approved and do not
Finally approved
need additional approval from higher levels

8.3.4.2 Level Based Chart of Authority

The Chart of Authority manages the following on each tab:

 ‘User Details’ tab
o List the COA users' general details.

133 | 148
 EDF uses following data to determine OpenText User ID

☒ E-mail address (digits before the @)

☐ SAP User ID

 ‘Approval Limit/Level’ tab

o Define the approval levels and amounts, based on company code and expense type.

Maintain following details per combination of company code and approval level

Description

Company code Add company code to which the approval level should apply.

Expense type Select an expense type from the list.

Approval level Basic value of the level based COA. Select one of the following values from
the list:
 0 = Coder level (no limit possible, always 0,00 EUR)
 1 = Requester level
 2, 3, ... = Approval levels

Description Enter a description of the level (optional). It describes the different levels
for the different key fields.

Amount limit Enter an amount. This amount will be considered as the approval limit. The
user can finally approve the invoice line(s) if the amount of the pack is less
than or equals to the amount mentioned in this column. If the pack
amount exceeds this limit, the invoice line needs next level approval.

134 | 148
 Approval category This column is specific to header based approval. Select ‘H-Highest pack
only’ or ‘A-All pack’ from the list. For the Coder level (level 0) the value
always must be set to ‘H-Highest pack only’. Not relevant for level based
approval.

Additional amount Enter an amount. The additional amount is used in the header based
approval to check all packs (‘All pack’ scenario). Not relevant for level based
approval.

 ‘COA Details’ tab

o Assign cost objects (cfr. COA variables) to each user.

For the Requester (level 1), the cost objects are checked to see if the user can approve the
corresponding cost objects within his/her pack. All lines must be approved by a legitimated
Coder or Requester. The invoice is forwarded to the next Requester until all lines within the level
are approved.

For the Approvers (as from level 2), the COA is used to determine the next Approver and also to
create the pack when opening the work item. If more than one Approver exists in the COA for
the corresponding cost objects of the invoice line, the first user in the COA will be selected.

In the COA, you can maintain different cost objects (e.g. cost center and WBS element). Multiple
cost objects can be defined per approver.
For example:

135 | 148
 Maintain following details per user

Description

Company code Company code that the user is authorized to approve. For line based
approval, the company code of the invoice line is used to check
against the COA. For header based approval, the header company
code is relevant.

Approval level Approval level.

User mapping object ID OpenText User ID maintained in the ‘User Details’ tab.

Counter Non-editable column that is filled automatically by the system. It is

used to indicate the number of times the same user with same level
and company code is assigned to different cost elements.

Configurable cost Cost elements (e.g. cost center, WBS element …) can be maintained in
elements (COA variables) table /OPT/BL_T401V.
According to the configuration of /OPT/BL_T401V, you can
maintain ranges for the different cost objects. It is also possible to
configure an asterisk (*) for a cost object, which means that the
approver is allowed to approve invoice lines for all cost objects within
that level.

More details about approving work items in bulk can be found in section ‘Bulk Approval’.

 ‘Coder Settings’ tab

Within the VIM package there is no maintenance view available for the coder. The coder is
configured to be the requester.

136 | 148
8.4 Posting Date

The posting date is the current system date.

This proposed date can be overwritten in the indexing information during the SAP IM workflow before
posting manually. In case the current system date cannot be taken during month end closing, automatic
posting can be disabled per company code in the master data for a period of time.

8.5 FI Document Type

Below an overview of the assigned FI document types if invoices/credit notes get posted:

Non-PO PO

Invoice KR RE

Credit note KG RE

8.6 Tax Code Determination

For posting invoices into SAP it is required to define the applicable tax code on the invoice.

When invoices enter SAP IM from ICC, the tax code may not be supplied. However in SAP IM it is
important for the system to have the tax code to enable auto-posting. Therefore SAP IM provides a tax
code determination rule that tries to determine the tax code corresponding to the supplied tax rate.
(Note: This rule only works whenever a tax rate is being supplied.)

The objective is to assign a correct tax code to each line item of PO and non-PO invoices using master
data and PO data (for PO invoices).

The following logic is applicable for EDF:

The system reads the tax code from the PO line and checks if the tax rate supplied by ICC matches
uniquely. If the tax code exists in the PO line and no match is found, the tax code is considered to be not
determined and the system will stop any further checking.

137 | 148
9 Process Work Items

An end-user of SAP IM can consult and open work items from either of below interfaces.

9.1 Integrated Invoice Cockpit (IIC)

The Integrated Invoice Cockpit gathers and displays all your SAP IM exceptions in one place. This applies
within a single system landscape or a multiple backend system.

You can view the work items per SAP Client. You can also choose to filter your work items per document
process defined in the DP workflow and per blocked process in the LIV workflow.

The following options are available in the IIC:

Icon Meaning Description

Executes the work item and opens it in the associated dashboard. This would
mean that (1) if the work item is in the DP workflow, the DP dashboard will open;
Execute work item
(2) if it is in the block workflow, the block workflow dashboard will open; and (3) if
it is in the approval workflow, the approval dashboard will open.

Display image Opens the invoice image associated to the work item.

View or add comments to the work item. If there are existing comments the icon
Display comment
is highlighted.

Displays the work item. This function is similar to the display function in SAP
Display work item
Business Workplace.

Releases the payment block. This is only available for price discrepancies in the
Release LIV workflow. By releasing the work item you accept the price discrepancy and
the price blocking will be removed.

138 | 148
You will be provided with following information over the invoice:

ICC fields

Logical system Local currency

Document ID Quantity

Company code Purchase order unit of measure

Document number of an invoice document Difference quantity (in case of quantity discrepancy)

Fiscal year Posting date in the document

Invoice item Different invoicing party

Accounting item Vendor name

Item text Due date

Reference document number Days to due

Work item ID Purchasing document category

Work item text Purchasing document number

Agent type Item number of purchasing document

Agent ID Plant

Process type Purchasing organization

Process type description Purchasing group

Parking reason Description of purchasing group

Parking reason description Storage location

Block reason Material number

Block reason description Account assignment category description

Exception types for extended IIC Processing status of a work item

Exception type ID Status of work item as icon

Exception text Creation date of work item

Last option executed type Creation time of work item

Last option executed ID Priority of a work item

Last option executed text Current role

Gross invoice amount in document currency Document status

Currency key Credit memo indicator

Difference value (in case of price discrepancy) Barcode

139 | 148
9.2 VIM Workplace

The VIM Workplace is especially designed for VIM super users, for example the AP processor. It allows
you to display lists of your work items based on criteria that you have specified. In addition you can
display work items of other users and of your team as a whole.

9.3 SAP Approval Portal

The SAP Approval Portal is especially designed for non-SAP users. It displays all the SAP IM documents
assigned to you for Approval in one place. This applies within a single system landscape or a multiple
backend system.

140 | 148
10 Reminder E-mails

EDF is responsible for ensuring e-mails can be sent from SAP by configuring and maintaining the
necessary MS Exchange settings. The e-mail address corresponding to the SAP user must be available
within SAP.

10.1 Standard Reminder E-mail to the End-User

On a periodic basis SAP IM workflow users can be informed about the workflow items that are waiting to
be processed in their SAP inbox (Business Workplace) in case of approvals. They will get an e-mail
containing a list of all invoices that they are responsible for to process. An invoice will be taken up in this
list if:
 A work item corresponding to the invoice is present in the SAP inbox for more than X days
already.
 A work item corresponding to the invoice is present in the SAP inbox and Y or less days later a
calculated ‘Payment Due Date’ is met.

A scheduled background job will take care of sending out the reminder e-mails to the SAP IM users. In
this way each user will receive 1 e-mail per Z day(s) (with Z the periodicity of the background job).

This e-mail will consist out of a header text and a body.

A typical e-mail looks as follows:

The body contains an overview of all work items to be processed by the SAP IM user on that particular
moment. The columns that will make up the body are:
 Company code
 SAP IM document ID
 Document Number
 Line Item
 Invoice amount

141 | 148
  Currency
 Inbox days
 Days before due
 Vendor number
 Vendor Name
 Due Date
 Fiscal Year
 Workitem ID

Hence, for each ‘workflow task type/role’ combination, we will configure the trigger used to decide
whether the invoice should be taken up in the e-mail and we can also define a standard header text:

Workflow task type Role Trigger to include a particular invoice in the body Header text

DP Document Dashboard * After residing 4 days in the SAP inbox. ZREMINDERS

Non-PO Approval Task * After residing 4 day in the SAP inbox. ZREMINDERS

PO Blocked Line * 4 days before invoice due date. ZREMINDERS

PO Blocked Header * 4 days before invoice due date. ZREMINDERS

142 | 148
10.2 Workitem Notification E-mail to the End-User

An initial notification e-mail will be sent to the Info Providers, Receivers, Buyers and Vendor Maintenance
team members whenever a workitem is assigned to them.

This workitem notification will have some basic details of the invoice as the vendor name, vendor
reference, PO number and gross amount.
The e-mail that will be used to send the notification will be the e-mail address that each user has on their
SAP profile.

143 | 148
11 Reporting

SAP IM provides different, out-of-the-box reports, mainly based on the real-time data available in the
specific SAP IM database tables, complemented with vendor and company code master data.

11.1 VIM Analytics

VIM Analytics provides clear data reports on the processed invoices with exceptions as well as the invoice
exception workflows. It allows tracking of the documents routed through SAP workflows by SAP IM. VIM
Analytics presents the data report results in the SAP List Viewer (ALV).

VIM Analytics is used to check the current document status and exception reason of a particular invoice
in the Document View. It allows also checking of the current workflow status, current agent and
exception reason of a particular invoice in the Workflow View.

It is delivered with pre-configured reporting variables. Modifying the report to meet additional reporting
requirements is out of the scope of the baseline.

11.2 Current Liability Report

The Current Liability Report offers a clear data report on documents that aren’t posted in the system yet.
The purpose of this report is to provide the Accounts Payable department with accurate information
about the current liabilities at any point in time.

As a primary use, the report helps the AP department to do the accruals at month or period end. It
provides various views of the data, enabling the AP department to analyze the liability information from
various forms. The various views address the different accrual procedures used by various companies.

The report considers parked invoice documents and optionally credit memos that are in parked status. It
also considers DP documents that were created but have not been processed as SAP documents. Both PO
and non-PO invoices are supported. There are various controls within the report allowing you to calculate
sub totals, download to Excel … You can restrict the output to lines that are within a certain amount
range. This is useful if your company’s internal policy is to ignore all lines that are below a certain money
limit.

11.3 SAP IM Central Reporting Infrastructure

The Central Reporting Infrastructure provides reporting across the landscape in multiple backend
systems. In single system scenarios, as at EDF, it also provides useful reports. It creates several reports
that enable you to measure certain properties of VIM invoice documents and their work items in order to
optimize working with SAP IM. In particular, the following reports are provided:

144 | 148
Key Process Analytics Report

The Key Process Analytics Report reports about a variety of key figures regarding the SAP IM process. The
individual report panels of the Key Process Analytics Report highlight the following aspects:
 Total Liability
 Processed/In Process Documents
 Channel Analysis
 First Pass: This panel provides an overview of first pass VIM invoices, meaning VIM invoices that
could be posted without any exceptions. By double-clicking, you can display a detailed list of
documents.
 Top Exceptions by Count
 Top Vendors by Amount

Productivity Report

The Productivity Report reports about the productivity of users/roles and the activities of users/roles. It
comprises the following features:
 Provides an overview of the processing times (total and average) and wait times (average) per
user/role.
 Enables the comparison of productivity of a freely selectable period to a comparison period.
 Provides a snapshot of reserved and in process items per user/role.
 Enables the analysis of the average number of touches (per invoice) of users/roles.
 Enables the analysis of the average number of referrals (per invoice) of users/roles.
 Allows displaying a detailed list of:
Documents processed by a single user/role.
Currently reserved items of a single user/role.
Currently processed items of a single user/role.

Exception Analysis Report

The Exception Analysis Report reports all work items with exceptions, grouped by exception, company
code or vendor. It provides the following:
 Finds and tracks exceptions with the highest impact on your business.
 Monitors how often exceptions occur.
 Finds companies or vendors who cause the highest number of exceptions.
 Indicates the invoice amount that is affected by work items with exceptions.

Aging Report

The Aging Report comprises the following features:

 Provides an overview of the processing times of documents that have not been posted without
error.
 Provides a snapshot of documents that have not been posted and are still work in process.

145 | 148
  Allows displaying a detailed list of:
Documents still in process, grouped by document type.
Documents still in process, grouped by role.

Summary Report

The summary report is a new Central Report available since SP4 to replace the VAN Summary section. It is
created to display the summary of all the invoice documents processed through SAP IM.

Automation Report

The summary report is a new Central Report available since VIM 7.5. The report provides data about the
automated and manual processing steps of VIM documents.

146 | 148
12 Substitution

There is an option in standard SAP workflow functionality of naming a substitute when a user is absent:
transaction RMPS_SET_SUBSTITUTE.

The substitute user can display and process the absent user’s work items for the duration of the
substitution. For this to occur, the substitute must be defined in advance. The substitute does not need to
be assigned as a receiver or as a processor of the underlying task.

The rules for substitution vary depending on whether the period of absence is scheduled (e.g. holiday) or
unscheduled (e.g. illness).

12.1 Scheduled Absence

When a period of absence is scheduled, there is a need to name a substitute and a period and then
activate that substitution (active substitution). This could be done in advance. The work items are
automatically forwarded to the substitute for the duration of the substitution. The substitute is then able
to process both, their own and absent user’s work items.

12.2 Unscheduled Absence

In case of an unscheduled absence, a substitute can be specified in advance but the substitution must not
be activated (passive substitution). The substitute can decide to adopt the workflow task of the absent
person when this is required.

147 | 148
 Copyright© 2004-2017 by Delaware Consulting.
The copyright to these materials and any accompanying software is owned, without reservation, by
Delaware Consulting. These materials and any accompanying software may not be copied in whole or
part without the express, written permission of Delaware Consulting.
All rights reserved. Printed in Belgium.
Products or company names are used for identification purposes only, if any, and are trademarks of their
respective owners.

_______________________

148 | 148