Federal Financial 

Management 

System 

Requirements

OFFM-NO-0106

January 2006
Abbreviations 

x 

Core Financial System Requirements 
Foreword 

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

document first issued by JFMIP in January 1988. Changes made to this version reflect recent 

changes in laws, regulations, and central agency reporting systems, such as the Department of 

Treasury's new Governmentwide Accounting (GWA) program. It also incorporates updates to 

existing requirements. In many cases: 

• Existing requirement text has been clarified 

• Redundant or outdated requirements have been deleted 

• Requirement priorities (mandatory or value added) have been updated 

• New requirements have been added to reflect current business practices. 

This document is a part of the Federal Financial Management Systems Requirements document 

series. FFMSR addresses the joint goals of the Chief Financial Officers Council and the Office 

of Management and Budget to improve the efficiency and quality of financial management in the 

Federal Government. The FFMSR document series also supports key provisions of the: 

• Chief Financial Officers Act (CFO Act) of 1990 

• Government Performance and Results Act (GPRA) of 1993. 

• Government Management Reform Act (GMRA) of 1994 

• Federal Financial Management Improvement Act (FFMIA) of 1996. 

Collectively, these acts mandate the use of financial systems to facilitate the effective 

management of Government programs and services and the proper stewardship of public 

resources. 

This update demonstrates a strong commitment by the Federal CFO community to continually 

improve the quality of financial services. The CFO community's support in developing these 

requirements was invaluable. We thank the CFO Council's Financial System Integration 

Committee and the many agency representatives that participated in improving this document. 

'\ 

/,J ""t,/'J 

i/-·?i~c~:~l?? 1'/ /-'7 

(··'/·Dr. linda M. Combs 

Controller 

Office of Management and Budget 

in the Executive Office of the President 

2005 Core Financial System Requirements 
Abbreviations 

x 

Core Financial System Requirements 
Core Financial System Requirements iii

Contents 

Abbreviations ..............................................................................................vii 

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

Federal Financial Management Framework.................................................2 

FFMSR MODEL ........................................................................................................... 2 

FRAMEWORK GOALS .................................................................................................... 3 

Requirements Interpretation Guidelines.......................................................4 

MANDATORY VERSUS VALUE-ADDED REQUIREMENTS ..................................................... 4 

INTERNAL CONTROL REQUIREMENTS ............................................................................. 5 

QUERY VERSUS REPORT REQUIREMENTS ...................................................................... 5 

REQUIREMENTS APPLICABILITY...................................................................................... 6 

Core Financial System Overview.................................................................8 

CORE SYSTEM FUNCTIONS ........................................................................................... 8 

CORE FINANCIAL SYSTEM FUNCTIONAL REQUIREMENTS SUMMARY.................................. 9 

System Management Function ..................................................................11 

ACCOUNTING CLASSIFICATION PROCESS...................................................................... 11 

DOCUMENT AND TRANSACTION CONTROL PROCESS ..................................................... 13 

DOCUMENT REFERENCING AND MODIFICATION PROCESS .............................................. 17 

SYSTEM-GENERATED TRANSACTIONS PROCESS........................................................... 20 

AUDIT TRAILS PROCESS ............................................................................................. 22 

General Ledger Management Function .....................................................24 

GENERAL LEDGER ACCOUNT DEFINITION PROCESS ...................................................... 24 

TRANSACTION DEFINITION PROCESS............................................................................ 25 

GENERAL LEDGER UPDATING AND EDITING PROCESS ................................................... 26 

UPWARD/DOWNWARD SPENDING ADJUSTMENT PROCESS ............................................. 27 

GENERAL LEDGER ANALYSIS AND RECONCILIATION PROCESS ....................................... 28 
Contents 

Core Financial System Requirements iv

ACCOUNTING PERIOD MAINTENANCE AND CLOSING PROCESS ....................................... 29 

FINANCIAL REPORTING PROCESS ................................................................................ 30 

Budgetary Resource Management Function..............................................34 

BUDGET PLANNING PROCESS...................................................................................... 34 

BUDGET PREPARATION PROCESS................................................................................ 35 

BUDGET AUTHORITY PROCESS.................................................................................... 37 

FUNDS DISTRIBUTION PROCESS .................................................................................. 38 

FUNDS CONTROL PROCESS ........................................................................................ 40 

FUNDS STATUS PROCESS ........................................................................................... 43 

Payment Management Function ................................................................46 

PAYEE INFORMATION MAINTENANCE PROCESS............................................................. 46 

ACCOUNTS PAYABLE PROCESS ................................................................................... 49 

INVOICING PROCESS................................................................................................... 50 

DISBURSING PROCESS ............................................................................................... 53 

PAYMENT FOLLOW-UP PROCESS................................................................................. 59 

Receivable Management Function.............................................................62 

CUSTOMER INFORMATION MAINTENANCE PROCESS ...................................................... 63 

RECEIVABLES AND BILLING PROCESS........................................................................... 64 

DEBT MANAGEMENT PROCESS.................................................................................... 67 

COLLECTIONS AND OFFSETS PROCESS ........................................................................ 70 

Cost Management Function.......................................................................73 

COST SETUP AND ACCUMULATION PROCESS................................................................ 73 

COST DISTRIBUTION PROCESS.................................................................................... 74 

COST REPORTING PROCESS ....................................................................................... 75 

Fund Balance with Treasury Management Function..................................76 

TREASURY INFORMATION MAINTENANCE PROCESS ....................................................... 76 

PAYMENT CONFIRMATION PROCESS ............................................................................ 77 

RECONCILIATION AND REPORTING PROCESS ................................................................ 78 
Contents 

Core Financial System Requirements v

Technical System Requirements ...............................................................82 

GENERAL DESIGN/ARCHITECTURE............................................................................... 82 

INFRASTRUCTURE....................................................................................................... 83 

USER INTERFACES ..................................................................................................... 84 

INTEROPERABILITY ..................................................................................................... 85 

WORKFLOW/MESSAGING ............................................................................................ 86 

DOCUMENT MANAGEMENT .......................................................................................... 87 

INTERNET ACCESS ..................................................................................................... 88 

SECURITY.................................................................................................................. 88 

OPERATIONS.............................................................................................................. 90 

AD HOC QUERY ......................................................................................................... 91 

DOCUMENTATION ....................................................................................................... 93 

SYSTEM PERFORMANCE ............................................................................................. 94 

Appendix A—References 

Appendix B—Requirement Drafting Guidelines 

Appendix C—Standard Core Financial System Reports 

Appendix D—Contributors 

Figures 

Figure 1: FFMSR Components .................................................................................. 2 

Figure 2: System Functions ....................................................................................... 8 

Figure 3: Technical Requirement Groupings ............................................................. 9 
Contents 

Core Financial System Requirements vi
vii 

Core Financial System Requirements 

Abbreviations 

ACC Accounting Classification Code 

ACE Accounting Classification Element 

ACH Automated Clearing House 

ACR Agency Confirmation Report 

ALC Agency Location Code 

ANSI American National Standards Institute 

API Application Program Interface 

ATB Adjusted Trial Balance 

BEA Budget Enforcement Act of 1990 

BETC Business Event Type Code 

BPA Blanket Purchase Agreement 

CCD Cash Concentration or Disbursement 

CCD+ Cash Concentration or Disbursement Plus Addendum 

CCR Central Contractor Registration 

CFO Chief Financial Officer 

CFOC Chief Financial Officers Council 

CFR Code of Federal Regulations 

CMIA Cash Management Improvement Act 

COTR Contracting Office(r) Technical Representative 

COTS Commercial Off-the-Shelf 

CTX Corporate Trade Exchange 

CVF Current Value of Funds 

DBA Doing Business As 

DCIA Debt Collection Improvement Act of 1996 

DMA Document Management Alliance 

DO Disbursing Office(r) 

DOJ Department of Justice 

DT/DV Deposit Ticket/Deposit Voucher 

DUNS Data Universal Numbering System 

ECS Electronic Certification System 

EDI Electronic Data Interchange 

EFT Electronic Funds Transfer 

FACTS I Federal Agencies Centralized Trial Balance System I 

FACTS II Federal Agencies Centralized Trial Balance System II 

FAR Federal Acquisition Regulation 

FASAB Federal Accounting Standards Advisory Board 

FAST Federal Account Symbols and Titles 

FBWT Fund Balance with Treasury 

FFMIA Federal Financial Management Improvement Act of 1996 

FFMSR Federal Financial Management System Requirements 

FMFIA Federal Managers’ Financial Integrity Act of 1982 

FMS Department of the Treasury Financial Management Service 
Abbreviations 

viii 

Core Financial System Requirements 

FOB Free On Board 

FSB Financial Systems Branch 

FSC Federal Supply Classification 

FTE Full-Time Equivalent 

GAO General Accountability Office 

GMRA Government Management Reform Act of 1994 

GOALS Government Online Accounting Link System 

GPRA Government Performance and Results Act of 1993 

GFRS Governmentwide Financial Report System 

GSA General Services Administration 

GWA Governmentwide Accounting 

IAE Integrated Acquisition Environment 

IAS Information Access System (GOALS II) 

IDD International Direct Deposit 

IGTE Intra-governmental Transaction Exchange 

IPAC Intra-governmental Payment and Collection System 

IRS Internal Revenue Service 

IT Information Technology 

MAPI-WF Messaging API-Workflow 

MIME Multipurpose Internet Mail Extensions 

MTS Metric Tracking System 

MVS Multiple Virtual System 

NACHA National Automated Clearing House Association 

NAICS North American Industry Classification System 

NARA National Archives and Records Administration 

NIST National Institute of Standards and Technology 

ODA/ODIF Open Document Architecture/Open Document Interface Format 

ODMA Open Document Management Architecture 

OFFM Office of Federal Financial Management 

OMB Office of Management and Budget 

OPAC Online Payment and Collection System 

OS Operating System 

PDF Portable Document Format 

PKI Private Key Infrastructure 

PPD Prearranged Payment and Deposit 

PPD+ Prearranged Payment and Deposit Plus Addendum 

RFC Regional Finance Center 

PSC Product Service Code 

RTN Routing Transit Number 

SAM Shared Accounting Module 

SCS Secure Payment System 

SFFAS Statements of Federal Financial Accounting Standards 

SGML Standard Generalized Markup Language 

SIC Standard Industrial Classifications 

SQL Structured Query Language 
Abbreviations 

ix 

Core Financial System Requirements 

SPS Secure Payment System 

TAFS Treasury Appropriation Fund Symbol 

TAS Treasury Account Symbol 

TCP/IP Transmission Control Protocol/Internet Protocol 

TDO Treasury Disbursing Office 

TFM Treasury Financial Manual 

TIN Taxpayer Identification Number 

TROR Treasury Report on Receivables 

U.S.C. United States Code 

U.S. SGL U.S. Standard General Ledger 

VIM Vendor Independent Messaging 

VPN Virtual Private Network 

WFMC Workflow Management Coalition 

XML Extensible Markup Language 
Abbreviations 

x 

Core Financial System Requirements 
 

Core Financial System Requirements 1 

Introduction 

This document is part of a series of publications entitled Federal Financial Management System 

Requirements (FFMSR). FFMSR specifies the mandatory functional and technical requirements 

that agency financial management systems must meet in order to be considered compliant with 

Federal standards as mandated by the Federal Financial Management Improvement Act (FFMIA). 

OMB Circular A-127, Financial Management Systems, sets forth general policies for Federal 

financial management systems. Each agency is required to establish and maintain a single 

integrated financial management system. Each agency must have an ongoing financial systems 

improvement planning process and perform periodic reviews of its financial system capabilities. In 

addition, each agency must maintain financial management system components that comply with 

uniform Federal accounting concepts and standards promulgated by the Federal Accounting 

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

(SFFAS), which constitute generally accepted accounting principles for the Federal Government. 

A complete list of laws, regulations and governmentwide standards that are addressed by specific 

requirements can be found in Appendix A, References. 

Establishing governmentwide system requirements promotes a common understanding among 

private- and public-sector financial managers and agency program managers regarding Core 

system functional and technical capabilities. Such requirements serve as a tool for the oversight 

agencies to evaluate systems. They help justify agency system improvements or replacements. 

They also help organize the private-sector market by communicating mandatory functionality that 

commercial software must provide to Federal agencies and identifying value-added features 

desired by Federal agencies. 

The next section of this document sets forth the framework for the establishment and 

maintenance of an integrated Federal financial management system. The specific Core financial 

system requirements are presented in detail in the functional and technical requirements sections 

that follow. These requirements, which are reviewed and updated periodically, incorporate the 

latest changes in laws and regulations governing Federal financial systems, such as the Intragovernmental Payment and Collection System (IPAC) and Central Contractor Registration (CCR). 

Appendices provide references, a glossary, a summary of external reporting requirements, 

requirements drafting guidelines and a list of agencies that participated in updating this document. 
 

Core Financial System Requirements 2 

Federal Financial Management Framework 

The Framework for Federal Financial Management Systems document describes the basic 

elements of a model for integrating financial management systems in the Federal Government. 

It provides a foundation for all systems included in the FFMSR. The Framework was 

republished in April 2004. This updated document description does the following: 

• Explains how Federal financial management supports Federal agencies and the mission 

of government as an inherent component of the delivery of all Federal programs 

• Sets forth financial management performance goals, outcomes, and desired capabilities 

and characteristics that future systems must be designed to meet 

• Describes financial management functions, information flows, and systems that support 

the Federal agencies in carrying out programs 

• Describes the agency and central agency roles 

• Links financial management to program performance and describes how it supports 

budget and performance integration 

• Presents the business needs, performance goals, and information architecture that drive 

financial system requirements. 

FFMSR Model 

The current model comprises the Framework, Core, Managerial Cost Accounting, and 13 

subsidiary financial or mixed systems. Such systems must be able to provide consistent, 

standardized information for program managers, financial managers, agency executives, and 

oversight organizations, and they must meet Federal statutes, regulations, and standards. 

Figure 1 provides an architectural view of the current financial management applications 

described by the FFMSR series. The system functions and technical requirement groupings that 

constitute the Core application are reflected later in Figures 2 and 3. 

Figure 1: FFMSR Components
Federal Financial Management Framework 

Core Financial System Requirements 3

Framework Goals 

The following financial management system performance goals, outlined in the Framework 

document, are applicable to all financial management systems. All financial management 

systems must deliver the following: 

• Demonstrate compliance with accounting standards and requirements 

• Provide timely, reliable, and complete financial management information for decision 

making at all levels of government 

• Meet downstream information and reporting requirements with transaction processing 

data linked to transaction engines 

• Accept standard information integration and electronic data to and from other internal, 

governmentwide, or private-sector processing environments 

• Provide for “one-time” data entry and reuse of transaction data to support downstream 

integration, interfacing, or business and reporting requirements 

• Build security, internal controls, and accountability into processes and provide an audit 

trail 

• Be modular in design and built with reusability as an objective 

• Meet the needs for greater transparency and ready sharing of information 

• Scale to meet internal and external operational, reporting, and information requirements 

for both small and large entities. 
 

Core Financial System Requirements 4 

Requirements Interpretation Guidelines 

This document contains a list of functional capabilities (i.e., established governmentwide 

requirements) that a qualified system must deliver to be considered qualified for agency 

acquisition. This document does not address accounting policy or procedures. The following are 

examples of system capabilities covered by this document: 

• Produce an SF 133 report 

• Process a receiving report 

• Generate a FACTS II data file. 

The requirements in this document represent a complete list of functional capabilities deemed 

mandatory for qualified financial management systems by the government. These requirements 

should not be considered to be a complete system specification. They do not, for example, 

specify computing logic needed to summarize SF 133 reported information, to edit receiving 

data, or to classify GL data for FACTS reporting purposes 

Covered requirements are organized by function, process, and, in some cases, an activity. 

Functions represent major office responsibility areas such as accounts payable. Processes are 

common system-supported tasks such as disbursing. Activities are sub processes; and are 

used when a finer grouping of requirements is helpful. 

In all cases, the system is responsible for performing specified actions. Unless otherwise stated 

within a requirement’s text, the system must execute it automatically. For example, if a 

requirement states “process an obligation,” the system is expected to capture obligation data 

and to record related GL transactions without user intervention. 

The remainder of this section provides guidance on how to interpret requirements text and 

attributes. Specific guidance is provided for the following requirement categories: 

• Mandatory versus value-added requirements 

• Internal control requirements 

• Query versus report requirements. 

Other key words that affect how agencies are to interpret requirements text are defined in 

Appendix B, Requirement Drafting Guidelines. 

Mandatory versus Value-Added Requirements 

Every requirement contained in this document has been prioritized as being mandatory or value 

added. These terms are defined as follows: 

• Mandatory. Mandatory requirements describe discrete capabilities that a fully compliant 

financial system must deliver. Collectively, mandatory requirements represent the 

minimum level of functionality needed to establish a financial system based on Federal 

laws, regulations, and governmentwide consensus. Mandatory requirements apply to 

existing systems and new systems that are planned for acquisition or are under 
Requirements Interpretation Guidelines 

Core Financial System Requirements 5

development. Commercial packages are tested for compliance with mandatory 

requirements. Agency heads can use mandatory requirements as a basis for 

determining substantial compliance of their systems under FFMIA. 

• Value-added. Value-added requirements are desirable system features. Value-added 

requirements may consist of any combination of the following: use state-of-the-art 

technology, employ preferred or best business practices, or meet the special 

management needs of an individual agency. Agencies should consider value-added 

features when judging system options. The need for these value-added features is left to 

the discretion of each agency head. 

Within this document, mandatory system requirements are indicated by the word “must”—for 

example, a qualified system “must provide automated functionality to update all general ledger 

account balances based on a single input transaction”. Value-added requirements are indicated 

by the key word “should”—for example, a system “should provide automated functionality to 

import budget formulation data”. 

Internal Control Requirements 

OMB Circular A-123, Management’s Responsibility for Internal Controls, requires agencies to 

operate systems with appropriate internal controls to ensure the accuracy of data, completeness 

and consistency of transaction processing, and reporting. Automatic internal control capabilities 

needed to meet the provisions of A-123 are expected to be integrated into every qualified 

financial management system. 

The Core requirements that specify validations be performed on invoice data before they can be 

certified and system enforced separation of duties are examples. In addition, the technical 

requirements found in this document incorporate a full range of data and user access security 

controls. Ultimately, however, each agency is responsible for implementing the internal controls 

they need to ensure that their financial systems are operated in a secure and effective manner. 

Query versus Report Requirements 

Qualified systems must maintain complete, reliable, consistent, timely, and useful financial 

management information. Such information enables agency management, programs, 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 government 

services. Methods of delivering financial information to agency users include queries and 

reports. 

• Query. When a functional requirement refers to a “query,” the Core system must be 

capable of displaying the requested information online. In addition, query features, such 

as drill-down or desktop downloading must be delivered where specified. As a rule, 

query requirements must be met using software that is integrated into the Core system. 

• Report. When a functional requirement refers to a “report,” the application must be 

capable of generating a formatted, hard-copy report or printable report file containing 

specified information. Additional reporting formats such as online display or data file 

extracts must be delivered where specified. As a rule, reporting requirements can be 

met using software that is integrated into the Core system, using a separate reporting 

software package, or a combination of both. 
Requirements Interpretation Guidelines 

Core Financial System Requirements 6

All queries and reports specified in this document are considered “standard” and must be 

delivered as part of the qualified Core system product. A summary of all standard external 

reports can be found in Appendix C. 

Requirements Applicability 

FFMIA requires agencies to install integrated financial systems that substantially comply with 

the following: 

• Government-established system requirements 

• Accounting standards 

• U.S. Government Standard General Ledger (U.S. SGL) at the transaction level. 

OMB Circular A-127, Financial Management Systems, further defines government-established 

system requirements to include the items published in this document. A separate OMB 

memorandum, FFMIA Implementation Guidance, reinforces this mandate. This guidance, 

however, exempts agencies from meeting individual system requirements relating to business 

processes they do not perform. For example, an agency that does not issue grants does not 

need to meet grant-related system requirements. Although FFMIA compliance is subject to 

audit, the final determination of the applicability of any cited requirement rests with agency 

management. 

OMB Circular A-130, Management of Federal Information Resources, requires agencies 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. In the case of financial management systems, 

Circular A-127 limits agencies to the acquisition of COTS products that have been certified 

through a formal test process. To accomplish testing, A-127 assigns the Chief Financial Officers 

Council (CFOC) responsibility for doing the following: 

• Developing/administering the certification test 

• Notifying the General Services Administration (GSA) when a package successfully 

completes a test 

• Providing interested parties with information on Core requirements and related testing 

scenarios. 

COTS packages are periodically tested against the mandatory system requirements specified in 

this document. Through this test process, packages demonstrate their ability to comply with all 

mandatory requirements as interpreted by the Financial System Integration Office (FSIO). 

Packages that pass the test are deemed qualified for Federal agency acquisition. 

Agencies, however, have considerable leeway in how they elect to use tested capabilities. For 

example, the funds distribution process area includes a requirement that packages be capable 

of recording spending at levels below where funding was distributed. Although this is a 

mandatory requirement for vendor software, an agency is not required to control spending in 

this manner. 
Requirements Interpretation Guidelines 

Core Financial System Requirements 7

Packages are also not expected to support illegal or inappropriate application of individual 

requirements. For example, the requirement to synchronize vendor data with data maintained in 

the Central Contractor Registry (CCR) does not apply to a payee exempt from CCR registration. 

In practice, the applicability of individual requirement provisions depends on business 

circumstances.
Core Financial System Requirements 

Core Financial System Requirements 8 

Core Financial System Overview 

Federal agencies disburse over $2 trillion in appropriated funds annually. Financial and program 

managers throughout government are fiscally responsible for these resources and for the 

program results they achieve. To do their jobs, they need ready access to detailed financial 

information essential to formulating agency budgets, monitoring program operations, and 

reporting performance as maintained in a proper and reliable financial system. Such systems 

support the following management objectives: 

• Accountability, by providing accurate information needed to inform taxpayers, Congress, 

and agency personnel in terms they can readily understand, on how the Nation’s tax 

dollars are spent, and how Federal assets are protected 

• Efficiency, economy, and effectiveness, by supporting delivery of efficient, economical, 

and effective delivery of services to the Federal agency’s internal and external 

customers (e.g., individuals, contractors, partnerships, state and local governments, 

other Federal agencies/organizations, the military, and foreign governments) 

• Decision making, by providing Congress, agency heads, and program managers with 

timely reports linking financial results and program data so that policy and program 

decisions can be accurately identified, tracked, and forecasted. 

Furthermore, Core financial systems, whether they are being implemented or are currently in 

use, must operate in accordance with laws, regulations, and judicial decisions. This document 

establishes a set of comprehensive functional requirements for a proper and reliable Core 

financial management system. 

Core System Functions 

Core financial systems provide specific functional capabilities necessary for managing a general 

ledger, controlling spending, making payments, managing receivables, measuring costs, 

reconciling the agency’s Fund Balance with Treasury, and reporting in the Federal environment. 

Figure 2 depicts the major functions within the Core financial system. 

Figure 2: System Functions 
Core Financial System Requirements 

Core Financial System Requirements 9

In practice, a single financial event can require processing in multiple system areas. A good 

example is a payment that includes additional charges not previously recorded, such as interest 

costs due to late payment or additional shipping charges. This transaction would (1) originate in 

the Payment Management function; (2) be edited for funds availability and update balances in 

the Budgetary Resource Management function; (3) possibly update cost amounts controlled by 

the Cost Management function; (4) update the general ledger balances in the specified General 

Ledger Management function; and (5) update audit trails used in the System Management 

function. 

In addition, technical requirements have been established to help ensure that a Core financial 

system is fully supported and capable of processing the workload required. From a technical 

perspective, the Core system must provide transaction processing integrity and general 

operating reliability; use standard procedures for installation, configuration, and operations; 

provide seamless integrated workflow processing; have the ability to query, access, and format 

information; and be well documented. It must not conflict with other administrative or program 

systems or with other agency-established IT standards. Figure 3 depicts the major technical 

groups within the Core financial system. 

Figure 3: Technical Requirement Groupings 

Most technical requirements are stated in general terms to give vendors maximum flexibility in 

designing compliant financial systems. Individual agencies are encouraged to add specific 

interoperability, system performance, workload, and access requirements unique to their 

respective IT environments when evaluating packages for acquisition. 

Core Financial System Functional Requirements Summary 

The following sections identify specific requirements that every qualified Core financial system 

must deliver. These requirements provide the basic information and control needed by agencies 

to perform 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. 
Core Financial System Requirements 

Core Financial System Requirements 10

The major functions supported by a Core financial system and the abbreviations used in this 

document to identify related requirements are as follows: 

• System Management (SM) 

• General Ledger Management (GL) 

• Budgetary Resource Management (FM) 

• Payment Management (PM) 

• Receivable Management (RM) 

• Cost Management (CM) 

• Fund Balance with Treasury Management (FB). 

The ID assigned to each requirement defines its function, process, and sequence. For example, 

the first requirement in the first process associated within the System Management function is 

identified by SMA-01. “SM” stands for System Management, “A” represents the first defined 

process under system management (in this case, “accounting classification”), and “01” is a 

unique sequence number.
Core Financial System Requirements 11 

System Management Function 

The System Management function ensures that the capabilities exist to capture, classify, 

process, and report the financial activity of Federal agencies. The System Management function 

establishes the framework for sharing data among components of an agency’s single integrated 

financial management system. This function also ensures that transactions are processed 

consistently and completely and that appropriate audit trails are maintained. The System 

Management function consists of the following processes (the prefixes assigned to the 

requirements are noted in parentheses): 

• Accounting Classification (SMA) 

• Document and Transaction Control (SMB) 

• Document Referencing and Modification (SMC) 

• System-Generated Transactions (SMD) 

• Audit Trails (SME) 

Accounting Classification Process 

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. SGL, provides for tracking of specific program expenditures, and covers financially related 

information. 

The accounting classification process provides the means for categorizing financial information 

along several dimensions to support financial management and reporting functions. The data 

elements that a particular agency includes in its accounting classification will depend on data 

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

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

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

be standardized to ensure uniform and efficient accounting treatment, classification, and 

reporting. The Accounting Classification Management process provides a consistent basis for 

the following activities: 

• Capturing financial activity with all of the data necessary to identify the funding used, the 

organization charged, the type of expense or asset affected, and the program or project 

involved 

• Recording data at the lowest level of detail and summarizing or rolling it up to higher 

levels in a standardized manner for reporting purposes 

• Comparing and combining similar programs across agencies and calculating overall 

program results 

• Integrating budget and accounting activities by synchronizing their accounting 

classifications and relationships. 
System Management Function 

Core Financial System Requirements 12

Mandatory Requirements 

To support the Accounting Classification Management process, the Core financial system must

provide automated functionality to do the following: 

SMA-01 Accounting classification—Maintain an accounting classification structure that 

includes the following elements: 

• Treasury Account Symbol 

• Budget fiscal year 

• Internal fund code 

• Organization 

• Program 

• Project 

• Activity 

• Cost center 

• Object class 

• Revenue source 

• Budget function 

• Budget sub-function code 

• Accounting period. 

Maintain each classification element independently. For example, budget fiscal 

year must be maintained as a separate value from the period of availability 

component in the TAFS. 

SMA-02 Additional accounting classifications—Define five additional accounting 

classifications elements, including element titles and valid values. 

SMA-03 Classify transactions—Classify transactions by standard and agency-defined 

accounting classification elements. 

SMA-04 Short classification codes—Derive full accounting classifications on 

transactions from abbreviated user input. Examples of methods include: 

entering shorthand codes, deriving elements from an entered field, or providing 

users with a list of values from which to choose. 

SMA-05 Accounting classification tables—Add, change, or deactivate elements of the 

accounting classification structure and define valid ACE values without 

programming changes (e.g., through online table updates). 

SMA-06 Accounting classification effective date—Capture an effective date for 

accounting classification structure and valid value changes. Activate or 

deactivate accounting classification changes based on effective date. 

SMA-07 Accounting activity query—Query document accounting data. Parameters 

include all standard and agency-defined accounting classification elements. 

Result is a list of selected document accounting lines. Display the document 

number, accounting classification elements and accounting line amounts. Drill 

down from accounting lines to GL transaction details, including transaction 

numbers, transaction and system dates and debits and credits. 
System Management Function 

Core Financial System Requirements 13

SMA-08 Revenue source code structure—Maintain a revenue source code structure to 

classify types of revenue and receipts as defined by the agency, such as rental 

income, sales by product type and income by type of service performed. 

SMA-09 Treasury Account Symbol—Maintain a TAS structure that includes the 

following components defined by Treasury and OMB: 

• Subclass 

• Agency code 

• Hyphen (when co-owner is not null) 

• Transfer agency 

• Fiscal year (period of availability) 

• Main account number 

• Sub-account symbol. 

SMA-10 Accounting classification structure levels—Define additional (lower) levels in 

the fund, program, project, organization and object class structures (e.g. 

establish parent child relationships with the ability to summarize, distribute 

funds, and report data at all defined levels). 

SMA-11 ACE associations—Maintain an accounting classification structure that can 

associate each element with multiple other elements and element values, 

including: 

• TAS to multiple internal funds 

• Internal fund to multiple organizations, programs, projects, and 

activities 

• Organization to multiple programs, projects and activities 

• Project code to multiple organizations, programs and activities 

• Program to multiple organizations, projects and activities. 

SMA-12 Object class code structure—Maintain an object class structure consistent 

with the standard object class codes defined in OMB Circular A-11. 

Accommodate additional (lower) levels in the object class structure, e.g., by 

establishing parent child relationships. 

SMA-13 Pre-configured BOC codes—Deliver the Core financial system software 

populated with the 3-digit Budget Object Classification codes specified in OMB 

Circular No. A-11. 

Value-Added Requirements 

 There are no value-added requirements for this process. 

Document and Transaction Control Process 

The Document and Transaction Control process defines the rules for recording, editing, and 

processing transactions that are entered directly to the Core financial system. In addition to 

recording these transactions, the Core financial system must be able to record and process 

transactions originating in other systems. All transactions must be handled consistently, 

regardless of their point of origin. The Core financial system must ensure that transactions are 

controlled properly to provide reasonable assurance that the funds are available, tolerances 

between documents are not exceeded, and other transaction processing edits are met. Core 

financial systems edit for the presence of data elements required on all system documents or on 
System Management Function 

Core Financial System Requirements 14

specific document types (e.g., spending documents). The Document and Transaction Control 

process defines these required data elements and validations. 

Mandatory Requirements 

To support the Document and Transaction Control process, the Core financial system must

provide automated functionality to do the following: 

SMB-01 Document number—Capture a unique system-generated or agency-assigned 

document number for each document and document modification. 

SMB-02 Transaction number—Capture a unique system-generated number to identify 

each general ledger transaction. Associate one or more general ledger 

transactions with a document and document modifications. 

SMB-03 Referenced documents—Associate referenced documents in the processing 

chain, such as when an obligation document references one or more prior 

commitment documents. 

SMB-04 Source document number—Capture a reimbursable agreement number and 

one other agency-assigned source document number in separate fields on all 

spending documents. The agency-assigned source document number may be a 

purchase requisition number, contract number and associated delivery /task 

order number, purchase order number, blanket purchase agreement number 

and associated call number, grant number, travel order number, etc. 

SMB-05 Document number source—Define document numbering as systemgenerated or agency-assigned by document type. 

SMB-06 Duplicate documents—Validate that duplicate documents are not recorded, 

e.g., by editing document numbers or storing additional information that make 

the document number unique (as in date stamp on a utility bill). 

SMB-07 Source system—Capture the source system and the source system document 

number of each interfaced document. 

SMB-08 Period of performance—Capture goods delivery and service performance 

period start and end dates on documents where the period of performance is a 

validation for future processing, e.g., 

• Contracts 

• Blanket purchase agreements 

• Reimbursable agreements 

• Travel orders 

• Grants. 

SMB-09 Reimbursable agreement terms and conditions—Capture the following data 

elements when establishing reimbursable agreements: 

• Reimbursable agreement number 

• Reimbursable agreement amount 

• Billing limit 
System Management Function 

Core Financial System Requirements 15

• Billing terms 

• Accounting classification information 

• Source (federal, other non-federal entities, or public). 

SMB-10 Funds control and tolerance levels—Define the level of fund control edits and 

tolerance checks as one of the following: 

• Rejection 

• Warning (override authority needed to post transaction) 

• Information only (no override needed). 

SMB-11 Reject documents—Prevent the recording of erroneous transactions by 

rejecting documents that fail transaction processing edits. 

SMB-12 Failed edit notification—Notify the user when online documents fail funds 

control edits, transaction processing edits, or tolerance checks. Provide the 

notification on the document entry screen, and include the nature of each error 

and the validation level (rejection, warning or information only). Retain errors 

with the document until they have been resolved. 

SMB-13 Suspended documents—Suspend documents that fail transaction processing 

edits, funds control edits, or tolerance checks. 

SMB-14 Hold documents—Allow users to hold documents for completion or processing 

at a later date. Segregate held from suspended documents. 

SMB-15 Process suspended documents—Process “suspended” documents when 

external referenced data that caused the system to suspend processing of a 

document is corrected, such as when a vendor's CCR status changes from 

expired to active. 

SMB-16 Failed edit corrections—Allow users to select suspended and held documents 

for continued processing. 

SMB-17 Cancel posted documents—Allow users to cancel (permanently close) posted 

documents. 

SMB-18 Delete unposted documents—Allow users to delete held or suspended 

documents. 

SMB-19 Over tolerances—Define tolerances by percentage, "not-to-exceed" dollar 

amounts, or "not-to-exceed" quantities at the document line level, and use them 

to control overages by document line for the following relationships: 

• Obligations to commitments 

• Receipts to obligations 

• Invoices to obligations 

SMB-20 Over Tolerances by obligation type—Define over tolerances for all obligations 

or by obligation type. 
System Management Function 

Core Financial System Requirements 16

SMB-21 Accounting line item detail—Capture the following accounting line item detail 

on all documents: 

• Line item number 

• Line item amount 

• Line item accounting classification information. 

SMB-22 Define acquisition information—Define the valid values for the following 

acquisition information: 

• NAICS business codes 

• SIC codes 

• Product and service codes 

• FOB shipping points 

• Ship to locations (destination codes).

SMB-23 Validate acquisition information—Validate that valid values for the following 

acquisition information are captured on spending documents: 

• NAICS business codes 

• SIC codes 

• Product service codes 

• FOB shipping points 

 • Ship to locations (destination codes). 

SMB-24 Document line item detail on obligation documents—Capture the following 

document line item information on spending documents: 

• Quantity 

• Unit of measure 

• Unit Price 

• Extended Price 

• Description 

• Product service codes 

 • FOB shipping points 

 • Ship to locations (destination codes). 

SMB-25 Line items to document total—Validate that the sum of all document line 

items is equal to the document total. 

SMB-26 Default transaction date—Derive the default transaction date from the current 

system date. 

SMB-27 Default accounting period—Derive the default accounting period from the 

transaction date. Prevent user override. 

SMB-28 Override transaction date—Capture an agency-specified transaction date (i.e., 

allow the agency to override the default transaction date with a date in any open 

accounting period). 

SMB-29 Transaction date of subsequent activity—Record subsequent activity against 

a document with the transaction date of that activity, e.g., the payment voucher, 

not the transaction date of the original document, e.g., the referenced obligation. 
System Management Function 

Core Financial System Requirements 17

SMB-30 Validate ACE—Validate transaction accounting classification elements. Prevent 

the recording of transactions with missing, invalid or inactive classification 

elements or values. 

SMB-31 Validate FACTS attributes—Validate transaction-associated FACTS attributes. 

Prevent the recording of transactions with missing, invalid or inactive FACTS 

attributes. 

SMB-32 Record type 7 validation—Validate transactions that would post to U.S. SGL 

accounts (e.g., borrowing authority, contract authority, or investments) to ensure 

that the associated fund code is designated as having the appropriate RT7 

code. 

SMB-33 Transaction dates—Capture the following dates on all transactions: 

• Transaction date - The date a transaction is effective in the general 

ledger (i.e., the date a financial event is recognized). 

• System date - The actual date a transaction is processed by the 

system. This date is assigned by the computer and may not be 

modified. 

Value-Added Requirements 

To add value to the Document and Transaction Control process, the Core financial system 

should provide automated functionality to do the following: 

SMB-34 Foreign currency transactions—Record transactions in both foreign currency 

and U.S. dollars in all Core system modules. 

SMB-35 Under tolerances—Define tolerances by percentage, dollar amount or quantity 

for final payments that are less than the referenced obligation document line 

amounts, and use them to control erroneous de-obligations of the funds. 

SMB-36 Under Tolerances by obligation type—Define under tolerances for all 

obligations or by obligation type. 

Document Referencing and Modification Process 

In the typical Federal spending chain, a purchase moves from the reservation (commitment) of 

funds, to the execution of an obligating document (e.g., contract or purchase order), to the 

acknowledgment of goods or services received and accepted goods, and finally to payment of 

the expense or asset. The Document Referencing and Modification process defines the 

relationships that must be maintained between these document types, the types of document 

amendments that must be accommodated by the Core financial system, and the related 

querying capabilities required by Core financial system users. 
System Management Function 

Core Financial System Requirements 18

Mandatory Requirements 

To support the Document Referencing and Modification process, the Core financial system 

must provide automated functionality to do the following: 

SMC-01 Associate documents in the processing chain—Associate documents in the 

processing chain, and bring forward accounting and non-financial information from 

one document to another, when the previously recorded document is referenced, 

(e.g., commitment to obligation, receivable to collection). This is to include 

accounting classification, vendor and customer information. 

SMC-02 Update referenced document balances—Update the balance of open 

documents by accounting line item as they are referenced by subsequent 

documents in the processing chain. For example, reduce commitments when 

referenced by obligations, reduce obligations when referenced by expenditures, 

reclassify obligations when referenced by advances, reduce accounts receivable 

when referenced by collections. 

SMC-03 Associate documents with source documents—Associate documents with 

related source documents (e.g., reimbursable agreements, purchase orders, 

contracts and delivery orders, BPAs and call numbers, and grants) so that queries 

show all related activity. 

SMC-04 Financial modifications to documents—Capture document modifications at the 

accounting line item level that affect the general ledger, including changes to dollar 

amounts and accounting classifications. Validate that funds are available prior to 

recording the modifications. 

SMC-05 Non-financial document modifications—Capture document modifications that 

do not affect the general ledger, such as changes to vendor names, descriptions, 

etc. 

SMC-06 Associate modifications with original documents—Associate document 

modifications and cancellations with the original documents so that queries show 

all related activity. 

SMC-07 Re-open closed document—Re-open a closed document to allow further 

processing against it, without requiring a new or amended document number. 

SMC-08 Reference multiple prior documents—Reference multiple documents and 

document lines in the processing chain. For example, reference multiple 

commitments or commitment lines on an obligating document, or reference 

multiple receivable documents or document lines on a collection. 
System Management Function 

Core Financial System Requirements 19

SMC-09 Document status—Capture the latest system processing status on all documents. 

• Held: The user has decided to save (hold) the document and not allow the 

system to process it. (Note: This status is distinguished from invoices that 

are processed and warehoused, then “held” from inclusion in the payment 

schedule.) 

• Suspended: The document has failed one or more system validations 

(edits) and is prevented by the system from processing. The document is 

automatically stored for later processing. Suspended documents may be 

automatically processed by the system upon changes to underlying data, 

such as available funds. 

• Pending Approval: The document has passed all system validations. The 

system will not process the document until all approvals required by the 

agency's workflow configuration have been applied. Not all documents 

require approvals. 

• Approved: The document has passed all system validations (edits) and all 

required approvals have been applied. The document is available for 

processing. 

• Processed: All related accounting events have been recorded and system 

tables have been updated. 

• Open: The document has been processed but not liquidated or only 

partially liquidated. The document is available for further processing. 

• Closed: The document has been processed and completely liquidated. 

The system will not allow further processing against the document unless it 

is reopened by the user. 

• Cancelled: The user has permanently closed a previously processed 

document. The system will not allow further processing against the 

document. 

• Deleted: The user has chosen not to process a held or suspended 

document. Deleted documents are marked for purging. 

• Converted: The document was processed through an automated or 

manual transfer from a legacy system. 

SMC-10 Related documents query—Query documents. Parameter includes any 

document number. Result is a list of all document numbers in the document's 

processing chain with document statuses and balances at the document level. 

Drill-down from each document number to its document details (e.g., 

vendor/customer name, description, amount). 

SMC-11 Standard document transactions query—Query transactions. Parameter is any 

document number. Result is a list of all general ledger transactions in the 

document's processing chain, including: 

• Transaction numbers 

• Amounts 

• GL debits and credits 

• Accounting classification elements. 
System Management Function 

Core Financial System Requirements 20

SMC-12 Standard document query—Query documents. Parameter(s) include any one or 

a combination of the following: 

• Document type 

• Document status (e.g., open, closed) 

• Vendor number 

• Vendor DUNS+4 number 

• Customer number 

• Accounting classification elements. 

Result is a list of selected document numbers with document statuses and 

balances at the document level. Drill-down from each document number to its 

document lines and detailed GL transactions. 

Value-Added Requirements 

To add value to the Document Referencing and Modification process, the Core financial system 

should provide automated functionality to do the following: 

SMC-13 Update accounting data—Update accounting data at the accounting line level 

when accounting classification elements are restructured, i.e., by reversing GL 

and subsidiary ledger transactions and reposting them with the new values. 

Generate an audit trail from the original postings to the final postings. 

SMC-14 Dating of accounting data reclassification—Reclassify accounting data from 

the beginning of the current fiscal year or fiscal month. 

SMC-15 Update open documents—Update related open documents when users 

modify classification information on a document in a processing chain. 

System-Generated Transactions Process 

The initial source of Core financial system activity may be any one of the following: online data 

entry, other systems or modules, or system-generated transactions. System-generated 

transactions include recurring entries (and reversals), closing entries, cost assignment entries, 

and transactions generated by other transactions. Agencies define these entries in advance for 

subsequent posting by the Core financial system. The general ledger postings are specified, as 

well as the date or frequency of those postings. System-generated transactions are then posted 

automatically by the Core financial system on the specified dates, based on the passage of 

time. 

Mandatory Requirements 

To support the System-Generated Transactions process, the Core financial system must

provide automated functionality to do the following: 

SMD-01 Parameters for recurring entries—Capture start and end dates and posting 

frequency (monthly, quarterly, or specified number of days) of recurring entries 

and reversals such as accruals and obligations. 

SMD-02 Future-dated recurring entries—Generate recurring entries and reversals in 

future accounting periods (e.g., payroll and travel accruals), when the specified 

transaction dates are reached. This is to include entries that cross fiscal years. 
System Management Function 

Core Financial System Requirements 21

SMD-03 Future-dated transactions—Future date transactions for processing in 

subsequent accounting periods, i.e., when the specified transaction dates are 

reached. Validate the transaction upon initial entry and re-validate the 

transaction at the point it is recorded. 

SMD-04 Transaction reversals—Generate batched reversal transactions by any one or 

a combination of the following parameters: 

• Accounting period 

• Transaction or document type 

• Accounting classification elements 

• System date 

• Transaction date 

• Source system ID. 

For example, reverse payroll transactions posted on January 1, 2006. 

SMD-05 Valid transaction reversals—Validate that transaction reversals do not violate 

the integrity of the document chain. For example, do not reverse obligations that 

have been liquidated by payments. 

SMD-06 Transaction reversal report—Generate a report of posted and unposted 

reversal transactions. Parameters are: 

• Accounting period 

• Transaction or document type 

• Accounting classification elements 

• System date 

• Transaction date 

• Source system ID. 

 Result is a list of transactions including: 

• System date 

• Transaction date 

• Original document and accounting line numbers 

• Status (posted or un-posted) 

• Accounting classification elements 

• GL transaction ID number 

• GL debits and credits. 

Sorting options include document number and reversal status. 

SMD-07 System interfaces—Deliver the capability to send/receive financial transactions 

from Governmentwide mandated applications: 

• Central Contractor Registration (CCR) 

• Electronic Certification System (ECS) 

• Federal Agencies Centralized Trial Balance System I (FACTS I) 

• Federal Agencies Centralized Trial Balance System II (FACTS II) 

• Government Online Accounting Link System (GOALS II) 

• Intra-governmental Payment and Collection System (IPAC) 

• Treasury Offset Program (TOP) 

• Secure Payment System (SPS). 
System Management Function 

Core Financial System Requirements 22

Value-Added Requirements 

To add value to the System-Generated Transactions process, the Core financial system should

provide automated functionality to do the following:

SMD-08 Other system interfaces—Deliver the capability to send/receive financial 

transactions from Government wide mandated applications: 

• eTravel 

• CA$HLINK II 

• GWA. 

Audit Trails Process 

Adequate audit trails are critical to providing support for transactions and balances maintained 

by the Core financial system. Although audit trails are essential to auditors, they are also 

important to agencies in their day-to-day operation of the system. Audit trails provide agencies 

with information necessary to reconcile accounts, research document history, and query the 

data stored in the Core financial system. 

Mandatory Requirements 

To support the Audit Trails process, the Core financial system must provide automated 

functionality to do the following: 

SME-01 Document processing audit trail—Generate an audit trail of transactions 

recorded as a document moves from its source through all document statuses. 

The initial source may be documents that were entered online, systemgenerated, interfaced from other systems or modules, or converted during 

implementations or software upgrades. 

SME-02 Document activity logging—Capture all document change events (additions, 

modifications and cancellations), including the date/time and User ID. 

SME-03 Document activity query—Query document additions, modifications and 

cancellations. Parameters include: 

• User ID 

• Document number 

• Document type 

• Change type (add, modify, cancel) 

• Transaction date range 

• Accounting period. 

Results include all parameter values, document numbers, date and time 

stamps. 

SME-04 Accounting classification history—Generate an audit trail of all accounting 

classification structure additions, changes and deactivations, including the 

effective dates of the changes. 
System Management Function 

Core Financial System Requirements 23

SME-05 Converted documents—Capture the following additional information on 

converted documents: 

• Legacy system identifier 

• Legacy system document number. 

Value-Added Requirements 

There are no value-added requirements for this process.
Core Financial System Requirements 24 

General Ledger Management Function 

General Ledger Management is the central function of the Core financial system. All 

transactions to record financial events must post to the general ledger, regardless of the origin 

of the transaction. Transactions originating in other systems may post to the general ledger at a 

summary level, depending on an agency’s overall financial management system design and 

need. At a minimum, however, summary transactions must post at a level that maintains the 

accounting classification elements and attributes needed to support central agency reporting. 

The general ledger must summarize and maintain account balances at the U.S. SGL account 

and attribute level. In addition, it must maintain balances by the accounting classification 

elements established in the System Management function. For example, account balances must 

be maintained at the internal fund and organization level. An agency might choose to classify 

financial data at a lower level by establishing general ledger subaccounts or agency-specific 

accounting classification elements in order to support internal reporting needs or program 

management performance reporting. The general ledger must maintain account balances at 

these agency-specific levels, as well. 

The General Ledger Management function consists of the following processes (the prefixes 

assigned to the requirements are noted in parentheses): 

• General Ledger Account Definition (GLA) 

• Transaction Definition (GLB) 

• General Ledger Updating and Editing (GLC) 

• Upward/Downward Spending Adjustments (GLD) 

• General Ledger Analysis and Reconciliation (GLE) 

• Accounting Period Maintenance and Closing (GLF) 

• Financial Reporting (GLG). 

General Ledger Account Definition Process 

OMB Circular A-127, Financial Management Systems, requires implementation of the U.S. SGL 

at the transaction level. The U.S. SGL is defined in the latest supplement to the Department of 

the Treasury’s TFM, which includes the chart of accounts, account descriptions and postings, 

accounting transactions, U.S. SGL attributes, and crosswalks to standard external reports. Each 

agency must implement a chart of accounts that is consistent with the U.S. SGL and meets the 

agency’s information needs. 

Mandatory Requirements 

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

provide automated functionality to do the following: 
General Ledger Management Function 

Core Financial System Requirements 25

GLA-01 Chart of accounts—Maintain a chart of accounts consistent with the U.S. SGL 

Chart of Accounts, including the proprietary, budgetary, and memorandum 

accounts, basic numbering structure, and account titles. 

GLA-02 Account attributes—Maintain an association between the chart of accounts 

and valid attribute domain values used for Treasury reporting (e.g., FACTS I, 

FACTS II and GFRS reporting). 

GLA-03 Control accounts—Define specific GL accounts as control accounts for 

purposes of tracking activity in subsidiary ledgers. 

GLA-04 Sub-accounts—Define agency-specific GL sub-accounts that summarize to 

U.S. SGL accounts. 

GLA-05 Sub-account length—Accommodate an additional 2 digits beyond the U.S. 

SGL account for agency-specific GL sub-accounts. 

GLA-06 Memorandum accounts—Define agency-specific memorandum accounts in 

the chart of accounts. 

GLA-07 Account changes—Add, change or de-activate accounts in the chart of 

accounts without programming changes. 

GLA-08 Attribute value changes—Add, change or de-activate U.S. SGL attribute 

domain values in order to accommodate changes in Treasury reporting (e.g. 

FACTS I, FACTS II, or GFRS) without programming changes. 

GLA-09 Pre-configured U.S. SGL accounts—Deliver the Core financial system 

software populated with the current published values for the U.S. SGL chart of 

accounts. 

GLA-10 Pre-configured FACTS II attributes—Deliver the Core financial system 

software populated with the current published values for the FACTS II attributes. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Transaction Definition Process 

In addition to implementing the U.S. SGL at the transaction level, OMB Circular A-127 requires 

common processes to be used for processing similar kinds of transactions throughout an 

integrated financial management system. This ensures that all transactions are handled 

consistently, regardless of their point of origin. Consistency in processing transactions is 

accomplished by defining standard transactions for use in recording accounting events. 

Standard transactions must comply with U.S. SGL posting rules and include budgetary, 

proprietary, and memorandum accounts, as applicable. 
General Ledger Management Function 

Core Financial System Requirements 26

Mandatory Requirements 

To support the Transaction Definition process, the Core financial system must provide 

automated functionality to do the following: 

GLB-01 Standard transactions—Record like accounting events consistently using 

standard transactions. Standard transactions must specify the general ledger 

account postings, and update document balances and any related tables (e.g. 

available funding). 

GLB-02 GL account posting—Define the general ledger account postings used in a 

standard transaction. 

GLB-03 Transaction accounts—Define standard transactions that include proprietary, 

budgetary and memorandum accounts. 

GLB-04 U.S. SGL consistency—Define standard transactions consistent with U.S. SGL 

posting rules. 

GLB-05 Posting derivation—Define standard transactions that derive general ledger 

postings based on accounting classification elements or other document data 

elements. 

GLB-06 Transaction rules—Define edit rules for standard transactions to require, 

prohibit, or set a default value for accounting classification elements. 

GLB-07 Number of GL account pairs—Define up to 10 debit and credit pairs in a 

single standard transaction. 

Value-Added Requirements 

There are no value-added requirements for this process. 

General Ledger Updating and Editing Process 

To ensure the consistency and completeness of financial records, the General Ledger Update 

and Editing process requires that all general ledger accounts—budgetary, proprietary, and 

memorandum—referenced on a standard transaction be updated at the time of input of a 

transaction. It requires general ledger updates to be balanced at all levels of the organization 

and consistent with updates to subsidiary ledgers. Subsidiary ledgers must support the general 

ledger at various levels of detail, whether totally integrated as part of the Core financial system 

or interfaced from other systems. 

Mandatory Requirements 

To support the General Ledger Update and Editing process, the Core financial system must

provide automated functionality to do the following: 

GLC-01 Updating GL balances—Update all general ledger account balances (i.e., 

budgetary, proprietary and memorandum accounts) based on a single input 

transaction. 
General Ledger Management Function 

Core Financial System Requirements 27

GLC-02 Classifying transactions by attribute—Classify accounting transactions by 

U.S. SGL attributes required for FACTS I, FACTS II, and GFRS reporting as 

specified by the current supplement(s) to the TFM. 

GLC-03 Validate attributes—Validate U.S. SGL attributes on transactions (whether 

entered or derived) prior to the posting. 

GLC-04 Balanced GL postings by ACS—Prevent transactions from posting that would 

cause general ledger debits and credits to be out-of-balance at any level of the 

agency's accounting classification structure specified on a transaction. 

GLC-05 Balanced GL postings by account type—Prevent transactions from posting 

that would cause general ledger debits and credits to be out of balance within 

the proprietary, budgetary, or memorandum accounts. Proprietary, budgetary, 

and memorandum accounts must each be self-balancing. 

GLC-06 GL control accounts balanced with subsidiary ledgers—Update general 

ledger control accounts consistent with postings made to subsidiary ledgers. 

Prevent transactions from posting that would cause the general ledger control 

accounts to be out-of-balance with the subsidiary ledgers. 

GLC-07 De-activated accounts—Prevent transactions from posting to general ledger 

accounts that have been de-activated. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Upward/Downward Spending Adjustment Process 

Accounting for upward and downward spending adjustments requires a complex analysis of the 

types of adjustments made to prior-year spending documents. This process requires the system 

to recognize when an adjustment occurs and to determine what type of adjustment occurred. 

Based upon this analysis, the system must automatically create the appropriate adjustment 

entry to record the financial event. 

Mandatory Requirements 

To support the Upward/Downward Spending Adjustment process, the Core financial system 

must provide automated functionality to do the following: 

GLD-01 Record spending adjustments—Derive and record the amount of upward or 

downward spending adjustments upon liquidating, canceling, or modifying the 

dollar amount of prior year obligations or expenditures. Record the spending 

adjustment at the time of posting the transaction which generated it. 

GLD-02 Spending adjustment reversals—When correcting documents that previously 

generated spending adjustment entries, reverse the original spending 

adjustment entries and generate new spending adjustments for the correct 

amounts. 
General Ledger Management Function 

Core Financial System Requirements 28

GLD-03 Adjustments to expired vs. unexpired—Determine if upward and downward 

adjustments are to expired or unexpired budget authority in order to derive the 

U.S. SGL prescribed entries to record spending adjustments. 

GLD-04 Anticipated recoveries—Determine if anticipated recoveries have been 

previously recorded in order to derive the U.S. SGL prescribed entries to record 

downward spending adjustments. 

GLD-05 Adjustments to paid vs. unpaid—Determine if upward and downward 

adjustments are to paid or unpaid obligations and/or expenditures in order to 

derive the U.S. SGL prescribed entries for recording spending adjustments. 

GLD-06 Adjustments to delivered vs. undelivered orders—Determine if upward and 

downward adjustments are to delivered or undelivered orders in order to derive 

the U.S. SGL prescribed entries to record spending adjustments. 

GLD-07 Previously unrecorded obligations—Permit recording of previously 

unrecorded obligations to prior year budget authority or expired budget authority 

and generate related upward spending adjustments in the current year. 

GLD-08 Spending adjustment validation—Identify when posting transactions will 

invoke upward spending adjustments, and apply the agency-defined level of 

validation (I.e., rejection, warning or information only). 

Value-Added Requirements 

There are no value-added requirements for this process. 

General Ledger Analysis and Reconciliation Process 

The Core financial system must provide information to use in analyzing account balances and in 

reconciling account balances to information contained in reports and in subsidiary ledgers. With 

system integration, the likelihood of out-of-balance conditions existing between financial reports, 

subsidiary ledgers, and account balances should be minimal, but the possibility of such 

conditions do exist as a result of system failures and incorrect transaction definitions. 

Mandatory Requirements 

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

must provide automated functionality to do the following: 

GLE-01 General ledger account balances query—Query general ledger account 

balances. Parameters include beginning and ending accounting period, and 

TAS or internal fund code. Result is beginning account balances, period activity, 

and ending account balances for the period and TAS, or internal fund code, 

specified. Drill-down from period activity to supporting general ledger 

transactions; from general ledger transactions to supporting documents; and 

from supporting documents to other documents in the document chain. 
General Ledger Management Function 

Core Financial System Requirements 29

GLE-02 Daily GL and Subsidiary Ledger Exception Report—Generate the Daily GL 

and Subsidiary Ledger Exception Report. Result is a list of GL control accounts 

by internal fund code whose balances differ from the subsidiary ledgers. Report 

lines include the GL control account balance, the balance of the open 

documents in the subsidiary ledger, and the difference. 

GLE-03 GL Supporting Document Report—Generate the GL Supporting Documents 

Report as of the current system date. Parameters include a GL control account 

and TAS or internal fund code. Result is the GL account balance, and a list of 

the open documents and balances supporting the GL account balance. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Accounting Period Maintenance and Closing Process 

This process segregates accounting transactions into accounting periods and creates 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 Accounting Period Maintenance and Closing process, the Core financial system 

must provide automated functionality to do the following: 

GLF-01 Accounting periods—Maintain fifteen accounting periods per fiscal year. 

Provide the option to designate one period for recording opening balances, 

twelve periods for recording monthly activity and two additional periods for year 

end pre-closing and closing entries. 

GLF-02 Open accounting periods—Record transactions to any open accounting 

period. Provide the option to keep multiple accounting periods (minimum of 3) 

open simultaneously. 

GLF-03 Closed accounting periods—Close accounting periods and prevent the 

posting of new transactions to any closed period. 

GLF-04 Re-opening accounting periods—Re-open closed accounting periods and 

record transactions to them. 

GLF-05 Closing entries—Provide a year-end closing process that records U.S. SGL 

prescribed closing entries in accounting periods separate from other accounting 

periods. 

GLF-06 Multiple closings—Perform multiple closings in a trial/test mode so that users 

can review the closing results, clear the closing entries and re-run the closing 

process. This functionality must be available for both "pre-closing" entries and 

"closing" entries. 
General Ledger Management Function 

Core Financial System Requirements 30

GLF-07 Closing results—Generate trial balances that support the review of the closing 

process run in trial/test mode. 

GLF-08 Open fiscal years—Record transactions to the current and prior fiscal year 

(i.e., until the closing process is complete). 

GLF-09 Roll forward balances—Derive an accounting period’s opening balances 

based on the prior accounting period’s closing balances at the U.S. SGL 

attribute level. The opening of general ledger account balances must maintain 

the U.S. SGL attribute information required to satisfy FACTS I, FACTS II, and 

GFRS reporting requirements. 

GLF-10 Fiscal year driven tables—Make fiscal year driven tables available in 

subsequent fiscal years. 

GLF-11 Single year tables—Make single year appropriation and fund tables available 

in subsequent fiscal years. 

Value-Added Requirements 

To add value to the Accounting Period Maintenance and Closing functionality, the Core financial 

system should do the following: 

GLF-12 Mass table changes at fiscal year end—Deliver a capability to make mass 

changes to tables rolled forward to a subsequent fiscal year. 

Financial Reporting Process 

The financial reporting process ensures that the system provides the basic reports and online 

information access needed to review financial information and to fulfill central agency reporting 

requirements. It provides specifications for the minimum data elements to be displayed in the 

internal and external financial reports, while establishing general requirements that provide 

agencies with flexibility in configuring the reports, and generating the reports for specified 

accounting periods. 

Accounting reports that are based on the GL, such as a trial balance, are normally run as of a 

specified current or prior accounting period. If run for the current period, activity is reported 

through the current date. All financial accounting reports are expected to be generated using 

information maintained in the core general ledger. 

Mandatory Requirements 

To support the Financial Reporting process, the Core financial system must provide automated 

functionality to do the following: 

GLG-01 Report end dates—Generate all standard reports as of any accounting period. 

Amounts reported must reflect the cumulative amount of all transactions posted 

to the general ledger up through the accounting period specified for running the 

report. If reporting for the current period, amounts must be cumulative up 

through the current date. 
General Ledger Management Function 

Core Financial System Requirements 31

GLG-02 Report consistency—Ensure consistency between the data sources used to 

generate internal and external financial reports for the same accounting period. 

The following relationships must be maintained: 

• The beginning and ending balances and total debit and credit activity 

reported on the Standard Trial Balance must equal the beginning and 

ending balances and total debit and credit activity reported on the 

FACTS I and FACTS II trial balances. 

• The debit and credit activity reported on the Transaction Register must 

equal the debit and credit activity reported on all of the trial balances. 

• The system-generated FACTS I transfer file must agree with the 

system-generated Balance Sheet, Statement of Net Cost, and 

Statement of Changes in Net Position 

• The system-generated FACTS II transfer file must agree with the 

system-generated Statement of Budgetary Resources and the SF-133. 

GLG-03 Transaction register—Generate a transaction register report. Parameters are: 

accounting period, transaction date range, or system date range. Result is a 

report displaying the following data elements for each transaction posted during 

the accounting period or date range specified: 

• Fiscal year 

• TAS 

• Internal fund code 

• Document number 

• Transaction number 

• Transaction date 

• System date 

• System time 

• Entry user ID 

• Debit account number(s) 

• Debit amount(s) 

• Credit account number(s) 

• Credit amount(s) 

• Object class 

• U.S. SGL attribute values. 

Provide an option to group transactions at the TAS, internal fund, or 

organization level. Transactions which occur from a single posting event must 

be grouped together. The report must include headings for each data element 

displayed. The report must include all transactions in all funds that occurred 

within the accounting period specified. 

GLG-04 Trial balance—Generate a trial balance report. Parameter is the accounting 

period. Result is a report providing the following amounts for each general 

ledger account: 

• Beginning balance for the accounting period 

• Total amount of debits for the accounting period 

• Total amount of credits for the accounting period 

• Cumulative ending balance for the accounting period. 

Provide the option to select whether general ledger account balances are rolled 

up to the TAS level, internal fund level, or organization level, and also whether 

they are displayed at the GL sub-account level (actual accounts used for 

posting transactions) or the U.S. SGL account level. Sub-totals for beginning 

balance, accounting period activity, and ending balance columns must be 
General Ledger Management Function 

Core Financial System Requirements 32

provided after each change in organization, internal fund and TAS on the report. 

The report must include the balances of all funds and all fiscal years maintained 

by the agency. 

GLG-05 FACTS I trial balance—Generate a FACTS I trial balance report. Parameter is 

the accounting period. Result is a report displaying the following balances for 

each U.S. SGL account or U.S. SGL account and attribute combination: 

• Beginning balance for the accounting period 

• Total amount of debits for the accounting period 

• Total amount of credits for the accounting period 

• Cumulative ending balance for the accounting period. 

Provide the option to specify whether general ledger account balances are 

rolled up to the TAS level, internal fund level, or organization level. The report 

must include all general ledger accounts (both FACTS I accounts and nonFACTS I accounts). FACTS I accounts must be displayed at the U.S. SGL and 

attribute level (I.e. separate amounts should be displayed when there is more 

than one attribute value within an U.S. SGL account). Non-FACTS I accounts 

must be displayed at the U.S. SGL account level. Subtotals for beginning 

balance, accounting period activity, and ending balance columns must be 

provided after each change in TAS, internal fund, and organization on the 

report. 

GLG-06 FACTS II trial balance—Generate a FACTS II trial balance report. Parameter 

is the accounting period. Result is a report displaying the following balances for 

each U.S. SGL account or U.S. SGL account and attribute combination: 

• Beginning balance for the accounting period 

• Total amount of debits for the accounting period 

• Total amount of credits for the accounting period 

• Cumulative ending balance for the accounting period. 

Provide the option to specify whether general ledger account balances are 

rolled up to the TAFS level, internal fund level, or organization level. The report 

must include all general ledger accounts (both FACTS II accounts and nonFACTS II accounts). FACTS II accounts must be displayed at the U.S. SGL and 

attribute level (i.e., separate amounts should be displayed when there is more 

than one attribute value within a U.S. SGL account). Non-FACTS II accounts 

must be displayed at the U.S. SGL account level. Subtotals for beginning 

balance, accounting period activity, and ending balance columns must be 

provided after each change in TAFS, internal fund, and organization on the 

report. 

GLG-07 FACTS ATB—Export bulk transfer files for FACTS I and FACTS II Adjusted 

Trial Balances (ATBs) to the Department of Treasury's FMS. 

GLG-08 FACTS validation—Validate FACTS I and FACTS II data prior to submission of 

the FACTS I and FACTS II ATBs and the GFRS report to Treasury's FMS. 

Provide the option to run validation edits on demand. 

GLG-09 SF 133—Generate the Report on Budget Execution and Budgetary Resources 

(SF-133). Parameters include TAFS and accounting period end date. When no 

TAFS is specified, generate a report for each reportable TAFS. Results are 

reports in accordance with OMB Circular A-11 instructions and the U.S. SGL 

crosswalk to the SF-133 report. 
General Ledger Management Function 

Core Financial System Requirements 33

GLG-10 Financial statements—Generate the following consolidated agency financial 

statements: 

• Balance Sheet 

• Statement of Net Cost 

• Statement of Changes in Net Position 

• Statement of Budgetary Resources 

• Statement of Financing 

• Statement of Custodial Activity (if applicable). 

Parameter is the accounting period end date. Reports are to be generated from 

the general ledger account balances and attributes crosswalked in accordance 

with the U.S. SGL Crosswalks to Standard External Reports. Results are 

reports in accordance with the current OMB Bulletin on Form and Content of 

Agency Financial Statements. 

GLG-11 Statement customization—Customize agency financial statement formats by 

adding or deleting line items, changing the name of line items, inserting 

additional subtotals, or modifying account crosswalks through table updates or 

report writing capability. 

GLG-12 GFRS Statements—Generate reclassified consolidated agency financial 

statements for input to GFRS in accordance with current TFM Agency Reporting 

Requirements for the Financial Report of the United States Government and the 

U.S SGL Crosswalks to the Closing Package. 

GLG-13 On-line statements—Generate consolidated financial statements on-line. Drilldown from the consolidated amounts to the GL accounts and balances that 

make up the amounts, from the GL account balances to the individual balances 

by TAS, and to detailed GL transactions. 

Value-Added Requirements 

There are no value-added requirements for this process. 
Core Financial System Requirements 34 

Budgetary Resource Management Function 

Article I, section 9, of the Constitution of the United States provides that “no money shall be 

drawn from the Treasury, but in Consequence of Appropriations made by law....” From this 

basic provision, a body of laws and regulations has evolved to govern the Federal budget 

process and prescribe generally uniform procedures for obtaining, expending, administering, 

and controlling resources. Federal appropriations law, U.S. Comptroller General Decisions, and 

OMB Circular A-11, Preparation, Submission, and Execution of the Budget, constitute 

authoritative guidance and set governmentwide policy for budgetary resource management. 

To comply with OMB Circular A-11, each agency of the Federal Government is responsible for 

preparing an agency budget estimate to request funding and for establishing a system for 

ensuring that it does not obligate or disburse funds in excess of those appropriated or 

authorized. The Budgetary Resource Management function of the Core financial system is an 

agency’s primary tool for carrying out this responsibility. In addition to supporting the 

governmentwide policies, the Budgetary Resource Management function must support agency 

policies on internal funds allocation methods and controls. 

An agency will likely have many other systems in addition to the Core financial system that 

affect budgetary resources. For example, procurement and travel systems generate documents 

that commit and obligate funds. These and other systems that affect funds availability should 

access data in and use processes of the Core financial system to verify that funds are available 

and to update balances. These systems typically access the funds availability editing activity 

before allowing an obligation to be incurred, such as when entering into a contract. However, in 

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

The Budgetary Resource Management function consists of the following processes (the prefixes 

assigned to the requirements are noted in parentheses): 

• Budget Planning (FMA) 

• Budget Preparation (FMB) 

• Budget Authority (FMC) 

• Funds Distribution (FMD) 

• Funds Control (FME) 

• Funds Status (FMF). 

Budget Planning Process 

Budget planning is the process of establishing the initial agency budget plan. The budget plan is 

a blueprint for using financial resources during any given fiscal period or series of periods. The 

Budget Planning process includes updating the budget plan as necessary and reporting on the 

use of resources against these plans throughout the year. 
Budgetary Resource Management Function 

Core Financial System Requirements 35

Mandatory Requirements 

To support the Budget Planning process, the Core financial system must provide automated 

functionality to do the following: 

FMA-01 Financial operating plans—Capture financial operating plans for any funded 

organization level or other accounting classification. 

FMA-02 Spending plans—Capture spending plans for any funded organization level or 

other accounting classification. 

FMA-03 Plan periods—Capture financial operating and spending plans by month, 

quarter and year. 

FMA-04 Export plan data—Export financial operating and spending plan data at the 

accounting line item level in an Excel or ASCII text delimited file format. 

Value-Added Requirements 

To add value to the Budget Planning process, the Core financial system should provide 

automated functionality to do the following: 

FMA-05 Plan measurements—Generate plan results based on multiple measures 

including fixed dollar amounts, unit costs, cost allocations, labor hours or fulltime equivalents (FTEs). 

FMA-06 Plan versions—Maintain current and multiple historical versions of plans. 

FMA-07 Compare plans—Compare multiple versions of plans. 

FMA-08 Future plans—Maintain financial operating and spending plans for future 

periods (i.e., future fiscal years). 

FMA-09 Plan activation—Activate future period plans based on a specified plan start 

date or on-demand. 

FMA-10 Planned to actual—Compare planned spending to actual spending. 

Budget Preparation Process 

Budget preparation is the process of assembling estimates for the upcoming fiscal year for 

transmittal to OMB and the congressional appropriations committees, preparing justification 

materials to support those estimates, and defending those estimates formally (at OMB and 

congressional hearings) and informally (through staff contacts with these entities). 

Mandatory Requirements 

There are no mandatory requirements for this process. 
Budgetary Resource Management Function 

Core Financial System Requirements 36

Value-Added Requirements 

To add value to the Budget Preparation process, the Core financial system should provide 

automated functionality to do the following: 

FMB-01 Budget information—Classify budget projections using accounting 

classification elements (e.g., Apportionment categories, Authority type, etc.). 

FMB-02 Import budget formulation data—Import budget formulation data (e.g., 

Presidential/OMB pass backs, congressional markup documents, and internal 

agency decisions). 

FMB-03 Calculate prior year budget data—Calculate prior year budgets, actual 

spending amounts and variances at the line item level. 

FMB-04 Export prior year budget data—Export prior year budgets, actual spending 

and variances at the line item level in an excel or ASCII text delimited file 

format. 

FMB-05 Projected activity—Generate projected future period obligations, income, and 

expenditures at any level of the organizational structure based on prior year 

actual activity using agency-defined projection rates. 

FMB-06 Define projection rates—Define projection rates (e.g., 90%, 100%, 110%) by 

budget object class for use in budget formulation. 

FMB-07 Apply projection rates—Calculate budget amounts for all, selected groups, or 

individual budget line items based on agency-defined projection rates. 

FMB-08 What if analysis—Generate multiple budgets based on alternative agencyspecified accounting structures, funding levels, and spending criteria. 

FMB-09 Payroll forecasts—Generate payroll forecasts (i.e., anticipated compensation 

and benefits) at the object class and individual employee level. 

FMB-10 Modified payroll forecasts—Generate modified payroll forecasts. 

FMB-11 Projected overhead—Generate overhead projections using agency defined 

overhead rates. 

FMB-12 Import budget information—Import budget formulation data submitted in 

Excel or ASCII text delimited format. 

FMB-13 Import budget submission guidance—Import budget submission guidance, 

other narrative text and briefing material written using common PC desktop 

applications (e.g., MS Word). 

FMB-14 Distribute budget submission guidance—Distribute budget submission 

guidance electronically. 
Budgetary Resource Management Function 

Core Financial System Requirements 37

FMB-15 Budget cycles—Generate budget information for multiple budget cycles (e.g. 

monthly, quarterly, semi-annual, and yearly). 

FMB-16 Budget and GPRA goals—Associate budget formulation line items to the 

agency’s stated goals and objectives required by GPRA. 

FMB-17 Budget information—Generate budget formulation information for all 

categories on which legally binding budgetary decisions are made (e.g., 

appropriation limitations). 

FMB-18 Administrative budget information—Generate budget formulation information 

for administrative purposes as in the nature of policy guidance and decision 

making (e.g., Presidential/OMB pass backs, congressional markup documents, 

or internal agency decisions). 

FMB-19 SF 132 TAFS data—Capture SF-132 Schedule data by TAFS. 

FMB-20 Export SF 132 Schedules—Export SF-132 Schedules for each TAFS requiring 

apportionment in Excel file format specified by OMB. 

Budget Authority Process 

Establishing budget authority, formerly referred to as Funds Allocation, is the beginning of the 

budget execution process. This process records an agency’s budgetary resources and supports 

the establishment of legal budgetary limitations within the agency, including appropriation 

warrants, apportionments, reapportionments, transfer allocations, and continuing resolutions. It 

also supports the establishment of funding to agencies that are not subject to apportionment. 

Mandatory Requirements 

To support the Budget Authority process, the Core financial system must provide automated 

functionality to do the following: 

FMC-01 Budget execution documents—Record funding based on related budget 

execution documents (e.g., appropriation warrants and apportionments). 

FMC-02 Budget execution documents data—Capture fund specific information (e.g., 

public law, program, authority type, apportionment category, etc.) on budget 

execution documents. 

FMC-03 Budget authority types—Record budgetary authority (defined in OMB Circular 

A-11) including direct appropriations, borrowing authority, contract authority, 

and spending authority from offsetting collections. 

FMC-04 Internal funds control document—Capture multiple internal fund codes based 

on a single apportionment schedule, ensuring that unique fund characteristics 

(e.g. authority type, apportionment category) are available for funds control 

purposes. 
Budgetary Resource Management Function 

Core Financial System Requirements 38

FMC-05 Changes to budget authority—Record changes to budget authority including 

reductions; rescissions; amounts withheld or made unavailable; supplementals, 

transfers; reprogramming; legal limitations and changes to continuing 

resolutions. 

FMC-06 Expirations of budget authority—Record the expiration and cancellation of 

budget authority in accordance with OMB Circular A-11. 

FMC-07 Continuing resolutions—Record multiple, successive continuing resolutions. 

FMC-08 CR effective dating—Capture the start and end dates, amount, and public law 

number of a continuing resolution. 

FMC-09 CR amendments—Record amendments to the amount and/or effective dates 

of an existing Continuing Resolution. 

FMC-10 Revolving funds—Process revolving fund contracts, work orders, and projects. 

Monitor all related advances, prepayments and reimbursements. 

FMC-11 Reimbursable authority—Calculate available fund balances based on 

reimbursable agreement authority. 

FMC-12 Advance funding edit—Prevent the use of funds against reimbursable 

agreements with the public and other non-federal entities without an advance. 

FMC-13 SF 132 apportionment data—Record apportioned funds in accordance with 

the latest OMB approved SF 132 Apportionment and Reapportionment 

Schedule. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Funds Distribution Process 

Funds distribution is the part of budget execution cycle in which legally apportioned resources 

are distributed within the agency to support missions, programs, and other objectives. The 

process establishes multiple levels of budgetary control by allotting and sub-allotting 

apportioned resources for agency management. 

Mandatory Requirements 

To support the Funds Distribution process, the Core financial system must provide automated 

functionality to do the following: 

FMD-01 Limitations—Capture legal (statutory) and administrative (agency imposed) 

limitations on the use of funds. 

FMD-02 Fund distributions—Record allotments, sub-allotments, allocations and 

allowances (i.e. distribute funds) to multiple organizational levels or other 

elements of accounting classification. 
Budgetary Resource Management Function 

Core Financial System Requirements 39

FMD-03 Fund distribution levels— Record up to eight levels of funds distribution including 

levels used for appropriation and apportionment of budget authority.

FMD-04 Fund distribution availability—Prevent the distribution of funds in excess of 

the amount of funds available at the next highest distribution level. 

FMD-05 Fund distribution modification—Record the modification of funding 

distributions at multiple organizational levels or elements of the accounting 

classification structure. 

FMD-06 Withdrawal of unobligated funds by TAFS—Record the withdrawal (or 

cancellation) of unobligated allotments and sub-allotments (both expired and 

unexpired) for all or selected TAFS at the end of a fiscal period or on demand 

as in rescissions. 

FMD-07 Withdrawal of unobligated funds by organization—Record the withdrawal 

(or cancellation) of unobligated allotments and sub-allotments (both expired and 

unexpired) for selected organizations at the end of a specific fiscal period or on 

demand as in rescissions. 

Value-Added Requirements 

To add value to the Funds Distribution process, the Core financial system should provide 

automated functionality to do the following: 

FMD-08 Plan-based funding updates—Update allotments, sub-allotments, allocations 

and legal and administrative limitations based on changes to operating plans. 

FMD-09 System-generated allotments—Generate allotment and sub-allotment 

information with sufficient detail to support funds control. 

FMD-10 Distribute allotments—Distribute system-generated allotment and suballotment information electronically to subordinate organizations. 

FMD-11 Reprogramming requests—Capture requests for reprogramming of funds or 

additional funds outside the formal budget process. 

FMD-12 Reprogramming request status—Capture submitted, reviewed and approved 

status information on re-programming requests. 

FMD-13 Record reprogramming requests—Record budget authority changes based 

upon approval of reprogramming requests. 
Budgetary Resource Management Function 

Core Financial System Requirements 40

Funds Control Process 

Funds control prevents the expenditure of funds in excess of established budgetary limitations 

as established through the Funds Distribution process. The Core financial systems must be 

designed to apply effective funds control at the point that spending documents are entered. The 

Funds Control process consists of the following document processing activities: 

• Funds Availability Editing. This activity verifies that sufficient funds are available for each 

processed spending transaction that affects the agency’s available fund balances. 

• Commitments. This activity records commitment documents (e.g., requisitions). 

Commitments allow the agency to “reserve” funds before legal obligations are 

established. Commitments are a useful funds control tool, but are not appropriate for all 

spending situations. In cases where the agency determines that the use of commitments 

is appropriate, the Core financial management system must provide the capability to 

apply funds control as defined in this document. 

• Obligations. This activity records obligating documents in the Core system. OMB 

Circular A-11 defines obligations as a binding agreement that will result in outlays, 

immediately or in the future. Budgetary resources must be available before obligations 

can be legally incurred. Examples are amounts of orders placed, contracts awarded, 

services received, and similar transactions that require payments during the current or a 

future period. 

• Advances. This activity records advances made to others by the agency. Advances 

include money prepaid under a statutory authorization for goods, services, or other 

assets to be received at a later date. For example, payment for all or any part of the 

estimated cost of the work could be made to the provider filling the order in advance. 

Later, the advance payments are adjusted as agreed to on the basis of the actual cost of 

goods or services provided. 

All requirements relating to Funds Control are grouped by these activities. 

Mandatory Requirements 

To support the Funds Control/Funds Availability Editing activity, the Core financial system must

provide automated functionality to do the following: 

FME-01 Monitor use of funds—Monitor the use of funds at each organizational level or 

other accounting classification to which budget authority is distributed. Reject, 

warn or inform the agency by spending document line when distributed authority 

is exceeded. 

FME-02 Spending documents—Process spending documents that affect the 

availability of funds, including commitments, obligations, advances, and 

expenditures. 

FME-03 Spending transactions—Record spending transactions, including 

commitments, obligations, advances and expenditures, at or below the level in 

the accounting classification than they are budgeted. 
Budgetary Resource Management Function 

Core Financial System Requirements 41

FME-04 Prior year funds—Record transactions against prior year funds, both expired 

and unexpired, in the current year. 

FME-05 Closed account payments—Monitor amounts paid out of current year funds to 

cover obligations made against a cancelled account (TAFS). Prevent payments 

that cumulatively exceed 1 percent of the current year appropriation or the total 

amount available prior to close of the original appropriation. 

FME-06 Spending document classification—Capture accounting classification 

information on commitments, obligations, advances, and expenditures at the 

accounting line item level. 

FME-07 Historical spending data—Maintain a history of changes made to 

commitment, obligation, advance, and expenditure documents. 

FME-08 Open spending document detail—Maintain open documents to show the 

status of commitments, obligations, advances, accruals and disbursements by 

document (commodity) line item. 

FME-09 Validate funds availability—Validate funds availability prior to recording 

spending transactions. 

FME-10 Use of unexpired, expired or cancelled funds—Derive funds availability 

based on the budget fiscal year of the originating document, i.e., whether funds 

cited are unexpired, expired, or cancelled. Record U.S. SGL prescribed general 

ledger entries when de-obligation of expired funding occurs. 

FME-11 Reuse of de-obligated funds—Validate period of availability. Prevent the 

allotment and reuse of de-obligated balances for new obligations in expired 

funds. 

FME-12 Fund control updates—Update balances used for funds controls to reflect 

changes in the status and amounts of commitments, obligations, expenditure 

and available balances. 

FME-13 Monitor plans—Monitor the use of funds against financial operating and 

spending plans. 

FME-14 Monitor limitations—Monitor the use of funds against legal (statutory) and 

administrative (agency imposed). 

FME-15 Monitor object class limitations—Monitor the use of funds against specific 

object class limitations. 

FME-16 Monitor reimbursable agreements—Monitor spending against reimbursable 

agreement amounts. 

FME-17 Reduce reimbursable balance—Reduce reimbursable authority and 

reimbursable agreement balances when customer orders are recorded. 
Budgetary Resource Management Function 

Core Financial System Requirements 42

FME-18 Monitor contracts—Monitor the use of funds against contracts, work-orders, 

task orders, and grants. 

To support the Funds Control/Commitments activity, the Core financial system must provide 

automated functionality to do the following: 

FME-19 Suggested vendor—Capture a suggested vendor on commitment documents. 

FME-20 Close commitments—Close commitment documents and document lines 

under the following circumstances: 

 • By the system upon issuance of an obligating document 

 • By an authorized user 

 • As part of the year-end pre-closing process. 

To support the Funds Control/Obligations activity, the Core financial system must provide 

automated functionality to do the following: 

FME-21 Obligating document data—Capture the following additional data elements 

on obligating documents: 

• Obligation type 

• Prompt pay indicator and type, or payment terms (including discount 

terms) 

• Fast Pay indicator 

• Matching terms (2-way, 3-way, 4-way) 

• Vendor ID number 

• Vendor name (legal, DBA or division) 

• DUNS + 4 number 

• NAICS code 

• SIC code 

• Approval date. 

FME-22 Define obligation types—Define the obligation types to be captured on 

obligation documents, based on budget object class (e.g., travel, payroll), 

agency source document (e.g., travel order, purchase order, grant) or other 

agency-specified criteria. 

FME-23 Validate CCR vendor name on obligations—Validate that the vendor name 

on an obligation is the same as the vendor name on the vendor file, for 

registered CCR vendors. 

FME-24 No related commitment—Record obligations when there is no related 

commitment. 

FME-25 Different vendors—Capture a different vendor on an obligating document than 

the vendor captured on a referenced commitment. 
Budgetary Resource Management Function 

Core Financial System Requirements 43

FME-26 Close obligations— Close obligation documents under the following 

circumstances: 

• By the system upon final payment for goods or services, or 

• By an authorized user. 

Upon the closing of an obligation, classify any de-obligation of excess funds by 

budgetary status (i.e., expired, unexpired, available for obligation or 

unavailable). 

FME-27 Records of call—Process, track, and control records of call against blanket 

purchase agreements. 

FME-28 Delivery orders—Process, track, and control delivery orders against contract 

limitations. 

To support the Funds Control/Advances activity, the Core financial system must provide 

automated functionality to do the following: 

FME-29 Advance payments—Record advance payments made, such as travel 

advances, contract prepayments, and grant advances. When recording an 

advance payment, reference an obligating document and bring forward all 

accounting information. In cases where no obligating document is available, 

reduce funds availability and create an obligating document to support the 

advance payment made. 

FME-30 Expenditures against advances—Record advance payment refunds by 

document or document line item. Update the advance balance. 

FME-31 Expenditures incurred—Record expenditures incurred against advance 

payments made, reducing the advance balance and liquidating the referenced 

obligation. 

Value-Added Requirements 

To add value to the Funds Control process, the Core financial system should provide 

automated functionality to do the following: 

FME-32 Additional obligation data—Capture the following other data fields on 

obligating documents: 

• Requester's name 

• Telephone number of requester 

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

• Contact name 

• COTR name 

• COTR telephone number 

• Comments. 

Funds Status Process 

The Funds Status process provides budgetary information to enable agency personnel to 

analyze, monitor, and adjust funding for programs throughout the fiscal year. 
Budgetary Resource Management Function 

Core Financial System Requirements 44

Mandatory Requirements 

To support the Funds Status process, the Core financial system must provide automated 

functionality to do the following: 

FMF-01 Status of Funds Report—Generate the Status of Funds Report. Parameter is 

the accounting period. Result is a report providing the following information for 

each allotment recorded by the agency: 

• Accounting classification elements 

• Total Allotment 

• Commitments 

• Obligations 

• Expenditures 

• Available Balance 

Available balance must equal the GL balance in the 4610 or 4620 account. 

Amounts should be cumulative from the beginning of the fiscal year through the 

accounting period specified. If reporting for the current period, amounts must 

be cumulative up through the current date. 

FMF-02 Status of Funds Query—Query status of funds. Parameters include 

accounting period, and allotment accounting classification. Result is a display 

providing the following information: 

• Accounting classification elements 

• Total Allotment 

• Commitments 

• Obligations 

• Expenditures 

• Available Balance (available balance must equal the balance in the 

4610 or 4620 account). 

Drill down from the commitments line, obligations line, and the expenditures line 

to the detailed transactions, documents, and document detail that support these 

lines. 

FMF-03 Contract/BPA Activity Report—Generate a contract/BPA activity report. 

Parameters include contract/BPA number accounting period and period covered 

(monthly, quarterly, fiscal year-to-date, or inception-to-date). Result is list of 

accounting activity (obligations, expenditures, disbursements, etc.) under the 

contract/BPA, with vendor information, period of performance, document 

numbers, delivery order/task order numbers, accounting classification 

information, transaction dates and amounts. Sorting options include transaction 

date, document type and accounting classification. 

FMF-04 Reimbursable Agreement Activity Report—Generate a reimbursable 

agreement activity report. Parameters include reimbursable agreement 

number, accounting period and period covered (monthly, quarterly, fiscal yearto-date, or inception-to-date). Result is a list of accounting activity 

(commitments, obligations, advances, expenditures, etc.) under the 

reimbursable agreement, with customer/vendor information, period of 

performance, document numbers, accounting classification information, 

transaction dates and amounts. Sorting options include transaction date, 

document type and accounting classification. 
Budgetary Resource Management Function 

Core Financial System Requirements 45

FMF-05 Budget query—Query budget information. Parameters include accounting 

classifications. Result is budgetary authority amounts (all types, as applicable to 

the fund type), spending activity (e.g., obligations, expenditures), and the 

available balance. Displayed amounts should be consistent with amounts 

derived using the U.S. SGL crosswalk to the SF-133. 

FMF-06 System assurance for funds availability—Validate that funds availability 

balances used for funds control and funds status reporting agree with the 

general ledger. 

FMF-07 MAX budget data—Maintain budget data needed to support OMB’s MAX A-11 

system requirements that agencies currently fulfill via their FACTS II 

submissions to FMS. 

FMF-08 MAX budget data reporting—Generate Excel files that are consistent with the 

presentation of the program and financing schedule and the object class 

schedule published in OMB Circular A-11.

Value-Added Requirements 

To add value to the Funds Status process, the Core financial system should provide automated 

functionality to do the following: 

FMF-09 Funds availability notification by exception—Notify the agency when funds 

availability is reduced based on the processing of agency-specified transaction 

types or sources (e.g., credit card payments and payroll). 

FMF-10 Funds availability notification by percent—Notify the agency when funds 

availability by TAFS or internal fund code reaches a pre-defined percent of the 

original total funding amount. 

FMF-11 Other MAX Budget Data Reporting—Generate Excel files that are consistent 

with the presentation of budget schedules published in OMB Circular A-11.
Core Financial System Requirements 46 

Payment Management Function 

The Payment Management function deals with accounts payable. Depending on an agency’s 

system architecture, specific activities relating to payments may be supported in Core by other 

systems that provide payment data to the Core financial system for control and management. 

For example, payroll systems usually trigger actual disbursements to employees through direct 

deposit or by check, and send only the expense and disbursement information to the Core 

financial system for recording the impact on the general ledger, funds control, and cost 

management processes. Likewise, loan and grant programs might be supported by systems 

that maintain their own information on payees and payments and send transaction data to the 

Core financial system. 

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

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

system to manage the actual payment process itself. For example, a travel system might 

calculate the amount to be paid on a travel voucher and send transactions to the Core financial 

system to record the expenses and a payable to the traveler. The Core financial system would 

then schedule the payment for disbursement and confirm that the disbursement has been 

made. 

The Payment Management function consists of the following processes (the prefixes assigned 

to the requirements are noted in parentheses): 

• Payee Information Maintenance (PMA) 

• Accounts Payable (PMB) 

• Invoicing (PMC) 

• Disbursing (PMD) 

• Payment Follow-Up (PME). 

Payee Information Maintenance Process 

The term “payee” is used here to include any entity to which disbursements may be made, for 

example, individuals and organizations providing goods and services, employees, grant 

recipients, loan recipients, and other government agencies. In an integrated system, payee 

information needed to make payments should be coordinated with information needed for other 

purposes and in other systems. For example, a company that provides goods and services to 

an agency should have a common identifier, such as a TIN, associated with it that is shared by 

the procurement and payment processes. With this common identifier, contract information and 

payment information can be linked, even if the addresses for ordering and paying are different. 

Furthermore, such information should also be available to the procurement and payment 

processes. 

Subpart 4.11 of the FAR prescribes policies and procedures for requiring contractor registration 

in the CCR database, the common source of vendor data for the Federal Government. Both 

current and potential government vendors are required to register in CCR in order to be 

awarded contracts by the government. The CCR validates the vendors’ information and 

electronically shares the data with the Federal agencies’ finance offices to facilitate paperless 
Payment Management Function 

Core Financial System Requirements 47

payments through EFT. Agencies’ Core financial systems must accommodate the data 

elements and definitions used in the CCR in order to facilitate this information exchange and to 

maintain current information on the vendors with which they conduct business. 

Mandatory Requirements 

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

provide automated functionality to do the following: 

PMA-01 Vendor information—Capture the following vendor information: 

• Vendor ID number (agency-assigned) 

• Vendor name (Legal) 

• Vendor name (DBA) 

• Vendor name (Division) 

• Vendor address 

• Business type (support CCR published business rules for business 

type: Federal govt., state govt., small business, etc.) 

• Organization type (support CCR published business rules for 

organization type: sole proprietorship/Individual; partnership, employee, 

etc.) 

• US or Non-US 

• Product Service codes 

• SIC code 

• NAICS code 

• Credit Card Vendor Indicator 

• DUNS number 

• DUNS + 4 number for each instance of banking information, for CCR 

vendors 

• Prompt Pay indicator and type, or payment terms 

• IRS 1099 indicator 

• IRS W-2 indicator 

• CCR registration indicator (required, exempt) 

• CCR registration status (active or expired) 

• Comment field 

• Active/Inactive indicator 

• Debarment indicator 

• Debarment start and end dates 

• GFRS and FACTS I trading partner codes for Federal vendors 

• ALC (for Federal vendors) 

• Disbursing Office Symbol (for Federal vendors) 

• Default payment method, e.g., check, EFT 

• Alternate payment methods 

• TIN 

• Foreign address indicator 

• Four remittance addresses, for check payments (including street 

address, city, state, zip code, and country) 

• Contact name, telephone number and e-mail address for each 

remittance address 

• Four instances of EFT banking information (including account number; 

account type (e.g., checking, savings); and RTN) 

• Four instances of EFT bank name and address 

• Contact name, telephone number and e-mail address for each instance 
Payment Management Function 

Core Financial System Requirements 48

of EFT banking information, accommodating contact types defined as 

mandatory" in CCR business rules. 

PMA-02 Third-party vendor information—Capture third-party payee information 

associated a primary vendor including: 

• Payee name 

• Payee point of contact 

• Payee telephone number 

• Payee email address 

• Remittance address or/banking information (account number, account 

type, RTN). 

PMA-03 Vendor/customer relationships—Associate vendor and customer records that 

represent the same entity. 

PMA-04 CCR updates to vendor data—Import CCR data. Update vendor data for 

relevant changes contained in the CCR's daily extract files. Support the data 

definitions (e.g. data types; field names; field lengths) used in CCR for fields 

that are common to the CCR and the Core vendor file. 

PMA-05 CCR company name change exception report—Identify updated CCR 

company names (legal, DBA or division) that are different than vendor names 

on obligations. Generate an exception report to notify agencies of contracts that 

require modification. Result is a list of selected vendor numbers, details of the 

CCR company name change, related obligation document numbers and 

associated vendor names. 

PMA-06 Agency updates to CCR vendor data—Prevent the agency from manually 

updating CCR vendor data for vendors required to register in the CCR. 

PMA-07 DUNS number to TIN association—Associate multiple DUNS numbers with a 

single TIN. 

PMA-08 DUNS+4 to DUNS number association—Associate multiple DUNS plus 4 

numbers to a single DUNS number. 

PMA-09 Banking information to DUNS+4 number association—Associate one 

DUNS+4 with each instance of a vendor’s CCR banking information. 

PMA-10 Validate vendor TINs—Validate for duplicate TIN when adding or updating 

vendor records. Notify the agency when duplicate TINs are identified. Allow the 

error message to be overridden. 

PMA-11 Vendor file query—Query vendor file. Parameters include: 

• Vendor number 

• Vendor legal name 

• Vendor DBA Name 

• Vendor Division 

• Vendor TIN 

• DUNS number 

• IRS 1099 indicator. 

Result is a display of all vendor data for the specified vendor. Output options 
Payment Management Function 

Core Financial System Requirements 49

include an Excel formatted data file. 

PMA-12 Vendor file history—Maintain a history of changes made to vendor 

information. Capture name of data item changed, before and after values, entry 

date and time and ID of user who made the change. 

PMA-13 Vendor history query—Query vendor history. Parameters include vendor 

number, change date range. Results include date and time of change, ID of 

user who made the change, item name, before and after data values. 

PMA-14 Criteria for deactivating vendors—Deactivate vendors on demand or based 

on agency-specified length of time with no activity. 

PMA-15 Vendor deactivation edit—Prevent the deactivation of vendors that have 

unliquidated obligations or unpaid invoices in the system. 

PMA-16 Debarred vendors—Prevent new obligations that reference inactive or 

debarred vendors. 

PMA-17 Expired CCR registrations—Prevent new obligation and payment to vendors 

with expired CCR registrations. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Accounts Payable Process 

This process recognizes and records accounts payable due to another entity in the near term. 

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

Mandatory Requirements 

To support the Accounts Payable process, the Core financial system must provide automated 

functionality to do the following: 

PMB-01 Receipt and acceptance—Record full or partial receipt and/or acceptance of 

goods and services by document line item. This is to include the receipt and/or 

acceptance of partial quantities of goods and services on each document line. 

PMB-02 Accrued liability upon receipt—Record an accrued liability and the 

reclassification of the order from delivered to undelivered upon receipt of goods 

or services. 

PMB-03 Liquidate advance/prepaid expense—Liquidate advance or prepaid expense 

when recording an accrued liability (receipt of goods or services). 
Payment Management Function 

Core Financial System Requirements 50

PMB-04 Receipt document data—Capture the following additional information on 

receipt documents (receiving reports): 

• Receiving official 

• Dates products were delivered or services were provided 

• Quantity/amount received 

• Vendor ID number and name 

• Ship to locations. 

PMB-05 Acceptance data—Capture the following additional information on the 

acceptance of goods/services: 

• Acceptance official 

• Dates products were delivered or services were provided 

• Date products/services accepted 

• Quantity/amount accepted 

• Date products/services rejected 

• Quantity/amount rejected 

• Vendor ID number and name 

• Ship to locations. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Invoicing Process 

The Invoicing process supports the recording of invoices received from vendors and the 

matching of these documents to related obligation, receipt, and acceptance documents. The 

matching process ensures that payments are made in accordance with contract terms and 

applicable regulations, including 5 CFR 1315. Once matched and approved, invoices are 

warehoused in the Core financial system and await payment scheduling that occurs when their 

payment due dates are reached. Adequate internal controls must be in place to verify that 

goods and services paid for were actually ordered, received, and accepted; that proper due 

dates and payment amounts are computed; and that duplicate payments are prevented. 

Mandatory Requirements 

To support the Invoicing process the Core financial system must provide automated 

functionality to do the following: 

PMC-01 Invoice data—Capture the following additional information on invoice 

documents: 

• Vendor invoice number or account number 

• Invoice date 

• Invoice receipt date 

• Vendor ID number and name 

• Contract line/subline number 

• Name and address of contractor official to whom payment is to be sent 

• EFT banking information (account number, account type, RTN) 

• DUNS+4 number for CCR vendors 

• Payment terms (including discount for prompt payment) 

• Shipping terms (e.g., shipment number and date of shipment) 

• Vendor contact name and telephone number 
Payment Management Function 

Core Financial System Requirements 51

• Dates products were delivered or services were provided 

• User comments 

• Date invoice returned to vendor 

• Date improper invoice resubmitted by vendor. 

PMC-02 Vendor invoice number—Capture a vendor invoice number of up to 30 

characters or the current requirement of I TFM-6-5000. Report the complete 

number on all payment files, reports and query results. 

PMC-03 Invoice line items—Capture up to 9,999 document line items per invoice 

document. 

PMC-04 Duplicate vendor invoice edit criteria—Define the criteria to be used in 

editing for duplicate vendor invoices, including one or more of the following: 

agency code, vendor number, vendor account number, vendor TIN, vendor 

invoice number, invoice date, invoice amount, referenced obligation document 

number. 

PMC-05 Validate for duplicate vendor invoices—Validate for duplicate vendor 

invoices based on the agency-defined editing criteria. 

PMC-06 Validate invoices from CCR vendors—Validate invoices from registered CCR 

vendors for the following CCR vendor information: 

• Active status 

• Vendor name on invoice or referenced obligation same as CCR 

company name (legal, DBA or division) 

• Banking information on invoice or referenced obligation same as 

banking information on vendor file. 

PMC-07 Validate payments to CCR vendors—At the time of preliminary payment 

scheduling, validate payments to registered CCR vendors for the following CCR 

vendor information: 

• Active status 

• Vendor name same as CCR company name (legal, DBA or division) on 

vendor file 

• Banking information same as banking information on vendor file. 

Hold payments that fail these validations from inclusion in the final payment 

schedules. 

PMC-08 Matching options—Match invoices to obligations, receiving reports and 

acceptance information by document line item and quantity. Perform two-way 

matching (obligation and invoice, or obligation and receipt), three-way matching 

(obligation, simultaneous receipt/acceptance and invoice), and four-way 

matching (obligation, receipt, acceptance and invoice). Prevent the payment of 

invoices until the matching process is complete. 

PMC-09 Invoices for partial amount of quantities received and accepted—Process 

invoices for payment of partial quantities received and accepted. 
Payment Management Function 

Core Financial System Requirements 52

PMC-10 Validate invoice period of performance—Validate that invoice dates that 

products were delivered or services were performed are within the period of 

performance dates on the referenced obligation. 

PMC-11 Validate invoice delivery/performance dates—Validate that the invoice dates 

that products were delivered or services were performed are dates for which the 

products/services have been received and accepted. Prevent the processing of 

invoices with unmatched dates and the duplicate processing of invoices with 

matched dates. 

PMC-12 Final payment—Record an invoice as a "partial" or "final" payment of the 

referenced obligation. If "final", deobligate any unliquidated balance and close 

the obligation and receipt. 

PMC-13 Adjust payment amounts—Record additional shipping and other charges to 

adjust the payment amount, if they are authorized and within variance 

tolerances. 

PMC-14 Set up recurring payments—Define recurring payments in the system and 

schedule items (e.g. contracts, leases, etc.) for payment on an interval 

determined by the agency (i.e., weekly, bi-weekly, monthly, quarterly or other 

specified number of days). Capture the actual payment dates on the individual 

payment records. 

PMC-15 Update recurring payment terms—Update recurring payment information for 

changes in agreement terms, amounts, frequency, etc. 

PMC-16 Warehouse Invoices—Warehouse approved invoices for future scheduling. 

PMC-17 Define reason codes for invoice processing errors—Define reason codes 

and related descriptions for invoice processing errors in the following 

categories: 

• Advantageous discount lost 

• Interest paid, and 

• Improper payment made. 

For example, DL01, Discount Lost because invoice misplaced. 

PMC-18 Define reason codes for invoice processing actions—Define reason codes 

and related descriptions for invoice processing actions in the following 

categories: 

• Invoice adjusted 

• Invoice held from payment schedule 

• Invoice cancelled. 

For example, PH01, Payment Held, Vendor CCR status expired, IA03, Invoice 

Adjusted, Unauthorized shipping charges deducted, IC02, Invoice cancelled, 

Invoice re-submitted with new invoice number. 

PMC-19 Define reason codes for improper invoices—Define reason codes and 

related descriptions for improper invoices. For example, IP01- Improper Invoice, 

X data missing. 
Payment Management Function 

Core Financial System Requirements 53

PMC-20 Capture reason codes for invoice processing errors and actions—Capture 

reason codes and related descriptions for the following types of invoice 

processing errors and actions: 

• Advantageous discount lost 

• Interest paid 

• improper payment made 

• Invoice adjusted 

• Invoice held from payment schedule 

• Invoice cancelled. 

PMC-21 Capture reason codes for improper invoices—Capture reason codes and 

related descriptions for improper invoices held or suspended (i.e., failed 

validations). 

PMC-22 Notify vendor of return of improper invoice notice—Generate a letter or email to the vendor notifying them of the return of an improper invoice, upon the 

recording of an improper invoice reason code. Include the following information 

in the notice: 

• Vendor invoice number and date 

• Reason code(s) and description(s) of invoice discrepancies 

• Date of notice. 

• Request for a corrected invoice 

• Name, title, telephone number and e-mail address of Agency contact 

person. 

PMC-23 Import CCR vendor updates—Import vendor updates from the CCR system 

and release previously suspended invoices and payment vouchers for the 

following: 

• Vendor status change from expired to active 

• Vendor name on document or referenced obligation now the same as 

CCR company name (legal, DBA, or division) 

• Banking information on document or referenced obligation now the 

same as banking information on vendor file. 

Calculate payment due dates for released invoices and re-calculate payment 

due dates for released payment vouchers. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Disbursing Process 

This process supports activities required to make payments that were warehoused or to record 

payments made by other systems. The Core financial system must provide the capability to 

prepare requests for disbursement (payment schedules) and to create and transmit payment 

files in the formats required by Treasury for the initiation of EFTs and check payments for 

agencies for which Treasury does the actual disbursing. Some agencies have delegated 

disbursing authority and can print checks or initiate electronic transfers themselves. Agencies 

with delegated disbursing authority must comply with the requirements contained in I TFM Part 

4 and all applicable requirements in this function. 
Payment Management Function 

Core Financial System Requirements 54

Federal payment regulations are documented in several different sources, including 5 CFR 

1315 (codification of OMB Circular A-125, Prompt Payment), which specifies government policy 

for payments made to vendors against contracts. It states, in part, that agencies must make 

payments on time; pay interest when payments are late; and take discounts only when 

payments are made on or before the discount date and when it is advantageous to the 

government. 

Mandatory Requirements 

To support the Disbursing process, the Core financial system must provide automated 

functionality to do the following: 

PMD-01 Prompt payment—Calculate the due date of vendor payments in accordance 

with 5 CFR 1315, including but not limited to the following factors: 

• Commodity type 

• Contract terms 

• Invoice receipt 

• Goods/services receipt and acceptance 

• Fast Payment 

• Discount terms 

• Accelerated payment methods 

• Governmentwide commercial purchase card rebates 

• Improper invoices returned more than 7 days after receipt. 

PMD-02 Invoices with multiple due dates—Calculate multiple due dates when items 

on an invoice have different payment terms. 

PMD-03 Override vendor record payment terms on obligation—Capture payment 

terms on obligations that are different than those specified on the associated 

vendor record. 

PMD-04 Validate invoice payment terms—Validate payment terms on invoices against 

the payment terms on the related obligating documents. Calculate the most 

advantageous terms, store them on the invoice documents, and use them to 

calculate the payment due dates and amounts. 

PMD-05 Payment due date override—Capture an agency-specified payment due date 

in place of a system-calculated due date (i.e. payment due date override). 

PMD-06 System calendar—Define dates (e.g., weekends, Federal holidays) for which 

payments cannot be scheduled. Prevent payment scheduling that falls on 

agency-excluded dates. 

PMD-07 Advantageous discounts—Calculate whether taking a discount is 

economically justified as defined in I TFM-6-8040. 

PMD-08 Calculate payment amounts—Calculate amounts to be disbursed, including 

discounts, interest, and penalties, in accordance with 5 CFR 1315. Record U.S. 

SGL prescribed transactions for discounts taken, and interest, penalties and 

principal paid. 
Payment Management Function 

Core Financial System Requirements 55

PMD-09 Use Treasury interest rate tables—Calculate payment amounts and due 

dates using Treasury rate tables, i.e., Prompt Pay Act Interest rate and Current 

Value of Funds rate. 

PMD-10 Apply interest and discounts—Apply interest and discount amounts across 

multiple accounting lines on an invoice using the ratio of the original invoice 

accounting line amounts to the invoice total. 

PMD-11 Record late payment interest—Define the default for recording late payment 

interest, i.e., to the same accounting classification as the original payment or to 

another specified accounting classification in the same fund as the original 

payment. 

PMD-12 Numbering payment schedules—Maintain a sequential numbering system for 

scheduling payments to be made by the disbursing office. Define different 

schedule number ranges for different payment types, such as travel schedules, 

transportation schedules, payroll schedules, vendor schedules, etc. Generate 

appropriate and unique schedule numbers for the payments scheduled for 

disbursement. 

PMD-13 Payment certification—Identify payments to be disbursed in a particular 

payment cycle based on their due date. Provide for on-line review and 

certification by an authorized certifying officer, including the holding of individual 

payments from inclusion in the payment schedule. 

PMD-14 Payment based on receipt—Generate a payment if the receiver information 

matches the obligation, under related 2-way matching option. 

PMD-15 Disbursements-in-transit—Record disbursements-in-transit entries when 

payments are certified. 

PMD-16 Do not disburse to negative cash position—Validate that invoices selected 

for payment will not disburse a fund into a negative cash position. Notify the 

agency of invoices that fail this edit. 

PMD-17 Manual payments—Select and process warehoused invoices for manual 

payment. 

PMD-18 Statistical sample of invoices query—Query preliminary payment schedule 

data. Identify a sample of invoices for certification based on agency-defined 

sampling criteria and the payment due date. Result is a list of invoice document 

numbers with drill down to invoice details, including data required on a proper 

vendor invoice per 5 CFR 1315. 

PMD-19 Distribute invoice payment—Distribute the payment of a single invoice to 

multiple bank accounts. 

PMD-20 Payment files—Export check and EFT payment files in the current Treasury 

FMS defined formats. 
Payment Management Function 

Core Financial System Requirements 56

PMD-21 ACH payment formats—Export Automated Clearing House (ACH) payment 

files in the following formats: 

• Corporate Trade Exchange (CTX) 820 file 

• CTX Flat File 

• Cash Concentration or Disbursement (CCD) 

• CCD Plus Addendum (CCD+) 

• Prearranged Payment and Deposit (PPD) 

• Prearranged Payment and Deposit Plus Addendum (PPD+). 

PMD-22 NACHA payment formats—Export NACHA payment formats for Non-Treasury 

DOs. 

PMD-23 Treasury edits on EFT files—Validate that EFT payment file data submitted to 

Treasury will pass the following edits: 

• RTNs exist in the Financial Organization Master File (FOMF) or other 

verified update file, for the financial institution. 

• RTNs pass the Modulus 10 check on the validity of the check digit. 

• RTNs for domestic banks are nine-digits, numeric-only, and not all 

zeroes 

• RTNs for foreign banks are eight-digits, alpha-numeric, and not all 

zeroes 

• ALCs are eight-digits and numeric only. 

• Taxpayer Identification Numbers are nine-digits, numeric-only, and not 

all zeroes. 

PMD-24 Treasury edits on banking information—Prevent the creation of an EFT 

(Fedwire, ACH or CTX) payment that does not contain a RTN, bank account 

number and account type (checking or savings). 

PMD-25 ACH employee payments—Validate that employee ACH payments are 

generated only as PPD or PPD+ payments. 

PMD-26 ACH vendor payments—Validate that vendor ACH payments are generated 

only as CCD, CCD+ or CTX formats. 

PMD-27 CTX vendor payments—Generate CTX payment files that meet the following 

specifications: 

• Reflect balanced transactions (sum of all remittance records equals the 

transaction total). 

• Include a valid settlement date (next business day or later). 

• Accommodate credit memos. 

PMD-28 Treasury edits on CTX files—Validate that CTX vendor payments contain 

properly structured remittance information, as specified in the CTX payment 

file's remittance record format. 

PMD-29 ECS payments—Schedule and disburse U.S. dollar payments (SF 1166) 

through the Treasury's ECS, containing up to the limit of 60 payments per 

schedule (for non-summary schedules) and 100 schedules for each ECS 

terminal per day. 
Payment Management Function 

Core Financial System Requirements 57

PMD-30 SPS payments—Schedule and disburse U.S. dollar payments (SF 1166) 

through the Treasury's SPS containing up to the limit of 60 payments per 

schedule (for non-summary schedules). 

PMD-31 TAFS information on Treasury payment files—Capture the TAFS associated 

with each payment in ECS, SPS and Bulk Vendor/Miscellaneous payment files. 

PMD-32 Payment schedule totals by TAFS—Generate totals by TAFS on each ECS 

and SPS payment file. 

PMD-33 ECS and SPS payment files for multiple ALCs—Combine ECS and SPS 

payment files with multiple ALCs into single files for transmission to Treasury. 

Include summary totals (items and dollars) by ALC and TAFS and for the entire 

file for certification purposes. 

PMD-34 Bulk check payment files for multiple payee types—Generate one bulk 

check payment file regardless of payee type (employee or vendor). 

PMD-35 Consolidate multiple payments to payee—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). Provide the option to issue separate checks to a 

payee. 

PMD-36 Remittance information on Treasury payment files—Generate the following 

identification on each remittance, as allowed for by Treasury payment file 

formats and NACHA edits: 

• Vendor invoice number(s) or account number 

• Obligating document number or other reference number 

• Discount, interest and offset amounts. 

PMD-37 Prompt pay—Capture prompt payment information required by 5 CFR 1315, 

including discounts taken, discounts lost, and interest paid. 

PMD-38 Prompt Pay Metric Query—Query disbursement data. Parameters include 

accounting period range, disbursement type(s) to be included. Provide an option 

to exclude credit card transactions. Result is the total number of payments 

made on time by disbursement type. Query returns total number of on-time and 

late payments made based on due date. 

PMD-39 Payments GL entries—Record the U.S. SGL prescribed general ledger entries 

for the payment of advances, prepaid expenses, loans, and grants. 

PMD-40 Imprest funds—Record the establishment and replenishment of imprest funds. 

PMD-41 Imprest funds and third party U.S. SGL entries—Record purchases made 

through the use of imprest funds and third-party drafts. 

PMD-42 Simultaneous obligation and payment—Record "obligate and pay" 

transactions where obligation and payment occur simultaneously. 
Payment Management Function 

Core Financial System Requirements 58

PMD-43 Payments for other agencies—Record payments made on behalf of another 

agency, citing the other agency's funding information. 

PMD-44 Interfaced payment entries—Record payment transactions from other 

systems, such as payroll and travel. Identify whether or not disbursement has 

already been made, and record the U.S. SGL prescribed general ledger entries. 

Schedule those disbursements not already made for payment through the Core 

financial system. 

PMD-45 IPAC payments and collections—Capture the following additional information 

for IPAC transactions: 

• Sender/originator TAS 

• Sender ALC 

• Sender SGL account 

• Sender BETC 

• Sender DO symbol 

• Sender DUNS number 

• Sender DUNS+4 number 

• Customer/receiver TAS 

• Customer ALC 

• Customer SGL account 

• Customer DUNS number 

• Customer DUNS+4 number 

• Customer BETC 

• Customer Department Code. 

PMD-46 IPAC reclassifications—Capture the following additional information with IPAC 

reclassifications: 

• Original DO symbol 

• Voucher number. 

PMD-47 IPAC posted SGL transactions—Capture SGL comments with IPAC 

disbursement and collection transactions. 

PMD-48 IPAC bulk file export—Export a bulk file in the currently required format for 

uploading the following interagency transactions to IPAC: 

• Payment 

• Collection 

• Adjustment 

• Zero dollar 

• SGL posting. 

PMD-49 IPAC GL entries—Record transactions to reflect disbursement activity initiated 

by other agencies and recorded in IPAC. 

PMD-50 Credit memo processing—Record vendor credit memoranda as accounts 

receivable or negative accounts payable. 
Payment Management Function 

Core Financial System Requirements 59

PMD-51 Process credit memoranda offsets—Reduce payments to vendors to satisfy 

outstanding credit memos. Record the collection for the amount offset and 

reduce expenditures under the related obligation. If a credit is not fully liquidated 

by one payment, maintain the balance of the credit for application against a 

future payment. 

PMD-52 Credit memoranda offsets across funds—Record credit memo offsets 

against subsequent payments to the same vendor from the same or a different 

funding source. 

PMD-53 Notify vendors of credit memoranda offsets—Notify vendors of payments 

that have been offset by credit memos. Specify the invoice number, invoice 

amount, offset amount, payment amount and payment date. 

PMD-54 Credit memo offset exclusions—Prevent agency offset of vendor payments 

based on agency-defined criteria such as accounting classification elements, 

vendor number, and vendor CCR business type. 

PMD-55 Reverse scheduled payments—Generate the reversal of an entire payment 

schedule or a single payment within a payment schedule based on a single, 

online action. Generate disbursement-in-transit reversal entries, record the reestablished accounts payable, and update related payment records. 

PMD-56 Payments Referencing Cancelled Funds—For payments that reference 

obligations in cancelled funds, bring forward accounting and non-financial 

information from the original obligation document to an invoice in the current 

year. 

Value-Added Requirements 

To add value to the Disbursing process, the Core financial system should provide automated 

functionality to do the following: 

PMD-57 Calculate foreign payment amounts—Calculate payments to foreign vendors 

based on current exchange rates. 

PMD-58 Foreign payment file formats—Generate foreign payment file formats, 

including International Direct Deposit (IDD). 

Payment Follow-Up Process 

This process allows for agency follow-up on payments pending and accomplished. Core 

financial systems must capture the information needed to track invoices through various stages 

of processing, to respond to vendor inquiries, and to report payment activity to external entities 

such as the IRS. 

Mandatory Requirements 

To support the Payment Follow-Up process, the Core financial system must provide automated 

functionality to do the following: 
Payment Management Function 

Core Financial System Requirements 60

PME-01 Invoice Status Query—Query invoice status information. Parameters include: 

vendor number, vendor name (legal, DBA or division), TIN, DUNS number and 

vendor invoice number. List the selected invoices, their due dates, the dates 

that the following stages were reached and the number of days between each 

date: 

• Invoice received 

• Invoice suspended due to validation errors 

• Invoice held 

• Invoice returned to vendor 

• Invoice resubmitted by vendor 

• Invoice approved and warehoused 

• Invoice scheduled for payment (disbursement-in-transit) 

• Invoice paid. 

PME-02 Payment history—Maintain a history of the following information for each 

payment made: 

• Accounting classification information 

• ALC 

• TAS/BETC 

• Referenced obligation document number(s) 

• Source document number(s) (reimbursable agreement number, BPA 

and associated BPA call number, Contract and associated delivery/task 

order number, and grant number) 

• Total invoice amount 

• Payment voucher document number 

• Vendor invoice number 

• Vendor information (number, name, address, TIN, and DUNS+4 

number for CCR vendors) 

• Payment address or bank account number and routing number 

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

• Payment amount 

• Interest paid 

• Discount taken 

• Internal offset made 

• Date due 

• Date paid. 

PME-03 EFT Metric Query—Query payment data. Parameter is accounting period 

range. Result is number of payments and percent of total by payment method 

(EFT vs. check). 

PME-04 Unmatched Invoice Document Lines Report—Generate the Unmatched 

Invoice Document Lines Report. Result is a list of selected invoice document 

numbers with document lines not matched to obligations, receipts, and/or 

acceptance, as required by the matching terms of the obligation (2, 3 or 4-way 

matching). Report the following information for each invoice document listed: 

• Vendor number and name 

• Invoice number 

• Invoice date 

• Invoice receipt date 

• Invoice amount 

• Referenced obligation number 
Payment Management Function 

Core Financial System Requirements 61

• Document number 

• Document line number(s) 

• Document line amount(s) 

• Document line accounting classification 

• Unmatched document(s) (obligation, receipt and/or acceptance) 

• Age, in days, that invoice document line has been unmatched. 

Sorting options include document number, vendor number, vendor name, 

accounting classification and unmatched age. 

PME-05 Late Payments Pending Report—Generate a report of payment vouchers past 

their due date, as of current system date. List the selected payment vouchers 

with the following information: 

• Payment voucher number 

• Referenced obligation number 

• Vendor invoice number 

• Vendor number and name 

• Invoice date 

• Invoice amount 

• Invoice due date 

• Number of days late. 

Sort options include number of days late and vendor number. 

PME-06 IRS 1099 Forms—Generate IRS Forms 1099-MISC, 1099-INT and 1099-G in 

accordance with IRS regulations and in current IRS acceptable format, including 

hard copy and electronic form (i.e., bulk file). For example, produce an IRS 

Form 1099-MISC for payments of $600 or more to a sole proprietor for services 

rendered. 

PME-07 IRS 1099-MISC reporting of payments to third parties—Report third-party 

payments on the principal vendors' IRS 1099-MISC forms. 

PME-08 IRS 1099-MISC query—Query IRS 1099-MISC information. Parameters include 

calendar year, vendor name (legal or DBA), TIN and DUNS+4 number. Result is 

details supporting IRS 1099-MISC reporting. 

PME-09 Statistical sample of payments query—Query payments data. Identify a 

sample of payments for review based on agency-defined sampling criteria and 

the date(s) of payment. Result is a list of invoice document numbers with drill 

down to invoice details, including data required on a proper vendor invoice per 5 

CFR 1315. 

Value-Added Requirements 

To add value to the Payment Follow-Up process, the Core financial system should provide 

automated functionality to do the following: 

PME-10 Travel payment notification—Generate e-mail notification to employees of 

travel payments made by disbursing offices. 
Core Financial System Requirements 62 

Receivable Management Function 

Receivables are established to account for amounts due from others as the result of 

performance of services by the agency, delivery of goods sold, the passage of time (e.g., 

interest earned), overpayments, or other actions. Receivables are accounted for as assets until 

funds are collected, or determined to be uncollectible in whole or in part. In addition, some 

receipts may be collected without the prior establishment of a receivable, as in the case of 

goods sold for cash. 

Federal debt management regulations are documented in several different sources. The Debt 

Collection Act of 1982 authorized agencies to charge interest, penalties, and administrative 

costs against delinquent non-Federal debtors, and on debts due from state and local 

governments. OMB Circular A-129, Policies for Federal Credit Programs and Non-Tax 

Receivables, prescribes policies and procedures for collecting non-tax receivables and sets 

standards for servicing these receivables and for collecting delinquent debt. DCIA established a 

framework for improved Federal debt collection by requiring agencies to take prompt action to 

recover debts, screen potential borrowers related to credit programs, and resolve outstanding 

debt through various options. DCIA centralized the management of delinquent non-tax 

obligations overdue by 180 days in the Department of the Treasury for administrative offset and 

cross-servicing. In addition, DCIA allows referral of the delinquent debt to the Department of 

Justice for litigation. To remain in compliance with these requirements, Federal agencies, unless 

otherwise precluded from statute, must accurately and timely report on receivables by 

submitting all required information on the TROR. 

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 data requirements, such as loan programs, grant programs, or fee-for-service 

programs. Servicing and collection of 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. Servicing of payroll collections (benefits, 

judgments, etc.), however, should be maintained in the payroll system and made available to 

the Core system for recording the general ledger impact. 

The Receivable Management function includes recording, billing, monitoring, and collecting 

amounts due the government whether previously established as a receivable or not. These 

activities must be supported by aging schedules, exception reports, and reports used to monitor 

due diligence efforts. 

The Receivable Management function consists of the following processes (the prefixes 

assigned to the requirements are noted in parentheses): 

• Customer Information Maintenance (RMA) 

• Receivables and Billing (RMB) 

• Debt Management (RMC) 

• Collections and Offsets (RMD). 
Receivable Management Function 

Core Financial System Requirements 63

Customer Information Maintenance Process 

The word “customer” is used here to include any entity that owes a debt to the agency, including 

contractors, employees, grantees, loan recipients, and other government agencies. Agency 

payees or vendors may become customers of the agency, in the event that duplicate or 

overpayments occur. 

The Customer Information Maintenance process involves the maintenance of customer 

information (name, address, etc.), identification of the type of customer from which collection is 

due, and the recording of trading partner codes used in the elimination of intra-governmental 

activity from financial statements, as well as other critical information related to the customer 

that is needed for receivable processing, maintenance, and collection. The process ensures that 

customer TINs are captured in order to report overdue receivables for potential offset and to 

provide for IRS Form 1099 reporting of debts written off. 

Mandatory Requirements 

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

provide automated functionality to do the following: 

RMA-01 Customer information—Maintain customer information to support receivable 

management processes including the following: 

• Customer name 

• Customer ID number 

• Customer type (Federal agency, foreign/sovereign, state/local 

government, commercial, or consumer) 

• Billing method (IPAC, 1081, paper bill, or other) 

• TIN 

• Customer address 

• Customer contact name 

• Customer contact telephone number 

• Customer contact e-mail address 

• Federal vs. Non-Federal indicator 

• GFRS and FACTS I Trading Partner codes (for Federal customers) 

• ALC (for Federal customers) 

• IRS 1099-C indicator 

• Third-party payer name 

• Third-party payer address 

• Third-party payer contact name 

• Third-party payer contact telephone number 

• Comment field 

• DUNS+4 number 

• Active/Inactive indicator 

RMA-02 Validate Customer TINs—Validate TINs when adding or updating customer 

records. Notify the agency when duplicate TINs are identified. Allow the error 

message to be overridden. 

RMA-03 Customer query—Query customer file. Parameters include: 

• Customer number 

• Customer name 

• Customer TIN 
Receivable Management Function 

Core Financial System Requirements 64

• DUNS+4 number 

• IRS 1099-C indicator. 

Result is a display of all data for the specified customer. 

RMA-04 Customer file history—Maintain a history of changes made to customer 

information. Capture name of data item changed, before and after values, entry 

date and time and ID of user who made the change. 

RMA-05 Customer history query—Query customer history. Parameters 

include customer number, change date range. Results include date and time of 

change, ID of user who made the change, item name, before and after data 

values. 

RMA-06 Criteria for deactivating customer—Deactivate customers on demand or 

based on agency-specified length of time with no activity. 

RMA-07 Customer deactivation edit—Prevent the deactivation of customers that have 

unliquidated receivables in the system. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Receivables and Billing Process 

The Receivables and Billing 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 Receivables and Billing process, the Core financial system must provide 

automated functionality to do the following: 

RMB-01 Record receivables—Record accounts receivable and corresponding 

revenues, expense reductions, advance/prepayment reclassifications, or other 

offsets. 

RMB-02 Receivable adjustments—Record adjustments to receivables and capture a 

reason and description on each adjustment. 

RMB-03 Receivable type—Capture an agency-defined receivable type on receivable 

documents to identify the activity which generated the receivable, such as: the 

sale of goods or services, overpayments, unused advances subject to refund, 

fees and fines. 

RMB-04 Receivable document data—Capture the following additional information on 

receivable documents: 

• Baseline receivable date (used to properly age the receivable and 

determine the delinquency date) 

• Customer ID number 

• Reimbursable agreement number. 
Receivable Management Function 

Core Financial System Requirements 65

RMB-05 Converted receivables—Capture the original baseline receivable date on 

receivables converted from legacy systems, in order to properly age the 

receivable. 

RMB-06 Non-reimbursable billings—Generate bills to non-reimbursable customers 

based on receivables recorded. Include the following information on the bills: 

• Customer name 

• Customer address 

• Customer contact name 

• Agency contact name, office, address and telephone number 

• Date due. 

RMB-07 Reimbursable agreement billings—Calculate billing amounts and generate 

bills to customers based on reimbursable agreement billing terms, such as: 

• Percentage of work completed 

• Accrued expenditures 

• Actual costs incurred (direct and indirect using data from the cost 

management system). 

Include the following information on the bills: 

• Customer name 

• Customer address 

• Customer contact name 

• Agency contact name, office, address and telephone number; and 

• Date due. 

RMB-08 Reimbursable agreement billing limits—Monitor billing limits on a 

reimbursable agreement. Reject, warn or inform the agency when limit is 

exceeded. 

RMB-09 Scheduled billings—Generate bills based on pre-defined fee schedules or 

payment schedules. 

RMB-10 Bills to third-party payers—Generate bills to third party payers as responsible 

debtors. 

RMB-11 Bill types—Customize the text and data elements to be displayed on systemgenerated bills, by customer type, receivable type, or billing method. For 

example, an IPAC bill for the sale of goods and services would need to contain 

different supporting text than a bill to an employee for an overpayment. 

RMB-12 Bill data—List principal, interest, penalties, and administrative charges 

separately on a bill and provide a description of each. 

RMB-13 Additional bill data—Include advances and prior collections received on bills. 

RMB-14 Bill forms—Generate bills in hard-copy format, including Standard Forms 1080 

and 1081. 

RMB-15 Derive bill date—Derive the bill date from the system date. Allow for override. 
Receivable Management Function 

Core Financial System Requirements 66

RMB-16 Bill number and date—Capture a unique bill number and a bill date on systemgenerated bills. 

RMB-17 Consolidating receivables—Consolidate multiple receivables for a customer 

onto one bill retaining identification of each receivable separately within the bill. 

RMB-18 Receivable status—Update receivable status from unbilled to billed when bills 

are generated. Associate the receivable with the bill number and bill date. 

RMB-19 Manual bills—Capture information from manually prepared bills. Update 

receivable document (e.g., change status of receivable from unbilled to billed) 

with manual bill information. 

RMB-20 Returned checks—Re-establish a receivable when a check collection is 

cancelled due to insufficient funds or a when a chargeback is recorded. 

Capture the original baseline receivable date and update receivable status from 

billed to unbilled. 

RMB-21 Reschedule receivables—Reschedule existing receivables to be paid under 

installment plans. 

RMB-22 Multiple rescheduling—Reschedule a receivable multiple times. 

RMB-23 Amortization schedule—Generate a Debt Repayment Amortization Schedule. 

Parameters include the receivable number, final due date, begin date, 

frequency of payments, and interest rate. Result is an amortization schedule 

that displays the original amount of debt, payment dates, amount of incremental 

payments, and balance remaining after each payment for debt being paid under 

an installment plan or rescheduled debt. 

RMB-24 Customer account statements—Generate Customer Account Statements. 

Parameters include customer type, customer ID number, customer name, and 

time period (month, quarter, year-to-date). Result is a statement for each 

customer that includes: 

• Statement date 

• Customer ID number 

• Customer name 

• Customer address 

• Customer contact name 

• Agency name 

• Agency contact name 

• Agency contact phone number 

• Agency contact email address 

• Balance brought forward 

• Receivables established (including due dates) 

• Interest 

• Penalties 

• Administrative costs 

• Adjustments made 

• Collections received (identify principal, interest, penalties, and 

administrative charges separately to indicate how collections were 

applied) 
Receivable Management Function 

Core Financial System Requirements 67

• Outstanding receivable balance. 

Provide agency the option to generate customer statements in Excel format. 

RMB-25 Outstanding receivable balance query—Query outstanding receivable 

balance. Parameter is the receivable document number. Result is the original 

amount of the receivable, the current outstanding amount of the receivable and 

a detailed list of all activity related to the receivable, including: 

• Adjustments 

• Interest 

• Penalties 

• Administrative charges 

• Collections 

• Waivers 

• Write-offs. 

RMB-26 Reimbursable agreement query—Query reimbursable agreements. 

Parameters include Reimbursable Agreement Number, Customer ID Number, 

Customer Name, Project, or Fund. Result is a display of the following 

information for each reimbursable agreement selected: 

• Period of performance 

• Billing terms 

• Reimbursable agreement amount 

• Billing limit 

• Amount obligated 

• Amount expended 

• Unfilled customer order amount 

• Advances collected 

• Advances applied to earned revenue 

• Remaining balance on advances 

• Amount earned 

• Amount billed 

• Amount collected on receivables 

• Outstanding accounts receivable (billed and unbilled). 

Value-Added Requirements 

There are no value-added requirements for this process. 

Debt Management Process 

The Debt Management process involves the maintenance of account information on individual 

accounts receivable. The process supports activities to age receivables, calculate interest and 

record penalties and administrative charges on overdue debt, pursue collection of amounts due, 

liquidate receivables, record adjustments to receivables, maintain a proper allowance for 

uncollectible amounts, and record write-offs. 

Mandatory Requirements 

To support the Debt Management process, the Core financial system must provide automated 

functionality to do the following: 
Receivable Management Function 

Core Financial System Requirements 68

RMC-01 Assessing interest—Calculate and record late payment interest charges on 

overdue non-Federal receivables based on the Treasury Current Value of 

Funds Rate (CVFR) unless otherwise specified by the agency. 

RMC-02 Interest assessment rate—Calculate and record late payment interest charges 

on overdue non-Federal receivables based on an agency-assigned interest rate 

different from the CVFR for a particular receivable, customer, or customer type. 

RMC-03 Penalties and administrative charges—Calculate and record penalties and 

administrative charges on overdue receivables based on an agency-assigned 

rate or amount for a particular receivable, customer, customer type, or 

receivable type. 

RMC-04 Accounting classification of receivables—Optionally record interest, 

penalties, or administrative costs to accounting classification elements that are 

different from those to which the principal amount is recorded. 

RMC-05 Interest on referred debt—Optionally cease or continue accruing interest on 

delinquent debts that have been referred to Treasury or another agency. 

RMC-06 Dunning notices—Generate dunning notices on overdue receivables at 

frequencies specified by the agency, including on-demand, and by agencydefined parameters, including customer type. 

RMC-07 Dunning notice text—Customize text used on dunning notices based on 

receivable age categories and customer types. 

RMC-08 Accounts Receivable Aging Report—Generate an Accounts Receivable 

Aging Report. Parameters include: 

• Accounting Period 

• TAS or Internal Fund Code 

• General Ledger Account 

• Customer type 

• Federal/Non Federal Indicator 

• Customer ID number. 

Result is a report that displays the outstanding receivable balances in each of 

the Delinquent Debt Age categories listed on the TROR. 

RMC-09 Accounts receivable aging query—Query accounts receivable by age 

categories. Parameters include: 

• Accounting Period 

• TAS or Internal Fund Code 

• General Ledger Account 

• Customer type 

• Federal/Non Federal Indicator 

• Customer ID number. 

Result is a display of the outstanding receivable balances in each of the 

Delinquent Debt Age categories listed on the TROR. Drill-down to a detailed list 

of outstanding receivables within any one age category. 
Receivable Management Function 

Core Financial System Requirements 69

RMC-10 Receivables eligible for write-off—Identify receivables that may be eligible for 

write-off. Selection criteria is: 

• Delinquent debt age category 

• Customer type 

• Receivable type. 

Display selected items on-line. Include the receivable number, outstanding 

amount, age of receivable, vendor or customer name, and vendor or customer 

ID number of each receivable. Provide the option to mark a receivable as 

eligible for write-off. 

RMC-11 Waivers and write-offs—Record the waiver and write-off of receivables, 

including interest, penalties, and administrative charges. 

RMC-12 Classify write offs—Classify receivables written off as "Currently not 

Collectible" or "Closed Out." 

RMC-13 Waived and written-off receivables—Maintain data on receivables that have 

been waived or written-off. 

RMC-14 Receivables eligible for referral— Identify receivables that may be eligible for 

referral. Selection criteria is: 

• Delinquent debt age category 

• Customer type 

• Receivable type. 

Display selected items on-line. Include receivable number, receivable amount, 

age of receivable, vendor or customer name, and vendor or customer ID 

number of each receivable. Provide the option to mark receivables as eligible 

referral. 

RMC-15 Delinquent debt referral file—Generate a delinquent debt referral file for 

transmission to Treasury in accordance with the Debt Collection Improvement 

Act (DCIA). 

RMC-16 Receivable updates—Update receivables with dunning notice dates, referral 

dates, and comments to support debt collection activities. 

RMC-17 Allowance for loss—Calculate and record the allowance for loss on accounts 

receivable based on agency-defined criteria, including percentage of gross book 

value of receivables within an age category, customer type, and receivable type.

RMC-18 Delinquent debt categories—Classify delinquent debt by the following 

categories needed for the TROR: 

• In Bankruptcy 

• In Forbearance or formal appeals process 

• In Foreclosure 

• At private collection agencies 

• At DOJ 

• Eligible for internal offset 

• In wage garnishment 

• At Treasury for cross-servicing 

• At Treasury for Offset 
Receivable Management Function 

Core Financial System Requirements 70

• At Agency 

• Other. 

RMC-19 Treasury Report on Receivables (TROR)—Generate the Treasury Report on 

Receivables (TROR). Parameter is the fiscal year and quarter. Result is the 

TROR in accordance with Treasury form and instructions. Ensure reported 

totals agree with the general ledger. 

RMC-20 Customer receivables query—Query customer receivables. Parameters 

include Customer ID Number, Customer Name, TIN, Trading partner codes. 

Result is a display of the customer's information (e.g., customer ID number, 

customer name, TIN, trading partner codes) and all receivable-related activity 

associated with the customer, including the following: 

• Principal 

• Interest 

• Penalties 

• Administrative charges 

• Adjustments 

• Collections 

• Waivers 

• Write-offs 

• Receivable balance. 

Group interest, penalties, and administrative charges with their associated 

principal. Drill down to the detailed transactions, documents, and document 

details (e.g., document numbers, transaction dates, document reference 

numbers, receivable statuses (billed or unbilled), bill numbers (if billed), bill 

dates, dunning notice dates, referral dates, due dates, and delinquent debt 

statuses). 

RMC-21 IRS Form 1099-C—Generate IRS form 1099-C in accordance with IRS 

instructions. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Collections and Offsets Process 

The Collections and Offsets process supports activities to record the receipt of funds either by 

currency (e.g., cash, EFT) or check and the deposit of such funds in accordance with Treasury 

and agency regulations. The process also provides for the receipt of payment offset information 

from Treasury and its application to the appropriate accounts receivable. 

Mandatory Requirements 

To support the Collections and Offsets process, the Core financial system must provide 

automated functionality to do the following: 

RMD-01 Collection data—Capture the following additional information on collections: 

• Vendor/customer ID number and name 

• Deposit number 

• Deposit date 
Receivable Management Function 

Core Financial System Requirements 71

• Deposit confirmation date 

• Obligation reference number 

• Reimbursable agreement reference number 

• Advance reference number 

• Payment reference number 

• Source (Cash, EFT, Check, Money order, Credit card, IPAC, SF 1081, 

Electronic file from bank, or Treasury Offset Program) 

• Comments. 

RMD-02 Collections against receivables—Record collections against receivables. 

Reference the receivable document and update customer records and related 

billing information. 

RMD-03 Collections without receivables—Record collections with corresponding 

revenues, expenditure reductions, advance/prepayment reclassifications or 

other offsets, when receivables were not previously established. 

RMD-04 Order for applying collections—Apply collections against receivables in the 

following order: first to penalty and administrative costs, second to interest 

receivable, and third to outstanding debt principal, in accordance with the DCIA, 

unless otherwise stated in program statute. 

RMD-05 Collections on closed receivables—Record collections received against 

receivables that were waived or written off. 

RMD-06 Collections of overpayments—Record collections of refunds of previous 

overpayments or erroneous payments. If a receivable was not previously 

established, reference the obligation. Reduce cumulative payments and 

expenditures under the obligation. 

RMD-07 Collections of advance payments—Record collections of refunds of advance 

payments or prepayments. If a receivable was not previously established, 

reference the advance obligation. Reduce cumulative advances under the 

obligation. 

RMD-08 Reimbursable agreement advances received—Record advances (unearned 

revenue) received under reimbursable agreements. Update the advance 

balances on the reimbursable agreements. 

RMD-09 Reimbursable agreement revenue received—Record revenue received under 

reimbursable agreements. Update the earned revenue balances on the 

reimbursable agreements. 

RMD-10 Refund excess advance payments—Generate a refund payable when 

collections of advances from others exceed the amount expended or billed on a 

reimbursable agreement after all work is performed. Update the advance 

balances on the reimbursable agreements. 

RMD-11 Collections query—Query collections. Parameters include: 

• Source 

• Customer ID number 

• Customer name 
Receivable Management Function 

Core Financial System Requirements 72

• TIN 

• Reimbursable agreement number 

• Receivable document number 

• Deposit date range 

• Accounting period 

• Accounting classification. 

Result is a list of collections within the specified parameters, with the values for 

all the possible parameters. 

Value-Added Requirements 

There are no value-added requirements for this process. 
Core Financial System Requirements 73 

Cost Management Function 

The Cost Management function encompasses the capability to accumulate, recognize, and 

distribute the cost of an agency’s activities in the financial system for management information 

purposes. Managerial cost accounting concepts and standards for the Federal Government are 

prescribed in SFFAS 4, Managerial Cost Accounting Concepts and Standards for the Federal 

Government, promulgated by FASAB. 

The term “cost” universally 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. However, the level of sophistication needed within the Cost Management function of 

the Core financial system is dependent upon an agency’s requirements and the nature of the 

programs within the agency. For example, if an agency’s primary mission is to produce a 

product or service for sale, the costing function typically will be accomplished in the Managerial 

Cost Accounting System that is integrated with the Core financial system. Programs with less 

crucial cost information needs might perform cost management functions by analytical or 

sampling methods. 

The managers and executives who have the need for cost information should drive cost 

management in agencies. Regardless of agency need, the Core financial system must contain 

basic cost management functions. 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. 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. A “cost object” is any activity, output, outcome, or item 

whose cost and revenue are to be measured, such as organizational units, programs, projects, 

targeted outputs, specific contracts, specific customers, work orders, GPRA programs and 

activities, etc. After cost information is accumulated and prepared, it is distributed to managers. 

The Cost Management function consists of the following processes (the prefixes assigned to the 

requirements are noted in parentheses): 

• Cost Setup and Accumulation (CMA) 

• Cost Distribution (CMB) 

• Cost Reporting (CMC). 

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 
Cost Management Function 

Core Financial System Requirements 74

for fees, services, or products. It also provides a basis for linking operational results to the 

budget and performance measures. 

Mandatory Requirements 

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

automated functionality to do the following: 

CMA-01 Define cost objects—Define the following types of cost objects for 

accumulation, distribution and reporting purposes: 

• Accounting classification elements 

• Specific customers, vendors, reimbursable agreements, contracts, PAs, 

task orders, work orders, and grants 

• GPRA goals. 

CMA-02 Accumulate costs—Accumulate costs and revenue by cost object. 

CMA-03 Costs objects on prepaid expenses—Associate the purchase of fixed assets 

and inventory and the payment of advances with related cost objects so that 

subsequent expenditures are identified by cost object. 

CMA-04 Full cost—Accumulate the full cost of cost objects. Full costs include direct 

costs, indirect cost allocations, implicit costs (e.g., costs provided by other 

government agencies such as pension costs), and unfunded costs (e.g., annual 

leave costs). 

CMA-05 Non-financial data—Accumulate non-financial data (e.g., units purchased, 

units sold) by cost object at the transaction level. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Cost Distribution Process 

The managerial cost accounting concepts and standards contained in SFFAS 4 are aimed at 

providing reliable and timely information on the full cost of programs, their activities, and 

outputs. The information is used by stakeholders, executives, and managers when making 

decisions about allocating resources, authorizing and modifying programs, and evaluating 

program performance. Program managers also use the cost information for making managerial 

decisions to improve operating efficiency. Ultimately, the effectiveness of a cost management 

program depends on 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 automated 

functionality to do the following: 

CMB-01 Recording cost distribution entries in GL—Distribute the full cost of goods 

and services by cost object. Record the cost distribution entries in the GL. 
Cost Management Function 

Core Financial System Requirements 75

CMB-02 Attributes on cost distribution—Capture U.S. SGL attributes on cost 

distribution entries needed to prepare the Statement of Net Cost. For example, 

costs distributed to programs and used in the preparation of the Statement of 

Net Cost should retain the Federal/Non-Federal, Exchange/Non-Exchange, and 

Custodial/Non-Custodial classifications. 

CMB-03 Multi-layer overhead distributions—Perform multi-layer overhead 

distributions that are agency-defined (at least 3 levels of distribution) using 

multiple rates and fixed amount allocation methods. 

CMB-04 Re-distribute costs—Re-distribute costs based on revised rates and allocation 

amounts. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Cost Reporting Process 

To support the Cost Reporting process, the Core financial system must provide automated 

functionality to do the following: 

CMC-01 Comparative income statement by cost object—Generate the Comparative 

Income Statement by Cost Object. Parameters include cost object and 

accounting periods (month and year). Result is a report that compares month 

and year-to-date activity to prior month and prior year-to-date activity, by cost 

object. The report must list the following data: 

• Revenue 

• Direct expenses 

• Indirect expenses (overhead) 

• Total expenses 

• Net revenue/cost. 

CMC-02 Cost object income statement—Generate Cost Object Income Statement. 

Parameters include any cost object and accounting period. Result is a report 

with revenue, direct cost, and indirect cost (overhead) by cost object. 

CMC-03 Cost object audit trail —Maintain an audit trail of transactions from their origin 

to the final cost object(s). 

Value-Added Requirements 

There are no value-added requirements for this process. 
Core Financial System Requirements 76 

Fund Balance with Treasury Management Function 

The Fund Balance with Treasury (FBWT) represents the money an agency can spend on future 

authorized transactions. Agencies record transactions that increase and decrease their FBWT 

to U.S. SGL account 1010 in their general ledger. Appropriation warrants, non-expenditure 

transfers, collections, and disbursements are some of the transactions that impact an agency’s 

FBWT. 

Treasury requires that agencies reconcile their FBWT accounts regularly. RFCs, Disbursing 

Offices, and other depositaries provide Treasury with receipt and disbursement activity of the 

government. A comparison of this receipt and disbursement activity with agency records 

ensures the integrity and accuracy of internal and governmentwide financial report data. 

The Fund Balance with Treasury Management function consists of the following processes (the 

prefixes assigned to the requirements are noted in parentheses): 

• Treasury Information Maintenance (FBA) 

• Payment Confirmation Process (FBB) 

• Reconciliation and Reporting (FBC). 

Treasury Information Maintenance Process 

Most Federal agencies process large volumes of transactions that impact their FBWT. To 

facilitate automatic reconciliations with Treasury, an agency must classify cash transactions with 

Treasury defined codes. The Treasury Information Maintenance process ensures that the 

classification structures and valid data element relationships are in place for an agency’s system 

to use to classify and identify transactions that impact the FBWT. 

Mandatory Requirements 

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

provide automated functionality to do the following: 

FBA-01 Multiple ALCs—Maintain multiple ALCs. 

FBA-02 ALC Type—Define an ALC as a GWA reporter or a non-GWA reporter. 

FBA-03 ALC Business Activities—Maintain ALC Business Activities.

FBA-04 ALC Business Activity—Define an ALC's Business Activity as: 

• IPAC only 

• CA$HLINK II only 

• TDO Payments only 

• IPAC and CA$HLINK II 

• IPAC and TDO payments 

• TDO payments and CA$HLINK II 

• IPAC, CA$HLINK II, and TDO payments. 
Fund Balance with Treasury Management Function 

Core Financial System Requirements 77

FBA-05 GWA Reporter Categories—Maintain GWA Reporter Categories. 

FBA-06 GWA Reporter Category—Define the GWA Reporter Category for GWA 

reporter ALCs as 

• IPAC Only 

• CA$HLINK II Only 

• TDO Payments Only 

• IPAC and CA$HLINK II 

• IPAC and TDO Payments 

• TDO Payments and CA$HLINK II, or 

• IPAC, CA$HLINK II and TDO Payments. 

FBA-07 Capture ALC—Capture the ALC on all transactions that impact the FBWT and 

are reported to Treasury on the FMS 224, Partial 224, or through the GWA 

system. 

FBA-08 TAS/BETC combinations—Maintain valid TAS/BETC combinations as 

provided by Treasury's SAM for classification of the agency's FBWT 

transactions in the GWA system. 

FBA-09 Capture TAS/BETC—Capture the TAS/BETC on all transactions that impact 

the FBWT and are reported through the GWA system. 

FBA-10 FBWT transaction types—Define transactions that impact the FBWT and are 

reported on the FMS 224, Partial 224, or through the GWA system as "IPAC", 

"CA$HLINK II", "TDO Payments", or "Reclassifications". 

FBA-11 Treasury Document Number—Capture the "Treasury Document #" on all 

transactions that impact the FBWT. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Payment Confirmation Process 

Agencies that disburse payments through Treasury provide the details of requested payments 

(e.g., vendor name, amount of payment, payment date) on a payment schedule. The payment 

schedule may contain hundreds of individual payments that an agency is requesting be made. 

Upon accomplishing the payments, Treasury will notify the agency. The agency must update its 

general ledger with the proper accounting entry to record the disbursement of funds and to 

capture information about individual payments that may be critical in reconciling the FBWT or 

answering vendors’ questions concerning payments made. Because of the high volume of 

payments that most Federal agencies make, the Payment Confirmation process must ensure 

that an automated process is in place to update confirmation information. 

Mandatory Requirements 

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

automated functionality to do the following: 
Fund Balance with Treasury Management Function 

Core Financial System Requirements 78

FBB-01 Payment confirmation data—Import payment confirmation data from the 

GOALS II/ IAS RFC Agency Link. 

FBB-02 Liquidate disbursements-in-transit—Liquidate individual disbursement-intransit transactions and record confirmed disbursements upon receipt of 

payment confirmation from the GOALS II IAS RFC Agency Link. 

FBB-03 Update payment information—Update payments with paid schedule number, 

confirmed date, and check number or trace number upon receipt of confirmation 

data from the GOALS II IAS RFC Agency Link. 

FBB-04 Assign check numbers—Assign check numbers to individual payments, based 

upon the payment schedule's check range received from the GOALS II IAS RFC 

Agency Link. 

FBB-05 Correct check number—Correct system-assigned check numbers on payment 

records that do not match the actual check number assigned by Treasury. 

FBB-06 Multiple check ranges—Assign check numbers to individual payment records 

when a payment schedule has multiple check ranges or a break in check 

numbers. 

FBB-07 Disbursement cancellations—Record disbursement cancellations for 

individual payments that have not been negotiated. 

Value-Added Requirements 

There are no value-added requirements for this process. 

Reconciliation and Reporting Process 

Reconciling the FBWT is a complex and multistep process that involves an exchange of 

information between an agency and the Treasury. Agencies provide Treasury with the proper 

classification (e.g., Treasury Account Symbol) information for its receipt and disbursement 

activity. Treasury provides agencies with detailed support listings of receipt and disbursement 

activity that agencies must compare to the detailed transactions posted in their general ledger. 

The Reconciliation and Reporting process facilitates the comparison of transactions at this 

detailed level. 

Mandatory Requirements 

To support the Reconciliation and Reporting process, the Core financial system must provide 

automated functionality to do the following: 

FBC-01 Import ACR listing—Import the ACR support listing from the GOALS II/IAS 

RFC Agency Link to facilitate reconciliation of agency recorded disbursements 

and cancellations with Treasury. 
Fund Balance with Treasury Management Function 

Core Financial System Requirements 79

FBC-02 Compare ACR support listing with GL—Compare individual amounts on the 

ACR support listing with amounts recorded in the agency's general ledger by 

schedule number and accounting period. The accounting period is the fiscal 

month and year used for financial reporting purposes. 

FBC-03 GL/ACR Discrepancy Report—Generate the GL/ACR Discrepancy Report. 

Parameter is accounting period. Result is a report including schedule number, 

dollar amount, and confirmed date or transaction date of: 

• Items on the ACR listing and not in the agency's general ledger 

• Items on the ACR listing for a different amount than in the agency's 

 general ledger 

• Items in the agency's general ledger and not on the ACR listing. 

FBC-04 Import IPAC support listing—Import IPAC support listing from the GOALS 

II/IAS to facilitate reconciliation of agency recorded IPAC transactions with 

Treasury. 

FBC-05 Compare IPAC support listing with GL—Compare IPAC transactions on the 

IPAC support listing with IPAC transactions recorded in the agency's general 

ledger. 

FBC-06 GL/IPAC Discrepancy Report—Generate the GL/IPAC Discrepancy Report. 

Parameter is the accounting period. Result is report including document 

reference number (from IPAC Support Listing), dollar amount, and audit date or 

transaction date of: 

• Items on the IPAC support listing and not in the agency's general ledger

• Items on the IPAC support listing for a different amount than in the 

agency's general ledger 

• Items in the agency's general ledger and not on the IPAC support 

listing. 

FBC-07 Import DT/DV support listing—Import the Monthly DT/DV support listing from 

the GOALS II/ IAS to facilitate reconciliation of agency recorded deposits and 

debit vouchers with Treasury. 

FBC-08 Compare DT/DV support listing with GL—Compare individual amounts on 

the DT/DV support listing with amounts recorded in the agency's general ledger 

by document number and accounting period. 

FBC-09 GL/DT/DV Discrepancy Report—Generate the GL Deposit Ticket/Debit 

Voucher Discrepancy Report. Parameter is the accounting period. Result is a 

report including document number (Deposit Ticket or Debit Voucher number), 

dollar amount, and document date of: 

• Items on the DT/DV support listing and not in the agency's general 

ledger 

• Items on the DT/DV support listing for a different amount than in the 

agency's general ledger 

• Items in the agency's general ledger and not on the DT/DV support 

listing. 
Fund Balance with Treasury Management Function 

Core Financial System Requirements 80

FBC-10 FMS 224 Report—Generate the FMS 224 Report. Parameter is the accounting 

period. Result is the FMS 224, Statement of Transactions, for non-GWA 

reporting ALC's. Generate the report in both hard copy and electronic formats 

required by the Department of the Treasury. 

FBC-11 Partial 224 Report—Generate the FMS Partial 224 Report. Parameters are the 

ALC Business Activity, GWA Reporter Category, and accounting period. Result 

is the FMS Partial 224 for transactions associated with the ALC's Business 

Activity (IPAC, CA$HLINK II, TDO Payments) and not reported through the 

GWA system, and Reclassification transactions. Generate the report in both 

hard copy and electronic formats required by the Department of Treasury. 

FBC-12 1219/1220 Statements—Generate the SF1219/1220 statements. Parameter is 

accounting period. Result is SF 1219/1220, Statement of Accountability/ 

Transactions in both hard copy and electronic formats required by the 

Department of Treasury. 

FBC-13 FMS 224 Cash Transaction Detail Report—Generate the FMS 224 

Transaction Detail Report. Parameter is the accounting period. Result is a 

report listing the detailed transactions supporting each TAS total reported in 

each section of the FMS 224. Detailed transactions must include: 

• ALC 

• TAS 

• Transaction amount 

• Confirmation date 

• Transaction document number or Treasury document number. 

Separate report totals for disbursement and receipt activity by ALC and TAS 

must be provided. 

FBC-14 Partial 224 Transaction Detail Report—Generate the Partial 224 Transaction 

Detail Report. Parameter is the accounting period. Result is a report listing the 

detailed transactions supporting each TAS total reported in each section of the 

Partial 224. Detailed transactions must include: 

• ALC 

• TAS 

• Transaction amount 

• Confirmation date 

• Transaction document number or Treasury document number. 

Separate report totals for disbursement and receipt activity by ALC and TAS 

must be provided. 

FBC-15 Partial 224 Exception Report—Generate a Partial 224 Exception Report. 

Parameter is accounting period. Result is a list of the FBWT transactions that 

were posted to an ALC, but are ineligible for inclusion on the P224 based on the 

ALC's business activity. Transactions must include: 

• ALC 

• TAS 

• Transaction amount 

• Confirmation date 

• Document number. 
Fund Balance with Treasury Management Function 

Core Financial System Requirements 81

FBC-16 Cash Forecasting Report—Generate the Cash Forecasting Report. Result is a 

report with payment and deposit amounts at a detail suitable for reporting large 

dollar notifications as described in I TFM-6-8500, Cash Forecasting 

Requirements. 

Value-Added Requirements 

There are no value-added requirements for this process. 
Core Financial System Requirements 82 

Technical System Requirements 

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

fully supported and capable of processing the workload required. It must provide transaction 

processing integrity and general operating reliability; use standard procedures for installation, 

configuration, and operations; provide seamless integrated workflow processing; have the ability 

to query, access, and format information; and be well documented. It must not conflict with other 

administrative or program systems or with other agency-established IT standards. 

Core financial systems must meet the mandatory technical requirements specified in this 

section. In addition, they should strive to include the functionality listed as value-added 

requirements. The technical requirements are categorized as follows (the prefixes assigned to 

the requirements are noted in parentheses): 

• General Design/Architecture (TLA) 

• Infrastructure (TLB) 

• User Interfaces (TLC) 

• Interoperability (TLD) 

• Workflow/Messaging (TLE) 

• Document Management (TLF) 

• Internet Access (TLG) 

• Security (TLH) 

• Operations (TLI) 

• Ad Hoc Query (TLJ) 

• Documentation (TLK) 

• System Performance (TLL). 

Most technical requirements are stated in general terms to allow vendors maximum flexibility in 

designing compliant financial systems. Individual agencies are encouraged to add specific 

interoperability, system performance, and workload requirements considered unique to their 

respective IT environments when evaluating packages for acquisition. 

General Design/Architecture 

The technical requirements relate to the overall product and its structure at the highest level. 

Federal standards are published for the purpose of limiting Core financial system acquisition to 

qualified options. The basic design features and system architecture determine the adaptability 

of the system, such as customization and upgradeability. A Core financial system must be 

designed with the flexibility to respond to the changing Federal environment. 
Core Financial System Technical Requirements 

Core Financial System Requirements 83

Mandatory Requirements 

To meet General Design/Architecture requirements, the Core system must deliver the following: 

TLA-01 General design—Delivered system must be modular, highly scalable and 

incorporate an open-systems architecture. 

TLA-02 Customization— Delivered system must be customizable to meet agency-defined 

business practices. Agency customizable features must be table/parameter driven. 

TLA-03 Upgradeability—Delivered system must be upgradeable to accommodate changes 

in laws, regulations, best practices or new technology. 

TLA-04 System outputs—Delivered system must generate output reports, query results 

and data files using multiple formats as specified by functional requirements. 

Specified formats can include online display, printed report, Portable Document 

Format (PDF), MS Word, Excel, ASCII or delimited text file. In cases where an 

output format is not specified within a requirement, the requested information must 

be viewable to the agency online, using the application user interface. 

TLA-05 Date handling—Deliver fault-free performance in the processing of date and daterelated data (including, calculating, comparing, and sequencing) by all hardware 

and software products included as part of the application both individually and in 

combination (i.e., be Y2K compliant). 

Value-Added Requirements 

To add value to the General Design/Architecture functionality, the Core financial system should

deliver the following: 

TLA-06 Parallel transaction processing—Delivered system should be capable of 

processing online transactions, batch jobs and transactions submitted via system 

interface simultaneously. 

TLA-07 Report spooling—Deliver a reports management capability to enable online 

retrieval, viewing, re-printing, and permanent archiving of system-generated reports.

Infrastructure 

The Core financial systems infrastructure provides the underlying base or foundation of the 

computing system platforms and operating system environments where a qualified Core system 

would be installed by a Federal agency. It is necessary for the infrastructure to support a 

Windows operating system and provide certain basic communications and database functions 

common to Federal Government system installations. 

Mandatory Requirements 

To meet Infrastructure requirements, the Core system must deliver the following: 

TLB-01 Relational database—Delivered system must include a Structured Query 

Language (SQL) compliant relational database. 
Core Financial System Technical Requirements 

Core Financial System Requirements 84

Value-Added Requirements 

To add value to the Infrastructure functionality, the Core financial system should deliver the 

following: 

TLB-02 Mainframe operation—Operate in a mainframe environment (e.g., Multiple Virtual 

System (MVS), Operating System (OS/) 390). 

TLB-03 UNIX/NT software—Operate in a server computing environment running under 

UNIX, LINUX, Windows Server 2000 or above. 

TLB-04 Apple/Mac—Operate in an Apple Macintosh system environment. 

User Interfaces 

Technical User Interfaces requirements specify how agency users and operators interact with 

the Core financial system. These requirements address the ability of users to effectively 

configure the package, enter transactions, query processing results, or start/stop internal 

processes. 

Mandatory Requirements 

To meet User Interfaces requirements, the Core financial system must deliver the following: 

TLC-01 GUI interface—Deliver an online graphical user interface (GUI). The GUI must 

provide consistent data entry, navigation and information presentation across all 

modules and sub-systems. 

TLC-02 508 Compliance—Comply with Section 508 of the Rehabilitation Act, as detailed in 

36 CFR 1194, Subpart B. 

TLC-03 Context-sensitive help—Deliver a context-sensitive, online help facility. This 

facility must be customizable by the agency. 

TLC-04 Error message customization—Deliver the capability to customize error message 

text. 

TLC-05 Data entry efficiencies—Incorporate user interface features designed to reduce 

the amount of direct keying required for transaction processing, such as: 

• Default values based on system maintained transaction and user profiles 

• Value look-up tables 

• Highlighting or accentuating required fields 

• Grayed data fields that are unavailable for user entry 

• Auto tabs 

• Automatic data recall 

• Auto fill text 

• Cut, copy and paste functionality 

• Keyboard shortcuts (e.g., function keys to invoke help facility, clear screen, 

etc.) 

• Menu mode of screen navigation 

• Undo/redo 

• Disabling of non-supported function keys 
Core Financial System Technical Requirements 

Core Financial System Requirements 85

• Ability to select records from a list by scrolling or typing only part of an entry.

• Ability to pass common data from field to field, screen to screen and 

transaction to transaction. 

Value-Added Requirements 

To add value to the User Interfaces functionality, the Core financial system should deliver the 

following: 

TLC-06 Desktop integration—Support integration with other common desktop applications 

(e.g., word processing, spreadsheets, data management). 

Interoperability 

Financial transactions can be originated using multiple external feeder applications. These 

feeder systems and the Core financial system must interface seamlessly so that data can move 

effectively between them. The Core system must be able to process and validate the data 

independent of origination. There must also be a process for handling erroneous input and 

corrections. 

Mandatory Requirements 

To meet Interoperability requirements, the Core system must deliver the following: 

TLD-01 Application program interface (API)—Deliver a capability to import and process 

standard transactions generated by other systems. 

TLD-02 API record layouts—Deliver data record layouts for all standard transactions that 

can be accepted by the application's API facility. Transactions must include sufficient 

data to enable complete validation and processing by the receiving system. 

TLD-03 API transaction validation—Process API transactions using the same business 

rules, program logic, and edits used by the system in processing transactions 

submitted through the application client. 

TLD-04 API transaction suspension—Deliver the capability to suspend erroneous API 

transactions. Suspense processing must include the ability to perform the following 

functions: 

• Report suspended transactions 

• Retrieve, view, correct and process, or cancel suspended transactions 

• Automatically re-process transactions 

• Report re-processed transactions. 

TLD-05 API processing controls— Deliver API processing controls to ensure real time 

transactions or batch transactions files are received from authorized sources, 

complete and not duplicates. In addition, the API must ensure that where batch files 

are used: 

• The number of transactions in a received file matches a control record count 

• The dollar total of transactions in a file matches a control amount 

• The sender is notified of erroneous transactions 

• The erroneous transactions are automatically returned to the sender. 
Core Financial System Technical Requirements 

Core Financial System Requirements 86

TLD-06 API generated error notices—Generate API transaction edit error records using a 

data layout defined by the vendor (i.e., provide two-way interface support). 

TLD-07 Agency e-mail—Deliver the capability to connect to an agency operated e-mail 

system. This capability must include the ability to distribute application generated 

text messages with attached files. 

Value-Added Requirements 

To add value to the Interoperability functionality, the Core financial system should deliver the 

following: 

TLD-08 EDI translation—Support direct EDI translation compliant with American National 

Standards Institute (ANSI) X-12 standards to enable electronic data exchanges with 

designated trading partners. 

TLD-09 XML—Deliver an integrated Extensible Markup Language (XML) parsing capability. 

TLD-10 XRBL—Deliver a capability to exchange data using the Extensible Business 

Reporting Language. 

Workflow/Messaging 

Workflow/messaging includes technical requirements that establish standards for application 

interfaces and collectively define how a Core financial system automatically manages document 

processing; generates, builds, maps, and models workflow processes and business rules; and 

notifies agency staff of pending work (e.g., review/approval of pending accounting documents). 

Mandatory Requirements 

To meet Workflow/Messaging requirements, the Core financial system must deliver the 

following: 

TLE-01 Integrated workflow—Deliver an integrated workflow management capability to 

automate internal routing of documents, transactions, forms or reports for online 

approval processing. 

TLE-02 Workflow process definition— Deliver the capability to customize workflow 

processes to automate agency-defined business rules, required approvers, pooled 

or proxy approving authorities and workload balancing. Agency customization must 

include the capability to apply start and end dates to approvers and their proxies. 

TLE-03 Document processing approval—Deliver the capability to define multiple levels of 

document approvals based on agency-defined criteria, including dollar amounts, 

types of items purchased, and document types. 

TLE-04 Document approvals—Deliver the capability to define multiple approval levels to a 

single user. Prevent a user from applying more than one level of approval to the 

same document in order to conform to the principle of separation of duties. For 

example, a disbursing officer must not be allowed to certify payment of an invoice 

he/she entered, and a certifying officer must not be allowed to schedule a payment 

he/she certified. 
Core Financial System Technical Requirements 

Core Financial System Requirements 87

TLE-05 Processing exception notices—Deliver a workflow calendaring capability to 

generate date-based process exception reports and alerts. For example, notify an 

accounts payable office when invoices are held over 30 days with no matching 

receiving report. 

TLE-06 Document approval tracking—Deliver the capability to capture approval actions 

by transaction, including the time/date and approving party. 

TLE-07 Document routing— Deliver the capability to route action requests/status 

messages internally to individuals, groups or external trading partners. Supported 

communications channels must include agency e-mail, Blackberry, internal 

application messaging. 

TLE-08 User alerts—Deliver the capability to generate workflow event-based user alerts. 

For example, at the point an emergency travel voucher is approved, electronically 

notify the affected traveler. 

TLE-09 User notices—Deliver the capability to generate user alerts based on agencydefined thresholds (i.e., trigger events). For example, electronically warn a budget 

officer when available funds reach 50% of the allotment. 

Value-Added Requirements 

To add value to the Workflow/Messaging functionality, the Core financial system should deliver 

the following: 

TLE-10 Workflow process modeling—Deliver a business process modeling capability. 

TLE-11 Workflow definition audits—Generate auditable records of changes made to the 

workflow approval routing design. 

TLE-12 Wf-XML—Delivered system should comply with the current Workflow Management 

Coalition (WFMC) Workflow Standard - Interoperability. 

Document Management 

Document management addresses how the Core system stores and retrieves electronically 

formatted documents. 

Mandatory Requirements 

To meet Document Management requirements, the Core financial system must deliver the 

following: 

TLF-01 Indexed reference materials—Deliver the capability to index and store file 

reference materials received or generated by the agency in electronic format. 
Core Financial System Technical Requirements 

Core Financial System Requirements 88

Value-Added Requirements 

To add value to the Document Management functionality, the Core financial system should

deliver the following: 

TLF-02 Document imaging—Deliver the capability to electronically image, index and store 

file reference materials delivered in a hard copy format (e.g., a signed contract, bill 

of lading, vendor invoices). 

TLF-03 Image availability notification—Deliver the capability to notify the user of the 

presence of associated document images. Deliver on-screen display of imaged 

material. 

Internet Access 

The Internet is a vast collection of interconnected networks that communicate using TCP/IP. It 

has become a critical infrastructure for application access. The technical requirements relating 

to Internet access represent a specialized subset defining user connectivity options and security 

issues. 

Mandatory Requirements 

To meet Internet Access requirements, the Core financial system must deliver the following: 

TLG-01 TCP/IP—Delivered system must support Transmission Control Protocol/Internet 

Protocol (TCP/IP) for application component connectivity. 

TLG-02 Browser access—Deliver browser access to all system modules/functionality. 

Value-Added Requirements 

To add value to the Internet Access functionality, the Core financial system should deliver the 

following: 

TLG-03 Internet-originated transactions—Deliver the capability to receive vendor invoices 

and payments from the public via the Internet. 

TLG-04 Internet access to ad hoc queries— Support secure Internet access to the 

integrated ad hoc data query facility. 

TLG-05 VPN—Support operations via a Virtual Private Network (VPN) system capability for 

secure remote access. 

TLG-06 PKI—Deliver the capability to use Public Key Infrastructure technology to control 

system access. 

Security 

This section addresses security controls needed to protect the confidentiality, integrity, and 

availability of financial data maintained in a qualified agency system. To meet security 

requirements, the core system must comply with approved standards and guidelines, including 

minimum requirements, for providing adequate information security for all agency operations 
Core Financial System Technical Requirements 

Core Financial System Requirements 89

and assets as are appropriate for the specific characteristics of the system. In addition to 

meeting the specified application design standards, agencies are required to comply with the 

following security related regulations and guidance: 

• Title III of the E-Government Act, of the Federal Information Security Management Act 

(FISMA) of 2002, P.L. 107-347, requires each federal agency to develop, document, and 

implement an agency-wide information security program. 

• In accordance with the provisions of FISMA, information security must be effectively 

integrated into the system development life cycle. 

• All new applications must undergo a full Certification and Accreditation (C&A), including 

an initial review to ensure compliance with NIST SP 800-37, Guidelines for the Security 

Certification and Accreditation of Federal Information Technology Systems. In 

conjunction with C&A, an agency will perform a self-assessment using the guidance 

found in NIST SP 800-26, Security Self-Assessment Guide for Information Technology 

Systems. 

• Title II of the E-Government Act of 2002, Section 208, requires a Privacy Impact 

Assessment (PIA) prior to developing or procuring IT systems that collect, maintain, or 

disseminate Information in Identifiable Form (IIF). All systems shall have a current PIA 

to ensure compliance with the Privacy Act of 1974 and other IT privacy requirements. 

System specific guidance, for systems which are not national security systems, is provided by 

NIST, consistent with the requirements of the Office of Management and Budget (OMB) Circular 

A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in A-130, Appendix 

IV: Analysis of Key Sections. Supplemental information is provided A-130, Appendix III. 

Mandatory Requirements 

To meet Security requirements, the Core system must deliver the following: 

TLH-01 NIST compliance—Deliver integrated security functionality compliant with the 

National Institute of Standards and Technology (NIST) Security Standards. 

TLH-02 Security controls—Ensure that the management, operations and technical 

baseline security controls are implemented in accordance with Federal Information 

Processing Standards (FIPS) 199 Standards for Security Categorization of Federal 

Information and Information Systems and other current NIST guidance on selecting 

the appropriate security controls. 

TLH-03 Access control—Deliver the capability to control function access (e.g., system 

modules, transactions, approval authorities) and data access (i.e., create, read, 

update, delete) by assigned: 

• User ID 

• Functional role (e.g., payable technician) or 

• Organization. 

Enable the agency to define access rules based on any combination of these 

attributes. 
Core Financial System Technical Requirements 

Core Financial System Requirements 90

TLH-04 Security policy—Ensure that the appropriate security controls are consistently 

enforced in all modules, including software used for ad-hoc data query/report 

generators. 

TLH-05 Sensitive data masking— Deliver the capability to restrict access to sensitive data 

elements, such as social security numbers, banking information by user ID, 

assigned role or organization. 

Value-Added Requirements 

There are no value-added requirements in this category. 

Operations 

In general, most users should be unaware of background system operations, except for 

scheduled maintenance. The Core financial system should run smoothly and efficiently, and it 

must maintain database consistency; archive, log, and retrieve data; stop and restart the system 

without losing data; and report system status. 

Mandatory Requirements 

To meet Operations requirements, the Core system must deliver the following: 

TLI-01 Process scheduling—Deliver a process scheduling capability. Allow the agency to 

define, initiate, monitor and stop system processes (e.g., online availability, batch 

jobs, and system maintenance). 

TLI-02 Internal database controls—Maintain internal database consistency at all times. In 

the event of a system failure the system must have the capability to: 

• Back out incompletely processed transactions 

• Restore the system to its last consistent state before the failure occurred 

• Re-apply all incomplete transactions previously submitted by the user 

• Validate internal database consistency to ensure duplicate postings are 

avoided 

• Report any data or transactions that failed to process completely. 

TLI-03 Job processing messages—Generate online status messages to the operator. 

Include job or transaction type, name, when processing initiates, when it completes, 

and any processing errors encountered. 

TLI-04 Job restart— Deliver a restart capability for all application’s online and batch 

processing components. Batch jobs must be segmented to facilitate restart in the 

event of a system failure. 

TLI-05 Error handling—Deliver common error-handling routines across functional 

modules. Generate meaningful and traceable error messages that allow the user or 

system operator to identify and respond to reported problems. 

TLI-06 Data archiving—Deliver a document archiving capability. Include the ability to 

define, establish, and maintain archival criteria, such as date, accounting period, 

closed items, and vendors/customers inactive for a specific time period. Archiving of 
Core Financial System Technical Requirements 

Core Financial System Requirements 91

 closed or completed detail transactions must not affect related general ledger 

account balances. 

TLI-07 Data archive standards—Support data archiving and record retention in 

accordance with rules published by the National Archives and Records 

Administration (NARA), GAO, and National Institute of Standards and Technology 

(NIST). 

TLI-08 Archived data retrieval—Deliver the capability to restore archived data based on 

agency-defined criteria such as date, accounting period, or vendor/customer. 

TLI-09 Event logging—Deliver an event logging capability for systems, transactions, 

tables, and system parameters. The logs must include the following: 

• User ID 

• System date 

• Time 

• Type of activity (i.e., add, modify, delete) 

• Old value 

• New value. 

(For example, provide a log of all attempts to log onto the system or track changes 

to the prompt pay interest rate value.) 

TLI-10 Productivity reporting—Maintain and report application usage statistics. 

Productivity statistics should include concurrent users, job submissions, 

transactions throughput, and system availability. 

TLI-11 System date for testing—Deliver a capability to override the system date value 

used to automatically default document effective date and related transaction 

posting date/period. This capability is intended for system testing. 

Value-Added Requirements 

To add value to the Operations functionality, the Core financial system should deliver the 

following: 

TLI-12 Queued jobs—Deliver the capability to process queued jobs (i.e. reports, 

transaction files from interfacing systems, bulk record updates) with no online 

performance degradation. 

TLI-13 User selected access logging—Deliver the capability to customize system logging 

features. Allow the agency to specify which parameters (or tables) to log. Allow the 

agency to turn logging feature on or off as needed). 

Ad Hoc Query 

Over time, demands for specific financial data are expected to change considerably as changes 

occur in, for example, administrations, program missions, budget priorities, justifications, and 

oversight. Ad hoc queries are often general but are critical to enabling effective agency, 

program, and financial management in the face of change. To support ad hoc queries, the Core 

financial system must provide flexible data access, download, and formatting. 
Core Financial System Technical Requirements 

Core Financial System Requirements 92

Mandatory Requirements 

To meet Ad Hoc Query requirements, the Core financial system must deliver the following: 

TLJ-01 Ad hoc query—Deliver an integrated ad hoc query capability to support agency 

access to and analysis of system maintained financial data. 

TLJ-02 Ad hoc query origination—Deliver the capability to define parameter-based query 

scripts that can be queued for execution, stored for re-use and shared with other 

authorized agency users. 

TLJ-03 Ad hoc query execution—Process submitted queries and queue output on-line for 

access by authorized users. 

TLJ-04 Ad hoc query results— Distribute query results or notifications of online query 

result availability to pre-defined individuals or groups. 

TLJ-05 Run-time controls—Deliver run-time controls to prevent "run-away" queries and to 

restrict very large data download requests. 

TLJ-06 Graphical output— Deliver the capability to display graphical output on the 

desktop with dynamic report reformatting. 

TLJ-07 Drill-down—Deliver an on-line "drill-down" capability from summary amounts in 

queries to supporting detail records. 

TLJ-08 Data downloading—Deliver the capability to download selected query data. 

Reformat downloaded query information for direct access by common desktop 

applications (e.g., spreadsheet, ASCII text, "," delimited). 

TLJ-09 Query/Report preview—Deliver the capability to preview a query, form, report, or 

other result before printing. 

TLJ-10 Available data— Deliver capability to access current year and historical financial 

data. 

TLJ-11 Ad hoc query interface—Deliver the following ad hoc query interface features: 

• Graphical display of data sources 

• The ability to "point and click" on selectable table, data, and link objects for 

inclusion in a custom query, and 

• An active data dictionary to provide users with object definitions. 

Value-Added Requirements 

To add value to the Ad Hoc Query functionality, the Core financial system should deliver the 

following: 

TLJ-12 Query optimization—Deliver the capability to optimize queries. 

TLJ-13 Dashboard output—Deliver a "dashboard" reporting capability that can be used to 

continuously display agency-defined performance metrics on a managers desktop 

(e.g., a graphical view of the agency's budget status). 
Core Financial System Technical Requirements 

Core Financial System Requirements 93

Documentation 

It is not enough for a vendor to deliver a Core financial system and help with installation. The 

documentation that comes with the product is key to the effective and efficient use of the system 

and its appropriate implementation and maintenance. The documentation submitted with the 

software must be written at a sufficient level of detail that users who are familiar with the Core 

system and its functions, but are new to the product, can understand and use the 

documentation without assistance from the vendor. 

Mandatory Requirements 

To meet Documentation requirements, the Core financial system must deliver the following: 

TLK-01 Hardware and software—Deliver documentation that identifies all software and 

hardware products needed by an agency to install, operate, access, and maintain 

the application. Delivered hardware and software documentation must specifically 

identify those products that are intended to be purchased or licensed as part of the 

product licensing agreement, and those products needed to meet any technical and 

functional requirement that must be acquired separately by the agency. 

TLK-02 Application design—Deliver application design documentation. This 

documentation must include the following: 

• Description of the application's design/architecture and integrated 

 technologies 

• Database specifications 

• Data dictionary 

• Entity relationship diagrams 

• Internal file record layouts 

• Cross references between internal files, database tables and data-entry 

screens 

• Program module specifications including firmware and program source code

• System flowcharts. 

Application documentation must identify known problems (software bugs) and 

recommended work around. 

TLK-03 Software installation and maintenance—Deliver product installation and 

maintenance documentation. Installation documentation must describe the following 

items: 

• Product release content 

• Third party software configuration requirements 

• Database installation steps 

• The directory structure for locating application data, programs, files, tables 

including drive mappings 

 • Hardware driver installation and configuration 

• Application security set-up and maintenance 

• Software configuration instructions 

• Operating parameter definitions and any other required set-up data 

• Software build instructions 

• Vendor supplied configuration tools 

• Interface processes to be installed 

• Startup scripts needed to initiate the software 

• Test steps needed to verify correct installation. 
Core Financial System Technical Requirements 

Core Financial System Requirements 94

TLK-04 User and operating documentation—Deliver system operations and user 

manuals. Documentation must explain the following system operations: 

• System start-up 

• Shutdown 

• Monitoring 

• Recovery/re-start 

• Internal processing controls 

• Archiving and application security. 

User documentation must explain in detail how to execute available functionality in 

each application component and must cover instructions for the following: 

• Access procedures 

• User screen layout 

• Standard report layout and content 

• Transaction entry 

• Workflow 

• Batch job initiation 

• GL and transaction maintenance 

• Yearend processing 

• Error codes with descriptions 

• Recovery steps 

• Trouble shooting procedures. 

TLK-05 Updated release specific documentation—Deliver documentation updates 

concurrent with the distribution of new software releases. Release notes must 

clearly identify all changes made to the system's functionality, operation or required 

computing hardware and software. 

Value-Added Requirements 

There are no value-added requirements in this category. 

System Performance 

This section defines system performance categories that need to be considered when 

evaluating packages for potential acquisition. These requirements were written without specific 

(i.e., testable) performance criteria. Recognizing that delivered package performance is 

dependent on agency-supplied computing infrastructure and workload, agencies should 

customize these requirements, adding their own unique criteria (e.g., number of concurrent 

users, geographic distribution of worksites, number of transactions, processing windows, and 

volume of agency information expected to be maintained online or archived). 

Mandatory Requirements 

TLL-01 Activity workload—Process the agency’s specified accounting workload without 

adversely impacting projected online response time. 

TLL-02 Batch processing workload—Process all scheduled work (e.g., batch jobs) within 

an agency specified processing window. Scheduled work can include: 

• Daily systems assurance reports 

• Daily backups 

• Daily interface processing 

• Core GL posting 
Core Financial System Technical Requirements 

Core Financial System Requirements 95

• Table updates 

• Standard reporting. 

TLL-03 Data volume—Maintain the agency’s specified current and historical financial data 

(e.g. general ledger records, documents, transactions, lines, and vendor records) 

storage needs with no degradation to online or batch processing performance. 

TLL-04 Concurrent user access—Support concurrent access to functional modules for the 

agency's specified user community. 

Value-Added Requirements 

To add value to the System Performance functionality, the Core financial system should deliver 

the following: 

TLL-05 Performance metrics—Deliver computing performance metrics for platforms and 

systems environments that the application is certified to run on. Performance 

metrics provided by the vendor should describe: 

• Transaction processing throughput capacity, 

• Expected workstation client response time by transaction type, 

• Data storage capacity, and 

• Limitations on concurrent user connectivity. 
Core Financial System Technical Requirements 

Core Financial System Requirements 96
Core Financial System Requirements A-1

Appendix A—References 

Introduction 

This appendix lists governmentwide accounting standards, laws, regulations, and other 

guidance that pertain to Core financial system requirements. Reference categories are as 

follows: 

• Federal legislation 

• U.S. Code 

• Statements of Federal Financial Accounting Standards 

• Office of Management and Budget guidance 

• Treasury Financial Manual 

• Other Federal standards, guidelines, and regulations 

• Federal Financial Management System Requirements 

The list is not all-inclusive and may not include citations supporting agency-specific or programspecific mandates. It is every agency’s responsibility to comply with the most current versions of 

applicable laws, regulations and other guidance. In addition, it is important to note that many 

requirements are based on common business need in addition to a cited laws and regulations. 

Federal Legislation 

Cash Management Improvement Act of 1990 (CMIA) (Pub. L. No. 101-453), extended by the 

Cash Management Improvement Act Amendments of 1992 (Pub. L. No. 102-589) 

Chief Financial Officers Act of 1990 (Pub. L. No. 101-576) 

Clinger-Cohen Act of 1996 (Information Technology Management Reform Act, Division E of 

Pub. L. No. 104-106) 

Computer Security Act of 1987 (Pub. L. No. 100-235) 

Debt Collection Improvement Act of 1996 (Pub. L. No. 104-134) 

Defense Authorization Act for FY1991 (Pub. L. No. 101-510, § 1405(a)) amended 31 U.S.C. 

subtitle II, ch. 15, subch. IV, Closing Accounts, §§ 1551–1557, 

Federal Financial Management Improvement Act of 1996 (Pub. L. No. 104-208) 

Federal Managers’ Financial Integrity Act of 1982 (Pub. L. No. 97-255) 

Federal Records Act of 1950, as amended (Records Management by Federal Agencies, 

44 U.S.C. § 3101 et seq.) 

Freedom of Information Act and Amendments of 1974 (Pub. L. No. 93-502) (5 U.S.C. § 552) 

Government Management Reform Act of 1994 (Pub. L. No. 103-356) 
Appendix A—References 

Core Financial System Requirements A-2

Government Paperwork Elimination Act of 1998 (Pub. L. No. 105-277) 

Government Performance and Results Act of 1993 (Pub. L. No. 103-62) 

Omnibus Reconciliation Act of 1993 (Pub. L. No. 103-66) 

Paperwork Reduction Reauthorization Act of 1986 (Pub. L. No. 104-13) 

Prompt Payment Act of 1982 and Amendments of 1996 (Pub. L. No. 97-177) 

Rehabilitation Act Amendments of 1998 (Workforce Investment Act) (Pub. L. No. 106-246) 

Sarbanes-Oxley Act of 2002 (Pub. L. No. 107-204) 

Internal Revenue Service Restructuring and Reform Act of 1998 (IRS RRA) 

(Pub. L. No. 105-206) 

U.S. Code 

5 U.S.C. § 552 contains provisions of the Freedom of Information Act. 

31 U.S.C. § 1301(a) (the “Purpose Statute”) requires that monies be expended only for the 

purposes for which appropriations were made. 

31 U.S.C. §§ 1341, 1342, 1349–51, and 1511–19 (jointly referred to as the “Anti-deficiency Act”) 

prohibit obligating more money than an agency has or before it gets the money, accepting 

voluntary services or monies not specifically allowed by law, and obligating more money than 

has been appropriated or allotted in a time period. 

31 U.S.C. § 1501 (the “Recording Statute”) requires that an obligation be recorded when, and 

only when, it is supported by written evidence of a binding agreement (an offer and its 

acceptance) for goods or services for a purpose authorized in the appropriation. 

31 U.S.C. § 1502 (a) (the “Bona Fide Needs Statute”) requires that obligations against an 

appropriation be limited to a specific time period and that obligations be charged to the 

appropriation in force when the obligation is made. 

31 U.S.C. §§1551–1557 (Closed Accounts subchapter) contains the M-year legislation which 

requires that all Federal agencies close fixed-year appropriation accounts and cancel any 

remaining balances by September 30th of the 5th year after the period of availability began. 

31 U.S.C. § 3302 (b) (the “Miscellaneous Receipts (Deposit) Statute”) requires that, except for 

trust funds and revolving funds, collected monies from any source be deposited in the Treasury 

as soon as practicable without deduction for any charge or claim. 

31 U.S.C. § 3512 requires the head of each executive agency to establish and maintain 

systems of accounting and internal control designed to provide effective control over, and 

accountability for, all assets for which the agency is responsible. 

44 U.S.C. § 3101 addresses records management within Federal agencies. 

5 CFR 1315 is the codification of former OMB Circular A-125, Prompt Payment. 
Appendix A—References 

Core Financial System Requirements A-3

Statements of Federal Financial Accounting Standards 

SSFAS 1, Statement of Federal Financial Accounting Concepts

SFFAS 3, Accounting for Inventory and Related Property

SSFAS 4, Managerial Cost Accounting Concepts and Standards

SSFAS 5, Accounting for Liabilities of the Federal Government

SFFAS 7, Accounting for Revenue and Other Financing Sources

SSFAS 10, Accounting for Internal Use Software

Office of Management and Budget Guidance 

OMB Circular A-11, Preparation, Submission, and Execution of the Budget

OMB Circular A-25, User Charges

OMB Circular A-109, Policies for Acquiring Major Systems

OMB Circular A-123, Management Accountability and Control 

OMB Circular A-127, Financial Management Systems

OMB Circular A-130, Management of Federal Information Resources

OMB Circular A-134, Financial Accounting Principles and Standards 

OMB Circular A-136, Financial Reporting Requirements

Treasury Financial Manual 

I TFM-2-3100, Instructions for Disbursing Officers’ Reports 

I TFM-2-3300, Reports of Agencies for which the Treasury Disburses 

I TFM-2-4000, Federal Agencies’ Centralized Trial-Balance System 

I TFM-2-4100, Debt Management Reports 

I TFM-6-5000, Administrative Accounting Systems Requirements 

I TFM-6-8040, Disbursements 

I TFM-6-8500, Cash Forecasting Requirements 

Other Federal Standards, Guidelines, and Regulations 

Electronic and Information Technology Accessibility Standards (issued by the Architectural and 

Transportation Barriers Compliance Board) 

Federal regulations established by the National Archives and Records Administration 

Federal regulations issued by the National Institute of Standards and Technology 
Appendix A—References 

Core Financial System Requirements A-4

Rules related to payment formats issued by The Electronic Payments Association (also called 

NACHA) 

Federal Financial Management System Requirements 

Framework for Federal Financial Management Systems, January 1995 

Inventory, Supplies, and Materials System Requirements, August 2003 

Revenue System Requirements Document, January 2003 

Acquisition Financial System Requirements, June 2002 

Core Financial System Requirements, November 2001 

Benefit System Requirements, September 2001 

Core Financial System Requirements, February 1999 

Direct Loan System Requirements, June 1999 

Grant Financial System Requirements, June 2000 

Guaranteed Loan System Requirements, March 2000 

Human Resources and Payroll System Requirements, April 1999 

System Requirements for Managerial Cost Accounting, February 1998 

Seized Property and Forfeited Assets System Requirements, December 1999 

Travel System Requirements, July 1999 

Managerial Cost Accounting Implementation Guide, February 1998 

Property Management System Requirements, October 2000 
Core Financial System Requirements B-1

Appendix B—Requirement Drafting Guidelines 

Our goal is to publish a comprehensive set of functional requirements that can be used by 

agencies and vendors in developing more effective financial systems. To help ensure that our 

efforts produce consistent and accurate requirement text, we have adopted drafting guidelines 

for each type of requirement we deal with. The requirement types found in this document are:

• Configuration 

• Input 

• Process 

• Query 

• Report 

• Interface 

• Non-functional. 

Our drafting guidelines call for starting every requirement statement with a standard verb as 

defined in this appendix. Definitions of other key terms that could affect an agency’s 

interpretation of individual requirements can be found in the Glossary. In reading each functional 

requirement, please assume the following opening statement: 

“Deliver an automated capability to:” 

A key objective in drafting this version of the requirements was to eliminate ambiguous phrasing 

such as “as applicable,” “as appropriate,” or “at a minimum.” 

Examples, where included in requirement text, are not intended to be definitive. They are used 

only to help clarify the intent. Examples are identified with the lead-in phrase “for example” or 

“such as.” 

Configuration Requirements 

Configuration requirements describe functionality needed by an agency to create tables, 

structures, codes, labels, access rights, and rules. 

• We use “maintain” when specifying functionality that will allow the agency to directly 

enter or import additions, changes, or deletions to system configuration or operating 

tables. For example: 

Maintain a revenue source code structure. 
Appendix B—Requirement Drafting Guidelines 

Core Financial System Requirements B-2

• We use “define” when the intention of the requirement is to allow the agency to specify 

edits, business rules, workflows, code values, or other conditional processes. For 

example: 

Define specific GL accounts as control accounts for purposes of tracking activity 

in subsidiary ledgers. 

• We use “customize” when referring to the ability to allow the agency to enter and modify 

displayed field labels, report titles, column headings, or user interface settings. For 

example: 

Customize dunning text displayed on system-generated bills. 

Input Requirements 

Input requirements describe how different types of information are to be entered into the 

system. Input requirements cover individual data items and documents. 

• We use “associate” when referring to establishing a relationship (i.e., link) between data 

records. Associations are normally created automatically by the underlying database 

software when new records are added. For example: 

Associate transactions posted to the general ledger with an originating 

document. 

• We use “capture” when the intention of the requirement is to store new information or 

link other stored data to a new record. Captured data can be user entered or system 

generated. The ability to subsequently retrieve, modify, or delete captured information is 

assumed. For example: 

Capture item description on each line of a commitment document, or, capture a 

system derived effective date. 

• We use “classify” when referring to capturing attributes that are subject to complex 

business rules. For example: 

Classify ALCs as "Governmentwide Accounting" (GWA) System reporters or 

Non-GWA System reporters. 

• We use “update” when the intention of the requirement is to allow the agency to modify 

an existing data record. Updates can be agency entered online or generated from an 

imported transaction file. 

Update posted transactions with the Treasury confirmed schedule, issue date, 

and assigned check number. 

Process Requirements 

Process requirements describe automated tasks performed on financial data as entered into the 

system. Processes include validating data, monitoring funds, notifying users, performing 

calculations, and distributing costs. Because process requirements cover a wide range of 

functionality, they are written using a variety of standard syntax rules. 
Appendix B—Requirement Drafting Guidelines 

Core Financial System Requirements B-3

• We use “archive” to specify functionality used to store processed, non-current data to a 

segregated storage area, subject to read access and retrieval. For example: 

Archive closed commitment, obligation, receipt, and expenditure documents. 

• We use “calculate” when referring to system functionality needed to compute a result 

based on a defined arithmetic formula. For example: 

Calculate late payment interest charges, or calculate a due date. 

• We use “derive” when referring to functionality the system uses in applying business 

rules. For example: 

Derive the amount of upward or downward spending adjustment. 

• We use “distribute” when referring to allotting funds or the assignment of accumulated 

costs. For example: 

Distribute funds to subordinate organizations. 

• We use “generate” when specifying requirements where the system must originate 

information. For example: 

Generate an audit trail of all accounting classification structure additions, 

changes, and deletions.

• We use “identify” to refer to the flagging or lookup/retrieval of information based on an 

entered parameter or defined rule. For example: 

Identify payments to be disbursed in a particular payment cycle. 

• We use “liquidate” when the intent is to reduce or close a line item on a referenced 

document. For example: 

Liquidate individual disbursement-in-transit transactions. 

• We use “monitor” to refer to the comparison of an accumulated amount against an 

established limit. For example: 

Monitor the use of funds. Prevent spending, warn or inform the agency when 

distributed authority is exceeded. 

• We use “notify” when the requirement is for the system to issue an e-mail or other 

online message to inform the agency of a processing exception. For example: 

Notify the agency when funds availability is reduced. 

We use “prevent” when the system is required to stop a user from completing an entry 

or initiating a process. In some cases, actions that are prevented based on funds control 

or line item tolerance checks are subject to override. For example: 

Prevent the recording of duplicate transactions. 
Appendix B—Requirement Drafting Guidelines 

Core Financial System Requirements B-4

• We use “process” to refer to the system manipulation of captured data. Processing can 

involve multiple steps. Processing can be triggered by user request, job submission, or 

other internal system logic. For example: 

Process suspended documents upon changes to funding data. 

• We use “record” when referring to the posting of transactions into the general ledger or 

journal. “Record” is usually followed by an accounting term such as assets, liabilities, 

accounts payable, equity, revenue, expenses, interest, depreciation, amortization, 

collections, receipts, payments, commitments, obligations, expenditures, authority, or 

appropriations. For example: 

Record a payment advance. 

• We use “reference” to refer to the association of document line items to prior document 

lines and their automatic liquidation. For example: 

Reference multiple prior documents in a processing chain. 

• We use “suspend” when requiring the system to place a document or other work item 

into a holding queue subject to later retrieval, correction, and completed processing. For 

example: 

Suspend incomplete documents and those that fail edits (i.e., save for later 

retrieval and processing).

• We use “validate” when requiring the system to confirm the validity of entered 

information against a defined business rule. For example: 

Validate that a duplicate vendor number was not entered. 

Query Requirements 

Queries describe requirements for accessing system-maintained information online. By default, 

query requirements must be satisfied using real-time Core application screen displays. Some 

complex, high-volume queries can optionally be satisfied using a separately delivered business 

information query (BIQ) tool (e.g., data warehouse). Unlike Core queries, BIQ queries are 

generally scripted, stored, and queued for execution. 

• We use “query” to specify data selection, summarization, and display. For example: 

Query related transactions. Parameters include any document number. Result is 

a list of general ledger transactions from all documents in the requested 

document’s processing chain. 

• We use “parameters include” to specify the selection criteria. When multiple 

parameters are listed, it is understood that one or any combination of the parameters are 

to be applied. Parameters should allow for selection of one value, a range of values, or 

all values. For example, 

Parameters include beginning effective date, ending effective date, and TAS or 

internal fund code.
Appendix B—Requirement Drafting Guidelines 

Core Financial System Requirements B-5

• We use “drill down” to specify functionality used to display detailed supporting entries 

for a query summarized record. For example: 

Drill down from listed documents to document details. 

Report Requirements 

Report requirements describe system-generated outputs that are subject to predefined form and 

content rules. Rules for external reports are separately defined by the GAO, OMB, Treasury, or 

EOP. Internal report requirements include the data to be listed or summarized as a part of the 

requirements text. 

• We use “generate a report” to describe the agency’s requirements for formatted output. 

For example: 

Generate an Open Commitments and Obligations Report. Select documents 

based on any combination of accounting classification elements (e.g., open 

commitments and obligations by organization). List the document number, 

unliquidated amount, vendor, and accounting classification string of each 

reported document. 

• We use “output options include” to specify sorting options or other special format 

requirements. Reports must be printable by default. Some reports can be designated as 

online and subject to additional drill-down. For example: 

Output options include sorting and summarizing reported data by fund or 

organization code. 

Interface Requirements 

Interface requirements define the need to exchange data with another internal agency or an 

external governmentwide system. An example of an internal interface is the requirement for an 

acquisition system to generate transactions needed to establish commitments in the Core 

system. An example of an external interface is the requirement for the Core system to generate 

a payment file suitable for transmission to Treasury’s ECS. 

• We use “import” when requiring the system to receive and process data originated in 

another financial or mixed system. For example: 

Import collection files from banks for application to open receivable, or import 

CCR updates. 

• We use “export” when the intention of the requirement is to generate and send a 

transaction file to another system for processing. For example: 

Export plan information at the line item level. 
Appendix B—Requirement Drafting Guidelines 

Core Financial System Requirements B-6

Non-Functional Requirements 

Non-functional requirements are used to reference standards, rules, or policies maintained by 

others to be incorporated into a delivered system. Non-functional requirements are used 

throughout the technical area. 

• We use “comply” with a defined external standard. For example: 

Comply with Workflow Management Coalition (WFMC) Workflow Standard–

Interoperability. 

• We use “deliver” to specify non-functional features that must be included as part of the 

baseline product. For example: 

Deliver user, system, and operating documentation. 

• We use “support” for requirements that reference a defined government policy. For 

example:

Support CCR rules for coding business type. 

• We use “incorporate” to specify principles and best practices that should be reflected in 

a delivered package For example: 

Incorporate open-systems architecture. 

• We use “operate” to specify computing environments in which a package should or must 

be designed to run. For example: 

Operate in a server computing environment running under UNIX, LINX, Windows 

Server 2000 or above. 

. 
Core Financial System Requirements C-1

Appendix C—Standard Core Financial System Reports 

Title (Form) Purpose Level Basis Frequency Guidelines

Report on Budget 

Execution and 

Budgetary 

Resources (SF 133) 

Report status of 

budgetary 

resources 

TAS Modified 

Cash 

On demand OMB Circular 

A-11 

Federal Agencies 

Centralized Trial 

Balance System 

(FACTS I) 

Report data for 

consolidation from 

FACTS I into the 

Financial Report of 

the U.S. 

Government 

Appropriation/ 

Fund Group 

Accrual Quarterly I TFM-2-4000 

Federal Agencies 

Centralized TrialBalance System 

(FACTS II) 

Report status of 

budgetary 

resources 

Appropriation/ 

Fund Account 

Accrual Quarterly Current TFM 

U.S. SGL 

Supplement 

FACTS II Client 

Bulk User’s 

Guide 

Treasury Report on 

Receivables (TROR) 

Provide 

information on the 

status of public 

receivables and 

delinquencies 

Appropriation/ 

Fund Account 

(but can vary) 

Accrual Quarterly I TFM-2-4100 

Statement of 

Transactions 

(FMS-224, FMSP224) 

Report 

disbursements 

collections, and 

status of 

collections 

Agency Location 

Code by 

Appropriation/ 

Fund Account 

Cash Monthly I TFM-2-3300 

Report of 

Accountability 

(FMS-1219) 

Provide an 

analysis of 

disbursing officers’ 

activities in 

agencies that do 

not do their own 

disbursing 

Agency Location 

Code and 

Disbursing 

Officer 

Cash Monthly I TFM-2-3100 

Statement of 

Transactions 

(FMS-1220) 

Report 

disbursements and 

collections in 

agencies that do 

their own 

disbursing (the 

counterpart to 

FMS-224) 

Agency Location 

Code and 

Appropriation/ 

Fund Account 

Cash Monthly I TFM-2-3100 

Information Returns: 

(IRS 1099-C,1099-

G, 1099-MISC) 

Provide 

information to the 

IRS on payments 

made or debts 

forgiven 

Taxpayer 

Identification 

Number 

Cash Annually IRS instructions 

for forms 1099, 

1098, 5498, and 

W-2G 
Appendix C—Standard Core Financial System Reports 

Core Financial System Requirements C-2

Title (Form) Purpose Level Basis Frequency Guidelines

Balance Sheet Disclose statement 

of assets, 

liabilities, and net 

position 

Department Accrual Quarterly OMB bulletin on 

form and 

content 

Statement of Net 

Cost 

Report gross costs 

less revenue 

earned 

Department Accrual Quarterly OMB bulletin on 

form and 

content 

Statement of 

Changes in Net 

Position 

Report financing 

sources, gains, 

and losses 

Department Accrual Quarterly OMB bulletin on 

form and 

content 

Statement of 

Budgetary 

Resources 

Report available 

budgetary 

resources and 

status 

Department Obligation/

Accrual 

Quarterly OMB bulletin on 

form and 

content 

Statement of 

Financing 

Report on 

reconciliation 

between 

proprietary and 

budgetary 

accounts 

Department Accrual Quarterly OMB bulletin on 

form and 

content 

Statement of 

Custodial Activity 

Report nonexchange revenue

Department Accrual Quarterly OMB bulletin on 

form and 

content 

 
2005 Core Financial System Requirements D-1

Appendix D—Contributors 

Office of Management and Budget 

Office of Federal Financial Management 

Daniel Werfel 

Wayne Leiss 

Bill Apgar 

Hans Heidenreich 

Agency for International Development 

Steve Crabtree 

Corporation for National and Community Service 

Adam Liu 

Pete Rudman 

Department of Commerce 

Robert Bair 

Patricia Jackson 

Karen McBride 

James L. Taylor 

Lynn Wilson 

Patent and Trademark Office 

Michelle Picard 

Gita Zoks 

Department of Agriculture 

Kay Levy 

Pauline Myrick 

Jon Sandy 

Wendy Snow 

Department of Defense 

Mark Doehnert 

Defense Finance Accounting Service 

Tom Prince 
Appendix D—Contributors 

Core Financial System Requirements D-2

Defense Logistics Agency 

Jim Olaughlin 

Department of Education 

 Mark Carney 

 Angela Butler 

Department of Energy 

Deanna Ammons 

Linda Denoff 

Ed Golden 

Warren Huffer 

Bonneville Power Administration 

David Rubin 

National Nuclear Security Administration 

Eileen Rountree-McLennan 

Department of Health and Human Services 

Scott Brna 

Bill Brown 

Steve Cohen 

Eric Houser 

Dennis Loveless 

Ed Martin 

Margie Yanchuk 

Matt Zakiefarz 

Department of Homeland Security 

Gerald Ross 

James Mich 

Department of Justice 

Mark Busby 

Jeffrey Cadman 

Brad Callery 

Ken Klaus 

Darryl Lawson 

Robert Mathews 

Dana Rosensweig 

Sonal Vashi 
Appendix D—Contributors 

Core Financial System Requirements D-3

Department of Labor 

Pat Clark 

Ed Winkler 

Department of State 

Sally Zottnick 

Department of the Interior

Monica Taylor Lane 

Department of the Treasury 

Elois Adair 

Tajuan Brown 

Robert Deans 

David Epstein 

JoJo Ferguson 

Robin Gilliam 

Betty Harvey 

Jeff Hoge 

Wally Ingram 

Margaret Kaeser 

Patrick Mezzetta 

Matthew Miller 

Larry Rosenberg 

Judy Yuran 

Internal Revenue Service 

Mark Dale 

David Hensley 

Kathleen Miller 

Jack Roziner 

Chuck Sarahan 

Thuan Truong 

Office of the Comptroller of the Currency 

Sandra Butler 

Carolyn Horlor 

Angela Williams 

Department of Veterans Affairs 

Lorraine Grant 

Pete Mulhern 

Bill Walsh 
Appendix D—Contributors 

Core Financial System Requirements D-4

Environmental Protection Agency 

Sue Arnold 

Lisa Ayala 

Judi Brown 

Larry Burnham 

Valerie Chun 

Joe Dillon 

Juanita M. Galbreath 

Heidi Gross 

Terry Ouverson 

Martin Poch 

Charles Young 

Federal Communications Commission 

Tim Taylor 

General Services Administration 

Ameer R. Alzer 

Timothy Burke 

Lloyd Cherry 

Ed Cox 

Kenneth A. Dressner 

Jan Fulk 

Douglas A. Glenn 

Ed Gramp 

Terry Gricher 

David Hollar 

David Horn 

Lynne Johnson 

Peter Kapsales 

Fang Li 

Tim Long 

Ray Najib 

Ellen Pierzchala 

John W. Potocko 

Mark Sayr 

Dennis Schroff 

Dave Straka 

Anh Tang 

Kent Taylor 

Norma Tolson 

Kevin Young 
Appendix D—Contributors 

Core Financial System Requirements D-5

Government Accountability Office 

Yang Hahn 

Thomas Placentrat 

Department of Housing and Urban Development 

Gail B. Dise 

Mary L. Kohlmeier 

Linda Rodgers 

Tammy Smutney 

Tom Stein 

National Aeronautics and Space Administration 

Chuck Calhoun 

Charlene Williams 

National Science Foundation 

Ed Miller 

Jannell Rennie 

Preston Rich 

Nuclear Regulatory Commission 

Russell Allwein 

Office of Personnel Management 

Gisele Jones 

Jim Loiselle 

Gerald Thomas 

Dorran Thompson 

Social Security Administration 

Thomas J. Bianco 

Financial Systems Integration Office (Formerly JFMIP) 

Doris Chew, Acting Director 

Dennis Mitchell 

Stephen Balsam 

Steven Fisher 
Appendix D—Contributors 

Core Financial System Requirements D-6

Program Office Support (LMI)

Ronald Rhodes 

Duane Whitt 

Mike Allen 

Rob Capozzi 

Kathy Crampton 

Debra Dunn 

Loan Nguyen 

Carol Pickens 

Maureen Stratford 

Milissa Young-Loiselle