Federal

Financial

Management

System

Requirements

Revenue

System

Requirements

JFMIP-SR-03-01

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

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
Revenue System Requirements 1

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,” whichoutlines 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 

 

1

 The requirements documents and other information are available on the JFMIP website at www.jfmip.gov. 
Introduction

2 Revenue System Requirements

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.
Revenue System Requirements 3

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.

♦ 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 agencie s 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 
Federal Financial Management Framework

4 Revenue System Requirements

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.
Federal Financial Management Framework

Revenue System Requirements 5

Illustration 1

Illustration 1

• Standard Reporting 

Requirements

U.S. Government 

Standard General Ledger

Core Financial System 

Requirements

Human Resources and 

Payroll Systems 

Requirements

Travel System 

Requirements

Seized Property and 

Forfeited Assets Systems 

Requirements

Direct Loan System 

Requirements

Guaranteed Loan System 

Requirements

Inventory System 

Requirements

System Requirements for 

Managerial Cost 

Accounting

Property Management 

System Requirements

•

•

•

•

•

•

•

•

•

•

•

•

•

• Revenue System 

Requirements

Benefit System 

Requirements

Acquisition Financial 

Systems Requirements

Other Standards

• Adaptation

Procedures

Training

Documentation

Conversion

Maintenance

•

•

•

•

•

•

•

•

•

Additional 

Agency 

Functional 

Requirements

Additional 

Agency Technical 

Requirements

Integration 

Strategy

Software/ 

Hardware 

Evaluation

• Software 

Selection

Standards/

Requirements Agency Implementation

Financial System Improvement Projects

Subject of

this report
Federal Financial Management Framework

6 Revenue System Requirements

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. 
Federal Financial Management Framework

Revenue System Requirements 7

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 agencywide 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 anothe r 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 costbeneficial 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).
Federal Financial Management Framework

8 Revenue System Requirements

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

Illustration 2
Federal Financial Management Framework

Revenue System Requirements 9

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 agencylevel 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 
Federal Financial Management Framework

10 Revenue System Requirements

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

Illustration 3 

Budget

Formulation

System

Non-Financial

Systems

Travel

System

Seized 

Property

& Forfeited

Assets

Systems

Guaranteed

Loan

System

Inventory

System

Grant Financial

System

Departmental Execu tive Informatio n System

Human 

Resources

& Payroll

Systems

Property

Management

Systems

Direct

Loan

System

Acquisition

System

Insurance Claim

System

Benefit System

 Revenue

System

Core

Financial

System

Financial

Reporting

System
Revenue System Overview

Revenue System Requirements 11

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:

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

 

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.
Revenue System Overview

12 Revenue System Requirements

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:

- 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

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”; valueadded 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). 

 

4

 Statement of Federal Financial Accounting Standards, Number 4, Appendix K
Revenue System Overview

Revenue System Requirements 13

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

Revenue System Requirements 15

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 

 

General Ledger 

Management

Payment 

Management

Cost 

Management

Reporting

Funds 

Management

Receivable 

Management

Illustration 4

Core Financial System Management
Relationship with Other Systems

16 Revenue Systems Requirements

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 

 

 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

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

Revenue System Requirements 17

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. 

 

5

 E-Government Strategy, Mark Forman, Associate Director for Information Technology and E-Government, Primary goals 

for the President’s “Expanding E-Government” initiative.
(LEFT BLANK INTENTIONALLY)
Customer Order Options

Revenue System Requirements 19

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

To support Customer Order Options, the Revenue System must 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)

 

6

 Statement of Federal Financial Accounting Standards, Number 4, Appendix K
Customer Order Options

20 Revenue System Requirements

• 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

To support Customer Order Options, the Revenue System should 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

Revenue System Requirements 21

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

To support revenue tracking and various methods of payment of the Remittance Options function, the 

Revenue System must 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
Remittance Options

22 Revenue System Requirements

- Date order filled. (RO-1)

Value-added Requirements

To support Remittance Options, the Revenue System should 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

Revenue System Requirements 23 

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

To support the Cashier Function, the Revenue System must 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

There are no value-added requirements for this function.
Proprietary and Budgetary Accounting

24 Revenue System Requirements

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

To support Proprietary and Budgetary Accounting functions of the USSGL, the Revenue System 

must 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 
Proprietary and Budgetary Accounting

Revenue System Requirements 25

 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)

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

• 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)
Proprietary and Budgetary Accounting

26 Revenue System Requirements

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

• 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. (BPA12)

• 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

There are no value-added requirements for this function.
Deposit Account Function

Revenue System Requirements 27

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

To support the Deposit Account Function, the Revenue System must provide the capability to:

• Create a new deposit account (escrow account) record with data element fields required in RO1 (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)
Deposit Account Function

28 Revenue System Requirements

• Notify customers (if specified) if their deposit account balance drops below a certain dollar 

amount. (DAS-6) 

• 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

There are no value-added requirements for this function. 
Transaction Validation

Revenue System Requirements 29

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

To support the Transaction Validation activity, the Revenue System must 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)
Transaction Validation

30 Revenue System Requirements

• 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)
Transaction Validation

Revenue System Requirements 31

• 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

To support the Transaction Validation activity, the Revenue System should 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

32 Revenue System Requirements

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

To support the Collection Process, the Revenue System must 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)
Collection Process

Revenue System Requirements 33

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

• Create a deposit record for a deposit ticket. Info must include: 

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

• 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

There are no value-added requirements for this function.
Revenue Recognition

34 Revenue System Requirements

Revenue Recognition

The Revenue Recognition function provides for the reclassification of revenue transactions into earned 

and unearned receipts.

Mandatory Requirements

To support the Revenue Recognition function, the Revenue System must 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)

• 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

There are no value-added requirements for this function. 
Receivable Management Process

Revenue System Requirements 35

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

To support the Receivable Management Process, the Revenue System must 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

There are no value-added requirements for this function.
Bill Generation

36 Revenue System Requirements

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

To support the Bill Generation function, the Revenue System must 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. (BG3)

• 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)
Bill Generation

Revenue System Requirements 37

• 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

To support the Bill Generation function, the Revenue System should 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

38 Revenue System Requirements

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

To support the Debt Management function, the Revenue System must 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)

• 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)
Debt Management

Revenue System Requirements 39

• Provide information to allow for the automated reporting of delinquent accounts to 

commercial credit bureaus. (DM-9)

• Create files of delinquent accounts for electronic submission to collection agencies and 

appropriate federal agencies. (DM-10)

• Maintain data for receivables referred to other federal agencies and outside organizations for 

collections and allow for electronic updates. (DM-11)

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

• 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;
Debt Management

40 Revenue System Requirements

- 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

To support the Debt Management function, the Revenue System should provide the capability to:

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

• 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 System Requirements 41

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

To support Revenue Estimation, the Revenue System must provide the capability to:

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

Value-added Requirements

To support Revenue Estimation, the Revenue System should 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)
Automated Reconciliation

Revenue System Requirements 43

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

To support the Automated Reconciliation function, the Revenue System must 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)

• 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

There are no value-added requirements for this function.
Performance Measurement

44 Revenue System Requirements

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

To support the Performance Measurement function, the Revenue System must 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

To support the Performance Measurement function, the Revenue System should provide the capability to:

• Track actual performance against established standards and to calculate variances for both 

system users and organizations. (PM-3)

• Collect cost information of performing collection activities. (PM-4)
Internal and External Reporting

Revenue System Requirements 45

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

To support the Internal and External Reporting function, the Revenue System must be able to:

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

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

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

• Report financial activity transactions by any element within the accounting classification 

structure (e.g., individual or hierarchical organization code, project code). (IER-6)

• Identify government, including inter- and intra- agency transactions and non-government 

revenues and expenses to support preparation of external reports. (IER-7)

• Produce report of transaction level details for the TAS/TAFS totals on the Financial 

Management Service (FMS) Form 224, Statement of Transactions. (IER-8)

• Support produc tion 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)
Internal and External Reporting

46 Revenue System Requirements

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

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

• Support reporting of FACTS I and FACTS II data as required by the core financial 

management system. (IER-11)

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

- 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

To support the Internal and External Reporting function, the Revenue System should provide the 

capability to:
Internal and External Reporting

Revenue System Requirements 47

• “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)

• Save customized report/query routines and/or results with the capability to transmit either 

electronically. (IER-16)

• Report process compatibility with both database and application security protocols. (IER-17)

• Perform exception and data ranking reporting based on user-defined parameters. (IER-18)

• Define and modify customized reports. (IER-19)

• 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

48 Revenue System Requirements

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

To support the Audit Trail function, the Revenue System must 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

To support the Audit Trail function, the Revenue System should 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

Revenue System Requirements 49

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

To support On-Line Query Capability, the Revenue System must 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

To support the On-Line Query function, the Revenue System shouldprovide the capability to:

• Generate reports by geographic location. (OLQ-12) 
Ad-Hoc Query

50 Revenue System Requirements

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

To effectively support Ad-Hoc Query Capability, the Revenue System must:

• 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

To provide additional Ad-Hoc Query Capability, the Revenue System should 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 
Ad-Hoc Query

Revenue System Requirements 51

 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

52 Revenue System Requirements

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

To support the Records Retention function, the Revenue System must 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

There are no value-added requirements for this function.
Interface

Revenue System Requirements 53

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

To support Interface requirements, the Revenue System must 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)

• 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

54 Revenue System Requirements

• 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” (M03-01). (I-7)

• Link to other applications and data sources (e.g., strategic plans, performance measures and 

data warehouse). (I-8)

Value-added Requirements

There are no value-added requirements for this function.
Security

Revenue System Requirements 55

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

To support the Security function, the Revenue System must provide the capability to:

• Allow entry into system only to those individuals who are authorized and only during 

times authorized. (S-1)

• 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)
Security

56 Revenue System Requirements

• 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. (S10)

• 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

To support Security function, the Revenue System should 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

Revenue System Requirements 57

Appendix A – Authoritative References

Authoritative References Topic Source

Federal Credit Reform Act of 1990 Loans Congress (Statutory)

Rehabilitation Act of 1973 Accessibility for the 

Disabled

Congress (Statutory)

31 U.S.C. 1535 - Economy Act Reimbursable Agreements

Between Federal Entities

Congress (Statutory)

PL 103-356 Government Management Reform Act (Authorizes Franchise 

Fund Pilots to facilitate Inter-Governmental Cross-Servicing) 

Reimbursable Agreements

Between Federal Entities

Congress (Statutory)

31 U.S.C. 6501 – 6508 Authority for Intergovernmental

Cooperation

Intergovernmental 

Agreements 

Congress (Statutory)

31 U.S.C. 3711; Claims Collection Standards (31 CFR Parts 900-904); 

Debt Collection Act of 1982; Debt Collection Improvement Act of 1996

Receivables & Loans Congress (Statutory)

31 U.S.C. 9701 – Independent Offices Appropriation Act of 1952 User Charges Congress (Statutory)

Title 31 Code of Federal Regulations Subtitle B Regulations on Money and 

Finance

National Archives and Records 

Administration

Title 12, Section 265, Code of Federal Regulations Insured banks as depositories 

of public money

National Archives and Records 

Administration

OMB Circular A-11 Budget Formulation and Execution (formerly A-34) Budgetary Office of Management & Budget

OMB Circular A-25 - User Charges User Charges Office of Management & Budget

OMB Circular A-123 Management control requirements and testing Internal Management 

Controls

Office of Management & Budget

OMB Circular A-127 Requires a single, integrated financial management 

system

Single Integrated Financial 

System

Office of Management & Budget

OMB Circular A-129 Policies for Managing Federal Credit Programs and 

 Non-Income Tax Receivables

Receivables & Loans Office of Management & Budget

OMB Bulletin 01-09 provides requirements for the form and content of 

Agency Financial Statements

Form & Content of Financial

Statements

Office of Management & Budget

SFFAS 2 - Accounting for Direct Loans and Loan

Guarantees, and SFFAS 18 – Amendments

Loans FASAB

SFFAC 2 - Entity and Display External Reporting and

Disclosure

FASAB

SFFAC 3 – Management’s Discussion and Analysis External Reporting and

Disclosure

FASAB

SFFAS 4 - Managerial Cost Accounting Concepts and Standards Cost Accounting FASAB

SFFAS 7 – Accounting for Revenues and Other Financing Sources Revenues/Financing Sources FASAB

Volume I – Parts 5 & 6 Treasury Financial Manual

Volume 5 – Ca$hlink

Governmentwide Deposit 

and Collection Requirements

U.S. Department of the Treasury, 

Financial Management Service

Treasury Financial Manual Supplemental Guidance - Cash Management 

Made Easy

Cash Management U.S. Department of the Treasury, 

Financial Management Service

Core Financial Systems Requirements Overall Federal Financial 

System Requirements

JFMIP 

Systems Requirements on Direct and Guaranteed Loans Loans JFMIP
(LEFT BLANK INTENTIONALLY)
Appendix B: Glossary

Revenue System Requirements 59

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.
Appendix B - Glossary

60 Revenue System Requirements

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.
Appendix B: Glossary

Revenue System Requirements 61

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.
Appendix B - Glossary

62 Revenue System Requirements

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.
Appendix B: Glossary

Revenue System Requirements 63

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 intragovernmental 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.
Appendix B - Glossary

64 Revenue System Requirements

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.
Appendix B: Glossary

Revenue System Requirements 65

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).
Appendix B - Glossary

66 Revenue System Requirements

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).
Appendix B: Glossary

Revenue System Requirements 67

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.
68 Revenue System Requirements

(LEFT BLANK INTENTIONALLY)
Appendix C: Contributors

Revenue System Requirements 69

Appendix C - Contributors

Joint Financial Management Improvement Program (JFMIP) Steering Committee

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

Karen Cleary Alderman, Executive Director

Dan Costello, Project Manager

Steve Fisher

Dennis Mitchell

US Customs Service

Jo Ellen Cohen, Project Sponsor, Deputy Chief Financial Officer

Department of Agriculture

Karen Day

Margo Erny

Dale Theurer

Earl Thompson

Timothy Travers

Stephanie Zagrodniczek

Department of Housing and Urban Development

Linda Rodgers

Wendy Stover

Department of Interior

Bill Webber

Department of Justice

Robert Bevilaqua

Karen Brown

Kenneth Gragg

Lee Lofthus

Frank Maguire

Deanna Payne

Jeanne Vinson

Department of State

John Boakye

Lauretta Pridgen
Appendix C: Contributors

70 Revenue System Requirements

Department of Transportation

Gayle Sienicki

Department of the Treasury 

US Customs Service

Jo Ellen Cohen, Project Sponsor, Deputy Chief Financial Officer

Connie Reynolds-Shine

Financial Management Service

Marilyn Evans

Rose Miller

Judy Yuran

Department of Veterans Affairs

Dan Alper

Equal Employment Opportunity Commission

Jeffrey Smith, Chief Financ ial Officer

Federal Accounting Standards Advisory Board

Robert Bramlett

Federal Communications Commission

Mary Linda Norman

Federal Election Commission

Glenn Luxenberg

General Accounting Office

Casey Keplinger

General Services Administration

Maxine Gross

National Aeronautics & Space Administration

David Mielke

National Indian Gaming Commission

Irene Schrader

Nuclear Regulatory Commission

Leah Tremper

Office of Personnel Management

Bob Loring
Appendix C: Contributors

Revenue System Requirements 71

Small Business Administration

Robert Montgomery

Jim Phillips

Social Security Administration

Kenn Goodman

Department of State

John Boakye

Lauretta Pridgen

US Patent and Trademark Office

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.
1990 K Street NW

Suite 430

Washington, DC 20006