|
 |
|
Overview Grants
Contents
1. Introduction This paper provides a brief outline of how UCL uses the Oracle Grants Module, and it’s interaction with the General Ledger. The paper covers coding structures, budgets and funds checking, payroll interface, General Ledger links, burdening and invoicing. 2. Coding Structures UCL creates awards at application stage, using a five-digit number. There is no specific logic to the numbers, with new applications being given the next available number. Example 25123 Research into Ageing If an application is successful then a project code is set up using a four character alphanumeric coding. The first two characters are the standard departmental prefixes used in the accounting system at UCL. The third character is always alphabetical, with the fourth character being alphanumeric. There is no coding built into the last two characters. UCL has adopted a policy of each project only having one award. Occasionally one award may have more than one project. UCL anticipates moving to five-character codes in the future. Example FBA7 Research into Ageing (FB is the prefix for the Department of Anatomy) Each project will have a number of Tasks associated with it. UCL uses tasks to represent the sponsor budget categories that they have specified, such as Travel, Consumables, Equipment etc. The Task code is a five-character code representing an abbreviation of the sponsor budget description. The first character denotes the general type of budget (D for non-staff costs, S for staff costs and X for indirect costs). Example D-TRA Travel S-ACA Academic Salaries X-IND Indirect Costs The expenditure types are three-character codes, with the first character representing the general type (5 for salary, 6 for non-staff costs and indirect costs with 7 used for unusual items such as opening balances) and the next two characters being a sub-analysis of the type of expenditure. The expenditure types correspond to the analysis codes used in the General Ledger. In general any expenditure type can be used with any task. Example 5A0 Non-clinical academic salaries 6J2 Travel Overseas 3. Budgets and Funds Checking The sponsors budget is set up at a total level against the award at application stage, but is only linked to the project when the grant starts. There should be a budget for each task set up for the project. Although technically funds checking is set to on, all grants are set to funds checking – none. This means there are no warnings when purchase orders etc. result in expenditure exceeding the budget, either at task or at grant level. 4. Payroll Interface UCL runs a payroll from a different software supplier. Data is imported each month in a flat file from the payroll system showing the costs for the month for each employee charged to a grant, with the costs split into Basic Pay, Employer NI, Employer Superannuation, London Allowance and a couple of miscellaneous categories. The Transaction Import facility is used to load the data, with programs written in-house to load the data into the Import Tables. There are no salary commitments posted to the system. 5. General Ledger Links ( and see 10 below) There are three control accounts set up in the General Ledger for each academic department to gather the grants data. One is for Research Council Grants, one for UK Charity grants and one for all other grants/contracts. In addition there are control accounts by department for Unbilled Receivables and Unearned Income, as well as for indirect costs. Expenditure is interfaced each day as a standard process, but Revenue is not yet run automatically. Example FBZA Research Council Control Account for Dept of Anatomy Accounts Payable to GL Posting of expenditure from AP to GL is scheduled to occur once a day. Grant expenditure is coded to the Research Grant control accounts in this posting. AP to Grants A further interface from AP to Grants is required to post the AP details to the Grants ledger. This is not a scheduled process at present, but is run manually on a daily basis if possible. Non AP: Grants to GL Interfaced to GL on a regular manual basis Revenue: Revenue is generated on a monthly basis and interfaced to GL. This again is a manual process at present. 6. Burdening Currently UCL does not use the burdening functionality, partly because of historic problems with the system and partly because the indirect costs would be added to the same task as the salary costs (assuming the burdening is based on salary costs) whereas our sponsors require it against a separate indirect cost task. 7. Invoicing (and see 11 below) UCL currently operates a mixture of Cost-based and Event based invoices, split roughly half and half. Research Council grants and grants paid in foreign currency are Event based, whilst Wellcome Trust are cost-based. Invoices are generated manually for each project, rather than running general processes to generate all claims due. 8. Award, Project, Budget OGM is based around the idea that a sponsor will provide funding to an institution and information about this is held in the Award part of the system. The Award can then be used to provide funds for specific projects, where the expenditure will be recorded. An award can fund one or more projects, and conversely a project can be funded by more than one award. Awards are identified by a unique number. Projects are where data on expenditure is recorded, together with budget information. There is no facility to record income against projects, as a transaction. Projects have project numbers that are conventionally known as the grant code (e.g. EAA1). Awards are linked to specific projects by a process called Budget Baselining. This is the process whereby part or all of an award budget is allocated to a project. A project can never have a budget larger than the award budget. The normal processes would be to set up an award at application stage, and then set up a project if the application is successful, with an appropriate budget. For practical reasons the UCL has adopted a policy of never funding a project from more than one award. Occasionally an award may fund more then one project. 9. Expenditure, Revenue and Invoicing The idea behind the project part of OGM is that this will hold details of all expenditure that the project incurs, be it staff costs, purchases through the Purchase Ledger or Indirect Costs. The system introduces the concept of billable expenditure, being expenditure that can be recharged to the sponsor. In theory non-billable costs could be charged to the project, such as permanent staff time costs, direct costs that the sponsor will not fund etc, enabling the project to keep a track of the total cost of a grant. However we do not make any use of this facility. Revenue is defined in OGM as expenditure that can be recovered from the sponsor. Revenue and expenditure should be the same total on grants, as only chargeable expenditure is charged to projects (apart from overspends and disallowable costs). Invoicing represents the amount claimed from a sponsor, but this is not necessarily the same as revenue. A simple example may help to illustrate this point:- Sponsor A agrees to fund a grant costed at £100,000. The agreement says that A will only meet the direct costs incurred up to this amount. However they are prepared to pay £25,000 on signing the research agreement, £50,000 12 months later and the final amount when the project is completed. The project lasts for two years, incurring costs of £50,000 in each year. On signing the invoiced amount is £25,000 whilst Expenditure and Revenue is £0. After 12 months invoiced becomes £75,000 whilst Expenditure and Revenue is £50,000. After 24 months invoiced becomes £100,000 whilst Expenditure and Revenue is also £100,000. It is worth noting that Invoicing is something that happens against the award, and not the project. The system keeps track of what has happened against expenditure on projects by means of flags, to show whether expenditure items have had revenue raised on them, and if they have been invoiced. 10. Interaction with the General Ledger in more detail Data from the OGM needs to be interfaced to the General Ledger through various batch (as opposed to real-time) processes. The key data to be interfaced is Expenditure, Revenue and Invoices. There are a number of key General Ledger Accounts established for each department. If the departmental prefix was EA the codes established would be as follows:- For Expenditure EAZA For Research Council Grants EAZB For UK Charity Grants EAZC For all other research projects For Revenue the key account is EAZU For Invoices there are two key accounts, EAZU if the invoice relates to expenditure already incurred and EAZV if the invoicing is in advance of the expenditure. Using the example outlined above the following entries would be made:- On signing EAZC EAZU EAZV Raising invoice for initial payment Debit Sales Ledger Control Account £25,000 Credit EAZV (Unearned Income) (25,000) Balance 0 0 (25,000) At end of year one the following entries will have been made Expenditure of £50,000 incurred through Purchase Ledger Debit EAZC (Assume sponsor is company) 50,000 Credit Purchase Ledger Control Account £50,000 Generate Revenue based on expenditure. Credit EAZC 48A (50,000) Debit EAZV (Unearned Income) 25,000 Debit EAZU (Unbilled Receivables) 25,000 (Note part of the revenue is used to offset any balance on EAZV for this project, with the balance going to EAZU) Raise second invoice for £50,000 Debit Sales Ledger Control Account £50,000 Credit EAZU (Unbilled Receivables) (25,000) Credit EAZV (Unearned Income) (25,000) (Note part of the revenue is used to offset any balance on EAZU for this project, with the balance going to EAZV) Balance 0 0 (25,000) At end of year two the following entries will have been made Expenditure of £50,000 incurred through Purchase Ledger Debit EAZC £50,000 Credit Purchase Ledger Control Account £50,000 Generate Revenue based on expenditure. Credit EAZC (50,000) Debit EAZV (Unearned Income) 25,000 Debit EAZU (Unbilled Receivables) 25,000 Raise third invoice for £25,000 Debit Sales Ledger Control Account £25,000 Credit EAZU (Unbilled Receivables) (25,000) Balance 0 0 0 The balance on EAZV reflects invoices raised in advance of revenue, whilst the balance on EAZU represents revenue recoverable from a sponsor but not yet invoiced. 11. Types of Claims Invoice in more detail The system supports two systems of invoicing, called Event and Cost. Event based invoicing is, as the name suggests, the generation of invoices for set amounts at certain event stages (rather like milestones). The amount of the invoice is independent of expenditure or revenue of the project. A classic example of Event invoicing is with the Research Councils. They announce a series of profile payments due at certain times against each grant. These details are set up as Events on the system, with invoices generated automatically at the set time for the amount of each profile payments. The final Event of the grant is initially set for zero, then when the final claim is produced the event amount is altered to the outstanding balance on the grant. The example given in the previous sections is an example of an Event invoice. Cost invoices are based on the billable costs charged to the project for the appropriate time period. The amount of the invoice cannot be altered from the costs charged to the project. However it is possible to ‘hold’ specific items as non-billable if they are not to be charged to the sponsor, although currently it is not possible to hold part of an item. Cost claims go by the item date, not the date of posting. However if items are posted after a cost claim has been raised for the relevant period the system knows, by virtue of the invoicing flags, whether the item has been invoiced and will pick it up for the next invoice. A project is set up as either Cost or Event invoicing. Once the first invoice has been generated it is not possible to change the type of invoicing applicable to that project. Invoices are raised against the award, not the project. 12. Date Functionality There is considerable date functionality built into the system, to ensure that expenditure is only incurred during the active date of the project. The project dates cannot lie outside the award dates, but they can be for a smaller period. There is a small period of time after the end of a project when expenditure can be coded to it, to allow for the time lag in expenditure. Normally this is set to a period of 6 months after the end of the project. However purchase orders cannot be raised during this period. Also, invoices need an item date (which should generally be the actual invoice date) inside the live period of the project.
This page last modified June 3, 2011 by Web Editor |
|
|
+44 (0)20 7679 2000 - Copyright © 1999-2006 UCL