![](media/image1.wmf)

**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
U.S.C. §65). Leadership and program guidance are provided by the five
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 Revenue System requirements document is one in a series issued by
the Joint Financial Management Improvement Program (JFMIP) in support of
agency operations. 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 Act
(FFMIA) of 1996 that strongly reaffirmed the need for the Federal
Government to provide financial systems to facilitate the effective
management of government programs and services and the proper
stewardship of public resources. In addition, it supports the Government
Performance and Results Act (GPRA) of 1993, which was enacted to improve
Federal program effectiveness and public accountability by promoting a
new focus on results, service, quality, and customer satisfaction.

The provisions in this document constitute Federal requirements for
revenue financial systems (see exclusions on page 11). Agencies must use
these functional requirements, in addition to agency-unique mission
requirements, in planning their financial system improvement projects.
As with the other systems requirements documents, agencies will have to
include their unique requirements, both technical and functional, with
the requirements in this document. It is the responsibility of each
agency to be knowledgeable of the legal requirements governing its
financial 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 that 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 their systems with the core financial
system. As stated in the document, the use of the term "Revenue System"
is not intended to imply that a single system component (module) must
independently perform all of the functions herein required of a Revenue
System. Rather agencies are encouraged to maximize data exchange and
share functionality among system components of an integrated financial
system.

The requirements have been prepared in consultation with the JFMIP
Steering Committee: the Office of Management and Budget (OMB), the
General Accounting Office (GAO), the Department of the Treasury, the
Office of Personnel Management (OPM) and the General Services
Administration (GSA). The project also involved several Federal program
agencies and was led by the U.S. Customs Service. We thank the agency
officials and others in the financial management communities for their
contributions to the document. We appreciate their invaluable
assistance. Their continuous support provides a document to enhance
financial management systems contributing to effective and efficient
operations governmentwide.

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

Karen Cleary Alderman\
Executive Director, JFMIP

**(LEFT BLANK INTENTIONALLY)**

**Table of Contents**

Foreword

List of Illustrations and Acronyms

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

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

Revenue System Overview..................................... 11

Revenue System Major Functions......................... 13

Relationship with Other Systems............ 15

Functional Requirements........................... 17

Input.................................................................................
19

Customer Order Options........................ 19

Remittance Options............................................... 21

Cashier
Function...........................................................................23

Proprietary and Budgetary
Accounting................................................24

Process....................................................................................\......27

Deposit Account Function
...............................................................27

Transaction Validation 29

Collection Process...................... 32

Revenue Recognition.............................. 34

Receivable Management Process............ 35

Bill Generation...................................... 36

Debt Management........................... 38

Revenue Estimation................................... 41

Output................................................\....... 43

Automated Reconciliation................................. 43

Performance Measurement..................\... 44

Reporting....................................\... 45

Internal and External Reporting.................. 45

Audit Trail....................................................... 48

On-Line Query Capability................................. 49

Ad-Hoc Query Capability..................... .50

Records Retention........................... 52

Interface........................................ 53

Security............................................ 55

Appendix A: Authoritative References............\.... .57

Appendix B: Glossary..................... 59

Appendix C: Contributors ........................... 70

**Illustrations**

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

2\. The Agency's Enterprise Architecture................. 8

3\. Agency Systems Architecture 10

4\. Path of Revenue.............. 15

5\. Revenue Transaction Flow: Input, Process, Output and reporting
................ 16

**Acronyms**

ACH Automated Clearing House

ALC Agency Location Code

A/R Accounts Receivable

CFO Chief Financial Officer

CFR Code of Federal Regulations

CIO Chief Information Officer

DCIA Debt Collection Improvement Act of 1996

EA Enterprise Architecture

EFT Electronic Funds Transfer

FACTS Federal Agencies' Centralized Trial-Balance System

FASAB Federal Accounting Standards Advisory Board

FFMIA Federal Financial Management Improvement Act of 1996

FISCAM Federal Information System Controls Audit Manual

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

GSA General Services Administration

IPAC Intra-governmental Payment and Collection System

IRS Department of Treasury Internal Revenue Service

IT Information Technology

JFMIP Joint Financial Management Improvement Program

NARA National Archives and Records Administration

NIST National Institute of Standards and Technology

OMB Office of Management and Budget

OPM Office of Personnel Management

RA Reimbursable Agreement

SEC Securities and Exchange Commission

SF Standard Form

SFFAS Statements of Federal Financial Accounting Standards

TAFS Treasury Appropriation Fund Symbol

TIN Taxpayer Identification Number

TFM Treasury Financial Manual

U.S.C. United States Code

USSGL United States Standard General Ledger

**Introduction**

The U.S. Federal Government is the world's largest and most complex
enterprise, involving the collection, management, and disposition of
billions of dollars. Financial and program officials face tremendous
challenges in managing Federal programs. Improvements in agency revenue
and financial systems are critical to government's efforts to obtain
complete and reliable information needed to manage this enterprise
efficiently. Increasingly, integrated systems are expected to
simultaneously support multiple users (program managers, financial
managers, and revenue managers) while systems and data are being shared
by agencies with common needs. Information supplied by these systems is
expected to become more timely, accurate, and consistent across the
government.

Representatives from revenue management functions governmentwide formed
the partnership that developed this document. Its purpose is to provide
a common set of revenue financial information requirements with which
each agency's integrated financial management system must be consistent.
These shared information requirements, frequently arising from Federal
statutes or regulations, constitute information available in one system
that is required for the performance of another system. This document
delineates those interface requirements between revenue and other
systems, that are critical to the performance of both functions. These
requirements are intended to be available to all users who rely on the
information to carry out their responsibilities. This document does not
address system requirements associated solely with the revenue process.

The Federal Government also has consistently recognized the importance
of having high-quality information management systems that contain
financial, revenue, and other information necessary to support
government operations. As a result, Congress enacted a variety of recent
statutes, including the Federal Financial Management Improvement Act
(FFMIA) of 1996 and the Information Technology Management Reform Act
(Clinger-Cohen Act) of 1996 to assure that high-quality information
management systems are developed to enable effective and efficient
decision making by program officials. The Office of Management and
Budget (OMB) also issued several relevant publications, including
Circular A-127, "Financial Management Systems" and Circular A-130,
"Management of Federal Information Resources," which outlines the
requirement that all electronic systems, including financial and Revenue
Systems, have a defined association to an agency's enterprise
architecture. The FFMIA and OMB Circular A-127 specifically provide the
vision for a single, integrated Federal financial management system. As
mentioned earlier, in support of that vision, JFMIP publishes
requirements documents for financial systems and the financial aspects
of mixed systems (such as revenue). *Revenue System Requirements* should
be considered in the context of all the other JFMIP requirements
documents, which form the basis for total governmentwide financial
system requirements.[^1]

The first three sections of this document ("Federal Financial Management
Framework," "Integrated Financial Management Systems," and "Agency
Financial Management Systems Architecture") set forth the framework for
the establishment and maintenance of a single integrated Federal
financial management system, provide information on integrating an
agency's financial management system, and identify the relationships of
various system types.

The next section, "Revenue System Overview," discusses the high-level
processes of the Revenue System, while "Revenue System Major Functions"
outlines the various functional categories of the requirements.
"Relationship with Other Systems" illustrates different configurations
of Revenue Systems and depicts the usual flow of financial events in a
Revenue System. These sections are followed by the "Functional
Requirements" comprised of 21 major functions and their requirements.

Appendix A lists the statutes, laws and regulations upon which these
requirements are based, followed by Appendix B, which is a glossary of
the revenue and financial terms used in this document. The last section
of this document, Appendix C, lists those individuals who contributed
their time, effort and vision to the development of this document.

**Federal Financial Management Framework**

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 revenue and financial managers and to
ensure the integrity of information for decision making and measuring
performance. This includes the following abilities:

-   Collect accurate, timely, complete, reliable, and consistent
    information.

-   Provide for adequate agency management reporting.

-   Support governmentwide and agencywide policy decision-making.

-   Support the preparation and execution of agency budgets.

-   Facilitate the preparation of financial statements and other
    financial reports in accordance with Federal accounting and
    reporting standards.

-   Provide information to central agencies for budgeting, analysis, and
    governmentwide reporting, including consolidated financial
    statements.

```{=html}
<!-- -->
```
-   Provide a complete audit trail to facilitate audits.

-   Provide adequate security controls to minimize the risk that data
    could be disclosed to unauthorized individuals, improperly used or
    manipulated, or destroyed due to unauthorized access or use.

As shown in Illustration 1, establishing uniform requirements is only
part of the process of improving financial management systems and
information. Improvements are also achieved through the selection,
development, and/or purchase of software 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 the OMB's governmentwide five-year
financial management plan, will be successful.

Well-defined and effective governmentwide functional requirements assist
agencies in developing strong systems and information by eliminating
duplicate work among agencies and providing a common framework so that
commercial vendors can more economically provide systems software.
Development of governmentwide functional requirements is a critical
effort that will affect internally developed systems and mature manual
systems, as well as 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 interchange, to support program delivery, safeguard information and
agency resources, and manage taxpayer dollars.

Each agency should supplement the governmentwide standard requirements,
described in this document, with its unique agency requirements to
provide a uniform basis for the standardization of financial management
systems as required by the Chief Financial Officers (CFO) Act of 1990,
FFMIA, and other statutes. Furthermore, each agency's requirements for
its financial management systems should be based upon, and integrated
with, its efforts to develop and implement an enterprise architecture as
called for in Federal legislation and clarified in OMB Circular A-130.
However, standard core requirements must be maintained.

![](media/image3.wmf)

Illustration 1

**Illustration 1**

It is critical that financial management systems support the agency's
mission and programs, including changes to them, and that financial
management system's plans are incorporated into the agency's plans for
information technology (IT) infrastructure and information systems as a
whole. Further, systems design efforts should include an analysis of how
systems 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.

Aligning technology with business needs is an important aspect of
Enterprise Architecture (EA). Agencies are required by the Clinger-Cohen
Act to provide this function within their organization. The EA function
provides for analysis of business needs and monitoring business
direction. Knowledge of this information helps to design better
technology solutions and allows the organization to be better positioned
to respond to internal and external change factors. As such, business
programs and technology investments are linked in support of the
agency's mission. The EA function monitors emerging technologies and
charts a course for the use of technology in the agency. This is very
useful for planning any new systems development, as the system
architecture must be compatible with what is in existence or "targeted"
for future implementation. In this manner, the EA function contributes
to the use of standards for consistent operations, as well as
interoperability.

It cannot be too strongly emphasized that the general success of these
enterprise application initiatives may be dependent not so much on
standard products, but on levels of interoperability that must be
achieved by Federal agencies. Additionally, a Federal-level model of
information that has standard definitions could be critical for
effective integration and sharing of information. The data that moves
upward should have definitions or descriptions of the data implemented
governmentwide. Without the use of commonly defined data,
inconsistencies may result in inaccurate reporting.

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

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

The financial management system's policy, described in OMB Circular
A-127, requires that each agency establish and maintain a single,
integrated financial management system. Without a single, integrated
financial management system to ensure timely and accurate financial
data, poor policy decisions may occur. Managers are less likely to be
able to report accurately to the President, the Congress, and the public
on government operations in a timely manner. Scarce resources are more
likely to be directed toward the collection of information rather than
to delivery of the intended programs. Further, modifications to
financial management systems are necessary to keep pace with rapidly
changing technology and user requirements that cannot be coordinated and
managed properly.

Having a single, *integrated* financial management system does not
necessarily mean having only one software application within each agency
covering all financial management system's needs. Rather, a single,
integrated financial management system is a *unified* set of financial
systems and the financial portions of mixed systems (e.g., revenue)
encompassing the software, hardware, personnel, processes (manual and
automated), procedures, controls, and data necessary to carry out
financial management functions, manage the financial operations of the
agency, and report on the agency's financial status to central agencies,
Congress, and the public.

While the topic of these guidelines is uniquely devoted to interfaces
between financial and Revenue Systems, it is imperative to understand
that successful implementation of an integrated financial management
system is wholly dependent upon an articulated system (or enterprise)
architecture that defines data, application, and technical
infrastructure components. Efforts to develop and launch agency-wide
integrated financial management systems demand a thorough understanding
of the mission functions, information requirements, and overall business
processes that are documented as part of the agency's EA.

> *Integrated* means that the user is able to have one view into systems
> such that, at whatever level the individual is using the system, he or
> she can obtain the information needed efficiently and effectively
> through electronic means. It does not necessarily mean that all
> information is physically located in the same database. However, as
> data warehousing becomes more of a standard, the data may indeed be
> stored centrally and accessed remotely. These structured design
> aspects of how and where the data are located are decisions made in
> conjunction with the to-be view, data, applications and technology
> sections of an agency's EA.
>
> *Unified* means that systems are planned and managed together,
> operated in an integrated fashion, and linked together electronically
> in an efficient and effective manner to provide agencywide financial
> system support necessary to carry out the agency's mission and support
> the agency's financial management needs. It also means that this
> unification is resultant from having adhered to the approved
> architectural plans.

Interfaces, where one system feeds data to another system following
normal business/transaction cycles, such as depreciation charges
recorded in general ledger control accounts at specific time intervals,
may be acceptable as long as the supporting detail is maintained and
accessible to managers. In such cases, interface linkages must be
electronic unless the number of transactions is so small that it is not
cost-beneficial to automate the interface. Reconciliations between
systems, where interface linkages are appropriate, must be performed to
ensure data accuracy. Similarly, such reconciliations should be
automated when cost beneficial.

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

-   The scope of the business functions to be supported (processes)

-   How data quality will be ensured (data stewardship)

-   Data needed to support management decisions (information)

-   How systems fit together to support the functions (systems
    architecture)

-   Safeguards needed to ensure the integrity of operations and data
    (information assurance).

All of these pieces must be brought together in a model, or integrated
framework or architecture, such as the one shown in Illustration 2.
These pieces must work together to form an efficient integrated
information system. Federal agencies are required to adopt an
enterprise-level system architecture to provide for the most efficient
and effective utilization of technology in support of agency strategic
and tactical goals. Modular design considerations are necessary to
minimize the impact of future changes to information needs. Preliminary
data analysis should drive the structure of system modules to isolate
changes within a subject area. The following discusses agency financial
management systems architecture and relates that discussion to system
integration at the enterprise level as called for in Federal legislation
and OMB guidance.

**The Agency's Enterprise Architecture**

![](media/image4.wmf){width="4.8694444444444445in" height="3.575in"}

**Illustration 2**

Agency Financial Management Systems Architecture

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

Agency financial management systems fall into three categories:

(1) Core financial systems

(2) Other financial and mixed systems, including Revenue Systems

(3) 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. Moreover, systems in all three of these categories likely
have dependencies upon and some data exchange relation to other
information management systems used by the agency, such as project
management systems or performance tracking systems. Summary data
transfers must be provided from a wide range of 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 exchange and
management, and organizational responsibility, is a decision best left
to the individual agency, which can determine the optimal manner in
which to support its mission. As financial management is but one aspect
of back office support of each Federal agency's overall mission, it is
appropriate to endeavor to develop and operate core financial and other
related information systems in concert with one another, enabling
consolidation of common requirements and electronic interchanges. In
keeping with guidance provided by the Federal Chief Information
Officers' (CIO) Council, agencies are recommended to steer toward use of
open industry-wide supported standards and nonproprietary interfaces in
their architectural designs. The physical design of systems, however,
should consider the agency's organizational philosophy, the technical
capabilities available, and the most appropriate manner in which to
achieve the necessary single integrated financial management system for
the agency.

The systems architecture shown in Illustration 3 provides a finance
system-centric logical perspective identifying the relationships of
various financial system types. Although this does not necessarily
represent the physical design of the system, it does identify agency
system types generally needed to support program delivery/financing and
financial event processing for effective and efficient program
execution. Also, there is a requirement for an agency's financial
management systems of record, especially those supporting central agency
reporting, to use the U.S. Standard General Ledger (USSGL) Chart of
Accounts. The Revenue System box highlighted in Illustration 3 signifies
the financial interface requirements between an agency's revenue and
core financial systems---not those associated with the entire revenue
process.

An agency's financial management system architecture is an important
subset of the agency's overall enterprise and IT architecture.
Maintaining an agencywide view of systems' development and use is
especially critical to discussions involving financial systems'
deployment, as an enterprise architecture's primary purpose is to
support IT capital investment and help define a direction for future
technology acquisitions. Thus, both financial system reporting and
expenditure decisions, as well as procurement actions, are necessarily
core functions addressed within the business layer of the EA. Each
agency's core financial systems grow from a set of articulated
requirements that are, by definition, relevant to the entire federal
enterprise. The degree of integration of all of an agency's systems
should be reflected in the design and operational configuration
decisions pertaining to its financial system architecture.

**Agency Systems Architecture**

![](media/image5.wmf)

**Illustration 3**

**Revenue System Overview**

This section provides an overview of a Revenue System, the Revenue
System Major Functions and Relationship with Other Systems. Over 40
distinct revenue systems exist in over a dozen federal agencies. While
some agencies collect relatively small amounts of revenue, others
collect large quantities and primarily operate on the revenue their
programs generate. In Statements of Federal Financial Accounting
Standards (SFFAS) #7, paragraph 2, the Federal Accounting Standards
Advisory Board (FASAB) defines revenues as:

> **"An inflow of resources that the government demands, earns, or
> receives by donations"**

The scope and coverage of these requirements applies to revenue systems
with the following exceptions. The Internal Revenue Service (IRS) is a
one of a kind federal agency and its income tax system contains unique
functionality. This document covers Revenue Systems and excludes systems
used by the IRS to administer and collect revenue. Revenue from
insurance,[^2] benefits (i.e., Medicare and Social Security),
revaluation of property, plant and equipment and inventory are addressed
in other financial systems requirements.

Revenue can be either exchange revenue or non-exchange revenue. Exchange
revenue and gains are inflows of resources to a government entity that
the entity has earned. They arise from exchange transactions, which
occur when each party to the transaction sacrifices value and receives
value in return. That is, exchange revenue arises when a government
entity provides something of value to the public or another government
entity at a price.[^3]

**[Examples of Exchange Revenues:]{.underline}**

-   Sale of goods and services;

-   Sale of goods and services in undercover operations;

-   User charges, regulatory user fees (i.e., patent, copyright,
    immigration and consular fees);

-   Interest from loans, dividends, and rents (except for mineral
    rights);

-   Rents, royalties, and bonuses on Outer Continental Shelf and other
    petroleum and mineral rights;

-   Proceeds from auctions;

-   Interest on delinquent taxes and other receivables that arise as the
    result of custodial operations;

-   Premiums for insurance (outside of medical insurance, pension
    benefit guarantees and life insurance);

-   Premiums of one time fee;

-   Reimbursement for collecting revenue (i.e., ATF or Customs collects
    duties on goods imported from Puerto Rico and the Virgin Islands);

-   Reimbursement for cleanup costs;

-   Sale of government assets: other than property, plant and equipment;
    seized, forfeited and foreclosed property; and other inventory; or

-   Reimbursement for services.

Non-exchange revenue is inflows of resources to the government that the
government demands or that it receives by donations.[^4]

**[Examples of Non-exchange Revenues:]{.underline}**

-   Non-Income based taxes: excise taxes, estate and gift taxes;

-   Customs service fees (duties, merchandise processing fee, and user
    fees);

-   Donations (except types of property, plant, and equipment that are
    expensed);

-   Imposition of statutory fees;

-   Fines and penalties; and

-   Penalties due to delinquent taxes in connection with custodial
    activity.

**[Mandatory versus Value-added Requirements]{.underline}**

Revenue 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 in operation and new systems planned or under development.
>
> **Value-added** -- Value-added requirements describe features or
> characteristics and may consist of any combination of the following:
> (1) using state of the art technology, (2) employing the preferred or
> best business practices, and/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 Revenue System requirements are
indicated by the word "must"; value-added system requirements are
identified by use of the word "should". Any system used to administer
future Federal Revenue programs that may be established subsequent to
the issuance of this document will also be subject to these system
requirements. Requirement nomenclature uses the initials of the
functional category followed by a number for ease of reference (i.e.,
the first requirement in the Transaction Validation section is TV-1).

**Revenue System Major Functions**

The major functions typically performed by a Revenue 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 Revenue System tracks the life of revenue from initial order,
processing and output to maintain a complete history of financial
activity relating to those receipts. The Federal Revenue System
primarily consists of 21 major functions and the data processed by those
functions. These functions are:

1.  **Customer Order Options**

2.  **Remittance Options**

3.  **Cashier Function**

4.  **Proprietary Accounting and Budgetary Accounting**

5.  **Deposit Account Function**

6.  **Transaction Validation**

7.  **Collection Process**

8.  **Revenue Recognition**

9.  **Receivable Management Process**

10. **Bill Generation**

11. **Debt Management**

12. **Revenue Estimation**

13. **Automated Reconciliation**

14. **Performance Measurement**

15. **Internal and External Reporting**

16. **Audit Trail**

17. **On-Line Query Capability**

18. **Ad-Hoc Query Capability**

19. **Records Retention**

20. **Interface**

21. **Security**

Each of the listed functions is addressed in detail in the Functional
Requirements section. It is important to note that certain functions,
such as receivables management, may be performed completely or partially
by other systems that are not solely dedicated to supporting Revenue
programs (e.g., core financial 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.

**(LEFT BLANK INTENTIONALLY)**

**Relationship with Other Systems**

Illustration 4 depicts the interface of the initial transaction through
the Revenue System and to the Core Financial System. There are various
ways a Revenue System may be designed and configured. In this
illustration, summary data would be fed into the Core Financial System
after the initial transaction is posted to the Revenue System, and
various components of the Core Financial System would be impacted by a
single collection transaction. The initial transaction can be in the
form of an order for a product or service, the bestowing of a special
right or privilege, or the administration of a fine or penalty.

**Path of Revenue**

Initial Transaction

> Revenue System

![](media/image6.wmf) ![](media/image7.wmf)

**Illustration 4**

In order to visualize the "usual" flow of exchange and non-exchange
financial events that may result in earned revenue, Illustration 5 below
delineates transaction flow via Input, Process, Output, and Reporting
according to functional examples detailed further in this document that
carry out these processes:

**Revenue Transaction Flow: Input, Process, Output, and Reporting**

#  *INPUT PROCESS OUTPUT REPORTING*

# 

# *Customer Order Options Deposit Account Function Automated Reconciliation Audit Trail*

*Remittance Options Transaction Validation Performance Measurement
Record Retention*

# *Cashier Function Debt Management* 

# 

# [Exchange Revenue]{.underline} 

Sale of Goods Delivery of Goods Budgetary Impact (e.g., no- year,

Place Order Sale of Services Provide Services offsetting, return to
Treasury)

(e.g., mail, electronic, walk-in, Sale of Property Change Ownership

phone/fax) Sale of Rights Forecasting -- Revenue Estimation

Invoice A/R, Reduce Advance,

Cash Sale

Accrue Revenue

Cost of Goods Sold

Processing Cost

Reporting

> Internal/ External

Custodial Exchange Revenue (pass throughs)

Use Report Accrue Custodial Revenue Distribute Revenue

(e.g., mineral extraction) Budgetary Impact

Invoice A/R

# [Non-Exchange Revenue]{.underline}

Assess Penalties, Fines, etc. Accrue Revenue

Cost of Enforcement Operations

Budgetary Impact

Invoice A/R

Custodial Non-Exchange Revenue (pass throughs)

Use Report Accrue Custodial Revenue Distribute Revenue

(e.g., Customs Fees) Budgetary Impact

Invoice A/R

**Illustration 5**

Note: Revenue generating events generally require close relationships
with the core system, receivable management, asset

management, inventory, cost accounting, and budget execution functions.

**Functional Requirements**

For purposes of describing Federal Revenue System Requirements, this
section outlining functional system requirements has been segmented into
four sub-parts to reflect the sequence of activities to process
revenues. The sub-parts are **Input, Process,** **Output** and
**Reporting**. Security and Interface requirements transcend this
sequence of activities and are placed at the end of the functional
requirements section.

Value-added requirements consistent with the direction established by
the President's Management Agenda, particularly in the area of creating
a citizen based e-Government, are included in various sections. A
Revenue System, in efforts to simplify the delivery of services to
citizens, can: "make it easy for citizens to obtain service and interact
with the Federal Government; improve government efficiency and
effectiveness; and improve government's responsiveness to citizens."[^5]
By enhancing e-Government channels between the customer and agency,
Revenue Systems become more citizen centered and more efficient.

Significant governmentwide statutes, regulations, and guidance documents
address the proper handling of Federal revenue/collections programs and
the attendant recording of financial transactions in an agency's USSGL
within the Core Accounting System. In addition to the "generic"
governmentwide authoritative references, there are also many specific
statutory authorities and/or regulations that relate to very specific
revenue programs. It is critically important to identify all of the
related authoritative sources (generic and specific) for a particular
program when considering a system that will be expected to properly
recognize and record revenues and related accounting events. For ease of
reference, Appendix A summarizes significant governmentwide
authoritative references that have been consulted in the preparation of
this document.

**(LEFT BLANK INTENTIONALLY)**

**Input**

Input into a Revenue System begins with a financial event that will
result in the recognition of exchange revenue or non-exchange revenue,
and includes variations for custodial exchange revenue or custodial
non-exchange revenue. A financial event can be in the form of a
financial remittance (voluntary or on demand), customer order,
reimbursable service agreement, fine/penalty, or similar action that
will cause an inflow of cash. Please note however, that not all
collection actions will result in the recognition of revenue; for
example, refunds of overpayments, non-expenditure transfers, returns of
unused cash advances, advance payments received by the provider agency
for a future service, or a payment for an outstanding receivable or a
loan are not revenue. These transactions could be recorded directly in
the core financial or other systems. The revenue system must be able to
record collections representing revenue transactions, refund
overpayments, and provide advances for reimbursable work. This sub-part
identifies requirements to support:

a)  Customer order options,

b)  Remittance options,

c)  Cashier function, and

d)  Fundamental proprietary and budgetary accounting USSGL postings.

**Customer Order Options**

The phrase "customer order" in this context signifies an order received
and accepted by the performing activity from a customer. It is written
documentation that certain goods and services will be provided to the
tenderer of the order for a specified amount.[^6] Customer orders are
created in exchange revenue transactions, not in non-exchange revenue
transactions (when a fee is imposed). The following "customer order" or
"customer request" options cover the full spectrum of ordering
possibilities; these are:

> a\) In person (Walk-Up),

b\) Telephone or Fax,

c\) Electronic, and

d\) Mail.

### 

[Mandatory Requirements]{.underline}

To support Customer Order Options, the Revenue System
**[must]{.underline}** provide the capability to:

-   Process and track orders to determine order status and allow for
    detailed (by customer) and batched information required in RO-1
    (see p. 21). In a non-exchange revenue transaction, collect the same
    data a customer order provides in an exchange revenue transaction
    (see examples of non-exchange revenues). Customer order data is to
    be retained to capture an order's entire history for handling
    inquiries and providing an audit trail. OMB's Business Rules for
    Intragovernmental Transactions, (M-03-01), requirements must also be
    supported (i.e., providing DUNS numbers, order numbers, standard
    data elements for billing records, and others). Also, customer order
    data is to be filed in accordance with National Archives and Records
    Administration (NARA) regulations for the required time frames based
    on the type of record and activity. (CO-1)

-   To ensure that order fulfillment and revenue can be associated with
    a specific intragovernmental order, the seller must capture the
    buyer's intragovernmental order number in the seller's order
    fulfillment or revenue system to associate the buyer's order number
    with any agreement or control number assigned by the seller's
    system. (CO-2)

[Value-added Requirements]{.underline}

To support Customer Order Options, the Revenue System
**[should]{.underline}** provide the capability to:

-   Receive customer orders via Internet. (CO-3)

-   Provide an integrated customer management relationship to establish
    a single view of account information. (CO-4)

**Remittance Options**

Remittance includes the following remittance options:

> a\) Cash, check, and money order -- all of which can be in foreign
> currency;

b\) Electronic, including Automated Clearing House (ACH), Electronic
Funds Transfer (EFT),

> FedWire, Intra-governmental Payment and Collection System (IPAC),
> Pay.gov, Credit Card,
>
> and Lockbox;
>
> c\) Prepayment/advances (i.e., funds advanced by customers in
> requesting an
>
> order/service \-- advance balances are reduced for goods upon delivery
> receipt and inspection,
>
> and for services based upon deliverables or on accrual estimates/cost
> reports); and

d\) "On account", i.e., an account receivable is established and an
invoice is generated.

#### [Mandatory Requirements]{.underline}

#### To support revenue tracking and various methods of payment of the Remittance Options function, the Revenue System [must]{.underline} provide the capability to: 

-   Maintain a customer record at the individual document level
    capturing:

> \- Unique Order Sequence ID;
>
> \- Agency Location Code (ALC) for Deposit transactions for Federal
> customers only;
>
> \- ALC at the transaction level for Federal customers only;
>
> \- Treasury Appropriation Fund Symbol (TAFS);
>
> \- Data elements required in OMB "Business Rules for Intragovernmental
> Transactions",
>
> (M-03-01);
>
> \- Customer name;
>
> \- Customer ID number;
>
> \- Taxpayer Identification Number (TIN);
>
> \- Customer addresses, i.e., physical, mailing, email and billing;
>
> \- Contact name;
>
> \- Contact telephone number;
>
> \- Federal vs. Non-Federal indicator;
>
> \- Six-digit Trading Partner code;
>
> \- IRS 1099-C indicator (For non-Federal Accounts Receivable needed in
> case of debt
>
> write-off);
>
> \- Comment field;
>
> \- Date of last update;
>
> \- User ID of last update;
>
> \- Order Type Indicator (i.e., walk up; phone; fax; electronic; mail);
>
> \- Method of Payment (cash, check, money order, electronic payment,
> charge or credit
>
> card, debit card, advance reduction, and on account);
>
> \- Amount received;
>
> \- Date of each payment received;
>
> \- Unfilled Customer Orders (for use when funds are received with a
> delay in filling the
>
> customer's order);
>
> \- custodial or non-custodial;
>
> \- Exchange or non-exchange; and
>
> \- Date order filled. (RO-1)

[Value-added Requirements]{.underline}

To support Remittance Options, the Revenue System
**[should]{.underline}** provide the capability to:

-   Alert customers holding outstanding or overdue accounts and alert
    internal users. (RO-2)

-   Create and maintain a "Personalized Page" that allows users to
    access and track program specific information including information
    on payment options, amounts due, payment history and laws mandating
    reason for and use of payment. (RO-3)

**Cashier Function**

A collection process may require one or more "cashier" functions.
Cashiers are responsible for safeguarding cash and negotiable
instruments while in their custody and expeditiously depositing cash and
negotiable instruments in a financial institution sanctioned by the U.S.
Treasury. Sound internal controls including separation of duties between
personnel are paramount in cash handling and cashier operations for
posting cash transactions. Detailed deposit requirements for cash,
checks, money orders, ACH receipts, credit cards and so forth are
prescribed by the U.S. Treasury in the *Treasury Financial Manual* (TFM)
Volume 1 Parts 5 & 6. The TFM is available on-line, the website is:
**www.fms.treas.gov/tfm/index.html.** Typical steps of a cashier
function include:

a\) Batching the collections by payment type;

b\) Preparing a deposit slip, i.e., Standard Form (SF) 215 or equivalent
specifying the ALC;

c\) Directing the accompanying "customer orders" or "remittance slips"
to their program office for

fulfillment;

d\) Entering accounting and order tracking system data; and

> e\) Performing daily reconciliation with the U.S. Treasury via the
> Ca\$hLink System (to be replaced
>
> by Ca\$hLink II) is essential to ensure that funds are deposited
> promptly in the appropriate
>
> financial institution.

#### [Mandatory Requirements]{.underline}

To support the Cashier Function, the Revenue System
**[must]{.underline}** provide the capability to:

-   Identify the TAFS for which the deposit is being made. (CF-1)

-   Recognize and classify collections in the proper budgetary
    categories. Record and control all prescribed types of budgetary
    authorities relative to earned and unearned revenue or cash
    collections (both cash and accrual basis), including spending
    authority from offsetting collections. (CF-2)

-   Recognize and record advance payments received. (CF-3)

-   Recognize and record cash donations as non-exchange revenue. (CF-4)

-   Perform transaction cross-referencing in which a user can perform a
    query to locate the details of associated transactions in the
    processing \"chain\" (e.g., querying on a receivable would provide
    any associated cash receipts). (CF-5)

-   Track funds at various levels based on required elements of the
    accounting classification and project/program accounting structure.
    (CF-6)

    [Value-added Requirements]{.underline}

    There are no value-added requirements for this function.

**Proprietary and Budgetary Accounting**

Generally, accrual accounting concepts are used, i.e., revenue is to be
recognized (earned) when service, product, or other revenue activity is
completely or constructively rendered. However, some activities may be
on a cash basis; i.e., when cash is received rather than when the
product or service is delivered. This requirement includes the posting
of debits and credits to the appropriate USSGL accounts to support
accrual accounting and financial reporting showing actual financial
position and results of operations by accounting for assets,
liabilities, net position, revenues and expenses. A revenue generating
financial event could occur on a(n):

> a\) Immediate basis, when a "face-to-face" interaction occurs, either
> for an exchange (e.g.,
>
> paying for the privilege to visit a National Park) or non-exchange
> transaction (e.g., donation);
>
> b\) Shipment basis, when an item from inventory shipped (e.g.,
> purchase of office supplies
>
> from the General Services Administration, proof coins from the U.S.
> Mint);
>
> c\) Periodic basis, when services provided in whole or part over time
> (e.g., performing payroll
>
> services on an on-going cross-service basis);
>
> d\) Actual Use basis, when extracting a resource from government
> lands, using airspace or
>
> shorelines (e.g., timber, microwave spectrum, mineral extractions,
> airplane flyovers); or
>
> e\) Enforcement action, when administering a fine, fee, assessment,
> collection action or penalty.

Budget execution consists of processes needed to ensure that the
agency's funds control systems are fully supported by its accounting
systems. It also consists of processes needed to track an agency's
budget authority and manage prior-year funds in the current fiscal year.
Allotments are designed so that responsibility for budget control is
placed at the lowest practical organizational level. Since
revenues/collections can have an impact on budgetary authority, the
revenue system must track and pass through to the core financial system
data from revenues and collections and properly recognize the budgetary
impact for Reimbursable Activities, Revolving Funds, and Offsetting and
Non-Offsetting Collections. This process records an agency's budgetary
resources and supports the establishment of budgetary limitations at
each of the levels required within the agency (e.g., apportionments,
allotments, and allocations). The higher levels, such as appropriation,
apportionment and allotment have the weight of legal authority behind
the limitations. Lower levels of control are generally used for internal
management purposes.

#### [Mandatory Requirements]{.underline}

To support Proprietary and Budgetary Accounting functions of the USSGL,
the Revenue System **[must]{.underline}** provide the capability to:

-   Allow internal users to indicate whether the collecting entity
    retains the revenue or transfers it to others.

> \- Exchange revenue must be recognized within the same reporting
> period the entity
>
> provides goods or services to the public or another government entity
> (accrual
>
> accounting).
>
> \- For services, revenue should be recognized when the services are
> performed.
>
> \- For specific goods made to order under a contract or services
> produced under a
>
> contract, revenue should be recognized in proportion to estimated
> total cost when
>
> goods and services are acquired to fulfill the contract.
>
> \- For goods kept in inventory, revenue should be recognized when the
> goods are
>
> dropped from inventory (shipped) to the customer. (BPA-1)

-   Record the actual price that is received or receivable under the
    established pricing arrangements. A receivable should be recorded if
    cash has not been received and an appropriate allowance should be
    established. Unearned revenue should be recorded if amounts have
    been received, but goods or services have not yet been provided.
    (BPA-2)

-   Match revenue with costs for determining the net cost of operations.
    The components of net cost should also include the gross cost of
    providing services that did not earn exchange revenue. If the
    collecting entity transfers the exchange revenue it should account
    for that revenue as a custodial activity. (BPA-3)

```{=html}
<!-- -->
```
-   Properly classify revenue and inflows to facilitate preparing
    financial statements that meet the Federal financial reporting
    objectives. In order to measure performance, exchange revenue must
    be matched with costs whereas non-exchange revenue is not matched
    with costs because they are not earned in the operations process.
    (BPA-4)

```{=html}
<!-- -->
```
-   Recognize revenue when the entity establishes a specifically
    identifiable, legally enforceable claim to cash or other assets, to
    the extent that the collection is probable and reasonably
    measurable. (BPA-5)

-   Taxes and duties should also be measured on the cash basis, and the
    cash basis amount(s) should be shown in conjunction with the accrual
    amounts recognized. The source and disposition of revenue from
    taxes, duties, and related fines, penalties, and interest should be
    measured by the collecting entities in a manner that enables
    reporting of (1) cash collections, refunds, and the "accrual
    adjustment" necessary to determine the total revenue and (2) cash or
    cash equivalents transferred to each of the recipient entities and
    the revenue amounts to be recognized by each of them. (BPA-6)

-   Provide extensive disclosures for estimating future cash flows and
    for overseeing their custodial responsibilities. For proper
    disclosures for non-exchange revenue, the following must be
    disclosed:

> \- Basis of Accounting;
>
> \- Factors affecting collectibility (e.g., non-voluntary collections
> are more difficult than
>
> donated ones);
>
> \- Distinction of the categories of accounts receivable (accrual,
> cash, modified cash) and
>
> the amounts involved;
>
> \- Include self-assessments, or post-audits, by customer (or
> importers), penalties, interest,
>
> unearned revenues, refunds, refund offsets and drawbacks, abatements,
> accounts
>
> receivable written off during the reporting period as uncollectible,
> and provisions made
>
> to the allowance for uncollectible amounts;
>
> \- Cumulative cash collections and refunds by year and type. (BPA-7)

-   Account for (1) trust funds legally entitled to excise taxes
    collected, (2) trust funds legally entitled to receive Social
    Security taxes accrued, (3) collection entities entitled to retain
    revenue, and (4) the general fund, the amount collected should be
    accounted for as a custodial activity by the collecting entity.
    (BPA-8)

-   Account for fines and penalties -- the point in time when a claim to
    resources arises will depend on the nature of the fine and the
    associated legal and administrative processes. An allowance for
    uncollectible accounts should be recognized as a revenue adjustment
    and determined in accordance with other standards. (BPA-9)

-   Recognize revenue arising from donations for those inflows of
    resources that meet recognition criteria for assets and estimate the
    fair value of the contribution. (BPA-10)

```{=html}
<!-- -->
```
-   Record the total amount of billing offset against advance payments
    received and automatically liquidate the advance amount recorded in
    the core system based on billings generated from the Revenue System
    either partially or fully, to interface with the core and allow the
    recording of refunds of amounts advanced, if necessary. (BPA-11)

-   Provide control features that ensure that the amounts reflected in
    the funds control structure agree with the related general ledger
    account balances at the end of each update cycle. (BPA-12)

-   Establish interface with core system for updates of advances from
    accounts in the core system, as well as related billings and
    accounts receivable data. The Revenue System must verify that the
    billing amount to the customer does not exceed the amount authorized
    by the reimbursable agreement (RA) when applicable prior to
    generating bills and recognizing revenue. (BPA-13)

-   Record and maintain RAs (e.g., inter-agency agreements, memorandums
    of understanding) so that monthly, quarterly, and fiscal
    year-to-date as well as inception-to-date information can be
    presented. (BPA-14)

[Value-added Requirements]{.underline}

There are no value-added requirements for this function.

**Process**

After the financial data from revenue is entered, the Revenue System
performs a variety of tasks (i.e., processing of orders, administration
of a fine or penalty). In order to perform these functions, the system
must be able to verify whether orders can be filled, how the service is
delivered, how and when it is recognized, check to see if the payment
amount is correct, if there is a refund due to the customer, and produce
the necessary bills recording the transaction history. This section
deals with functions from the end of input to the beginning of output of
a Revenue System.

**Deposit Account Function**

The following requirements identify activities used to provide support
in maintaining deposit accounts. Deposit accounts can also be funds
deposited outside of Treasury. All deposit funds are deposit accounts,
but not all deposit accounts are deposit funds.

Advances are amounts of money prepaid to a Federal Government account
(fund) for the later receipt of goods, services, or other assets, or as
matching funds (OMB Circular A-11). When an advance is required, the
budgetary resource provided by the order is denominated by the cash
accompanying the order. The advance, per se, is not available for
obligation. If both the order and the advance were to be available for
obligation, budgetary resources would be double-counted.

Any advance funds that cannot be identified upon receipt are to be
deposited as follows (until further information is obtained):

If the advance is from: Then deposit the advance in:

\- A non-federal source - Deposit fund account (6500)

\- A federal source - An intragovernmental clearing account (F3885)

[Mandatory Requirements]{.underline}

To support the Deposit Account Function, the Revenue System
**[must]{.underline}** provide the capability to:

-   Create a new deposit account (escrow account) record with data
    element fields required in RO-1 (p. 21) to record account history
    and activity. (DAS-1)

-   Provide access to update deposit account records for both active and
    inactive deposit accounts. Modifications to any deposit account data
    will be date effective. (DAS-2)

-   Close a deposit account. The system will record the disposition of
    any remaining balance. Closed deposit account records will be
    archived. (DAS-3)

-   Process remittances to and charges against a deposit account.
    Remittances will be processed in the same record format as a
    payment. (DAS-4)

-   Provide monthly statements of transaction activity in paper and/or
    electronic form. (DAS-5)

-   Notify customers (if specified) if their deposit account balance
    drops below a certain dollar amount. (DAS-6)

```{=html}
<!-- -->
```
-   Validate accounts by not accepting a transaction for a charge
    against a deposit account until the system has determined that the
    account number is valid, not delinquent, and has a sufficient
    balance to cover the charge. If the balance is not sufficient to
    cover the charge, the system must send notification to the customer
    and a notice permitting/delaying service to be rendered. Any deposit
    account transaction that causes an overdrawn balance without
    notification shall be rejected by the system. (DAS-7)

-   Apply penalty charges for deposit account balances that fall below a
    predetermined level at any point in time or at a predetermined
    point, such as at the end of a month. The predetermined level and
    assessment date may vary by deposit account type. These penalty
    charges shall be automatically assigned by the system. (DAS-8)

# [Value-added Requirements]{.underline}

There are no value-added requirements for this function.

**Transaction Validation**

OMB Circular No. A-127 requires common processes to be used for
processing similar kinds of transactions throughout an integrated
financial management system to enable transactions to be reported in a
consistent manner. The Revenue System must ensure that all transactions
are handled consistently, regardless of their point of origin. It also
must ensure that all 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. The following set of
requirements identifies functions to accomplish these objectives.

#### [Mandatory Requirements]{.underline}

To support the Transaction Validation activity, the Revenue System
**[must]{.underline}** provide the capability to:

-   Comply with USSGL posting rules and update appropriate documents and
    any related tables, when accounting transactions are recorded in a
    subsidiary ledger within the Revenue System. Use standard
    transactions when recording accounting events. (TV-1)

-   Interface with the core financial system to record transactions
    consistent with USSGL posting rules. (TV-2)

-   Allow users to define and maintain standard rules that control
    subsidiary ledger account postings for all accounting events when
    accounting transactions are recorded in a subsidiary ledger within
    the Revenue System. The process of defining posting rules can be
    accomplished in a variety of ways, including (but not limited to)
    using: transaction codes, screen "templates," derivation rules, and
    others. (TV-3)

-   Enable users to selectively require, omit, or set a default value
    for individual accounting classification elements. (TV-4)

-   Allow users to define and process system-generated transactions,
    such as automated accruals (e.g., interest accrual entries),
    pre-closing and closing entries, and transactions that generate
    other transactions in those cases where a single transaction is not
    sufficient. (TV-5)

-   Liquidate (automatically), partially or in full, the balance of open
    documents by line item. This capability will be used in the
    liquidation of various documents such as receivables and advances,
    upon the processing of subsequent related transactions (e.g.,
    liquidate a receivable upon entry of the corresponding collection).
    (TV-6)

-   Control the correction and reprocessing of all erroneous
    transactions gathered through interfaces through the use of
    error/suspense files. Erroneous transactions must be maintained
    until corrected and posted at the specific request of a user. (TV-7)

-   Provide immediate, on-line notification to the user of erroneous
    transactions obtained through direct data entry. Advise reason for
    error and provide the ability to enter corrections on-line. (TV-8)

-   Provide controls to prevent the creation of initial duplicate
    transactions. For example, prevent the use of the same unique
    transaction identification number (e.g., document number). (TV-9)

-   Provide a warning message when the user attempts to input a check
    number that has already been recorded for the related debtor.
    (TV-10)

-   Validate the fields for all accounting classification elements
    required to process the transaction prior to posting (e.g., fields
    pertaining to TAS/TAFS, revenue source, invoice number, debtor or
    customer code and organization). (TV-11)

-   Enter, edit, and store transactions in the current accounting period
    for automatic processing in a future accounting period for one-time
    events and/or monthly recurring entries. (TV-12)

-   Capture the six-digit trading partner code (as specified by
    Treasury) when processing all transactions that directly involve
    another Federal entity (i.e., both parties to a transaction are
    Federal entities). (TV-13)

-   Capture transaction dates (effective date of the transaction) and
    posting dates (date transaction forwarded to core financial system
    or posted to the general ledger). (TV-14)

-   Determine (automatically) the posting date from the system date for
    all transactions. Automatically associate a default accounting
    period for each transaction, but allow authorized user to override.
    (TV-15)

-   Reverse (automatically with prior discretion of user) entries by the
    following parameters: transaction or document type, date range,
    schedule numbers, transaction identification number (i.e., document
    number) range, and trading partner. (TV-16)

-   Permit posting to the current and prior months concurrently until
    the prior month closing is complete while interacting with the core
    financial system within that fiscal year. (TV-17)

-   Post to the current fiscal year and prior fiscal year concurrently
    until prior year-end closing is complete while interacting with the
    core financial system within that fiscal year. (TV-18)

-   Record different transaction types at the detailed transaction
    level. (TV-19)

-   Validate that all deposits to a receivable or unbilled revenue
    account balance the total of the deposit. (TV-20)

-   Employ appropriate edits at the point of entry to ensure that all
    required data have been entered and to validate the accuracy of the
    data prior to acceptance. (TV-21)

-   Record the user's identification as part of the transaction record.
    (TV-22)

-   Determine that the account number is valid, the credit card has not
    expired, and there is sufficient credit available to cover the
    charge. Any credit card transaction that does not meet these
    criteria will be declined by the system. (TV-23)

-   Reject a transaction or provide a warning message when attempting to
    post a transaction that would cause general ledger debits and
    credits to be out-of-balance at a level below the TAS/TAFS (e.g.,
    organization level). (TV-24)

-   Process and track transactions in both foreign currency and U.S.
    dollars. (TV-25)

[Value-added Requirements]{.underline}

To support the Transaction Validation activity, the Revenue System
**[should]{.underline}** provide the capability to:

-   Allow the user to relate memorandum accounts with budgetary and
    proprietary accounts in the definition of a standard transaction.
    (TV-26)

-   Perform validation checks for use of certain general ledger accounts
    associated with specific authority (e.g., Cashiers fund, borrowing
    authority) prior to posting a transaction. (TV-27)

-   Calculate progress payments to foreign vendors based on current
    exchange rates. (TV-28)

**Collection Process**

The Collection Process supports activities to record the receipt of
funds either by currency (e.g., cash, EFT) check, IPAC or credit card
and the deposit of such funds in accordance with Treasury and agency
regulations. The process also provides for the receipt of payment offset
information from Treasury and its application to the appropriate
accounts receivable.

#### 

#### [Mandatory Requirements]{.underline}

To support the Collection Process, the Revenue System
**[must]{.underline}** provide the capability to:

-   Record the application of complete and partial payments made by the
    debtor on a delinquent debt to administrative fees, penalties,
    interest, and then to principal, unless otherwise stated in program
    statute. (CP-1)

-   Record revenues for collections for which no receivable was
    previously established. (CP-2)

-   Apply collections back to the specific account, contract, or
    purchase order award to reduce "or liquidate" cumulative payments
    and expenditures (e.g., upon the refund of erroneous payments).
    (CP-3)

-   Record information associated with a collection at the time funds
    are applied to an open receivable document, including the deposit
    ticket number and date, ALC code, TAS/TAFS and accomplish date.
    (CP-4)

-   Apply collections to more than one receivable. (CP-5)

-   Re-open closed accounts to record collections after a waiver or
    write-off of a receivable has been recorded. (CP-6)

-   Process SF-5515 debit vouchers, SF 215, charge backs, canceled
    payments or insufficient funds, to reduce collections and
    re-establish a receivable. (CP-7)

-   Provide the ability to reduce collections with a miscellaneous
    adjustment (i.e., journal voucher). For example, a debit
    voucher/bank adjustment not related to a returned check reduced
    deposit total. (CP-8)

-   Maintain customer account information for internal statement of all
    transactions and to support billing, reporting and research
    activities, including at a minimum:

> \- Account number unique to each transaction or reference (not just
> unique to customer);
>
> \- Account balance;
>
> \- Associated customer ID number;
>
> \- Date due and age of accounts receivable;
>
> \- Accounting classification code strip; and
>
> \- Reimbursable order number, where applicable. (CP-9)

-   Process a receipt against an established receivable and close or
    liquidate the receivable if payment is in full. Leave the receivable
    open if not paid in full. (CP-10)

-   Apply collections to a hierarchy of debts. (CP-11)

```{=html}
<!-- -->
```
-   Create a deposit record for a deposit ticket. Info must include:

```{=html}
<!-- -->
```
-   Deposit ticket number (should be able to accommodate an agency
    assigned number and

> the Treasury assigned number);
>
> \- Deposit ticket date;
>
> \- Deposit ticket amount;
>
> \- ALC;
>
> \- Entry date;
>
> \- Treasury confirmation date;
>
> \- User ID -- for establishing ticket; and
>
> \- User ID -- for closing ticket. (CP-12)

-   Record the receipt of an advance from others and associate it with
    the RA. (CP-13)

```{=html}
<!-- -->
```
-   Provide the ability to record a receipt, part of which is revenue to
    the collecting agency, the remainder of the receipt is revenue to
    other agencies with which the receipt is shared. For example, INS
    collects fees for H-1B visas and retains a small percentage and
    shares with other agencies. (CP-14)

-   Provide system capability to automatically record collections by
    downloading data

> (lockbox, collection agency, DOJ, Treasury). (CP-15)

-   Provide capability to record and subsequently track collections by
    type (i.e., internally, externally with Treasury Offset Program, or
    other collection service center or agency). (CP-16)

#### [Value-added Requirements]{.underline}

There are no value-added requirements for this function.

**Revenue Recognition**

The Revenue Recognition function provides for the reclassification of
revenue transactions into earned and unearned receipts.

[Mandatory Requirements]{.underline}

To support the Revenue Recognition function, the Revenue System
**[must]{.underline}** provide the capability to:

-   Support standard transactions to adjust receivables and revenue
    based on adjustments to receipts (returned checks or credit card
    charge backs) and refunds (errors in service processing or return of
    purchased products). (RR-1)

-   Process a receipt against a holding/suspense account that will be
    researched at a time in the future. (RR-2)

-   Support transactions to record revenue based on sales of products or
    services, where the products or services are delivered prior to or
    concurrent with the payment. (RR-3)

-   Support standard transactions that allocate receipts to unearned
    revenue/advances (e.g., allow for entry of receipts to an advance
    USSGL account, either on an individual transaction basis, or for a
    class of transactions based on a predefined attribute or combination
    of attributes, such as revenue source code). (RR-4)

```{=html}
<!-- -->
```
-   Support standard transactions that provide for subsequent
    reclassification of prior advances to earned revenue based on some
    triggering event or action. For example, completed processing of an
    application allows agency to treat application fee as earned
    revenue. (RR-5)

-   Support the reclassification of prior receipts to earned revenue
    based on incremental triggering events. For example, a 4-step
    application process allows the agency to earn 25 percent of the fee
    as earned revenue as each step is completed. (RR-6)

#### [Value-added Requirements]{.underline}

There are no value-added requirements for this function.

**Receivable Management Process**

The Receivable Management Process supports activities to record
receivables in the system as they are recognized and to produce bills
for amounts due to the agency. A receivable is recognized when an agency
establishes a claim to cash or other assets against other entities.

#### 

#### [Mandatory Requirements]{.underline}

To support the Receivable Management Process, the Revenue System
**[must]{.underline}** provide the capability to:

-   Record the establishment of receivables along with the corresponding
    revenues. (RMP-1)

-   Accept transactions that generate revenue receivables. (RMP-2)

-   Identify multiple types of bills (e.g., overpayments, user fee
    based) and the supporting data used to verify the specific charges.
    (RMP-3)

-   Establish receivables to be paid under installment plans, including
    plans for which payments have been rescheduled. Generate flexible
    repayment schedules for delinquent indebtedness. (RMP-4)

-   Record billings and collections by line item in order to identify
    specific accounting classification codes. (RMP-5)

-   Support bills and collections between Federal agencies through the
    use of electronic systems such as IPAC. Provide supporting data to
    agencies billed which can be used to verify the charges. (RMP-6)

#### [Value-added Requirements]{.underline}

There are no value-added requirements for this function.

**Bill Generation**

The Bill Generation process supports activities to produce bills for
amounts due to the agency. A bill is notification of an amount due to a
federal agency for a service or product.

[Mandatory Requirements]{.underline}

To support the Bill Generation function, the Revenue System
**[must]{.underline}** provide the capability to:

-   Generate bills to customers based on accounts receivable
    calculation, event and time period, and type of claim. Bases used
    for billing may include:

\- Percentage of reimbursable obligations, accrued expenditures or
costs;

\- Fee schedules for goods or services provided; and

\- Payment schedules or other agreements with other entities. (BG-1)

-   Provide the capability to automatically calculate additional
    customer charges (e.g., interest) using user-defined criteria and
    automatically generate separate line item to reflect charges on the
    bill. (BG-2)

-   Record billings by line item in order to identify specific
    accounting classification codes. (BG-3)

-   Support bills between business partners and provide supporting data
    to agencies billed which can be used to verify the charges. (BG-4)

-   Reverse a bill issued non-IPAC, and reissue the bill via IPAC and
    vice versa. (BG-5)

-   Print bills, accommodating the generation of standard forms. Allow
    for customized text and descriptive information in generating
    billing documents. (BG-6)

-   Date bills with a system-generated date or with the date supplied by
    the user. (BG-7)

-   Consolidate multiple accounts receivable for a customer onto one
    bill. (BG-8)

-   Generate bills prepared manually and allow transactions to be
    entered onto bill by authorized personnel. (BG-9)

-   Provide the capability to allow adjustments to billing data prior to
    billing. (BG-10)

-   Record adjustments to bills and post to customer accounts. (BG-11)

-   Provide the capability to store billing supporting information.
    (BG-12)

-   Perform on-line "drill downs" from general ledger summary balances
    to detail transactions and referenced documents. (BG-13)

-   Provide the capability to issue credit bills when merchandise is
    returned. (BG-14)

-   Provide the capability to maintain, on-line, all activity related to
    the customer including date of last update and last date customer
    contact made, at document level. (BG-15)

-   Provide the capability to generate recurring billings with
    pre-defined customer and amount information. (BG-16)

[Value-added Requirements]{.underline}

To support the Bill Generation function, the Revenue System
**[should]{.underline}** provide the capability to:

-   Sort and summarize billing line item information, using user-defined
    criteria. (BG-17)

-   Provide the capability to allow customers to access their bills via
    the Internet. (BG-18)

-   Produce billing statements with tear-off portion, MICR-encoded to
    facilitate a lockbox operation. (BG-19)

**Debt Management**

The Debt Management process involves the maintenance of account
information on individual accounts receivable. The process supports
activities to: age receivables; calculate interest and record penalties
and administrative charges on overdue debt; pursue collection of amounts
due; liquidate receivables; record adjustments to receivables; maintain
a proper allowance for uncollectible amounts; and record write-offs.

#### 

#### [Mandatory Requirements]{.underline}

To support the Debt Management function, the Revenue System
**[must]{.underline}** provide the capability to:

-   Maintain data on individual receivables and referenced transactions
    supporting the receivable. (DM-1)

-   Maintain accounts for reimbursable orders and identify government
    and non-government accounts that are designated as advance funding.
    (DM-2)

-   Update each customer account when: billing documents are generated,
    collections are received, interest, penalty or administrative fees
    are applied, and when amounts are written-off or offset. (DM-3)

-   Calculate interest and penalty charges using the appropriate
    Treasury Late Payment Charge rate and user-defined criteria (e.g.,
    customer, customer type). Automatically generate a separate line
    item for interest charges on the customer bill. (DM-4)

-   Allow the user to specify administrative and penalty amounts and
    record these amounts to different accounting classification elements
    for which the principal amount is recorded. Automatically apply
    these charges to customer accounts and generate separate line items
    for the charges on the customer bills. (DM-5)

-   Provide an automated process for issuing invoices and follow-ups
    every 30 days, and generate posting/updating to the General Ledger
    with automated audit trail to source documents (OMB Circular A-129).
    (DM-6)

```{=html}
<!-- -->
```
-   Follow instructions provided in authoritative guidance:

> \- Automatically age receivables as described in OMB Circular A-129;
>
> \- Provide referral of payment history to Credit Reporting Bureaus (31
> U.S.C. 3711);
>
> \- Refer all applicable non-federal accounts receivable over 180 days
> to Treasury for Offset
>
> (DCIA of 1996); and
>
> \- Generate report of accounts receivable for debts in excess of
> \$100,000 for approval or
>
> write-off (31 CFR Part 902). (DM-7)

-   Provide information on the age of receivables to allow for
    management and prioritization of collection activities. This is to
    include aging information on individual receivables and on a summary
    basis, such as by customer, type of customer, fund, and general
    ledger account. (DM-8)

```{=html}
<!-- -->
```
-   Provide information to allow for the automated reporting of
    delinquent accounts to commercial credit bureaus. (DM-9)

```{=html}
<!-- -->
```
-   Create files of delinquent accounts for electronic submission to
    collection agencies and appropriate federal agencies. (DM-10)

```{=html}
<!-- -->
```
-   Maintain data for receivables referred to other federal agencies and
    outside organizations for collections and allow for electronic
    updates. (DM-11)

```{=html}
<!-- -->
```
-   Record the waiver and write-off of receivables, including interest,
    penalties, and administrative charges. Maintain data to monitor
    closed accounts. (DM-12)

-   For accounts referred to the Department of Justice, capture the
    judgment date, amount and the post-judgment interest rate.
    Automatically accrue interest on the judgment. Compound interest on
    the anniversary date of the judgment and accrue interest on new
    principal amount. (DM-13)

-   Compute simple and compound interests for user-defined (or according
    to a contractual or modification agreement) time frames using fixed
    and variable rates. (DM-14)

-   Generate dunning (collection) letters for overdue receivables when
    accounts become delinquent, and incorporate, as appropriate, due
    process notices for referring delinquent accounts. (DM-15)

-   Identify and report receivables that meet predetermined criteria for
    write-off, or referral and generate the appropriate entries. (DM-16)

-   Calculate (as a percentage of gross receivables or related revenues)
    and record the allowance for doubtful accounts based on historical
    experience, review of files, or other data indicating trend. (DM-17)

-   Produce IRS-1099-C's in the amounts of debts forgiven that meet or
    exceed a user-defined dollar threshold (e.g., \$600 or more) and
    produce a dataset file for electronic transmission to the IRS.
    (DM-18)

-   Support generation of demand letters at predefined intervals or on
    an ad-hoc basis. (DM-19)

-   Support storage and retrieval of history of demand letters and dates
    by account. (DM-20)

```{=html}
<!-- -->
```
-   Track and report on the date and nature of changes in the status of
    an accounts receivable, including the following:

> \- In Forbearance or in Formal Appeals Process;
>
> \- In Foreclosure;
>
> \- In Wage Garnishment;
>
> \- Rescheduled;
>
> \- Current;
>
> \- Waived/unwaived;
>
> \- Eligible for Referral to Treasury for Offset;
>
> \- Referred to Treasury for Offset;
>
> \- Eligible for Internal Offset;
>
> \- Eligible for Referral to Treasury or a Designated Debt Collection
> Center for Cross-
>
> servicing;
>
> \- Referred to Treasury for cross-servicing;
>
> \- Referred to private collection agency;
>
> \- Referred to Department of Justice \[with tracked cases by code and
> date\];
>
> \- Offset;
>
> \- Suspended;
>
> \- Compromised;
>
> \- Currently not collectible (written off, but not yet closed out);
>
> \- Written-off; and
>
> \- Closed Out. (DM-21)

-   Produce case history of litigation activities including date sent,
    nature of complaint, prejudgment, agreement, type of judgment --
    default/summary/consent, reason returned by Department of Justice,
    amount outstanding and amount collected. (DM-22)

-   Offset payments to debtors for amounts due to the agency (e.g.,
    outstanding accounts receivable, credit memo, and open advances).
    When an entire payment is offset, create the appropriate notice to
    the vendor that the offset has been made. (DM-23)

    [Value-added Requirements]{.underline}

    To support the Debt Management function, the Revenue System
    **[should]{.underline}** provide the capability to:

-   Customize the dunning process parameters and dunning letter text.
    (DM-24)

```{=html}
<!-- -->
```
-   Support ability to capture free form notes (i.e., comments from
    phone messages) by date and to retrieve comments by date. (DM-25)

-   Provide a status code with user definable text values that can be
    used for monitoring and tracking accounts. (DM-26)

**Revenue Estimation**

Revenue estimation provides agencies with a prediction of how revenue
will change from the current baseline. Typically, estimates are
approximations taken from existing data on revenue, supplemented with
additional data sources as necessary.

#### [Mandatory Requirements]{.underline}

To support Revenue Estimation, the Revenue System **[must]{.underline}**
provide the capability to:

-   Support the export of historical data for use in revenue
    forecasting. (REA-1)

[Value-added Requirements]{.underline}

To support Revenue Estimation, the Revenue System
**[should]{.underline}** provide the capability to:

-   Support revenue forecasting based on historical revenue data and
    other variables such as known current or future events (planned rate
    increases, market changes, etc.). For example, if regulation will
    increase fees, effective May 1, compute revenue for balance of
    fiscal year. (REA-2)

-   Establish a baseline of revenue collections in comparison to
    potential revenue. (REA-3)

**(LEFT BLANK INTENTIONALLY)**

**Output**

This section identifies requirements preceding interaction with an
agency's core financial system. Sections include automated
reconciliation and performance measurement.

**Automated Reconciliation**

Agencies' Revenue Systems maintain detailed subsidiary account
information that supports control functions of the general ledger.
Information is to be provided to core financial systems for
reconciliation with financial information contained in reports from
Treasury and other agencies. The Revenue System shall provide automatic
reconciliation of daily activity receipts based upon collections,
remittances, revenue, amounts due or payable, amounts tendered and
method of payments.

[Mandatory Requirements]{.underline}

To support the Automated Reconciliation function, the Revenue System
**[must]{.underline}** provide:

-   Detailed subsidiary record amounts used to compare with amounts in
    the general ledger resulting in the creation of reports for those
    accounts that are out of balance. This capability must be available
    for all open accounting periods and at frequencies defined by the
    user, such as daily, weekly and monthly. (AR-1)

```{=html}
<!-- -->
```
-   The capability to record sales of goods and services based on
    user-defined criteria, for example use of trans codes, SGL accounts
    or pro formas. (AR-2)

[Value-added Requirements]{.underline}

There are no value-added requirements for this function.

**Performance Measurement**

The Government Performance and Results Act (GPRA) of 1993 is designed to
make federal agencies accountable for achieving program results.
Effective Revenue Systems account for revenue at the lowest cost.
Federal managers are required to set strategic goals, measure
performance, and report on their progress. An agency's Revenue System
should accumulate and track program performance data.

[Mandatory Requirements]{.underline}

To support the Performance Measurement function, the Revenue System
**[must]{.underline}** provide the capability to:

-   Meet GPRA requirements and link to an agency's strategic plan and
    provide revenue cost management information that can be matched with
    budget execution information for performance measure calculations.
    (PM-1)

-   Perform trend analyses across periods and fiscal years. (PM-2)

[Value-added Requirements]{.underline}

To support the Performance Measurement function, the Revenue System
**[should]{.underline}** provide the capability to:

-   Track actual performance against established standards and to
    calculate variances for both system users and organizations. (PM-3)

```{=html}
<!-- -->
```
-   Collect cost information of performing collection activities. (PM-4)

**Reporting**

Reporting encompasses internal and external reporting, the creation of
audit trails, performing on-line and ad-hoc query, and records
retention.

**Internal and External Reporting**

Financial management systems must be designed with the flexibility to
accommodate new and emerging reporting requirements both internally and
externally. The Revenue System must provide complete, reliable,
consistent, timely and useful detailed transaction and summary
information to an agency's Core financial system to enable individual
operating components to carry out program responsibilities effectively
and efficiently.

[Mandatory Requirements]{.underline}

To support the Internal and External Reporting function, the Revenue
System **[must]{.underline}** be able to:

-   Export data from the Revenue System to the Core financial system.
    (IER-1)

```{=html}
<!-- -->
```
-   Support provision (to Core Financial System or directly) of data in
    hard copy and electronic formats required by the Department of the
    Treasury for the Form 224, Statement of Transactions, and Treasury
    Report on Receivables. (IER-2)

-   Create, compute, and post all necessary financial transactions.
    (IER-3)

-   Track receivables that have been forwarded to an external collection
    agency (e.g., Treasury). (IER-4)

```{=html}
<!-- -->
```
-   Support provision of data for the preparation of consolidated
    financial statements as required by FASAB Standards and the current
    OMB Bulletin on Form and Content of Agency Financial Statements
    requirements (IER-5)

```{=html}
<!-- -->
```
-   Report financial activity transactions by any element within the
    accounting classification structure (e.g., individual or
    hierarchical organization code, project code). (IER-6)

```{=html}
<!-- -->
```
-   Identify government, including inter- and intra- agency transactions
    and non-government revenues and expenses to support preparation of
    external reports. (IER-7)

```{=html}
<!-- -->
```
-   Produce report of transaction level details for the TAS/TAFS totals
    on the Financial Management Service (FMS) Form 224, Statement of
    Transactions. (IER-8)

```{=html}
<!-- -->
```
-   Support production of daily on-line Available Funds report(s) for
    each TAS/TAFS that is subject to Federal Agencies' Centralized
    Trial-Balance System (FACTS) II reporting requirements. Support must
    be provided for the parameters established by FMS. (IER-9)

```{=html}
<!-- -->
```
-   Provide on-line subsidiary revenue activity summary at the internal
    fund, organization, and TAS/TAFS levels. The subsidiary summary must
    provide the following minimum data elements for each applicable
    general ledger account:

```{=html}
<!-- -->
```
-   The balance at the beginning of the accounting period,

-   The total amount of debits by transaction type for the accounting
    period,

-   The total amount of credits by transaction type for the accounting
    period, and

-   The cumulative ending balance for the accounting period. (IER-10)

```{=html}
<!-- -->
```
-   Support reporting of FACTS I and FACTS II data as required by the
    core financial management system. (IER-11)

```{=html}
<!-- -->
```
-   Produce an on-line transaction register at the internal fund,
    organization, and TAS/TAFS level for each accounting period, that
    provides the following data elements:

```{=html}
<!-- -->
```
-   Fiscal year;

-   TAS/TAFS;

-   Internal fund;

-   Document number;

-   Document entry date;

-   Document entry time;

-   Document entry User ID;

-   Document transaction date;

-   Transaction type;

-   Debit account number;

-   Debit account object class;

-   Debit amount;

-   Credit account number;

-   Credit account object class;

-   Credit amount;

-   USSGL attribute domain headings; and

-   USSGL attribute values associated with the transaction.

> The register must include all transactions that occurred within the
> accounting period specified. (IER-12)

-   Forward aging reports to the appropriate individuals with write-off
    approval authority using automated workflow facilities. (IER-13)

-   Report the financial information required for program management
    performance reporting. (IER-14)

[Value-added Requirements]{.underline}

To support the Internal and External Reporting function, the Revenue
System **[should]{.underline}** provide the capability to:

-   "Drill down" to detail transactions for any summary level within a
    report for transactions originally input and maintained within the
    accounting and/or financial management system. (IER-15)

```{=html}
<!-- -->
```
-   Save customized report/query routines and/or results with the
    capability to transmit either electronically. (IER-16)

```{=html}
<!-- -->
```
-   Report process compatibility with both database and application
    security protocols. (IER-17)

```{=html}
<!-- -->
```
-   Perform exception and data ranking reporting based on user-defined
    parameters. (IER-18)

```{=html}
<!-- -->
```
-   Define and modify customized reports. (IER-19)

```{=html}
<!-- -->
```
-   Report on collection statistics by customer and agency during a
    reporting period. (IER-20)

-   Provide a revenue source code structure to identify and classify
    types of revenue and receipts as defined by the user. For example,
    categories could be rental income, sales by product type, income by
    type of service performed and others. (IER-21)

**Audit Trail**

Adequate audit trails are critical to providing support for transactions
and balances maintained by the Revenue System. While audit trails are
essential to auditors and system evaluators, they are also necessary for
day-to-day operation of the system. For example, they allow for the
detection and systematic correction of errors.

[Mandatory Requirements]{.underline}

To support the Audit Trail function, the Revenue System
**[must]{.underline}** provide the capability to:

-   Provide audit trails to trace transactions from their initial source
    through all stages of related system processing within the
    installation accounting/financial management system. The initial
    source may be source documents, transactions originating from other
    systems (e.g., feeder systems), or internal system-generated
    transactions. (AT-1)

-   Identify document input, change and approval by user. (AT-2)

-   Select items for review based on user-defined criteria by type of
    transaction (e.g., by receivable transactions, debtor, date range).
    For example, to select items for financial statement audits. (AT-3)

#### 

#### [Value-added Requirements]{.underline}

To support the Audit Trail function, the Revenue System
**[should]{.underline}** provide the capability to:

-   Support audit processes by flagging remittance variations and gaps.
    For example, an agent collects and remits fees quarterly and skips
    one quarter or sends in remittance that is 50 percent lower than
    prior year. (AT-4)

-   Match non-exchange transactions with the event(s) that initiate the
    recognition of this revenue. (AT-5)

**On-Line Query Capability**

Query access will be restricted to users on a query profile basis to
insure that system processing time is not degraded by undue access.
Establishing and maintaining query profiles will be the responsibility
of the systems administrator.

#### [Mandatory Requirements]{.underline}

To support On-Line Query Capability, the Revenue System
**[must]{.underline}** provide the capability to:

-   Record all transactions for a specific accounting record. (OLQ-1)

-   Report the amount totals by type of fee and date range. (OLQ-2)

-   Report by any combination or subset of name, receivable number, date
    range, transaction number, deposit account number, and transaction
    amount. (OLQ-3)

-   Assign user level capability for ad hoc query access. (OLQ-4)

-   Produce deposit account history by account number and date range.
    (OLQ-5)

-   Produce customer inquiry history by deposit account number or
    receivable number. (OLQ-6)

-   Produce deposit account transactions in a monthly deposit account
    statement format for the each month. (OLQ-7)

-   Provide deposit ticket (SF 215) and debit voucher (SF 5515) number
    or amount. (OLQ-8)

-   Perform on-line queries of account activity (billing, collection,
    and adjustment) by customer and receivable. (OLQ-9)

-   Perform on-line queries of miscellaneous cash receipts (applied to
    any Treasury fund symbol) by customer, when identified, and by
    accounting period. (OLQ-10)

-   Provide and maintain on-line queries and reports on balances
    separately for the current/prior months and current/prior fiscal
    years. At a minimum, queries must be maintained on-line for
    current/prior months and current/prior fiscal years until the prior
    month/year closing is complete. (OLQ-11)

    [Value-added Requirements]{.underline}

    To support the On-Line Query function, the Revenue System
    **[should]{.underline}** provide the capability to:

```{=html}
<!-- -->
```
-   Generate reports by geographic location. (OLQ-12)

**Ad-Hoc Query Capability**

Over time, demands for specific financial data are expected to change
considerably based on new administrations, program missions, budget
priorities, or oversight. While requirements associated with standard
internal and external reporting are based on clearly defined financial
management information needs, ad hoc query requirements are general in
nature. The ability of a financial management system package to provide
for flexible data access is critical to enabling effective agency,
program and financial management in the face of change. The proper
management of data communication is as critical as providing its access.
Data information communicated to users and customers must be consistent
-- the same answer must be provided to the same question asked at
different times. This section addresses data and access capabilities
expected as part of an ad-hoc query function.

#### [Mandatory Requirements]{.underline}

To effectively support Ad-Hoc Query Capability, the Revenue System
**[must]{.underline}**:

-   Allow users to create and submit parameter-based query scripts or to
    store them in a common library for future use. (AHQ-1)

-   Allow users to run queries on-line or in batch mode and to stage
    output for later access by authorized users. (AHQ-2)

-   Provide run-time controls to limit \"run-away\" queries and large
    data download requests. (AHQ-3)

-   Support graphical output display on the desktop. Output display
    should also support dynamic report reformatting, regrouping and
    drill-down to detail records from summary report lines. (AHQ-4)

-   Allow authorized users to download selected financial data. This
    download capability must be able to automatically reformat
    downloaded information for direct access by common desktop
    applications (e.g., ASCII formatted). (AHQ-5)

-   Provide the ability to preview a report, form, or other query result
    before printing. (AHQ-6)

-   Support access to current year and historical financial data.
    (AHQ-7)

#### [Value-added Requirements]{.underline}

To provide additional Ad-Hoc Query Capability, the Revenue System
**[should]{.underline}** provide the capability to:

-   Allow users to automatically distribute copies of report/query
    results via e-mail to multiple pre-identified individuals or groups.
    (AHQ-8)

-   Provide the following ad hoc query interface features:

> \- The ability to "point and click" on selectable table, data, and
> link objects for inclusion in
>
> a custom query;
>
> \- An active data dictionary to provide users with object definitions;
>
> \- The ability to share user developed query scripts with other
> authorized agency users and
>
> query optimization; and
>
> \- On-line help. (AHQ-9)

-   Facilitate customer query and self-service capability subsequent to
    customer verification and clearance. (AHQ-10)

**Records Retention**

Records Retention removes data that is no longer needed for immediate
access from the system data stores used for inquiry and reporting on
current information. Each archive episode shall generate a library entry
in an archive information table. The library entry will include the
transaction date range for the information archived. Once transactions
are archived they will be deleted from the system.

[Mandatory Requirements]{.underline}

To support the Records Retention function, the Revenue System
**[must]{.underline}** provide:

-   Temporary restoration to the on-line system for browsing and
    reporting. (AD-1)

-   Retention of system records in accordance with Federal regulations
    established by 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.
    (AD-2)

[Value-added Requirements]{.underline}

There are no value-added requirements for this function.

**Interface**

Financial management systems must be designed with effective and
efficient interrelationships between the agency's other financial
management feeder systems and the agency's core financial system. The
CFO Act of 1990 and financial management systems policy described in OMB
Circular No. A-127, Financial Management Systems, require that each
agency establish and maintain a single, integrated financial management
system. A single integrated financial management system must be one with
a unified set of financial systems.

[Mandatory Requirements]{.underline}

To support Interface requirements, the Revenue System
**[must]{.underline}** provide the capability to:

-   Produce reports and transmittable files to meet the relevant
    Application Program Interface specified by the core financial
    system. Interface information must include:

> \- Cash refund information capturing who and why;
>
> \- Receipt, collection, and billing information capturing what, when
> and what for;
>
> \- Deposit information required by the National Automated Clearing
> House
>
> Association;
>
> \- Receivable aging information;
>
> \- Uncollectable receivables/bad debt information;
>
> \- Balance of advances from others;
>
> \- RA limits to make sure billings do not exceed the RA; and
>
> \- Cost related to reimbursable work not directly recorded in the
> acquisition or cost
>
> systems. (I-1)

-   Provide integration or appropriate interfaces between system modules
    and have the ability to simultaneously update or interface with the
    various systems or modules without the need for duplication. (I-2)

-   Provide the capability to provide for uploading and downloading data
    to other systems and databases in a personal computer environment.
    (I-3)

-   Interface with Cost and Acquisition Systems to update cost data
    needed for services performed under a RA. (I-4)

```{=html}
<!-- -->
```
-   Provide controls over interfaced data to ensure that files are
    transmitted by an authorized source to an authorized destination and
    they are complete and not duplicates. In addition, controls over
    each file should ensure (1) the number of transactions in the file
    matches control records; (2) the dollar total of transactions in the
    file matches control records; (3) the sender is notified of any
    erroneous transactions; and (4) erroneous transactions are
    automatically returned to the sender. (I-5)

-   Provide an application user face that complies with the software
    application standards required by section 508 of the Rehabilitation
    Act, as detailed in 36 CFR 1194, subpart 9. (I-6)

-   Interface with the Central Contractor Registration (CCR), an
    existing on-line database that is the single validated source of
    data on vendors doing business for the government, for the exchange
    of identification data and EFT routing information in business
    transactions and other data elements required by OMB's "Business
    Rules for Intragovernmental Transactions" (M-03-01). (I-7)

-   Link to other applications and data sources (e.g., strategic plans,
    performance measures and data warehouse). (I-8)

[Value-added Requirements]{.underline}

There are no value-added requirements for this function.

**Security**

This technical category defines internal and external access controls. A
Revenue System must be designed to protect an agency's financial data
from unauthorized access or alteration. Adequate data protection
includes the following discrete requirements.

[Mandatory Requirements]{.underline}

To support the Security function, the Revenue System
**[must]{.underline}** provide the capability to:

-   Allow entry into system only to those individuals who are authorized
    and only during times authorized. (S-1)

```{=html}
<!-- -->
```
-   Perform annual revalidation of the user. (S-2)

-   Maintain a history of password changes over a specified amount of
    time and preclude the consecutive use of the same password,
    including changes and lost passwords. (S-3)

-   Require the use of unique user identifications and passwords for
    authentication purposes. Passwords must be non-printing and
    non-displaying. The application must allow for the enforcement of
    password standards (e.g., minimum length and use of alpha, numeric
    and special characters). The application must also allow for the
    establishment of a specified period for password expiration to
    provide changes on a regular basis, accommodate prohibiting the user
    from reusing recent passwords and be capable of periodic change, at
    option of user, and of mandatory change, at the option of the system
    administrator after a specified period of time. (S-4)

-   Maintain an audit logging capability to record access activity of
    every user and every terminal including:

> \- Time and date of use;
>
> \- Type of transaction;
>
> \- All log-in/log-out attempts by user and workstation;
>
> \- User submitted transactions;
>
> \- Initiated processes;
>
> \- System override events; and
>
> \- Direct additions, changes or deletions to application maintained
> data. (S-5)

-   Limit the capability of users to selected functions (i.e., create,
    read, update, and delete) as well as have the capability to define
    functional access rights (e.g., to modules, transactions and
    approval authorities) and data access rights (e.g., record, create,
    read, update and delete) by assigned user ID, functional role (e.g.,
    payable technician) and owner organization. User profiles can be
    added, deleted, modified or changed by the system administrator.
    (S-6)

-   Allow the system administrator to restrict access to sensitive data
    elements such as social security numbers and banking information by
    named user, groups of users, or functional role. (S-7)

-   Allow the user to void a transaction within the same day the
    original posting is made prior to batch processing. Controls should
    be in effect to prevent transactions from being voided on a date
    other than the date the transaction was originally posted. (S-8)

-   Limit access to data files and programs by individuals attempting to
    access them both through the system and through access methods
    external to the system for other than the data base administrator.
    (S-9)

-   Alert and record when invalid access is attempted or when user ID
    limit is exceeded. (S-10)

-   Prevent the alteration of financial data (i.e., voids) except
    through the posting of transactions that are entered through the
    normal edit and update process under proper security. (S-11)

-   Comply with the National Institute of Standards and Technology
    (NIST) Security Standards relating to the applications integrated
    security features. See http://csrc.nist.gov/ for more information.
    (S-12)

-   Control access to the application, functional modules, transactions,
    and data by having integrated security features that are
    configurable by the system administrator. (S-13)

-   Query the audit log by type of access, date and time stamp range,
    user identification, or terminal ID. (S-14)

-   Comply with Federal Information System Controls Audit Manual
    (FISCAM) standards. (S-15)

#### [Value-added Requirements]{.underline}

To support Security function, the Revenue System
**[should]{.underline}** provide the capability to:

-   Provide confidential Internet based communication from customer to
    system. (S-16)

-   Maintain general profile identity attributes that could consist of a
    customer's:

> \- Username;
>
> \- Name;
>
> \- Address;
>
> \- Home telephone number;
>
> \- Social Security Number;
>
> \- Date of birth;
>
> \- Personal e-mail address;
>
> \- Employer name;
>
> \- Employer address;
>
> \- Employee telephone number;
>
> \- Employer e-mail address; and

\- Confidential questions and answers. (S-17)

**Appendix A -- Authoritative References**

+------------------------------------+--------------+-----------------+
| **Authoritative References**       | **Topic**    | **Source**      |
+------------------------------------+--------------+-----------------+
| Federal Credit Reform Act of 1990  | Loans        | Congress        |
|                                    |              | (Statutory)     |
+------------------------------------+--------------+-----------------+
| Rehabilitation Act of 1973         | A            | Congress        |
|                                    | ccessibility | (Statutory)     |
|                                    | for the      |                 |
|                                    | Disabled     |                 |
+------------------------------------+--------------+-----------------+
| 31 U.S.C. 1535 - Economy Act       | Reimbursable | Congress        |
|                                    | Agreements   | (Statutory)     |
|                                    |              |                 |
|                                    | Between      |                 |
|                                    | Federal      |                 |
|                                    | Entities     |                 |
+------------------------------------+--------------+-----------------+
| PL 103-356 Government Management   | Reimbursable | Congress        |
| Reform Act (Authorizes Franchise   | Agreements   | (Statutory)     |
|                                    |              |                 |
| Fund Pilots to facilitate          | Between      |                 |
| Inter-Governmental                 | Federal      |                 |
| Cross-Servicing)                   | Entities     |                 |
+------------------------------------+--------------+-----------------+
| 31 U.S.C. 6501 -- 6508 Authority   | Inter        | Congress        |
| for Intergovernmental              | governmental | (Statutory)     |
|                                    |              |                 |
| Cooperation                        | Agreements   |                 |
+------------------------------------+--------------+-----------------+
| 31 U.S.C. 3711; Claims Collection  | Receivables  | Congress        |
| Standards (31 CFR Parts 900-904);  | & Loans      | (Statutory)     |
|                                    |              |                 |
| Debt Collection Act of 1982; Debt  |              |                 |
| Collection Improvement Act of 1996 |              |                 |
+------------------------------------+--------------+-----------------+
| 31 U.S.C. 9701 -- Independent      | User Charges | Congress        |
| Offices Appropriation Act of 1952  |              | (Statutory)     |
+------------------------------------+--------------+-----------------+
| Title 31 Code of Federal           | Regulations  | National        |
| Regulations Subtitle B             | on Money and | Archives and    |
|                                    | Finance      | Records         |
|                                    |              | Administration  |
+------------------------------------+--------------+-----------------+
| Title 12, Section 265, Code of     | Insured      | National        |
| Federal Regulations                | banks as     | Archives and    |
|                                    | depositories | Records         |
|                                    | of public    | Administration  |
|                                    | money        |                 |
+------------------------------------+--------------+-----------------+
| OMB Circular A-11 Budget           | Budgetary    | Office of       |
| Formulation and Execution          |              | Management &    |
| (formerly A-34)                    |              | Budget          |
+------------------------------------+--------------+-----------------+
| OMB Circular A-25 - User Charges   | User Charges | Office of       |
|                                    |              | Management &    |
|                                    |              | Budget          |
+------------------------------------+--------------+-----------------+
| OMB Circular A-123 Management      | Internal     | Office of       |
| control requirements and testing   | Management   | Management &    |
|                                    | Controls     | Budget          |
+------------------------------------+--------------+-----------------+
| OMB Circular A-127 Requires a      | Single       | Office of       |
| single, integrated financial       | Integrated   | Management &    |
| management system                  | Financial    | Budget          |
|                                    | System       |                 |
+------------------------------------+--------------+-----------------+
| OMB Circular A-129 Policies for    | Receivables  | Office of       |
| Managing Federal Credit Programs   | & Loans      | Management &    |
| and                                |              | Budget          |
|                                    |              |                 |
| Non-Income Tax Receivables         |              |                 |
+------------------------------------+--------------+-----------------+
| OMB Bulletin 01-09 provides        | Form &       | Office of       |
| requirements for the form and      | Content of   | Management &    |
| content of                         | Financial    | Budget          |
|                                    |              |                 |
| Agency Financial Statements        | Statements   |                 |
+------------------------------------+--------------+-----------------+
| SFFAS 2 - Accounting for Direct    | Loans        | FASAB           |
| Loans and Loan                     |              |                 |
|                                    |              |                 |
| Guarantees, and SFFAS 18 --        |              |                 |
| Amendments                         |              |                 |
+------------------------------------+--------------+-----------------+
| SFFAC 2 - Entity and Display       | External     | FASAB           |
|                                    | Reporting    |                 |
|                                    | and          |                 |
|                                    |              |                 |
|                                    | Disclosure   |                 |
+------------------------------------+--------------+-----------------+
| SFFAC 3 -- Management's Discussion | External     | FASAB           |
| and Analysis                       | Reporting    |                 |
|                                    | and          |                 |
|                                    |              |                 |
|                                    | Disclosure   |                 |
+------------------------------------+--------------+-----------------+
| SFFAS 4 - Managerial Cost          | Cost         | FASAB           |
| Accounting Concepts and Standards  | Accounting   |                 |
+------------------------------------+--------------+-----------------+
| SFFAS 7 -- Accounting for Revenues | Revenu       | FASAB           |
| and Other Financing Sources        | es/Financing |                 |
|                                    | Sources      |                 |
+------------------------------------+--------------+-----------------+
| Volume I -- Parts 5 & 6 Treasury   | Go           | U.S. Department |
| Financial Manual                   | vernmentwide | of the          |
|                                    | Deposit and  | Treasury,       |
| Volume 5 -- Ca\$hlink              | Collection   | Financial       |
|                                    | Requirements | Management      |
|                                    |              | Service         |
+------------------------------------+--------------+-----------------+
| Treasury Financial Manual          | Cash         | U.S. Department |
| Supplemental Guidance - Cash       | Management   | of the          |
| Management Made Easy               |              | Treasury,       |
|                                    |              | Financial       |
|                                    |              | Management      |
|                                    |              | Service         |
+------------------------------------+--------------+-----------------+
| Core Financial Systems             | Overall      | JFMIP           |
| Requirements                       | Federal      |                 |
|                                    | Financial    |                 |
|                                    | System       |                 |
|                                    | Requirements |                 |
+------------------------------------+--------------+-----------------+
| Systems Requirements on Direct and | Loans        | JFMIP           |
| Guaranteed Loans                   |              |                 |
+------------------------------------+--------------+-----------------+
|                                    |              |                 |
+------------------------------------+--------------+-----------------+

**(LEFT BLANK INTENTIONALLY)**

**Appendix B - Glossary**

**ACCRUAL METHOD**

The accrual method of accounting recognizes the significant aspects of
financial transactions as they occur. Under the accrual method, income
and assets are recorded in the period in which earned or acquired, and
expenses and liabilities are recorded in the period in which incurred.
Accrual accounting emphasizes matching revenues and expenses. Generally,
accrual accounting can contribute to effective financial control over
resources and cost of operations and is essential to developing adequate
cost information.

**ACTIVITY**

The actual task or step performed in producing and delivering products
and services. An aggregation of actions performed within an organization
that is useful for purposes of activity-based costing.

AGENCY LOCATION CODE (ALC)

Code assigned by Treasury to each reporting unit requiring the
preparation of an FMS-224, Statement of Transactions. The ALC must be
shown on all correspondence, forms, and other documentation forwarded to
financial institutions, The Department of Treasury FMS, other Federal
agencies, and to Treasury Regional Financial Centers, and particularly
on all SF-215s: Deposit Tickets, and SF-5515s: Debit Vouchers.

**APPLICATION PROGRAM INTERFACE (API)**

A set of routines, protocols, and tools for building software
applications.

**APPORTIONMENT**

A distribution made by OMB of amounts available for obligation in an
appropriation or fund account into amounts available for specified time
periods, activities, projects, objects, or combinations thereof. The
amounts so apportioned limit the obligations that may be incurred.

**APPROPRIATED FUNDS**

Appropriated funds are monies made available to a federal entity by
Congress. There are generally two types of appropriations: annual and
multiyear. The appropriation acts approved by Congress specify the
purpose for which the Funds can be used.

**USSGL ATTRIBUTES**

To meet external reporting requirements, agencies need data at a level
below the four-digit USSGL account. Agencies' systems must capture this
information at the transaction level by recording transactions using
USSGL four-digit accounts plus attributes. Attributes are like
adjectives that further describe a USSGL account in order to meet a
specific reporting requirement. Examples include: Apportionment
Category, Authority Type, Availability Time, Reimbursable Flag, etc.

**BILL**

Notification of an amount due to a federal agency for service/product.

**BUDGET AUTHORITY**

The authority provided by federal law to incur financial obligations
that will result in immediate or future outlays. Specific forms of
budget authority include appropriations, borrowing authority, contract
authority, and spending authority from offsetting collections.

**BUDGETARY ACCOUNTING**

Budgetary accounting is the system that measures and controls the use of
resources according to the purposes for which budget authority was
enacted; and that records receipts and other collections by source. It
tracks the use of each appropriation for specified purposes in separate
budget accounts through the various stages of budget execution from
appropriation to apportionment and allotment to obligation and eventual
outlay. This system is used by the Congress and the Executive Branch to
set priorities, to allocate resources among alternative uses, to finance
these resources, and to assess the economic implications of federal
financial activity at an aggregate level. Budgetary accounting is used
to comply with the Constitutional requirement that "No Money shall be
drawn from the Treasury, but in Consequence of Appropriations Made by
Law; and a regular Statement and Account of the Receipts and
Expenditures of all public money shall be published from time to time."

**CA\$HLINK**

A Treasury system used to manage and monitor the collection of
government revenues and report the balances to federal agencies.

**CASH BASIS OF ACCOUNTING**

The cash basis of accounting emphasizes the receipt and payment of cash.
That is, revenue is recognized only when cash is received from a
customer or client, and expenses are recognized only when cash is
actually paid for an item or service received.

**CHART OF ACCOUNTS**

The list of general account numbers that subdivide basic accounting
equations, with associated titles and definitions, used by an entity for
posting to its general ledger.

**CLASSIFICATION STRUCTURE**

The data elements defined to support a specific portion of information
architecture.

**COLLECTION**

Amounts received by the Federal Government during the fiscal year.
Collections are classified as follows:

1\. Budget receipts or off-budget receipts are collections from the
public based on the government's exercise of its sovereign powers,
including collections from participants in compulsory social insurance
programs.

2\. Offsetting collections are collections from government accounts
(intragovernmental transactions) or from the public that are offset
against budget authority and outlays rather than reflected as receipts
in computing the budget and off-budget totals. They are classified as
(a) offsetting receipts (i.e., amounts deposited to receipt accounts),
and (b) collections credited to appropriation or fund accounts. The
distinction between these two major categories is that collections
credited to appropriation or fund accounts are offset within the account
that contains the associated disbursements (outlays), whereas offsetting
receipts are in accounts separate from the associated disbursements.
Offsetting collections are deducted from gross disbursements in
calculating net outlays.

**CONTRA ACCOUNT**

One of two or more accounts which partially or wholly offset another or
other accounts; on financial statements, they may be either merged or
appear together.

**COST**

The monetary value of resources used or sacrificed or liabilities
incurred to achieve an objective.

**COST ACCOUNTING**

Method of accumulating, classifying, summarizing, reporting, and
interpreting information for the purposes of operational planning and
control, special decisions, and product costing.

**CUSTODIAL ACTIVITY**

The collection of taxes or other revenues collected or collectible.

**CUSTODIAL REVENUE**

If exchange revenue is collected on behalf of other entities (including
the U.S. Government as a whole), the entity that collects the revenue
should account for that revenue as a custodial activity, i.e., an amount
collected for others. 

**CUSTOMER ORDER**

An order received and accepted by the performing activity from a
customer. It is written evidence that certain goods and services will be
provided to the tenderer of the order for a specified amount. The order
must contain an original signature or equivalent of both the ordering
activity and the receiving activity. For non-exchange transactions, the
customer order is generated when the revenue event takes place.

**DEPOSIT FUND ACCOUNT**

An account established to record amounts held temporarily by the
government until ownership is determined (e.g., earnest money paid by
bidders for mineral leases) or held by the government as an agent for
others (e.g., State and local income taxes withheld from Federal
employees' salaries and not yet paid, to the state or local government).
Deposit fund transactions are excluded from the budget totals because
the funds are not owned by the government. Since increases in deposit
fund balances reduce Treasury's need to borrow, they are a means of
financing a deficit or a surplus. FMS establishes a deposit fund account
to record moneys that do not belong to the Federal Government. The
deposit fund (liability) classification is proper for any account that
meets one of the following three criteria:

1\) Moneys withheld by the government from payments for goods and
services received. Agencies may treat this transaction as a deposit fund
liability only when they have charged a budget account and the
government is holding the funds pending payment (e.g., payroll
deductions for savings bonds or State income taxes).

2\) Deposits received from outside sources for which the government is
acting solely as a banker, fiscal agent or custodian.

3\) Moneys the government is holding awaiting distribution based on a
legal determination or investigation. This category includes moneys in
dispute (between the government and outside parties) where ownership is
in doubt and there is no present basis for estimating ultimate
distribution.

**DOCUMENT**

This refers to balances and descriptive data of individual documents,
such as requisitions, purchase orders, contracts, vouchers, billings,
advances, and the like.

**ENTITY**

A unit within the Federal Government, such as a department, agency,
bureau, or program, for which a set of financial statements would be
prepared. Entity also encompasses a group of related or unrelated
commercial functions, revolving funds, trust funds, and/or other
accounts for which financial statements will be prepared in accordance
with OMB annual guidance on Form and Content of Financial Statements.

**EXCHANGE REVENUE**

Inflows of resources to a governmental entity that the entity has
earned. They arise from exchange transactions, which occur when each
party to the transaction sacrifices value and receives value in return.

**EXCHANGE TRANSACTION**

A transaction that arises when each party to the transaction sacrifices
value and receives value in return.

**FINANCIAL ACCOUNTING**

1\. The accounting for assets, liabilities, equities, revenues, and
expenses as a basis for reports to external parties.

2\. A methodology that focuses on reporting financial information
primarily for use by owners, external organizations, and financial
institutions. This methodology is constrained by rule-making bodies such
as the Financial Accounting Standards Board (FASB), the Securities
Exchange Commission (SEC), and the American Institute of Certified
Public Accountants (AICPA).

**FINANCIAL EVENT**

Any occurrence having financial consequences to the Federal Government
related to the receipt of appropriations or other financial resources;
acquisition of goods or services; payments or collections; recognition
of guarantees, benefits to be provided, or other potential liabilities;
or other reportable financial activities.

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

**FULL COST**

The total amount of resources used to produce the output.

**FUTURE-DATED TRANSACTIONS**

Financial transactions that are input and warehoused in the current
accounting period, scheduled to be posted to a later accounting period.

**GENERAL FUND**

Accounts for receipts not earmarked by law for a specific purpose, the
proceeds of general borrowing, and the expenditure of these moneys.

**GENERAL LEDGER**

The core of an accounting system, which is a chronological record of
accounting transactions. It shows the names of accounts, the amounts
that are to be debited and credited to each account, and descriptions of
the transactions. Also see USSGL.

**GOVERNMENTAL RECEIPTS**

Collections from the public that result primarily from the exercise of
the government's sovereign or governmental powers. Governmental receipts
consist mostly of individual and corporation income taxes and social
insurance taxes but also include excise taxes, compulsory user charges,
customs duties, court fines, certain license fees, gifts and donations,
and deposits of earnings by the Federal Reserve System. They are
compared to outlays in calculating a surplus or deficit.

**INCOME**

Money earned during an accounting period that results in an increase in
total assets (such as rents, interest, gifts, and commissions). Also
includes: revenues arising from sales of goods and services; excess of
revenues over expenses and losses for an accounting period (i.e., net
income).

**INFORMATION SYSTEM**

The organized collection, processing, transmission, and dissemination of
information in accordance with defined procedures, whether automated or
manual. Information systems include non-financial, financial and mixed
systems.

**INTEGRATED SYSTEM**

A single, integrated financial management system is a unified set of
financial systems and the financial portions of mixed systems
encompassing the software, hardware, personnel, processes (manual and
automated), procedures, controls, and data necessary to carry out
financial management functions, manage financial operations of the
agency, and report on the agency\'s financial status to central
agencies, Congress, and the public.

**INTEREST**

The service charge for the use of money or capital, paid at agreed
intervals by the user, commonly expressed as an annual percentage of
outstanding principal.

**INTEREST RATE**

The price charged per unit of money borrowed per year, or other unit of
time, usually expressed as a percentage.

**INTERNAL CONTROL**

"Internal Control" is a process, affected by an agency's management and
other personnel, designed to provide reasonable assurance that the
objectives of the agency are being achieved in the following categories:

> \- Effectiveness and efficiency of operations including the use of the
> entity's resources.

-   Reliability of financial reporting, including reports on budget
    execution, financial statements, and

other reports for internal and external use.

> \- Compliance with applicable laws and regulations.

**INTRA-GOVERNMENTAL PAYMENT AND COLLECTION SYSTEM (IPAC)**

Stands for: Intra-governmental Payment and Collection System, an
Internet application for intra-governmental payments. IPAC was developed
by the Treasury Department to replace the On-line Payment and Collection
System (OPAC) through the migration of the GOALS OPAC application from a
contractor-operated platform to a government owned and operated
platform.

**LOGGING**

Data used for audit trail purposes to record activity in the system
other than financial transactions, such as table changes.

**LOSS**

Any expense or irrecoverable cost, often referred to as a form of
non-recurring charge, an expenditure from which no present or future
benefit may be expected.

**MIXED SYSTEM**

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

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

Inflows of resources to the government that the government demands or
that it receives by donations. The inflows that it demands include
taxes, duties, fines, and penalties.

**NON-EXCHANGE TRANSACTION**

A transaction that arises when one party to a transaction receives value
without giving or promising value in return or one party to a
transaction gives or promises value without receiving value in return.

**OBLIGATIONS**

Amounts of orders placed, contracts awarded, services received, and
other transactions occurring during a given period that would require
payments during the same or a future period.

**OFFSET**

Withholding money payable by the government to, or held by the
government for a person or entity to satisfy a debt that the person or
entity owes the government.

**OTHER FINANCING SOURCES**

Inflows of resources that increase net position of a reporting entity
but that are not revenues or gains. Borrowing is not included as other
financing sources, since it does not increase the net resources of the
reporting entities.

**POSTED TRANSACTION**

Data from financial transactions that have been processed, accepted and
recorded in the system.

PRO FORMA TRANSACTIONS

Predetermined standard set of general ledger account postings associated
with an accounting event.

**PROPRIETARY ACCOUNTING**

Also known as financial accounting, a process that supports accrual
accounting and financial reporting that attempts to show actual
financial position and results of operations by accounting for assets,
liabilities, net position, revenues, and expenses.

RECORD

To give expression to a transaction on (or in) the books of account; to
enter.

**REIMBURSABLE OBLIGATION**

An obligation financed by offsetting collections credited to an
expenditure account in payment for goods and services provided by that
account.

**REIMBURSABLE ORDER**

May also be known as Customer Orders. Orders for goods and services to
be provided by the agency to another entity in return for payment.

**REIMBURSEMENTS**

Sums received as payment or advance payment for goods or services
furnished either to the public or to another Federal Government account.
If authorized by law, these sums are credited directly to specific
appropriation and fund accounts. These amounts are deducted from the
total obligations incurred (and outlays) in determining net obligations
(and outlays) for such accounts. Reimbursements are offsetting
collections. (See offsetting collections.)

**REMITTANCE**

The act of transmitting money, bills, or the like, in satisfaction of a
demand, or in discharge of an obligation.

**REQUIREMENTS**

*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 in operation and new systems
planned or under

development.

*Value-Added -* Value-added requirements describe optional features or
characteristics and may

consist of any combination of the following: (1) using state-of-the-art
technology, (2) employing

the preferred or best business practices, or (3) meeting the special
management needs of an

individual agency. *Value-added*, *optional*, and other similar
terminology may be used to describe

this category of requirements. Agencies should consider value-added
features when judging

systems options. The need for value-added features in agency systems is
left to the discretion of

each agency head.

**REVENUE**

Increase in the assets of an organization or the decrease in liabilities
during an accounting period, primarily from the organization's operating
activities. This may include sales of products (sales), rendering of
services (revenues), and earnings from interest, dividends, lease
income, and royalties.

**REVENUE ADJUSTMENT**

A contra revenue account that is used to report reduction in revenue
when realization is not probable (less likely than not). It includes,
returns, allowances, and price re-determinations but not credit losses
(due to the inability of the debtor to pay the established or negotiated
price).

**REVENUE SOURCE CODE**

Identifies and classifies the types of revenue and receipts as defined
by the user. For example, categories could be rental income, sales by
product type, and income by type of service performed.

**REVOLVING FUND**

A fund consisting of permanent appropriation and expenditures of
collections, from both the public and other governmental agencies and
accounts, that is earmarked to finance a continuing cycle of
business-type operations.

**SERVICE**

An intangible product or task rendered directly to a customer.

**SINGLE, INTEGRATED FINANCIAL MANAGEMENT SYSTEM**

A unified set of financial systems and the financial portions of mixed
systems encompassing the software, hardware, personnel, processes
(manual and automated), procedures, controls and data necessary to carry
out financial management functions, manage financial operations of the
agency and report on the agency\'s financial status to central agencies,
Congress and the public. Unified means that the systems are planned for
and managed together, operated in an integrated fashion, and linked
together electronically in an efficient and effective manner to provide
agency-wide financial system support necessary to carry out the
agency\'s mission and support the agency\'s financial management needs.

**SUBSIDIARY LEDGERS**

Records that provide detailed information about amounts recorded in the
general ledger accounts.

**SUSPENDED TRANSACTIONS**

Transactions that have not been completely processed and posted in the
system.

**SYSTEM**

Two or more individual items (equipment components) that are part of a
self‑contained group, that are joined physically, electronically, or
electromechanically, programmed or designed specially to rely on each
other, and cannot function independently if separated, and cannot be
easily disconnected and reconfigured to function with or within another
unit or \"system.\"

**TRANSACTION**

A particular kind of external event involving the transfer of something
of value concerning two or more entities. The transfer may be a two way
or one way flow of resources or of promises to provide resources.

**TRANSFER**

To move budgetary resources from one budget account to another.
Depending on the circumstances, the budget may record a transfer as an
expenditure transfer, which involves an outlay, or as a non-expenditure
transfer, which does not involve an outlay.

**TREASURY APPROPRIATION FUND SYMBOL (TAFS)**

A summary account established in the Treasury for each appropriation and
fund showing transactions to such accounts. Each such account provides
the framework for establishing a set of balanced accounts on the books
of the agency concerned. As used in OMB Circular No. A-34, this phrase
refers to general fund expenditure accounts, special fund expenditure
accounts, public enterprise revolving funds, intragovernmental revolving
funds, management funds, trust fund expenditure accounts, and trust
revolving fund accounts. Also known as Treasury Appropriation Symbol
(TAS).

**TREASURY APPROPRIATION SYMBOL (TAS)**

Synonymous with Treasury Appropriation Fund Symbol (TAFS).

**TREASURY OFFSET**

Collection of a delinquent debt by Treasury or a non-Treasury disbursing
officer through offset of a Federal payment. Federal payments of
benefits, tax refunds, salary, or vendors are subject to offset.

**TRUST FUNDS**

Accounts that are designated by law as trust funds, for receipts
earmarked for specific purposes and the associated expenditure of those
receipts. Collections may come from the public (e.g., earmarked taxes or
user charges) or from intra-budgetary transfers.

**UNDELIVERED ORDER**(**S)**

Contracts or orders issued by the ordering entity for goods and services
which have not yet been received and accepted, and for which the
liability has not yet been accrued.

**UNFILLED CUSTOMER ORDERS**

The amount of orders accepted from ordering entities within the U. S.
Government for goods and services to be furnished on a reimbursable
basis; or, in the case of transactions with the public, amounts
collected in advance for which the entity has not yet performed as
requested.

**UNIFIED SYSTEM**

Systems that are planned and managed together, operated in an integrated
fashion, and linked together electronically in an efficient and
effective manner to provide agency-wide financial system support
necessary to carry out the agency\'s mission and support the agency\'s
financial management needs.

**UNITED STATES GOVERNMENT STANDARD GENERAL LEDGER (USSGL)**

A uniform chart of accounts and pro forma transactions used to
standardize federal agency accounting and to support the preparation of
standard external reports required by central agencies. OMB and Treasury
Financial Management Service regulations require agencies to use the
USSGL to accumulate and report standard financial data. The USSGL chart
of accounts identifies and defines budgetary, proprietary, and
memorandum accounts to be used in agencies' accounting systems. The
USSGL is generic for the Federal Government, and is not intended to
reflect any single federal agency's accounting system. The Federal
Financial Management Improvement Act of 1996 requires agency financial
management systems to comply with the USSGL at the transaction level.

**USER CHARGE**

Fees assessed for the provision of government services and for the sale
or use of government goods or resources.

**USER FEES**

A subset of user charges that are authorized to be utilized solely to
support the program or activity for which they were levied.

**WRITE-OFF**

An action to remove an amount from an entity's assets or financial
resources. A write-off of a loan occurs when an agency official
determines, after all appropriate collection tools have been used, that
a debt is uncollectible. Active collection on an account ceases, and the
account is removed from an entity's receivables.

**(LEFT BLANK INTENTIONALLY)**

**Appendix C - Contributors**

**[Joint Financial Management Improvement Program (JFMIP) Steering
Committee]{.underline}**

Joseph L. Kull, Chair, Office of Management and Budget

Karen Cleary Alderman, Executive Director, JFMIP

Robert N. Reid, Department of the Treasury

Jeffrey C. Steinhoff, General Accounting Office

Kathleen M. Turco, General Services Administration

Kathleen M. McGettigan, Office of Personnel Management

**[Joint Financial Management Improvement Program]{.underline}**

Karen Cleary Alderman, Executive Director

Dan Costello, Project Manager

Steve Fisher

Dennis Mitchell

**[US Customs Service]{.underline}**

Jo Ellen Cohen, Project Sponsor, Deputy Chief Financial Officer

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

Karen Day

Margo Erny

Dale Theurer

Earl Thompson

Timothy Travers

Stephanie Zagrodniczek

**[Department of Housing and Urban Development]{.underline}**

Linda Rodgers

Wendy Stover

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

Bill Webber

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

Robert Bevilaqua

Karen Brown

Kenneth Gragg

Lee Lofthus

Frank Maguire

Deanna Payne

Jeanne Vinson

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

John Boakye

Lauretta Pridgen

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

Gayle Sienicki

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

*[US Customs Service]{.underline}*

> Jo Ellen Cohen, Project Sponsor, Deputy Chief Financial Officer

Connie Reynolds-Shine

*[Financial Management Service]{.underline}*

Marilyn Evans

Rose Miller

Judy Yuran

**[Department of Veterans Affairs]{.underline}**

Dan Alper

**[Equal Employment Opportunity Commission]{.underline}**

Jeffrey Smith, Chief Financial Officer

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

Robert Bramlett

**[Federal Communications Commission]{.underline}**

Mary Linda Norman

**[Federal Election Commission]{.underline}**

Glenn Luxenberg

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

Casey Keplinger

**[General Services Administration]{.underline}**

Maxine Gross

**[National Aeronautics & Space Administration]{.underline}**

David Mielke

**[National Indian Gaming Commission]{.underline}**

Irene Schrader

**[Nuclear Regulatory Commission]{.underline}**

Leah Tremper

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

Bob Loring

**[Small Business Administration]{.underline}**

Robert Montgomery

Jim Phillips

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

Kenn Goodman

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

John Boakye

Lauretta Pridgen

**[US Patent and Trademark Office]{.underline}**

Jeanette Kuendel

**Requests for JFMIP Publications**

JFMIP documents may be accessed electronically on the Internet in
electronic format, suitable for online viewing or printing.

**http://www.jfmip.gov**

To receive notification of JFMIP publications when they are issued, join
the JFMIP Mailing List through the JFMIP home page.

![](media/image8.wmf){width="2.26875in" height="0.7875in"}

[^1]: The requirements documents and other information are available on
    the JFMIP website at [www.jfmip.gov](http://www.jfmip.gov/).

[^2]: The Insurance Claims System Requirements will be developed and
    will address revenue associated with insurance programs.

[^3]: Statement of Federal Financial Accounting Standards, Number 7,
    paragraph 33.

[^4]: Statement of Federal Financial Accounting Standards, Number 4,
    Appendix K

[^5]: E-Government Strategy, Mark Forman, Associate Director for
    Information Technology and E-Government, Primary goals for the
    President's "Expanding E-Government" initiative.

[^6]: Statement of Federal Financial Accounting Standards, Number 4,
    Appendix K