+----------------------------------------------------+-----------------+
| ![](media/image1.wmf)                              | > Federal       |
|                                                    | >               |
| > Core                                             | > Financial     |
| >                                                  | >               |
| > Financial                                        | > Management    |
| >                                                  | >               |
| > System                                           | > System        |
| >                                                  | >               |
| > Requirements                                     | > 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.

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.

![](media/image2.png){width="3.1131944444444444in"
height="0.7090277777777778in"}

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

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](#introduction)

[Federal Financial Management Framework
3](#federal-financial-management-framework)

[Integrated Financial Management Systems
6](#integrated-financial-management-systems)

[Agency Financial Management Systems Architecture
7](#agency-financial-management-systems-architecture)

[Core Financial System Overview 9](#core-financial-system-overview)

[Background 9](#background)

[General Information 9](#general-information)

[Policy 9](#policy)

[Management Controls 10](#management-controls)

[Summary of Functional Requirements
10](#summary-of-functional-requirements)

[Core Financial System Management 11](#core-financial-system-management)

[General Ledger Management 12](#general-ledger-management)

[Funds Management 12](#funds-management)

[Payment Management 13](#payment-management)

[Receivable Management 13](#receivable-management)

[Cost Management 13](#cost-management)

[Reporting 14](#reporting)

[Summary of Technical Requirements
15](#summary-of-technical-requirements)

[Functional Requirements 16](#functional-requirements)

[Core Financial System Management Function
17](#core-financial-system-management-function)

[Accounting Classification Management Process
17](#accounting-classification-management-process)

[Transaction Control Process 20](#transaction-control-process)

[General Ledger Management Function
24](#general-ledger-management-function)

[General Ledger Account Definition Process
24](#general-ledger-account-definition-process)

[Accruals, Closing and Consolidation Process
25](#accruals-closing-and-consolidation-process)

[General Ledger Analysis and Reconciliation Process
26](#general-ledger-analysis-and-reconciliation-process)

[Funds Management Function 28](#funds-management-function)

[Budget Preparation Process 28](#budget-preparation-process)

[Budget Formulation Process 29](#budget-formulation-process)

[Funds Allocation Process 30](#funds-allocation-process)

[Budget Execution Process 31](#budget-execution-process)

[Funds Control Process 32](#funds-control-process)

[Payment Management Function 38](#payment-management-function)

[Payee Information Maintenance Process
38](#payee-information-maintenance-process)

[Payment Warehousing Process 40](#payment-warehousing-process)

[Payment Execution Process 42](#payment-execution-process)

[Payment Confirmation and Follow-up Process
46](#payment-confirmation-and-follow-up-process)

[Receivable Management Function 48](#receivable-management-function)

[Customer Information Maintenance Process
48](#customer-information-maintenance-process)

[Receivable Establishment Process 50](#receivable-establishment-process)

[Debt Management Process 51](#debt-management-process)

[Collection Process 53](#collection-process)

[Cost Management Function 55](#cost-management-function)

[Cost Setup and Accumulation Process
55](#cost-setup-and-accumulation-process)

[Cost Recognition Process 57](#cost-recognition-process)

[Cost Distribution Process 57](#cost-distribution-process)

[Working Capital and Revolving Fund Process
58](#working-capital-and-revolving-fund-process)

[Reporting Function 60](#reporting-function)

[General Reporting Process 60](#general-reporting-process)

[External Reporting 61](#external-reporting)

[Internal Reporting 61](#internal-reporting)

[Ad Hoc Query 64](#ad-hoc-query)

[Technical Requirements 66](#technical-requirements)

[General Design/Architecture 66](#general-designarchitecture)

[Infrastructure 68](#infrastructure)

[User Interfaces 69](#user-interfaces)

[Interoperability 70](#interoperability)

[Workflow/Messaging 71](#workflowmessaging)

[Document Management 72](#document-management)

[Internet Access 72](#internet-access)

[Security 73](#security)

[Operations and Computing Performance
74](#operations-and-computing-performance)

[Appendix A: References 76](#appendix-a-references)

[Appendix B: Glossary 79](#appendix-b-glossary)

[Appendix C: Summary of Standard External Reports from Core Financial
Systems
89](#appendix-c-summary-of-standard-external-reports-from-core-financial-systems)

[Appendix D: Contributors 91](#appendix-d-contributors)

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

# 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

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

Financial System Improvement Projects

![](media/image3.wmf)

**Illustration 1**

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 systems[^1]
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.

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

![](media/image4.wmf){width="3.4916666666666667in"
height="2.6645833333333333in"}

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

![](media/image5.wmf)Agency Systems Architecture

**Illustration 3**

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

Core Financial System

![](media/image6.wmf)

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

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

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

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

# 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

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

#### Mandatory Requirements

To support the Accounting Classification Management process, the Core
financial system **[must]{.underline}** provide the capability to:

-   Classify accounting transactions by:

```{=html}
<!-- -->
```
-   Treasury Account Symbol/Treasury Account Fund Symbol (TAS/TAFS),

-   Internal fund code (see CFA-04 below),

-   Budget fiscal year,

-   Accounting quarter and month,

-   Program,

-   Organization,

-   Project,

-   Activity,

-   Cost center,

-   Object class,

-   Budget function (and sub function code), and

-   Remaining U.S. SGL attributes not specified above. (CFA‑01)

```{=html}
<!-- -->
```
-   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:

```{=html}
<!-- -->
```
-   Budget formulation classifications (budget function and sub function
    classification codes, per OMB Circular No. A-11)

-   Budget execution and accounting classifications (e.g., TAS/TAFS,
    internal fund, program, project, activity), and

-   The agency's organizational structure. (CFA‑03)

```{=html}
<!-- -->
```
-   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:

```{=html}
<!-- -->
```
-   Fund type (e.g., general fund, deposit fund, trust fund, special
    fund, revolving fund, receipt account);

-   Funding source (e.g., borrowing authority, contract authority,
    direct appropriation, spending authority from offsetting
    collections); and

-   Budget status (e.g., on budget, off budget, or financing account);
    and TAS/TAFS status (e.g., annual, multiyear, and no-year). (CFA‑05)

```{=html}
<!-- -->
```
-   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 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]{.underline}** 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)

### 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]{.underline}** 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)

-   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)

-   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]{.underline}** 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)

-   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]{.underline}** 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.

## 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 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]{.underline}** 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]{.underline}** provide the capability to:

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

-   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]{.underline}** 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)

#### Value-added Requirements

There are no value-added requirements for this process.

## 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]{.underline}** 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)

#### Value-added Requirements

To support the Budget Preparation process, the Core financial system
**[should]{.underline}** 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]{.underline}** 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)

-   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]{.underline}** 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)

-   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]{.underline}** 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]{.underline}** 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)

-   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]{.underline}** 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.

#### Mandatory Requirements

To support the Funds Availability Editing activity, the Core financial
system **[must]{.underline}** 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 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]{.underline}** 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]{.underline}** provide the capability to:

-   Maintain information related to each commitment document, including
    amendments. The Core financial system must capture:

```{=html}
<!-- -->
```
-   Requisition number,

-   Appropriate accounting classification values, and

-   Estimated amounts. (FME‑15)

```{=html}
<!-- -->
```
-   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.

**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]{.underline}** 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)

-   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]{.underline}** provide the capability to:

-   Maintain the following additional data fields for each obligating
    document

```{=html}
<!-- -->
```
-   Requester's name

-   Telephone number of requester

-   Contract number/GSA schedule number

-   Deliver to location (e.g., room number, division)

-   Comment field

-   Contact name

-   COTR name

-   COTR telephone number

-   Prompt Pay indicator

-   Approval date, and

-   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]{.underline}** 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)

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

## 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 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]{.underline}** provide the capability to:

-   Maintain payee (vendor) information to support obligation, accounts
    payable, and disbursement processes, including:

```{=html}
<!-- -->
```
-   Vendor name

-   Vendor ID number

-   Vendor type (e.g., Federal agency, state/local government,
    commercial entity, individual, employee)

-   TIN

-   Three or more payment addresses

-   Three or more separate instances of banking information (i.e.,
    account and routing numbers) for issuing payments

-   Bank account type (check or savings)

-   Three or more contact names

-   Three or more contact telephone numbers

-   Federal vs. Non-federal indicator

-   Six-digit Trading Partner codes

-   Entity type (e.g., small business, 8A, women owned business)

-   Multiple vendor payment methods (e.g., Electronic Funds Transfer
    (EFT), check)

-   Third-party information (e.g., payee TIN for notice of assignment)

-   Data Universal Numbering System (DUNS) number

-   ALC number (for Federal vendors)

-   Subject to Prompt Pay indicator

-   Internal Revenue Service (IRS) -1099 indicator

-   W-2 indicator

-   Comment field

-   Date of last update, and

-   User ID of last update. (PMA-01)

```{=html}
<!-- -->
```
-   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)

-   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]{.underline}** 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]{.underline}** 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)

-   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:

```{=html}
<!-- -->
```
-   Invoice number

-   Invoice date

-   Invoice receipt date

-   Invoice due date

-   Invoice amount

-   Unit price and quantity

-   Description

-   Discount terms, as applicable

-   Obligating document reference(s)

-   Vendor identification number and address code. (PMB-11)

```{=html}
<!-- -->
```
-   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)

-   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]{.underline}** 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. 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]{.underline}** 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)

-   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)

-   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]{.underline}** 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)

-   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]{.underline}** 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:

```{=html}
<!-- -->
```
-   Payment scheduled

-   Schedule sent to appropriate disbursing office

-   Payment issued by appropriate disbursing office. (PMD‑01)

```{=html}
<!-- -->
```
-   For each payment made by the Core financial system, maintain a
    history of the following information:

```{=html}
<!-- -->
```
-   Vendor Invoice number

-   Invoice amount

-   Vendor identification number

-   Vendor name

-   Payment address or banking information

-   Payment amount

-   Interest paid, when applicable

-   Discount taken, when applicable

-   Offset made, when applicable

-   Payment method (e.g., check, EFT)

-   Referenced obligation number, and

-   Appropriation charged. (PMD‑02)

```{=html}
<!-- -->
```
-   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)

-   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]{.underline}** 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)

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

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]{.underline}** provide the capability to:

-   Maintain customer information to support receivable management
    processes, including, at a minimum:

```{=html}
<!-- -->
```
-   Customer name

-   Customer ID number

-   Customer type (federal agency, state/local government, commercial
    entity, individual, employee)

-   Taxpayer Identification Number (TIN)

-   Customer address

-   Contact names

-   Contact telephone number

-   Federal vs. Non-Federal indicator

-   Six-digit Trading Partner codes

-   ALC number (for Federal customers)

-   Internal Revenue Service (IRS) 1099 indicator

-   Comment field

-   Date of last update

-   User ID of last update

-   DUNS number (RMA‑01)

```{=html}
<!-- -->
```
-   Maintain customer account information for audit trail purposes and
    to support billing, reporting and research activities, including:

```{=html}
<!-- -->
```
-   Account number

-   Account balance

-   Associated Customer ID number

-   Date due and age of accounts receivable

-   Reimbursable order number, travel order number, etc., where
    applicable. (RMA‑02)

#### Value-added Requirements

There are no value-added requirements for this process.

### 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]{.underline}** 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:

```{=html}
<!-- -->
```
-   Percentage of reimbursable obligations, accrued expenditures, or
    costs, using data recorded by the cost accumulation function;

-   Fee schedules for goods or services provided; and

-   Payment schedules or other agreements with other entities. (RMB‑03)

```{=html}
<!-- -->
```
-   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)

-   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]{.underline}** 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 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:

```{=html}
<!-- -->
```
-   In Forbearance or in Formal Appeals Process,

-   In Foreclosure,

-   In Wage Garnishment,

-   Rescheduled,

-   Waived/unwaived,

-   Eligible for Referral to Treasury for Offset,

-   Referred to Treasury for Offset,

-   Eligible for Internal Offset,

-   Eligible for Referral to Treasury or a Designated Debt Collection
    Center for Cross-servicing,

-   Referred to Treasury for cross-servicing,

-   Referred to private collection agency,

-   Referred to Department of Justice,

-   Offset,

-   Suspended,

-   Compromised,

-   Written-off,

-   Closed Out. (RMC‑15)

```{=html}
<!-- -->
```
-   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 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]{.underline}** 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)

-   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]{.underline}** 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)

## 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 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]{.underline}** 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.

### 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]{.underline}** 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.

#### Mandatory Requirements

To support the Cost Distribution process, the Core financial system
**[must]{.underline}** 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]{.underline}** 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)

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

## 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]{.underline}** 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)

#### Value-added Requirements

To support the Financial Reporting process, the Core financial system
**[should]{.underline}** 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]{.underline}** provide the capability to:

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

```{=html}
<!-- -->
```
-   FMS Form 224, Statement of Cash Transactions,

-   FMS Form 1219, Statement of Accountability, and

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

```{=html}
<!-- -->
```
-   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 designed to support agency budget,
accounting, and financial management reporting processes.

#### Mandatory Requirements

To support the Internal Reporting process, the Core financial system
**[must]{.underline}** 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)

-   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:

```{=html}
<!-- -->
```
-   The balance at the beginning of the accounting period,

-   The total amount of debits for the accounting period,

-   The total amount of credits for the accounting period, and

-   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)

```{=html}
<!-- -->
```
-   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.

```{=html}
<!-- -->
```
-   The related official U.S. SGL account number,

-   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)

```{=html}
<!-- -->
```
-   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:

```{=html}
<!-- -->
```
-   Fiscal year,

-   TAS/TAFS,

-   Internal fund,

-   Document number;

-   Document entry date,

-   Document entry time,

-   Document entry User ID,

-   Document transaction date,

-   Debit account number;

-   Debit account object class,

-   Debit amount,

-   Credit account number,

-   Credit account,

-   Object class,

-   U.S. SGL attribute domain headings, and

-   U.S. SGL attribute values associated with the transaction.

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

#### 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]{.underline}**:

-   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)

-   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]{.underline}**:

-   Provide the following ad hoc query interface features:

```{=html}
<!-- -->
```
-   Graphical display of data sources,

-   The ability to "point and click" on selectable table, data, and link
    objects for inclusion in a custom query,

-   An active data dictionary to provide users with object definitions,

-   The ability to share user developed query scripts with other
    authorized agency users, query optimization, and

-   On-line help. (RD‑10).

# 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]{.underline}**:

-   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)

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

```{=html}
<!-- -->
```
-   Back out incompletely processed transactions,

-   Restore the system to its last consistent state before the failure
    occurred, and

-   Re-apply all incomplete transactions previously submitted by the
    user. (TA‑03)

```{=html}
<!-- -->
```
-   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:

```{=html}
<!-- -->
```
-   Product installation and configuration steps,

-   Application access procedures,

-   User screen layout and content,

-   Transaction entry procedures,

-   Batch job set-up, processing and recovery/re-start procedures,

-   Error codes with full descriptions and recovery steps,

-   Standard report layout and content,

-   Internal processing controls,

-   Application security,

-   Operating specifications and system flowcharts,

-   Database entity relationships, table formats and data element
    descriptions, and

-   Program module descriptions. (TA‑06)

```{=html}
<!-- -->
```
-   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)

#### Value-added Requirements

To meet JFMIP application architectural requirements, the Core financial
system **[should]{.underline}**:

-   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]{.underline}**:

-   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]{.underline}**:

-   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)

-   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]{.underline}**:

-   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:

```{=html}
<!-- -->
```
-   Mouse activated icons,

-   Buttons,

-   Scroll bars,

-   Drop-down lists,

-   Check boxes,

-   Menu bars,

-   Text boxes,

-   Tool tips,

-   Resizable windows, and

-   Cut, copy, and paste functions. (TC‑02)

```{=html}
<!-- -->
```
-   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:

```{=html}
<!-- -->
```
-   Single function windows (e.g., one input screen per transaction),

-   The ability to pass common data from screen to screen,

-   Highlighting of required fields,

-   Auto tabs,

-   Function keys (e.g., retrieve previous data, invoke help facility,
    suspend transaction, clear screen, etc.),

-   Disabling of non-supported function keys,

-   Menu mode and an expert mode of screen navigation,

-   The ability to retrieve suspended transactions by user, document,
    vendor, etc.,

-   Transaction entry undo/redo,

-   Context-sensitive on-line help, and

-   The ability to select records from a list by scrolling or by typing
    in only part of an entry. (TC‑03)

```{=html}
<!-- -->
```
-   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]{.underline}**:

-   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:

```{=html}
<!-- -->
```
-   View, update, or delete suspended transactions,

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

```{=html}
<!-- -->
```
-   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)

#### Value-added Requirements

To meet JFMIP interoperability requirements, the Core financial system
**[should]{.underline}**:

-   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]{.underline}**:

-   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]{.underline}**:

-   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)

-   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]{.underline}**:

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

#### Value-added Requirements

To meet JFMIP Internet Access requirements, the Core financial system
**[should]{.underline}**:

-   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]{.underline}**:

-   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)

-   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:

```{=html}
<!-- -->
```
-   All log-in/log-out attempts by user and workstation,

-   User submitted transactions,

-   Initiated processes,

-   System override events; and

-   Direct additions, changes or deletions to application maintained
    data. (TH‑07)

```{=html}
<!-- -->
```
-   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]{.underline}**:

-   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)

-   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]{.underline}**:

-   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:

```{=html}
<!-- -->
```
-   Transaction processing throughput capacity,

-   Expected workstation client response time by transaction type,

-   Data storage capacity, and

-   Limitations on concurrent user connectivity. (TI‑09)

```{=html}
<!-- -->
```
-   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)

# 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

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

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](http://www.nara.gov/)

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.

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

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.

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

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.

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.

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

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.

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.

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.

# Appendix C: Summary of Standard External Reports from Core Financial Systems 

+---------+---------+---------+---------+----------+--------+--------+
| **      | *       | **Pu    | **      | *        | *      | **     |
| Title** | *Form** | rpose** | Level** | *Basis** | *Frequ | Guidel |
|         |         |         |         |          | ency** | ines** |
+=========+=========+=========+=========+==========+========+========+
| Report  | SF-133  | Status  | Appr    | Cash/Ob  | Quar   | OMB    |
| on      |         | of      | opriati | ligation | terly/ | Ci     |
| Budget  |         | bu      | on/Fund |          | An     | rcular |
| Ex      |         | dgetary | Account |          | nually | No.    |
| ecution |         | re      |         |          |        | A-34   |
|         |         | sources |         |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| Federal | Ele     | Report  | Appropr | Accrual  | An     | I      |
| Ag      | ctronic | data    | iation/ |          | nually | TFM-   |
| encies; | Re      | for     | Fund    |          |        | 2-4000 |
| Cent    | porting | consol  | Group   |          |        |        |
| ralized | repl    | idation |         |          |        |        |
| Trial   | acement | from    |         |          |        |        |
| Balance | of      | FACTS I |         |          |        |        |
| System  |         | into    |         |          |        |        |
| (FACTS  | SF-220  | the     |         |          |        |        |
| I)      |         | Fi      |         |          |        |        |
|         | S       | nancial |         |          |        |        |
|         | F-220-1 | Report  |         |          |        |        |
|         |         | of the  |         |          |        |        |
|         | SF-221  | U.S.    |         |          |        |        |
|         |         | Gov     |         |          |        |        |
|         | SF-222  | ernment |         |          |        |        |
|         |         |         |         |          |        |        |
|         | and     |         |         |          |        |        |
|         | SF-223  |         |         |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| Federal | Ele     | Status  | Appr    | Accrual  | Quar   | C      |
| Ag      | ctronic | of      | opriati |          | terly/ | urrent |
| encies; | Re      | bu      | on/Fund |          | An     | TFM    |
| Cent    | porting | dgetary | Account |          | nually | U.S.   |
| ralized | of      | re      |         |          |        | SGL    |
| Trial-  | SF-133, | sources |         |          |        | Supp   |
| Balance | FM      |         |         |          |        | lement |
| System  | S-2108, |         |         |          |        |        |
| (FACTS  | and     |         |         |          |        | FACTS  |
| II)     | Program |         |         |          |        | II     |
|         | and     |         |         |          |        | Client |
|         | Fi      |         |         |          |        | Bulk   |
|         | nancing |         |         |          |        | User's |
|         | S       |         |         |          |        | Guide  |
|         | chedule |         |         |          |        |        |
|         | (actual |         |         |          |        |        |
|         | data    |         |         |          |        |        |
|         | c       |         |         |          |        |        |
|         | olumns) |         |         |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| Report  | SF-133  | Allows  | Appropr | Accrual  | On-    | OMB    |
| on      |         | mon     | iation/ |          | demand | Ci     |
| Budget  |         | itoring | Fund    |          |        | rcular |
| Ex      |         | of      | Group   |          |        | No.    |
| ecution |         | status  |         |          |        | A-34   |
| and     |         | of      |         |          |        |        |
| Bu      |         | funds   |         |          |        |        |
| dgetary |         | that    |         |          |        |        |
| Re      |         | were    |         |          |        |        |
| sources |         | appo    |         |          |        |        |
|         |         | rtioned |         |          |        |        |
|         |         | on the  |         |          |        |        |
|         |         | SF-132  |         |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| Report  | R       | P       | Appropr | Accrual  | Quar   | I      |
| on      | eplaces | rovides | iation/ |          | terly/ | TFM-   |
| Rece    | S       | info    | Fund    |          |        | 2-4100 |
| ivables | F-220-9 | rmation | Account |          | An     |        |
| Due     |         | on the  | but can |          | nually |        |
| from    |         | status  | vary    |          |        |        |
| the     |         | of      |         |          |        |        |
| Public  |         | public  |         |          |        |        |
|         |         | rece    |         |          |        |        |
|         |         | ivables |         |          |        |        |
|         |         | and     |         |          |        |        |
|         |         | delinq  |         |          |        |        |
|         |         | uencies |         |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| St      | FMS-224 | Reports | Agency  | Cash     | M      | I      |
| atement |         | disbur  | l       |          | onthly | TFM-   |
| of      |         | sements | ocation |          |        | 2-3300 |
| Trans   |         | colle   | code by |          |        |        |
| actions |         | ctions, | Appropr |          |        |        |
|         |         | and     | iation/ |          |        |        |
|         |         | status  | Fund    |          |        |        |
|         |         | of      | Account |          |        |        |
|         |         | coll    |         |          |        |        |
|         |         | ections |         |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| Report  | F       | P       | Agency  | Cash     | M      | I      |
| of      | MS-1219 | rovides | l       |          | onthly | TFM-   |
| Account |         | an      | ocation |          |        | 2-3100 |
| ability |         | a       | code    |          |        |        |
|         |         | nalysis | and     |          |        |        |
|         |         | of      | Dis     |          |        |        |
|         |         | dis     | bursing |          |        |        |
|         |         | bursing | Officer |          |        |        |
|         |         | of      |         |          |        |        |
|         |         | ficers' |         |          |        |        |
|         |         | act     |         |          |        |        |
|         |         | ivities |         |          |        |        |
|         |         | in      |         |          |        |        |
|         |         | a       |         |          |        |        |
|         |         | gencies |         |          |        |        |
|         |         | which   |         |          |        |        |
|         |         | do not  |         |          |        |        |
|         |         | do      |         |          |        |        |
|         |         | their   |         |          |        |        |
|         |         | own     |         |          |        |        |
|         |         | dis     |         |          |        |        |
|         |         | bursing |         |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| St      | F       | Reports | Agency  | Cash     | M      | I      |
| atement | MS-1220 | disbur  | L       |          | onthly | TFM-   |
| of      |         | sements | ocation |          |        | 2-3100 |
| Trans   |         | and     | code    |          |        |        |
| actions |         | coll    | and     |          |        |        |
|         |         | ections | Approp  |          |        |        |
|         |         | in      | riation |          |        |        |
|         |         | a       | Fund    |          |        |        |
|         |         | gencies | Account |          |        |        |
|         |         | which   |         |          |        |        |
|         |         | do      |         |          |        |        |
|         |         | their   |         |          |        |        |
|         |         | own     |         |          |        |        |
|         |         | dis     |         |          |        |        |
|         |         | bursing |         |          |        |        |
|         |         | (the    |         |          |        |        |
|         |         | coun    |         |          |        |        |
|         |         | terpart |         |          |        |        |
|         |         | to      |         |          |        |        |
|         |         | F       |         |          |        |        |
|         |         | MS-224) |         |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| Info    | 109     | Provide | T       | Cash     | An     | IRS    |
| rmation | 9-MISC, | info    | axpayer |          | nually | instru |
| Returns | 1099-G, | rmation | Identif |          |        | ctions |
|         | etc.    | to the  | ication |          |        | for    |
|         |         | I       | number  |          |        | forms  |
|         |         | nternal |         |          |        | 1099,  |
|         |         | Revenue |         |          |        | 1098,  |
|         |         | Service |         |          |        | 5498,  |
|         |         | on      |         |          |        | and    |
|         |         | p       |         |          |        | W-2G   |
|         |         | ayments |         |          |        |        |
|         |         | made or |         |          |        |        |
|         |         | debts   |         |          |        |        |
|         |         | f       |         |          |        |        |
|         |         | orgiven |         |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| Balance | N/A     | D       | Trust   | Obl      | An     | OMB's  |
| Sheet   |         | isclose | and     | igation/ | nually | Bu     |
|         |         | st      | re      | Accrual  |        | lletin |
|         |         | atement | volving |          |        | on     |
|         |         | of      | funds,  |          |        | Form   |
|         |         | assets, | a       |          |        | and    |
|         |         | liabi   | ccounts |          |        | C      |
|         |         | lities, | substa  |          |        | ontent |
|         |         | and net | ntially |          |        |        |
|         |         | p       | com     |          |        |        |
|         |         | osition | mercial |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| St      | N/A     | Reports | Trust   | Accrual  | An     | OMB's  |
| atement |         | gross   | and     |          | nually | Bu     |
| of Net  |         | costs   | re      |          |        | lletin |
| Cost    |         | less    | volving |          |        | on     |
|         |         | revenue | funds,  |          |        | Form   |
|         |         | earned  | a       |          |        | and    |
|         |         |         | ccounts |          |        | C      |
|         |         |         | substa  |          |        | ontent |
|         |         |         | ntially |          |        |        |
|         |         |         | com     |          |        |        |
|         |         |         | mercial |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| St      | N/A     | Reports | Trust   | Accrual  | An     | OMB's  |
| atement |         | fi      | and     |          | nually | Bu     |
| of      |         | nancing | re      |          |        | lletin |
| Changes |         | s       | volving |          |        | on     |
| in Net  |         | ources, | funds,  |          |        | Form   |
| P       |         | gains   | a       |          |        | and    |
| osition |         | and     | ccounts |          |        | C      |
|         |         | losses  | substa  |          |        | ontent |
|         |         |         | ntially |          |        |        |
|         |         |         | com     |          |        |        |
|         |         |         | mercial |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| St      | N/A     | Av      | Appropr | Obl      | An     | OMB's  |
| atement |         | ailable | iation/ | igation/ | nually | Bu     |
| of      |         | bu      | Fund    | Accrual  |        | lletin |
| Bu      |         | dgetary | Group   |          |        | on     |
| dgetary |         | re      |         |          |        | Form   |
| Re      |         | sources |         |          |        | and    |
| sources |         | and     |         |          |        | C      |
|         |         | status  |         |          |        | ontent |
+---------+---------+---------+---------+----------+--------+--------+
| St      | N/A     | Report  | Trust   | Accrual  | An     | OMB's  |
| atement |         | on      | and     |          | nually | Bu     |
| of      |         | reconci | re      |          |        | lletin |
| Fi      |         | liation | volving |          |        | on     |
| nancing |         | between | funds,  |          |        | Form   |
|         |         | prop    | a       |          |        | and    |
|         |         | rietary | ccounts |          |        | C      |
|         |         | and     | substa  |          |        | ontent |
|         |         | bu      | ntially |          |        |        |
|         |         | dgetary | com     |          |        |        |
|         |         | a       | mercial |          |        |        |
|         |         | ccounts |         |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+
| St      | N/A     | Report  | Trust   | Accrual  | An     | OMB's  |
| atement |         | of      | and     |          | nually | Bu     |
| of      |         | non-e   | re      |          |        | lletin |
| Cu      |         | xchange | volving |          |        | on     |
| stodial |         | revenue | funds,  |          |        | Form   |
| A       |         |         | a       |          |        | and    |
| ctivity |         |         | ccounts |          |        | C      |
|         |         |         | substa  |          |        | ontent |
|         |         |         | ntially |          |        |        |
|         |         |         | com     |          |        |        |
|         |         |         | mercial |          |        |        |
+---------+---------+---------+---------+----------+--------+--------+

# 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

#### 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

#### 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

#### 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

#### 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

[^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.