FAQs
The Chart of Accounts (COA) is a set of codes used to classify and record financial transactions. Yale is a complex and highly regulated environment, and the COA provides the structure for reporting and monitoring financial activity that responds to our various requirements.
Proper use of the COA helps the University organize financial information for:
- Internal reporting and financial management
- External reporting and compliance
- Effective management of restricted funds
Yale’s financial system of record, Workday, is a software-as-a-service (SaaS) application designed to enable the use of various modules and special functions for accurate grants management, gifts and endowment management, and asset capitalization. Therefore, utilizing certain worktags or COA segments that enable those special functions is key versus combining “multi-purpose” COA segments.
Many segments in the Chart of Accounts are grouped into hierarchies and may have multiple hierarchies if required, for diverse reporting or system needs. Hierarchies can help users find segments (such as using the Project hierarchy to find your department’s Project list) or group activity together in reporting (such as the Fund hierarchy in a Statement of Activities). Learn more about COA Hierarchies.
Certain COA segments are designed to tell the system to always default (or “bring along”) one or more Related Worktags. The Grant hierarchy is the most powerful of these “driver” segments; it defaults in all of the required segments needed to directly charge that Grant. Funding components (Grant, Gift, and Yale Designated) all bring along a Fund. Learn more about Related Worktags.
Worktag Templates may also be used on requisitions to create reusable COA charging instructions templates, speeding up the requisition checkout process. This feature can be especially useful for users working in a grant-heavy environment. Learn more about Managing Requisition Worktag Templates.
Users of the COA will coordinate with their department business offices to identify appropriate charging instructions.
Zero-dollar value balances may appear in Workday reporting in any of the following instances:
- Starting balance was zero and current year activity exists but nets to zero.
- On certain Workday balance reports, the system is designed to return account balances on any system-identified unique COA combination, inclusive of non-Core COA worktags (such as a revenue category, spend category, or location worktag). As a result, accounts that departments may have considered to have been zeroed-out or inactive may not drop off year-over-year.
- Workday delivered some functionality that allows entities to configure worktags to include in the annual roll forward of balances. The theory here is that if we define the worktags that we consider to be the “full string,” anything with zero balances and zero activity at the “full string” level would drop off. Yale thoroughly investigated this in FY22, but due to our use of book and book codes in Workday, this functionality did not resolve our pain point and was not implemented.
The COA team is researching alternatives to resolve this pain point.
Yes. To maintain the University’s external regulatory and reporting compliance, Workday may autopopulate certain spend categories (SCs) on Purchase Requisitions or Expense Reports to enforce appropriate classification of various types of products and services. This built-in system control was also designed to assist preparers in spend category selection. In many cases, the SC may autopopulate based on a built-in eight-digit United Nations Standard Products and Services Codes (UNSPSCs) by product or service. Similar defaulting behavior occurs on expense reports based on a built-in four-digit Merchant Category Code (MCC) assigned to certain suppliers (mostly travel) for accurate classification of their primary business activity to ensure alignment with spend categories. Nonetheless, initiators do have the ability to modify spend categories and/or expense items. As always, it is the responsibility of transaction approvers to review carefully to ensure accuracy.
The “Ledger Accounts with Spend/Revenue Categories – Yale” report provides a view of Workday’s behind-the-scenes accounting rules engine called the Account Posting Rules (APRs). It was created to help users understand the relationship between the Revenue Categories and Spend Categories entered on most transactions and the Ledger Accounts that appear in reports. The report is currently filtered to just look at the rules driven by Revenue Categories and Spend Categories (RCs/SCs) and return the derived Ledger Accounts based on the Workday APRs since this is the most common business need.
Users may modify report filters, as needed, to pull information by APR value (the transaction type that uses the rule), Ledger Account, or Account Posting Rule Condition Dimension (the worktag that the rule uses to decide what Ledger Account will be applied). The report may further be filtered or exported for additional analysis. For ease of readability, this report was designed to group information in a stacked-view fashion (e.g., if a ledger account is related to multiple COA segment values (RCs or SCs) and/or other COA Worktags (Cost Center, Program, Project, Yale Designated) users may need to parse data externally if an alternate view is desired).
To see payroll ledger accounts and categories, remove all values in the “Account Posting Rule Condition Dimension” field.
The presentation and structure of this report are limited by the way the information is captured in the Account Posting Rule Set and how the rule is written. If the rule is written based on Revenue or Spend categories (impacting transactions like expense reports and cash sales), the categories appear in the segment values column. If the rule is written based on other data points (such as payroll rules being driven by dimensions such as Pay Component, Job Category, or Pay Group) and the Spend Category is part of the programmed output, the categories appear in the Resulting Worktags column. The Business Area column aligns with the type of transaction that engages the rule in question.