Benefit 

System 

Requirements

Federal 

Financial 

Management 

Systems 

Requirements

JFMIP-SR-01-01 

September 2001
 

What is JFMIP? 

The Joint Financial Management Improvement Program (JFMIP) is a joint undertaking of the: U.S. Department 

of the Treasury; General Accounting Office (GAO); Office of Management and Budget (OMB); and Office of 

Personnel Management (OPM), working in cooperation with each other, with other agencies, and with the 

private sector, to improve financial management in the Federal Government. The Program was given statutory 

authorization in the Budget and Accounting Procedures Act of 1950 (31 United States Code (U.S.C.) §65). 

Leadership and program guidance are provided by the four Principals of the JFMIP – Comptroller General of 

the United States; Secretary of the Treasury; Director of OMB; and Director of OPM. Each Principal designates 

a representative to serve on the JFMIP Steering Committee, which is responsible for the general direction of the 

Program. The Executive Director of JFMIP is a permanent member of the Steering Committee, and is also 

responsible for day-to-day operations of JFMIP. Additionally, a representative from the Federal community 

serves on the Committee for a 2-year term. 

The Program promotes strategies and sponsors projects to improve financial management across the Federal 

Government; participates in the financial management activities of central policy organizations; and facilitates 

the sharing of information about good financial management practices. Information sharing is accomplished 

through conferences and other educational events; newsletters; meetings with interagency groups and agency 

personnel; and the Internet. 

For information on JFMIP, call (202) 219-0526, or visit the JFMIP Web site at: 

http://WWW.JFMIP.GOV
 

Foreword 

This Benefit System Requirements document is one of a series of documents published by the JFMIP on Federal 

financial management system functional requirements. It reflects financial system requirements associated with 

Federal benefit systems (hereafter referred to as benefit systems) used in administering programs that do not 

involve a health care component (i.e., non-health care benefit programs). The majority of systems that are 

subject to the provisions of this document pertain to Federal retirement, disability, death, survivor, and other 

income protection programs. For example, it applies to systems used in administering social security, civil 

service, military, railroad and foreign service retirement programs, various veterans’ benefits, and various 

disability programs (see chart A on p.10). 

This document addresses the goal of the Chief Financial Officers (CFO) Council and the JFMIP to improve the 

efficiency and quality of financial management in the Federal Government. It also addresses the CFO Act of 

1990, the Government Management Reform Act (GMRA) of 1994, and the Federal Financial Management 

Improvement (FFMIA) of 1996 that strongly reaffirmed the need for the Federal Government to provide 

financial systems that facilitate the effective management of Government programs and services and the proper 

stewardship of public resources. 

The provisions in this document constitute Federal requirements for benefit systems. Agencies must use these 

functional requirements in planning their benefit system improvement projects. It is the responsibility of each 

agency to be knowledgeable of the legal requirements governing its benefit operations; therefore, agencies may 

develop additional technical and functional system requirements as needed to support unique mission 

responsibilities. Further, the provisions of this document supplement existing statutes, regulations, and Federal 

policy concerning financial management systems. In the event a requirement conflicts with existing agency 

specific statutes or regulations, the law, statute or regulation takes precedence. Agencies must also develop 

strategies for interfacing or integrating benefit systems with their core financial and other applicable systems. 

As is stated in the document, our use of the term “benefit system” is not intended to imply that a single system 

component (module) or software application must independently perform all of the functions herein required of 

a benefit system. Rather agencies are encouraged to maximize data exchange among the components of an 

integrated financial system. 

We thank the agency officials and others in the financial, benefit program management, and information 

technology communities who contributed to this document. We value their assistance and support. With 

continuing support such as theirs, we can face the financial management challenges of this new century with 

confidence. 

Karen Cleary Alderman 

Executive Director

 

Acronyms 

ACH Automated Clearing House 

ALC Agency Location Code 

CDO Chief Disbursing Officer 

CFO Chief Financial Officer 

CFR Code of Federal Regulations 

CSRS Civil Service Retirement System 

DCA Debt Collection Act of 1982 

DCIA Debt Collection Improvement Act of 1996 

DOD Department of Defense 

DOL Department of Labor 

EFT Electronic Funds Transfer 

FACTS Federal Agencies’ Centralized Trial-Balance System 

FASAB Federal Accounting Standards Advisory Board 

FERS Federal Employees Retirement System 

FFMIA Federal Financial Management Improvement Act of 1996 

FFMSR Federal Financial Management System Requirements 

FMS Department of the Treasury Financial Management Service 

GAO General Accounting Office 

GMRA Government Management Reform Act of 1996 

GPRA Government Performance and Results Act of 1994 

HHS Department of Health and Human Services 

IVR Interactive Voice Response 

IRS Internal Revenue Service 

JFMIP Joint Financial Management Improvement Program 

NARA National Archives and Records Administration 

OMB Office of Management and Budget 

OPM Office of Personnel Management 

RRB Railroad Retirement Board 

SSA Social Security Administration 

SSN Social Security Number 

SFFAS Statements of Federal Financial Accounting Standards 

TAFS Treasury Account Fund Symbol 

TIN Taxpayer Identification Number 

TOP Treasury Offset Program 

TFM Treasury Financial Manual 

U.S.C. United States Code 

U.S. SGL United States Standard General Ledger 

VA Department of Veterans Affairs 

Illustrations (List) 

1. Financial System Improvement Projects .....................................................................................4

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

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

4. Typical Interactions of a Benefit System...................................................................................12 

 

Table of Contents 

Forward 

Acronyms and Illustrations List 

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

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

Benefit System Overview.................................................................................................................8 

 Background..........................................................................................................................8 

Management Controls .......................................................................................................11 

Benefit System Major Functions .......................................................................................11 

Relationship with Other Systems ......................................................................................12 

Information Stores - Data Requirements Overview ......................................................................13 

Functional Requirements................................................................................................................14 

Claims Acceptance and Tracking......................................................................................14 

Claims Processing .............................................................................................................15 

Benefit Payment Administration .......................................................................................18 

Recovery Receivable Management ...................................................................................26 

Accounting for Benefit Transactions.................................................................................30 

Reporting ...........................................................................................................................33 

Interfaces ...........................................................................................................................36 

Quality Assurance and Maintenance .................................................................................37 

Technical Functional Requirements ..................................................................................38 

Information Stores – Required Data Elements ...............................................................................42 

Application Information Stores .........................................................................................42 

Claimant Master Record Information Store ......................................................................46 

Program Criteria Information Store...................................................................................46 

Financial Information Store...............................................................................................46 

Appendix A: References.................................................................................................................48 

Appendix B: Glossary ....................................................................................................................50 

Appendix C: Contributors .............................................................................................................52 

 Introduction 

Introduction

The citizens of the United States entrust the stewardship of Federal Government financial resources and assets to 

the legislative and executive branches of Government. Financial and program managers are accountable for 

program results and are fiscally responsible for the resources entrusted to them. Managers must understand that 

their daily actions have financial implications for taxpayers and affect the amount of public debt the Federal 

Government must assume to support Government initiatives. Furthermore, managers need timely and reliable 

information essential for monitoring budgets, operations, and program performance. 

The Federal Government recognizes the importance of having high quality financial systems to support 

improvement of Government operations and to provide useful financial and related information to program and 

financial managers. The CFO Act of 1990, GMRA, and FFMIA of 1996 mandate improved financial 

management, assign clearer responsibility for leadership to senior officials, and require new financial 

organizations, enhanced financial systems, and audited financial reporting. 

Improving Federal financial management systems is critical for: increasing the accountability of financial and 

program managers, providing better information for decision-making, and increasing the efficiency and 

effectiveness of services provided by the Federal Government. Proficient and reliable financial management 

systems must provide for: 

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

understand, about how the Nation’s tax dollars are spent, and how Federal assets are protected. 

Efficiency and Effectiveness. Provide efficient and effective service to the Federal agency’s internal 

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

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

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

linking financial results and program data so that financial and program results of policy and program 

decisions can be identified, tracked, and forecasted more accurately. 

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

management systems. Each agency is required to develop and maintain a single, integrated financial 

management system. To support this requirement, each agency must have an ongoing financial systems 

improvement planning process and periodic reviews of financial system capabilities. In addition, each agency 

must maintain financial management systems that comply with uniform Federal accounting concepts and 

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

Federal Financial Accounting Standards (SFFAS) which constitute generally accepted accounting principles for 

the Federal Government.

System requirements for common systems have been prepared under JFMIP direction as a series of publications 

entitled “Federal Financial Management System Requirements” (FFMSR). The FFMIA statute codified the 

FFMSR as key benchmarks that agency systems must meet to be substantially in compliance with system 

requirements provisions under FFMIA. This Benefit System Requirements document has been prepared as a 

continuation of the FFMSR series that began with the Core Financial Systems Requirements document in 

January 1988. 

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

managers, and others, who design, develop, implement, operate, and maintain or audit financial management 

systems.

Benefit System Requirements 1
 Federal Financial Management Framework 

 

Federal Financial Management Framework 

This document provides high level functional requirements for benefit systems that will help provide the 

capability for financial managers, program managers and others to control and account for Federal benefit 

programs as defined in governmentwide and agency specific statutes, regulations, guidelines and need 

assessments. This document is one component of a broad program to improve Federal financial management. 

This program involves establishing uniform requirements for financial information, financial systems, reporting, 

and financial organizations. Appendix A contains a listing of relevant governmentwide accounting standards, 

laws, regulations and other mandates pertaining to Federal benefit programs. 

As shown in Illustration 1, Financial Systems Improvement Projects (see p.4), establishing uniform 

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

Improvements can be achieved through the selection, development, and or purchase of applications that meet 

approved functional requirements and technical and data management specifications. Agencies must continue to 

improve their financial systems and implement new requirements as they are issued so that continuing efforts to 

standardize and upgrade data and reporting requirements, in accordance with OMB’s governmentwide 5-year 

financial management plan, will be successful. 

Well defined and effective governmentwide functional requirements will assist agencies in developing strong 

systems and information by eliminating duplicate work among agencies and providing a common framework so 

that outside vendors can more economically provide systems software. Development of such requirements for 

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

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

governmentwide financial management systems and compatible agency systems, with standardized information 

and electronic data exchange to support program delivery, safeguard assets, and manage taxpayer dollars. 

Each agency should integrate its unique requirements with these governmentwide standard requirements to 

provide an effective and uniform basis for the standardization of financial management systems as required by 

the CFO Act of 1990, FFMIA of 1996, and other statutes. 

Financial management systems in the Federal Government must be designed to support the vision articulated by 

the Government's financial management community. This vision requires financial management systems to 

support the partnership between program and financial managers and to assure the integrity of information for 

decision-making and measuring performance. This includes the ability to:

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

• provide for adequate agency management reporting; 

• support governmentwide and agency-wide policy decision-making; 

• ts and other financial reports in accordance with 

• ting, analysis, and governmentwide reporting, 

• support the preparation and execution of agency budgets; 

facilitate the preparation of financial statemen

Federal accounting and reporting standards; 

provide information to central agencies for budge

including consolidated financial statements; and 

• provide a complete audit trail to facilitate audits. 

2 Benefit System Requirements 
 Federal Financial Management Framework 

 

 

It is critical that financial management systems support the agency's mission and programs, including changes to 

them, and that financial management system plans are incorporated into the agency's plans for informati

technology infrastructure and information systems as a whole. Further, systems design efforts should include an 

analysis of how system improvements, new technology supporting financial management systems, and 

modifications to existing work processes can together enhance agency

on 

 operations and improve program and 

financial management. Reassessing information and processing needs and redesigning processes, procedures, 

and policies are essential steps to meeting user needs. 

Benefit System Requirements 3
 

 Federal Financial Management Framework 

Financial System Im provem ent Projects

Agency Implementation



 Ada pta tion



 Proc e dure s



 Tra ining 



 Doc um e nta tion



 Conve rsion



 M a inte na nc e

Subje c t of 

this doc ume nt



Additiona l 

 Agency 

 Func tiona l 

 Re quire m e nts



Additiona l 

 Agency 

 Te c hnic a l 

 Re quire m e nts



Inte gra tion 

 Stra te gy



Softwa re / 

 Ha rdwa re 

 Eva lua tion



Softwa re 

 Se le c tion

Standards/ 

R equirements 

Sta nda rd Re porting 

Re quire m e nts 

U.S. G ove rnm e nt Sta nda rd 

G e ne ra l Le dge r 

Core Fina nc ia l Syste m 

Re quire m e nts 

Hum a n Re sourc e s & 

Pa yroll Syste m s 

Re quire m e nts 

Tra ve l Syste m 

Re quire m e nts 

Se ize d Prope rty a nd 

Forfe ite d Asse ts Syste m s 

Re quire m e nts

Dire c t Loa n Syste m 

Re quire m e nts

G ua ra nte e d Loa n Syste m 

Re quire m e nts 

Inve ntory Syste m 

Re quire m e nts 

M a na ge ria l Cost 

Ac c ounting 

Prope rty M a na ge m e nt 

Syste m Re quire m e nts

O the r Sta nda rds

Syste m Re quire m e nts for 

Be ne fit Syste m 

Re quire m e nts 

Illustration 1 

4 Benefit System Requirements 
 Federal Financial Management Framework 

 

 

Integrated Financial Management Systems

Financial management systems must be designed with effective and efficient interrelationships between 

software, hardware, personnel, procedures, controls, and data contained within the systems. To be integrated, 

financial management systems must have, as a minimum, the following four characteristics: 

(1) Standard data classifications (definitions and formats) established and used for recording financial 

events; 

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

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

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

The CFO Act of 1990 and financial management systems policy described in OMB Circular A-127 “Financial 

Management Systems” require that each agency establish and maintain a single integrated financial management 

system. Without a single, integrated financial management system to ensure timely and accurate financial data, 

poor policy decisions are more likely to occur, due to inaccurate or untimely information. Managers are also 

less likely to be able to report accurately to the President, the Congress, and the public on Government 

operations in a timely manner. Scarce resources are more likely to be directed toward the collection of 

information rather than to delivery of the intended programs. And, modifications to financial management 

systems necessary to keep pace with rapidly changing user requirements cannot be coordinated and managed 

properly. The basic requirements for a single, integrated financial management system are outlined in OMB 

Circular A-127, “Financial Management Systems. 

Having a single, integrated financial management system does not necessarily mean having only one software 

application that covers all financial management system needs. Rather, a single, integrated financial 

management system is a unified set of financial systems and the financial portions of mixed systems1

encompassing the software, hardware, personnel, processes (manual and automated), procedures, controls, and 

data necessary to carry out financial management functions, manage financial operations of the agency, and 

report on the agency's financial status to central agencies, Congress, and the public. However, it does not mean 

that all information is physically located in the same database. 

Unified means that systems are planned and managed together and linked together electronically in an efficient 

and effective manner to provide agency-wide financial system support necessary to carry out the agency's 

mission and support the agency's financial management needs. 

Interfaces where one system feeds data to another system following normal business and transaction cycles, 

such as the benefit system providing summary level benefit payment data to the core system for posting in the 

general ledger at specific time intervals, may be acceptable as long as the supporting detail is maintained and 

readily accessible to managers. Additionally, for determining compliance with FFMIA, the implementation 

guidance issued by OMB requires that the posting rules in the feeder system (when applicable) must be 

consistent with the U.S. Standard General Ledger (U. S. SGL) posting rules. Also, a funds control mechanism 

must be present in the feeder system unless two-way communication encompasses funds availability 

verification. Interfaces must be automated unless the number of transactions is so small that it is not cost-

 

1

 An information system that supports both financial and non-financial functions of the Federal Government or components 

thereof. See OMB Circular A-127. 

Benefit System Requirements 5
 

 Federal Financial Management Framework 

beneficial to automate the interface. Reconciliation between systems, where interfaces are appropriate, must be 

maintained to ensure data accuracy. 

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

identify: 

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

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

• information to be processed (management information), 

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

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

All of these pieces, as shown in Illustration 2, must work together to form an efficient integrated information 

system. A change to any part of the model will require determining the impact on other parts of the model. For 

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

Integrated Model for

Federal Information Systems

D ata Stewardship

Processes

Management

Information

Systems

Architecture

Illustration 2 

 necessary to carry out fiduciary responsibilities, and support the preparation of auditable 

financial statements. 

Agency Financial Management Systems Architecture 

Agency financial management systems are information systems that track financial events and summarize 

information to support the mission of an agency, provide for adequate management reporting, support agency 

level policy decisions

6 Benefit System Requirements 
 Federal Financial Management Framework 

` 

 

Agency financial management systems fall into four categories: 

(1) Core financial systems; 

(2) Other financial and mixed systems, (such as benefit systems); 

(3) Shared systems; and 

(4) Departmental executive information systems (systems to provide management information to all 

levels of management) 

These systems must be linked together electronically to be effective and efficient. Summary data transfers must 

be provided from agency systems to central systems to permit summaries of management information and 

agency financial performance information on a governmentwide basis. 

Subject to governmentwide policies, the physical configuration of financial management systems, including 

issues of centralized or decentralized activities, processing routines, data, and organizations, is a determination 

that is best left to individual agencies. Agencies can determine the optimal manner in which to support their 

own mission. When determining the physical design of the system, agencies should consider their 

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

necessary single integrated financial management system. 

Agency Financial Management Systems Architecture

Core

Financial

System

Revenue

System

Budget Formulation

System

Non-financial

Systems

Travel

System

Seized Property & Forfeited

Asset

System

Guaranteed

Loan

System

Inventory

System

Insurance Claim

System

Grant

System

Financial

Reporting

System

Managerial Cost Account ni g

Depart ment al Execut i ve Informat i on Syst em

Human Resources

& Payroll

System

Property Management System

Direct

Loan

System

Acquisition

System

Benefit System

Illustration 3 

. 

The agency systems architecture depiction shown in Illustration 3 shows the typical components of an integrated 

Federal financial management system. Although this does not necessarily represent the physical design of the 

system, it does identify the types of systems needed to support program delivery/financing and financial event 

processing for effective and efficient program execution. 

Benefit System Requirements 7
 

Benefit System Overview 

Benefit System Overview 

This section provides an overview of a benefit system in the following sections: Background, Management 

Controls, Benefit System Major Functions, Relationship with Other Systems, and Information Stores - Data 

Requirements Overview. 

Background 

General Information 

The United States Government is the world’s largest and most complex enterprise. In fiscal year 2001, Federal 

agencies disbursed over a half-trillion dollars in Federal non-health care2

 benefits (hereafter referred to as 

benefits) to millions of recipients. These outlays are controlled and accounted for in various agency systems. 

This document is intended to specify the baseline functional capabilities which benefit systems must have in 

order to support agency missions and comply with laws and regulations. This section provides a brief 

explanation of why benefit system requirements are needed and provides an overview of the types of benefit 

systems subject to the requirements contained within this document. 

Establishing governmentwide benefit system requirements promotes a common understanding among private 

and public sector financial managers and benefit program managers regarding benefit system functional 

capabilities. They provide benchmarks for agency compliance under FFMIA and serve as a tool for oversight 

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

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

software must be able to provide to Federal agencies, as well as identifying value-added features desired by 

Federal agencies. 

Policy 

Government benefit systems, as components of the Federal Agency Systems Architecture (see Illustration 3) are 

relied upon to feed data to the financial management systems, which are used to produce agency consolidated 

financial statements. Federal Government benefit systems must provide consistent standardized information for 

program managers, financial managers, agency executives, and oversight organizations. Furthermore, all 

benefit systems being designed and implemented or that are currently in use must operate in accordance with 

laws, regulations, and judicial decisions. 

This document identifies mandatory and value-added financial functional requirements for Federal benefit 

systems. Although the document may be used when developing new benefit systems or improving/evaluating 

current systems, the document does not provide a specific model for such systems. Any functional requirements 

that are not mandated by law, regulation, directive, or judicial decision should be incorporated in these systems 

only if cost-effective and in the Government’s best interest. All possible alternatives for meeting the 

requirements should be considered. 

Benefit system functional requirements are designated as mandatory and value-added. Definitions for these two 

categories are: 

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

acceptable functionality necessary to establish a system, or are based on Federal laws and regulations. 

Mandatory requirements are those against which agency heads evaluate their systems to determine 

substantial compliance with systems requirements under the FFMIA. These requirements apply to existing 

systems and new systems that are planned or under development. 

 

2

 See glossary at appendix B for definition of health care benefit program. 

8 Benefit System Requirements 
 Benefit System Overview 

 

Value-added – Value-added requirements describe features or characteristics and may consist of any 

combination of the following: (1) using state-of-the-art technology, (2) employing preferred or best 

business practices, or (3) meeting the special management needs of an individual agency. Value-added, 

optional, and other similar terminology may be used to describe this category of requirements. Agencies 

should consider value-added features when judging systems options. The need for these value-added 

features in agency systems is left to the discretion of each agency head. 

Within this document, mandatory benefit system requirements are indicated by the word “must”; value-added 

system requirements are identified by use of the words “may” or ”should.”

What is a Federal Benefit System? 

In general, a Federal benefit system is a unified mixed3 system used in administering a Federal benefit program 

(see characteristics below). Taken as a whole, the components of the unified system accomplish the major 

functions specified on p. 11. As previously noted, the term benefit system does not mean that specific system 

architecture is required or that only a single software application is used. A benefit system includes all of the 

modules, applications and data bases used in fulfilling the major functions as defined in this document 

regardless of whether the function is performed in one or more information system. For example, the mandatory 

data elements that are specified in the information stores section of this document may reside in a central data 

base that is accessed by a variety of systems (e.g., core, benefits, debt management, or others) or multiple data 

bases in various locations. The term “benefit” has been widely used in reference to Federal programs. Use of 

the term has encompassed programs such as food stamps, Medicare, Veterans Health care, unemployment 

benefits, and others. In fact, there is no steadfast universal definition of a Federal benefit program. However, 

for purposes of this document, a Federal benefit program excludes health care related programs, such as 

Medicare, Veterans Health, Tricare, and others whose primary functions involve reimbursement for services 

provided and providing direct care. This document identifies five main categories that comprise Federal benefit 

programs, they are; retirement, disability, death , survivor, and other. Although disability programs typically 

involve an initial medical diagnosis and reimbursement for certain medically related expenses, a primary 

objective of disability programs is to provide income protection to individuals because their earning capacity has 

been diminished. Therefore disability programs are included as a non-health care Federal benefit program. 

Benefit programs generally have certain common characteristics. The criteria below should be used in 

determining whether a program is a Federal benefit program, and therefore whether the related financial 

system(s) are subject to the requirements specified herein. 

Benefit program characteristics generally include all or most of the following: 

1. The program is classified as “mandatory” rather than discretionary under the Budget Enforcement Act 

classification. 

2. The systems used in daily operations are owned and operated by the Federal Government. 

3. The majority of monetary payments are provided directly to individuals or a designee as opposed to 

reimbursement to service providers. 

4. The Federal Government determines the exact amount of the benefit payment. 

5. A “fixed amount” recurring payment is frequently involved. 

6. The program and related system are not addressed in any other FFMSR issued by JFMIP. For example, 

the Department of Agriculture uses a grant system to provide funding for the food stamp program. 

Therefore, grant system requirements apply to that program. 

 

3

 An information system that supports both financial and non-financial functions of the Federal Government or components 

thereof. See OMB Circular A-127. 

Benefit System Requirements 9
 

Benefit System Overview 

Chart A lists examples (i.e., it is not an all-inclusive listing) of existing Federal benefit programs for which the 

related financial systems are subject to the requirements specified in this document. Any system used to 

administer future Federal benefit4

 programs that may be established subsequent to the issuance of this document 

will also be subject to these system requirements. 

Chart A - Examples of Federal Benefit Programs

Program Name/Description5 Department/Agency 

Federally Administered Retirement 

Civil service retirement system (CSRS) OPM 

Coast guard retirement Department of Transportation 

Commissioned corps. retirement Department of Health and Human 

Services (HHS) 

District of Columbia Judicial Retirement (and Federal pension) Treasury 

Federal employees retirement system (FERS) OPM 

Foreign service retirement Department of State 

Old age Social Security Administration 

(SSA) 

Railroad retirement programs Railroad Retirement Board (RRB) 

Retired military pay Department of Defense (DOD) 

Veterans pensions Department of Veterans Affairs 

(VA) 

Elements of the Federal Thrift Savings Plan Department of Agriculture 

Disability Related 

Black lung Department of Labor (DOL) 

Disability OPM, SSA 

Energy employees occupational illness DOL 

Federal employees compensation DOL 

Longshore and harbor workers compensation DOL 

Railroad sickness RRB 

Supplemental security income SSA 

Veterans compensation VA 

Veterans readjustment VA 

Vaccine injury compensation HHS 

Death 

Death benefit OPM, SSA 

Federal employees death benefit DOL 

Railroad death benefit RRB 

Veterans burial VA 

Survivors 

Various survivor programs DOD, DOL, OPM, RRB ,SSA 

Department of State, VA 

Other 

Veterans education VA 

Railroad unemployment RRB 

 

4

 As herein defined. 

5

 Program name or description does not necessarily equate to the name of the related Treasury Account Fund Symbol (TAFS). 

10 Benefit System Requirements 
 Benefit System Overview 

 

Federal agencies’ benefit systems are critical for maintaining financial accountability over Federal benefit 

programs. Such systems also serve important roles to help ensure that benefit programs are properly managed in 

accordance with missions and roles established by Congress. The system requirements outlined in this 

document are intended to support functional requirements that have a direct financial impact on the agency 

administering the program. Benefit systems may also require functionality which may not necessarily have a 

direct financial impact or which is agency specific. 

Management Controls

Benefit systems must incorporate appropriate controls to ensure the accuracy of data entry, completeness and 

consistency of transaction processing and reporting, as stated in OMB Circular A-127. Certain controls are 

typically incorporated into software applications, such as input controls. Other controls such as proper 

segregation of duties may be implemented as a feature of software functionality, as a manual process, or both. 

This document contains some specific requirements for implementing basic management controls within the 

appropriate functional area (e.g. funds control, claims processing, etc.). However, each agency is responsible 

for implementing adequate controls to ensure the benefit system is operating as intended. 

Benefit System Major Functions 

The major functions typically performed by a unified benefit system are listed below. The Functional 

Requirements section contains a detailed description of each function. Requirements described in this document 

can be accommodated in multiple software applications or by using the functional capability of other systems. 

A benefit system tracks the life of claims from initial receipt through final payment and maintains a complete 

history of financial activity relating to those claims. The Federal benefit system primarily consists of nine major 

functions and the data processed by those functions. These functions are: 

1. Claims Acceptance and Tracking 

2. Claims Processing 

3. Benefit Payment Administration 

4. Recovery Receivable Management 

5. Accounting for Benefit Transactions 

6. Reporting 

7. Interfaces 

8. Quality Assurance and Maintenance 

9. Technical Functions

Each of the above functions is addressed in detail in the Functional Requirements section. It is important to note 

that certain of these functions, such as benefit payment administration and recovery receivable management may 

be performed completely or partially by other systems that are not solely dedicated to supporting benefit 

programs (e.g. core system). If these functions are performed by other systems, those systems are subject to and 

must also perform the appropriate requirements specified within the related functional area of this document. 

Benefit System Requirements 11
 

Benefit System Overview 

Relationship with Other Systems 

Illustration 4 shows how a benefit system relates to other external and internal agency systems. There are 

various ways a benefit system may be designed and configured. As indicated in the Venn diagram below, the 

benefit system may contain a payment module that generates payments and maintains detailed (claim holder) 

account information, and subsequently sends summary level data to the core system. Alternatively, the benefit 

system may interface with the core system to exchange detailed information and utilize the payment 

functionality of the core system. Additionally, the system may employ a combination of both methods. These 

alternate methods may also apply to receivable processing and servicing and other functions. 

Typical Interactions of a Benefit System

OMB

Systems Treasury

Offset

External Data

Systems

Illustration 4 

 

12 Benefit System Requirements 
 Information Stores Overview 

 

Information Stores - Data Requirements Overview 

The benefit system stores, accesses, and or updates several types of data. In this document, a grouping of 

related types of data is referred to as an information store. The term information store (rather than database or 

file) is used to avoid any reference to the technical or physical characteristics of the data storage medium. 

Actual data storage (physical databases and files) must be determined by each agency during system 

development and implementation based upon the benefit program’s statutory requirements as well as the 

agency’s technical environment, processing volumes, organizational structure, and degree of system 

centralization or decentralization. This section briefly describes the four information stores. The detailed data 

elements required in each information store are covered in detail beginning on p. 42. 

Application Information Stores 

This refers to data used to determine the eligibility and demographics of the claimant and data about the 

benefit(s) for which a claim has been submitted. It also includes the status of the review and approval of the 

application. 

Claimant Master Record Store 

This refers to data associated with a benefit once it has been approved. Data are captured from the Application 

Information Stores for approved benefits. Additional data are added throughout the duration of the benefit 

payment period to support servicing and analysis. 

Program Criteria Store 

This refers to decision-making criteria used in determining benefit eligibility based on specific program 

regulations, and policies. Examples include income limitations, health conditions, prior military service or other 

work related prerequisites. 

Financial Information Store 

This refers to external financial information that is stored for use in performing calculations, such as the current 

interest rate specified by the Department of the Treasury. 

Benefit System Requirements 13
 

Functional Requirements 

14 Benefit System Requirements 

Functional Requirements 

Claims Acceptance and Tracking 

This function includes activities associated with providing potential claimants mechanisms for submitting 

claims, and for receiving, recording and tracking both properly completed and incomplete applications (claims) 

for benefit payments. Various benefit programs contain provisions requiring payments that are retroactive to the 

claimant’s initial filing date. Therefore, it is imperative that the system is able to track claims from point of 

receipt to final approval or denial. 

Mandatory Requirements

To support the claims acceptance and tracking functions, the benefit system must:

• Capture all applicable mandatory data elements (i.e., universal and appropriate categorical) specified in the 

“Application Information Stores” section (see p. 42) of this document. 

• Maintain all of the data elements specified in the “Application Information Stores” so information is readily 

accessible through standard online queries6

 or reports, until the claim is approved and a master record is 

established, or until a final determination is made denying the claim. 

• By fiscal year 2003, provide for electronic acceptance of benefit applications. If an agency anticipates 

receipt by electronic means of 50,000 or more submittals of a particular form, the system must allow 

multiple methods of electronic signatures for the submittal of such form, whenever feasible and appropriate. 

The system must provide for the electronic acknowledgement of electronic forms that are successfully 

submitted. 

• Capture various correspondence, including due process requests submitted by various electronic mediums 

and automatically associate the correspondence with the specific claim for the required action. For 

manually submitted correspondence, provide for associating the correspondence with the specific 

application or existing claimant master record for the required action. 

• When electronic methods (e.g. web based, telecommunications) are used to facilitate claim form acceptance, 

the system must incorporate input and completeness controls to ensure only complete7

 applications are 

accepted by the system. 

• The user shall have the ability to flag a claimant's paper based application as incomplete and to suspend 

further processing of the application until it is properly completed as specified by program requirements. 

• Store incomplete applications in accordance with agency policies, and provide for automatic purging of 

incomplete applications after a time period specified by the agency. 

• For each claim, associate a unique identifier (e.g. initials or user code) of the employee assigned to review 

the claim. 

• Utilize an alternative application procedure that accommodates persons with disabilities (e.g. blind, missing 

limbs). 

• Provide capabilities to track the status of due process or other appeal proceedings when applicable, after an 

initial claim has been denied. 

 

6

 As specified in the Claims Processing section. 

7

 The claimant fills in all required fields. 
 Functional Requirements 

 

 

Value-added Requirements

To support the Claims Acceptance and Tracking process, the benefit system should:

• Maintain a system record of pending claims and the status of other information including: 

♦ where in the process an ongoing claim is located; 

♦ who is holding claim; 

♦ what actions are needed to complete the claim; 

♦ whether additional information is needed; and 

♦ accommodation of explanation codes to indicate the reason why the claim is pending. 

• Allow the user to update the status items above. 

Claims Processing 

This function includes activities associated with the input and processing of the data provided by claimants on 

applications. There are three types of processes that a unified benefit system must be able to perform as part of 

the claims processing function. They are administrative, eligibility determination and computational processes. 

This document does not require the complete automation of the claims processing function. It provides for 

flexibility in implementing agency specific processing rules. The functional requirements listed below are 

intended to promote efficient data exchange (i.e., reduce data entry) among system components and optimize the 

use of technology. However, agencies should have a goal to keep manual processes to a minimum and automate 

claims processing to the maximum extent possible within the programs legal framework. 

Administrative Process 

The Administrative Process involves general features needed for efficiently handling claims. 

Mandatory Requirements

To support the administrative processes the benefit system must:

• Utilize claimant data that has been submitted electronically in an automated fashion without manual 

intervention (i.e., avoid re-entering data from one component to another). 

• Have the ability to date and time stamp due process requests and other time sensitive correspondence that 

has been received through electronic mediums. 

• Accommodate automated case workload distribution by providing for various claim routing options as 

determined and maintained by the system administrator. For example, provide for the ability to route claims 

for manual validation. 

• Indicate if the benefit payment calculation or verification thereof occurred manually. 

• Provide the user with the ability to update a claimant’s master record with the results of a manual claim 

validation or manual verification of the benefit payment amount, or create a new master record if none 

exists. 

• Have the ability to capture what information is needed from the claimant in order to complete an incomplete 

claim. 

• Provide for electronic approvals of claims at all levels of the approval process, whenever feasible. 

• Incorporate a notification mechanism that informs users (claim evaluators and supervisors) when an 

application(s) has not completed processing within a time frame that can be specified by the agency. 

Benefit System Requirements 15
 

Functional Requirements 

• Facilitate user queries on individual claims. Specifically, for all claims that have been received and 

recorded in the system, the system must be able to retrieve data maintained in the application information 

stores by querying the claim holders’ (or claimant if different) information. For example, data must be 

retrievable by query on full name, and Social Security Number (SSN) or taxpayer ID number. 

• For denied claims, accommodate explanation codes to indicate the reason why the claim has been denied. 

• Automatically create a claimant master record using the claimant information for initial claims that are 

approved, when a master record for the claimant did not previously exist. The master record must contain 

all of the mandatory data elements as specified in the Claimant Master Record Information Store (see p. 46). 

• Automatically update an existing claimant master record (i.e., claimant already receives a different type of 

benefit administered by the agency) to reflect the status (pending, approved, or rejected) of additional claims 

for other benefits the agency administers that are sought by the claimant. 

• Automatically merge the mandatory claimant data maintained in the application information stores into the 

appropriate master record after a claim has been approved and a claimant master record has been 

established. 

• Provide capability to generate statistics on approved and rejected claim applications. 

• Provide capabilities to accept, identify, track, and report manual overrides of system-generated 

acceptance/rejection recommendations. 

• Allow a user who has the proper access to reverse or affirm an initial decision regarding the denial of a 

benefit, and process the claim accordingly. 

• Provide capabilities to review all prior employee notations or decisions made while processing a benefit 

claim. 

Value-added Requirements 

To support the Administrative Process the benefit system should:

• Provide capabilities to record an estimated completion date for pending claims. 

• Have the ability, where multiple claims exist for the same claimant, to process the claims sequentially based 

on order of precedence. 

Eligibility Determination Processes 

Eligibility determination is generally agency specific, based on criteria that are unique to individual programs. 

However, although the criteria are agency specific, certain functions pertaining to determining claimant 

eligibility are common to benefit systems, in general. 

Mandatory Requirements

To support the Eligibility Determination Process the benefit system must:

• Have the ability to automatically compare information contained in application(s) that have been submitted 

by claimants against agency program eligibility criteria (i.e., screen applications for eligibility). 

• Have the ability to accept the manual validation of a claim. 

• Provide for maintaining separate eligibility criteria and processing routines by type of claim. 

• Provide for establishment of various age limitations depending on the type of benefit for automatic 

verification of program eligibility. For example, the system should allow for age attainment verification 

(e.g. generally a claimant must be at least 60 years of age to be eligible for SSA retirement benefits). 

16 Benefit System Requirements 
 Functional Requirements 

 

 

• Provide ability to cross-validate applicant information against data maintained for other benefit payment 

programs which are internal to the administering agency to ensure compliance with all program 

requirements (e.g. ensure that applicant has not filed for multiple conflicting benefits). 

• Provide features to indicate that applicant submitted required evidence. For example, allow user to record 

receipt of a school certification pertaining to a claimant or his/her dependent child. 

• Provide features to create and maintain a system record of accepted and rejected claim applications. 

• Provide tools to check the appropriate data files to determine whether the applicant has submitted a 

duplicate application or had a recent benefit application rejected. 

• Provide features to determine whether payments being made to the claimant in relation to other internal 

benefit payment programs affect the claimant’s eligibility or payment amount for the benefit under 

consideration, whenever legally permitted (i.e., permitted by statute or regulation). 

• Allow the user to put the processing of a claim on hold (suspend) while verifying questionable information, 

and to release hold (suspended) status as appropriate. 

Value-added Requirements 

To support the Eligibility Determination Process the benefit system should:

• Provide ability to inform applicant of potential eligibility for other internal benefit payment programs. 

• Have the ability to automatically validate survivor applicant information against information about the 

deceased spouse8

 or related former guardian that is maintained in a master record database. 

• Automatically validate dates of employment, earnings and other claimant-specific data provided on the 

application for benefits against the work history and earnings information reported to central agencies such 

as the Internal Revenue Service (IRS), SSA, and OPM when permitted by statute, or against other verified 

claimant-specific information maintained by the agency. 

Computational Processes 

Mandatory Requirements

To support the Computational Processes the benefit system must:

• Have the ability to determine if the effective date of the claim has been reached (e.g., the effective date of a 

retirement claim), and initiate subsequent processing. 

• Provide features to compute the amount of both recurring and non-recurring benefit payments based on all 

available information (e.g., applicant data, and specific benefit program criteria). 

• Determine the ending date for recurring payments of limited duration. 

• When processing an approved claim for benefits such as retirement, disability, death, survivor, and other 

claims, calculate the amount of recurring payment, or capture the amount of the claimant’s recurring 

payment that has been determined externally. 

• Provide flexibility in maintaining pay rates. For example, use tables that are easily maintained by the user. 

• Provide for adjusting the amount of payment when the claimant is receiving offsetting monetary amounts. 

For example, military retired pay is offset on a dollar for dollar basis against veterans compensation 

 

8

 Or former spouse. 

Benefit System Requirements 17
 

Functional Requirements 

payments, and for individuals under age 65, Social Security benefits are offset at a predetermined ratio for 

every dollar earned by claimants above the established threshold amount. 

• For Federal and Uniformed Service retirement systems, identify whether the claimant retired under 

provisions of voluntary separation incentive, and capture the amount of the incentive. 

• For Federal and Uniformed Service retirement systems, compute the base amount of retirement pay by 

determining the "highest paid 369

 months of paid service.” 

• Determine the creditable years of service based on dates of employment or active military service. 

• Provide features to calculate the claimant’s and or related dependent’s age based on the birth date provided 

in an application or other verified source for subsequent use in determining claimant eligibility. 

• Provide for user defined reasonableness/tolerable limit checks on the amounts of benefit payments that are 

calculated by the system. 

• Flag or suspend processing of a claim that fails reasonableness edits to facilitate manual verification of the 

amount computed. 

• Enable approved users to have the ability to resume the processing of a claim that was suspended for failing 

a reasonableness edit, and subsequently verified as accurate. 

• Allow a user to initiate the calculation of a claimant’s benefit amount, at any time, based on claimant data 

that exists when the request is made. 

• Have the ability to record the amount of manually computed benefit payments. 

• Provide for automatic system initiated calculation and or recalculation of benefit amount by claim type, 

based on a specific user defined event such as claim validation and approval, court order, claimant initiated 

withholding change, etc. 

• Provide for automated routines that access claimant master record data to facilitate calculating the amount of 

benefits due claimants. 

• Provide features to calculate and send overpayment information (date of occurrence, claimant name, and 

overpayment amount) to Receivables/Collections subsidiary ledger. 

Benefit Payment Administration 

The Benefit Payment Administration function should provide appropriate control over all benefit payments 

made by or on behalf of an agency. Agencies that administer benefit programs make payments to individual 

citizens or a designated payee. Federal benefit programs are usually supported by systems that maintain detailed 

information on payees and generate payments10 directly from those systems rather than generating benefit 

payments from its core financial management system, especially when large volumes of transactions are 

involved. Summary data is then passed into its core financial management system. If this situation exists, 

benefit systems must meet the requirements listed here for payment administration. 

Benefit systems may also support activities that lead to the payment stage, but rely on the core financial system 

to manage the payment process itself. For example, a benefit system might calculate the amount to be paid to 

each claimant and send transactions to the core financial system to record the expenses and related payable and 

cash outlays to the claimant. The Core financial system would then schedule the payment for disbursement and 

 

9

 Or other number as required by law, regulation or statute. 10 Generating payments involves creating a payment file, which is forwarded to the Department of the Treasury, or funds are 

disbursed directly under delegated disbursing authority. 

18 Benefit System Requirements 
 Functional Requirements 

 

 

confirm that it occurred. In this case, only the payee information maintenance, and payment warehousing 

functional requirements listed below would apply to the benefit system. However, in this alternative situation, 

once the detailed information is passed to the core system for scheduling and payment, the applicable core funds 

control, payment execution and payment confirmation and follow-up functional requirements would also apply 

to benefit payments made directly from the core system. 

The Benefit Payment Administration function consists of the following processes: 

• Payee Information Maintenance 

• Payment Warehousing 

• Funds Control 

• Payment Execution 

• Payment Confirmation and Follow-up 

Payee Information Maintenance Process 

The term “payee” is used here to include any entity to which a disbursement may be made. For example, 

individuals or an entity that are fulfilling a fiduciary responsibility, such as a professional services entity that is 

acting as trustee for an incapacitated beneficiary. In a unified system, payee information needed to make 

payments should be coordinated with information needed for other purposes and in other systems. For example, 

occasionally overpayments produce recoveries receivable. If a centralized debt collection system is utilized, 

information in that system should be coordinated with detailed payee information. 

 

Mandatory Requirements

To support the Payee Information Maintenance Process, the benefit financial system must:

• Maintain payee information that includes data to support obligation, accounts payable, and disbursement 

processes. 

• Support payments made to parties that act as an agent for the payee without changing permanent claimant 

information that is maintained in the claimant’s master record such as the claimant’s name, address or 

financial institution. 

• Allow the user to capture the current tax status, number of exemptions, and other information requested on 

applicable IRS withholding forms (i.e., W-4P, W-4S, and W-4V). 

• Maintain detailed information for each payee to comply with IRS reporting requirements. For example, 

information needed for 1099 reporting, including SSN or taxpayer identification number (TIN). In cases 

where payments are made to third parties who are serving in a fiduciary capacity, maintain 1099 information 

for the principal party rather than the agent. 

• Provide the capability to automatically update payee records to reflect automated clearinghouse (ACH) or 

electronic funds transfer (EFT) related changes. These updates may be supplied periodically by Treasury, 

financial institutions or other sources. 

• At a minimum, accumulate actual payments for each payee on an annual basis. 

• Provide search capability for payee information (e.g., payee name). 

• Produce payee listings based on agency-defined criteria, (e.g., payee name and SSN.) 

Benefit System Requirements 19
 

Functional Requirements 

• Maintain as part of the claimant’s master record a complete history, of all financial transactions executed for 

each payee receiving benefits under the claim holder’s master record. This includes payments, and 

collections, waivers11, or offsets resulting from overpayments. 

• For all active “payees,” make the financial transaction history data of the most recent 18 months available 

for online query and review. 

Value-added Requirements 

To support the Payee Maintenance Process, the benefits financial system should:

• Allow for maintaining deposit account information on at least two financial institutions for a single payee. 

Payment Warehousing Process 

This process stores payments that are due to benefit claimants in the near term. After a claim has been 

approved, whether the payment is lump-sum or recurring, the system must be able to “hold” or store properly 

approved payments and automatically release payments for scheduling based on payment due dates. 

Mandatory Requirements

To support the Payment Warehousing Process, the benefits system must:

• Have the ability to determine whether the benefit payment is a non-recurring payment. 

• Automatically determine the due date and amount of benefit payments. 

• Reestablish payables for voided checks, or EFTs that were not successful. Allow for reversing the 

accounting transaction leading to the disbursement and reestablishment of a payable, as appropriate. 

Value-added Requirements 

To support the Payment Warehousing Process, the benefits system should:

• Allow anticipated obligation or expenditure transactions so that documents may be entered early, stored, and 

posted at the appropriate date. Subject these documents to edit and validation procedures prior to posting. 

If the anticipated obligation does not occur, permit the user to delete the transaction without posting it. 

Funds Control Process 

Each agency of the Federal Government is responsible for establishing a system for ensuring that it does not 

obligate or disburse funds in excess of those appropriated and or authorized. The Anti-Deficiency Act provides 

legal requirements regarding obligating Federal funds. The Funds Control Process within an agency’s Core 

financial system is the primary tool for carrying out this responsibility. 

However, depending on an agency’s financial system architecture, benefit systems may also require funds 

management capability. For example, typically benefit systems generate transactions that obligate and expend 

funds, and may also maintain detailed receivable information. Benefit systems may access data and rely on 

functions of the Core financial system to verify that funds are available before allowing an obligation to be 

incurred and recorded in the benefit system. Under certain circumstances, however, such two-way interfacing 

may not be feasible. Accordingly, any benefit payment system that does not interface with the agency’s Core 

financial system to utilize funds control features of the core system must perform the following funds control 

functions. 

 

11 See definition in Appendix B glossary 

20 Benefit System Requirements 
 Functional Requirements 

 

 

Funds Availability Editing. 

This activity verifies that sufficient funds are available at the various control levels specified in the funds 

allocation process for each transaction processed which may affect available funds balances. If sufficient funds 

are not available, notification is provided so that appropriate action may be taken. 

Mandatory Requirements

To support Funds Availability Editing the benefit system must:

• Allow for recording of funding transactions. This includes recording internal allocations or allotments from 

within the agency. 

• Include adequate controls to prevent the recording of obligations or expenditure transactions that exceed 

available balances. The system must also support recording obligations or expenditures that exceed 

available balances based on proper management approval (i.e., provide the capabilities and controls for 

authorized users to override funds availability edits). 

• Provide for designated authorities to establish and modify the system’s response (either reject transaction or 

provide warning) to the failure of a funds availability edit. 

• Record the financial impact of all transactions that affect the availability of funds, such as commitments, 

obligations, expenditures and the establishment of, and collections against recovery receivables. 

• Automatically update all appropriate budgetary tables and ledger account balances (when applicable) to 

ensure that the system always maintains and reports the current status of funds for all open accounting 

periods. 

Value-added Requirements 

To support Funds Availability Editing the benefit system should:

• Provide for designated authorities to establish and modify the level of funds control using elements of the 

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

• Provide the ability to produce an on-line status of funds report down to the lowest level of the organizational 

structure. The report should include: amounts available/allotted, open commitments, open obligations, 

expenditures, and balance available. 

Commitments 

Commitments are an optional stage prior to the establishment of an obligation. Commitments can be a useful 

tool in funds management by helping users to anticipate future outlays. They should be used when helpful to an 

agency’s management process, but are not necessary, or even appropriate, for all obligations. 

Mandatory Requirements

None. Commitment accounting is not required. 

Value-added Requirements

If the commitment accounting is utilized, the benefit system should perform the following to support the 

Commitment function: 

• Allow commitment transactions to be entered on-line and from multiple locations. 

• Maintain information related to each commitment transaction. At a minimum, the system should capture 

accounting classification elements, and estimated amounts. 

Benefit System Requirements 21
 

Functional Requirements 

• Provide for modifications to commitment transactions, including ones that change the dollar amount or the 

accounting classification elements cited. 

• Allow for commitment transactions to be future-dated, stored, and posted at the appropriate date. 

• Close open commitments under the following circumstances: (1) by the system upon issuance of an 

obligating document, (2) by an authorized user, and (3) as part of the year-end closing if the commitment is 

in an annual appropriation or in the last year of a multi-year appropriation. 

• Provide the capability to support commitment accounting based on agency needs. 

Obligations and Expenditures

OMB Circular A-34 defines obligations as transactions during a given period that will require payments during 

the same or a future period. Such amounts include outlays for which obligations had not been previously 

recorded and reflect adjustments for differences between obligations previously recorded and actual outlays to 

liquidate those obligations. 

Mandatory Requirements

To support the Obligation and Expenditure activity, the system must:

• Update budgetary tables to reflect obligations based on obligating documents and liquidate, at the user’s 

request, the related commitments, either partially or fully. 

• Update budgetary tables to reflect obligations for which there is no related commitment. 

• Maintain information related to each obligation document, including amendments. At a minimum, the 

system must capture the obligating document number and type; and other identification, including benefit 

payee SSN or TIN, accounting classification elements as appropriate; referenced commitment (if 

applicable); and dollar amounts. 

• Allow obligation documents to be entered on-line and from multiple locations. 

• Allow authorized modifications and cancellations of posted obligation documents. 

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

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

• Close open obligating documents to accommodate both of the following circumstances: (1) automatically 

when reclassifying an unliquidated obligation to an expenditure, or (2) by an authorized user. 

Value-added Requirements

To support the Obligations and Expenditures activity, the benefit system should:

• Allow multiple commitments to be combined into one obligation or expenditure document and one 

commitment document to be split into various obligating or expenditure documents. 

Analysis 

The Analysis activity provides information necessary to support analysis of the Funds Management function. It 

provides information on funds availability at the levels defined and compares data in the Funds Management 

function to data in other functions to ensure consistency. 

22 Benefit System Requirements 
 Functional Requirements 

 

 

Mandatory Requirements

To support the Analysis activity, the benefit system must:

• Maintain current information on obligations according to the classification elements established by the 

agency, on a fund by fund basis. 

• Sort and provide on-line access to both summary level and detailed information, based on the defined level 

of funds control for those transactions that represent obligations and expenditures. 

• Provide control features that ensure the amounts reflected in the fund control structure agree with the 

general ledger account balances at the end of each update cycle. 

Value-added Requirements

To support the Analysis activity, the benefit system should:

• Track the use of funds against operating or financial plans. 

Payment Execution Process

This process supports activities required when making and recording payments. Agencies for whom Treasury 

does the actual disbursing prepare requests for disbursements that are transmitted to Treasury. However, some 

agencies have “delegated disbursing authority” and can print checks or make electronic transfers without using 

Treasury as an intermediary. Title 31 U.S.C. § 3321(b), provides that, for economy and efficiency, the Secretary 

of the Treasury may delegate the authority to disburse public money to officers and employees of other Federal 

agencies. 

Agencies with Delegated Disbursing Authority 

If an agency has delegated disbursing authority, certain requirements generally relating to Treasury specific 

payment processing and reporting may not be applicable. However, the following requirements apply to 

agencies with delegated disbursing authority. 

Mandatory Requirements:

To support the Payment Execution Process (for such agencies) the benefit system must:

• Support the reporting and other requirements specified in Volume I of the Treasury Financial Manual 

(TFM) Part 4. For example; the system must enable the agency to: 

♦ report all disbursements made under the delegation in the agency's payment accounting reports to the 

Financial Management Service (FMS), using the appropriate agency accounting codes, as authorized by 

FMS. As stated in Section 10025, the agency must submit immediately to the Chief Disbursing Officer 

(CDO) any irregularity in accounts involving disbursement activity. Furthermore, the agency is 

responsible for resolving any irregularities or discrepancies associated with such reports. 

♦ submit check issuance data in a timely and accurate manner to FMS no later than the close of business 

of the week in which the issue dates occur and at month's end.( See I TFM 4-6025.10.) FMS must 

receive this information within the required timeframe to carry out properly its check reconciliation 

responsibilities to decline final payment and or reclaim payment on certain improperly negotiated 

Treasury checks or counterfeit checks. See 31 Code of Federal Regulations (CFR) Part 240. 

♦ comply with applicable Treasury offset guidelines established under the authority of 

31 U.S.C. § 3716(c). 

Benefit System Requirements 23
 

Functional Requirements 

♦ comply with FMS guidelines concerning applicable requirements to include a payee's taxpayer 

identifying number on payment vouchers in accordance with 31 U.S.C. § 3325(d). 

♦ comply with all applicable EFT system requirements including those related to message authentication 

and enhanced security, unless explicitly waived in writing by the CDO. 

All Other Agencies 

Mandatory Requirements 

To support the Payment Execution Process, the benefit system must:

• Automatically identify and select payments to be disbursed in a particular payment cycle based on their due 

dates. Provide a function for review and certification by an authorized certifying officer. 

• Allow changes to payment schedules by authorized staff prior to acceptance by the disbursing office. 

• Allow specific payments selected for disbursement to be excluded from the payment cycle and held for later 

payment. 

• Automatically determine taxable benefit payments from non-taxable payments. 

• Automatically compute net amounts to be disbursed, after taking into account withholdings, interest, 

garnishments, or other offsets as needed, in accordance with applicable regulations. Generate the 

appropriate transactions to reflect the above deductions and additions. 

• Collect information on interest paid if applicable, and record the amounts to the proper ledger account. 

• Calculate totals by Agency Location Code (ALC) and TAFS for inclusion on the payment schedule. 

• Sort individual payment detail by TAFS to enable SF-224 reconciliation. 

• Provide for various forms of payment to be used, (i.e., check or electronic funds transfer). 

• Support Treasury-specific standards for format of check and EFT payment requests. 

• Automatically update payment records based on updates recorded in the payee’s master record, such as 

change of address, changes in deposit account information, etc. 

• Allow a payment request to be removed from the automated scheduling stream and scheduled as a manual 

payment by an authorized official. 

• Allow the user to trigger an immediate benefit payment for “emergency12 ” situations. 

• Provide the capability to schedule and make payments in various forms (e.g., ACH, SF-1166) as required by 

an agency’s disbursing offices, including physical media (e.g., tape, electronic transfer). 

• After payments are scheduled and prior to actual disbursement by Treasury, allow for cancellation of an 

entire payment schedule or a single payment within a payment schedule. 

• Provide features to reduce the payment amount due a claimant, in order to offset an outstanding receivable 

owed by the claimant, in accordance with applicable laws, regulations, and provisions of the Treasury Offset 

Program (TOP). However, the system must properly record the impact of the entire amount of the 

transaction in both budgetary and proprietary (i.e., entire amount is expensed, payables or cash accounts 

reflect net outlay, budgetary resources increased by amount of nonfederal receivable collected, etc.). 

• Provide for reissuing payments for misplaced payments, lost or stolen checks. 

 

12 As defined by the administering agency. 

24 Benefit System Requirements 
 Functional Requirements 

 

 

Value-added Requirements

To support the Payment Execution Process, the benefit system should:

• Automatically consolidate amounts due benefit claimants when the claimant is entitled to more than one 

benefit administered by the same agency, and itemize all payments covered by the one check or EFT on a 

payment advice or addendum to the EFT file per Treasury specifications. 

• Allow for the splitting of a single benefit payment into separate bank accounts (i.e., allotments) as indicated 

on the claimants direct deposit request form. Allow for a minimum of one allotment in addition to the 

primary deposit account. 

• Provide for making payments in a foreign currency. 

Payment Confirmation and Follow-up Process 

This process confirms that disbursements were made as anticipated and supports inquiries from benefit 

claimants regarding payments, and reporting requirements relating to the Benefit Payment Administration 

function. 

Mandatory Requirements

To support the Payment Confirmation and Follow-up Process the benefit system must:

• Update master record information resulting from payments made by the core system (if applicable). 

• Allow the user to record the outcome of the Treasury search when recertified checks are issued because 

original checks are lost, stolen, or destroyed. 

• Provide information about each payment to reflect the stage of the scheduling process that the payment has 

reached and the date each step was reached for the following processing steps: 

♦ payment scheduled; 

♦ schedule sent to appropriate disbursing office; and 

♦ payment issued by appropriate disbursing office. 

• Provide for comparison of the agency’s payment schedule and the disbursing office’s accomplished 

payment schedule. 

• Update payment information when confirmation is received from the disbursing office, including the paid 

schedule number, check numbers or trace numbers, date, amount of payment, and payment method 

(e.g., check or EFT). 

• Maintain history of every payment by the benefits system, including authorizing document number, 

payment schedule number, payment date, payment address, and TAFS charged. 

• Provide on-line access to claimant and payment information. 

• Provide on-line access to open documents based on agency selection criteria (e.g., SSN). 

• Produce IRS 1099s in IRS acceptable form (hard copy or magnetic tape) when required by IRS regulations 

(e.g., miscellaneous payments to individuals over $600). 

• Automatically liquidate the related liability or the in-transit amount when payment confirmation updates the 

system. 

Benefit System Requirements 25
 

Functional Requirements 

Recovery Receivable Management 

The Recovery Receivable Management function supports activities associated with establishing receivables; 

recording collections, offsetting payments, waivers and servicing receivables. This function includes recording, 

billing, monitoring, and collecting amounts due the Government. Recovery receivables are established resulting 

from erroneous payments or over payments to benefit claimants. In some instances, it is necessary to compute 

interest, penalty, and administrative charges that are added to the principal balance. 

Depending on an agency’s system architecture, servicing, and collection activities for receivables may be 

supported by other agency systems that pass data to and from other components of a unified benefit system. 

Alternatively, the recovery receivables function may be supported by self contained module dedicated to the 

benefit system. Regardless of which system component supports this function, the unified benefit system must 

perform the processes listed below. 

The Recovery Receivable Management function consists of the following processes: 

• Receivable Establishment 

• Receivable Servicing 

• Collections 

• Offset 

• Funds Control 

Recovery Receivable Establishment Process 

The Recovery Receivable Establishment Process supports activities to record receivables in the system as they 

are recognized and produce bills or other correspondence for amounts due the agency. 

Mandatory Requirements

To support the Recovery Receivable Establishment Process, the benefits system must:

• Record the establishment of receivables in the claimant’s master record. 

• Provide for the establishment of receivables in other systems such as centralized accounts receivable 

systems, based on individual claim holder debts. 

• Provide the capability for a user to select the reason the receivable is being recorded from a domain of 

recognized reasons. 

• Support the establishment and tracking of receivables to be paid under installment plans, including plans for 

which payments have been rescheduled. Specifically, provide the capability for a user to record the begin 

and end dates of the payment period, and the frequency and amount of each payment. 

• Calculate, generate and post the required ledger entries for receivables resulting from duplicate payments or 

erroneous payments, and the corresponding expenditure reductions, or other offsets. 

• Print bills, accommodating the generation of standard forms and turnaround documents to be used as a 

remittance advice. Allow customized text in generated billing documents. 

• Provide features to notify overpaid individuals (or claimant's estate) of: 

♦ the amount overpaid and how and when overpayment occurred; 

♦ the right to appeal the overpayment determination; 

26 Benefit System Requirements 
 Functional Requirements 

 

 

♦ the required recovery; and 

♦ the right to request a waiver of recovery. 

• Record adjustments, both increases and decreases (i.e., non-cash credits) and post to a claimant’s master 

record. 

• Date the bills with the system-generated date or with the date supplied by an authorized user. 

• Accept transactions that generate receivables from other systems in a standard format for entry into the 

benefits system. 

Value-added Requirements

To support the recovery receivable establishment process, the benefits system should:

• Print statements as well as bills. 

Recovery Receivable Servicing Process 

The Recovery Receivable Servicing Process supports activities to: maintain information on entities owing the 

Government (name, address, etc.); age receivables; make efforts to collect amounts due including related 

interest, penalties, and administrative charges; liquidate receivables; record adjustments to receivables, maintain 

a proper allowance for doubtful amounts; record write-offs and waivers. 

Mandatory Requirements

To support the Recovery Receivable Servicing Process, the benefit system must:

• Maintain detailed information by account (i.e., individual) sufficient to provide audit trails and to support 

billing and research activities. 

• Update each master record when billing documents are generated and collections are received. 

• Provide on-line query capability to receivable and account information. 

• Provide information, on a summary basis and on individual receivables, on the age of receivables to allow 

for management and prioritization of collection activities. 

• Provide automatic calculation and assessment of interest, administrative charges, and penalty charges as 

applicable on overdue receivables. 

• Allow for the waiver of the charges listed above with appropriate authority. 

• Identify and report receivables that meet predetermined criteria for bad debt provisions or write-off. 

• Maintain data for receivables referred to other Federal agencies and or outside organizations for collections. 

• Automatically initiate transactions to record the write-off of delinquent or uncollectible receivables 

(including interest, penalties, and administrative charges) based on user defined criteria, and maintain data 

to monitor closed accounts. 

• Produce dunning (collection) letters for overdue receivables in accordance with Treasury requirements and 

existing legislation. 

• Provide authorized users with the ability to customize the dunning process parameters and dunning letter text. 

• Provide information to allow either manual or automated reporting of delinquent accounts to commercial 

credit bureaus and referral to collection agencies or other appropriate governmental organizations. 

• Maintain information needed to support reporting required by IRS. 

Benefit System Requirements 27
 

Functional Requirements 

• Maintain a history of billings and receipts for each receivable and account in accordance with agency 

requirements. 

• Match receipts to the appropriate receivables and update system balances. 

• Provide the ability to apply receipts to more than one receivable. 

• Update receivable balances document by document, classifying and posting against principal, interest, 

administrative fees, etc., required by OMB Circular A-129, “Managing Federal Credit Programs.” 

• Identify receivables that have been reduced by some means other than cash collections, such as waivers or 

write-offs. 

• Provide for re-establishment of a receivable for checks returned due to insufficient funds. 

Collection Process 

The Collection Process supports activities to record the receipt of funds either by currency (e.g., cash, electronic 

funds transfer) or check and the deposit of such funds in accordance with Treasury and agency regulations. 

Mandatory Requirements

To support the Collection Process, the benefit system must:

• Record complete and partial receipts according to the Debt Collection Act (DCA) of 1982 and the Debt 

Collection Improvement Act (DCIA) of 1996 and other applicable regulations. 

• Record deposits and related debit vouchers for reconciliation to deposit confirmation information provided 

by Treasury or the banking system. Specifically, provide the capability for a user to record the deposit 

ticket or debit voucher document amount, number, and date. 

• In connection with recording deposits, if a claimant’s master record is located, provide the capability to 

display all active receivable accounts of record for the relative to the claimant. 

• If the user is not able locate an existing receivable in the master record of the person making a payment, and 

the document being recorded is a deposit ticket item, provide the capability to associate the collection of 

funds to the claimant’s master record if a master record exists. 

• Provide features to record method of recovery (i.e., payment; internal offset; TOP, compromise settlement; 

civil suit; etc.). 

• Provide the capability to flag a claimant’s receivable record to reflect “due process” status, in order to 

suspend collection activities associated with the receivable. Additionally, the system must automatically 

allow collection activities to resume when due process has expired or the flag has been reversed. 

• Capture whether the receivable has been petitioned and or discharged in connection with bankruptcy 

proceedings to facilitate compliance collection restrictions pertaining to such debts. 

Value-added Requirements

To support the Collection process, the benefit system should:

• Provide for the processing of cash or credit card receipts against outstanding receivables. 

28 Benefit System Requirements 
 Functional Requirements 

 

 

Offset 

Benefit payment offset occurs when the amount of a claimant's payment is reduced. In general, Federal benefit 

payments may be reduced to collect on a debt owed to a U.S. Government agency13, or to comply with a court 

garnishment order resulting from a judgement imposed against the claimant. However, there are limitations on the 

amount that can be offset, and restrictions on the types of Federal benefit payments that may be offset. For example, 

certain Social Security payments are subject to offset but with limitations. Means-tested14 Federal benefit payments 

will be exempted from offset at the request of the head of the payment certifying agency and other payments may be 

exempted by Treasury. Bankruptcy provisions also affect an agency's ability to offset payments. Agencies must 

verify whether legal authority permits offset of payments on a program by program basis. Also, opposing statutory 

authority supercedes the mandatory implementation of the requirements in this section. However, such determination 

is made on program specific basis. Accordingly, agencies that administer more than one benefit program will 

essentially need to incorporate logic into the system to reflect whether there is legal authority. Agencies should 

ensure that the implementation of these requirements is consistent with the DC A and the DCIA as they apply to their 

benefit programs. 

Mandatory Requirements

To support the Offset process, the benefit system must:

• Provide ability to report overdue receivables with associated SSN or TIN data to Treasury for possible 

offset. 

• Allow for offset of funds due to delinquent indebtedness through administrative offset, Federal employee 

salary offset, and income tax refund offset. Comply with requirements of the IRS Tax Refund Offset 

Program and TOP requirements. 

• Provide the capability for a user to record the effective date of the offset plan. 

• Incorporate logic to reflect the legal authority as to whether the payment type may be reduced by offset, or 

is exempt from the TOP or other offsets. 

• Provide the capability to automatically exclude certain receivables from the offset function. For example, 

receivables that are in due process status, or those that relate to and bankruptcy filings. 

• Automatically subject receivables to offset which had been previously excluded because of due process or 

bankruptcy status once status has been resolved. 

Value-added Requirements

To support the Offset process, the benefit system should:

• Provide the capability for a user to select from a domain of offset program participants (i.e., the recipient of 

the amount to be offset against a claimant’s benefit payment). 

• If the desired offset program recipient does not exist as a participant, provide the capability for a user to 

create a participant record. 

• In connection with paying retirement benefits, uniquely identify bankruptcy debt so that a bankruptcy debt 

is bypassed when computing the legally mandated 65 percent maximum deduction amount, when an account 

has both garnishment and former spouse deductions. 

 

13 The Federal Government also has authority to collect debts owed to non-federal entities. 14 See definition in Appendix B Glossary. 

Benefit System Requirements 29
 

Functional Requirements 

Funds Control 

In addition to the Funds Control requirements specified within the payment administration function, the benefit 

system must properly record the financial affects of various transactions relating to receivable management. 

Mandatory Requirements

To support the Funds Control process within the recovery receivable management function the benefit system 

must:

• Properly record the budgetary affect on U.S. SGL balances for all transactions typically involved with 

receivable management. For example, establishing a receivable, adjusting receivables, collections and 

offsets, waivers and write-offs. (See Accounting for Benefit Transactions discussed below.) 

Accounting for Benefit Transactions 

The Accounting for Benefit Transactions function is broken out into several areas: entity definition, account 

definition, transaction definition and processing, and audit trails. The requirements listed below are also 

typically performed by the agency’s core financial management system. However as previously noted, an 

agency’s financial management system architecture may be designed so that some of the functions described in 

this document, such as recording accounting transactions, are occasionally performed by other systems (e.g. core 

financial management system, an accounts payable or centralized receivable systems). Therefore, although the 

requirements below may be similar to those performed by a core financial management system, they are 

requirements that apply to benefit systems in the event that detailed accounting is performed completely or 

partially in the benefit system rather than the core system. 

Entity Definition 

The Entity Definition is the reporting entity in the benefits system for which transactions are recorded and 

financial information is presented. 

Mandatory Requirements

To support Entity Definition, the system must:

• Allow for recording transactions in multiple TAFS and various fund types. This includes annual, multi-year, 

and no-year appropriations, and trust funds.

• Accommodate reporting for multiple programs within a TAFS, based on the accounting classification 

elements (e.g., organization level, cost center).

Account Definition

Both OMB Circular A-127 and OMB’s “Revised Implementation Guidance for the Federal Financial 

Management Improvement Act of 1996” require implementation of the U.S. SGL at the transaction level. The 

U.S. SGL is defined in a supplement to the TFM, which includes the chart of accounts, account descriptions 

and postings, account attributes, accounting transactions 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. 

30 Benefit System Requirements 
 Functional Requirements 

 

 

Mandatory Requirements

To support the Account Definition activity, the benefits system must:

• Use account titles consistent with the account titles provided in the U.S. SGL. 

• Use account definitions consistent with the account definitions provided in the U.S. SGL. Any expansion to 

the chart of accounts must roll up to the accounts as defined in the U.S. SGL. However, a pseudo code can 

be used instead of the exact U.S. SGL account numbers, providing the account descriptions and posting 

rules are the same as those used in the U.S. SGL for relevant transactions (also see transaction processing). 

• Provide subsidiary ledger support for U.S. SGL accounts. Support may be as detailed as the agency deems 

appropriate. The system must also support reconciliation of U.S. SGL control accounts to their respective 

subsidiary records by accounting period. 

• Provide the capability to create additional sub-accounts to the general ledger for agency specific tracking 

and control. These sub-accounts will summarize to the U.S. SGL accounts. 

Transaction Definition and Processing 

The transaction definition activity defines the editing and posting rules for transactions in the benefits system. 

Both OMB Circular A-127, and OMB’s “Revised Implementation Guidance for the Federal Financial 

Management Improvement Act of 1996” requires common processes be used for processing similar kinds of 

transactions throughout an integrated financial management system to enable consistent reporting of 

transactions. They also require financial events to be recorded applying the requirements of the U.S. SGL at the 

transaction level. Many of the U.S. SGL accounting transaction descriptions require a single accounting event 

to update multiple budgetary and proprietary accounts. The transaction processing activity must ensure that all 

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

controlled properly to provide reasonable assurance that the recording, processing, and reporting of financial 

data are properly performed and that the completeness and accuracy of authorized transactions are ensured. 

Mandatory Requirements

If accounting transactions are recorded in the benefit system, rather than the core financial management system, 

than to support the Transaction Definition and Processing activities, the benefits system must:

• Use standard transactions to record accounting events and to control the related updating of other 

information maintained in the system, such as values in tables (e.g., available funding). 

• Allow standard transactions, including system-generated transactions, to be established, modified, or deleted 

by authorized personnel. Provide for traceability of changes. 

• Generate and post compound debit and credit entries to the U.S. SGL accounts. Update both budgetary and 

proprietary U.S. SGL accounts based on a single input transaction. 

• Provide the capability to add, modify, and maintain editing and posting rules through systems tables 

controlled by authorized personnel. 

• Perform integrity checks on batches received via interfaces. Checks should include a batch number to detect 

duplicate or skipped batches, and validity of header and trailer records to ensure counts and amount in trailer 

agree with records in the batch. 

• Process transactions consistent with U.S. SGL account descriptions and postings. Use of other than U.S. 

SGL account numbers (i.e., a pseudo code) is acceptable providing the account descriptions and posting 

rules are the same as those used in the U.S. SGL for relevant transactions. 

Benefit System Requirements 31
 

Functional Requirements 

• Process system-generated transactions, such as automated payment scheduling, accruals, closing entries, 

recurring payments, and transactions that generate other transactions in those cases where a single 

transaction is not sufficient. 

• Automatically liquidate, partially or in full, balances of preceding documents when entering dependent 

documents. This capability will be used in the liquidation of commitments, obligations, payables, 

receivables, or other items, as appropriate. For example, when expending an existing obligation the balance 

of the open obligation must be automatically reduced by the amount expended. 

• Provide control over the correction and reprocessing of all erroneous transactions through the use of error 

file(s) and or suspense accounts. Erroneous transactions must be maintained and tracked until either 

corrected or posted or deleted at the specific request of an authorized user. 

• Support management controls to ensure that transactions are processed in accordance with Government and 

agency-prescribed standards and procedures, the integrity of data in the system is maintained, and access is 

restricted to authorized users. 

• Provide transaction edits that control, at a minimum, fund availability, account structure, and tolerance 

levels between related transactions, such as between an obligation and its related accrual. 

• Provide controls to prevent the creation of duplicate transactions. 

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

provide on-line queries and reports on balances separately for the current and prior months. At a minimum, 

balances must be maintained on-line for both the current and prior months until prior month closing. 

Value-added Requirements

To support the Transaction Definition and Processing activities, the benefits system should:

• Provide the capability to enter and store for future processing any transactions in the current month for 

processing in the subsequent month. 

Audit Trails. 

Adequate audit trails are critical to provide support for transactions and balances maintained by the benefits 

system. While audit trails are essential to auditors and system evaluators, they are also necessary for day-to-day 

operation of the system. For example, they allow for the detection and systematic correction of errors that arise. 

Mandatory Requirements

To support the Audit Trails process, the benefits system must:

• Provide audit trails to trace transactions from source documents, original input, other systems, systemgenerated transactions, and internal assignment transactions through the system. Provide transaction details 

to support account balances. 

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

to the financial statements and the reverse. 

• Provide audit trails to identify changes made to system parameters and tables that would affect the 

processing or reprocessing of any financial transactions. 

• For all types of transactions, provide capability to select items for review based on user-defined criteria. 

Examples of selection criteria are accounting period, amount, and payee. 

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

32 Benefit System Requirements 
 Functional Requirements 

 

 

• Provide the capability to record the user ID, date, and time updated for each transaction affecting the general 

and subsidiary ledger accounts. 

Reporting 

The benefits financial system must be able to provide financial information in a timely and useful fashion to: 

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

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

reporting requirements, including, as necessary, the requirements for financial statements prepared in 

accordance with Federal generally accepted accounting principles and the form and content prescribed by OMB, 

reporting requirements prescribed by Treasury, and legal, regulatory and other special management 

requirements of the agency; and (5) support the compulsory notification function. 

Information maintained by the benefits system must be provided in a variety of formats according to user needs. 

Methods of providing information include on-line inquiries, extract data files, and hard-copy reports. These 

requirements could be satisfied by: application software that is part of the benefits system; generalized 

reporting/inquiry software that works with a variety of applications, or the most likely case, a combination of 

both. 

The Reporting function consists of the following processes: 

• External Reporting 

• Internal Reporting 

• Performance Reporting 

• Compulsory Notifications

External Reporting 

The benefits system must provide complete, reliable, consistent, timely and useful financial management 

information on operations to ensure central management agencies are able to in fulfill their responsibility of 

being accountable to the public. A medley of laws and regulations impose a variety of mandatory notifications 

to benefit recipients. For example, benefit recipients must be notified when there are changes in eligibility, 

payment amounts, etc. 

Mandatory Requirements

To support the External Reporting process, the benefits system must:

• Maintain accounting data to support reporting in accordance with accounting standards pronounced by 

FASAB, and with other reporting requirements issued by the Director of OMB and the Secretary of the 

Treasury (some examples are listed in Appendix A). Of particular significance is data that is needed when 

preparing actuarial estimates for financial statement presentation, in compliance with the reporting 

requirements specified by SFFAS No. 5 and No. 17. For example, the system should facilitate historical 

trend analysis of various data elements as determined by the agency. 

• Provide summarized data electronically to systems used by the agency for decision support and provide for 

the preparation of external reports such as those required by the Department of the Treasury and OMB. For 

example, the system must pass the data needed to prepare reports for required by the Federal Agencies’ 

Centralized Trial-Balance System (FACTS) I, FACTS II, SF-224 (when appropriate) and financial 

statements to the Core financial system. 

Benefit System Requirements 33
 

Functional Requirements 

• Report events and transactions according to the accounting classification elements established and within a 

given accounting period. This includes providing the ability to automatically assign costs by a major 

program to facilitate preparation of the Statement of Net Costs in accordance with OMB’s current Bulletin 

on “Form and Content of Agency Financial Statements.” 

• Maintain the information required for program performance, financial performance, and financial 

management performance measures needed for budgeting, program management, and financial statement 

presentation. 

• Provide the capability to produce all relevant reports, statements, or returns required by the IRS, including 

producing year-end 1099 statements. 

• Allow a user to request a reissued tax statement for current or previous year. 

Value-added Requirements

To support the External Reporting process, the benefits system should:

• Provide for an automated methodology of data manipulation and data exportation. 

• Provide for automatic translation of foreign currency payments based on the exchange rate specified by the 

user (i.e., determine the appropriate amount of corresponding U.S. dollars when recording transactions for 

payments made in foreign currency). (See value-added requirement under Financial Information Store on 

p. 47.) 

• Allow a user to request a reissued tax statement for previous 3 prior years. 

Internal Reporting

The benefits system must provide complete, reliable, consistent, timely and useful financial management 

information on operations to enable individual operating components, divisions, bureaus and other sub units to 

carry out their fiduciary responsibilities; deter fraud, waste, and abuse of resources; and facilitate efficient and 

effective delivery of programs by relating financial consequences to program performance. The benefits system 

must be designed to support agency budget, accounting, and financial management reporting processes. 

Mandatory Requirements

To support the Internal Reporting process, the benefits system must:

• Provide for the production of formatted reports. The system must allow for the reformatting of reports to 

present different sorts of information, the presentation of only specific information in the format selected, 

the summarization of data, and the modification of report formats to tailor the reports to the specific 

requirements of the user. 

• Provide for program cost accounting data to support reporting requirements specified in OMB’s “Form and 

Content of Agency Financial Statements,” and the decision-making process in managing agency programs. 

This will include: 

♦ cost reports to be utilized in the analysis of programmatic activities; 

♦ schedules and operating statements based on the accounting classification elements and agency criteria; 

♦ meaningful cost information needed to support performance measures; and 

♦ ability to transfer cost information directly to and from other systems. 

34 Benefit System Requirements 
 Functional Requirements 

 

 

Value-added Requirements

To support the Internal Reporting process, the benefits system should:

• Cost information for comparison to other program data to determine compliance with planned budgeted 

activities, and 

• Support the use of historical data to conduct variance analysis. 

Performance Reporting

Mandatory Requirements

To support the Performance Reporting process, the benefits system must:

• Provide features to compute and maintain performance trends such as: 

♦ number and dollar value of benefit payments made; 

♦ average benefit payment; and 

♦ benefit payments made by operating levels and geographic region. 

• Provide features to compute and maintain efficiency measures to help determine the effectiveness of use of 

agency resources (at the local level and the national level) such as: 

♦ number of applications processed; 

♦ number of awards; and 

♦ number of denials. 

• Provide features to compute the length of time claimants have received benefits (average number of months 

and years, and report(s) showing the number of individuals receiving benefits for by duration (e.g. 1-5 years, 

6-10 years) for the entire claimant population. 

Value-added Requirements

To support the Performance Reporting process, the benefits system should:

• Provide features to automatically compute and maintain efficiency measures to help determine the 

effectiveness of use of agency resources (at the local level and the national level) such as: 

♦ administrative cost per application approved, and 

♦ time required to process a claim application. 

Compulsory Notifications 

The compulsory correspondence process encompasses only outgoing correspondence. Incoming 

correspondence is addressed in claims acceptance and tracking and or claims processing depending on the type 

of incoming correspondence. 

Mandatory Requirements

To support the Compulsory Notification process the benefits system must:

• Provide for issuing standard notices for a variety of user defined events. For example, provide capabilities 

to notify claimant of decisions affecting payment amount or cessation of payments. 

• Allow the user to add custom text for each standard correspondence type. 

• Allow user to record that the U.S. Postal Service has returned correspondence as undeliverable. 

Benefit System Requirements 35
 

Functional Requirements 

• Automatically capture various correspondence including due process requests submitted by various 

electronic mediums and associate with the specific claim for the required action. 

• For manually submitted correspondence, provide for capturing such requests and associate with the specific 

claim for the required action. 

• Have the ability to capture or record the date on which a request for information is received from a claimant 

or an authorized representative, relative to an appeals case. 

Interfaces 

Benefit systems may exchange both financial and non-financial data with other internal and external systems via 

automated interface. Benefit systems require capability to develop and maintain interfaces efficiently and 

effectively through utility applications such as Application Programming Interfaces to facilitate receiving data. 

Typically benefit systems interface with other systems that are internal to an organization such as decision 

support, performance measurement, and other financial management (e.g., core). Benefit systems also interface 

with external systems of oversight and regulatory agencies such as those within Treasury FMS, IRS, OPM, and 

OMB. 

Internal Interfaces 

Mandatory Requirements

To support the Internal Interface function the benefit system must:

• If an agency’s financial management system architecture is configured so that the major functions described 

herein are performed entirely by the benefit module, provide capability to interface with agency core 

accounting system to record the accounting impact of all financial activity at the U.S. SGL level, on a daily 

basis, to support consolidated financial reporting. 

• Provide standard input record format(s) for interface of transactions from other systems to the benefits 

system and subject all transactions from interfacing systems to the benefits financial system edits, 

validations, and error correction procedures. Erroneous transactions must be maintained and tracked until 

corrected, posted, or deleted by an authorized user. 

• When a major benefit system function(s) such as payment administration or recovery receivable 

management is performed by the core system, the benefit system must provide capability to interface with 

agency’s core accounting system to automatically update detailed claimant related information (e.g. 

individual payable and receivable records) that is maintained in the core system. 

• Provide for capability to interface to the agency’s cost accounting system. 

Value-added Requirements

To support the Internal Interface function the benefit system should:

• Provide capability for a two-way interface with the core system for purposes of funds control and funds 

availability verification. 

External Interfaces 

As stated throughout this document, the functions listed below can be accomplished using functionality of 

integrated financial system components such as the core financial system. 

36 Benefit System Requirements 
 Functional Requirements 

 

 

Mandatory Requirements

To support the External Interface function the benefit system must:

• Provide capabilities allowing interface with central agency financial systems such as Department of the 

Treasury FMS and IRS Systems, OMB, and OPM systems according to the standards established by these 

oversight and regulatory agencies. For example, Department of the Treasury interfaces must include the 

capability to: 

♦ receive and read the deposit reconciliation file from Treasury, and to produce a report of the matched 

data and differences; 

♦ produce a file of all hold check transactions as they are created, and to periodically transmit the hold 

check file to Treasury; 

♦ produce and transfer a file of changes to EFT payments previously forwarded to Treasury for release; 

♦ produce and transfer a file of changes to be made to the Home Address file in Treasury; 

♦ receive and process the data on the returned check file sent by Treasury’s Recertification system, 

including generating returned check transactions and updating account data; and 

♦ receive and automatically process an ACH update file (containing changes to EFT information) from 

Treasury or other sources on a recurring basis. 

Value-added Requirements

To support the External Interface function the benefit system should:

• Receive information from SSA records to verify applicant's name, SSN, and income information, when 

legally permitted. 

• Provide features to verify applicant's income against Civil Service Annuity, Military Retirement, and IRS 

earnings records, when legally permitted. 

Quality Assurance and Maintenance 

This section addresses processes that are performed by the system to ensure that improper payments are avoided 

and that claimants’ master records are accurate and updated in a timely manner. 

Mandatory Requirements

To support the Quality Assurance and Maintenance function, the benefit system must:

• Provide capabilities to select benefit claims based on agency program evaluation criteria (such as attainment 

of certain dollar thresholds—cumulative and per payment, excessive length of benefit payment life) for 

subsequent review. 

• Provide ability to monitor and update a claimant’s master records to reflect changes in circumstances 

affecting a claimant's eligibility or the amount of payment. 

• Provide capabilities to capture claimant (or relative) reported matters such as: 

♦ death; 

♦ change in amount of earned/unearned income; 

♦ change of residence; 

♦ marriage, divorce, or separation; 

♦ absence from the U.S.; 

♦ change in disability condition; 

♦ eligibility for other benefits; 

Benefit System Requirements 37
 

Functional Requirements 

♦ changes in net worth/resources of claimant; 

♦ change in school attendance; 

♦ change in composition of household; and 

♦ change in citizenship or alien status. 

• Provide for the recording of notes or comments by customer service representatives and associate with the 

claimant’s master record, and maintain a history of notes taken. 

• Provide features to record death information provided from voluntary sources (e.g. returned check, funeral 

home notification, and next of kin). 

• Provide capabilities to record the method used to independently verify the death of a claimant before 

terminating benefits (phone contact, signature verification, or personal contact with next of kin). 

• Provide ability to maintain schedule of continuing disability reviews (when applicable) at the individual 

claim holder level, and maintain the status of the schedule within the claimants master record. 

• Provide capabilities to track the status of appeal proceedings when a change is made affecting a current 

claimant’s level of benefits. 

• Provide features to record termination of benefit payment including: 

♦ event/reason for termination (e.g. death, increase in income); and 

♦ date of event (thus effective date of benefit cessation). 

Value-added Requirements

To support the Quality Assurance and Maintenance function, the benefit system should:

• Provide features to determine if benefits are commensurate with claimant's gender. 

• Have the ability to select benefit payment calculations based on statistical sampling techniques for the 

purpose of verifying calculations. 

• Provide the ability to generate a random sample of claimants to periodically survey regarding their 

satisfaction with the agency’s benefit payment claims process (from initial contact with agency to receipt of 

benefit payment). 

• Allow users to suspend payment to claimants, when fraud is suspected, or death has been reported but not 

yet verified by an authoritative source (e.g., SSA). 

• Allow users to cancel a previously recorded suspected death on a claimant, and place the claimant back in a 

payment status if appropriate

Technical Functional Requirements 

Technical functional requirements are grouped into the following five categories: general, security and internal 

control related, access to information, data entry, archiving and purging. 

General 

Mandatory Requirements

To support the general technical functionality, the benefit system must:

• Provide for back up and recovery of the system per relevant OMB Circulars.

• Adhere to the applicable final “Electronic and Information Technology Accessibility Standards” issued by 

the Architectural and Transportation Barriers Compliance Board, which address technical and functional 

38 Benefit System Requirements 
 Functional Requirements 

 

 

performance criteria necessary for such technology to comply with section 508 of the Rehabilitation Act 

Amendments of 1998.

• Allow users to input parameters required to run batch jobs in a production mode either daily, monthly, 

quarterly or yearly. 

• Provide all users the capability to perform a “Print Screen” function. 

Security and Internal Controls 

The requirements listed below supplement other internal control requirements that have been incorporated into 

the appropriate major functional requirement section of this document. The following requirements affect more 

than one of the major functional requirements 

Mandatory Requirements:

To support the Security and Internal Controls activities, the benefits system must: 

• Provide flexible security facilities to control user access at varying degrees including: overall system access, 

capability to perform specific functions (inquiry, update), access to certain functionality. 

• Provide capability to define access to specific functions by named user, class of user, and position. 

• Provide for multiple levels of approvals based on user-defined criteria including dollar limits, type of 

document processed, etc. 

• Provide the capability to perform reconciliation routines for internal participant accounts, ledgers, and funds, 

and to identify unsuccessful reconciliations via error log or error report. 

• Establish appropriate administrative, technical and physical safeguards to ensure the security and 

confidentiality of records and to protect against anticipated threats or hazards to their security or integrity 

which could result in substantial harm, embarrassment, inconvenience, or unfairness to any individual on 

whom information is maintained. 

• Provide a mechanism to monitor changes to software coding and the responsible individual (authorized 

user). 

Access to Information 

Mandatory Requirements:

To support the Access to Information process, the benefits system must:

• Comply with the disclosure provisions of the Privacy Act of 1974 (5 U.S.C. § 552A) as amended. 

• Allow for the information contained in the system to be queried and present detailed data as requested. This 

will include user-defined criteria to access data for open or closed accounting periods. 

• Provide users with access to on-line guidance or help for performing system functions 

• If a claimant’s or claim holder’s record is not located via query, display a message indicating the transaction 

cannot be completed and further research is required. 

• Present information resulting from system queries in a formatted fashion to facilitate the understanding of 

the information by non-technical users, and unformatted for more technically proficient users. 

• Provide the capability to access historical data records that are removed from on-line viewing, including 

items such as individual benefit payments, receivable, and collection data. 

Benefit System Requirements 39
 

Functional Requirements 

• Allow users to design extract files for their specific requirements, and perform table look-ups and expansion 

of codes when needed to clarify the information contained within the results of system queries or reports. 

• Provide features to facilitate verification (i.e., matching programs) using information extracted (see above) 

from the benefit system for comparison against benefit programs administered by other agencies when 

legally permitted. 

• Facilitate the analysis of information contained in the system by allowing analysts to obtain report 

information and the results of system queries in data files that can be transferred to other applications or 

analytical tools. 

• Provide for easy access to historical files for comparative, analytical, and trend information. 

Value-added Requirements

To support the Access to Information process, the benefit system should: 

• Provide for self-service claimant initiated Web browser requests pertaining to account specific matters. For 

example: 

♦ enable the claimant to request the reissuance of a misplaced payment using a Web browser; 

♦ enable the claimant to access decision tree functions to help guide them through self-service 

transactions through a Web browser; 

♦ have pop-up windows to help annuitants when making changes to files through a Web browser; 

♦ enable the claimant to complete forms using a Web browser; 

♦ have the ability to verify the claimant security information through a Web browser; 

♦ provide access to claimant retirement related data through Interactive Voice Response (IVR); 

♦ make IVR available for claimant inquiries 24 hours a day, 7 days a week with the exception of 

scheduled outages; 

♦ allow the claimant to initiate changes to his/her account through the IVR; 

♦ have the ability to support multiple languages (e.g., English and Spanish). 

Data Entry 

Mandatory Requirements:

To support the Data Entry technical function, the benefits system must:

• Utilize various automated input devices when hard copy applications and correspondence are received. For 

example, optical character recognition devises, digital imaging tools or other input streamlining technology 

must be utilized whenever feasible when processing standard hard copy applications or other required 

correspondence. 

• Support both batch and real-time on-line data entry and use the same edit and update rules as appropriate for 

each mode. 

• Support simultaneous data entry/access by multiple users in a variety of access modes. 

• User entry and query screens must support validation of codes entered on the screen. Assist users in 

determining correct codes if an invalid code is entered. Provide for inquiry by the user to verify valid codes 

during the data entry process. 

• Provide the capability to display inputs required to complete transactions by a user based on the selection of 

transaction type. Whenever possible, keystroke reducing tools such as drop down menus should be utilized 

to reduce chance of data entry error. 

40 Benefit System Requirements 
 Functional Requirements 

 

 

• Display a message to the user notifying them of the acceptance or rejection of each transaction once all 

inputs are completed. 

Value-added Requirements

To support the Data Entry technical function, the benefits system should: 

• Identify erroneous inputs with corrective recommendations. 

• Provide the capability for financial users to create comments relating to all types of transactions using freeform text 

Archiving and Purging 

The archiving and purging process supports data management for the benefits system. It removes data that is no 

longer needed for immediate access from the system data stores used for inquiry and reporting on current 

information. Archiving moves data to a storage medium that has a longer access time; for example, from disk to 

tape. Purging deletes data altogether. Archiving and purging criteria should be jointly agreed to by the system 

administrator and users to balance user needs with resource limitations. 

Mandatory Requirements:

To support the Archiving and Purging process, the benefits system must:

• Provide an automated means for permanently storing electronic data. 

• Archive transactions and related information needed for audit trails in a format accessible by audit software. 

• Provide the authorized system administrator the flexibility to determine whether records are to be archived 

or purged. Of those documents that meet the criteria the system must allow selective action. The system 

must include the capability to establish and maintain user defined archival criteria. 

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

Records Administration (NARA), GAO, and others. Prevent the purging of transactions prior to the proper 

period in accordance with regulations governing the retention of documents and transactions. 

Benefit System Requirements 41
 

 Information Stores –Benefit System Data Elements 

Information Stores –Benefit System Data Elements 

Application Information Stores 

This refers to all data recorded from the source document(s) used in determining eligibility, and also includes 

the status of the review and approval of the application. The various types of benefits addressed in this 

document have information requirements that are both universal for all benefit categories (as defined in this 

document) and those that are unique to a particular category of benefit (i.e., retirement, disability, etc.). 

Accordingly, the following data requirements are organized as universal and also by benefit category. All data 

elements must be captured and maintained in accordance with the provisions of Privacy Act of 1974 as 

amended. 

Universal Data Elements 

The following data elements are essential and common to every Federal benefit category. These data elements 

are supplemented with additional elements that vary depending on the category of benefit that is being 

administered as described below. 

Mandatory Requirements

To support the Application Information Store data element requirements of all the benefit categories described 

below, the benefits system must capture: 

• Name and address of claim holder (person on whose record benefit is earned/due). 

• SSN of claim holder. 

• Birth date of the claim holder 

• Date of initial claim. 

• Claimant information, if other than claim holder, including: 

♦ name, address and SSN, and birth date; and 

♦ the claimant's relationship to claim holder, when different from the claim holder (e.g., self, spouse, 

child, dependent parent). 

• Name and relationship of a representative payee, including estate executors or legal guardians, when 

applicable. 

• The specific benefit(s) for which the claim is made. 

• Claimant address. 

• Bank information for direct deposit, if applicable including American Bank Association routing number, 

claimant bank account number, and account type. 

• Type of evidence/proofs required and submitted when applicable. 

• Status of the claim (e.g. approved, pending, denied). 

• For benefit systems relating to taxable programs, information needed to determine withholding amount 

such as: withholding status15 (e.g., married, single, or exempt); tax number of withholding allowances, 

back-up withholding, and additional voluntary amount of tax withholding. 

 

15 This does not necessarily equate to marital status. 

42 Benefit System Requirements 
 Information Stores –Benefit System Data Elements 

 

 

Additionally, for systems used in administering “means tested programs” the benefits system must capture: 

• Claimant wages, salaries, and other income that is considered in determining eligibility and or benefit 

amounts. 

• Types and amounts of assets owned by the claimant, which are considered in determining eligibility and or 

benefit amounts. 

Value-added Requirements

To support the Application Information Store data element requirements of all the benefit categories described 

below the benefits system should capture 

• Gender of Claimant (to facilitate verifying claimant’s identity). 

Categorical Benefit System Information Stores 

All of the following data requirements listed below will not apply to every agency that administers a Federal 

benefit program. The requirements for each category listed below are applicable only when an agency 

administers a benefit program within a particular category. For example, an agency administers a disability 

program and no other program. In this situation the agency would only be required to capture the universal data 

elements and the mandatory data elements listed within the disability category. 

Federally Administered Retirement Benefit Systems

Federally administered retirement benefit systems include systems used in administering both Federal 

employment related (i.e., civilian, military and Federal law enforcement) retirement programs and Social 

Security retirement programs. Generally, the data elements needed for Federal Employment Related Retirement 

benefit systems are the same as Social Security retirement benefits. However, there are certain unique data 

elements that apply only to Federal employment related retirement benefit systems. Those unique data elements 

are listed separately below, under Federal Employment Related Retirement benefit systems. 

Mandatory Requirements

To support the Application Information Store data requirements for Federally administered retirement systems, 

the benefits system must capture: 

• The effective date of retirement. 

• Claim holder and or claimant dependency information (e.g., children, parents). 

• Dates of creditable employment of the claim holder (and military service when used in determining 

eligibility and the amount of benefits). 

• Historical earnings data (e.g., previous annual wages and salary) of the claim holder that used required for 

determining eligibility or the amount of benefit. 

• Total participant and employer contributions to the retirement plan made on behalf of the participant. 

Benefit System Requirements 43
 

 Information Stores –Benefit System Data Elements 

Value-added Requirements

To support the Application Information Store data requirements for Federally administered retirement systems, 

the benefits system should capture: 

• Current balance of vested employee and employer contributions. 

• Other names under which the claim holder has used (such as maiden name). 

• Phone number of claimant. 

• Other unique identifying number. 

Federal Employment Related Retirement Benefit Systems

The following data requirements pertain only to Federal employment related benefit systems such as CSRS, 

FERS, military retirement, and others. They do not apply to the general Old Age retirement benefit system 

administered by the SSA, or any other federally administered retirement programs that are not related to Federal 

employment. 

Mandatory Requirements

To support the Application Information Store data requirements Federal employment related retirement, the 

benefits system must capture: 

• Date of final separation. 

• Lump sum (refund of contributions) distributions versus annuity distributions. 

• Annuity selection (e.g., self-only, self and reduced survivor, self and maximum survivor). 

• Present marital status. 

• Spouse’s name, date of birth, social security number and date of marriage when applicable. 

• Name, date of birth, social security number and dates of marriage and divorce of former spouses who have 

a court ordered annuity. 

• Percentage or dollar amount of court ordered former spouse annuity. 

• Highest pay scale (grade) level or amount of highest salary and related dates. 

• Voluntary separation monetary incentive. 

Disability Related Benefits 

Mandatory Requirements

To support the Application Information Store data requirements relative to systems used in administering 

disability related programs, the benefits system must capture: 

• Type of disability or disability code. 

• Date of disability onset or injury. 

• Degree of impairment or diagnosis. 

• Name of examining physician. 

• Claimant’s physical location where injury occurred (i.e., at work, home, etc.). 

44 Benefit System Requirements 
 Information Stores –Benefit System Data Elements 

 

 

Value-added Requirements

To support the Application Information Store data requirements relative to systems used in administering 

Disability Related Benefit programs, the benefits system should capture: 

• Whether disability was caused by employment or related to military service. 

• Claimant or dependent(s)’ student status (e.g., fulltime, yes or no). 

Death Benefits 

Mandatory Requirements

To support the Application Information Store data requirements relative to systems used in administering death 

benefit programs, the benefits system must capture: 

• Claimant’s relation to claim holder. 

• Dates of creditable employment of the claim holder (and military service when used in determining 

eligibility and the amount of benefits). 

• Claimant dependency information, when such affects the benefit amount. 

• Date married, when applicable. 

• Date divorced when applicable. 

• Date of claim holder death. 

Value-added Requirements

To support the Application Information Store data requirements relative to systems used in administering death 

benefit programs, the benefits system should capture: 

• Claimant and or claim holder’s dependent(s) student status (e.g., fulltime, yes or no). 

Survivor Benefits 

Mandatory Requirements

To support the Application Information Store data requirements relative to systems used in administering 

survivor programs, the benefits system must capture: 

• Claimant’s relation to claim holder. 

• Dates of creditable employment of the claim holder (and military service when used in determining 

eligibility and the amount of benefits). 

• Claim holder or claimant dependency information (e.g. children, parents). 

• Date married, when applicable (i.e., claimant is former spouse). 

• Date divorced, when applicable (i.e., claimant is former spouse). 

• Date of claim holder death. 

• Student status (e.g., fulltime, yes or no) . 

Benefit System Requirements 45
 

 Information Stores –Benefit System Data Elements 

Other Benefits 

Mandatory Requirements 

To support the “Other” Application Information Store data requirements, the benefits system must capture 

♦ Universal data elements only, there are no additional mandatory data elements. 

Value-added Requirements

To support the “Other” Application Information Store data requirements, the benefits system should capture: 

• Claimant or dependent(s)’ student status (e.g., fulltime, yes or no). 

Claimant Master Record Information Store

This refers to permanent data that is maintained in the system for each claimant once a claim has been approved. 

Certain data is captured from the Application Information Store and additional data is added throughout the 

duration of the benefit payment period to support customer servicing and analysis. The following data must be 

maintained in the system for each approved claim. 

 

Mandatory Requirements

To support the Claimant Master Record data requirements, the benefit system must maintain: 

• All applicable mandatory data elements (Universal and appropriate categorical) specified within the 

application information data stores; 

• General information such as: case status, benefit type, chronology of key dates; 

• award data such as: total award, gross and or net monthly payment as appropriate; 

• payment history such as: prior disbursements, collections including principal and interest, accruals; 

• special Collection Activity Data such as: delinquent debt collection activity and status. 

Value-added Requirements

To support the Claimant Master Record data requirements, the benefit system should: maintain: 

• General data such as demographic data other than that specified in the application information stores that 

has been historically used by the agency in preparing actuarial estimates, for purposes such as forecasting 

and complying with financial statement reporting requirements (e.g. SFFAS No. 5 and No. 17). 

Program Criteria Information Store 

Generally, these requirements will be agency specific. However, the criteria should be easily modified by 

agency users who have the appropriate access to reflect changes in legislation. Whenever possible, criteria 

should be maintained in tables rather than being embedded in the system coding. 

Financial Information Store

Mandatory Requirements

To support the Financial Information Store data element requirements, the benefit system must maintain:

• Present interest rate per the Department of the Treasury. 

46 Benefit System Requirements 
 Information Stores –Benefit System Data Elements 

 

 

Value-added Requirements

To support the Financial Information Store data element requirements, the benefit system should maintain: 

• Daily exchange rate for relevant (as specified by agency) currencies. 

Benefit System Requirements 47
 

Appendix A: References 

Appendix A: References

Introductory Note: The following list identifies governmentwide accounting standards, laws, regulations, and 

other mandates that pertain to Federal benefit programs and benefit system requirements. Some laws and 

regulations pertaining to benefit programs apply only to certain agencies. Because they do not have 

governmentwide applicability, these agency-specific laws and regulations are not included in the list below. 

However, agencies should ensure that their benefit systems perform the functions necessary to comply with any 

internal agency-specific laws and regulations. 

ACCOUNTING STANDARDS:

Statements of Federal Financial Accounting Standards (SFFAS): 

SSFAS 1, Accounting for Selected Assets and Liabilities 

SSFAS 4, Managerial Cost Accounting Concepts and Standards 

SSFAS 5, Accounting for Liabilities of the Federal Government 

SSFAS 17, Accounting for Social Insurance 

 

JFMIP SYSTEM REQUIREMENTS

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

Core Financial System Requirements, JFMIP-SR-99-4, 2/99 

LAWS

Accounting Standardization Act of 1995 

Anti-Deficiency Act 

Budget Enforcement Act 

Chief Financial Officers Act (CFO) Act of 1990 (Public Law 101-576) 

Clinger/Cohen Act (Information Technology Management Reform Act) (Division E of Public Law 104-106) 

Computer Security Act of 1987 (Public Law 100-235) 

Debt Collection Act of 1982 

Debt Collection Improvement Act of 1996 

Federal Financial Management Improvement Act (FFMIA) of 1996 

Federal Manager’s Financial Integrity Act of 1982 

Federal Records Act of 1950, as amended (Records Management by Federal Agencies, 44 U.S.C 3101 et. seq.) 

Freedom of Information Act of 1982 (5 U.S.C 552) 

Government Management Reform Act (GMRA) of 1994 

Government Performance and Results Act of 1993 (Public Law 103-62) 

Government Paperwork Elimination Act 

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

48 Benefit System Requirements 
 Appendix A: References 

 

 

Paperwork Reduction Reauthorization Act of 1986 (Public Law 104-13) 

Privacy Act 

Rehabilitation Act Amendments of 1998 (Workforce Investment Act) (Public Law 106-246) 

US CODES

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) 

5 U.S.C § 552 (contains provisions of Freedom of Information Act) 

44 U.S.C § 3101 (Addresses records management within Federal agencies) 

OMB DOCUMENTS:

OMB Bulletin No. 01-01, "Form and Content of Agency Financial Statements.” 

OMB Circular No. A-11, "Planning, Budgeting, and Acquisition of Capital Assets (Part 3) Supplement to Part 3, 

Capital Programming Guide" 

OMB Circular A-109 – “Policies for Acquiring Major Systems.” 

OMB Circular No. A-123, "Management Accountability and Control," 6/95 

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

OMB Circular No. A-129, “Managing Federal Credit Programs.” 

OMB Circular No. A-130, "Management of Federal Information Resources,” 2/96 

OMB Memorandum M-97-02, “Funding Information Systems Investments.” 

OTHER APPLICABLE STANDARDS, GUIDELINES, AND REGULATIONS

Electronic and Information Technology Accessibility Standards (issued by the Architectural and Transportation 

Barriers Compliance Board) 

Federal regulations established by the NARA 

Treasury Financial Manual 

Benefit System Requirements 49
 

Appendix B: Glossary 

Appendix B: Glossary 

Annuity: A contract which entitles the holder to a sum of money payable at regular intervals, typically monthly 

or annually, for an agreed upon period of time. Generally, annuities are determined based on actuarial 

estimates. 

Benefit System: A unified system used in administering a Federal benefit program. Taken as a whole, the 

components of the unified system accomplish the major functions specified on p. 11.

Central Systems: Central systems collect and maintain financial and related performance measurement data 

needed for governmentwide reporting and analysis, budget execution analysis, production of consolidated 

financial statements, program monitoring, and government- wide decision-making support.

Claim: A written assertion of entitlement. 

Claimant: Person who is filing (applying) for benefits. 

Claim Holder: Person on whose record a benefit was earned/due. 

Financial Management System: The financial systems and the financial portions of mixed systems necessary 

to support financial management. 

Financial System: An information system comprised of one or more applications used for collecting, 

processing, maintaining, transmitting, and reporting data about financial events; supporting financial planning or 

budgeting activities; accumulating and reporting cost information; or supporting financial statement preparation. 

Federal Benefit Program: A Federal program that typically encompasses most (but not necessarily all) the 

following characteristics: Is classified as “mandatory” rather than discretionary under the Budget Enforcement 

Act classification; related systems used in daily operations are owned and operated by the Federal Government; 

involves monetary payments that are provided directly to individuals or a designee; the Federal Government 

determines the exact amount of payments; involves a “fixed amount” recurring payment. Additionally, health 

care related programs such as Medicare, Tricare, and Veterans Health are specifically excluded for purposes of 

this document. 

Health Care Related Benefit Program: A Federal program in which the primary function focuses on 

providing monetary reimbursement to health care providers for services performed, or providing direct care to 

qualified participants. 

Information System: The organized collection, processing, transmission, and dissemination of information in 

accordance with defined procedures, whether automated or manual. Information systems encompass nonfinancial, financial and mixed systems. 

Internal Benefit Payment Program: All benefit payment programs that are administered by the same Federal 

agency (e.g. old age retirement, survivor, and disability are internal to the SSA.), (an agency perspective). 

Mixed System: An information system that supports both financial and non-financial functions of the Federal 

Government or components thereof. See OMB Circular A-127. 

Means Tested Programs: Programs in which the claimant’s financial need is taken into consideration 

when awarding a benefit and financial resources are evaluated during claim processing.

50 Benefit System Requirements 
 Appendix B: Glossary 

 

 

Module: A component of an information system that carries out a specific function or functions and may be 

used alone or combined with other components. 

Non-Financial System: Information systems that support a variety of non-financial functions necessary to carry 

out programs. These systems involve processes necessary to carry out programs not involving financial events. 

Examples include Air Traffic control and law enforcement systems. 

Offset: A reduction of a payment due to a claimant for the purpose of recovering a debt owed by the claimant. 

Payee: Anyone receiving a benefit payment or portions thereof, including guardians, executors, other 

individuals designated by the claimant, and creditors of a claimant (e.g. garnishment and offsets). 

Reconciliation: The process of aligning shared records or information contained in more than one location or 

storage facility (e.g. data base, hard copy report). In financial systems, the sum of detailed data is reconciled to 

a control total in another related system or module. 

Software: The application and operating system programs, procedures, rules, and any associated 

documentation pertaining to the operation of a computer system. 

Source Document: The original record that serves as the basis for entering data into a financial or mixed 

system. Typically, it is a paper record such as an application for benefits. 

Tax Withholding Status: Single, married, married but withhold at higher single rate, and exempt. This 

selection is typically elected by the claimant on tax withholding forms (e.g., W-4P). 

Unified System: Information systems that are planned and managed together, and linked together electronically 

in an efficient and effective manner to provide agency-wide financial system support necessary to carry out the 

agency's mission and support the agency's financial management needs.

User: An individual agent (employee or contractor) of the agency administering the benefit program who has 

authorized access to the benefit system. Unless otherwise specified, the term user does not refer to self-service 

activities performed by a benefit claimant on an IVR system or via a web browser. 

Venn Diagram: A graph that employs circles to represent logical relations. 

Waiver: A forgiveness of debt, the claimant is not held responsible and is not subject to collection efforts. 

Benefit System Requirements 51
 

Appendix C: Contributors 

Appendix C: Contributors 

JFMIP Steering Committee 

Jeffrey C. Steinhoff, Chair, U.S. GAO 

Donald V. Hammond, U.S. Department of the Treasury

Karen Cleary Alderman, Executive Director, JFMIP

Joseph L. Kull, Office of Management and Budget

William B. Early, General Services Administration

Kathleen M. McGettigan, Office of Personnel Management 

Joint Financial Management Improvement 

Program 

Karen Cleary Alderman, Executive Director, JFMIP

Steven A. Fisher, Project Manager

Benefit System Requirements Project Team

Department of Veterans Affairs (Sponsoring Agency)

Dennis Kordyak, Acting Deputy Assistant Secretary for Management, (Project Chair ) 

Chuck Cusak 

Vidal Falcon 

Richard Norwood 

Dana Rooney-Fisher 

Department of Agriculture

Donna Speed 

Department of Defense 

Kris Beaubien 

Fiti Malufau 

Federal Accounting Standards Advisory Board

Richard Fontenrose 

General Accounting Office

Debra Sebastian 

Janett P. Smith

Department of Health and Human Services

Paul Henderson 

52 Benefit System Requirements 
 Appendix C: Contributors 

 

 

Department of Labor

June Carter 

Veronica Freeman 

Office of Management and Budget

Sandra Swab 

Office of Personnel Management

Ken Harris 

Robert Yuran 

Railroad Retirement Board

Kris Garmager 

Social Security Administration

Bonnie Kind 

Lois Sheppard 

Stan Wegerski 

Department of State

Jacqueline May 

Sally Zottnick 

Department of the Treasury

Richard Aaronson 

Betty Harvey-Tauber 

Peter Mackey 

Executive Leadership Program Participants

Beverly Sylvia Brooks, SSA 

Irene Lucas, Department of State 

Ruth Laughner, HHS, NIH 

Shirl Wilson, HHS, HRSA 

Benefit System Requirements 53