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 account payables. In addition Cash Pools which represent significant portion of the UN assets is within the scope of accounting for financial instrument.

The objective of this chapter is to give a brief overview of the accounting lifecycle and relevant guidance on accounting for financial assets other than Investments and Cash and cash equivalents within Umoja environment. This chapter on financial instruments primarily includes Accounts Receivable module within Umoja environment.

This chapter details how an end user, based on the involved Umoja user profiles, should perform roles and responsibilities related to accounting of financial assets other than Investments and Cash and Cash equivalents.

2         Summary of IPSAS Accounting Policies

UN Secretariat reporting entities classifies certain financial assets like Cash and cash equivalents, receivables non-exchange and exchange transactions, loans to implementing partners, executing agency, staff, certain Investments in term deposits as Loans and receivables.

The classification of financial assets primarily depends on the purpose for which the financial assets are acquired and is re-evaluated at each reporting date.

2.1            Recognition, Derecognition and Measurement of Loans and Receivables

UN Secretariat reporting entities initially recognizes financial assets classified as loans and receivables on the date that they originate, which is the date the reporting entity becomes party to the contractual provisions of the instrument.

Loans and receivables are non-derivative financial assets with fixed or determinable payments that are not quoted in an active market. They are initially recorded at fair value plus transaction costs and subsequently reported at amortized cost calculated using the effective interest method. Interest revenue is recognized on a time proportion basis using the effective interest rate method on the respective financial asset. They are included in current assets, except for maturities greater than 12 months after the end of the reporting period.

Loans and receivables are assessed at each reporting date to determine whether there is objective evidence of impairment. Evidence of impairment includes default or delinquency of the counterparty or permanent reduction in value of the asset. Impairment losses are recognized in surplus or deficit in the Statement of Financial Performance in the year they arise.

Loans and receivables are derecognized when the rights to receive cash flows have expired or have been transferred and the UN has transferred substantially all risks and rewards of financial asset.

Financial assets and liabilities are offset and the net amount reported in the Statement of Financial Position when there is a legally enforceable right to offset the recognized amounts and there is an intention to settle on a net basis or release the asset and settle the liability simultaneously.

Cash and Cash Equivalents

Cash and cash equivalents include 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.

Contributions receivable

Contributions receivable includes uncollected revenue from assessed and voluntary contributions committed to UN Secretariat reporting entities by member states, non-member states, donors based on enforceable commitments. These non-exchange receivables are stated at nominal value, unless the impact of discounting future contractual cash flows is material, less impairment for estimated irrecoverable amounts.

Other Receivable

Other receivable primarily includes amounts receivable for goods or services provided to other entities, amount receivable for operating lease arrangements, and loans/advances to staff, Inter fund balance.

Impairment of Financial Assets Classified as Loans and Advances

Estimated irrecoverable amount for financial reporting purpose is computed based on an analysis which is primarily based on specific identification of receivable and the period since the receivable is overdue.

Estimated irrecoverable amount for voluntary contributions receivable, trade receivables and other receivables is 100% when overdue for 3 years and more, 60% when overdue by more than 2 years and 25% when overdue by more than 1 year. Estimated irrecoverable amount for assessed contributions receivables is 100% when past due in excess of 2 years for which Member States have contested the amounts and any balances outstanding for less than 2 years will be disclosed in the notes to the Financial Statements.

2.2            Identification of Financial Instruments - Assets

Table below provides a list of common assets in the statement of financial position line items and applies the concepts to determine whether the items meet the definition of a financial instrument. The last two columns of the table establish whether the instruments identified fall within or outside the scope of IPSAS 28: Financial Instruments: Presentation; IPSAS 29: Financial Instruments: Recognition and Measurement, and IPSAS 30: Financial Instruments: Disclosures. The list is not exhaustive, but provides an aide to help in identifying financial instruments.

 

Assets (such as pre-paid expenses) for which the future economic benefit is the receipt of goods or services, rather than the right to receive cash or another financial asset, are not financial assets.

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 Accounts Receivable Module

The Accounts Receivable (AR) area is comprised of all business processes related to recording and tracking receivables from member states, donors, commercial customers, staff members and any other entity that owes money to the UN. The AR module is integrated with other modules/sub module like General Ledge (GL), Sales & Distribution (SD), Travel Management (TM), Flexible Real Estate Management (RE) and Grants Management (GM) which allows simultaneous and online postings to AR.

The Umoja AR solution includes the following processes:

AR process requires the creation of customer as master data elements to execute transactions and maintain source data. These are recorded as Business Partner (BP).

On initial set up, each BP is assigned to a reconciliation account that reflects sub ledger activity in the General ledger. Transactions posted to Business Partner (BP) or customer accounts (invoices, credit memos, payments) are recorded in AR sub ledger and are automatically updated to General Ledger accounting through reconciliation accounts.

Payments from customers can be received via EFT (electronic fund transfer), bank deposits, and cheques. The incoming payment processing and clearing of invoices can be done manually or automatically and as a whole or partially.

Receivable are tracked to ensure timely payments by customers. In the event of late payments, a Dunning process is implemented that creates reminders automatically in the Umoja system.

Impairment is recorded either by way of write offs (recognized directly to business partners ledger account) or by way of allowance (recognized through the use of an allowance account). Allowance for bad debts is recorded as accrual entry. Accrual entry implies that the entry for the allowance is recorded in one period and then automatically reversed in the next period. Accordingly for each period, the allowance entry will be calculated in total, recorded, and then reversed in the next period.

Back to top

3.1.1        Document Types

The use of document types is the key to a meaningful classification of transaction on a customer's account.

There are four categories of accounts receivable document types:

i.              Original documents

·               Documents created manually by AR Users in the accounts receivable module.

·               Downpayment (advance) requests, invoices, credit notes, write offs and incoming payment received by the Cashier and recorded in the cash journal are original documents.

·               AR Users are expected to attach supporting documentation to original documents.

·               Original documents must be approved in workflow, except for cash journal documents which are posted immediately by the cash journal custodian.

ii.            Follow on documents

·               Documents that are automatically created by the system based on original, interfaced or converted documents.

·               Majority of these follow on documents are incoming payment documents generated by the bank reconciliation and clearing documents created by the clearing batch program.

·               A manual follow on document is created when the cash received could not be identified by the bank reconciler and was recorder in the Unapplied Cash GL account. In this case, the AR User has to do a manual application of the cash to the customer's account.

·               Another manual follow on document is created after a downpayment has been paid by the customer. In this case, the AR User manually clears the downpayment.

·               Follow on documents are posted without workflow approval and no supporting documentation is attached.

iii.          Interfaced documents

·               Documents will come through:

o   The Sales and Distribution (SD) interface. Approved Sales Orders in SD will give rise to billing documents in FI.

o   The Real Estate (RE) interface. Approved lease contract will give rise to billing documents in FI.

o   The Grant module via SD where the revenue and receivables for grants with status 'Award'.

·               All accounts receivable documents created by an interface are created with status 'posted'.

·               No supporting document is expected to be attached to interfaced documents.

iv.           Converted documents

·               These documents are posted by the conversion program and there is no supporting documents attached. X1 is the document type for all converted documents in accounts receivable.

 

 

 

3.1.2        Document Status, Workflow Status and Workflow Routing

In Umoja the document status is not linked to the workflow status, thus to know what action is needed to complete a document, combination of the document and workflow status needs to be considered.

Below are document statuses for FI documents, Earmark Funds documents and FM redeployment.

 

It is important to remember that all parked accounts receivable documents need to be cleared at end of month.

·               It is the responsibility of the mission/local office to ensure that there are no parked documents at month end.

·               It is the UNHQ responsibility to ensure that there are no parked documents in a period before the period is closed.

3.1.3        Business Partner (BP)

Accounts receivable module requires a customer for all transactions. No transaction can be posted in the module without a customer. A customer is a business partner that has one of the customer roles.

3.1.3.1  BP Groups

The BP group defines:

i.              the number range of the BP;

ii.            the General Ledger control account used to record accounts receivable transactions for that BP; and

iii.          what roles the BP can have.

The BP group is the first parameter that is defined on the BP master record and it should not be changed afterwards.

The following table shows BP groups available in Umoja:

 

BP numbers are automatically determined by ECC (Enterprise Core Component) in a sequential manner except for:

·               Commercial Vendor UNGM (1110). The BP number is determined by SRM as such that it is considered 'external' to ECC.

·               Individuals BP Groups (2000 to 2001 Individual External, Staff Members and Military and Police). The BP number incorporates the individual's index number (6 or 7 digits) preceded by 2 and two or three zeros to fill in the BP number to 10 digits.

Back to top

3.1.3.2  BP Roles

The BP role defines what transactions can be recorded on the BP. Roles are added to the BP master record by the Master Data Maintenance (MDM) teams responsible for BPs. Roles can be added at the time of creation or at any time later upon request.

The following is the list of the BP roles available in Umoja.

	Role	Financial Transactions	Comment
Z00009	UN Low Value Vendor	Accounts payable	Can be used in SRM with a low value PO and directly in AP for invoices without PO
Z00010	UN FI Vendor	Accounts payable	Only invoices without PO
Z00011	UN Vendor	Accounts payable	Can be used in SRM with POs and directly in AP for invoices without PO
Z00012	UN FI Customer	Accounts receivable	Only invoices without sales order
Z00013	UN Customer	Accounts receivable	Can be used in Sales and Distribution for sales order and directly in AR module for invoices without sales order
Z00014	UN Tenant (w/o Cust. Acct)	No
Z00015	UN Master Tenant	No
Z00016	UN Sponsor	No
Z00017	UN Counterparty	No
Z00018	UN Ship to Partner	No
Z00019	UN Bill to Partner	No
Z00020	UN Financial Services BP	No, Treasury only
Z00021	UN Issuer	No, Treasury only
Z00022	UN Global Custodian	No, Treasury only
Z00023	UN Depository Bank	No, Treasury only
Z00024	UN Bank	No, Treasury only
Z00025	UN Paying Bank	No, Treasury only
Z00026	UN Landlord w.Vendor Account	No
Z00050	UN Lease Processor	No
Z00051	UN Contract Approver	No
Z00052	UN Facilities Planner	No
Z00053	UN Facilities Manager	No
Z00054	UN Real Estate Agent	No
Z00055	UN Contact Person	No

Note: Roles in italized font permit the recording of financial transactions. Roles in blue font are relevant to accounts receivable.

Many roles do not permit the recording of financial transactions in the financial accounting (FI). For example if we use a BP with only the UN Sponsor role, we will not be able to record accounts receivable or accounts payable in FI or record transactions in GM for that BP.

It is also important to remember that the following Business Partner Groups - Commercial Vendor UNGM, Individuals external with index numbers (Retirees, Consultants, Independent Contractors, Survivors, etc), UN Staff Members, Military and Police - do not have customer roles. They only have vendor roles. Accordingly, any cost recoveries from them e.g. telephone bill, fuel, liberty hours, etc. are done by debiting their vendor accounts through a credit memo in the Accounts Payable sub-ledger. The Accounts Receivable sub-ledger is only used to record receivables from Business Partners who have a customer role in Umoja.

In practice, many BPs has more than one roles. The number of roles created on the BP master record depends on the BP group. The following table shows for each BP group, what roles the UN Secretariat has decided to give to all BPs created in that group and what additional roles can be requested at the time of creation or later on an 'as needed' basis.

 

Note: Commercial BP groups (1110 Commercial Vendor, 1800 Commercial Customers and 1900 Vendor non UNGM) do not mix vendor and costumer roles on the same BP while other BP groups (such as 1111 Member States) combine a vendor and customer role on the same BP. This is because BP number for 1110 Commercial Vendor UNGM is not determined in ECC whereas the BP number for 1800 Commercial Customers is. As a result, two separate BP groups and number ranges had to be created for commercial entities.

3.1.3.3  BP Types

The BP type is a field on the BP master record that provides more definition within a BP group. It is mostly used to distinguish the type of individual. A BP can only have one type at a time; however the BP type can be changed as needed by the MDM teams upon request.

The HRM solution does not require BP types, as it uses Employee groups and sub-groups to categorize individuals. However, in the Umoja foundation the Progen payroll system has been retained and BP types are used to categorize individuals for the purpose of the Progen interface.

The following shows the BP types available in Umoja:

 

3.1.4        General Ledger (GL) Account Used in Accounts Receivable

The accounts receivable subledger uses reconciliation accounts to record transactions. These accounts can only be accessed through the subledger with the use of a business partner with a customer role. This ensures that the AR subledger will reconcile with the general ledger.

The GL account structure for accounts receivable include four GL accounts for each BP Group. The structure will allow us to provide analysis or disclosure information by BP Group.

 

Back to top

The following table summarizes the GL accounts used in accounts receivable that may be classified as Loans and receivables:

 

3.1.4.1  Exchange Receivable

The following GL accounts are used to record exchange accounts receivable balances:

 

Exchange GL Accounts
GL Acct	Long Text	GL Acct Structure
15101010	AR Exch Mmbr St	1	510	10	10
15101014	AR Exch Mmbr St Man Adj				14
15101016	AR Exch Mmbr St AFDA Man				16
15101019	AR Exch Mmbr St Revaluation				19
15101110	AR Exch Govt NonMmbr St			11	10
15101114	AR Exch Govt NonMmbr St Man Adj				14
15101116	AR Exch Govt NonMmbr St AFDA Man				16
15101119	AR Exch Govt NonMmbr St Revaluation				19
15101210	AR Exch Govt and Local Authority			12	10	1 = Current Asset
15101214	AR Exch Govt and Local Authority Man Adj				14		510 = Exchange Accounts Receivable
15101216	AR Exch Govt and Local Authority AFDA Man				16			10 = Member States BP Group
15101219	AR Exch Govt and Local Authority Revaluation				19			11 = Govt Non Membr St BP Group
15101310	AR Exch UN Agency Fund Programme			13	10			12 = Govt and Local Authority BP Group
15101314	AR Exch UN Agency Fund Programme AFDA Man Adj				14			13 = UN Agency Fund Programme
15101316	AR Exch UN Agency Fund Programme AFDA Man				16			14 = Intergov and NGO
15101319	AR Exch UN Agency Fund Programme Revaluation				19			15 = Commercial
15101410	AR Exch Intergovernment NGO			14	10			16 = Staff Members
15101414	AR Exch Intergovernment NGO Man Adj				14			17 = Military and Police
15101416	AR Exch Intergovernment NGO AFDA Man				16			18 = Individual External
15101419	AR Exch Intergovernment NGO Revaluation				19				10 = reconciliation account
15101510	AR Exch Commercial Customer			15	10				14 = Man Adj + System Reclassification
15101514	AR Exch Commercial Customer Man				14				16 = Allowance for Doubtful Accounts (ADA or AFDA)
15101516	AR Exch Commercial Customer AFDA Man				16				19 = System Revaluation per IPSAS
15101519	AR Exch Commercial Customer Reval				19
15101614	AR Exch UN Staff Member Man			16	14
15101616	AR Exch UN Staff Member AFDA Man				16
15101619	AR Exch UN Staff Member Reval				19
15101714	AR Exch Military and Police Man			17	14
15101716	AR Exch Military and Police AFDA Man				16
15101719	AR Exch Military and Police Reval				19
15101814	AR Exch Individual External on Payroll Man			18	14
15101816	AR Exch Individual External on Payroll AFDA				16
15101819	AR Exch Individual External on Payroll Reval				19

 

Note: Individuals (Staff and non-staff) do not have a customer role and therefore there is no reconciliation GL account ending in '10'.

 

3.1.4.2  Non-Exchange Contributions and Loans Payable (Borrowings)

The AR subledger is also used to record loans payable (borrowings) from entities outside Umoja. Even though loans payable (borrowings) are classified as current liabilities in the UN financial statement, these transactions result in cash receipt being recorded in Umoja. Thus loans payable (borrowings) are recorded in the accounts receivable subledger on a BP with a customer role. Conversely, loans receivable are recorded in the accounts payable subledger on a BP with a vendor role.

Because only one reconciliation GL account can be maintained on the BP master record and we have opted to maintain the Exchange GL account on the BP master records, special GL (SPGL) indicators will need to be used to record non-exchange transactions and loans payable in different reconciliation accounts. Combination of the reconciliation account on the BP master record with the specific SPGL used on the transactions will determine the alternate reconciliation GL account for non-exchange transactions and loans payable.

GL accounts used for non-exchange contributions and loans payable are as follows:

 

Assessed Contributions Receivable - SPGL M
GL Acct	Long Text	GL Acct Structure
13101010	AR Assessed Mmbr St	1	310	10	10	1 = Current Asset
13101014	AR Assessed Mmbr St Man Adj				14		310 = Assessed Contributions Receivable
13101016	AR Assessed Mmbr St AFDA Man				16				10 = Member States BP Group
13101019	AR Assessed Mmbr St Revaluation				19				11 = Govt Non Membr St BP Group
13101110	AR Assessed Govt NonMmbr St			11	10						10 = AR Control Account
13101114	AR Assessed Govt NonMmbr St Man Adj				14						14 = Man Adj + System Reclassification
13101116	AR Assessed Govt NonMmbr St AFDA Man				16						16 = Allowance for Doubtful Accounts (ADA or AFDA)
13101119	AR Assessed Govt NonMmbr St Revaluation				19						19 = System Revaluation per IPSAS

 

Voluntary Contributions Receivable - SPGL V
GL Acct	Long Text	GL Acct Structure
14101010	AR Volunt Mmbr St	1	410	10	10	1 = Current Asset
14101014	AR Volunt Mmbr St Man Adj				14		410 = Voluntary Contributions Receivable
14101016	AR Volunt Mmbr St AFDA Man				16			10 = Member States BP Group
14101019	AR Volunt Mmbr St Revaluation				19			11 = Govt Non Membr St BP Group
14101110	AR Volunt Govt NonMmbr St			11	10			12 = Govt and Local Authority BP Group
14101114	AR Volunt Govt NonMmbr St Man Adj				14			13 = UN Agency Fund Programme
14101116	AR Volunt Govt NonMmbr St AFDA Man				16			14 = Intergov and NGO
14101119	AR Volunt Govt NonMmbr St Revaluation				19			15 = Commercial
14101210	AR Volunt Govt and Local Authority Govt			12	10				10 = AR Control Account
14101214	AR Volunt Govt and Local Authority Govt Man Adj				14				14 = Man Adj + System Reclassification
14101216	AR Volunt Govt and Local Authority Govt AFDA Man				16				16 = Allowance for Doubtful Accounts (ADA or AFDA)
14101219	AR Volunt Govt and Local Authority Govt Revaluat				19				19 = System Revaluation per IPSAS
14101310	AR Volunt UN Agency Fund Programme			13	10
14101314	AR Volunt UN Agency Fund Programme Man Adj				14
14101316	AR Volunt UN Agency Fund Programme AFDA Man				16
14101319	AR Volunt UN Agency Fund Programme Revaluation				19
14101410	AR Volunt Intergovernment NGO			14	10
14101414	AR Volunt Intergovernment NGO Man Adj				14
14101416	AR Volunt Intergovernment NGO AFDA Man				16
14101419	AR Volunt Intergovernment NGO Reval				19
14101510	AR Volunt Commercial Customer			15	10
14101514	AR Volunt Commercial Customer Man Adj				14
14101516	AR Volunt Commercial Customer AFDA Man				16
14101519	AR Volunt Commercial Customer Reval				19

 

Voluntary Contribution Receivable in Kind - SPGL K
GL Acct	Long Text	GL Acct Structure
14111010	AR In Kind Volunt Mmbr St	1	411	10	10	1 = Current Asset
14111014	AR In Kind Volunt Mmbr St Man Adj				14		411 = Voluntary Contributions Receivable in Kind
14111016	AR In Kind Volunt Mmbr St AFDA Man				16			10 = Member States BP Group
14111019	AR In Kind Volunt Mmbr St Revaluation				19			11 = Govt Non Membr St BP Group
14111110	AR In Kind Volunt Govt NonMmbr St			11	10			12 = Govt and Local Authority BP Group
14111114	AR In Kind Volunt Govt NonMmbr St Man Adj				14			13 = UN Agency Fund Programme
14111116	AR In Kind Volunt Govt NonMmbr St AFDA Man				16			14 = Intergov and NGO
14111119	AR In Kind Volunt Govt NonMmbr St Revaluation				19			15 = Commercial
14111210	AR In Kind Volunt Govt and Local Authority			12	10				10 = AR Control Account
14111214	AR In Kind Volunt Govt and Local Authority Man				14				14 = Man Adj + System Reclassification
14111216	AR In Kind Volunt Govt and Local Authority AFDA				16				16 = Allowance for Doubtful Accounts (ADA or AFDA)
14111219	AR In Kind Volunt Govt and Local Authority Reval				19				19 = System Revaluation per IPSAS
14111310	AR In Kind Volunt UN Agency Fund Programme			13	10
14111314	AR In Kind Volunt UN Agency Fund Programme ManAdj				14
14111316	AR In Kind Volunt UN Agency Fund Programme ADAMan				16
14111319	AR In Kind Volunt UN Agency Fund Programme Reval				19
14111410	AR In Kind Volunt Intergovernment NGO			14	10
14111414	AR In Kind Volunt Intergovernment NGO Man Adj				14
14111416	AR In Kind Volunt Intergovernment NGO AFDA Man				16
14111419	AR In Kind Volunt Intergovernment NGO Reval				19
14111510	AR In Kind Volunt Commercial Customer			15	10
14111514	AR In Kind Volunt Commercial Customer Man Adj				14
14111516	AR In Kind Volunt Commercial Customer AFDA Man				16
14111519	AR In Kind Volunt Commercial Customer Reval				19

 

VAT Receivable and Recoverable - SPGL N
GL Acct	Long Text	GL Acct Structure					1 = Current Asset
15201010	AR VAT Receivable	1	520	10	10			520 = VAT Receivable
15201014	AR VAT Recoverable Man Ajd (OIM)				14				10 = AR Control Account
15201015	AR VAT Recoverable Man				15				14 = Intermediate GL account
15201020	AR VAT Recoverable				20				15 = For use in Grant?
15201099	AR VAT Receivable Reval				99				99 = System Revaluation per IPSAS

 

Loans Payable GL accounts - SPGL L
GL Acct	Long Text	GL Acct Structure
36201310	Borrowing UN Agency Fund Programme	3	620	13	10	3 = Current Liability
36201320	Borrowing UN Agency Fund Programme Manual				20		620 = Voluntary Contributions Receivable
36201327	Borrowing UN Agency Fund Programme Interfund(OIM)				27			13 = UN Agency Fund Programme
36201328	Borrowing UN Agency Fund Programme Interfund				28				10 = AR Control Account
36201399	Borrowing UN Agency Fund Programme Reval				99				20 = Man Adj + System Reclassification
									27 = Interfund loans within Umoja (FV50)
									28 = Interfund loans within Umoja
									99 = System Revaluation per IPSAS

 

3.1.5        Special GL (SPGL) Indicator

The following table shows SPGL indicators available in Umoja for accounts receivable and the change in reconciliation account resulting from each SPGL indicator for each BP groups.

 

3.1.6        Document Flow - General

The general flow provides for an accounts receivable document cleared by an incoming payment document which is clearing a bank statement document.

 

Back to top

3.1.7        Enterprise Roles Involved in Accounts Receivable

 

3.2            Recognition of Accounts Receivable

The UN reports its income under three sections. The recording of some of these incomes results in the creation of accounts receivable.

Examples of transactions resulting in accounts receivable include:

·               Sale of goods sold and services rendered including Catering Services, Sale of Publications, Guided tours, Sale of audio/visual products etc.

·               Recovery of:

o      Vehicle repair charges from UN Agencies

o      Use of conference facilities

o      Advances and other recoveries from staff members

o      Advance to organize programs

o      Common services used by UN Agencies and NGOs

o      VAT from host government

·               Sale of assets

·               Lease administration for owned and subleased properties

·               Grants billing to donors

·               Transfer of revenue bearing work/service order management to other UN agencies

It must be noted that all assets and liabilities that result from transactions with in AR module may not be financial assets as per IPSAS. Assets such as pre-paid expenses for which the future economic benefit is the receipt of goods or services, rather than the right to receive cash or another financial asset, are not financial assets.

Various methods are used in Umoja to capture revenues (exchange and non-exchange). The choice of which method to use is a function of two factors; type of customer and type of income. The following are methods used in Umoja for billing/cost recovery.

Receivable can be recorded in Umoja through a customer Invoice. A customer invoice can be created in Umoja through:

 

Receivable from Assessed Contributions

The main objective of this process is to interface with the legacy systems which calculate the Member States' assessments for the Working Capital Fund, Regular Budget (RB), Peacekeeping (PK) Operations, Tribunals and Capital Master Plan (CMP), to record invoices and credit memos and to prepare assessment letters with attachments to member states.

The process will start after the adoption of the RB & PK scales and budgeted amounts for RB, PK, Tribunals and CMP. After the adoption, the appropriated amounts (Gross, Staff assessment credits and Net assessments) are apportioned using the applicable scale of assessments. This is done using Excel spreadsheets. The apportioned amounts (Gross, Staff assessment and Net components) will then be interfaced from the Excel Spreadsheets to Umoja to post the assessments and the credits if any from peacekeeping operations to Member States' accounts.

The accounting policy for revenue recognition is discussed in Revenue from Non-Exchange Transactions. Once the invoices and related credits are approved for posting, the system will also post automatic journal entries by recognizing the revenue and posting relevant entries in the Accounts Receivable (AR) System.

Receivables from Upstream Processes

The creation of most invoices from upstream processes will be automatic. For example, a sale of postal stamps processed in Sales & Distribution (SD) triggers a creation of sales order followed by outbound delivery (post goods issue) which leads to the billing process to record the receivable and related revenue. The resulting accounting entry created from billing process is passed through the backend to Financial Accounting (FI) - AR (sub ledger) and Financial Accounting (FI) - GL modules.

Below is a list of business transactions identified to create receivables coming from different upstream processes:

Upstream Module	Business transactions
Sales & Distribution (SD)	Commercial activities, third party procurement, cost reimbursement for services provided to parties external to Umoja, Sale or donation of inventory (material) or asset and Advance payment requests to other Agencies
Real Estate Management (RE)	Rental revenues arising from owned and subleased assets
Grants Management (GM)*	Receivables from sponsors and/ or implementing partners
Travel Management (TM)	Advances to staff

* Currently in GM, receivables can be processed through the SD billing function as well as creation of manual invoice in Finance.

Receivables Managed in Finance (FI) module

In certain cases, invoices will be created manually in the Financial Accounting division. For example, when the UN Secretariat pays insurance or taxes on behalf of other UN entities, a manual invoice will be raised to create the related receivable.

Below is a proforma data entry view to recognize receivable from other UN entities e.g. remittance of taxes on their behalf. UN entities belong to account group Z014, therefore the reconciliation account to be derived for this BP account group is 15101310 AR Ex UN Agency Fund Program.

PK	SPGL	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Fund	Segment	Funded Program	Fund Center
01		14XXXXXXXX	BP number with customer role	1000	USD	S001
50		79151010*	Reimbursement of Federal Tax	(1000)	USD	S001	10UNA	114STFASMT	FPNR	10001

* The combination of coding block entered above will automatically derive the business area, functional area, segment, funded program, fund center, and budget period.

Back to top

3.2.1        Customer Invoice Processing

This section includes the requirements to create invoices from different business areas such as revenue bearing work or service order processed in SD, GM, TM, RE, or FI. The accounts receivable is recognized at BP with customer role level and automatically updates the General Ledger reconciliation account.

In general, there are three sources of customer invoice processing in Umoja:

·               Invoice processing through manual entry (refer to section 3.2.1.1)

·               Invoice processing through interface (refer to section 3.2.1.2)

·               Invoice processing from upstream processes (refer to section 3.2.1.3)

3.2.1.1  Customer Invoice Processing through Manual Entry

A.      Create parked customer invoice or credit memo / Transaction Code: FV70 or FV75

A.1.      In Park Customer Invoice or Credit Note entry screen the following values are entered or selected from drop down menus:

Header Data:

Basic data tab:

·               Customer: 13XXXXXXXX* (BP with customer role)

·               SGL Ind:

·               Invoice date:

·               Posting Date:

·               Document Type: DR Customer Invoice (default value)

·               Amount: USD 100

·               Document Currency: USD

·               Reference:

·               Text: freely definable

* 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 13 will call BP account group Z013 which is Government and Local Authority and derive GL account 15101210 AR Ex Govt Local assigned to the BP number.

Park Customer Invoice (T-code: FV70)

Park Customer Credit Memo (T-code: FV75)

Payment tab:

·               Bline Date:

·               Payt Terms: Z001 Payable immediately (only applicable in T-code FV75)

·               Pmt Method: applicable in T-code FV70

T-code: FV70

T-code: FV75

Line Item Data:

·               G/L acct: 74121010

·               D/C: Credit/Debit

·               Amount:

·               Fund: 20OLA

·               Cost center: 10062

·               Grant: GMNR*

* The combination of coding block entered above will automatically derive the business area, functional area, segment, funded program, fund center, and budget period.

T-code: FV70

T-code: FV75

A.2.      Press Enter to validate the information entered.

A.3.      Click on the Simulate General Ledger to review the proforma entry

PK	SPGL	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Fund	Segment	Funded Program	Fund Center
01		15101210	AR Ex Govt Local	100	USD	P003	20OLA	206PKSUPMG	FPNR	10062
50		74121010*	OE Communication Carrier Service	(100)	USD	P003	20OLA	206PKSUPMG	FPNR	10062

*Represents expense recoverable from Local government where Local government has agreed to share portion of expense incurred by UN.

A.4.      Select Save as completed button to release the parked invoice or credit note to workflow. A document number (invoice number) appears at the bottom of the screen to be noted down.

B.      Display Manual Invoice/Credit Memo / Transaction Code: FB03

For manual invoice or credit memo, there is no specific form of invoice defined as a business requirement.

B.1.      Enter FB03 in the Command field and press Enter.

B.2.      Enter:

·               Company Code: 1000

·               Fiscal Year: 20XX

·               Document Number: 22XXXXXXXX

B.3.      Select Execute button à Display Document: Data Entry View screen appears.

Back to top

3.2.1.2  Customer Invoice Processing through Interface

This process is applicable for receivables from assessed contributions that are calculated in the legacy system. The completed assessments worksheet for the regular budget, peacekeeping operations, peacekeeping credits, capital master plan and international tribunals are uploaded to the Member State Assessment Cockpit in Umoja. This process is only carried out by the Contributions Services in New York.

C.      Upload of assessment calculation to Umoja / Transaction Code: ZARASSESS

The upload of assessment calculation to Assessment Cockpit will trigger the review and approval to create accounts receivables from or credits (payables) to Member States and Non-Member States.

C.1.      Export from the Assessed Contributions Management System spreadsheet for upload to the cockpit

C.1.1.      All relevant calculations processed through the Assessed Contributions Management System (ACMS) - http://nyvm0428.ptc.un.org/ACMS/Default.aspx

C.1.2.      Select assessment to be uploaded. E.g. Type PKA

C.1.3.      Click Submit to Umoja

C.1.4.      When actions box pops up, click Save document

C.1.5.      Once download is complete, go to excel and open the file from downloads

C.1.6.      Note that the file is downloaded as a PKA file

C.1.7.      Once the file has been selected, click Open

C.1.8.      Step 1 of Wizard - Select Delimited then click Next

C.1.9.      Step 2 of Wizard - Ensure only Comma is selected and click Next

C.1.10.  Step 3 of Wizard - Ensure General is selected. Then click Finish

C.1.11.  File opens as below

C.1.12.  Go to File>Save As

C.1.13.  Change name of file to format 'YYMMFFFFF.PKA.CSV' and save type to CSV (Comma delimited) and save to C:\IAIS\data directory. Close file

C.1.14.  In files related to additional assessments, the word 'additional' should not be bracketed. Please also note that any word/character entered in this cell will be accepted during the upload. You may also wish to note, there is a validation built into the system. If an attempt is made to load a file with the same name for the same mandate period but the word additional is not included, then the upload will fail as the system will interpret this file as a duplicate file

C.1.15.  All files which are to be uploaded to the Member Assessment Cockpit must meet requirements related to the file type and name format. The following file types have been configured for use in Umoja

C.2.      Upload a document into the assessment cockpit in Umoja (T-code ZARASSESS)

C.2.1.      Enter the T-code ZARASSESS in the Command field

C.2.2.      Click the Enter icon

C.2.3.      The Member Assessments Credits Screen is displayed

C.2.4.      In the Document Date field, enter the date of the document to be uploaded. This can be the same as the current date

C.2.5.      The Positing Date field defaults to the current date but may be defined as the date you are posting the assessment to the system

Back to top

C.2.6.      Click on the File Location field and select the file to be uploaded by clicking on the icon which resembles two sheets of paper

C.2.7.      Once file has been selected, click on the Execute button

C.2.8.      The system will review the file to confirm it is acceptable for upload. Should this review process uncover any errors, these errors will be displayed and the file must be corrected and the upload restarted

C.2.9.      Once upload has been successful, verify that all entries match the uploaded file, including header information. Issue date can be modified at this stage to match the actual issue date of the assessment

C.2.10.  Once details of the upload have been confirmed, click the Save button at the top of the screen to post the uploaded assessment. Once saved, the system will generate a Y* document number

C.3.      Approve a document in the assessment cockpit in Umoja

C.3.1.      To approve the upload, click the Back button and return to Member Assessment Credits screen

C.3.2.      Select the Approve button and within the Document ID tab, select the document to be approved

C.3.3.      Click Execute

C.3.4.      The new screen Assessment cockpit Approve/Reject Details is displayed

C.3.5.      At this stage, the document can either be approved (posted) or canceled (deleted)

C.3.6.      To approve, select Approve (F8) and the system prompts for confirmation that you wish to approve the document

C.3.7.      Click the for yes and the for no. The approval process may take a few minutes. If no is selected, you will need to click back, return to the selection screen and select the document again

C.3.8.      PLEASE NOTE: If is selected, the system request confirmation if you want to delete the uploaded records. Click the for yes and the for no

C.3.9.      If the is selected, the document is deleted and the user receives a message confirmation

C.4.      Change issue date after document has been approved

After a document has been approved, it is possible to change the issue date of the approved document. The act of changing the issue date will impact the aging of the related AR documents.

C.4.1.      Select the Change Issue Date radio button

C.4.2.      Then select the correct document by either typing the document number in or selecting by clicking on the icon

C.4.3.      Once document has been selected, click on the Execute button . The Issue Date can now be manually changed and the Save button should be clicked to confirm the change

C.4.4.      Once the is selected, an information box is displayed indicating that a spool has been created and the message 'Issue date successfully updated' is visible by line item

C.5.      Reversal of an approved document

If an approved document needs to be reversed, a process exists to reverse documents either in their entirety or not at all.

C.5.1.      To reverse a document, go the Member Assessments Credits screen and select the Reversal button

Back to top

C.5.2.      Select the document to be reversed and click Execute

C.5.3.      The Assessment Cockpit - Reverse Details screen appears. This screen contains the option to reverse

Please note that if any of the related AR documents have a payment or credit applied against it, this must be undone before the reversal occurs.

C.5.4.      Upon clicking REVERSE, the confirmation box pops up. Clicking the green tick confirms that the reversal should proceed. Please note that the reversal process will take time as it needs to reset and reverse each clearing document, reverse each credit memo and then reverse each AR document

C.5.5.      When complete, document status changes to REVERSED and the relevant reversal document numbers are indicated

NOTE: Additional information on the reversal process

The clearing document generated in the cockpit acts as a knot between the credit memo and the account receivable. During the reversal process, this knot must first be undone (reset) before the clearing document can be reversed. This reset and reversal process of the clearing memo is independent of the status of the credit memo and account receivable entry, and cannot be undone once it has begun.

The system is configured as an all or nothing system. Therefore, if for any reason the credit memo or accounts receivable cannot be reversed, the status will not reverse the existing entries until the hindrance is removed.

C.6.      Reports

C.6.1.      Reports for Uploaded Records (Uploaded but not yet approved)

C.6.1.1.            Select the Report for Uploaded Records

C.6.1.2.            Click the Execute button and the upload selection criteria screen opens

This screen can then be narrowed according to Document ID, Issue Date, Posting Date in the Document, Fund, Source Filename and Assessment Type. It is also possible to do a free search by simply clicking the Execute button without selecting any criteria.

C.6.1.3.            Results returned indicate the Document ID, Issue Date, Doc ID Status, Source Filename, Timestamp, User Name, Posting Date, Doc date, Budget Period, etc.

C.6.1.4.            If you wish to see the line details related to a particular Document ID, double click on the document ID and the details are displayed in the screen preview below

C.6.1.5.            In order to approve the document, you will need to copy or make a note of the Document ID number and then click the Back button in order to select the Approve radio button (please refer to the section on approval)

C.6.2.      Reports on Posted Records

C.6.2.1.            Select the Report for Posted Records

C.6.2.2.            Click the Execute button and the posted selection criteria screen opens

This screen can then be narrowed according to Document ID, Issue date, Posting Period, Fiscal Year, Fund, Source Filename and Assessment Type. It is also possible to do a free search by simply clicking the Execute button without selecting any criteria

C.6.2.3.            Results returned indicate the Document ID, Issue Date, Doc ID Status, Source Filename, Timestamp, User Name, Posting Date, Doc Date, Budget Period, etc.

Back to top

C.6.2.4.            If you wish to see the line details related to a particular Document ID, double click on the document ID and the details are displayed in the screen preview below

C.6.3.      Reports on Reversed Documents

This report can be used to identify all records which have been reversed in the cockpit

C.6.3.1.            Select the Report for Reversed Records

C.6.3.2.            Click the Execute button and the reverse selection criteria screen opens

C.6.3.3.            The user can either do a free/wide search or can narrow their search criteria according to Document ID, Issue date, Source File Name, Posting Period, Fiscal Year, Fund and Assessment Type

C.6.3.4.            Results returned indicate the Document ID, Issue Date, Doc ID Status, Source Filename, Timestamp, User Name, Posting Date, Doc Date, Budget Period, etc.

C.6.4.      Report on Document ID Status

This report can be used to identify all records which have been entered into the cockpit and will show the status of the particular document

C.6.4.1.            Select the Report for Document ID Status

C.6.4.2.            Click the Execute button and the document status selection criteria screen opens

The user can either do a free/wide search or can narrow their search criteria according to Document ID, Issue date, Posting Period, Fiscal Year, Assessment Type, Fund and Document ID Status.

C.6.4.3.            Results returned indicate the Document ID, Issue Date, Doc ID Status, Source Filename, Timestamp, User Name, Posting Date, Approval date (if applicable), Posting User, Reversal Date, Reversal User, Posting Period and Fiscal Year

General note on the status of documents

Based on the current design, documents can be in the status of Approved, Unapproved, Creditsapp(Credits Applied), Reversed, Deleted or Revinprogress (reversal in progress)

Definitions:

Unapproved: Assessment worksheet has successfully passed the built in validations for uploading and has been uploaded and saved.

Approved: Document which has been uploaded has passed the validations for approval and has generated the relevant accounting documents (Accounts Receivable, Credit Memo and Clearing Document (for Staff Assessment portion of the assessment).

Creditsapp: Used to indicate that the credits have been applied for the particular fund. Credits are loaded using as a PKC assessment.

Reversed: reversed indicates that all documents generated by the approval process in the cockpit have been reversed. Documents can only be reversed if all subordinate documents can be reversed as no follow-on transactions have been processed against these documents.

Deleted: After a document has been uploaded and saved, it is possible to delete the document prior to approval. In this case, the system maintains a record of the header information related to the document uploaded, but there is no line item view available.

Revinprog: This relates to the reversal process. When the reversal process has begun, the system first reverses the clearing document that has been generated. It then tries to reverse the credit emo against the account receivable document which has been created. If for any reason, the credit memo is unable to be cleared against the receivable document, the reversal process will halt, advise of an error and cannot be restarted until the problem has been resolved.

Error Logging

Umoja has a spool report format which maintains a record of all files processed in the cockpit. If an error is generated during the upload, approval, change issue date or reversal process, the system generates a report which is similar to an audit trail. This report can be reviewed and saved to excel (for example).

To view report in detail, click on the icon in the column Type for additional details.

Back to top

3.2.1.3  Customer Invoice Processing from Upstream Processes

The transactions are initiated in upstream processes such SD, RE, GM, and TM. They are posted in Sub-ledger using the BP accounts with customer role and automatically updated in General Ledger (GL).

D.     Invoice processing of posted document coming from Sales & Distribution (SD)

The followings are steps for the Financial Accounting Senior User to follow in order to process customer invoice from standard order generated and approved by Sales and Distribution (SD) User and Approver.

D.1.     Display and review list of Standard Orders / Transaction Code: VA05

The Sales and Distribution user or approver must communicate the list of approved standard order to the FI Senior User as currently there is no Umoja workflow or automated notification to the FI Senior User after the approval of a sales order.

D.1.1.     Enter VA05 in the Command field and press Enter.

D.1.2.     Enter the following values and press Enter:

·         Sold-to party: customer number

·         Document Date

·         Checked Open sales orders button in Selection criteria section to obtain list of standard orders for which invoices have not been issued.

D.1.3.     Double click the specific sales order from the list to review the details in the sales order screen that appears.

D.1.4.     At the Sales tab, check and ensure that the status of each item is Approved.

D.1.5.     Click the Item detail tab and review the Item category.

Described below are the available Item categories and their functionalities:

Item Category	Description	Comments
TAD	Service	Used when the line item is for a 'Service' provided to the Sold-to Party
TAS	ThirdPartyIt w/PReq	Used when the line item is for a 'Service' or 'Material' that is provided by a Third Party to the Sold-to Party. This category creates a Purchase Requisition (shopping cart) automatically, which will be converted to a Purchase Order and sent to the Third Party. The Sold-to Party would pay the owner of the order and the Third Party would be paid by the owner of the order
ZTAD	Service W/DownPaymt	Used when the line item is for a 'Service' and requires a 'Downpayment' before the start of the service. Billing Plans are used to maintain these downpayments
ZTAS	ThirdParty w/DP-PReq	Used when the line item is for a 'Service' or 'Material' that is provided by a Third Party, where an automatic purchase requisition is created and a downpayment is required
Z3P	Bill 3Party w/o PReq	Used when the line item is for a 'Service' that is provided by a Third Party, but a purchase requisition is not created automatically
Z3PD	Bill 3 PtywDP no PReq	Used when the line item is for a 'Service' that is provided by a Third Party, a downpayment is required but an automatic purchase requisition is not created

 

D.1.6.     From the Item overview tab, select the Line Item to review and click Display Item Detail icon.

D.1.6.1.           At the Billing Document tab, verify the Billing Date associate with the line item. Ensure that this is the correct due date.

Note: The system will not process the billing when the Billing Date is earlier than the Sales Order date or when there is no account assignment.

D.1.6.2.           At Conditions tab, verify the condition types and the surcharges. Ensure that the charges are applied in accordance with the UN rules and policies.

Back to top

D.1.6.3.           At Account assignment tab, click FM AccAssignt to review the fund assignment of the standard order.

Ensure that the Fund Center, Fund and Functional Area combination is correct and that the Fund is valid for the relevant financial period.

Note: Refer to Job Aid for P1E 100 Coding Block to review the correct combination of Fund Center, Fund and Functional Area.

D.1.6.4.           Click the Back icon to return to the Overview screen.

D.1.7.     If the Sales Order Item Category includes a downpayment from the customer, then the FI Senior User must check the entry in the Billing plan tab.

Note: Downpayment may be created through the header or the line item. When it is on the header, the downpayment is applied to all the items in the sales order.

D.1.7.1.           Click on the Display doc. Header Details icon to access the order header.

D.1.7.2.           At the Billing plan tab, review:

·               Billing Date: The billing date on the first line refers to the due date for the customer to pay the downpayment. The billing date on the second line refers to the due date for Finance to complete the service to the customer.

·               Downpayment percentage located on the first row.

·               The total value of the line item on the second row, which should be the same as the amount in the Billing value field.

Note: The system automatically puts a block on the second line to prevent the processing of the final invoice before the downpayment. After the downpayment is received and recorded and the service rendered, the block needs to be removed by the FI Senior user, as a prerequisite for the final billing document to be created.

D.2.     Process billing / Transaction Code: VF04

A billing document is a financial document that records a receivable on the customer's account and credits either revenue or an expense account as determined by the configuration of the material used on the sales order. During this process, the accounting entries are posted to the general ledger and to the customer account.

Note: The GL account determined by the system to record the credit cannot be modified by the SD User, SD Approver or FI Senior User.

D.2.1.     Enter VF04 in the Command field and press Enter.

D.2.2.     In the Maintain Billing Due List screen, enter the relevant parameters:

·         Billing Date from

·         Sales Organization: 1000

·         Check Order-related checkbox

D.2.3.     Click DisplayBillList button.

D.2.4.     Highlight the appropriate sales order document. Select the Display document from the Environment drop down list to view the details of the document. Click the button to simulate the billing document and review the proforma.

D.2.5.     Click the Back icon and hit the Individual billing document button. Note: Click the Collective billing document if consolidated billing is required.

D.2.6.     Click the Save icon to create an invoice.

Below is the proforma entry of the document created.

PK	SPGL	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Fund
01		1XXXXXXXXX	BP account with customer role	2700	USD
50		63102040	Inc. SP Ext Cleaning	(1500)	USD	P012	20HSA
50		63101090	Inc. SP ExtComCablAud	(1200)	USD	P012	20HSA

 

If a customer was billed for an advance, the system creates a Downpayment request or a Noted Item in the system which is a memo entry (one line entry) with the special GL indicator (SPGL) F is created.

D.3.     Change or cancel invoice / Transaction Codes: VF02 and VF11

The FI Senior User should not change the invoice directly. If there is an error, the FI Senior User cancels the invoice and request the SD User to amend the Standard Order thus a new billing document is processed to reflect the changes in the Standard Order.

The FI Senior User can use the Invoice Change function to add any additional text or instruction on to the invoice.

D.3.1.     To change an invoice, enter VF02 in the Command field and press Enter.

D.3.1.1.           Key in the invoice number in the Billing document field and hit Enter.

Back to top

D.3.1.2.           In the open screen, click the Display doc. Header Detail icon.

D.3.1.3.           Go to Head.text tab and enter the required text or instruction. Click Save when complete.

D.3.1.4.           To enter text at Line Item level, select the relevant line and click Display Item Detail icon.

D.3.1.5.           Go to Item Texts tab and enter the required text or instruction. Click Save when complete.

D.3.2.     To cancel an invoice, enter VF11 in the Command field and press Enter.

D.3.2.1.           Enter the invoice number in the Document field.

D.3.2.2.           Click Save to execute the transaction à a new Document Number will be generated and saved.

D.4.     Print invoice / Transaction Code: VF02

D.4.1.     Enter VF02 in the Command field and press Enter.

D.4.2.     Enter the Invoice Number in the Billing document field and Execute.

D.4.3.     Click the Output icon or select Goto from the navigation menu à Header à Output.

D.4.4.     Enter ZRD0 in the Output column of the Output table à press the Enter key à the ZRD0 output row is automatically populated with the appropriate information.

D.4.5.     Click the Communication method icon to bring up the Printing information screen of the Output page.

D.4.6.     Enter the printer ID (LOCL) in the Logical destination field.

D.4.7.     Tick the 'Print immediately' and 'Release after output' checkboxes.

D.4.8.     Click the Back button to return to the main Output screen.

D.4.9.     Click the Further data icon at the top of the screen.

D.4.10. Select 'Send immediately (when saving the application)' from the Dispatch time dropdown menu.

D.4.11. Click the Back button to return to the main Output page and click the Save button to initiate invoice printing.

D.4.12. The printer dialogue box will appear. Choose the appropriate printer and print the invoice.

Back to top

E.      Invoice processing of posted documents coming from Real Estate (RE)

The followings highlight the steps to process customer invoice in the Financial Accounting (FI) module where the posted documents are coming from Real Estate (RE) interface. Refer to section 3.3.2 of Finance Manual Chapter on Leases for more details.

·               The Lease Processor has created Real Estate contract and included all relevant information such as: General contract data (contact name, validity dates, conditions, tenant details, etc) and Financial information (posting parameters, payment frequency, etc).

·               The Lease Approver has approved and activated the contract.

·               The Lease Processor successfully simulates the periodic postings.

·               In Umoja ECC, the Financial Accounting Senior User can also simulate periodic postings to check an error once a lease contract has been approved. If no errors, the Financial Accounting Senior User will execute and create a receivable in the tenant's customer account.

Note: The process can only be commenced once.

E.1.      Generate invoice / Transaction Code: RERAIV

E.1.1.      Enter RERAIV in the Command field or click the SAP menu and select the Accounting --> Flexible Real Estate Management --> Accounting --> Invoices --> Create Invoices menu item à press Enter.

E.1.2.      In the Contract Selection section, enter details in the following fields:

·         Company Code: 1000.

·         Contract number from and to fields: This allows you to create invoices for multiple contracts by entering a range of contract numbers.

E.1.3.      In the Selection of Invoice Items section, enter details in the following fields:

·         Selection Type: Always select 'Only Items from FI Documents'.

·         Due Period: The dates that correspond with the conditions.

Note: These fields specify whether or not to pick up items on the invoice that are the result of the periodic posting run execution and/or cash flow forecast in the contract.

E.1.4.      In the Invoice Creation section, enter details in the following fields:

·         Execution Mode: Always select 'Simulation' to review the invoice before executing

·         Title: The title of the run

·         Summarize Invoices: Always select 'Per Contract'

E.1.5.      Click the Execute icon or go to Program --> Execute à the Invoice Overview screen displays.

E.1.6.      Select an invoice and click the Preview button to display PDF copy of the invoice.

E.1.7.      Review the invoice to ensure that it is correct.

E.1.8.      Click on the Back icon twice to revert to the Create Invoices for Rent screen.

E.1.9.      In the Invoice Creation section, select 'Update Run' from the dropdown menu in the Execution Mode field.

E.1.10.  Click Execute icon.

The 'Update Run' creates an invoice with automatically generated number.

E.1.11.  Double click on the selected invoice to display the PDF invoice to be sent to the customer.

F.       Invoice processing of posted documents coming from Grant Management (GM) - Refer to section 4.3.3.7 of the Finance Manual Chapter on Revenue from Non-Exchange Transactions.

G.     Insert the Acct Determination Rules for Travel Management (TM) to generate postings (most likely custom program).

Back to top

3.2.1.4  Workflow to AR Approver

This workflow is only applicable to manual invoice or credit note parked in Financial Accounting. For assessed contributions, approval or rejection is processed in Assessment Cockpit while AR transactions processed in upstream modules like Sales & Distribution, Flexible Real Estate Management, Travel Management and Grants Management are already validated in each module where the resulting financial postings are passed on to FI-AR and GL.

Based on the organizational unit e.g. business area and/ or cost center, enterprise roles assigned, and financial authority delegated to workflow approvers, the parked invoice or credit memo is routed to their inbox for approval or rejection.

·               The approval of parked invoice or credit memo automatically posts the transaction in FI-AR module and updates the GL.

·               The rejection of parked invoice or credit memo automatically sends a notification message to the business user who parked the invoice or credit memo.

The business user can track the status of parked invoice or credit memo by using the workflow overview in menu list of display document screen.

H.     Process steps for approval / Transaction Code: SBWP

H.1.     Enter SBWP in the Command field to access the Business Workplace screen.

H.2.     Click the Enter icon.

H.3.     Navigate to Inbox à Workflow à Grouped according to task à AR Document -Approving Agent.

H.4.     Click the document to review and approve. The parked document number will appear at the lower part of the screen. The Company Code (1000) and year (2013) will be added to the document number in front and at the end respectively.

H.5.     The document will open with its attachments. Review it to ensure key data like Customer account, Reference, Amount, GL account etc. are correctly inputted.

H.6.     When the review is completed, click on the Back icon to return to the workplace.

H.7.     Double click on document title to go to Decision Options.

H.8.     Once the document title is double clicked, the user claims the document. As a result, it becomes unavailable to any other user named in the Workflow Table.

H.9.     Three actions are possible:

·         Cancel-If the Approver wants to return the document to workflow so that another user can take action on it.

·         Refuse-if the Approver is not satisfied with the document and wants to return it to the Transaction Entry Agent (originator). A reason must be given.

·         Approve-if the Approver is satisfied with the document and wants to post it.

3.2.1.5  Assessment Letters

Assessment letters for Member States and Non-Member States will be generated from Assessment Cockpit.

This section details the steps required to prepare a standard letter of assessment in Umoja for the regular budget, peacekeeping operations, international tribunals, peacekeeping credits for inactive funds and non-member states. Prior to the generation of assessment letters, the related assessment must be approved in the member state cockpit.

This section covers the following scenarios:

·               Generation of assessment letters for the regular budget, with and without working capital amounts, with and without local currency requirements;

·               Generation of assessment letters for peacekeeping operations and the return of peacekeeping credits with the inclusion of the translation template;

·               Generation of assessment letters for the international tribunals with a distinction for the International Criminal Tribunal for Yugoslavia and the euro currency option with the inclusion of the translation template;

·               Generation of assessment letters for the assessment of non-member states.

Back to top

I.        Preparing an Assessment Letter / Transaction Code: ZARASSESSLTR

I.1.        Enter the T-code ZARASSESSLTR in the Command Field

I.2.        Click the Enter icon à the Custom Assessment Letter Print Program is displayed

I.3.        In the Letter Type field, enter the letter type related to the assessment which needs to be prepared. Current options are shown below and can be accessed by clicking on the icon

Please note that all three Tribunals are available using the ICT letter type.

I.4.        Once letter type has been selected, hit Enter

I.5.        Enter the Reference related to the assessment you are trying to print and hit enter. The Fund field should populate and this should be validated against the assessment being printed.

Please note that the Reference field is what ties different assessments together e.g. the regular budget and adjustment to working capital. The reference is determined outside of the system and must be communicated prior to the preparation of the assessment letters.

Within the Reference selection, Umoja will provide a list of all uploaded files which relate to the assessment type chosen. This screen will also show the mandate beginning and end, fund, issue date and doc ID.

Supplementary information regarding Letter Types

Please note that there are some enhancements which are determined by the Letter Type chosen.

J.        Letter Type RBU

J.1.        If RBU is chosen, the screen changes to allow for Local Currency Requirements and Working Capital if applicable.

J.2.        In the case of the regular budget assessment letter to be issued, once the RBU Letter Type is selected, hit the Enter button. An additional selection screen pops up with Local Currency Requirements and Working Capital Applicable.

J.3.        The Local Currency Requirements should be used for those member states who are allowed to make their contributions to the regular budget in their local currency. These member states can be selected as a single value or multiple values.

J.4.        In the year where there is an adjustment for working capital, the check box next to Working Capital Applicable must be selected and the Biennium years must be filled in. e.g. 2016 to 2017.

Note: If there is no working capital adjustment, this box does not need to be checked.

K.      Letter Type PKA

K.1.      In the case of the peacekeeping assessment letter to be issued, once the PKA Letter Type is selected, hit the Enter button. An additional selection is displayed for the Translation Template.

K.2.      In the case of PKA, another action is required to finalize the letter preparation, the Translation Template.

K.3.      The Translation Template contains the following columns:

The fields to be modified are:

·         Reference - which is the unique identifier which links the related assessment schedules together;

·         Legislative Basis, Security Resolution, Mandate beg-end: updated based on the assessment being issued.

K.4.      Once the template has been finalized, select all from the word Language - across and down, copy, open Notepad and paste to notepad. Save the file and close.

K.5.      Return to Umoja, and in the Translation Template field, click on the Translation Template field, then select and search for the location of the .txt file. Choose the file and then click on the Execute button .

L.       Letter Type ICT

In the case of the international tribunals, the ICT assessment Letter Type is to be used. Please note as of September 2015, there are three criminal tribunals (ICTY, ICTR and IRMCT).

L.1.       Once the ICT Letter Type is selected, hit the Enter button. An additional selection is displayed for the Translation Template and the type of tribunal.

L.2.       Due to the option of member states to pay their contributions to the International Criminal Tribunal for Yugoslavia (ICTY) in Euros to a Euro-currency denominated account, there is a separate letter version used for ICTY.

Back to top

M.   Letter Type PKC

M.1.   Letter Type PKC is used when credits are being returned to member states related to inactive/closed operations and when there is no accompanying assessment. Once the Letter Type is selected, hit Enter.

M.2.   Follow the steps above to select the Reference and validate the Fund. Upload Translation Template and Execute.

N.     Letter Type NME

N.1.     The Letter Type NME is to be used for letters related to non-member state assessments for the Regular Budget.

O.     Variants

O.1.     The Member State Assessment Letter screen also allows the issuer to issue letters for a specific member state or group of member states. There is also a variant which is customized according to the areas of responsibility of the Contributions Service User.

O.2.     This level of specification will generate letters only for those under the specified area of responsibility.

O.3.     Once all parameters have been included, select Execute .

O.4.     Depending on the number of assessment letters being generated, it may take a few moments. Once the letters are generated, navigate to Goto and select PDF Preview to obtain a pdf view.

O.5.     Review letters to confirm outstanding balance match accounting records. Refer to section A.6.6 of Finance Manual Chapter on Revenue of Non-Exchange Transactions.

Please note that the balance shown will include the new assessment and all credits. If verifying by column, review member state account balance and include/exclude new assessment as appropriate.

O.6.     If all information is accurate, save pdf file to shared location and print letters for signing. If discrepancies are found, investigate, resolve and re-run letters.

3.2.2        Incoming Payment Processing

This process follows the incoming payment processing from Cash Management; Daily Reconciliation of Bank Transactions and Incoming Payment Processing - Cheque and Cash. It involves the processing by the Accounts Receivable unit of all incoming receipts that have not been automatically applied to an open item by the system or that have not been manually applied by Treasury staff.

This process is applicable to all types of incoming payments. The process starts with payments received by Treasury and ends with the payments applied to customer accounts and invoices partially or/and totally cleared.

The business process steps outlined in incoming payment processing assumes that the AR business user will perform the following reconciliation and analysis where Cash Management was not successful in matching the incoming payments against open accounts receivable.

The following table summarizes the possible scenarios of Incoming Payment Processing and their respective process steps in Umoja.

 

3.2.2.1  Customer account is identified along with specific invoice to be cleared

·               If the incoming payment received through the Cashier, where BP or customer account is identified along with specific invoice to be applied, use transaction code FBCJ through Cash Journal. For detail business process steps, refer to section 3.2.7.4 of Finance Manual Chapter on Accounts Payable specific to receipt of cash/cheques from customer business transaction types in Cash Journal.

·               If the incoming payment received is through Electronic Fund Transfer (EFT), use transaction code FEBAN with credit to BP customer account.

Back to top

P.      Clearing incoming payment through EFT against customer BP account / Transaction Code: FEBAN

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

P.2.      Click on the Execute icon at the bottom right corner. This opens the Edit Bank Statement screen.

P.3.      Double-click the open item you intend to clear.

P.4.      Go to the menu, click Statement Items and select Post (can also be done via Ctrl + S or by right clicking and selecting Post Items). This opens the Post with Clearing Select open items screen.

P.5.      Enter the Customer's Account in the Account field.

P.6.      Enter 'D' in the Account Type field.

P.7.      Click the Back icon to go to the Post with Clearing Display Overview screen.

P.8.      In the Post with Clearing Display Overview screen take note of the following:

·         Doc Type: This is an Incoming Payment (DZ).

·         Reference: This is the number of the uploaded bank statement which carried this Incoming Payment.

·         Period: The posting date and period refer to the time the bank statement was uploaded.

·         Line 1: Automatically generated by the system, this is the debit entry to a GL account EFT-In. Hence posting key 40 (GL debit).

P.9.      To create the credit line, enter Posting Key 15(Customer Incoming Payment) in the PstKy field.

P.10.  Enter the Customer Number again in the Account field.

P.11.  Click Enter.

P.12.  In the Post with Clearing Correct Customer Item screen, enter information in the following fields:

·         Amount: .

·         Bus. Area:

·         Assignment: Enter the number of the AR document f.

·         Text: Description of the transaction.

P.13.  Click the More data button to input data in the Fund and Grant fields.

P.14.  In the navigation menu, click Document and click Simulate. The Post with Clearing Display Overview screen opens.

P.15.  Review the entries in the Post with Clearing Display Overview screen. Ensure that:

·         The credit line shows the desired Customer Account.

·         The sum of debits equals the sum of credits i.e. the balance is zero.

P.16.  Click the Post icon.

Note: Posting an incoming payment through FEBAN is not subject to workflow.

Back to top

P.17.  In the Command field type FEBAN and then click on Execute to return to the Edit Bank Statement screen.

P.18.  Double click on the Incoming Payment that was just applied to a Customer Account. It now displays a green status.

P.19.  Review the document number in Posting Area 2 (FB03 or double click the doc#).

The AR business user should drill down and reconcile the incoming payment received to attempt to identify the BP or customer account, if not successful the transaction will be temporarily be recognized in Unapplied Cash until new information becomes available to specifically reclassify the incoming payment to specific BP or customer account. A proforma entry is illustrated below:

PK	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Fund
40	11011016	Cash HQ New York JPMorgan USD Wire ACH EFT Incoming	69,000	USD	S101	64VQA
15	1XXXXXXXX*	BP or Customer account	(69,000)	USD	S101	64VQA

* The specific BP account number selected in data entry view determines the AR reconciliation account that will be pulled in accounting entry.

3.2.2.2  Customer account is not identified

·               If the incoming payment received where BP or customer account is not identified is through Cash Journal, use transaction code FBCJ. For detail business process steps, refer to section 3.2.7.4 of Finance Manual Chapter on Accounts Payable specific to receipt of cash/ cheques business transaction types in Cash Journal.

·               If the incoming payment received is through Electronic Fund Transfer (EFT), use transaction code FEBAN with credit to Unapplied Cash account (GL account 39201010).

For detailed steps on this process, refer to above steps P.1 through P.16 with the exception of step P.9 for the journal entry. Instead of credit to customer account or BP with posting key 15, it will be Posting Key 50 and credit to Unapplied Cash account (GL account 39201010).

A proforma entry is illustrated below:

PK	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Fund
40	11011019	Cash HQ New York JPMorgan USD Wire ACH EFT Unidentified	69,000	USD	S101	64VQA
50	39201010	Unapplied Cash	(69,000)	USD	S101	64VQA

 

3.2.2.3  Customer account is identified, no specific invoice can be cleared

·               If the incoming payment received where BP or customer account is identified but no specific invoice to be applied is through Cash Journal, use transaction code FBCJ. For detail business process steps, refer to section 3.2.7.4 of Finance Manual Chapter on Accounts Payable specific to receipt of cash/cheques from customer business transaction types in Cash Journal.

·               If the incoming payment received is through Electronic Fund Transfer (EFT), use transaction code FEBAN with credit to BP customer account.

Q.     Clearing incoming payment through EFT against customer BP account with no specific invoice to be cleared against / Transaction Code: FEBAN

For detailed steps on this process, refer to above steps P.1 through P.16 with the exception of step P.12, enter the number of the AR document in the Assignment field, as there is no document invoice reference, so there will be nothing to be entered in the assignment field.

The AR business user must correspond with Customer to match the incoming payment received against a specific invoice in the BP or customer open items. If not successful, the incoming payment will be temporarily recognized in BP or customer account as a credit and without specific application to open invoice. It will reduce the total outstanding balance of BP or customer account. Once the additional information becomes available to apply to a specific AR invoice, refer to section 3.2.2.5 for a follow-on process to clear the credit against open invoice within the BP or customer account. A proforma entry is illustrated below:

PK	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Fund
40	11011016	Cash HQ New York JPMorgan USD Wire ACH EFT Incoming	69,000	USD	S101	64VQA
15	1XXXXXXXX*	BP or Customer account	(69,000)	USD	S101	64VQA

* The specific BP account number selected in data entry view determines the AR reconciliation account that will be pulled in accounting entry.

3.2.2.4  Customer account and open invoice are subsequently identified

The AR business user will perform manual clearing of incoming payment that was temporarily posted in Unapplied Cash account (GL 39201010) against specific open AR invoice.

R.      Manual clearing of Unapplied Cash account GL against specific invoice / Transaction Code: F-28

R.1.      In the Command field, type F-28 and press Enter. This opens the Post Incoming Payments: Header Data screen.

R.2.      Enter the following fields:

Header Data:

·         Document Date:

·         Posting Date:

·         Document Type: DZ (default value)

·         Document Currency: USD

·         Reference: Invoice #XXXXXXXX

·         Doc.Header Text: freely definable

·         Clearing text: freely definable

Bank data:

·         Account: 39201010 (GL account for Unapplied Cash account)-Debit

·         Business Area: S101

·         Amount: 4476,44

·         Value Date:

·         Text: freely definable

Open item selection (BP Data):

·         Account: 111XXXXXXXX (BP or Customer account)-Credit

·         Account Type: D (Customer)

·         Standard OIs (Open Items): activate

R.3.      Select Process open items button.

R.4.      At the Post Incoming Payments Process Open Items screen select Partial Pmt tab. This opens the Post Incoming Payments Enter partial payments screen.

R.5.      The system selects all open items by default. De-select (double click) each amount except the one intended to apply the incoming payment to. As the items are de-selected this reduces the Payment Amount (narrows the difference between Amount entered and Assigned).

Back to top

R.6.      If the incoming payment amount is less than the specific open invoice amount, the AR business user has two options:

·         Write-off the difference by selecting the Charge off diff. button and assign it to write off account, if it is within the tolerance and authorization of the user; or

·         Record a 'partial payment' meaning that the difference between invoice amount and the payment amount will remain on the invoice and the invoice will remain open with the same terms of payment (e.g. same due date).

R.7.      Go to Documents button and select Simulate General Ledger to review the proforma entry:

The AR business user will apply the incoming payment to specific BP or customer account and debit to Unapplied Cash account. A proforma entry is illustrated below:

PK	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Fund
40	39201010	Unapplied Cash	4476	USD	S101	64VQA
15	11140000000*	BP or Customer account	(4476)	USD	P003	20OLA
40	11701010**	CSH Main Pool	4476	USD	P003	20OLA
50	11701010**	CSH Main Pool	(4476)	USD	S101	64VQA

* The specific BP account number selected in data entry view determines the AR reconciliation account that will be pulled in accounting entry.

** If the transaction crosses either business areas and/or funds, automatic postings to recognize the due to/ due from will be created by the system.

R.8.      Select the Save icon to post the manual application of incoming payment against open AR invoice. The posting is not subject to workflow.

3.2.2.5  Reconcile incoming payments in customer accounts sub-ledger

The posting of clearing document will not have financial impact to GL as this is merely offsetting of credits against open debits within the Sub-ledger account of BP or Customer.

S.       Reconcile credits in customer accounts sub-ledger against open invoices / Transaction Code: F-32

S.1.       In the Command field enter F-32 and press Enter. This opens the Clear Customer: Header Data screen.

S.2.       Enter the customer's number in the Account field.

S.3.       Select 'Amount' in the Additional Selections section.

S.4.       Click on Process open items. This opens the Clear Customer Enter selection criteria screen.

S.5.       Type the amount of the Credit Memo you intend to allocate to the Customer Invoice in the From and To fields of the Amount (USD) section.

S.6.       Click on Process open items. This opens the Clear Customer Process open items screen. The system displays all documents with the amount (selected by default) specified.

S.7.       De-select (double click) all the amounts you don't intend to allocate in this transaction. Only the debit (DR) and credit (DG) docs should remain selected.

S.8.       Check that the Amount entered and Assigned both have a zero value, such that Not assigned = zero as well.

S.9.       From the navigation menu click Document, then Simulate. This opens the Clear Customer Display Overview screen.

S.10.   Note the following:

·         Doc Type: DC-Document Clearing.

·         Both posting keys relate to the AR Sub-ledger since the clearing is being done there: 07 is Debit -Other Clearing and 17 is Credit -Other Clearing.

·         The sum of debits equals the sum of credits.

S.11.   Click on the Save icon to post the transaction. The posting message displays at the bottom of the screen.

Back to top

3.2.2.6  Incoming payment posted to Unapplied Cash was received in error

If this scenario were to happen, use transaction code FV60 to recognize the payable to the entity entitled to incoming payment received. Refer to step above i.e. the BP account or customer is not known at the time of receipt of payment.

PK	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Fund
40	39201010	Unapplied Cash	100	USD	S101	64VQA
31	1XXXXXXXXX*	BP account with vendor role	(100)	USD

* The specific BP account number selected in data entry view determines the AR reconciliation account that will be pulled in accounting entry.

For detailed process steps refer to section 3.2.2 of Finance Manual Chapter on Accounts Payable's Invoice Processing without PO.

3.2.2.7  Issuance of CRV (Cash Receipt Voucher) for assessed contributions

Please refer to the Revenue from Non-Exchange Transactions Chapter, section 4.3.3.7 for the detail process on the issuance of a Cash Receipt Voucher.

3.2.3        Dunning Process

The dunning process creates reminders or notices automatically based on the scenarios defined in the Umoja system. The dunning functionality proposes overdue items based on dunning interval, grace days and dunning level.

The Umoja solution relies on a very light SAP AR dunning functionality using dunning level 1 or reminder letter. The Umoja Solution includes review of AR open items and the periodical preparation of the dunning proposal, analysis of the dunning proposal with the purpose of selecting the customers, to whom the dunning letters will be sent, and creating and sending dunning letters to those customers.

The following process steps are applicable to Collections:

T.      Generate AR Reports for review / Transaction Code: FBL5N or ZARFBL5N

The custom AR reports provide customer line item display per Fund. The report can also be restricted by Fund, Business Area, Segment, Grant based the on the parameters entered by the business user. Special GL transactions can also be included or excluded as desired by the business user.

T-code: FBL5N

T-code: ZARFBL5N

T.1.      Enter T-code ZARFBL5N in the Command field to review open receivables.

T.2.      In the Customer Selection section, enter the customer number in the Customer Account field. If the intention is to generate a report of all open AR balances as of a certain date, leave the field blank and filter the output by entering the specific Business Area, Fund or Grant.

T.3.      Under the Status section, depending on the items for review, select Open items, Cleared items or All items if the intention is to view all items including cleared items.

T.4.      In the Type section:

·         Tick Normal items for receivables that are recorded to the reconciliation account without special GL indicators.

·         Tick Special G/L transactions for receivables recorded to alternative reconciliation account with special GL indicators.

·         Tick Noted items to include memo entries that are created when advance payments are requested in the sales order.

·         Tick Parked items to include documents pending approval in workflow.

·         Tick Vendor items to include payable items to customers who are also vendors.

T.5.      Select Execute button to run the report.

Note: Open items for all customers are displayed with a red ball status. When the items are cleared, the ball will turn to green.

Back to top

U.     Run the dunning program / Transaction Code: F150

U.1.     Enter:

·         Run On: date YYYY-MM-DD (required field)

·         Identification: ID JMP01 (required field)

U.2.     Select Parameters tab and enter the values in following fields:

·         Dunning date: Required field

·         Document posted up to: Required field

·         Company Code: 1000

·         Account Restrictions: Customer account range 11XXXXXXXX - 11XXXXXXXX

U.3.     Save values entered in Parameters tab and go back to Status tab.

U.4.     Select Schedule dunning run.

U.5.     Select Refresh icon to check if the dunning selection is complete.

U.6.     Select the Dunning List button to review the dunning proposal.

U.7.     Select the Sample Print out button to print the dunning letters.

V.      Send the dunning letters to BP or Customers/ Manual.

3.3            Subsequent Measurement - Write Offs and Allowance

The write-off process at the UN will be triggered by the need to determine whether the bad debt should be written-off. It will end with either writing-off the debt or continuing the effort to collect it. The write-off process will start when there is an open receivable that is past due and accounts receivable is not able to collect it in spite of all the possible collection efforts. The write-off amount must be reviewed and approved based on the authorization limit. Once the amount is approved for write-off, the accounts receivable department must write off the receivable by using the write off functionality within AR module.

United Nations policy for impairment of contribution receivable:

Based on historical assessment, recognition patterns and no anticipated changes to the collection pattern the UN approach for impairment of receivable / allowance for doubtful accounts as per in the IPSAS policy framework is as follows:

·               Assessed contributions receivable:

o      Assessed contributions receivable from Member States:

    Receivables from Member States that are subject to the Charter of the United Nations Article 19 General Assembly voting rights restriction due to arrears equaling or exceeding the amount of the contributions due from it for the preceding two full years and that are past due in excess of two years: 100 per cent allowance;

    Receivables that are past due in excess of two years for which the General Assembly has granted special treatment as regards payment: United Nations Emergency Force (UNEF), United Nations Operation in the Congo (ONUC), unpaid assessed contributions by People's Republic of China which were transferred to a special account pursuant to General Assembly resolution 36/116 A, former Yugoslavia: 100 per cent allowance;

    Receivables that are past due in excess of two years for which Member States have specifically contested the balance: 100 per cent allowance; (the two year time period is to allow for potentially resolving the contested matter); any contested amount outstanding for less than two years will be disclosed in the Notes to the Financial Statements;

    Assessed contributions receivable that are past due in excess of two years related to peacekeeping missions that have been closed over two years: 100 per cent allowance; and

    For receivables with approved payment plans, no allowance will be established, rather disclosure will be made where necessary.

o      Assessed contribution receivable from Non-member States: Similar to Member States.

·               Voluntary Contributions receivables, trade receivables and other receivables:

o      Specific identification - Provisioning will first go through specific identification of accounts receivable.

o      Aging: The policy guidance is 25% allowance for receivables outstanding longer than 12 months, 60% for receivables outstanding longer than 24 months and 100% for receivables outstanding longer than 36 months.

Decisions for write-offs are considered at management level, or in the case of assessed or voluntary contributions from Member States - at the General Assembly level or Executive Body level, as appropriate. Accordingly a receivable balance should not be written-off unless appropriate approvals are in place.

This section explains the write-off process including requests for blocking customer and changing credit terms on the customer profile. An independent but related process of establishing general allowance for bad debt is also included on this process map. It is important to separate write offs from Allowance for Doubtful Accounts (AFDA). In Umoja, AFDA are recorded at the General Ledger level while Write-Offs are recorded at the Accounts Receivable sub-ledger level to clear the account receivable open item.

3.3.1        Allowance for Doubtful Accounts (AFDA)

AFDA are estimates of the amount that will not be recovered and are statistical for budget purposes. They are recorded as accruals at the end of an accounting period and reversed at the beginning of the next period.

The following process steps are applicable to AFDA:

W.   Generate AR Reports for review / Transaction Codes: ZARFBL5N and ZARAGING

The custom AR reports provide customer line item display per Fund as well as aging report. The report can also be restricted by Fund, Business Area, Segment, Grant based on the parameters entered by the business user. Special GL transactions can also be included or excluded as desired by the business user.

W.1.   Enter ZARFBL5N or ZARAGING in the Command field and press Enter.

T-code ZARFBL5N

T-code ZARAGING

Back to top

W.2.   Enter the values for:

·         Customer Range: 1XXXXXXXXX to 2XXXXXXXXX

·         Open items at key date: 2014-28-02

W.3.   For ZARAGING report to calculate the allowance of doubtful accounts per aging bucket, the end user must enter the % values in the selection parameters:

W.4.   Select Execute button.

Note: If AR transactions are posted using normal GL account then the aging should be calculated manually based on payment due date however from a practical perspective for non-material balances posting date can also be used.

X.      Determination of AFDA based on specific identification of uncollectible receivables / Transaction Code: FV50

At period end, perform analysis of AFDA recognized for the period under review against aging open items and other factors such as going concern, payment history of customers etc. Following are the steps to compute AFDA of a group of financial asset as at period end:

·         Financial asset that are considered to be individually significant should be assessed for allowance individually based on whether objective evidence of impairment exists;

·         Financial assets whether individually significant or not should be assessed for allowance if there is a known evidence of impairment as at reporting date;

·         All other contribution receivables that are not individually significant should be assessed for impairment collectively on a group basis as indicated below;

·         All contribution receivables that have been individually assessed for impairment, whether significant or not, but for which there is no objective evidence of impairment, are included within a group of receivables with similar credit risk characteristics and collectively assessed for impairment;

·         Contribution receivables that are individually assessed for impairment and for which an impairment loss is (or continues to be) recognized are not included in the collective assessment for impairment.

Example: Sample worksheet for allowance for assessed contributions receivable from member state calculated as per United Nations IPSAS Policy Framework

UNITED NATIONS
Assessment Aging Summary for assessed contributions receivable (Hypothetical numbers)
Country	Over Four Years	Over Three Years	Over Two Years	Over One Year	Less Than One Year	Total
A	137,110	1352	10,330	3,134	8,536	160,462
B	180,442	16,220	51,644	174,966	188,120	611,392
C	17,864	0	0	0	492,002	509,866
D	0	0	0	0	433,830	433,830
E	0	0	39,392	159,428	97,106	295,926
F	0	0	0	33,268	64,820	98,088
G	0	0	0	0	2,684,118	2,684,118
H	0	0	0	0	1992	1,992
I	0	0	0	0	0	0
J	0	0	0	0	0	0
K	0	0	0	0	25,642	25,642
L	0	0	0	0	267,726	267,726
M	1,126,368	1,391,182	4,879,490	5,140,502	3,123,306	15,660,848
N	132,342	92,784	156,992	149,472	76,792	608,382
O	0	0	0	0	313,686	313,686
Total	1,594,126	1,501,538	5,137,848	5,660,770	7,777,676	21,671,958
Less: Allowance for specifically contested amounts				149,472	38396	187,868
Balance	1,594,126	1,501,538	5,137,848	5,511,298	7,739,280	21,484,090
Allowance % based on aging analysis	100%	80%	60%	20%	0%
Less: Allowance	1,594,126	1,201,230	3,082,709	1,102,260	0	6,980,325
Net assessed contribution receivable	0	300,308	2,055,139	4,409,038	7,739,280	14,503,765

 

X.1.      Refer to values to be entered on specific fields as noted in incoming payment processing to be posted to Unapplied Cash account (section 3.2.2.2). For detailed process on creating a journal voucher using T-code FV50 refer to section 3.2.1 of Finance Manual Chapter on General Ledger.

X.2.      Go to Documents button and select Simulate General Ledger to review the proforma entry:

If based on analysis performed additional amount of AFDA is required, the following proforma entry will be created as parked document:

PK	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Cost Center	Fund
40	79611016	AFDA Assessed Contrib Govt Member St	100	USD	P003	10068	20OLA
50	13101016	AR Assessed Mmbr St AFDA Man	(100)	USD	P003	10068	20OLA

 

If the current amount of AFDA is more than what is required for the period under review, the following entry will be created as parked document.

PK	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Cost Center	Fund
50	79611016	AFDA Assessed Contrib Govt Member St	(100)	USD	P003	10068	20OLA
40	13101016	AR Assessed Mmbr St AFDA Man	100	USD	P003	10068	20OLA

 

X.3.      Select Save as completed button to release the parked journal entry to workflow.

Y.      Workflow to AR Approver / Transaction Code: SBWP

Based on the organizational unit e.g. business area and/ or cost center, enterprise roles assigned, and financial authority delegated to workflow approvers, the parked invoice or credit memo is routed to their inbox for approval or rejection. Refer to section 3.2.1.4 for detail instructions.

Z.      Create reversal document of AFDA / Transaction Code: FB08

AFDA recorded at the end of period should be reversed at the beginning of next period.

Z.1.      Enter FB08 in the Command field and hit Enter to access the Reverse Document screen.

Z.2.      Enter values on:

·         Document Details: Document Number 11XXXXXXXX

·         Company Code: 1000

·         Fiscal Year: 20XX

Z.3.      Enter values on Specifications for Reverse Posting section:

·         Reversal Reason: 01 Reversal in Current Period

·         Posting Date: YYYY/MM/DD

·         PostingPeriod: 01

Z.4.      Select Display before reversal button to review the reversing entry.

Z.5.      Select Save icon to post the reversal entry.

Back to top

3.3.2        Write Off of Receivable

Write off of specific open AR invoice deemed to be uncollectible and approved for write off by Authorized Personnel.

AA. Write off of an open AR invoice / Transaction Code: F-63

AA.1. Enter F-63 in the Command field.

AA.2. Click the Enter icon. The Park Document: Document Header page displays.

AA.3. In the Header section, enter details in the following fields:

·         Document Date: Date write off was approved

·         Posting Date: Current date

·         Doc. Type: DC

·         Reference: Reference of authorizing document

AA.4. Select the checkbox in the Control table.

AA.5. Enter the following information in the First line item section:

·         PstKy (Posting Key): 17

·         Account: Customer Account Number

AA.6. Press the Enter key.

AA.7. In the Item 1/Other clearing/17 section, enter information in the following fields:

·         Amount

·         Bus. Area

·         Assignment: # of original doc

·         Text: Reference

AA.8. In the Next line item section at the bottom of the screen, enter information in the following fields:

·         Posting Key: 40

·         Account: G/L Write-off Account Number

There are a total of six write-off accounts in Umoja:

AA.9. Press the Enter key à the Park Document: Enter G/L Account Item screen displays.

AA.10.   In the Item 2/ Debit entry / 40 section, enter information in the following fields:

·         Amount

·         Business Area

·         Cost Center

·         Text

AA.11.   Click the More button à the Coding Block screen appears.

AA.12.   Enter required details in the Fund and Grant fields.

AA.13.   Click the Enter icon.

AA.14.   Click the Document Overview icon à the Park Document: Overview screen appears.

The first line with Posting Key 17 will credit the Customer account and the second line will record the write off Expense.

AA.15.   Click the Document tab.

AA.16.   Click Complete.

The proforma entry:

PK	GL Acct	GL Acct Name	Amount Dr / (Cr)	Document Currency	Bus Area	Cost Center	Fund
40	13101016**	AR Assessed Mmbr St AFDA Man	2893	USD	P003		20OLA
11	1111000014*	BP or Customer account	(2893)	USD	P003		20OLA

* The specific BP account number selected in data entry view determines the AR reconciliation account that will be pulled in accounting entry.

** If the specific open AR invoice to be written off is not previously provided an allowance for doubtful account (AFDA), the write off will be posted directly to expense account.

PK	GL Acct	GL Acct Name	Amount	Document Currency	Bus Area	Cost Center	Fund
40	7965XXXX	Write Off account	2893	USD	P003	10068	20OLA

 

AA.17.   Select Save as completed button to release the parked journal entry to workflow.

AA.18.   Refer to section 3.2.1.4 for Workflow Approval.

3.3.3        Block or Change Credit Limit

These two functions can only be executed after the Financial Accounting Approver approves the proposal for blocking or changing the credit limit of customer with long outstanding balances put forward by the AR user.

BB. Request Master Data Maintenance (MDM) to block or change credit limit of Customer account with outstanding and aging open items / Transaction Code: BP

BB.1. Enter transaction code BP in the Command field and hit Enter.

BB.2. Enter BP customer account in BP Number field and hit Enter.

BB.3. Go to Display in BP role field and select the BP role e.g. UN Customer.

BB.4. Select the Company Code view and go to Customer: Status tab.

BB.5. Click the display/change icon to activate the change mode.

BB.6. Activate the Posting Block; All Company Codes.

BB.7. Select the Save icon to save changes.

All requests to change BP by AR business user will be forwarded to the Master Data Maintenance (MDM) team to evaluate and perform due diligence on the impact on subsequent transactions in the same business area and across other business areas within company code 1000.

Back to top

December, 2016