Chart of Accounts Design

Introduction and Approach

The Florida Planning, Accounting, and Ledger Management (Florida PALM) Chart of Accounts (COA) Design establishes and defines a statewide level COA structure that includes individual design components for the ChartFields and Budget Structures. The COA Design is a component of the Florida PALM Analysis and Design activities. The COA Design was evolved and refined through iterative and collaborative work with the Department of Financial Services (DFS) Division of Accounting and Auditing, Division of Treasury, and Office of Information Technology, along with Florida Financial Management Information Systems (FFMIS) partners and agencies.

The scope of the COA Design defines the ChartField structure, definition, usage, ownership, and maintenance of each ChartField that collectively comprise the COA. To support COA Design activities and ease the transition from the legacy system to Florida PALM, the ChartField values resemble the legacy values where possible. The COA Design is a result of extensive efforts contemplated to accommodate financial management and reporting using Florida PALM COA and other Florida PALM solution functionalities that previously were accomplished via specific legacy data elements. The COA Design establishes the statewide COA structure for Florida PALM.

The scope of the COA Design also defines the Budget Structures, including rules and configurations, key budget ChartFields and translation, and budget control options. The Florida PALM Budget Structure supports information received from the Legislative Appropriations System/Planning and Budgeting Subsystem (LAS/PBS) and helps agencies comply with budgetary statutory provisions. The COA Design includes specifications for statewide and agency-specific budget definitions to fulfill budget management, transactional processing, exception management, and reporting requirements. Budget Structures are tightly integrated with the ChartFields. The processes describing the maintenance of the ChartField values, appropriations, and allotments are detailed in the Business Process Models.

The COA Design has a system-wide impact and is identified as a “major key” configuration element of the Solution within the Application Configuration and Development Strategy, meaning any significant future modifications may be difficult to implement and will require thorough analysis and extensive testing to confirm business processes are not adversely impacted by the change. However, managing ChartField values (e.g., addition or modification) is part of operational maintenance efforts to support transaction processing and reporting.

The COA Design began early in the implementation lifecycle with updates and refinements planned through approval. Figure 1 provides a visual of the COA Design activities occurring between September 2018 and February 2020.

Figure 1: Chart of Accounts Design Activities

The initial COA Design was developed taking business requirements, system capabilities, and Florida Accounting Information Resource (FLAIR) research and analysis into consideration. Following the initial COA Design, the Florida PALM Project Team (Project Team) developed Business Process Models that provided further insight to evolve the COA Design. In parallel, the Project Team continued to refine the COA Design through collaboration with DFS Divisions, including the Divisions of Accounting & Auditing and Treasury, and the Office of Information Technology.

Throughout the development of the COA Design, the Project Team conducted extensive FLAIR research and analysis to develop a comprehensive understanding of how agencies use the legacy data elements to transact and report. As a result, the Project Team conducted additional meetings with targeted agencies based on their current use of FLAIR data elements and provided a forum to validate that a standardized COA Design could meet agency needs.

A questionnaire was distributed to all agencies to gather additional information on each agency’s usage of the FLAIR data elements as well as their budget and cash management methods. Responses were received from 88 percent of agencies which provided valuable insight into the purpose and intent behind the usage of the agency-specific FLAIR data elements and the desired level of agency budgetary control.

Following the submission of the questionnaire, a series of working sessions were conducted to share and discuss the COA Design with agencies. Over a seven-week period, the Project Team conducted:

• Two (2) kickoff sessions
• Three (3) working sessions on ChartFields
• Three (3) working sessions on Budget Structures
• Five (5) in-person office hour sessions
• Six (6) call-in office hour sessions

Across these activities, the Project Team engaged with 159 representatives from all agencies and FFMIS partners, including the 12 percent that did not respond to the questionnaire.

Following the conclusion of the working sessions, the Project Team documented the COA Design in preparation for review and approval by the Executive Steering Committee (ESC). The iterative nature was intended to allow the design to evolve throughout the process providing an opportunity for increased confidence in the COA Design.

The COA Design is intended for use as an input for the configuration activities necessary to ready Florida PALM for testing. The DFS Divisions of Accounting & Auditing and Treasury, along with applicable agencies, including FFMIS partners, will provide support for the configuration activities. As part of configuration activities, the Commitment Control module will be configured to define additional Budget Structure components that will be leveraged to enable the Fund cash management and cash checking processes for Florida PALM.

Subsequent to the implementation of the Cash Management System (CMS) Wave, the Project reassessed functional and technical business requirements and related Design Dispositions. The COA Design has been updated to incorporate changes identified during this period that will be implemented in Florida PALM at the Financials and Payroll Major Implementation.

ChartField Structure

A ChartField stores COA information and provides the basic structure to segregate and categorize transactional and budget data. ChartFields represent one defined purpose with many values to capture that defined purpose. ChartFields are numeric or alphanumeric, providing flexibility when titling values and room for growth as additional values are established.

The ChartField structure defines the design of each individual ChartField, specifies how each ChartField is established, and identifies the ownership of ChartField value additions or updates at two levels: statewide or agency. The ownership of ChartField values is set via a configuration feature called TableSet Control. The statewide ChartFields are set under a statewide TableSet Control value (State) and agency-specific ChartFields are set using the agency specific TableSet (Business Unit) Control values.

The below sections describe the ChartField structure for Florida PALM. The ChartField Use and Features section describes the Solution functionalities used in Florida PALM to confirm a secure and consistent financial management and reporting process. The ChartField Structure Request and Securing Access to ChartFields sections provide additional information about the Solution. The ChartField Details section includes a detailed description of each ChartField and the Project-related fields that support the Project ChartField.

ChartField Use and Features

Once the ChartField values are configured, they are available for use on transactions and reporting. This section highlights the ChartField-related Solution features which provide support for transactional and reporting activities including Attributes, ChartField Combination Edits, SpeedKeys, Trees, and ChartField inheritance. With the exception of SpeedKeys, these ChartField-related Solution features are centrally maintained by DFS.

Attributes

A ChartField Attribute is a system configuration feature that provides the ability to record additional characteristics about individual ChartField values for reference or reporting purposes. Attributes are not visible to the end user for use on transactions in the modules. Only one Attribute value can be selected for each Attribute associated with a ChartField value. Attributes are used on statewide ChartFields only and are established and maintained by DFS. Attribute values assigned to a ChartField value can be used in designated reports. Each Attribute is described in more detail in Appendix 1 – ChartField Attributes. The Appendix 1 will be updated when additional attributes are identified.;

ChartField Combination Edits

ChartField Combination Edits help to maintain data integrity across modules by validating ChartField relationships to ensure that required ChartFields and ChartField values are valid for use with one another. The enforcement of ChartField relationships ensures accurate and meaningful reporting of the State’s financial results from the State’s financial management system. Combination Edits can be used to specify which ChartFields are required on a transaction or which ChartField values are not allowed based on values entered in other ChartFields. ChartField Combination Edits are established and maintained by DFS for use by all agencies and are defined at both the ChartField level and the value level.

ChartField Combination Edit errors are identified during the Edit Check process and prevent affected transactions from further processing. ChartField Combination Edit errors cannot be overridden by the transaction processor and must be corrected in order to proceed. Combination Edits occur prior to approval and budget checking and are applicable in all modules. 

Human Capital Management (HCM) or Payroll also utilizes ChartField Combination Edits to enforce the use of valid ChartField Strings on Payroll transactions. Payroll utilizes the same COA values that have been defined and configured in the General Ledger. The COA is published (i.e., synced) to Payroll on an ongoing basis. 

The following are the design considerations for creating ChartField Combination Edit rules:

• ChartField Combination Edits are used to enforce the relationships between ChartField values within Florida PALM.
• ChartField Combination Edits occur in the General Ledger, Commitment Control, and Payroll as well as all source modules.  
• ChartField Combination Edits can be configured to be enterprise-wide across all modules or be setup to be module specific (e.g., General Ledger only, Accounts Payable, and Accounts Receivable).
• ChartField Combination Edits provide simple and consistent rules that aid and do not hinder data entry.

ChartField Combination Edit rules are listed in Appendix 2 - ChartField Combination Edits. Additional rules may be identified that will result in updates to Appendix 2.

SpeedKey

Florida PALM provides a SpeedKey tool to manage data entry for various Financials and Payroll transactions. Characteristics of SpeedKeys include:

• Aid in data entry and may include one or more ChartFields
• Required in Payroll 
• Required for Purchasing Card transactions in PCard Works
• Optional for Financials modules within Florida PALM, excluding Asset Management, Cash Management and Project Costing where it is not available
• May include multiple distribution lines in Accounts Payable and Purchase Order modules to split amount by percentage
• Once the ChartField values are populated within the transaction, values may be changed by the transaction processor
• May be included on spreadsheet uploads, but is not available on interface files
• Available for reporting

SpeedKey set up and maintenance will occur at an agency level. SpeedKeys are established centrally within an agency and provided to users for use on transactions. Payroll SpeedKeys not using pre-approved category values are systematically routed to DFS, Bureau of State Payrolls for approval prior to agency use.

Trees are used to organize the values of a single ChartField into a hierarchical structure to facilitate reporting, security, and budget translation. Trees facilitate reporting at summarized levels by grouping financial amounts on transactions by the detailed ChartField values that hierarchically roll-up to a summary level value. Trees are also used to assign security permissions to a group of users (i.e., Organization tree), restricting the access or visibility of users within that group to minimize configuration maintenance. Trees can be used to translate (i.e., associate) budgets from the summary levels down to detailed transactional values to reduce budgetary maintenance. All trees in Florida PALM are maintained by DFS. A listing of configured trees is accessible via the Tree Viewer functionality in Florida PALM.

Trees

Trees are used to organize the values of a single ChartField into a hierarchical structure to facilitate reporting and budget translation. Trees facilitate reporting at summarized levels by grouping financial amounts on transactions by the detailed ChartField values that hierarchically roll-up to a summary level value. Trees can be used to translate (i.e., associate) budgets from the summary levels down to detailed transactional values to reduce budgetary maintenance. All trees in Florida PALM are maintained by DFS. A listing of configured trees is accessible via the Tree Viewer functionality in Florida PALM.

ChartField Inheritance

The ChartField inheritance feature drives how the ChartFields are determined for system-generated entries that are created to support the accrual basis of accounting for Florida PALM. These system-generated entries are offset accounting lines (e.g., the liability accounting line generated when a user enters the expenditure accounting line on an Accounts Payable voucher). All ChartFields used on the user-entered transaction accounting line are inherited by the system-generated offsetting transaction line.

ChartField Structure Request

The ChartField Structure Request is a system feature which supports the initiation/request, routing, and establishment of ChartField values in Florida PALM. The ChartField Structure Request allows designated users to provide required information related to the ChartField request and systematically route for approval within the agency and to DFS. Upon approval, the ChartField value will be systematically configured. ChartField applicability is detailed in the Maintenance section of each ChartField.

Securing Access To ChartFields

Within Florida PALM, there are several tools that can be used to enforce security, internal controls, and data integrity. In addition to the Combination Edits previously described, controls can be placed on the access to and use of certain ChartFields. Securing access to ChartFields provides the ability to secure user access to designated Business Unit and Organization ChartField values. Once security is applied, the Solution only displays Business Unit and Organization ChartField values and rows of data that a user is authorized to view based on their assigned security profile. The following provides additional details regarding how security is accomplished.

• Business Unit Security will be accomplished by establishing user security permission lists that designate which Business Unit(s) a user has access to. A Business Unit will be established for each agency within Florida PALM. Business Unit security is a type of security that provides the ability to restrict access to the entirety of an agency’s transactions and reporting information. From a reporting perspective, this type of security enables users to access data without accessing data for all agencies. For example, users in one agency can be restricted from reporting against another agency’s transactions unless given access to the respective agency’s Business Unit.
• Organization ChartField Security will be accomplished by configuring rules that identify the Organization ChartField values a user has access to, by permission list. Access to an agency’s ChartField values can be restricted by explicit values and ranges of values or allow access to all values. For example, within an agency, users within one division can be restricted from entering, updating, or inquiring on transactions that reference another division’s Organization ChartField values. Florida PALM will apply Organization ChartField Security to the following source modules:
  1. Accounts Payable
  2. Purchase Order
  3. Asset Management

Important Note: Organization ChartField Security only applies to screens and transactions that contain an Organization ChartField value.

ChartField Details

This section details the purpose and design characteristics of ChartFields that will make up the Florida PALM COA. For each ChartField, the following information is provided:

• Design – Documents the purpose of ChartFields, describes the structural details, and lists the design considerations to establish ChartField values used for transactional and reporting purposes
• Assumptions – Provides a bulleted list of the assumptions or external factors that must continue to function in order for the COA Design to be complete
• Maintenance – Describes the ongoing operational process for how ChartField values, Attributes, and trees are added, removed, or modified

The table provides a summary of the Florida PALM ChartFields. The table provides the field name and length, the associated legacy FLAIR data element, the Florida PALM database field name, and indicates whether the field is required and the entity that will control the set up and maintenance of the values within Florida PALM.

Items noted with “N/A” indicate where there is no current legacy FLAIR data element that is anticipated to be replaced by a Florida PALM ChartField. Agencies may choose to utilize the fields to accommodate new tracking and reporting needs or to accommodate other legacy features and functions, as identified in the Legacy FLAIR Data Elements Met by Other Solution Functionality section below. Additional information about each ChartField is included in the ChartField Details section below.

Table: Florida PALM ChartField Summary

⁽¹⁾ Outside of the General Ledger, this field is known as BUSINESS_UNIT_GL
⁽²⁾ Only existing legacy state standard Balance Sheet General Ledger codes will be configured as Account values in Florida PALM
⁽³⁾Required when a Project ChartField value is present

Legacy FLAIR Data Elements Met by Other Solution Functionality

With the implementation of Florida PALM, not all legacy FLAIR Data Elements are replaced by Florida PALM ChartFields. Instead, they are met by other Florida PALM functionality. The following explains how functionality will be met for FLAIR Data Elements that will not be ChartFields in Florida PALM::

• Year (YR) is accommodated via transactional features driven by the budget date field/functionality. 
• GAAFR Fund (GF) is an attribute of the Fund ChartField.
• State Fund (SF) is captured in the numbering scheme of the budgetary fund value as detailed in the Fund section below and is also an Attribute of the Fund ChartField.
• Internal Budget Indicator (IBI) functionality is replaced by Fund ChartField functionality as detailed in the Fund section below. The Florida PALM team engaged with the Department of Health and the Legislature and confirmed that the use of Fund will accommodate the functionality currently provided by IBI.

In addition to the above legacy FLAIR Data Elements, the Project Team considered additional FLAIR codes and classifications as part of the COA Design activities, with the results as follows:

• Expanded State Program code is replaced by the agency-specific ChartFields. The Florida PALM team engaged with the Department of Transportation, the Department of Children and Families, the Department of Highway Safety and Motor Vehicles, the Florida Fish and Wildlife Conservation Commission, the Florida Department of Education, the Florida Department of Agriculture and Consumer Services, the Agency for Persons with Disabilities, the Department of Elder Affairs, and the Department of Environmental Protection and confirmed that the Expanded State Program is either not in use or can be met through the agency-specific ChartFields. 
• Agency Unique code to subclassify an organization code is met by Business Unit security and Organization ChartField security. This provides similar functionality to the way Agency Unique is used on the Access Control File. Agency Unique code is also used as a separate Data Element, which is met through the use of agency-specific ChartFields.
• External FLAIR codes are replaced by module functionality and enhanced reporting tools. The COA questionnaire provided insight into agencies’ usage of the external FLAIR codes. While these codes were not heavily used across all agencies, those agencies who did leverage these codes used them to provide further categorization or classification for tracking and reporting purposes.

Version History