Professional Documents
Culture Documents
August 2006
To-Be Business Process Model
Deliverable
Description: This deliverable is designed to provide a draft of the To-Be business
process model for the Manage Vendor Invoices sub-process
Version: 2.0
2 of 36
To-Be Business Process Model
3 of 36
To-Be Business Process Model
TABLE OF CONTENTS
4 of 36
To-Be Business Process Model
5 of 36
To-Be Business Process Model
4.0 KEY PERFORMANCE INDICATORS FOR THE MANAGE VENDOR INVOICES SUB-
PROCESS....................................................................................................................................... 35
6 of 36
To-Be Business Process Model
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
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
Page 9 of 36
To-Be Business Process Model
Page 10 of 36
To-Be Business Process Model
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
Page 12 of 36
To-Be Business Process Model
Page 13 of 36
To-Be Business Process Model
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.
Page 14 of 36
To-Be Business Process Model
Page 15 of 36
To-Be Business Process Model
Page 16 of 36
To-Be Business Process Model
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.
Price Variance
Quantity Variance
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
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.
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
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.
Page 19 of 36
To-Be Business Process Model
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
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.
Page 21 of 36
To-Be Business Process Model
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
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.
Page 23 of 36
To-Be Business Process Model
Page 24 of 36
To-Be Business Process Model
Page 25 of 36
To-Be Business Process Model
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.
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
Partial Payments can be performed with a direct link with invoices payment is applied to.
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
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
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
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.
Page 30 of 36
To-Be Business Process Model
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
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
Page 33 of 36
To-Be Business Process Model
Page 34 of 36
To-Be Business Process Model
4.0 Key Performance Indicators for the Manage Vendor Invoices Sub-Process
Page 35 of 36
To-Be Business Process Model
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