Chart of Accounts Committee
Final Report
May 12, 2000
Executive Summary:
The University of Delaware looks to replace the current financial system within two years. The implementation of PeopleSoft Human Resources software prompts the University to consider a new chart of accounts structure utilizing the conceptual framework of PeopleSoft Educational and Government Financials software. The Chart of Accounts committee was charged to develop a prototype for a new chart of accounts that will address the organizational, programmatic and reporting needs of users throughout the University by maximizing system value and responsiveness to user needs.
This document chronicles the efforts of the committee to conceptualize a new chart of accounts, to gather information from a broad spectrum of end users in the University community, and to analyze that information. The result is a prototype that blends the core requirements of the central administrative offices with the demand for flexibility from the end users. The request for this flexibility is envisioned as the ability to add complementary data to the core financial data in an efficient, effective computing environment. The committee supports the concept of user-defined fields, and considers this need so important, the recommendation will allocate a full chart field for this use.
The committee has recommended uses
for the chart fields as delivered by PeopleSoft for the chart of accounts.
It is important to note that not all fields will be required as input for
transactions. The number needed will vary.
| Field
Business Unit
Fund Account Program Class Department Project |
5
5 6 5 5 10 15 |
5
2 or as few as needed 6 To be decided 5 6 Variable |
Required by PS-1 to 5 - Values denote maximum (Corporate entry level) Major category definition Object code Function plus additional detail User defined Budget Unit Grant and Construction project reporting plus other users |
As important as the detail of the prototype, is the knowledge gained about the process of implementation. The committee drew insight from the experience of the Human Resources Implementation Team, as well as from the experience of many other schools, which outlines the implementation as an evolving process. During the implementation process, decisions should be made in the context of practice, needed changes should be recognized and new, critical information should be cycled back through the process for further decision making. Implementation is therefore an iterative process and more likely to be successful if approached as evolutionary, rather then revolutionary.
The focus groups have set the stage for user participation in the iterative process and further development of the PeopleSoft Financials software. A core group of identified "power users" and those with highly specialized needs should continue to be informed of progress and advancements developed by the Implementation Team through a series of occasional, but regular group meetings. This process of development and feedback from end users will help support a smooth campus wide implementation and will provide important background for end users prior to actual training on the product.
Furthermore, the success of the new chart of accounts will ultimately be determined not so much by the specific definitions and detail embedded in the chart of accounts, but by the strength, speed and responsiveness of the reporting mechanisms made available to the end users. PeopleSoft Financials software is only one facet of the balanced equation. Adequate technological resources (hardware, data warehouse structures, computer staff resources) and focused training for key personnel will also be crucial for implementation success.
The Process:
The Chart of Accounts Committee was formed by the Treasurer’s Office in July 1999 with representatives from nine university departments including the Treasurer’s Office, Provost Office, Budget Office, General Accounting, Auxiliaries, Facilities, Office of the Vice Provost for Research, and Academic Departments. Committee support included a consulting representative from KPMG Consulting. The goal of the committee was to develop a prototype chart of accounts within a system that would maximize its value and responsiveness to user needs while eliminating the need for separate (shadow) information systems and thus allow for easier and faster access to data. The committee would solicit and collect information through focus group meetings to design the prototype and fully assess users’ needs.
Through the fall of 1999, monthly planning meetings were held to develop and define the needs of the institution. The committee discussed the needs and wants that should be addressed with a new system and the likes and dislikes of the current system to assess what should be retained. Flexibility of the system and the ability to communicate easily with other sub systems in use across the University computing environment was a key factor for consideration.
Orientation to PeopleSoft Financials provided a perspective on a chart of account design that was very different from the current system. Discussion focused on the appropriate data elements needed for reporting that must be included in a new chart of accounts design. PeopleSoft representatives were available to demonstrate the financial modules and how they integrate with each other as well as with the newly released Contracts and Grants module. Web sites and documents from other universities were reviewed for suggestions for the new design.
Two sub-committees were formed in October 1999. The first sub-committee focused on the design structure of the chart of accounts and evaluated the use of user defined fields for the new chart of accounts. They also looked at the use of ‘trees’ to meet reporting needs. The second sub-committee designed the format of the focus groups and developed the script to be used in these meetings. The sub-committees met as needed and reported back to the full committee at the regularly scheduled monthly meetings.
The committee developed a list of constituents to represent a broad range in the types of users of the system. Eighteen focus groups of 8-10 system users were held across campus in January 2000. Participants came from approximately 95 academic and administrative units. (Appendix A)
Two committee members (a primary leader and recorder) led each focus group using the pre-written script. Groups were limited to a maximum of 90 minutes. The first 30 minutes of each focus group defined the current chart of accounts and outlined the charge of the committee. Participants were asked to identify the number and type of shadow systems in use, as well as to briefly describe their use.
Discussion was then directed toward designing the future chart of accounts and encouraging the participants to offer ideas and suggestions. Four primary questions provided the basis for discussion: What do you like about the current system? What do you dislike? If you could design a chart of accounts what would you include? What is your willingness to enter additional information to achieve desired results?
Focus group input and comments were tabulated, and common issues or themes were grouped, then cross referenced to identify the source focus group. This information was then reviewed in weekly meetings through February and March 2000 to allow all the committee members to fully understand issues that were raised in the various groups. The result was an outline of primary issues and concerns, as well as the committee’s working understanding of the ways in which those issues could be addressed within the framework of the chart of accounts prototype being developed, and PeopleSoft financials. (Appendix B)
In March 2000, three members of the committee attended the PeopleSoft Higher Ed 2000 Special Interest Group (SIG) conference in Dallas, Texas to learn more about the financial product and determine if the system could address the issues, concerns and requests that were brought out in the focus groups. Committee members attended sessions on the Financials, Budget, Reporting, Contracts and Grants, and Implementation Issues. The opportunity to meet with and discuss issues with representatives from other institutions using PeopleSoft was highly productive, both in helping the committee understand more about the product, and in developing other institutional contacts that will be helpful during the implementation phase.
It is the intent of the committee to
share the final report with the participants of the focus groups and allow
for additional feedback and review. This feedback will be shared with the
Implementation Team as the first stage of the iterative process. A complete
set of committee meeting and focus group minutes will also be made available
to the Implementation Team.
The Concepts:
A discussion of the essential concepts embodied in the chart of accounts follows. An outline of the chart, its field lengths and some detail is shown in Appendix C. As a prototype, the chart of accounts is far from a final design. Much of the final detail will be determined during the implementation process.
The concepts embodied in the recommended chart of accounts take into account various factors not directly related to the chart fields themselves. These are:
One important consideration in the development of the chart recommendations is the strong motivation to reserve at least one of the chart fields to be user-defined. Using one of the chart fields is critical because all application screens in the existing PeopleSoft product (as well as those features/enhancements developed in the future) must include this piece of information. Therefore, ALL users would have the opportunity to "tag" every transaction with their own subsidiary categorization of financial data, and at the lowest level possible. Additionally, in PeopleSoft, the Project module offers flexibility that may further enhance this end user-defined capability.
The chart recommendation takes advantage of the windows-based nature of the application where users will be able to choose, rather than memorize, important financial information. However, there is a need to limit chart field table values to a manageable list and avoid duplication of meaning. This implies an effort to identify, upon implementation, a commonly accepted set of values that are centrally supported.
Key Issues and Assumptions
The breadth of the focus groups allowed for a great depth of understanding about the key issues and assumptions that will influence the ultimate chart of accounts design. As such, the following items place the recommendations of the committee in context with regard to current practice at the University and PeopleSoft functionality.
1. User-defined fields. Currently, departments throughout the University use "shadow" systems and complementary data warehouses to address their specific needs for flexible report summarization and/or additional detail not contained in the current chart of accounts. The goal of the redesigned chart of accounts (and new financial system) should be to incorporate most of the needs exhibited by the development of these systems directly into a centrally maintained chart of accounts structure as user-defined fields. Departmental users should have input into this structure so that their needs are met, while developing a consistent structure that addresses the overlapping needs across the University. In this way, coding that is currently unique among schools and departments can be made consistent allowing for more robust reporting and analysis, and knowledge transfer between various business units of the University.
2. Data entry after initial transaction. The various complementary accounting systems in use throughout the University allow departments to add transactional detail to previously posted transactions. This occurs because:
3. Preprocessing Capability. An important possibility for providing the transaction detail requested by end users is to allow electronic access to the detail before it is processed through the general accounting system, in an environment similar to the purchasing card now in use at the University.
4. Level of transaction detail. The chart of accounts structure must serve a diverse population – some with complex management information and reporting needs, and others with fairly simple accounting, budgeting and reporting needs. While some users of the current accounting system are requesting additional detail and coding, others desire a simpler structure. The chart of accounts structure should attempt to balance these conflicting needs. Where possible, users with simpler needs should not be required to enter information that is not needed by their department or the University. However, if necessary, the level of detail entered should tend toward greater detail so that this information can be used to better manage components of the University and the University as a whole.
5. Use of trees. Some information that is related to the chart of accounts structure will no longer be needed in the primary chart and has not been included in the design, such as MINS Code. While the University currently uses various attributes of the chart of accounts structure to support its reporting needs, some or many of these needs can be accommodated through the use of trees in PeopleSoft.
A tree allows definitions of groupings and hierarchical relationships between values in PeopleSoft. An organizational chart is a good example of a tree – it defines how the departments in the University relate to one another. The PeopleSoft system uses tree information when it needs to summarize data, such a report that collects data for all departments in a division. It is anticipated that the University will use trees to support grouping, aggregation and summarization for reporting, allocation and analysis.
6. Allocations. The PeopleSoft allocation feature is separate from the chart of accounts structure. PeopleSoft uses allocations to distribute revenue and expenses across funds, departments, and projects – any field or logical group. As with trees, the University will use this structure to support cost allocation and will not need to embed some of its cost allocation attributes in the chart of accounts. For example, the application of benefits rate and indirect costs to externally funded activities would use this feature.
7. Additional account combinations. Focus group participants identified a need for detail that is not currently supported by the chart of accounts. In some cases, it appears that this may require creation of additional account combinations within departments or colleges that can then be summarized as appropriate at the institutional level. For example, the committee anticipates that the new chart of accounts will contain an expanded set of object codes and may use the project chart field to define additional detail about departmental transactions that is not available in the current financial system.
8. Holistic approach to chart of accounts definition. To be successful in implementing a new chart of accounts design, the University will need to actively incorporate college and department needs as well as central institutional needs into the detail design. If the University wants to reduce or eliminate the use of various "shadow" or duplicative systems on campus, it will need to ensure that end-user needs are largely accommodated by the design of the system. To do so, the implementation process should involve key end-user departments throughout the implementation —soliciting needs, reviewing design decisions, and communicating activities — so that departmental users buy in to the changes that will be part of the new financial system.
9. Level of detail in general ledger from other systems. Various departmental users indicated that general ledger transaction detail, for transactions generated from other systems, was not adequate. In some cases, this was because users did not have access to the appropriate transaction detail directly from those systems (see "access to other systems" below). However, it will be important that the University thoroughly review the interfaces from these systems and, in some cases, reevaluate the level of detail in the general ledger appropriate to user needs.
10. Access to other systems for detail information. It appears that end-users are looking to the general ledger for data that should be available from other systems but is not because it has not been added to the data warehouse, users haven’t been given security access, or it doesn’t exist at all. As a result, focus group participants requested additional detail information from the general ledger. While adding this information to the chart of accounts design and the general ledger would address these needs, it will also result in a higher volume of detail transactional data in the accounting system. The University should consider providing additional access to these other systems through changes to security access to these systems, expansion of the data warehouse and/or drill down capability.
11. Data warehouse. The data warehouse is a significant reporting and information repository for the University community. The data warehouse, or a reconstituted version thereof, should be available with the new financial accounting system. Plans for the new/revised data warehouse should address complementary systems supported by the data warehouse. The functionality of these systems should be accommodated by the new financial system directly or in the manner currently supported through the data warehouse.
12. Computing Capability.
An important factor considered in the chart recommendations is the University's
aggressiveness in providing its users computer tools and capabilities (such
as desktop computers and the data warehouse) to enable users to merge their
complementary data and central data.
The Chart:
PeopleSoft Financials software is delivered with seven defined chart fields, several with specific functionality and purpose. The committee began the construction of the chart accounts with the following assumptions:
BUSINESS UNIT
The PeopleSoft Financials Software is configured to balance journal entries and ledgers by Business Unit. Business unit is defined as an entity that produces its own financial statements and reports. This required chart field may then be used to consolidate information to the highest level, that of the parent organization. While the committee debated the use of multiple Business Units for agency accounts, auxiliaries, or other independent operations, the only use of multiple Business Units in higher education appears to be in multiple campus settings. Further, Business Units must be consistent between the Human Resources system and the General Ledger module. Multiple units require multiple control tables. Given the complexity of use and the fact that the Human Resources PeopleSoft Implementation team has elected a single Business Unit, the committee recommends that there be no effort in the initial implementation to have more than one Business Unit.
FUND
Typically, this chart field identifies fund subsets that require a balancing-type structure. These subsets may include, but are not limited to, traditional "fund" subsets, such as Endowment, Plant, etc. These subsets may also be used for official financial reporting such as the FASB definitions of temporarily and permanently restricted net assets and may be used for other internal management reporting or convenience. This field has been used creatively by other institutions, and the committee recommends that looking for a "best of breed" example be undertaken before the final definition of this chart field is set.
Brevity is important here. Every transaction entry requires that this five charater field be filled in, thus, the fewer values in this table the better.
ACCOUNT
The committee recommends the use of this field with values similar to the existing object code listing which describes the nature of a financial entry. Limits on entries are quite important, as Account is a required field for every transaction. PeopleSoft requires the account value to be identified as unique to asset, liability, revenue, expense or fund/equity type codes. This limitation may cause duplicate accounts with the same meaning for asset, liability, and agency fund accounts, but such limitation is a minor inconvenience that can be accommodated.
Critical to the success of the overall chart design is the ability of users to "tag" their data with useful departmentally defined information. One option to achieve this objective is to assign broad centrally identified value ranges for the first four characters of this chart field. The last two characters would be assigned by end users, thus allowing them to "tag" their data according to their own need for detail. This is one option that may meet our needs, and we have identified one university that has used part of this chart field as user-defined. However the majority of consultants/users surveyed recommend against this dual use. Experience with the system should guide us in the use, if any, of the last two digits.
PROGRAM
The committee recommends this five-character chart field be used for the description of how a financial transaction relates to the mission of the institution, including the standard reporting needs for FASB statement of activities. This corresponds to the current definition of function in digits 3 and 4 of the current account code, defining activities as to purpose, e.g. instruction, research, and student affairs.
CLASS
The committee recommends this five-character chart field be reserved for users other than core administration. The need for such a user-defined field is detailed elsewhere in this report. Use of this field therefore will be avoided when preparing Official University financial documents.
Values in this field should be generic in most cases such that individual units can assign their own meaning to the values. However, use of this field needs to be managed to prevent chaos and clutter in the chart field organization. Users, who wish to use it for internal departmental control and reporting, should do so by having on file with central accounting, the departmental logic chart they intend to use. This "backup" mechanism should be routinely updated. It is in the interests of system efficiency and reasonable table organization to minimize the number of entry values in this table.
DEPARTMENT
The committee recommends the use of the field for the purposes of defining an identifiable unit. However, as with the other fields, values should be alpha numeric, rather than just the traditional numeric fields now in use. The field allows for ten characters and the committee suggests the use of at least six characters to assist in defining broad ranges, thus retaining flexibility within those ranges.
PROJECT
The Project field can be used to define the individual activities of construction, contracts, gift funds, and other non-budgeted segregated funds. Use of this field in conjunction with the grants module is mandated. The field is fifteen characters long with subdivisions. The committee recommends that all fifteen characters are made available, however, a shorter character set may suffice. Again, brevity should be a goal to reduce needed input time while capturing all the necessary information for adequate reporting.
Project appears to be the most robust chart field in terms of having the flexibility to meet many of the needs expressed by both academic and administrative users. A project has three reporting levels below the primary project, defined as segment, phase and activity. While it is clear that the implementation team will need to understand the capabilities of the project/grant module early, it is also clear that peer institutions with the system running attest to the power of this segment of the system.
Reporting:
Consistently across the focus groups, issues and concerns were raised that demonstrated the critical reporting needs of system users. They want to have a system that is easy to use while giving the level of detail that they need. Many users rely on the data warehouse to extract their information into a form that allows them to add complementary data, as well as to manipulate the data into a variety of end reporting uses. The data warehouse also serves as a complementary system that will allow users to enter additional information not available at the time of transaction. The committee recommends the data warehouse concept is maintained, as it will continue to provide one very important tool in the array of tools available to achieve the necessary level of reporting detail and flexibility desired in the new system.
The use of PS Query along with Crystal Reports or PS/nvision should allow the users to obtain most of the data they need and produce the reports they want when they want them. Specific needs include the ability to compare data over a defined range of dates, and the ability to print reports on demand when needed. A rudimentary understanding of the use of ‘trees’ to combine multiple chart fields and chart field segments will allow for more varied organization of the data and more flexible, more precise user defined reporting. Additional review of the reporting tools is necessary to confirm this assumption.
Through the use of trees and an artful combination of chart fields, the chart recommendation should meet external reporting needs, such as for the Financial Accounting Standards Board (FASB), the indirect cost proposal, and sponsored research reports. It should also meet internal reporting needs of University management, the research office, administrative units such as housing, dining services and facilities, as well as the needs of the academic units.
Training sessions on the use of trees and other reporting methods will be essential in familiarizing the end users with the capabilities of the PeopleSoft system.
Implementation:
Among the most significant findings of the committee as it sifted through the focus group information were the number of issues that came up in regards to implementation of the new financial software. Although many of the end users were familiar with the inherent structure of a chart of accounts, many of their concerns arose from understanding the interactive functionality of the software. How does it work? What are the relationships between the data? What kind of training commitment will be required? How will existing sub-systems interface with the new system?
The committee was able to discuss these questions at length. Committee members also investigated the implementation process completed at other schools through website reviews and discussions with colleagues while attending the SIG conference in Dallas. As a result, the committee offers the following recommendations to the Implementation Team:
Appendix: