Sap Fi AP BBP Document

BLUEPRINT
SAP H IMPLEMENTATION PROJECT

BUSINESS BLUEPRINT
SAP FI Accounts Payable

DOCUMENT DETAILS
Prepared By
Document/ File Name
Version
Created Date
Number of Pages
Project Folder Path
DOCUMENT CONTROL
Version Revision Date Revision Description Author/ Reviewer Signature
APPROVAL
NAME TITLE DATE SIGNATURE
SAP H Implementation Project Page 2 of 117

Table of Contents
1 Introduction ....................................................................................................................................................................... 9
1.1 Management Executive/Summary .............................................................................................................................. 10
1.2 Basic Documents ........................................................................................................................................................ 10
1.3 Project Charter............................................................................................................................................................ 11
1.4 Project Scope/Scope Document ................................................................................................................................. 12
1.5 Significant Changes to the Current Status .................................................................................................................. 13
2 Business Process Modeling ............................................................................................................................................ 16
2.1 Cross Process related topics ...................................................................................................................................... 16
2.1.1 Information Carrier Model .............................................................................................................................. 16
2.2 Process Model Level 1, Core and Support processes <Financial Accounting>........................................................ 17
2.2.1 Flow Chart: .................................................................................................................................................... 18
2.3 Process Model Level 2, Process groups <Accounts Payable Accounting> .............................................................. 19
2.3.1 Flow Chart: .................................................................................................................................................... 20
2.4 Process Model Level 3, Business Process 1 Process Vendor Invoices ................................................................... 21
2.4.1 Short Description of the Process ................................................................................................................... 21
2.4.2 Business Requirements ................................................................................................................................. 22
2.4.3 Written Explanation........................................................................................................................................ 24
2.4.3.1 Process of Logistics Invoice Verification of Vendor: ...................................................................................... 24
2.4.4 Linked Processes .......................................................................................................................................... 40
2.4.5 Inputs (Event Triggers, entities, parameters) ................................................................................................. 40
2.4.6 Outputs (Process Results) ............................................................................................................................. 40
2.4.7 Process specific User Roles & Requirements for the Authorization Concept ................................................ 40
2.4.8 Quantification ................................................................................................................................................. 41
2.4.8.1 Transaction and Data Volumes ..................................................................................................................... 41
2.4.8.2 Frequency of the Processes .......................................................................................................................... 41
2.4.9 Measurable KPIs ........................................................................................................................................... 41
2.4.9.1 Status of KPIs before the Project ................................................................................................................... 41
2.4.9.2 Target KPIs .................................................................................................................................................... 42
2.4.10 Improvements to the Process Compared to As-Is Status .............................................................................. 42
2.4.11 Functional Deficits/Gaps ................................................................................................................................ 42
2.4.12 Notes on Further Improvements .................................................................................................................... 42
2.4.13 Development Considerations ......................................................................................................................... 42
2.4.14 FRICE Considerations ................................................................................................................................... 42
2.4.14.1 Forms Considerations ............................................................................................................................... 42
2.4.14.2 Reports Considerations ............................................................................................................................. 43
2.4.14.3 Interface Considerations ........................................................................................................................... 43
2.4.14.4 Data Conversion Considerations ............................................................................................................... 43
2.4.14.5 Enhancements Considerations ................................................................................................................. 43
2.5 Process Model Level 3, Business Process 2 Handle Vendor DR/CR Notes ............................................................ 43


2.5.3 Flow diagram ................................................................................................................................................. 45
2.5.9 Quantification ................................................................................................................................................. 48
2.5.10 Measurable KPIs ........................................................................................................................................... 49
2.5.10.1 Status of KPIs before the Project .............................................................................................................. 49
2.5.10.2 Target KPIs ............................................................................................................................................... 49
2.6 Process Model Level 3, Business Process 3 Handle Vendor Advances/Deposits/Guarantees/Retentions .............. 51
2.6.1.1 Vendor Advances: ......................................................................................................................................... 51
2.6.1.2 Vendor Deposits: ........................................................................................................................................... 51
2.6.1.3 Bank Guarantees: .......................................................................................................................................... 52
2.6.1.4 Vendor Retention: .......................................................................................................................................... 52
2.6.3 Flow diagram ................................................................................................................................................. 54
2.6.4.1 Vendor Deposits: ........................................................................................................................................... 56
2.6.4.2 Guarantees: ................................................................................................................................................... 56
2.6.4.2.1 Process Flow Chart Guarantees ............................................................................................................ 57
2.6.4.3 Retention: ...................................................................................................................................................... 59
2.6.4.3.1 Process flow chart Retention .................................................................................................................. 60

2.6.9 Quantification ................................................................................................................................................. 67
2.6.10 Measurable KPIs ........................................................................................................................................... 67
2.6.10.2 Target KPIs ............................................................................................................................................... 67
2.6.12 Gaps in the process Coverage ...................................................................................................................... 69
2.6.13 Organization change for further Improvements ............................................................................................ 69
2.7 Process Model Level 3, Business Process 4 Handle Vendor Letter of Credit .......................................................... 70
2.7.3 Flow diagram ................................................................................................................................................. 71
2.7.9 Quantification ................................................................................................................................................. 75
2.7.10 Measurable KPIs ........................................................................................................................................... 75
2.7.10.2 Target KPIs ............................................................................................................................................... 75


2.8 Process Model Level 3, Business Process 5 Plan/Schedule Vendor Payments ...................................................... 77
2.8.3 Flow diagram ................................................................................................................................................. 78
2.8.9 Quantification ................................................................................................................................................. 82
2.8.10 Measurable KPIs ........................................................................................................................................... 82
2.8.10.2 Target KPIs ............................................................................................................................................... 82
2.9 Process Model Level 3, Business Process 6 Process Vendor Payment .................................................................. 84
2.9.3 Flow diagram Manual Payment Process .................................................................................................... 86
2.9.4 Flow diagram Automatic Payment Process ................................................................................................ 89
2.9.10 Quantification ................................................................................................................................................. 94
2.9.10.1 Transaction and Data Volumes ................................................................................................................. 94
2.9.10.2 Frequency of the Processes ...................................................................................................................... 95

2.9.11 Measurable KPIs ........................................................................................................................................... 95

2.9.11.2 Target KPIs ............................................................................................................................................... 95
2.10 Process Model Level 3, Business Process 7 Provide Vendor Account Confirmation ............................................... 97
2.10.3 Flow diagram ................................................................................................................................................. 98
2.10.4 Written Explanation...................................................................................................................................... 100
2.10.5 Linked Processes ........................................................................................................................................ 100
2.10.6 Inputs (Event Triggers, entities, parameters) ............................................................................................... 100
2.10.7 Outputs (Process Results) ........................................................................................................................... 100
2.10.8 Process specific User Roles & Requirements for the Authorization Concept .............................................. 100
2.10.9 Quantification ............................................................................................................................................... 101
2.10.9.1 Transaction and Data Volumes ............................................................................................................... 101
2.10.9.2 Frequency of the Processes .................................................................................................................... 101
2.10.10 Measurable KPIs ..................................................................................................................................... 101
2.10.10.1 Status of KPIs before the Project ............................................................................................................ 101
2.10.10.2 Target KPIs ............................................................................................................................................. 102
2.10.11 Improvements to the Process Compared to As-Is Status ........................................................................ 102
2.10.12 Functional Deficits/Gaps ......................................................................................................................... 102
2.10.13 Notes on Further Improvements .............................................................................................................. 102
2.10.14 Development Considerations .................................................................................................................. 102
2.10.15 FRICE Considerations ............................................................................................................................. 102
2.10.15.1 Forms Considerations ............................................................................................................................. 102
2.10.15.2 Reports Considerations ........................................................................................................................... 102
2.10.15.3 Interface Considerations ......................................................................................................................... 102
2.10.15.4 Data Conversion Considerations ............................................................................................................. 102
2.10.15.5 Enhancements Considerations ............................................................................................................... 102
2.11 Process Model Level 3, Business Process 8 Accounts Payable Reports ............................................................... 102
2.11.1 Short Description of the Process ................................................................................................................. 102

2.11.2 Business Requirements ............................................................................................................................... 103

2.11.3 Flow diagram ............................................................................................................................................... 104
2.11.4 Written Explanation...................................................................................................................................... 107
2.11.5 Linked Processes ........................................................................................................................................ 108
2.11.6 Inputs (Event Triggers, entities, parameters) ............................................................................................... 108
2.11.7 Outputs (Process Results) ........................................................................................................................... 108
2.11.8 Process specific User Roles & Requirements for the Authorization Concept .............................................. 108
2.11.9 Quantification ............................................................................................................................................... 108
2.11.9.1 Transaction and Data Volumes ............................................................................................................... 108
2.11.9.2 Frequency of the Processes .................................................................................................................... 108
2.11.10 Measurable KPIs ..................................................................................................................................... 108
2.11.10.1 Status of KPIs before the Project ............................................................................................................ 109
2.11.10.2 Target KPIs ............................................................................................................................................. 109
2.11.11 Improvements to the Process Compared to As-Is Status ........................................................................ 109
2.11.12 Functional Deficits/Gaps ......................................................................................................................... 109
2.11.13 Notes on Further Improvements .............................................................................................................. 109
2.11.14 Development Considerations .................................................................................................................. 109
2.11.15 FRICE Considerations ............................................................................................................................. 109
2.11.15.1 Forms Considerations ............................................................................................................................. 109
2.11.15.2 Reports Considerations ........................................................................................................................... 109
2.11.15.3 Interface Considerations ......................................................................................................................... 109
2.11.15.4 Data Conversion Considerations ............................................................................................................. 109
2.11.15.5 Enhancements Considerations ............................................................................................................... 109
3 Solution Transformation ................................................................................................................................................ 110
3.1 Cross Process related Topics .......................................................................................................................... 110
3.1.1 SAP Organizational Structure ...................................................................................................................... 110
3.1.2 Business Requirements ............................................................................................................................... 110
3.1.3 Design Aspects ............................................................................................................................................ 111
3.1.4 Master Data Concept ................................................................................................................................... 111
3.1.4.1 Scenario Overview....................................................................................................................................... 111
3.1.5 High-Level Migration Concept ..................................................................................................................... 112
3.1.6 Roles ........................................................................................................................................................... 114
3.1.7 APPENDIX A for Accounts Payable Reports ............................................................................................. 114
4 System Landscape........................................................................................................................................................ 116
4.1 Planned / After Go-Live ............................................................................................................................................ 116
4.1.1 Requirements for the Authorization concept ................................................................................................ 116
4.1.2 Necessary IT systems required ................................................................................................................... 116
4.2 Actual / Before the Poject Launch ............................................................................................................................. 116
4.2.1 Requirements for the Authorization concept ................................................................................................ 116
4.2.2 Necessary IT systems required ................................................................................................................... 116

5 Glossary ........................................................................................................................................................................ 116

5.1 Appendix ................................................................................................................................................................... 117
5.2 References/Biblography ........................................................................................................................................... 117
1 INTRODUCTION
This document states all of the conceptual results of the project SAP H. These project results were devised
and decided on by the project team and the Business Process Owner during the Business Blueprint project

phase. This is the main concept document of the project. The content of this document forms the basis and
the guidelines for the subsequent realization phase. This document aims to describe the future business
solution for SAP.
Any additional explanations that are only relevant when the project is in progress are given in the various
project management plan documents, which the project management team will provide on request.
1.1 M ANAGEMENT EXECUTIVE/SUMMARY
The following Business Team form part for the outcome of the Business Blue Print.
ABC SAP
Team
Leader Name Role E-mail
1
Key Users
1
2
3
4
5
1.2 BASIC DOCUMENTS
The following basic documents describe the foundations of the project work that affected the initial
designs and concepts of the project. The information here is a selection of the most important

information. The complete information is available on the shared project file server at
\\10.3.24.51\SAP_Project\SAPH\2000- Business Blueprint\2100-Business Blue Prints
Document ID Document Name
BBP Workshop Report_FI_AP_03 Workshop Report
1.3 PROJECT CHARTER
Project Charter Mission & Benefits:

The mission of SAP H Project is to enable and enhance effectiveness and efficiency of business
processes of ABC company whilst utmost adaptation of SAP standard functionality and best business
practices.
ABCs current computer system has evolved through in-house development since two decades and
many individual island systems exist to carry out the business process.
Data communications among the applications are very restrictive and are not supporting the business
requirements adequately and are not integrated.
As part of its Computerization strategy, ABC Company has made the decision to replace its existing
systems with an ERP - my SAP integrated software.
The focus of benefits will be to provide common business systems across ABC that will:
Enable more effective use of resources
Support business growth
Leverage administration costs
The primary benefits expected to accrue from the SAP implementation are:
Reduction of paper work that promote concept of paperless office.
Identify the profitability of an activity and associated costs.
Flexible, evolving and responsive business environment.
Simple and shortened close at month and year-end.
Reduction of administrative overhead, enabling staff to concentrate on analysis rather than
transactional issues.
Provision of an integrated solution to the shortfalls of the current systems.
Information sharing across the company.
Provision of a feed of enterprise transaction data to any future data repositories and decision
support tools such as the Business Intelligence.
High quality reporting resulting from improved data collection, database and reporting tools.

Introduction of Executive Information System (EIS) reporting for more informed decision-making.
Broadly to mention
The project sponsor Mr. XYZordered this project on 07.11.2010.

The name of the project is SAP H.
The go-live of the project is scheduled.
The internal sponsor is the IT&HR department. ABC has named Mr.xxxx as its program
manager.
Consultants from SAP International for IT have been appointed by ABC as their SAP
Implementing Partner.
The complete project charter is available on the project server.
1.4 PROJECT SCOPE/SCOPE DOCUMENT
This section summarizes the project scope that was agreed between the customer and the contractor.
This scope goes beyond the tasks that the service provider SAP has been assigned and includes all
project tasks that ABC must complete internally for itself.
The scope is subject to a strict change procedure. The process for changing the scope is described in
Project Scope Document ID.
To explain the scope as precisely as possible, several dimensions were chosen for examining the
scope, some of which may overlap: Specifically, the scope is examined in terms of the processes, IT
functions, technology, organization, method, and deliverables.
The highlights are:

Processes:
- General ledger accounting, accounts receivables accounting, Accounts Payable Accounting,
Asset Accounting, Cash and Bank Accounting and Treasury.
Functions:
- mySAP ERP, component ECC 6.0 with EHP5.
Technology:
- Complete replacement of Venus System
Organization:
- Preparation of a centralized accounting department for all subsidiaries, including the appropriate
training activities
Method:
- The project includes the training of end users

- Project staff will provide support for the end users during the first month after the go-live
The current version of the complete project scope is available at (path).
Process Scope:
Core & Support Process Business Process Business Process Business

-Level 1 Group Level 2 Level 3 Process Code
Financial Accounting HI_FI_AP_03_01
Accounts Payable Process Vendor Invoices
Business Processes
Handle Vendor DR/CR Notes HI_FI_AP_03_02
Schedule/ Plan for Vendor
HI_FI_AP_03_03
Payments
Handle Vendor
Advances/Deposits/Guarantees/ HI_FI_AP_03_04
Retention
Handle Vendor LCs HI_FI_AP_03_05
Process Vendor Payments HI_FI_AP_03_06
Process Vendor Account
HI_FI_AP_03_07
Confirmation
Accounts Payable Reports HI_FI_AP_03_08
1.5 SIGNIFICANT CHANGES TO THE CURRENT STATUS
The following processes are examined in the area of maintaining Accounts Payables Accounting by
ABC Company Finance Department:
Vendor Master
Payment Terms
Vendor Invoice Process & Vendor Payments

Advance to Vendor
LC Process
Retention to Vendor
Accounts Payable Report
Vendor Master: Vendor Groups are not maintained in current Accounting Software
Presently Vendor Master is maintained by Finance and Procurement Departments in separate

databases. No Integration between both databases.
Payment Terms:
Currently, the following Payment Terms are being used by ABC. ABC will open the L/C for Import
and Bank Guarantee in case of Domestic against Vendor.
ABC PAYMENT TERMS
CODE Payment Terms
AD01 100% Advance
Cash in Advance
50% Advance & Balance Before Delivery
50% Advance & Balance on Delivery
50% Advance & Balance on Completion
Cash against Documents
Telex Transfer
Payment on Delivery
CR01 30 Days Credit from Delivery Date
45 Days Credit from Delivery Date

ABC PAYMENT TERMS
BE01 B.O.E 60 Days from B/L Date
B.O.E 90 Days from B/L Date
B.O.E 120 Days from B/L Date
LC01 L/C 30 Days from B/L Date
L/C 60 Days from B/L Date
L/C Sight
Normally the payment terms are against the delivery, 30, 60, 90 or 180 days. Payment terms vary
material- wise, service-wise as well as vendor-wise. For some vendors and sub-contractors, the
terms of payments are back to back.
Payments terms start from the delivery date. In case imports vendors payment terms start from date
of Bill of Lading.
VENDOR INVOICE PROCESS AND VENDOR PAYMENTS: Vendor Invoices are paid through L/C
mostly. For making payments to vendor, CFO/ Financial Controller/ Accounts Payable
Manager/Project Manager Approval is required on original vendor invoice, and Accounts Manager
(A/P), Financial Controller and C.F.O approval required on payment voucher. If there is any
discrepancy in the vendor invoice, ABC Company returns the invoice to vendor for modification.
Retention money is applicable for some Vendors as per the Payment Terms
In case of domestic purchases, if any shortage, breakage of material, ABC Company returns
material along with invoice copy to vendor. Vendor will send revised invoice copy and replace the
material. In some cases vendor will be issued the Dr/Cr note.
Imports vendor issues Dr/Cr note in case shortage or breakage of material
Advance to Vendors: Advance payment is made after receiving the acceptance letter from vendor.
In some cases ABC Company requires a L/C from the vendor for making advance payment.
Accounts Payable Report: Accounts Payable reports are prepared in Venus Accounting Software
and MS Excel Spreadsheet.

2 BUSINESS PROCESS MODELING
2.1 CROSS PROCESS RELATED TOPICS
2.1.1 Information Carrier Model
Present all processes that the business blueprint examines in a structured format using three process
model levels. Handle the processes according to the various criteria.
Often, the structured descriptions of processes on the lower levels contain process variants that only
deviate from the main process in minor details, but which can later affect subsequent processes. In such
cases, decide whether it makes sense to include the variants in the process model.

2.2 PROCESS MODEL LEVEL 1, CORE AND SUPPORT PROCESSES <FINANCIAL ACCOUNTING>
This document explains the design of the Financial Accounting module. The document will describe how
Accounts Payable Master Data is maintained and used in FI and other all Integrated modules like CO,
MM, SD, PP, HR etc.,
The document will act as a single source of material for all future design including General Ledger Master
Data and Business Processes in SAP for project Project SAP H of Finance Department.
The document is based on the following:
Customer Inputs from Business Blueprint Workshop and Workshop Reports.

Consideration into account all valuable suggestions and ideas from subject matter experts.
Considering into past experience of SAP Consultant Team.
Deficient areas and approach to cover them from AS-IS Study
Discussions with ABC SAP IT Team.

2.2.1 Flow Chart:
FINANCIAL ACCOUNTING
GENERAL LEDGER ACCOUNTS ACCOUNTS ASSET BANK

ACCOUNTING RECEIVABLE PAYABLE MANAGEMENT ACCOUNTING
Maintain Chart of Process Customer Invoice Process vendor invoices

Create House Banks & Bank
Accounts Master Data Plan & Acquire Assets Accounts (Master data)
HI_FI_GL_01_02 HI_FI_AR_04_01 HI_FI_AP_03_01 HI_FI_AA_05_02
HI_FI_CABL_02_01
Handle Vendor DR / CR
Maintain Journal Entries /
Handle Customer DR/CR notes
Generate Parked Documents/ Develop Capital Projects
notes HI_FI_AP_03_02
Post Parked Documents/Post (AUC)
HI_FI_AR_04_02 Process Bank
with Reference/Post with HI_FI_AA_05_03 Reconciliation Statement
Clearing
HI_FI_CABL_02_02
Schedule/Plan for Payment
Follow up-on Receipts Due Refurbishment of Assets
HI_FI_GL_01_03/ HI_FI_AP_03_03
HI_FI_GL_01_05/ HI_FI_AR_04_03 Bank Cheques
HI_FI_AA_05_04
HI_FI_GL_01_06/ Management
HI_FI_GL_01_07/ Handle Vendor Advances / HI_FI_CABL_02_03
HI_FI_GL_01_08 Deposits / Guarantees
Handle Customer HI_FI_AP_03_04 Transfer of Assets
Maintain Recurring Advances / Deposits / Create Petty Cash Book
Transactions Guarantees HI_FI_AA_05_05 (Master data)
HI_FI_GL_01_04 HI_FI_AR_04_04 HI_FI_CABL_02_04
Handle Vendor L/Cs
Run Accrual and HI_FI_AP_03_05

Deferral Entries Run Depreciation Maintain Petty Cash
HI_FI_GL_01_09 Book Transactions
Process Incoming Payment
Process Vendor Payments HI_FI_AA_05_06 HI_FI_CABL_02_05
Run Month End Process HI_FI_AR_04_05
HI_FI_AP_03_06
HI_FI_GL_01_10 Cash Management
Retire Assets
Complete Customer Provide Vendor account HI_TR_CM_01
Reconciliation Confirmation HI_FI_AA_05_07
Run Year End Process HI_FI_AP_03_07
HI_FI_AR_04_06
Accounts Receivable Reports in Accounts HI_TR_CM_01
Financial Reports Reports in Asset Management
Reports Payable
HI_FI_AA_05_08
HI_FI_GL_01_12 HI_FI_AR_04_07 HI_FI_AP_03_08

2.3 PROCESS MODEL LEVEL 2, PROCESS GROUPS <ACCOUNTS PAYABLE ACCOUNTING>
Accounts Payable Accounting provides a comprehensive picture to Manage Vendor Accounting. It

Records all business transactions carried with Vendors in a software system that is fully integrated
with all the other operational areas of a company to ensure that the Vendor Accounting data is always
complete and accurate.
The Accounts Payable application component records and manages accounting data of all Vendors. It
is also an integral part of Materials Management.
All postings in Accounts Payable are also recorded directly in the General Ledger. Different General
Ledger accounts are updated depending on the transaction involved (for example, Receivables, down
payments, Retention etc). The system contains a range of tools that ABC can use to monitor open
items, such as account analyses, due date lists, and a flexible automatic payment program.
There are a range of tools available for documenting the transactions that occur in Accounts Payable,
including balance lists, journals, balance audit trails, and other SAP standard reports.
Accounts Payable will be having the close integration with the Materials Management component.
The processes identified are:
HI_FI_AP_03_01 Process Vendor Invoices

HI_FI_AP_03_02 Handle Vendor DR/CR Notes
HI_FI_AP_03_03 Schedule/Plan Vendor Payments
HI_FI_AP_03_04 Handle Vendor Advances/Deposits/Guarantees/Retention
HI_FI_AP_03_05 Handle Vendor LCs
HI_FI_AP_03_06 Process Vendor Payments
HI_FI_AP_03_07 Provide Vendor Account Confirmation
HI_FI_AP_03_08 Accounts Payable Reports
All of these processes also have associated/sub activities.

2.3.1 Flow Chart:
FINANCIAL ACCOUNTING
GENERAL LEDGER ACCOUNTS ACCOUNTS ASSET BANK

ACCOUNTING RECEIVABLE PAYABLE MANAGEMENT ACCOUNTING
Maintain Chart of Process Customer Invoice Process vendor invoices

Create House Banks & Bank
Accounts Master Data Plan & Acquire Assets Accounts (Master data)
HI_FI_GL_01_02 HI_FI_AR_04_01 HI_FI_AP_03_01 HI_FI_AA_05_02
HI_FI_CABL_02_01
Handle Vendor DR / CR
Maintain Journal Entries /
Handle Customer DR/CR notes
Generate Parked Documents/ Develop Capital Projects
notes HI_FI_AP_03_02
Post Parked Documents/Post (AUC)
HI_FI_AR_04_02 Process Bank
with Reference/Post with HI_FI_AA_05_03 Reconciliation Statement
Clearing
HI_FI_CABL_02_02
Schedule/Plan for Payment
Follow up-on Receipts Due Refurbishment of Assets
HI_FI_GL_01_03/ HI_FI_AP_03_03
HI_FI_GL_01_05/ HI_FI_AR_04_03 Bank Cheques
HI_FI_AA_05_04
HI_FI_GL_01_06/ Management
HI_FI_GL_01_07/ Handle Vendor Advances / HI_FI_CABL_02_03
HI_FI_GL_01_08 Deposits / Guarantees
Handle Customer HI_FI_AP_03_04 Transfer of Assets
Maintain Recurring Advances / Deposits / Create Petty Cash Book
Transactions Guarantees HI_FI_AA_05_05 (Master data)
HI_FI_GL_01_04 HI_FI_AR_04_04 HI_FI_CABL_02_04
Handle Vendor L/Cs
Run Accrual and HI_FI_AP_03_05

Deferral Entries Run Depreciation Maintain Petty Cash
HI_FI_GL_01_09 Book Transactions
Process Incoming Payment
Process Vendor Payments HI_FI_AA_05_06 HI_FI_CABL_02_05
Run Month End Process HI_FI_AR_04_05
HI_FI_AP_03_06
Retire Assets
Complete Customer Provide Vendor account HI_TR_CM_01
Reconciliation Confirmation HI_FI_AA_05_07
Run Year End Process HI_FI_AP_03_07
HI_FI_AR_04_06
Accounts Receivable Reports in Accounts HI_TR_CM_01
Financial Reports Reports in Asset Management
Reports Payable
HI_FI_AA_05_08
HI_FI_GL_01_12 HI_FI_AR_04_07 HI_FI_AP_03_08

2.4 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 1 PROCESS VENDOR INVOICES
2.4.1 Short Description of the Process
The Process of Vendor Invoices in SAP will be done in two instances.
Invoice against a Purchase Order

Invoice Without a Purchase Order
Invoice against a Purchase Order
The main aim of any invoice verification process is to ensure that vendors are paid the correct amount at
the right time (not too late but also not too early). The process should have a high incidence of first-time
matching to ensure that as little time as possible is spent trying to manually match invoices that appear
to be incorrect. It is important to include as few steps as possible in the process, considering that the
process of handling payments does not in itself add value to the company.
The main steps included in the process are:

Capture of the vendors invoice details
Matching of those details to the details that we believe to be correct
Investigation and management of any mismatches
Release for payment of validated invoices
Accounting entries (delivery costs)
Details recorded for audit purposes
It is important to keep these steps to a minimum and the SAP processes achieve this goal.
Invoice without a Purchase Order (Non PO Items)
This process defines the procedure of recording payables for non PO related supplier invoices.
Company receives vendor invoices that are not issued against a purchase order. Recording liability for
the companies purchases with a supplier, on receipt of supplier invoice with reference to an approval
document authorizing the purchase of such items.
It is also possible to post invoices from FI without the necessity of purchase order. That can be used to
fulfill the requirement of postings like miscellaneous payments, employee-related payments, travel agent
payments, hotel bills, and consultancy payments.

2.4.2 Business Requirements
The objective of Manage Account Payable (Vendor Invoices) is to ensure that all liabilities towards
vendors are recorded and paid accurately and in a timely manner as per Company policies,
procedures and contractual agreements.
The requirements are:
Single system to handle all Invoice transactions.
Single point of entry for all invoices to the Company
Reduction in paper invoices where practically possible through enabling technology.
Allow for payment outside the normal payment run
Automate postings of Difference in Exchange rate
Automate the clearing of vendor accounts and post banking ledger entries
Communicate payment details to banks
Allow payments to vendors with multiple bank accounts
Ensure all controls and checks have been performed when validating the Payment Proposal
Ensure segregation of duties between PO, GR, Invoice Entry and Payment Processing
Ensure that the PO process is used where a material or service is acquired
Ensure that once paid, an invoice is flagged to prevent any duplicate payment
Ensure that there is actual match between PO, GR/SR and Invoice.
Ensure tolerance levels have been defined properly
Identify due payments as and when required
Provide control reports to check for Overdue, Blocked and Parked invoices
Provide facility to reverse wrong entries made

Process Flow Diagram
HI_FI_AP_03_01 Process Vendor Invoices
Trigger
Point
Invoice Verification
Accounts Payable Accountant
Goods Receipt in
Materials Management YES Invoice Verification NO (FI Invoice)
(MM) Module with reference to
HI_MM_XX_XX Purchase Order
Verify & Park

Vendor Invoice
Schedule / Process
Clear Vendor
Accounts
Vendor Payment
Manager
Payable
Down Payments
HI_FI_AP_03_03
Post Vendor Invoice HI_FI_AP_03_04
HI_FI_AP_03_06

Process Steps Process Vendo r Invoice

Process Process Step Description Responsibility In SAP / Change
Step Outside management
Box No SAP required
(Process/System)
Invoice Decision needs to be AP Accountant Non-SAP Required at
verification with taken that, Invoice Process Level
reference to verification is with
1 Purchase Order reference to P.O. or
not? If, not FI Invoice
verification will be
done
Verify & Park Vendor Invoice AP Accountant SAP Required at
Vendor Invoice verification will be Process Level
done with reference
to contract / P.O. or
2
other ways. Required
data need to be
entered and park it.
Post Vendor Select the parked AP Manager SAP Required at

Invoice Invoice number, Process Level
3 which received from
AP Accountant. Verify
the details & Post
2.4.3 Written Explanation
2.4.3.1 Process of Logistics Invoice Verification of Vendor:

Posting LIV invoices for vendors should accommodate the majority of invoices in an organization.
LIV (Logistics-invoice-verification) invoices provide for a three-way matching between PO,
Goods/Service receipt and invoice. Here are some design features:
Recommendation for invoices to be received and processed centrally (Finance Division) wherever
possible
All LIV invoices must be associated with a PO number, otherwise the invoice is returned to the
vendors. If this is not common practice already, Organization Units should communicate this to their
vendors prior to go-live of this Blueprint. During the early stages of go-live or if returning invoices

with no PO is not an option due to logistical restrictions, then these invoices may be tracked via
Delivery note number. This situation should only exist during an interim period and thus is not
recommended as a medium to long term approach.
Validations ensure that invoices against vendors are only processed via LIV; hence an error is
issued if the invoice processor attempts to process the invoice within FI
Company code dependant validation may force the invoice processor to enter the House Bank (i.e.
the bank to pay from) upon invoice processing. Otherwise, the House Bank is selected
automatically based on payment method and currency while executing the automatic payment
program. The reason for the mandatory input of the House Bank at the time of invoice processing
would be to drive the Cash Requirements report, which would not provide information by House
Bank if the field is left blank.
A duplicate invoice validation should take place at the time of postings invoices. The check should
compare the invoice with posted documents where the vendor and reference (invoice number) are
the same. Hence, the invoice date and currency are removed from duplicate invoice check. Upon
finding a match, a warning message is issued listing the matching document(s)
Small differences tolerance, if required, should be active for all company codes, but the amount of
small difference allowed are left to the discretion of the Organization Units. These are meant to
take into account any rounding issues or decimal variances between the receipts and the invoice
value. The price difference tolerance, which allows update during invoice processing of the cost
(receipt) lines, should also be active for all company codes. Here, the lower limit is set by the
Organization Unit and allows for the reduction of the cost line (receipt) in cases where the invoice
price is lower than the receipt even though this situation is not common. However, the upper
tolerance should be set to 0 for all Organization Unit. Hence, if the invoice is out of small difference
tolerance and is higher in value than the receipt (due to price), then an error is issued and the
invoice must be held.
Vendor Retention is handled through standard SAP functionality via special retention payment
terms. When these payment terms are used, the vendor line is split into two open items, each
assigned to different payment terms defaulted from the special retention payment term.
For example a 10% retention payment term may result in one line item for 90% of the vendor value
available for immediate payment and another line item for the remaining value available for payment
after 45 days. The second line item may even be defaulted as blocked for payment. These
characteristics are specified against the special retention payment term.
OR

Development Logic will be decided after SAP note will be raised to meet ABC requirement
Discounts at invoice level are also handled via payment terms and are automatically booked as
revenue. Contract level discounts (e.g. volume discount) relating to materials and services though are
normally effected against the price directly.
Business Process Flow Chart

The LIV invoice processing flow is summarised below:
Process LIV Invoice for Vendor
Return Invoice
to Vendor
Receive No
invoice
PO number Register Invoice via
from
available? LIV
Trade Yes
(MIRO)
vendor
Record invoice details

(e.g. dates, reference,
amount) and
PO number
Post Invoice
Yes
File invoice
3 way matching hard copy
(PO: GR/SR: Inv) Within Post Invoice with
for audit
Achieved? tolerance small differences
Outside Select reason for Hold invoice for

tolerance Holding Further processing

Matching Invoice
Once an invoice is received with a valid PO number on it, it is processed through LIV. Invoice details are
recorded as follows:
Process Steps Matching Invoice

Field Status Use
Basic Data:
Invoice date Mandatory This is the date the invoice is received at the organisation. It is
defaulted into the baseline date which is used for start date of
computation of payment terms. Invoice date is also used to
determine the JV.
Posting date Mandatory This is the posting date which is defaulted to the day the invoice is
posted.
For held invoices which are released after the registry period has
been closed, the invoice processor needs to change the posting date
to the new accounting period.
Reference Mandatory This is the vendors invoice reference. It is used during the duplicate
invoice check and is a mechanism of identification, linking vendor
invoices to the ones registered within the Blueprint.
Amount Mandatory This represents the total invoice amount
Currency Mandatory The invoice currency, which may or may not be the same as the PO
currency. In Organisation Units where invoice currency is always
equal to PO currency, then a company code validation may be
activated to instate this
Item Text Mandatory Enter text to depict the department responsible for the invoice or the
reason for holding in cases of mismatch. This field is mandatory in
cases where an LIV invoice is held and appears within the held
invoices Blueprint report.
Other information may also include the responsible staff name within
a department or the nature of the invoice transaction.
PO number (or Receipt Mandatory Enter the PO number (or receipt number if available) to which the
number) invoice relates. This activates some defaults from the PO like the
payment terms, PO currency and receipted items to be matched.
Next to PO number, there is an icon marked with a right arrow which
enables the entry of multiple Purchase orders in the case where an
invoice relates to multiple Pos
Payment:
Baseline date Optional This defaults from document date, but may be updated if required. It

Field Status Use

represents the start date of computation of the payment terms which
normally begins from the invoice receipt date.
Payment Terms Optional These are defaulted from the PO if available or entered by the user.
Payment terms vary from immediate payment to payment due in x
days to retention type payment terms where a percentage of the
invoice is blocked from payment
Payment method Optional This determines the payment method. Generally left blank to be
derived by the automatic payment program; however, may be
manually entered or automatically substituted where necessary
Payment ref. Optional This field is generally used for certification
Part. Bank Optional This determines the bank that the vendor is paid to. A substitution
can be used to govern the contents of this field:
- if vendor is assigned only one bank, then no action is taken
- if vendor is assigned multiple banks, but only one in the currency of
the invoice, then the equivalent part. Bank (or bank type) is defaulted
- if vendor assigned multiple banks in the invoice currency, then a
pop-up appears to the user for bank selection
House Bank Optional This determines the bank to pay from. Generally left blank to be
derived by the automatic payment program; however, may be set to
mandatory per Organisation Unit (through a validation) where it is a
requirement to define the bank to pay from at invoice level.
The validation would ensure that House Bank is entered upon
posting vendor and customer invoice as well as down payment
requests and change documents (to avoid blanking). Customer
invoices are included in order to ensure matching during payment
program in cases where a vendor and customer are assigned to
each other.
Existence of house bank against vendor and customer line items
drives the Cash Requirement report, which will not have any house
bank information on it if this field is left blank.
Payee Optional This field determines alternative permitted payees. It only appears
during invoice processing if Permitted Payees are recorded within
the vendor master record.
Note that only permitted payees specified in the vendor master can
be selected when posting the invoice.
In cases where the Alternative Payee is entered on the vendor
master (at general data level or company code level), then this is

Field Status Use

always used for payment regardless of the permitted payee field
entered on the invoice.
If alternative payee is entered against the vendor master at both
levels (general and company code), the payment program utilises
the alternative payee recorded at the company code level.
Details
Unplanned delivery Optional In cases where goods have been receipted with freight and customs
conditions, but the invoice value is higher than the estimate made on
the PO, then the remainder may be input as unplanned delivery.
Invoice Party Optional The invoicing party (i.e. the invoice vendor) may be optionally
changed only in cases where freight & customs conditions apply
Assignment Optional Can be used for manual entry of Contract Number. This allows
invoice sorting per contract on the vendor account.
Otherwise, the assignment field is populated automatically based on
a default recorded against the G/L account master record entered in
the Sort Key
Upon entry of the associated PO number or receipt, the available receipted items appear for matching. In
cases where the invoice matches exactly with the receipts or to within a small tolerance, then the invoice is
posted directly and is available for payment through the next automatic payment run depending on the
invoice payment terms. Hence the three way matching provides sufficient control over invoice processing
with no further approvals necessary before payment.
Note that the actual invoice tolerance limit is determined by each Organization Unit; but is generally kept to a
small value or percentage to cater for any slight variances resulting from rounding or currency exchanges.
The invoice accounting entry is to credit the vendor and debit the GR/IR or SR/IR accounts. Other
automatic accounting entries may result depending on the invoice for example small differences. In
cases where the invoice is processed in a different currency than the PO or fixed exchange rate is not
selected on the PO, then realized exchange differences may also result from the invoice posting.
In cases where the invoice does not match with the receipts (i.e. out of tolerance), then an error message is
issued and posting terminates.


The process is summarised in the diagram below:
Process LIV Invoice for a Vendor
Report Delete held

What is the
held Incorrect invoice and
reason for
invoices Invoice return to
holding?
Vendor
Incorrect Unplanned
receipt delivery
Receipt
Receipt
available
unavailable
Post receipt Adjust PO Enter unplanned

price deliver amount
a) b)
a)
Reverse and
re - post Post Invoice
Execute (automatic
b) receipt
automatic block U)
Invoice
Post Invoice matching Post Invoice
Approve and
un - block
invoice
File invoice hard copy for audit
After investigation with the relevant department (mostly depicted by the purchasing group), if the invoice is
not a valid one, then the held invoice is deleted completely (transaction MR8M) and the hard copy returned
to the vendor. A Standard SAP report (transaction MIR5) for deleted held invoices can be used later for
reporting deleted / cancelled held documents for audit purposes.
If the invoice is a valid one, then there are either issue with the receipts or with delivery costs. Issues with
unplanned delivery costs are covered below.
If the receipts are not available (or not sufficient quantity posted), then the requesting department records
the receipts after confirmation of work done (either Goods Receipt or Approved Service Receipt) prior to the
re-matching of the held invoice. In-line with common business practice, it is assumed here that the POs
have been recorded and issued to the vendor prior to receiving the invoice. During early go-live, a transition
period may be necessary in order to record all outstanding POs with outstanding Goods Receipt.
Once accurate receipts are available, the held invoice may be matched manually or automatically (see
activity / sub-section Process Matching of Held Invoices).
If the receipts are available, but do not portray the correct values, then the issue is either with quantity or

price. For variances on the quantity, then either the invoice is incorrect; or the receipt. Either way, the
invoice is either returned to the vendor or the correct quantities are received (i.e. a top up of the quantities
as it is highly unlikely that more was receipted than is being invoiced. In any case, if such a scenario were
to occur, then the receipt must be reversed and reposted with less quantity).
If the mismatch is due to price, then the user has the option either to reverse the receipt, update the PO and
contract prices and then re-post; or adjust the price on the PO and contract without reversing the receipt,
which incidentally may be disallowed anyway in the case of stock materials that have already been issued.
In the latter case, held invoice matching can only occur through the automatic matching program (see
Process Matching of Held Invoices).
Stock, Freight & Customs
When dealing with stock related purchasing; stock quantities and handling charges need to be addressed.
Stock Related Invoice
Firstly, if a stock invoice is processed against a goods receipt where price variances exist (i.e. invoice does
not match with receipts), then the invoice must be held. Regardless whether the price variance is higher or
lower and assuming the invoice in this case is validated to be correct, the PO and contract prices are
updated to reflect these actual rates. This ensures that the prices on contracts and the PO are in-line with
the agreed rates so that subsequent planning and business with the vendor is more accurate and efficient.
After this update, if the invoice price is lower in value but within the Price Difference (PP) lower tolerance,
then the receipt line value on the invoice is reduced and the invoice posted as per normal. The resulting
accounting entry automatically reduces the stock value and material MAP (Moving Average Price) to the
invoice amount.
(In case of in-sufficient stock coverage i.e. if the available stock quantity is lower than the invoice quantity,
then the variance is posted instead to the price difference account, which in turn is manually cleared as part
of month end) Note that in the unlikely event that the difference here is larger than that defined by the PP
price lower variance tolerance, then an error will result and the goods receipt is either reversed and re-
posted as described in (a) below, or matched through the automatic matching program as detailed in (b)
below.
If the invoice is higher in value, then the user has two options:
a) Reverse the goods receipt and re-post with the correct rates. This allows direct invoice matching. Note, in
cases where material quantity in stock is less than the goods receipt quantity, then the goods receipt cannot
be reversed and hence option (b) below must be followed

b) Wait for the next scheduled execution of the automatic matching program which matches invoice price
with PO price and adjusts any variance from the GR. Here, the stock value is automatically adjusted as well
as an increase in the MAP in cases where stock qty is higher than invoice qty. Otherwise, the variance is
posted to the price difference account and manual clearing is required (provided that sufficient tolerance
limits are set in PP).
Import Delivery Charges (Landed Cost)
Import delivery charges are planned in PO conditions. These eventually become a part of material landed
cost. The LIV process shall handle the payment/ verification of these delivery charges
In line with accounting policies, material valuations must include handling fees so that stock valuations and
goods issues include these costs as well as material price. In some Organisation Units, handling fees may
amount to a significant percentage of the material price.
In this respect, the optimal solution is for the material MAP to include material handling fees as well as the
pure material price. Some material contracts include handling charges within the material price in which
case no special handling is required. Otherwise, the solution is to define freight and customs condition types
when setting up the contracts and POs. These represent an estimate of the handling fees and are posted at
the same time of the goods receipt (GR/IR style accounts). These conditions allow for the entry of a different
vendor than that on the main PO in cases where the freight or customs vendors are different than the PO
vendor. Note that later during invoice processing, the defaulted vendor information from freight and customs
conditions may be updated directly by the user. Hence, there is no hard control over the vendor that is used
to post freight and customs invoices.
Upon posting of the material good receipt with freight and customs conditions, the following elements result:
a) The MAP, and hence stock valuation, reflects price and handling fees
b) The estimate cost is realised at the time of receipt against material account
c) Open items are generated against the freight and customs GR/IR accounts awaiting invoice matching and
subsequent payment. Any difference between estimate & actual is posted to material stocks / price
difference accordingly, at the time of LIV.
d) Instead of estimate freight & customer charges, if actual charges are required to be a posted at the time
of GR then, LIV for freight & custom duty should be posted before GR

Processing of the invoices is best described by the process flow below:

Freight Related Invoices

Invoices
Receive Yes No Hold
PO number Register Goods Receipt
freight invoice Invoice
available? Invoice via available?
from Trade against PO
vendor LIV
No (MIRO)
Yes No
Return Invoice
to Vendor Has material
Invoice beenN No
Yes posted? o Is the
payment
Freight invoice Delivery
Freight invoice urgent?
lower? Charges
matches
exactly? Second Freight Yes
Reduce receipt Corresponding Invoice? Process
line (use FI charges Down
credit memo if Match invoice payment
outside PP Post Invoice with down request
tolerance) payment
Yes
Clearing in
Approve and Down No
payment next
Un-block
- payment
Post Invoice Post Invoice invoice exists?
run
Assuming the invoice arrives with a valid PO number, if there are no good receipts available, and then the
PO is held for further processing as per normal. In cases where the payment is urgent and cannot await a
good receipt, then a down payment request is processed and approved for payment. Otherwise, or once a
goods receipt is available, then:
a) If the invoice matches exactly the invoice is posted and is ready for payment during the next automatic
payment run
b) If the invoice is lower then the receipt line is reduced directly and the invoice is processed. Correcting
accounting entries result to reduce the P&L previously posted by the freight condition estimate. Note that in
this case, reverse and re-post is not an option as the freight conditions are generally determined as
percentages and not as fixed values. The amount with which the cost line can be reduced is managed by
the PP lower limit tolerance. If the cost line requires adjustment over and above the maximum allowed
amount, then the cost line is cleared as is and a correction subsequent credit memo is processed.
c) If the freight invoice is higher or second invoice then it is not possible to update the receipt lines as per
(b). This is because the upper limit tolerance (PP) is set to 0 for reasons previously explained. Reversing

the goods receipt is also not an option. Thus, the unplanned delivery field is used to record the difference
between the invoice and receipted lines.
The posting / accounting entries for unplanned delivery cost will depend upon the system settings in
customizing. Whether on material or separate G/L account?
ABCContracting Company has to decide during Realization phase that whether unplanned delivery cost be
posted on:
Material (distribute among invoice items)

Separate G/L account
Assuming the material invoice has been posted or is the same as the freight invoice, then unplanned
delivery can be used. The maximum allowed variance from the material line (or use of unplanned delivery)
can be controlled by company code by building appropriate custom transaction if no standard SAP
transaction exists for this. Note that if the freight invoice is a second or third that relates to the same item,
then the total invoice amount is entered as unplanned delivery assuming it is within the company code limits
to be set by the custom table. This is because the original line item would have been cleared by the first
processed invoice.
Also, the invoicing party field may be modified by the user directly in cases where the invoice vendor is
different to that stipulated by the freight condition.
If a down payment request exists against the invoice, then it is matched before the next scheduled automatic
payment run.
The change to the limits may be temporary in cases of one-off situations. Note that accounting entries
resulting from unplanned delivery adjust the stock value (or cost for direct purchasing) where the total qty in
stock is higher than the invoice qty. Otherwise, the difference is posted to the price difference account
awaiting clearing at month end.

Inter-company Invoice
Inter-company invoicing is a possibility from both LIV and FI, and is only relevant to Organization Units
where multiple company codes (or legal entities) are active. Inter-company invoicing may be required
for ABC in future, due to the following business requirements:
a) External Vendor payment is contractually restricted to a single company code regardless of which
company code the work is done. In this case, the invoice is posted as per normal against the vendor, but
against the paying company code (as in PO) rather than the company code where the Goods/Service
receipt was posted.
b) For vendors that perform work against multiple company codes, inter-company invoicing facilitates single
source payment for all work done for the Organization Unit hence allowing improved management of total
vendor liability by Organization Unit (across company code).
An invoice against the company code where the costs are originally charged to:
Debit GR-IR (for sub-sequent matching with receipts during automatic clearing)
Credit Inter-company Vendor (payment to be made to inter-company company code)
The vendor here represents the company code where the vendor line is booked for subsequent payment
The net effect of the transaction is that the company code where the work is done owes the inter-company
company code and not the trade vendor. This payment may be settled without any restricted payment terms
and at the discretion of the Organisation Unit depending on legal inter-company regulations. In turn, the
trade vendor payment is then consolidated with any other outstanding payments due to the vendor from a
single company code.
Process: Matching of Held LIV Invoices
Held invoice are matched with receipts once available. This can be done manually upon confirmation that
the reason for holding has been resolved;
Manual Matching
Based on the output of Held Invoice report, held invoices are accessed through transaction code MIR4 by
specifying the MM LIV number listed in the report output (or MIR6 for a held invoice listing). In the case
where matching is achievable, the document is moved to change mode (from display mode) and posted.
Process: LIV Invoice against Blanket PO (or no GR PO)
Blanket POs are used within Blueprint where required for low value high volume item purchasing e.g. office
equipment, flowers etc... Due to their nature, no receipting is required, allowing invoices to be posted
directly against the PO line items. This is also an equivalent process to any standard PO where the receipt

flags have been manually deactivated on the PO. Though this is not recommended, it may be applicable to
certain low value POs where receipting is not practical.
Upon receipt of an invoice against a blanket PO, the invoice is processed manually using MIRO. Invoice
amounts are limited to the PO value ceiling and are processed without a payment block. In other words,
invoices received within the PO value ceiling are approved for payment. Due to this risk, it is important that
the use of blanket POs is restricted to a small community of users who utilise the functionality for low value
items.
Note that since the use of blanket POs (or no GR POs) does not involve receipting, then any accruals
relating to services procured in this manner need to be posted manually as there is no mechanism for
creating service entry sheets which are the trigger to automatic accrual generation.

The process for FI invoices is summarised by the diagram below:
Process: FI Invoice for Vendors
Process LIV for

Vendor
Yes
Receive
invoice PO number Register Invoice via FI
from available? (FB60)
FI No
vendor
Record invoice details
(e.g. dates, reference,
Amount etc.,)
Post Invoice
(Automatic Block F)
Approve and Unblock File invoice

Invoice hard copy for
(Invoice Approver) audit
Invoice paid in next

scheduled payment
run
Upon receipt of the invoice, if a PO number is associated with the invoice, then the invoice must relate to an
MM vendor and should be processed through LIV. Otherwise if it is a valid FI only invoice, then it is posted

using transaction FB60. Due to the expected low volume of such invoices, they are posted directly to the
ledgers before approval; hence FI parking functionality is NOT used or can be used in some cases by ABC.
During posting, the invoice can be blocked through a blocking indicator block A FI Invoice. The
designated invoice approver(s) then have the responsibility of reporting against the blocked invoices, and
approving their payment by removing the payment block indicator. The list of blocked invoices may be
easily generated by executing transaction code FBL1N "Vendor Line item Display" and specifying the
blocking indicator in the selection criteria. Note that if the Invoice approvers record the FI invoices
themselves, then no blocking takes place and the posting is assumed approved for payment.
Inter-company invoices also can be handled by FI invoices. These invoices are generated by the Finance
Department. The payments are settled through the next scheduled execution of the payment program.
For single source vendor payment or payment by loan from another company code, inter-company FI
invoices can be used in a similar manner to that described above Inter-company Invoicing of this paper.
Invoice Processing depend on the particular business requirement and vendor relationships, variations to
invoice processing exist within the blueprint as summarised in the diagram below:

Process of Non PO related Invoice: (Process)
Process Name : Payable Posting For Non PO

Owner: Mr.Shafi Process Flow
Start
Concern Department
Collect Invoice
for purchases
Approval by
department
Manager/
Prepare PC
Receive
supplier
invoice, PC
Verify supplier
invoice & PC
Accounts Payable Finance Department
Approval by
No Yes
AP Manager
Inform concern Post supplier

Dept. invoice
FB60 Payable
doc.
End
Printing/filing
End

Business Process Step
Seq Task T-Code Freq In Charge Description
1 Receive Manual Daily Concern The invoice from the supplier for any
Invoice and department purchases without a PO will be received by
PC from buyer the buyer (employee of any department).
concern The invoice shall be supported with required
department approval documents from the department
manager, before forwarding it to AP
accountant.
2 Approval by Manual Daily Concern Upon receipt of purchased items the
concern department purchase invoice should be approved by the
department buyer department manager, to enable the
manager recording of companies liability in
accounting books.
2 Conduct Manual Daily AP The received documents should be
Physical Accountant physically checked for the consistency
check authorized approvals.
3 Approval by Manual Daily AP Verified documents may be forwarded to

AP manager Accountant the AP Manager for further approval to
create a liability to pay. Upon verification for
any issues arising there from the
documents should be reverted back to the
originator, department with proper
comments and concerns.
4 Inform Manual Daily AP In order to comply with mandatory
Concern Accountant requirements of the process the information
department regarding any concerns should be
buyer communicated to the originator, concern
department manager and further steps of
the process should be hold until the
concerns are clarified.
6 Post supplier FB60 Daily AP Upon confirming the invoice shall be posted
invoice Accountant to create a liability and update the supplier
account with reference to the physical
invoice sent by the supplier.
7 Printing & Manual Daily AP Print and file the documents if required for

filing Accountant official record.
The accounts department based on the invoices received from the vendors will process vendor invoices.
The following entry will be passed on approval.
Dr. Expenses Account
Cr. Vendor Account
2.4.4 Linked Processes
There is a direct link to GL Accounting, Accounts Receivable Accounting, and Cash Management.
And indirect link to all integrated modules likes CO, SD, MM, PM, PS, PP etc., to this General Ledger
Accounting.
2.4.5 Inputs (Event Triggers, entities, parameters)
Receive Supplier Invoice along with the copy of Bank Guarantee/Letter of Credit.
2.4.6 Outputs (Process Results)
Output Relevant Areas

1. Vendor Account Gets updated with the Invoice Payable Transaction Data
2. Updation of Bank Guarantee/Letter of Credit Usage Transaction Data
2.4.7 Process specific User Roles & Requirements for the Authorization Concept
Step Department User Role Process Description SAP T Code

# Module
1 Finance & AP Accountant Enter the required Purchase FI MIRO
Accounts Order and FI Data for Logistics
2 Finance & AP Accountant Enter the required data for FI FI FV65
Accounts (Invoice) and Park

Step Department User Role Process Description SAP T Code

# Module
1 Finance & AP Accountant Enter the required Purchase FI MIRO
Accounts Order and FI Data for Logistics
3 Finance & AP Manager Review & Post Parked Invoice FI FB60
Accounts
4 Finance & AP Manager View the FI Document, which FI FB03
Accounts posted thru MM LIV process if,
it posted with reference to a PO
in MIRO transaction as
subsequent debit
2.4.8 Quantification
In Terms of Quantification the Transaction and Data Volume will be considerably high and the frequency
of the transaction will be daily during the working hours.
2.4.8.1 Transaction and Data Volumes
Separate Transactions will be used in SAP for Invoice with Purchase Order and Invoice without
Purchase Order. The Data Volume will considerably high.
2.4.8.2 Frequency of the Processes
Frequency will be daily during working hours.
2.4.9 Measurable KPIs
The following sections describe the KPIs for the project
2.4.9.1 Status of KPIs before the Project
No current KPIs were seen

2.4.9.2 Target KPIs
Standard transaction recording and tracking process.
2.4.10 Improvements to the Process Compared to As-Is Status
ORGANIZATIONAL CHANGE IMPACT
Change AS IS TO BE in SAP
Impact
Summary
Process of Currently the Vendor Automated LIV Process which matches based on Goods
Vendor Invoice is being prepared and Services Received
Invoice in Excel Sheet/Word
Tolerance limits can be placed for Invoice Verification
Document.
Invoices not matched and outside the tolerance (Invoice
The Matching of the
amount against PO amount) limit will be parked,
Invoice is being done
investigated and then processed later.
manually against the
Purchase Order. All open items get cleared once payment is made
For Invoice without
The incorrect documents posted through other modules will
purchase order, a manual
be reversed by respective modules only.
JV is being passed in the
current Venus System.
2.4.11 Functional Deficits/Gaps
NIL
2.4.12 Notes on Further Improvements
NIL
2.4.13 Development Considerations

NIL
2.4.14 FRICE Considerations
2.4.14.1 Forms Considerations

NIL

2.4.14.2 Reports Considerations

NIL
2.4.14.3 Interface Considerations

NIL
2.4.14.4 Data Conversion Considerations

Vendor Master Data to be uploaded
Vendor Open Invoices to be uploaded
2.4.14.5 Enhancements Considerations

NIL
2.5 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 2 HANDLE VENDOR DR/CR NOTES
Debit Note will be raised for the following purposes:
Liquidated damages on Vendors
Interest on advance payment
Recovery in value of shortages, contamination, damages, penalties etc. is done from the transport
vendors in the event of accidents, lost vehicle etc. No debit note is required to be raised on the
transporters for normal shortages, because in such cases only net amount is posted to the
transporters A/c.
Recovery of certain service charges from the vendors in lieu of certain services provided.
Providing various facilities during execution of the Job, such as :-

Providing Guest House facility
Providing Car
Providing Air/ Train ticket
Providing power/water etc
Providing safety items
Making payment to third party
All Debits relating to procurement/services will be through MM
There are few cases where FI Dr notes are required to be raised

Liquidated Damages (LD) on Vendors

Recovery of Insurance Premium / Freight & Transportation charges etc. paid on behalf of
vendors
Claims recovery

2.5.3 Flow diagram
HI_FI_AP_03_02 Handle Vendor Debit / Credit Notes
Trigger
Need to create a
Point
Debit / Credit Note in
FI
1
Process Vendor YES NO (FI Dr / Cr Note)
Invoice Create a Debit / Credit
HI_FI_AP_03_01 Note with reference to
Purchase Order ?
Process Vendor
Invoice
HI_FI_AP_03_01
2
Verify & Park
Vendor Debit /
Credit Note in FI
Schedule / Process
Vendor Payment
Accounts
Manager
3
Payable
HI_FI_AP_03_03
Post Vendor Debit /
HI_FI_AP_03_06
Credit Note in FI

Process Steps Handle Vendor Credit Notes in FI

Process Process Description Responsibility In SAP / Change Remarks
Step Step Outside management
Box No SAP required
(Process/System)
Create a Whenever AP Accountant Non- Required at Based on
Debit/Credit Debit/Credit SAP Process Level nature of
Note with note needs to transaction AP
reference be created, is Accountant will
to it having select the
Purchase reference of transaction
Order Purchase
Order or not
decision will
be taken by
AP
Accountant
1 If Yes:
Create a
Debit/Credit
Note via MM
module
If No:
Create a
Debit/Credit
Note via FI
module
Verify & Vendor AP Accountant SAP Required at Information

Park Debit/Credit Process Level passed to AP
Vendor Note will be Manager to
2 Debit/Credit verified, enter approve and
Note in FI the data and post
only Parks for Debit/Credit
approval Note

Process Process Description Responsibility In SAP / Change Remarks

Box No SAP required
(Process/System)
Post Select the AP Manager SAP Required at AR Manager
Vendor parked FI Process Level can view / edit /
Debit/Credit Debit/Credit delete or post
Note note number, the Debit/Credit
which Note.
received from For MM
AP Debit/Credit
3 Accountant. Note parking &
Verify the Posting will be
details & Post done via MM
LIV process,
then
automatically FI
Document will
be posted
A debit memo is a transaction that reduces Amounts Payable to a vendor because; you send damaged
goods back to your vendor.
In SAP Vendor Debit notes are handled with Document type KG.
Debit/Credit note will have to be raised on Vendors for various reasons like return of goods, subsequent
debit, adjustment of short payable etc.,
Vendor Master with Materials Management (MM) module

General Ledger Accounting
Although, there is no direct link of these processes with other processes but these master records
become pre-requisite for certain processes.
Raising of a Debit/Credit Note with reference to Purchase Order (for Material / Service)
Raising a Debit/Credit Note without reference to PO (FI Credit Note)

All Debit/Credit notes relating to procurement/services will be through MM LIV process

There are very few cases where FI Credit notes are required to be raised for Some of them are :
Deposit transferred to the credit of vendors normal account.
Reversal of excess recoveries made by way of debit note
DR Memo of Vendor is updated for an approved transaction.
Step # Department User Role Process Description SAP T Code

Module
1 Finance & AP Enter the required data for FI FV65

Accounts Accountant FI Credit Note and Park
2 Finance & AP Manager Review & Post Parked FI FB65

Accounts Invoice.
3 Finance & AP Manager View the FI Document, FI FB03

Accounts which posted thru MM LIV
process if, Credit note
posted with reference to a
PO in MIRO transaction
In terms of Quantification, the posting of DR/CR Notes for Vendors will be considerably less.
The Transaction and Data Volumes is very less in number in respect of Vendor DR/CR Notes.
The frequency of the Vendor DR/CR Postings will be as and when required as per the Business
requirement.

No current KPIs were seen
2.5.10.2 Target KPIs
Easy transaction posting

Eliminating user risk of non approvals and non recording of a transaction.
Flexibility of change and deleting park/hold documents

Change Impact AS IS TO BE in SAP

Summary
Vendor DR/CR Currently Vendor Vendor DR/CR note is linked to MM Module and an
Notes DR/CR Notes are automatic entry gets passed through the integrated
being posted Module.
manually as JV in
Venus System. Facility of posting DR/CR note through FI also possible.
Document Currently the In SAP there are two ways to reverse a document. 1.
Reversal Journal Entry is Individual Reversal and 2. Mass Reversal.
being posted
manually in Venus
Documents originated at different modules will be
System.
reversed from respective module only.
Open Item Currently in the Vendor Accounts which are maintained in SAP can be
Clearing Existing Venus managed through this Clearing functionality.
system there is no
facility of Vendor
Period end (Daily, Monthly, Quarterly, Half Yearly and
Clearing.
Annual) schedules to Vendor Accounts can be taken
directly from the system (list of Vendor open items after
manual clearing is done).


NIL

NIL

NIL

NIL

NIL

NIL

Vendor Opening Balances to be uploaded

NIL
2.6 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 3 HANDLE VENDOR

ADVANCES/DEPOSITS/GUARANTEES/RETENTIONS
2.6.1.1 Vendor Advances:
This process defines the procedure of effecting down payments to suppliers. As per the agreed
payment terms with the supplier, ABC pays advances to suppliers after creating a PO and receiving a
Bank Guarantee/LC from the Vendor. The advances are paid on the Down Payment request of
Procurement department with reference to the PO terms. Advances are issued by the accounts payable
department to the supplier and recorded in the supplier account and the same shall be cleared at the
time of supplier invoicing.
2.6.1.2 Vendor Deposits:

This process defines the procedure of effecting Vendor Security Deposits. As per the agreed payment
terms with the supplier, ABC will record the receipt of Deposit from Vendor against the agreed terms of
the Purchase Order as a performance Guarantee. Deposits will be cleared after the satisfactory
execution of the deliverables by the Supplier.

2.6.1.3 Bank Guarantees:

Guarantees made / received with Procurement / Service / Sub-Contract Vendors as per agreed/
approved terms & conditions. These Guarantees will be cleared at the end of the Contract / Agreement.
Guarantees are providing by the Banker upon the request of ABC from the Overdraft / Credit Limit of
the Company. So, it will not affect the Books of Accounts. It is just a Contingent Liability
2.6.1.4 Vendor Retention:

This process defines the procedure of effecting Vendor Retention. As per the agreed payment terms
with the supplier some percent of amount is retained (withheld) by ABC as a performance guarantee.
The Final amount will be released to the Vendor after the satisfactory deliverable by him. ABC will
record the Retention payable to Vendor in a separate GL Account for efficient tracking of the Retention
Amount against the Purchase Order.
The following Business Requirements of ABC will be fulfilled with the below:
Such Payments to Vendors will be clearly recorded as Advance/Deposit/Guarantee/Retention.
Revenue & Capital Advance should be appropriately noted. (At the transaction level)
It should be paid against approved Purchase Order (including contracts) as per the terms agreed.
Only in rare cases with specific approval, the advance payment will be made to the vendor without
reference to the purchase order.
Advances should be cleared against running bills/Final Invoice as applicable. In some cases, a particular
% (say 10%) advance is given for total contract. Billing is done in parts; in such cases that particular
% (in our case 10%) of advance will be required to be cleared from subsequent Billing.
System should give a report on vendor wise down payment/Deposits/Guarantees/Retention required to be

made against a PO/SO.
Vendor account should display down payments outstanding separately.
Vendor Account should display Deposits/Guarantees/Retention separately
Balance Sheet should display Down Payments separately.
List of Unadjusted advance as on date-Report per vendor/ purchase order wise.
Link of advance voucher with purchase order for control purpose.
Special GL indicator will assist in displaying Guarantees Vendor Wise/Down Payment wise.

Integration of GL with sub ledgers (AP) will ensure in displaying Guarantees as Contingent Liability
(Footnote of the Balance sheet) but, not as the item of P&L or Balance Sheet
Guarantees with Vendors will be clearly recorded as Noted Items in SAP
Noted Item is the item shall not cover under P&L account or Balance Sheet
All types of Guarantees will be having two special G/L Indicator G for Guarantee.
It should be paid / received against approved Purchase Order (including contracts).
In Vendor account, outstanding Guarantees should display separately
Balance Sheet should display Incoming / Outgoing Guarantees separately
List of Guarantees per vendor wise can display
Such Guarantees will be cleared upon the due date or closing date as per terms of agreement
User dept will be releasing Retention money as per Contractual terms & conditions.
Retention will be having special GL Indicator R for Retention.
Payment will be released by FI as per Payment process.

2.6.3 Flow diagram
(HI_FI_AP_03_04) Handle Vendor Advances (Down Payments)

Trigger
Point
Start
1 2
Vendor makes a Central

request for down Procurement
payment against Dept. logs
a valid PO No. the request
in the system
3 NO
Whether terms of the PO
matches with the request
YES
Process Vendor
payment YES 4 NO
Accounts
Manager
STOP
Payable
HI_FI_AP_03_0 Get approval

6
END

Process Steps
Step # Departmen User Role Process Description SAP Module
t
1 Central MM Users / Purchase Orders are placed or agreement is MM

Procureme Vendor entered in to with the Vendor as per agreed
nt terms & conditions. And Vendor makes a
request for down payment against this valid PO
2 Central MM Users The Purchase user with reference to MM/FI

Procureme PO/Contract will create request for down
nt payment with appropriate Special GL indicator.
3 Finance AP Whether terms of the PO matches with the FI

Accountant request or not? Need to check manually. And If,
approval required send request to approve
outside system
4 Finance AP Manager Validate the details and approve the same for FI
payment. If not the request can be deleted in
system
Finance AP Once approved, down payment will be made by FI

Accountant Finance Dept with reference to Down Payment
Request created as above. This will post
accounting document debiting Vendor with
Special GL indicator & net amount will be paid
crediting Bank outgoing payment GL account.
Finance AP Manager Down Payment clearing will be done from FI

Running bills/Final bill as applicable. This will
debit Vendor normal item & credit Vendor
Special GL Item.
Pending Down Payment requests will be
Finance AP Manager FI
analysed & same should be cleared (paid /
reversed) immediately.
Finance AP Manager Vendor Line item can be displayed for normal FI

items / Special GL Items.

Down payment request will be raised by Central Procurement Department and clearing in the system shall
be made by Finance Department
Down payment shall be authorised manually by the approver.
System should show details of any advances paid against the same purchase order.
System shall verify the following before release of down payment :-
o Security Deposit in any form
o Previous open down payments.
o Any bank guarantees received
o Any Letter of Credit opened against Vendor
Down payments are made to various types of vendors i.e. Procurement/ Services/ Contractors/
Transporters/ Foreign/ Inter Company etc.
System Consideration: Advances/Deposits/Guarantees/Retention will be handled through Special GL

Indicators in SAP.
2.6.4.1 Vendor Deposits:
Vendor Deposits Scenario does not exist/applicable for ABC.
2.6.4.2 Guarantees:
Guarantees will be treated as Noted Items. . Guarantees made / received with Procurement / Service /
Sub-Contract Vendors as per agreed/ approved terms & conditions. These Guarantees will be cleared at
the end of the Contract / Agreement.
Guarantees are provided by the Banker upon the request of ABC from the Overdraft / Credit Limit of the
Company. So, it will not affect the Books of Accounts. It is just a Contingent Liability

2.6.4.2.1 Process Flow Chart Guarantees
(HI_FI_AP_03_04) Handle Guarantees

Trigger
Point
Vendor Start Bank Vendor
2
MM Users
1 Central Procurement
Vendor makes a Dept. raise the request
request for outside the system to
Guarantee against provide the Guarantee to
a valid PO No. Vendor as per
agreement
Accounts Payable
5
Accountant
3 Prepare required
Whether terms of the document for
PO matches with the Banker and make
request a request to
provide Guarantee END
6
4 YES Bank Provides
Accounts
7
Manager
Payable
Get approval Guarantee / Bond Post Vendor

as per request and Guarantee as
NO submits to Vendor Noted Item
STOP

Guarantee request will be initiated by Vendor with concerned Procurement Department for the respective PO / SO / Contract
Guarantee request will be raised by Central Procurement Department at outside of the system
Guarantee shall be made & maintained by Finance Department in the system
Finance Department will prepare required documentation and place a request with the Banker to Open a Letter of Credit/Guarantee
Receives the Guarantee form from the Banker & submit the same to particular Vendor by Finance Department
Vendor Guarantee will be recorded as a Noted Item and recorded with a special G/L Indicator
Guarantees are made to various types of vendors i.e. Procurement/ Services/ Contractors/ Transporters/ Foreign/ Inter Company etc.
Guarantees will be cleared in the system, as per or after the completion of term/ agreement
Process Steps : Handle Vendor Deposits/Guarantees

Step Department User Role Process Description SAP Module

#
1 Central MM Users / Purchase Orders are placed or agreement MM

Procurement Vendor is entered in to with the Vendor as per
agreed terms & conditions. And Vendor
makes a request for Guarantee against
this valid PO / agreement

Procurement PO/Contract will create request for
Guarantee via various communication
channel

Accountant request or not? Need to check. And If,
thru communication channel
4 Finance AP Manager Validate the details and approve the same FI

to provide Guarantee in concerned Bank. If
not the request will be stopped.
5 Finance AP Once approved, AP Accountant prepares FI

Accountant required document to open Guarantee in
the respective Bank and submits in Bank
6 Finance AP Manager Receives the Bank Guarantee document FI

from the Bank and submit the same with
the Vendor
Bank Guarantee provided to Vendor will be
7 Finance AP Manager FI
recorded in system with a special G/L
Indicator and as a Noted Item
2.6.4.3 Retention:
Retention money deducted from Vendors running bills as per the terms of contract is required to be
released with last invoice on completion of work satisfactorily.

2.6.4.3.1 Process flow chart Retention
(HI_FI_AP_03_04) Handle Vendor Retention

Trigger
Point
Vendor Start Bank Vendor

MM Users
1 2
Vendor makes a Central Procurement
request for Dept. raise the
Guarantee against request outside the
a valid PO No. system to provide
the Guarantee to
Vendor as per
Accounts Payable
agreement
Accountant
5
Prepare required
document for
3
Banker and make
Whether terms of the END
a request to
PO matches with the
provide Guarantee
request
6
4 YES Bank Provides
Accounts
7
Manager
Payable
Get approval Guarantee / Bond

Post Vendor
as per request and
Guarantee as
submits to Vendor
NO Noted Item
STOP

When Invoice verification done thru FI Invoice only or LIV (MM), user can select the amount or percentage
of retention for that particular Invoice.
Normally the Invoice Verification Entry will be (e.g,):
Purchase/Inventory a/c .. Dr 500 /
Vendor a/c Cr 500 /
The full Invoice amount (including retention amount) has to enter in Invoice verification transaction
Whenever the Invoice document posted, with the taking the reference of that posted document number a
back-end document will be posted by system automatically (This Development is doing to fulfil the special
requirement of ABC Company Limited, which are mentioned in the following)
Retention Invoice Verification Entry will be (e.g,):
1) Purchase/ Inventory a/c .. Dr 500 /
Vendor a/c . Cr 500 /
If, User selected 5% on the Invoice Verification Screen and posted the document then the following entry will be
posted by system in back-end:
2) Vendor a/c . Dr 25 /
Vendor a/c (R) .. Cr 25 /
(R) is the Special G/L Indicator for Retentions
The back-end Document will be the FI document and posts with a special G/L Indicator R (Retention) with
a blocking indicator
In Vendor Account the Retentions will appears in another tab than normal Items tab. And normal open items
will appear as excluding retention amounts
In Balance Sheet Retention Payable item will appear separately under current liabilities (This is the special
requirement of ABC)
Normally Retention money is released in full or partly after completion of specified period or defect liability
period along with the final bill.
If the Contract with the vendor permits, retention money may also be released on submission of Letter of
Credit/Bank Guarantee (BG) during execution of the job / before expiry of defect liability period.

In case of any defect in quality of goods or services delivered by the vendor, the retained money is not
refunded /refunded partly to the vendor. The amount not refunded is treated as credit to relevant expenses
where original amount was debited and this will be recorded manually.
Finance Manager in Finance Dept. will remove Payment Block in the system for releasing the money.
Process Steps Handle Vendor Retention

Step # Department User Role Process Description SAP
Module

Procurement Vendor entered in to with the Vendor as per agreed
terms & conditions. And Vendor makes a
request for Guarantee against this valid PO /
agreement

Procurement PO/Contract will create request for Guarantee
via various communication channel

Accountant request or not? Need to check. And If, approval
required send request to approve thru
communication channel
4 Finance AP Manager Validate the details and approve the same to FI

provide Guarantee in concerned Bank. If not the
request will be stopped.
5 Finance AP Once approved, AP Accountant prepares FI

Accountant required document to open Guarantee in the
respective Bank and submits in Bank
6 Finance AP Manager Receives the Bank Guarantee document from FI

the Bank and submit the same with the Vendor
Bank Guarantee provided to Vendor will be
7 Finance AP Manager FI
recorded in system with a special G/L Indicator
and as a Noted Item

The following Special GL Indicators are used for ABC for Handling
Advances/Deposits/Guarantees/Retention.
Special GL Indicator Account Type Description
A K Advances
D K Security Deposits
G K Bank Guarantees
R K Vendor Retention


The process of Handling Down Payment has a direct link with MM and CO Module.
Process Name : Supplier Down Payment Process

Owner: Mr.Shafi Process Flow
Procurement Department
Create Down
Start payment request
F-47
Retrieve pending
Check PO terms
requests
FBL1N ME23N
AP Manager
No Yes
approval
Post down
Inform payment
Procurement Paymnt
F-48 Doc
End
Print Check/
Check Bank Transfer
Bank transfer
Print Bank
Print Check
Transfer
FBZ5 FBZ5
Bank transfer
Check delivered delivered to bank
Printing/filing
to buyer
Procurem
ent
Process

1 Create down F-47 Daily Buyer A supplier down payment request shall be
payment created with reference to a PO, as per the
request agreed terms. The request so created
appears in supplier account automatically for
further processing to be done by AP
accountant.
2 Retrieve FBL1N Daily AP This report details the number of down
pending Accountant payment request existing against each
requests supplier due for payment
2 Check PO ME23N Daily AP Each payment request will be created with
terms Accountant reference to a PO. The AP accountant shall
check the PO for the compliance of terms
mentioned in the PO.
3 Approval by Manual Daily AP manager A final approval to release payment shall be
AP manager given by the AP manager. For any issues the
AP manager shall hold the approval and the
same shall be informed back to the
procurement department.
4 Post down F-48 Daily AP Upon approval of AP manager a down
payment Accountant payment entry will be posted to the suppliers
account. SAP classifies the down payments
as special GL transaction recorded in a
separate GL determined by the system
automatically.
6 Print a FBZ5 Daily AP A check or a bank transfer shall be printed
check/bank Accountant subsequently for each down payment posted.
transfer form
7 Check Manual Daily AP The down payment check printed shall be
delivered to Accountant signed and delivered to the buyer. A copy of
buyer the same shall be filed for record.
8 Bank transfer Manual Daily AP Bank transfer form shall be delivered to bank
form Accountant on daily basis.
delivered to
bank

9 Printing/filing Manual Daily AP Checks and bank transfer copies printed and
Accountant filed for official record.
Down Payment is updated to the Vendor Account
Deposits/Guarantees/Retention are updated to vendor Account
Step # Department User Role Process Description SAP Module

Procuremen Vendor entered in to with the Vendor as per agreed
t terms & conditions. And Vendor makes a
request for down payment against this valid PO

Procuremen PO/Contract will create request for down
t payment with appropriate Special GL indicator.

Accountant request or not? Need to check manually. And If,
outside system
4 Finance AP Manager Validate the details and approve the same for FI
payment. If not the request can be deleted in
system
Finance AP Once approved, down payment will be made by FI

Accountant Finance Dept with reference to Down Payment
Request created as above. This will post
accounting document debiting Vendor with
Special GL indicator & net amount will be paid
crediting Bank outgoing payment GL account.

Step # Department User Role Process Description SAP Module
Finance AP Manager Down Payment clearing will be done from FI

Running bills/Final bill as applicable. This will
debit Vendor normal item & credit Vendor
Special GL Item.
Pending Down Payment requests will be
Finance AP Manager FI
analysed & same should be cleared (paid /
reversed) immediately.
Finance AP Manager Vendor Line item can be displayed for normal FI

items / Special GL Items.
In Terms of Quantification the Transactions and Data Volume in respect of Down Payment
Requests/Down Payments/Deposit/Guarantees/Retention will be considerably high
Individual Transactions need to be performed for Down Payment Request/Down

Payments/Deposit/Guarantees/Retention for which Data Volume will be considerably high in nature.
The Transactions of Down Payment Request/Down Payment/Deposit/Guarantees/Retention will be

performed daily as per the Business Requirement.
No Current KPIs were seen.
Less time consuming
Automation of postings.
Reduce user work load.


Summary
Advances/Deposit/G Currently the Journal Down Payment Request automatically gets generated
uarantees/Retention Entry is being posted from MM Module.
manually in Venus
Down Payment Request will be converted to Down
System.
Payment and post to Financial Accounting.
Advances/Deposits/Guarantees/Retention will be
handled in SAP through a Special GL Indicator.
Special GL indicator will assist in displaying Guarantees

Vendor Wise/Down Payment wise.
Integration of GL with sub ledgers (AP) will ensure in

displaying Guarantees as Contingent Liability (Footnote
of the Balance sheet) but, not as the item of P&L or
Balance Sheet
Special GL indicator will assist in displaying Retentions

Vendor Wise
Vendor account open item wise analysis can be done

for blocked items

displaying Retentions as Current Liability under Balance
Sheet

2.6.12 Gaps in the process Coverage
Automatic posting of Retention JV
2.6.13 Organization change for further Improvements

NIL
User Exit to post Retention JV
Forms if any yet to receive from Accounts Payable Department
Reports if any, yet to receive from Accounts Payable Department

NIL
All the Advances/Deposits/Guarantees/Retention provided to Vendors are uploaded using data

migration program during the Go-Live phase.
All the Retentions of Vendors are uploaded using data migration program during the Go-Live phase

NIL

2.7 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 4 HANDLE VENDOR LETTER OF CREDIT
This scenario describes the process of importing goods into your country using a letter of credit for
payment.
Noted Items:
Special G/L transactions are also used to manage noted items. These are postings that are not
displayed in your accounts but are only to remind you of outstanding payments due or to be made. This
special document does not update the account balance: it is merely managed as a line item in the open
item account and the special G/L account. Because of it should always mark the Line item display option
for these G/L accounts.
Letter of Credit will be opened with reference to PO
A request will be raised from Procurement Department to Open Letter of Credit.
User should be able to decide the amount limit for which Automatic payment run should be done.

2.7.3 Flow diagram
HI_FI_AP_03_05 Handle Vendor L/Cs

Trigger
Point
Vendor Start
1 NO
Request to 2
end
open Letter of Approved L/C?
Credit
YES
4
Receive & Request the Banker 3
Accounts
Manager
Payable
Send L/C to open L/C with Create a L/C when opened

NON-SAP submitting required new L/C with special G/L
Documentation Indicator
NON-SAP
5
Clear the L/C when
closed with using
different posting key
end

Process Steps Letter of Credit

Process Process Step Description Responsibility In SAP/ Change Remarks
Box No SAP required
(Process/System)
Request to Procurement MM User NON- Required at Upon request
open Letter of Department SAP Process Level of Vendor,
Credit will request procurement
with the department
Finance Dept. will intimate to
to Open a Finance
1 Letter of Department
Credit upon
the request or
details/
agreement
with the
vendor
Approved L/C? Check the AP Manager NON- Change Authorized
details of SAP Management personnel
agreement/ approval is
contract, required to
terms & open a Letter
2 conditions, of Credit and
eligibility etc., budget also
and make a should allow.
request for
approval if,
required
Create a L/C Create a L/C AP Manager SAP Required at Statistical
when opened as Statistical Process Level Posting shows
new L/C with Posting with the Liability
special G/L mentioning under Vendor
3
Indicator special G/L Account and
Indicator as well as
Contingency
Liability
Request the Prepare the AP Manager NON- Required at Based on
4
Banker to required SAP Process Level chosen Bank

Process Process Step Description Responsibility In SAP/ Change Remarks

Box No SAP required
(Process/System)
open L/C with documentation documentation
submitting and request to and request
required open a Letter letter need to
Documentation of Credit. be submitted
Receive the to Banker.
same from the Finance Dept.
Banker to will receive
submit with L/C and
Vendor submit with
Vendor
Clear the L/C Clear the AP Manager SAP Required at When
when closed Statistic Process Level information
with using posting, when receives from
5 different L/C cleared Banker this
posting key transaction
need to be
performed
Import Involving a Letter of Credit
As an importer, ABC request a quotation from the exporter for the products/ goods want to purchase.
This may or may not include transportation and insurance costs.
Once ABC receive the quotation, it creates a purchase order based on the offer ABC received from the
exporter.
The exporter creates a pro forma invoice and sends it to ABC.
Upon the receiving of the vendor pro forma invoice (finance / procurement dept.) procurement
department requests the finance department via various communication channels to open a Letter of
Credit.
ABC open a letter of credit with the opening bank in the country of destination (Import country). This
involves informing the opening bank of the documents which ABC require from the exporter. As an
importer company not only need the documents required by customs, but also the documents that are
required by any other agencies regulating concerned good.
ABC creates a Letter of Credit in SAP as a Noted Item (single line item).

Noted Item will not update the Books of Accounts. The entry will be as follows:
ABC get import Letter of Credit to provide its vendors with the banks undertaking that they will receive
payment upon delivery of those documents specified in the Letter of Credit within a stipulated time. For
ABC, as an importer, using a Letter of Credit reduces the risk of having to pay in advance for products/
goods or pay for any products or services that are not consistent with the product descriptions in the
Letter of Credit.
With Letter of Credit, the vendor does not need to ask for shipments to be secured by cash in advance
and ABC may obtain better pricing if the vendor is assured of a Letter of Credit.
The opening bank sends the Letter of Credit to the advising bank in the exporter's/ Vendors country.
The advising bank advises the exporter that a Letter of Credit has been opened in their favor.
The exporter/ vendor ships the merchandise in accordance with the terms stipulated in the Letter of
Credit.
The exporter gives the documents proving that the shipment was made in conformance with the letter of
credit to the advising bank.
The advising bank pays the exporter based on the documents received.
The advising bank transfers the documents to the opening bank and receives payment.
The opening bank gives the documents to ABC (the importer). ABC clear the concerned Noted Item
ABC submits those documents to the clearing house agent to release the shipment.
And ABC performs the MM- GR process in SAP.
Letter of Credit process has no direct link with the Financials. It will be treated as a Noted Item for
Information and control in the Financial Books.
Company Code
Chart of Accounts
Vendor Groups & Accounts
House Banks & Bank Accounts
Special G/L Indicator for LC Noted Items
Letter of Credit posted as Noted Item against Vendor


Module
1 Finance & AP Manager Enter Noted Items & FI F-57

Accounts Cancel Noted Items
(with different posting
key)
In Terms of Quantification the transaction of Letter of credit posting will be as per the Business
Requirement as and when required.
The Transaction and Data Volume is comparatively less as and when Business requires.
The Transaction is posted as per the Business Requirement.
This Section explains the Measurable KPIs of the Project.
Currently no KPIs seen.
Less time consuming

Easy tracking of Letter of credit notes.
Reduce user work load

Change Impact Summary AS IS TO BE in SAP
Letter of Credit Currently Letter of All Letter of Credits will be posted into 1 G/L account
Credit are being
At the time of posting PO reference will be given so,
maintained
with that reference Opened Letter of Credits can be
Manually in a
tracked
Register
Open Letter of Credits can be monitored with the status
as Open or Close
Letter of Credit Control Register

NIL
To Check the feasibility of Development for LC Management Control Register

NIL

NIL

NIL

Open LCs are to be uploaded into the system at the time of GO Live.

NIL

2.8 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 5 PLAN/SCHEDULE VENDOR PAYMENTS
This process defines the process of Plan/Schedule Vendor Payments Automatically in the SAP
System.

The following Business Requirement will be fulfilled for ABC.
User should be able to define which vendors should be covered in automatic payment run.
User should be able to decide the amount limit for which Automatic payment run should be done.
Automatic payment run should also be done with respect to a specified date, say document entered
from and up to a particular date.
Automatic Payment run will be done at Company code / vendor account / at line item level.

2.8.3 Flow diagram
HI_FI_AP_03_03 Schedule / Plan for Payments

Trigger
Point
Run Proposal
Accountant
Accounts
Payable
1 2 3
Enter Available amounts and Run Proposal with Pass information to AP Manager
validate Ranking order Bank Automatic Payment with Proposal Run ID
wise Program NON-SAP
Accounts
Manager
Payable
5
4 Send Proposal List to 6 Process
Generate First Generate Final Vendor
Run Proposal and approving authority & Edit Proposal and
Proposal List Proposal List Payment
generate Receive approved schedule for Payment
Proposal List List Program Run HI_FI_AP_03_
NON-SAP 06

Process Steps Plan/Schedule Vendor Payments
Process Process Description Responsibility In SAP/ Change Remarks

Box No SAP required
(Process/System)
Enter Enter AP Accountant SAP Required at Delete the previous
Available available Process Level proposals if
amounts amounts in required
and Banks &
1
validate ranking orders
Ranking if required
order Bank before running
wise proposal
Run Enter AP Accountant SAP Required at Selection of
Proposal Proposal ID, Process Level Company Codes
with date then and Vendors etc.,
2
Automatic enter required parameters has to
Payment data and run select
Program proposal
Pass Passes the AP Accountant NON - Change Various
information information to SAP management communication
to AP AP Manager channels can be
3 Manager with Proposal used to perform
with Run ID for this
Proposal approval
Run ID
Run Select AP Manager SAP Required at Generate First time
Proposal Proposal ID Process Level Proposal List
and from received
4
generate information
Proposal and generate
List Proposal List
Send Proposal List AP Manager NON- Change Instruction
Proposal will be SAP Management forwarded to which
List to forwarded to vendors payment
approving approving need to make from
authority & authority for the authority
5
Receive final payment
approved along with
List available
amount etc.,
details
Edit Block the AP Manager SAP Required at Now it is ready to
Proposal unwanted Process Level run the automatic
and vendor payment program
schedule payments
for from the
Payment current
6
Program proposal and
Run make final list
and make
ready to run
the payment
program


As per plan, periodically Vendor Payment program has to run
If there are several house banks that to use for payment transactions and have limited funds in these
accounts, to plan the cash balances available for each bank account and specify the ranking order by
which the program is to use these accounts. In addition, because there are several house banks
available to the payment program it has to enter the order in which the bank accounts are selected
Once the parameters for the proposal run are completed, it can schedule for the payment proposal or
immediately can be done.
It is possible to make changes when editing the payment proposal. It can make changes to the payment
(payment method, house bank) and the items paid (block indicator, cash discount). All changes made
affected only in the payment proposal. No changes are made to the source documents


This process has direct Link to the Cash Management in Treasury Module and indirect link to the
Controlling Module.

Create Proposal
Edit Proposal
Execute Payment Run
Print Check

Vendor Automatic Payment Program is executed and checks will be printed.

Module
1 Finance & AP Manager Enter Available amounts FI S_ALR_87001486,

Accounts and set Ranking Order if
S_ALR_87001487
required
2 Finance & AP Enter the Parameters FI F110

Accounts Accountant and specifications in
Proposal Run
3 Finance & AP Manager Check & Run Proposal. FI F110

Accounts Generate the proposal
List
4 Finance & AP Manager Edit the Proposal after FI F110

Accounts receiving from
approving authority
5 Finance & AP Manager Run immediately / FI F110

Accounts schedule for payment
proposal

In terms of Quantification the transaction will be on a daily basis as per the requirement of the Business.
The Data Volume will be comparatively less for ABC.

Transaction and Data Volume for this process will be considerably less in nature

The Frequency of the Processes will be daily as per the Business requirement.

This section explains the Measurable KPIs of the Project.

Currently no KPIs seen

Automatic Proposal Run will be created and can be edited within less time.

Summary
Plan/Schedule Vendor Currently in the Proposal is the guide line to co-ordinate with available
Payments existing system funds in the organization.
there is no system Based on importance or Payment terms the payment can
for planning Vendor be selected or editing can be done.
Payment
Approval authority will be the final

displaying open items as on a particular run date
Documents will not be posted hence, the books of

accounts will not be updated


NIL

NIL

NIL

NIL

NIL

NIL

NIL

NIL

2.9 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 6 PROCESS VENDOR PAYMENT
This process defines the Vendor Payment Process in two methods.

1. Manual Vendor Payments
2. Automatic Vendor Payments

User should be able to define which vendors should be covered in automatic payment run.
User should be able to decide the amount limit for which Automatic payment run should be
done.
Automatic payment run should also be done with respect to a specified date, say document
entered from and up to a particular date.
Automatic Payment run will be done at Company code / vendor account / at line item level.
Payment document will be posted as and when the cheques are issued.
Cheques would be printed from the system for the banks that can achieve such by ABC
Company.
For all Banks, manual outgoing payment will also be made possible.
Payment Advice should be printed along with the cheque with individual line item, as shown
in the table below. Vendor should be able to find out from the payment advice, the
reasons for any short payment. For advance payment the Payment Advice shall mention
Advance Payment with text if required. The following details should be available in the
Payment advice.
Accounting Doc. No. Amount paid to the vendor

Accounting Doc. Date Details of any deduction
Vendors Bill/Invoice No. Remarks (Long text)
Vendors Bill/Invoice date User defined special message for the vendor
Vendors Bill/Invoice Amount
Cheques / document cancellation in exceptional cases will be done.

Periodic Summary report would be required for payments showing the details of date of
payment, Nature of expenses for which payment is made, Party code, Party name,
amount paid, bank and other payment details etc.

System should not allow payment run if the total amount of payment covered by the
payment run exceeds the clear balance in the bank a/c and/or overdraft limit unless it is
authorised by a higher authority.

2.9.3 Flow diagram Manual Payment Process

Process Name : Supplier Payments Against Invoice
Owner: Mr.M.Shafi Process Flow
Supplier/Procurement
Initiate payment
Start request
F-59
Prepare payment
due list
FBL1N
AP Manager
No Yes
approval
Payments
posting by
Hidada
Hold/ inform
concern dept.
Clear Advances
Clearing Clear Invoices

F-54/F-44
document
End F-53
Clear Invoices
Post
F-53 intercompany
Payment payments
document F-53
Post payments
Payment
document
F-53
Print Check/
Check Bank Transfer
Bank transfer
Check Bank transfer

delivered to form delivered
supplier to bank
Printing/filing
End

Process Steps Manual Payment

1 Initiate Manual Daily AP As per the agreed payment terms as

payment Accountant supplier may request for payment
request against the material of services
delivered.
2 Prepare FBL1N Daily AP On periodic basis a due payment list
payment due Accountant/P is prepared to plan for payment
list rocurement release
3 Approval Manual Daily AP manager Depending on the agreed payment
terms and the cash flow position the
AP manager may approve or hold
payments.
4 Hold/ inform Manual Daily AP If the payments are on hold the same
concern Accountant shall be communicated back to the
dept. concern department duly.
5 Clear down F-54/F-44 Daily AP All the down payments made to the
payments Accountant supplier are cleared as a first step to
make final payments to the supplier.
6 Clear F-58 Daily AP The supplier invoices to be cleared
invoices Accountant are selected on the basis of due date
and approval and cleared against the
amount approved for payment.
Invoices may be cleared partially or
fully.
7 Post F-58 Daily AP A payment document shall be posted
payment Accountant against the selected invoices
updating the supplier account.
Subsequently a check or a bank
transfer shall be printed and signed
for delivery.
8 Check Manual Daily AP The down payment check printed
delivered to Accountant shall be signed and delivered to the
supplier supplier. A copy of the same shall be
filed for record.
9 Bank Manual Daily AP Bank transfer form shall be delivered
transfer form Accountant to bank on daily basis.
delivered to
bank

10 Printing/filing Manual Daily AP Checks and bank transfer copies

Accountant printed and filed for official record.

2.9.4 Flow diagram Automatic Payment Process
( HI_FI_AP_03_06 Process Vendor Payments Automatic Payment Process )
Trigger Point Start
Automatic
payment run
GR/IR Data
System to generate a
proposal list of all the
vendors bills as per
the criteria by user
Collection System to check

and NO The list to be
whether appropriable
authorised by
Banking funds available on the
Head of A/cs
Process date of cheque issue
Accounts Payable
Manager
YES
Generate Automatic
Payment Payment
Advice Program
Posting to vendors
A/c, Printing of
cheque / For Bank In case of net NO
Transfer, generate transfer
whether E-
Letter
signatured ?
YES
Signing of END
Cheque / E- Post to vendors
signature ledger and also
credit by bank to
the vendor
Handover to
Vendor

Process Steps Automatic Payment

1 Initiate SBWP Daily AP As per the agreed payment terms as

payment Accountan supplier may request for payment against
request t the material of services delivered.
2 Prepare FBL1N Daily AP On periodic basis a due payment list is
payment Accountan prepared to plan for payment release
due list t/Procurem
ent
3 Approval SBWP Daily AP Depending on the agreed payment terms
manager and the cash flow position the AP manager
may approve or hold payments.
4 Hold/ SBWP Daily AP If the payments are on hold the same shall
inform Accountan be communicated back to the concern
concern t department duly.
dept.
5 Clear F-54/F-44 Daily AP All the down payments made to the
down Accountan supplier are cleared as a first step to make
payments t final payments to the supplier.
6 Clear F110 Daily AP The supplier invoices to be cleared are
invoices Accountan selected on the basis of due date and
t approval and cleared against the amount
approved for payment. Invoices may be
cleared partially or fully.
7 Post F110 Daily AP A payment document shall be posted
payment Accountan against the selected invoices updating the
t supplier account. Subsequently a check or
a bank transfer shall be printed and signed
for delivery.
8 Check Manual Daily AP The down payment check printed shall be
delivered Accountan signed and delivered to the supplier. A
to supplier t copy of the same shall be filed for record.
9 Bank Manual Daily AP Bank transfer form shall be delivered to
transfer Accountan bank on daily basis.
form t
delivered
to bank
10 Printing/fili Manual Daily AP Checks and bank transfer copies printed
ng Acountant and filed for official record.


Payments are required to be released to various organisations and/or individuals.
Payment document will be posted using automatic payment functionality for Banks specified
above.
Mode of payments will be Cheque, Bank transfer, Bank for payment against documents, or
through LC (letter of credit).
Following payments will be made :-
o Vendor Payments (Normal items, Down payment, release of Retention money, etc)
o Lease Rent
o Compensations
o Staff payments
o Statutory payments like Zakat etc.
Initially ABC will be using Manual Payment Process. But the Automatic Payment Program
Set up also will be available for future use.
Periodicity of payment Manual/Automatic run will be pre-decided for payment to each

category of vendors.
Finance Dept. will ensure to use correct payment terms, payment method, House banks &
check lots etc. for accurate payments.
Reimbursement to staff will be against Cash Journal, payment vouchers or direct bank credit
(if employees bank accounts are maintained).
Customer Refund/payment if any will be exceptional in nature & will be made only on specific
request/advice from Marketing.
All statutory payments will be through Vendor payments.
Other than Vendor payments will be through GL.
Vendors bills will be kept by Finance Dept as per LIV process.
Advances paid if any will be recovered from subsequent billing as explained in LIV process
Manual Payment/Payment Proposal/ exception list will be analysed & edited by Finance Dept.
if required.
Final payment document will be posted manually or by Automatic Payment Problem &
payment list will be printed.
Cheques will be manually written initially and in future cheques printed on pre-printed Bank
Cheque Stationery (pre-printed as a crossed a/c payee cheque) for cash withdrawals (i.e. for
self) the pre-printed a/c payee crossing will be manually opened.

Payment list & Cheque Register will be printed & signed by Cash officer.
Cheques will be signed by authorised signatories along with payment list/ cheque
register.
Cheque register will be available from the system. Payment vouchers will be signed
by Cashier & Payee wherever received directly.
Cheque/payment document reversals/cancellations would be done in exceptional

cases only.
Signed cheques together with Payment advice would be handed over /despatched to
Vendors /Staff etc.
As and when required the single payment can do through manual payment process even in
Future.
AP Manager enters the required data and select against/ reference line items and make the
payment for manual payment process
A payment against an invoice clears or settles the outstanding invoice amount in the vendor
account. System will display the list of open items or unsettled invoices from the vendor
account, for which the payments are due. Specific open items can be selected based on the
various parameter such as bill amount, due date, document ref no. etc. System will pass the
following entry on posting the payment against open item.
Vendor a/c Dr
To Outgoing Bank A/c Cr
Partial Clearing
There are instances of terms of the purchase that allow payment to be made to the vendor in
installments over a period of time. In these cases the outgoing payments made to the vendor may
not settle the invoice in full but only partially. If the Partial Clearing is used, system will post a line
item in debit for the payment made. The system however, will not clear the invoice till the entire
invoice amount is cleared and all such line items are shown as open items till the time it is fully
cleared.
However the disadvantage of using partial clearing method is that both the items i.e. the invoice
and the part payment in the above example remain open items. Hence the ageing analysis shows
skewed results as the invoice amount credit is shown from the date of the invoice date and the
part paid amount is shown as debit paid from the payment date.
Residual Clearing

Residual clearing is also used for clearing open items in case of part payment etc. In case of
residual clearing the system clears the open line item to the extent of payment made and
generates a new line item for the balance payable. The default baseline date for the new
document will be Residual document date; however, the date may be changed to any other date.
Supplier Retention Posting
There may be some vendors for whom certain % of the Purchase order value will be retained as
retention money and will be released only after a period of time. The Purchase Order shall
capture this information. The retention money shall be transferred from the normal balances to the
special GL balances in the vendor account. The system will also keep a track of all these
retention moneys and the due dates when they become payable. The retention money will be
distinguished by the use of a special G/L indicator. The financial entry will be as follows:
For example - There is a vendor invoice of SAR 10,000/-. A part payment of SAR 9,000 is made
for the invoice and SAR 1000/ is to be keep as retention money.
Vendor A/c Dr SAR 10000
To Bank A/c CR SAR 9000
To Vendor A/c (with special GL Indicator) CR SAR 1000
Whenever the retention money is to be released, the vendor a/c (with special GL indicator) will be
debited.
Exchange Rate Difference
In case of foreign currency transactions the difference in the invoice amount and the payment
amount will be accounted to either the exchange rate gain / loss account. The standard accounts
for loss and gain as defined in the Chart of Account shall be used for this purpose.
The following is an example of booking of import invoice in USD, its corresponding payment entry
and booking of the exchange rate fluctuations.
Invoice entry @ 3.70 SAR: 1 USD
Asset / Expense A/c DR USD 100 SAR 370
TO, Vendor A/c CR USD 100 SAR 370
Payment Entry @ 3.71 SAR: 1 USD
Vendor A/c DR USD 100 SAR 370
Exchange Rate Gain / Loss DR USD 0 SAR 1
TO, Bank CR USD 100 SAR 371
OR
Payment Entry @ 3.69 SAR: 1 USD
Vendor A/c DR USD 100 SAR 370

TO, Bank CR USD 100 SAR 369
TO, Exchange Rate Gain / Loss CR USD SAR 1
The following Payments methods have been identified for ABC:
Payment Method Description

C Check
T Bank Transfer

This process has a direct link with the MM, FI and indirectly link to CO Modules.
Document Header Data

Company Code
Bank Details
Amount

Manual Payment to Vendor
Automatic Payment to Vendor
Module
1 Finance & AP Manager Run Automatic Payment FI F110

Accounts Program
2 Finance & AP Manager Post Outgoing Payment, FI F-53,

Accounts Payment with Check
F-58
print
In terms of Quantification this process transactions and data volume will be considerably high.

The Usage of Vendor Payment Transactions and Data Volume will be considerably high


The Frequency of the Processes will be daily.



Process with accuracy and less time consuming.

Summary
Vendor Payment Currently there is Proposal is the guide line to co-ordinate with
Process no Automatic available funds in the organization
Payment Program Based on importance or Payment terms the
in the Venus payment can be selected or editing can be do
System.
Integration of GL with sub ledgers (AP) will ensure
The Checks are
in displaying open items as on a particular run
handled manually.
date

Documents will be posted automatically and the

books of accounts will be updated
Automatically Check numbers will be reserved

and printed the same
Re-print of check & Check register maintenance

can be managed
Vendor open line items will be cleared

automatically from sub-ledger and general ledger
will get updated

NIL

NIL

NIL

Check printing in Arabic or English along with Payment Advice notes in case of Automatic
Payment Process (Consideration for Future)
Bank Transfer Advice notes (Consideration for Future)

NIL

NIL

NIL

NIL

2.10 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 7 PROVIDE VENDOR ACCOUNT CONFIRMATION
This process defines the procedure of sending supplier account statements to suppliers.
Supplier accounts are updated with down payments, invoices, payments and clearing
transactions on real time basis. All such information is sent to supplier in a required, pre
defined and organized format. Supplier account statements are sent on periodic basis or as
requested by the supplier. A statement may be a supplier transaction history for a required
period, monthly account statement or an open item (due items) statement. Supplier account
statement may facilitate in updating a supplier of his till date transaction, periodic account
reconciliation.

Following Business Requirements are fulfilled by SAP for ABC.
Receive balance confirmation request from external auditors.

Prepare balance confirmation letter to supplier
Receive statement of account from the supplier
Reconcile this statement with our books

2.10.3 Flow diagram
HI_FI_AP_03_07 Provide Vendor Account Confirmation

Trigger
Point
Clear Vendor
Account
1
Automatic Manual
Vendor Account
Clear Automatic /
Run Month End Manual 2

Process Clear Manually
HI_FI_GL_01_10 Vendor Account
Generate Final
Vendor Account
Balance
Confirmation
3
Passed information
to AP Manager for
Review & Approve
NON-SAP
Accounts
Manager
Payable
4
Reviewed and
Approved the
same NON-SAP

Process Steps Vendor Account Confirmation

Box No SAP required
(Process/Syste
m)
1 Vendor Decision will AP Accountant NON- Required at If want to
Account be taken to SAP Process Level clear at
Clear clear Vendor month-end
Automati Account automatica
c/ lly or
Manual manually
as and
when
required.
Before
clearing
some
activities
need to be
validated.
2 Clear Vendor AP Accountant SAP Required at Vendor
Vendor Account Process Level confirmatio
Account should clear n list will
Manually as and when be sent for
required approval to
rather than AP
period-end Manager
process via
manual clear
process
3 Passed Generate AP Accountant NON- Required at Vendor
informati Vendor SAP Process Level Account
on to AP account confirmatio
Manager confirmation n letter can
for and send to also be
review &| AP Manager sent to
approve to approve or Vendor for
to make confirmatio
adjustments n of their


Box No SAP required
(Process/Syste
m)
account
4 Reviewe Review & AP Manager NON- Required at Is it
d& approve the SAP Process Level required to
Approved confirmation send or
letter, which not to send
need to be to vendor
sent to will be
Vendor decided by
AP
Manager

Periodically Vendor account items need to be cleared. Due to many reasons like:
Reference not matched while clearing

Partial payments made
The vendor account items may not appear as cleared items

At Month-end execute automatic clearing program with selecting required vendor
accounts and some parameters
As and when if required, need to clear the un-cleared line items in any Vendor account.
Select the required vendor account and clear it manually
Payments will be released by selecting open items/requests
Vendor account will be analysed & cleared, if required

Vendor Account Confirmation is directly linked to MM Module and indirectly linked to CO
Module in SAP.

Periodic schedule, request to send an account statement.

Account statement sent to supplier.


Module
1 MM MM Users Logistics Invoice FI MM

Verifications (LIV) are
posted in Vendor
account on
receipt/passing of bills
2 Finance & AP Manager While making payments F53/F-58/F110

Accounts through cheque to
Vendors, open item will
get cleared. In case of
payment by cash, it
needs to be manually
cleared.
3 MM MM Users If LIV is reversed, same MM

does not clear open
invoice automatically.
4 Finance & AP Manager Open item clearing will F-44 Manual Account
Accounts be done from the Vendor clearing,
account.
F.13 Automatic
clearing
In terms of Quantification prescribed transactions needed to be executed and the Data
Volume will be considerably high.

Prescribed Transactions should be executed for getting the required Vendor Confirmation
reports in SAP. Data Volume of Extraction is considerably high.

The Frequency of the Processes will be daily as per the Business Requirement.




Automated process and less time consuming.

Summary
Vendor Account Currently in the Open items analysis & clearing by User Dept.
Confirmation Venus system, no
Regular analysis/monitoring/clearing of Vendor open items
Account
will ensure correct outstanding in vendor account
Confirmation
reports are being
generated.

NIL

NIL

NIL

NIL

NIL

NIL

NIL

NIL
2.11 PROCESS MODEL LEVEL 3, BUSINESS PROCESS 8 ACCOUNTS PAYABLE REPORTS

Reports are very important to any Organization. Before generating correct reports at Period-
end or as and when required, ensure that certain activities need to be performed by ABC.


The Following Business Requirements are fulfilled by SAP
Receive updated Vendor Account.
Reconciliation of Vendor Account
To Know the outstanding in Vendor Account
Online Reporting System

2.11.3 Flow diagram
HI_FI_AP_03_08 Accounts Payable Reports

Trigger
Point
Reports
AccountPa
Manager
yable
1 2 5
3 4 6 7
Displaying Displaying / Displaying
Vendor Vendor Vendor Other SAP
Vendor Changing Vendor
Master Data Special G/L Ageing Standard
Document Vendor Line Account
List Transactions Report Reports
Journal Items Balances

Process Steps Accounts Payable Reports

Box No SAP required
(Process/System)
1 Displayin Total period AP Manager SAP Required at Missing
g Vendor Debits & Process Level document
Documen Credits. number
t Journal Opening can track
Balance & if,
Closing technicall
Balances y
are document
displayed number
along with jumbles
document
number
series
2 Displayin Required AP Manager SAP Required at Certain
g/ Vendor Process Level minor
Changing account line changes
Vendor items can can make
Line be in
Items displayed or document
can be .
changed/ Documen
reversed ts can be
reversed/
reset the
reversed
line items
3 Vendor List of AP Manager SAP Required at List of
Master Vendors, Process Level Vendors
Data List Addresses Company
and Code
changes to Level/
Vendors Purchase
Master can Organizat
track ion Level
or


Box No SAP required
(Process/System)
Centrally
can be
monitored
4 Vendor What are AP Manager SAP Required at Required

Special the Vendor- Process Level paramete
G/L wise or total rs need to
Transacti special G/L be
ons transactions selected
each as per
indicator requireme
wise also nt
can be
tracked
5 Displayin Select AP Manager SAP Required at Period
g Vendor required Process Level wise total
Account vendor/s & line
Balances and execute items can
the program be
to see the displayed.
vendor Open
balances Items,
Cleared
Items or
both can
also see
in a single
screen.
Foreign &
Local
currency
balances
also can
see in
one view
6 Vendor Vendor wise AP Manager SAP Required at


Box No SAP required
(Process/System)
Ageing required Process Level
Report ageing days
has to enter
to get
ageing
report
7 Other Master AP Manager SAP Required at All types
SAP data, Process Level of
standard Balances, standard
Reports Line Items, SAP
Payment reports
transactions are
& Bank available,
related which are
transactions satisfying
etc., can the
monitor ABCBusi
ness
requireme
nts

The Accounts Payable information system enables you to run reports for accounts payable.
You can evaluate, among other things, payment history, cash discount history, currency
exposure among
vendors, or aging reports.
You can select information you want to report based on the following criteria:
Fiscal Year
Period
Date Ranges
Account
Company Codes
Standard Reports available in SAP are

Vendor Balances

Vendor Items
Master Data
PaymentTransactions

Accounts payable reports has direct link with Material Management Module and indirect link
with Controlling Module

The following are the Inputs for the above process.
Fiscal Year
Period
Date Ranges
Account
Company Code

Accounts Payable Reports executed with detailed information.
Step # Department User Role Process Description SAP Mod T Code
1 Finance & AP Manager Accounts Payable FI As per Appendix A

Accounts Reports showing the Tcodes
for all Standard
Transactions &
Reports
In terms of Quantification prescribed transactions needed to be executed and the Data
Volume will be considerably high.

Prescribed Transactions should be executed for getting the required Accounts Payable
reports in SAP. Data Volume of Extraction is considerably high.

The Frequency of the Processes will be daily as per the Business Requirement.




Automated process and less time consuming.

Summary
Accounts Payable Currently in the Open items analysis & clearing by User Dept.
Reports Venus system, no
Regular analysis/monitoring/clearing of Vendor open items
Accounts Payable
will ensure correct outstanding in vendor account
reports are being
generated. Vendor Ageing Reports

NIL

NIL

NIL

NIL

NIL

NIL

NIL

NIL

3 SOLUTION TRANSFORMATION
3.1 Cross Process related Topics
3.1.1 SAP Organizational Structure
The use of FI vendors in the Blueprint should be strictly controlled and be limited to
Utility Bills (Gas, Water & Electric) only where fixed contracts with vendor does not
exist
Audit Fees (Nominated without a contract)
Zakat
Payment of Dividends
Partner functions are to enable within the Blueprint to allow for:

Alternative Ordering Addresses to be maintained for the same supplier
Alternative Invoicing Bank Details to be maintained for the same supplier
By specifying more than one ordering address and Invoice Address in the vendor master
record, the partner functions screen would allow options to select which Ordering Address
and/or Invoice Address to use whilst creating the PO.
The Organizational Elements involves in the above processes are as below:

Company Code
Plant & Storage Locations
Chart of Accounts
Cost Center and Cost Elements

The following Business Requirements are fulfilled with the above processes:
Full integration of Goods and Service Vendors. This would mean Single process within
SAP irrespective of goods or service.
Vendors registered and pre-qualified outside of SAP. This would ensure Single repository
of Information, with single point responsibility for vendor master data maintenance
Automatic calculation of delivery and quality scores based on a Vendors ability to

deliver to agreed Delivery Dates and Quality Products these will be reportable at a
Material Master, Material Group or overall Vendor level. Vendor Performance is handled
outside SAP with the exception of delivery and quality performance which we will use
vendor evaluation in SAP.

3.1.3 Design Aspects
Vendor numbers will be generated internally using SAP (Vendor Account groups will be
given number range)
There are four major Vendor groups recommended for use within the Blueprint:
1. 1000 Vendors Domestic

2. 2000 Vendors Foreign
3. 3000 Vendors GCC Countries
4. 4000 One-Time Vendors
FI vendors would be created for vendors that invoice without three way matching (no PO
GR/SR stage)
General Data; E.g.:
Vendor addresses, Bank data
Accounting Data; E.g.:
Reconciliation account, Payment methods,
Purchasing Data; E.g.:
Terms of payment, Order currency
3.1.4 Master Data Concept
3.1.4.1 Scenario Overview
The aim is to standardize the creation of Vendor Master Records for ABC Company.
Fore more details of technical & functional, kindly refer the MM Master Data Blueprint

Sub Process Overview
Vendor Management
EBPro
Vendor Vendors
qualification Purchase
materials /
services
Manage
Identification vendor
Receive &
Of Vendors Vendor invoices
put away
master materials
Payment maintenance
Methods
Vendor
Bank performance
Details Block/Unblock
Vendor Master analysis
Record
3.1.5 High-Level Migration Concept
The Vendor Master will contain all data relating to Vendors, for both goods and services. Apart from
the name and address of a vendor, the vendor master record will contain data regarding the currency
and payment terms, as well as names of important contact persons.
A Vendor Master Record consists of three sections of data: General Data, Company Code Data, and
Purchasing Organisation Data. The General Data part will consist of all the data which applies across
all companies such as address details, contact information, bank account details. Company Code
Data contains data that are unique per company such as house banks (from which to obtain
payment), payment methods (bank transfer, bank draft, cheque). Purchasing Data will be maintained
per Purchasing Organisation, which will include all information relevant to Contracting and
Procurement, such as contacts, delivery terms etc.
Once the data is converted, control is required to ensure that legacy data is complete and converted
successfully. It will then be used to compare uploaded records with legacy data.

Below are a few guidelines on how the data should be verified for this data object:
a) For Company Code Extension - Execute transaction MKVZ to generate the vendor list.
b) For Assign Customer to Vendor Master - Execute transaction MKVZ to generate the vendor
list
c) The critical fields that needs to be checked during verification

Account Group
Name
Search Term 1
Country
Standard communication type
Email
Previous Account No.
Sort Key
Recon Account
Payment term
Order currency
Inco-terms
d) Explore the following transactions for the actual verification:

Transaction code XK03: To view vendor master records one at a time
Transaction code SE16: To download old vendor number and new vendor number from
these tables:
ADRC:Address Info (Complete)
LFA1: Address Info (Truncated)
LFB1: Company Code Info
LFM1: Purchasing Org Info
Transaction S_ALR_87012086 to generate the vendor list for a specific company code.
e) Conduct random checks against extract covering minimum percentage
f) Download the converted data for the detailed analysis.

3.1.6 Roles
Step # User Role Process Description SAP Module
Financial Analyst All Accounts Payable Reports FI

1
Accounts Payable All Accounts Payable Transactions Authorization FI

2
Manager
Master Data Create Vendor Master in the System FI
3
Administrator
Support Team Display Vendor Details and Reports
4 FI
Support Team Process Accounts Payable Transactions

5 FI
Users of Integrated Display authorization for Accounts Payable reports

6 FI
Modules
3.1.7 APPENDIX A for Accounts Payable Reports
Transaction Title Description Use

MIR6 Invoice Overview This report will provide the (on-
(display held invoice line) list of invoices processed in
MIR4) the system. The selection criteria
can be specified based on various
fields, i.e. document date, posting
date, status (unverified, incorrect,
completed). The report shows the
status of the document and
enables the further processing of
held invoices.
S_ALR_87012991 Accounting Documents This report will provide a list of
for Material material documents created
during the goods movements
(receipt / issue). The report
enables drilling down to the
accounting details of the
documents.
S_ALR_87012078 Due date analysis for This report will give the list of


Open items open items by vendors and due
dates. It will provide the list of
overdue amounts in 30-day
incremental periods. Then by drill
down, it is possible to list the
invoices (overdue, not due, etc.)
S_ALR_87012083 List of vendor open This report gives the list of open
items items per vendor account. The
details include the document
(invoice) number, reconciliation
account, posting dates and
amount.
S_ALR_87012085 Vendor Payment This report gives the list of details
History with Open Item about the payments and open
sorted List items for the specified vendors.
S_ALR_87012103 List of vendor line This report gives the list of line
amount. (This is similar to report
List of vendor open items, but it
has different selection options, i.e.
the clearing date range)
S_ALR_87012104 List of cleared vendor This report gives the list of cleared
amount.
S_P99_41000099 Payment List This report gives the details about
Payment Proposal Run for the
specified date and identification
feature.
F.42 Vendor balances in This report will give a list of

local currency balances accounts payable for the


specified vendors. The details
include the start of period
balance, period debit total, period
credit total, and debit/credit
balances.
4 SYSTEM LANDSCAPE
4.1 PLANNED / AFTER GO-LIVE
4.1.1 Requirements for the Authorization concept
Final Authorization matrix will be given at the time of User Acceptance Testing
4.1.2 Necessary IT systems required

None
4.2 ACTUAL / BEFORE THE POJECT LAUNCH
4.2.1 Requirements for the Authorization concept
Required for the Authorization concept
4.2.2 Necessary IT systems required
Currently stand alone systems are being used by individual divisions
5 GLOSSARY
Term Explanation
ABC ABC Company
SAP H SAP Project Code for ABC
Dunning Sending Reminders
LIV Logistic Invoice Verification
Payment method Method of

Payment in partial settlement of an outstanding invoice amount.

Partial Payment
Residual Payment Clears the invoice and the payment to create a new open item
Roles & Authorization Authorization for posting the Transactions in SAP
FRICE Forms, Reports, Interfaces, Conversions, Enhancements in SAP
Data Migration Data Migration from Legacy System to SAP
5.1 APPENDIX
NIL
5.2 REFERENCES/BIBLOGRAPHY
NIL

Sap Fi AP BBP Document

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sap Fi AP BBP Document

Enviado por

Direitos autorais:

Formatos disponíveis

BLUEPRINT

SAP H IMPLEMENTATION PROJECT

SAP FI Accounts Payable

Document/ File Name

Project Folder Path

Version Revision Date Revision Description Author/ Reviewer Signature

NAME TITLE DATE SIGNATURE

SAP H Implementation Project Page 2 of 117

SAP H Implementation Project Page 3 of 117

2.5.2 Business Requirements ................................................................................................................................. 43

SAP H Implementation Project Page 4 of 117

SAP H Implementation Project Page 5 of 117

2.7.15.4 Data Conversion Considerations ............................................................................................................... 76

SAP H Implementation Project Page 6 of 117

2.9.11 Measurable KPIs ........................................................................................................................................... 95

SAP H Implementation Project Page 7 of 117

2.11.2 Business Requirements ............................................................................................................................... 103

SAP H Implementation Project Page 8 of 117

5 Glossary ........................................................................................................................................................................ 116

SAP H Implementation Project Page 9 of 117

1.1 M ANAGEMENT EXECUTIVE/SUMMARY

1.2 BASIC DOCUMENTS

SAP H Implementation Project Page 10 of 117

Document ID Document Name

BBP Workshop Report_FI_AP_03 Workshop Report

1.3 PROJECT CHARTER

Project Charter Mission & Benefits:

SAP H Implementation Project Page 11 of 117

The project sponsor Mr. XYZordered this project on 07.11.2010.

1.4 PROJECT SCOPE/SCOPE DOCUMENT

The highlights are:

SAP H Implementation Project Page 12 of 117

The current version of the complete project scope is available at (path).

Core & Support Process Business Process Business Process Business

1.5 SIGNIFICANT CHANGES TO THE CURRENT STATUS

Vendor Invoice Process & Vendor Payments

SAP H Implementation Project Page 13 of 117

Accounts Payable Report

Presently Vendor Master is maintained by Finance and Procurement Departments in separate

ABC PAYMENT TERMS

CODE Payment Terms

AD01 100% Advance

50% Advance & Balance Before Delivery

50% Advance & Balance on Delivery

50% Advance & Balance on Completion

Cash against Documents

CR01 30 Days Credit from Delivery Date

45 Days Credit from Delivery Date

50 Days Credit from Delivery Date

60 Days Credit from Delivery Date

75 Days Credit from Delivery Date

90 Days Credit from Delivery Date

120 Days Credit from Delivery Date

180 Days Credit from Delivery Date

SAP H Implementation Project Page 14 of 117

ABC PAYMENT TERMS

BE01 B.O.E 60 Days from B/L Date

B.O.E 90 Days from B/L Date

B.O.E 120 Days from B/L Date

LC01 L/C 30 Days from B/L Date

L/C 60 Days from B/L Date

L/C 90 Days from B/L Date

L/C 120 Days from B/L Date