Federal

Financial
Management
System
Requirements

Core
Financial
System
Requirements

JFMIP-SR-02-01
November 2001
What is JFMIP?
The Joint Financial Management Improvement Program (JFMIP) is a joint undertaking of the
U.S. Department of the Treasury, the General Accounting Office (GAO), the Office of
Management and Budget (OMB), and the Office of Personnel Management (OPM), working in
cooperation with each other and other agencies to improve financial management practices in
the Federal Government. The Program was given statutory authorization in the Budget and
Accounting Procedures Act of 1950 (31 USC 65 as amended). Leadership and program
guidance are provided by the four Principals of the JFMIP, who are the: Comptroller General of
the United States, Secretary of the Treasury, Director of the OMB, and Director of OPM. Each
Principal designates a representative to serve on the JFMIP Steering Committee, which is
responsible for the general direction of the Program. The Executive Director of JFMIP is a
permanent member of the Steering Committee, and is also responsible for day-to-day
operations of JFMIP. Additionally, a representative from the Federal community serves on the
Committee for a 2-year term.

The Program promotes strategies and sponsors projects to improve financial management
across the Federal Government; participates in the financial management activities of central
policy organizations; and facilitates the sharing of information about good financial management
practices. Information sharing is accomplished through conferences and other educational
events; newsletters; meetings with interagency groups and agency personnel; and the Internet.

The JFMIP has managed interagency projects that developed a financial systems framework
and financial systems requirements. JFMIP has also revised the Federal Government’s
requirements definition, testing, and acquisition processes. JFMIP’s objectives are to develop
systems requirements, communicate and explain Federal and agency needs, provide agencies
and vendors with information to improve financial systems and ensure that products meet
relevant system requirements.

For information on JFMIP, call (202) 219-0526, or visit the JFMIP website:
http://www.JFMIP.gov.
Foreword

This document represents the latest update to the Core Financial System Requirements
document first issued in January 1988. This update reflects recent changes in laws and
regulations and in governmentwide reporting systems, such as the Department of Treasury’s
Federal Agencies Centralized Trial Balance System (FACTS) II system. The update also
includes the following types of changes to Core financial system requirements:

• Some existing requirements have been clarified

• Redundant or outdated requirements have been deleted

• Value-added requirements are now incorporated into this document

• The priority (mandatory or value-added) of certain requirements has been changed, and

• New requirements have been added to reflect the current needs of Federal agencies.

This document addresses the goal of the Chief Financial Officers (CFO) Council and the JFMIP
to improve the efficiency and quality of financial management in the Federal Government. It
also addresses the CFO Act of 1990, the Government Management Reform Act (GMRA) of
1994, and the Federal Financial Management Improvement Act (FFMIA) of 1996 that strongly
reaffirmed the need for the Federal Government to provide financial systems that facilitate the
effective management of Government programs and services and the proper stewardship of
public resources. In addition, it supports the Government Performance and Results Act (GPRA)
of 1993, which was enacted to improve Federal program effectiveness and public accountability
by promoting a new focus on results, service, quality, and customer satisfaction. The GPRA
requires agencies to establish performance goals to define the level of performance to be
achieved by a program activity, and to provide a basis for comparing actual program results with
the established performance goals.

The provisions in this document constitute Federal requirements for Core financial systems.
They are stated as either mandatory (required) or value-added (optional) system requirements.
Agencies must use the mandatory functional and technical requirements in planning their Core
financial system improvement projects. Value-added requirements should be used as needed
by the agency. It is the responsibility of each Agency to be knowledgeable of the legal
requirements governing its Core financial operation; therefore, agencies may develop additional
technical and functional system requirements as needed to support unique mission
responsibilities. Further, the provisions of this document supplement existing statutes,
regulations and Federal policy concerning financial management systems. In the event that a
requirement conflicts with existing agency specific statutes or regulations, the law, statute or
regulation takes precedence. Agencies must also develop strategies for interfacing or
integrating other systems with the Core financial system. As stated in the document, the use of
the term “Core financial system” is not intended to imply that a single system component
(module) must independently perform all of the functions herein required of a Core financial
system. Rather agencies are encouraged to maximize data exchange and share functionality
among system components of an integrated financial system.
Foreword

These requirements also remain the basis for the Federal Government to test compliance of
commercially available Core financial software. In fiscal year (FY) 1999, JFMIP developed a
new testing and qualification process, directly linking tests to these requirements. Also, the
testing/qualification process was separated from the acquisition phase of the software selection
process governed by the General Services Administration (GSA).

This document should be used in conjunction with JFMIP’s electronic repository, called the
Knowledgebase, which can be reached through the JFMIP website at http://www.JFMIP.gov.

The CFO Act of 1990 places specific responsibility for developing and maintaining effective
financial systems with the CFOs in Federal agencies. This update to the Core Financial System
Requirements, along with the other system requirements published by JFMIP and the
information provided in its Knowledgebase, demonstrate the commitment of the CFO
community to continually improve Federal financial systems.

We appreciate their support, and thank the CFO Council Financial Systems Committee, OMB,
the GAO, Treasury, OPM and the GSA, and other agencies that participated in improving this
document.

Karen Cleary Alderman

Executive Director
Acronyms

ACH Automated Clearing House

ALC Agency Location Code
API Application Program Interface
ATB Adjusted Trial Balance
CCD Cash Concentration or Disbursement
CCD+ Cash Concentration or Disbursement Plus Addendum
CFO Chief Financial Officer
CFR Code of Federal Regulations
CMIA Cash Management Improvement Act
CCR Central Contractor Registration
COTS Commercial Off-the-Shelf
CTX Corporate Trade Exchange
DCIA Debt Collection Improvement Act of 1996
DMA Document Management Alliance
DOJ Department of Justice
DUNS Data Universal Numbering System
ECS Electronic Certification System
EDI Electronic Data Interchange
EFT Electronic Funds Transfer
FACTS Federal Agencies Centralized Trial Balance System
FASAB Federal Accounting Standards Advisory Board
FFMIA Federal Financial Management Improvement Act of 1996
FFMSR Federal Financial Management System Requirements
FMS Department of the Treasury Financial Management Service
GAO General Accounting Office
GMRA Government Management Reform Act of 1994
GOALS Government Online Accounting Link System
GPRA Government Performance and Results Act of 1993
GSA General Services Administration
IPAC Intra-governmental Payment and Collection System
IRS Internal Revenue Service
IT Information Technology
JFMIP Joint Financial Management Improvement Program
MAPI-WF Messaging API-Workflow
MVS Multiple Virtual System
NACHA National Automated Clearing House Association
ODA/ODIF Open Document Architecture/Open Document Interface Format
ODMA Open Document Management Architecture
OMB Office of Management and Budget
OPAC On-line Payment and Collection System
OS Operating System
Acronyms

PPD Prearranged Payment and Deposit

PPD+ Prearranged Payment and Deposit Plus Addendum
RTN Routing Transit Number
SFFAS Statements of Federal Financial Accounting Standards
SGML Standard Generalized Markup Language
TAS Treasury Account Symbol
TAFS Treasury Account Fund Symbol
TFM Treasury Financial Manual
TIN Taxpayer Identification Number
U.S.C. United States Code
U.S. SGL United States Standard General Ledger
VIM Vendor Independent Messaging
WFMC Workflow Management Coalition
XML Extensible Markup Language

Illustrations

1. Financial System Improvement Projects.............................................................................. 5

2. Integrated Model for Federal Information Systems ............................................................. 7
3. Agency Systems Architecture .............................................................................................. 8
4. Core Financial System ....................................................................................................... 11
Table of Contents

Introduction ................................................................................................................................ 1
Federal Financial Management Framework .............................................................................. 3
Integrated Financial Management Systems........................................................................ 6
Agency Financial Management Systems Architecture........................................................ 7
Core Financial System Overview............................................................................................... 9
Background......................................................................................................................... 9
General Information ....................................................................................................... 9
Policy.............................................................................................................................. 9
Management Controls.................................................................................................. 10
Summary of Functional Requirements.............................................................................. 10
Core Financial System Management ........................................................................... 11
General Ledger Management ...................................................................................... 12
Funds Management ..................................................................................................... 12
Payment Management ................................................................................................. 13
Receivable Management ............................................................................................. 13
Cost Management........................................................................................................ 13
Reporting...................................................................................................................... 14
Summary of Technical Requirements............................................................................... 15
Functional Requirements .................................................................................................. 16
Core Financial System Management Function ................................................................. 17
Accounting Classification Management Process ......................................................... 17
Transaction Control Process........................................................................................ 20
General Ledger Management Function ............................................................................ 24
General Ledger Account Definition Process ................................................................ 24
Accruals, Closing and Consolidation Process.............................................................. 25
General Ledger Analysis and Reconciliation Process ................................................. 26
Funds Management Function ........................................................................................... 28
Budget Preparation Process ........................................................................................ 28
Budget Formulation Process........................................................................................ 29
Funds Allocation Process............................................................................................. 30
Budget Execution Process ........................................................................................... 31
Funds Control Process................................................................................................. 32
Payment Management Function ....................................................................................... 38
Payee Information Maintenance Process .................................................................... 38
Payment Warehousing Process ................................................................................... 40
Payment Execution Process ........................................................................................ 42
Payment Confirmation and Follow-up Process ............................................................ 46
Receivable Management Function ................................................................................... 48
Customer Information Maintenance Process ............................................................... 48
Receivable Establishment Process.............................................................................. 50
Debt Management Process.......................................................................................... 51
Collection Process ....................................................................................................... 53
Cost Management Function.............................................................................................. 55
Table of Contents

Cost Setup and Accumulation Process ........................................................................ 55

Cost Recognition Process............................................................................................ 57
Cost Distribution Process ............................................................................................. 57
Working Capital and Revolving Fund Process ............................................................. 58
Reporting Function............................................................................................................ 60
General Reporting Process .......................................................................................... 60
External Reporting ....................................................................................................... 61
Internal Reporting......................................................................................................... 61
Ad Hoc Query............................................................................................................... 64
Technical Requirements .......................................................................................................... 66
General Design/Architecture............................................................................................. 66
Infrastructure..................................................................................................................... 68
User Interfaces.................................................................................................................. 69
Interoperability .................................................................................................................. 70
Workflow/Messaging......................................................................................................... 71
Document Management.................................................................................................... 72
Internet Access ................................................................................................................. 72
Security ............................................................................................................................. 73
Operations and Computing Performance ......................................................................... 74
Appendix A: References .......................................................................................................... 76
Appendix B: Glossary .............................................................................................................. 79
Appendix C: Summary of Standard External Reports from Core Financial Systems............... 89
Appendix D: Contributors......................................................................................................... 91
Introduction

The citizens of the United States entrust the stewardship of Federal Government financial
resources and assets to the legislative and executive branches of Government. Financial and
program managers are accountable for program results and fiscally responsible for the
resources entrusted to them. Managers must understand that their daily actions have financial
implications for taxpayers and affect the amount of public debt the Federal Government must
assume to support Government initiatives. Furthermore, managers must be able to provide
information essential to monitor budgets, operations, and program performance.

The Federal Government recognizes the importance of having high quality financial systems to
support improvement of Government operations and to provide financial and related information
to program and financial managers. The CFO Act of 1990, the GPRA, the Government
Management Reform Act (GMRA) of 1994, and FFMIA of 1996 mandate improved financial
management, assign clearer responsibility for leadership to senior officials, and require new
financial organizations, enhanced financial systems, and audited financial reporting.

Improving Federal financial management systems is critical to increasing the accountability of

financial and program managers, providing better information for decision-making, and
increasing the efficiency and effectiveness of services provided by the Federal Government.
Proper and reliable financial management systems must provide for:

Accountability. Inform taxpayers, Congress, and agency personnel in terms they can
readily understand, on how the Nation’s tax dollars are spent, and how Federal assets
are protected.

Efficiency and Effectiveness. Provide efficient and effective service to the Federal
agency’s internal and external customers (e.g., individuals, contractors, partnerships,
state and local governments, other Federal agencies/organizations, the military, and
foreign governments).

Better Decision-Making. Provide to Congress, agency heads and program managers,

timely reports linking financial results and program data so that financial and program
results of policy and program decisions can be identified, tracked, and forecasted more
accurately.

The OMB Circular No. A-127, Financial Management Systems, sets forth general policies for
Federal financial management systems. Each agency is required to establish and maintain a
single, integrated financial management system. To support this requirement, each agency
must have an ongoing financial systems improvement planning process and perform periodic
reviews of financial system capabilities. In addition, each agency must maintain financial
management systems that comply with uniform Federal accounting concepts and standards
promulgated by the Federal Accounting Standards Advisory Board (FASAB) in its Statements of
Federal Financial Accounting Standards (SFFAS), which constitute generally accepted
accounting principles for the Federal Government.

System requirements for common systems have been prepared under JFMIP direction as a
series of publications entitled Federal Financial Management System Requirements (FFMSR).
The FFMIA statute codified the FFMSR as key requirements that agency systems must meet to
be substantially in compliance with system requirements provisions under FFMIA. The Core
Financial System Requirements document has been prepared as a continuation of the FFMSR

Core Financial System Requirements 1

Introduction

series that began with the Core Financial Systems Requirements document first published in
January 1988.

This document is intended for financial system analysts, systems accountants, systems
developers, program managers, and others who design, develop, implement, operate or
maintain financial management systems. It is also intended as guidance for reviews of system
compliance with FMFIA requirements.

Information that applies to all financial management systems, such as internal controls, system
security, training, documentation, and support are discussed in the JFMIP Framework for
Federal Financial Management Systems document. The Framework document, published in
January 1995, provides guidance in the design, implementation, and operation of financial
management systems to support the increased emphasis being placed on improving
Government operations. However, the internal controls and security considerations for Core
financial systems are interspersed throughout this document.

This document is the basis for evaluating Core financial system software for compliance with
JFMIP requirements, through a testing process that links test scenarios to the requirements
presented in this document. JFMIP tests commercial software functionality against these
requirements and qualifies the software as meeting mandatory requirements. JFMIP also uses
this process to test Government agency software compliance for those agencies that provide
accounting systems to other Government agencies on a cross-service arrangement. For cross-
servicing agencies, this testing is voluntary. For further information on the JFMIP testing
process and for the results of completed software qualification tests please see the JFMIP web
site at http://www.JFMIP.gov. Please note that the JFMIP web site also includes all JFMIP
requirements documents, such as Human Resources & Payroll System, Travel System, etc.

The next chapters in this document set forth the framework for the establishment and
maintenance of an integrated Federal financial management system. An overview of the Core
financial system, including a summary of functions and technical requirements is provided in the
System Overview chapter. Specific requirements are presented in detail in the functional and
technical requirements chapters. Appendices provide References, a Glossary, a Summary of
External Reporting Requirements, and a list of Contributors.

2 Core Financial System Requirements

Federal Financial Management Framework

The Core Financial System Requirements document provides functional requirements for
financial managers, program managers and others to control and account for Federal programs
as defined in governmentwide statutes, regulations, guidelines. This document is one
component of a broad program to improve Federal financial management. That program
involves establishing uniform requirements for financial information, financial systems, reporting,
and financial organizations.

As shown in Illustration 1, Financial Systems Improvement Projects (page 5), establishing

uniform requirements is only part of the process of improving financial management systems
and information. Improvements can be achieved through the selection, development, or
purchase of applications that meet approved functional requirements and technical and data
management specifications. Agencies must continue to improve their financial systems and
implement new requirements as they are issued so that continuing efforts to standardize and
upgrade data and reporting requirements, in accordance with OMB’s governmentwide 5-year
financial management plan, will be successful. A financial management system, as with most
other systems, may require periodic maintenance, enhancement, or modification. Each agency
should establish standards and procedures for testing, implementing and installing
enhancements, fixes and other modifications in the financial management system.

Well-defined and effective governmentwide functional requirements assist agencies in

developing strong systems and information by eliminating duplicate work among agencies and
providing a common framework so that outside vendors can more economically provide
systems software. Development of governmentwide functional requirements for each
application is a critical effort that will affect internally developed systems and the evaluation and
selection of commercially available systems.

Each agency should integrate its unique requirements with these governmentwide standard
requirements to provide a uniform basis for the standardization of financial management
systems as required by the CFO Act of 1990, FFMIA of 1996, and other statutes.

Financial management systems in the Federal Government must be designed to support the
vision articulated by the Government’s financial management community. This vision requires
financial management systems to support the partnership between program and financial
managers and to assure the integrity of information for decision-making and measuring of
performance. This includes the ability to:

• Collect accurate, timely, complete, reliable, and consistent information;

• Provide for adequate agency management reporting;

• Support governmentwide and agency level policy decisions;

• Support the preparation and execution of agency budgets;

• Facilitate the preparation of financial statements, and other financial reports in

accordance with Federal accounting and reporting standards;

• Provide information to central agencies for budgeting, analysis, and governmentwide

reporting, including consolidated financial statements; and

Core Financial System Requirements 3

Federal Financial Management Framework

• Provide a complete audit trail to facilitate audits.

In support of this vision, the Federal Government must establish and maintain
governmentwide financial management systems and compatible agency systems, with
standard information and electronic data exchange, to support program delivery, safeguard
assets, and manage taxpayer dollars.

4 Core Financial System Requirements

 Federal Financial Management Framework

Financial System Improvement Projects

Standards/
Requirements Agency Implementation

Standard Reporting
Requirements
Additional Adaptation
U.S. Government Standard Agency
General Ledger Functional
Requirements
Core Financial System
Requirements
Procedures
Human Resources &
Payroll Systems
Requirements Additional
Agency
Travel System Technical Training
Requirements Requirements
Software
Seized Property and Selection
Forfeited Assets Systems
Requirements Documentation

Direct Loan System Integration

Requirements Strategy

Guaranteed Loan System

Conversion
Requirements

Inventory System Software/

Requirements Hardware
Evaluation
System Requirements for Maintenance
Managerial Cost
Accounting

Property Management
System Requirements

Benefit System
Requirements

Other Standards

Subject of
this document

Illustration 1

Core Financial System Requirements 5

Federal Financial Management Framework

It is critical that financial management system plans support the agency’s mission and
programs, including planned changes to them, and that the financial management systems
plans are incorporated into the agency’s plans for information technology (IT) infrastructure and
information systems as a whole. Further, system design efforts should include an analysis of
how system improvements, new technology supporting financial management systems, and
modifications to existing work processes can together enhance agency operations and improve
program and financial management. Reassessing information and processing needs and
redesigning processes, procedures, and policies are essential steps to meeting user needs.

Integrated Financial Management Systems

Financial management systems must be designed with effective and efficient interrelationships
between software, hardware, personnel, procedures, controls, and data contained within the
systems. To be integrated, financial management systems must have, as a minimum, the
following four characteristics:

(1) Standard data classifications (definition and formats) established and used for
recording financial events;

(2) Common processes used for processing similar kinds of transactions;

(3) Internal controls over data entry, transaction processing, and reporting applied
consistently; and

(4) A design that eliminates unnecessary duplication of transaction entry.

The CFO Act of 1990 and financial management systems policy described in OMB Circular No.
A-127 Financial Management Systems require that each agency establish and maintain a
single, integrated financial management system. Without a single, integrated financial
management system to ensure timely and accurate financial data, poor policy decisions are
more likely to occur due to inaccurate or untimely information. Managers are also less likely to
be able to report accurately to the President, the Congress, and the public on Government
operations in a timely manner. Scarce resources would more likely be directed toward the
collection of information rather than to delivery of the intended programs. Also, upgrades to
financial management systems that are necessary to keep pace with rapidly changing user
requirements cannot be coordinated and managed properly. The basic requirements for a
single, integrated financial management system are outlined in OMB Circular No. A-127.

Having a single, integrated financial management system does not necessarily mean that each
agency must have only one software application covering all financial management system
needs. Rather, a single, integrated financial management system is a unified set of financial
systems and the financial portions of mixed systems1 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. However,
it does not mean that all information is physically located in the same database

Unified means that the systems are planned and managed together and linked together
electronically in an efficient and effective manner to provide agency-wide financial system
support necessary to support the agency’s financial management needs.
1
A mixed system is an information system that supports both financial and non-financial functions of the
Federal Government or components thereof. See OMB Circular No. A-127.

6 Core Financial System Requirements

 Federal Financial Management Framework

Interfaces where one system feeds data to another system following normal business and
transaction cycles (such as recording payroll data in general ledger control accounts at specific
time intervals) may be acceptable as long as the supporting detail is maintained and accessible
to managers. Additionally, for determining compliance with FFMIA, the implementation
guidance issued by OMB requires that the posting rules in the feeder system must not be
contrary to the United States Standard General Ledger (U.S. SGL) posting rules. Interfaces
must be automated unless the number of transactions is so small that it is not cost-beneficial to
automate the interface. Reconciliation between systems, where interfaces are appropriate,
must be maintained to ensure data accuracy.

To develop any unified information system, it is critical that the senior systems analysts and
systems accountants identify:

• Scope of the functions to be supported (processes),

• How data quality will be assured (data stewardship),

• Information to be processed (management information),

• How systems fit together to support the functions (systems architecture), and

• Safeguards needed to ensure the integrity of operations and data (internal control).

All of these pieces, as shown in Illustration 2, must work together to form an efficient integrated
information system. A change to any part of the model will require determining the impact on
other parts of the model. For example, a new reporting requirement may require changes
throughout the entire model.

Integrated Model for Federal Information Systems

Illustration 2

Agency Financial Management Systems Architecture

Agency financial management systems are information systems that track financial events and
summarize information to support the mission of an agency, provide for adequate management

Core Financial System Requirements 7

Federal Financial Management Framework

reporting, support agency level policy decisions necessary to carry out fiduciary responsibilities,
and support the preparation of auditable financial statements.

Agency financial management systems fall into four categories:

(1) Core financial systems,

(2) Other financial and mixed systems (such as inventory systems),
(3) Shared systems, and
(4) Departmental executive information systems (systems to provide information to all
levels of management).
These systems must be linked together electronically to be effective and efficient. Summary
data transfers must be provided from agency systems to central systems to permit summaries
of management information and agency financial performance information on a governmentwide
basis.

Subject to governmentwide policies, the physical configuration of financial management

systems, including issues of centralized or decentralized activities, processing routines, data,
and organizations, is a determination that is best left to individual agencies. Agencies can
determine the optimal manner in which to support their own mission. When determining the
physical design of the system, agencies should consider their organizational philosophy, the
technical capabilities available, and the most appropriate manner to achieve the necessary
single integrated financial management system.

The agency financial management systems architecture depicted in Illustration 3 shows the
typical components of an integrated Federal financial management system. Although this does
not necessarily represent the physical design of the system, it does identify the system types
needed to support program delivery/financing and financial event processing for effective and
efficient program execution.

Agency Systems Architecture

Direct Seized Property

Guaranteed Loan & Forfeited Travel
Loan System Asset System
System System Human Resources
& Payroll
Benefit System System
Managerial Cost
A
Insurance Claim Core Financial Non-financial
cco tin

System Financial Reporting Systems

un

System System g
Grant
System Budget
Formulation
Inventory System
System Property Revenue
Management Acquisition System
System System

D e p ar t m e
nt a l E xec utive I nfo rm at i on Sy s te m

Illustration 3

8 Core Financial System Requirements

Core Financial System Overview

This chapter provides an overview of a Core financial system in the following sections:
Background, Management Controls, Summary of Core Financial System Functions and
Summary of Technical Requirements.

Background
General Information
The U.S. Government is the world’s largest and most complex enterprise. Each year Federal
agencies control and disburse almost two trillion dollars that are ultimately controlled by Core
financial systems. This document is intended to specify the baseline functional capabilities that
Core financial systems must have to support agency missions and comply with laws and
regulations.

Establishing governmentwide Core system requirements promotes a common understanding

among private and public sector financial managers and agency program managers regarding
Core system functional capabilities. They provide criteria for agency compliance under FFMIA
and serve as a tool for oversight agencies to evaluate such systems. They help justify agency
system improvements or replacements. They also help organize the private sector market by
communicating mandatory functionality that commercial software must be able to provide to
Federal agencies, as well as identifying value-added features desired by Federal agencies.

Policy
Government Core financial systems, as an integral component of the Federal Agency Systems
Architecture (see Illustration 3) are relied on to control and support the key financial
management functions of an agency. In addition to reporting on results of operations, these
functions include managing: the general ledger, funding, payments, receivables and costs. The
Core financial system receives data from other financial and mixed systems and from direct
user input, and provides data and supports processing for other systems. Federal Core
financial systems must provide consistent and standardized information for program managers,
financial managers, agency executives and oversight organizations. Furthermore, all Core
financial systems, whether being designed and implemented or are currently in use, must
operate in accordance with laws, regulations, and judicial decisions.

Financial management system development and implementation efforts shall seek cost effective
and efficient solutions as required by OMB Circular No. A-130, Management of Federal
Information Resources. Agencies are required to use commercial-off-the-shelf (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.
However, as stated previously, the agency has the ultimate responsibility for implementing
sound financial management practices and systems, and cannot depend on a vendor or
contractor to do this for them.

To promote effectiveness in COTS software, JFMIP is responsible for three major functions:
Updating and communicating financial management system requirements so that COTS
software vendors and agencies can better understand the Federal market requirements; testing
and qualifying COTS software; and maintaining a web site (www.jfmip.gov) with information

Core Financial System Requirements 9

Core Financial System Overview

available on the certified Core financial management systems software. This information should
reduce agency acquisition cost and risk when implementing COTS products because they will
have already been tested and certified as meeting JFMIP requirements.

The document identifies mandatory and value-added financial functional requirements for
Federal Core financial system. Definitions for these two categories are:

Mandatory–Mandatory requirements describe what the system must do and consist of

the minimum acceptable functionality necessary to establish a system, or are based on
Federal laws and regulations. Mandatory requirements are those against which agency
heads evaluate their systems to determine substantial compliance with systems under
the FFMIA. These requirements apply to existing systems and new systems that are
planned or under development.

Value-added–Value-added requirements describe features or characteristics and may

consist of any combination of the following: using state-of-the-art technology; employing
preferred or best business practices; or meeting the special management needs of an
individual agency. Value-added, optional, and other similar terminology may be used to
describe this category of requirements. Agencies should consider value-added features
when judging system options. The need for these value-added features in agency
systems is left to the discretion of each agency head.

Within this document, mandatory Core financial system requirements are indicated by the word
“must” and value-added system requirements are identified by use of the words “may” or
“should.”

Management Controls
Core financial systems must incorporate appropriate controls to ensure the accuracy of data
entry, completeness and consistency of transaction processing and reporting, as stated in OMB
Circular No. A-127. Certain controls are typically incorporated into software applications, such
as input controls. Other controls such as proper segregation of duties may be implemented as
a feature of software functionality, as a manual process, or both. This document contains some
specific requirements for implementing basic management controls within the appropriate
functional area. Additionally, this document incorporates global security requirements.
Specifically, TH-1 through TH-8 require system changes only by “authorized users.” These
requirements preclude the need to qualify other functional requirements with references to
authorized users. Ultimately, each agency is responsible for implementing adequate controls to
ensure the Core financial system is operating as intended.

Summary of Functional Requirements

The following is a brief description of the major functions of a Core financial system. The
Functional Requirements chapter provides a detailed description of each function, including the
requirements within each function. Illustration 4 depicts the major functions within the Core
financial system.

10 Core Financial System Requirements

 Core Financial System Overview

Core Financial System

ancial System Mana

Fin gem
r e en
Co Receivable t
Payment Management
Management

General Ledger
Management Funds
Cost Management
Management

Reporting

Illustration 4

A single financial event will require processing by more than one function within the Core
financial system. The Core Financial System Management function affects all financial event
transaction processing because it maintains reference tables used for editing and classifying
data, controls transactions, and maintains security. Likewise, the General Ledger Management
function is involved either directly or indirectly with financial events since transactions to record
financial events must be posted to the general ledger either individually or in summary. Any
transactions involved in budget execution will use the Funds Management function.

An example of a financial event affecting multiple functions is a payment including additional

charges not previously recorded, such as interest costs due to late payment or additional
shipping charges allowed by the contract. This transaction would: (1) originate in the Payment
Management function, (2) be edited for funds availability and update balances in the Funds
Management function for the excess costs and to move the undelivered order amount to an
expenditure status, (3) update cost amounts controlled by the Cost Management function,
(4) update the general ledger balances in the General Ledger Management function, and (5) be
edited against reference data and update audit trails in the Core Financial System Management
function.

Core Financial System Management

The Core Financial System Management function consists of all the processes necessary to
maintain the financial system in a manner that is consistent with established financial
management laws, regulations and policy. This function sets the framework for all other Core
financial system functions. The Core Financial System Management function consists of the
following processes:
• Accounting Classification Management
• Transaction Control

Core Financial System Management requirements can be found starting on page 17.

Core Financial System Requirements 11

Core Financial System Overview

General Ledger Management

General Ledger Management is the central function of the Core financial system. The general
ledger is the highest level of summarization and must maintain account balances by the
accounting classification elements established in the Core Financial System Management
function. For example, account balances must be maintained at the internal fund and
organization level. Depending on the agency’s reporting requirements, some or all of the
general ledger accounts may have balances broken out by additional elements of the
accounting classification. All transactions to record financial events must post, either
individually or in summary, to the general ledger, regardless of the origin of the transaction.

The General Ledger Management function consists of the following processes:

• General Ledger Account Definition

• Accruals, Closing, and Consolidation

• General Ledger Analysis and Reconciliation.

General Ledger Management requirements can be found starting on page 24.

Funds Management
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. The
Funds Management function of the Core financial system is an agency’s primary tool for
carrying out this responsibility.

The Funds Management function consists of the following processes:

• Budget Preparation

• Budget Formulation

• Funds Allocation

• Budget Execution

• Funds Control.

Note that Budget Formulation functionality is covered by this Core requirements document and
is also listed as a separate requirements document on Illustration 3, Federal Agency Systems
Architecture. There has never been a formal development of the separate Budget Formulation
System requirements document. However, agencies have processes that require Budget
Formulation system actions. Until a formal Budget Formulation Requirements System
document is developed, JFMIP presents a number of suggested budget formulation
requirements as value-added requirements within the Core Financial System Requirements
document.

Funds Management requirements can be found starting on page 28.

12 Core Financial System Requirements

 Core Financial System Overview

Payment Management
The Payment Management function should provide appropriate control over all payments made
by or on behalf of an agency. Agencies initiate payments to: vendors in accordance with
contracts, purchase orders and other obligating documents; state governments under a variety
of programs; employees for salaries and expense reimbursements; other Federal agencies for
reimbursable work performed; individual citizens receiving Federal benefits; recipients of
Federal loans; and make payments for other reasons. Designated payment organizations
(specified agency or Treasury organizations) accomplish payments. Certain agencies that are
authorized to make their own disbursements must comply with the Provisions pertaining to
“delegated disbursing authority” contained in I Treasury Financial Manual (TFM) - 4, and
applicable requirements below.

The Payment Management function consists of the following processes:

• Payee Information Maintenance

• Payment Warehousing

• Payment Execution

• Payment Confirmation and Follow-up.

Payment Management requirements can be found starting on page 38.

Receivable Management
The Receivable Management function supports activities associated recognizing and recording
debts due to the Government, performing follow-up actions to collect on these debts, and
recording agency cash receipts. A receivable is recognized when an agency establishes a
claim to cash or other assets against other entities. This section also addresses accounting for
miscellaneous cash receipts.

The Receivable Management function consists of the following processes:

• Customer Information Maintenance

• Receivable Establishment

• Debt Management

• Collections and Offsets.

Receivable Management requirements can be found starting on page 48.

Cost Management
The Cost Management function of the Core financial system attempts to measure the total cost
and revenue of Federal programs, and their various elements, activities and outputs. Cost
Management is essential for providing accurate program measurement information,
performance measures, and financial statements with verifiable reporting of the cost of
activities. The term “cost” refers to the monetary value of resources used or sacrificed or

Core Financial System Requirements 13

Core Financial System Overview

liabilities incurred to achieve an objective, such as to acquire or produce a good or to perform

an activity or service. A “cost object” is any activity, output or item whose cost and revenue are
to be measured.

The level of sophistication of the Cost Management function needed by an agency depends on
the requirements of the agency and the operational nature of the programs involved. For
example, if an agency’s primary mission is to produce a product or service for sale, the costing
function typically will be accomplished in the Managerial Cost Accounting System that is
integrated with the Core Financial System. However, in any Core system, certain basic
functions must be present.

The Cost Management function consists of the following processes:

• Cost Setup and Accumulation

• Cost Recognition

• Cost Distribution

• Working Capital and Revolving Fund.

Cost Management requirements can be found starting on page 55.

Reporting
The Core financial system must be able to provide timely and useful financial information to
support: management’s fiduciary role; budget formulation and execution functions; fiscal
management of program delivery and program decision making; and internal and external
reporting requirements. External reporting requirements include the requirements for financial
statements prepared in accordance with the form and content prescribed by OMB, reporting
requirements prescribed by Treasury, and legal, regulatory and other special management
requirements of the agency.

The reporting function consists of the following processes:

• General Reporting

• External Reporting

• Internal Reporting

• Ad hoc Query.

Reporting requirements can be found starting on page 60.

14 Core Financial System Requirements

 Core Financial System Overview

Summary of Technical Requirements

Technical requirements have been established to help ensure that a Core financial system: is
capable of meeting a wide variety of workload processing demands; provides transaction
processing integrity and general operating reliability; incorporates standard installation,
configuration and operating procedures; and does not conflict with other administrative/program
systems or other agency established IT standards.

Core financial systems subject to JFMIP testing must meet the mandatory technical
requirements specified in this section. Additionally they should strive to include the functionality
listed as value-added requirements. The requirements are listed in the following subcategories:

• General Design/Architecture

• Infrastructure

• User Interfaces

• Interoperability

• Workflow/Messaging

• Document Management

• Internet Access

• Security

• Operations and Computing Performance

Most technical requirements are stated in general terms to allow vendors maximum flexibility in
designing compliant financial systems. Individual agencies are encouraged to add specific
workload and interoperability requirements considered unique to their respective IT
environments when evaluating packages for acquisition.

Technical requirements can be found starting on page 66.

Core Financial System Requirements 15

Functional Requirements

This chapter identifies the governmentwide requirements for a Core financial system to support
the fundamental financial functions of a Federal agency. The major functions supported by a
Core financial system are as follows:

• Core Financial System Management

• General Ledger Management

• Funds Management

• Payment Management

• Receivable Management

• Cost Management

• Reporting

Together, these functions provide the basic information and control needed to carry out financial
management functions, manage the financial operations of an agency, and report on the
agency’s financial status to central agencies, Congress, and the public. This includes data
needed to prepare the principal financial statements for Federal agencies in accordance with
the current OMB Bulletin that addresses the form and content (i.e., OMB Bulletin No. 01-09
Form and Content of Agency Financial Statements, as of the publication of this document).

The numbering series assigned to the requirements in each process section are noted in
parentheses. The numbering scheme describes the related function, section and requirement
number. For example, the first requirement in the Core Financial System Management function
section A is “CFA-01”. CF represents “Core Financial”, A is the section, and 01 is the
requirement number.

The following abbreviations are used:

CF – Core Financial

GL – General Ledger

FM – Funds Management

PM – Payment Management

RM – Receivable Management

CM – Cost Management

R – Reporting

T – Technical

16 Core Financial System Requirements

Core Financial System Management Function

The Core Financial System Management function ensures that the capability exists for
capturing, classifying, processing, storing and retrieving the financial data Federal agencies use
in their daily operations. The Core Financial System Management function establishes the
reporting entity and framework for ensuring that data is shared among components of an
agency’s single integrated financial management system. This function also ensures that
transactions are processed in a uniform and consistent manner. The Core Financial System
Management function consists of the following processes.

• Accounting Classification Management (CFA)

• Transaction Control (CFB)

Accounting Classification Management Process

Within each department or agency, the accounting classification elements and definitions must
be standardized to ensure consistency, uniformity, and efficiency in accounting treatment,
classification, and reporting. The Accounting Classification Management process provides a
consistent basis for:

• Consolidating governmentwide financial information,

• Integrating planning, budgeting, and accounting,

• Capturing data at the lowest level of detail at the point of data entry-throughout the
agency in a manner that ensures that when data is rolled up to the level that is
standardized, it is consistent at the standardized level, and

• Comparing and combining similar programs across agencies and calculating overall
program results.

The OMB Circular No. A-127, Financial Management Systems, requires financial management
systems to reflect an agency-wide financial information classification structure that is consistent
with the U.S. SGL, provides for tracking of specific program expenditures, and covers financially
related information. Additionally, it states:

“Financial management system designs shall support agency budget, accounting, and
financial management reporting processes by providing consistent financial information
for budget formulation, budget execution, programmatic and financial management,
performance measurement, and financial statement preparation.”

The accounting classification is a subset of the agency financial information classification

structure, which also includes financially related personnel information, performance
measurement information, and other financial information needed by the agency. It provides the
means for categorizing financial information along several dimensions as needed to support
financial management and reporting functions. The data elements a particular agency includes
in its accounting classification will depend on data aggregation requirements for preparation of
financial statements under the CFO Act, the appropriation structure, and other reporting and
management needs of the agency.

Core Financial System Requirements 17

Core Financial System Management Function

Mandatory Requirements

To support the Accounting Classification Management process, the Core financial system must
provide the capability to:

• Classify accounting transactions by:

o Treasury Account Symbol/Treasury Account Fund Symbol (TAS/TAFS),

o Internal fund code (see CFA-04 below),
o Budget fiscal year,
o Accounting quarter and month,
o Program,
o Organization,
o Project,
o Activity,
o Cost center,
o Object class,
o Budget function (and sub function code), and
o Remaining U.S. SGL attributes not specified above. (CFA-01)

• Define additional accounting classification elements. Classify and report accounting

transactions by each type of element. (CFA-02)

• Achieve consistency in budget and accounting classifications and synchronization

between those classifications and the organizational structure. Consistency will include
maintaining data relationships between:

o Budget formulation classifications (budget function and sub function classification

codes, per OMB Circular No. A-11)
o Budget execution and accounting classifications (e.g., TAS/TAFS, internal fund,
program, project, activity), and
o The agency’s organizational structure. (CFA-03)

• Provide a fund structure that identifies TAS/TAFS established by OMB and Treasury.
Accommodate additional detail below the TAS level, such as an internal fund code to
support fiscal year accounting, and appropriation sub-accounts used for reporting to
Treasury. (CFA-04)

• Differentiate among the type of budgeting, accounting, and reporting treatments to be

used based on various TAS/TAFS characteristics. At a minimum, the following fund
characteristics must be supported in accordance with Treasury and OMB reporting and
budget execution requirements:

o Fund type (e.g., general fund, deposit fund, trust fund, special fund, revolving fund,
receipt account);
o Funding source (e.g., borrowing authority, contract authority, direct appropriation,
spending authority from offsetting collections); and
o Budget status (e.g., on budget, off budget, or financing account); and TAS/TAFS
status (e.g., annual, multiyear, and no-year). (CFA-05)

• Provide a program structure with sufficient levels of detail to allow reporting for all
categories on which budgetary decisions are made, whether legally binding, as in

18 Core Financial System Requirements

 Core Financial System Management Function

appropriation limitations, or in the nature of policy guidance, as in Presidential pass-

backs and congressional markup tables. (CFA-06)

• Establish an organizational structure based on responsibility segments, such as

bureaus, divisions, and branches. Provide for the ability to tie responsible organizational
units to programs, projects and activities. (CFA-07)

• Support the management of multiple Agency Location Codes (ALC) and associate the
appropriate ALC with each transaction involving Fund balance with Treasury to facilitate
external reporting (e.g., Financial Management Service (FMS)-224) and reconciliation
with Treasury. (CFA-08)

• Provide a project structure that is independent of the other accounting classification

elements to allow multiple organizations, programs, and funding sources to be
associated with a project. (CFA-09)

• Provide an object class structure consistent with the standard object class codes
contained in OMB Circular No. A-11. Provide flexibility to accommodate additional levels
(lower) in the object class structure. (CFA-10)

• Process additions, changes and deletions to elements of the accounting classification

design, and related valid domain values within accounting classifications, without
extensive program or system changes (e.g., through on-line table updates). (CFA-11)

• Allow the user to enter, edit, and store accounting classification table changes so that
the changes automatically become effective at any future date determined by the user.
(CFA-12)

• Reject or suspend interfaced transactions that contain accounting classification elements

or domain values that have been deactivated or discontinued. (CFA-13)

Value-added Requirements

To support the Accounting Classification Management process, the Core financial system
should provide the capability to:

• Provide a revenue source code structure to identify and classify types of revenue and
receipts as defined by the user. For example, categories could be rental income, sales
by product type, income by type of service performed and others. (CFA-14)

• Validate all transactions involving Treasury and other disbursing centers for valid
combinations of ALC and TAS/TAFS, as defined by the user. (CFA-15)

• Derive the full accounting classifications from abbreviated user input so that user input is
minimized, data entry is made easier, and errors are controlled and reduced. Examples
of methods include entering "shorthand codes," using a keyboard function to look up
additional elements, "clicking" on a "pop-up menu," and scanning a bar code. (CFA-16)

• Provide for an automated method to reclassify accounting data at the document level
when a restructuring of the existing values pertaining to the mandatory accounting
classification elements is needed. Maintain an audit trail from the original postings to the
final posting. (CFA-17)

Core Financial System Requirements 19

Core Financial System Management Function

Transaction Control Process

The Transaction Control Process defines, maintains and executes the posting and editing rules
for transactions that are processed in the Core financial system. In addition to recording
transactions originally entered into the Core financial system, the Core financial system must be
able to process and record transactions originating in other systems. In order to provide the
basis for central financial control, the Core system must track such transactions and related
information.

The Transaction Control Process is further categorized as Transaction Definition and

Processing activities, and Audit Trail activities.

Transaction Definition and Processing. OMB Circular No. A-127 requires common processes
to be used for processing similar kinds of transactions throughout an integrated financial
management system to enable transactions to be reported in a consistent manner. It also
requires financial events to be recorded by applying the requirements of the U.S. SGL at the
transaction level. This is accomplished by defining a standard transaction(s) for each
accounting event. U.S. SGL accounting transactions typically update multiple budgetary and
proprietary accounts based on a single accounting event. The Core financial system must
ensure that all transactions are handled consistently, regardless of their point of origin. It also
must ensure that transactions are controlled properly to provide reasonable assurance that the
recording, processing, and reporting of financial data are properly performed and that the
completeness and accuracy of authorized transactions are ensured.

Mandatory Requirements

To support the Transaction Definition and Processing activity, the Core financial system must
provide the capability to:

• Use standard transactions when recording accounting events. The standard

transactions must specify the postings to the general ledger accounts, and update
document balances and any related tables (e.g., available funding). (CFB-01)

• Allow the user to include proprietary, budgetary and memorandum accounts in the
definition of a standard transaction. (CFB-02)

• Record transactions consistent with U.S. SGL posting rules. (CFB-03)

• Reject a transaction or provide a warning message when attempting to post a

transaction that would cause general ledger debits and credits to be out-of-balance at a
level below the TAS/TAFS (e.g., internal fund, organization level). (CFB-04)

• Allow users to define and maintain standard rules that control general ledger account
postings for all accounting events. The process of defining posting rules can be
accomplished in a variety of ways, including (but not limited to) using: transaction codes,
screen “templates,” derivation rules, and others. (CFB-05)

• Enable users to selectively require, omit, or set a default value for individual accounting
classification elements. For example, a budget object class code value is not
necessarily needed when recording depreciation expense. (CFB-06)

20 Core Financial System Requirements

 Core Financial System Management Function

• Update all applicable general ledger account balances (i.e., budgetary, proprietary and
memorandum accounts) based on a single input transaction. (CFB-07)

• Define, generate and post compound general ledger debit and credit entries for a single
transaction. Accommodate at least 10 debit and credit pairs or 20 accounts when
defining and processing a single transaction. (CFB-08)

• Allow users to define and process system-generated transactions, such as automated

accruals (e.g., payroll accrual entries), pre-closing and closing entries, cost assignment
transactions, recurring payments, and transactions that generate other transactions in
those cases where a single transaction is not sufficient. (CFB-09)

• Automatically liquidate, partially or in full, the balance of open documents by line item.
This capability will be used in the liquidation of various documents such as
commitments, obligations, undelivered orders, payables, receivables, and advances,
upon the processing of subsequent related transactions (e.g., liquidate an obligation
upon entry of the related receiving report). (CFB-10)

• Automatically determine and record the amount of upward or downward adjustments to

existing obligations upon liquidation, cancellation or other adjustment. This is to include
transactions entered directly to the Core system and those received from interfaced
modules or systems. (CFB-11)

• When adjustments are made to existing obligations or previously recorded expenditures,

automatically distinguish between upward and downward adjustments to unexpired and
expired budget authority, and generate the appropriate general ledger postings, without
user intervention. (CFB-12)

• Relative to expired funds, provide an overrideable error message when attempting to

post (previously unrecorded) obligations to current year general ledger obligation
accounts (e.g., U.S. SGL accounts 4801, 4802). (CFB-13)

• When recording adjustments to prior year obligations (including previously expended

authority), automatically classify upward and downward adjustments as paid and or
unpaid according to the status of the related obligation or expenditure. This is to include
transactions entered directly to the Core system and those received from interfaced
modules or systems. (CFB-14)

• Control the correction and reprocessing of all erroneous transactions through the use of
error/suspense files. Erroneous transactions must be maintained until either corrected
and posted or deleted at the specific request of a user. (CFB-15)

• Provide immediate, on-line notification to the user of erroneous transactions. Advise

reason for error and provide the ability to enter corrections on-line. (CFB-16)

• Provide controls to prevent the creation of duplicate transactions. For example, prevent
the use of the same unique transaction identification number (e.g., document number).
(CFB-17)

• Provide a warning message when the user attempts to input an external vendor invoice
number that has already been recorded for the related vendor. (CFB-18)

Core Financial System Requirements 21

Core Financial System Management Function

• Validate the fields for all accounting classification elements required to process the
transaction prior to posting. For example, fields pertaining to TAS/TAFS, object class,
vendor code, organization, and others. (CFB-19)

• Enter, edit, and store transactions in the current accounting period for automatic
processing in a future accounting period. (CFB-20)

• Put transactions in a hold status (saved, but not processed or posted) within the Core
system (i.e., importing transactions from a spreadsheet or database application is not
acceptable). Allow users to select held transactions and continue processing at a later
date. (CFB-21)

• Capture the six-digit trading partner code (as specified by Treasury) when processing all
transactions that directly involve another Federal entity (i.e., both parties to a transaction
are Federal entities). (CFB-22)

• For all transactions, capture transaction dates (effective date of the transaction) and
posting dates (date transaction posted to general ledger). (CFB-23)

• Automatically determine the posting date from the system date for all transactions.
Automatically associate a default accounting period for each transaction, but allow user
to override. (CFB-24)

• Automatically reverse entries by the following parameters: transaction or document type,

date range, schedule numbers, transaction identification number (i.e., document
number) range, and trading partner. (CFB-25)

• Post to the current and prior months concurrently until the prior month closing is
complete. (CFB-26)

• Provide and maintain on-line queries and reports on balances separately for the current
and prior months. At a minimum, balances must be maintained on-line for both the
current and prior months until the prior month closing is complete. (CFB-27)

• Post to the current fiscal year and prior fiscal year concurrently until prior yearend
closing is complete. (CFB-28)

• Provide and maintain on-line queries and reports on balances separately for the current
and prior fiscal years. At a minimum, balances must be maintained on-line for both the
current and prior fiscal years until the prior fiscal year closing is complete. (CFB-29)

Value-added Requirements

To support the Transaction Definition and Processing activity, the Core financial system should
provide the capability to:

• Perform validation checks for use of certain general ledger accounts associated with
specific Record Type 7 authority (e.g., Imprest fund, borrowing authority) prior to posting
a transaction. (CFB-30)

22 Core Financial System Requirements

 Core Financial System Management Function

• Have all functions of the system, including budgeting, spending, accounts payable, and
accounts receivable, process and track transactions in both foreign currency and U.S.
dollars. (CFB-31)

• Calculate progress payments to foreign vendors based on current exchange rates.

(CFB-32)

Audit Trails. Adequate audit trails are critical to providing support for transactions and
balances maintained by the Core financial system. While audit trails are essential to auditors
and system evaluators, they are also necessary for day-to-day operation of the system. For
example, they allow for the detection and systematic correction of errors.

Mandatory Requirements

To support the Audit Trail activity, the Core financial system must provide the capability to:

• Provide audit trails to trace transactions from their initial source through all stages of
related system processing. The initial source may be source documents, transactions
originating from other systems (e.g., feeder systems), or internal system-generated
transactions. (CFB-33)

• Select items for review based on user-defined criteria by type of transaction (e.g., by
obligation transactions, vendor, date range). Examples of reasons to select items are
payment certification and financial statement audits. (CFB-34)

• Provide audit trails that identify document input, change, approval, and deletions by
user. (CFB-35)

Value-added Requirements

There are no value-added requirements for this activity.

Core Financial System Requirements 23

General Ledger Management Function

Depending on the agency’s reporting requirements, some or all general ledger accounts may
use sub accounts to provide additional detail about elements of the accounting classification
and about U.S. SGL attributes required to meet FACTS I and FACTS II reporting requirements.

The General Ledger Account Definition process establishes the general ledger account
structure for the agency consistent with the U.S. SGL, and establishes the transaction edit and
posting rules to record financial events. The basis for Federal agency accounting as required
by the FASAB in its SFFAC and SFFAS, by the TFM, and described in 31 United States Code
(U.S.C.) 3512(e) is the accrual basis. The U.S. SGL account and transaction definitions and the
form and content requirements for financial statements were developed consistent with this
concept.

Subsidiary ledgers support the general ledger at various levels of detail. These subsidiary
ledgers may be totally integrated as part of the Core financial system or interfaced from other
systems. For example, detailed property records supporting the equipment account in the
general ledger might be maintained in a system devoted to controlling and maintaining
equipment. The payroll system might contain detailed employee pay records that support
records of expenditure by object class, organization, program, project, or activity that are
passed to and recorded in the Core financial system.

All transactions to record financial events must post, either individually or in summary, to the
general ledger, regardless of the origin of the transaction. Posting of transactions whose initial
point of entry is the Core financial system normally would be expected to occur for each
transaction individually. Posting of transactions originating in other systems may occur within
the general ledger either for individual transactions, or for summarized transactions, depending
on an agency’s overall financial management system design and needs. However, summary
transactions are acceptable only if an audit trail is maintained and the transactions from feeder
systems are summarized at a level that supports Central agency reporting requirements (e.g.,
the U.S. SGL attribute level at a minimum). Agencies are not required to maintain duplicates of
individual transactions posted in other feeder systems within the Core financial system. For
example, rather than posting every payroll transaction for each employee in both the payroll and
Core system general ledger, similar transactions (same accounting classification) may be
summarized for posting to the general ledger.

The General Ledger Management function consists of the following processes.

• General Ledger Account Definition (GLA)

• Accruals, Closing, and Consolidation (GLB)

• General Ledger Analysis and Reconciliation (GLC)

General Ledger Account Definition Process

OMB Circular No. A-127, Financial Management Systems, requires implementation of the U.S.
SGL at the transaction level. The U.S. SGL is defined in the latest supplement to the U.S.
Department of the Treasury’s TFM which includes the chart of accounts, account descriptions
and postings, accounting transactions, U.S. SGL Attributes, and crosswalks to standard external

24 Core Financial System Requirements

 General Ledger Management Function

reports. Each agency must implement a chart of accounts that is consistent with the U.S. SGL
and meets the agency’s information needs.

Mandatory Requirements

To support the General Ledger Account Definition process, the Core financial system must
provide the capability to:

• Allow users to define and maintain a chart of accounts consistent with the U.S. SGL,
including account titles and the basic numbering structure. (GLA-01)

• Incorporate proprietary, budgetary, and memorandum (credit reform) accounts in the

system, and maintain the relationships between U.S. SGL accounts as described in the
current TFM Supplement. (GLA-02)

• Provide U.S. SGL control accounts for detailed subsidiary accounts in the Core or
external systems. (GLA-03)

• Create additional sub-accounts to the U.S. SGL for agency specific tracking and control.
These sub-accounts will summarize to the appropriate U.S. SGL accounts. (GLA-04)

• Capture U.S. SGL attribute information required for both FACTS I and FACTS II
reporting as specified by the current supplement(s) to the TFM. (GLA-05)

• Provide flexibility so that the system can adapt to changes in FACTS I and FACTS II
reporting requirements. For example, the user should be able to add or modify valid
values within an existing attribute domain. (GLA-06)

• Process additions, deletions, and changes to the chart of accounts without extensive
program or system changes, (e.g., through on-line table updates). (GLA-07)

• Prohibit new transactions from posting to general ledger accounts that have been de-
activated. (GLA-08)

Value-added Requirements

There are no value-added requirements for this process.

Accruals, Closing and Consolidation Process

This process creates accrual transactions (adjusting) and closing entries needed at the end of a
period (month or year) for reporting purposes. It also controls and executes period-end system
processes needed by the system to open a new reporting period, such as rolling forward
account balances or reversing certain yearend entries. This process supports the preparation of
consolidated financial statements by identifying information needed in that process.

Mandatory Requirements

To support the Accruals, Closing, and Consolidation process, the Core financial system must
provide the capability to:

• Allow for accruals relating to contracts or other items that cross fiscal years. (GLB-01)

Core Financial System Requirements 25

General Ledger Management Function

• Automatically generate selected recurring accrual entries and reversals in subsequent

accounting periods (e.g., payroll accrual). (GLB-02)

• Close an accounting period and prohibit subsequent postings to the closed period.
(GLB-03)

• Automatically determine an accounting period’s opening balances based on the prior

accounting period’s closing balances, without user intervention or adjustment. The
rollover of general ledger balances must be accomplished in a detailed manner to
maintain the U.S. SGL attribute information required to satisfy FACTS I and FACTS II
reporting requirements. (GLB-04)

• Perform multiple preliminary yearend closings, while maintaining the capability to post
current and prior period data. (GLB-05)

• Automatically generate fiscal yearend pre-closing and closing entries as they relate to
fund types. (GLB-06)

• Provide for an automated yearend rollover of appropriate system tables into the new
fiscal year. (GLB-07)

Value-added Requirements

There are no value-added requirements for this process.

General Ledger Analysis and Reconciliation Process

This process supports the control functions of the General Ledger. The Core financial system
must provide information to use in determining that balances in the general ledger control
accounts agree with more detailed subsidiary accounts and for reconciling system balances with
financial information contained in reports from Treasury and other agencies. As internal
controls improve and system integration increases, the likelihood of out-of-balance conditions
decreases; however, the possibility of such conditions will always exist as a result of system
failures, incorrect transaction definitions, etc.

Mandatory Requirements

To support the General Ledger Analysis and Reconciliation process, the Core financial system
must provide the capability to:

• Compare amounts in the general ledger accounts with the amounts in the related
subsidiary records and create reports for those accounts that are out of balance. This
capability must be available for all open accounting period balances and at frequencies
defined by the user, such as daily, weekly and monthly. (GLC-01)

• Perform on-line "drill downs" from general ledger summary balances to detail
transactions and referenced documents (e.g., purchase orders, receiving reports, etc.).
(GLC-02)

• Record subsequent activity related to a closed document under a unique document ID

and provide an audit trail that associates the new activity with the transaction history of
the original document. (GLC-03)

26 Core Financial System Requirements

 General Ledger Management Function

Value-added Requirements

There are no value-added requirements for this process.

Core Financial System Requirements 27

Funds Management Function

Federal appropriations law, U.S. Comptroller General Decisions, OMB Circular No. A-34,
Instructions on Budget Execution, and (to a lesser extent), OMB Circular No. A-11, Preparation
and Submission of Budget Estimates, comprise authoritative guidance and set governmentwide
policy for funds management, which the Core financial system must support. In addition to
supporting the governmentwide policies, the Funds Management function must support agency
policies on internal funds allocation methods and controls.

An agency will likely have many other systems in addition to the Core financial system that
effect funds management. For example, procurement and travel systems generate documents
that commit and obligate funds. These and other systems that affect funds availability should
access data 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 editing 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 processes.

• Budget Preparation (FMA)

• Budget Formulation (FMB)

• Funds Allocation (FMC)

• Budget Execution (FMD)

• Funds Control (FME)

Budget Preparation Process

Budget preparation is the process of establishing initial agency operating/financial plans and
updating them as necessary throughout the fiscal year. An operating/financial plan is a
blueprint for using financial resources during any given fiscal period or series of periods. The
function includes reporting on the use of resources against these plans throughout the year.

Mandatory Requirements

To support the Budget Preparation process, the Core financial system must provide the
capability to:

• Establish and maintain operating/financial plans at or below the level of funds control.
(FMA-01)

• Establish operating/financial plans by month and quarter at any level of the

organizational structure specified by the user. (FMA-02)

• Track and report on the use of funds against operating/financial plans. (FMA-03)

28 Core Financial System Requirements

 Funds Management Function

Value-added Requirements

To support the Budget Preparation process, the Core financial system should provide the
capability to:

• Prepare operating/financial plans based on multiple measures, including obligations,

costs, labor hours, and full-time equivalents. (FMA-04)

• Modify/revise an existing operating/financial plan by line item. (FMA-05)

• Maintain original and modified operating/financial plans. (FMA-06)

• Identify legal and administrative limitations on funds in operating/financial plans.

(FMA-07)

• Generate allotments and sub-allotments (including limitations based on approved

changes to operating/financial plans). (FMA-08)

• Enter operating/financial plans for future operating periods. (FMA-09)

• Roll future plans into active budget plans based on future date or retrieval function.
(FMA-10)

Budget Formulation Process

Budget formulation is the process of assembling estimates for the upcoming fiscal year for
transmittal to OMB and the congressional appropriations committees, preparing justification
materials to support those estimates, and defending those estimates formally (at OMB and
congressional hearings) and informally (through staff contacts with these entities).

Mandatory Requirements

There are no mandatory requirements for this process.

Value-added Requirements

To support the Budget Formulation process, the Core financial system should provide the
capability to:

• Report information for all categories on which budgetary decisions are made, whether
legally binding (e.g., appropriation limitations) or in the nature of policy guidance and
decision-making (e.g., Presidential/OMB pass-backs, congressional markup documents,
or internal agency decisions). (FMB-01)

• Populate the budget formulation system with prior-year budgeted and actual amounts.
(FMB-02)

• Perform projections of obligations, income, and expenditures at any level of the

organizational structure (e.g., projecting obligations based on prior periods and applying
these to a future period). (FMB-03)

Core Financial System Requirements 29

Funds Management Function

• Adjust projection rates (e.g., 90 percent, 100 percent, and 110 percent) and exclude
specified obligations from projection. (FMB-04)

• Create, store, and modify payroll forecasts, including anticipated monthly compensation
and benefits, at the individual employee level. (FMB-05)

• Incorporate overhead distribution as part of budget formulation. (FMB-06)

• Develop budgets on-line and via upload from spreadsheets. (FMB-07)

• Prepare budget submission guidance, budget narratives, and budget briefing packages
on-line and via upload from desktop software applications. (FMB-08)

• Distribute budget submission guidance to subordinate organizations electronically.

(FMB-09)

• Establish and maintain multiple budget cycles. (FMB-10)

• Tie budget formulation to the agency’s stated goals and objectives required by GPRA.
(FMB-11)

Funds Allocation Process

This process records an agency’s budgetary resources and supports the establishment of
budgetary limitations at each of the levels required within the agency (e.g., apportionments and
allocations). The higher levels, such as appropriation, apportionment and allotment, have the
weight of legal authority behind the limitations. Lower levels of control are generally used for
internal management purposes.

Mandatory Requirements

To support the Funds Allocation process, the Core financial system must provide the capability
to:

• Record funding and related budget execution documents (e.g., warrants,

apportionments, allotments) and limitations. (FMC-01)

• Control the use of funds against limitations consistent with appropriation and
authorization language (including congressional intent and continuing resolutions) and
administrative limitations established by agency management. (FMC-02)

• Distribute, track, and control, funds at various levels, based on the elements of the
accounting classification and project structure. (FMC-03)

• Verify that funds distributed do not exceed the amount of funds available for allotment or
sub-allotment at each distribution level. (FMC-04)

• Support Public Law 101-510 (M-year legislation) by assuring that amounts paid out of
current year funds to cover obligations made against a closed account do not exceed 1
percent of the current year appropriation. (FMC-05)

30 Core Financial System Requirements

 Funds Management Function

• Record and control all types of budgetary authority, including appropriations, spending
authority from offsetting collections, borrowing authority and contract authority. Identify
the type of authority and track obligations by funding source (FMC-06)

• Record the expiration and cancellation of appropriation authority in accordance with

OMB Circular No. A-34 and the U.S. SGL. (FMC-07)

• Account for spending transactions at a lower level in the accounting classification than
they are budgeted. (FMC-08)

• Account for budgetary resources at a lower level in the accounting classification than
they are budgeted and controlled. (FMC-09)

• Prepare and electronically transmit SF-132s (Apportionment and Reapportionment

Schedules and associated financial information) to OMB. Store prepared requests as
submitted for future use. (FMC-10)

Value-added Requirements

To support the Funds Allocation process, the Core financial system should provide the
capability to:

• Generate budgetary data in format required by OMB's MAX system. (FMC-11)

• Automatically prepare the formal allotment and sub-allotment documents and

electronically distribute them to subordinate organizations. (FMC-12)

• Create continuing resolution funding levels based on a percentage of prior-year funding.

(FMC-13)

Budget Execution Process

The Budget Execution process is the most detailed level of an Agency’s funds control and
consists of processes needed to ensure that the agency’s funds control systems are fully
supported by its accounting systems. It also consists of processes needed to track an agency’s
budget authority and manage prior-year funds in the current year. Allotment systems should be
designed so that responsibility for budget control is placed at the highest practical organizational
level consistent with effective and efficient management and control.

Mandatory Requirements

To support the Budget Execution process, the Core financial system must provide the capability
to:

• Record budget authority at multiple levels of distribution (at least five). (FMD-01)

• Track and record all changes to budget authority - including rescissions, supplementals,
transfers between TAS/TAFS, reprogramming, limitations and changes to continuing
resolutions prior to appropriation enactment - at multiple levels of distribution (at least
five). (FMD-02)

Core Financial System Requirements 31

Funds Management Function

• Track actual amounts and verify commitments and obligations against the budget as
revised, consistent with each budget distribution level. (FMD-03)

• Modify funding distribution (including apportionments and allotments) at multiple

organizational levels (at least five). (FMD-04)

• Manage and control prior-year funds in the current year. (FMD-05)

• Establish and maintain user-defined variance tolerances by document type, percentage,

and a “not-to-exceed” dollar threshold. (FMD-06)

• Automatically withdraw (or cancel) uncommitted and unobligated allotments and sub-
allotments for all or selected TAS/TAFS at the end of a specific fiscal period. (FMD-07)

• Automatically withdraw (or cancel) uncommitted and unobligated allotments and sub-
allotments for selected organizations at the end of a specific fiscal period. (FMD-08)

• Distribute the annual budget in accordance with the latest SF-132 Apportionment and
Reapportionment Schedule approved by OMB. (FMD-09)

Value-added Requirements

To support the Budget Execution process, the Core financial system should provide the
capability to:

• Request approval for reprogramming and request additional funds outside the periodic
budget review process. Allow such requests to be submitted, reviewed, revised, and
approved. Approval would update current operating budgets. (FMD-10)

Funds Control Process

This process records transactions affecting the resources and status accounts in the budgetary
section of the U.S. SGL. It also provides appropriate warnings and controls to ensure that
budgetary limitations are not exceeded. The Funds Control process consists of the following
activities:

• Funds Availability Editing

• Commitments

• Obligations

• Analysis.

Funds Availability Editing. This activity verifies that sufficient funds are available at the
various control levels specified in the Funds Allocation process for each processed transaction
that may affect available fund balances. If sufficient funds are not available, notification is
provided so that appropriate action may be taken.

32 Core Financial System Requirements

 Funds Management Function

Mandatory Requirements

To support the Funds Availability Editing activity, the Core financial system must provide the
capability to:

• Establish and modify multiple levels of funds control using elements of defined
accounting classifications, including object class, program, organization, project, and
fund. (FME-01)

• Establish and modify the system’s response (either reject transaction or provide
warning) to the failure of funds availability edits for each transaction type. (FME-02)

• Perform on-line inquiry of funds availability prior to the processing of spending

transactions (commitments, obligations, and expenditures). (FME-03)

• Determine funds availability based on whether funds cited are current, expired, or
canceled and record appropriate accounting entries when de-obligation of expired
funding occurs. Do not allow the use of de-obligated prior-year funds for current year
expenditures. (FME-04)

• Record transactions that affect the availability of funds, including commitments,

obligations, and expenditures. (FME-05)

• Provide for modification to spending documents (commitments, obligations and

expenditures), including ones that change the dollar amount or the accounting
classification cited. Check for funds availability when changes are made. (FME-06)

• Provide on-line notification to users of transactions failing funds availability edits, and
make the rejected transactions available for corrective action. This is to include
transactions entered directly to the Core system and those received from external
modules or systems. (FME-07)

• Override funds availability edits, including automatically releasing and processing

transactions previously rejected for exceeding user-defined tolerances. Produce a
report or otherwise notify management of the over obligation of funds. (FME-08)

• Automatically update all appropriate budgetary accounts and or tables to ensure that the
system always maintains and reports the current status of funds. (FME-09)

• Check for funds availability when the obligation exceeds the commitment document or
when the expenditure (upon receipt or disbursement) exceeds the obligating document
due to quantity or price variances, additional shipping charges, etc., within tolerances.
Provide on-line notification when tolerances are exceeded. When variances are within
tolerances, process and adjust the obligation accordingly. (FME-10)

• Allow for available fund balances to be based on reimbursable customer orders

accepted. In the case of reimbursable orders from the public, ensure that an advance
must also be received before additional funding authority is recorded. (FME-11)

• Track all activity related to an individual reimbursable agreement. When recording

commitments, obligations, and expenditures incurred in support of reimbursable

Core Financial System Requirements 33

Funds Management Function

agreements, check for funds availability against the amount authorized by the
agreement and the corresponding start and end dates. (FME-12)

• Record and maintain reimbursable agreements, (e.g., inter-agency agreements,) so that

monthly, quarterly, and fiscal year-to-date as well as inception-to-date information can
be presented. (FME-13)

Value-added Requirements

To support the Funds Availability Editing activity, the Core financial system should provide the
capability to:

• Automatically notify users when funds availability is reduced by transactions from

external systems (e.g., credit card payments, and payroll). (FME-14)

Commitments. Commitments are an optional stage of fund reservations prior to the

establishment of an obligation. This activity records commitment documents, such as
requisitions. Commitments can be a useful tool in funds management by helping users to
anticipate future procurements. They should be used when helpful to an agency’s management
process, but are not necessary, or even appropriate, for all situations.

However, the Core financial management system must provide the capability to use this stage
of funds control, and therefore must meet the mandatory requirements below.

Mandatory Requirements

To support the Commitment activity, the Core financial system must provide the capability to:

• Maintain information related to each commitment document, including amendments.

The Core financial system must capture:

o Requisition number,
o Appropriate accounting classification values, and
o Estimated amounts. (FME-15)

• Input line item detail for commitment documents, including item description, unit price,
quantity of goods and services, accounting information, and amounts. (FME-16)

• Future-date, store, and automatically post commitment documents at the appropriate

date. Subject these documents to edit and validation procedures prior to posting.
Provide notification when transactions are posted. (FME-17)

• Close commitments by document and line item under the following circumstances: (1)
automatically by the system upon issuance of an obligating document, (2) by an
authorized user, and (3) automatically as part of the yearend pre-closing process.
(FME-18)

Value-added Requirements

There are no value-added requirements for this activity.

34 Core Financial System Requirements

 Funds Management Function

Obligations. OMB Circular No. A-34 defines obligations as a binding agreement that will result
in outlays, immediately or in the future. Budgetary resources must be available before
obligations can be incurred legally. Examples are amounts of orders placed, contracts
awarded, services received, and similar transactions that will require payments during the same
or a future period. Such amounts include outlays for which obligations had not been previously
recorded and reflect adjustments for differences between obligations previously recorded and
actual outlays to liquidate those obligations.

Mandatory Requirements

To support the Obligation activity, the Core financial system must provide the capability to:

• Record obligations for which there is no related commitment. (FME-19)

• Maintain information related to obligation documents and related amendments, including

obligating document number and type; vendor information, accounting classification
elements, referenced commitment (if applicable); and dollar amounts. (FME-20)

• Future-date, store, and automatically post obligation documents at the appropriate date.
Subject these documents to edit and validation procedures prior to posting. Provide
notification when transactions are posted. (FME-21)

• Enter recurring obligation transactions that will be automatically posted at various time
intervals such as monthly, quarterly or a specific number of days determined by the user.
(FME-22)

• Allow multiple commitments to be combined into one obligating document. (FME-23)

• Allow one commitment document to be split between multiple obligating documents.

(FME-24)

• Reference multiple funding sources on a single commitment or obligation. (FME-25)

• Allow authorized modifications and cancellations of posted obligating documents.

(FME-26)

• Provide on-line access to all obligations by selection criteria (e.g., document number,
vendor number, accounting classification elements). (FME-27)

• Maintain an on-line history file of closed-out documents for a user-defined period of time.
(FME-28)

• Allow the vendor used on an obligation to be different from suggested vendor recorded
on the related commitment document. (FME-29)

• Close obligation documents under the following circumstances: (1) automatically by the
system upon final payment for goods or services, or (2) by an authorized user. Upon the
closing of an obligation, automatically classify any de-obligation of excess funds to the
appropriate budgetary status (i.e., expired, unexpired, available for obligation or
unavailable). (FME-30)

Core Financial System Requirements 35

Funds Management Function

• Record and maintain contracts and grants and related financial activity so that fiscal
year-to-date and inception-to-date information can be presented. (FME-31)

• Record blanket purchase agreements, and record, control, and track records of call.
(FME-32)

• Record, control, and track delivery orders against a contract limitation. (FME-33)

• Record advance payments made, such as travel advances, contract advances, and
grants. Ensure that an obligation exists prior to recording an advance. (FME-34)

• Record expenditures claimed against advance payments made, and automatically

liquidate the advance either partially or fully, as appropriate. Allow the recording of
advance refunds. (FME-35)

• Automatically link transactions in the spending chain, and bring forward accounting and
non-financial information from one document to another, when the previously accepted
document is referenced (e.g., commitment to obligation, obligation to receiving report).
(FME-36)

Value-added Requirements

To support the Obligation activity, the Core financial system should provide the capability to:

• Maintain the following additional data fields for each obligating document

o Requester’s name
o Telephone number of requester
o Contract number/GSA schedule number
o Deliver to location (e.g., room number, division)
o Comment field
o Contact name
o COTR name
o COTR telephone number
o Prompt Pay indicator
o Approval date, and
o Discount payment terms. (FME-37)

Analysis. The Analysis activity provides information necessary to support analysis of the
Funds Management function. It provides information on funds availability at the levels defined
and compares data in the Funds Management function to data in other functions to ensure
consistency.

Mandatory Requirements

To support the Analysis activity, the Core financial system must provide the capability to:

• Maintain current information on commitments and obligations according to the required

accounting classification elements (see CFA-01). (FME-38)

• Produce detailed listings and summary reports of commitments, obligations and

expenditures by the elements of the defined accounting classifications. (FME-39)

36 Core Financial System Requirements

 Funds Management Function

• Provide control features that ensure that the amounts reflected in the fund control
structure agree with the related general ledger account balances at the end of each
update cycle. (FME-40)

• Maintain historical data on all commitment, obligation, payment and collection

transactions. (FME-41)

• Maintain open documents to show the status of commitments, obligations, accruals, and
disbursements by document line item. (FME-42)

• Provide the ability to perform document cross-referencing in which a user can query on
any document and identify the document numbers of associated transactions in the
processing "chain" (e.g., querying on a purchase order would provide any amendments
to purchase orders, receiving reports, requisitions, and invoices; querying on a
receivable would provide any associated cash receipts). (FME-43)

Value-added Requirements

There are no value-added requirements for this activity.

Core Financial System Requirements 37

Payment Management Function

Federal payment regulations are documented in several different sources. Title 5, Part 1315 of
the code of Federal Regulations (CFR) (codification of OMB Circular No. A-125, Prompt
Payment 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 Cash Management Improvement Act (CMIA)
specifies requirements for payments made to states. Regulations implementing CMIA are
specified in 31 CFR 205. The Debt Collection Improvement Act (DCIA) of 1996 provides for
access to taxpayer identification numbers (TINs) and enhanced administrative offset and salary-
offset authorities. Other regulations govern payments made for travel, payroll, benefits, and
other purposes.

Depending on an agency’s system architecture, specific activities performed relating to

payments may be supported by other systems that provide transaction data to the Core financial
system for control and management purposes. For example, payroll systems usually trigger the
actual disbursement process to pay employees through direct deposit or by check, and send
only the expense and disbursement information to the Core financial system for recording by the
general ledger, funds control, and cost management processes. Likewise, large loan and grant
programs might be supported by systems that maintain their own detailed information on
payees and payments and send transaction data to the Core financial system. If the supporting
systems are covered by one or more other JFMIP FFMSR documents, agencies should refer to
those documents for specific payment management requirements. If the supporting systems
use payment management functionality of the Core system, then payments initiated from other
systems are subject to the applicable requirements listed here for payment management. In
other words, these requirements apply to all payments processed through the Core system.

For example, another system 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. A travel system might 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 consists of the following processes.

• Payee Information Maintenance (PMA)

• Payment Warehousing (PMB)

• Payment Execution (PMC)

• Payment Confirmation and Follow-up (PMD)

Payee Information Maintenance Process

The term “payee” is used here to include any entity to which disbursement may be made, for
example, individuals and organizations providing goods and services, employees, grant
recipients, loan recipients, and other Government agencies. In an integrated system, payee
information needed to make payments should be coordinated with information needed for other
purposes and in other systems. For example, a company that provides goods and services to

38 Core Financial System Requirements

 Payment Management Function

an agency should have a common identifier, such as a TIN, associated with it that is shared by
the procurement and payment processes. With this common identifier, contract information and
payment information can be linked, even if the addresses for ordering and paying are different.
Furthermore, such information should also be available to the procurement and payment
processes.

Mandatory Requirements

To support the Payee Information Maintenance process, the Core financial system must
provide the capability to:

• Maintain payee (vendor) information to support obligation, accounts payable, and

disbursement processes, including:

o Vendor name
o Vendor ID number
o Vendor type (e.g., Federal agency, state/local government, commercial entity,
individual, employee)
o TIN
o Three or more payment addresses
o Three or more separate instances of banking information (i.e., account and routing
numbers) for issuing payments
o Bank account type (check or savings)
o Three or more contact names
o Three or more contact telephone numbers
o Federal vs. Non-federal indicator
o Six-digit Trading Partner codes
o Entity type (e.g., small business, 8A, women owned business)
o Multiple vendor payment methods (e.g., Electronic Funds Transfer (EFT), check)
o Third-party information (e.g., payee TIN for notice of assignment)
o Data Universal Numbering System (DUNS) number
o ALC number (for Federal vendors)
o Subject to Prompt Pay indicator
o Internal Revenue Service (IRS) -1099 indicator
o W-2 indicator
o Comment field
o Date of last update, and
o User ID of last update. (PMA-01)

• Support payments made to third parties (payees) that act as an agent for the payee
(vendor). Maintain information needed to produce IRS –1099s for the principal party
rather than the agent. (PMA-02)

• Prevent the duplicate entry of vendor records (e.g., by editing vendor ID numbers or
vendor names.) Provide an on-line warning message to the user when duplication is
identified. (PMA-03)

• Track and maintain a history of changes to the vendor file, including vendor additions
and purges, and changes to vendor specific information such as payment address, bank
account and routing information, and payment type. Maintain an audit trail of payments
made to historical vendor information. (PMA-04)

Core Financial System Requirements 39

Payment Management Function

• Query and report on payee information by user-defined criteria, such as payee name,
payee number, and IRS -1099 reporting status. (PMA-05)

• Activate and deactivate vendors that meet user selected criteria (e.g., such as length of
time with no activity.) (PMA-06)

Value-added Requirements

To support the Payee Information Maintenance process, the Core financial system should
provide the capability to:

• Capture vendor information required when registering with the Central Contractor
Registration (CCR) and track activity by CCR identifier. (PMA-07)

Payment Warehousing Process

This process recognizes and records payments due to another entity in the near term. These
payments may be due for any of several reasons; for example, as a result of receiving goods
and services in accordance with contract terms, under a loan or grant agreement, as an
advance payment for goods or services to be provided in the future, or as a progress payment
under a construction contract.

Title 5, Part 1315 of the CFR requires documentation to support payment of invoices and
interest, including information from contracts, purchase orders, invoices, and receiving reports.
These documents should be matched through a process, which may be automated, manual, or
a combination, that ensures payments are made in accordance with contract terms and
applicable regulations. Adequate internal controls should be in place to verify that goods and
services paid for were actually ordered and received and are paid for only once and at the
agreed-upon price.

Mandatory Requirements

To support the Payment Warehousing process, the Core financial system must provide the
capability to:

• Record an accrued liability upon receipt and acceptance of goods and services and
properly identify them as capital asset, expense, prepaid expense, or construction.
(PMB-01)

• Record "full" or "partial" receipt and acceptance of goods and services by line item.
(PMB-02)

• Automatically update the funds control and budget execution balances to reflect changes
in the status of obligations and expended appropriations, as well as changes in amounts.
(PMB-03)

• Warehouse payment vouchers for future scheduling. (PMB-04)

• Allow a warehoused payment to be modified, cancelled, and put on hold. (PMB-05)

40 Core Financial System Requirements

 Payment Management Function

• Automatically match invoices to obligations and receiving reports by document and line
item. Provide for two-way matching (obligation and invoice) and three-way matching
(obligation, receiving report, and receipt of invoice). (PMB-06)

• Process "obligate and pay" transactions where payment scheduling and obligation
occurs simultaneously. (PMB-07)

• Reference multiple obligations on a single invoice document. (PMB-08)

• Set up recurring payments in the system and automatically schedule items (e.g.,
contracts, leases, etc.) for payment on an interval determined by the user (i.e., weekly,
bi-weekly, monthly, quarterly or other specified number of days). (PMB-09)

• Modify recurring payment information for changes in agreement terms, amounts,

frequency, etc. (PMB-10)

• Capture, store and process the following information for each vendor invoice, for audit
trail, research and query purposes:

o Invoice number
o Invoice date
o Invoice receipt date
o Invoice due date
o Invoice amount
o Unit price and quantity
o Description
o Discount terms, as applicable
o Obligating document reference(s)
o Vendor identification number and address code. (PMB-11)

• Edit the TIN field to ensure that it is a nine digit numeric field, does not include dashes,
and is not all zeroes. Allow for override for agency specific requirements. (PMB-12)

• Accommodate an invoice number field of up to 30 characters or the current requirement

of I TFM-6-5000. (PMB-13)

• Determine the due date and amount of vendor payments in accordance with Title 5, Part
1315 of the CFR which states, in part, that for agencies subject to prompt payment
requirements, payment is due on either: (1) 30 days after the receipt of a proper invoice
for services and non-dairy products; (2) 10 days after the receipt of a proper invoice for
dairy products; (3) the date specified in the contract; (4) in accordance with discount
terms when discounts are offered and taken; or (5) in accordance with Accelerated
Payments Methods. (PMB-14)

• Manually override a system-calculated payment due date. (PMB-15)

• Split an invoice into multiple payments on the appropriate due dates when items on the
invoice have different due dates or discount terms. (PMB-16)

• Record discount terms and automatically determine whether taking the discount is
economically justified as defined in I TFM-6-8040. (PMB-17)

Core Financial System Requirements 41

Payment Management Function

• Record additional shipping and other charges to adjust the payment amount, if they are
authorized and within variance tolerances. (PMB-18)

• Record obligations, expenses, assets, etc., associated with payments made through use
of Imprest funds, third-party drafts, and Government credit cards. Establish payables to
replenish the Imprest fund. (PMB-19)

• Record detailed transactions associated with credit card purchases. Allow users to
change accounting classification information by line item for specific transactions.
(PMB-20)

• Schedule payments of advances, prepaid expenses, loans, and grants, with the
appropriate accounting entries for each. (PMB-21)

• Establish payables and make payments on behalf of another agency, citing the other
agency’s funding information. For each disbursement made on behalf of another
agency, provide the information required (e.g., purchase order number or reimbursable
agreement number and the ALC) by Central agency systems (e.g., On-line Payment and
Collection System (OPAC)/Intra-governmental Payment and Collection System (IPAC))
to the appropriate Central agency system. (PMB-22)

• Record expense or assets when goods have been received, or services performed, for
items that were funded by advances, prepaid expenses, and grants and make the
appropriate liquidations. Verify funds availability and automatically update funds control
account and or table balances to reflect obligation changes. (PMB-23)

• Indicate if a payment is “partial” or “final.” If “final,” automatically de-obligate any

unliquidated balances. (PMB-24)

Value-added Requirements

To support the Payment Warehousing process, the Core financial system should provide the
capability to:

• Automatically generate a payment voucher if the purchase order matches the receiver
information. Provide this option as a function of the matching process. (PMB-25)

• Use the Fast Payment clause indicator on the obligating document to determine whether
or not an accelerated payment is to be made. (PMB-26)

• Compare discount terms on the invoice with discount terms on the related obligating
document. Notify the user when differences are identified. (PMB-27)

• Provide a system-generated letter or e-mail to the vendor stating the reason for rejection
or "notice of intent to disallow" an invoice within 7 days of receipt of invoice. (PMB-28)

Payment Execution Process

This process supports activities required to make a payment that was warehoused or to record
a payment made by another system. The system should provide the capability to capture, store
and process information needed to create EFT payments for agencies for which Treasury does
the actual disbursing and prepare requests for disbursements that are transmitted to Treasury.

42 Core Financial System Requirements

 Payment Management Function

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 below.

Mandatory Requirements

To support the Payment Execution process, the Core financial system must provide the
capability to:

• Automatically identify and select payments to be disbursed in a particular payment cycle

based on their due dates. Provide for on-line review and certification by an authorized
certifying officer. (PMC-01).

• Automatically compute amounts to be disbursed, including discounts, interest, and

penalties, in accordance with Title 5, Part 1315 of the CFR. Generate the appropriate
transactions to reflect the payment deductions and additions. (PMC-02)

• Automatically apply interest and discount across multiple accounting lines on an invoice
in the same rule used to apply the original payment. (PMC-03)

• Apply the appropriate Treasury interest rate tables (e.g., Prompt Pay rate and Current
Value of Funds rate). (PMC-04)

• Capture prompt payment information required by Title 5, Part 1315 of the CFR, including
discounts taken, discounts lost, and interest paid. (PMC-05)

• Automatically include relevant identification information on each remittance, including:

vendor invoice number(s); obligating document number or other reference number; and
discount, interest and offset amounts, as applicable. (PMC-06)

• Record user comments for each voucher/invoice. (PMC-07)

• Provide for up to 9,999 line items per invoice. (PMC-08)

• Record reason codes for returned and adjusted invoices, lost discounts, and late
payments. (PMC-09)

• Track the status of invoices in the payment process, including those that were not
accepted and returned to the vendor and those that are awaiting administrative approval.
Maintain the time and aging of approvals in relation to payments. (PMC-10)

• Provide for various forms of payment to be used (i.e., check or EFT (e.g., Automated
Clearing House (ACH) and wire)). Capture, store and process information needed to
create EFT payments in accordance with Treasury standards, including American
Bankers Association Routing Transit Number (RTN), recipient bank account number,
and bank account type (checking or savings). This includes the ability to identify
employees versus companies to ensure use of correct ACH formats. (PMC-11)

• Generate ACH payments in Corporate Trade Exchange (CTX) (820 or Flat File), Cash
Concentration or Disbursement (CCD), Cash Concentration or Disbursement Plus
Addendum (CCD+), Prearranged Payment and Deposit (PPD), and Prearranged
Payment and Deposit Plus Addendum (PPD+) formats. (PMC-12)

Core Financial System Requirements 43

Payment Management Function

• Ensure that employee ACH payments are generated only as PPD or PPD+ payments.
(PMC-13)

• Ensure that vendor ACH payments are generated only as CCD, CCD+ or CTX formats.
(PMC-14)

• Prohibit the creation of an ACH payment in any format (PPD, PPD+, CCD+, or CTX) that
does not contain a RTN and an account number. (PMC-15)

• Consolidate multiple payments to a single payee in accordance with TFM prescribed

limitations (currently up to 14 lines of 55 characters each for check payments, up to
9,999 lines of 80 characters each for CTX payments). Itemize all payments covered by
the one check or EFT (CTX only). However, allow for separate checks to a payee.
(PMC-16)

• Create check files and EFT payment files in all formats (CTX (820 or Flat File), CCD,
CCD+, PPD, and PPD+) using different media (telecommunications, tape, direct entry to
Electronic Certification System (ECS), and third party upload through ECS). (PMC-17)

• Provide an edit on the RTN field. The field is a nine-digit numeric-only field. Prohibit
fewer or more than nine characters, allow for only numeric characters, and prohibit the
entry of all zeroes in this field. Edit RTN’s against the data supplied in the Financial
Organization Master File (or other verified update file) to ensure the validity of the check
digit (Modulus 10 check). (PMC-18)

• Edit the invoice number field to ensure it is populated. Prohibit the generation of a
(vendor) payment that does not contain properly structured remittance information on the
addendum. (PMC-19)

• Generate multiple payments using the same invoice number, to accommodate utility and
telecommunication companies’ use of an account number as a recurring invoice number.
(PMC-20)

• Edit the ALC field to ensure it is an eight digit numeric field. Allow for override (e.g., by
agencies that have their own disbursing authority.) (PMC-21)

• Create one check file regardless of payee type (employee or vendor). (PMC-22)

• Combine payment files from multiple ALCs into a single file for transmission to Treasury.
Provide summary totals (items and dollars) by ALC and for the entire file for certification
purposes. (PMC-23)

• Make CTX payments using a separate file. The transactions need to be balanced (sum
of all the remittance records must equal the transaction total). The file must include a
valid settlement date (next business day or later). The file must be able to
accommodate the inclusion of Credit Memos. (PMC-24)

• Schedule and disburse U.S. dollar payments (SF-1166) through the Treasury’s ECS,
containing up to the limit of 60 payments per schedule and 100 schedules for each ECS
terminal per day. (PMC-25)

44 Core Financial System Requirements

 Payment Management Function

• Process payment transactions from other systems, such as payroll and travel. Identify
whether or not disbursement has already been made, and record the appropriate
accounting entries. Schedule those disbursements not already made for payment
through the Core financial system. (PMC-26)

• Automatically generate transactions to reflect disbursement activity initiated by other

agencies and recorded in Central agency electronic systems (such as OPAC/IPAC).
Capture related information required by the Central agency system for each transaction
(e.g., purchase order number, reimbursable agreement number, ALC). (PMC-27).

• Flag vouchers selected for payment that will disburse a fund into a negative cash
position. (Reimbursable work can result in this type of transaction with appropriate
authority.) (PMC-28)

• Process credit memoranda for returned goods or other adjustments. Apply the credit to
the specific obligation that resulted in the credit, reducing the expenditure attributed to
that obligation. If a credit is not fully liquidated by one payment, maintain the balance of
the credit (e.g., as an account receivable) for application against a future payment.
Create the appropriate notice to the vendor that a credit has been applied to the affected
payment. (PMC-29)

• Apply credits against subsequent disbursements to the same vendor regardless of the
funding source. (PMC-30)

• Allow for the exclusion of payments from agency offset based on user-defined criteria
including funding source, object class, vendor type and vendor number. (PMC-31)

• Provide, generate, and maintain a sequential numbering system for scheduling

payments to the disbursing office. Assign different schedule number ranges for different
payment types, such as travel schedules, transportation schedules, payroll schedules,
vendor schedules, etc. Require each schedule number to be unique. (PMC-32)

• On each payment schedule/file, report totals by TAS/TAFS. (PMC-33)

• Cancel an entire payment schedule or a single payment within a payment schedule,

prior to transmission to Treasury. Allow for reversal of an entire schedule in a single,
interactive action. Perform the appropriate accounting reversals. (PMC-34)

• Cancel an entire payment schedule prior to actual disbursement by or upon rejection by

Treasury. Allow for reversal of an entire schedule in a single, interactive action. Perform
the appropriate accounting reversals. (PMC-35)

Value-added Requirements

To support the Payment Execution process, the Core financial system should provide the
capability to:

• When consolidating multiple payments to a single payee, include the TAS/TAFS

associated with each payment in the payment file. (PMC-36)

• When combining payment files for multiple ALCs into a single file for transmission to
Treasury, provide summary totals by TAS/TAFS. (PMC-37)

Core Financial System Requirements 45

Payment Management Function

• Provide National Automated Clearing House Association (NACHA) payment formats for
Non-Treasury Disbursing Offices. (PMC-38)

• Split a single payment into separate bank accounts (e.g., benefit payments to
recipients). (PMC-39)

• Provide statistical sampling capabilities to support agency payment certification.

(PMC-40)

• Identify and report payment and deposit amounts at a detail suitable for reporting large
dollar notifications as described in I TFM-6-8500, Cash Forecasting Requirements.
(PMC-41)

Payment Confirmation and Follow-up Process

This process confirms that disbursements were made as anticipated and supports inquiries from
vendors regarding payments and reporting requirements relating to the Payment Management
function.

Mandatory Requirements

To support the Payment Confirmation and Follow-up process, the Core financial system must
provide the capability to:

• Provide information about each payment to reflect the stage of the scheduling process
that the payment has reached and the date each step was reached for the following
processing steps:

o Payment scheduled
o Schedule sent to appropriate disbursing office
o Payment issued by appropriate disbursing office. (PMD-01)

• For each payment made by the Core financial system, maintain a history of the following
information:

o Vendor Invoice number

o Invoice amount
o Vendor identification number
o Vendor name
o Payment address or banking information
o Payment amount
o Interest paid, when applicable
o Discount taken, when applicable
o Offset made, when applicable
o Payment method (e.g., check, EFT)
o Referenced obligation number, and
o Appropriation charged. (PMD-02)

• Automatically update the payment information when confirmation is received from the
disbursing office, including the paid schedule number, payment date and check number
or trace number. (PMD-03)

46 Core Financial System Requirements

 Payment Management Function

• Automatically liquidate the in-transit amount and reclassify budgetary accounts from
unpaid to paid when the payment confirmation updates the system. (PMD-04)

• Record more than one check range for a payment schedule, along with a break in check
numbers. (PMD-05)

• Provide on-line access to vendor and payment information. (PMD-06)

• Provide on-line access to open documents based on agency selection criteria, including
the accounting classification elements, document number, and vendor number.
(PMD-07)

• Reverse disbursement transactions for voided checks or for other payments that have
not been negotiated. (PMD-08)

• Produce IRS-1099s (such as 1099-INT, 1099-MISC, 1099-C and 1099-G) in accordance

with IRS regulations and current IRS acceptable format, including hard copy and
electronic form. For example, when payment to a sole proprietor for services performed
(not including cost of merchandise) exceeds a specified dollar amount (e.g., $600)
produce a 1099-M. (PMD-09)

• Electronically download monthly “Fund Balance with Treasury” and activity recorded by
Treasury (and related warrant information) for comparison to cash activity in the
agency’s general ledger. Produce a report of differences. (PMD-10)

Value-added Requirements

To support the Payment Confirmation and Follow-up process, the Core financial system should
provide the capability to:

• Include the TAS/TAFS charged and the associated amount(s) in the history of each
payment made by the Core financial system. (PMD-11)

• Provide an automated interface to the Department of Treasury system containing paid

schedule data (i.e., Government On-line Accounting Link System (GOALS) Regional
Finance Center Agency Link, or its successor). (PMD-12)

• Provide written notification to payees (vendors, travelers, etc.) of payments made by

disbursing offices. Allow for agency flexibility in defining the contents of the notifications.
(PMD-13)

• Provide e-mail notification to employees of travel payments made by disbursing offices.

(PMD-14)

• Track and report on aged, unmatched vendor invoices. (PMD-15)

• Track and report on spending agency-wide by state and congressional district. (PMD-16)

Core Financial System Requirements 47

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), loans made to others that must be repaid, or other actions. Receivables are
accounted for as assets until funds are collected, or determined to be uncollectible in whole or in
part. Additionally, some receipts may be collected without the prior establishment of a
receivable, as in the case of goods sold for cash.

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, and on debts due from State and local governments.
OMB Circular No. A-129, Policies for Federal Credit Programs and Non-tax Receivables,
prescribes policies and procedures for collecting non-tax receivables and sets standards for
servicing these receivables and for collecting delinquent debt. The DCIA of 1996 provides that
any non-tax debt owed to the United States that has been delinquent for a period of 180 days
shall be turned over to the Secretary of the Treasury for appropriate action to collect or
terminate collection actions on the debt or claim, with certain exceptions. The DCIA provides for
access to taxpayer identification numbers (TIN) and enhanced administrative offset and salary
offset authorities.

Depending on an agency’s system architecture, servicing and collection activities for some
receivables may be supported by other systems that provide data to the Core financial system.
This would be particularly appropriate for receivables resulting from large programs with
complex supporting data requirements, such as loan programs, grant programs, or fee-for-
service programs. Servicing and collection for receivables with simpler requirements for
supporting data, such as those resulting from erroneous payments, may be supported directly
by the Core financial system with no support by other systems.

The Receivable Management function includes recording, billing, monitoring, and collecting
amounts due the Government whether previously established as a receivable or not. These
activities must be supported by aging schedules, exception reports, and reports used to monitor
due diligence efforts.

The Receivable Management function consists of the following processes.

• Customer Information Maintenance (RMA)

• Receivable Establishment (RMB)

• Debt Management (RMC)

• Collections and Offsets (RMD)

Customer Information Maintenance Process

The word “customer” is used here to include any entity that owes a debt to the agency, including
contractors, employees, grantees, loan recipients and other Government agencies. Agency
payees, or vendors, as defined in the preceding Payment Management Function section, may
become customers of the agency, in the event that duplicate or overpayments occur.

48 Core Financial System Requirements

 Receivable Management Function

The Customer Information Maintenance process involves the maintenance of customer

information (name, address, etc.), identification of the type of customer from which collection is
due, and the recording of trading partner codes used in the elimination of intra-governmental
activity from financial statements. The process ensures that customer TINs are captured in
order to report overdue receivables for potential offset and to provide for IRS 1099 reporting of
debts written off.

The Customer Information Maintenance process also supports billing, reporting and research
activities through the association of customer information with individual accounts receivable.

Mandatory Requirements

To support the Customer Information Maintenance process the Core financial system must
provide the capability to:

• Maintain customer information to support receivable management processes, including,

at a minimum:

o Customer name
o Customer ID number
o Customer type (federal agency, state/local government, commercial entity, individual,
employee)
o Taxpayer Identification Number (TIN)
o Customer address
o Contact names
o Contact telephone number
o Federal vs. Non-Federal indicator
o Six-digit Trading Partner codes
o ALC number (for Federal customers)
o Internal Revenue Service (IRS) 1099 indicator
o Comment field
o Date of last update
o User ID of last update
o DUNS number (RMA-01)

• Maintain customer account information for audit trail purposes and to support billing,
reporting and research activities, including:

o Account number
o Account balance
o Associated Customer ID number
o Date due and age of accounts receivable
o Reimbursable order number, travel order number, etc., where applicable. (RMA-02)

Value-added Requirements

There are no value-added requirements for this process.

Core Financial System Requirements 49

Receivable Management Function

Receivable Establishment Process

The Receivable Establishment process supports activities to record receivables in the system
as they are recognized and to produce bills for amounts due to the agency.

Mandatory Requirements

To support the Receivable Establishment process, the Core financial system must provide the
capability to:

• Record the establishment of receivables along with the corresponding revenues,

expense reductions, or other offsets. (RMB-01)

• Accept transactions that generate receivables from other systems in a standard format
for entry into the Core financial system. (RMB-02)

• Support the calculation and establishment of accounts receivable based upon billing
source, event and time period, and type of claim. Automatically generate related bills to
customers. Bases used for billing may include:

o Percentage of reimbursable obligations, accrued expenditures, or costs, using data

recorded by the cost accumulation function;
o Fee schedules for goods or services provided; and
o Payment schedules or other agreements with other entities. (RMB-03)

• Establish receivables and credit memos from vendors to whom the agency has made
duplicate or erroneous payments. (RMB-04)

• Uniquely identify multiple types of bills (e.g., overpayments, user fee based) and the
supporting data used to verify the specific charges. (RMB-05)

• Automatically establish receivables to be paid under installment plans, including plans

for which payments have been rescheduled. Generate flexible repayment schedules for
delinquent indebtedness. (RMB-06)

• Record billings and collections by line item in order to identify unique accounting
classification codes. (RMB-07)

• Support bills and collections between Federal agencies through the use of electronic
systems such as IPAC. Provide supporting data to agencies billed which can be used to
verify the charges. (RMB-08)

• Print bills, accommodating the generation of standard forms, such as SF-1080s or SF-
1081s, and turnaround documents to be used as a remittance advice. Allow for
customized text in generated billing documents. (RMB-09)

• Date the bills with the system-generated date or with the date supplied by the user.
(RMB-10)

• Consolidate multiple accounts receivable for a customer onto one bill. (RMB-11)

50 Core Financial System Requirements

 Receivable Management Function

• Allow transactions related to manually prepared bills to be entered by authorized

personnel. (RMB-12)

• Record adjustments to bills and post to customer accounts. (RMB-13)

• Generate monthly statements to customers showing account activity. (RMB-14)

Value-added Requirements

There are no value-added requirements for this process.

Debt Management Process

The Debt Management process involves the maintenance of account information on individual
accounts receivable. The process supports activities to: age receivables; calculate interest and
record penalties and administrative charges on overdue debt; pursue collection of amounts due;
liquidate receivables; record adjustments to receivables; maintain a proper allowance for
uncollectible amounts; and record write-offs.

Mandatory Requirements

To support the Debt Management process, the Core financial system must provide the
capability to:

• Maintain data on individual receivables and referenced transactions supporting the

receivable. (RMC-01)

• Maintain accounts for reimbursable orders and identify Government and non-
government accounts that are designated as advance funding. (RMC-02)

• Update each customer account when: billing documents are generated; collections are
received; interest, penalty or administrative fees are applied, and when amounts are
written-off or offset. (RMC-03)

• Automatically calculate interest charges using the appropriate Treasury Late Payment
Charge rate and user-defined criteria (e.g., customer, customer type). Automatically
generate a separate line item for interest charges on the customer bill. (RMC-04)

• Allow the user to specify administrative and penalty amounts and record these amounts
to different accounting classification elements for which the principle amount is recorded.
Automatically apply these charges to customer accounts and generate separate line
items for the charges on the customer bills. (RMC-05)

• Automatically generate dunning (collection) letters for overdue receivables when

accounts become delinquent, and incorporate, as appropriate, due process notices for
referring delinquent accounts. (RMC-06)

• Customize the dunning process parameters and dunning letter text. (RMC-07)

• Provide information on the age of receivables to allow for management and prioritization
of collection activities. This is to include aging information on individual receivables and

Core Financial System Requirements 51

Receivable Management Function

on a summary basis, such as by customer, type of customer, fund, and general ledger
account. (RMC-08)

• Identify and report receivables that meet predetermined criteria for write-off, or referral
and generate the appropriate entries. (RMC-09)

• Automatically calculate (as a percentage of gross receivables or related revenues) and

record the allowance for loss on accounts receivable. (RMC-10)

• Provide information to allow for the automated reporting of delinquent accounts to

commercial credit bureaus. (RMC-11)

• Automatically create files of delinquent accounts for electronic submission to collection

agencies and appropriate governmental organizations. (RMC-12)

• Maintain data for receivables referred to other Federal agencies and outside
organizations for collections. (RMC-13)

• Record the waiver and write-off of receivables, including interest, penalties, and
administrative charges. Maintain data to monitor closed accounts. (RMC-14)

• Track and report on the date and nature of a change in the status of an accounts
receivable, including the following:

o In Forbearance or in Formal Appeals Process,

o In Foreclosure,
o In Wage Garnishment,
o Rescheduled,
o Waived/unwaived,
o Eligible for Referral to Treasury for Offset,
o Referred to Treasury for Offset,
o Eligible for Internal Offset,
o Eligible for Referral to Treasury or a Designated Debt Collection Center for Cross-
servicing,
o Referred to Treasury for cross-servicing,
o Referred to private collection agency,
o Referred to Department of Justice,
o Offset,
o Suspended,
o Compromised,
o Written-off,
o Closed Out. (RMC-15)

• Perform on-line queries of account activity (billing, collection, and adjustment) by

customer and receivable. (RMC-16)

• Perform on-line queries of miscellaneous cash receipts (applied to any Treasury fund
symbol) by customer, when identified, and by accounting period. (RMC-17)

• Uniquely record, classify, and report on reimbursable funds including: billing limit,
amount obligated, amount expended, amount billed, advanced amount (unearned
revenue), and earnings and collections received, based on customer and customer

52 Core Financial System Requirements

 Receivable Management Function

agreement number. Support the ability to query and report on these items by any of the
accounting classification elements (e.g., fund or object class). (RMC-18)

• Automatically produce IRS-1099-C’s in the amounts of debts forgiven which meet or

exceed a user-defined dollar threshold (e.g., $600 or more). (RMC-19)

Value-added Requirements

There are no value-added requirements for this process.

Collection Process
The Collections process supports activities to record the receipt of funds either by currency
(e.g., cash, EFT) or check, and the deposit of such funds in 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.

Mandatory Requirements

To support the Collections process, the Core financial system must provide the capability to:

• Automatically record the application of complete and partial payments made by the
debtor on a delinquent debt to administrative fees, penalties, interest, and then to
principal, unless otherwise stated in program statute. (RMD-01)

• Record revenues, expenditure reductions, or other appropriate offsets associated with

collections for which no receivable was previously established. (RMD-02)

• Apply collections back to the specific contract or purchase order award to reduce
cumulative payments and expenditures (e.g., upon the refund of erroneous payments.)
(RMD-03)

• Record the receipt of an advance repayment and an advance from others with a
reference to the related reimbursable agreement (RA) obligation, whether or not an
account receivable was previously established. (RMD-04)

• Process cash or credit card collections. Match collections to the appropriate receivables
and update related bills and customer accounts. (RMD-05)

• Record information associated with a collection at the time funds are applied to an open
receivable document , including the deposit ticket number and date, and ALC code.
(RMD-06)

• Support the receipt of collection files from banks for application to open receivables.
(RMD-07)

• Record collections received against advance payments made. (RMD-08)

• Apply collections to more than one receivable. (RMD-09)

• Re-open closed accounts to record collections after a waiver or write-off of a receivable

has been recorded. (RMD-10)

Core Financial System Requirements 53

Receivable Management Function

• Electronically download monthly deposit and debit voucher confirmation information from
Treasury and the banking system for comparison to activity in the agency’s general
ledger. Produce a report of differences. (RMD-11)

• Support the receipt of payment offset information from Treasury. Apply offset collections
to open receivables and generate the appropriate accounting entries to record the
collections. (RMD-12)

• Automatically offset payments to vendors for amounts due to the agency (e.g.,
outstanding accounts receivable, credit memo, and open advances.) When an entire
payment is offset, create the appropriate notice to the vendor that the offset has been
made. (RMD-13)

Value-added Requirements

To support the Collections process, the Core financial system should provide the capability to:

• Record TAS/TAFS(s) associated with collections received on deposit tickets and debit
vouchers. (RMD-14)

• When downloading monthly deposit and debit voucher confirmation information from the
Treasury and the banking system for comparison to the agency general ledger, include
both the TAS/TAFS(s) and the associated amount(s). (RMD-15)

• Interface with CA$HLINK, in order to reconcile Treasury recorded collections to the

collections recorded in the Core financial system and generate exception reports.
(RMD-16)

54 Core Financial System Requirements

Cost Management Function

SFFAS No. 4, Managerial Cost Accounting Concepts and Standards for the Federal
Government, promulgated by FASAB, prescribes the managerial cost accounting concepts and
standards for the Federal Government. The managers and executives who have the need for
cost information should drive Cost Management in agencies. SFFAS No. 4 states:

“… based on sound cost accounting concepts and are broad enough to allow maximum
flexibility for agency managers to develop costing methods that are best suited to their
operational environments.”

The term “cost” refers to monetary value 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.

The level of sophistication of the Cost Management function needed by an agency is dependent
on the requirements of the agency, and the operational nature of the programs involved. For
example, if an agency’s primary mission is to produce a product or service for sale, the costing
function typically will be accomplished in the Managerial Cost Accounting System that is
integrated with the Core Financial System. Programs with less crucial cost information needs
might perform cost management functions by analytical or sampling methods. However, in any
Core system, certain basic functions must be present. For example, SFFAS 4 requires that cost
information developed for different purposes should be drawn from common data sources, and
that cost reports should be reconcilable to each other.

The Cost Management function consists of the following processes.

• Cost Setup and Accumulation (CMA)

• Cost Recognition (CMB)

• Cost Distribution (CMC)

• Working Capital and Revolving Fund (CMD)

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 accordingly. Finally,
cost information is prepared and distributed to managers. A “cost object” is any activity, output,
outcome, or item whose cost and revenue are to be measured, such as, organizational units,
programs, projects, targeted outputs, specific contracts, specific customers, work orders, and
GPRA program/activities, etc.

Cost Setup and Accumulation Process

The Cost Setup and Accumulation process identifies and tracks cost data associated with the
specific cost objects required by management. This process provides for the establishment of
identifiers for the desired cost objects in the processes, systems and applications that make up
the accounting system, and for the subsequent collection of cost data. An agency’s financial
management system must allow the establishment of cost object identifiers consistent with the
stated needs of its financial and operational managers. Ideally, the financial system will allow
this to be done in a straightforward manner, without undue complexity. The Cost Setup and
Accumulation process provides the data needed for accountability over the financial execution

Core Financial System Requirements 55

Cost Management Function

of public programs, meaningful comparisons to measure compliance with management policies,

evaluation of the efficiency and economy of resources used in the various activities, and support
for fees, services, or products. It also provides a basis for linking operational results to the
budget and performance measures.

Mandatory Requirements

To support the Cost Setup and Accumulation process, the Core financial system must provide
the capability to:

• Use the agency’s accounting classification elements to identify and establish unique cost
objects (for the purpose of cost and revenue capture, accumulation and reporting). Cost
objects might include: organizational units, programs, projects, activities, targeted
outputs, specific contracts, specific customers, work orders, etc. (CMA-01)

• Allocate and distribute the full cost and revenue of cost objects as defined in SFFAS
No. 4. Full cost includes: support costs provided by other responsibility segments, both
internal and external; identifiable support costs provided by other Government agencies
such as pension and other retirement benefits; unfunded costs such as accrued annual
leave that accrue in the current reporting period; depreciation expense; and,
amortization costs. (CMA-02)

• Allocate and distribute the full cost of goods and services provided by one Federal entity
to another. (CMA-03)

• Track current cost information against prior month and prior-year-to date cost data for
selected cost objects, and track progress against pre-determined plans. (CMA-04)

• Identify all costs incurred by the agency in support of activities of revolving funds, trust
funds, or commercial functions, including the applicable portions of any related salaries
and expense accounts identified with those activities. (CMA-05)

• Accumulate non-financial data relating to cost objects such as output units to allow the
calculation of both total and unit costs. (CMA-06)

• Transfer (and trace) cost data directly to and from other cost systems/applications that
produce or allocate cost information. (CMA-07)

• Calculate prices, fees, and user charges for reimbursable agreements and other
purposes using full cost, consistent with the guidance of OMB Circular No. A-25 User
Charges. (CMA-08)

Value-added Requirements

There are no value-added requirements for this process.

56 Core Financial System Requirements

 Cost Management Function

Cost Recognition Process

Recognition of the effects of transactions in financial systems is fundamental to the accounting
process. The recognition process determines when the results of an event are to be included in
financial statements and ensures that the effects of similar events and transactions are
accounted for consistently within the Federal Government.

Mandatory Requirements

To support the Cost Recognition process, the Core financial system must provide the capability
to:

• Use the accrual basis of accounting when recognizing costs and revenue. Recognize
costs in the period of time when the events occurred regardless of when ordered,
received or paid for. Recognize revenue when earned. (CMB-01)

• Associate with the appropriate cost objects, the reductions of balances such as
inventories, prepaid expenses and advance payments as the balances are used or
liquidated. (CMB-02)

• Identify and record costs incurred by each cost object, including input of costs from
feeder systems, such as inventory, travel, property management (depreciation), or
payroll. (CMB-03)

• Assign indirect costs on a cause-and-effect basis, or allocate costs through any

reasonable and consistent basis such as a percentage of total cost incurred, direct labor
hours used, square footage, or metered usage. (CMB-04)

• Perform multi-layer overhead distributions that are user-defined (at least three levels of
distribution) using multiple rates, fixed amount and other appropriate allocation methods.
(CMB-05)

Value-added Requirements

There are no value-added requirements for this process.

Cost Distribution Process

The managerial cost accounting concepts and standards contained in SFFAS 4 are aimed at
providing reliable and timely information on the full cost of programs, their activities and outputs.
The information is to be used by stakeholders, executives and managers in making decisions
about allocating resources, authorizing and modifying programs, and evaluating program
performance. Program managers can also use the cost information for making managerial
decisions to improve operating efficiency. Ultimately, the effectiveness of a cost management
program lies in the way managers use the cost information asked for and reported to them.

Core Financial System Requirements 57

Cost Management Function

Mandatory Requirements

To support the Cost Distribution process, the Core financial system must provide the capability
to:

• Distribute information (such as income statements and status of funds reports) on costs
and revenue associated with cost objects. (CMC-01)

• Provide consistent information on financial, budget, and program matters in different

reports. For example, bills generated for customers in the receivables system should
match customer status reports generated by the cost management system for the same
periods. (CMC-02)

• Use historical information to conduct variance and time-series analyses, and to

demonstrate the fairness and appropriateness of rates and charges that are based on
actual historical costs. (CMC-03)

• Distribute costs to other cost objects regardless of how they were originally assigned.
(CMC-04)

• Provide an audit trail that traces a transaction from its origin to the final cost object(s).
(CMC-05)

Value-added Requirements

There are no value-added requirements for this process.

Working Capital and Revolving Fund Process

Agencies may elect to use revolving funds, which include working capital funds and franchise
funds, for their organizations. These funds require separate legislation and have charters that
focus on specific purposes. Such charters have the potential to make program management
much more flexible by lifting apportionment controls while adding operational safeguards. If an
agency uses revolving funds, the Core system must be able to track service level agreements,
verify funds availability, bill customers, and measure costs.

Mandatory Requirements

To support the revolving fund function, the Core financial system must provide the capability to:

• Use cost management in revolving funds, including working capital programs. (CMD-01)

• Allocate working capital and revolving fund costs across organization and program lines
and generate appropriate journal entries. (CMD-02)

• Create and track the funding associated with cost objects (e.g., contracts, work-orders,
projects, reimbursable agreements) and provide funding status on fiscal year-to-date
and project inception-to-date bases. (CMD-03)

• Support the aggregation of project cost and funding information to a higher level, for
example linking the costs of a set of related projects for a particular customer on one
report. (CMD-04)

58 Core Financial System Requirements

 Cost Management Function

• Verify funds availability for orders placed against a specific contract, work-order or
agreement for a particular customer of the revolving fund operation. (CMD-05)

• Support funding of revolving fund contracts, work-orders, and projects through the use of
advances, prepayments or reimbursements. (CMD-06)

Value-added Requirements

There are no value-added requirements for this process.

Core Financial System Requirements 59

Reporting Function

Information maintained by the Core financial system must be provided in a variety of formats to
users according to their needs. Methods of providing information include on-line inquiries,
extractable data files, and hard-copy reports. These requirements could be satisfied by either;
application software that is part of the Core financial system, generalized reporting/inquiry
software that works with a variety of applications, or a combination of both.

For financial information to be timely and useful, the Core financial system must provide for
ready access to the information it contains. Information must be accessible to personnel with
varying levels of technical knowledge of systems. Personnel with relatively limited knowledge of
the system or of financial accounting concepts and principles must be able to access and
retrieve data with minimal training on the system. The system should be capable of storing
recurring data search requirements for future use.

The reporting function consists of the following processes.

• General Reporting (RA)

• External Reporting (RB)

• Internal Reporting (RC)

• Ad hoc Query (RD)

General Reporting Process

The Core financial system must provide complete, reliable, consistent, timely and useful
financial management information on operations. Such information enables central
management agencies, individual operating agencies, divisions, bureaus and other subunits to:
carry out their fiduciary responsibilities; deter fraud, waste, and abuse of resources; and
facilitate efficient and effective delivery of programs by relating financial consequences to
program performance.

Where reference to a “report” is made within a functional requirement, the application must be
capable of generating a formatted, printable report file containing the specified information.
Prescribed report formats must be followed where stated.

Mandatory Requirements

To support the Financial Reporting process, the Core financial system must provide the
capability to:

• Produce reports and transmittable files using data maintained by the Core financial
management system. (RA-01)

• Report on financial activity by any element of accounting classification (e.g., individual or

hierarchical organization code, project code). (RA-02)

60 Core Financial System Requirements

 Reporting Function

Value-added Requirements

To support the Financial Reporting process, the Core financial system should provide the
capability to:

• Report the financial information required for program management performance

reporting. (RA-03)

External Reporting
The Core financial system must provide complete, reliable, consistent, timely and useful
financial management information on operations to enable central management agencies to
fulfill their responsibility of being accountable to the public.

Mandatory Requirements

To support the External Reporting process, the Core financial system must provide the
capability to:

• Provide data in hard copy and electronic formats required by the Department of the
Treasury for the following reports:

o FMS Form 224, Statement of Cash Transactions,

o FMS Form 1219, Statement of Accountability, and
o FMS Form 1220, Statement of Transactions According to Appropriations, Funds, and
Receipt Accounts. (RB-01)

• Provide data in the electronic formats required by the Department of the Treasury for
FACTS I and FACTS II reporting. (RB-02)

• Produce a monthly SF-133, Report on Budget Execution and Budgetary Resources, in

the hard copy and electronic formats required by OMB. (RB-03)

• Perform the validation edits specified by Treasury to ensure the accuracy of data
transmitted for FACTS I and FACTS II reporting (at least) on a monthly basis. See the
FACTS II Client Bulk Users Guide for examples. (RB-04)

• Automate the preparation of consolidated financial statements as required by the current

OMB Bulletin on Form and Content of Agency Financial Statements. (RB-05)

Value-added Requirements

There are no value-added requirements for this process.

Internal Reporting
The Core financial system must provide complete, reliable, consistent, timely and useful
financial management information on operations to enable individual operating components,
divisions, bureaus and other sub units to carry out their fiduciary responsibilities; deter fraud,
waste, and abuse of resources; and facilitate efficient and effective delivery of programs by
relating financial consequences to program performance. The Core financial system must be

Core Financial System Requirements 61

Reporting Function

designed to support agency budget, accounting, and financial management reporting

processes.

Mandatory Requirements

To support the Internal Reporting process, the Core financial system must provide the
capability to:

• Produce a report of transaction level details for the TAS/TAFS totals reported on the
FMS Form 224, Statement of Cash Transactions. (RC-01)

• For each TAS/TAFS that is subject to FACTS II reporting requirements, produce a daily
on-line Available Funds report(s). The report(s) must accommodate the following
parameters: “internal fund”, budget object class, organization, program, project, and
activity and contain the following data elements as described below.

At the internal fund level, report data on budget execution as follows:

Total resources (by budget fiscal year and by authority type including warrant
information) as follows:
• Total authority brought forward,
• Total appropriated for the budget fiscal year,
• Total contract authority,
• Total borrowing authority (realized and unrealized), and
• Total estimated and total actual spending authority from offsetting collections.

Funding distribution, including:

• Total not yet apportioned,
• Total apportioned,
• Total allotted, and
• Total allowances.

Spending Activity, including:

• Total amount of commitments,
• Total obligations (including paid and unpaid), and
• Total expenditures (including paid and unpaid).

Balances available, such as:

• Balance of apportionments available for allotment,
• Balance of allowance available for commitment (uncommitted), and
• Balance of allowances available for obligation (unobligated).

When reporting on funds availability by the remaining parameters (i.e., at the

organization, budget object class, program, project and activity level), provide the same
data noted above except “total resources” data are not required (all elements for funding
distribution, spending and balances available are required). In addition, a summary
inclusive of all of the parameters must be provided at the TAS/TAFS level with total
amounts for each data element listed above. (RC-02)

62 Core Financial System Requirements

 Reporting Function

• Provide on-line summary trial balances at the internal fund, organization, and TAS/TAFS
levels. The trial balances must provide the following minimum data elements for each
general ledger account:

o The balance at the beginning of the accounting period,

o The total amount of debits for the accounting period,
o The total amount of credits for the accounting period, and
o The cumulative ending balance for the accounting period.

Grand totals for TAS/TAFS must be provided for beginning balance, current period
activity and ending balance columns. The system must produce both pre-closing and
post-closing trial balances at yearend. (RC-03)

• Support FACTS I and FACTS II reporting and analysis by producing on-line trial
balances at the internal fund, organization, and TAS/TAFS levels. The trial balances
must provide the data elements listed below for each general ledger account.

o The related official U.S. SGL account number,

o The following items at the U.S. SGL attribute level (i.e., separate amounts whenever
there is more than one attribute domain value within an U.S. SGL account):
- The balance at the beginning of the accounting period,
- The total amount of debits for the current accounting period,
- The total amount of credits for the accounting period, and
- The cumulative ending balance for the accounting period.

Grand totals for each TAS/TAFS must be provided for beginning balance, current period
activity, and ending balance columns. The system must produce both pre-closing and
post-closing trial balances at yearend. (RC-04)

• Provide an on-line transaction register at the internal fund, organization, and TAS/TAFS
level, for each accounting period, that provides the following data elements:

o Fiscal year,
o TAS/TAFS,
o Internal fund,
o Document number;
o Document entry date,
o Document entry time,
o Document entry User ID,
o Document transaction date,
o Debit account number;
o Debit account object class,
o Debit amount,
o Credit account number,
o Credit account,
o Object class,
o U.S. SGL attribute domain headings, and
o U.S. SGL attribute values associated with the transaction.

The report must include all transactions that occurred within the accounting period
specified. (RC-05)

Core Financial System Requirements 63

Reporting Function

Value-added Requirements

There are no value-added requirements for this process.

Ad Hoc Query
Over time, demands for specific financial data are expected to change considerably based on
new administrations, program missions, budget priorities, or oversight. This section addresses
data and access capabilities expected as part of the of an ad hoc query function. The
requirements address issues such as:

• The universe of FMS data that must be accessible,

• Core data access methods,

• Applied access security, and

• Needed output formatting tools.

While requirements associated with standard internal and external reporting are based on
clearly defined financial management information needs, ad hoc query requirements are general
in nature. The ability of an FMS package to provide for flexible data access is critical to
enabling effective agency, program and financial management in the face of change.

Mandatory Requirements

To effectively support ad hoc data access, the Core financial system must:

• Provide an integrated data query facility that supports ad hoc query access to agency
financial data sources and provides data analysis reporting tools. (RD-01)

• Allow users to create and submit parameter-based query scripts or to store them in a
common library for future use. (RD-02)

• Allow users to run queries on-line or in batch mode and to stage output for later access
by authorized users. (RD-03)

• Allow users to automatically distribute copies of report/query results via e-mail to multiple
pre-identified individuals or groups. (RD-04)

• Provide run-time controls to limit "run-away" queries and large data download requests.
(RD-05)

• Support graphical output display on the desktop. Output display should also support
dynamic report reformatting, regrouping and drill-down to detail records from summary
report lines. (RD-06)

• Allow authorized users to download selected financial data. This download capability
must be able to automatically reformat downloaded information for direct access by
common desktop applications (e.g., ASCII formatted). (RD-07)

64 Core Financial System Requirements

 Reporting Function

• Provide the ability to preview a report, form, or other query result before printing.
(RD-08)

• Support access to current year and historical financial data. (RD-09)

Value-added Requirements

To provide additional ad hoc data access functionality, the Core financial system should:

• Provide the following ad hoc query interface features:

o Graphical display of data sources,

o The ability to “point and click” on selectable table, data, and link objects for inclusion
in a custom query,
o An active data dictionary to provide users with object definitions,
o The ability to share user developed query scripts with other authorized agency users,
query optimization, and
o On-line help. (RD-10).

Core Financial System Requirements 65

Technical Requirements

Technical requirements have been established to help assure that a Core financial system is:
capable of meeting a wide variety of workload processing demands; provides transaction
processing integrity and general operating reliability; uses standard procedures for installation,
configuration and operations; and does not conflict with other administrative or program systems
or other agency established IT standards.

Core financial systems subject to JFMIP qualification must meet the mandatory technical
requirements specified in this section. Additionally, they should strive to include the functionality
listed as value-added requirements. The technical requirements are categorized below.

• General Design/Architecture (TA)

• Infrastructure (TB)

• User Interfaces (TC)

• Interoperability (TD)

• Workflow/Messaging (TE)

• Document Management (TF)

• Internet Access (TG)

• Security (TH)

• Operations and Computing Performance (TI)

Most technical requirements are stated in general terms to allow vendors maximum flexibility in
designing compliant financial systems. Individual agencies are encouraged to add specific
workload and interoperability requirements considered unique to their respective IT
environments when evaluating packages for acquisition.

General Design/Architecture
This category includes technical requirements relating to an application’s design, internal data
management, and general ease of use.

Mandatory Requirements

To meet JFMIP application architectural requirements, the Core system must:

• Be modular in design, utilize open-systems architecture, and be upgradeable by Core

system module to accommodate changes in laws, regulations, best practices and new
technology. (TA-01)

• Be a commercially available product, subject to regular maintenance based on vendor

developed and scheduled software releases. (TA-02)

66 Core Financial System Requirements

 Technical Requirements

• Include internal transaction processing controls, including the capability in the event of a
system failure to automatically:

o Back out incompletely processed transactions,

o Restore the system to its last consistent state before the failure occurred, and
o Re-apply all incomplete transactions previously submitted by the user. (TA-03)

• Enforce internal database consistency during all on-line and batch update operations,
including distributed databases, if applicable. (TA-04)

• Have fully documented restart capabilities for the application’s on-line and batch
processing components. Batch jobs must be segmented to facilitate their recovery in the
event of a system failure. (TA-05)

• Include complete installation, operating, and system maintenance documentation

covering:

o Product installation and configuration steps,

o Application access procedures,
o User screen layout and content,
o Transaction entry procedures,
o Batch job set-up, processing and recovery/re-start procedures,
o Error codes with full descriptions and recovery steps,
o Standard report layout and content,
o Internal processing controls,
o Application security,
o Operating specifications and system flowcharts,
o Database entity relationships, table formats and data element descriptions, and
o Program module descriptions. (TA-06)

• Include revised documentation concurrent with the distribution of new software releases.
(TA-07)

• Employ common error-handling routines across functional modules and present error
messages that allow the user or system operator to respond to reported problems.
(TA-08)

• Common error message text must be customizable by the agency. (TA-09)

• Generate output information to formats specified by functional requirements. In cases

where a functional requirement does not specify an output format, required information
must be viewable using the application’s on-line user interface by default. (TA-10)

• Be customizable to meet agency specific business/accounting needs using agency

supplied application configuration and operating parameters. (TA-11)

• Provide fault-free performance in the processing of date and date-related data

(including, calculating, comparing, and sequencing) by all hardware and software
products included as part of the application both individually and in combination (i.e.,
year 2000 compliance). (TA-12)

Core Financial System Requirements 67

Technical Requirements

Value-added Requirements

To meet JFMIP application architectural requirements, the Core financial system should:

• Include an integrated relational, Structured Query Language compliant database.

(TA-13)

• Simultaneously process on-line transactions and transactions submitted via system

interface. (TA-14)

Infrastructure
This requirement category identifies computing platforms and operating system environments
where a JFMIP qualified Core system could be installed by a Federal agency. Individual
packages do not need support every specified platform and operating environment.

Mandatory Requirements

To meet JFMIP infrastructure requirements, the Core system must:

• Identify all software and hardware products needed by an agency to install, operate,
access, and maintain the application. This requirement includes identification of distinct
products that are intended to be purchased or licensed as part of the product licensing
agreement. The vendor is also required to identify products needed to meet any
technical and functional requirement that must be acquired separately by the agency.
(TB-01)

• Utilize transaction Control Protocol/Internet Protocol communications protocol for

application, database, and workstation connectivity. (TB-02)

• At a minimum, support application client operation on a 32-bit, Microsoft Windows

compatible operating system. (TB-03)

Value-added Requirements

To meet JFMIP infrastructure requirements, the Core financial system should:

• Operate in a mainframe environment (e.g., Multiple Virtual System (MVS), Operating

System (OS/) 390). (TB-04)

• Operate in a server-computing environment running under UNIX or NT (e.g., Windows

Server 2000). (TB-05)

• Support application client operation on an Apple Macintosh Windows compatible

operating system. (TB-06)

• Support application client operation on a UNIX operating system. (TB-07)

• Support automated touch-tone telephone access for standardized, commonly requested,

inquiries (such as payment status). (TB-08)

68 Core Financial System Requirements

 Technical Requirements

• Support automated fax-back access for standardized, commonly requested, documents

(such as account statements). (TB-09)

• Provide the capability to accept bar-coded documents. (TB-10)

• Include a report spooling capability to enable on-line viewing, re-printing, and permanent
archiving of requested reports. (TB-11)

User Interfaces
Technical user interface requirements specify how agency users and operators interact with the
Core financial system. To enable users to effectively configure the package, enter transactions,
query processing results, or start/stop internal processes the system interfaces should meet the
following requirements.

Mandatory Requirements

There are no mandatory requirements in this category.

Value-added Requirements

To meet JFMIP user interface requirements, the Core financial system should:

• Provide a consistent, Windows-compatible, on-line user interface to all modules and

integrated subsystems. Interface consistency includes the use of common command
entry syntax, dialog window styles, data entry structures, and information presentation.
(TC-01)

• Incorporate common Graphical User Interface characteristics:

o Mouse activated icons,

o Buttons,
o Scroll bars,
o Drop-down lists,
o Check boxes,
o Menu bars,
o Text boxes,
o Tool tips,
o Resizable windows, and
o Cut, copy, and paste functions. (TC-02)

• Incorporate data entry features designed to reduce the amount of direct keying required
to initiate transaction processing. Desired efficiencies include the use of default values,
look-up tables, and automatic data recall. Other desirable features include:

o Single function windows (e.g., one input screen per transaction),

o The ability to pass common data from screen to screen,
o Highlighting of required fields,
o Auto tabs,
o Function keys (e.g., retrieve previous data, invoke help facility, suspend transaction,
clear screen, etc.),
o Disabling of non-supported function keys,

Core Financial System Requirements 69

Technical Requirements

o Menu mode and an expert mode of screen navigation,

o The ability to retrieve suspended transactions by user, document, vendor, etc.,
o Transaction entry undo/redo,
o Context-sensitive on-line help, and
o The ability to select records from a list by scrolling or by typing in only part of an
entry. (TC-03)

• Support desktop integration with other common workstation applications used for word
processing, spreadsheets, data management, and graphics. (TC-04)

• The application help facility should be customizable by the agency. (TC-05)

• Provide an application user interface that complies with the software application
standards required by Section 508 of the Rehabilitation Act, as detailed in 36 CFR 1194,
Subpart B. (TC-06)

Interoperability
Financial transactions can be originated using external, feeder applications. Typically, these
feeders are considered legacy systems and are based on older computing technologies.

Mandatory Requirements

To ensure that data can move effectively between the Core financial system and other financial
applications operated by the agency, the Core system must:

• Include an application program interface (API) to accept financial data generated by

external applications (e.g., the financial portion of mixed program systems, Electronic
Data Interchange (EDI) translators, and modules such as travel or payroll). This
interface must support the receipt of transactions for all Core accounting components, as
well as, vendor information updates. (TD-01)

• Process API submitted transactions using the same business rules, program logic, and
edit table entries as are used by the application in editing transactions submitted on-line
(e.g., via user interface). (TD-02)

• Hold API submitted transactions that do not pass required edits in suspense pending
appropriate corrective action by the user. Suspense processing must include the ability
to:

o View, update, or delete suspended transactions,

o Automatically re-process suspended transactions. (TD-03)

• Provide internal controls with the API (e.g., control totals, record counts) to ensure the
integrity of received and processed transactions. (TD-04)

• For the API, generate transaction editing error records in a standard format defined by
the vendor for return to the originating feeder application (i.e., provide two-way interface
support). (TD-05)

70 Core Financial System Requirements

 Technical Requirements

Value-added Requirements

To meet JFMIP interoperability requirements, the Core financial system should:

• Support direct EDI translation compliant with American National Standards Institute
(ANSI) X-12 standards to enable electronic data exchanges with designated trading
partners such as a bank credit card service provider, major supplier, or customer.
(TD-06)

• Interface with the agency electronic communications system to distribute application

generated documents and messages electronically to either intranet or Internet users.
(TD-07)

• Accept vendor invoices and other external originated transactions over the Internet (e.g.,
Extensible Markup Language (XML)). (TD-08)

• Support emerging XML-based specifications for the exchange of financial data such as
Extensible Business Reporting Language (XBRL). (TD-09)

Workflow/Messaging
Workflow/messaging includes technical requirements that collectively define how a Core
financial system automatically manages document processing and notifies agency staff of
pending work (e.g., review/approval of pending accounting documents).

Mandatory Requirements

To meet JFMIP workflow and messaging requirements, the Core financial system must:

• Provide an integrated workflow management capability, including generation and routing

of internal forms, reports, and other financial documents for on-line approval or
subsequent processing. (TE-01)

Value-added Requirements

To meet JFMIP workflow and messaging requirements, the Core financial system should:

• Enable authorized users to define workflow processes and business rules, including
approval levels, and to modify workflow (e.g., assigning a proxy approving authority).
(TE-02)

• Provide the capability to establish multiple levels of document approvals based on user-
defined criteria including dollar amounts, types of items purchased, and document types.
(TE-03)

• Provide an internal calendar or user-defined routing tables to generate rule-based or

exception reports to support the generation of work flow messages (i.e., notification of
Accounts Payable office for invoices warehoused over 30 days with no matching
receiving report). (TE-04)

• Provide the ability to track approval events on-line by transaction, including the time/date
and approving party. (TE-05)

Core Financial System Requirements 71

Technical Requirements

• Provide the capability to automatically generate electronic routing and status messages
to individuals or groups. (TE-06)

• Support Workflow Management Coalition (WFMC) standards. (TE-07)

• Support Messaging API-Workflow (MAPI-WF) standards. (TE-08)

• Support Vendor Independent Messaging (VIM) standards. (TE-09)

Document Management
Document management includes technical requirements that define how the Core system is to
store and retrieve electronically formatted documents.

Mandatory Requirements

There are no mandatory requirements in this category.

Value-added Requirements

To meet JFMIP document management requirements, the Core financial system should:

• Support Document Management Alliance (DMA) standards. (TF-01)

• Support Open Document Management Architecture (ODMA) standards. (TF-02)

• Support Open Document Architecture/Open Document Interface Format (ODA/ODIF)

standards. (TF-03)

• Support Portable Document Format standards. (TF-04)

• Support Standard Generalized Markup Language (SGML) standards. (TF-05)

• Provide the capability to electronically image, index, store, and retrieve document
reference material (e.g., signed contracts, purchase orders and vendor invoices).
(TF-06)

• Notify the user of the presence of associated document images and allow an on-screen
display of this material. (TF-07)

Internet Access
Technical requirements relating to Internet access represent a specialized infrastructure subset.
These requirements generally define user connectivity options.

Mandatory Requirements

There are no mandatory requirements in this category.

72 Core Financial System Requirements

 Technical Requirements

Value-added Requirements

To meet JFMIP Internet Access requirements, the Core financial system should:

• Support secure web browser access to all financial management system modules
including workflow related features for the purpose of entering new financial
documents/transactions and to review/approve their processing. (TG-01)

• Support secure Internet access to the integrated ad hoc data query facility. (TG-02)

• Provide the capability to receive public payment collections via the Internet (e.g., Web-
based collections via credit card). (TG-03)

• Support the use of standard Public Key Infrastructure technology to control access to
sensitive data over the Internet. (TG-04)

Security
This technical category defines internal and external access controls. A qualified Core financial
system must be designed to protect an agency’s financial data from unauthorized access or
alteration. Adequate data protection includes the following discrete requirements.

Mandatory Requirements

To meet JFMIP Security requirements, the Core system must:

• Have integrated security features that are configurable by the system administrator to
control access to the application, functional modules, transactions, and data. The
application’s integrated security features should be compliant with the National Institute
of Standards and Technology (NIST) Security Standards. (TH-01)

• Ensure that the agency’s access policies are consistently enforced against all attempts
made by users or other integrated system resources including software used to submit
ad-hoc data query requests or to generate standard reports. (TH-02)

• Require the use of unique user identifications and passwords for authentication
purposes. Passwords must be non-printing and non-displaying. The application must
allow the enforcement of password standards (e.g., minimum length and use of alpha,
numeric and special characters.) The application must also allow for the establishment
of a specified period for password expiration and accommodate prohibiting the user from
reusing recent passwords. (TH-03)

• Enable the system administrator to define functional access rights (e.g., to modules,
transactions, approval authorities) and data access rights (e.g., record create, read,
update and delete) by assigned user ID, functional role (e.g., payable technician) and
owner organization. (TH-04)

• Permit the system administrator to assign multiple levels of approval to a single user, but
prevent that user from applying more than one level of approval to a given document in
order to conform to the principle of separation of duties. (TH-05)

Core Financial System Requirements 73

Technical Requirements

• Allow the system administrator to restrict access to sensitive data elements such as
social security numbers and banking information by named user, groups of users, or
functional role. (TH-06)

• Maintain an audit logging capability to record access activity including:

o All log-in/log-out attempts by user and workstation,
o User submitted transactions,
o Initiated processes,
o System override events; and
o Direct additions, changes or deletions to application maintained data. (TH-07)

• Provide the ability to query the audit log by type of access, date and time stamp range,
user identification, or terminal ID. (TH-08)

Value-added Requirements

There are no value-added requirements for this process.

Operations and Computing Performance

This section covers two related areas - operating support functionality and computing
performance criteria. The operations related requirements are considered mandatory. Those
requirements that deal specifically with computing performance have been separately classified
as value-added.

JFMIP defines computing performance using general criteria rather than hard response time
standards or transaction processing capacity. We recognize that installed package
performance is dependent to a large part on the computing infrastructure and activity levels set
by the user agency. To use these requirements as part of an acquisition process, an agency
would need to add their own workload estimates (i.e., number concurrent of users, their
geographic distribution, number of transactions and processing timeframes as well as the
overall volume of agency information expected to be maintained on-line).

Mandatory Requirements

To meet all mandatory operations related requirements, the Core system must:

• Include a process scheduling capability that enables the operator to initiate, monitor, and
stop scheduled processes (e.g., on-line availability, batch jobs, and system
maintenance). (TI-01)

• Provide online status messages indicating job or transaction type and name, when
requested processing starts, completes, and system errors. (TI-02)

• Allow reports to be produced in the background while other system processing takes
place. (TI-03)

• Provide the system administrator the ability to control the archiving process. The system
must include the capability to establish and maintain user-defined archival criteria, such
as date, accounting period, closed items, and vendors inactive for a specific time period.
The system must allow selective action on those documents that meet the criteria.
(TI-04)

74 Core Financial System Requirements

 Technical Requirements

• Retain archived data and system records in accordance with Federal regulations
established by the National Archives and Records Administration, GAO, and the
National Institute of Standards and Technology (NIST). (TI-05)

• Provide the ability to selectively retrieve archived data based on user-defined criteria
such as date, accounting period, or vendor. (TI-06)

• Maintain and report on productivity statistics about application usage. (TI-07)

• Provide audit trails to identify changes made to system parameters and tables that would
affect the processing or reprocessing of any financial transactions. (TI-08)

Value-added Requirements

To meet value-added computing performance requirements, the Core financial system should:

• Provide computing performance metrics, for platforms and systems environments that
the application is certified to run on. Performance metrics provided by the vendor should
describe:

o Transaction processing throughput capacity,

o Expected workstation client response time by transaction type,
o Data storage capacity, and
o Limitations on concurrent user connectivity. (TI-09)

• Process an agency’s projected accounting activity without impacting projected on-line

response time. (TI-10)

• Complete routine batch processing (e.g., backups, nightly interface processing, Core GL
posting, table updates, standard reporting, and systems assurance) within an agency
defined batch-processing window. (TI-11)

• Maintain the agency’s current and historical financial data (e.g., general ledger records,
documents, transactions, lines, and vendor records) with no degradation to on-line or
batch processing performance. (TI-12)

• Support concurrent access to functional modules by the agency's defined user

community. (TI-13)

• Disclose processing jobs, steps, and dependencies that are required to operate the
system on a daily, weekly, monthly, quarterly, and annual basis. (TI-14)

• Provide the capability to process batched transactions during online hours and accept
online transactions from interfacing systems with no on-line performance degradation.
(TI-15)

Core Financial System Requirements 75

Appendix A: References

Introduction
The following list identifies many of the governmentwide accounting standards, laws,
regulations, and other mandates that pertain to Core financial system requirements. The list is
not all-inclusive and may not include citations supporting agency-specific or program specific
requirements. In addition, it is important to note that some of the governmentwide Core
financial system requirements are based on common need or usage, rather than regulations.

It is every agency’s responsibility to know the appropriate regulations and to comply with them.
It is the responsibility of agencies, system vendors and integrators to ensure system compliance
with the most current versions of laws, regulations, and other appropriate guidance.

The importance of financial management and control for Federal agencies is firmly rooted in the
Constitution of the United States. Article I, Section 9, Clause 7 of the Constitution states:

“No money shall be drawn from the Treasury, but in consequence of Appropriation made
by Law; and a regular Statement and Account of the Receipts and Expenditures of all
public Money shall be published from time to time.”

Many of the laws and regulations governing the financial behavior of Federal agencies flow from
the Constitution.

Federal Legislation
Accounting Standardization Act of 1995
Budget Enforcement Act
Cash Management Improvement Act
Chief Financial Officers Act (CFO) Act of 1990 (Public Law 101-576)
Clinger/Cohen Act (Information Technology Management Reform Act) (Division E of Public Law
104-106)
Computer Security Act of 1987 (Public Law 100-235)
Debt Collection Improvement Act (DCIA) of 1996
Federal Financial Management Improvement Act (FFMIA) of 1996
Federal Managers’ Financial Integrity Act (FMFIA) of 1982
Federal Records Act of 1950, as amended (Records Management by Federal Agencies, 44
U.S.C § 3101 et. seq.)
Freedom of Information Act of 1982 (5 U.S.C § 552)
Government Management Reform Act (GMRA) of 1994
Government Performance and Results Act (GPRA) of 1993 (Public Law 103-62)
Government Paperwork Elimination Act

76 Core Financial System Requirements

 Appendix A: References

Omnibus Reconciliation Act of 1993 (Public Law 103-66)

Paperwork Reduction Reauthorization Act of 1986 (Public Law 104-13)
Prompt Payment Act of 1982 and Amendments of 1996
Rehabilitation Act Amendments of 1998 (Workforce Investment Act) (Public Law 106-246)

United States Codes and Regulations

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–51, 1511–19 (jointly referred to as the “Anti-deficiency Act”),
prohibits 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. § 3302 (b) (the “Miscellaneous Receipts (Deposit) Statute”), requires that, except for
trust funds and revolving funds, collected monies from any source must 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.
44 U.S.C. § 3101 addresses records management within Federal agencies.
5 C.F.R. § 1315 is the codification of former OMB Circular No. A-125, “Prompt Payment.”
Public Law 101-510 is the M-year legislation.

Office of Management and Budget Guidance

OMB Bulletin 01-09, Form and Content of Agency Financial Statements
OMB Circular No. A-11, Preparation and Submission of Budget Estimates
OMB Circular No. A-11, Planning, Budgeting, and Acquisition of Capital Assets (Part 3)
Supplement to Part 3, Capital Programming Guide
OMB Circular No. A-25, User Charges
OMB Circular No. A-34, Instructions on Budget Execution
OMB Circular No. A-109, Policies for Acquiring Major Systems
OMB Circular No. A-123, Management Accountability and Control, 6/95

Core Financial System Requirements 77

Appendix A: References

OMB Circular No. A-127, Financial Management Systems, 7/93

OMB Circular No. A-130, Management of Federal Information Resources, 12/00
OMB Circular No. A-134, Financial Accounting Principles and Standards

Federal Accounting Standards

Statements of Federal Financial Accounting Standards (SFFAS), specifically:
SSFAS 1, Statement of Federal Financial Accounting Concepts
SFFAS 3, Accounting for Inventory and Related Property
SSFAS 4, Managerial Cost Accounting Concepts and Standards
SSFAS 5, Accounting for Liabilities of the Federal Government
SFFAS 7, Accounting for Revenue and Other Financing Sources
SSFAS 10, Accounting for Internal Use Software

JFMIP System Requirements

Framework for Federal Financial Management Systems (FFMSR-0), 1/95

Other Applicable Standards, Guidelines, and Regulations

Electronic and Information Technology Accessibility Standards (issued by the Architectural and
Transportation Barriers Compliance Board)
Federal regulations established by the National Archives and Records Administration
Federal regulations issued by the National Institute of Standards and Technology (NIST)
Rules related to payment formats issued by The Electronic Payments Association (also called
NACHA)
The Treasury Financial Manual (TFM), specifically including:
I TFM-2-3100 Instructions for Disbursing Officers' Reports
I TFM-2-3300 Reports of Agencies for which the Treasury Disburses
I TFM-2-4000 Federal Agencies' Centralized Trial-Balance System
I TFM-2-4100 Debt Management Reports
I TFM-6-5000 Administrative Accounting Systems Requirements
I TFM-6-8040 Disbursements
I TFM-6-8500 Cash Forecasting Requirements.

78 Core Financial System Requirements

Appendix B: Glossary

Accomplished payments
A term used by Treasury and agency personnel to refer to payments requested by an entity and
made by Treasury or a non-Treasury disbursing office on the behalf of that entity.

Activity
A financial summary accumulator defined by an agency.

Adjusted Trial Balance (ATB)

A list of general ledger accounts and the corresponding balances (including adjustments) as of
a specific date. The total debit balances must equal the total credit balances. In reference to
FACTS (I and II) reporting, the adjusted trial balance includes U.S. SGL attributes and the U.S.
SGL account balances should reflect pre-closing adjusting entries.

Agency
Any department, agency, commission, authority, administration, board, or other independent
establishment in the executive branch of the Government, including any corporation wholly or
partly owned by the United States that is an independent instrumentality of the United States,
not including the municipal government of the District of Columbia.

Agency Location Code (ALC)

Code assigned by Treasury to each reporting unit requiring the preparation of an FMS-224,
Statement of Transactions. The ALC must be shown on all correspondence, forms, and other
documentation forwarded to financial institutions, The Department of Treasury FMS, other
Federal agencies, and to Treasury Regional Financial Centers, and particularly on all SF-215s:
Deposit Tickets, and SF-5515s: Debit Vouchers

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 others statutory authority making funds available for obligation.

Application (financial or mixed system)

A group of interrelated components of financial or mixed systems which supports one or more
functions and has the following characteristics: a common database, common data element
definitions, standardized processing for similar types of transactions, common version control
over software.

Application Program Interface (API)

A set of routines, protocols, and tools for building software applications.

Apportionment
A distribution made by OMB of amounts available for obligation in an appropriation or fund
account into amounts available for specified time periods, activities, projects, objects, or
combinations thereof. The amounts so apportioned limit the obligations that may be incurred.

Appropriation
A provision of law (not necessarily in an appropriations act) authorizing the expenditure of funds
for a given purpose. Usually, but not always, an appropriation provides budget authority.

Core Financial System Requirements 79

Appendix B: Glossary

ATB Code
Consists of a department, bureau and Treasury appropriation/fund group. This is a unique
identifier code for a record in the Master Appropriation File.

Attributes
To meet external reporting requirements, agencies need data at a level below the four-digit U.S.
SGL account. Agencies’ systems must capture this information at the transaction level by
recording transactions using U.S. SGL four-digit accounts plus attributes. Attributes are like
adjectives that further describe a U.S. SGL account in order to meet a specific reporting
requirement. Examples include: Apportionment Category, Authority Type, Availability Time,
Reimbursable Flag, etc.

Attribute Domains
Domain values are all of the possible valid choices within an attribute. For example, the valid
domains for the Reimbursable Flag attribute are D, for Direct, and R, for Reimbursable.

Authority to borrow
One of the basic forms of budget authority. Statutory authority that permits a Federal agency to
incur obligations and make payments for specified purposes out of borrowed monies.

Automatically
Refers to the system processing of transactions, table updates and other activity without manual
intervention or the entry of additional transactions (including journal vouchers and other
reclassifications) by the user. In these cases, the system takes action based on specified
conditions or relationships, for example it: brings forward previously entered data to subsequent
transactions in the spending chain, closes open obligations when final payments are made,
liquidates open commitments at fiscal yearend, generates reports based on specified
crosswalks, etc.

Budget authority (BA)

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.

CA$HLINK
A Treasury system used to manage and monitor the collection of Government revenues and
report the balances to Federal agencies.

Central Contractor Registration

The primary vendor database for the Department of Defense (DoD), NASA, and Department of
Transportation (DoT). The CCR collects, validates, stores and disseminates data in support of
agency missions.

Close Out (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.

Commitment
The amount of allotment or sub-allotment committed in anticipation of an obligation.

80 Core Financial System Requirements

 Appendix B: Glossary

Compromise (a debt)
Agree to settle a debt at a lower amount than initially claimed.

Continuing Resolutions (CRs)

Joint resolutions that provide continuing appropriations for a fiscal year. CRs are enacted when
Congress has not yet passed new appropriations bills and a program's appropriations are about
to or have expired, or when the President has vetoed congressionally passed appropriations
bills.

Contract authority
A type of budget authority that permits obligations to be incurred in advance of either an
appropriation of the cash to make outlays to liquidate the obligations or offsetting collections.

Cost
The cash value of the resources allocated to a particular program. When used in connection
with Federal credit programs, the term means the estimated long-term cost to the Government
of a direct loan or loan guarantee, calculated on a net present value basis, excluding
administrative costs and any incidental effects on governmental receipts or outlays.

Cost Center
A logical grouping of one or more related activities and/or organizational units into a common
pool for the purpose of identifying the cost incurred for performing all of those activities.

Cost Object
Any activity, output, or item whose cost and revenue are to be measured, such as
organizational units, programs, projects, targeted outputs, specific contracts, specific customers,
work orders, and GPRA program/activities, etc.

Disbursements
Payments made using cash, checks, or electronic transfers. Disbursements include advances
to others as well a payments for goods and services received and other types of payments
made.

Document
This refers to balances and descriptive data of individual documents, such as requisitions,
purchase orders, contracts, vouchers, billings, advances, and the like.

Document Management Alliance (DMA)

A standards body seeking to provide interoperability between document management systems
from different vendors. The DMA specification enables vendors to build document management
applications and systems that provide "reliable, security-controlled search and retrieval
capabilities to documents stored throughout the enterprise". In addition to document search
and retrieval, DMA-compliant products will provide a framework for other common document
management functions, such as document creation, editing, version control, check-in/check-out,
and security.

Expended authority
Paid and unpaid expenditures for (a) services performed by employees, contractors, vendors,
carriers, grantees, lessors, or other Government funds; (b) goods and tangible property
received; and (c) amounts becoming owed under programs for which no current service or
performance is required (i.e., annuities, insurance claims, other benefit payments).

Core Financial System Requirements 81

Appendix B: Glossary

Expense
The outflows of assets or incurrence of liabilities during a period resulting from rendering
services, delivering or producing goods, or carrying out other normal operating activities.

Federal Agencies Centralized Trial-Balance System (FACTS)

System used by agencies to electronically transmit a pre-closing adjusted trial balance(s) (ATB)
at the TAS/TAFS level (FACTS II) or fund group level (FACTS I) using U.S. Government
Standard General Ledger account and other specified elements. FACTS I supports
consolidated financial statement reporting. FACTS II supports centralized budget execution
reporting.

Financial event
Any occurrence 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; or
other reportable financial activities.

Financial management system

The financial systems and the financial portions of mixed systems necessary to support financial
management.

Financial system
An information system comprised of one or more applications used for collecting, processing,
maintaining, transmitting, and reporting data about financial events; supporting financial
planning or budgeting activities; accumulating and reporting cost information; or supporting
financial statement preparation.

Financing 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.

Full-time equivalent employment

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.

Future-dated transactions
Financial transactions that are input and warehoused in the current accounting period,
scheduled to be posted to a later accounting period.

GOALS
Government On-line Accounting Link System. An electronic network that ties agencies to
Treasury and each other for the exchange of information. Over the network, agencies can
transfer funds to each other and receive notification that Treasury has accomplished
disbursements. Also, agencies and Treasury can submit and receive reports once exchanged
in hard copy format by mail. The GOALS network can be used with a wide variety of terminals
and modems.

Graphical User Interface

A program interface that takes advantage of a computer's graphics capabilities to make the
program easier to use.

82 Core Financial System Requirements

 Appendix B: Glossary

Imprest fund
A fixed-cash or petty-cash fund in the form of currency, coin, or Government check, which has
been advanced as Funds Held Outside of Treasury and charged to a specific 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.

Information system
The organized collection, processing, transmission, and dissemination of information in
accordance with defined procedures, whether automated or manual. Information systems
include non-financial, financial and mixed systems.

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 and/or the dollar
amount to be collected. Debts in a formal forbearance program represent debts that are still in
negotiation.

In Foreclosure
A delinquent debt is in foreclosure when a notice of default has been filed.

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).

Integrated system
Related sub-systems that enable a user to have one view into the components or modules in
order to access information efficiently and effectively through electronic means.

IPAC
Intra-governmental Payment And Collection System. An Internet application for intra-
governmental payments. IPAC was developed by the Treasury Department to replace the On-
line Payment and Collection System (OPAC) through the migration of the GOALS OPAC
application from a contractor-operated platform to a Government owned and operated platform.

Limitation
A funding restriction, imposed by OMB, a department, or an agency, that places a ceiling for
obligation/spending authority. The limitation may exist at any level within a funding structure or
may be imposed using an independent structure.

Line Item
Unless otherwise stated, line item refers to a line of accounting information, (i.e., accounting
classification elements, on a document.)

Logging
Data used for audit trail purposes to record activity in the system other than financial
transactions, such as table changes.

MAX Budget System (MAX)

MAX is a computer system used to collect and process most of the information required for
preparing the budget. MAX consists of a series of schedules that are sets of data within the
MAX database.

Core Financial System Requirements 83

Appendix B: Glossary

Mixed system
Any information system that supports both the financial and non-financial functions of the
Federal Government or components thereof.

Messaging API-Workflow (MAPI-WF)

A Microsoft framework originally intended to provide a standardized way for any Messaging
Application Programming Interface (MAPI)-capable application to be workflow-enabled and to
support work item interchange between various workflow engines. It is now expected to be
merged with standards based on Multipurpose Internet Mail Extensions (MIME)-based
standards.

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.

Multiple Virtual Storage (MVS)

The operating system for older IBM mainframes. MVS was first introduced in 1974 and
continues to be used although it has been largely superceded by IBM's newer operating system
OS, OS/390.

Object classification
A method of classifying obligations and expenditures according to the nature of services or
articles procured (e.g., personal services, supplies and materials, and equipment). Obligations
are classified by the initial purpose for which they are incurred, rather than for the end product
or service provided.

Object classes
Categories in a classification system that presents obligations by the items or services
purchased by the Federal Government. The major object classes are: 10 - Personnel
compensation and benefits; 20 - Contractual services and supplies; 30 - Acquisition of assets;
40 - Grants and fixed charges; 90 - Other. Many agencies have defined lower levels of object
classes for internal use.

Obligated balance
The cumulative amount of budget authority that has been obligated but not yet outlayed, also
known as unpaid obligations (which is made up of accounts payable and undelivered orders)
net of accounts receivable and unfilled customers 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 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.

On-line
Accessible by any computer connected to a network (for example, an “on-line” database').

OPAC
On-line Payment and Collection System. A component of GOALS. OPAC is an automated
means by which billing information is transmitted between Federal Agencies through a

84 Core Financial System Requirements

 Appendix B: Glossary

commercial time-sharing service via a telecommunications network. Intragovernmental

payments are also made using OPAC.

Open Document Architecture/Open Document Interface Format (ODA/ODIF) - ODA

An international standard that enables users to exchange texts and graphics generated on
different types of office products. ODIF - Defines the Open Document Architecture (ODA)
format in terms of interchanged data elements.

Open Document Management Architecture (ODMA)

Provides standard interface between document management systems and end-user
applications. ODMA is becoming a desktop application integration de facto standard.

Operating/financial plan
A financial plan is a blueprint for using financial resources during any given fiscal period or
series of periods. There are many variations of these plans from agency to agency (level of
detail, reporting periods, etc.) Some agencies refer to financial plans as "operating plans".
Others differentiate between "operating" and "financial" plans based on different levels of detail,
different fiscal periods covered, or other variables. Since the functionality is the same, these
plans are all referred to as "operating/financial plans."

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 interest accrued on public issues of the public debt.

Posted Transaction
Data from financial transactions that have been processed, accepted and recorded in the
system.

Pro forma transactions

Predetermined standard set of general ledger account postings associated with an accounting
event.

Program
Generally defined as an organized set of activities directed toward a common purpose, or goal,
undertaken or proposed by an agency in order to carry out its responsibilities. In practice,
however, the term program has many uses and thus does not have well-defined, standard
meaning in the legislative process. Program is used to describe an agency’s mission,
programs, functions, activities, services, projects, and processes.

Program structure
The budget programs, activities, etc. on which budgetary decisions are made, whether legally
binding, as in appropriation limitations, or in the nature of policy guidance, as in Presidential
pass backs, Congressional markup tables, or internal agency decisions.

Project
A planned undertaking of something to be accomplished, produced, or having a finite beginning
and finite end. Examples are a construction project or a research and development project.

Core Financial System Requirements 85

Appendix B: Glossary

Reappropriation
An extension in law of the availability of unobligated balances of budget authority that have
expired or would otherwise expire. A reappropriation counts as budget authority in the year in
which the balance becomes newly available for obligation.

Reimbursable order
May also be known as Customer Orders. Orders for goods and services to be provided by the
agency to another entity in return for payment.

Reimbursable obligation
An obligation financed by offsetting collections credited to an expenditure account in payment
for goods and services provided by that account.

Rescheduled (debt)
Modified terms and conditions to facilitate repayment of a debt, which includes establishing new
terms as a result of changes in authorizing legislation.

Requirements
JFMIP systems requirements are either mandatory or value-added. The definitions of these two
categories are:
• Mandatory–Mandatory requirements describe what the system must do and consist of
the minimum functionality necessary to establish a system, or are based on Federal laws
and regulations. Mandatory requirements are those against which agency heads
evaluate their systems to determine substantial compliance with systems requirements
under the FFMIA. These requirements apply to existing systems in operation and new
systems planned or under development.
• Value-added–Value-added requirements describe features or characteristics and may
consist of any combination of the following: (1) using state of the art technology, (2)
employing the preferred or best business practices, or (3) meeting the special
management needs of an individual agency. Value-added, optional, and other similar
terminology may be used to describe this category of requirements. Agencies should
consider value-added features when judging systems options. The need for these
value-added features in agency systems is left to the discretion of each agency head.

Rescission
A legislative action that cancels new budget authority or the availability of unobligated balances
of budget authority prior to the time the authority would otherwise have expired.

Single, 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 together electronically in an efficient and effective manner to
provide agency-wide financial system support necessary to carry out the agency's mission and
support the agency's financial management needs.

Standard Generalized Markup Language (SGML)

An international standard of identifying the basic structural elements of a text document. SGML
addresses the structure of a document, not its format or presentation.

86 Core Financial System Requirements

 Appendix B: Glossary

Suspended (Debt)
Collection activity on a debt is temporarily stopped because: (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.

Suspended Transactions
Transactions that have not been completely processed and posted in the system.

System
Two or more individual items (equipment components) that are part of a self-contained group,
that are joined physically, electronically, or electromechanically, programmed or designed
specially to rely on each other, and cannot function independently if separated, and cannot be
easily disconnected and reconfigured to function with or within another unit or "system."

Tolerance levels
The percentage or dollar variance of related transaction amount that can exceed a control
amount, such as obligation to commitment; accrual to obligation; and obligation to payment.

Transfer
To move budgetary resources 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 non-expenditure transfer, which does not involve an outlay.

Treasury Appropriation Fund Symbol (TAFS)

A summary account established in the Treasury for each appropriation and fund showing
transactions to such accounts. Each such account provides the framework for establishing a
set of balanced accounts on the books of the agency concerned. As used in OMB Circular No.
A-34, this phrase refers to general fund expenditure accounts, special fund expenditure
accounts, public enterprise revolving funds, intragovernmental revolving funds, management
funds, trust fund expenditure accounts, and trust revolving fund accounts. Also known as
Treasury Appropriation Symbol (TAS).

Treasury Appropriation Symbol (TAS)

Synonymous with Treasury Appropriation Fund Symbol (TAFS).

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

Unified system
Systems that are planned and managed together, operated in an integrated fashion, and linked
together electronically in an efficient and effective manner to provide agency-wide financial
system support necessary to carry out the agency's mission and support the agency's financial
management needs.

UNIX
A popular multi-user, multi-tasking operating system developed at Bell labs in the early 1970s.

Unobligated balance
The cumulative amount of budget authority that is not obligated and that remains available for
obligation under law.

Core Financial System Requirements 87

Appendix B: Glossary

Vendor Independent Messaging (VIM)

An application-programming interface (API) that allows the exchange of electronic mail among
programs from different vendors. Members of the VIM Consortium are in the process of
internally standardizing on VIM across all their networking products as they roll out their new
product releases. VIM is designed to work across desktop platforms on Windows, Macintosh,
DOS and OS/2.

Waiver
A forgiveness of debt, the debtor is not held responsible and is not subject to collection efforts.

Warehoused Payment
A warehoused payment is a payment voucher that is stored on-line for disbursement at a future
date. Payment vouchers are invoices and recurring payments that are typically warehoused
when the receipt of goods or services is pending, approval is pending, or the payment due date
has not yet arrived

Write Off
To remove an uncollectible amount from an entity's receivables. Collection attempts can be
made after receivables are removed.

Warehoused payment
Is a payment voucher that is stored on-line for disbursement at a future date. Payment
vouchers are invoices and recurring payments that are typically warehoused when the receipt of
goods or services is pending, approval is pending, or the payment due date has not yet arrived.

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.

Workflow Management Coalition (WFMC)

The Workflow Management Coalition, founded in August 1993, is a non-profit, international
organization of workflow vendors, users, analysts and university/research groups.

88 Core Financial System Requirements

Appendix C: Summary of Standard External Reports
from Core Financial Systems

Title Form Purpose Level Basis Frequency Guidelines

Report on SF-133 Status of Appropriation/ Cash/Obligation Quarterly/ OMB Circular
Budget budgetary Fund Account Annually No. A-34
Execution resources
Federal Electronic Report data Appropriation/ Accrual Annually I TFM-2-4000
Agencies; Reporting for Fund Group
Centralized replacement consolidation
Trial Balance of from FACTS I
System SF-220 into the
(FACTS I) SF-220-1 Financial
SF-221 Report of the
SF-222 U.S.
and SF-223 Government
Federal Electronic Status of Accrual Quarterly/ Current TFM
Agencies; Reporting of budgetary Appropriation/ Annually U.S. SGL
Centralized SF-133, FMS- resources Fund Account Supplement
Trial- Balance 2108, and
System Program and FACTS II
(FACTS II) Financing Client Bulk
Schedule User’s Guide
(actual data
columns)
Report on SF-133 Allows Appropriation/ Accrual On-demand OMB Circular
Budget monitoring of Fund Group No. A-34
Execution and status of funds
Budgetary that were
Resources apportioned
on the SF-132
Report on Replaces SF- Provides Appropriation/ Accrual Quarterly/
Receivables 220-9 information on Fund Account Annually I TFM-2-4100
Due from the the status of but can vary
Public public
receivables
and
delinquencies
Statement of FMS-224 Reports Agency Cash Monthly I TFM-2-3300
Transactions disbursements location code
collections, by
and status of Appropriation/
collections Fund Account
Report of FMS-1219 Provides an Agency Cash Monthly I TFM-2-3100
Accountability analysis of location code
disbursing and
officers’ Disbursing
activities in Officer
agencies
which do not
do their own
disbursing
Statement of FMS-1220 Reports Agency Cash Monthly I TFM-2-3100
Transactions disbursements Location code

Core Financial System Requirements 89

Appendix C: Summary of Standard External Reports from Core Financial Systems

Title Form Purpose Level Basis Frequency Guidelines

and and
collections in Appropriation
agencies Fund Account
which do their
own
disbursing (the
counterpart to
FMS-224)
Information 1099-MISC, Provide Taxpayer Cash Annually IRS
Returns 1099-G, etc. information to Identification instructions
the Internal number for forms
Revenue 1099, 1098,
Service on 5498, and W-
payments 2G
made or debts
forgiven
Balance Sheet N/A Disclose Trust and Obligation/ Annually OMB’s
statement of revolving Accrual Bulletin on
assets, funds, Form and
liabilities, and accounts Content
net position substantially
commercial
Statement of N/A Reports gross Trust and Accrual Annually OMB’s
Net Cost costs less revolving Bulletin on
revenue funds, Form and
earned accounts Content
substantially
commercial
Statement of N/A Reports Trust and Accrual Annually OMB’s
Changes in financing revolving Bulletin on
Net Position sources, gains funds, Form and
and losses accounts Content
substantially
commercial
Statement of N/A Available Appropriation/ Obligation/ Annually OMB’s
Budgetary budgetary Fund Group Accrual Bulletin on
Resources resources and Form and
status Content
Statement of N/A Report on Trust and Accrual Annually OMB’s
Financing reconciliation revolving Bulletin on
between funds, Form and
proprietary accounts Content
and budgetary substantially
accounts commercial
Statement of N/A Report of non- Trust and Accrual Annually OMB’s
Custodial exchange revolving Bulletin on
Activity revenue funds, Form and
accounts Content
substantially
commercial

90 Core Financial System Requirements

Appendix D: Contributors

JFMIP Steering Committee

Jeffrey C. Steinhoff, Chair, U.S. GAO
Donald V. Hammond, U.S. Department of the Treasury
Karen Cleary Alderman, Executive Director, JFMIP
Joseph L. Kull, Office of Management and Budget
William B. Early, General Services Administration
Kathleen M. McGettigan, Office of Personnel Management

Joint Financial Management Improvement

Program
Karen Cleary Alderman
Stephen Balsam
Steven Fisher
Dennis Mitchell

Core Financial System Requirements Project Team

Corporation for National Service

Wynn Cooper

Department of Agriculture

Jane Bannon
Christine C. Burgess
Lucille Crouch
Richard Davis

Department of Commerce

Patricia Jackson
James L. Taylor

Department of Defense

Lois Douglas
Gerald Thomas
Mike Trout

Department of Education

Dan Harris

Core Financial System Requirements 91

Appendix D: Contributors

Department of Energy

James T. Campbell
Juanita Delair
Warren Huffer
Laura Kramer
Bill Maharay
Ike Smith

Department of Health and Human Services

Sandra Fry
Norbert Juelich
Sue Mundstuk
Teresa Wright
Margie Yanchuk

Department of Housing and Urban Development

Rhea Riso

Department of Interior

Don Haines
R. Schuyler Lesher
Clarence Smith
Monica Taylor

Department of Justice

Robert Karas
Charles R. L. Power

Department of Labor

Patricia Clark
John J. Getek
Gordon S. Heddell
Lee Jones
Brenda Kyle
Michael T. McFadden
Leroy Sandoval

Department of State

Tom Allwein
Alan K. Evans
Lauretta Pridgen

92 Core Financial System Requirements

 Appendix D: Contributors

Department of Transportation

Terry Letko
John L. Meche
Tom Park

Department of the Treasury

Richard Aaronson
Carolyn Dockett-Butler
Dan Devlin
David Epstein
Pamela J. Gardiner
Denise Goss
Betty Harvey-Tauber
David Hesch
Jeff Hogue
Wally Ingram
James Lingebach
Robert Reid
Ray Reinhart
Dale Walton
David Williams

Department of Veterans Affairs

Vidal Falcon
Jesse Symlar

Environmental Protection Agency

Sue Arnold
Ron Bachan
Bill Cooke
Debra Bennet
Mark Bolyard
Judi Brown
Valerie Chun
Joe Dillon
Kathy Edwards
Judy Lum
Lynn Mason
Juliette McNeil
Terry Ouverson
Martin Poch

Core Financial System Requirements 93

Appendix D: Contributors

Federal Deposit Insurance Corporation

Dottie Willey

Federal Emergency Management Agency

Theodore Alves
Cole Cox
Sue Schwendiman

Federal Energy Regulatory Commission

Herman Dalgetty
Janet Dubbert
Hilary Schubert

General Accounting Office

Chris Martin
Janett Smith
Sally Thompson

General Services Administration

Jerry Cochran
William Topolewski
Ellen Warren

National Aeronautics and Space Administration

Patrick Iler
Mela Jo Kubacki
Alan Lamoreaux
Stephen Varholy

National Science Foundation

Phil Ziegler

Nuclear Regulatory Committee

Barbara K. Gusack
Amanda Flo
Sylvia Washington

94 Core Financial System Requirements

 Appendix D: Contributors

Office of Management and Budget

Jean Holcombe
Neil Lobron
Jerry Williams

Office of Personnel Management

Maurice Duckett
Robert Loring

Railroad Retirement Board

Kenneth Boehne

Social Security Administration

Tom Bianco
Jim Fornataro
Steven L. Schaeffer
Dale Sopper
Peter Spencer
Tom Staples
Kitt Winter

U.S. Customs

Jim Mitch

CFO Fellows Participant

David Cauthon

Logistics Management Institute

James Atherton
Kathy Crampton
Frank Duesing
Steven Mead
Catherine Nelson
Loan Nguyen
Ronald Rhodes
Susan Smith
Duane Whitt
Kim Murray

Core Financial System Requirements 95