Federal

Financi al

Management

Syst em

Requi rement s

Core 

Financial

System 

Requir ements 

Core 

Financial

System 

Requir ements 

June 2 0 0 1
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, 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 Government. The 

Program was given statutory authorization in the Budget and Accounting Procedures Act of 

1950 (31 USC 65 as amended). The four Principals of the JFMIP – Comptroller General of the 

United States, Secretary of the Treasury, and the Directors of the OMB and OPM provide 

leadership and program guidance. Each Principal designates a representative to serve on the 

JFMIP Steering Committee, which is responsible for the general direction of the Program. The 

JFMIP Executive Director and a program agency representative (who serves for 2 years) are 

also on the Steering Committee. 

The Program promotes strategies and guides financial management improvement across 

Government, reviews and coordinates central agencies’ activities and policy promulgations, and 

acts as a catalyst and clearinghouse for sharing and disseminating information about good 

financial management practices. This information sharing is done through conferences and 

other educational events, newsletters, meetings with interagency groups and agency personnel, 

and through the Internet. 

The JFMIP has worked on interagency projects that developed a financial systems framework 

and financial systems requirements. The Program Management Office (PMO) has also revised 

the Federal Government’s requirements definition, testing, and acquisition processes. The 

objectives of the PMO 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 systems requirements. 

For information on JFMIP, call (202) 219-0526, or visit the JFMIP website: www.JFMIP.gov.
JOINT FINANCIAL MANAGEMENT

Improvement Program 

JFMIP

1990 K Street NW 

Suite 430 

Washington, DC 20006

Principals 

David M. Walker 

Comptroller General of the United States 

Paul H. O’Neill 

Secretary of the Treasury 

Mitchell E. Daniels, Jr. 

Director 

U.S. Office of Management and Budget 

Steven R. Cohen 

Acting Director 

U.S. Office of Personnel Management 

Steering Committee 

Jeffrey C. Steinhoff (Chair) 

Managing Director 

Financial Management and Assurance 

U.S. General Accounting Office 

Donald V. Hammond 

Fiscal Assistant Secretary 

Department of the Treasury 

Joseph L. Kull 

Deputy Controller 

U.S. Office of Management and Budget 

Kathleen M. McGettigan 

Chief Financial Officer 

U.S. Office of Personnel Management 

William B. Early, Jr. 

Chief Financial Officer 

General Services Administration 

Karen Cleary Alderman 

Executive Director, JFMIP

Date: June 11, 2001 

To: Senior Financial Officials 

 From: Executive Director, JFMIP – Karen Cleary Alderman 

Subject: JFMIP Core Financial System Requirements Document 

The JFMIP Core Financial System Requirements document Exposure 

Draft is attached for comment. This effort was supported by the JFMIP; 

the Chief Financial Officers’ (CFO) Council Financial Systems 

Committee; OMB; U.S. GAO; Department of Treasury and others. 

The Core Financial System Requirements document was developed by a 

task force led by Stephen Balsam, JFMIP. The task force included 

selected representatives from agency CFO communities (listed in 

Appendix D: Contributors) and individuals who participated in the prior 

tests of core financial system software. This document addresses updates 

to the prior document (JFMIP SR-99-4, February 1999). The revisions are 

the result of meetings with agencies that are currently implementing core 

financial systems, input from the software vendor community, information 

obtained during JFMIP’s testing of vendor core financial system software, 

and new requirements. 

The document is intended to assist agencies when reviewing new core 

financial systems and when improving or evaluating existing core financial 

systems. It provides the baseline functionality that core financial systems 

must have in order to support agency missions and comply with laws and 

regulations. The final issuance of this JFMIP Core Financial System 

Requirements document will augment existing Federal financial 

management system functional requirements used in assessing compliance 

with the Federal Financial Management Improvement Act (FFMIA). 

We are particularly interested in your comments on the following changes 

that have been reflected in this exposure draft: 

1. Requirement type format. In the JFMIP SR-99-4 document the 

mandatory requirements were included and the technical and 

value-added requirements were referenced. In the JFMIP SR-01-

02 document both mandatory and value-added requirements are 

now presented, along with the technical requirements. 

2. Requirement number format. The specific requirements are now 

identified with the numbering scheme that is currently available in the 

requirements section in the Knowledgebase. The exposure draft used this 

numbering scheme and reorders the requirements in a new logical flow. 

The final document will renumber them to reflect their listed order. 
3. Cost Management. The revolving fund requirements, which were previously valueadded, have been expanded and are now mandatory in the Cost Management Function. 

4. Ad hoc reporting requirements are now mandatory versus value-added. 

5. Requirements that state “automatically.” Periodically the requirements will indicate 

that the system must "automatically" do something. While most requirements should be met 

through the system, JFMIP recognizes that occasionally manual intervention may be necessary. 

However, "automatically" is specified for those requirements that the system must meet without 

manual intervention. 

6. Authorized user. In preparing these requirements, agencies commented that 

requirements should in some cases state "authorized user". In lieu of stating this on each 

requirement, JFMIP has added mandatory technical requirements TS-4 through TS-6 as global 

requirements to require system changes only by "authorized users". 

7. Mandatory vs. value-added requirements. Is the categorization of system 

requirements between mandatory and value-added appropriate? Are there requirements that 

should be changed from mandatory to value-added or vice-versa? 

8. Automated method to reclassify accounting data. All requirements should be 

reviewed. However, JFMIP asks specific comment on draft mandatory requirement CF-15 (Core 

Financial System Management mandatory requirement CF-15), which specifies “...an automated 

method to reclassify accounting data.” This requirement, currently value-added, has equal 

requests by agencies for classification as value-added and mandatory. Should this be a valueadded or mandatory requirement? 

9. Glossary. Are all terms sufficiently defined? Are there additional terms that need to be 

defined? 

10. Format Standards. Please comment on the use of format standards for transmitting 

electronic information, (e.g., Electronic Data Interchange (EDI), Extensive Mark-up Language 

(XML) and other formats.) 

This document is being circulated widely within the Federal government’s financial and 

oversight communities and to private sector system providers. It is also being posted in 

electronic Word format on JFMIP’s website at: WWW.JFMIP.GOV.

Please provide your comments by August 20, 2001. Comments on any section of this document 

are encouraged. If possible, we would appreciate responses in the electronic form, placing the 

comment as a “redline” within the available Word document. At a minimum, responses should 

reference the specific requirement number or narrative section related to each comment. 

Responses will be more helpful if the underlying rationale is also provided. Respondents should 

also indicate the capacity in which they are responding. Comments should be sent to: 

 Joint Financial Management Improvement Program 

 Suite 430 

1990 K Street NW 

Washington, DC 20006 

Attn: Core Financial System Requirements, Steve Balsam 

Attachment
Foreword 

This document represents the latest update to the Core Financial System Requirements 

document, first issued in January 1988. This most recent update reflects recent changes in laws 

and regulations and in government-wide reporting systems, such as the Department of 

Treasury’s Federal Agencies Centralized Trial Balance System (FACTS) II system. Also, some 

of the existing requirements have been clarified, redundant or outdated requirements have been 

deleted, vague or open-ended requirements have been addressed, and the priority (mandatory 

or value-added) of certain requirements has been changed and new requirements have been 

added to reflect the current core financial system needs of Federal agencies. 

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 each Agency’s responsibility to be knowledgeable of the legal requirements 

governing its core financial operations; therefore, agencies may develop additional technical 

and functional system requirements as needed to support unique mission responsibilities. 

Agencies must also develop strategies for interfacing or integrating other systems with the core 

financial system. 

These requirements also remain the basis for the Federal government to test compliance of 

commercially based, core financial software. In FY 1999, the JFMIP’s PMO 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) Financial Management 

Systems Software (FMSS) Schedule processes. 

This document should be used in conjunction with JFMIP’s Web based electronic repository, 

called the Knowledgebase, which can be reached through the JFMIP website at 

http://www.JFMIP.gov. These requirements form a major portion of the Knowledgebase. In 

addition, vendor support requirements are included in the Knowledgebase. 

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 the JFMIP PMO and the 

information provided in its Knowledgebase, demonstrates the commitment of the CFO 

community to continually improve Federal financial systems. 

We appreciate their support, and thank the CFOs Council Financial Systems Committee, OMB, 

the GAO, the GSA, and other agencies that participated in improving the requirements 

document. 

 Karen Cleary Alderman 

Executive Director 

Acronyms 

ACH Automated Clearing House 
ALC Agency Location Code 

ANSI American National Standards Institute 

API Application Program Interface 

ATB Adjusted Trial Balance 

BPA Blanket Purchase Agreement 

CCD+ Cash Concentration or Disbursement Plus Addendum 

CFO Chief Financial Officer 

CFR Code of Federal Regulations 

CMIA Cash Management Improvement Act 

COTS Commercial Off-the-Shelf 

CTX Corporate Trade Exchange 

DCIA Debt Collection Improvement Act 

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 

EIN Employee Identification Number 

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 

FOMF Financial Organization Master File 

FTE Full Time Equivalent 

GAO General Accounting Office 

GMRA Government Management Reform Act of 1996 

GOALS Government Online Accounting Link System 

GPRA Government Performance and Results Act of 1994 

GUI Graphical User Interface 

IPAC Intragovernmental Payment and Collection System 

IRS Internal Revenue Service 

JFMIP Joint Financial Management Improvement Program 

MAF Master Appropriation File 

MAPI-WF Messaging API-Workflow 

MVS Multiple Virtual System 

NARA National Archives and Records Administration 

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 

PDF Portable Document Format 

PMO Program Management Office 

PKI Public Key Infrastructure 

P. L. Public Law 

Acronyms (continued)

PPD Prearranged Payment and Deposit 
RTN Routing Transit Number 

SFFAS Statements of Federal Financial Accounting Standards 

SGL Standard General Ledger 

SGML Standard Generalized Markup Language 

SQL Standard Query Language 

TAFS Treasury Account Fund Symbol 

TCP/IP Transaction Control Protocol/Internet Protocol 

TFM Treasury Financial Manual 

TIN Taxpayer Identification Number 

U.S.C. United States Code 

VIM Vendor Independent Messaging 

WFMC Workflow Management Coalition 

XML Extensible Markup Language 

Illustrations (List) 

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

2. Integrated Model for Federal Information Systems .............................................................. 8 

3. Agency Systems Architecture ............................................................................................... 9

4. Core Financial System........................................................................................................ 10 
Table of Contents 

Introduction ................................................................................................................................ 1 

Federal Financial Management Framework .............................................................................. 3 

Integrated Financial Management Systems........................................................................ 6 

Agency Financial Management Systems Architecture........................................................ 7 

Core Financial System Overview............................................................................................... 9 

Summary of Functions...................................................................................................... 10 

Summary of Technical Requirements............................................................................... 14 

Information Stores—Data Requirements .......................................................................... 16 

Functional Requirements ......................................................................................................... 18 

Core Financial System Management Function................................................................. 18 

General Ledger Management Function ............................................................................ 25 

Funds Management Function ........................................................................................... 28 

Payment Management Function....................................................................................... 36 

Receipt Management Function......................................................................................... 45 

Cost Management Function.............................................................................................. 49 

Reporting Function............................................................................................................ 53 

Technical Requirements .......................................................................................................... 55 

General Design/Architecture............................................................................................. 56 

Interoperability .................................................................................................................. 57 

Security............................................................................................................................. 58

Operations and Computing Performance ......................................................................... 59 

Year 2000 Compliance ..................................................................................................... 60 

Infrastructure..................................................................................................................... 60 

User Interfaces.................................................................................................................. 61 

Workflow/Messaging......................................................................................................... 62 

Document Management.................................................................................................... 63 

Internet Access ................................................................................................................. 63 

Data Import/Reconciliation................................................................................................ 64 

Ad Hoc Query ................................................................................................................... 64 

Appendix A: References .......................................................................................................... 66 

Appendix B: Glossary .............................................................................................................. 67 

Appendix C: Summary of External Reporting Requirements................................................... 72 

Appendix D: Contributors......................................................................................................... 75 
Introduction 

The Federal Government recognizes the importance of using state-of-the-art financial systems 

to support Government operations and to provide quality and timely financial and related 

information to program and financial managers. Congress enacted the CFO Act of 1990, 

GMRA, and FFMIA of 1996 to improve 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 for financial and program managers. 

The improvements provide better information for decision-making, and increase the efficiency 

and effectiveness of services provided by the Federal Government. Proper financial 

management and reliable financial systems must provide for: 

Accountability. Inform taxpayers, agency personnel, and the Congress, in terms they can 

readily understand, on how the Nation’s tax dollars are being spent, and that 

Federal assets are being protected. 

Efficiency and Effectiveness. Provide efficient and effective service to the Federal 

agencies’ internal and external customers (e.g. general public, contractors, partnerships, 

state and local Governments, other Federal agencies/organizations, the military, and 

foreign governments). 

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

with timely reports linking financial execution and program results. 

The OMB Circular A-127, “Financial Management Systems”, sets forth general policies for 

Federal financial management systems. Each agency is required to develop and maintain a 

single, integrated financial management system. To support this objective, each agency must 

have an ongoing financial systems improvement planning process and periodic reviews of 

financial system capabilities. In addition, each agency must maintain financial management 

systems that comply with the requirements of the Federal accounting standards established by 

the Federal Accounting Standards Advisory Board (FASAB) in its Statements of Federal 

Financial Accounting Standards (SFFAS) and with the requirements of OMB’s Form and 

Content of Agency Financial Statements. 

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 benchmarks 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 first Core Financial Systems Requirements document in published 

January 1988. 

This document is intended for financial system analysts, systems accountants, systems 

developers, program managers, and others who design, develop, implement, operate, and 

maintain or audit financial management systems. 

1 Core Financial System Requirements – Exposure Draft
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, facilitates the design, implementation, and operations 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. The JFMIP’s PMO tests commercial software functionality against 

these requirements, qualifies the software as meeting mandatory requirements, and publishes 

the results in the Knowledgebase, at http://www.JFMIP.gov. 

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, technical requirements, and data 

requirements is provided in the System Overview chapter. Specific requirements are presented 

in detail in the functional and technical requirements chapters. Appendices provide source for 

References, a Glossary, a Summary of External Reporting Requirements, and a list of 

Contributors. 

Core Financial System Requirements – Exposure Draft 2
Federal Financial Management Framework 

The Core Financial System Requirements document establishes standard requirements for the 

“backbone” modules of an agency’s integrated financial management system. It provides 

common processing routines, supports common data for critical financial management functions 

affecting the entire agency, and maintains the required financial data integrity control over 

financial transactions, resource balances, and other financial management systems. This 

document is a part of a broad program to improve Federal financial management that involves 

the establishment of uniform requirements for financial information, financial systems, reporting, 

and financial organization. 

As shown in Illustration 1, Financial Systems Improvement Projects, establishing uniform 

requirements is only part of the process of improving financial management systems and 

information. Improvements can be achieved through the selection, development, and/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 Government-wide 5-year 

financial management plan, will be successful. 

Well-defined and effective Government-wide 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 Government-wide functional requirements for each 

application is a critical effort that will affect internally developed systems and the evaluation and 

selection of commercially available systems. In support of this vision, the Federal Government 

must establish Government-wide financial management systems and compatible agency 

systems, with standardized information and electronic data exchange, to support program 

delivery, safeguard assets, and manage taxpayer dollars. 

Each agency should integrate its unique requirements with these Government-wide 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 government-wide 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 

3 Core Financial System Requirements – Exposure Draft
• Provide a complete audit trail to facilitate audits. 

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.

Core Financial System Requirements – Exposure Draft 4
5 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 6

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 financial management systems policy stated in OMB Circular A-127 “Financial 

Management Systems,” requires 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 due to 

inaccurate or untimely information; managers are 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 are more likely to be directed toward the collection of information rather than 

to delivery of the intended programs; and modifications to financial management systems 

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 Section 7 of OMB Circular 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 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 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. 

“Integrated” means that the user is able to have one view into the system such that, at whatever 

level the individual is using the system, needed information may be efficiently and effectively 

obtained through electronic means. However, it does not mean that all information is physically 

located in the same database. 

Interfaces, where one system feeds data to another system following normal 

business/transaction cycles, (e.g. salary payroll charges are recorded in general ledger control 

accounts when the payroll payments are made) may be acceptable as long as the supporting 

detail is maintained and accessible. In such cases, interface linkages must be electronic unless 

the number of transactions is so small that it is not cost-beneficial to automate the interface. 

Easy and timely reconciliation between systems, where interface linkages are appropriate, must 

be maintained to ensure data accuracy. 

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

• The 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 must be brought together in a model such as the one shown in Illustration 2. 

These pieces must work together to form an effective integrated information system. A change 

to any part of the model will require determination of the implications on other parts of the 

model. For example, a new reporting requirement may require changes throughout the entire 

model. 

Agency Financial Management Systems Architecture 

Agency financial management systems are information systems which 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 management 

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 government-wide policies, the physical configuration of financial management 

systems, including issues of centralized or decentralized activities, processing routines, data, 

and organizations, is left to the Agency to decide the optimal manner in which to support the 

agency mission. The physical design of the system, however, should consider the agency’s 

organizational philosophy, the technical capabilities available, and the most appropriate manner 

to achieve the necessary single, integrated financial management system for the agency. 

The systems architecture shown in Illustration 3 provides a logical perspective identifying the 

relationships of various agency system types. 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. 

7 Core Financial System Requirements – Exposure Draft
Core Financial System 

As shown in Illustration 3, the Core financial system is an integral part of an agency’s single, 

integrated financial management system. It controls and supports the key functions of an 

agency’s financial management, including general ledger management, funds management, 

payment management, receipt management, cost management, and reporting. The Core 

financial system receives data from all other financial and mixed systems and from direct user 

input, and it provides data and supports processing for those systems that need it. 

Financial management system development and implementation efforts shall seek cost effective 

and efficient solutions as required by OMB Circular 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. 

Core Financial System Requirements – Exposure Draft 8
The JFMIP PMO has been responsible for two major functions: 

• Updating and communicating financial management system requirements so that 

COTS software vendors and agencies can better understand the Federal market 

requirements; and 

• Testing and qualifying COTS software and creating an open Knowledgebase, with 

information available on the functional, design, and performance characteristics of 

certified Core financial management systems software. The availability of this 

information to agencies should reduce acquisition costs and risks of implementing COTS 

products; they will have already been tested and certified as meeting JFMIP 

requirements. 

Only software that has been qualified as meeting JFMIP Core Financial System Requirements 

has been certified. 

Core Financial System Overview 

This chapter provides an overview of a Core financial system. The overview has the following 

sections: 

9 Core Financial System Requirements – Exposure Draft
• Summary of Functions, which presents a high-level description of the functions 

supported by the Core financial system and describes how Core financial systems 

interact with other systems. 

• Summary of Technical Requirements, which summarizes the functionality that core 

financial systems either must have or should have. 

• Information Stores - Data Requirements, which discusses the types of data needed to 

perform the various functions of a Core financial system. 

Summary of Functions 

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 

lower level processes within each function. Illustration 4 depicts the functions within the Core 

financial system. 

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 originate in the Payment 

Management function, would 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, would update cost amounts controlled by the Cost Management function, 

would update the general ledger balances in the General Ledger Management function, and 

would be edited against reference data and update audit trails in the Core Financial System 

Management function. 

Core Financial System Management 

Core Financial System Requirements – Exposure Draft 10
The Core Financial System Management function consists of the processes necessary to 

maintain system processing rules consistent with established financial management policy. 

 This function sets the framework in which all other Core financial system functions operate. 

 The Core Financial System Management function consists of the following processes: 

• Accounting Classification Structure Management 

• Transaction Control 

• Archiving and Purging. 

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 fund 

structure and individual general ledger accounts established in the Core Financial System 

Management function. Depending on the agency’s reporting requirements, some or all general 

ledger accounts may have balances broken out by additional elements of the accounting 

classification structure. All transactions to record financial events must post, either individually 

or in summary, to the general ledger, regardless of the origin of the transaction. 

Subsidiary ledgers at various levels of detail support the general ledger. These subsidiary 

ledgers may be maintained within the Core financial system or in 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 

and organization in the Core financial system, which in turn provide partial support for 

expenditure and expense accounts in the general ledger. 

The General Ledger Management function consists of the following processes: 

• General Ledger Account Definition 

• Accruals, Closing, and Consolidation 

• General Ledger Analysis and Reconciliation 

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 and/or authorized. 

 The Funds Management function of the Core financial system is an agency’s primary tool for 

carrying out this responsibility. 

OMB Circular A-34, “Instructions on Budget Execution,” and, to a lesser extent, OMB Circular A11, “Preparation and Submission of Budget Estimates,” set government-wide policy for funds 

management with which the Core financial system must conform. In addition to supporting the 

government-wide policies, the Funds Management function must support agency policies on 

internal funds allocation methods and controls. 

An agency may have many other systems in addition to the Core financial system that affects 

funds management. For example, procurement and travel systems prepare 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. When possible and cost-effective, these systems should access the 

funds availability editing activity before allowing an obligation to be incurred, such as a contract 

11 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 12

being signed. In some cases, such as payroll, this may not be practical. 

The Funds Management function consists of the following processes: 

• Budget Preparation 

• Budget Formulation 

• Funds Allocation 

• Budget Execution 

• Funds Control 

Payment Management 

The Payment Management function should provide appropriate control over all payments made 

by or on behalf of an agency. Agencies make payments to vendors in accordance with 

contracts; to state governments under a variety of programs; to employees for salaries and 

expense reimbursements; to other Federal agencies for reimbursable work performed; to 

individual citizens receiving Federal benefits; to recipients of Federal loans; and for many other 

reasons. 

Title 5 Part 1315 of the Code of Federal Regulations (CFR) requires that agencies must make 

payments to vendors on time, pay interest penalties when payments are late, and take 

discounts only when payments are made on or before the discount date. The Cash 

Management Improvement Act (CMIA) specifies requirements for payments made to states. 

 Regulations implementing CMIA are at Title 31 CFR 205. Other regulations affect 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 this situation 

exists, these other systems must meet the requirements listed here for payment management. 

Other systems may also support activities that lead up to the payment stage, such as recording 

obligations and expenditures and establishing payables, but depend on the Core financial 

system to manage the actual payment process itself. For example, a travel system 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 take over to schedule the payment for disbursement and confirm that it occurred. 

The Payment Management function consists of the following processes: 

• Payee Information Maintenance 

• Payment Warehousing 

• Payment Execution 

• Payment Confirmation and Follow-up. 

Receipt Management 

The Receipt Management function supports activities associated with recording agency cash 
receipts, including servicing and collecting receivables. 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. Some receipts may be collected without the prior establishment of a 

receivable, as in the case of goods sold for cash. 

A receivable is recognized when the agency establishes a claim to cash or other assets against 

other entities, either based on goods or services provided or on legal provisions, such as a 

payment due date (e.g., taxes not received by the date they are due). If the exact amount is 

unknown, a reasonable estimate is made. Receivables are accounted for as assets until funds 

are collected, converted into other resources, or determined to be uncollectible in whole or in 

part. 

Depending on an agency’s system architecture, servicing and collection activities for some 

receivables may be supported by other systems that provide transaction 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 Receipt 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 Receipt Management function consists of the following processes: 

• Receivable Establishment 

• Receivable Management 

• Collections 

• Offset Process. 

Cost Management 

The Cost Management function of the Core financial system attempts to measure the total cost 

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 and 

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 is to be measured. 

The level of sophistication of the Cost Management function needed by an agency is depends 

on the requirements of the agency and the operational nature of the programs involved 

(appropriation only, appropriation with reimbursable authority, revolving fund). 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. 

13 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 14

The Cost Management function consists of the following processes: 

• Cost Setup and Accumulation 

• Cost Recognition 

• Cost Distribution 

• Working Capital and Revolving Fund. 

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. 

Reporting 

The Core financial system must be able to provide timely and useful financial information to 

support: (1) management’s fiduciary role; (2) budget formulation and execution functions; (3) 

fiscal management of program delivery and program decision making; and (4) internal and 

external reporting requirements, including, as necessary, 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. 

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, 

extract data files, and hard-copy reports. These requirements could be satisfied by (1) 

application software that is part of the Core financial system, (2) generalized reporting/inquiry 

software that works with a variety of applications, or (3) a combination of both. 

Summary of Technical Requirements 

Technical requirements have been established to help ensure that a Core financial system (1) is 

capable of meeting a wide variety of workload processing demands; (2) provides transaction 

processing integrity and general operating reliability; (3) is easy to install, configure and operate; 

and (4) does not conflict with other administrative/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 requirements listed in the following subcategories are 

mandatory: 

 

 General Design/Architecture 

 Interoperability 

 Security 

 Operations and Computing Performance 

 Year 2000 Compliance 

The following subcategories include requirements that are value-added: 

 Infrastructure 

 User Interfaces 

 Workflow/Messaging 

 Document Management 
 Internet Access 

The following subcategory is comprised of both mandatory and value-added requirements: 

 Ad Hoc Query 

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. 

15 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 16

Information Stores - Data Requirements 

The Core financial system stores, accesses, and updates several types of data. In this 

document, a grouping of related types of data is referred to as an “information store.” The term 

“information store” is used rather than “database” or “file” to avoid any reference to the technical 

or physical characteristics of the data storage medium. Actual data storage (physical databases 

and files) must be determined by each agency during system development and implementation 

based upon agency statutory requirements, technical environment, processing volumes, 

organizational structure, and degree of system centralization or decentralization. 

The information stores defined here are logical groupings of data. Some of this data may be 

derived from summarizing more detailed data and, as a result, may not be stored in a 

permanent, physical form in some systems. In other cases, implementation of a single 

information store may involve several record types or files. As stated above, the physical 

storage characteristics are considered part of the specific system implementation strategy, 

which is outside the scope of this document. 

The information stores used by the Core financial system are as follows: 

General Ledger. This refers to data summarized to the level of a trial balance for each fund by 

fiscal year; includes control totals for all general ledger accounts. 

Funds Availability. This refers to data supporting the funds allocation and funds control 

processes; tracks budgetary resources and usages (such as, but not limited to, allotments, 

commitments, undelivered orders, and expenditures) at the various levels within an agency’s 

accounting classification structure (ACS) that an agency wishes to control its funds. 

Operating Data. This refers to subsidiary ledger supporting data for general ledger accounts 

tracked at the lowest level of the accounting classification structure; typically used for cost data, 

detailed funds reporting, and similar purposes that require data by organization, program, etc. 

may be used to support some or all general ledger accounts, depending on an agency’s internal 

management and reporting needs. 

Documents. This refers to balances and descriptive data of individual documents, such as 

requisitions, purchase orders, contracts, vouchers, billings, advances, and the like. 

Posted Transactions. This refers to data from financial transactions that have been 

processed, accepted and posted to the system; used to provide an audit trail of financial 

transactions. 

Suspended Transactions. This refers to data from financial transactions that have been 

placed in a suspended status, (i.e. not posted to the other information stores) due to errors in 

the data or due to the timing of the processing cycle for them, such as holding for overnight 

processing. 

Logging Data. This refers to data used for audit trails to record activity in the system other than 

financial transactions, such as table changes. 

Reference Data. This refers to data used to control actions of the system, define codes and 

descriptive titles, etc., such as accounting classification structure code tables, general ledger 
account definitions, transaction definitions, and security control tables. 

External Entities. This refers to data concerning other entities the agency deals with, such as 

payees and customers, including name, address, taxpayer identification number, banking 

information, or other appropriate data depending on the function associated with the entity. 

17 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 18

Functional Requirements 

This chapter identifies the government-wide 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 

 Receipt 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 six principal financial statements for Federal agencies in accordance with 

the current OMB Bulletin on the form and content of agency financial statements. 

Core Financial System Management Function 

The Core Financial System Management function consists of the processes necessary to 

operate and maintain the core system consistent with established financial and related (e.g., 

record retention) laws, regulations, governmentwide policy, and best practices. This function 

sets the framework in which all other Core financial system functions operate. The Core 

Financial System Management function consists of the following processes: 

• Accounting Classification Structure Management 

• Transaction Control 

• Archiving and Purging. 

The core financial system management function ensures that the procedures for capturing, 

classifying, communicating, processing, and storing data and transactions are uniform (or 

translatable among the various subsystems or system components as necessary). 

Accounting Classification Structure Management Process 

Within each department or agency, the accounting classification structure and definitions must 

be standardized to ensure consistency, uniformity, and efficiency in accounting treatment, 

classification, and reporting. The Accounting Classification Structure Management process 

provides a consistent basis for: 

• Consolidating government-wide 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, 
• Comparing and combining similar programs across agencies and calculating overall 

program results. 

The OMB Circular 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. Government Standard General Ledger (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 structure 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 structure will depend in part on the 

implementation strategy for the SGL (e.g., use of sub-accounts versus data elements), data 

aggregation requirements for preparation of financial statements under the CFO Act, 

appropriation structure, and other reporting and management needs of the agency. 

Mandatory Requirements

To support the Accounting Classification Structure Management process, the Core financial 

system must provide the capability to: 

• Classify accounting transactions by the following structures: fund, program, 

organization, project, activity, and budget sub function code, cost center and object 

class. (CF-1) 

• Achieve consistency in budget and accounting classifications and synchronization 

between those classifications and the organizational structure. Consistency will 

include maintaining data relationships between budget formulation classifications 

(budget functional classification code, see OMB Circular A-11) and budget execution 

and accounting classifications (Treasury Account Fund Symbols (TAFS)), and the 

agency’s organizational structure. (CF-2) 

• Provide a fund structure that identifies appropriation and fund accounts established by 

OMB and Treasury, with additional detail below the appropriation level to support 

fiscal year accounting, appropriation sub-accounts used for reporting to Treasury, and 

financial statement preparation. (CF-3) 

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

used for each funding mechanism (e.g., annual appropriation, multiyear appropriation, 

no-year appropriation, revolving fund, trust fund, receipt account, reimbursable fund). 

At a minimum, these characteristics must be supported: fund type, (e.g., general fund, 

deposit fund, trust fund, revolving fund); borrowing source: OMB function 

designations; budget status (e.g., on budget, off budget, or financing account); and 

the fiscal year designation (e.g., annual, multiyear, no-year obligation authority, 

reimbursable funds). (CF-4) 

• Provide a program structure with sufficient levels of detail to allow reporting for all 

19 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 20

categories on which budgetary decisions are made, whether legally binding, as in 

appropriation limitations, or in the nature of policy guidance, as in Presidential passbacks, or congressional markup tables. (CF-5) 

• Establish an organization structure based on responsibility segments, such as offices, 

divisions, and branches. Provide for the ability to tie responsible organizational units 

to programs and projects. (CF-6) 

• Capture Agency Location Codes (ALC’) and TAFS’ on all transactions and reports 

involving Treasury and other disbursing centers, including, but not limited to, the SF224, “Statement of Cash Transactions”; SF-215, “Deposit Ticket,” and SF-5515, “Debit 

Voucher.” (CF-7) 

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

allow multiple organizations, programs, and funding sources to be associated with a 

project. (CF-8) 

• Provide an object class structure consistent with the standard object class codes 

contained in OMB Circular A-11, “Preparation and Submission of Budget Estimates.” 

Provide flexibility to accommodate additional levels (higher and/or lower) in the object 

class structure. (CF-9) 

• Provide a revenue source code structure to identify and classify types of revenue and 

receipts in sufficient detail to facilitate proper representation and/or eliminations on 

agency financial statements. At a minimum, the revenue source code structure must 

enable the user to differentiate between federal and non-federal revenue sources. For 

Federal sources, the structure must enable the user to differentiate between inter and 

intra-agency transactions, and the internal source entities for intra-agency 

transactions. (CF-10) 

• Process additions, changes and deletions to the accounting classification structure 

without extensive program or system changes, (e.g., through on-line table updates).

(CF-13) 

• Enter, edit and store table changes for automatic processing at a future effective date. 

(CF-13C) 

• Maintain historical reference tables for each fiscal year for all elements of the account 

structure for use in reconstruction of prior-year reports. (CF-13B) 

• Provide for an automated method to reclassify accounting data at the document level 

when a reorganization of the classification structure is necessary. Maintain an audit 

trail from the original postings to the final posting. (CF-15) 

• Prohibit new transactions from posting to accounting classification structures that 

have been deactivated. Provide a warning when table updates/changes affect 

pending transactions. (CF-15B) 

• Account for budgetary resources at a lower level in the accounting classification 

structure than they are budgeted and controlled. (CF-14) 

Value-added Requirements

To support the Accounting Classification Structure Management process, the Core financial 

system should provide the capability to: 

 Test all transactions involving Treasury and other disbursing centers for valid 
combinations of ALC and fund, as defined by the user. (CF-7B) 

 Derive the expanded accounting classification structure 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. (CF-12) 

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, as well as keep track of 

such transactions and related information, in order to provide the basis for central financial 

control. 

The Transaction Control Process is further categorized as Transaction Definition and 

Processing activities, and Audit trail activities. 

Transaction Definition and Processing. OMB Circular 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 applying the requirements of the SGL at the transaction 

level. This is accomplished by defining a standard transaction(s) for each accounting event. 

SGL accounting transactions typically update multiple budgetary and proprietary accounts 

based on a single accounting event. The core financial system must ensure that all transactions 

are handled consistently, regardless of their point of origin. It also must ensure that transactions 

are controlled properly to provide reasonable assurance that the recording, processing, and 

reporting of financial data are properly performed and that the completeness and accuracy of 

authorized transactions are ensured. 

Mandatory Requirements

To support the Transaction Definition and Processing activity, the Core financial system must

provide the capability to: 

• Allow users to define standard transactions and posting and editing rules for all 

accounting events, including the associated accounting entries (i.e., debit and credit 

accounts) to be generated. (CF-26) 

• Provide the ability to require or omit individual data elements of the accounting 

classification structure for each debit and credit of the transaction. (CF-26B) 

• Update all applicable SGL account balances (i.e., budgetary, proprietary and 

memorandum accounts) based on a single input transaction. (CF-27) 

• Define, generate and post compound SGL debit and credit entries (at least 10 pairs) 

based on a single transaction. (CF-28) 

• Define and process system-generated transactions, such as automated accruals (e.g., 

depreciation 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. (CF-29) 

21 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 22

• Automatically liquidate, partially or in full, the balance of open documents by line item. 

This capability will be used in the liquidation of 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). (CF-30) 

• Provide controls to prevent the alteration of financial data except through the posting 

of transactions that are subject to the core financial system security, edits, validations 

and error correction procedures. (CF-40B) 

• 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. (CF-41) 

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

reason for error and provide the ability to enter corrections on-line. (CF-41B) 

• Query and modify, on-line, any interfaced data failing the edit routines. (CF-42B) 

• Provide transaction edits that control, at a minimum, fund availability, accounting 

classification structure, and tolerance levels between related transactions, such as 

between an obligation and its related accrual. (CF-46) 

• Provide controls to prevent the creation of duplicate transactions. (CF-47) 

• Validate all codes entered by users on transactions, including, but not limited to: ACS, 

SGL, vendor, and transaction codes. Also, provide user inquiry capabilities through 

drop-down boxes or query screens. (CF-48) 

• Enter, edit, and store transactions in the current accounting period for automatic 

processing in a future accounting period. (CF-49). 

• Put transactions in a hold status (saved, but not processed or posted) within the core 

system. Allow users to select held transactions and continue processing at a later 

date. (CF-49B) 

• Capture trading partner codes in the processing of intra-governmental and intergovernmental transactions. (CF-50) 

• Capture transaction dates (effective date of the transaction), posting date (date 

transaction posted to general ledger), accounting period (year, quarter, month), and 

fiscal year for all transactions. (CF-56) 

• Automatically determine the posting date from the system date for all transactions. 

Automatically insert a default accounting period on transactions, but allow user to 

override. (CF-57) 

• Automatically reverse entries by user-defined parameters such as type, schedule, etc. 

(CF-58) 

• Post to the current and prior months concurrently until month-end closing; maintain 

and provide 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 prior month closing. (CF-39) 

• Post to the current fiscal year and prior fiscal year concurrently until year-end closing. 

Provide on-line queries and reports on balances separately for the current and prior 

fiscal year. (CF-40) 

Value-Added Requirements:
To support the Transaction Definition and Processing activity, the Core financial system should

provide the capability to:

• Automatically generate pro forma transactions by accounting event or source/type of 

document without requiring the user to enter specific transaction codes and 

associated SGL accounts. (CF-33) 

• Define, generate and post compound SGL debit and credit entries (more than ten 

pairs) based on a single transaction. (CF-28B) 

• Perform validation checks for use of certain SGL accounts associated with specific 

Record Type 7 authority (e.g., imprest fund, borrowing authority) prior to posting a 

transaction. (CF-33B) 

• 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. (CF-51) 

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

(CF-51B) 

Audit Trails. Adequate audit trails are critical to providing support for transactions and 

balances maintained by the Core financial system. While audit trails are essential to auditors 

and system evaluators, they are also necessary for day-to-day operation of the system. For 

example, they allow for the detection and systematic correction of errors. 

Mandatory Requirements

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

• Provide audit trails to trace transactions from source documents, original input, other 

systems, system-generated transactions, and internal assignment transactions 

through related system processing. (CF-34) 

• Provide audit trails to trace source documents and transactions through successive 

levels of summarization to the financial statements data. (CF-35) 

• Perform on-line "drill downs" from general ledger summary balances to detail 

transactions and associated source documents (e.g., purchase orders, receiving 

reports, etc.). (CF-34B) 

• Select items for review based on user-defined criteria by type of transaction. 

Examples of reasons to select items are payment certification and financial statement 

audits. (CF-37) 

• Provide audit trails that identify document input, change, approval, and deletions by 

user. (CF-38) 

Value-added Requirements

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

 Notify the feeder system of all errors identified for interface transactions that fail core 

financial system edits, (New) 

23 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 24

 Propagate data input fields with values from existing tables or files, such as vendor 

information. (New) 

Archiving and Purging Process 

The Archiving and Purging process supports data management for the Core financial system. It 

removes data that is no longer needed for immediate access from the system data stores used 

for inquiry and reporting on current information. Archiving moves data to a more permanent 

storage medium that generally also has a longer access time, for example, moving records from 

disk to tape. Purging deletes data altogether. To balance user needs with resource limitations, 

the system administrator and users should jointly agree on archiving and purging criteria. 

Mandatory Requirements

To support the Archiving and Purging process, the Core financial system must provide the 

capability to: 

• Establish and maintain user-defined archival and purging criteria, such as date, 

accounting period, closed items, vendors inactive for a specific time period. Allow for 

selective archiving and purging of those documents that meet the one or more of the 

criteria. (CF-54) 

• Selectively retrieve archived records. (CF-52) 

• Retain system records in accordance with Federal regulations established by the 

National Archives and Records Administration (NARA), GAO, and others. (CF-55) 
General Ledger Management Function 

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 fund 

structure and individual general ledger accounts established in the Core Financial System 

Management function. Depending on the agency’s reporting requirements, some or all general 

ledger accounts may have balances broken out by additional elements of the accounting 

classification structure and by attributes required to meet FACTS reporting requirements. 

The General Ledger Account Definition process establishes the general ledger account 

structure for the agency in accordance with the SGL, and establishes the transaction edit and 

posting rules to record financial events. The prescribed basis for Federal agency accounting is 

the accrual basis (31 U.S.C. 3512(e)). The SGL account and transaction definitions and the 

form and content requirements for financial statements were developed consistent with this 

concept. 

Subsidiary ledgers at various levels of detail support the general ledger. These subsidiary 

ledgers may be maintained within the Core financial system or in 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 

and organization in the Core financial system, which in turn provide partial support for 

expenditure and expense accounts in the general ledger. 

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 originated in other systems may occur either for 

individual transactions or for summarized transactions as long as an adequate audit trail is 

maintained. The Core financial system is not expected to maintain duplicates of every 

transaction occurring in other systems. For example, rather than posting every payroll 

transaction for every employee, summary transactions by organization could be passed to the 

Core financial system for posting. 

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 Account Definition Process 

OMB Circular A-127, “Financial Management Systems,” requires implementation of the SGL at 

the transaction level. The SGL is described in a supplement to the Treasury Financial Manual 

(TFM) which includes the chart of accounts, account descriptions and postings, accounting 

transactions, suggested data elements/sub-accounts, and crosswalks to standard external 

reports. Each agency must implement a chart of accounts that is consistent with the SGL and 

meets the agency’s information needs. 

25 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 26

Mandatory Requirements

To support the General Ledger Account Definition process, the Core financial system must

provide the capability to: 

• Define and maintain a chart of accounts consistent with the SGL, including account 

titles and the basic numbering structure. (CF-18) 

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

the system, and maintain the relationships between accounts as described in the 

SGL. (CF-19) 

• Provide SGL control accounts for detailed subsidiary accounts in the core or external 

systems. (CF-21) 

• Create additional sub-accounts to the SGL for agency specific tracking and control. 

 These sub-accounts will summarize to the appropriate SGL accounts. (CF-24) 

• Capture general ledger information, including attributes, required for FACTS I and 

FACTS II reporting by TFM Transmittal Letter No. S2-01-01 or its successor. (CF18B) 

• Provide flexibility so that the system can adapt to changing FACTS II data model and 

reporting requirement changes, such as by maintaining attributes in user updated 

tables. (R-8B) 

• Process additions, deletions, and changes to the chart of accounts without extensive 

program or system changes, (e.g., through on-line table updates.) Provide a warning 

when table updates/changes affect pending transactions. (CF-20B) 

• Prohibit new transactions from posting to general ledger accounts that have been deactivated. (CF-20C) 

Accruals, Closing and Consolidation Process 

This process creates accrual transactions 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 year-end entries. This process supports the preparation 

of consolidated financial statements by identifying information needed in that process. 

Mandatory Requirements

To support the Accruals, Closing, and Consolidation process, the Core financial system must

provide the capability to: 

• Allow for accruals of contracts or other items that cross fiscal years. (SGL-6) 

• Automatically generate selected recurring accrual entries and reversals in subsequent 

accounting periods based on user-defined criteria. (SGL-5) 

• Close an accounting period and prohibit subsequent postings to the closed period. 

(SGL-3) 

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

accounting period’s closing balances, without intervention or adjustment. The rollover 

of SGL balances must be accomplished in a detailed manner so as to maintain 

FACTS attribute information (e.g. vendor type –government, non-government, 
department/bureau codes, funded/unfunded). (SGL-3B) 

• Perform multiple preliminary year-end closings, while maintaining the capability to 

post current and prior period data. (SGL-4) 

• Generate fiscal year end pre-closing and closing entries as they relate to fund types 

and as defined by the user. (SGL-7) 

• Automatically generate intra-entity elimination transactions, based on a six-digit 

trading partner codes or other alternative, reporting purposes only (with no effect on 

actual account balances). Provide for exception reporting of out-of-balance 

eliminations. (SGL-8) 

• Provide for an automated year-end rollover of appropriate system tables into the new 

fiscal year. (SGL-11) 

• Record and control upward and downward adjustments and recoveries of prior-year 

obligations in the appropriate fiscal year. (SGL-12) 

General Ledger Analysis and Reconciliation Process 

This process supports the control functions of the General Ledger. The Core financial system 

provides information for accountants to use in determining that amounts posted to general 

ledger control accounts agree with more detailed subsidiary accounts and in reconciling system 

balances with financial information contained in reports from Treasury and other agencies. As 

internal controls improve and system integration increases, the likelihood of out-of-balance 

conditions decreases; however, the possibility of such conditions will always exist as a result of 

system failures, incorrect transaction definitions, etc. 

Mandatory Requirements

To support the General Ledger Analysis and Reconciliation process, the Core financial system 

must provide the capability to: 

• Compare amounts in the general ledger accounts with the amounts in the related 

subsidiary records and report 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. (SGL-13) 

• Record the on-line correction of out-of-balance conditions discovered during the 

reconciliation of general ledger controls accounts to subsidiary records. Maintain an 

audit trail of all such corrections. (SGL-15) 

• Perform on-line "drill downs" from general ledger summary balances to detail 

transactions and associated documents (e.g., purchase orders, receiving reports, 

etc.). (CF-34B)

• Maintain historical data to produce comparative financial reports and statements. 

(SGL-2) 

• Allow closed documents to be reopened at the document control level with all 

associated transaction history. The control totals and balances in the month in which 

the document was closed will not be affected by a reopened document. Adjustments 

to the reopened document will only affect control totals and balances in the open 

accounting period in which the document was reopened. (CF-53) 

27 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 28

Funds Management Function 

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 and/or authorized. 

 The Funds Management function of the Core financial system is an agency’s primary tool for 

carrying out this responsibility. 

OMB Circular A-34, “Instructions on Budget Execution,” and, to a lesser extent, OMB Circular A11, “Preparation and Submission of Budget Estimates,” set government-wide policy for funds 

management with which the Core financial system must conform. In addition to supporting the 

government-wide policies, the Funds Management function must support agency policies on 

internal funds allocation methods and controls. 

An agency may have many other systems in addition to the Core financial system that affects 

funds management. For example, procurement and travel systems prepare 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. When possible and cost-effective, these systems should access the 

funds availability editing activity before allowing an obligation to be incurred, such as a contract 

being signed. In some cases, such as payroll, this may not be practical. 

The Funds Management function consists of the following processes: 

• Budget Preparation 

• Budget Formulation 

• Funds Allocation 

• Budget Execution 

• Funds Control 

Budget Preparation Process 

Budget preparation is the process of establishing initial agency financial resource plans and 

updating them as necessary throughout the fiscal year. The function includes reporting on the 

use of resources against these plans throughout the year. 

Mandatory Requirements

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

capability to: 

• Establish and maintain operating plans at or below the level of funds control. (FD-8) 

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

structure specified by the user. (BP-2) 

• Track and report on the use of funds against operating plans. (FD-50 and FD-51) 

Value-added Requirements

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

capability to: 

• Prepare operating plans based on multiple measures, including obligations, costs, 
labor hours, and full-time equivalents (FTEs). (BP-5) 

• Modify/revise an existing operating plan by line item. (BP-1) 

• Maintain original and modified operating plans. (BP-4) 

• Identify legal and administrative limitations on funds in operating plans. (BP-6) 

• Automatically generate allotments and sub-allotments (including limitations based on 

approved changes to obligation-based financial plans) and upload them to the core 

financial system. (BP-7) 

• Enter financial plans for future operating periods. (BP-3) 

• Roll future plans into active budget plans based on future date or retrieval function. 

(BP-8) 

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

Value-added Requirements

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

capability to: 

 Report 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). (BF-1) 

 Populate the budget formulation system with prior-year budgeted and actual 

amounts. (BF-3) 

 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.) (BF-4) 

 Adjust projection rates (e.g., 90 percent, 100 percent, and 110 percent) and exclude 

specified obligations from projection. (BF-11) 

 Create, store, and modify payroll forecasts, including anticipated monthly 

compensation and benefits, at the individual employee level. (BF-11B) 

 Incorporate overhead distribution as part of budget formulation. (BF-11D) 

 Develop budgets on-line and via upload from spreadsheets. (BF-2) 

 Prepare budget submission guidance, budget narratives, and budget briefing 

packages on-line and via upload from desktop software applications. (BF-6) 

 Distribute budget submission guidance to subordinate organizations electronically. 

(BF-5) 

 Establish and maintain multiple budget cycles. (BF-10) 

 Tie budget formulation and execution to Government Performance and Results Act 

29 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 30

(GPRA) goals and objectives. (BF-11C) 

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. The higher levels, such 

as appropriation, apportionment and allotment, have the weight of legal authority behind the 

limitations. Lower levels of control are generally used for internal management purposes. 

Mandatory Requirements

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

to: 

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

apportionments, allotments) and limitations. (FD-1) 

• 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. (FD-2) 

• Distribute, track, control, and report funds authorized at various funding levels, based 

on the accounting classification structure and project structure. (FD-4) 

• Verify that funds allocated do not exceed the amount of funds available at each 

distribution level. (FD-4B) 

• Support 1990 Public Law (P. L.) 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. (FD-4C) 

• Record and control funds that receive other budgetary authority in addition to 

appropriations, including offsetting collections, receipts (when authorized by law); 

reimbursements; and trust funds and donations. Identify the type of authority and track 

obligations by funding source (e.g. reimbursable, appropriated direct). (FD-6) 

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

OMB Circular A-34 and the SGL. (FD-7) 

• Account for spending transactions at a lower level in the accounting classification 

structure than they are budgeted. (FD-10) 

Value-added Requirements

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

capability to: 

 Automatically generate SF-132 Apportionment and Reapportionment Schedule and 

store associated financial information. (FD-1B) 

 Support 1990 P. L. 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 and also do not exceed the original 

appropriation of the closed account. (FD-4C) 

 Prepare apportionment requests on-line and electronically transmit them to OMB. 

Store prepared requests as submitted for future use. (FD-11) 
 Generate budget execution data in format required by OMB's MAX system. (FD11B) 

 Automatically prepare the formal allotment and sub-allotment documents based on 

changes to obligation-based financial plans and electronically distribute them to 

subordinate organizations. (FD-12) 

Budget Execution Process 

The Budget Execution process is the highest level of an Agency’s funds control and consists of 

processes needed to ensure that where the agency’s fund 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. The timeframe covered by an 

agency’s fund control system will correspond to the agency’s financial plans. Allotment systems 

should be designed so that responsibility for budget control is placed at the highest practical 

organizational level consistent with effective and efficient management and control. 

Mandatory Requirements

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

to: 

• Record budget authority at multiple levels of distribution (at least five). (BE-1) 

• Track and record all changes to budget authority - including rescissions, 

supplementals, transfers between appropriations, reprogramming, limitations and 

changes to continuing resolutions prior to appropriation enactment - at multiple levels 

of distribution (at least five). (BE-1B) 

• Track actual amounts (e.g., commitments and obligations) against the original budget 

as revised, consistent with each budget distribution level. (BE-2) 

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

organizational levels (at least five). (BE-3) 

• Manage and control prior-year funds in the current year. Identify and report current 

year increases and decreases to prior-year obligations (i.e., prior-year recoveries) by 

fiscal year appropriated. (BE-4) 

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

a not-to-exceed dollar threshold. (BE-6) 

• Automatically withdraw (or cancel) uncommitted and/or unobligated allotments and 

sub-allotments for all or selected appropriations at the end of a specific fiscal period. 

(BE-7) 

• Automatically withdraw (or cancel) uncommitted and/or un-obligated allotments and 

sub-allotments for selected organizations at the end of a specific fiscal period. (BE-8) 

Value-added Requirements

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

capability to: 

 Perform automated distribution of changes in budget authority (e.g., rescissions). 

(BE-3B) 

31 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 32

 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. (BE-3C) 

 Establish limitations in accordance with credit reform objectives for loan programs, 

including program lending limits and available subsidy amounts. (BE-5) 

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

funding. (BE-10) 

 Generate budget execution transactions from the budget formulation structure and 

accounts. (BE-13) 

Funds Control Process 

This process records transactions affecting the resource usage accounts in the budgetary 

section of the SGL (e.g., commitments, undelivered orders, expenditures, reimbursements 

earned). 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 provide the 

capability to: 

• Establish and modify multiple levels of funds control using elements of the 

classification structure, including object class, program, organization, project, and 

fund. (FD-15) 

• Establish and modify the system’s response (either reject transaction or provide 

warning) to the failure of a funds availability edit for each transaction type. (FD-16) 

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

transactions (commitments, obligations, and expenditures). (FD-13) 

• Use appropriate calculations to determine funds availability based on whether funds 

cited are current, expired, or canceled and record appropriate accounting entries for 

the use of these funds. Properly account for prior-year de-obligations and do not 

allow the use of these funds for current year expenditures. (FD-21) 

• Provide the capability for external modules or systems to access the financial system 

to perform funds availability checking. (FD-13B) 

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

obligations, undelivered orders, and expenditures. (FD-18) 
• Provide for modification to spending documents (commitments, obligations and 

expenditures), including ones that change the dollar amount or the accounting 

classification structure cited. Check available funds for changes. (FD-23) 

• Provide on-line notification to users of transactions failing funds availability edits, and 

place the rejected transactions in an error/suspense file for corrective action. This is 

to include transactions entered directly to the core system and those received from 

external modules or systems. (FD-19) 

• Override funds availability edits, including transactions rejected for exceeding userdefined tolerances. Produce a report or otherwise notify management of the over 

obligation of funds. (FD-14 and FD-17) 

• Update all appropriate accounts to ensure that the system always maintains and 

reports the current status of funds. (FD-20) 

• Check available funds when the obligation exceeds the commitment document or 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. Within tolerances, adjust 

the obligation accordingly. (FD-24 and FD-24B) 

• Adjust available fund balances as reimbursable orders are accepted. In the case of 

reimbursable orders from the public, an advance must also be received before 

additional funding authority is recorded. (FD-25) 

• Track all activity related to an individual reimbursable agreement. Check available 

funds for commitments, obligations, and expenditures incurred in support of 

reimbursable agreements against the amount authorized by the agreement and the 

corresponding start and end dates. (FD-26) 

• 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. (FD-26B) 

Value-added Requirements

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

capability to: 

 Automatically notify users when funds availability is reduced by transactions from 

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

Commitments. This activity records commitment documents, such as requisitions. 

Commitments are an optional stage prior to the establishment of an obligation. 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 obligations. 

Mandatory Requirements

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

• Allow commitment documents to be entered into the Core financial system on-line and 

33 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 34

from multiple locations, as well as through interfaces with other systems. (FD-27) 

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

At a minimum, the Core financial system must capture: 

• requisition number, 

• accounting classification structures, and 

• estimated amounts. (FD-28) 

• Input line item detail for commitment, obligation, receiving, and invoice/voucher 

documents, including item description, unit price, quantity of goods and/or services, 

accounting information, and amounts. (FD-29B) 

• 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. (FD-30) 

• Close commitments by document and line item under the following circumstances: (1) 

by the system upon issuance of an obligating document, (2) by an authorized user, 

and (3) as part of the year-end pre-closing process. (FD-31) 

Obligations. OMB Circular A-34 defines obligations as amounts of orders placed, contracts 

awarded, services received, and similar transactions during a given period that will require 

payments during the same or a future period. Such amounts include outlays for which obligations 

had not been previously recorded and reflect adjustments for differences between obligations 

previously recorded and actual outlays to liquidate those obligations. 

Mandatory Requirements

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

• Allow vendor used on obligation to be different from suggested vendor recorded on a 

commitment document. (FD-32B) 

• Record obligations for which there is no related commitment. (FD-33) 

• Maintain information related to obligation documents and related amendments, 

including obligating document number and type; vendor information, accounting 

classification structures, referenced commitment (if applicable); and dollar amounts. 

(FD-34) 

• 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. (FD-36) 

• Enter recurring obligation transactions that will be automatically posted at userdefined time intervals. (FD-36B) 

• Allow multiple commitments to be combined into one obligating document and one 

commitment document to be split between multiple obligating documents. (FD-37) 

• Combine multiple funding sources on a single commitment or obligation. (FD-37B) 

• Allow authorized modifications and cancellations of posted obligating documents. (FD38) 

• Provide on-line access to all obligations by selection criteria, (e.g., document number.) 

(FD-39) 

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

• 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 return excess obligated funds to the 

appropriate budgetary account code structure. (FD-42) 

• Record and maintain contracts and grants so that fiscal year-to-date and inception-todate information can be presented. (FD-44) 

• Record blanket purchase agreements (BPAs), and record, control, and track records 

of call. (FD-45) 

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

• Record advance payments made, such as travel advances, contract advances, and 

grants. Ensure that an obligation exists prior to recording an advance. (FD-48B) 

• Record expenditures claimed against advance payments made, and automatically 

liquidate the advance either partially or fully, as appropriate. (FD-48) 

• 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). (FD-48B) 

• Provide the capability to have more than one ALC per Agency. (FD-59C) 

Value-added Requirements

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

 Maintain the following additional data fields for each obligating document: 

 Reference number 

 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 

• Discount indicator. (FD-34B) 

 Record Central Contract Registration (CCR) numbers and track activity against 

them. (New) 

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 

35 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 36

and compares data in the Funds Management function to data in other functions to ensure 

consistency. 

Mandatory Requirements

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

• Maintain current information on commitments and obligations according to the 

accounting classification structure. (FD-49) 

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

expenditures by the defined accounting classification structure and by user-defined 

criteria. (FD-53) 

• Provide control features that ensure that the amounts reflected in the fund control 

structure agree with the SGL account balances at the end of each update cycle. (FD54) 

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

transactions. (FD-55) 

• Maintain open documents to show the status of commitments, obligations, accruals, 

and disbursements by document line item. (FD-56) 

Payment Management Function 

The Payment Management function should provide appropriate control over all payments made 

by or on behalf of an agency. Agencies make payments to vendors in accordance with 

contracts; to state governments under a variety of programs; to employees for salaries and 

expense reimbursements; to other Federal agencies for reimbursable work performed; to 

individual citizens receiving Federal benefits; to recipients of Federal loans; and for many other 

reasons. 

Title 5 Part 1315 of the CFR (codification of OMB Circular 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 penalties 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 CMIA specifies requirements for payments made to 

states. Regulations implementing CMIA are at 31 CFR 205. The Debt Collection Improvement 

Act of 1996 (DCIA) provides for access to taxpayer identification numbers (TINs) and enhanced 

administrative offset and salary offset authorities. Other regulations affect 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 this situation 

exists, these other systems must meet the requirements listed here for payment management. 

Other systems may also support activities that lead up to the payment stage, such as recording 

obligations and expenditures and establishing payables, but depend on the Core financial 
system to manage the actual payment process itself. For example, a travel system 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 take over to schedule the payment for disbursement and confirm that it occurred. 

The Payment Management function consists of the following processes: 

• Payee Information Maintenance 

• Payment Warehousing 

• Payment Execution 

• Payment Confirmation and Follow-up. 

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, if the same company was also to receive payments from the agency, such as a 

loan, that information should also be available to the procurement and payment processes. 

Mandatory Requirements

To support the Payee Information Maintenance process, the Core financial system must

provide the capability to: 

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

disbursement processes, including, at a minimum: 

• Vendor name 

• Vendor ID number 

• Vendor type 

• TIN 

• Multiple payment address(es) 

• Multiple bank account and routing information 

• Multiple contact names 

• Multiple 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., cash, EFT, or check) 

• Third-party information 

• Data Universal Numbering System (DUNS) number 

• ALC number (for federal vendors) 

37 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 38

• Internal Revenue Service (IRS) -1099 indicator 

• W-2 indicator 

• Comment field 

• Date of last update 

• User ID of last update.(PM-4) 

• Support payments made to third parties (payees) that act as an agent for the payee 

(vendor). Maintain IRS -1099 information for the principal party rather than the agent. 

(PM-2) 

• Prevent the duplicate entry of vendor records, (e.g., by editing TINs, vendor ID 

numbers, or vendor names.) Provide an on-line warning message to the user when 

duplication is identified. (PM-4D) 

• Track and maintain a history of vendor file changes, including the retention of 

information with payment history. (PM-4B) 

• Query and report on payee information by user-defined criteria, such as payee name, 

payee number, and IRS -1099 reporting status. (PM-5) 

• Activate and deactivate vendors that meet user selected criteria. (PM-4C) 

Value-added Requirements

To support the Payee Information Maintenance process, the core financial system should

provide the capability to: 

• Maintain payee information that includes, at a minimum, the following elements: 

• Subject to Prompt Pay Indicator 

• Country Code 

• Payee TIN for Notice of Assignment. 

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 penalties, 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 that payments are made in accordance with contract 

terms and applicable regulations. Adequate internal controls should be in place to verify that 

goods and services paid for were actually ordered and received and are paid for only once and 

at the agreed-upon price. 

Mandatory Requirements

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

capability to: 

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

(PM-8) 

• Record "full" or "partial" receipt and/or acceptance of goods and services by line item, 

and link with the matching process. (PM-8B) 

• Automatically update the funds control and budget execution balances to reflect 

changes in the status of undelivered orders and expended appropriations, as well as 

changes in amounts. (PM-15) 

• Warehouse payments for future scheduling. 

• Allow a warehoused payment to be modified, cancelled, or put on hold. (PM-18) 

• 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 invoice). (PM-55D) 

• Process "obligate and pay" transactions where payment scheduling and obligation 

occurs simultaneously. (PM-55E) 

• Reference multiple obligations on a single invoice document. (PM-55F) 

• Set up recurring payments in the system and to automatically schedule for payment, 

(e.g. contracts, leases, etc.) (PM-55G) 

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

frequency, etc. (PM-55I) 

• Capture, store, and process invoices received in electronic format through an 

electronic commerce arrangement or from another system. (PM-24) 

• Capture, store, and process invoice information required by Title 5, Part 1315 of the 

CFR, including: 

• invoice number 

• invoice amount 

• obligating document references 

• vendor TIN 

• vendor number 

• IRS -1099 indicator 

• DUNS number 

• payee name and address 

• country code 

• payee banking information 

• discount terms 

• unit price and quantity 

• invoice amount 

• invoice date 

• invoice receipt date, and 

• description. (PM-7B) 

• Edit the TIN field to ensure that it is a 9 digit numeric field, does not include dashes, 

and is not all zeroes. Allow for override. (PM-37E) 

39 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 40

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

requirement of 1 TFM 6-5000. (PM-25) 

• Allow single invoice documents to reference multiple obligations. (PM-55F) 

• Determine the due date and amount of vendor payments in accordance with Title 5, 

Part 1315 of the CFR which states that payment is due on either: 1) the date specified 

in the contract; 2) in accordance with discount terms when discounts are offered an 

taken; 3) in accordance with Accelerated Payments Methods; or 4) 30 days after the 

start of a payment period, when a proper invoice is received. (PM-10) 

• Manually override a system-calculated payment due date. (PM-10D) 

• Split an invoice into multiple payments on the appropriate due dates when items on 

the invoice have different due dates or discount terms. (PM-11) 

• Record discount terms and automatically determine whether taking the discount is 

economically justified as defined in Volume I, section 6-8040 of the TFM. (PM-12) 

• Record additional shipping and other charges to adjust the payment amount, if they 

are authorized. (PM-13) 

• Set tolerances as a percentage or amount, between commitments and obligations, 

obligations and invoices, obligations and receipts, and receipts and invoices. 

Establish tolerances for both unit price and extended amount at the line-item level. 

(PM-14B) 

• Provide-line notification of spending transactions that exceed user-defined tolerances. 

Allow for override of the rejection of these. (PM-14C) 

• 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. (PM-21) 

• Record detailed transactions associated with credit card purchases, including 

merchant data to allow for IRS -1099 reporting. Allow users to change accounting 

information by line item for specific transactions. (PM-21B) 

• Schedule payments of advances, prepaid expenses, loans, and grants, with the 

appropriate accounting entries for each. (PM-22) 

• Establish payables and make payments on behalf of another agency, citing the other 

agency’s funding information. (PM-16) 

• Record expense or assets upon the performance that was funded by advances, 

prepaid expenses, and grants, and make the appropriate liquidations. Check available 

funds and automatically update funds control balances to reflect obligation changes. 

Ensure that total advances and disbursements do not exceed obligated amounts. 

(PM-23) 

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

unliquidated balances. (PM-25B) 

• Allow closed obligations to be reopened after final payment has been made. (PM-17) 

• Reverse disbursement transactions for voided checks or for other payments that have 

not been negotiated. (PM-20) 

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 their own disbursing authority and can print checks or make electronic 

transfers themselves. 

Mandatory Requirements

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

capability: 

• 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. (PM-28). 

• Automatically compute amounts to be disbursed, including discounts, withholdings, 

interest, or penalties, in accordance with Title 5, Part 1315 of the CFR. Generate the 

appropriate transactions to reflect the above deductions and additions. (PM-30) 

• Apply interest and discount across multiple accounting lines on an invoice. (PM-30B) 

• Apply the appropriate Treasury interest rate tables, (e.g., Prompt Pay rate, Current 

Value of Funds rate, and Late Payment Charge rate for debt collection.) Allow for 

override. (PM-30C) 

• Capture prompt payment information required by Title 5, Part 1315 of the CFR, 

including discounts taken, discounts lost, and interest penalties paid. (PM-32) 

• Automatically include relevant identification information on each payment, including 

invoice number, obligating document number, discounts, withholdings, offsets, and 

interest. (PM-31) 

• Record user comments for each voucher/invoice. (PM-55B) 

• Record reason codes for returned and adjusted invoices, lost discounts, and late 

payments. (PM-55C) 

• Identify and report payment/deposit amounts at a detail suitable for reporting large 

dollar notifications as described in I TFM, Part 6, Chapter 8500, Cash Forecasting 

Requirements. (PM-33B) 

• Include on each payment the applicable payment type and CASH TRACK line item 

code(s) used for cash management purposes. (PM-33C) 

• Generate Automated Clearing House (ACH) payments in CTX (820 or Flat File), 

CCD+, PPD, and PPD+ formats. (PM-34) 

• Ensure that employee ACH payments are generated only as PPD or PPD+ payments, 

and that vendor ACH payments are generated only as CCD+ or CTX formats. 

• Prohibit the creation of an ACH payment in any format (PPD, PPD+, CCD+, or CTX) 

that does not contain an Routing Transit Number (RTN) and an account number. (PM37G) 

• 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). Allow for separate checks to a payee. (PM-35) 

41 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 42

• Split a single payment into separate bank accounts (e.g., benefit payments.) 

• Create payment files (all formats) using different media (telecommunications, tape, 

Electronic Certification System (ECS), third-Party upload). (PM-37) 

• Provide an edit on the bank electronic routing number RTN field. The field is a ninedigit numeric-only field. Prohibit fewer or more characters, allow for only numeric 

characters, and prohibit the entry of all zeroes in this field. Edit RTN’s against the 

data supplied by in the Financial Organization Master File (FOMF) to ensure the 

validity of the check digit (Modulus 10 check). (PM-37B) 

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

(PM-37C) 

• Generate multiple payments using the same invoice number, since utility and 

telecommunications companies use an account number as a recurring invoice 

number. (PM-37D) 

• Edit the ALC field to ensure it is an eight digit numeric field. (PM-37F) 

• Create one check or ACH file regardless of payee type (employee or vendor). (PM37H) 

• Combine 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. (PM-37I) 

• 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. (PM-37J) 

• Provide the capability to schedule and disburse U.S. dollar payments (SF1166) 

through the Treasury’s ECS. ECS has a limitation of 60 payments per schedule and 

200 schedules for each ALC per day. (PM-37K) 

• 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. (PM-39) 

• Record disbursements made by another federal agency, on behalf of the agency 

using agency funds, through central electronic systems such as Intra-governmental 

Payment and Collection (IPAC) system. (PM-40) 

• Flag payment transactions that will disburse a fund into a negative cash position. 

(Reimbursable work can result in this type of transaction with appropriate authority.) 

(PM-43) 

• Process credit memoranda for returned goods or other adjustments. Apply the credit 

to the specific obligation that resulted in the credit, reducing the expense 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. (PM-19) 

• Apply credits against subsequent disbursements to the same vendor regardless of the 

funding source. (PM-27) 
• Automatically offset payments to vendors for amounts due to the agency, i.e., credit 

memos, outstanding accounts receivable, and open advances. When an entire 

payment is offset, create the appropriate notice to the vendor that the offset has been 

made. (PM-55J) 

• Allow for the exclusion of certain payments from the offset function based on userdefined criteria such as object class, vendor, vendor type, and funding source. (New) 

• 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. (PM7B) 

• Report the total amount by appropriation on each payment schedule. (PM-33) 

• Provide statistical sampling capabilities to support final payment certification. (New) 

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

prior to actual disbursement by Treasury. Allow for reversal of an entire schedule in a 

single, interactive action. (PM-42) 

Value-added Requirements

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

capability to: 

• Provide unlimited line items per invoice. (PM-44B) 

• 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. (PM-44D) 

Payment Confirmation and Follow-up Process 

This process confirms that disbursements were made as anticipated and supports inquiries from 

vendors regarding payments and reporting requirements relating to the Payment Management 

function. 

Mandatory Requirements

To support the Payment Confirmation and Follow-up process, the Core financial system must

provide the capability to: 

• Provide information about each payment to reflect the stage of the scheduling process 

that the payment has reached and the date each step was reached for the following 

processing steps: 

• Payment scheduled 

• Schedule sent to appropriate disbursing office 

• Payment issued by appropriate disbursing office. (PM-45) 

• Automatically update the payment information when confirmation is received from the 

disbursing office, including the paid schedule number, check numbers or trace 

numbers, and date, amount of payment, payment method (check or EFT). (PM-47) 

• Automatically liquidate the in-transit amount and reclassify budgetary accounts from 

43 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 44

unpaid to paid when the payment confirmation updates the system. (PM-55) 

• Accommodate the assignment by Treasury of more than one check range to a 

payment schedule, along with a break in check numbers. (New) 

• Maintain a history of every payment by the Core financial system, including 

authorizing document number, payment schedule number, payment date, invoice 

number, vendor number, vendor name, payment address, appropriation charged, and 

prompt payment information. (PM-48) 

• Maintain a history of payment calculations made by the core financial system to 

include discounts, withholdings, interest, or penalties that resulted in deductions or 

additions to the original invoice amount. (PM-48A) 

• Provide on-line access to vendor and payment information. (PM-49) 

• Provide on-line access to open documents based on agency selection criteria, 

including accounting classification structure, document number, and vendor number. 

(PM-50) 

• Produce IRS-1099s (including 1099-INT, 1099-MISC, 1099-C and 1099-G) in 

accordance with IRS regulations, such as for services only (1099-C) or for activity 

over a specified dollar amount (1099-MISC). Produce IRS -1099s in current IRS 

acceptable format, including hard copy and electronic form. (PM-51) 
Receipt Management Function 

The Receipt Management function supports activities associated with recording agency cash 

receipts, including servicing and collecting receivables. 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. Some receipts may be collected without the prior establishment of a 

receivable, as in the case of goods sold for cash. 

A receivable is recognized when the agency establishes a claim to cash or other assets against 

other entities, either based on goods or services provided or on legal provisions, such as a 

payment due date (e.g., taxes not received by the date they are due). If the exact amount is 

unknown, a reasonable estimate is made. Receivables are accounted for as assets until funds 

are collected, converted into other resources, or determined to be uncollectible in whole or in part. 

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-forservice 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 Receipt 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 Receipt Management function consists of the following processes: 

• Receivable Establishment 

• Receivable Management 

• Collections 

• Offset. 

Receivable Establishment Process 

The Receivable Establishment process supports activities to record receivables in the system 

as they are recognized and to produce bills for amounts due to the agency. 

Mandatory Requirements

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

capability to: 

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

expense reductions, or other offsets. (RM-2) 

• Support the automatic establishment and tracking of receivables to be paid under 

installment plans, including plans for which payments have been rescheduled. 

45 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 46

Provide for the generation of repayment schedules for delinquent indebtedness. (RM3) 

• Accept transactions that generate receivables from other systems in a standard 

format for entry into the Core financial system. (RM-10) 

• Support the calculation, automatic generation, and posting of (billed or unbilled) 

customer bills based upon billing source, event and/or time period, and type of claim. 

Bases used for billing may include: 

• percentage of reimbursable obligations, accrued expenditures, or costs, using 

data recorded by the cost accumulation function; 

• fee schedules for goods or services provided; 

• duplicate payments; 

• erroneous payments; and 

• payment schedules or other agreements with other entities. (RM-1) 

• Receive automated billing files from an outside source and use to create bills in the 

applicable format (EDI or non-EDI). (RM-36) 

• Uniquely identify multiple types of bills (e.g., reimbursable agreements, user fees) and 

the supporting data used to verify the specific charges, each with the appropriate data 

fields. (RM-2B) 

• Record billings and collections by line item in order to identify unique financial data 

such as accounting classification codes, claim numbers, customer order numbers, 

and descriptive information. (RM-2C) 

• Print bills, accommodating the generation of standard forms, such as SF-1080s or SF1081s, and turnaround documents to be used as a remittance advice. Allow for 

customized text in generated billing documents. (RM-4) 

• Support bills and collections between Federal agencies through the use of electronic 

systems. Provide supporting data to agencies billed which can be used to verify the 

charges. (RM-5) 

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

personnel. (RM-6) 

• Record adjustments to bills and post to customer accounts. (RM-7) 

• Date the bills with the system-generated date and/or with the date supplied by the 

user. (RM-8) 

• Generate statements to customers showing account activity. (RM-9) 

• Perform consolidated billing. (RM-46B) 

Receivable Management Process 

The Receivable Management process supports activities to maintain information (name, 

address, etc.) on entities owing the government; identify the type of customer from which 

collection is due; age receivables; make efforts to collect amounts due including related interest, 

penalties, and administrative charges; liquidate receivables; record adjustments to receivables 

including IPAC charge-backs; maintain a proper allowance for uncollectible amounts; and 

record write-offs. 

Mandatory Requirements
To support the Receivable Management process, the Core financial system must provide the 

capability to: 

• Identify the type of customer from which collection is due, including: other federal 

agency, state/local government., commercial entity, individual, and employee. (RM11) 

• Maintain detailed information by customer account (such as customer name, address, 

account balance, account number, Employee Identification Number (EIN)/TIN, date 

due, reimbursable order number, government agency) to provide audit trails and to 

support billing, reporting and research activities. (RM-11B) 

• Support the maintenance of additional customer data such as multiple addresses, 

contact names, telephone numbers, and comment fields. (RM-11C) 

• Add, modify, and delete non-financial account data. (RM-14) 

• Maintain accounts for reimbursable orders and identify government and nongovernment accounts that are designated as advance funding. (RM-12) 

• 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. The system should also support the ability to query and report on 

these items by any segment of the account code structure (e.g., fund or object class). 

(RM-33) 

• Update each account when billing documents are generated and collections are 

received. (RM-13) 

• Maintain data on individual receivables and referenced transactions supporting the 

receivable. (RM-15) 

• Automatically calculate interest, administrative and penalty charges using userdefined criteria (e.g., customer, customer type) and automatically generate a separate 

line item to reflect charges on the bill. (RM-18) 

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

accounts become delinquent, and incorporate, as appropriate, due process notices for 

referring delinquent accounts. (RM-22) 

• Customize the dunning process parameters and dunning letter text. (RM-23) 

• 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, fund, and general ledger 

account. (RM-17) 

• Identify and report receivables that meet predetermined criteria for bad debt 

provisions, write-off, or referral. (RM-19). 

• Calculate and record the allowance for loss on accounts receivable. (RM-35) 

• Provide information to allow either manual or automated reporting of delinquent 

accounts to commercial credit bureaus and referral to collection agencies or other 

appropriate governmental organizations. (RM-24) 

• Maintain data for receivables referred to other Federal agencies and/or outside 

organizations for collections. (RM-20) 

47 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 48

• Record the waiver or write-off of receivables (including interest, penalties, and 

administrative charges) with reason codes. Maintain data to monitor closed accounts. 

(RM-21) 

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

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

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

customer and receivable. (RM-16) 

• Perform on-line queries of miscellaneous cash receipts by customer and accounting 

period. (RM-16B) 

Collection Process 

The Collections process supports activities to record the receipt of funds either by currency 

(e.g., cash, electronic funds transfer) or check, and the deposit of such funds in accordance with 

Treasury and agency regulations. 

Mandatory Requirements

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

• Automatically record the application of complete and partial payments made by the 

debtor on a delinquent debt to penalties, admin fees, interest, and then to principal, 

unless otherwise stated in program statute. (RM-37) 

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

collections for which no receivable was previously established. (RM-38) 

• Post collections and reference reimbursable agreements where no billing document 

has been established. (New) 

• Process cash or credit card collections. Match collections to the appropriate 

receivables and update related bills and customer accounts. (RM-40 and RM-27) 

• Record information associated with a collection at the time of application, including the 

deposit ticket number and date, and ALC code. (RM-27B) 

• Support the receipt of collection files from lock box banks and EFT for application to 

open receivables. (RM-42) 

• Support the ability to utilize other electronic payment and collection systems such as 

IPAC. (RM-46) 

• Record collections received against outstanding advances. (New) 

• Apply collections to more than one receivable. (RM-28) 

• Identify and report those receivables that have been reduced by some means other 

than cash collections, such as waivers or write-offs. (RM-30) 

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

receivable has been recorded. (RM-34) 

• Automatically reconcile, on a periodic basis (e.g. monthly), recorded deposits and 

debit vouchers with confirmation information provided by the Disbursing Center 

(Treasury) or the banking system. (RM-39) 

Value-added Requirements
To support the Collections process, the Core financial system should provide the capability to: 

• Interface with CASHLINK, in order to reconcile Treasury recorded collections to the 

collections recorded in the core financial system and generate exception reports. 

CASHLINK is a Treasury System used to manage and monitor the collection of 

government revenues and report the balances to Federal Agencies. 

Offset Process 

This requirement will ensure that TINs of Federal payment recipients are available to facilitate debt 

collection by offset of Federal payments under the DCIA, and for vendor income reporting to the 

Internal Revenue Service (IRS) as mandated. 

Mandatory Requirements

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

• Capture TIN data for the debtor in order to report overdue receivables for potential 

offset. (RM-43) 

• Generate the automated files required by Government offset programs. Support the 

receipt of collection files from offset programs for application to open receivables. 

(RM-44) 

• Record and report on the date and nature of a change in the status of an accounts 

receivable, including the following: 

• Held, 

• Reinstated, 

• Judgment received, 

• Appealed, 

• Waived/unwaived, 

• Referred for government. offset, 

• Referred to collection agency, 

• Referred to Department of Justice (DOJ), 

• Offset, 

• Suspended, 

• Compromised, 

• Written-off. (RM-44B) 

Cost Management Function 

The Cost Management function of the Core Financial System attempts to measure the full cost 

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. 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 4 standards are: 

49 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 50

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

(appropriation only, appropriation with reimbursable authority, revolving fund). For example, in 

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 

• Cost Recognition 

• Cost Distribution 

• Working Capital and Revolving Fund 

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 

or item whose cost is to be measured, such as, organizational units, programs, projects, 

targeted outputs, specific contracts, specific customers, work orders, 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. 

Mandatory Requirements

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

the capability to: 

 Use the agency’s accounting classification structure 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, targeted outputs, specific 

contracts, specific customers, work orders, etc. (CM-3) 

 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. (CM-7C) 

 Identify all costs incurred by the agency in support of activities of revolving funds, trust 

funds, or commercial functions, including the applicable portions of the related salaries 

and expense accounts identified with those activities. (CM-6) 

 Accumulate non-financial data relating to cost objects such as output units to allow the 

calculation of both total and unit costs. (CM-4B) 

 Transfer (and trace) cost data directly to and from other cost systems/applications that 

produce allocation information. (CM-7B) 

 Calculate prices, fees, and user charges for reimbursable agreements and other 

purposes using full cost, consistent with the guidance of OMB Circular A-25 (User 

Charges). (CM-5) 

Cost Recognition Process 

Recognition of the effects of transactions in financial systems is fundamental to the accounting 

process. Recognition determines when the results of an event are to be included in financial 

statements and ensures that the effects of similar events and transactions are accounted for 

consistently within the Federal government. 

Mandatory Requirements

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

to: 

• Use the accrual basis of accounting when recognizing costs and revenue. Recognize 

costs in the period of time when the events occurred regardless of when ordered, 

received or paid for. Recognize revenue when earned. (CM-1) 

• 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. (CM-2) 

• Identify and record costs incurred by each cost object, including input on costs from 

feeder systems, such as inventory, travel, property management (depreciation), or 

payroll. (CM-9) 

• 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. (CM-10) 

• Perform multi-layer overhead distributions that are user-defined (at least 3 levels of 

distribution) using multiple rates, fixed amount and other appropriate allocation 

methods. (CM-11) 

Cost Distribution Process 

51 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 52

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 provide the capability 

to: 

• Accumulate and distribute information on costs and revenue associated with cost 

objects. (CM-8B) 

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

adjustments based on actual costs. (CM-12) 

• Distribute costs to other cost objects regardless of how they were originally assigned. 

(CM-13) 

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

(CM-14) 

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 specific 

charters that focus on specific purposes. Such charters have the potential to make program 

management much more flexible by lifting apportionment controls while adding operational 

safeguards. If an agency uses revolving funds, the core system must be able to track service 

level agreements, verify funds availability, bill customers, and measure costs. 

Mandatory Requirements

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

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

• Create and track the funding associated with cost objects (e.g. contracts, work-orders, 

projects, reimbursable agreements) and provide funding status on FY-to-date and 

project inception-to-date bases. (CM-16) 

• Support the aggregation of project funding status to a higher lever, such as from work 

order level to customer level. (new CM-17) 

• Verify funds availability for orders placed against a specific contract, work-order or 

agreement for a particular customer of the revolving fund operation. (CM-18) 

• Support funding of revolving fund contracts, work-orders, and projects through the use of 

advances, prepayments or reimbursements. (CM-19) 

• Reconcile information in revolving fund customer and contract/workorder/project/reimbursable agreement status reports with bills and statements generated 

for customers by the receivables processes. (CM-23) 
Reporting Function 

The Core financial system must be able to provide timely and useful financial information to 

support: (1) management’s fiduciary role; (2) budget formulation and execution functions; (3) 

fiscal management of program delivery and program decision making; and (4) internal and 

external reporting requirements, including, as necessary, 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. 

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, 

extract data files, and hard-copy reports. These requirements could be satisfied by (1) 

application software that is part of the Core financial system, (2) generalized reporting/inquiry 

software that works with a variety of applications, or (3) 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 easily accessible and 

understandable to personnel with varying levels of technical knowledge of systems and financial 

data. Personnel with relatively limited knowledge of the system or of financial accounting 

concepts and principles should 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. 

Financial Reporting Process 

The Core financial system must provide complete, reliable, consistent, timely and useful 

financial management information on operations to enable 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. The Core 

financial system must be designed to support agency budget, accounting, and financial 

management reporting processes by providing consistent information for budget formulation, 

budget execution, programmatic and financial management, performance measurement and 

financial statement preparation. 

Mandatory Requirements

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

capability to: 

• Produce internal or external reports or data transmissions from data that can be 

traced directly to SGL accounts and attributes. (R-11) 

• Produce, at a minimum, the following standard internal reports: 

• Summary and detailed trial balances 

• Summary and detailed trial balances with attributes 

• Transaction register with attributes. (SGL-9) 

• Produce an on-line current status of funds report down to the lowest level of the 

accounting classification structure, including such data as: 

53 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 54

• annual budget (including revisions): 

• outstanding or total appropriations 

• apportionments 

• allotments, and 

• allowances; 

• open commitments; 

• open obligations; 

• net payments/liquidated obligations; and 

• balance available. (R-20) 

• Provide data in the hard copy and electronic formats required by central agencies, 

including the SF-133, SF-224, SF-1219, SF-1220, FMS-2108, FACTS I and FACTS II.

(R-14) 

• To ensure the accuracy of data transmitted for FACTS I and FACTS II reporting, 

perform the validation edits specified by Treasury. (CF-43B) 

• Report financial activity by any element within the accounting classification structure 

(e.g., individual or hierarchical organization code, project code). (R-15) 

• Provide information for the managerial cost accounting decision-making process, the 

management of the agency, and external reporting. For each cost object, identify and 

accumulate data to support: 

 Schedules and operating statements for audit, and for financial statement 

preparation (including the Statement of Net Cost) 

 Cost and revenue reports to be utilized in the analysis of programmatic activities 

 Program and unit cost information needed to support program, financial and 

financial management performance measures as required by GPRA 

 Comparison with other program data to determine compliance with planned or 

budgeted activities. (CM-7) 

• Generate accounting statements by revolving fund customer and/or contract/workorder/project at month-end to include financial statements, revenue and funding 

status reports, cost reports and other reports with data sufficient to justify fees 

charged. (CM-22) 

• Prepare and distribute agency-specific formatted reports. (R-17) 

Value-added Requirements

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

capability to: 

 Automate the preparation of consolidated financial statements as required by the 

current OMB Bulletin on Form and Content of Agency Financial Statements. (R-13) 

 Report on aged unliquidated requisitions by organization and line item. (R-27B) 

 Report on aged outstanding obligating documents by entry date and expected 

receipt date. (R-27C) 

 Report on aged receiving reports without an acceptance. (R-27D) 
 Report on aged, unmatched vendor invoices. (R-27E) 

 Track and report on spending agency-wide by state and congressional district. (R27F) 

Technical Requirements 

Technical requirements have been established to help assure that a Core financial system (1) is 

capable of meeting a wide variety of workload processing demands, (2) provides transaction 

processing integrity and general operating reliability, (3) is easy to install, configure and operate 

and (4) does not conflict with other administrative/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 requirements listed in the following subcategories are 

mandatory: 

 

 General Design/Architecture 

 Interoperability 

 Security 

 Operations and Computing Performance 

 Year 2000 Compliance 

The following subcategories include requirements that are value-added: 

 Infrastructure 

 User Interfaces 

 Workflow/Messaging 

 Document Management 

 Internet Access 

 Data Import/Reconciliation 

The following subcategory is unique in that it is comprised of both mandatory and value-added 

requirements: 

 Ad Hoc Query 

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. 

55 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 56

General Design/Architecture 

This category includes technical requirements relating to an application’s design, internal data 

management, and general ease of use. 

Mandatory Requirements 

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

 Be modular in design and upgradeable to accommodate regular changes in laws, 

regulations, best practices and new technology. (TA-1) 

 Base application configuration management on commercially available product 

versions and standard releases. (TA-2) 

 Incorporate a standard relational database product into the application design. 

Financial data maintained in this database must be accessible through an SQLcompliant API. (TA-3) 

 The application design must include internal transaction processing controls, 

including the capability in the event of a system failure to automatically: 

 back out incompletely processed (in-flight) transactions, 

 restore the system to its last consistent state before the crash (e.g., database 

checkpoint), and 

 re-apply all incomplete transactions previously posted by the user community. 

(TA-4)

 Ensure internal database consistency during update operations, including distributed 

databases, if applicable. (TA-5) 

 Control access and updates to the same record by concurrent users. (TA-6) 

 Support cascading record updates and deletions. (TA-7) 

 Be designed to simultaneously process on-line transactions and transactions 

submitted via system interface. (TA-8) 

 Have fully documented restart capabilities for the application on-line and batch 

processing components. Batch jobs must be segmented to facilitate their recovery in 

the event of a system failure. (TA-9) 

 Include vendor provided services for complete installation, operating and system 

maintenance documentation covering: 

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

 Include revised documentation provided by the vendor concurrent with the 

distribution of new software releases. (TA-11) 

 Employ common error-handling routines across functional modules and present error 

messages that allow the user or system operator to respond to reported problems. 

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

 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. (TA-13) 

 Be capable of generating output using computer screen displays; to data file for 

FACTS I, FACTS II, and Treasury payment schedules; and hardcopy reports. Where 

not otherwise specified by a functional requirement, requested information must be 

viewable using the application’s on-line user interface. Where the term report is 

used, the application must be capable of generating a formatted, hardcopy report 

containing the specified information. Other special output requirements are specified 

by the technical requirements addressing Interoperability and Ad Hoc Query. (TA-14) 

Interoperability 

Financial transactions can be originated using external, feeder applications. Typically, these 

feeders are considered legacy systems and are based on older computing technologies. 

Mandatory Requirements 

To ensure that data can move effectively between the core financial system and other financial 

applications operated by the agency, the core system must: 

 Include an application program interface (API) to accept accounting activity 

generated by external applications (e.g., accounting feeders, EDI gateways, program 

area mixed systems, travel, payroll). This interface must support the following 

functional transaction groups: 

 Core Accounting 

 Budget 

 Payables 

 Receivables 

 Fixed Asset 

 Accounting Classification Structure Tables 

 Vendor Table Maintenance (TD-1) 

 Process API submitted transactions using the same program logic, table entries and 

business rules as are used by the application in editing transactions submitted online (e.g., via user interface). The core system must maintain the erroneous 

transactions until either corrected and posted or deleted. (TD-2) 

 Provide internal controls with the API (e.g., control totals, record counts) to ensure 

the integrity of received and processed transactions. (TD-3) 

57 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 58

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

 For the API, include the ability to automatically re-process suspended transactions. 

(TD-5) 

Security 

This technical category defines internal and external access controls. A qualified core financial 

system must be designed to protect an agency’s financial data from unauthorized access or 

alteration. Adequate data protection includes the following discrete requirements: 

Mandatory Requirements 

To meet JFMIP Security requirements, the core system must: 

 Have integrated security features that are configurable by the system administrator 

to control access to the application, functional modules, transactions, and data. (TS1) 

 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. (TS-2) 

 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 at least the most recent 3 passwords. (TS-3) 

 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. (TS-4) 

 Permit the system administrator to assign multiple levels of approval to a single, 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. (TS-5) 

 Allow the system administrator to restrict access to sensitive data elements data 

such as social security numbers and banking information by named user, groups of 

users or functional role. (TS-6) 

 Maintain an audit logging capability to record access activity including: 

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

 Provide the ability to query the audit log by type of access, event date time stamp 

range, user identification, or terminal id. (TS-8) 
Operations and Computing Performance 

Technical computing performance requirements define batch transaction loads; concurrent 

users and agency determined processing time constraints. Specific workload requirements will 

come from an agency. 

Mandatory Requirements 

To meet JFMIP Operations and Computing Performance requirements, the core system must: 

 Include vendor provided computing performance metrics, for platforms and systems 

environments that the application is certified to run. Performance metrics provided by 

the vendor must describe: 

 transaction processing throughput capacity, 

 expected workstation client response time by transaction type, 

 data storage capacity, and limitations in concurrent user connectivity. (TX-1) 

 Provide the ability to complete routine batch processing (e.g., backups, nightly 

interface processing, core GL posting, table updates, standard reporting, and 

systems assurance) within an agency’s specified batch processing window. (TX-2) 

 Be capable of storing, updating and retrieving the agencies financial data (e.g. 

vendors records, transactions, documents, lines and subsidiary ledger records) with 

no degradation to on-line or batch processing performance. (TX-3) 

 Support concurrent access by the agency's user community with no negative impact 

on standard response time. (TX-4) 

 Be designed to include a flexible scheduling capability to enable the operator to 

initiate, monitor and stop scheduled processing (e.g., on-line availability, batch jobs 

and system maintenance). (TX-5) 

 Provide online status messages indicating when requested processing starts, 

completes and system errors. (TX-6) 

 Include automated system assurance routines (e.g., data integrity verification 

reports) that can be regularly run and used to detect systemic posting problems. (TX7)

 Allow reports to be produced in the background while other system processing takes 

place. (TX-8) 

 Provide the capability to process batched transactions during online hours and 

accept online transactions from interfacing systems with no on-line performance 

degradation. (TX-9) 

 Provide the system administrator the ability to determine whether records are to be 

archived or purged. The system must include the capability to establish and maintain 

user-defined archival criteria, such as date, accounting period, closed items, vendors 

inactive for a specific time period. The system must allow selective action on those 

documents that meet the criteria. (TX-10) 

 Retain system records in accordance with Federal regulations established by the 

National Archives and Records Administration (NARA), GAO, and others. (TX-11) 

59 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 60

 Provide the ability to selectively retrieve archived records. (TX-12) 

 Maintain and report on productivity statistics about application usage. (TX-13) 

 Provide audit trails to identify changes made to system parameters and tables that 

would affect the processing or reprocessing of any financial transactions. (TX-14) 

 

Year 2000 Compliance 

Year 2000 compliance requirements ensure that the core system is not impacted by date based 

calculations. 

Mandatory Requirements

To be year 2000 compliant the core financial system must:

 Be warranted for fault-free performance in the processing of date and date-related 

data (including, but not limited to calculating, comparing, and sequencing) by all 

hardware and software products delivered under this contract, individually and in 

combination, upon installation. (TY-1) 

 Include fault-free performance during the manipulation of any data with dates prior 

to, through, and beyond January 1, 2000 and shall be transparent to the user. (TY-2) 

 Successfully transition to the year 2000 with the correct system date, without human 

intervention, including leap year calculations. (TY-3) 

 Provide correct results when moving forward and backward in time across the year 

2000. (TY-4) 

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. 

Value-added Requirements

To meet JFMIP infrastructure related requirements, the core financial system should: 

 Operate in a centralized mainframe environment (e.g., MVS, OS/390) or in a 

distributed computing environment running under UNIX or NT (Windows Server 

2000). (TB-1) 

 Operate on TCP/IP network to support application, database and workstation 

connectivity. (TB-2) 

 Support application client operation on a 32-bit, Microsoft Windows compatible 

operating system. (TB-3) 

 Support EDI translation compliant with ANSI X-12 standards and Federal 

implementation conventions to enable electronic data exchanges with designated 

trading partners such as a bank credit card service provider, major supplier or 

customer. (TB-4) 

 Support automated touch-tone telephone access for standardized, commonly 

requested, inquiries (such as payment status). (TB-5) 

 Support automated fax-back access for standardized, commonly requested, 
documents (such as account statements). (TB-6) 

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

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. 

Value-added Requirements

To meet JFMIP infrastructure related requirements, the core financial system should: 

 The application should provide a consistent Windows-based, graphical user interface 

(GUI) across all modules and integrated subsystems. Interface consistency includes 

the use of common command syntax, dialog window styles, data entry structures and 

information presentation (both hard-copy and on-line). Desired GUI characteristics 

include mouse activated: 

 Icons, 

 Buttons, 

 Scroll bars, 

 Drop-down lists, 

 Check boxes, 

 Menu bars, 

 Text boxes, 

 Tool tips, 

 Resizable windows, 

 Cut, copy, and paste functions. (TC-1) 

 The application interface should incorporate features designed to reduce the amount 

of direct keying required to initiate processing. Data entry efficiency features include 

the use of default values, look-up tables and automatic data recall. Other desirable 

features include: 

 The use of single function windows (e.g., one input screen per transaction), 

 The ability to pass common data from screen to screen, 

 Highlighting of required fields, 

 The use auto tabs, 

 The use of function keys (e.g., retrieve previous data, invoke help facility, 

suspend transaction, clear screen, etc.), 

 Disabling of non-supported function keys, 

 A 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 

61 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 62

 The ability to select records from a list by scrolling or by typing in only part 

of an entry. (TC-2) 

 The application interface should support desktop integration with other common 

workstation applications. (TC-3)

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

Value-added Requirements

To meet JFMIP workflow and messaging related requirements, the core financial system 

should:

 The application should 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 based on user-defined and 

modifiable business rules via a graphical definition facility. (TE-1) 

 The application should provide a graphical facility to enable authorized users to 

define workflow processes and business rules, including approval levels and to 

modify workflow (e.g. assign a proxy approving authority). (TE-2) 

 The application should 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-3) 

 The application should 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-4) 

 The application should provide the ability to track the approval event, including the 

time/date and approving party. (TE-5) 

 The application should provide the capability to automatically generate electronic 

routing and status messages to individuals or groups. (TE-6) 

 The application should provide an interface to the agency electronic mail system, or 

groupware application to distribute application generated documents and messages 

electronically (i.e., to intranet/Internet connected users). (TE-7) 

 The application should provide on-line query capability and customizable queries to 

track the status of transactions through the workflow process. (TE-8) 

 The application should provide capability to support Workflow Management Coalition 

(WFMC). (TE-9) 

 The application should provide capability to support Messaging API-Workflow (MAPIWF). (TE-10) 

 The application should provide capability to support Vendor Independent Messaging 

(VIM). (TE-11)
Document Management 

Document management includes technical requirements that define how the Core system is to 

store and retrieve electronically formatted documents. 

Value-added Requirements

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

 Provide the capability to support Document Management Alliance (DMA). (TF-1) 

 Provide the capability to support Open Document Management Architecture 

(ODMA). (TF-2) 

 Provide the capability to support Open Document Architecture/Open Document 

Interface Format (ODA/ODIF). (TF-3) 

 Provide the capability to support Portable Document Format (PDF). (TF-4) 

 Provide the capability to support Standard Generalized Markup Language (SGML). 

(TF-5) 

 Provide the capability to support imaging of hard-copy document reference material 

(e.g., signed contracts, purchase orders and vendor invoices). (TF-6) 

 Provide the capability to notify the user of the presence of an associated electronic 

file and allow an on-screen display. (TF-7)

Internet Access 

Technical requirements relating to internet access represent a specialized infrastructure subset. 

These requirements generally define user connectivity options. 

Value-added Requirements

To meet JFMIP all connectivity options document management related requirements, the core 

financial system should:

 Support secure web browser access to work queues, review status of documents, 

approve documents, and enter transactions such as commitments, obligations, 

disbursements, and receiving reports. (TN-1) 

 Support secure web-browser access to its integrated ad hoc data query facility. (TN2) 

 Provide the capability to accept vendor invoices and other external originated 

transactions over the Internet using XML. (TN-3) 

 Provide the capability to receive public payment collections via the Internet (e.g., 

Web-based collection of reimbursable activity using credit cards. (TN-4) 

 Support the use of standard Public Key Infrastructure (PKI) technology to control 

access to sensitive data over the Internet. (TN-5) 

63 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 64

Data Import/Reconciliation 

Federal agencies are required to reconcile financial data maintained in their core system with 

fund data maintained by U.S. Treasury. To facilitate this reconciliation process, Treasury makes 

their fund balance data available to electronic format. Agencies need a facility that can "import" 

this information and automatically report discrepancies. This technical requirements sub-section 

defines requirements for specific reconciliation scenarios suggested by Federal agencies that 

need to be addressed. 

Value-added Requirements

To meet JFMIP Data Import/Reconciliation related requirements, the core financial system 

should:

 Provide the ability to import Treasury Master Appropriation File (MAF) data, including 

Treasury fund balances at the TAFS and Record Type 7 level for automatic 

comparison against FACTS data generated by the Agency. (TM-1) 

 Perform automatic monthly cash reconciliation with Treasury (e.g., 6653) and provide 

detail data on of balance items. (TM-2) 

Ad Hoc Query 

Ad hoc query requirements define how a Core financial system supports retrieval of financial 

data for analytical purposes. 

Mandatory Requirements

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

 Provide a data query facility that will enable ad hoc access to financial information 

and analytical/reporting tools. Utilization of this facility must not impact normal on-line 

and batch processing system performance. (TG-1) 

 Include a user interface that allows users to create/edit parameter-based query 

scripts and to submit them for immediate execution and/or store them in a common 

library for future use. (TG-2) 

 Allow users to run selected queries automatically in batch mode and to stage the 

“report” output for later access by agency users. (TG-4) 

 Include on-line tools to help optimize query scripts and identify potential resourceintensive submissions ands provide run-time controls to limit "run-away" queries and 

large data download requests. (TG-5) 

 Support simultaneous access to multiple data sources using standard query 

language (SQL) or a functionally similar query mechanism. (TG-6) 

 Support output display on the desktop. The facility must also support dynamic report 

reformatting, regrouping and drill-down to detail records from summary report lines. 

(TG-7) 

 Allow authorized users to download selected financial data to their PC desktop. This 

download capability must be able to automatically reformat downloaded information 

for direct access by common desktop applications (e.g., ASCII formatted). (TG-8) 
 Provide the ability to preview a report, form or other query result before printing. (TG9) 

 Support access to current and historical financial information (i.e., prior-year data). 

(TG-10) 

 Provide the ability to perform document cross-referencing in which a user can query 

on any document and receive information on associated documents 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). (TG-11) 

Value-Added Requirements 

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

 Include a graphical display of data sources and allow users to point and click on 

selectable table, data, and link objects for inclusion in a custom query. (TG-12) 

 Include an active data dictionary to provide users with object definitions. (TG-13) 

 Allow users to transmit copies of report/query results electronically via e-mail to 

multiple pre-identified individuals. (TG-14) 

65 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 66

Appendix A: References 

Applicable references can be found on the JFMIP Knowledgebase website at 

http://www.JFMIP.gov. 
Appendix B: Glossary 

This section prescribes certain terms that have been used throughout this document. The 

source of each definition is identified in parentheses following the definition; the terms are all 

found in one of the following sources: 

• OMB Circular A-34, “Instructions on Budget Execution”; referred to as A-34. 

• OMB Circular A-11 “Preparation and Submission of Budget Estimates”; referred to as 

A-11. 

• Treasury Financial Manual; referred to as TFM. 

• U.S. Government Standard General Ledger; referred to as SGL. 

• Commonly used terms within the Federal sector; referred to as Common Term. 

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

Term) 

Activity 

Agency-defined financial summary accumulator. 

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. (A-34, Part 11, Section 21.1, 

p. 11-2) 

Agency location code (ALC)

Code assigned by Treasury to each reporting unit requiring the preparation of an SF-224, 

Statement of Transactions. The first two digits of the symbol identify the department or agency, 

the third and fourth digits identify the particular bureau within that department, and the 

remaining four digits identify the lowest level of reporting required for the particular agency 

accounting station within that bureau (e.g., Letter of Credit, Trust Funds, all other, etc.). The 

ALC must be shown on all correspondence, forms, and other documentation forwarded to 

financial institutions, FMS, other Federal agencies, and to Treasury Regional Financial Centers, 

and particularly on all SF-215s: Deposit Tickets, and/or related SF-5515s: Debit Vouchers. (I 

TFM 2-3320.10) 

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. (A34, Part 11, Section 21.1, p. 11-1) 

• Category A Apportionments are apportionments that are made on a quarterly basis. 

• Category B Apportionments are apportionments made on a basis other than a 

67 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 68

quarterly basis. 

• Category C Not subject to apportionment.. 

• Category D Apportionments made on the basis of reimbursements for goods or 

services provided. 

Appropriations

One of the basic forms of budget authority. Statutory authority that allows Federal agencies to 

incur obligations and to make payments out of the Treasury for specified purposes. An 

appropriation act is the most common means of providing budget authority, but in some cases 

the authorizing legislation itself provides the budget authority. (A-34, Part 11, Section 21.1 

(Budget authority), p. 11-3) 

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. (A-34, 

Part 11, Section 21.1 (Budget authority), p. 11-3) 

Budget authority

Authority provided by law, including joint resolutions making continuing appropriations (also 

known as continuing resolutions), and becoming available during the year to incur obligations. 

 The basic forms of budget authority are appropriations, authority to borrow, and contract 

authority. (A-34, Part 11, Section 21.1, p. 11-3) 

Commitment

The amount of allotment or lower level authority committed in anticipation of an obligation. 

(SGL, definition of account 4700) 

Contract authority

One of the basic forms of budget authority. Statutory authority under which contracts or other 

obligations may be entered into prior to an appropriation for the payment of such obligations. 

 The later enacted appropriation provides cash to liquidate such obligations. (A-34, Part 11, 

Section 21.1 (Budget authority), p. 11-3) 

Cost Center

An identifiable department or area within a recipient’s organization that has been assigned an 

account number in the recipients accounting system for the purpose of accounting costs. 

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. (Common Term) 

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). (SGL, 

definition of accounts 4901, expended authority - unpaid, and 4902, expended authority - paid) 

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. (SGL, definition of 

6000 series) 

Federal Agencies Centralized Trial-Balance System (FACTS) 

System used by agencies to electronically transmit a pre-closing adjusted trial balance(s) (ATB) 

at the Treasury appropriation/fund group level 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. 

Fund account

(See Appropriation or fund account) 

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 Online Accounting Link System. The electronic network which 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. (Common Term) 

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. (I TFM 4-3020) 

Information Stores

Logical grouping or categories of data. 

Limitation

A funding restriction, imposed by OMB, a department, or an agency, that places a ceiling for 

obligational/spending authority. The limitation may exist at any level within a funding structure 

or may be imposed using an independent structure. (Common Term) 

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. OMB Circular A-11 provides current object classifications for reporting 

budget estimates to OMB. Many agencies have defined lower levels of object classification for 

internal use. (A-11, Sec 35.1) 

Obligation

69 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 70

Obligations are amounts of orders placed, contracts awarded, services received, and similar 

transactions for bona fide needs existing during a given period that will require payments during 

the same or a future period and that comply with applicable laws and regulations. Such 

amounts will include outlays for which obligations had not been previously recorded and will 

reflect adjustments for differences between obligations previously recorded and actual outlays to 

liquidate those obligations. (A-34, Sec. 21.1, p.11-7) 

Organization structure

The offices, divisions, branches, etc. established within an entity based on responsibility 

assignments, whether functional or program related. (Common Term) 

Outlay

The measure of government spending for budget purposes. Payments to liquidate obligations 

(other than the repayment of debt). Except where outlay figures are labeled as gross, they are 

stated net of any related refunds and offsetting collections. Outlays generally are equal to cash 

disbursements, but they are also 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. (A-11, Section 14.1, p. 35) (Note that, although not technically correct, the terms 

‘expenditures’ and “net disbursements’ are sometimes used interchangeably with ‘outlays’.) 

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 

passbacks, Congressional markup tables, or internal agency decisions. (SGL p. IV-1) 

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. 

(SGL p. IV-7) 

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. (Common Term) 

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 Federal Financial Management Improvement Act (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. 

Standard General Ledger at the transaction level 

Implementing the SGL at the transaction level requires that the core financial system general 

ledger management function is in full compliance with the SGL chart of accounts descriptions 

and posting rules; transactions from feeder systems are summarized and fed into the core 

financial system’s general ledger following SGL requirements through an interface (automated 

or manual); detail supporting the interface transactions can be traced back to the source 

transactions in the feeder systems; and the feeder systems process transactions consistent with 

SGL account descriptions and posting. 

System Integration 

The ability for the user to have one view into the system and can get to the information needed 

efficiently and effectively through electronic means. 

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. 

Treasury appropriation fund symbol

A summary account established in the Treasury for each appropriation and/or 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 A34, this phrase refers to general fund expenditure accounts, special fund expenditure accounts, 

public enterprise revolving funds, intra-governmental revolving funds, management funds, trust 

fund expenditure accounts, and trust revolving fund accounts. (A-34, Part 11, Section 21.1, p. 

11-4 and 5) 

Unified systems 

Systems that are planned for and managed to work together using common data elements, 

operated in an integrated fashion, and linked together electronically in an efficient and effective 

manner to provide agency-wide financial system necessary to carry out the agency’s mission 

and support the agency’s financial management needs. 

71 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 72

Appendix C: Summary of External Reporting Requirements 

 

 

 Title Form Purpose Level Basis Frequency Guidelines

Program and 

Financing 

Schedule 

(actual data 

columns) 

Prior-year 

data 

Supporting 

information for 

agency budget 

submissions 

to OMB 

Appropriation/ 

Fund Account

Cash Annually OMB Cir.A-11 

SGL 

Crosswalk 

Federal 

Agencies; 

Centralized 

Trial Balance 

System 

(FACTS I) 

Electronic 

Reporting 

replacement 

of 

SF-220 

SF-220-1 

SF-221 

SF-222 

and SF-223 

Report data 

for 

consolidation 

from FACTS 

into the U.S. 

Government 

Consolidated 

Financial 

Statement 

Appropriation/ 

Fund Group 

Accrual Quarterly/ 

Annually 

1 TFM 2-4000

Federal 

Agencies; 

Centralized 

Trial- Balance 

System 

(FACTS II) 

Electronic 

Reporting 

replacement 

of SF-133 and 

TFS-2108 

Report data 

for 

consolidation 

from FACTS II 

into the U.S. 

Government 

Consolidated 

Financial 

Statement 

Appropriation/ 

Fund Group 

Accrual Quarterly/ 

Annually 

TFM 

Transmittal 

Letter S2-01-

01 

Report on 

Guaranteed 

Loans 

SF-220-8 Provides 

information for 

monitoring 

status of 

guaranteed 

loans 

Appropriation/ 

Fund Account 

but can vary 

Accrual Quarterly/ 

Annually 

TFM Bulletin 

92-04 Bulk 

Transfer 

User’s Guide 

Report on 

Receivables 

Due from the 

Public 

Replaces SF220-9 Provides 

information on 

the status of 

public 

receivables 

and 

delinquencies

Appropriation/ 

Fund Account 

but can vary 

Accrual Quarterly/ 

Annually 

Bulk Transfer 

Instructional 

Workbook 

(March 1994) 

Statement of 

Transactions 

SF-224 Reports 

disbursements

, collections, 

and status of 

collections 

Agency 

location code 

by 

Appropriation/ 

Fund Account

Cash Monthly 1 TFM-3300 

Bulk Transfer 

user’s Guide 

Report of 

Accountability 

SF-1219 Provides an 

analysis of 

disbursing 

officers’ 

activities in 

agencies 

Agency 

location code 

and 

Disbursing 

Officer 

Cash Monthly 1 TFM 3100 
 Title Form Purpose Level Basis Frequency Guidelines

which do not 

do their own 

disbursing 

Statement of 

Transactions 

SF-1220 Reports 

disbursements 

and 

collections in 

agencies 

which do their 

own 

disbursing 

 (the 

counterpart to 

SF-224) 

Agency 

Location code 

and 

Appropriation 

Fund Account

Cash Monthly 1 TFM 3100 

Information 

Returns 

1099-MISC, 

1099-G, etc. 

Provide 

information to 

the Internal 

Revenue 

Service on 

payments 

made or debts 

forgiven 

Taxpayer 

Identification 

number 

Cash Annually IRS 

instructions for 

forms 1099, 

1098, 5498, 

and W-2G 

Balance Sheet N/A Disclose 

statement of 

assets, 

liabilities, and 

net position 

Trust and 

revolving 

funds, 

accounts 

substantially 

commercial 

Obligation/Acc

rual 

Annually OMB’s Bulletin 

on Form and 

Content 

Statement of 

Net Cost 

N/A Reports gross 

costs less 

revenue 

earned 

Trust and 

revolving 

funds, 

accounts 

substantially 

commercial 

Accrual Annually OMB’s Bulletin 

on Form and 

Content 

Statement of 

Changes in 

Net Position 

N/A Reports 

financing 

sources, gains 

and losses 

Trust and 

revolving 

funds, 

accounts 

substantially 

commercial 

Accrual Annually OMB’s Bulletin 

on Form and 

Content 

Statement of 

Budgetary 

Resources 

N/A Available 

budgetary 

resources and 

status 

Trust and 

revolving 

funds, 

accounts 

substantially 

commercial 

Obligation/ 

Accrual 

Annually OMB’s Bulletin 

on Form and 

Content 

Statement of 

Financing 

N/A Report on 

reconciliation 

between 

proprietary 

and budgetary 

accounts 

Trust and 

revolving 

funds, 

accounts 

substantially 

commercial 

Accrual Annually OMB’s Bulletin 

on Form and 

Content 

73 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 74

 Title Form Purpose Level Basis Frequency Guidelines

Statement of 

Custodial 

Activity 

N/A Report of nonexchange 

revenue 

Trust and 

revolving 

funds, 

accounts 

substantially 

commercial 

Accrual Annually OMB’s Bulletin 

on Form and 

Content 
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, Executive Director, JFMIP 

Stephen Balsam 

Steven Fisher 

Dennis Mitchell 

Core Financial System Requirements Project Team

Corporation for National Service

Wynn Cooper 

Department of Commerce

Patricia Jackson 

Department of Defense

Gerald Thomas 

Environmental Protection Agency

Martin Poch 

Department of Energy

Warren Huffer 

Ike Smith 

General Accounting Office

Chris Martin 

Janett Smith 

Sally Thompson 

General Services Administration

William Topolewski 

75 Core Financial System Requirements – Exposure Draft
Core Financial System Requirements – Exposure Draft 76

Health and Human Services

Norbert Juelich 

Teresa Wright 

Margie Yanchuk 

Housing and Urban Development

Rhea Riso 

Department of Interior

R. Schuyler Lesher, Deputy Chief Financial , Chair, Financial Systems Committee, 

 Chief Financial Officers’ Council 

Department of Justice

Robert Karas 

Department of Labor

Patricia Clark 

Lee Jones 

NASA

Mela Jo Kubacki 

Office of Management and Budget

Neil Lobron 

Jerry Williams 

Office of Personnel Management

Robert Loring 

Maurice Duckett 

Railroad Retirement Board

Kenneth Boehne 

Social Security Administration

Tom Bianco 

Department of State

Lauretta Pridgen 

Department of the Treasury

Richard Aaronson 

David Epstein 

Carolyn Dockett-Butler 

Betty Harvey-Tauber 

Jeff Hoge 
Department of Veterans Affairs

Jesse Symlar 

CFO Fellows Participant

David Cauthon, Office of Personnel Management 

Executive Leadership Program Participants 

Dotty Willey, Federal Deposit Insurance Corporation 

Logistics Management Institute

James Atherton 

Kathy Crampton 

Frank Duesing 

Steven Mead 

Catherine Nelson 

Ronald Rhodes 

Susan Smith 

Duane Whitt 

77 Core Financial System Requirements – Exposure Draft