Chart of Accounts (COA)

View the current COA ChartField Values (Google Sheet) spreadsheet containing the detail values. Keep in mind that the official record of active codes is in the financial system itself, rather than on these web pages or spreadsheets.

View notes about changes to Fund and Account codes for fiscal year 2025.

Request a New ChartField Value or a Change to a Current Value

New DeptID requests or requests for changes are reviewed by the Budget Office. For other ChartField values, requests are considered centrally throughout the year. For areas being served by the Financial Operations Center, there is a ChartField Request for available in TeamDynamix. For all other areas, each college or administrative unit has individuals with access to the COA Request form in EFS to complete requests for these values. Requests for new Program codes, ChartField 1, ChartField 2, or ChartField 3 (FinEmplID) values are accepted throughout the year. 

Combo Codes for Campus Solutions or HRMS

Combo Codes are the PeopleSoft-delivered way for HRMS to make use of ChartField strings from Finance. Item Types are the PeopleSoft-delivered way for Campus Solutions' Student Fees and Scholarships to make use of ChartField strings from Finance.

Viewing Combo Codes

  • The best place to view Combo Codes is the Combo Code Table in the HR system: UM Financial Transactions > UM Salary, Fringe, Adjustments > Combination Code Table
  • Another location in the HR system is: Set up HRMS > Chartfield Configuration > Combination Code Table

Expand all

Definitions

Chart of Accounts

The Chart of Accounts is the organizing framework for budgeting, transacting/recording, and reporting on all University financial transactions. It is designed to capture financial information to make good financial decisions.

  • The Chart of Accounts is a series of values that represent the University's mission, organizational structure, and fiscal accountability.
  • These values are the language of the financial system. It allows for accurate and consistent communication, structure, and parameters across all financial system users.
  • The Chart of Accounts is used every time there is a financial transaction at the University. Lanyards and land, grants and grass all require it.

Every time a transaction is entered into a particular module within the financial system, the Chart of Accounts is used to capture information about that transaction and allow it to flow through the system to the General Ledger. The more accurately a transaction is described through the ChartField string, the better the information that will be available to us.

ChartFields

ChartFields are values used to classify financial transactions entered into the General Ledger.

  • Each ChartField represents one specific type (piece) of financial data.
  • Each piece of information captured by a ChartField fulfills a need. That information may be required for regulatory reporting, for tracking expenditures against budgets, for managerial decision making, or other reasons.
  • There are eleven ChartFields in the financial management system (not all 11 ChartFields are used on each transaction).
  • Some ChartFields are required for every accounting transaction (Fund, DeptID, Account).
  • The remaining ChartFields are used to report even more information about a transaction.

ChartField string

ChartFields comprise the ChartField string. The ChartField string is comprised of a sequence of values that describes the financial transaction.

ChartField independence

ChartField values are designed to work independently of each other. This allows values to be used across departments increasing flexibility of monitoring and reporting.

Example: Below is an illustration that shows the ChartField strings two departments use to track the same information. The only difference is the DeptID, and the other values remain the same. This one difference is significant, as it changes the meaning of the ChartField string by identifying a different responsible unit

FundDeptIDProgramAccount
10001008420000720101
10001000620000720101

Other COA Terminology

Code of Conduct

The University of Minnesota’s Code of Conduct applies to all employees of the University, and ensures honesty, integrity, and responsibility in all University-related activities, including purchasing. 

Find the current Code of Conduct policy on the Regents of UMN website.

ChartField Quick Reference

A printable version of the ChartFields job aid (pdf) is also available.

Chart explaining ChartFields used in EFS ChartField strings

Required ChartFields per Transaction Type

Depending on the transaction type, specific ChartFields must be populated for a ChartField string. Three transaction types are listed below. The required ChartFields for each transaction type are indicated with an checkmark in each field. Conditional/optional ChartFields CF1, CF2, and Fin EmplID can be used separately or in combination with any of the transaction types.

Required ChartFields per transaction type

Financial System Integration

Information flows from one area of the financial system to the next. It is a complex hive of activity. It is important to keep in mind that an accounting entry ends up in the General Ledger (and for sponsored projects, an entry also ends up in the Projects module). For a visual representation of this process, please see Financial System Data Integration.

Fiscal Responsibilities Guide

A community of people within each unit share financial stewardship, even though we may all play different roles. Listed below are six primary financial roles. Keep in mind that these are roles, not job descriptions, so you may function in several of these capacities.

Initiator

Individuals who request or initiate an event that results in a financial transaction. They are responsible for conducting activities and events within the boundaries of compliance with University policies and procedures and funding agency restrictions. Note: Any University employee has the potential to be an initiator.

Preparer

Individuals who prepare, code, review, and/or process sponsored and nonsponsored accounting transactions in compliance with University policies and procedures and funding agency restrictions; resolve discrepancies; and prepare reports.

Approver

Individuals who review and approve sponsored and nonsponsored accounting transactions to ensure compliance with University policies and procedures and funding agency restrictions, and who identify problems and ensure resolutions.

Fiscal monitor

Individuals who are responsible for policy interpretation  and implementation for a department (or collegiate unit or higher). They manage the sponsored and nonsponsored accounting and fiscal operations of a department (or collegiate unit or higher) in compliance with University policies and procedures and funding agency restrictions.

Principal Investigator (PI) or project manager

Individuals who provide leadership for a research grant and/or subunit within a department by managing, problem solving, ensuring compliance with policies, and monitoring budgets.

Academic or administrative head

Individuals who provide overall leadership for the unit and the University in general. They participate in policy formation and ensure policy implementation for their unit. They are also responsible for their unit’s overall financial management.

Internal Controls

Internal control is a process affected by a university’s governing board, administration, faculty, and staff, designed to provide reasonable assurance regarding the achievement of objectives in the following categories:

  • effectiveness and efficiency of operations
  • reliability of financial reporting
  • compliance with applicable laws and regulations

Components

Internal control consists of five interrelated components derived from basic university operations and administrative processes as follows:

Control Environment

The core of any educational institution is its people. They are the engines that drive the organization. Their individual attributes (integrity, ethical values, and competence) and the environment in which they operate determine the success of the institution.

Risk Assessment

Universities must be aware of and deal with the risks they face. They must set objectives that integrate key activities so the total organization operates in concert. They also must establish mechanisms to identify, analyze, and manage the related risks.

Control Activities

Control policies and procedures must be established and executed to help ensure that actions necessary to achieve the institution’s objectives are effectively carried out.

Information and Communication

Surrounding these activities are information and communication systems. These enable the organization’s people to capture and exchange the information needed to conduct, manage, and control its operations.

Monitoring

The entire process must be monitored and modified as necessary. Thus, the system can react dynamically to changing conditions.

* Internal Controls section reference source of material: From Internal Control Concepts and Applications, Committee of Sponsoring Organizations of the Treadway Commission, 1992 .

Trees

The Chart of Accounts is organized and summarized via trees.  Trees are hierarchical structures that represent a group of summarization rules for a particular ChartField.  For example, a tree can specify how the University’s sources of funding should be summarized, or rolled up, for reporting purposes. A tree can also show the reporting relationships within the University by specifying how the individual DeptIDs should be summarized into Resource Responsibility Centers (RRC), or campuses.

The summarization rules depicted in a tree apply to the detail values of a particular field: vendors, departments, or other values that you define. These detail values are summarized into nodes on the tree. The nodes may also be organized into levels to logically group nodes that represent the same type of information or level of summarization.

Once a tree is defined, the system can use it in a variety of ways:

  • Reporting. When summarizing results for a particular department or campus, the system checks against the tree to determine which DeptIDs to include. Without the tree, each time a report is created, each DeptID needed must be explicitly specified.
  • Summary ledgers. To create a summary ledger that summarizes transaction by department, the system refers to the tree to determine which transactions to include in the summarized entry for each department.
  • Security. User access can be restricted to only certain nodes or levels. The application tables tell the system what department the user is in; the tree tells it what other departments are in the same division. (This use is appropriate for Human Resources Management System [HRMS] applications only.)

Multiple trees can also be created for the same ChartFields, providing different rollups for different views of the financial data. For example, departments can be grouped together differently for reporting than for security.

Advantages of trees

By building trees, the system has a single place to look for summarization rules. This centralization enables rules to be defined once and then used throughout the system. For example, different reports, ledgers, and security profiles might all refer to parts of the University’s organizational chart. All these objects can refer to the same predefined tree.

Trees make it easier to select and update values in reports, ledgers, or security profiles. Rather than specify DeptIDs 10086, 10717, and 10855 in a report, you can specify the Office of Technology Commercialization, which includes all these DeptIDs according to the tree. When the organizational structure changes, only the tree is updated rather than updating an untold number of reports, ledgers, security profiles, and so on.

Another advantage of trees is that they visually present summarization rules. Looking at a tree through the Financial System Tree Viewer, it is easy to see how the values relate to each other. See the sample tree below.

Family tree terminology

When talking about trees, we use terminology derived from the idea of a family tree. The nodes that report to the root node are called its children. They are also called child nodes. The root node is their parent. Nodes that have the same parent are called siblings.

Using roll up levels (nodes)

Nodes are defined as a level of roll up within a tree representing a categorization of values according to function, organizational structure, type, etc.

Each detail value reports to a tree node at the next higher level of the organization. Each roll up level represents  the group of detail values that rolls up to it. Referring to the roll up level is a shorthand way of referring to the group of detail values under it. For example, if a report refers to the Office of the Vice President for Research, it includes data from all the DeptID detail values under the Office of the Vice President for Research node—including the detail values
under the Office of Technology Commercialization, because the Office of Technology Commercialization reports to the Office of the Vice President for Research.

In turn, each roll up level reports to another roll up level at a higher level of organization, until we reach the top level of the hierarchy.

Using detail levels (leaves)

Detail values, or leaves of the tree, link a roll up structure to the supporting detail. For example, the nodes in the following ACCOUNT tree are not the actual accounts but categories of accounts. Using this example, the account tree has a parent node called Revenues, with a child node called Tuition, with detail values specifying a range of Tuition accounts from 400000 to 400999 rolling up to it.

Effective dates

Using effective dates with trees provides the ability to specify new objects, departments, reporting relationships, or organizational structures in advance and have them take effect automatically. Trees can also be used with past, present, or future effective dates when reporting on current or historic data.

Sample Account tree

Account tree highlighting nodes and leaves. A leaf is the lowest detail level value and leaves roll up to a node. For example, there are detail values for different kinds of revenue activity (leaves) that roll up to a value for all revenue (node).

Contact Us

Financial Helpline: 612-624-1617
[email protected]

1300 2nd Street S Minneapolis, MN 55454 (WBOB)
Campus Mail Code: 7529

Controller's Office units are housed in the West Bank Office Building (WBOB) and in the McNamara Alumni Center on the Twin Cities campus.