Which of the following normally would trigger the b/ar/cr process to record a customer payment?

1         Objective

Financial instruments include a wide range of assets and liabilities at the United Nations (UN) Secretariat reporting entities such as cash, term deposits, investments, contributions receivables and accounts payable. In addition Cash Pools, which represent significant portion of the UN assets, is within the scope of accounting for financial instruments.

The objective of this chapter is to give a brief overview of the accounting lifecycle and relevant guidance on cash management within Umoja environment. This chapter on financial instruments includes Cash management module within Umoja environment. For the accounting lifecycle and relevant guidance on investments that are classified as cash equivalents please refer to Finance Manual Chapter on Investments Management.

This chapter details how an end user, based on the involved Umoja user profiles, should perform roles and responsibilities related to Cash management.

2         Summary of IPSAS Accounting Policies

2.1            Cash and Cash Equivalents - Policy

Cash and Cash Equivalents comprises cash, and short-term, highly liquid investments that are readily convertible to known amounts of cash and are subject to an insignificant risk of changes in value. Financial instruments classified as cash equivalents include investments in term deposits with a maturity of three months or less from the date of acquisition and investments in the Cash Pools which meet these definitions.

2.2            Cash and Cash Equivalents - Examples

The following table summarizes the GL accounts classified as Cash and Cash Equivalents in the statement of financial position:

2.3            Reference

For more details on the IPSAS requirements regarding Financial Instruments, refer to:

·               The IPSAS Policy Framework;

·               The Corporate Guidance on Financial Instruments.

3         Desktop Procedures

3.1            Introduction to Cash Management Module

The Cash Management unit manages all business processes to support the following objectives:

·               Keep the cash balances of the UN bank accounts, funds and grants at optimal levels

·               Support the processing of deposit receipts into the UN bank accounts

·               Support the execution of payments from the UN bank accounts

·               Maintain the stability of the UN's financial structure

·               Manage investments and foreign currency of the UN in a profitable way

Though most cash management activities are performed by UNHQ Treasury in New York, the Cashier offices in the field missions and in OAH also play a key role in the Cash Management process.

The deployment of the Cash Management Module solution brings about efficiency, enhanced control, cost savings and better client services to cash management within UN. This has introduced a number of changes to the way cash management is conducted at UN, specifically on two key areas:

·               Transition to Cash Pooling and House Banks

·               Introduction of Cash Journal to Field Missions

Cash Pooling and House Bank Concept

Umoja introduces cash pooling where funds are consolidated into Treasury Fund House Bank Accounts. Treasury can manage the cash levels in House Banks based on payment forecasts compiled from multi-mission data. The goal is to minimize the number of bank accounts per country. All UN cash is consolidated into UNHQ Treasury Fund (Cash Pool) and each mission/office will have a specific share in the pool. When a mission spends cash, since each mission no longer has its own bank account, that expense is deducted from its share in the Treasury fund and the corresponding House Bank Account.

In payment processing, the Umoja solution requires all UN payments to automatically select the correct house bank and account ID using the following logic:

House bank and Account ID will be based on the following:

1.            Payment method

2.            Payment currency

3.            Location of the vendor/customer/employee (if the payment method is cheque or cash)

4.            Location of the vendor/customer/employee's bank account (if the payment method is other than cheque)

5.            Business Area

6.            Accounting Clerk

Cash Journal

The electronic Cash Journal (CJ) replaces Cash Receipt Vouchers in the field missions. Immediately, on receipt of cash or a cheque, a Cash Journal will be created. A system document will be generated at the end of the process and given to the payee to acknowledge the receipt of the cash or cheque.

Treasury Hub Role

Please refer to Job Aid: Treasury Hub Rolefor, which outlines the specific functionality of the designated Treasury Hub role. Seven T-codes included in this role are presented in the referred Job Aid with explanations and detailed screen shots.

3.2            Cash and Liquidity Management: Reports and Tools

Cash liquidity and management is made up of the following:

·               Cash Position and Liquidity Forecast Reports (3.2.1)

·               Manage Cash Levels (3.2.2)

Umoja Cash and Liquidity Management component consists of 4 integrated reports and 1 cash planning tool:

Back to top

3.2.1        Cash Position and Liquidity Forecast Reports and Tools

Depending on the business needs, the reports can be run on a daily or weekly basis.

Umoja Cash Position/Liquidity Forecast Reports are geared towards daily operations of the Cash and Liquidity Management. These reports are designed to show, in a single screen, all cash-related items that are due on a given day, week, or month.

After uploading the electronic bank statement and reconciling the items, the Cashier generates Cash Position and Liquidity Forecast Reports.

3.2.1.1  Cash Position Report

The following process steps are applicable to generate Cash Posting reports:

A.      Generate Cash Position Report / Transaction Code: FF7A

A.1.      Enter FF7A in the Command field.

A.2.      Click the Enter icon -> the Cash Management and Forecast: Initial Screen appears.

A.3.      Enter the appropriate Data.

·               Enter 1000 in the Company Code field.

·               Enter the appropriate business area code in the Business Area field.

·               Select the checkbox next to Cash Position only.

·               Enter the grouping code in the Grouping field.

·               Enter the report date in the Display as of field.

Note: This field reflects the run date, by default the system proposed the current date as the run date in that field but the user has the option to enter a historical date, MONTH XX YY, however if a past historical date is entered, the report will only capture transactions as of that date. Even if there are subsequent transactions, they will not be considered.

·               Enter the correct currency in the Display in field.

A.4.      Click the Execute icon in the top left hand corner of the screen.

A.5.      Analyze Report Data: Cashiers can review all Cash Management Reports (for this process, Cash Position Report) to identify and resolve issues, for example:

·               Incomplete data - omitted cash flows / balances; or

·               Incorrect data - bank statement details not correctly reflected in Umoja.

3.2.1.2  Liquidity Forecast Report

Missions play an important role in ensuring the accuracy of UN liquidity forecasts. The timely submission and incorporation of mission-related expenses impacts the cash flow reflected in the liquidity forecast in real time.

B.      Generate Liquidity Forecast Report / Transaction Code: FF7B

B.1.      Enter FF7B in the Command field.

B.2.      Click the Enter icon -> the Cash Management and Forecast: Initial Screen appears.

B.3.      Enter the appropriate data.

·               Enter 1000in the Company Code field.

·               Enter the appropriate business area code in the Business Area field.

·               Select the checkbox next to Liquidity Forecast.

·               Enter the grouping code in the Grouping field.

·               Enter the report date in the Display as of field.

Note: This field reflects the run date, by default the system proposed the current date as the run date in that field but the user has the option to enter a historical date, MONTH XX YY, however if a past historical date is entered, the report will only capture transactions as of that date. Even if there are subsequent transactions, they will not be considered.

·               Enter the correct currency in the Display in field.

B.4.      Click the Execute icon in the top left hand corner of the screen.

B.5.      Analyze Report Data: Cashiers can review reports to identify and resolve issues, for example:

·               Incomplete data - omitted cash flows / balances; or

·               Incorrect data - bank statement details not correctly reflected in Umoja.

3.2.1.3  Cash Balance Report

The Business Warehouse Analyst in various departments generates the Cash Balance Reports for Fund/Grant Managers. The reports show the current and future cash balances of specific funds/grants.

C.      Generate Cash Balance Reports for Fund/Grant Managers / Transaction Code: ZGMRBUDGET_REL

C.1.      Enter ZGMRBUDGET_REL in the Command field.

C.2.      Click the Enter icon. The Cash Balance GM Budget Release screen is displayed.

C.3.      In the Report Selection section, select either the Cash Inflows or Available Cash Balance radio button. Both these options allow you to request for reports with different purposes:

·               Cash Inflows: Used to forecast revenue and cash inflows.

·               Available Cash Balance: Used to evaluate the availability of cash before the budget is released from Grants Management to Funds Management. This report must be run by the Budget Officers and assistants to evaluate how much money can be 'released' to implementation (equivalent of spending authority or allotment in Funds Management). This is a necessary step to ensure that the 'spending authority' is given to spend funds only if the cash is received by UN.

Back to top

C.4.      In the Required Selection Criteria section, populate the following fields:

·               Fiscal Year: Enter the current year for the Available Cash Balance report.

·               Fund: Enter the Trust Fund.3

C.5.      Click the Multiple Selection icon to enter a number of funds. The Multiple Selection for Fund pop-up window is displayed.

C.6.      Enter a number of values that can either be cut and paste from the excel file or use the dropdown menu. Next, click the Continue icon.

Note: If you are looking for the related Passthrough grants, ensure that you select the 32 and 33 funds.

C.7.      In the Report Output Options section, select the By Fund or By Fund/Grant radio button. Then, click the Execute icon. The Cash Balances GM Budget Release report is displayed.

Note: The format of the report depends on the Report Output option selected. 'By Fund' option displays a pre-formatted report that can be expanded by clicking the Expand subtree icon. The grants under this fund are displayed.

In the example below, S1-32SAU-000003 Grant has two Passthrough Grants: P1-33SAU-000005 and P1-33SAU-000004.

Grants without relationship are listed at the same level. In example below, Resource Mobilization Grants (R1-32SAU-000009, R1-32SAU-000010, R1-32SAU-000038, R1-32SAU-000040 R1-32SAU-000000 etc.) are standing along.

Note: Sub-totals in By Fund are at the top.

3.2.1.4  Cash Planning Tool - Memo Records

The Cashier reviews Cash Management Reports generated in the system to check if they include all material cash flows. If cash flows deemed to be material for the purpose of cash management are not included in the Cash Position and Liquidity Forecast Reports, the Cashier creates a Cash Planning record which automatically updates the Cash Position and Liquidity Forecast Report. The update is in the form of a Memo, and has no impact on the General Ledger.

Memo records are one-time financial entries that are used to bring transactions that have not been processed in Umoja into the Cash Position and Liquidity Forecast for a specific account. The inclusion of transactions added as memo records results in a cash position that is updated in real-time and not subject to lag-processing times that may be incurred during transaction processing or pending periods.

There are four types of memo records that exist in Umoja; each originates from a different source:

The following process steps are applicable to creation of memo records within Cash Planning Tool.

D.     Access the Create Memo Record screen / Transaction Code: FF63

D.1.     Enter FF63 in the Command field.

D.2.     Click the Enter icon -> the Create Memo Record: Initial Screen appears.

D.3.     Enter the following information:

·               Enter 1000in the Company Code field.

·               Select the type of transaction (Planning type) that will be reflected by the memo record.

D.4.     Press the Enter key

D.5.     The Create Memo Record: Payment advice screen appears.

Note: Data Search functionality can be used for fields containing UN-specific data. This functionality is accessed by clicking the Search icon located next to the field being populated or by pressing F4.

D.6.     Enter the required information:

·               Enter the appropriate date in the Value Date field.

·               Enter the appropriate account code in the Account Name field.

·               Enter the Amount of the item being logged as a memo record.

·               Enter the currency of the memo record in the Currency field.

·               Enter the amount in its local currency in the Amount in LC field.

·               Enter the type of local currency used in the Local Currency field.

D.7.     Click the Enter icon to continue.

Back to top

3.2.2        Manage Cash Levels

The Cash Position and Liquidity Forecast is used in conjunction with projections from local missions to determine when current cash levels in a House Bank Account are too low to cover projected expenses that will be paid from that account. This enables UN Treasury to replenish the cash level of that account before the payments are processed.

Depending on the type of account being replenished (determined by currency held and location), the cash level of a bank account can be replenished in one of two ways:

E.      Bank-to-Bank Transfer / Transaction Code: FRFT_B

Note: This process is for USD bank to bank only. For non-USD currency, refer to section 3.1.2 of the Finance Manual Chapter on Investments Management.

A Bank-to-Bank Transfer replenishes account fund levels through the transfer of money from one account to another are made via SWIFT.

E.1.      Create and approve transfer payment request.

E.1.1.      Enter FRFT_B in the Command Field.

E.1.2.      Click the Enter icon -> the Fast Entry with Repetitive Codes (Bank-to-Bank Transfer) page appears.

E.1.3.      All House Banks are saved in Umoja as master data.

E.1.4.      Enter the code for the House Bank receiving the transfer in the House Bank field.

E.1.5.      Press the Enter key -> the House Bank Transfer information populated in the Selected Repetitive Codes section.

E.1.6.      Click the Create Payment Request button.

E.1.7.      The Display logs window appears indicating that a payment request has been generated for the House Bank entered.

E.1.8.      Click the Enter icon -> the payment request appears in the Open Payment Requests table.

E.1.9.      Click the Pay button.

E.1.10.  The Display logs window reappears indicating that the payment request has been released and paid.

E.1.11.  Click the Enter icon.

E.2.      Transmit MT-202 SWIFT message

The creation and approval of a transfer payment request results in the automatic generation of an MT-202 SWIFT message in Umoja. This is a message used by Treasury to communicate high value transfer instructions between bank accounts it manages.

It is transferred to the Bank Communications Management (BCM) for distribution to the bank signatories assigned to the House Bank Account from which the money is being transferred. The bank-to-bank transfer cannot be executed until it is approved by the House Bank's signatory.

BCM automatically sends the MT-202 SWIFT message.

When a Payment Proposal is created by a Cashier, Umoja checks if the House Bank Account has a sufficient balance to cover the payments. If not, a Cashier will initiate a Cash Concentration Process, which will create a cash transfer payment request to transfer the required funds from the Money Market Accounts to the House Bank Account.

For the process in which the balance of the US dollar House Bank Account will be replenished and the effects of changes in foreign exchange rates for replenishment of a non-US dollar House Bank Account, refer to section 3.1.2 of the Finance Manual Chapter on Investments Management.

Upon receipt of the SWIFT MT-202 message from SWIFT, the House Bank where the Investment Pool Bank account is maintained will transfer the funds to the House Bank Account whose balance is insufficient. This replenishment will enable the outgoing payments originating from the Payment Proposal to be released.

E.3.      Receive Ack/Nak message from bank

Once the bank has received and processed the MT-202 SWIFT message, it sends an Ack/Nak message to Treasury confirming the transfer. This message is received via BCM and marks the end of this process.

Caution should be taken not to re dial / re initiate a payment document whose status is 'Rejected by bank'. UNHQ Treasury communicates responsibility for correcting a payment error e.g. removal of invalid characters, correction of bank account etc. to the mission cashier.

There are instances especially with the UNHQ Treasury house banks wherein the payment status is 'Payment Medium Created' despite the transfer having been successfully wired. This can be confusing as the standard status of successful wire transfer is 'Received by Bank'.

Note: The liquidation and purchase of investments and the purchase of foreign currency is handled by Treasury. These activities are covered in Chapter on Investment Management.

Back to top

3.3            Umoja Payment Processing

3.3.1        Process Outgoing Payments in Umoja

Outgoing payment is the process by which Treasury facilitates payments. It is the final touch point before the payment files are transmitted to House banks (Banks used by the UN) or cheques are printed.

Outgoing payments are initiated from the following sources:

·               Source 1: Payment processing from AP are items which are processed through the AP payment process and associated with a vendor. Based on the parameters entered for a given Payment Proposal Run, a payment proposal is first generated by the system. Payment Parameters will include the Payment Currency, Payment Methods, the valid Customer / Vendor Accounts, the 'Up-to Due Dates' on open items, etc. Once the Proposal is validated, Treasury can make the final selection of payments and execute the Payment Run. The payment program or transaction code F110 posts payments and clears the corresponding open items on a vendor account. Additionally, it will generate the required payment media; Cheque, ACH, Wire, or files to be transmitted to other UN Agencies requesting them to make payments on behalf of the UN.

·               Source 2: Treasury payments are payments initiated based on settlement instructions for Treasury Transactions (Investments, Foreign Exchange Instruments, Internal bank transfers). These payment instructions are setup in the counterparty information in the Business Partner record. Upon settlement of the Treasury Transaction, the payment instructions are inherited from the contract, and accordingly the necessary journal entries and a Treasury Payment request is generated. This in turn allows for separate payment runs, if desired, where high value transactions are managed using the Treasury Payment Program and operational day-to-day payments are processed using the standard Financials Payment Program.

* Treasury payments are covered in the Investment Management Chapter.

Treasury payments are primarily applicable to:

·               Time deposits where payments are handled by the UN

·               Payments on Foreign exchange (FX) Spot transactions

·               Payments on Foreign exchange (FX) Forward transactions

·               Internal bank transfers when accounts are in surplus or deficit

The Outgoing Payments process identifies the steps to create a payment proposal, conduct required cash sufficiency checks, hold a payment (if necessary) and release the payment.

3.3.1.1  Process Outgoing Payments - House Bank Method (Method 1)

The end-to-end outgoing payment process through a House Bank is as follows:

3.3.1.1.1 Payment Proposal

Prior to generating the payment run, the parameters to generate the payment proposal are entered. The Proposal can then be displayed or printed to get an overview of the payments proposed by the program. The process can also propose the grouping of payments to the same vendor and netting with accounts receivable. When the proposal is created, the system checks the results, reading the proposal log and records any exceptions to it.

Parameters included in a payment proposal are:

1.            Accounts to be included in the payment run

2.            Account types

3.            Desired posting date

4.            Payment method

5.            Payment currency

6.            Date of next payment run

7.            Payment grouping when being paid out to the same vendor (Optional Parameter)

8.            Netting with Accounts Receivable (A/R) (Optional Parameter)

F.       Create the Payment Proposal / Transaction Code: F110

F.1.       Type F110 in the Command field.

F.2.       Click the Enter icon -> the Automatic Payment Transactions: Parameters screen appears. Populate required details in the following parameter fields:

·               Enter the run date in the Run Date field.

·               Enter the list number in the Identification field to identify the payment in Payment Release List.

·               Enter the current date in the Posting Date field.

·               Enter the document entry date in the Docs entered up to field.

·               Enter 1000 in the Company codes field.

·               Enter the Payment Method (Pmt meths). Usually plus one day from the Docs entered up to date.

Note: Each payment method is represented by a symbol in Umoja. When you scroll over that field in the system, the menu icon will appear. Click the menu icon to view the list of payment codes.

·               Enter the Next Posting Date (Next p/date)

·               Enter payments for a range of vendors in the lists in the Vendor account field.

F.3.       Click the Free selection tab and enter the appropriate selection criteria:

·               Click the Document Number from the Mathcode Field Name menu.

·               Enter the document number in the Values field. Use a comma when specifying more than one document number.

Note: Free selection entries are strictly optional and will normally use when we want to make a specific payment.

Back to top

F.4.       Click the Additional Log tab and enter the following data:

F.4.1.       Check the options in the Required logging type section:

·               Due date check.

·               Payment method selection in all cases.

·               Line items of the payment documents.

F.4.2.       Enter the account number for the vendor being paid in the proposal in the first text box in the Accounts required section.

Note: If multiple vendors are being paid, a range can be entered by adding the account number of the last vendor in the second text box.

F.5.       To activate the Payment Release List proposal, click the Save icon to save all the parameters entered.

F.6.       Click the Status tab.

F.7.       Click the Proposal button.

F.8.       The Information dialog box appears stating that the 'Payment Release List is activated'.

F.9.       Click the Checkmark button.

F.10.   Click the Status

F.11.   The first time you click the Status button, the Schedule Proposal pop-up window appears. The user can either schedule the proposal to run at a certain date and time or run it immediately by clicking the Start immediately check box.

In this example: The proposal will run immediately as the Start immediately checkbox has been selected.

F.12.   Click the Status

F.13.   After the payments release list is proposed, the items in the list are further grouped into smaller lists according to different payment criteria. The sub-lists are then approved and released for payment.

3.3.1.1.2 Cash Sufficiency Check and Create Payment Release List

Payments to Member States for reimbursement of troop/COE will be flagged by the system for confirmation of 3 month cash availability prior to payment. The Cashier will check whether the Fund has sufficient cash balance to cover the next 3 month expenditures. If not, the Cashier will hold the payment until sufficient cash is available for the Fund in question. The partial automation of the process of validating the 3 month cash sufficiency would require a custom enhancement. The custom enhancement of three months cash availability check as a business rule will be evaluated as of a later phase in Umoja.

G.     Cash Sufficiency Check at Fund/Grant Level / Transaction Code: FMCCAVCOVERVIEW

Before payments are processed, the Payment Approver via the payment program must check that there are sufficient funds in the Fund/Grant. If cash insufficiency is found for a Fund/Grant, a question should be asked whether the overriding of such insufficiency by Treasury personnel is pre-authorized.

If no pre-authorization is given, the Cashier should hold the payment. A request for the Inter fund Borrowing may be initiated in the event that the Cash Sufficiency check fails and there is no pre-authorization received to make the payment.

Therefore after creating a payment proposal, the user must conduct a cash sufficiency check to ensure that the cash balance in the identified account is sufficient to cover the proposed payment.

G.1.     Type FMCCAVCOVERVIEW in the Command field.

G.2.     Click the Enter icon -> enter the data required to run the cash sufficiency check.

·               Enter 1000 in the Company Code field.

·               Enter 9P in the Control Ledger field.

·               If appropriate, enter the Fund to narrow down your selection.

G.3.     Click the Execute icon to run the report -> the Cash Control Overview Report for the selected Ledger appears. Review the report. Expand the necessary folders and double-click amounts to see the desired information.

Back to top

H.     Cash Sufficiency Check at House Bank Account Level

After the cash sufficiency check at Fund/Grant Level, the cash sufficiency check at House Bank Account Level is performed. Cashier checks if the House Bank account has sufficient balance to cover a payment. Although a fund/grant may have sufficient cash, this cash may not be in the specific House Bank account from which the payment will be made. This cash sufficiency check is bypassed if a payment is to be paid by the UN Agency on our behalf.

If a House Bank Account does not have sufficient balance to cover the payment, then the Cashier takes the appropriate action to replenish the bank account and/or can remove payments from the Payment Proposal. Depending on the currency of payment, the Cashier takes a different action to replenish the bank account.

To replenish House Bank account, please refer to the manage cash levels section for USD and for replenishment of foreign exchange in the section 3.1.2 of Finance Manual Chapter on Investment Management.

I.        Creating/Editing the Payment Release List / Transaction Code: FPRL_LIST

Once payment proposal is created by the Treasury, Offices will do the approval and payment from their House Banks.

I.1.        Enter FPRL_LIST in the Command field.

I.2.        Click the Enter icon.

The FPRL_List screen displays the last Payment Release List created by the user. The settlement and item data in the payment proposals created in the Automatic Payment Program (T-code F110) are displayed as open items in a list of unassigned items.

All payment proposals must be assigned to a Payment Release List in order to be processed and released in Umoja. If no Payment Release Lists have been created, the screen appears blank.

Note: It is recommended that a new payment list is created every time FPRL_LIST is run. This will assist the user in keeping track of what has and has not been processed. One list should be made for each type of payment. Ex: USD cheque payments.

I.3.        To create a Payment Release List, click the Create New List

·               Enter a list name in the Description field.

·               Select the correct user ID in the Processor field.

Note: Selecting a processor enables the system to pull all payment proposals created by that user into the list being created.

I.4.        Press the Enter icon

I.5.        Click the Unassigned tab.

I.6.        Select the payments to be made by clicking on the button on the left side of each row. Use Ctrl-Click or Shift-Click to select multiple rows.

I.7.        Click the Assign Items

J.        Approving Payment Release List / Transaction Code: FPRL_LIST

J.1.        Click the Assigned tab.

J.2.        Select the payments to be made by clicking on the button on the left side of each row. Use Ctrl-Click or Shift-Click to select multiple rows. When all desired rows desired are selected, then they will be highlighted.

J.3.        Click the Approve Items

K.      Make payments / Transaction Code: FPRL_LIST

IMPORTANT: These steps only apply when Cashiers have to do an emergency payment which cannot wait for the scheduled payment run by the Treasury.

K.1.      In the Assigned tab, select the payments to be made by clicking on the button on the left side of each row. Use Ctrl-Click or Shift-Click to select multiple rows.

K.2.      Click the Pay Items

Note: Mission Cashiers are advised not to create separate payment release lists for each payment processed. The main purpose of creating a separate payment release list is to avoid locking out of other users from processing payable documents.

K.3.      Click the Refresh button - Item Status changes to 'Paid' and document number is generated.

Back to top

3.3.1.1.3 Schedule Payment Run

Once the payment proposal is approved by the Payment Approver, the payment run is scheduled. The job created for the payment run will contain either the payment program as one step or an extra step for each payment method and each variant. In scheduling the payment run, the desired start time is set and the print or processing options are selected. The system will determine the Paying Bank based on pre-defined rules. The rules are based on the combination of Payment Currency, Payment Method, Country of Vendor Bank, and other factors. The system also considers the Payee Country in determining if Bank Chains need to be processed (Payment via Intermediary Banks). After checking the cash sufficiency at the account level, the user merges payments and schedules a payment run.

L.       Executing the payment run and payment medium / Transaction Code: FBPM1

Note: Payments are batched according to currency first, then vendor.

L.1.       Type FBPM1 in the Command field.

L.2.       Click the Enter icon -> the Creation of Cross-Payment Media screen is displayed.

L.3.       Specify the selection criteria for the payments to be included and create the payment media.

·               In the Pymt.runs section, enter the processing date in the Run Date field (do not enter the value date).

·               Enter House Bank.

·               Enter Payment method.

·               Enter Currency.

L.4.       Click the Execute icon -> a dialog box will display stating the number of payments selected, the medium run created and an indication that the program has started as a separate job:

Note: It is advisable to run payment batching at the end of the day once all payments have been entered (prior to applicable bank deadlines).

L.5.       After scheduling a payment run, the payment batch is automatically sent to the Umoja Bank Communication Management (BCM) program to be released. The batch will not be released from BCM until it has been approved by the bank signatories associated with the House Bank account the money is being withdrawn from.

Below is a proforma accounting entry created when the payment is approved for payment release:

* The specific BP account number selected in data entry view determines the AP reconciliation account that will be pulled in accounting entry. In this pro-forma entry, BP account range 20 will call BP account group Z020 which is Staff Member, Ex-Staff Member and derive GL account 35101610 AP UN Staff Member.

**In the above accounting entry, the transaction crosses two different business areas and funds, thus additional line items for GL account 11701010 Cash Held in UNHQ Main Pool are automatically created to balance the transactions per business area and per fund level.

Document type KZ (Vendor Payment) is automatically assigned by the system for payment transactions.

3.3.1.1.4 Release Payment Files

If a payment is to be made through bank transfer, the system creates and transmits payment files. When a payment mode is EFT, upon the execution of the payment run, Umoja creates an EFT payment file. The format may be ACH, SWIFT or others as predefined by the payment method. Umoja will generate the Payment files in the required format. The ACH files are securely uploaded through FTP (File Transmission Protocols) and transmitted to House Bank using File Act. The SWIFT files are transmitted to House Banks through SWIFT network. The UN Treasury is a SWIFT participant and maintains desktop access to the SWIFT Alliance portal in-house.

Umoja also sends emails to the payees and relevant parties (payment requesting offices) advising them of EFT payments. Such details as the amount, EFT value date, Paying bank, routing details, and payment purposes will be included in the email advice.

The following steps are conducted by the bank signatories to review, approve and release a payment batch:

M.   Release/approve payment batch / Transaction Code: BNK_APP

Note: Only a bank signatory can review and approve the list of batches being paid from the House Bank Account for which s/he has been delegated authority to serve as bank signatories. Dual approval requires two different bank signatories to approve the batch.

M.1.   Enter BNK_APP in the Command field.

M.2.   Click the Enter icon -> the Payment Batches screen appears displaying all payment batches created in the system. A batch can be easily located by referencing its run date or its three letter identification. As stated in each line item, a batch requires approval by two separate bank signatories.

The Payment Batches screen groups batches into separate tabs based on status:

Back to top

M.3.   Highlight the batch to be processed.

M.4.   First Bank Signatory: Click the Approve

M.5.   Click the Enter button or press the Enter key to confirm. -> The batch line item is moved to the Additional Release Steps tab and is now ready for approval by the second bank signatory.

M.6.   Second Bank Signatory in the Additional Release Steps tab: Highlight the appropriate batch line item.

M.7.   Click the Approve button -> a pop-up box appears prompting the user to confirm that the batch is being approved.

M.8.   Click the Enter button or press the Enter key to confirm.

Note: The second Bank Signatory approval triggers the automatic release of the batch. For batches containing electronic payments, a SWIFT202 message is automatically generated and sent to notify the bank that the specified amount must be drawn and deposited in the vendor's bank account. For cheques, the second Bank Signatory approval triggers cheque printing.

3.3.1.1.5 Review and Manage Payment Batches Following Approval

The Batch and Process Monitor screen is a component of the BCM program and is used to review SWIFT messages sent to banks following batch approval and manage cheque log and print cheques

Review SWIFT messages

N.     Monitor and track status of payments processed by batch / Transaction Code: BNK_MONI

N.1.     Type BNK_MONI in the Command field.

N.2.     Click the Enter button -> the Batch and payment monitor screen appears.

N.3.     Click the Expand

·               Paying company code

·               House Bank

·               Run Date

Note: This is an inquiry screen that provides the user with filtered views of system data. Each additional field populated increases the specificity of the data by filtering it.

N.4.     Click the Execute button.

N.5.     The Batches screen appears displaying all batches created in Umoja within the parameters entered on the previous screen (e.g. House Bank Account).

Note: For the vendor field; with the adoption of EU1 a search of a staff member payable using the KZ document should be in the format 2000 + XXXXXX (Index number). For a search of a staff member payable using the PY document should be in the format XXXXX (index number)

A consolidated list of all batches is displayed in the All tab. Batches are also listed in separate tabs according to status:

N.6.     To retrieve additional information for each batch line item, highlight the appropriate line item and click the FILES

Back to top

N.7.     Select the File for this batch menu option to display the SWIFT MT202 message sent to the bank for completed electronic batch line items.

Verify printed cheques

For cheque payments, Umoja creates a cheque file to print cheques and the corresponding Positive Pay Files. Positive Pay is a tool available to prevent cheque fraud currently being used by the UN. Umoja transmits the Positive Pay Files to the House Bank containing information on the cheques issued. Once the bank is in receipt of the file it will only honor cheques which match the information in the Positive Pay File. Any cheques presented which do not reconcile to the cheque data on the Positive Pay Files will not be honored by the bank. The reconciliation is carried out based on cheque amount, cheque number, and cheque date. The Bank in turn will present the details of these unmoored cheques to Treasury. The process can be run on a weekly, daily, and multiple times a day basis, but depends on the frequency of transaction code F110 or outgoing payments and the arrangements with the specific banks.

Umoja also sends emails to the payees and relevant parties (payment requesting offices) advising them of issuance of cheques. Such details as the amount, cheque number, cheque issue date, cheque distribution method, and payment purposes will be included in the email advice.

Additionally, the Cashier updates the status of cheque distribution: mailed, uncollected, collected at Cashier's Window. Umoja will update the cheque register for cheques cleared on a given clearing date based on the information received on the UN Bank Statement.

If a payment is to be made by cheque, Cashier executes the cheque run that will create a file to be uploaded to a cheque printing system. The system will also create a Positive Pay File for transmission to the House Bank.

O.     Verify printed cheque against the Cheque Register (FCHN) / Transaction Code: FCHN

O.1.     On the Check Register screen, enter the Paying Company Code and House Bank.

O.2.     To narrow down the selection, you can also populate the range in the following fields under the Further Selections tab:

·               Date of Issue

·               Payment document no.

·               Checks from Payment Run

·               Checks from an extract

O.3.     Verify that all the printed cheques have the correct numbers in the Register. This is usually the case, if the pre-printed number on the cheque form and the number printed by Umoja are aligned. The Cheque Register also keeps track of voided cheques (upon reprint FCH7 or FCH8 void and reverse or FCH3 voiding of unprinted cheque stock)

Void and reprint FCH7 will list the same Payment Document number.

Note: Since the numbers are not necessarily in sequence, you may filter or sort on the Payment Document number.

The Check Register also tells you if the bank statement has already reconciled a cheque.

P.      Verify that no cheques have failed / Transaction Code: BNK_MONI

P.1.      Click the Expand icon in the Batch and payment monitor screen.

P.2.      Populate the following fields to display the batches:

·               Batch Number: It is the range of batch numbers obtained upon approval.

·               House Bank

Back to top

P.3.      Click the Execute button.

P.4.      Click the Exceptions tab.

Note: In case of an exception, please consult with the support to determine the root cause. Typically, transaction code FBRA (reset cleared items) is being used to correct this condition; however, this should only be done upon advice of Umoja support after investigating the cause.

Corrective Action:

Below table gives correction actions that can be taken based on scenarios presented.

P.5.      Send remittance advice / Manual

When ACH/EFT files are transmitted to the House Bank / IRS or when a UN Agency is requested to make a payment to a specific payee, the system sends emails to the payees and relevant parties advising them of the payments.

3.3.1.2  Process Outgoing Payments- Cash Journal (Method 2)

The Cash Journal is functionality in Umoja that is used to record the following types of cash transactions:

·               Main Cashier's Imprest Disbursements

·               Imprest Disbursements

·               Petty Cash Transactions

Note: For all journal entries refer to the Cash Journal transactions in Finance Manual Chapter on Accounts Payable (section 3.2.7.2), which includes an exhaustive list of entries for set up of Cash Journal, replenishments (outgoing payment for replenishment and post replenishment fund) and various other transactions processed in the Cash Journal.

Cashier, Petty Cash and Imprest Custodians now record journal entries in Umoja at the time of cash disbursement.

3.3.1.2.1 Disbursement from the Main Cashier's Imprest

Cash can only be disbursed from the Main Cashier's Imprest if a payable is raised by Accounts Payable for the required amount. The document number generated when the payable was posted is entered in the Assignment field in the Cash Journal.

Q.     Posting disbursement from the Main Cashier's Imprest / Transaction Code: FBCJ

Q.1.     Enter FBCJ in the Command field.

Q.2.     Click the Enter button.

Q.3.     In the Cash Journal pop-up window, enter 1000in the Company Code field.

Q.4.     Select the appropriate Main Cashier's Imprest journal.

Q.5.     Click the Enter button -> the Main Cashier's Imprest appears.

Q.6.     Click the Today button to ensure that the available balance of the journal is up to date.

Q.7.     Click the Cash payments tab and enter the following information:

·               Select PAID TO VENDOR in the Business transaction column.

·               Enter the transaction Amount.

·               Select the vendor being paid.

·               Enter the document number of the associated approved payable in the Assignment field.

Q.8.     Press the Enter key to auto-populate remaining required fields. Remaining required information is auto populated in each respective column and the red status light appears in the DocStatus column.

Q.9.     Highlight the transaction.

Q.10.Click the Post sel.

Q.11.Click the Follow-on doc. button àthe List of Documents in Accounting pop-up window appears.

Q.12.Double-click the Accounting document row.

Q.13.The General Ledger View shows the transaction line item posted to the Accounts Payable Subsidiary Ledger and the transaction line item posted to the Reconciliation Account.

Back to top

Q.14.To view more details on the vendor transaction, double click the vendor line item. The Vendor Line Item Display provides additional details on the transaction, including:

·               The corresponding invoice.

·               The cashier's imprest payment transaction.

3.3.1.2.2 Disbursement from Petty Cash Account

R.      Posting disbursement from Petty Cash Account / Transaction Code: FBCJ

Follow the steps Q.1-Q.6 by selecting the appropriate Petty Cash account from the Cash Journal options window.

After the available petty cash balance in the selected account has been confirmed, the disbursement can be documented and posted.

R.1.      Click the Cash payments tab and enter the following information:

·         Select the EXPENSE in the Business transaction column.

·         Enter the disbursement amount in the Amount column.

·         Enter the appropriate GL number in the G/L column.

R.2.      Press the Enter key to auto populate remaining required fields in the transaction row. Remaining required information is auto populated in each respective column and the red status light appears in the document status column.

R.3.      Click the Save sel.

R.4.      Click the Post sel.

R.5.      The petty cash amount posted can now be disbursed by the cashier.

3.3.1.3  Process Outgoing Payments - Payment through UN Agency (Method 3)

In some cases, the UN requests other UN Agencies to execute payments on our behalf. An example may be a request to UNDP, Tehran as a pay agent to make a US dollar payment to a UN payee because Iran is subject to the US sanction and the UN cannot make a payment through a US bank. The UN Agency payment is considered as one of the custom-defined payment methods. A payment through a UN Agency will bypass the cash sufficiency check at House Bank account level because there will be no physical cash outflow. Payments requested to UN Agencies will be processed and recorded through the Accounts Payable and Treasury Modules, as if cash was issued, but the outcome will be a file transmitted to the UN Agency with the payment request. For detailed process steps please refer to Finance Manual Chapter on Accounts Payable under Inter - Agency document processing (section 3.2.5).

3.3.2        Process Incoming Payments in Umoja

Incoming Payments come in three forms:

·               Electronic Funds Transfers (EFTs)

·               Cash

·               Cheques

All incoming payments are recorded in the Pool Funds described earlier. The majority of incoming payments are received as EFTs which are brought into Umoja when the prior day bank statement is uploaded into the system. As the process of uploading bank statements also triggers the automatic matching of incoming payments to open Accounts Receivable items, this is covered in section 3.4 Bank Reconciliation, where the automatic reconciliation of bank transactions is examined.

The other remainder of this process is the receipt of incoming payments as cash and cheques. The Cash Journal functionality is used to record both incoming cash and cheques. The following are the different business transaction types set up in Umoja Cash Journal to manage the incoming cash and cheques using transaction code FBCJ:

·               Cash or Cheque receipt from Customer

·               Cash or Cheque receipt from Vendor

·               Cash or Cheque receipt with credit to Revenue account

·               Cash or Cheque receipt from Bank e.g. replenishment of Petty Cash or Imprest account

The high-level process followed to process incoming cash or cheque payments is as follows:

3.3.2.1  Receive Cash and Cheques

At the UN, only the authorized offices (hereafter called Cash Management Offices) can receive money on behalf of the Organization. While the UN strongly encourages customers to pay us through EFT payment, there are some occasions where cash, cheques, traveler's cheques, money orders, postal orders, or other monetary instruments (hereafter called cheques in this document) are received at the Cash Management Office. In the Umoja, individual Cashiers working in Cash Management Offices are identified by a Cash Desk.

3.3.2.2  Confirm the Purpose of the Payment

When cash or cheques are received, the Cashier verifies the purpose of the payment. The purpose for which a payment is made should be consistent with the policies, aims, and activities of the UN.

3.3.2.3  Examine the Validity of Cash and Cheques

The Cashier should verify the following to make sure that the funds will be received into the House Bank Account without any issue:

·               Cash is not counterfeit;

·               Cheque is properly signed;

·               The issue date of the cheque is valid (not postdated, nor stale dated);

·               Cheque is made payable to the UN or to the name of the bank account where the cheque is to be deposited;

·               The amount in the numbers on the cheque agrees with the amount in words;

·               The total of the cash and cheques received agrees with the amount in the accompanying memo.

Back to top

3.3.2.4  Post Receipt of Payment in Cash Journal

Following the verification, the Cashier processes the payment by posting the receipt to the Cash Journal.

S.       Posting receipt of cash/cheque payment / Transaction Code: FBCJ

S.1.       Enter FBCJ in the Command field.

S.2.       Click the Enter button -> the Cash Journal screen appears and the Cash Journal Specification window pops-up.

S.3.       Enter 1000 in the Company code field.

S.4.       Select the Cash journal to be opened.

Note: The Cash Journal entered will determine the currency displayed.

S.5.       Click the Continue icon -> the Cash Journal screen appears. Click Today button to ensure that the available balance of the journal is up to date.

S.6.       Click the Cash receipts tab for payments received in cash or Check receipts tab to record payments received by cheques.

S.7.       Select the appropriate business transaction from the menu in the Business transaction field and click the Continue icon.

S.8.       Enter all relevant fields to record the payment receipt:

·               Amount.

·               G/L: The system will populate the GL account depending on the type of Business transaction selected.

Note: If the GL account is unknown and the payment receipt is to be recorded as Revenue, select GL account 39201020 (Unapplied cash).

·               Text: Enter text identifying reason for receipt.

·               Vendor or Customer number: Applicable to record cash/cheque receipt from vendor or customer.

·               Document Date

·               Reference

·               Assignment: If an Accounts Receivable exists, enter the document number in this field.

·               Business Area

·               Fund

S.9.       Press the Enter key to save the line item. The line item is saved, as indicated by the status triangle in the DocStatus field (column 3).

S.10.   Once all entries have been added click the Select button on the left side of the line item and click the Post button to post the payment(s) entered to the Cash Journal.

S.11.   The status in the DocStatus field will turn to green and the closing balance of the journal is automatically adjusted.

Note: More detailed process step instructions including the proforma accounting entries created for each incoming payments are outlined in section 3.2.7 of Chapter on Accounts Payable under Petty Cash Fund business process steps. The process steps to use Cash Journals are the same for Petty Cash Fund, Imprest Account, and Cashier's Incoming.

T.      The following tables describe the generic set of Accounting Journals under different scenarios:

T.1.      Scenario A: Fund, Customer and specific Open Item are identified.

* The specific BP account number selected in data entry view determines the AR reconciliation account that will be pulled in accounting entry. In this proforma entry, BP account range 15 will call BP account group Z015 which is NGOs and Intergovernmental and derive GL account 15101410 Non-Governmental Organizations & Intergovernmental.

Document type DZ (Incoming Payment) is automatically assigned by the system for payment transactions.

Back to top

T.2.      Scenario B: Only Customer is identified.

Same proforma accounting entry will be created as in Scenario A using the Cash Journal. The Cash Journal number is linked to business area through substitution rule. It means transactions entered in Business area P001. Cash Journals will always be assigned to business area P001 and fund 20CUA.

T.3.      Scenario C: Only Fund is identified.

Document type DZ (Incoming Payment) is automatically assigned by the system for payment transactions.

T.4.      Scenario D: Neither Customer nor Fund is identified.

Same proforma accounting entry will be created as in scenario C.

Note: In all scenarios outlined above for incoming receipts managed through Cash Journals, subsequent process steps are required to clear the AR open item in sub-ledger against payments received. For scenarios A and B, where the incoming payments are credited to BP with customer role accounts, use transaction code F-32 to clear the specific AR open invoice against the credit posted from incoming payment. Whereas, for scenarios C and D where the incoming payments are temporarily credited to Unapplied Cash Journal account, use transaction code F-30. The detailed process steps for transaction codes F-32 and F-30 are in section 3.2.2.5 of Chapter on Accounts Receivables.

3.3.2.5  Issue of Receipt, Deposit Cheque and Cash Desk Closing

3.3.2.5.1 Issue of Receipt

In lieu of customer/vendor portal update, if applicable, the system will send emails to the payors confirming receipt of cheque payments. Since Accounts Receivable unit sends official receipts, attention should be paid in deciding what information will be included in this email confirmation.

A receipt can be issued by the Cashier from the Cash Journal (T-code FBCJ) acknowledging receipt of the payment by selecting the Print Receipt

3.3.2.5.2 Deposit Cheque/Cash

Below are several ways that a Cashier can do to deposit cheque/cash received:

U.     Over the Counter / Manual

A Cashier deposits cash and cheques received using the pre-numbered deposit slips. As part of the process, the deposit slip number is recorded in Umoja in order to facilitate the automatic reconciliation (match and clear) of the over-the-counter deposit to the Bank Statement.

V.      Mail Cheque for Deposit / Manual

Applicable where a Cashier's Office is located far away from the depository bank where the cheques need to be deposited, cheques will be sent to the depository bank by secure means. This 'Deposit Process' involves recording the deposit slip number as well as an expected date of cheque deposits to accommodate the time lag between the receipt of the payments and the over-the-counter deposit to the bank, for cash management purposes.

W.   Send Cheque for Collection / Manual

A cheque in US dollars drawn on a bank outside of the United States (hereafter called a foreign cheque) requires special processing because it cannot be deposited to a US dollar bank account in the United States. The depository bank (i.e. the UN Bank) has to send the cheque to the drawee bank (i.e. the payor's bank) to collect the proceeds of the cheque. Collection fees will be deducted from the face amount of the cheque, both by the drawee bank and the depository bank. The bank account of the UN is credited only when the proceeds of the cheque are received, which is usually a few weeks after the date when the cheque is sent to the depository bank for further collection.

In Umoja, for each foreign cheque received there will be a unique, separate deposit within the Cash Desk. Once the proceeds are realized, the originating source of the payment can be recorded with any associated bank fees.

3.3.2.5.3 Cash Desk Closing

At the end of the day, the Cashier closes out the Cash Journals in the system by processing all cash paid, cash and cheque receipts. All cash and cheque receipts received for the day will be subsequently deposited using the business transaction 'payment to bank' to reduce the balance of Cash Journal.

For detailed steps and related accounting entry created, please refer to section 3.3.1.1. This entry is a result of putting the cash into the clearing account and out of petty cash as the cash has been deposited.

Document type ZI (Imprest Account) or ZP (Petty Cash) is automatically assigned by the system for Cash Journal (CJ) transactions depending on Cash Journal type used.

The following day when the electronic bank statement is uploaded to Umoja, the Bank ABC Cheque/Cash Receipt In (suspense) Account is cleared against the Bank Account. The following are the GL entries.

Document type ZR (Bank Reconciliation) is automatically assigned by the system for bank reconciliation transactions.

3.4            Bank Reconciliation

Bank reconciliation is made up of three components shown in the image below:

The bulk of the bank reconciliation activities are based around the Outgoing and Income Payments transactions to a bank account and the reconciliation framework in Umoja is based on:

1.             House Banks:

With the introduction of House Banks in Umoja, all bank accounts now belong to one of the three Treasury Pool funds.

·               Main Pool - Cash & Investments 64VQA (for all operational in/out payments)

·               EUR Pool - Investment 64VQE

·               UNSMIS Pool - Investment 64VQZ

Operational Funds (e.g. Missions) no longer have balances in their own bank accounts. Instead, they have equity in the Treasury Main Pool. The equity of each Fund in the Pool increases with the Fund's incoming payments and falls with outgoing payments.

2.             Nominal and Bank Clearing Accounts:

In Umoja besides the Nominal account opened for each physical bank account, there are seven other GL accounts associated with the same bank account. These eight accounts are used to record the balance and reconciling items linked to the physical account.

Example:

·         1-101-1010 Cash HQ USD Nominal

·         1-101-1011 Cash HQ USD Cheque Out

·         1-101-1012 Cash HQ USD Cheque In

·         1-101-1014 Cash HQ USD EFT Out

·         1-101-1016 Cash HQ USD EFT In

·         1-101-1017 Cash HQ USD Invest

·         1-101-1018 Cash HQ USD Charges

·         1-101-1019 Cash HQ USD Unidentified

Through reconciliation process these clearing accounts will ensure that bank reconciling items do not appear in the GL Bank Nominal account and the balance in the Nominal GL account is equal to the balance in the physical bank account.

3.             T-code: FEBAN:

The transaction code is used to access bank statements that have been uploaded into Umoja and to perform bank reconciliation accordingly.

Daily Bank Reconciliation and Cash Management begin with the process whereby Treasury reconciles the Prior Day Bank Statements against the Operational transactions (Accounts Payable and Accounts Receivable), as well as the Treasury Transactions, so as to ensure that:

·               All cash transactions are recorded;

·               Unidentified items appearing on the daily bank file are investigated and resolved; and

·               UN Treasury can determine the current cash balances and the short-term liquidity forecast.

The following shows the process flow for Bank reconciliation of daily transactions:

Back to top

X.      The Bank prepares prior day bank statement files. This is outside of Umoja.

Y.      Bank Files Imported into Umoja system / Transaction Code: Automated

The System imports the Electronic Bank Statement via Secure Transmission through Bank Communication Manager and stores its contents in the Umoja database. Each day (on which banks operate), the prior day Bank Statements are imported to the system. Each and every transaction on the Bank Statement is validated by the system to ensure that the transactions have matching operational and/or Treasury records in the Financial Ledgers.

Z.      Automatic matching during upload of bank statements / Transaction Code: FEBAN

When an Accounts Receivable is raised, notification is sent to the debtor with details of the amount, description of the receivable. Importantly, the Document Number is generated when the AR document is raised in Umoja. The debtor is advised to include the Document Number when making a payment so that the Incoming Payment can be applied to the outstanding receivable.

The BELNR Number Interval specifies the range of the Document Numbers included in the Incoming Payments that are featured in the uploaded bank statement. If an AR document already exists in Umoja and has a Document Number that is within the range indicated in the BELNR Number Interval, a match will be established, provided that the amounts in both documents are the same. The system will automatically apply the Incoming Payment to the outstanding receivable. Items that are not automatically cleared are to be manually matched and cleared.

Automatic matching of incoming payments excludes transactions arising from Assessed Contributions. The UN has regulations and rules on how to apply the assessed contributions from the Member States. Since the FIFO method applies to assessed contributions, the UN sometimes has to override the invoice number provided by the Member States. Accordingly, assessed contributions are excluded from automatic posting rules.

Note: The accounting entry and transaction in this process is described in the incoming payments section.

The matched items are displayed on the Update Account Statement / Check Deposit Transaction screen, seen below:

AA. Manual upload of bank statements / Transaction Code: FF67

For Umoja bank accounts which do not go through the SWIFT system, manual upload of bank statements are required to facilitate bank reconciliation process.

AA.1.Enter FF67 in Command field and press Enter. A dialog box opens to enter the following relevant values:

• Internal bank determination indicator

• Import advices indicator

• Variant: UN001

• Customer match code ID: D

• Vendor match code ID: V

• Processing type: 4 Further processing online

• Transfer value date indicator

AA.2.Select Check button and enter the values in selection screen:

• Company Code: 1000

• House Bank

• Account ID

• Statement number

• Statement Date

• Opening Balance

• Closing Balance

• Posting Date

AA.3.Select Check button and enter the following values in bank statement items:

• Transaction type

• Value date

• Bank Reference

• Amount

• Document number

AA.4.Select Save button to go back to main screen.

BB.Analysis of Bank Reconciling Items / Transaction Code: FEBAN

To analyze which items cleared automatically and which did not when the bank statement was uploaded is through use of the Edit Bank Statement screen. It is accessed as follows:

BB.1.Enter FEBAN in the Command field and press Enter. This opens the Selection of Bank Statements by Banks and Account Nos. screen.

BB.2.Enter data in the following fields:

• Company Code

• House Bank

• Statement Date (As bank reconciliation is a daily process, it would beneficial to narrow down selections by date especially for banks with voluminous transactions)

BB.3.Click the Check button at the bottom right corner of the screen to verify input, then Execute if no errors -> when the Selection of Bank Statements by Banks and Account Nos is executed, the Edit Bank Statement screen is displayed.

BB.4.Note the following in the Edit Bank Statement screen.

1.            House Bank whose statement is displayed.

2.            Bank Statement Number and the amount next to it is the closing balance.

3.            Unreconciled/open Outgoing Payment. It has a status.

4.            Unreconciled Incoming Payment (cash and cheques) have a status.

5.            Reconciled/cleared item. It has a green status.

6.            Posting Areas. Clearing document numbers are displayed in the posting areas for manually reconciled items only.

CC.Review Exception Items / Manual

The Cashier reviews Exception items on the Bank Statement. If the exception item has insufficient information for the item to be applied, the Cashier needs to contact the Bank and request the Bank to investigate. Upon receiving enquires from the Cashier, the Bank investigates the exception item(s) and provides specific details for the transactions enquired so that the Cashier can review the item(s).

Back to top

3.4.1        Bank Reconciliation - Incoming Payments

The UN receives revenue either from exchange transactions or from non-exchange transactions. Ideally, receivables or recoverables need to be established prior to the receipt of any type of revenue.For revenue received through Electronic Funds Transfer (EFT), Umoja solution is configured to ensure that the incoming payment is automatically applied to the open accounts receivable/recoverable of the debtor/creditor (customer/vendor), if certain conditions are met. Bank reconciliation will not be needed in this case. In the majority cases though, the conditions for automatic clearance will not be met. In such instance, incoming payments will manually be applied to the open accounts.

Reviewing Open Customer items prior to reconciling incoming payments complements the reconciliation process. The followings are the steps to identify Open Customer items:

DD.Identifying Open Customer items / Transaction Code: ZARFBL5N

DD.1.Type ZARFBL5N in the Command field and click Enter à the Financial Accounting Accounts Receivable screen opens.

DD.2.Enter details in the following fields:

·               Customer account: Keep this field open

·               In Line Item Selection, choose Open Items.

·               Also in Line Item Selection, under Type, check all boxes as shown below to capture ALL open items (Some items may have been parked but not yet approved in which case, should be brought to the attention of the respective departments. Also, there are items that have special GL indicators such as travel and salary advance and assessed contributions from member states that may need to be reviewed for application)

·               Click the Dynamic Selections

DD.3.Click Execute to run the search à a listing of all Customer Open items is displayed.

Note: Red status indicates that the item is still open or not cleared. Use the list to identify items that are not automatically reconciled.

When an EFT Incoming Payment is received, the customer's account is not immediately credited in the GL. Instead the credit is temporarily booked to the EFT In GL account. This is one of the seven GL accounts created to record balances and reconciling items for each House Bank that UN Treasury opens.

The task of reconciling transactions with the bank, which result from the Incoming Payments received, essentially consists of moving these credits from the EFT Incoming account to the respective accounts where the funds are to be lodged. This maybe done automatically by Umoja or manually.

When the Bank Statement of the previous day transactions is uploaded into Umoja, the system will generate a ZR document with a Bank EFT-In clearing account being credited by the debit of EFTs received as follows:

·               Dr 64VQA Cash USD Nominal (GL 11011X10)

·               Cr 64VQA Cash USD EFT In (GL 11011X16)

The credit is next moved to a customer/vendor's account.

If the incoming payment contains information e.g. invoice number that identifies an existing receivable (customer) or recoverable (vendor) for the same amount, Umoja will establish a match between the two. The receivable or recoverable will be automatically cleared by the incoming payment.

·               Dr 64VQA Cash USD EFT In (GL 11011X16)

·               Cr 20OLA Customer/Vendor Open Item

At the same time the equity of the Fund for which the incoming payment was meant will increase in the Treasury Pool.

·               Dr 20OLA Equity in Pool

·               Cr 64VQA Equity in Pool

Whether a bank transaction resulting from Incoming Payments will be reconciled automatically or manually depends on what happens when bank statements are uploaded into Umoja. The following sections look into a number of cases where manual bank reconciliation for incoming payments is applied.

3.4.1.1  Case 1: Incorrect Reference on Bank Statement

The task of the bank reconciler is to move the funds from the EFT-In GL account to a Customer/ Vendor's GL account when the system fails to do so automatically.

One reason why automatic clearance will fail is when the reference on the bank statement for the Incoming Payment doesn't match an open receivable or recoverable item in the system.

To illustrate how manual clearance is done in this case, use the following data set:

·               Customer: 1111000010 -Government of Belgium

·               Outstanding Amount: USD 15,700

·               Being: Sale of Publications

·               AR Document No: 2200000485

EE.  Manual clearance of item with incorrect reference on Bank Statement / Transaction Code: FEBAN

EE.1.  Locate the bank statement on which the open item is found through FEBAN as described earlier (refer to step BB). For this example, it is Item no 11 of statement 13282 of House Bank USCH2.

EE.2.  Double-click the open item you intend to reconcile. Note that a document number appears in Posting Area 1 only. This is the reconciliation document ZR showing:

• Dr. Cash USD Nominal

• Cr. Cash USD EFT In

Back to top

EE.3.  Click the Post icon. This starts the process to move the funds from EFT In (debit) to the Customer's account (credit). At the end of the process a document number will appear in Posting Area 2.

EE.4.  In the Post with Clearing Select open Items screen that opens:

·               Enter the Customer's Account in the Account field.

·               Enter 'D' in the Account Type field.

·               Select the Amount button from Additional selections section. (Easier to select and input document number instead, if known).

EE.5.  Click on Process open items. This opens the Post with Clearing Enter selection criteria screen.

EE.6.  Enter the amount you intend to clear in the From field of the Amount (USD) section.

EE.7.  Click Process open items. This opens the Post with Clearing Process open items screen.

A list of open items with the amount specified earlier is displayed. Their total is shown in the Assigned field in the Processing Status section (bottom right).

EE.8.  De-select (by double clicking) the amounts not intended to match to the Incoming Payment until the Amount entered = Amount Assigned.

EE.9.  Click on Document in the menu bar and select Simulate. This opens the Post with Clearing Display Overview screen.

EE.10.Take note of the following:

·         Document Type is DZ, Incoming Payment.

·         The posting key (PK) for the debit entry is 40 because it is debiting a GL account, while 15 is used to credit a Customer account.

·         The sum of debits equals the sum of credits.

EE.11.Click on the Save icon to post the document. A message appears at the bottom of your screen with the posted document number.

EE.12.Return to the bank statement and double click the item you just reconciled. Note the following:

·      The status is now green.

·      A document number (DZ document) now appears in Posting Area 2.

Back to top

EE.13.Double click each of the two document numbers in turn to review the entries.

EE.13.1.Document ZR 6300000288

·         Dr. Cash USD Nominal

·         Cr. Cash USD EFT In

Note: This entry will always be generated each time an uploaded bank statement shows that the bank has credited our account for an Incoming Payment, whether we established a receivable or not.

EE.13.2.Document DZ 2400000204

·         Dr. Cash USD EFT In

·         Cr. Customer

Note the differences in posting keys (PK), Business Area and Fund, as we debited a GL account and credited an AR Subledger account. Further, P003 ensures UNIFIL's equity increases in 64VQA by amount received.

EE.14.Review EFT In GL account (11012716).

EE.15.Use T-code FAGLL03 to access the G/L Account Line Item Display G/L View screen and review EFT In GL account 11012716.

On the screen, note that though it has moved the credit that was temporarily booked there to the account of the customer who made the payment, the two entries in the EFT In account still have a red status. When they are matched against each other as part of batch clearing process (assignment field on both documents should match), the status will change to green and a document number will appear in the now empty Clrng doc. field.

3.4.1.2  Case 2: Partial Payments

The bank may correctly reference an Incoming Payment on the bank statement. However, automatic clearing may still fail because the amount on the statement is different from the amount in the customer open item. For instance, we might receive a lesser amount than expected. This could be due to exchange rate differences, bank charges or because the customer disputes parts of the invoice. Whatever the reason, when the bank statement is uploaded, the system will:

·               Dr. Cash USD Nominal

·               Cr. Cash USD EFT In

It is the duty of the bank reconciler in collaboration with the Accounts Receivable Unit to move the funds from EFT In to the customer's account. If the difference is due to bank charges or exchange rate fluctuation, a JV should be raised to clear it.

Scenario - Customer 1111000026 -Municipality of Deir Mimas, used our air asset in June 2013. They were invoiced on 08 October 2013 for the full amount of USD 4,500. The customer however contests this amount because food wasn't served on board. They only paid USD 4,000 directly into our account on 08 October 2013. The AR document number was correctly referenced in Bank Statement no 13282 of House Bank USCH2. However, when the statement was uploaded on 09 October 2013 automatic clearance failed because of differences in amount between the Incoming Payment and customer open item. The user is required to do the manual reconciliation.

FF.   Manual clearance of item with partial payment / Transaction Code: FEBAN

FF.1.   Locate the bank statement on which the open item is found through FEBAN as described earlier (refer to step BB). For this instance it is Item no 2 of statement 13282 of House Bank USCH2.

FF.2.   Double-click the open item you intend to clear. Note that the Doc. field in Posting Area 2 is empty.

FF.3.   Click on the Save icon to post (can also be done via Ctrl + S). This opens the Post with Clearing Select open Items screen.

·               Enter the Customer's Accountin the Account field.

·               Enter 'D' in the Account Type field.

·               In Additional selections section, maintain the defaulted None option. (Easier to select and input document number instead, if known).

FF.4.   Click the Process open items icon. This opens the Post with Clearing Process open items screen.

FF.5.   Since we are not clearing the full amount of an open item, click on the Partial Pmt tab.

FF.6.   Double click the amount of the item you intend to clear. This highlights the amount and also duplicates it in the Payment Amount.

FF.7.   Delete the amount in the Payment Amount field and replace it by the partial payment you intend to make.

FF.8.   Press Enter to validate. Note that the Not assigned becomes zero.

FF.9.   Click on Document on the menu bar then Simulate.

Back to top

FF.10.  When the Post with Clearing Display Overview screen opens, note that the Document Type is DZ -Incoming Payment, corresponds with the posting key for line 2 i.e. credit of a customer account for an Incoming Payment.

FF.11.  Click the Save icon to post and note the document number that is displayed at the bottom of the page when posting is done.

FF.12.  Return to FEBAN and double click on the Incoming Payment that was just applied to a Customer account. It now displays a green status.

FF.13.  Note that the document (document DZ) carrying the reconciliation entries now appears in Posting Area 2. Double click the documents in Posting Areas 1 and 2.

FF.14.  Review EFT In GL account (11012716)

Use T-code FAGLL03 to access the G/L Account Line Item Display G/L View screen and review EFT In GL account 11012716.

Even though the two entries in the EFT In account still have a red status, the status will change to green and a document number will appear in the now empty Clrng doc. field when they are matched against each other as part of batch clearing process (assignment field on both documents should match). Sometimes the automatic batch clearing process does not clear all items so the T-code F-03 can be used in this case.

FF.15.  Review Customer Open Item.

A review of the customer's account for Invoice number 2200000383 (DR doc type) shows that though a partial payment of USD 4,000 was received on 09.10.2013, the invoice is still outstanding by USD 500.

If management decides to write off the balance, a JV should be raised using T-code F-63.

3.4.1.3  Case 3: Payments from Vendors

Recoverable amounts from staff members, MILOBs, Commercial Vendors and other Business Partners who do not have customer roles in Umoja are done through credit memos established in the Accounts Payable Sub-ledger. Incoming Payments from these vendors to settle outstanding items will have to be matched and cleared manually.

Scenario - Staff member 1110001280 -Abou Saleh, owed UNIFIL USD 100.00 for private telephone calls he made while on mission there during Pilot Go-live last July. A credit memo (document type KG 3200000063) was raised to record this recoverable on 30 August 2013. The staff member transferred USD 100.00 to our House Bank USUS1. The Incoming Payment was reflected in our bank statement no 13279 of 09 October 2013. Perform the manual reconciliation.

GG.Manual clearance of item identified as payment from vendor / Transaction Code: FEBAN

GG.1.   Locate the bank statement on which the open item is found through FEBAN as described earlier (refer to step BB). For this case it is Item no 6 of statement 13279 of House Bank USUS1.

GG.2.   Double-click the open item you intend to clear. Note that the Doc. field in Posting Area 2 is empty.

GG.3.   Click on the Save icon to post (can also be done via Ctrl + S). This opens the Post with Clearing Select open items screen.

·         Enter the Vendor's Account in the Account field.

·         Enter 'K' in the Account Type field.

·         In Additional selections section click on Document Number.

Back to top

GG.4.   Click the Process open items icon. This opens the Post with Clearing Enter selection criteria screen.

GG.5.   Enter the KG document number in the From field of the Document Number section.

GG.6.   Click the Process open items icon. This opens the Post with Clearing Process open items screen.

GG.7.   Since we entered the document number of the credit memo we intend to clear only one result is returned, which matches with the amount of the Incoming Payment. Note that Not assigned is zero.

GG.8.   Click on Document on the menu bar then Simulate.

GG.9.   When the Post with Clearing Display Overview screen opens, note that the Document Type is DZ -Incoming Payment, corresponds with the posting key for line 2 i.e. credit of a vendor account for an Incoming Payment.

GG.10.  Click the Save icon to post and note the document number that displayed at the bottom of the page when posting is done.

GG.11.  Return to FEBAN and double click on the Incoming Payment that was just applied to a Customer account. It now displays a green status.

GG.12.  Note that the document (document DZ) carrying the reconciliation entries now appears in Posting Area 2. Double click the documents in Posting Areas 1 and 2.

GG.13.  Review EFT In GL account (11012916)

Use T-code FAGLL03 to access the G/L Account Line Item Display G/L View screen and review EFT In GL account 11012916. Even though the two entries in the EFT In account still have a red status, the status will change to green and a document number will appear in the now empty Clrng doc. field when they are matched against each other as part of batch clearing process. T-code F-03 can also be used to match the items immediately after reconciliation instead of waiting for the batch clearing process.

GG.14.  Review Vendor Open Item

A review of the Vendor's account for Credit Memo number 3 (KG document type) shows that the outstanding recoverable of USD 100 has been cleared by the Incoming Payment (DZ). No more bank reconciliation work is needed.

3.4.1.4  Case 4: Payments Received before Receivable is Raised.

In exceptional cases a customer may pay the UN before a receivable has been raised in the customer's account. Automatic clearance of the Incoming Payment will fail for an obvious reason. If by the time of Month End Closing the receivable is not yet raised, the Incoming Payment will be moved to GL account 39201010 - AP Unapplied Cash, where it will remain until a decision is made on what to do with it. If that decision is to move the funds to a customer's account, the T-code to use then will be F-28.

Scenario -On 24 of October an Incoming Payment of USD 1,200 was included in bank statement 1265 of House Bank USCH1. By the 30 of October when the Month End Closing was done, it was still not possible to move the funds to a Customer or Vendor account because the receivable or recoverable could not be established. It was decided to move the funds to AP Unapplied Cash until the receivable or recoverable is set up.

Back to top

HH.Manual clearance of payment item not yet raised in receivable / Transaction Code: FEBAN

HH.1.   Locate the bank statement on which the open item is found through FEBAN as described earlier (refer to step BB). In this case, Item no 7 of statement 1265 of House Bank USCH1.

HH.2.   Double-click the open item you intend to clear. Note that the Doc. field in Posting Area 2 is empty.

HH.3.   Click on the Save icon to post (can also be done via Ctrl + S). This opens the Post with Clearing Select open items screen.

HH.4.   Click on the Back icon.

HH.5.   When the Post with Clearing Display Overview screen opens, note that the Document Type is DZ. Also note that Line 1, the debit line is automatically generated by the system. We now have to enter Line 2.

HH.6.   Enter 50 in the PstKy field and 39201010 in the Account field.

HH.7.   Click Enter. This opens the Post with Clearing Add G/L account item screen.

·         Enter the amount in the Amount field.

·         Enter a descriptive test in the Text field.

·         Click on More data to open the Coding Block screen.

HH.8.   Enter Business Area, Fund, Budget Period (BP) and Grant.

HH.9.   Click on Enter. This opens the Post with Clearing Correct G/L account item screen.

HH.10.  Click on Document in the menu bar and select Simulate. This opens the Post with Clearing Display Overview screen.

HH.11.  Review the two lines, especially the posting keys andBusiness Areas.

HH.12.  Click on Save to post the DZ document and note the number that displays at the bottom of the screen.

HH.13.  Return to FEBAN and double click on the Incoming Payment that was just applied to the Unapplied Cash account. It now displays a green status.

Back to top

HH.14.  Note that the document (DZ) carrying the reconciliation entries now appears in Posting Area 2. Double click the documents in Posting Areas 1 and 2.

II.      Perform manual incoming payment against Customer for clearing of the Unapplied Cash account / Transaction Code: F-28

Subsequently, the incoming payment must be cleared against BP account with customer role. For detailed process steps on transaction code F-28, please refer to section 3.2.2 of Finance Manual Chapter on Accounts Receivables specific to Incoming Payments.

* The specific BP account number selected in data entry view determines the AR reconciliation account that will be pulled in accounting entry. In this proforma entry, BP account range 15 will call BP account group Z015 which is NGOs and Intergovernmental and derive GL account 15101410 Non-Governmental Organizations & Intergovernmental.

**In the above accounting entry, the transaction crosses two different business areas and funds, thus additional line items for GL account 11701010 Cash Held in UNHQ Main Pool are automatically created to balance the transactions per business area and per fund level.

3.4.1.5  Case 5: Rejected Outgoing Payment

In some cases, outgoing payments are rejected by the bank and are therefore credited to the UN bank account in a similar manner to incoming payments. In this instance, the Bank reconciler would require to transfer the amount to a clearing account 11479997 and account payable processors would then re-issue the payment.

Scenario - On 30 August 2013, an incoming payment USD 74.446,42 was included in bank statement 13243 of House Bank USCH1. After communication with Treasury department, Bank reconciler found out that the amount had been returned by the bank, being payment rejected by the bank.

JJ.     Manual clearance of item identified as rejected outgoing payment / Transaction Code: FEBAN

JJ.1.     Locate the bank statement on which the open item is found through FEBAN as described earlier (refer to step BB). For this example, it is Item no 2 of statement 13243 of House Bank USCH1.

JJ.2.     Double-click the open item you intend to clear. Note that the Doc. field in Posting Area 2 is empty.

JJ.3.     Click on the Save icon to post (can also be done via Ctrl + S). This opens the Post with Clearing Select open Items screen. Prior to this step, from the Note To Payee field write down the reference to the original payment document (KZ or PY). If it's missing, Treasury does the additional research and provides this information to a bank reconciler.

JJ.4.     Click on the Back icon.

JJ.5.     When the Post with Clearing Display Overview screen opens, note that the Doc. Type is DZ. Also note that Line 1, the debit line is automatically generated by the system. We now have to enter Line 2.

JJ.6.     Enter 50 in the PstKy field and GL account 11479997 (Payment Rejected by Bank) in the Account field.

JJ.7.     Click Enter. This opens the Post with Clearing Add G/L account item screen.

·               Enter the amount of the original KZ or PY document in the Amount field.

·               Enter a descriptive test in the Text field. The Text field should be uniform across all entries to the GL 11479997. EXAMPLE: REJ KZ 3302211990 BP 2000450085 USCH1. This allows easy search for the re-issue by AP processors. Click on More data to open the Coding Block screen. Enter Business Area, Fund and Grant of the original invoice and click Enter.

·               Bank charges or Foreign Exchange difference (if any) are both booked to the GL 74251010

JJ.8.     Click on Overview

Back to top

3.4.1.6  Case 6: Payments Received in Error

Exceptionally, payments may be made to the UN in error. Prior to closing the month the money should be moved from EFT In to another GL account 39201010 -Unapplied Cash, where it will remain until a decision is made on what to do with it. The steps to move the funds from EFT In to Unapplied Cash are the same as those described in Case 4.

3.4.2        Bank Reconciliation - Outgoing Payments

An outgoing payment is the amount of money or its equivalent issued by the UN entity to pay for goods or services. The payment is normally created in the accounts payable/vendor account or its equivalent by an AP User role.

At the time an accounts payable is established through either T-code MIR7 or FV60, a vendor's invoice (KR document type, NOTE: replace with various types of AP documents, such as RE, KA, KH, TA, TI, etc.) is created with these entries:

·               Dr. GR-IR or Expense account

·               Cr. Vendor

When the cashier generates payment through T-codes F110 and FPRL_LIST, creating an Outgoing Payment document type KZ, the nominal bank account or cash is not immediately credited in the general ledger. Instead, the credit is temporarily booked to one of the two bank clearing accounts for outgoing payments.

·               Dr. Vendor

·               Cr. Cash EFT Out or Cheque Out

The Outgoing Payment (KZ) is then matched to an open payable item (KR) which clears the vendor's account for that item. For instance Outgoing Payment 3300000272 is created to settle vendor's invoice 3100000288. The status of the AP document turns from red to green with a zero balance displayed for the item as shown below.

The task of reconciling transactions with the bank, which result from the Outgoing Payments (KZ) that we created, is essentially the processing of the credits that are temporarily booked to one of the clearing accounts (Cash Cheque Out or Cash EFT Out ) when the cashier generates payments. While some of the transactions will reconcile automatically, others will have to be cleared manually.

When the Bank Statement of the previous day transactions is uploaded into Umoja, for each Outgoing Payment listed in an uploaded bank statement, the system will automatically generate a ZR document with the following entries in the GL:

·               Dr. 64VQA Cash USD EFT Out (or Cheque Out)

·               Cr. 64VQA Cash USD Nominal

This reflects the fact that the bank has debited the account for the disbursement they made on our behalf. Umoja thus reduces the balance of the Bank Nominal in the GL to synchronize it with the balance held by the bank. In principle, as far as Outgoing Payments are concerned, the GL Bank Nominal account will only be credited when the bank has effectively paid out money as instructed by the UN. Any Outgoing Payments generated by us but for which the bank has not yet made disbursements will appear in the GL Cash EFT Out (or Cheque Out) as KZ or PY documents and not in the GL Bank Nominal.

Umoja will attempt to establish a link between the credit in the KZ document and the debit in the ZR document. Two possible outcomes exist:

1              If both entries relate to the same transaction, Umoja will establish a match and use the ZR document to clear the KZ document. In this case no more bank reconciliation work is needed for this Outgoing Payment.

2              If a link cannot be established, automatic clearance will fail. The ZR document will have to be manually applied to the KZ document.

The match between the KZ and ZR documents is established by two elements:

1              KZ document number (referenced in the Assignment field that should match with the ZR assignment field) - This is the Payment doc.no. generated by the system after the Cashier has successfully executed the process steps using T-codes F110 and FPRL_List (Assign, Approve and Pay). This number is included in the instructions that go to the bank. In return, the bank is required to reference the number in their bank statement against the corresponding disbursements made.

2              Amount - A match will not be established if there is a discrepancy between the amounts in both documents, whatever the magnitude of the difference.

Example - Automatic Clearance

A payable of USD 1,400 was established for Vendor 2080001758 through KR 3100000288. The cashier generated payment (KZ 3300000272) via House Bank JPM Chase US with credit to clearing account 11011014 CshHQ USD EFT AP. The bank paid out the money and debited our account in their books by USD 1,400, as well as included the ref.3300000272 in bank statement no 13283.

KK.  To access a given bank statement / Transaction Code: FEBAN

KK.1.  Enter FEBAN in the Command field and click the Enter icon. This opens the Selection of Bank Statements by Banks and Account Nos. screen.

KK.2.  Enter data in the following fields:

·         Company Code

·         House Bank

·         Statement number or Statement Date

·         Currency

KK.3.  Click on the Execute button to run the search

Back to top

KK.4.  The Edit Bank Statement screen displays. Note the following:

·               The statement no. is 13283, for House Bank USCH1, currency USD, closing balance USD 3,100.

·               The transaction uploaded has reduced our bank nominal balance -it is an Outgoing Payment (negative sign).

·               Also the status of the transaction is green, meaning that the debit of the ZR document (6300000416) created by Umoja when the statement was uploaded automatically cleared with the credit of the existing KZ document (3300000272).

KK.5.  Double click the ZR document number located in the Posting Area 1 to see its accounting entries.

KK.6.  Note that PmtAcc field is empty.

KK.7.  Review ZR document

As expected, the ZR document debits EFT AP and credits Bank Nominal. Both accounts are in the GL, hence the 50 and 40 posting keys used respectively. Note that the Reference generated by the system is a combination of the House bank, currency and bank statement number. Also note that as both accounts belong to the Treasury Main Pool they have the same Fund (64VQA) and Business Area (S101). This information will be helpful when we manually apply the ZR to a KZ document.

LL.   Review EFT AP account / Transaction Code: FAGLL03

Next, review the EFT AP account 11011014 to confirm that the existing credit entry from the KZ document has indeed been cleared by the debit entry from the ZR doc.

LL.1.   Type FAGLL03 at the Command field and click Enter. The G/L Account Line Item Display G/L View screen displays.

LL.2.   Enter 11011014 in the G/L account field.

LL.3.   Select Cleared Items in Line Item Selection section.

LL.4.   Enter the date the item was cleared in the Clearing Date field.

LL.5.   Click Execute to run the search. The results are shown in another G/L Account Line Item Display G/L View screen, which opens.

Note that effectively, the credit of the KZ document has been cleared by the debit of the ZR document. This is attested by the green status that both lines now have. The clearing document number is 6300000416, which is nothing other than the ZR document number.

Automatic reconciliation of Outgoing Payments must satisfy all of the following three criteria:

1.      Transactions must be on the same GL

2.      The assignment fields must be identical

3.      The payment amounts must be identical

Factors contributing to the failure of automatic reconciliation are:

The cashier may have generated an outgoing payment (i.e. a KZ doc exists) but the bank incorrectly quoted either the KZ doc number (assignment) or the amount of the Outgoing Payment on the bank statement. As a result, when the statement is uploaded, Umoja will be unable to establish a match between the KZ and ZR documents, thereby failing to automatically clear the related transactions. The bank has debited our account but no Outgoing Payment exists because our cashier has not generated a payment nor sent instructions to the bank to disburse funds on our behalf. This could be due to a number of reasons, such as:

·               The bank debited our account in error.

·               Bank charges and other fees that the bank directly imputes to us but for which we do not need to raise a payable and generate an Outgoing Payment.

·               The disbursement by the bank is legitimate but it was made before we had raised the payable, and the cashier generated an Outgoing Payment

NOTE: There are three terms that have to be met in order for the items to autoreconcile: they have to be on the same GL, have matching assignment field and have the matching amounts. Probably the above has to be replaced with those three bullet points.

The following sections illustrate a series of cases where manual bank reconciliation for incoming payments are necessary.

3.4.2.1  Case 1: Incorrect Reference on Bank Statement

The cashier generated Outgoing Payment (KZ) ref. 3300000267 for the amount of USD 500 via House Bank JPM Chase. However, the bank incorrectly quoted the KZ ref. number on the bank statement. As expected, automatic clearance failed when the statement was uploaded because all the three criteria were not met. We will then have to manually reconcile the transactions.

Back to top

MM.  A Manual clearance of item with incorrect reference on Bank Statement / Transaction Code: FEBAN

MM.1.  Locate the bank statement on which the open item is found through FEBAN (refer to step BB). In this case, it is statement 23 of House Bank USCH1.

MM.2.  Double click the item. This brings up the ZR document number but this time it appears in the PmtAcc field of Posting Area 1. When manual clearance is completed another ZR document will be generated in the now empty Doc. field.

MM.3.  Double click the PmtAcc document number. It will show the debit to Cash EFT AP and credit to Bank Nominal.

MM.4.  Click Statement Items and click Post.

MM.5.  In the Post with Clearing Process open items screen that opens, note that all open items are displayed and selected by default. We are only interested in matching the remaining debit line of ZR 6300000420 to the open credit line of KZ 3300000267.

MM.6.  Double click any other amount we are not interested in to deselects those amounts.

MM.7.  When only the lines of interest to us remain selected the Amount entered and Assigned fields in the totals section below will be both zero. This means that the sum of debits equals the sum of credits.

MM.8.  Click on Document in the menu bar and select Simulate. -> the Post with Clearing Display Overview screen opens. Note the following:

·               The document type is ZR. This will be the second ZR document. The first (6300000420) was created by the system with credit to Bank Nominal and debit to EFT AP.

·               Both the Reference and Doc. Header Text are system generated with the former being a combination of House Bank, Currency of account and bank statement number.

·               Both lines relate to the same GL account, Cash EFT AP, the debit being the second debit line of ZR 6300000420 and the credit being the credit line of KZ 3300000267.

·               The sum of debits is equal to the sum of credits.

MM.9.  Click on the Save icon to post the document.

MM.10.A message with a green status appears at the bottom of the screen informing that the document has been posted. Note the document number.

MM.11.Return to FEBAN and double click the item just reconciled. Note the following:

·                  The status has changed from to green.

·                  In Posting Area 1 there is a second ZR document (6300000421) shown in the Doc. field. This is the reconciling document.

MM.12. Double click on both ZR 6300000420 and 6300000421 to review their entries.

MM.12.1.    Document ZR 6300000420

·               Dr. Csh HQ USD EFT AP

·               Cr. Csh HQ USD Nominal

As mentioned earlier, these entries will always be generated each time an uploaded bank statement shows that the bank has debited our account, whether we generated an Outgoing Payment or not.

Back to top

MM.12.2.    Document ZR 6300000421

·               Dr. Csh HQ USD EFT AP this is clearing for ZR 6300000420

·               Cr. Ch HQ USD EFT AP this is clearing for KZ 3300000267

Both the debit and credit were in the same account but not matched to each other. By manually reconciling, we are pairing the two entries.

MM.13.Review Csh HQ USD EFT AP (EFT Out) account using T-code FAGLL03 (refer to step LL).

Note the two ZR documents (6300000420 and 6300000421). The debit of the first ZR document (6300000420) and credit of KZ document (3300000267) were cleared by the second ZR document (6300000421).

3.4.2.2  Case 2: Bank debits UN accounting error

A more serious case is when the bank debits UN account but the UN cashier has not created, and do not intend to create an Outgoing Payment. Suppose the amount is USD 3,500, on bank statement 24. Once again, when the bank statement is uploaded automatic clearance fails as expected.

A ZR document is created with a credit to Bank Nominal (Csh HQ USD Nominal) and a debit line to Csh HQ USDEFT AP. Manual reconciliation in this case requires transferring this debit from the Csh HQ USD EFT AP account to Csh HQ USD Uniduntil the bank clarifies the transaction.

NN.   Manual clearance of item identified as error payment made by the bank / Transaction Code: FEBAN

NN.1.   Locate the bank statement on which the open item is found through FEBAN (refer to step BB). In this case, it is statement 24 of House Bank USCH1.

NN.2.   Double click the item. This brings up the ZR document number but this time it appears in the PmtAcc field of Posting Area 1. When manual clearance is completed another ZR document will be generated in the now empty Doc. field.

NN.3.   Double click the PmtAcc document number. It will show the debit to Csh HQ USD EFT AP and credit to Csh HQ USD Nominal.

NN.4.   Click Statement Items and click Post.

NN.5.   In the Post with Clearing Process open items screen, note that all open items are displayed and selected by default.

NN.6.   Click the Back button. This brings you to the Post with Clearing Display Overview screen where you will manually create the debit line for the Bank Unidentified account associated with the House Bank JM Chase. The system will then automatically post a credit to the Csh HQ USD AP line once you post the transaction.

NN.7.   Enter the line. This will be a debit to the Csh HQ USD AP a/c. Enter posting key 40 in the PstKy field. This is the key used when debiting a GL account.

NN.8.   In the Account field, enter the Csh HQ USD Unid number i.e. 11011019.

NN.9.   Click on the Enter icon, which opens the Post with Clearing Add G/L account item screen where additional data for the debit line will be entered.

·                  Enter the amount to be cleared in the Amount field.

·                  Enter a descriptive text in the Text field.

·                  Click on More data for additional data fields à the Coding Block screen opens.

NN.10.  In the Coding Block pop up window, enter the following:

·               Business Area: Since Csh HQ USD AP account is an account of the Treasury Main Pool, enter S101.

·               Fund: Because we are entering data for an account of the Treasury Main Pool, enter 64VQA.

·               Grant: GMNR

NN.11.  Click on the Enter icon. This opens the Post with Clearing Add G/L account item screen.

NN.12.  Click Enter to return to the Post with Clearing Add G/L account item screen.

NN.13.  Click Document in the menu bar and select Simulate.

Back to top

NN.14.  In the Post with Clearing Display Overview screen that opens, note the following:

·               The document type is ZR. This is the second ZR document. The first (6300000422) was created by the system with credit to Bank Nominal and debit to EFT AP.

·               Both the Reference and Doc. Header Text are system generated with the former being a combination of House Bank, Currency of account and bank statement number.

·               The credit of the Cash EFT AP clears the un-reconciled debit in the same account generated by ZR 6300000422. Cash Unidentified is now debited.

·               The sum of debits is equal to the sum of credits.

NN.15.  Click on the Save icon to post the document.

NN.16.  A message with a green status appears at the bottom of the screen informing that the document has been posted. Notethe document number.

NN.17.  Return to FEBAN and double click the item just reconciled. Note the following:

·               The status has changed from to green.

·               In Posting Area 1 there is a second ZR document (6300000423) shown in the Doc. field. This is the reconciling document.

NN.18.  Double click on both ZR 6300000422 and 6300000423 to review their entries.

NN.18.1.  Document ZR 6300000422

·               Dr. Csh HQ USD EFT AP

·               Cr. Csh HQ USD Nominal

As mentioned earlier, these entries will always be generated each time an uploaded bank statement shows that the bank has debited our account, whether we generated an Outgoing Payment or not.

NN.18.2.  Document ZR 6300000423

·               Dr. Csh USD Unident

·               Cr. Csh HQ USD EFT AP

The debit in ZR 6300000422 has now been transferred to Cash Unidentified temporarily pending clarification from the bank.

NN.19.  Review EFT AP account using T-code FAGLL03 (refer to step LL).

Note that even though the debit that was temporarily booked has been moved to the Cash Unidentified account, the two entries in the EFT AP account still have a red status. When the documents are matched against each other as part of batch clearing process (T-code F.13), the status will turn to green and a document number will appear in the Clrng Doc. Field.

3.4.2.3  Case 3: Bank Charges

At times the bank may correctly debit our account for fees which do not require us to raise payables and generate Outgoing Payments. This will be the case with bank charges and other commissions that the bank directly imputes to our account.

As before, at the time the bank statement is uploaded, Umoja creates a ZR document with the below entries:

·               Dr. Csh XX USD EFT AP (or Cheque Out)/Csh HQ USD XX Charge

·               Cr. Csh XX USD Nominal

Since a payable will not be established and an Outgoing Payment (KZ) generated, manual bank reconciliation is required. This will be similar to the above process concerning the unidentified deposit, but in this instance the debit will be to an expense account (usually GL 74251010 for bank fees}. Please note that bank debits under GL XXXXXXXX18 cannot be cleared through FEBAN; rather they have to be cleared using T-code F-03.

OO.  Analysis of Bank Reconciliation items (Outgoing Payment) / Transaction Code: FEBAN

OO.1.  Enter FEBAN in the Command field and click the Enter icon. This opens the Selection of Bank Statements by Banks and Account Nos. screen.

OO.2.  Enter data in the following fields:

·                  Company Code

·                  House Bank

·                  Statement number (bank statement number)

·                  Currency

OO.3.  Click on the Execute button to run the search.

OO.4.  The Edit Bank Statement screen displays. Note the following:

·                  The statement no. is 13283, for House Bank USCH1, currency USD, closing bal. USD 3,100.

·                  The transaction uploaded has reduced our bank nominal balance -it is an Outgoing Payment (negative sign).

·                  Also the status of the transaction is green, meaning that the debit of the ZR document (6300000416) created by Umoja when the statement was uploaded automatically cleared with the credit of the existing KZ document (3300000272).

·                  PmtAcc field is empty.

Back to top

OO.5.  Double click the ZR document number to see its accounting entries.

OO.6.  Review ZR document.

·                  The ZR document debits EFT AP and credits Bank Nominal. Both accounts are in the GL, hence the 50 and 40 posting keys used respectively.

·                  The Reference generated by the system is a combination of the House bank, currency and bank statement number.

·                  As both accounts belong to the Treasury Main Pool they have the same Fund (64VQA) and Business Area (S101). This information will be helpful when we manually apply the ZR to a KZ document.

3.4.3        Bank Reconciliation - Bank to Bank Transfers

This section outlines the steps to reconcile transfers between UN bank accounts.

3.4.3.1  Transfer to a Zero-Balance Account

The UN may find necessary to maintain a zero-balance accounts for operational convenience. Transfer to zero-balance account is done automatically by the source bank.

PP.     Bank reconciliation in the Recipient bank / Transaction Code: FEBAN

PP.1.  Locate the bank statement on which the incoming transfer is found through FEBAN (refer to step BB). In this example, the source bank is LBCI2.

PP.2.  Double click in the line to see the details of the transaction.

PP.3.  To see the posting of the bank statement (ZR document), double click in the document number (6300021740) of the Posting Area 1. The expected posting for the receiving bank is a debit to the Nominal and a credit to EFT-In.

PP.4.  To clear the incoming transfer, go back to the Edit Bank Statement screen and double click the line identified in step PP.2.

PP.5.  Click the Post icon or select from the main menu Statement Itemsà Post.

Note: As FEBAN would be clearing the credit in the EFT-In, the system will automatically debit that account. Therefore, the action to be taken through FEBAN would be to post a credit (posting key=50) to the EFT-AP GL of the Source bank account. Please note that posting to the nominal bank account is only through the upload of bank statements and never through FEBAN.

PP.6.  Enter the EFT-AP GL account of the Source bank in the Account field and change the Account Type to S.

PP.7.  Click Process open items. This opens the Post with Clearing Process open items screen.

PP.8.  Select the document related to the outgoing transfer; in this example 6300021748 (selected line would be light blue the others, if any, are black).

PP.9.  Select Document from the menu bar and click on Simulate to see the postings in the Posting with Clearing Display Overview screen.

PP.10.And finally select the Save icon to post the document. A message appears at the bottom of the screen with the posted document number.

PP.11.Clearing document 2400000311 is posted and the line is cleared (green).

QQ.  Bank reconciliation in the Source bank / Transaction Code: FEBAN

QQ.1.  Locate the bank statement on which the incoming transfer is found through FEBAN (refer to step BB). In this example, the source bank is USCI1

QQ.2.  Double click in the line to see the details of the transaction

QQ.3.  To see the posting of the bank statement (ZR document), double click in the document number (6300021748) of the Posting Area 1. The expected posting for the source bank is a credit to the Nominal account and a debit to EFT-AP.

QQ.4.  To clear the outgoing transfer, go back to the Edit Bank Statement screen and double click the line already identified in step QQ.2.

Back to top

QQ.5.  Click the Post icon or select from the main menu Statement Items/Post. The system finds that there is a credit (created by FEBAN in the prior step) and reconciles it with the debit of the bank statement (clearing document 6300024968 is posted).

QQ.6.  Using FAGLL03 you may verify that the assignment of the debit and the credit is the same for the EFT-In (11##XX16) account. Those entries will be cleared with the automatic batch or manually using F-03.

QQ.7.  For the EFT-AP (11##XX14), in which the system automatically reconciled the debit and the credit with clearing document 6300024968, both lines are already cleared.

3.4.3.2  Transfer to a Non Zero-Balance Account

This section looks into reconciliation of transfers from an Umoja Source bank account to an Umoja Recipient bank account. Specific focus is on transfer from a USD bank account to a foreign currency bank account.

Scenario - Transfer from a USD bank account (House Bank USCH1) to a GBP bank account (House Bank GBCH1) for the amount of USD 100,000. The transfer has been approved and posted with document numbers 1700020886 and 1700020885 (document type: ZT).

Note that the credit in the Source bank (USD) and the debit in the Receiving bank are in GL 11xxxx17. Likewise, the gain/loss in exchange rate is the difference between the debit and the credit in GL 79611010 (USD 97,546.98 - 100,000). Consequently, there will be no need to post any exchange rate difference with FEBAN.

In case the transfer is from a USD bank account to another USD bank account, there will be only one ZT document (debit and credit to 11xxxx17) and there will be no postings to GL 79611010 (FX Purch Sale Curren).

RR.Bank reconciliation in the Source bank / Transaction Code: FEBAN

RR.1.Locate the bank statement on which the open item is found through FEBAN (refer to step BB). For this instance it is Item no 1 of statement 96 of House Bank USCH1.

RR.2.Double click the open item you intend to clear. The ZR document (6300002667) appears in the PmtAcc field of Posting Area 1.

RR.3.Double click the document in PmtAcc to see the posting created.

RR.4.The bank statement (Source bank) posts a credit to the nominal bank account. The debit could be in GL 11xxxx17 or 11xxxx14 (EFT-AP)

RR.5.To clear the outgoing transfer, go back to the Edit Bank Statement screen and double click the line identified in step SS.2.

RR.6.Click on the Post icon or select from the main menu Statement items à Post.

RR.7.In the Post with Clearing Process open items screen, select only documents 1700020886 and 6300002667. Selected lines would be light blue while the others are black and click the Post icon.

RR.8.Click on the Save icon to post document.

Back to top

RR.9.Return to FEBAN and double click the item just reconciled. Note that a clearing document 6300025876 has been posted and the line is now cleared (green).

RR.10.In instances where the bank statement of the Source bank debits GL 11xxxx14 (EFT-AP) while the credit of the ZT document is in GL 11xxxx17, as the Post with Clearing Process open items screen opens after document ZR 6300002667 was selected select Edit à Select more from the main menu.

RR.11.Enter the Investment GL account of the Source bank in the Account field and click Process open items.

RR.12.Select the related ZT document; in this example 1700020886 (selected line would be light blue the others, if any, are black).

RR.13.Select Document à Simulate from the main menu to review the posting.

RR.14.Click the Post icon.

SS.   Bank reconciliation in the Recipient bank / Transaction Code: FEBAN

SS.1.   Locate the bank statement on which the open item is found through FEBAN (refer to step BB). For this instance it is Item no 1 of statement 108 of House Bank GBCH1.

SS.2.   Double click the open item to be cleared. The ZR document (6300002628) appears in the Doc. field of Posting Area 1.

SS.3.   To see the posting, double click the document number

SS.4.   In this case, the Receiving bank has a debit (ZT doc 1700020885) in GL 11011317 and a credit (ZR doc 6300002628) in GL 11011316. Both lines need to be cleared through FEBAN using a similar procedure as described in step RR.10 above.

SS.5.   To clear the incoming transfer, go back to the Edit Bank Statement screen and double click the line identified in step SS.2.

SS.6.   Once the Post icon is selected, select Edit à Select more from the menu in the Post with Clearing Process open items screen.

SS.7.   Enter the Investment GL account of the Receiving bank in the Account field and click Process open items.

SS.8.   Select the related ZT document; in this example 1700020885 (selected line would be light blue the others, if any, are black).

SS.9.   Select Document à Simulate from the main menu to review the posting.

SS.10.  To post, select the Post icon.

3.4.3.3  Posting ZR Document Not Appearing in FEBAN.

There might be instances in which the ZR document has not been posted even though the line appears in FEBAN.

TT.     Steps to post ZR document not appearing in bank statement / Transaction Code: FEBAN

TT.1.     Locate the line item in the bank statement through FEBAN.

TT.2.     To post the ZR document, select the Post icon or from the menu select Statement Item à Post.

TT.3.     Double click in the line again and FEBAN will show the just posted ZR document.

Back to top

3.4.3.4  Print List of Transfers.

When UNHQ approves a transfer to a mission bank account, a posting is automatically recorded with document type ZT:

• Cr Source Bank Invt FX (GL 11xxxx17)

• Dr Receiving Bank Invt FX (GL 11xxxx17)

To review the list of transfers, use report FAGLL03 with the Variant 'Remittance'.

UU.Generate list of transfers / Transaction Code: FAGLL03

UU.1.   Execute T-code FAGLL03 to access the G/L Account Line Item Display G/L View screen and select Goto à Variants à Get from the menu.

UU.2.   In the Find Variant pop up window ensure the Created By field is empty i.e. remove your name if it appears in this box.

UU.3.   Click on the Execute button.

UU.4.   Select Remittances.

UU.5.   Note that there is one dynamic selection for that variant. Select All Items to see open and cleared remittances i.e. all remittances.

UU.6.   Click the Execute button.

3.4.4        Bank Reconciliation - Payroll Related Entries.

VV.Steps to run bank reconciliation for payroll entries / Transaction Code: FAGLL03

VV.1.Run T-code FAGLL03 for a bank GL ending in 14 - EFT Outgoing payments, select all open items as at end of the month date, i.e. 30.11.2016.

Back to top

VV.2.PY type of document represents the payment document generated by the payment run performed by Treasury. It is similar to the KZ type, except it posts only for payroll payments to staff members.

VV.3.In order to auto-reconcile, the PY document amount should match the ZR (bank movement) amount. The example of auto-reconciliation is as follows:

In this example, the ZR amount equals the sum of PY postings on the same bank GL, which is a basis for the items to auto-reconcile. When items auto-reconcile, the assignment field of the bank movement posting ZR always reflect its own document number.

Most of the payroll related payments posted on the bank auto-reconcile. They do not appear on the open items reports for Umoja banks and do not require a separate review, however there are two scenarios in which they do not auto-reconcile, as outlined below:

Scenario 1.

There is a difference between local currency (USD) amounts in ZR and PY documents. The document currency is any currency other than USD. To reconcile post the difference (loss or gain) to the GL 79601010 - Foreign Exchange the coding block for this GL is S101-99901-64VQA-GMNR.

The screenshot above represents two entries, PY and ZR documents, where the PY has been posted in currency other than USD, however the money were paid in USD. The difference between debit and credit ZR and PY entries was posted as a loss on Foreign Exchange.

Scenario 2.

ZR and PY documents have the same local/document currency, however they don't clear each other (do not add up to a zero). The reason being payroll payment entries for the same BP posted in several bank accounts within the same month. Since the Umoja bank and book postings were designed to match by the assignment field (BP number reference), we can run the postings for the same assignment across the entire number of Umoja banks and see, whether all PY and ZR documents for the same assignment (one BP) sum up to a zero.

In order to do this, we have created a variance that includes all GL accounts of all Umoja banks, so a bank reconciler doesn't have to manually enter the GLs each time the transaction is run. The entry to run all banks for one BP is FAGLL03, this time around selecting the previously mentioned saved variance:

VV.4.After selecting the variant, using the Dynamic Selection, select the Assignment field and insert the BP reference number of the ZR and PY entries that need to be reconciled.

VV.5.Run Open items for the selected Assignment across the entire GL accounts of all Umoja banks.

The results of the transaction are as follows:

In this case, the summary of postings on different banks equal zero, so the open items can be cleared manually using the T-code F-03 in the same posting period as PY and ZR.

In the case below the total of all PY and ZR postings did not amount to zero, which means we cannot reconcile the entries for this particular Assignment (BP). Note different GLs in Account field, representing different bank accounts that have postings related to one BP.

In cases when the result of the transaction doesn't equal zero, the first step is to notify Payroll counterparts and request that posting is manually adjusted. The analysis of payroll related postings is done in the HCM module of Umoja (Human Capital Management), to which bank reconcilers do not have access.

If payroll colleagues do not respond (typically within one month) and do not make manual adjustment to the entries, leaving the bank GL with several open items, a bank reconciler clears the open items to the GL 39101180 - CL Liability Transfer HCM Payroll. After doing so, a bank reconciler makes a list of all open items cleared to the GL 39101180 and notifies payroll colleagues for their information and further action. At this point, work of a bank reconciler is complete.

3.5            Master Data Maintenance

Master Data enables all UN data across specific functional areas to be housed in one place and to be accessed from anywhere in the world. Each process area utilizes a different combination of Master Data elements.

The Cash Management and Treasury process uses the following Master Data elements to execute transactions and maintain source data:

Back to top

3.5.1        Master Data Maintenance - Payee Bank

The Payee means an entity or person to whom payments will be made and includes the following categories:

In Umoja, a Payee is referred to as a Vendor, irrespective of the type of payee. The UN Treasury is responsible for creating and updating the Payee Bank information portion of the Master Record for all payees. There are three high level steps:

1.                  The Payee needs to be created in Umoja. The Payee record should have pertinent information such as the names, addresses, contact person names, and telephone numbers. Commercial Vendors will be created and maintained by the Supply Chain Master Data Team. Employees will be created and maintained by the HR Master Data Team. Member States, UN Agencies, NGOs and other Implementing Partners will be created by the Finance (Accounts Division) Master Data Team.

2.                  The bank where the payee maintains its account needs to be identified. This step is accomplished by selecting the appropriate bank from the Bank Reference List. The UN Treasury Master Data Team or specifically designated Administrative Office will input the information in Umoja. As explained in the FI_001_001_002_F Master Data Maintenance - Bank Reference List, the Bank Master records are updated by a third party service provided and subject to monitoring by the Treasury Master Data Team. The Bank Master records include information such as the full bank name, bank address, and bank routing information (ABA, SWIFT).

3.                  The bank account details need to be entered in the Payee Bank Master record. The bank account details include the account number, account type (savings or checking), the currency of the bank account, and the currency of the payment. The Payment Method (Fedwire vs. ACH, or Urgent Payment System vs. Non-Urgent Payment System such as SEPA) is also identified here. If a payee needs to be paid through the UN Agency, rather than through the banking systems, such payment method is identified here. The UN Treasury Master Data Team and the designated Administrative Office will be responsible for the completeness of bank account details and will selectively review data entered.

The followings are steps to maintain Payee bank Master Data:

WW.  Receive payee bank info and check if bank record currently exists in Umoja

The Payee Bank Processor 1 receives the payee bank account information from the payee, reviews the information received, and checks if the respective bank record currently exists in Umoja.

XX.     Check if the bank record exists

If the respective bank record exists in Umoja, the Payee Bank Processor 1 continues creating a payee bank record in Umoja. If the respective bank record does not exists in Umoja, then sends a request to Treasury Master Data Team to create a bank record. This process is explained in FI_001_001_002_F Master Data Maintenance - Bank Reference List. When the new bank record is created, the Payee Bank Processor will continue the process of creating a payee bank record.

YY.     Enter bank account information in Umoja and attach supporting documentation

YY.1.  For updating bank details of existing Payee: The Payee Bank Processor 1 enters the details of the bank account of the payee. When the payee bank account record is created, the Payee Bank Processor 1 attaches supporting documentation (e.g. digitized copy of the bank account form received from the payee) to the newly created payee bank record.

YY.2.  To create new Payee bank records:

YY.2.1.  The Payee Bank Processor receives payee bank account information from the payees in a secure manner, creates/updates payee bank records in Umoja and uploads a copy of the supporting document to Umoja for future reference and audit trail.

YY.2.2.  The Payee Bank Processor links the Payee Bank record to the respective bank record in Umoja. The bank records in Umoja are maintained by uploading the bank directory file received from the Third Party Service Provider, such as Accuity, SWIFT, or Bankers Almanac. The appropriate bank record should be selected using the bank key such as BIC/SWIFT code or ABA Routing Number. In rare cases when it is found that there is no bank record in Umoja to be linked to the given payee bank information, the Treasury Bank Master Team will be requested to create a new bank record manually in Umoja.

YY.2.3.  Umoja automatically validates the information entered when the payee bank record is saved, i.e. the system will perform the edit checks. The information subject to validation includes the IBAN, or the length of the account numbers (13 digits) of UNFCU accounts. If the edit check indicates a data error, e.g. if the number of digits in the bank account number isn't consistent with the required number of digits for a bank account in that particular country, the user receives an error message in real-time indicating which field has inconsistent data.

YY.2.4.  The Payee Bank Processor uploads to Umoja the payee bank account information received, in digitized form.

ZZ.     Edit and validation

Umoja system performs several validation routines or edits checks before the banking information records entered is saved.

ZZ.1.  Is the payee bank record OK?

If the payee bank record passes the validation, the Payee Bank Processor 1 will continue the process of payee bank creation. If the payee bank record does not pass the validation, the Payee Bank Processor 1 will contact the payee to obtain the correct information from the payee in replacement.

ZZ.1.1.  Park and Save Information

The Payee Bank Processor 1 parks the payee bank record.

The Payee Bank Processor 2 verifies the parked payee bank record against the supporting document received from the payee. The Payee Bank Processor 2 saves the payee bank record.

ZZ.2.  Identify complex banking instructions

Umoja, through enhancement, will identify master record that meets the criteria for complex banking instructions. For example, domestic USD ACH payments or Euro payments to Euro-zone countries are considered as straightforward payments. Payments that are not straight forward payments are considered complex payments.

Each master record is evaluated by a custom enhancement to determine whether the bank instructions meet the criteria for records that need to include intermediary bank information, i.e. a routing through an intermediary bank. All master records falling in the complex banking instruction category go through a manual review to ensure that all the information necessary to route the payment is included and accurate prior to being released. Master records that do not meet the complex banking instructions criteria (i.e. US dollar payments to banks in the US, and EUR payments to banks in the Euro zone (IBAN)) are not subject to a review and are automatically released.

ZZ.2.1.  Complex Routing?

If a master record meets the criteria for complex banking instructions, the record will be forwarded to the Treasury Master Data Team for manual review. If a master record is considered straight forward payment, the record will be automatically released in Umoja.

ZZ.2.2.  Receive and review payee bank information

The Payee Bank Processor reviews the banking information and, if needed, correct or add the necessary routing information. The Payee Bank Processor forwards the record to the Payee Bank Approver through the workflow for review and approval.

AAA.   Review and release or reject

The Payee Bank Approver reviews and approves the payee bank record forwarded by the Payee Bank Processor. Once the record is released (i.e. approved), it will be available for executing a payment to the payee.

Back to top

BBB.   ACH pre-note

If a record of ACH payment is created, the system creates an ACH pre-notification file. The ACH pre-notification file will be automatically transmitted to the bank along with daily ACH payment files.

Once the payee bank records are created, Umoja will generate an ACH pre-notification file to be transmitted to the bank for verification of the bank account details. Through this ACH pre-notification procedure, if the UN Treasury is advised of a problem with the bank account information of the payee, the payee bank record needs to be modified. A Payee Bank Processor will contact the payee to verify the information, and makes necessary amendment to the payee bank account details.

BBB.1.   Is the pre-note OK?

If the result of pre-note is OK, the process of creating the payee bank record ends. If the result of the pre-note is not OK, then the payee needs to be contacted to receive the correct bank account information.

BBB.2.   Request missing information from Requestor

In the process of finalizing the payee bank record, if the Payee Bank Approver rejects the record or if the result of the pre-note is not OK, then the Payee Bank Processor may contact the Payees to obtain the correct bank account information.

As a result of the review by a Payee Bank Processor or a Payee Bank Approver, if there is missing information to be obtained from the payee, a Payee Bank Processor will contact the payee to request re-submission of the banking information.

3.5.2        Master Data Maintenance - House Bank

House Bank Account refers to the bank account of UN. Receipts are deposited into the House Bank Accounts and payments are made out of the House Bank Accounts. The House Bank Account is linked to the Bank Master Data.

The UN Banks (hereafter referred to as the House Banks in Umoja), represent the Master Data elements associated with the bank accounts held by the UN (as opposed to vendor associated bank accounts).

Umoja system is configured such that the Bank Account is fully integrated; this includes:

·               Setting up the bank master record

·               Requesting a GL account structure associated with the bank account

·               Defining accounting rules for automatic reconciliation of bank transactions

·               Setting up interfaces for bank connectivity of incoming and outgoing transactions as necessary

UNHQ Treasury is responsible for maintaining a 'House Bank Determination Table' in Umoja. This table is referenced by Umoja each time a payment is created. This table determines which House Bank account will be assigned for a particular payment.

The followings outline maintenance processes for House Bank Master Data.

CCC.   Request to open new account or modify signatories / Manual

Upon installation of key infrastructure and administrative systems at a new office or field mission, the office / field mission would conduct an assessment of local banking options. The office / field mission would submit a request to Treasury HQ for opening a local currency account if they determine such an account is justified.

This process of requesting and approving of bank accounts will be managed either via custom developments within Umoja, and/or an industry recognized third party solution with integration functions to Umoja.

The office / field mission would recommend a list of the bank signatories and the bank where the account may be opened. It should be noted that if a fund can utilize an existing bank account, there would not be a need to open a new bank account.

Upon receipt of the request for a new bank account, Treasury reviews and selects an appropriate bank where the UN account should be opened in accordance with the business requirements and the UN Treasury guidelines.

Finally, the list of bank signatories should be sent to OIOS (Office of Internal Oversight Services) for their endorsement.

Upon approval of the Bank Account opening or signatory panel modification, the Treasury Banking Processor will:

·               issue a letter to the selected external bank requesting to open a new account,

·               send a specimen signature of the bank signatories to the House Bank

·               execute other security requirements as defined by the bank.

·               receive the bank account details (bank account number, contact details, etc.) of the new Bank Account from the selected House Bank.

CCC.1.   Receive request to open account or to modify signatories

Treasury receives a request to open a new bank account or to amend the signatory panel for the existing bank account. The request is submitted via an interactive form from the OAH's or Peacekeeping Missions to the Treasury.

CCC.2.   Review the proposed bank

The Treasury Banking Processor reviews the interactive form and identifies the bank proposed by the OAH's or Peacekeeping Missions. The Treasury Banking Processor routes the Interactive Form to the Treasury Banking Approver through workflow.

CCC.3.   Approve the proposed bank

The Treasury Banking Approver reviews the justification for a new bank account. If justified, the Treasury Banking Approver then assesses the appropriateness of the bank identified based on set criteria (e.g. credit checks, global/regional network, D&B reports).

CCC.4.   Review and check the proposed bank signatory list

Next, the Treasury Banking Processor reviews the list of proposed bank signatories and ensures that the proposed signatories are UN employees who meet the treasury policy guidelines.

The process will include an automated check to ensure that the proposed signatory is not an A/P Approver.

CCC.5.   Approve the proposed bank signatory list

The Treasury Banking Approver approves the proposed bank signatory list. The Treasury Banking Approver forwards the interactive form to OIOS for clearance of the bank signatory appointment through workflow.

CCC.6.   Review and endorse the proposed signatory list

OIOS reviews the request in line with the relevant policies and endorses the proposed signatory list.

CCC.7.   Contact bank to request opening of bank account or modify signatory

The Treasury Banking Processor communicates with the selected bank, requesting to open an account. Documentation required by the bank is completed, compiled, and returned to the bank.

This process is also valid when there is a modification to the Bank Signatory Panel. This may occur in the following circumstances:

·               addition of bank signatory(ies)

·               deletion of bank signatory(ies)

·               employee name change

DDD.Create/Update House Bank and signatory records in Umoja / Transaction Codes: FI01 and FI02

The Treasury Banking Processor creates/updates the House Bank records in Umoja, including the record of the bank signatories.

The Treasury Banking Processor creates the master record based on information received, including:

·               Bank Name

·               Bank Address

·               Bank Representative Contacts

·               Bank ID Number (US ABA Number, SWIFT Account Number, etc.)

·               Bank Account Number

·               Bank Account's Main General Ledger Account Number

The Bank Account's Main General Ledger Account Number is established in Umoja through the common protocols established for the creation of General Ledger Accounts.

In order for the account to be fully functional, the Accounting Rules for Bank Transactions (such as BAI2 or SWIFT MT-940 message) will need to be defined and pre-configured in Umoja, in order to facilitate Bank Reconciliations. Additionally, depending on the transactions executed with the Bank, the necessary Secure Transmission Interfaces such as SWIFT will be established in order to support Electronic Communication / Transmission of Files between the UN and the appointed Bank.

EEE.    Approve the House Bank Master Data

The Treasury Banking Approver reviews and approves the House Bank Master Data records and bank signatory records created/updated by the Processor.

Back to top

FFF.      Request Set up of GL Accounts / Manual

The Treasury Banking Processor initiates a request to the Umoja Master Data Team for the creation of the necessary GL Accounts. This is to ensure that once the bank account is operational, transactions can be posted to the Financial Ledgers.

If the Bank Account needs to be reconciled electronically, the Cash Processor will define the Bank Transaction to GL Mapping Changes and the automated clearing rules.

GGG.UMOJA System Administration Team sets upthe required interfaces for bank connectivity of incoming/outgoing transactions.

HHH.The System Administration Team configures:

·               The Bank Statement File Formats (where available)

·               The Secure Transmission Mechanism options available (preferably via SWIFT)

·               The Bank Transaction to GL Mapping Changes and the automated clearing rules required

·               Establishment of Digital Signature in the system

III.          Once the new house bank is configured in Umoja, the requestor is notified so that he/she can proceed to commence utilizing the account

3.5.3        Master Data Maintenance - Bank Reference List

The Bank Reference List is a data table stored in Umoja that contains important Master Data for global banks. To maintain accurate and up-to-date bank information in Umoja, the UN has subscribed an electronic global bank directory file available from a third party service provider. Accuity and SWIFT are examples of such service providers.

The information such as listed below will be available in the Bank Reference List Master Data:

·               bank name

·               bank address

·               bank contact details

·               SWIFT/BIC (if applicable)

·               CHIPS UID (if applicable)

·               National clearing codes (if applicable)

Examples

·               Correspondent bank per currency (if applicable)

·               Head office/branch location

·               Others

The Bank Reference List Master Data table is linked to:

Through these updates of the Bank Directory, a change in the Bank Reference List Master Data automatically changes the Bank Data Information related to the above Master Data objects. Any payment (in transit) that has yet to be included in a payment media file for transmission to the bank is automatically updated.

At the same time, the Bank Data is validated every time any of the above Master Data Objects (listed above) is created and subsequently maintained.

It is important to distinguish between Bank Master Data and Payee Bank Account Data.

The followings outline processes to maintain the Bank Reference List Master Data.

JJJ.         Transmission of Bank Master Data File

The Third Party Service Provider transmits the Bank Master Data File securely via email/web portal to Umoja.

The information in the Bank Master Data will be kept up to date by periodical electronic updates provided by the Third Party Bank Data Service Provider. Umoja will interrogate the third party server on a daily basis for an updated file without human intervention. Typically, the third party service provider will provide an updated file on a monthly basis; thus although Umoja will check daily, it is unlikely that there will be daily updates. When the bank directory is updated, Umoja will automatically produce a report (log) outlining the number of new records, records updated and records flagged for deletion.

JJJ.1.         Upload the Data File

Umoja reads the electronic file provided and updates Umoja Bank Data.

JJJ.2.         Generates a report/log

JJJ.3.         Review Report for update of Bank Master Data / Manual

Once the update is completed, Umoja generates a report outlining the updates to Umoja Bank Directory. This report is then reviewed by the Cash Processor for exceptions. Few exceptions are expected as the same service provider that is currently used will provide this service and exceptions, if any, will be treated on a case by case basis.

It is critical to maintain the most updated information in the Bank Master Data to make payments accurately. The Bank Master Data records are not static as banks change names, routing numbers, and correspondent bank relationships through mergers and acquisitions.

In the rare circumstances where a bank record does not exist in Umoja Bank Directory it will need to be created manually.

KKK.    Creating new bank record / Manual

KKK.1.    Receive a Request to create a bank record

If it is found that a bank account record is missing in Umoja while creating a Payee Bank record, a request to create a bank record in Umoja will be sent to the Treasury Master Data Team.

KKK.2.    Create a bank record manually

The Cash Processor 1 creates a bank record manually.

KKK.3.    Verify and approve a bank record

The Cash Processor 2 verifies and approves the bank record created by the Cash Processor 1.

KKK.4.    Notify the requestor

The Cash Processor 1 or 2 notifies a requester that the bank record has been recorded in Umoja.

Back to top

December, 2016