Core Financial System Requirements
Contents
CONTENTS
Foreword
iii
Executive Summary
1
Background Information
3
Chapter 1
Document Organization
4
Chapter 2
The Core Financial System and How It Relates to Other Financial
Systems
6
Chapter 3
Core Financial System Requirements and How They Relate to Other
Standards and Documents
8
Requirement Management Process
10
Chapter 4
Collaboration and Continuous Improvement
11
Chapter 5
Enabling Federal Financial Management in an Evolving Systems
Landscape
15
Requirements
16
Chapter 6
General Information about the Requirements
17
Chapter 7
General Ledger Management Function
21
Chapter 8
Reporting Management Function
23
Chapter 9
Funds Management Function
25
Chapter 10
Payment Management Function
29
Chapter 11
Receivable Management Function
33
Chapter 12
Cost Management Function
36
Chapter 13
Fund Balance with Treasury Management Function
39
Chapter 14
Cross-functional Classification
41
Chapter 15
Reimbursable Management Function
43
Chapter 16
Technical Capability Function
45
Chapter 17
Security Control Function
49
Appendices
52
Appendix A Changes to Core Financial System Requirements
53
Appendix B Accounting Standards, Laws, Regulations, and Other Guidance
55
Appendix C Requirement Writing Guidelines
61
Appendix D List of Reports
63
Appendix E Glossary
68
Appendix F Abbreviations
92
Appendix G Contributors
99
Tables
Table 1. Requirement Introductory Phrases
Exposure Draft February 2010
i
61
Core Financial System Requirements
Contents
Figures
Figure 1. Primary Capabilities of a Core Financial System
Figure 2. Agency Systems Supporting Financial Management Functions
Figure 3. Continuous Improvement Cycle
Exposure Draft February 2010
ii
6
7
11
Core Financial System Requirements
Foreword
FOREWORD
The January 9, 2009, update to Office of Management and Budget Circular
No. A-127 introduced a requirement for agencies to use a certified standard Federal
configuration of commercial off-the-shelf financial management software. The
Financial Systems Integration Office (FSIO) is responsible for defining
governmentwide core financial system requirements, certifying the standard Federal
configuration for each software product, and assessing agency use of that
configuration.
Each software product vendor will define a standard Federal configuration of its
product that supports the standard Federal financial business processes and the use of
the Common Governmentwide Accounting Classification (CGAC) structure. To meet
its responsibilities for certifying a standard Federal configuration of each software
product, FSIO is revising the approach from a single requirements document and
testing materials to a suite of documents based on the standards for processes and
data. Each document has a particular focus and a unique function. These documents
will include the following:
•
Core financial system requirements (presented in this document), which
describe the system functions needed by a Federal agency to support uniquely
Federal financial management needs. Each requirement is a statement of a
need, identifying what Federal agencies need from a core financial system to
perform Federal financial management operations.
•
Use cases, which provide the system event flow and desired outcomes for
process threads of the standard business processes. Use cases provide context
for requirements to explain how they are interrelated. They provide a “flow”
view of Federal financial management needs. Each use case references one or
more requirement statements.
•
Functional design specifications, which describe system functionality
needed to support automated threads of the standard business processes.
Functional design specifications provide detail about how the system is
expected to perform within the business context described by a use case and
in a manner consistent with the requirements. The functional design
specifications will establish a baseline standard Federal configuration for each
core financial management software product against which it can be assessed
and certified. This is the level at which compliance can be monitored.
•
Data exchange specifications, which provide the data and file formats,
source and target data mappings, data translations, and data flows needed to
achieve interoperability with governmentwide systems. This document is
important for establishing a standard Federal configuration because the
certified configuration needs to include interfaces with Treasury and other
governmentwide systems.
Exposure Draft February 2010
iii
Core Financial System Requirements
Foreword
This document—Core Financial System Requirements—is a second exposure draft
containing updated core financial system requirements. The core financial system
requirements in this exposure draft have been updated to align with the most recently
published standard business processes. This document also reflects the changes that
resulted from the disposition of comments received during the public review and
comment period for the first exposure draft issued in 2009. The second exposure draft
also introduces new methods for requirement management and public delivery. The
new methods are intended to increase agility, adaptability and accessibility as
described in detail in the Requirement Management Process section of this document.
The financial management community is encouraged to provide comments on this
exposure draft using the instructions provided at www.fsio.gov.
Dianne Copeland
Director, Financial Systems Integration Office
Exposure Draft February 2010
iv
Core Financial System Requirements
Executive Summary
EXECUTIVE SUMMARY
The requirements in this document describe what is needed by a Federal agency from
a core financial management system to provide uniquely Federal financial
management services. These requirements result from a complex set of regulations
and guidance for Federal financial management. The requirements are intended to do
the following:
•
Organize Federal financial management regulations and guidance into logical
categories that correspond to system functions or capability components
•
Relate Federal financial management standard business processes to system
functions
•
Describe expected outcomes from system processes.
A core financial system is defined in Office of Management and Budget Circular
No. A-127, Financial Management Systems, as
an information system that may perform all financial functions including
general ledger management, funds management, payment management,
receivable management, and cost management. The core financial system
is the system of record that maintains all transactions resulting from
financial events. It may be integrated through a common database or
interfaced electronically to meet defined data and processing
requirements. The core financial system is specifically used for
collecting, processing, maintaining, transmitting, and reporting data
regarding financial events. Other uses include supporting financial
planning, budgeting activities, and preparing financial statements.
This document has four major sections.
•
The Background Information section defines what a core financial system is
and how it fits in the overall Federal financial management system
environment, and it describes how this document relates to other FSIO
documents.
•
The Requirement Management Process section explains how different
stakeholders should use the requirements. It also describes new methods for
updating and researching requirements that are designed to increase: a.) the
agility with which they may be updated, b.) the adaptation of the
requirements for use in the various phases of a Federal enterprise lifecycle,
and c.) the accessibility of the requirements to information consumers.
•
The Requirements section presents the core financial system requirements
grouped by function and subfunction. This section also includes an overview
of each function and subfunction.
Exposure Draft February 2010
1
Core Financial System Requirements
•
Executive Summary
The Appendices section describes the reasons changes were made to this
edition of the requirements; lists governmentwide accounting standards, laws,
regulations, and other guidance pertaining to core financial systems; defines
terms used in drafting requirements; lists standard reports; provides a glossary
of terms; and defines abbreviations.
Exposure Draft February 2010
2
Core Financial System Requirements
Background Information
BACKGROUND INFORMATION
Exposure Draft February 2010
3
Core Financial System Requirements
Chapter 1
Document Overview
DOCUMENT ORGANIZATION
This chapter describes the organization of the core financial system requirements
document. It includes brief descriptions of the content of each chapter. The
document is divided into four sections: Background Information, Requirement
Management Process, Requirements and Appendices.
Background information
•
Chapter 2, “Historical Context”, explains the importance of Federal financial
management system requirements now and in the future.
•
Chapter 3, “The Core Financial System and How It Relates to Other Financial
Systems”, defines what a core financial system is and how it fits in the overall
Federal financial management system environment.
•
Chapter 4, “Core Financial System Requirements and How They Relate to
Other Standards and Documents”, describes the standards and documents
being developed to support the definition of a standard Federal configuration.
Requirement Management Process
•
Chapter 4, “Collaboration and Continuous Improvement”, describe the unique
role that the core financial system requirements play across the executive
branch of the Federal government.
•
Chapter 5, “Enabling Financial Management in a Changing Systems
Landscape”, clarifies the relationship of the core financial system
requirements to the development and maintenance of standard Federal
product configurations.
•
Chapter 6, “General Information about the Requirements”, provides
information about the need for the requirements. It also describes how the
requirements are organized.
•
Chapters 7 through 17 present requirements by function, subfunction, and, in
some cases, by activity. Functions represent major responsibility areas such
as accounts payable. Subfunctions are common system-supported tasks such
as disbursing. Activities are further divisions of subfunctions and are used
when a finer grouping of requirements is helpful.
Appendices
•
Appendix A describes the reasons changes were made to requirements in this
edition.
•
Appendix B lists governmentwide accounting standards, laws, regulations,
and other guidance that pertain to core financial systems.
Exposure Draft February 2010
4
Core Financial System Requirements
Document Overview
•
Appendix C contains detailed guidance on interpreting requirement text and
attributes, and defines the terms used in drafting requirements.
•
Appendix D lists reports included in the Reporting Management chapter of
Standard Federal Financial Business Processes.
•
Appendix E is a glossary of terms used in requirements.
•
Appendix F defines the abbreviations used in this document.
•
Appendix G lists the organizations that contributed to the development of this
document.
Exposure Draft February 2010
5
Core Financial System Requirements
Chapter 2
Core Financial System Requirements
and How They Relate to Other Standards and Documents
THE CORE FINANCIAL SYSTEM AND HOW IT
RELATES TO OTHER FINANCIAL SYSTEMS
A core financial system is one element within the Federal financial management
environment. This section defines “core financial system” and describes its
relationships to other financial systems within an agency and within the Federal
government.
2.1
CORE FINANCIAL SYSTEM
A core financial system is defined in Office of Management and Budget (OMB)
Circular No. A-127, Financial Management Systems, as
an information system that may perform all financial functions including
general ledger management, funds management, payment management,
receivable management, and cost management. The core financial system
is the system of record that maintains all transactions resulting from
financial events. It may be integrated through a common database or
interfaced electronically to meet defined data and processing
requirements. The core financial system is specifically used for
collecting, processing, maintaining, transmitting, and reporting data
regarding financial events. Other uses include supporting financial
planning, budgeting activities, and preparing financial statements.
Figure 1 depicts the capabilities of a core financial system. These capabilities may be
tightly integrated as a single system or may be standalone systems with information
transferred among them.
Figure 1. Primary Capabilities of a Core Financial System
Exposure Draft February 2010
6
Core Financial System Requirements
2.2
Core Financial System Requirements
and How They Relate to Other Standards and Documents
RELATIONSHIP OF CORE TO OTHER AGENCY FINANCIAL
SYSTEMS
The core financial system exchanges data with other financial and mixed systems1
that are necessary to support financial management. These systems, together with the
core financial system, make up an agency’s financial management system. Figure 2
illustrates the relationship of core and other financial and mixed systems within an
agency.
Figure 2. Agency Systems Supporting Financial Management Functions
2.3
RELATIONSHIP OF CORE TO GOVERNMENTWIDE SYSTEMS
Governmentwide systems provide centralized support for common business
transaction processes and consolidated reporting. The primary governmentwide
financial systems are maintained by Treasury.
A core financial system may interface with governmentwide systems either to
complete a business transaction or to provide data for reporting. As examples, the
core financial system does the following:
•
Provides authorized payment transactions to Treasury so that Treasury can
make the payments
•
Provides general ledger account balances to Treasury for compilation into
governmentwide budgetary and accounting regulatory reports
•
Receives vendor payee information from Central Contractor Registration
(CCR).
1
An agency system that supports both financial and nonfinancial functions is referred to as a
“mixed” system.
Exposure Draft February 2010
7
Core Financial System Requirements
Chapter 3
Core Financial System Requirements
and How They Relate to Other Standards and Documents
CORE FINANCIAL SYSTEM REQUIREMENTS
AND HOW THEY RELATE TO OTHER
STANDARDS AND DOCUMENTS
The January 9, 2009, update to OMB Circular No. A-127 introduced a requirement
for agencies to use a certified configuration of commercial off-the-shelf financial
management software. FSIO is responsible for defining governmentwide core
financial system requirements, certifying the standard Federal configuration for each
software product, and assessing agency use of that configuration. This chapter
describes the standards and documents being developed to support the definition of a
standard Federal configuration.
3.1
GOVERNMENTWIDE BUSINESS STANDARDS
The starting point for establishing a standard Federal configuration has been the
development of standards for processes and data. Specifically, FSIO has been
working with agencies to develop the following:
•
Standard Federal financial management business processes, which are
designed to standardize and streamline financial business activities common
to all Federal agencies. FSIO has defined processes for funds management,
payment management, receivable management, reports management, and
reimbursable management. The standard processes form the basis for defining
the functions a core financial system must support. The processes are
presented in the Standard Federal Financial Business Processes document
which includes standard functional process flow diagrams, step descriptions,
and business rules.
•
Common Governmentwide Accounting Classification structure, which
establishes the standard for classifying the financial effects of government
business activities to be used by all Federal agencies. As a result, the
classification structure provides important information to those seeking to
develop standard Federal configurations of commercial available Federal
financial management products. The CGAC document includes standard
names, definitions, and formats for the classification elements.
The process and data standards described above are based on Federal financial
management policy and guidance from OMB, Treasury, and the Federal Accounting
Standards Advisory Board (FASAB). Appendix B describes the relevant policy and
guidance. Likewise, the process and data standards guide the development of
standard Federal product configurations. Thus, each commercially available product
vendor must build a configuration that supports the process and data standards.
Exposure Draft February 2010
8
Core Financial System Requirements
3.2
Core Financial System Requirements
and How They Relate to Other Standards and Documents
CORE FINANCIAL SYSTEM DOCUMENTS
To meet its responsibilities for establishing a certified configuration of each software
product, FSIO is revising the approach from a single requirements document to a
suite of documents based on the standards for processes and data. Each document has
a particular focus and a unique function. The core financial system documents are
based on information identified in the FTF catalog in a manner consistent with the
guidance provided in the FEA reference models.
The documents will include the following:
•
Core financial system requirements, which describe the system functions
needed by a Federal agency to support uniquely Federal financial
management needs. Each requirement (presented in this document) is a
statement of need, identifying what Federal agencies need from a core
financial system to perform Federal financial management operations.
•
Use cases, which provide the system event flow and desired outcomes for
process threads of the standard business processes. Use cases provide context
for requirements to explain how they are interrelated. They provide a “flow”
view of Federal financial management needs. Each use case references one or
more requirement statements.
Use cases will provide software product vendors with the context necessary to
design product enhancements before FSIO issues testing materials.
Previously, only the testing materials provided context for the requirements.
•
Functional design specifications, which describe standard system
functionality needed to support automated threads of the standard business
processes. Functional design specifications provide detail about how the
system is expected to perform within the business context described by a use
case and in a manner consistent with the requirements.
The functional design specifications will establish a baseline standard Federal
configuration for each core financial management software product against
which it can be assessed and certified. This is the level at which compliance
can be monitored.
•
Data exchange specifications, which provide the data and file formats,
source and target data mappings, data translations, and data flows needed to
achieve interoperability with governmentwide systems. These specifications
are important for establishing a standard Federal configuration because the
certified configuration needs to include interfaces with Treasury and other
governmentwide systems.
Exposure Draft February 2010
9
Core Financial System Requirements
Requirement Management Process
REQUIREMENT MANAGEMENT
PROCESS
Exposure Draft February 2010
10
Core Financial System Requirements
Chapter 4
Collaboration and Continuous Improvement
COLLABORATION AND CONTINUOUS
IMPROVEMENT
One goal of the requirement management process is to support collaboration among
all stakeholders. Another goal of requirement management is to ensure that the
requirements are improved continuously. Collaboration has been greatly improved by
the use of emerging Internet technologies. The requirements are continuously
improved when their content and disposition are visible to the public and when
feedback can be accepted on a continuous basis. This chapter describes how these
two goals of the requirement management process are being achieved.
4.1
FACILITATING COLLABORATION
Previously, the core financial system requirements were provided to the public in the
body of this document and in a single “crosswalk” spreadsheet. Because a Word
document is impossible to query and because it is also infeasible to sort or group the
requirements contained within a document, this document now includes links to
external Excel spreadsheets of requirements grouped by function. The single
crosswalk has been supplemented with a master view, which includes the final
version of each requirement shown in relation to that requirement’s attributes
including the function and subfunction attributes.
Figure 3. Continuous Improvement Cycle
Exposure Draft February 2010
11
Core Financial System Requirements
Collaboration and Continuous Improvement
4.1.1 Adaptable Requirements
Adaptability involves the capacity to grow and change to suit varying environmental
conditions. Core financial system requirements also need to be adaptable. These
requirements are intended to guide or support the development, acquisition,
integration, test, and deployment of core financial systems supporting array of
agency missions. In addition, many agencies have a large host of technologies with
which a core financial system must be interoperable. Therefore, the requirements
must be adaptable for use in solicitations and commercial vendor product design
specifications.
However, not every requirement is adaptable to every circumstance for which a
stakeholder might wish to apply it. To facilitate correct adaptations of the core
financial system requirements, attributes have been defined to identify likely uses of
each requirement. The Requirement section of this document describes these
attributes.
4.1.2 Accessible Requirements
Accessibility is connected to the goals of transparency and collaboration. For
requirements to be accessible means that they are available to the stakeholders review
and comment. Accessibility enables transparency when pre-decisional and postdecisional information is maintained in a web space that is accessible to the public.
The core financial system requirements will be accessible to the public from the FSIO
web site. This document includes external links to the latest versions of the
requirements.
In addition, agency representatives will have continuous web-based access to the
requirements and agency comments concerning the requirements from the OMB Max
collaboration space - https://max.omb.gov/community/display/finance. The Max
collaboration space will also serve to facilitate the exchange of comments and ideas
among the agency officials.
Exposure Draft February 2010
12
Core Financial System Requirements
4.2
Collaboration and Continuous Improvement
THE NATURE OF FEDERAL SYSTEM REQUIREMENTS
The core financial system requirements are Federal enterprise-wide requirements.
They must be crafted in a manner that supports Federal enterprise standards, while
also enabling accurate and consistent interpretation without being unnecessarily
prescriptive. Current Federal financial management system policy mandates agency
conformance with Federal standard business processes, data standards and standard
Federal product configurations, but it also preserves the use of some agency-specific
and mission-specific distinctions in the operation of a core financial system. In
addition, current policy allows commercial products to differ in design and operation.
Thus, while the mandated standard Federal configurations of each product are
intended to drastically reduce variances in the implementation and operation of each
commercial product line, they do not require that every product satisfy each
requirement in precisely the same way.
Invariably during each public review period, comments are received that recommend
updates to the document that are inconsistent with the unique nature of Federal
enterprise-wide requirements. Unlike ordinary, implementation-specific system
requirements, the Federal enterprise-wide core financial system requirements must be
appropriate for:
4.3
•
Any Federal agency information technology (IT) architecture, landscape or
implementation strategy
•
A broad range of systems and commercially available products
•
Multiple phases of an enterprise management lifecycle
•
Guiding product selections and migrations to a shared service provider
•
Guiding the agency core financial system implementations
•
Enabling the design, build or configuration of commercially available
products
•
Evaluating and certifying commercially available products.
REQUIREMENTS STAKEHOLDERS
The core financial system requirements must be easily accessible and adaptable for
use by different stakeholders. These stakeholders include:
•
Agencies
•
Architects
•
Software Vendors
•
Shared Service Providers
Exposure Draft February 2010
13
Core Financial System Requirements
•
Collaboration and Continuous Improvement
Integration Partners
Thus, the same requirement that influences an agency acquisition process may also
guide a vendor’s product development process and an implementation partner’s
configuration and test activities. Therefore, as with all enterprise-wide requirements,
some stakeholder-unique specificity must be included in separate documents targeted
to each group of stakeholders. For example, functional design specifications are
planned for development to guide vendors in building standard Federal product
configurations. Instead of including lengthy details in verbose requirement narratives,
the specification documents will now include exhaustive lists of functional design
specifications.
Exposure Draft February 2010
14
Core Financial System Requirements
Chapter 5
5.1
Enabling Federal Financial Management in an Evolving Systems Landscape
ENABLING FEDERAL FINANCIAL
MANAGEMENT IN AN EVOLVING SYSTEMS
LANDSCAPE
ENABLING STANDARD FEDERAL PRODUCT
CONFIGURATIONS
Effective October 1, 2009, the revised OMB Circular No. A-127 established the
policy that:
A. FSIO Certified Commercial System
Agencies must use a core financial system that is a commercial off-the-shelf
(COTS) system and has been certified by FSIO as meeting the core financial
system requirements. If the core financial system is not up-to-date with FSIO
certification, agencies should consider upgrading to a certified version of the
same COTS product or implement a different certified product.
B. FSIO Testing
FSIO will establish processes for testing COTS software products supporting
core financial system requirements. The test will verify that the COTS
products meet the core financial system requirements. The product
configuration used in the test will become the certified configuration for that
software product.
Pursuant to this policy, a requirement baseline is being established to guide the
evaluation and certification of commercially available software products. The
requirements in this document are multipurpose requirements that necessarily must
omit specificity that will be provided in use cases, functional design specifications
and data exchange specifications.
Exposure Draft February 2010
15
Core Financial System Requirements
Requirements
REQUIREMENTS
Exposure Draft February 2010
16
Core Financial System Requirements
Chapter 6
6.1
General Information about the Requirements
GENERAL INFORMATION ABOUT THE
REQUIREMENTS
THE NEED FOR FEDERAL FINANCIAL MANAGEMENT
SYSTEM REQUIREMENTS
Financial management in the Federal government must comply with various laws,
regulations, guidance, and standards contained in a number of publications. Among
these publications are OMB circulars, the Treasury Financial Manual (TFM), and the
standards published by FASAB. FSIO also publishes standard Federal business
processes for government-wide implementation.
To comply with Federal financial management standards and regulations, Federal
agencies require specific financial system capabilities. This document identifies those
capabilities as system requirements. The system requirements in this document
represent the system capabilities and functionality needed by a Federal agency to
comply with Federal financial management regulations, guidance, and standards.
Specifically, the requirements in this document do the following:
6.2
•
Organize Federal financial management regulations and guidance into logical
categories that correspond to system functions or capability components
•
Relate Federal financial management standard business processes to system
functions
•
Describe expected outcomes from system processes.
REQUIREMENTS APPLICABILITY
Requirements describe expected outcomes from a system process, but do not specify
computing logic needed to generate the outcome. For example, a requirement may
state “generate a report” or “validate that funds are available,” but it should not
specify any of the computing logic that might be needed to generate the report or
perform validations.
The requirements in this document do not establish or replace existing
Governmentwide accounting policies and procedures. They are derived from the
existing body of laws, regulations, guidance, and standards that govern financial
management and technology in the Federal government.
The system requirements in this document are not all-inclusive. These requirements
are specific to the core financial system and are not intended to define or replace
system requirements for mixed systems such as payroll, travel, and benefits. In
addition, the requirements in this document are those that must be provided by
certified software products.
Exposure Draft February 2010
17
Core Financial System Requirements
6.3
General Information about the Requirements
STREAMLINED REQUIREMENTS
The approach to the requirements is to streamline the requirement language. In
response to feedback, the requirement statements have been streamlined. The goals of
the streamlining process were to:
•
Reduce the number of requirements.
•
Decrease the complexity of requirements for more consistent interpretations.
The following nine rules were applied in general to the pre-existing requirements to
achieve the streamlining process goals.
1. Requirements were removed that prescribe how a system functions unless
some aspect of that function is explicitly mandated by Federal policy. For the
few cases in which Federal policy mandates how a system must function, the
functional details from the prior version of the requirement will be transferred
to a specification.
2. Individual requirements for the user maintenance of master data elements are
consolidated into a single requirement instead of having separate
requirements for each element group or element type.
3. Individual requirements for the capture or usage of data elements were
consolidated into a single requirement, so that there would only be one
requirement per data element group. For example, there is one requirement
regarding the capture and usage of all “Treasury-defined codes for fund
balance with Treasury transactions”.
4. Individual document handling requirements for different types of documents
that are processed similarly were consolidated into one general requirement.
For example, there is one general requirement for the capture of unique
document reference numbers instead of one for each type of spending or
receivable document.
5. Significantly overlapping requirements have been consolidated into one
requirement. The consolidation was achieved by reviewing those that differ
only slightly in their context descriptors such as event trigger, actor or
business rule. New broader requirements have been written that do not
contain the context descriptors. The appropriate context is or will be given in
a use case or standard business process document.
6. The compounded requirements were divided into separate requirements,
because compound requirements often reduce clarity, impede comprehension
and interfere with the proper identification and classification of distinct
requirements in the requirement database and matrices. For example, a
payment confirmation sub-process thread includes three distinct requirements
for importing data, liquidating balances, and updating payment information.
An artificial combination of these three distinct requirements into one
requirement had created a compound requirement.
Exposure Draft February 2010
18
Core Financial System Requirements
General Information about the Requirements
7. Requirements that contained functional design specifications have been
abridged, removed or consolidated. For example, some requirements
previously specified interfacing system data object names instead of the
commonly used business terms. These requirements were revised to exclude
the specification information (e.g., an exhaustive list of query parameters),
because the precise data object names will be included in the data mapping
matrix of a data exchange specification.
8. Some proposed and previously issued requirements included a long and
exhaustive list of system data object names. Because system data object
names change more frequently than the related business terms, where
appropriate, system data object names have been replaced with collective
nouns or phrases. For example, either the phrase “vendor information” or
“payee information” is used to refer to both the “vendor id” and “vendor
name”. Exhaustive lists of data object names will be included in a
specification.
9. Requirements that included lengthy or complex clarifying statements, which
were for the purpose of facilitating a proper interpretation of the requirement
and its interrelationship with other requirements, have been replaced with
more succinct requirements. The redacted clarifications will be transferred to
an appropriate specification, standard business process or use case. Abridging
the language of these requirements so that they no longer contain standard
business process or use case information improves their clarity.
Note that there are a few instances where the above rules were not applied. For
example, one notable set of exceptions exists within the technical requirements. Some
technical requirements include specification information, because technical
specifications will not be developed. Therefore, some essential specification
information had to remain within some of the technical requirements.
6.4
EXTERNAL DOCUMENT LINKS
Each requirement functional group or classification contains links to external files
containing the requirement statements. The requirements have been grouped into four
sets called “views”. The views are targeted to common requirement uses and are
provided to serve the needs of different groups of stakeholders. The Collaboration
and Continuous Improvement chapter of this document describes these views and
their anticipated uses in detail.
•
Master View
•
Reports View
•
Acquisition View
•
Design View
The master view contains all core financial system requirements. The reports view
includes all requirements related to the standard Federal financial management
reports described in the Reports Management Standard Business Process. The reports
Exposure Draft February 2010
19
Core Financial System Requirements
General Information about the Requirements
view also includes requirements for functionality that enables the generation of
queries and reports such as drilldown functionality. While any requirement may
influence the design of a commercially available software product, the requirements
assigned to the design view were drafted specifically for the purpose of guiding the
development of the standard Federal product configurations.
Exposure Draft February 2010
20
Core Financial System Requirements
Chapter 7
General Ledger Management Function
GENERAL LEDGER MANAGEMENT
FUNCTION
General ledger management is the central function of the core financial system. All
transactions to record financial events must post to the general ledger, regardless of
the origin of the transaction. Transactions originating in other systems may post to
the general ledger at a summary level, depending on an agency’s overall financial
management system design and need. At a minimum, however, summary transactions
must post at a level that maintains the accounting classification elements and
attributes needed to support both external and internal agency financial reporting.
The general ledger must be able to maintain account balances at several levels. It
must summarize and maintain account balances at the U.S. Government Standard
General Ledger (USSGL) account and attribute level. It must also be able to
summarize balances by accounting classification elements such as the Treasury
Account Symbol (TAS), internal fund, or organization. In addition, the general ledger
must be able to summarize balances at the USSGL account extension level (the
agency-defined general ledger subaccount level). All of these levels of summarization
comprise components of the CGAC structure.
The general ledger management function consists of the following subfunctions:
7.1
•
General ledger account definition (GLA)
•
Transaction definition (GLB)
•
General ledger updating and editing (GLC)
•
Upward/downward spending adjustment (GLD)
•
Accounting period maintenance and closing (GLF).
GENERAL LEDGER ACCOUNT DEFINITION SUBFUNCTION
The USSGL is defined in a supplement to the TFM, which includes the chart of
accounts, account descriptions and postings, accounting transactions, USSGL
attributes, and cross-walks to standard external reports. Each agency must implement
a chart of accounts that is consistent with the USSGL, but may supplement it with
agency-specific accounts (to meet agency-specific information needs) as long as they
summarize to the USSGL accounts for external reporting purposes.
7.2
TRANSACTION DEFINITION SUBFUNCTION
Each time an approved transaction is recorded in the core financial system, the
appropriate general ledger accounts for posting the transaction must be identified
according to the rules defined in the USSGL guidance. To accomplish consistent and
Exposure Draft February 2010
21
Core Financial System Requirements
General Ledger Management Function
accurate posting, the core financial system must provide the capability to define
standard transactions and business rules for use in recording like accounting events.
Standard transactions must comply with USSGL posting rules and include budgetary,
proprietary, and memorandum accounts, as applicable.
7.3
GENERAL LEDGER UPDATING AND EDITING SUBFUNCTION
To ensure the consistency and completeness of financial records, this subfunction
requires that all general ledger accounts—budgetary, proprietary, and
memorandum—referenced on a standard transaction be updated when a transaction is
input. It requires general ledger updates to be balanced at the internal fund level and
at the accounting classification level of formal funds control. Summary postings to
the general ledger must also be consistent with detailed postings to subsidiary
ledgers. Subsidiary ledgers must support the general ledger at various levels of detail,
whether totally integrated as part of the core financial system or interfaced from other
systems.
7.4
UPWARD/DOWNWARD SPENDING ADJUSTMENT
SUBFUNCTION
Accounting for upward and downward spending adjustments requires a complex
analysis of the types of adjustments made to prior-year spending documents. This
subfunction requires the system to recognize when an adjustment occurs and to
determine what type of adjustment occurred. Based on this analysis, the system must
automatically create the appropriate adjustment entry to record the financial event.
7.5
ACCOUNTING PERIOD MAINTENANCE AND CLOSING
SUBFUNCTION
This subfunction pertains to the segregation of accounting transactions into
accounting periods and the creation of closing entries at the end of a period (month or
year) for reporting. It also addresses the control and execution processes needed by
the system to open a new reporting period, such as rolling forward account balances
or reversing certain year-end entries. This subfunction supports the preparation of
consolidated financial statements by identifying information needed in that process.
7.6
EXTERNAL DOCUMENT LINK FOR GENERAL LEDGER
REQUIREMENTS
The following link provides web-based access to the requirements within this
functional group.
http://www.fsio.gov/fsio/download/systemrequirements/2010SystemRequirements/R
equirements_GL.xlsx
Exposure Draft February 2010
22
Core Financial System Requirements
Chapter 8
Reporting Management Function
REPORTING MANAGEMENT FUNCTION
Financial management reporting functionality ensures that agencies will have the
tools necessary to monitor the input, output, and operation of the core financial
system and related mixed systems, as well as to produce basic data for use by both
the agency and central reporting entities, such as OMB and Treasury. Because some
reporting requirements can be resource intensive, care must be exercised when
determining data identification, organization, and maintenance requirements, so that
both reporting and transaction processing can be satisfied. The term “reports” as used
in this chapter refers to all system outputs independent of the output format (hard
copy, email, electronic file, or online).
The reports management chapter of Standard Business Processes groups reports into
seven reporting categories:
•
Financial statements. Financial reporting in the Federal government must be
in accordance with the Chief Financial Officers Act of 1990 (CFO Act) and
the Government Management Reform Act of 1994 (GMRA). In addition, the
Office of Federal Financial Management (OFFM) specifies, in OMB Circular
A-136, the required elements and format of financial reports.
•
General ledger. General ledger reports provide information on overall
account balances and transactions supporting those account balances for an
organization.
•
Payment management. Payment management reports provide information to
support vendor maintenance, invoice tracking, disbursement monitoring, cash
flow control, and cash management decisions.
•
Receivable management. Receivable management reports provide
information to support customer maintenance, receivable tracking,
collections, delinquent account monitoring, and effective cash flow
management.
•
Reimbursable management. Reimbursable management reports provide
information to support reimbursable activity between trading partners,
including partnership agreements, work in process, and billing.
•
System management. System management reports provide information that
enables the effective control of user access, traceability of modified
transactions, and override of established system controls.
•
Treasury reporting. Treasury reports provide information to meet Federally
mandated reporting requirements and to support the management of the Fund
Balance with Treasury (FBWT) and funds held outside of Treasury.
Appendix D lists the standard reports as described in the Standard Business Process.
The core financial system requirements that support all seven reporting categories
have been organized into four reporting management subfunctions.
Exposure Draft February 2010
23
Core Financial System Requirements
8.1
Reporting Management Function
•
Validation and Reconciliation (RPA)
•
Federal Enterprise-wide Reporting (RPB)
•
User Reports Interface (RPC).
•
Report Design, Development and Maintenance (RPD)
VALIDATION AND RECONCILIATION
The requirements of this subfunction fall into one of two categories. Some of these
requirements govern the use of reports to facilitate the reconciliation or validation of
data elements or transactions to be presented in reports, while others of these
requirements concern the validation and reconciliation of the reports themselves.
8.2
FEDERAL ENTERPRISE-WIDE REPORTING
The requirements in this subfunction specifically undergird the Financial Statement
and Treasury reporting categories of the Reports Management Standard Business
Process. As new reporting needs are identified the reports management requirements,
reporting specifications and standard business process documents will be updated
concurrently to ensure consistency.
8.3
USER REPORTS INTERFACE
The requirements in the User Reports Interface subfunction concern the human to
core financial system interface. They describe desired outcomes for ease of use. They
also identify functionality that must not require developer intervention, but instead
must be accessible to the end users. For example, this subfunction includes the
requirements for ad hoc reporting and query capabilities.
8.4
REPORT DESIGN, DEVELOPMENT AND MAINTENANCE
Unlike the User Reports Interface subfunction requirements, the Report Design,
Development and Maintenance subfunction requirements concern capabilities of a
core financial system that are likely to be transparent to end users. These
requirements describe the capabilities expected to be delivered in a preconfigured
standard Federal product configuration, or that are likely to require post-installation
developer support. Included in this subfunction are requirements that govern the
robustness of the reporting engines of a core financial system.
8.5
EXTERNAL DOCUMENT LINK FOR REPORTING
MANAGEMENT REQUIREMENTS
The following link provides web-based access to the requirements within this
functional group.
http://www.fsio.gov/fsio/download/systemrequirements/2010SystemRequirements/R
equirements_RP.xlsx
Exposure Draft February 2010
24
Core Financial System Requirements
Chapter 9
Funds Management Function
FUNDS MANAGEMENT FUNCTION
Article I, section 9, of the Constitution of the United States provides that “no money
shall be drawn from the Treasury, but in Consequence of Appropriations made by
law.” From this basic provision, a body of laws and regulations has evolved to govern
the Federal budget process and prescribe procedures for obtaining, expending,
administering, and controlling budgetary resources. Federal appropriations law, U.S.
Comptroller General Decisions, and OMB Circular A-11, Preparation, Submission,
and Execution of the Budget, constitute authoritative guidance and set
governmentwide policy for funds management.
To comply with OMB Circular A-11, each agency of the Federal government is
responsible for establishing a system for ensuring that it does not obligate or disburse
funds in excess of those appropriated or authorized.2 The funds management function
of the core financial system is an agency’s primary tool for carrying out this
responsibility. In addition to supporting the governmentwide policies, the funds
management function must support agency policies on internal fund distribution and
control.
Processes used by agencies to manage funds have been defined as governmentwide
standard business processes.3 The system requirements in this document reflect the
system functions required to support the standard processes.
An agency will likely have many other systems in addition to the core financial
system that affect funds. For example, prior to receiving appropriations, budget
formulation systems and procurement and travel systems generate documents that
commit and obligate funds. These and other systems that affect funds availability
should access data in and use processes of the core financial system to verify that
funds are available and to update balances. These systems typically access the funds
availability verification activity before allowing an obligation to be incurred, such as
when entering into a contract. However, in some cases, such as payroll, this may not
be practical.
The funds management function consists of the following subfunctions:
•
Financial, operating, and spending plan development (FMA)
•
Budget authority (FMC)
•
Funds distribution (FMD)
•
Funds control (FME).
2
Budget authority may be classified in the form of appropriations, borrowing authority,
contract authority, and the authority to spend offsetting collections.
3
“Funds Management Processes,” Standard Business Processes, Version 1.2, October 2009.
Exposure Draft February 2010
25
Core Financial System Requirements
9.1
Funds Management Function
FINANCIAL, OPERATING, AND SPENDING PLAN
DEVELOPMENT SUBFUNCTION
Financial, operating, and spending plans are blueprints for using financial resources
during any given fiscal period or series of periods. Agencies differentiate between
“financial,” “operating,” and “spending” plans based on different levels of detail,
different fiscal periods covered, or other variables. OMB uses the term “plan” as
follows: “The Budget of the United States Government sets forth the President’s
comprehensive financial plan for allocation of resources for the Federal
Government,” and “before agencies can use the resources, OMB must approve their
spending plans.”4
9.2
BUDGET AUTHORITY SUBFUNCTION
Establishing budget authority is the beginning of the budget execution process. This
subfunction records budget authority by the type of authority and apportions budget
authority in accordance with the latest OMB-approved SF 132 Apportionment and
Reapportionment Schedule. Recording and apportioning of budget authority establish
legal limitations on the availability of funds and set the foundation for subsequent
distribution of budgetary resources into amounts available for obligation and
expenditure for a particular organization, purpose, or type of expenditure. This
subfunction also includes the recording of reductions in budget authority, such as the
rescission of funds.
The standard Federal financial business processes supported by this subfunction are
as follows:
9.3
•
FM 2.1 Budget Authority Process
•
FM 2.1.1 Budgetary Resources
•
FM 2.1.2 Record Application of Budgetary Resources
(Apportionment).
FUNDS DISTRIBUTION SUBFUNCTION
Funds distribution is the part of the budget execution cycle in which legally
apportioned resources are distributed within the agency to support missions,
programs, and other objectives. This subfunction establishes multiple levels of
budgetary control by allotting and suballotting apportioned resources for agency
management.
The standard Federal financial business processes supported by this subfunction are
as follows:
•
FM 2.2 Funds Distribution
4
President’s Budget, Analytical Perspectives for 2010, Chapter 25, “The Budget System and
Concepts.”
Exposure Draft February 2010
26
Core Financial System Requirements
9.4
Funds Management Function
•
FM 2.2.1 Allotment Distribution
•
FM 2.2.1.1 Allotment for (Direct) Non-Anticipated, NonReimbursable Funding
•
FM 2.2.1.2 Allotment for Anticipated Reimbursable Funding
•
FM 2.2.1.3 Allotment for Anticipated Non-Reimbursable Funding
•
FM 2.2.2 Sub-Allotment Distribution
•
FM 2.2.3 Lower Level Distribution.
FUNDS CONTROL SUBFUNCTION
Funds control prevents the obligation and expenditure of funds in excess of the
amount of funds made available through the apportionment and funds distribution
subfunction. The core financial system must be designed to apply effective funds
control at the point that spending documents are entered. A spending document is any
one of the purchase-related documents in a spending chain. Spending chain
documents include commitments, obligations, advances, receiving and acceptance
reports, payments requests (invoices), and disbursements.
This subfunction consists of the following processing activities:
•
Funds availability verification. This activity verifies that sufficient funds are
available for each processed spending transaction that affects the agency’s
available fund balances.
•
Commitments. This activity records commitments (e.g., requisitions).
Commitments allow the agency to “reserve” funds before legal obligations
are established. A commitment is a useful funds control tool, but is not
appropriate for all spending situations. When an agency determines that the
use of commitments is appropriate, the core financial system must provide the
capability to apply funds control as defined in this document.
•
Obligations. This activity records obligations in the core financial system.
OMB Circular A-11 defines an obligation as a binding agreement that will
result in outlays, immediately or in the future. Budgetary resources must be
available before obligations can be legally incurred. Examples of obligations
include purchase orders, travel orders, and delivery orders.
The standard Federal financial business processes supported by this subfunction are:
•
FM 2.3 Funds Control Process
•
FM 2.3.1 Establishing Commitments and Obligations for Goods and Services
•
FM 2.3.2 Establishing Obligations Not Requiring Commitment
•
FM 2.3.3 Funds Check Prior to Obligation
Exposure Draft February 2010
27
Core Financial System Requirements
9.5
Funds Management Function
•
FM 2.3.4 Unexpired Funds Validation and Verification
•
FM 2.3.5 Expired Funds Validation and Verification.
EXTERNAL DOCUMENT LINK FOR FUNDS MANAGEMENT
REQUIREMENTS
The following link provides web-based access to the requirements within this
functional group.
http://www.fsio.gov/fsio/download/systemrequirements/2010SystemRequirements/R
equirements_FM.xls
Exposure Draft February 2010
28
Core Financial System Requirements
Chapter 10
Payment Management Function
PAYMENT MANAGEMENT FUNCTION
The payment management function consists of processes associated with receiving
goods or services that result in a payable, recording payment requests received from
vendors, and disbursing payments. The processes used by an agency to manage
payments to vendors have been defined as governmentwide standard business
processes.5 The system requirements in this document reflect the system functions
required to support the standard processes.
Depending on an agency’s system architecture, payment activities may be supported
by other systems that provide payment data to the core financial system. For example,
payroll systems usually trigger actual disbursements to employees through direct
deposit or by check and maintain the detailed information related to those
disbursements. The payroll system sends only the expense and disbursement
information to the core financial system for recording the impact on the general
ledger, funds availability balances, and cost management functions. Likewise, loan
and grant programs may be supported by systems that maintain their own information
on payees and payments and send transaction data to the core financial system.
Other systems may support activities that lead up to the payment stage, such as
recording obligations and expenditures and establishing payables, but depend on the
core financial system to manage the actual payment process itself. For example, a
travel system may calculate the amount to be paid on a travel voucher and send
transactions to the core financial system to record the expenses and a payable to the
traveler. The core financial system would then schedule the payment for
disbursement and confirm that the disbursement has been made.
The payment management function encompasses requirements related to the
processing of payee information and payment requests from non-Federal vendors.
Requirements related to the processing of interagency payments, i.e.,
Intergovernmental Payment and Collection (IPAC), are presented in the reimbursable
management section of this document.
The payment management function consists of the following subfunctions:
•
Payee information maintenance (PMA)
•
Accounts payable (PMB)
•
Payment request (PMC)
•
Disbursing (PMD)
•
Payment follow-up (PME).
5
“Payment Management Processes,” Standard Business Processes, Version 1.2, October
2009.
Exposure Draft February 2010
29
Core Financial System Requirements
10.1
Payment Management Function
PAYEE INFORMATION MAINTENANCE SUBFUNCTION
The term “payee” is used here to refer to any entity (Federal or non-Federal) to which
disbursements may be made. Payee information maintenance includes maintenance of
master data for payees such as commercial vendors (individuals and organizations
providing goods or services), employees, grant recipients, and loan recipients. Master
data related to Federal payees is covered in the reimbursable management section of
this document.
Subpart 4.11 of the Federal Acquisition Regulation (FAR) prescribes policies and
procedures for requiring contractor registration in the CCR, the common source of
payee information for commercial vendors in the Federal government. FAR requires
that prospective contractors be registered in the CCR prior to award of a contract or
agreement by the Federal government. The CCR validates the vendors’ information
and electronically shares the data with the agency finance offices to facilitate
paperless payments through electronic funds transfer (EFT). The core financial
system must accommodate the data received from the CCR and maintain current
information on these vendors.
Federal agencies that buy or sell goods or services to other Federal agencies must use
a Business Partner Network (BPN) identifier and register their BPN numbers in the
Federal Agency Registration (FedReg).6 The FedReg is a repository of Federal
agency data pertinent to procurement and payment for services and products.7 The
core financial system must accommodate the data received from FedReg and
maintain current information on these vendors. In addition, the core financial system
must maintain information on other types of payees such as employees, grantees, and
loan recipients.
10.2
ACCOUNTS PAYABLE SUBFUNCTION
This subfunction recognizes and records accrued liabilities resulting from the receipt
and acceptance of goods and services. It includes capturing information related to the
receipt of goods and services, such as dates of receipt, quantities and amounts
received, and reason codes and related descriptions when there are discrepancies
related to receipt and acceptance. The accounts payable subfunction also includes
reversing accrued liabilities when goods are rejected or returned.
The standard Federal financial business processes supported by this subfunction are
as follows:
6
7
•
PM 3.1 Receipt and Acceptance of Goods
•
PM 3.2 Receipt and Acceptance of Services.
TFM Bulletin 2007-03, “Intragovernmental Business Rules,” October 31, 2007.
Federal Agency Register (FedReg) Software User Manual (SUM), Version 5.0, October 28,
2008.
Exposure Draft February 2010
30
Core Financial System Requirements
10.3
Payment Management Function
PAYMENT REQUEST SUBFUNCTION
The payment request subfunction supports the recording of payment requests
received from vendors or other entities and the matching of these documents to
related obligation, receipt, and acceptance documents. The matching process ensures
that payments are made in accordance with contract terms and applicable regulations,
including Title 5 Section 1315 of the Code of Federal Regulations (CFR). Once
matched and approved, payment requests are warehoused in the core financial system
and await payment scheduling, which occurs when the payment due dates are
reached. Adequate internal controls must be in place to verify that goods and services
for which payment is requested were actually ordered, received, and accepted; that
proper due dates and payment amounts are computed; and that duplicate payments
are prevented.
The standard Federal financial business processes supported by this subfunction are
as follows:
10.4
•
PM 3.3 Accounts Payable and Invoicing Processes
•
PM 3.3.1 Invoice Entry
•
PM 3.3.2 Invoice Processing
•
PM 3.3.3 Credit Memo.
DISBURSING SUBFUNCTION
This subfunction supports activities required to make payments that were warehoused
or to record payments made by other systems. The core financial system must
provide the capability to prepare requests for disbursement (payment schedules) and
to create and transmit payment files in the formats required by Treasury for the
initiation of EFTs and check payments for agencies for which Treasury does the
actual disbursing. Some agencies have delegated disbursing authority and can print
checks or initiate electronic transfers themselves. Agencies with delegated disbursing
authority must comply with the requirements contained in I TFM Part 4 and all
applicable requirements in this function.
Federal payment regulations are documented in several different sources, including
5 CFR 1315 (codification of former OMB Circular A-125, Prompt Payment), which
specifies government policy for payments made to vendors against contracts. It states,
in part, that agencies must make payments on time, pay interest when payments are
late, and take discounts only when payments are made on or before the discount date
and when it is advantageous to the government.
The standard Federal financial business processes supported by this subfunction are
as follows:
•
PM 3.4 Disbursements
Exposure Draft February 2010
31
Core Financial System Requirements
10.5
Payment Management Function
•
PM 3.4.1 Disbursements for Bulk Files (ACH/EFT, CCD, CCD+, CTX, and
Checks)
•
PM 3.4.2 Disbursements for Small Volume and Same or Next Day Payments
•
PM 3.5 Returned Payments–ACH, Check, Same Day.
PAYMENT REQUEST SUBFUNCTION
This subfunction allows for agency follow-up on payments pending and
accomplished. Core financial systems must capture the information needed to track
payment requests through various stages of processing, to respond to vendor
inquiries.
10.6
EXTERNAL DOCUMENT LINK FOR PAYMENT MANAGEMENT
REQUIREMENTS
The following link provides web-based access to the requirements within this
functional group.
http://www.fsio.gov/fsio/download/systemrequirements/2010SystemRequirements/R
equirements_PM.xls
Exposure Draft February 2010
32
Core Financial System Requirements
Chapter 11
Receivable Management Function
RECEIVABLE MANAGEMENT FUNCTION
Receivables are established to account for amounts due from others as the result of
performance of services by the agency, delivery of goods sold, the passage of time
(e.g., interest earned), overpayments, or other actions. Receivables are accounted for
as assets until funds are collected or until the receivables are determined to be
uncollectible in whole or in part.
Federal debt management regulations are documented in several different sources.
The Debt Collection Act of 1982 authorized agencies to charge interest, penalties,
and administrative costs against delinquent non-Federal debtors. OMB Circular
A-129, Policies for Federal Credit Programs and Non-Tax Receivables, prescribes
policies and procedures for collecting non-tax receivables. The Debt Collection
Improvement Act of 1996 (DCIA) requires agencies to take prompt action to recover
debts, screen potential borrowers related to credit programs, and resolve outstanding
debt through various options. Treasury requires Federal agencies to report on
receivables by submitting all required information on the Treasury Report on
Receivables and Debt Collection Activities (TROR). Delinquent debt overdue by 180
days is centrally managed by Treasury. DCIA allows for referral of the delinquent
debt to the Department of Justice for litigation.
Depending on an agency’s system architecture, receivable and collection activities
may be performed directly in the core financial system or supported by other systems
that provide data to the core system. This would be particularly appropriate for
receivables resulting from large programs with complex data requirements, such as
loan programs, grant programs, or fee-for-service programs.
The receivable management function includes recording, billing, monitoring, and
collecting amounts due the government whether previously established as a
receivable or not. The system requirements in this document reflect the system
functions required to support the standard Federal financial business processes.
The receivable management function consists of the following subfunctions:
11.1
•
Customer information maintenance (RMA)
•
Receivables and billing (RMB)
•
Debt management (RMC)
•
Collections and offsets (RMD).
CUSTOMER INFORMATION MAINTENANCE SUBFUNCTION
The word “customer” is used here to include any entity—including contractors,
employees, grantees, loan recipients, and other government agencies—that owes a
debt to an agency. In the case of a duplicate or overpayment, a refund may be due
from an entity not ordinarily considered to be a customer like a vendor or payee. The
“customer” information for these entities must be available in the system to enable
Exposure Draft February 2010
33
Core Financial System Requirements
Receivable Management Function
the proper processing of receivable due to the government. Therefore, the term
“customer” in the requirements has been extended to include any entity in debt to the
agency.
This subfunction involves the maintenance of customer information (name, address,
etc.) that is needed for receivable processing, maintenance, and collection. The
subfunction ensures that customer taxpayer identification numbers (TIN) are captured
in order to report overdue receivables for potential offset and to provide for IRS
Form 1099 reporting of debts written off.
11.2
RECEIVABLES AND BILLING SUBFUNCTION
This subfunction supports activities to record receivables in the system as they are
recognized and to produce bills for amounts due to the agency.
The standard Federal financial business processes supported by this subfunction are
as follows:
11.3
•
RM 4.1 Establish Accounts Receivable Due From the Public
•
RM 4.3 Billing
•
RM 4.10 Return of a Negotiable Instrument
•
RM 4.12 Installment Plans.
DEBT MANAGEMENT SUBFUNCTION
The debt management subfunction supports activities related to analyzing accounts
receivable and managing delinquent debt. It includes aging accounts receivable;
assessing interest, penalties, and administrative charges on delinquent debt; pursuing
collection; calculating the allowance for uncollectible amounts; and recording writeoffs.
The standard Federal financial business processes supported by this subfunction are
as follows:
11.4
•
RM 4.2 Analyze Accounts Receivable
•
RM 4.6 Dunning
•
RM 4.7 Allowance for Loss on Accounts Receivable
•
RM 4.8 Write-off of Accounts Receivable
•
RM 4.11 Waiver of Interest, Administrative Costs, and Penalties.
COLLECTIONS AND OFFSETS SUBFUNCTION
The collections and offsets subfunction supports activities to record the receipt of
funds either by currency (cash, EFT) or check and the deposit of such funds in
Exposure Draft February 2010
34
Core Financial System Requirements
Receivable Management Function
accordance with Treasury and agency regulations. The process also provides for the
receipt of payment offset information from Treasury and its application to the
appropriate accounts receivable.
The standard Federal financial business processes supported by this subfunction are
as follows:
11.5
•
RM 4.4 Collection of Receipts
•
RM 4.5 Application of Receipts
•
RM 4.9 Issue Credit Memo.
EXTERNAL DOCUMENT LINK FOR RECEIVABLE
MANAGEMENT REQUIREMENTS
The following link provides web-based access to the requirements within this
functional group.
http://www.fsio.gov/fsio/download/systemrequirements/2010SystemRequirements/R
equirements_RM.xls
Exposure Draft February 2010
35
Core Financial System Requirements
Chapter 12
Cost Management Function
COST MANAGEMENT FUNCTION
The cost management function enables agencies to identify, assign, accumulate,
distribute, and report the full cost of Federal programs, including their activities and
outputs. This function allows agencies to use cost information to measure and report
on performance goals. It also provides automated mechanisms for recognizing and
reporting intragovernmental costs.
Cost management is sometimes viewed as being the same as funds management. It is
not. Cost management answers this question: “What was the total amount or quantity
of resources consumed to produce a particular output regardless of its funding
source?” In contrast, funds management during a budget execution year answers
these questions: “How much of the given budget authority was expended, when and
by whom was it expended, and what was the purpose of the expenditure?” Cost
information cannot be replaced with budget information. Likewise, budget
information is insufficient for making well-informed cost management decisions.
Similarly, financial accounting information, both budgetary and proprietary, uses the
same or similar data to provide information that differs from cost management
information. The JFMIP Managerial Cost Accounting Implementation Guide
describes the difference and interdependencies in detail.
Managerial cost accounting concepts and standards for the Federal government are
prescribed in Statement of Federal Financial Accounting Standards (SFFAS)-4,
Managerial Cost Accounting Concepts and Standards for the Federal Government,
issued by FASAB. The appendix includes other citations relevant to Federal cost
management. The cost management function of the core financial system is a critical
data source for meaningful financial accountability over public programs and for the
evaluation of the efficiency of resources used in various activities. In addition, it
provides the basis for setting fees and prices for services or products provided by a
Federal agency. It should also provide a basis for linking operational results to the
budget and performance measures. The level of rigor needed with respect to cost
management will vary depending on the nature of an agency’s programs. For
example, if an agency produces a product for sale, the cost function may be fairly
complex and accomplished in a separate managerial cost accounting system that is
integrated with the core financial system.
The cost management section of this document describes requirements for managerial
cost accounting systems. A managerial cost accounting system must be closely
interoperable with a core financial system, but need not be an integrated component
of a core financial system. Nonetheless, each commercially available product having
a cost component must demonstrate a capability to satisfy the cost management
functional requirements whether or not their Federal customers intend to use it.
SFFAS-4 requires that cost information developed for various purposes to be drawn
from common data sources and that the cost reports are reconcilable to each other.
Once management has identified the cost objects it needs and the corresponding
structure has been set up in the accounting system, the system accumulates cost data
Exposure Draft February 2010
36
Core Financial System Requirements
Cost Management Function
accordingly. SFFAS-4 sets forth five standard fundamental elements of managerial
cost accounting:
•
Regularly accumulating and reporting costs of activities for management
information purposes
•
Establishing responsibility segments to match costs with outputs
•
Determining full costs of government goods and services
•
Recognizing the costs of goods and services provided among Federal entities
•
Using appropriate costing methods to accumulate and assign costs to outputs.
Within a managerial cost accounting system, these processes are enabled by five
subfunctions of the cost management function:
12.1
•
Cost reporting (CMA)
•
Cost and performance measurement (CMB)
•
Cost accumulation, assignment, and distribution (CMC)
•
Cost identification (CMD)
•
Intragovernmental cost recognition (CME).
COST REPORTING SUBFUNCTION
The Cost Reporting subfunction supports management’s review of the costs of
operations and performance of programs. It also provides relevant and reliable cost
information to assist the Congress and the executive branch with making decisions
about allocating Federal resources, authorizing and modifying programs, and
evaluating program performance. The requirements in this subfunction seek to ensure
consistency between costs reported in general-purpose financial reports and costs
reported to program managers.
The core financial system should be able to produce the Statement of Net Cost for the
agency’s financial statements, the Comparative Income Statement by Cost Object,
and the Cost Object Income Statement
12.2
COST AND PERFORMANCE MEASUREMENT SUBFUNCTION
The Cost and Performance Measurement subfunction requirements address the
increasing need for agencies to describe and evaluate program performance in terms
of the effective and efficient use of all applicable Federal resources. These
requirements undergird both the Federal enterprise and agency-specific needs to
evaluate program performance for a cost perspective. They allow for the development
and maintenance of cost measures and the association of cost information with other
financial and nonfinancial information.
Exposure Draft February 2010
37
Core Financial System Requirements
12.3
Cost Management Function
COST ACCUMULATION, ASSIGNMENT AND DISTRIBUTION
SUBFUNCTION
After the Cost Identification subfunctions are performed, the costs identified must be
related to outputs. The Cost Accumulation, Assignment and Distribute subfunction
requirements concern the system support functions necessary to relate costs to
outputs on a reasonable or cause-and-effect basis by responsibility segment, program
and activity. These requirements trace and track cost data using agency-specific cost
object values required for cost management reports. SFFAS 4, under “Costing
Methodology,” describes several costing methods that can be used, but it does not
prescribe the use of any particular method.
12.4
COST IDENTIFICATION SUBFUNCTION
As previously stated, SFFAS-4 sets forth a standard fundamental element of
managerial cost accounting, which specifies that agencies are to determine the full
costs of government goods and services. To determine the full costs of government
goods and services, agencies must even recognize costs incurred from sources outside
their control. The requirements of the Cost Identification subfunction relate to the
establishment of cost objects related to responsibility segments, programs, activities
and outputs, so that the full costs of government goods and services may be
associated with outputs.
12.5
INTRAGOVERNMENTAL COST RECOGNITION
There are special policies and practices related to the recognition of unreimbursed
costs incurred by one agency on behalf of another agency. For example, Federal
retiree compensation is centrally funded, accounted for and managed. However, the
costs of retiree compensation are attributable to the agency or agencies that benefited
from each retired Federal employee’s years of service. In addition, full cost
projections should include the cost of retiree compensation that will result from
current or planned agency hiring actions. The Intragovernmental Cost Recognition
subfunction includes core financial system requirements that support the recognition
of intragovernmental costs.
12.6
EXTERNAL DOCUMENT LINK FOR COST MANAGEMENT
REQUIREMENTS
The following link provides web-based access to the requirements within this
functional group.
http://www.fsio.gov/fsio/download/systemrequirements/2010SystemRequirements/R
equirements_CM.xls
Exposure Draft February 2010
38
Core Financial System Requirements
Chapter 13
Fund Balance with Treasury Management Function
FUND BALANCE WITH TREASURY
MANAGEMENT FUNCTION
The FBWT represents the money an agency can spend on future authorized
transactions. Agencies record transactions that increase and decrease their FBWT to
USSGL account 1010 in their general ledger. Appropriation warrants, nonexpenditure
transfers, collections, and disbursements are some of the transactions that affect an
agency’s FBWT.
The FBWT function supports Treasury’s modernization initiative called the
Governmentwide Accounting and Reporting Modernization (GWA) Project. The
project addresses agency procedures for reporting and reconciling transactions for the
cash and monetary assets of the Federal government.
The FBWT management function consists of the following subfunctions:
13.1
•
Treasury information maintenance (FBA)
•
Payment and deposit confirmation (FBB)
•
FBWT reconciliation and reporting (FBC).
TREASURY INFORMATION MAINTENANCE SUBFUNCTION
Most Federal agencies process large volumes of transactions that affect their FBWT.
To facilitate automatic reconciliations with Treasury, an agency must classify FBWT
transactions using Treasury-defined codes. The Treasury information maintenance
subfunction ensures that the classification structures and valid data element
relationships, e.g., TAS and Business Event Type Code (BETC), are in place for an
agency’s system to use to classify and identify transactions that affect the FBWT.
13.2
PAYMENT AND DEPOSIT CONFIRMATION SUBFUNCTION
This subfunction enables agencies to update payment and collection records upon
notification from Treasury that payments and collections have been completed and
processed on its behalf. The process begins after an agency has recorded an initial
disbursement-in-transit or deposit. Once Treasury confirms the completed
transaction, it notifies the agency. The agency must make appropriate updates to the
general ledger and capture information such as the date of confirmation and any
relevant reference numbers.
Payment and deposit confirmation data are critical in reconciling the FBWT and
answering any vendor or customer questions concerning payments made or
collections received. Because of the high volume of payments and collections that
most Federal agencies process, this subfunction must ensure that an automated
process is in place to receive and update confirmation data.
Exposure Draft February 2010
39
Core Financial System Requirements
13.3
Fund Balance with Treasury Management Function
FBWT RECONCILIATION AND REPORTING SUBFUNCTION
Reconciling the FBWT is a complex, multistep process that involves an exchange of
information between an agency and the Treasury. Each agency provides Treasury
with the proper classification information (e.g., TAS and BETC) for its receipt and
disbursement activity. Treasury provides the agency with detailed lists of receipt and
disbursement activity that the agency must compare to the detailed transactions
recorded in its general ledger. The FBWT reconciliation and reporting subfunction
facilitates the comparison of transactions at this detailed level.
13.4
EXTERNAL DOCUMENT LINK FOR FUND BALANCE WITH
TREASURY REQUIREMENTS
The following link provides web-based access to the requirements within this
functional group.
http://www.fsio.gov/fsio/download/systemrequirements/Requirements_FB.xls
Exposure Draft February 2010
40
Core Financial System Requirements
Chapter 14
Cross-Functional Classification
CROSS-FUNCTIONAL CLASSIFICATION
The cross functional requirements ensure that the capabilities exist to capture,
classify, process, and report the financial activity of Federal agencies. This
classification establishes the framework for sharing data among components of an
agency’s single integrated financial management system. This function also ensures
that transactions are processed consistently and completely and that appropriate audit
trails are maintained.
These requirements consist of the following sub-classifications:
14.1
•
Accounting classification (XFA)
•
Document referencing and modification (XFC)
•
System-generated transactions (XFD).
ACCOUNTING CLASSIFICATION MANAGEMENT
An accounting classification structure comprises the data elements used for
categorizing financial transactions along several dimensions that enable retrieval,
summarization, and reporting of information in a meaningful way. The accounting
classification sub-classification provides the means for this categorization.
The CGAC structure establishes the standard for classifying the financial effects of
government business activities. The CGAC structure document is located at
http://www.fsio.gov/fsio/fsiodata/fmlob_cgac.shtml. It provides the name, definition,
authoritative source, and minimum field size of classification data elements to be
used by all Federal agencies in their core financial systems. At the same time, the
CGAC structure provides flexibility for agency mission-specific needs
The accounting classification management provides a consistent basis for the
following activities:
•
Maintaining an accounting classification structure appropriate to the Federal
agency
•
Capturing financial activity with all of the data necessary to identify the
funding used; the organization charged; the type of expense, asset, or liability
affected; and the program or project involved
•
Recording data at the lowest level of detail and summarizing or rolling it up
to higher levels in a standardized manner for reporting
•
Comparing and combining similar programs across agencies and calculating
overall program results
•
Integrating budget and accounting activities by synchronizing their
accounting classifications and relationships.
Exposure Draft February 2010
41
Core Financial System Requirements
14.2
Cross-Functional Classification
DOCUMENT REFERENCING AND MODIFICATION
These requirements define the relationships that must exist between the documents in
a processing chain. An example of a processing chain is the Federal spending chain in
which a commitment of funds moves to an obligating document (e.g., contract or
purchase order), to the acknowledgment of goods or services received and accepted,
and finally to the resulting payment. As each successive event is recorded, it
references the document of the previous event’s document, inheriting information
from the previous document and updating it accordingly. The document referencing
and modification classification also describes the types of document amendments that
must be accommodated by the core financial system.
14.3
SYSTEM-GENERATED TRANSACTIONS
The initial source of core financial system activity may be any one of the following:
online data entry, other systems or modules, or system-generated transactions.
System-generated transactions include recurring entries (and reversals), closing
entries, cost assignment entries, and transactions generated by other transactions.
Agencies define these entries in advance, specifying the debits and credits, the date or
frequency of the entry, and business rules that trigger the entry. System-generated
transactions are then recorded automatically by the core financial system on the
specified dates, based on the passage of time.
14.4
EXTERNAL DOCUMENT LINK FOR CROSS-FUNCTIONAL
REQUIREMENTS
The following link provides web-based access to the requirements within this group.
http://www.fsio.gov/fsio/download/systemrequirements/2010SystemRequirements/R
equirements_XF.xlsx
Exposure Draft February 2010
42
Core Financial System Requirements
Chapter 15
Reimbursable Management Function
REIMBURSABLE MANAGEMENT FUNCTION
Reimbursable management refers to the capabilities specific to recording, executing,
and reporting on transactions for the exchange of goods and services between a buyer
and seller (sometimes referred to as trading partners) under a reimbursable
agreement. Most reimbursable agreements are between Federal agencies in which one
Federal agency (the seller) supplies goods and services to another Federal agency (the
buyer). However, reimbursable agreements can also exist between a Federal agency
and a non-Federal entity. The term “interagency agreement” is used when referring
specifically to a reimbursable agreement between Federal agencies.
This chapter covers capabilities related to both interagency agreements between
Federal agencies and reimbursable agreements with non-Federal entities. This chapter
also covers activity related to both the buyer side and the seller side of a reimbursable
agreement.
The reimbursable management function consists of the following subfunctions:
15.1
•
Reimbursable customer and payee maintenance (RBA)
•
Establishment of reimbursable agreement (RBB)
•
Billing, collections, and payments under reimbursable agreements (RBC).
•
Inter-agency agreements, transactions and data exchanges (RBD)
REIMBURSABLE CUSTOMER AND PAYEE MAINTENANCE
This subfunction includes maintenance of master data specific to Federal customers
and payees. Most of the information maintained is obtained from FedReg. Master
data related to commercial and non-Federal customers and payees are covered in the
receivable management and payment management chapters in this document.
The term “payee” is used here to refer to an entity to which disbursements may be
made (the seller). The term “customer” is used here to refer to an entity that owes a
debt to the agency (the buyer).
Federal agencies that buy or sell goods or services to other Federal agencies must use
a BPN identifier and register their BPN numbers in the FedReg.8 The FedReg is a
repository of Federal agency data pertinent to procurement and payment for services
and products.9 The core financial system must accommodate the data received from
FedReg and maintain current information on these vendors.
8
9
TFM Bulletin 2007-03, “Intragovernmental Business Rules,” October 31, 2007.
Federal Agency Register (FedReg) Software User Manual (SUM), Version 5.0, October 28,
2008.
Exposure Draft February 2010
43
Core Financial System Requirements
15.2
Reimbursable Management Function
ESTABLISHMENT OF REIMBURSABLE AGREEMENT
This subfunction addresses the establishment of a reimbursable or interagency
agreement ensuring that all data elements necessary for tracking the agreement are
captured by the system.
15.3
BILLING, COLLECTIONS, AND PAYMENTS UNDER
REIMBURSABLE AGREEMENTS
This subfunction covers capabilities related to the execution of a reimbursable
agreement by both the seller and the buyer. Activities of the seller include billing and
collecting under a reimbursable agreement. Activities of the buyer include obligating
and disbursing monies under a reimbursable agreement. Some activities that are not
unique to reimbursable management, such as obligating funds are covered by other
subfunctions and not duplicated in this subfunction. This subfunction also covers the
processing of collections and payments.
15.4
INTRA-AGENCY AGREEMENTS, TRANSACTIONS AND DATA
EXCHANGES
The requirements in this subfunction satisfy the core financial system needs of the
reimbursable management processes unique to transactions between Federal buyers
and Federal sellers. The requirements have been engineered to support the
Reimbursables Management Standard Business Process document provisions. These
requirements have been expanded to cover data exchanges between core financial
systems and Treasury systems that process intra-agency transactions.
15.5
EXTERNAL DOCUMENT LINK FOR REIMBURSABLE
MANAGEMENT REQUIREMENTS
The following link provides web-based access to the requirements within this
functional group.
http://www.fsio.gov/fsio/download/systemrequirements/2010SystemRequirements/R
equirements_RB.xlsx
Exposure Draft February 2010
44
Core Financial System Requirements
Chapter 16
Technical Capability Function
TECHNICAL CAPABILITY FUNCTION
Technical requirements have been established to help ensure that a core financial
system is fully supported and capable of processing the workload required. It must
provide transaction processing integrity and general operating reliability; use standard
procedures for installation, configuration, and operations; provide seamless integrated
workflow processing; have the ability to query, access, and format information; and
be well documented. It must not conflict with other administrative or program
systems or with other agency-established IT standards.
The technical requirements are categorized as follows:
•
General design/architecture (TLA)
•
User interfaces (TLC)
•
Interoperability (TLD)
•
Workflow/messaging (TLE)
•
Document management (TLF)
•
Internet access (TLG)
•
Operations (TLI)
•
Ad hoc query (TLJ)
•
Documentation (TLK)
•
System performance (TLL).
Most technical requirements are stated in general terms to allow vendors maximum
flexibility in designing a compliant core financial system. Individual agencies are
encouraged to add specific interoperability, system performance, and workload
requirements considered unique to their respective IT environments when evaluating
software products for acquisition. In addition, the standard Federal business processes
and use cases include criteria that explains when to apply some technical
requirements and under what conditions. For example, core financial systems must
provide automated functionality that prevents the entry of duplicate documents.
Related standard business process threads and use cases provide the business context
for the appropriate application of the technical requirement; i.e., the basis for a
determination that an invoice document is a duplicate.
16.1
GENERAL DESIGN/ARCHITECTURE
The general design/architecture requirements relate to the overall product and its
structure at the highest level. The basic design features and system architecture
determine the adaptability of the system, such as customization and upgradability. A
Exposure Draft February 2010
45
Core Financial System Requirements
Technical Capability Function
core financial system must be designed with the flexibility to respond to the changing
Federal environment.
16.2
USER INTERFACES
User interface requirements specify how agency users and system administrators
interact with the core financial system. These requirements address the ability of
users to effectively configure the package, enter transactions, query processing
results, or start/stop internal processes.
16.3
INTEROPERABILITY
Financial transactions can be originated using multiple external feeder applications.
These feeder systems and the core financial system must interface seamlessly so that
data can move effectively between them. The core financial system must be able to
process and validate the data independent of origination. It must also be able to
validate interfaced data just as would validate the same data had it been manually
keyed into the system. For examples, interfaced invoices received "electronically"
from vendors must be processed in the same way as those received by the US mail
and then key entered. There must also be a process for handling erroneous input and
corrections.
16.4
WORKFLOW/MESSAGING
Workflow/messaging includes technical requirements that establish standards for
application interfaces and collectively define how a core financial system
automatically manages document processing; generates, builds, maps, and models
workflow processes and business rules; and notifies agency staff of pending work
(e.g., review and approval of pending accounting documents).
16.5
DOCUMENT MANAGEMENT
Document management addresses how the core financial system stores and retrieves
electronically formatted documents and related transactions. This subfunction defines
the rules for recording, editing, and processing documents and transactions that are
entered directly in the core financial system. In addition to recording these
transactions, the core financial system must be able to record and process documents
and transactions originating in other systems. All transactions must be handled
consistently, regardless of the point of origin. The core financial system must control
transactions properly to provide reasonable assurance that the funds are available,
tolerances between documents are not exceeded, data integrity is maintained, and
other transaction processing edits are met.
16.6
INTERNET ACCESS
The Internet is a vast collection of interconnected networks that communicate using
Transmission Control Protocol/Internet Protocol (TCP/IP). It has become a critical
infrastructure for application access. The technical requirements relating to Internet
Exposure Draft February 2010
46
Core Financial System Requirements
Technical Capability Function
access represent a specialized subset defining user connectivity options and security
issues.
16.7
OPERATIONS
In general, most users should be unaware of background system operations, except
for scheduled maintenance. The core financial system should run smoothly and
efficiently, and it must maintain database consistency; archive, log, and retrieve data;
stop and restart the system without losing data; and report system status.
16.8
AD HOC QUERY
Over time, demands for specific financial data are expected to change considerably as
changes occur in, for example, administrations, program missions, budget priorities,
justifications, and oversight. Ad hoc queries are often general but are critical to
enabling effective agency, program, and financial management in the face of change.
To support ad hoc queries, the core financial system must provide flexible data
access, download, and formatting.
16.9
DOCUMENTATION
To support the installation and ongoing use of a core financial system, agencies
require access to vendor system documentation. The documentation that comes with
the product is key to the effective and efficient use of the system and its appropriate
implementation and maintenance. The documentation provided with the software
product must be written at a sufficient level of detail that users who are familiar with
core financial system functions in general, but are new to the product, can understand
and use the documentation without assistance from the vendor.
16.10
SYSTEM PERFORMANCE
System performance needs to be considered when evaluating software products for
potential acquisition. System performance requirements were written without specific
(i.e., testable) performance criteria. Recognizing that delivered product performance
is dependent on agency-supplied computing infrastructure and workload, agencies
should customize these requirements, adding their own unique criteria; e.g., number
of concurrent users, geographic distribution of work sites, number of transactions,
processing windows, and volume of agency information expected to be maintained
online or archived.
16.11
EXTERNAL DOCUMENT LINK FOR TECHNICAL CAPABILITY
REQUIREMENTS
The following link provides web-based access to the requirements within this
functional group.
http://www.fsio.gov/fsio/download/systemrequirements/2010SystemRequirements/R
equirements_TL.xlsx
Exposure Draft February 2010
47
Core Financial System Requirements
Exposure Draft February 2010
Technical Capability Function
48
Core Financial System Requirements
Chapter 17
Security Control Function
SECURITY CONTROL FUNCTION
Security controls are needed to protect the confidentiality, integrity, and availability
of financial data maintained in the core financial system. To meet security
requirements, the core financial system must ensure that the management, operations,
and technical baseline security controls are implemented in accordance with current
National Institute of Standards and Technology (NIST) guidance on selecting the
appropriate security controls, including the following:
•
Federal Information Processing Standard (FIPS) 200, “Minimum Security
Requirements for Federal Information and Information Systems”
•
FIPS 199, “Standards for Security Categorization of Federal Information and
Information Systems”
•
FIPS 201, “Personal Identity Verification (PIV) of Federal Employees and
Contractors”
•
NIST Special Publication (SP) 800-37, Guide for Security Authorization of
Federal Information Systems: A Security Lifecycle Approach10
•
Other guidelines, including minimum requirements, for providing adequate
information security for all agency operations and assets as appropriate for
the specific characteristics of the system.
The system must consistently enforce the appropriate security controls in all modules,
including software used for ad hoc data query and report generators. In addition to
meeting the specified application design standards, agencies are required to comply
with the following security-related regulations and guidance:
•
Title III of the E-Government Act, of the Federal Information Security
Management Act (FISMA) of 2002 (Pub. L. 107-347) requires each Federal
agency to develop, document, and implement an agency-wide information
security program. In accordance with the provisions of FISMA, information
security must be effectively integrated into the system development life cycle.
•
Title II of the E-Government Act of 2002, Section 208, requires a Privacy
Impact Assessment (PIA) prior to developing or procuring IT systems that
collect, maintain, or disseminate information in identifiable form (IIF). All
systems must have a current PIA to ensure compliance with the Privacy Act
of 1974 and other IT privacy requirements.
NIST provides specific guidance for systems that are not national security systems.
That guidance is consistent with the requirements of OMB Circular A-130, Section
8b(3), Securing Agency Information Systems, as analyzed in Circular A-130,
10
Currently in draft
Exposure Draft February 2010
49
Core Financial System Requirements
Security Control Function
Appendix IV, “Analysis of Key Sections.” Supplemental information is provided in
OMB Circular A-130, Appendix III.
In addition, a financial system must meet various enterprise-level security
requirements and other mandated requirements in coordination with the agency that is
implementing the system to achieve certification and accreditation. For example, core
financial systems must comply with agency implementation standards for Homeland
Security Presidential Directive (HSPD) 12, “Policy for a Common Identification
Standard for Federal Employees and Contractors.” NIST security controls, such as
those specified for access control and for identity and authentication, support
HSPD 12 implementation; however, agency-defined standards must be followed.
The security requirements, which focus on application-level security, are categorized
as follows:
17.1
•
Access controls (TSA)
•
Auditing and accountability (TSB)
•
Configuration management (TSC)
•
Contingency planning (TSD)
•
Identity and authentication (TSE)
•
Media protection (TSF)
•
System and communications protection (TSG)
•
System and information integrity (TSH).
ACCESS CONTROLS
Access controls for applications relate to the granting or denying of specific requests
for obtaining and using information and to related information processing services.
17.2
AUDITING AND ACCOUNTABILITY
Audit trails provide detailed records that support transactions and balances
maintained by the core financial system. Although essential to auditors, audit trails
are equally important to agencies for day-to-day operation of the system. Audit trails
provide agencies with information necessary to reconcile accounts, research
document history, and query the data stored in the core financial system.
17.3
CONFIGURATION MANAGEMENT
Configuration management controls relate to the detailed monitoring, recording, and
updating of information that describes an enterprise’s computer systems and
networks, including all hardware and software components. Surveillance is done to
identify and document the functional and physical characteristics of a configuration
Exposure Draft February 2010
50
Core Financial System Requirements
Security Control Function
item, control changes to those characteristics to maintain the integrity and traceability
of the configuration, and record and report changes to processing and implementation
status.
17.4
CONTINGENCY PLANNING
Contingency planning controls relate to management policy and procedures designed
to maintain or restore business operations, including computer operations, possibly at
an alternate location, in the event of emergencies, system failures, or disaster.
17.5
IDENTITY AND AUTHENTICATION
Identity and authentication controls relate to verifying the identity of a user, process,
or device, often as a prerequisite to allowing access to resources in an information
system.
17.6
MEDIA PROTECTION
Media protection controls relate to physical devices or writing surfaces such as
magnetic tapes, optical disks, magnetic disks, memory chips, display media, and
printouts onto which information is recorded, stored, or printed within an information
system.
17.7
SYSTEM AND COMMUNICATIONS PROTECTION
System and communications protection controls relate to guarding against improper
information transmission, modification, or destruction. These controls include
ensuring that proper communication protocols and policies are followed for both
internal and external transmissions.
17.8
SYSTEM AND INFORMATION INTEGRITY
System and information integrity controls relate to guarding against improper
information modification or destruction and ensuring information nonrepudiation and
authenticity.
17.9
EXTERNAL DOCUMENT LINK FOR SECURITY CONTROL
REQUIREMENTS
The following link provides web-based access to the requirements within this
functional group.
http://www.fsio.gov/fsio/download/systemrequirements/2010SystemRequirements/R
equirements_TS.xlsx
Exposure Draft February 2010
51
Core Financial System Requirements
Appendices
APPENDICES
Exposure Draft February 2010
52
Core Financial System Requirements
Appendix A: Changes to Core Financial System Requirements
Appendix A CHANGES TO CORE FINANCIAL SYSTEM
REQUIREMENTS
The Federal government has been using automated systems to support accounting and
financial management for years. Federal financial management requirements were
defined as agencies sought to acquire software products that would most closely fit
their business needs. In 1988, JFMIP brought together requirements that had been
defined by many agencies into a single set and published them as Core Financial
System Requirements. Since then, JFMIP and its successor organization, FSIO,
published requirements in 1994, 1999, 2001, and 2006. This document represents the
most recent update to the requirements.
The current compliant vendor products have been tested against the 2001
requirements and some 2006 requirements, as documented in the “Core Financial
System Requirements, Tested” spreadsheet posted at www.fsio.gov. In the next test
cycle, products will be tested against 2009 requirements (as well as any 2006
requirements that have not been updated). Once products are qualified, agencies are
expected to implement the qualified products in order to comply with the 2009
requirements.
Changes have been made to this document for the following reasons:
•
To align the requirements with Standard Business Processes, published by
FSIO under the FMLoB. This document reflects changes made to
requirements to align with the standard business processes for funds
management, payment management, receivable management, and
reimbursable management. Changes to requirements resulting from
standardization of reports management will be reflected in a subsequent
publication.
•
To allow requirements to stand alone. Each requirement begins with an
introductory phrase in order that each requirement may stand alone outside
the context of this document. The standard introductory phrases for the
functional requirements may be found in Appendix C.
•
To distinguish between the system functionality needed by Federal agencies
and the functional specifications. The functional specifications will be
provided in a separate functional specifications document, which will provide
details about how the system is expected to perform and establish a baseline
standard Federal configuration for each financial management product against
which it can be assessed and certified. This is the level at which compliance
can be monitored.
•
To remove budget formulation requirements in recognition of their ownership
by the budget community and the Budget Formulation and Execution Line of
Business.
Exposure Draft February 2010
53
Core Financial System Requirements
Appendix A: Changes to Core Financial System Requirements
•
To remove value-added requirements. All of the requirements in this
document are mandatory.
•
To reorganize requirements into more logical groupings. Requirements
related to reimbursable management and financial reporting have been moved
to separate sections.
•
To improve traceability between requirement versions. The same requirement
number has been used for requirements not substantially changed. Deleted
requirement numbers were reused. As a result, new requirements may not be
in a logical sequence. Requirements will be resequenced once a requirements
management database system has been established.
•
To standardize terminology between this document and two other FMLoB
documents—Common Government-wide Accounting Classification Structure
and Standard Business Processes—as well as between FMLoB and other
Federal lines of business.
•
To provide better detail for compliance with Federal information security
requirements. Security requirements have been removed from Chapter 13,
Technical Capability Function, and put into a new chapter, Chapter 14,
Security Control Function, with greatly expanded detail.
Additional changes to this document include the reinsertion of the glossary and the
rewording of requirement text, wherever needed, to help clarify the intent. Several
functional areas have not been substantially changed. These include the cost
management function and the FBWT management function. The FBWT requirements
will be updated once the Department of the Treasury finalizes changes to the central
accounting systems.
Exposure Draft February 2010
54
Core Financial System Requirements
Appendix B: Accounting Standards, Laws, Regulations…
Appendix B ACCOUNTING STANDARDS, LAWS,
REGULATIONS, AND OTHER GUIDANCE
B.1
INTRODUCTION
This appendix lists governmentwide accounting standards, laws, regulations, and
other guidance that pertain to core financial system requirements. Guidance
categories are as follows:
•
Federal Legislation
•
U.S. Code
•
Statements of Federal Financial Accounting Concepts and Standards
•
Office of Management and Budget Guidance
•
Treasury Financial Manual
•
Other Federal Standards, Guidelines, and Regulations
•
Federal Financial Management System Requirements
•
Financial Management Line of Business Standards.
•
Government Accountability Office Standards.
The list is not all-inclusive and may not include citations supporting agency-specific
or program-specific mandates. It is every agency’s responsibility to comply with the
most current versions of applicable laws, regulations, and other guidance. Agencies
should note that many requirements are based on common business need in addition
to cited laws and regulations.
B.2
FEDERAL LEGISLATION
Accountability of Tax Dollars Act of 2002
Cash Management Improvement Act of 1990 (Pub. L. 101-453), extended by the
Cash Management Improvement Act Amendments of 1992 (Pub. L. 102-589)
Chief Financial Officers Act of 1990 (Pub. L. 101-576)
Clinger-Cohen Act of 1996 (Information Technology Management Reform Act,
Division E of Pub. L. 104-106)
Computer Security Act of 1987 (Pub. L. 100-235)
Debt Collection Act of 1982, as amended (Pub. L. 97-365)
Debt Collection Improvement Act of 1996 (Pub. L. 104-134)
Economy Act, 31 U.S.C. 1535
Exposure Draft February 2010
55
Core Financial System Requirements
Appendix B: Accounting Standards, Laws, Regulations…
Federal Financial Management Improvement Act of 1996 (Pub. L. 104-208)
Federal Managers’ Financial Integrity Act of 1982 (Pub. L. 97-255)
Federal Records Act of 1950, as amended (Records Management by Federal
Agencies, 44 U.S.C. 3101 et seq.)
Freedom of Information Act and Amendments of 1974 (Pub. L. 93-502)
(5 U.S.C. 52)
Government Management Reform Act of 1994 (Pub. L. 103-356)
Government Paperwork Elimination Act of 1998 (Pub. L. 105-277)
Government Performance and Results Act of 1993 (Pub. L. 103-62)
Improper Payments Information Act of 2002
Internal Revenue Service Restructuring and Reform Act of 1998 (Pub. L. 105-206)
Omnibus Reconciliation Act of 1993 (Pub. L. 103-66)
Paperwork Reduction Reauthorization Act of 1986 (Pub. L. 104-13)
Privacy Act of 1974 (Pub. L. 93-579)
Prompt Payment Act of 1982 (Pub. L. 97-177) and Amendments of 1996
(Pub. L. 100-496)
Rehabilitation Act Amendments of 1998 (Workforce Investment Act)
(Pub. L. 106-246)
Reports Consolidation Act of 2000
Sarbanes-Oxley Act of 2002 (Pub. L. 107-204)
Tax Increase Prevention and Reconciliation Act of 2005
B.3
U.S. CODE
5 U.S.C. 552 contains provisions of the Freedom of Information Act.
31 U.S.C. 1301(a) (the “Purpose Statute”) requires that monies be expended only for
the purposes for which appropriations were made.
31 U.S.C. 1341, 1342, 1349–1351, and 1511–1519 (jointly referred to as the
“Antideficiency Act”) prohibit obligating more money than an agency has or before it
gets the money, accepting voluntary services or monies not specifically allowed by
law, and obligating more money than has been appropriated or allotted in a time
period.
31 U.S.C. 1501 (the “Recording Statute”) requires that an obligation be recorded
when, and only when, it is supported by written evidence of a binding agreement (an
offer and its acceptance) for goods or services for a purpose authorized in the
appropriation.
31 U.S.C. 1502 (a) (the “Bona Fide Needs Statute”) requires that obligations against
an appropriation be limited to a specific time period and that obligations be charged
to the appropriation in force when the obligation is made.
31 U.S.C. 1551–1557 (Closed Accounts subchapter) contains the M-year legislation,
which requires that all Federal agencies close fixed-year appropriation accounts and
cancel any remaining balances by September 30th of the 5th year after the period of
availability began.
Exposure Draft February 2010
56
Core Financial System Requirements
Appendix B: Accounting Standards, Laws, Regulations…
31 U.S.C. 3302 (b) (the “Miscellaneous Receipts (Deposit) Statute”) requires that,
except for trust funds and revolving funds, collected monies from any source be
deposited in the Treasury as soon as practicable without deduction for any charge or
claim.
31 U.S.C. 3512 requires the head of each executive agency to establish and maintain
systems of accounting and internal control designed to provide effective control over,
and accountability for, all assets for which the agency is responsible.
31 U.S.C. 3701, 3711, and 3716–3720A–E authorize the Federal government to
employ various debt collection techniques commonly available to the private sector,
including administrative offset and Federal income tax refund offset.
44 U.S.C. 3101 addresses records management within Federal agencies.
5 CFR 1315 is the codification of former OMB Circular A-125, Prompt Payment.
B.4
STATEMENTS OF FEDERAL FINANCIAL ACCOUNTING CONCEPTS
AND STANDARDS
FASAB is responsible for developing accounting standards for the U.S. Government.
These standards are recognized as generally accepted accounting principles (GAAP)
for the Federal government and are applied by Federal agencies in preparing financial
statements. FASAB publishes these standards in SFFAS, interpretations, technical
bulletins, technical releases, and staff implementation guides. In addition to the
standards, FASAB publishes SFFAC, which are not GAAP but provide a framework
of objectives and concepts describing the purpose, content, and characteristics of
information provided in Federal financial reports.
FASAB’s standards foster understandable, relevant, and reliable financial information
and reporting concerning the financial position, activities, and results of operations
for the Federal government and its departments and agencies. Furthermore, the
standards prescribe accounting systems and internal controls that help demonstrate
that Federal programs are in compliance with laws and regulations.
The following concepts and standards are particularly relevant to core financial
system requirements.
•
SFFAC 1, Objectives of Federal Financial Reporting
•
SFFAC 2, Entity and Display
•
SFFAS 1, Accounting for Selected Assets and Liabilities
•
SFFAS 4, Managerial Cost Accounting Concepts and Standards
•
SFFAS 5, Accounting for Liabilities of the Federal Government
•
SFFAS 7, Accounting for Revenue and Other Financing Sources.
Exposure Draft February 2010
57
Core Financial System Requirements
B.5
Appendix B: Accounting Standards, Laws, Regulations…
OFFICE OF MANAGEMENT AND BUDGET GUIDANCE
OMB provides guidance and standards for executive departments and agencies to
follow concerning preparation and execution of the budget, management and
implementation of financial systems, internal controls, and preparation of financial
reports:
•
OMB Circular A-11, Preparation, Submission, and Execution of the Budget,
provides guidance on preparing and submitting materials to OMB in support
of agency budget requests and includes instructions on budget execution. It
provides guidance on the apportionment and reapportionment process, the
report on budget execution and budgetary resources (SF 133), and a checklist
for fund control regulations. It establishes formats and values for
classification elements such as budget accounts, subfunction classes, and
object classes used for reporting budget data through the OMB MAX A-11
Data Entry System (MAX).
•
OMB Circular A-127, Financial Management Systems, prescribes policies
and standards for executive departments and agencies to follow when
managing their financial management systems. This circular requires agencies
to use a FSIO-certified core financial system that is a COTS system, to use a
certified configuration, to adopt standard financial business practices,11 and to
use financial management SSPs to implement and maintain their core
financial system. In addition, the circular includes and clarifies the guidance
for reporting substantial compliance with FFMIA.
•
OMB Circular A-123, Management’s Responsibility for Internal Control,
requires internal controls to be in place over information systems. These
controls include ensuring that transactions are properly authorized and
processed accurately and that data are valid and complete. Controls should
also be established in the applications interface to verify the data input and
output.
•
OMB Circular A-130, Management of Federal Information Resources,
requires agencies to use COTS software to reduce costs, improve the
efficiency and effectiveness of financial system improvement projects, and
reduce the risks inherent in developing and implementing a new system. It
also provides guidance on collecting and managing information and records,
as well as on managing information systems and information technology.
•
OMB Circular A-136, Financial Reporting Requirements, provides guidance
on preparing an agency’s Performance and Accountability Report and the
Agency Financial Report. It also provides guidance on the form and content
of annual financial statements.
11
The standard business processes are defined by FSIO in Standard Federal Financial Business
Processes Document.
Exposure Draft February 2010
58
Core Financial System Requirements
Appendix B: Accounting Standards, Laws, Regulations…
Many of the standards and policies reflected in these OMB circulars, especially with
respect to funds control, budget execution, internal controls, and preparation of
financial statements, are incorporated into Core Financial System Requirements.
Financial management guidance is also provided in OMB Circular A-25, User
Charges, and OMB Circular A-134, Financial Accounting Principles and Standards.
B.6
TREASURY FINANCIAL MANUAL
Treasury’s FMS publishes the TFM, which provides guidance to Federal agencies on
central accounting and reporting and on other fiscal matters. The underlying purpose
of Treasury’s guidance is to make it possible to consolidate accounting results of all
agencies and to report on the financial operations of the Federal government. Two
parts of the TFM are of particular relevance to the core financial system:
•
Volume I, Part 2, includes requirements for the form, content, and submission
of financial data required by FMS.
•
TFM Supplement S2 09-02, U.S. Government Standard General Ledger,
provides a uniform chart of accounts and standard posting logic (transaction
codes) for recording financial events across government. The USSGL also
includes cross-walks that map the general ledger accounts to standard
external reports required by OMB and FMS.
Key sections of the TFM include the following:
•
I TFM 2-3100, Instructions for Disbursing Officers’ Reports
•
I TFM 2-3300, Statement of Transactions (FMS 224) Reporting by Agencies
for which the Treasury Disburses
•
I TFM 2-4100, Debt Management Reports
•
I TFM 2-4700, Agency Reporting Requirements for the Financial Report of
the United States Government
•
I TFM 4-2000, Payment Issue Disbursing Procedures
•
I TFM 4-7000, Cancellations, Deposits, and Claims for Checks Drawn on the
U.S. Treasury
•
I TFM 6-3100, Certifying Payments and Recording Corresponding
Intragovernmental Receivables in the Federal Government’s Judgment Fund
•
I TFM 6-4000, Intra-Governmental Payment and Collection (IPAC) System
•
I TFM 6-5000, Administrative Accounting Systems Requirements in Support
of the Debt Collection Improvement Act of 1996
•
I TFM 6-5100, Recovering Unclaimed Federal Financial Assets
Exposure Draft February 2010
59
Core Financial System Requirements
B.7
Appendix B: Accounting Standards, Laws, Regulations…
•
I TFM 6-8040, Disbursements
•
I TFM 6-8500, Cash Forecasting Requirements
•
TFM Supplement S2 09-02, U.S. Government Standard General Ledger
•
TFM Supplement for Treasury Report on Receivables and Debt Collection
Activities.
OTHER FEDERAL STANDARDS, GUIDELINES, AND REGULATIONS
Electronic and Information Technology Accessibility Standards (issued by the
Architectural and Transportation Barriers Compliance Board) as required by Section
508 of the Rehabilitation Act (http://www.access-board.gov/508.htm)
Federal regulations established by the National Archives and Records Administration
(www.nara.gov)
Federal regulations issued by the National Institute of Standards and Technology
(www.nist.gov)
Rules related to payment formats issued by The Electronic Payments Association
(also called NACHA) (www.nacha.org)
B.8
FINANCIAL MANAGEMENT LINE OF BUSINESS STANDARDS
Common Government-wide Accounting Classification Structure, Version 1.0, July
2007
Standard Business Processes (SBP) Document Version 1.2, October 2009
B.9
GOVERNMENT ACCOUNTABILITY OFFICE STANDARDS
A Glossary of Terms Used in the Federal Budget Process, GAO-05-734SP,
September 2005 (www.gao.gov/legal/resources.html)
GAO Standards for Internal Control in the Federal Government (Green Book)
AIMD-00-21.3.1, November 1999 (http://www.gao.gov/products/AIMD-00-21.3.1)
Government Auditing Standards (Yellow Book), GAO-07-731G, July 2007
(http://www.gao.gov/govaud/ybk01.htm)
Principles of Federal Appropriations Law (Red Book), Vols. I–III
(www.gao.gov/legal/resources.html)
Exposure Draft February 2010
60
Core Financial System Requirements
Appendix C: Requirement Writing Guidelines
Appendix C REQUIREMENT WRITING GUIDELINES
Our goal is to publish a comprehensive set of core financial system requirements that
can be easily understood and used by agencies and vendors in developing more
effective financial systems. To help achieve this goal, we have adopted standard
guidelines for writing the requirement statements. This appendix describes the
guidelines used.
C.1
REQUIREMENT INTRODUCTORY PHRASES
Each functional requirement starts with a standard introductory phrase. The terms
used in these introductory phrases convey specific meaning. Table C-1 provides a list
of the standard phrases used and explains their meaning.
Table 1. Requirement Introductory Phrases
Introductory Phrase
C.2
Explanation of Use
The system must provide the
capability to …
The capability must be delivered whether or not the agency
chooses to use it. (The capability may or may not be used
by all agencies in all implementations.)
The system must provide the
automated capability to …
The automated capability must be delivered whether or not
the agency chooses to use it. (The capability may or may
not be used by all agencies in all implementations.) The
requirement may be performed by the system without
manual intervention or may be initiated by the user.
The system must provide
automated functionality that …
The functionality must be delivered and performed by the
system in all implementations, because it is inherent in a
Federal implementation (e.g., prompt payment
functionality). However, there may be conditions under
which it is not applicable. The requirement is to be
performed by the system without manual intervention.
The system must provide the
capability to allow a user to …
The capability must be at the discretion of a user; user
intervention is required.
The system must provide the
capability for a user with special
authorization to …
The capability must be delivered, but its access is limited
to users with special authorization or privilege. Expert
knowledge is often required to effectively and correctly
trigger the system operation.
The system must be delivered
prepopulated with …
The requirement specifies governmentwide data values
that must be provided with the product.
REQUIREMENT TYPES
The requirement types found in this document are as follows:
•
Configuration requirements describe functionality needed by an agency to
establish and maintain master data, access rights, and business rules.
Exposure Draft February 2010
61
Core Financial System Requirements
C.3
Appendix C: Requirement Writing Guidelines
•
Input requirements describe the different types of information that is
captured by the system. Input requirements cover individual data items and
documents.
•
Process requirements describe automated tasks performed on financial data
as entered into the system. Processes include validating data, monitoring
funds, notifying users, performing calculations, and distributing costs.
Because process requirements cover a wide range of functionality, they are
written using a variety of standard syntax rules.
•
Report requirements describe system-generated outputs that are subject to
defined form and content rules and queries used for accessing information in
the system.
•
Interface requirements define the need to exchange data internally within the
agency or externally with a governmentwide system. An example of an
internal interface is an acquisition system that generates transactions needed
to establish commitments in the core financial system. An example of an
external interface is the generation of a payment file suitable for transmission
to Treasury’s disbursing system.
OTHER DRAFTING GUIDELINES
A key objective in drafting the requirements is to avoid ambiguous phrasing such as
“as applicable” or “as appropriate.”
Examples, when included in requirements, are not intended to be definitive. They are
used only to help clarify the intent. Examples are identified with the lead-in phrase
“for example” or “such as.”
C.4
KEY VERBS AND TERMS USED
Each requirement statement uses standard key verbs that are defined in the glossary
and used consistently in order to convey specific meaning with respect to system
capability or functionality. Appendix E, Glossary, defines these key verbs as well as
other terms that could affect the interpretation of an individual requirement.
Exposure Draft February 2010
62
Core Financial System Requirements
Appendix D: List of Reports
Appendix D LIST OF REPORTS
This appendix lists the required standard reports described in the reports management
chapter in Standard Business Processes. That document groups reports into seven
categories:
D.1
•
D.1 Financial Statements. Financial reporting in the Federal government must
be in accordance with the CFO Act and GMRA. Moreover, OMB’s OFFM
specifies, in OMB Circular A-13D, the required elements and format of
financial reports.
•
D.2 General Ledger Reports. General ledger reports provide information on
overall account balances or transactions supporting those account balances for
an organization.
•
D.3 Payment Management Reports. Payment management reports provide
information to support vendor maintenance, invoice tracking, disbursement
monitoring, cash flow control, and sound cash management decisions.
•
D.4 Receivable Management Reports. Receivable management reports
provide information to support customer maintenance, receivable tracking,
collections, delinquent account monitoring, and effective cash flow
management.
•
D.5 Reimbursable Management Reports. Reimbursable management reports
provide information to support reimbursable activity between trading
partners, including partnership agreements, work in process, and billing.
•
D.6 System Management Reports. System management reports provide
information that enables the effective control of user access, traceability of
modified transactions, and override of established system controls.
•
D.7 Treasury Reports. Treasury reports provide information to meet Federally
mandated reporting requirements and to support the management of fund
balances with Treasury and funds held outside of Treasury.
FINANCIAL STATEMENTS
Balance Sheet
Balance Sheet–Comparative Analysis
Budgetary Resources–Comparative Analysis
Changes in Net Position–Comparative Analysis
Custodial Activity–Comparative Analysis
Net Cost–Comparative Analysis
Exposure Draft February 2010
63
Core Financial System Requirements
Appendix D: List of Reports
Reconciliation of Net Cost of Operations (Proprietary) to Budget
Reconciliation of Net Cost of Operations (Proprietary) to Budgetary Accounts–
Comparative Analysis
Statement of Budgetary Resources
Statement of Changes in Net Position
Statement of Custodial Activity
Statement of Net Cost
D.2
GENERAL LEDGER REPORTS
Abnormal Balance
Budget Execution
Chart of Accounts
Daily General Ledger and Subsidiary Ledger Exception Report
Document History
General Ledger Account Activity
General Ledger Account Detailed Activity
Open Commitments
Open Obligations
Status of Funds
Suspense/Error Report
Tie Point Reconciliation
Transaction Register
Trial Balance
D.3
PAYMENT MANAGEMENT REPORTS
CCR Company Name Change Exception
Discounts Lost
Final Payment Register
Interfaced Commitment
Exposure Draft February 2010
64
Core Financial System Requirements
Appendix D: List of Reports
Interfaced Obligation
Interfaced Payment Request
IRS Form 1042
IRS Form 1099-G
IRS Form 1099-INT
IRS Form 1099-MISC
Late Payment
Payment Request Aging Report
Payment Request Date Override
Payment Notification
Payments by Vendor
Payments Exceeding Threshold Amounts
Potential 1099 Vendor Address Error
Preliminary Payment Register
Prompt Pay Metric by Payment Request Type
Statistical Sample of Invoices to be Processed for Payment
Vendor File Listing
Vendor File Modification
Vendor Notification of an Improper Payment Request
Vendor Notification of Held Payments
D.4
RECEIVABLE MANAGEMENT REPORTS
Accounts Receivable Aging
Accounts Receivable Collection Referral
Adjustments to Receivables
Allowance for Doubtful Accounts
Average Number of Days Outstanding/Late by Receivable Type
Exposure Draft February 2010
65
Core Financial System Requirements
Appendix D: List of Reports
Bill
Collections by Category
Credit Memo
Credit Memo Aging
Customer Activity
Customer File Modification
Dunning Letter
Interfaced Receivable and Collection Transactions
IRS Form 1099-C
Receivables Eligible for Referral to a Third Party Collector
Receivables Eligible for Write-off
Summary of Collections by Category
Summary of Dunning Process
D.5
REIMBURSABLE MANAGEMENT REPORTS
Earned-Unbilled
Interagency Agreement Accounting
Interagency Agreement Activity
Inventory of Interagency Agreements
Reconciliation
Summary of Interagency Agreements
Unfilled Customer Orders
Work in Process
D.6
SYSTEM MANAGEMENT REPORTS
Access by Type
Application Usage Statistics
Batch Processing
Exposure Draft February 2010
66
Core Financial System Requirements
Appendix D: List of Reports
General Ledger Posting Models
Period Status
System Audit
System Override
Transaction Suspension Report
User Status
D.7
TREASURY REPORTS
Comparison of SF 133, Report on Budget Execution and Resources, and the
Statement of Budgetary Resources
Deposit Ticket (DT) (SF 215)
FACTS I (Federal Agencies Centralized Trial Balance System)
FACTS II (Federal Agencies Centralized Trial Balance System)
Federal Transaction File
FMS 2108, Year-End Closing Statement
FMS 1219/1220, Statement of Accountability (FMS) and Transactions (FMS)
Foreign Currency Report
GFRS Statements
GTAS–Adjusted Trial Balance System
Partial 224
Partial 224–Exception Report
SF 133, Report on Budget Execution and Resources
Treasury Report on Receivables and Debt Collection Activities
Exposure Draft February 2010
67
Core Financial System Requirements
Appendix E: Glossary
Appendix E GLOSSARY
E.1
INTRODUCTION
This glossary lists and defines the key verbs used in requirement text as well as other
standard terms used throughout the document.
E.2
VERB GLOSSARY
The requirement drafting guidelines call for the use of standard verbs. The key verbs
used in the requirements are defined in alphabetical order below.
Associate
To establish a relationship between data or data records in the underlying database.
Associations may be made between master data elements for deriving data from other
data entered on a transaction or for validating for valid combinations of data on a
transaction. Associations can also be made between documents so that queries can
show all activity related to the source document.
Calculate
To compute a result based on a defined arithmetic formula.
Capture
To store new information on a record. Captured data can be entered by a user or
retrieved from other stored data (e.g., a referenced document or the payee information
file) at the time of processing a transaction. Captured data persist with the processed
record; the data do not automatically change when the underlying source of the data
changes. (For example, the payee information, such as legal name, captured on an
obligating document does not automatically change when the payee information file
is updated.) Captured data may be modified or deleted by a user with specialized
authorization.
Classify
To uniquely identify attributes of financial transactions upon entry along various
dimensions to enable retrieval, summarization, and reporting of information.
Customize
To enter or specify agency-defined text, parameters, data elements, or system
features. Customization may be done only by a user with specialized authorization.
Deactivate
To make a master data element or record inactive.
Define
To allow a user with specialized authorization to specify business rules, tolerance
levels, approval levels, access roles, workflows, or other conditional processes.
Exposure Draft February 2010
68
Core Financial System Requirements
Appendix E: Glossary
Deliver
To provide mandatory nonfunctional features within the software. For example, to
prepopulate current values for the USSGL chart of accounts.
Derive
To carry out a system function based on the application of business rules.
Determine
To require the system to choose the appropriate action based on predefined business
rules.
Display
To show data on a screen, report, or other media viewable by the user.
Distribute
To subdivide funds or costs into different amounts available to allocate across multiple
attributes or accounting lines (e.g., cost objects, allotments, interest and discount
amounts) [for a particular organization or purpose] in accordance with established
business rules.
Establish
To set up (either through direct entry or import) system referential data and master
data.
Export
To generate and transport a transaction file to an external system.
Generate
To produce an output.
Hold
To retain an unprocessed document for later completion (and correction, if
applicable) and processing.
Identify
To find or flag information based on an entered parameter or defined rule.
Import
To receive and process data from an external system.
Link
To establish a relationship between a document or document line and a prior
referenced document or document line in a document chain so that data can be
inherited by the new document and matched (if applicable), balances (quantity and
dollar amount) can be liquidated on the prior document, and queries can show all
related activity. One document may be linked to multiple documents. For example, an
obligating document may reference multiple commitment documents, commitment
document lines, and commitment accounting lines, and a commitment may be
referenced by multiple obligation documents and obligation lines.
Exposure Draft February 2010
69
Core Financial System Requirements
Appendix E: Glossary
Liquidate
To reduce the remaining balances (both dollar amount and quantity, if applicable) on
a document line. In general, liquidation occurs when a document is referenced by a
subsequent document in a document chain. However, liquidation can also occur as
the result of closing, canceling, or reducing the dollar amount or quantity on a
document.
Maintain
To store master data elements, business rules, or other data used to process
transactions.
Monitor
To compare an accumulated amount against an established limit.
Also, to watch closely for purposes of control and surveillance to support technical or
financial requirements.
Notify
To issue an electronic message, such as an email or other online message, to inform a
user or external party of an event or processing exception.
Prevent
To stop an event, such as the initiation of a process or completion of an entry, from
occurring. It is possible to override some of these events.
Record
To post a transaction into the general ledger or journal. An accounting term usually
accompanies any requirement that mandates a “record.”
Reference
To refer to a previous document or document line in a document chain in order to link
the documents.
Update
To modify a data record or balance. Updating can be done automatically by the
system or manually by a user with specialized authorization.
Validate
To confirm that data is correct, valid, or useful prior to processing. Also, known to
some as “to check against edits”. Examples of validation include verifying that data is
in a specified format, is present, falls within a specific range of valid values, does not
exceed an upper dollar limit, or conforms to certain business rules
E.3
GENERAL GLOSSARY
Accomplished Payments
A term used by Treasury and agency personnel to refer to payments submitted to
Treasury (requested by the agency) and released to the payee by Treasury or a nonTreasury disbursing office on the behalf of that agency.
Exposure Draft February 2010
70
Core Financial System Requirements
Appendix E: Glossary
Accounting Classification Structure
The data elements used for categorizing financial transactions along several
dimensions to enable retrieval, summarization, and reporting of information in a
meaningful way. An accounting classification structure is a comprehensive language
that supports the traceability and data interoperability of financial information to
support budget, financial accounting, and performance reporting requirements. It
includes multiple classification elements that allow data to be categorized along
various dimensions and analyzed from different perspectives to support a variety of
information needs.
Accounting Line
The accounting information, including accounting classification elements, general
ledger entry, and amount, related to a document or a document line.
Accounting Period
The time period in which a transaction is effective in the general ledger. In most
instances, this time period pertains to a fiscal month within a fiscal year. In some
instances, an accounting period represents a period that falls before or after the fiscal
month and is used for recording opening balances to the period or period-end
adjustments applicable to a month, quarter, or fiscal year. Accounting periods are
used to group transactions by the time period in which they are reported.
Activity
“The actual work task or step performed in producing and delivering products and
services. An aggregation of actions performed within an organization that is useful
for purposes of activity-based costing.”12 An activity in this context is not the same as
a “budget activity.” Budget activity is generally another name for a program.
Examples of activities are completing a study, preparing financial statements, and
maintaining roads.
Adjusted Trial Balance
A list of general ledger accounts and the corresponding balances (including
adjustments) submitted to Treasury as of a specific date. The total debit balances
must equal the total credit balances. In reference to FACTS (I and II) reporting, the
ATB includes USSGL attributes, and the USSGL account balances should reflect
preclosing adjusting entries.
Administrative Fee
A charge assessed to cover administrative costs incurred as a result of delinquent
debt.
Advance
Cash outlay made by a Federal entity to its employees, contractors, grantees, or others
to cover a part or all of the recipients’ anticipated expenses, as advance payments for
the costs of goods and services the entity receives, or as advance collections prior to
filling customer orders.
12
SFFAS 4.
Exposure Draft February 2010
71
Core Financial System Requirements
Appendix E: Glossary
Advance Payment
An amount paid prior to the receipt of goods, services, or other assets. Advances are
ordinarily made only to payees to whom an agency has an obligation. An advance
may not exceed the amount of the obligation.
Age Category
A classification of age assigned to receivables owed to a Federal agency (and the
Federal government’s debt portfolio). Age categories include “current” as well as the
delinquent debt age categories used by Treasury and reported on the TROR (1–90
days, 91–180 days, etc).
Agency
Any executive department, military department, government corporation,
government-controlled corporation, or other establishment in the executive branch of
the Federal government or any independent regulatory agency.
Agency Assigned
An indicator that the values used for referential data (e.g., document numbers),
master data (e.g., customer identifiers), or other supporting document information
were provided by an agency end user or generated by the system based on an agencydefined coding structure.
Agency Location Code
An identifier of the particular accounting office within an agency that reports
disbursements and collections to Treasury. The Agency Location Code (ALC) is
required when reporting transactions through Treasury governmentwide financial
systems. An ALC may report one of two ways, as either a GWA Non-Reporter or a
GWA Reporter. An ALC reporting as a GWA Reporter must also identify the source
system (business activity) that indicates which organizations are authorized to
provide TAS information on incoming daily transmissions to GWA.
Allotment
Authority delegated by the head or other authorized employee of an agency to agency
employees to incur obligations within a specified amount, pursuant to OMB
apportionment or reapportionment action or other statutory authority making funds
available for obligation.
Application (Financial or Mixed System)
A group of interrelated components supporting one or more functions and having the
following characteristics: a common database, common data element definitions,
standardized processing for similar types of transactions, and common version
control over software.
Apportionment
A distribution made by OMB of amounts available for obligation in an appropriation
or fund account into amounts available for specified time periods, programs,
activities, projects, objects, or any combinations of these. The apportioned amount
limits the obligations that may be incurred. An apportionment may be further
subdivided by an agency into allotments, suballotments, and allocations.
Exposure Draft February 2010
72
Core Financial System Requirements
Appendix E: Glossary
Appropriation
A provision of law (not necessarily in an appropriation act) authorizing the
expenditure of funds for a given purpose. Usually, but not always, an appropriation
provides budget authority.
Archived
Stored documents or records available for later retrieval.
Document
One of many kinds of tangible byproducts produced during the development of
software. Some documents (e.g., use cases, business processes, class diagrams, and
other UML models, requirements, and design documents) help describe the function,
architecture, and design of software. Other documents, such as project plans, business
cases, and risk assessments, are concerned with the process of development itself.
Audit Data
Chronological record of system activities to enable the reconstruction and
examination of the sequence of events and changes in an event.
Audit Trail
A mandatory record of system access. The record describes when access occurred,
who accessed the system, and what operations were performed, based on agencydefined performance metrics. All agency-defined transactions are recorded and
maintained securely to prevent tampering.
Automatically
The occurrence of a system process or operation that is based on defined business
rules and happens without manual intervention.
Bill
An invoice issued by a government entity (seller) to an individual, organization, or
other entity (buyer/payer) to communicate the amount owed the government to
satisfy a debt or claim and to communicate the billing terms.
Billed Receivable
An amount owed the government entity (seller) by an individual, organization, or
other entity (buyer) to satisfy a debt or claim for which the government has issued a
bill.
Billing Terms
The terms or standards the government entity (seller) negotiates with, or requires of,
an individual, organization, or other entity (buyer) for settlement of a debt or
obligation.
Borrowing Authority
A type of budget authority that permits obligations and
outlays to be financed by borrowing.
Exposure Draft February 2010
73
Core Financial System Requirements
Appendix E: Glossary
Budget
The budget of the U.S. Government, which sets forth the President’s comprehensive
financial plan for allocating resources and indicates the President’s priorities for the
Federal government.
Budget Account
An account that finances a program or activity of the Federal government. A budget
account includes the expenditure account and receipt account that are presented in the
President’s Budget. A budget account may be composed of one or more Treasury
accounts.
Budget Authority
The authority provided by law to incur financial obligations that will result in outlays.
Specific forms of budget authority include appropriations, borrowing authority,
contract authority, and spending authority from offsetting collections.
Budget Execution
Activities associated with the legal and managerial uses of budgetary resources to
achieve results that comply with the enacted budget and administration policy.
Budget execution activities include apportionments, allotments, commitments,
reprogramming actions, incurring obligations, and funds control, among other things.
See sections 120 through 150 of Part 4 of OMB Circular A-11 for a comprehensive
list of budget execution activities.
Budget Formulation
Activities undertaken to determine priorities for future spending and to develop an
itemized forecast of future funding and expenditures during a targeted period of time.
This includes the collection and use of performance information to assess the
effectiveness of programs and to develop budget priorities.
Budget Fiscal Year
The fiscal year in which an obligation is made and captured on the obligating
document. Agencies must maintain the budget fiscal year in their obligating
documents to properly use the USSGL-prescribed entries for recording both upward
and downward prior-year adjustments. Agencies must retain the budget fiscal year on
the obligating document even when the obligation remains unliquidated in a
subsequent fiscal year.
Budgetary Resource
An amount available to enter into new obligations and to liquidate them. Budgetary
resources are made up of new budget authority (including direct spending authority
provided in statute and obligation limitations) and of unobligated balances of budget
authority provided in previous years.
Bureau
A major suborganization of an agency specifically identified by OMB Circular A-11
or Treasury. Not all agencies have bureaus.
Business Event Type Code
An identifier used to classify transactions that are reported to Treasury through
Treasury governmentwide financial systems. The business event type code is used in
Exposure Draft February 2010
74
Core Financial System Requirements
Appendix E: Glossary
combination with the Treasury Account Symbol to identify the type of activity (gross
disbursement, offsetting collection, investment in Treasury securities, etc.) and the
effect of a transaction on the FBWT.
Cancelation
The process of rendering a check nonnegotiable after it has been issued and of
repaying the amount of the check (whether available or unavailable) to an
appropriation or fund account.
CA$HLINK
A Treasury system used primarily to manage the collection of U.S. Government
funds and to provide deposit information to Federal agencies.
Central Contractor Registration
The primary vendor database for all Federal agencies, maintained by the Integrated
Acquisition Environment. The CCR collects, validates, stores, and disseminates data
concerning all parties that receive payments from the Federal government. Agencies
that buy or sell goods or services to other Federal agencies are required to register in
FedReg.
Closeout (a debt)
An event that occurs concurrently with, or subsequent to, an agency decision to write
off a debt for which the agency has determined that future additional collection
attempts would be futile. At closeout, an agency reports to the IRS the amount of the
closed out debt as income to the debtor on IRS Form 1099-C, in accordance with
Treasury requirements. No additional collection action may be taken by the agency
after issuing the IRS Form 1099-C.
Collection
A transfer of money from a source outside the Federal government to an agency or to
a financial institution acting as an agent of the U.S. Government. A collection by the
government may be recorded in the budget as a receipt, an offsetting collection, or an
offsetting receipt.
Commitment
The amount of allotment or suballotment set aside in anticipation of an obligation.
Common Government-wide Accounting Classification
A standard structure to be used by all Federal agencies for classifying the financial
effects of government business activities. The CGAC document includes standard
names, definitions, and formats for the classification elements.
Compromise (a debt)
An agreement to settle a debt at a lower amount than initially claimed.
Complete
In the context of the interoperability technical requirements, the term “complete”
refers to files having the same content upon receipt as when sent; i.e., without
omission or truncations of any kind.
Exposure Draft February 2010
75
Core Financial System Requirements
Appendix E: Glossary
Confidentiality
Preservation of authorized restrictions on information access and disclosure, including
means for protecting personal privacy and proprietary information.
Continuing Resolution
Joint resolution that provides continuing appropriations for a fiscal year. Continuing
resolutions are enacted when Congress has not yet passed new appropriation bills and
a program’s appropriations are about to expire or have expired, or when the President
has vetoed congressionally passed appropriation bills.
Contract Authority
A type of budget authority that permits an agency to incur obligations in advance of
an appropriation, offsetting collections, or receipts to make outlays to liquidate the
obligations. Typically, Congress provides contract authority in an authorizing statute
to allow the agency to incur obligations in anticipation of the collection of receipts or
offsetting collections that will be used to liquidate the obligations.
Core Financial System
See Financial System.
Cost
The monetary value or quantity of resources used or sacrificed or liabilities incurred
to achieve an objective, such as to acquire or produce a good or to perform an activity
or service.
Cost Center
A logical grouping of one or more related activities or organizational units into a
common pool for the purpose of identifying the cost incurred. As an example, an
agency could collect all costs associated with a specific building into a common pool
(cost center) and then allocate the costs to specific outputs or activities.
Cost Object
Any activity, output, or item whose cost and revenue are to be measured, such as
organizational units, programs, and projects.
Customer
Any entity, including employees and other government agencies, that purchases
goods or services from the agency or that owes a debt to the agency. A vendor may
become a customer of the agency if that the agency overpays the vendor.
Disbursement
A payment made using cash, a check, or an electronic transfer in which Federal
moneys are transferred to an outside recipient or to another Federal agency.
Disbursements include advances to others, payments for goods and services received,
and other types of payments.
Disbursing Office
An office of the Treasury Financial Management Service, established to provide
disbursing services for Federal agencies. Also referred to as RFCs.
Exposure Draft February 2010
76
Core Financial System Requirements
Appendix E: Glossary
Document
The complete electronic record of related financial events. This record can include
descriptive, document, and financial data.
Document Line
A line of information about the document being recorded. The document line
includes information such as dollar amount, description, quantity, and unit price (if
applicable).
Document Number
A number or text string used to uniquely identify a document captured by the system.
Document numbers can be system generated or assigned by an end user when a new
document is entered.
Document Status
The current processing state of a document in the system.
Document Type
A document classification used to identify like accounting events—for example,
appropriations, commitments, payment vouchers, receivables, and closing entries—
processed by the system.
Electronic Funds Transfer
Any deposit or payment accomplished electronically, including wire transfers via
CA$HLINK and Taxlink, Fedwire, and Vendor Express.
Event
Any observable occurrence in a network or system.
Expended Authority
Paid and unpaid expenditures for goods and tangible property received or for services
performed by employees, contractors, vendors, carriers, grantees, lessors, or other
government organizations. Expended authority also includes amounts becoming
owed under programs for which no current service or performance is required
(annuities, insurance claims, other benefit payments, etc.).
Expenditure
The actual spending of money; an outlay.
Expense
The outflow of assets or incurrence of liabilities during a period resulting from
rendering services, delivering or producing goods, or carrying out other normal
operating activities.
Extensible Markup Language
A set of rules for encoding documents electronically. By definition, an XML
document is a string of characters. The characters that make up an XML document
are divided into markup and content.
Federal Agencies Centralized Trial-Balance System
System used by agencies to electronically transmit a preclosing adjusted trial balance
at the TAS level (FACTS II) or fund group level (FACTS I) using USSGL accounts
Exposure Draft February 2010
77
Core Financial System Requirements
Appendix E: Glossary
and other specified elements. FACTS I supports consolidated financial statement
reporting. FACTS II supports centralized budget execution reporting.
Federal Agency Registration
A requirement in OMB Memorandum M-03-01 and Treasury Financial Manual
Bulletin 2007-03, Intergovernmental Business Rules, that all Federal agencies buying
or selling goods or services to other Federal agencies register in FedReg.
Federal Limitations
Requirements set forth in OMB Memorandum A-11 Section 150 for the
Administrative Control of Funds requiring an agency's fund control system to monitor
any obligation or expenditure not to exceed the amount available in the appropriation or
fund account, the OMB apportionment or reapportionment, the allotment or suballotments made by an agency, any statutory limitations, and any other administrative
subdivision of funds made by an agency. See Limitation.
Federal Supply Classification Codes
Four-digit numeric classification codes for products, similar to Standard Industrial
Classification (SIC) codes.
Filled Customer Order
Order received from a customer for which goods or services have been provided.
Filling a customer order establishes the receivable and recognizes earnings. Also
referred to as a filled order.
Financial Event
Any activity having financial consequences to the Federal government related to the
receipt of appropriations or other financial resources; acquisition of goods or
services; payments or collections; recognition of guarantees, benefits to be provided,
or other potential liabilities; distribution of grants; or other reportable financial
activities.
Financial Management System
The core financial system and the financial portions of mixed systems necessary to
support financial management, including automated and manual processes,
procedures and controls, data, hardware, software, and support personnel dedicated to
the operation and maintenance of system functions. The following are examples of
financial management systems: core financial systems, procurement systems, loan
systems, grants systems, payroll systems, budget formulation systems, billing
systems, and travel systems.
Financial System
A core financial system. An information system that may perform all financial
functions, including general ledger management, funds management, payment
management, receivable management, and cost management. The core financial
system is the system of record that maintains all transactions resulting from financial
events. It may be integrated through a common database or interfaced electronically
to meet defined data and processing requirements. The core financial system is
specifically used for collecting, processing, maintaining, transmitting, and reporting
data regarding financial events. Other uses include supporting financial planning,
budgeting activities, and preparing financial statements. Any data transfers to the core
Exposure Draft February 2010
78
Core Financial System Requirements
Appendix E: Glossary
financial system must be: traceable to the transaction source; posted to the core
financial system in accordance with applicable guidance from the FASAB; and in the
data format of the core financial system.
Financial, Operating, and Spending Plans
Blueprints for using financial resources during any given fiscal period or series of
periods. Plans are internal to the agency and can be below the formal funds
distribution structure or beside it. They are used for tracking and reporting of actual
spending against planned spending. Agencies differentiate between “financial,”
“operating,” and “spending” plans based on different levels of detail, different fiscal
periods covered, or other variables. OMB uses the term “plan” as follows: “Congress
enacts laws that provide agencies with spending authority in the form of budget
authority. Before agencies can use the resources, OMB must approve their spending
plans.”
Financial Account
The account that collects the cost payments from a credit program account and
includes all cash flows to and from the government resulting from direct loan
obligations or loan guarantee commitments made on or after October 1, 1991.
FMS 224, Statement of Transactions
FMS 224 has been replaced with the Partial FMS 224 (P224).
Full-Time Equivalent
The basic measure of the levels of employment used in the budget. It is the total
number of hours worked (or to be worked) divided by the number of compensable
hours applicable to each fiscal year.
Fund
Resources set aside for a specific purpose. Often used interchangeably with the term
“account” when referring to the accounts established by Treasury in which
transactions are recorded and the accounts presented in the President’s Budget.
Funds Control
The mechanism, in a software product, used to keep obligations and expenditures
from exceeding apportionments and allotments or from exceeding budgetary
resources available for obligation, whichever is smaller. (No obligations should be
incurred against any anticipated budgetary resources, even if the funds are
apportioned and allotted.)
Funds Distribution
A subdivision made by an agency of the budget authority in a TAS into amounts
available for obligation. In general, funds distribution reflects a hierarchical
subdivision of funds in which the highest level represents the total budget authority
made available by an appropriation, the second level represents the OMB
apportionment of the funds, the third level represents an allotment of the funds into
amounts available for a particular organization or purpose, and successive levels
represent further subdivisions of the funds into smaller pools (e.g., suballotments).
In some agencies, a distinction is made between formal funds distribution and
informal funds distribution. Formal funds distribution is subject to the Antideficiency
Exposure Draft February 2010
79
Core Financial System Requirements
Appendix E: Glossary
Act; in other words, obligations may not exceed the amount of funds available from a
formal distribution. Formal funds distribution reflects statutory (legal) limitations.
Informal funds distribution refers to a subdivision of funds made for the purpose of
monitoring spending. Administrative limitations on the use of funds are usually an
informal funds distribution.
Future-Dated Transactions
Financial transactions that are input, held, and scheduled to be posted to a later
accounting period.
General Ledger Transaction
A balanced set of general ledger debits and credits posted as a result of agency input
of a financial event. Multiple general ledger transactions can exist for a given
document or document line.
Governmentwide Accounting and Reporting Modernization Project (GWA)
The Governmentwide Accounting and Reporting Modernization Project (also referred
to as GWAMP) addresses the central accounting and reporting functions and
processes associated with budget execution, accountability, and cash/other asset
management. This includes the collection and dissemination of financial management
and accounting information from and to federal program agencies. It also includes the
business processes in FMS that are related to ledger accounting for each
appropriation, fund, and receipt account's Fund Balance with Treasury, General
Ledger accounting for the cash and monetary assets of the government, and the
preparation of the Monthly Treasury Statement and the U.S. Government Combined
Statement and Appendix. In addition, GWA will improve information timeliness and
accuracy to support improved financial analysis and decision-making.
http://www.fms.treas.gov/gwa/
GWA Non-Reporter
A GWA Non-Reporter is identified by ALC and source system (e.g. IPAC, SPS,
CA$HLINKII) and indicates which organizations are not authorized to provide TAS
information on incoming daily transmissions to GWA. If they are a GWA NonReporter, an ALC reports through GOALS II CITRIX. An ALC may report one of
two ways as either a GWA Non-Reporter or a GWA Reporter.
GWA Reporter
A GWA Reporter is identified by ALC and source system and indicates which
organizations are authorized to provide TAS information on incoming daily
transmissions to GWA. If they are a GWA Reporter, they report through the Partial
FMS 224. GWA will collect and maintain information to create the appropriate 224
entries. The collected information will be processed through STAR. The GWA
Reporter Categories are defined by reporting system (e.g., IPAC). An ALC may
report one of two ways as either a GWA Non-Reporter or a GWA Reporter.
Historical transaction data
See Audit trail.
Imprest Fund
A fixed-cash or petty-cash fund, in the form of currency, coin, or government check,
that has been advanced as Funds Held Outside of Treasury and charged to a specific
Exposure Draft February 2010
80
Core Financial System Requirements
Appendix E: Glossary
appropriation account by a government agency official to an authorized cashier for
cash payment or other cash requirement as specifically authorized. The fund may be a
revolving type, replenished to the fixed amount as spent or used, or may be of a
stationary nature such as a change-making fund.
In Forbearance/In Formal Appeals Process
A delinquent debt that is in a formal appeals process or forbearance program. The
results of the appeal affect whether a debt is considered valid and legally enforceable,
how much of the dollar amount can be collected, or both. Debts in a formal
forbearance program represent debts that are still in negotiation.
In Foreclosure
A delinquent debt for which a notice of default has been filed.
Integrated Financial Management System
A unified set of financial systems and the financial portions of mixed systems
encompassing the software, hardware, personnel, processes (manual and automated),
procedures, controls, and data necessary to carry out financial management functions,
manage financial operations of the agency, and report on the agency’s financial status
to central agencies, Congress, and the public. “Unified” means that the systems are
planned for and managed together, operated in an integrated fashion, and linked
electronically to efficiently and effectively provide financial system support
necessary to carry out the agency’s mission and support the agency’s financial
management needs.
Integrity
The property that data have not been modified or deleted in an unauthorized and
undetected manner.
Interagency Agreement
A reimbursable agreement with another Federal agency. (See definition for
“reimbursable agreement.”)
Interest
A charge assessed when a debt is considered delinquent. The interest rate assessed is
that of the current value of funds to Treasury, i.e., the Treasury tax and loan rate.
Internal Control
A subset of management controls used to ensure the prevention or timely detection of
unauthorized acquisition, use, or disposition of the entity’s assets.
Internal Fund
A subdivision of an appropriation, receipt, or other fund account identified by a
Treasury Account Symbol, used for internal agency reporting. Could also refer to the
account as a whole.
Invoice
See Payment Request.
In Wage Garnishment
A delinquent debt for which the agency is pursuing administrative wage garnishment
(attaching money due to the debtor in order to satisfy a third-party debt).
Exposure Draft February 2010
81
Core Financial System Requirements
Appendix E: Glossary
Level of Funds Distribution
A level or layer within a hierarchical distribution of funds (budgetary resources).
Limitation
A restriction on the amount, purpose, or period of availability of budget authority.
While limitations are most often established through appropriations acts, they may
also be established through authorization legislation. Limitations may be placed on
the availability of funds for program levels, administrative expenses, direct loan
obligations, loan guarantee commitments, or other purposes. Limitations based on
language contained within appropriation or authorizing legislation are termed
“statutory limitations.” Spending limitations imposed at the department or agency
level are “administrative limitations.” Limitations may exist at any level within a
funding structure or may be imposed using an independent structure.
Master Data
Stable information that is incorporated by reference into transactions, is key to the
operation of business, and is stored in the system to support transactional processes,
operations, analysis, and reporting. Examples of master data are information about
vendors and customers, funds (e.g., appropriation symbols and validity periods), and
general ledger accounts.
Mixed System
An information system that can support both financial and nonfinancial functions.
Often referred to as a feeder system.
Module
A component of an information system that carries out a specific function or
functions and may be used alone or combined with other components.
North American Industry Classification System
Standard system used by Federal statistical agencies to classify business
establishments for the collection, analysis, and publication of statistical data related to
the U.S. business economy. Adopted in 1997 to replace the SIC system, NAICS
(pronounced Nakes) was developed under the auspices of OMB and in cooperation
with the statistical agencies of Canada and Mexico to establish a three-country
standard that allows for a high level of comparability in business statistics among the
three countries. (See the NAICS website for more information:
http://www.naics.com.)
Novation
Substitution of a new legal obligation for an old one as a result of a contractor’s legal
change of name. The following FAR clauses reference novation: 42.12 (Novation and
Change-of-Name Agreements), 42.1203 (Novation and Change-of-Name
Agreements: Processing Agreements), 42.1204 (Applicability of Novation
Agreements), 42.1205 (Novation and Change-of-Name Agreements: Agreement to
Recognize Contractor’s Change of Name), 53.242-1 (Novation and Change-of-Name
Agreements, SF 30), and 2.101 (Definition: Novation Agreement).
Object Classification
“A uniform classification identifying the obligations of the Federal government by
the types of goods or services purchased (such as personnel compensation, supplies
Exposure Draft February 2010
82
Core Financial System Requirements
Appendix E: Glossary
and materials, and equipment) without regard to the agency involved or the purpose
of the programs for which they are used.”13
Object Class Code
A code that classifies obligations by the items or services purchased by the Federal
government (e.g., personnel compensation, supplies, rent, or equipment). Object
classification is required when reporting obligations in accounts presented in the
President’s Budget. OMB establishes the standard codes, titles, and definitions of the
object class. Many agencies use an extension to the OMB object class for capturing
additional detail to support internal information needs.
Obligated Balance
The cumulative amount of budget authority that has been obligated but not yet
outlayed and also known as unpaid obligations (made up of accounts payable and
undelivered orders) net of accounts receivable and unfilled customer orders.
Obligation
A binding agreement that will result in outlays, immediately or in the future.
Budgetary resources must be available before obligations can be incurred legally.
Offset
Withholding of money payable by the government to, or held by the government for,
a person or entity to satisfy a debt that the person or entity owes the government.
OMB MAX A-11 Data Entry System
A computer system used to collect and process most of the information required for
preparing the budget. MAX collects the budget data using a series of schedules, or
sets of data, within the MAX database.
Online
A capability or function that is available on a computer or computer network (e.g.,
online display or online access) or an action accomplished on a computer (e.g., online
data entry or online approval processing).
Organization Structure
The offices, divisions, branches, etc., established within an entity based on
responsibility assignments, whether functional or program related.
Outlay
A payment to liquidate an obligation (other than the repayment of debt principal).
Outlays are the measure of government spending. Outlays generally are equal to cash
disbursements but also are recorded for cash-equivalent transactions, such as the
subsidy cost of direct loans and loan guarantees and the interest accrued on public
issues of the public debt.
Partial 224 (P224)
See Partial FMS 224.
13
Government Accountability Office, A Glossary of Terms Used in the Federal Budget
Process, September 2005, p. 70.
Exposure Draft February 2010
83
Core Financial System Requirements
Appendix E: Glossary
Partial FMS 224, Statement of Transactions (formerly known as FMS 224)
A monthly report submitted by an agency to Treasury. The FMS Partial 224 (P224)
classifies the agency’s collections, payments, and intragovernmental transactions by
Treasury Account Symbols. The P224 is used for transactions that are not submitted
through any of the Treasury governmentwide financial systems that require agencies
to provide a standard classification that includes a TAS at the inception of all
transactions.
Payment Confirmation Date
The date a check schedule was processed at Treasury and mailed or was deposited at
the payment recipient’s bank.
Payment Date
The date on which a check for payment is dated or the date an EFT payment is
deposited at the payment recipient’s bank (settlement date).
Payment Due Date
The date by which a payment must be made by an agency without incurring an
interest penalty. The payment due date is calculated in accordance with provisions of
the Prompt Payment Act.
Payment Request
An invoice or other form submitted to a government entity (buyer/payer) by an
individual, organization, or other entity (seller) requesting payment for goods and
services or reimbursement for expenses incurred. The goods and services may have
already been rendered or will be rendered in the future.
Payment Schedule
The basic disbursement voucher, SF 1166, Voucher and Schedule of Payments,
prescribed by Treasury for use by Federal Treasury-disbursing agencies to request
and schedule check and electronic payments to individuals, commercial entities, and
nonprofit entities.
Payment Terms
The terms or standards an individual, organization, or other entity (seller) negotiates
with, or requires of, a government entity (buyer/payer) for settlement of a government
debt or obligation.
Penalty
A charge assessed after a debt is delinquent for more than 90 calendar days. The rate
is set at 6 percent per annum.
Period of Availability
The period during which a Federal agency can incur new obligations, as defined in
the law appropriating the budget authority. The period of availability for incurring
new obligations is shorter than the period of availability for making disbursements,
which is covered by a general law. As indicated by the Authority Duration Code
associated with a fund, the period of availability to incur obligations is annual,
multiyear, or no-year.
Exposure Draft February 2010
84
Core Financial System Requirements
Appendix E: Glossary
Phase
A pre-defined stage or time period of a business or technology lifecycle named to
describe what activities occur during each time period. For example, some software
development lifecycle methodologies include the following phases: planning, design,
development, test, deployment, operations and maintenance, and retirement.
Posted Transaction
Data from a financial transaction that have been processed, accepted, and recorded in
the general ledger.
Prepayment
A payment made by a Federal entity to cover a certain periodic expense before the
expense is incurred.
Prior-year funds
Budgetary resources that were made available for obligation in the prior fiscal year.
Prior-year funds may be expired or unexpired (as in the case of unobligated
balances carried over from prior years in no-year funds).
Procurement Instrument Identifier (PIID)
A unique identifier assigned to each contract, purchase order, BOA, basic agreement,
and BPA reported to the FPDS. The PIID consists of alpha characters in the first
positions to indicate the agency, followed by alphanumeric characters identifying
bureaus, offices, or other administrative subdivisions. The last portion of the PIID is
numbered sequentially. The PIID may include other elements, as appropriate, such as
fiscal year. Delivery orders, task orders, and call numbers must be unique in
combination with the basic reference contract vehicle identifier. Source: FAR 4.603.
Product and Service Codes
Four-digit alphanumeric classification codes for products and services, similar to SIC
codes. The PSC manual may be found at
www.fpdsng.com/downloads/service_product_codes.pdf.
Program
“Generally, an organized set of activities directed toward a common purpose or goal
that an agency undertakes or proposes to carry out its responsibilities. Because the
term has many uses in practice, it does not have well-defined, standard meaning in
the legislative process. It is used to describe an agency’s mission, functions,
activities, services, projects, and processes.”14 “Program code” has been defined as an
element to classify obligations by program activities, to classify transactions by the
programs assessed using the Program Assessment Rating Tool, to classify
transactions by the programs reported in the agency’s financial statements, to derive
the USSGL account attributes for category B programs, or to derive the USSGL
account attributes for program report categories.
14
Government Accountability Office, A Glossary of Terms Used in the Federal Budget
Process, September 2005, p. 79.
Exposure Draft February 2010
85
Core Financial System Requirements
Appendix E: Glossary
Project
A planned undertaking of something to be accomplished or produced, or an
undertaking having a finite beginning and finite end. Examples are a construction
project, a research and development project, and a reimbursable project.
Query
A method of delivering financial information to agency users in which the user
specifies parameters and the system displays the requested data online.
Reappropriation
An extension in law of the availability of unobligated balances of budget authority
that have expired or would otherwise expire as a result of legislation enacted
subsequent to the law that provided the budget authority. A reappropriation counts as
budget authority in the year in which the balance becomes newly available for
obligation.
Reason Code
A unique character or set of characters that identifies the reason for certain
occurrences such as failed document validations, document modifications, the writeoff of receivables, and user overrides.
Receivable
A debt owed to the government.
Record
Units of related data fields (i.e., groups of data fields that can be accessed by a
program and that contain the complete set of information on particular items). Also,
the recordings of evidence of activities performed or results achieved (e.g., forms,
reports, test results), which serve as the basis for verifying that the organization and
the information system are performing as intended.
Referenced Document
A source document that is linked to a current document.
Reimbursable Agreement
A relationship under which an agency provides a product or service to another entity
(Federal or non-Federal) in return for payment. The payment made by the recipient
(buyer) represents reimbursement of the costs incurred by the provider (seller) under
the agreement.
Rejection
Action taken by the system that prevents a document from processing. Rejection is a
system response to a document failing agency-defined validations, or conditions that
result in an import failing to complete.
Requirements
Statements that describe capabilities, functionality, or operating characteristics that a
system is to provide.
Rescheduled Debt
Modified terms and conditions to facilitate repayment of a debt. This includes
establishing new terms as a result of changes in authorizing legislation. “Rescheduled
Exposure Draft February 2010
86
Core Financial System Requirements
Appendix E: Glossary
debt” may also refer to the set of repayments contractually required to be made
through the life of the debt, including principal and interest; an agreement between a
borrower and a lender that establishes the terms and conditions governing the
recovery of a debt; or the repayment stream of principal by due date and installment
amounts.
Rescission
A decision to reduce budgetary resources (new budget authority or unobligated
balances of budget authority) pursuant to the requirements of Title X of the
Congressional Budget and Impoundment Control Act of 1974.
Scheduled Payment Date
The calendar date on which a pending disbursement is scheduled (requested) to be
paid.
SF 132, Apportionment and Reapportionment Schedule
A report required by OMB (Circular A-11, Section 120) that provides information on
the sources and uses of budgetary resources. The report contains two general
sections: Budgetary Resources, and Application of Budgetary Resources. Under
Budgetary Resources are found the sources of actual and anticipated resources, as
well as actual and anticipated reductions to those resources. Under Application of
Budgetary Resources are found the intended use of the resources, whether by fiscal
quarter, activity, project, object, or a combination.
SF 133, Report on Budget Execution and Budgetary Resources
A report on the status of funds that were apportioned on the SF 132, Apportionment
and Reapportionment Schedule, and funds that were not apportioned. The SF 133
fulfills the requirements in 31 U.S.C. 1511–1514 that the President review Federal
expenditures at least four times a year. The SF 133 lists the sources of budgetary
resources, the status of budgetary resources, the change in obligated balances, and net
outlays by TAFS. The SF 133 is prepared for each unexpired and expired TAFS,
excluding clearing accounts, deposit funds, and closed TAFS. SF 133 budget
execution information is submitted electronically through Treasury’s FACTS II.
Simple Mail Transfer Protocol
A standard host-to-host mail transport protocol used by most e-mail systems to send
mail messages over the Internet from one server to another.
Spending Adjustment
An increase (upward adjustment) or a decrease (downward adjustment) to the amount
of a prior-year obligation.
Spending Authority from Offsetting Collections
A type of budget authority, provided in permanent law, that permits an agency to
credit offsetting collections to an expenditure account, to incur obligations, and to
make payments using the offsetting collections.
Spending Chain
A connected sequence of purchase-related events that have financial and budgetary
impact on a Federal agency. The sequence of events usually begins with a
commitment and ends with a payment. Data related to spending chain events,
Exposure Draft February 2010
87
Core Financial System Requirements
Appendix E: Glossary
including general ledger transactions, are captured by the core financial system in a
spending document. The following are common spending chain events:
•
Commitment of funds
•
Obligation of funds
•
Advance of funds
•
Receipt/acceptance of goods and services
•
Receipt of payment request (invoice)
•
Disbursement of funds (payment).
Spending Document
Any one of the purchase-related documents in a spending chain. Spending chain
documents include commitments, obligations, advances, receiving and acceptance
reports, payments requests (invoices), and disbursements.
Standard Generalized Markup Language
An international standard identifying the basic structural elements of a text document.
SGML addresses the structure of a document, not its format or presentation.
Standard Industrial Classification Codes
Four-digit numeric code used to classify businesses as defined by the U.S.
Department of Commerce. The first two digits correspond to major groups such as
construction and manufacturing, while the last two digits correspond to subgroups
such as constructing homes versus constructing highways. SIC is being replaced with
NAICS. See definition of North American Industry Classification System.
Standard Transaction
A predetermined set of general ledger debits and credits (posting model) used for the
consistent recording of like accounting events. Standard transactions should follow
the accepted and approved posting model established by Treasury (or other
accounting authority, when not addressed by Treasury) for recording an accounting
event. Agency-defined standard transactions are intended to accommodate agencyspecific account extensions (subaccounts) to the USSGL accounts.
Subsidiary Ledger
The detailed information that supports the balance of a summary account (control
account) in the general ledger. An example of a subsidiary ledger is the detailed
information and customer account balances that make up the accounts receivable
balance in the general ledger.
Suspended (debt)
Collection activity on a debt that is temporarily stopped for one of the following
reasons: (1) the agency cannot locate the debtor, (2) the debtor’s financial condition is
expected to improve, or (3) the debtor has requested a waiver or review of the debt.
System Administrator
A person who manages the technical aspects of a system.
Exposure Draft February 2010
88
Core Financial System Requirements
Appendix E: Glossary
System Date
The actual date a transaction is processed by the system. This date is assigned by the
computer. Because of its use in system audits, the system date may not be modified.
System Generated
Characteristic of document data, transactions, and reports that are automatically
supplied or produced by the system.
Tolerance Levels
The percentage or dollar variance amount that a related transaction can exceed a
control amount, such as the amount by which payment can exceed a referenced
receipt or obligation.
Transaction
Data from an event that has been processed, posted, or recorded in the system with a
system date.
Transaction Date
The date a transaction is effective in the general ledger (i.e., the date a financial event
is recognized). This date determines the accounting period for financial reporting.
The transaction date defaults to the system date but may be modified.
Transaction Number
A unique set of characters that identifies a specific general ledger transaction
recorded in the core financial system.
Transaction Processing Edits
Edits performed by the system to prevent transaction processing errors such as
missing data, invalid values in specific fields, and duplicate documents.
Transfer
An action in which budgetary resources are moved from one budget account to
another. Depending on the circumstances, the budget may record a transfer as an
expenditure transfer, which involves an outlay, or as a nonexpenditure transfer, which
does not involve an outlay.
Treasury Account Symbol
A group of elements that together make up the identification code assigned by
Treasury, in collaboration with OMB and the owner agency, to an individual
appropriation, receipt, or other fund account. A generic term, TAS is used to describe
any one of the account identification codes assigned by Treasury, while TAFS is used
to describe a particular type of TAS—one with budget authority. TAS and TAFS are
sometimes used synonymously.
Treasury Offset
Collection of a delinquent debt by Treasury or a non-Treasury disbursing officer
through offset of a Federal payment. Federal payments of benefits, tax refunds,
salary, or vendors are subject to offset.
Treasury Report on Receivables
A management report that informs Federal decision makers of the gross book value
of the receivables owed to Federal agencies and the status of the U.S. Government’s
Exposure Draft February 2010
89
Core Financial System Requirements
Appendix E: Glossary
debt portfolio. See Treasury Debt Management services at the Treasury website for
specific report instructions.
Undelivered Orders
The value of goods and services ordered and obligated that have not been received.
This amount includes any orders for which advance payment has been made but for
which delivery or performance has not yet occurred.
Unauthorized Access
An occurrence in which a user, legitimate or unauthorized, accesses a resource that he or
she is not permitted to use.
Unfilled Customer Order
Order received from a customer for which goods or services have not yet been
provided. Also referred to as an unfilled order. Recognition of an unfilled customer
order results in realization of previously anticipated reimbursable authority, when an
advance is not required.
United States Government Standard General Ledger
A uniform Chart of Accounts and technical guidance to be used in standardizing
federal agency accounting. The USSGL Supplement (released annually) is composed
of five major sections: Chart of Accounts, Account Descriptions, Accounting
Transactions, USSGL Attributes, and Report Crosswalks. The USSGL provides
standard posting logic (transaction codes) for recording financial events across
government and cross-walks that map the general ledger accounts to standard
external reports required by OMB and FMS.
Unobligated Balance
The cumulative amount of budget authority that is not obligated and that remains
available for obligation under law.
Upgradeable
A product line capable of migrating an operational product configuration to a more
recent release of its underlying technology without the need for an extensive
configuration or customization effort.
USSGL Account Attributes
Characteristics of a USSGL account captured and used to meet a specific reporting
requirement. Examples are Apportionment Category Code, Authority Type Code,
Current or Subsequent Code, and Direct or Reimbursable Code. Agency systems
must record transactions using USSGL account codes plus attributes in order to
capture information needed to meet external reporting requirements.
User
Individual or (system) process authorized to access an information system.
Validity Period
The period of time for which an object (master data element, allotment,
apportionment, continuing resolution, etc.) is valid.
Exposure Draft February 2010
90
Core Financial System Requirements
Appendix E: Glossary
Waiver
A forgiveness of debt. The debtor is not held responsible and is not subject to
collection efforts.
Warehoused Payment
An account payable that is awaiting payment scheduling.
Warning
Action taken by the system that requires override authority to continue processing a
document. Warning is a system response to agency-defined validation edits.
Warrant
An official document issued by the Secretary of the Treasury, pursuant to law, that
establishes the amount of money authorized to be withdrawn from the central
accounts maintained by the Treasury.
Work Order
A request of goods or services generated from within an agency, where the goods or
services are provided by that agency.
Write-off
The removal of an uncollectible amount from an entity’s actively reported
receivables. Amounts are written off when an authorized official determines that a
debt will not be repaid. Write-offs should be classified as closeout or currently not
collectible (CNC). Collection attempts continue to be made on write-offs classified as
CNC.
Exposure Draft February 2010
91
Core Financial System Requirements
Appendix F: Abbreviations
Appendix F ABBREVIATIONS
ABA
American Bankers Association
ACH
Automated Clearing House
ACR
Agency Confirmation Report
ALC
Agency Location Code
API
Application Programming Interface
ASCII
American Standard Code for Information Interchange
ATB
Adjusted Trial Balance
BEA
Budget Enforcement Act of 1990
BETC
Business Event Type Code
BOA
Basic Ordering Agreement
BPA
Blanket Purchase Agreement
BPN
Business Partner Network
C&A
Certification and Accreditation
CAGE
Commercial and Government Entity
CCD
Cash Concentration or Disbursement
CCD+
Cash Concentration or Disbursement Plus Addendum
CCR
Central Contractor Registration
CFO
Chief Financial Officer
CFO Act
Chief Financial Officers Act of 1990
CFR
Code of Federal Regulations
CGAC
Common Government-wide Accounting Classification
CMA
Cost Setup and Accumulation (Cost Management subfunction)
CMB
Cost Distribution (Cost Management subfunction)
CMC
Cost Monitoring (Cost Management subfunction)
Exposure Draft February 2010
92
Core Financial System Requirements
Appendix F: Abbreviations
COTR
Contracting Officer’s Technical Representative
COTS
Commercial Off-the-Shelf
CTX
Corporate Trade Exchange
CVFR
Current Value of Funds Rate
D&B
Dun and Bradstreet
DBA
Doing Business As
DCIA
Debt Collection Improvement Act of 1996
DO
Disbursing Office(r)
DOJ
Department of Justice
DT
Deposit Ticket
DUNS
Data Universal Numbering System
DV
Debit Voucher
EFT
Electronic Funds Transfer
EIN
Employer Identification Number
FACTS I
Federal Agencies’ Centralized Trial-Balance System I
FACTS II
Federal Agencies’ Centralized Trial-Balance System II
FAR
Federal Acquisition Regulation
FASAB
Federal Accounting Standards Advisory Board
FBA
Treasury Information Maintenance (Fund Balance with Treasury
subfunction)
FBB
Payment Confirmation (Fund Balance with Treasury subfunction)
FBC
FBWT Reconciliation and Reporting (Fund Balance with Treasury
subfunction)
FBWT
Fund Balance with Treasury
FEA
Federal Enterprise Architecture
FedReg
Federal Agency Registration (database)
FFMIA
Federal Financial Management Improvement Act of 1996
Exposure Draft February 2010
93
Core Financial System Requirements
Appendix F: Abbreviations
FFMSR
Federal Financial Management System Requirements
FIPS
Federal Information Processing Standards
FISMA
Federal Information Security Management Act
FMA
Financial, Operating and Spending Plan Development (Funds
Management subfunction)
FMC
Budget Authority (Funds Management subfunction)
FMD
Funds Distribution (Funds Management subfunction)
FME
Funds Control (Funds Management subfunction)
FMLoB
Financial Management Line of Business
FMS
Department of the Treasury Financial Management Service
FOB
Free On Board
FPDS
Federal Procurement Data System
FSC
Federal Supply Classification
FSIO
Financial Systems Integration Office
FTE
Full-Time Equivalent
FTF
Federal Transition Framework
GAO
Government Accountability Office
GAAP
Generally Accepted Accounting Principles
GFRS
Governmentwide Financial Report System
GLA
General Ledger Account Definition (General Ledger subfunction)
GLB
Transaction Definition (General Ledger subfunction)
GLC
General Ledger Updating and Editing (General Ledger subfunction)
GLD
Upward/Downward Spending Adjustment (General Ledger
subfunction)
GLF
Accounting Period Maintenance and Closing (General Ledger
subfunction)
GMRA
Government Management Reform Act of 1994
Exposure Draft February 2010
94
Core Financial System Requirements
Appendix F: Abbreviations
GOALS
Government Online Accounting Link System
GTAS
Governmentwide Treasury Account Symbol
GUI
Graphical User Interface
GWA
Governmentwide Accounting
IAS
Information Access System (GOALS II)
ID
Identification
IIF
Information in Identifiable Form
IPAC
Intergovernmental Payment and Collection
IRS
Internal Revenue Service
IT
Information Technology
JFMIP
Joint Financial Management Improvement Program
MAX
OMB MAX A-11 Data Entry System
MIME
Multipurpose Internet Mail Extensions
NACHA
National Automated Clearing House Association
NAICS
North American Industry Classification System
NARA
National Archives and Records Administration
NIST
National Institute of Standards and Technology
OFFM
Office of Federal Financial Management
OMB
Office of Management and Budget
PAM
Payment Automation Manager
PDF
Portable Document Format
PIA
Privacy Impact Assessment
PIID
Unique Procurement Instrument Identifier
PMA
Payee Information Maintenance (Payment Management subfunction)
PMB
Accounts Payable (Payment Management subfunction)
PMC
Payment Request (Payment Management subfunction)
Exposure Draft February 2010
95
Core Financial System Requirements
Appendix F: Abbreviations
PMD
Disbursing (Payment Management subfunction)
PME
Payment Follow-Up (Payment Management subfunction)
POC
Point of Contact
PPD
Prearranged Payment and Deposit
PPD+
Prearranged Payment and Deposit Plus Addendum
PSC
Product Service Code
Pub. L
Public Law
RBA
Reimbursable Customer and Payee Maintenance (Reimbursable
Management subfunction)
RBB
Establishment of Reimbursable Agreement (Reimbursable
Management subfunction)
RBC
Billing, Collections, and Payments under Reimbursable Agreements
(Reimbursable Management subfunction)
RFC
Regional Finance Center
RMA
Customer Information Maintenance Receivable Management
(subfunction)
RMB
Receivables and Billing (Receivable Management subfunction)
RMC
Debt Management (Receivable Management subfunction)
RMD
Collections and Offsets (Receivable Management subfunction)
RTN
Routing Transit Number
SAM
Shared Accounting Module
SFFAC
Statement of Federal Financial Accounting Concepts
SFFAS
Statement of Federal Financial Accounting Standards
SGML
Standard Generalized Markup Language
SIC
Standard Industrial Classification
SLA
Service Level Agreement
SMTP
Simple Mail Transfer Protocol
SPS
Secure Payment System
Exposure Draft February 2010
96
Core Financial System Requirements
Appendix F: Abbreviations
SSP
Shared Service Provider
TAFS
Treasury Appropriation Fund Symbol
TAS
Treasury Account Symbol
TCP/IP
Transmission Control Protocol/Internet Protocol
TDO
Treasury Disbursing Office
TFM
Treasury Financial Manual
TIN
Taxpayer Identification Number
TLA
General Design/Architecture (subfunction)
TLC
User Interfaces (subfunction)
TLD
Interoperability (subfunction)
TLE
Workflow/Messaging (subfunction)
TLF
Document Management (subfunction)
TLG
Internet Access (subfunction)
TLH
Security (subfunction)
TLI
Operations (subfunction)
TLJ
Ad Hoc Query (subfunction)
TLK
Documentation (subfunction)
TLL
System Performance (subfunction)
TOP
Treasury Offset Program
TROR
Treasury Report on Receivables and Debt Collection Activities
U.S.C.
United States Code
USSGL
United States Government Standard General Ledger
XFA
Accounting Classification (System Management subfunction)
XFB
Document and Transaction Control (System Management
subfunction)
XFC
Document Referencing and Modification (System Management
subfunction)
Exposure Draft February 2010
97
Core Financial System Requirements
Appendix F: Abbreviations
XFD
System-Generated Transactions (System Management subfunction)
XFE
Audit Trails (System Management subfunction)
XML
Extensible Markup Language
Y2K
Year 2000
Exposure Draft February 2010
98
Core Financial System Requirements
Appendix G: Contributors
Appendix G CONTRIBUTORS
The following organizations contributed to the development of this revision to the
Core Financial System Requirements:
•
Office of Management and Budget
•
Financial Systems Integration Office
•
Program Office Support (LMI)
In addition to the above contributing organizations, the following organizations
provided comments on the Exposure Draft:
•
•
•
CFO Act agencies
•
Department of Agriculture
•
Department of Commerce
•
Department of Defense
•
Department of Homeland Security
•
Department of Health and Human Services
•
Department of Housing and Urban Development
•
Department of the Interior
•
Department of the Treasury
•
General Services Administration
•
National Aeronautics and Space Administration
Other Federal agencies
•
Central Intelligence Agency
•
Government Accountability Office
•
Office of Management and Budget
•
United States Agency for International Development
Certified financial management software product vendors
•
Exposure Draft February 2010
CGI Federal
99
Core Financial System Requirements
•
Appendix G: Contributors
•
Digital Systems Group, Inc.
•
Oracle Corporation
•
SAP Public Services, Inc.
•
Savantage Solutions, Inc.
Other organizations
•
Exposure Draft February 2010
Booz Allen Hamilton
100