You are on page 1of 36

SAP Blueprint & Design

NNPC To-Be Business Process Model

Process: Requisition to Pay


16 Sub-Process: Manage Vendor Invoices

August 2006
To-Be Business Process Model

Project Name: SAP Blueprint and Design

To-Be Business Process Model


Deliverable Name: Manage Vendor Invoices

Date: August 2006

Deliverable
Description: This deliverable is designed to provide a draft of the To-Be business
process model for the Manage Vendor Invoices sub-process

It is important to note that this document will evolve into several


updated versions as improvement opportunities are identified and
detailed business understanding of the To-Be solution is developed.

Version: 2.0

2 of 36
To-Be Business Process Model

Sub - Process Owner

Organization Level Department/Responsibility


Group Level CIP
SBU Level CIP

3 of 36
To-Be Business Process Model

TABLE OF CONTENTS

1.0 SUB-PROCESS OVERVIEW MANAGE VENDOR INVOICES...........................................7

1.1 SUB PROCESS DESCRIPTION & OBJECTIVES.................................................................7

1.2 LIST OF ACTIVITIES............................................................................................................. 8

1.3 SUMMARY OF KEY CHANGES............................................................................................9

2.0 SUB PROCESS DETAILED DESIGN..................................................................................10

2.1 PROCESS INVOICES FOR SUNDRY CREDITORS............................................................11

2.1.1 ACTIVITY DESCRIPTION....................................................................................................11

2.1.2 ACTIVITY FLOW.................................................................................................................. 12

2.1.3 KEY CHANGES................................................................................................................... 13

2.1.4 CHANGE IMPACT/BENEFITS.............................................................................................13

2.2 PROCESS VENDOR INVOICES WITH A PURCHASE ORDER REFERENCE...................14

2.2.1 ACTIVITY DESCRIPTION....................................................................................................14

2.2.2 ACTIVITY FLOW.................................................................................................................. 15

2.2.3 KEY CHANGES................................................................................................................... 16

2.2.4 CHANGE IMPACT/BENEFITS.............................................................................................16

2.3 BLOCK VENDOR INVOICES...............................................................................................17

2.3.1 ACTIVITY DESCRIPTION....................................................................................................17

2.3.2 ACTIVITY FLOW.................................................................................................................. 18

2.3.3 KEY CHANGES................................................................................................................... 18

2.3.4 CHANGE IMPACT/BENEFITS.............................................................................................18

2.4 RELEASE VENDOR INVOICES..........................................................................................19

2.4.1 ACTIVITY DESCRIPTION....................................................................................................19

4 of 36
To-Be Business Process Model

2.4.2 ACTIVITY FLOW.................................................................................................................. 19

2.4.3 KEY CHANGES................................................................................................................... 20

2.4.4 CHANGE IMPACT/BENEFITS.............................................................................................20

2.5 PROCESS DEBIT/CREDIT MEMO......................................................................................21

2.5.1 ACTIVITY DESCRIPTION....................................................................................................21

2.5.2 ACTIVITY FLOW.................................................................................................................. 21

2.5.3 KEY CHANGES................................................................................................................... 22

2.5.4 CHANGE IMPACT/BENEFITS.............................................................................................22

2.6 PROCESS VENDOR PAYMENTS.......................................................................................23

2.6.1 ACTIVITY DESCRIPTION....................................................................................................23

2.6.2 ACTIVITY FLOW.................................................................................................................. 24

2.6.3 KEY CHANGES................................................................................................................... 25

2.6.4 CHANGE IMPACT/BENEFITS.............................................................................................25

2.7 PROCESS PARTIAL PAYMENTS........................................................................................26

2.7.1 ACTIVITY DESCRIPTION....................................................................................................26

2.7.2 ACTIVITY FLOW.................................................................................................................. 27

2.7.3 KEY CHANGES................................................................................................................... 27

2.7.4 CHANGE IMPACT/BENEFITS.............................................................................................27

2.8 PROCESS VENDOR DOWN PAYMENT.............................................................................28

2.8.1 ACTIVITY DESCRIPTION....................................................................................................28

2.8.2 ACTIVITY FLOW.................................................................................................................. 29

2.8.3 KEY CHANGES................................................................................................................... 29

2.8.4 CHANGE IMPACT/BENEFITS.............................................................................................29

5 of 36
To-Be Business Process Model

2.9 PROCESS VENDOR REPORTS.........................................................................................30

2.9.1 ACTIVITY DESCRIPTION....................................................................................................30

2.9.2 ACTIVITY FLOW.................................................................................................................. 30

2.9.3 KEY CHANGES................................................................................................................... 31

2.9.4 CHANGE IMPACT/BENEFITS.............................................................................................31

2.10 CLEAR VENDOR ACCOUNTS............................................................................................32

2.10.1 ACTIVITY DESCRIPTION....................................................................................................32

2.10.2 ACTIVITY FLOW.................................................................................................................. 33

2.10.3 KEY CHANGES................................................................................................................... 34

2.10.4 CHANGE IMPACT/BENEFITS.............................................................................................34

3.0 RISKS AND CONTROLS.....................................................................................................34

4.0 KEY PERFORMANCE INDICATORS FOR THE MANAGE VENDOR INVOICES SUB-
PROCESS....................................................................................................................................... 35

5.0 Configuration Management..................................................................................................36

6 of 36
To-Be Business Process Model

1.0 Sub-Process Overview Manage Vendor Invoices

1.1 Sub Process Description & Objectives

This sub - process involves all activities necessary in the processing of all vendor financial documents for
eventual payment. It further involves the Vendor Account Management comprising of reconciliation of
vendor accounts (matching debit and credit items) in a bid to clear all open items.

This sub process will address inefficiencies in the Invoice Verification, Processing and Payment activities.

The objective of Manage 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.
:

Page 7 of 36
To-Be Business Process Model

1.2 List of Activities

Activities Description
Process Sundry Vendor Invoices This involves all functions or task involved in the
processing of Sundry vendor invoices. These are
invoices not related to a purchase order (PO) or
inventory related purchase. This activity outlines
how such invoices will be processed for payment.
Staff retirements will be handled by this process
Process MM invoice - via Logistics Invoice This activity shows how PO related vendor
Verification invoices are processed including invoice
verification/matching against the PO and Goods/
Service Receipt. (3 way match)
Block Vendor Invoices This involves all functions required to block a
vendor invoice depending on a preconfigured
blocking reason
Release Vendor Invoices This involves the release or unblocking of invoices
previously blocked
Process Debit/Credit Memo This details all functions/ tasks required in
processing vendor debit and credit memos to
either reduce or increase NNPCs indebtedness to
a vendor.
Process Vendor Payments This activity handles the payment of approved
vendor invoices
Process Partial Payment This involves all tasks/functions necessary to
process manual and partial payments which are
outside the NNPC normal payment cycle.
Process Vendor Down Payment This activity caters for vendor prepayments, staff
advances and advance payment requests from
vendors
Process Vendor Reports Various categories of reports may be generated
per vendor. This process outlines the procedure
for generating reports.
Clear Vendor Accounts This activity describes how line items in vendor
accounts are matched and cleared both manually
& automatically

Page 8 of 36
To-Be Business Process Model

1.3 Summary of Key Changes

Invoice verification will be performed in a shorter time in an objective manner.


The introduction of the three way match precludes the need for manual invoice verification by the
originating departments of the purchase order.
Automatic vendor payments and posting increases the accuracy and reduces the effort involved in
vendor payments
Accruals are automatically processed at goods receipt
Availability of individual vendor accounts with history

Page 9 of 36
To-Be Business Process Model

2.0 Sub Process Detailed Design

Page 10 of 36
To-Be Business Process Model

2.1 Process Invoices for Sundry Creditors

2.1.1 Activity Description

Sundry invoices refer to transactions relating to taxes e.g. VAT, WHT, and other expenditures without
purchase orders. This process is triggered by the periodic receipt of a request to pay tax (when it is due) or
other sundry expense such as utility bills. This process can also be triggered by an expense retirement by a
staff.

After entering the details, the invoice will be parked in the system for approval. The system generated
document number must be written on the tax invoice or utility bill (as the case may be) by the Invoice
Processor once assigned by the system.

Invoices are approved for posting. On approval, the invoice is then posted and it is automatically queued
for the next payment run (depending on the payments terms). Vendor payment is covered in Process
Vendor Payments

Page 11 of 36
To-Be Business Process Model

2.1.2 Activity Flow

Page 12 of 36
To-Be Business Process Model

2.1.3 Key Changes

Invoices will be processed within a shorter time interval


Vendor invoices will be created and approved online hence the elimination of manual document
references e.g. Payment Vouchers (PV) and Journal Vouchers (JV).
Automatic check for duplicate invoices

2.1.4 Change Impact/Benefits

Invoice processing backlogs will be minimized.


There is increased visibility and transparency in the invoice processing and payment process.

Page 13 of 36
To-Be Business Process Model

2.2 Process Vendor Invoices with a Purchase Order reference

2.2.1 Activity Description

MM invoices originate from transactions relating to a purchase order (PO), work order or services contract.
On receipt of such an invoice, Invoice Verification will be performed to ascertain a match between the PO,
goods/ service receipt (GR/SR) and the invoice amount. This is called a 3-way match. Within NNPC,
invoices which do not match the PO and goods receipt will not be posted at all. Rather, these invoices will
be returned to Vendor through the user department after an internal investigation to ensure there are no
errors.

This mismatch could be as a result of incomplete delivery by the Vendor or due to the fact that the
delivered goods have not been fully received into the system or that the invoice amount exceeds the PO
amount. However, to correct the first situation, considering partial delivery is not permitted within NNPC,
the PO, subject to approval, will be altered to match the GR/SR and the Invoice Receipt (IR). In the
second instance, the responsible party is prompted to post all the goods receipts delivered into the system.
Where the invoice value exceeds the value of the PO, the invoice will be returned to the vendor for
correction.

On the other hand if there is a match between all three (3) documents, posting of the invoice is completed
which in turn creates both an MM and Financial (FI) document, with a debit entry to the GR/IR account (to
nil off the initial credit posting at time of goods receipt), and a credit to the vendor account. Once posted the
following fields can be changed to depict the present terms of the relevant transaction;

Payment Terms
Reference (Invoice number)
Document Header Text
Baseline Date
Payment Method Supplement

Purchase Order-related invoices will not be parked since all required authorizations would have been given
during the release (approval) of the related Purchase Requisition (PR) and Purchase order (PO)
The invoice is automatically queued for the next payment run depending on the payment terms.

All invoice processing will be centralized at the SBU level.

Page 14 of 36
To-Be Business Process Model

2.2.2 Activity Flow

Page 15 of 36
To-Be Business Process Model

2.2.3 Key Changes

System matching of invoices with LPO/WO and Goods Receipt


Automatic matching & clearing for vendor accounts
Automatic check for duplicate invoices
Vendor invoices will be posted and approved online hence the elimination of manual document
references e.g. Payment Vouchers (PV) and Journal Vouchers (JV).

2.2.4 Change Impact/Benefits

Invoice verification will be enhanced greatly.


Invoice processing will be faster
Reduction in manual document processing.

Page 16 of 36
To-Be Business Process Model

2.3 Block Vendor Invoices

2.3.1 Activity Description

If there are disputes over an invoice the invoice can be blocked. Once an invoice is blocked, it cannot be
paid. The invoice must first be released in a separate step before it can be further processed.

Invoices can be blocked for various reasons;

Price Variance
Quantity Variance

Other reasons such as liquidity

For the purpose of this documentation, Manual Blocking will be emphasized. Because there are no
tolerance limits in NNPC, invoices due to price variances cannot be processed further.

When the request to block an invoice is received, the relevant invoice is selected and an A (for Audit
blocks) or F (for FAD blocks) can be entered on the field Payment block on the vendor screen. Invoices
blocked by Audit can not be unblocked at the payment proposal stage.

Page 17 of 36
To-Be Business Process Model

2.3.2 Activity Flow

2.3.3 Key Changes

Invoices can be blocked on the system to prevent payment; hence liquidity may be managed by simply
blocking invoices that the corporation may not be able to pay at a particular time.

2.3.4 Change Impact/Benefits

System control of invoice blocking will ensure invoices are blocked and human intervention is
minimised in such action.
System ensures NNPC meets its contractual payment obligations when due
Enhanced tracking and reporting of unpaid/blocked invoices

2.4 Release Vendor Invoices

2.4.1 Activity Description

Where invoices have been blocked for specified reasons, they need to be released before they can be
processed for payment. A list of blocked invoices is generated and reviewed. The eligible blocked invoices
are then selected for release.

Page 18 of 36
To-Be Business Process Model

The invoices may then be released (collectively or individually). When you release an invoice, the system
cancels the blocking indicator in the invoice document.

2.4.2 Activity Flow

2.4.3 Key Changes

Invoice release process can only be done on the system


There is a system role responsible for blocking and releasing invoices.

Page 19 of 36
To-Be Business Process Model

2.4.4 Change Impact/Benefits

Better control and transparency of invoices as erroneous payment of a blocked invoice will be
eliminated as authorisations are required for unblocking vendor invoices.

Page 20 of 36
To-Be Business Process Model

2.5 Process debit/credit memo

2.5.1 Activity Description

Credit Memos issued by vendors post a debit into the vendors account to reduce the liability owed by
NNPC to the Vendor. The debit memo on the other hand posts a credit into the Vendors account increasing
the liability of NNPC to the Vendor. The credit/debit memo is processed the same way as sundry invoices.
Please refer to Process Invoices for Sundry Vendors. Where it relates to purchase orders the subsequent
credit and debit function within Logistics Invoice Verification (LIV) will be used to enable an update of the
PO history.

2.5.2 Activity Flow

Page 21 of 36
To-Be Business Process Model

2.5.3 Key Changes

Provides an enhanced means of accounting for under/over payment to vendors

2.5.4 Change Impact/Benefits

Proper accounting of under/overpayments will be enhanced. A report may also be generated that
shows such activity.

Page 22 of 36
To-Be Business Process Model

2.6 Process Vendor Payments

2.6.1 Activity Description

Invoice payments may be processed automatically or manually.

Automatic payment involves the creation and approval of a payment proposal (i.e. a list of open
items/invoices to be paid), and the payment run itself. This generates payment files which are forwarded to
Treasury for payment.

In the payment run, all invoices that have been posted and are due for payment are selected by the system
for payment using certain predefined criteria into a payment proposal. Invoices that are due but have been
for payment are also listed, but with exceptions

This list of invoices selected for payment is reviewed to determine whether any open items are to be
removed or added to the selection. Where changes are to be made, the payment proposal is edited
accordingly.

The finalized payment proposal is then generated and approved by management. The payment may then
be processed.

A payment run is processed in the system. This creates SAP accounting documents/payment files and
posts values to the General Ledger. The payment run generates advices which may be sent to the vendor.

These payment files are then printed and forwarded to Group Treasury for dispatch to vendors directly or
cheques are printed/ written for the vendors.

Note: This process (automatic payments) takes into consideration that NNPC pays Vendors at a
particular time of the week or month.

Manual payments are payments made by NNPC outside the normal payment cycle/ run. Due approval is
required to execute this process. In this case a batch run is not executed rather this is done on an
individual selection basis. The system only allows manual payments to be made net of applicable taxes.

Payment approval is done by FAD Management subject to approval limits.

Page 23 of 36
To-Be Business Process Model

2.6.2 Activity Flow

Page 24 of 36
To-Be Business Process Model

2.6.3 Key Changes

Automated processing of invoices due for payment


Online approval for payment of vendor liabilities .
Reduced time to complete invoice payment .
Due payments will be easily identified.
Due invoices that may not be paid are flaged as exceptions and reasons for such given

2.6.4 Change Impact/Benefits

Timely payments to vendors will be achieved.


Provides the basis for improved treasury management.

Page 25 of 36
To-Be Business Process Model

2.7 Process Partial Payments

2.7.1 Activity Description

This activity relates to payments in partial settlement of an outstanding invoice amount. This covers
situations where it may be deemed necessary to pay only part of the total amount of a vendor invoice.

There are two ways of making a partial settlement;

Partial Payment
Residual Payment

The difference between a partial payment and a residual amount is that a partial payment will keep the
open item document and allocate the payment against the document, whereas a residual amount will
consider the open item closed, and create a new document representing the difference between the value
of the original vendor invoice and the payment against that invoice.
You can make a partial payment for one or more open items. You can assign a reason code to each partial
payment.

The use of either partial payments or residual payments is at the discretion of the official posting the
payment.

Although there is provision for this, partial payments will ordinarily not be allowed in NNPC, There
are however cases where payments are made with retentions. Special payment terms have been
defined in the system for this.

Page 26 of 36
To-Be Business Process Model

2.7.2 Activity Flow

2.7.3 Key Changes

Partial Payments can be performed with a direct link with invoices payment is applied to.

2.7.4 Change Impact/Benefits

Automatic clearing or matching of debits and Credits will be enhanced as invoices are linked to
payments.

Page 27 of 36
To-Be Business Process Model

2.8 Process Vendor Down Payment

2.8.1 Activity Description

There are vendor transactions that involve advance/down payments. In some instances an initial payment
is required by vendors to secure goods or services prior to the issuing of an invoice.

Staff advances are also forms of down payments. It is proposed that two separate GL accounts be created
for the two transaction types and postings be separated by special GL indicators for the postings.

On receipt of the down payment request, it is entered into the system as noted item without having any
impact on the balance sheet. This tracks all down payments due to be made. It also enables the system to
post the down payments to your vendor automatically using the payment program.

The payment is made but these transactions are not posted to the G/L account (reconciliation account)
defined in the vendor master record but to an alternative G/L account (reconciliation account) called down
payments made via a Special GL Account indicator selected at time of posting.

When the vendor submits the final invoice the invoices are processed by the Accounts payable Section.
Please refer to Process Invoices for Sundry Creditors as well as Process Vendor Invoices with a PO
reference. (Invoices from vendors and staff advances down payments will be processed as PO related
invoices. Staff advances are treated as PO related because there is a requirement to track commitments
against the budgets for which the advances are made.

The down payment is proposed when ever an invoice is processed in the account. It can be cleared
against an invoice or posted in the vendor account.
When the next payment run is processed, the outstanding balance (invoice total less the Down Payment) is
then paid to the vendor.

Page 28 of 36
To-Be Business Process Model

2.8.2 Activity Flow

2.8.3 Key Changes

Down Payments will be tracked on the system centrally.


Staff advances are posted into the individual staff accounts

2.8.4 Change Impact/Benefits

Enhanced tracking of all down payments (Staff Advances and other Vendor Down payments made)
as the system automatically prompts of the existence of such payments.

Page 29 of 36
To-Be Business Process Model

2.9 Process Vendor Reports

2.9.1 Activity Description

Standard SAP reports may be generated for one or multiple vendor accounts either by summary or line
item. Some standard accounts payable reports include Payment History (days in arrears of open items), AP
Aging, Due date breakdown (total of due items, total of items not yet due), vendor balance report.

2.9.2 Activity Flow

Page 30 of 36
To-Be Business Process Model

2.9.3 Key Changes

More robust online system generated reports will be available

2.9.4 Change Impact/Benefits

Improvement in the accuracy of the reports due to minimised manual data entry
Reports will be available on demand.
Management decision making will be enhanced with readily available reports

Page 31 of 36
To-Be Business Process Model

2.10 Clear Vendor Accounts

2.10.1 Activity Description

Vendor accounts may be cleared periodically. Clearing may be done manually or automatically. Cleared
items may also be reset and reversed if clearing had been done erroneously to the wrong account.

Automatic Clearing

The automatic method clears open items for vendors accounts. The program is scheduled to run
periodically. It selects all accounts which are specified, and clears debit and credit postings that have the
same value. If the balance of the group of open items equals zero, the items are marked as cleared. The
basic prerequisite for automatic clearing is that the accounts must be kept on an open item basis.
Customer and vendor accounts are always managed in this way. Open item management ensures that all
items that have not yet been cleared are available in the system. A document can only be archived after all
open items in a document have been cleared.

Certain transactions like the payment run clear or allocate the transactions in the accounts.

Manual Clearing

Vendor accounts can also be manually cleared either as a next step to automatic clearing i.e if for some
reason there are outstanding open items after automatic clearing or as a matter of choice.

Page 32 of 36
To-Be Business Process Model

2.10.2 Activity Flow

Page 33 of 36
To-Be Business Process Model

2.10.3 Key Changes

Automatic matching of debits and credits in the Vendor Accounts

2.10.4 Change Impact/Benefits

Reduction in Vendor account reconciliation efforts

3.0 Risks and Controls

No Area Risk Control


Stolen ID and passwords can Periodic change of user
User Profiles and be used to carry out passwords should be made
1
Passwords transactions in the system mandatory e.g. every quarter to
minimize the risk of occurrence

Page 34 of 36
To-Be Business Process Model

4.0 Key Performance Indicators for the Manage Vendor Invoices Sub-Process

Performance Indicator Actual Target Comment


Accuracy of Vendor Invoice Processing &
Payment
Timeliness of Vendor of Vendor Invoice
Processing & Payments
Minimal Processing of Credit & Debit Memos
Time taken to post parked invoices and
Credit/Debit Memos

Page 35 of 36
To-Be Business Process Model

5.0 Configuration Management

History
Version Date Author Change Description
0.1 August Onyekachi Ginger- Initial draft
2006 Eke
Kunle Durojaiye
1.0 September Victor Osagie Client Copy
2006
2.0 October Onyekachi Ginger- Client Copy
2006 Eke
Edoka Edosio
3.0 December Joe Ujoh Client Copy
2006

Page 36 of 36

You might also like