Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Table of Contents
Objectives........................................................................................................................................ 2
Overview ......................................................................................................................................... 2
Enterprise Roles ........................................................................................................................... 3
Chapter 1 – Credit Note and Subsequent Credit recorded before the corresponding invoice is
paid ................................................................................................................................................. 3
1.1 ....................... How to Enter a MIR7 Credit Note/Subsequent Credit related to a PO Invoice
...................................................................................................................................................... 3
1.2 How to Enter a FV65 Credit Note related to non-PO Invoice or PO Invoice ......................... 5
Chapter 2 – Credit Note and Subsequent Credit recorded after the corresponding invoice is paid
......................................................................................................................................................... 6
2.1 How to Enter a Credit Note related to PO Invoice after invoice is paid ................................ 6
2.2 How to Enter a Credit Note related to FV60 Invoice after invoice is paid ............................ 8
Chapter 3 – Role of Cashier in processing Credit Notes ................................................................. 9
Chapter 4 - Examples .................................................................................................................... 11
Example 1 – Netting of Multiple Credit Notes against an Invoice ............................................. 11
Example 2 – Netting of Linked Invoice and Credit Memo with Different Payment Attributes . 19
Example 3 –Credit Note in Exception Automatically Assigned when an Invoice is Posted ....... 21
Example 4 – Referencing PO vs. Invoice Reference ................................................................... 25
Example 5 – Credit Note is Larger than Invoice ......................................................................... 28
Example 6 – Sum of Credit Notes is Larger than Invoice ........................................................... 30
Example 7 – Cashier Selects Only the Invoice in Manual F110 ................................................. 31
Example 8 – Local Cashier Selects Only the Invoice .................................................................. 32
Example 9 – UNHQ Cashier Assigns Invoice and Credit Note to Different Lists ........................ 34
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
1/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Objectives
This user aid explains how to create credit notes to ensure a) they do not go into the payment
exception log; and b) they net against invoices payable upon completion of FPRL_LIST and c)
our vendor history faithfully reflects reality.
Overview
In Umoja we should reflect faithfully what happens in reality. Here are a few scenarios where
credit notes and subsequent credits should be used. As you can see, using invoice reduction or
recording net invoices is not best practice to record credit notes:
Vendor Action
1. Vendor cancels the original invoice and
issues a new invoice for a lower amount
2. Vendor issues a credit note before the
original invoice is paid
3. Vendor issues a credit note after the
corresponding invoice is paid
4. Vendor agrees verbally to a reduction of
the invoice but does not issue a credit note
5. Contract provides for liquidated damages.
Vendor does not issue a credit note
6. None
Umoja Treatment
Reverse original invoice (if it was posted)
and create a new invoice with the lower
amount
Post original invoice with full amount and
post a credit note or subsequent credit for
the reduction.
Use invoice reduction for rounding
differences on invoice.
This Job Aid covers multiple scenarios. Chapter 1 covers credit notes and subsequent credit
documents created before the corresponding invoice is paid. In this case, the Invoice Reference
functionality is available and should be used when the credit note is created.
Chapter 2 covers credit notes and subsequent credit documents entered after the
corresponding invoice has been paid and before the next invoice is created. In this case, the
Invoice Reference functionality is not available. Thus all payment attributes must be entered
correctly on the credit note.
In both cases, proper creation of the credit note will result in netting of the credit note against
the invoice as intended.
Chapter 3 explains how the UNHQ and local Cashiers must proceed to ensure credit notes are
netted against the invoice. This chapter covers errors that can result in non-netting of credit
notes.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
2/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Chapter 4 provides nine examples that cover the majority of cases with correct and erroneous
processes.
Before we explain how to post a credit note on a vendor’s account, we must determine what Tcode will be used to record the credit note. The following table indicates what T-Code should be
used for various scenarios:
Scenario
1. Commercial vendor MIR7 invoice with
credit note or liquidated damage
2. Commercial vendor MIR7 invoice with
reduction for duty, custom or other fees
paid to another vendor. E.g. airport
handling fees.
3. Commercial vendor MIR7 invoice for
rations with reduction for utility bills such
as electricity, telephone, etc paid to other
vendors.
4. Individual contractors: reductions for
telephone charges, and other small costs
5. Low value invoice: credit note, liquidated
damage, miscellaneous reductions
T-Code
Invoice and credit memo/subsequent credits
are recorded with MIR7 and are visible on the
PO history
Invoice is recorded with MIR7. Reductions
should not be recorded on PO history and
therefore they should be recorded with FV65
Invoice is recorded with FV60 and reduction is
recorded with FV65
Enterprise Roles
FI Accounting User (AP)
FI Accounting Approver (AP)
Cashier (UNHQ and local)
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Chapter 1 – Credit Note and Subsequent Credit recorded before the
corresponding invoice is paid
1.1 How to Enter a MIR7 Credit Note/Subsequent Credit related to a PO
Invoice
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
3/35
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Job
Aid
The process flow is as follows. Reference to Credit Note in this Section include both MIR7 Credit
Notes and MIR7 Subsequent credits (explained later in the text):
Step
1
2
3
Enterprise Role
AP User
AP User
AP Approver
4
AP User or AP
Approver
Cashier
5
Action
Block PO invoice for payment (insert a payment block)
Create MIR7 credit note using Inv. Ref functionality.
Review MIR7 Credit Note and ensures Inv. Ref. has been used
correctly. Check that both invoice and credit note are blocked.
Approve credit note in workflow.
Perform daily management of AP documents and unblock PO
invoice (unblocking credit note is optional with Inv. Ref)
Process both the invoice and credit note/subsequent credit
documents together and ensures both documents have same
Posting Date for Payment Document (in FRPR_LIST)
To create one or more credit notes related to a PO Invoice that has not yet been paid (Step 2 in
above workflow), follow instructions outlined in the following table:
TCode
Transaction
MIR7
Credit Memo
Document Date
Today
Reference
Posting Date
Amount
Calculate Tax/Tax
Country
Text
Purchase Order
Inv. Ref
Click Enter
Simulate General
Ledger
Reminder
Subsequent Credit
Vendor Credit Note No
Today
Credit Note Amount
If needed
Note
Watch for system
message (in yellow)
indicating payment
data was copied from
invoice
Full Description
PO Number
Payment Tab
PO Invoice number 51XX
Message: Data was copied
Dr Vendor
Dr Vendor
Cr 35401010 GR-IR
Cr Expense
Save as Complete
Credit Memo to be used
Subsequent Credit to be
if we have Movt Type 122 –
used if we have no Movt
Goods Returned to Vendor on
Type 122 on PO History. In
PO History
this case we should not
Movt Type 122 result in
create a posting to the
posting:
GR-IR account
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
Troubleshooting Tip
Be careful! Your GRIR account will go
out of balance if you
use the wrong
transaction!
4/35
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Job
Aid
Dr 35401010 GR-IR
Cr Expense
It is CRITICAL to note:
1. When the Inv. Reference field is used correctly in step 2, the baseline date, payment
terms, payment method, payment block and partner bank (referred to as the
payment attributes) are automatically copied from the invoice document onto the
credit note/subsequent credit document. Thus both the invoice and credit
note/subsequent credits are synchronized at that moment in time. From that point
on, it will not be possible to make changes to the payment attributes of the credit
note independently of the invoice. It will be possible to change the payment
attributes of the invoice in change mode. It will not be necessary to make the same
changes to the credit note as the two documents will be linked (i.e both will have the
same payment attributes even though it will not be visible in the vendor report) and
will be processed at the same time.
2. For example, if we need to change one of the payment attributes (e.g. baseline date
or payment terms), then we need to make the change on the invoice and even though
the change is not made on the credit note, both the invoice and credit note will be
netted at the time of payment if the Cashier selects both documents at the same
time. Refer to example 2 below illustrating a credit note that has a different baseline
date, payment term, and payment method than the linked invoice and the net
payment resulting during FPRL_LIST if the Cashier selects both documents.
1.2 How to Enter a FV65 Credit Note related to non-PO Invoice or PO Invoice
The process flow is as follows:
Step
1
2
3
Enterprise Role
AP User
AP User
AP Approver
4
AP User or AP
Approver
Cashier
5
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Action
Block FV60/MIR7 invoice for payment (insert a payment block)
Create FV65 credit note using Inv. Ref functionality.
Review FV65 Credit Note and ensures Inv. Ref. has been used
correctly. Check that both invoice and credit note are blocked.
Approve credit note in workflow.
Perform daily management of AP documents and unblock
invoice (unblocking credit note is optional with Inv. Ref)
Process both the invoice and credit note documents together
and ensures both documents have same Posting Date for
Payment Document
Umoja Training
5/35
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Job
Aid
To create one or more credit notes related to a FV60 Invoice that has not yet been paid (Step 2
in above workflow), follow instructions outlined in the following table:
TCode
Transaction
FV65
Credit Memo
Document Date
Reference
Posting Date
Amount
Calculate Tax/Tax
Country
Text
Line Item
Today
Vendor Credit Note No
Today
Credit Note Amount
If needed
Note
Watch for system message (in
yellow) indicating payment
data was copied from invoice
Full Description
Full coding block
Payment Tab
FV60 Invoice number 31XX
or 51XX
Message: Data was copied
Inv. Ref
Click Enter
Simulate General
Ledger
Dr Vendor
Cr Expense
Save as Complete
It is CRITICAL to note:
1. Same as for PO Invoice in Section 1.1 above
2. Same as for PO Invoice in Section 1.1 above
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Chapter 2 – Credit Note and Subsequent Credit recorded after the
corresponding invoice is paid
2.1 How to Enter a Credit Note related to PO Invoice after invoice is paid
The process flow is as follows except for Payment Method Z, which is discussed later in this
section. Reference to Credit Note in this Section include both MIR7 Credit Notes and MIR7
Subsequent credits (explained later in the text):
Step
Enterprise Role
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Action
Umoja Training
6/35
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Job
Aid
1
AP User
2
AP Approver
3
AP User or AP
Approver
4
Cashier
Create MIR7 credit note manually entering all payment
attributes.
Review MIR7 credit note and ensure all payment
attributes have been entered
Perform daily management of AP documents take note
when a new invoice is posted with the same payment
attributes as the credit note
Process both the invoice and credit note/subsequent
credit documents together and ensures both documents
have same Posting Date for Payment Document
To create one or more credit notes related to a PO Invoice that has been paid (Step 2 in above
workflow), follow instructions outlined in the following table:
Do we have cases in which there is in fact Movt Type 122 even after the invoice has been paid?
TCode
Transaction
MIR7
Subsequent Credit
Document Date
Reference
Posting Date
Amount
Calculate Tax/Tax
Country
Text
Purchase Order
Inv. Ref
Baseline Date
Payment Terms
Payment Method
Partner Bank
Payment Block
Simulate General
Ledger
Today
Vendor Credit Note No
Today
Credit Note Amount
If needed
Full Description
PO number
Payment Tab
Blank (in this scenario there are no
Invoices pending to be paid)
Toay
Z001 – Due Immediately
Usual payment method for this
vendor
Usual partner bank for this vendor
(blank if payment method is cheque
or cash)
Blank
Dr Vendor
Cr Expense
Save as Complete
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
7/35
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Job
Aid
It is CRITICAL to note:
1. The full payment attributes must be entered on credit notes/subsequent credits (the invoice
reference field cannot be used because in this scenario there are no additional invoices posted
and not paid). Do not leave fields blanks because it is a credit note. Leaving payment attributes
blank accounts for the majority of problems experienced with netting.
2. Do not put a payment block on the credit note.
3. Note that the Due Date will be today. This means that this credit note will net against the next
invoice for this vendor entered with the same currency, payment method and partner bank.
4. This credit note may be netted against the invoice of another Fund/Business Area (see example
in Chapter 4 below).
5. Do not enter credit note on PO using FV65 because you will not see the credit note on the PO
History! User MIR7 for all credit notes related to PO invoices even if the credit note may
eventually be netted against a non-PO invoice. (exception: scenarios 2, 3 and 4 explained in
page 3)
6. For Payment Method Z, Umoja is configured to split the KZ 33XX payment documents. This is to
ensure that payments to multiple individual contractors (ICs) recorded on one Regional BP are
split into multiple KZ 33XX payment documents. Splitting payments for payment method Z is a
temporary workaround used we stop using Regional BPs. As a result of this, the credit note will
only net against the invoice if the Invoice Reference is entered for Payment Method Z.
Therefore, if the credit note is entered before the invoice, the credit note will need to be
reversed (FB08) and reentered after the invoice with the invoice reference number. Thus he
invoice must be posted prior to the credit note.
2.2 How to Enter a Credit Note related to FV60 Invoice after invoice is paid
The process flow is as follows:
Step
1
Enterprise Role
AP User
2
AP Approver
3
AP User or AP
Approver
4
Cashier
Action
Create FV65 credit note manually entering all payment
attributes.
Review FV65 credit note and ensure all payment attributes have
been entered
Perform daily management of AP documents and take note
when a new invoice is posted with the same payment attributes
as the credit note
Process both the invoice and credit note documents together
and ensures both documents have same Posting Date for
Payment Document (in FPRL_LIST)
To create one or more credit notes related to a FV60 Invoice that has been paid (Step 2 in
above workflow), follow instructions outlined in the following table:
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
8/35
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Job
Aid
TCode
Transaction
Document Date
Reference
Posting Date
Amount
Calculate Tax/Tax
Country
Text
Line Item
Inv. Ref
Baseline Date
Payment Terms
Payment Method
Partner Bank
Payment Block
Simulate General
Ledger
FV65
Credit Memo
Today
Vendor Credit Note No
Today
Credit Note Amount
If needed
Full Description
Full coding block
Payment Tab
Blank (in this scenario there is no
invoices pending to be paid)
Today
Z001 – Due Immediately
Usual payment method for this
vendor
Usual partner bank for this vendor
(blank if payment method is cheque
or cash)
Blank
Dr Vendor
Cr Expense
Save as Complete
It is CRITICAL to note:
1.
2.
3.
4.
Same as in Section 2.1 above.
Same as in Section 2.1 above.
Same as in Section 2.1 above.
Same as in Section 2.1 above.
Chapter 3 – Role of Cashier in processing Credit Notes
While the AP User and AP Approvers are responsible for creating the credit notes/subsequent
credits properly, the Cashier has an equally important role in ensuring that credit notes are
netting against invoices.
Responsibility #1: Unassign all documents from Assigned list at end of day
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
9/35
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Job
Aid
The Posting Date for Payment Document is system generated when the F110 batch is run for
documents that are either:
a) Captured by F110 for the first time; or
b) In Unassigned status in a payment release list; or
c) In Refused status in a payment release list; or
d) In Exception status in the Exception list.
Please note that the Posting Date for Payment document is not updated for documents that are
in Assigned status. Umoja will not net invoices and credit notes with different Posting Date for
Payment Documents. To ensure netting occurs, at the end of each day the local Cashier must
Unassign all documents remaining in their list with the Assigned status. In other words, Cashier
must empty their Assigned list by the end of their day.
Responsibility #2: Ensure both the credit note and the invoice have same Posting Date for
Payment Document before hitting the “Pay” button
UNHQ and local Cashier should organize their list to:
a) Be sorted by Vendor; and
b) Display the Posting Date for Payment Document next to the Document number
c) Display the Invoice Reference column next to the Posting Date for Payment column
This way Cashiers will be able to quickly identify any documents that have different Posting
Date for Payment Document for the same vendor.
If Cashiers detect documents with different Posting Date for Payment Document, they should
reset the Posting Date for Payment Document as follows:
i)
ii)
iii)
Select the document
Click the Refuse icon -> the document status will change to Refused and the
document will move the Unassigned list
Select the document in the Unassigned list and assign it back to their list -> the
Posting Date for Payment Document will be reset to the current date
Responsibility #3: Select Credit Note documents together with the Invoice
To avoid selecting invoices without the corresponding credit notes, it is very important that
Cashiers organize their list as explained above. Cashiers should pay particular attention to the
Invoice Reference column as it shows to what invoice a credit note is related when the Invoice
Reference functionality has been used. Cashiers must ensure credit note documents with an
invoice reference are selected at the same time as the invoice document i.e. both documents
must be highlighted before Cashier clicks the “Pay” button.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
10/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Responsibility #4: Request AP Users to block invoices that are not ready for payment
To decrease the number of “Assigned” items in their list at the end of the day, Cashiers should
periodically export the list of unpaid documents from their Assigned list and send to AP Users
and AP Approvers for their prompt action to block documents that are not ready to be paid.
For example, invoices for which we have not yet processed a credit note, invoices for which we
are calculating the liquidated damages, etc. should be blocked for payment.
Chapter 4 - Examples
Example 1 – Netting of Multiple Credit Notes against an Invoice
In this example, we have a FV60 invoice [1] on vendor 1110_1020 for which we have recorded 5
credit notes as follows:
[2] FV65 credit note with proper invoice reference and copied data (Scenario 1.2)
[3] FV65 credit note with proper invoice reference and copied date. We subsequently removed
the payment block on the invoice and (intentionally) left the payment block on the credit
note to demonstrate that it will not prevent netting. (Scenario 1.2)
[4] FV65 where we left the invoice reference blank and entered the payment attributes
manually (Scenario 2.2)
[5] FV65 where we left the invoice reference blank and entered all payment attributes
manually. This credit note is not due when we run F110/FPRL_LIST and will not be selected
by the batch. (Scenario 2.2)
[6] MIR7 where we left the invoice reference blank and entered all payment attributes
manually. This credit note will appear on the PO history but it will net against the next
invoice which happens to be a FV60 invoice. (Scenario 2.1)
We also have a MIR7 invoice [1] on vendor 1110_1036 for which we have recorded 4 credit
notes as follows:
[2] MIR7 subsequent credit with invoice reference and copied data (Scenario 1.1)
[3] MIR7 subsequent credit where we left the invoice reference blank and entered all payment
attributes manually. This credit note will appear on the PO history but it will net against the
next invoice which happens to be a MIR7 invoice. (Scenario 2.1)
[4] MIR7 subsequent credit where we left the invoice reference blank and entered all payment
attributes manually. This credit note is not due when we run F110/FPRL_LIST (Scenario 2.1)
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
11/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
[5] MIR7 subsequent credit where we intentionally made a mistake and failed to enter all
payment attributes (in this case the payment method is blank). This document is expected
to go into Exception in FPRL_LIST.
Finally, to demonstrate that credit notes will net for a given vendor we have entered additional
credit notes from a different Fund/ Business Area:
[6] FV65 credit notes with no Invoice Reference but due now.
[7] and [8] are not current scenario but could/should become scenarios in the future – FV65
credit notes with invoice reference to another Fund/Business Area PO invoice. We would not
use a MIR7 document to avoid recording the credit note of Business Area P003 or S100 on the
PO History of Business Area M008. In [8] we left the payment block on the credit note to
demonstrate that when we use the Invoice Reference, the documents are linked and the
payment block on the credit note does not prevent netting.
The vendor report (Vendor History) prior to the F110 batch/FPRL_LIST looks at follows:
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
12/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
13/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
When we ran F110 on the two vendors without selecting documents (similar to how the F110
batch runs) we observed 12 documents in the Unassigned Screen as follows:
It is important for Cashier to select and assign all debits and credits at this stage in the
FPRL_LIST.
We also noted that the credit note with the missing payment method went into Exception as
expected.
All unassigned items should be assigned. There was no issue during the assignment. All lines
had the same Posting Date for Payment Document:
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
14/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
All 12 items are Released for Payment without any issue:
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
15/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Note that one KZ document was created for each vendor effectively netting all credit notes
against the invoice.
 Vendor 1110_1020 -> KZ document 33_58527
 Vendor 1110_1036 -> KZ document 33_58528
The vendor report (Vendor History) after to the F110 batch/FPRL_LIST looks at follows:
1. For vendor 1110_1020, four credit notes were netted against the one FV60 invoice. One credit
note Due in the future was not captured by F110.
Conclusion: System working as intended.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
16/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
2. For vendor 1110_1036, six credit notes were netted against the one PO invoice including
credit notes from different Fund/Business Area. One credit note with incomplete
payment attribute went into Exception.
Conclusion: System working as intended.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
17/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
****************************************************************************************************************
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
18/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Example 2 – Netting of Linked Invoice and Credit Memo with Different Payment
Attributes
In this example we have created a MIR7 invoice with payment method H (cheque), no partner
bank, baseline date of 1-July-2014, payment terms of Z001, which results in a due date of 1July-2014, and no partner bank. Next, we have created a MIR7 subsequent credit and linked it
to the MIR7 invoice with Inv. Ref. Finally, we have used change mode to modify the invoice
payment method to W, changed the baseline date to 15-July-2014, and the payment terms to
Z012, which results in a due date of 1-August-2014, added a partner bank 2001. No changes
were made to the credit note document.
The vendor report prior to running F110 and FPRL_LIST looked as follows:
We ran F110 and FPRL_LIST. It is interesting to note that the credit note document appears
with payment method W while we have not changed it on the credit note document. Note that
the Posting Date of the Payment Document (title: Post.date.doc.) is the same for both
documents.
We approved and released for payment.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
19/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
The credit note is netted against the invoice. The vendor report shows the invoice and credit
note cleared:
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
20/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Example 3 –Credit Note in Exception Automatically Assigned when an Invoice is
Posted
For this example, in October we have recorded a FV65 credit note on a vendor that had no
invoice payable. The credit note is not blocked and backdated to 1-July. When we ran F110
today 1-October the item went into exception and this is normal and desirable because there is
no credit against which to offset the debit. We subsequently entered a FV60 invoice and ran
F110 on this invoice.
The vendor history shows no invoice payable for the vendor at the time the credit note is
created. The credit note has a baseline date = 1-July (date per vendor credit note) and Payment
terms of Z001 which results in a net due date = 1 July. Alternatively the baseline date could
have been today instead of 1 July. It is important to not future date credit notes!
After the F110 batch has run for 1 October, we can see that the credit note is in the Unassigned
List. There is no invoice to net against for this vendor:
After documents are assigned to the local Cashier for this House Bank, the credit note will
appear in the Assigned list with Posting Date of Payment Document equal to 1-October:
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
21/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Local Cashier will select this credit note to Approve and Pay as usual.
As expected, a credit note without an invoice will go to exception when we try to pay it. This is
OK. It will remain in exception until the next invoice is due.
Later in October, on 13-October, the next invoice is created with a due date of 13-August (i.e. it
is backdated to reflect the vendor invoice date).
The F110 batch for 13-October will pick up both the invoice and the credit note. The system will
make two changes to the credit note:
i)
Status changes from Exception to Assigned; and
ii)
Posting Date of Payment Document changes from 1-October to 13-October.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
22/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
The invoice will be in Unassigned status (as usual) and will be Assigned as usual by the UNHQ
Cashier.
After the invoice is assigned to the local Cashier’s list, both the invoice and credit note have the
same Posting Date for Payment Document. When both are selected for Approval we obtain the
following error message for the credit note:
Critical!
At this point, leave the invoice in “Release for Payment Status” i.e. do not “Pay”
the invoice without paying the credit note at the same time! The system will not
net the credit note unless we “Pay” both the invoice and credit note at the same
time!
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
23/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Because the credit note has already been approved before it went into Exception, the local
Cashier must Refuse and re-Assign the credit note document. The local Cashier must be careful
to ensure the credit note is released for payment at the same time as the invoice in order to
have only one KZ document for the net amount.
Finally select both the invoice and the credit note together to “Pay” the items and obtain
netting.
When both the invoice and credit note are selected to “Pay”, one KZ document is created for
the net amount.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
24/35
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Job
Aid
Example 4 – Referencing PO vs. Invoice Reference
In this example, we create a MIR7 Subsequent Credit. We want to record the subsequent credit
on the corresponding PO history and we want the credit to expense to have the same account
assignment as the corresponding PO. However, the MIR7 invoice (first invoice) is paid and we
want to link the subsequent credit to a different (new) invoice that is not yet paid (second
invoice) and is linked to a different PO.
Our Subsequent Credit document will reference the first invoice PO number but will link to the
second invoice using the Invoice Reference functionality. The account assignment for each POs
are as follows:
GL Account
Fund
Cost Center
PO #2200000128
74121030
20OLA
10062
PO#2200000794
71171010
20OLA
10062
The vendor report reflected the following before we created the credit note. Invoice
51000001588 linked to the first PO is paid. Invoice 5100002701 linked to the second PO is
awaiting payment:
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
25/35
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Job
Aid
While creating the credit note, the key is to:
i.
ii.
Refer to the PO #1 to get the account assignment of PO #1 (2200000128)
Use Inv. Ref functionality to refer to the second Invoice (5100002701)
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
26/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
The Subsequent Credit document is created with the account assignments of PO# 2200000128
but the payment attributes are copied from the new invoice 5100002701.
After the F110 batch has run, both documents are in the FPRL_LIST Unassigned list. They will
be Assigned by the UNHQ Cashier as usual. Local Cashiers will verify that the subsequent credit
and invoice have the same Posting Date for Payment Document and will ensure they select
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
27/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
both documents together to “Pay”. One KZ document will be created for the net amount of
USD 900.00.
Example 5 – Credit Note is Larger than Invoice
In this example, we have a MIR7 invoice for EUR 120 and a Subsequent Credit of EUR 150 on
vendor 1110001460.
Both items are due for payment. When the F110 batch is run both the invoice and subsequent
credit documents are automatically put in Exception because the sum of documents with a due
date = date F110 is run reflects a net amount due from the vendor i.e. the subsequent credit
exceeds the invoice and there is no net amount due to the vendor. The fact that the credit note
is linked or not to the invoice with the Invoice Reference functionality makes no difference.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
28/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
After the creation of the next invoice, the vendor history shows the following:
When a new invoice is created for the vendor for the same currency and the same Partner
Bank, the first invoice and subsequent credit are automatically put in Unassigned status by the
F110 batch. All three documents have the same Posting Date of Payment Document.
When all three documents are Assigned and Paid together, one KZ document is created for the
net amount.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
29/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Example 6 – Sum of Credit Notes is Larger than Invoice
In this example, we have one FV60 invoice for USD 200 and two FV65 credit notes totaling USD
220 for vendor 1110001460. There is a credit note of USD 150 and one for USD 70. Each credit
notes is linked to the invoice to ensure netting. The vendor history is as follows:
After the F110 batch has run, all three documents are in exception because the sum of
documents with a due date = date F110 is run reflects a net amount due from the vendor i.e.
the two credit notes exceeds the invoice and there is no net amount due to the vendor. The
fact that the credit notes are linked or not to the invoice with the Invoice Reference
functionality makes no difference.
After the creation of a new invoice for USD 65, the vendor history looks as follows:
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
30/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
As explained in Example 5, when the next invoice is entered the F110 batch will automatically
retrieve these three documents from Exception and will place them in Unassigned status for
processing against the new invoice.
The remainder of the steps to Pay these items is the same as in Example 5.
Example 7 – Cashier Selects Only the Invoice in Manual F110
In this example, we illustrate how Cashier can still make mistake which result in non-netting of
credit note against an invoice.
We have one FV60 invoice for USD 100 and one FV65 credit note for USD 20. The credit note is
linked to the invoice to ensure netting. The vendor history is as follows:
In this example, the Cashier manually runs F110 and mistakenly selects only the invoice
document 3100043074. [Mistake #1]
After the manual F110 is run, the invoice is in Unassigned Status.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
31/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Note – Mistake #1
!!! To avoid this mistake, Cashiers should not enter document numbers when they
run F110. Instead, they should enter the vendor number and capture all
documents on the vendor.
The UNHQ Cashier Assigns the invoice to the local Cashier list as usual. The local Cashier pays
the invoice.
The invoice is paid without netting the credit note!
Example 8 – Local Cashier Selects Only the Invoice
This example continues with the documents created in Example 7.
When the second invoice is posted the vendor history looks as follows:
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
32/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
During the next F110 batch (ran open without selecting document numbers), the invoice and
credit note will be put in Unassigned status.
Note – Mistake #2
!!! To avoid this mistake, local Cashiers should sort their FPRL_LIST by vendor and
display the Inv Reference column next to the Document Number column. This will
clearly show what documents are linked to other documents and therefore should
be selected together for payment.
UNHQ Cashier assigns both documents to the local Cashier list. In this example, the local
Cashier only selects the invoice and does not select the credit note for payment. [Mistake #2]
The invoice is paid without netting the credit note!
At the end of the day, the local Cashier “Refuses” the credit note to ensure the Posting Date for
Payment Document is automatically updated by the system. This will be done until a new
invoice is posted on the vendor and the UNHQ Cashier selects both the invoice and the Refused
credit note and Assigns them to the local Cashier list.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
33/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
UNHQ and Local Cashier lists should show the following columns:
Example 9 – UNHQ Cashier Assigns Invoice and Credit Note to Different Lists
This example continues with the documents created in Example 8.
When a third invoice is posted for the same vendor, the vendor history looks as follows:
During the next F110 batch (ran open without selecting document numbers), the invoice is put
in Unassigned status.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
34/35
Job
Aid
User Aid – Creation of Credit Notes to Ensure Payment
Netting
Note – Mistake #3
UNHQ and local Cashiers need send documents that are linked to the same list.
Organizing the list as explained at the end of Example 8 will help, as Cashiers will
see which documents are linked.
In this example the UNHQ cashier assigns the invoice to a separate payment list [Mistake #3].
The invoice is sent to payment list 495 while the credit note goes to payment list 144.
In that case, there is no mechanism to net the credit note against the invoice.
User_Aid_Creation_of_Credit_Notes
_to_Ensure_Payment_Netting_v04
Umoja Training
35/35