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

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.

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

> Karen Cleary Alderman
>
> Executive Director

Acronyms

ACH Automated Clearing House

ALC Agency Location Code

CDO Chief Disbursing Officer

CFO Chief Financial Officer

CFR Code of Federal Regulations

CSRS Civil Service Retirement System

DCA Debt Collection Act of 1982

DCIA Debt Collection Improvement Act of 1996

DOD Department of Defense

DOL Department of Labor

EFT Electronic Funds Transfer

FACTS Federal Agencies' Centralized Trial-Balance System

FASAB Federal Accounting Standards Advisory Board

FERS Federal Employees Retirement System

FFMIA Federal Financial Management Improvement Act of 1996

FFMSR Federal Financial Management System Requirements

FMS Department of the Treasury Financial Management Service

GAO General Accounting Office

GMRA Government Management Reform Act of 1996

GPRA Government Performance and Results Act of 1994

HHS Department of Health and Human Services

IVR Interactive Voice Response

IRS Internal Revenue Service

JFMIP Joint Financial Management Improvement Program

NARA National Archives and Records Administration

OMB Office of Management and Budget

OPM Office of Personnel Management

RRB Railroad Retirement Board

SSA Social Security Administration

SSN Social Security Number

SFFAS Statements of Federal Financial Accounting Standards

TAFS Treasury Account Fund Symbol

TIN Taxpayer Identification Number

TOP Treasury Offset Program

TFM Treasury Financial Manual

U.S.C. United States Code

U.S. SGL United States Standard General Ledger

VA Department of Veterans Affairs

Illustrations (List)

1\. Financial System Improvement Projects 4

2\. Integrated Model for Federal Information Systems 6

3\. Agency Financial Management Systems Architecture 7

4\. Typical Interactions of a Benefit System 12

Table of Contents

Forward

Acronyms and Illustrations List

Introduction 1

Federal Financial Management Framework 2

Benefit System Overview 8

Background 8

> Management Controls 11
>
> Benefit System Major Functions 11
>
> Relationship with Other Systems 12

Information Stores - Data Requirements Overview 13

Functional Requirements 14

> Claims Acceptance and Tracking 14
>
> Claims Processing 15
>
> Benefit Payment Administration 18
>
> Recovery Receivable Management 26
>
> Accounting for Benefit Transactions 30
>
> Reporting 33
>
> Interfaces 36
>
> Quality Assurance and Maintenance 37
>
> Technical Functional Requirements 38

Information Stores -- Required Data Elements 42

> Application Information Stores 42
>
> Claimant Master Record Information Store 46
>
> Program Criteria Information Store 46
>
> Financial Information Store 46

Appendix A: References 48

Appendix B: Glossary 50

Appendix C: Contributors 52

Introduction

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;

```{=html}
<!-- -->
```
-   provide for adequate agency management reporting;

```{=html}
<!-- -->
```
-   support governmentwide and agency-wide policy decision-making;

```{=html}
<!-- -->
```
-   support the preparation and execution of agency budgets;

```{=html}
<!-- -->
```
-   facilitate the preparation of financial statements and other
    financial reports in accordance with Federal accounting and
    reporting standards;

```{=html}
<!-- -->
```
-   provide information to central agencies for budgeting, analysis, and
    governmentwide reporting, including consolidated financial
    statements; and

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

![](media/image3.wmf)

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[^1] encompassing the software,
hardware, personnel, processes (manual and automated), procedures,
controls, and data necessary to carry out financial management
functions, manage financial operations of the agency, and report on the
agency\'s financial status to central agencies, Congress, and the
public. However, it does not mean that all information is physically
located in the same database.

Unified means that 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),

```{=html}
<!-- -->
```
-   how data quality will be assured (data stewardship),

```{=html}
<!-- -->
```
-   information to be processed (management information),

```{=html}
<!-- -->
```
-   how systems fit together to support the functions (systems
    architecture), and

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

![](media/image4.wmf)

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

![](media/image5.wmf)

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[^2] 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[^3] 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[^4] 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]{.underline}

+-----------------------------------------------+----------------------+
| # Program Name/Description[^5]                | # 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 | Treasury             |
| Federal pension)                              |                      |
+-----------------------------------------------+----------------------+
| 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**

![](media/image6.wmf)

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

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

```{=html}
<!-- -->
```
-   Utilize an alternative application procedure that accommodates
    persons with disabilities (e.g. blind, missing limbs).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

```{=html}
<!-- -->
```
-   Automatically determine the due date and amount of benefit payments.

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

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

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

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

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

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

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

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

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

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

To support the Payment Execution Process (for such agencies) the benefit
system **[must:]{.underline}**

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

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

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

```{=html}
<!-- -->
```
-   comply with applicable Treasury offset guidelines established under
    the authority of 31 U.S.C. § 3716(c).

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

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

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

```{=html}
<!-- -->
```
-   Allow changes to payment schedules by authorized staff prior to
    acceptance by the disbursing office.

```{=html}
<!-- -->
```
-   Allow specific payments selected for disbursement to be excluded
    from the payment cycle and held for later payment.

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

```{=html}
<!-- -->
```
-   Collect information on interest paid if applicable, and record the
    amounts to the proper ledger account.

```{=html}
<!-- -->
```
-   Calculate totals by Agency Location Code (ALC) and TAFS for
    inclusion on the payment schedule.

```{=html}
<!-- -->
```
-   Sort individual payment detail by TAFS to enable SF-224
    reconciliation.

```{=html}
<!-- -->
```
-   Provide for various forms of payment to be used, (i.e., check or
    electronic funds transfer).

```{=html}
<!-- -->
```
-   Support Treasury-specific standards for format of check and EFT
    payment requests.

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

```{=html}
<!-- -->
```
-   Allow a payment request to be removed from the automated scheduling
    stream and scheduled as a manual payment by an authorized official.

```{=html}
<!-- -->
```
-   Allow the user to trigger an immediate benefit payment for
    "emergency[^12] " situations.

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

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

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

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

```{=html}
<!-- -->
```
-   Allow the user to record the outcome of the Treasury search when
    recertified checks are issued because original checks are lost,
    stolen, or destroyed.

```{=html}
<!-- -->
```
-   Provide information about each payment to reflect the stage of the
    scheduling process that the payment has reached and the date each
    step was reached for the following processing steps:

```{=html}
<!-- -->
```
-   payment scheduled;

```{=html}
<!-- -->
```
-   schedule sent to appropriate disbursing office; and

```{=html}
<!-- -->
```
-   payment issued by appropriate disbursing office.

```{=html}
<!-- -->
```
-   Provide for comparison of the agency's payment schedule and the
    disbursing office's accomplished payment schedule.

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

```{=html}
<!-- -->
```
-   Maintain history of every payment by the benefits system, including
    authorizing document number, payment schedule number, payment date,
    payment address, and TAFS charged.

```{=html}
<!-- -->
```
-   Provide on-line access to claimant and payment information.

```{=html}
<!-- -->
```
-   Provide on-line access to open documents based on agency selection
    criteria (e.g., SSN).

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

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

-   Record the establishment of receivables in the claimant's master
    record.

```{=html}
<!-- -->
```
-   Provide for the establishment of receivables in other systems such
    as centralized accounts receivable systems, based on individual
    claim holder debts.

```{=html}
<!-- -->
```
-   Provide the capability for a user to select the reason the
    receivable is being recorded from a domain of recognized reasons.

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

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

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

```{=html}
<!-- -->
```
-   Provide features to notify overpaid individuals (or claimant\'s
    estate) of:

```{=html}
<!-- -->
```
-   the amount overpaid and how and when overpayment occurred;

```{=html}
<!-- -->
```
-   the right to appeal the overpayment determination;

```{=html}
<!-- -->
```
-   the required recovery; and

```{=html}
<!-- -->
```
-   the right to request a waiver of recovery.

```{=html}
<!-- -->
```
-   Record adjustments, both increases and decreases (i.e., non-cash
    credits) and post to a claimant's master record.

```{=html}
<!-- -->
```
-   Date the bills with the system-generated date or with the date
    supplied by an authorized user.

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

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

-   Maintain detailed information by account (i.e., individual)
    sufficient to provide audit trails and to support billing and
    research activities.

```{=html}
<!-- -->
```
-   Update each master record when billing documents are generated and
    collections are received.

```{=html}
<!-- -->
```
-   Provide on-line query capability to receivable and account
    information.

```{=html}
<!-- -->
```
-   Provide information, on a summary basis and on individual
    receivables, on the age of receivables to allow for management and
    prioritization of collection activities.

```{=html}
<!-- -->
```
-   Provide automatic calculation and assessment of interest,
    administrative charges, and penalty charges as applicable on overdue
    receivables.

```{=html}
<!-- -->
```
-   Allow for the waiver of the charges listed above with appropriate
    authority.

```{=html}
<!-- -->
```
-   Identify and report receivables that meet predetermined criteria for
    bad debt provisions or write-off.

```{=html}
<!-- -->
```
-   Maintain data for receivables referred to other Federal agencies and
    or outside organizations for collections.

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

```{=html}
<!-- -->
```
-   Produce dunning (collection) letters for overdue receivables in
    accordance with Treasury requirements and existing legislation.

```{=html}
<!-- -->
```
-   Provide authorized users with the ability to customize the dunning
    process parameters and dunning letter text.

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

```{=html}
<!-- -->
```
-   Maintain information needed to support reporting required by IRS.

```{=html}
<!-- -->
```
-   Maintain a history of billings and receipts for each receivable and
    account in accordance with agency requirements.

```{=html}
<!-- -->
```
-   Match receipts to the appropriate receivables and update system
    balances.

```{=html}
<!-- -->
```
-   Provide the ability to apply receipts to more than one receivable.

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

```{=html}
<!-- -->
```
-   Identify receivables that have been reduced by some means other than
    cash collections, such as waivers or write-offs.

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

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

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

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

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

```{=html}
<!-- -->
```
-   Provide features to record method of recovery (i.e., payment;
    internal offset; TOP, compromise settlement; civil suit; etc.).

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

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

-   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[^13], 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[^14] 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:]{.underline}**

-   Provide ability to report overdue receivables with associated SSN or
    TIN data to Treasury for possible offset.

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

```{=html}
<!-- -->
```
-   Provide the capability for a user to record the effective date of
    the offset plan.

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

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

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

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

```{=html}
<!-- -->
```
-   If the desired offset program recipient does not exist as a
    participant, provide the capability for a user to create a
    participant record.

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

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

-   Allow for recording transactions in multiple TAFS and various fund
    types. This includes annual, multi-year, and no-year appropriations,
    and trust funds.

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

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

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

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

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

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

```{=html}
<!-- -->
```
-   Allow standard transactions, including system-generated
    transactions, to be established, modified, or deleted by authorized
    personnel. Provide for traceability of changes.

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

```{=html}
<!-- -->
```
-   Provide the capability to add, modify, and maintain editing and
    posting rules through systems tables controlled by authorized
    personnel.

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

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

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

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

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

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

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

```{=html}
<!-- -->
```
-   Provide controls to prevent the creation of duplicate transactions.

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

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

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

```{=html}
<!-- -->
```
-   Provide audit trails to trace source documents and transactions
    through successive levels of summarization to the financial
    statements and the reverse.

```{=html}
<!-- -->
```
-   Provide audit trails to identify changes made to system parameters
    and tables that would affect the processing or reprocessing of any
    financial transactions.

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

```{=html}
<!-- -->
```
-   Provide audit trails that identify document input, change, approval,
    and deletions by originator.

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

```{=html}
<!-- -->
```
-   Internal Reporting

```{=html}
<!-- -->
```
-   Performance Reporting

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

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

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

```{=html}
<!-- -->
```
-   Maintain the information required for program performance, financial
    performance, and financial management performance measures needed
    for budgeting, program management, and financial statement
    presentation.

```{=html}
<!-- -->
```
-   Provide the capability to produce all relevant reports, statements,
    or returns required by the IRS, including producing year-end 1099
    statements.

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

-   Provide for an automated methodology of data manipulation and data
    exportation.

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

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

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

```{=html}
<!-- -->
```
-   cost reports to be utilized in the analysis of programmatic
    activities;

```{=html}
<!-- -->
```
-   schedules and operating statements based on the accounting
    classification elements and agency criteria;

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

-   Cost information for comparison to other program data to determine
    compliance with planned budgeted activities, and

```{=html}
<!-- -->
```
-   Support the use of historical data to conduct variance analysis.

**Performance Reporting**

Mandatory Requirements

To support the Performance Reporting process, the benefits system
**[must:]{.underline}**

-   Provide features to compute and maintain performance trends such as:

```{=html}
<!-- -->
```
-   number and dollar value of benefit payments made;

```{=html}
<!-- -->
```
-   average benefit payment; and

```{=html}
<!-- -->
```
-   benefit payments made by operating levels and geographic region.

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

```{=html}
<!-- -->
```
-   number of applications processed;

```{=html}
<!-- -->
```
-   number of awards; and

```{=html}
<!-- -->
```
-   number of denials.

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

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

```{=html}
<!-- -->
```
-   administrative cost per application approved, and

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

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

```{=html}
<!-- -->
```
-   Allow the user to add custom text for each standard correspondence
    type.

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

```{=html}
<!-- -->
```
-   For manually submitted correspondence, provide for capturing such
    requests and associate with the specific claim for the required
    action.

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

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

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

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

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

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

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

```{=html}
<!-- -->
```
-   receive and read the deposit reconciliation file from Treasury, and
    to produce a report of the matched data and differences;

```{=html}
<!-- -->
```
-   produce a file of all hold check transactions as they are created,
    and to periodically transmit the hold check file to Treasury;

```{=html}
<!-- -->
```
-   produce and transfer a file of changes to EFT payments previously
    forwarded to Treasury for release;

```{=html}
<!-- -->
```
-   produce and transfer a file of changes to be made to the Home
    Address file in Treasury;

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

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

-   Receive information from SSA records to verify applicant\'s name,
    SSN, and income information, when legally permitted.

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

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

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

```{=html}
<!-- -->
```
-   Provide capabilities to capture claimant (or relative) reported
    matters such as:

```{=html}
<!-- -->
```
-   death;

```{=html}
<!-- -->
```
-   change in amount of earned/unearned income;

```{=html}
<!-- -->
```
-   change of residence;

```{=html}
<!-- -->
```
-   marriage, divorce, or separation;

```{=html}
<!-- -->
```
-   absence from the U.S.;

```{=html}
<!-- -->
```
-   change in disability condition;

```{=html}
<!-- -->
```
-   eligibility for other benefits;

```{=html}
<!-- -->
```
-   changes in net worth/resources of claimant;

-   change in school attendance;

-   change in composition of household; and

-   change in citizenship or alien status.

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

```{=html}
<!-- -->
```
-   Provide features to record death information provided from voluntary
    sources (e.g. returned check, funeral home notification, and next of
    kin).

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

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

```{=html}
<!-- -->
```
-   event/reason for termination (e.g. death, increase in income); and

```{=html}
<!-- -->
```
-   date of event (thus effective date of benefit cessation).

Value-added Requirements

To support the Quality Assurance and Maintenance function, the benefit
system **[should:]{.underline}**

-   Provide features to determine if benefits are commensurate with
    claimant\'s gender.

```{=html}
<!-- -->
```
-   Have the ability to select benefit payment calculations based on
    statistical sampling techniques for the purpose of verifying
    calculations.

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

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

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

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

```{=html}
<!-- -->
```
-   Allow users to input parameters required to run batch jobs in a
    production mode either daily, monthly, quarterly or yearly.

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

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

```{=html}
<!-- -->
```
-   Provide capability to define access to specific functions by named
    user, class of user, and position.

```{=html}
<!-- -->
```
-   Provide for multiple levels of approvals based on user-defined
    criteria including dollar limits, type of document processed, etc.

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

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

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

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

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

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

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

-   Provide for self-service claimant initiated Web browser requests
    pertaining to account specific matters. For example:

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

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

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

```{=html}
<!-- -->
```
-   Support simultaneous data entry/access by multiple users in a
    variety of access modes.

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

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

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

-   Identify erroneous inputs with corrective recommendations.

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

-   Provide an automated means for permanently storing electronic data.

```{=html}
<!-- -->
```
-   Archive transactions and related information needed for audit trails
    in a format accessible by audit software.

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

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

```{=html}
<!-- -->
```
-   Claimant information, if other than claim holder, including:

```{=html}
<!-- -->
```
-   name, address and SSN, and birth date; and

```{=html}
<!-- -->
```
-   the claimant\'s relationship to claim holder, when different from
    the claim holder (e.g., self, spouse, child, dependent parent).

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

```{=html}
<!-- -->
```
-   For benefit systems relating to taxable programs, information needed
    to determine withholding amount such as: withholding status[^15]
    (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]{.underline}** 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]{.underline}** 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]{.underline}** capture:

-   The effective date of retirement.

-   Claim holder and or claimant dependency information (e.g., children,
    parents).

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

-   Type of disability or disability code.

```{=html}
<!-- -->
```
-   Date of disability onset or injury.

```{=html}
<!-- -->
```
-   Degree of impairment or diagnosis.

```{=html}
<!-- -->
```
-   Name of examining physician.

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

-   Whether disability was caused by employment or related to military
    service.

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

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

-   Daily exchange rate for relevant (as specified by agency)
    currencies.

***Appendix A: References***

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

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

Framework for Federal Financial Management Systems (FFMSR-0), 1/95

Core Financial System Requirements, JFMIP-SR-99-4, 2/99

**[LAWS]{.underline}**

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

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

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

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

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

Dennis Kordyak, Acting Deputy Assistant Secretary for Management,
(Project Chair )

Chuck Cusak

Vidal Falcon

Richard Norwood

Dana Rooney-Fisher

**[Department of Agriculture]{.underline}**

Donna Speed

**[Department of Defense]{.underline}**

Kris Beaubien

Fiti Malufau

**[Federal Accounting Standards Advisory Board]{.underline}**

Richard Fontenrose

**[General Accounting Office]{.underline}**

Debra Sebastian

Janett P. Smith

**[Department of Health and Human Services]{.underline}**

Paul Henderson

**[Department of Labor]{.underline}**

June Carter

Veronica Freeman

**[Office of Management and Budget]{.underline}**

Sandra Swab

**[Office of Personnel Management]{.underline}**

Ken Harris

Robert Yuran

**[Railroad Retirement Board]{.underline}**

Kris Garmager

**[Social Security Administration]{.underline}**

Bonnie Kind

Lois Sheppard

Stan Wegerski

**[Department of State]{.underline}**

Jacqueline May

Sally Zottnick

**[Department of the Treasury]{.underline}**

Richard Aaronson

Betty Harvey-Tauber

Peter Mackey

**[Executive Leadership Program Participants]{.underline}**

Beverly Sylvia Brooks, SSA

Irene Lucas, Department of State

Ruth Laughner, HHS, NIH

Shirl Wilson, HHS, HRSA

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

[^2]: See glossary at appendix B for definition of health care benefit
    program.

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

[^4]: As herein defined.

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

[^6]: As specified in the Claims Processing section.

[^7]: The claimant fills in all required fields.

[^8]: Or former spouse.

[^9]: Or other number as required by law, regulation or statute.

[^10]: Generating payments involves creating a payment file, which is
    forwarded to the Department of the Treasury, or funds are disbursed
    directly under delegated disbursing authority.

[^11]: See definition in Appendix B glossary

[^12]: As defined by the administering agency.

[^13]: The Federal Government also has authority to collect debts owed
    to non-federal entities.

[^14]: See definition in Appendix B Glossary.

[^15]: This does not necessarily equate to marital status.