Introduction

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

ACHAutomated Clearing House

ALCAgency Location Code

CDOChief Disbursing Officer

CFO Chief Financial Officer

CFRCode of Federal Regulations

CSRSCivil Service Retirement System

DCADebt Collection Act of 1982

DCIADebt Collection Improvement Act of 1996

DODDepartment of Defense

DOLDepartment of Labor

EFTElectronic Funds Transfer

FACTSFederal Agencies’ Centralized Trial-Balance System

FASAB Federal Accounting Standards Advisory Board

FERSFederal 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

IVRInteractive Voice Response

IRSInternal Revenue Service

JFMIP Joint Financial Management Improvement Program

NARANational Archives and Records Administration

OMB Office of Management and Budget

OPM Office of Personnel Management

RRBRailroad Retirement Board

SSASocial Security Administration

SSNSocial Security Number

SFFASStatements of Federal Financial Accounting Standards

TAFSTreasury Account Fund Symbol

TIN Taxpayer Identification Number 

TOPTreasury Offset Program

TFMTreasury Financial Manual

U.S.C.United States Code

U.S. SGLUnited States Standard General Ledger

VADepartment of Veterans Affairs

Illustrations (List)

1.  Financial System Improvement Projects4

2.  Integrated Model for Federal Information Systems 6

3.  Agency Financial Management Systems Architecture7

4.  Typical Interactions of a Benefit System12

Table of Contents

Forward

Acronyms and Illustrations List

Introduction1

Federal Financial Management Framework2

Benefit System Overview8

             Background8

Management Controls11

Benefit System Major Functions11

Relationship with Other Systems12

Information Stores - Data Requirements Overview 13

Functional Requirements14

Claims Acceptance and Tracking14

Claims Processing15

Benefit Payment Administration18

Recovery Receivable Management26

Accounting for Benefit Transactions30

Reporting33

Interfaces36

Quality Assurance and Maintenance37

Technical Functional Requirements38

Information Stores – Required Data Elements42

Application Information Stores42

Claimant Master Record Information Store46

Program Criteria Information Store46

Financial Information Store46

Appendix A: References48

Appendix B: Glossary50

Appendix C: Contributors 52

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.

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;

· support the preparation and execution of agency budgets;

· facilitate the preparation of financial statements and other financial reports in accordance with Federal accounting and reporting standards;

· provide information to central agencies for budgeting, analysis, and governmentwide reporting, including consolidated financial statements; and

· provide a complete audit trail to facilitate audits.

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

Illustration 1

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 systems encompassing the software, hardware, personnel, processes (manual and automated), procedures, controls, and data necessary to carry out financial management functions, manage financial operations of the agency, and report on the agency's financial status to central agencies, Congress, and the public.  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-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.

Illustration 2

**Agency Financial Management Systems Architecture**

Agency financial management systems are information systems that track financial events and summarize information to support the mission of an agency, provide for adequate management reporting, support agency level policy decisions necessary to carry out fiduciary responsibilities, and support the preparation of auditable financial statements.

Agency financial management systems fall into four categories:

(1) Core financial systems;

(2) Other financial and mixed systems, (such as 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

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

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

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 benefit 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/Description

# 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

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.

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

Illustration 4

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. 

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

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.

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

· 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 spouse 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 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 36 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 payments 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 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.) 

· 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, waivers, 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. 

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

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

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

· 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 “emergency ” 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.

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.

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;

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

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

**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 agency, 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-tested 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.

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

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.

· 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, system-generated 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.

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

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

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.

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

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;

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

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

· 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 free-form 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. 

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 status (e.g., married, single, or exempt); tax number of withholding allowances, back-up withholding, and additional voluntary amount of tax withholding. 

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.

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

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

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

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.

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

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

***Appendix B: Glossary***

advance \d3**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 non-financial, 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.

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

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

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

� An information system that supports both financial and non-financial functions of the Federal Government or components thereof.  See OMB Circular A-127.

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

� An information system that supports both financial and non-financial functions of the Federal Government or components thereof.  See OMB Circular A-127.

� As herein defined.

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

� As specified in the Claims Processing section.

� The claimant fills in all required fields.

� Or former spouse.

� Or other number as required by law, regulation or statute.

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

� See definition in Appendix B glossary

� As defined by the administering agency.

� The Federal Government also has authority to collect debts owed to non-federal entities.

� See definition in Appendix B Glossary.

� This does not necessarily equate to marital status.

Benefit System Requirements**1**

# _1063028362.unknown

# _1063177254.doc

# _1063177497.unknown

# _1056889965.unknown

# _1062924807.unknown