1. M Smith/N Gordon August 2010 SGUL Chart of Accounts SGUL Agresso Chart of Accounts 1

2. M Smith/N Gordon August 2010 SGUL Chart of Accounts Introduction This is an introduction to the new structures and components we’ve designed into Agresso. Its purpose is to explain what we’ve done and why, and to provide some context and reference material to complement training The term Chart of Accounts simply means the collection of accounts, projects, rules and relationships that we use to define and analyse SGUL’s finances There are major changes from Sage, to: –Make querying and reporting easier, more logical and more flexible. –Allow us to adapt the structure of Agresso to changes in the University –Support better financial management and procurement processes Ultimately, the point of this is to enable us to get a better handle on our finances, and so be able to make better decisions 2

3. M Smith/N Gordon August 2010 SGUL Chart of Accounts Introduction - terms The basic unit of activity in Agresso is the sub-project; in effect, this is who is spending money or receiving income. Agresso sub-projects are the equivalent of Sage projects. Each project that was in Sage has an equivalent sub-project in Agresso. Agresso account codes define how we analyse the products or services being bought or delivered; the equivalent in Sage is the expense or income code. We have drastically redesigned this set of codes to provide a more accurate and relevant picture of how we spend our money and where our income comes from. Agresso product codes define what product or service we are buying or delivering; again, we have made some major changes to the codes and how they’re grouped to make a more rational view of what we buy or offer. Product codes have been linked to account codes, so when we purchase or invoice something, Agresso can automatically fill in the relevant analysis code. Attributes are descriptive data, used to categorise and analyse information. Posting attributes affect how transactions are recorded in the accounts; reporting attributes are used more widely to help organise information and in reports and queries, but do not appear in the formal accounts. Relations are connections within Agresso. Later in this note are examples of relations and both types of attribute The core components of any transaction in Agresso are the sub-project being charged and account code for the transaction; almost everything else can be derived from these. 3

4. M Smith/N Gordon August 2010 SGUL Chart of Accounts SGUL structure in Agresso Sub-projects are the activities themselves; they include all SGUL activities – research projects, teaching, administrative and IT projects Activities within cost centres are grouped into projects; projects are reporting attributes of sub-projects Cost centres are the basic financial management unit at SGUL; they are posting attributes of sub-projects Research Centres are cost centres The University is split into divisions, including the 3 academic divisions and divisions for Administration, Estates, Registry etc. Divisions are a reporting attribute of sub-projects These are the structural components we’ve built into Agresso and how they’re related. There is more detail about how the relationships are implemented later in this document SGULDivision Research Centre Project Sub- project Project Sub- project Cost Centre Division Cost Centre Project Sub- project 4

5. M Smith/N Gordon August 2010 SGUL Chart of Accounts Cost Centres, Divisions, Projects and Sub-projects Cost centres are the basic “business unit” for SGUL; they are directly connected to sub-projects as posting attributes. This means that, when a transaction is recorded against a sub-project, the relevant cost centre is automatically added to the transaction information (the posting string – see later). The cost centre is a posting attribute of the because it’s our key business unit Divisions are reporting attributes of cost centres, which keeps them connected. If we needed to move a cost centre between divisions, we would simply change the relevant reporting attribute for that cost centre and everything else would follow. Projects are reporting attributes of sub-projects. This allows us to deal with projects that span cost centres or divisions: we can split a project into sub-projects, one sub-project for each cost centre or division. A common example is a teaching course, in which different modules are delivered in different divisions. Each division/cost centre needs to see the data for its sub-projects, and the overall project ‘owners’ need to see the complete picture for the course There’s a full explanation of how this works for teaching courses in Appendix 4. These connections are built-in, so Agresso maintains them. Hence, simply by recording the sub-project and account code, we get the totals/summaries for projects, cost centres and divisions 5

6. M Smith/N Gordon August 2010 SGUL Chart of Accounts Account Codes Account codes are our vehicle for analysing spend and income Every transaction is recorded against an account code (equivalent to Sage expense and income codes) We have substantially revised and added to the range of codes available to provide better analysis The codes used for recording income and expenditure are 3-digit numeric. There are some alphanumeric codes used for analysis on the balance sheet. A conversion chart of old Sage expense/income codes to new Agresso account codes is available separately Account codes are linked to other parts of Agresso via relations and account rules (see later). One key link is to product and service codes: this means that, when raising a requisition (or a sales order), Agresso can automatically complete the account code, based on the product or service. This will reduce coding mistakes, and provide more consistent analysis. Account rules, described further below allow more complex relations and help to reduce the amount of information we have to enter manually Finally, we use relations to group and organise account codes for reporting. It’s important to note that the codes themselves don’t mean anything – they’re just numbers in a sequence. If we create new ones, we’ll just add them to the list. The meaning comes from the relations we use to connect account codes to other information. 6

7. M Smith/N Gordon August 2010 SGUL Chart of Accounts Sub project codes Sub-projects are the equivalent of Sage project codes (the codes that began with R, H, D etc). Sub-projects define where the transaction is taking place; they are the lowest level of ‘ownership’ in Agresso. Sub-projects are the second most fundamental part of the posting string and for most transactions are the only other entry required in conjunction with the account code. Like account codes, sub-project codes don’t mean anything; they are simply numbers. Their meaning comes from how they are related to projects and cost centres. Where we used to use a prefix to identify the kind of project, we now use a reporting attribute. Sub-projects are always part of a project. We use the parent project as a way of aggregating information (where a project has several sub-projects) and allowing us to record more information about the activity. Project codes are 5-digit numbers, and are allocated in sequence. Sub-project codes consist of the parent project code plus a hyphen and 2 digits, e.g 12345-12. In many cases, a project has only one sub-project; although this seems like unnecessary duplication, it still makes sense, especially for research projects, where having the two levels allows us to organise information about funders, customers, collaborators etc 7

8. M Smith/N Gordon August 2010 SGUL Chart of Accounts Project and sub-project information All the information about projects and sub-projects is held in a master file, or in a relation to data elsewhere, and is set up when the project is created. The master files contain all the standing data needed to manage the project Master file information includes, apart from a name and description for the project: its type, who is responsible (the PI or other budgetholder), the customer and/or funder, start and end dates. Customer and budgetholder information is built on relations to other master files in Agresso. Where the project is a research project, the budgetholder will normally be a PI. Project/sub-project information can also include billing information (allowing automatic generation of invoices) A list of projects, with a mapping to old Sage projects, is available separately 8

9. M Smith/N Gordon August 2010 SGUL Chart of Accounts Transactions and the posting string The collection of information that has to be recorded for a transaction is called the posting string. In Agresso, the posting string has up to 8 segments (called categories). Some have to be entered by the user, and some can be filled in automatically. Which is which is determined by 2 factors – the account code, and account rules. The account rules also determine what information goes into each of the 8 categories; some categories can be used for different types of data, depending on the account rule. Which account rule is used is determined by the transaction type, which in turn is determined by what you’re doing. For example, if the transaction type is a student tuition fees payment, the attached account rule ensures that category 5 holds the academic year; for any other transaction type, Category 5 isn’t used. The diagram in Appendix 1 illustrates the posting string The essential point, shown in the diagram, is that the only items of data that are always needed are the account code and the sub-project code: everything else can be derived using account rules, attributes and relations. 9

10. M Smith/N Gordon August 2010 SGUL Chart of Accounts Account Code Category 1 Cost Centre Category 2 Project Category 3 Further Info: Res no. Asset no Building Endowment Student Sp Category 4 Sub Project Category 7 Analysis (Time Recording) Not used phase 1 Category 6 Further Info. FAPT FDT Pay Comp Category 5 Further Info. Academic Year Account Rules Division (Reporting Attribute of Cost Centre) Appendix 1: Agresso posting string, and capturing data Always Required Auto Populated Account Rules Additional Info. Not Used Colour Legend 10

11. M Smith/N Gordon August 2010 SGUL Chart of Accounts Appendix 2: Posting string additional segments/category fields Segments (Category fields) 3,5 & 6 have been set up to capture further information, in addition to account code, sub project and cost centre. Category 7 is used in most Agresso applications for time recording. SGUL will not be using this segment for phase 1 go live but it has been kept free for possible future use in this area. Categories 3,5 & 6 capture additional information related to specific areas of activity. Payroll and expenses for example need to capture the resource (employee) number in category 3 and the pay component in category 6. Estates transactions will need a building number in category 3. Student fees will require data for academic year in category 5, sponsor in category 3 and the ‘fee data type’ (FDT) in category 6. The latter gives coded information regarding items such as domicile and mode of study. It is possible to collect multiple attributes in a given segment / category so long as they are mutually exclusive e.g. on category 6 it will never be required to collect a fee data type and a fixed asset processing type in the same transaction. 11

12. M Smith/N Gordon August 2010 SGUL Chart of Accounts Appendix 3: Use of projects for aggregation of sub-projects Normally, projects and sub-projects are in a simple hierarchy Cost Centre (from Project) Project (from Sub Project) Sub Project Project (from Sub Project)Cost Centre (from Sub Project) At SGUL the link between the project and the cost centre has been replaced by a link from the sub project to the cost centre. This allows us to deal with activities that aren’t restricted to a single division or cost centre. The next Appendix describes how we use this to manage teaching course 12

13. M Smith/N Gordon August 2010 SGUL Chart of Accounts Appendix 4: application of project/sub-project/cost centre relationship for teaching courses For every case where a divisional section or research centre contributes to a course there will be a sub project for that contribution (called a module in the diagram). There might be more than one sub- project for a course (for example, where several different academics in a division are contributing, we might have a sub-project for each of them) The sub-project will capture any costs and receive income (via the resource allocation model). Spend will aggregate in two directions: –Up to the cost centre (via the posting attribute relationship) and thence to the division where the teaching contribution is being made –Up to the overall project (via the reporting attribute relationship), and thence to the cost centre and division where the course is hosted. For teaching courses, that will be Registry Income from HEFCE and tuition fees will be allocated a special sub-project of the course project in Registry. It will then be distributed to the module sub-projects, via the RAM, from where it will flow up to the cost centres and divisions in the same way as the costs. The goal is a view of how costs and income for teaching activities balance out. 13

14. M Smith/N Gordon August 2010 SGUL Chart of Accounts Appendix 4: application of project/sub-project/cost centre relationship for teaching courses Division X Module 2 (Sub Project) Divisional Section A (Cost Centre) Research Centre A (Cost Centre) Divisional Section B (Cost Centre) Research Centre B (Cost Centre) Module 4 (Sub Project) Module 3 (Sub Project)Module 1 (Sub Project) Course (Project) Division Y Income Flow of Income via RAM Sub Project Flow of Costs Project Cost CentreDivision 14