![](media/image1.wmf)

# Foreword

This document represents the latest update to the Core Financial System
Requirements document first issued by JFMIP in January 1988. Changes
made to this version reflect recent changes in laws, regulations, and
central agency reporting systems, such as the Department of Treasury's
new Governmentwide Accounting (GWA) program. It also incorporates
updates to existing requirements. In many cases:

-   Existing requirement text has been clarified

-   Redundant or outdated requirements have been deleted

-   Requirement priorities (mandatory or value added) have been updated

-   New requirements have been added to reflect current business
    practices.

    This document is a part of the Federal Financial Management Systems
    Requirements document series. FFMSR addresses the joint goals of the
    Chief Financial Officers Council and the Office of Management and
    Budget to improve the efficiency and quality of financial management
    in the Federal Government. The FFMSR document series also supports
    key provisions of the:

-   Chief Financial Officers Act (CFO Act) of 1990

-   Government Performance and Results Act (GPRA) of 1993

-   Government Management Reform Act (GMRA) of 1994

-   Federal Financial Management Improvement Act (FFMIA) of 1996.

    Collectively, these acts mandate the use of financial systems to
    facilitate the effective management of Government programs and
    services and the proper stewardship of public resources.

    This update demonstrates a strong commitment by the Federal CFO
    community to continually improve the quality of financial services.
    The CFO community's support in developing these requirements was
    invaluable. We thank the CFO Council's Financial System Integration
    Committee and the many agency representatives that participated in
    improving this document.

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

# Contents {#contents .unnumbered}

Abbreviations vii

Introduction 1

Federal Financial Management Framework 2

FFMSR Model 2

Framework Goals 3

Requirements Interpretation Guidelines 4

Mandatory versus Value-Added Requirements 4

Internal Control Requirements 5

Query versus Report Requirements 5

Requirements Applicability 6

Core Financial System Overview 8

Core System Functions 8

Core Financial System Functional Requirements Summary 9

System Management Function 11

Accounting Classification Process 11

Document and Transaction Control Process 13

Document Referencing and Modification Process 17

System-Generated Transactions Process 20

Audit Trails Process 22

General Ledger Management Function 24

General Ledger Account Definition Process 24

Transaction Definition Process 25

General Ledger Updating and Editing Process 26

Upward/Downward Spending Adjustment Process 27

General Ledger Analysis and Reconciliation Process 28

Accounting Period Maintenance and Closing Process 29

Financial Reporting Process 30

Budgetary Resource Management Function 34

Budget Planning Process 34

Budget Preparation Process 35

Budget Authority Process 37

Funds Distribution Process 38

Funds Control Process 40

Funds Status Process 43

Payment Management Function 46

Payee Information Maintenance Process 46

Accounts Payable Process 49

Invoicing Process 50

Disbursing Process 53

Payment Follow-Up Process 59

Receivable Management Function 62

Customer Information Maintenance Process 63

Receivables and Billing Process 64

Debt Management Process 67

Collections and Offsets Process 70

Cost Management Function 73

Cost Setup and Accumulation Process 73

Cost Distribution Process 74

Cost Reporting Process 75

Fund Balance with Treasury Management Function 76

Treasury Information Maintenance Process 76

Payment Confirmation Process 77

Reconciliation and Reporting Process 78

Technical System Requirements 82

General Design/Architecture 82

Infrastructure 83

User Interfaces 84

Interoperability 85

Workflow/Messaging 86

Document Management 87

Internet Access 88

Security 88

Operations 90

Ad Hoc Query 91

Documentation 93

System Performance 94

Appendix A---References

Appendix B---Requirement Drafting Guidelines

Appendix C---Standard Core Financial System Reports

Appendix D---Contributors

Figures

Figure 1: FFMSR Components 2

Figure 2: System Functions 8

Figure 3: Technical Requirement Groupings 9

# Abbreviations

ACC Accounting Classification Code

ACE Accounting Classification Element

ACH Automated Clearing House

ACR Agency Confirmation Report

ALC Agency Location Code

ANSI American National Standards Institute

API Application Program Interface

ATB Adjusted Trial Balance

BEA Budget Enforcement Act of 1990

BETC Business Event Type Code

BPA Blanket Purchase Agreement

CCD Cash Concentration or Disbursement

CCD+ Cash Concentration or Disbursement Plus Addendum

CCR Central Contractor Registration

CFO Chief Financial Officer

CFOC Chief Financial Officers Council

CFR Code of Federal Regulations

CMIA Cash Management Improvement Act

COTR Contracting Office(r) Technical Representative

COTS Commercial Off-the-Shelf

CTX Corporate Trade Exchange

CVF Current Value of Funds

DBA Doing Business As

DCIA Debt Collection Improvement Act of 1996

DMA Document Management Alliance

DO Disbursing Office(r)

DOJ Department of Justice

DT/DV Deposit Ticket/Deposit Voucher

DUNS Data Universal Numbering System

ECS Electronic Certification System

EDI Electronic Data Interchange

EFT Electronic Funds Transfer

FACTS I Federal Agencies Centralized Trial Balance System I

FACTS II Federal Agencies Centralized Trial Balance System II

FAR Federal Acquisition Regulation

FASAB Federal Accounting Standards Advisory Board

FAST Federal Account Symbols and Titles

FBWT Fund Balance with Treasury

FFMIA Federal Financial Management Improvement Act of 1996

FFMSR Federal Financial Management System Requirements

FMFIA Federal Managers' Financial Integrity Act of 1982

FMS Department of the Treasury Financial Management Service

FOB Free On Board

FSB Financial Systems Branch

FSC Federal Supply Classification

FTE Full-Time Equivalent

GAO General Accountability Office

GMRA Government Management Reform Act of 1994

GOALS Government Online Accounting Link System

GPRA Government Performance and Results Act of 1993

GFRS Governmentwide Financial Report System

GSA General Services Administration

GWA Governmentwide Accounting

IAE Integrated Acquisition Environment

IAS Information Access System (GOALS II)

IDD International Direct Deposit

IGTE Intra-governmental Transaction Exchange

IPAC Intra-governmental Payment and Collection System

IRS Internal Revenue Service

IT Information Technology

MAPI-WF Messaging API-Workflow

MIME Multipurpose Internet Mail Extensions

MTS Metric Tracking System

MVS Multiple Virtual System

NACHA National Automated Clearing House Association

NAICS North American Industry Classification System

NARA National Archives and Records Administration

NIST National Institute of Standards and Technology

ODA/ODIF Open Document Architecture/Open Document Interface Format

ODMA Open Document Management Architecture

OFFM Office of Federal Financial Management

OMB Office of Management and Budget

OPAC Online Payment and Collection System

OS Operating System

PDF Portable Document Format

PKI Private Key Infrastructure

PPD Prearranged Payment and Deposit

PPD+ Prearranged Payment and Deposit Plus Addendum

RFC Regional Finance Center

PSC Product Service Code

RTN Routing Transit Number

SAM Shared Accounting Module

SCS Secure Payment System

SFFAS Statements of Federal Financial Accounting Standards

SGML Standard Generalized Markup Language

SIC Standard Industrial Classifications

SQL Structured Query Language

SPS Secure Payment System

TAFS Treasury Appropriation Fund Symbol

TAS Treasury Account Symbol

TCP/IP Transmission Control Protocol/Internet Protocol

TDO Treasury Disbursing Office

TFM Treasury Financial Manual

TIN Taxpayer Identification Number

TROR Treasury Report on Receivables

U.S.C. United States Code

U.S. SGL U.S. Standard General Ledger

VIM Vendor Independent Messaging

VPN Virtual Private Network

WFMC Workflow Management Coalition

XML Extensible Markup Language

# Introduction

This document is part of a series of publications entitled *Federal
Financial Management System Requirements (FFMSR)*. FFMSR specifies the
mandatory functional and technical requirements that agency financial
management systems must meet in order to be considered compliant with
Federal standards as mandated by the Federal Financial Management
Improvement Act (FFMIA).

OMB Circular A-127, *Financial Management Systems*, sets forth general
policies for Federal financial management systems. Each agency is
required to establish and maintain a single integrated financial
management system. Each agency must have an ongoing financial systems
improvement planning process and perform periodic reviews of its
financial system capabilities. In addition, each agency must maintain
financial management system components that comply with uniform Federal
accounting concepts and standards promulgated by the Federal Accounting
Standards Advisory Board (FASAB) in its Statements of Federal Financial
Accounting Standards (SFFAS), which constitute generally accepted
accounting principles for the Federal Government. A complete list of
laws, regulations and governmentwide standards that are addressed by
specific requirements can be found in Appendix A, References.

Establishing governmentwide system requirements promotes a common
understanding among private- and public-sector financial managers and
agency program managers regarding Core system functional and technical
capabilities. Such requirements serve as a tool for the oversight
agencies to evaluate systems. They help justify agency system
improvements or replacements. They also help organize the private-sector
market by communicating mandatory functionality that commercial software
must provide to Federal agencies and identifying value-added features
desired by Federal agencies.

The next section of this document sets forth the framework for the
establishment and maintenance of an integrated Federal financial
management system. The specific Core financial system requirements are
presented in detail in the functional and technical requirements
sections that follow. These requirements, which are reviewed and updated
periodically, incorporate the latest changes in laws and regulations
governing Federal financial systems, such as the Intra-governmental
Payment and Collection System (IPAC) and Central Contractor Registration
(CCR). Appendices provide references, a glossary, a summary of external
reporting requirements, requirements drafting guidelines and a list of
agencies that participated in updating this document.

# Federal Financial Management Framework

The *Framework for Federal Financial Management Systems* document
describes the basic elements of a model for integrating financial
management systems in the Federal Government. It provides a foundation
for all systems included in the FFMSR. The Framework was republished in
April 2004. This updated document description does the following:

-   Explains how Federal financial management supports Federal agencies
    and the mission of government as an inherent component of the
    delivery of all Federal programs

-   Sets forth financial management performance goals, outcomes, and
    desired capabilities and characteristics that future systems must be
    designed to meet

-   Describes financial management functions, information flows, and
    systems that support the Federal agencies in carrying out programs

-   Describes the agency and central agency roles

-   Links financial management to program performance and describes how
    it supports budget and performance integration

-   Presents the business needs, performance goals, and information
    architecture that drive financial system requirements.

## FFMSR Model

The current model comprises the Framework, Core, Managerial Cost
Accounting, and 13 subsidiary financial or mixed systems. Such systems
must be able to provide consistent, standardized information for program
managers, financial managers, agency executives, and oversight
organizations, and they must meet Federal statutes, regulations, and
standards.

Figure 1 provides an architectural view of the current financial
management applications described by the FFMSR series. The system
functions and technical requirement groupings that constitute the Core
application are reflected later in Figures 2 and 3.

![](media/image3.wmf){width="3.661111111111111in"
height="2.452777777777778in"}

**Figure 1:** **FFMSR Components**

## Framework Goals

The following financial management system performance goals, outlined in
the Framework document, are applicable to all financial management
systems. All financial management systems **[must]{.underline}** deliver
the following:

-   Demonstrate compliance with accounting standards and requirements

-   Provide timely, reliable, and complete financial management
    information for decision making at all levels of government

-   Meet downstream information and reporting requirements with
    transaction processing data linked to transaction engines

-   Accept standard information integration and electronic data to and
    from other internal, governmentwide, or private-sector processing
    environments

-   Provide for "one-time" data entry and reuse of transaction data to
    support downstream integration, interfacing, or business and
    reporting requirements

-   Build security, internal controls, and accountability into processes
    and provide an audit trail

-   Be modular in design and built with reusability as an objective

-   Meet the needs for greater transparency and ready sharing of
    information

-   Scale to meet internal and external operational, reporting, and
    information requirements for both small and large entities.

# Requirements Interpretation Guidelines

This document contains a list of functional capabilities (i.e.,
established governmentwide requirements) that a qualified system must
deliver to be considered qualified for agency acquisition. This document
does not address accounting policy or procedures. The following are
examples of system capabilities covered by this document:

-   Produce an SF 133 report

-   Process a receiving report

-   Generate a FACTS II data file.

The requirements in this document represent a complete list of
functional capabilities deemed mandatory for qualified financial
management systems by the government. These requirements should not be
considered to be a complete system specification. They do not, for
example, specify computing logic needed to summarize SF 133 reported
information, to edit receiving data, or to classify GL data for FACTS
reporting purposes

Covered requirements are organized by function, process, and, in some
cases, an activity. Functions represent major office responsibility
areas such as accounts payable. Processes are common system-supported
tasks such as disbursing. Activities are sub processes; and are used
when a finer grouping of requirements is helpful.

In all cases, the system is responsible for performing specified
actions. Unless otherwise stated within a requirement's text, the system
must execute it automatically. For example, if a requirement states
"process an obligation," the system is expected to capture obligation
data and to record related GL transactions without user
intervention**.**

The remainder of this section provides guidance on how to interpret
requirements text and attributes. Specific guidance is provided for the
following requirement categories:

-   Mandatory versus value-added requirements

-   Internal control requirements

-   Query versus report requirements.

Other key words that affect how agencies are to interpret requirements
text are defined in Appendix B, Requirement Drafting Guidelines.

## Mandatory versus Value-Added Requirements

Every requirement contained in this document has been prioritized as
being mandatory or value added. These terms are defined as follows:

-   **Mandatory.** Mandatory requirements describe discrete capabilities
    that a fully compliant financial system must deliver. Collectively,
    mandatory requirements represent the minimum level of functionality
    needed to establish a financial system based on Federal laws,
    regulations, and governmentwide consensus. Mandatory requirements
    apply to existing systems and new systems that are planned for
    acquisition or are under development. Commercial packages are tested
    for compliance with mandatory requirements. Agency heads can use
    mandatory requirements as a basis for determining substantial
    compliance of their systems under FFMIA.

-   **Value-added.** Value-added requirements are desirable system
    features. Value-added requirements may consist of any combination of
    the following: use state-of-the-art technology, employ preferred or
    best business practices, or meet the special management needs of an
    individual agency. Agencies should consider value-added features
    when judging system options. The need for these value-added features
    is left to the discretion of each agency head.

Within this document, mandatory system requirements are indicated by the
word "must"---for example, a qualified system "must provide automated
functionality to update all general ledger account balances based on a
single input transaction". Value-added requirements are indicated by the
key word "should"---for example, a system "should provide automated
functionality to import budget formulation data".

## Internal Control Requirements

OMB Circular A-123, *Management's Responsibility for Internal Controls*,
requires agencies to operate systems with appropriate internal controls
to ensure the accuracy of data, completeness and consistency of
transaction processing, and reporting. Automatic internal control
capabilities needed to meet the provisions of A-123 are expected to be
integrated into every qualified financial management system.

The Core requirements that specify validations be performed on invoice
data before they can be certified and system enforced separation of
duties are examples. In addition, the technical requirements found in
this document incorporate a full range of data and user access security
controls. Ultimately, however, each agency is responsible for
implementing the internal controls they need to ensure that their
financial systems are operated in a secure and effective manner.

## Query versus Report Requirements

Qualified systems must maintain complete, reliable, consistent, timely,
and useful financial management information. Such information enables
agency management, programs, agencies, divisions, bureaus, and other
subunits to carry out their fiduciary responsibilities; deter fraud,
waste, and abuse of resources; and facilitate efficient and effective
delivery of government services. Methods of delivering financial
information to agency users include queries and reports.

-   **Query.** When a functional requirement refers to a "query," the
    Core system must be capable of displaying the requested information
    online. In addition, query features, such as drill-down or desktop
    downloading must be delivered where specified. As a rule, query
    requirements must be met using software that is integrated into the
    Core system.

-   **Report.** When a functional requirement refers to a "report," the
    application must be capable of generating a formatted, hard-copy
    report or printable report file containing specified information.
    Additional reporting formats such as online display or data file
    extracts must be delivered where specified. As a rule, reporting
    requirements can be met using software that is integrated into the
    Core system, using a separate reporting software package, or a
    combination of both.

All queries and reports specified in this document are considered
"standard" and must be delivered as part of the qualified Core system
product. A summary of all standard external reports can be found in
Appendix C.

## Requirements Applicability

FFMIA requires agencies to install integrated financial systems that
substantially comply with the following:

-   Government-established system requirements

-   Accounting standards

-   U.S. Government Standard General Ledger (U.S. SGL) at the
    transaction level.

OMB Circular A-127, *Financial Management Systems*, further defines
government-established system requirements to include the items
published in this document. A separate OMB memorandum, *FFMIA
Implementation Guidance*, reinforces this mandate. This guidance,
however, exempts agencies from meeting individual system requirements
relating to business processes they do not perform. For example, an
agency that does not issue grants does not need to meet grant-related
system requirements. Although FFMIA compliance is subject to audit, the
final determination of the applicability of any cited requirement rests
with agency management.

OMB Circular A-130, *Management of Federal Information Resources*,
requires agencies to use commercial off-the-shelf (COTS) software to
reduce costs, improve the efficiency and effectiveness of financial
system improvement projects, and reduce the risks inherent in developing
and implementing a new system. In the case of financial management
systems, Circular A-127 limits agencies to the acquisition of COTS
products that have been certified through a formal test process. To
accomplish testing, A-127 assigns the Chief Financial Officers Council
(CFOC) responsibility for doing the following:

-   Developing/administering the certification test

-   Notifying the General Services Administration (GSA) when a package
    successfully completes a test

-   Providing interested parties with information on Core requirements
    and related testing scenarios.

COTS packages are periodically tested against the mandatory system
requirements specified in this document. Through this test process,
packages demonstrate their ability to comply with all mandatory
requirements as interpreted by the Financial System Integration Office
(FSIO). Packages that pass the test are deemed qualified for Federal
agency acquisition.

Agencies, however, have considerable leeway in how they elect to use
tested capabilities. For example, the funds distribution process area
includes a requirement that packages be capable of recording spending at
levels below where funding was distributed. Although this is a mandatory
requirement for vendor software, an agency is not required to control
spending in this manner.

Packages are also not expected to support illegal or inappropriate
application of individual requirements. For example, the requirement to
synchronize vendor data with data maintained in the Central Contractor
Registry (CCR) does not apply to a payee exempt from CCR registration.
In practice, the applicability of individual requirement provisions
depends on business circumstances.

# Core Financial System Overview

Federal agencies disburse over \$2 trillion in appropriated funds
annually. Financial and program managers throughout government are
fiscally responsible for these resources and for the program results
they achieve. To do their jobs, they need ready access to detailed
financial information essential to formulating agency budgets,
monitoring program operations, and reporting performance as maintained
in a proper and reliable financial system. Such systems support the
following management objectives:

-   *Accountability*, by providing accurate information needed to inform
    taxpayers, Congress, and agency personnel in terms they can readily
    understand, on how the Nation's tax dollars are spent, and how
    Federal assets are protected

-   *Efficiency, economy, and effectiveness*, by supporting delivery of
    efficient, economical, and effective delivery of services to the
    Federal agency's internal and external customers (e.g., individuals,
    contractors, partnerships, state and local governments, other
    Federal agencies/organizations, the military, and foreign
    governments)

-   *Decision making*, by providing Congress, agency heads, and program
    managers with timely reports linking financial results and program
    data so that policy and program decisions can be accurately
    identified, tracked, and forecasted.

Furthermore, Core financial systems, whether they are being implemented
or are currently in use, must operate in accordance with laws,
regulations, and judicial decisions. This document establishes a set of
comprehensive functional requirements for a proper and reliable Core
financial management system.

## Core System Functions

Core financial systems provide specific functional capabilities
necessary for managing a general ledger, controlling spending, making
payments, managing receivables, measuring costs, reconciling the
agency's Fund Balance with Treasury, and reporting in the Federal
environment. Figure 2 depicts the major functions within the Core
financial system.

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

**Figure 2: System Functions**

In practice, a single financial event can require processing in multiple
system areas. A good example is a payment that includes additional
charges not previously recorded, such as interest costs due to late
payment or additional shipping charges. This transaction would
(1) originate in the Payment Management function; (2) be edited for
funds availability and update balances in the Budgetary Resource
Management function; (3) possibly update cost amounts controlled by the
Cost Management function; (4) update the general ledger balances in the
specified General Ledger Management function; and (5) update audit
trails used in the System Management function.

In addition, technical requirements have been established to help ensure
that a Core financial system is fully supported and capable of
processing the workload required. From a technical perspective, the Core
system must provide transaction processing integrity and general
operating reliability; use standard procedures for installation,
configuration, and operations; provide seamless integrated workflow
processing; have the ability to query, access, and format information;
and be well documented. It must not conflict with other administrative
or program systems or with other agency-established IT standards. Figure
3 depicts the major technical groups within the Core financial system.

![](media/image5.wmf){width="4.095833333333333in"
height="2.803472222222222in"}

**Figure 3: Technical Requirement Groupings**

Most technical requirements are stated in general terms to give vendors
maximum flexibility in designing compliant financial systems. Individual
agencies are encouraged to add specific interoperability, system
performance, workload, and access requirements unique to their
respective IT environments when evaluating packages for acquisition.

## Core Financial System Functional Requirements Summary

The following sections identify specific requirements that every
qualified Core financial system must deliver. These requirements provide
the basic information and control needed by agencies to perform
financial management functions, manage the financial operations of an
agency, and report on the agency's financial status to central agencies,
Congress, and the public.

The major functions supported by a Core financial system and the
abbreviations used in this document to identify related requirements are
as follows:

-   System Management (SM)

-   General Ledger Management (GL)

-   Budgetary Resource Management (FM)

-   Payment Management (PM)

-   Receivable Management (RM)

-   Cost Management (CM)

-   Fund Balance with Treasury Management (FB).

The ID assigned to each requirement defines its function, process, and
sequence. For example, the first requirement in the first process
associated within the System Management function is identified by
SMA-01. "SM" stands for System Management, "A" represents the first
defined process under system management (in this case, "accounting
classification"), and "01" is a unique sequence number.

# System Management Function

The System Management function ensures that the capabilities exist to
capture, classify, process, and report the financial activity of Federal
agencies. The System Management function establishes the framework for
sharing data among components of an agency's single integrated financial
management system. This function also ensures that transactions are
processed consistently and completely and that appropriate audit trails
are maintained. The System Management function consists of the following
processes (the prefixes assigned to the requirements are noted in
parentheses):

-   Accounting Classification (SMA)

-   Document and Transaction Control (SMB)

-   Document Referencing and Modification (SMC)

-   System-Generated Transactions (SMD)

-   Audit Trails (SME)

## Accounting Classification Process

OMB Circular A-127, *Financial Management Systems*, requires financial
management systems to reflect an agency-wide financial information
classification structure that is consistent with the U.S. SGL, provides
for tracking of specific program expenditures, and covers financially
related information.

The accounting classification process provides the means for
categorizing financial information along several dimensions to support
financial management and reporting functions. The data elements that a
particular agency includes in its accounting classification will depend
on data aggregation requirements for preparation of financial statements
under the CFO Act, the appropriation structure, and other reporting and
management needs of the agency.

Within each department or agency, the accounting classification elements
and definitions must be standardized to ensure uniform and efficient
accounting treatment, classification, and reporting. The Accounting
Classification Management process provides a consistent basis for the
following activities:

-   Capturing financial activity with all of the data necessary to
    identify the funding used, the organization charged, the type of
    expense or asset affected, and the program or project involved

-   Recording data at the lowest level of detail and summarizing or
    rolling it up to higher levels in a standardized manner for
    reporting purposes

-   Comparing and combining similar programs across agencies and
    calculating overall program results

-   Integrating budget and accounting activities by synchronizing their
    accounting classifications and relationships.

##### Mandatory Requirements

To support the Accounting Classification Management process, the Core
financial system **[must]{.underline}** provide automated functionality
to do the following:

+--------+-------------------------------------------------------------+
| SMA-01 | **Accounting classification---**Maintain an accounting      |
|        | classification structure that includes the following        |
|        | elements:                                                   |
|        |                                                             |
|        | > • Treasury Account Symbol                                 |
|        | >                                                           |
|        | > • Budget fiscal year                                      |
|        | >                                                           |
|        | > • Internal fund code                                      |
|        | >                                                           |
|        | > • Organization                                            |
|        | >                                                           |
|        | > • Program                                                 |
|        | >                                                           |
|        | > • Project                                                 |
|        | >                                                           |
|        | > • Activity                                                |
|        | >                                                           |
|        | > • Cost center                                             |
|        | >                                                           |
|        | > • Object class                                            |
|        | >                                                           |
|        | > • Revenue source                                          |
|        | >                                                           |
|        | > • Budget function                                         |
|        | >                                                           |
|        | > • Budget sub-function code                                |
|        | >                                                           |
|        | > • Accounting period.                                      |
|        |                                                             |
|        | Maintain each classification element independently. For     |
|        | example, budget fiscal year must be maintained as a         |
|        | separate value from the period of availability component in |
|        | the TAFS.                                                   |
+--------+-------------------------------------------------------------+
| SMA-02 | **Additional accounting classifications---**Define five     |
|        | additional accounting classifications elements, including   |
|        | element titles and valid values.                            |
+--------+-------------------------------------------------------------+
| SMA-03 | **Classify transactions---**Classify transactions by        |
|        | standard and agency-defined accounting classification       |
|        | elements.                                                   |
+--------+-------------------------------------------------------------+
| SMA-04 | **Short classification codes---**Derive full accounting     |
|        | classifications on transactions from abbreviated user       |
|        | input. Examples of methods include: entering shorthand      |
|        | codes, deriving elements from an entered field, or          |
|        | providing users with a list of values from which to choose. |
+--------+-------------------------------------------------------------+
| SMA-05 | **Accounting classification tables---**Add, change, or      |
|        | deactivate elements of the accounting classification        |
|        | structure and define valid ACE values without programming   |
|        | changes (e.g., through online table updates).               |
+--------+-------------------------------------------------------------+
| SMA-06 | **Accounting classification effective date---**Capture an   |
|        | effective date for accounting classification structure and  |
|        | valid value changes. Activate or deactivate accounting      |
|        | classification changes based on effective date.             |
+--------+-------------------------------------------------------------+
| SMA-07 | **Accounting activity query---**Query document accounting   |
|        | data. Parameters include all standard and agency-defined    |
|        | accounting classification elements. Result is a list of     |
|        | selected document accounting lines. Display the document    |
|        | number, accounting classification elements and accounting   |
|        | line amounts. Drill down from accounting lines to GL        |
|        | transaction details, including transaction numbers,         |
|        | transaction and system dates and debits and credits.        |
+--------+-------------------------------------------------------------+
| SMA-08 | **Revenue source code structure---**Maintain a revenue      |
|        | source code structure to classify types of revenue and      |
|        | receipts as defined by the agency, such as rental income,   |
|        | sales by product type and income by type of service         |
|        | performed.                                                  |
+--------+-------------------------------------------------------------+
| SMA-09 | **Treasury Account Symbol---**Maintain a TAS structure that |
|        | includes the following components defined by Treasury and   |
|        | OMB:                                                        |
|        |                                                             |
|        | > • Subclass\                                               |
|        | > • Agency code\                                            |
|        | > • Hyphen (when co-owner is not null)\                     |
|        | > • Transfer agency\                                        |
|        | > • Fiscal year (period of availability)\                   |
|        | > • Main account number\                                    |
|        | > • Sub-account symbol.                                     |
+--------+-------------------------------------------------------------+
| SMA-10 | **Accounting classification structure levels---**Define     |
|        | additional (lower) levels in the fund, program, project,    |
|        | organization and object class structures (e.g. establish    |
|        | parent child relationships with the ability to summarize,   |
|        | distribute funds, and report data at all defined levels).   |
+--------+-------------------------------------------------------------+
| SMA-11 | **ACE associations---**Maintain an accounting               |
|        | classification structure that can associate each element    |
|        | with multiple other elements and element values, including: |
|        |                                                             |
|        | > • TAS to multiple internal funds                          |
|        | >                                                           |
|        | > • Internal fund to multiple organizations, programs,      |
|        | > projects, and activities                                  |
|        | >                                                           |
|        | > • Organization to multiple programs, projects and         |
|        | > activities                                                |
|        | >                                                           |
|        | > • Project code to multiple organizations, programs and    |
|        | > activities                                                |
|        | >                                                           |
|        | > • Program to multiple organizations, projects and         |
|        | > activities.                                               |
+--------+-------------------------------------------------------------+
| SMA-12 | **Object class code structure---**Maintain an object class  |
|        | structure consistent with the standard object class codes   |
|        | defined in OMB Circular A-11. Accommodate additional        |
|        | (lower) levels in the object class structure, e.g., by      |
|        | establishing parent child relationships.                    |
+--------+-------------------------------------------------------------+
| SMA-13 | **Pre-configured BOC codes---**Deliver the Core financial   |
|        | system software populated with the 3-digit Budget Object    |
|        | Classification codes specified in OMB Circular No. A-11.    |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

## Document and Transaction Control Process

The Document and Transaction Control process defines the rules for
recording, editing, and processing transactions that are entered
directly to the Core financial system. In addition to recording these
transactions, the Core financial system must be able to record and
process transactions originating in other systems. All transactions must
be handled consistently, regardless of their point of origin. The Core
financial system must ensure that transactions are controlled properly
to provide reasonable assurance that the funds are available, tolerances
between documents are not exceeded, and other transaction processing
edits are met. Core financial systems edit for the presence of data
elements required on all system documents or on specific document types
(e.g., spending documents). The Document and Transaction Control process
defines these required data elements and validations.

##### Mandatory Requirements

To support the Document and Transaction Control process, the Core
financial system **[must]{.underline}** provide automated functionality
to do the following:

+--------+-------------------------------------------------------------+
| SMB-01 | **Document number---**Capture a unique system-generated or  |
|        | agency-assigned document number for each document and       |
|        | document modification.                                      |
+--------+-------------------------------------------------------------+
| SMB-02 | **Transaction number---**Capture a unique system-generated  |
|        | number to identify each general ledger transaction.         |
|        | Associate one or more general ledger transactions with a    |
|        | document and document modifications.                        |
+--------+-------------------------------------------------------------+
| SMB-03 | **Referenced documents---**Associate referenced documents   |
|        | in the processing chain, such as when an obligation         |
|        | document references one or more prior commitment documents. |
+--------+-------------------------------------------------------------+
| SMB-04 | **Source document number---**Capture a reimbursable         |
|        | agreement number and one other agency-assigned source       |
|        | document number in separate fields on all spending          |
|        | documents. The agency-assigned source document number may   |
|        | be a purchase requisition number, contract number and       |
|        | associated delivery/task order number, purchase order       |
|        | number, blanket purchase agreement number and associated    |
|        | call number, grant number, travel order number, etc.        |
+--------+-------------------------------------------------------------+
| SMB-05 | **Document number source---**Define document numbering as   |
|        | system-generated or agency-assigned by document type.       |
+--------+-------------------------------------------------------------+
| SMB-06 | **Duplicate documents---**Validate that duplicate documents |
|        | are not recorded, e.g., by editing document numbers or      |
|        | storing additional information that make the document       |
|        | number unique (as in date stamp on a utility bill).         |
+--------+-------------------------------------------------------------+
| SMB-07 | **Source system---**Capture the source system and the       |
|        | source system document number of each interfaced document.  |
+--------+-------------------------------------------------------------+
| SMB-08 | **Period of performance---**Capture goods delivery and      |
|        | service performance period start and end dates on documents |
|        | where the period of performance is a validation for future  |
|        | processing, e.g.,                                           |
|        |                                                             |
|        | > • Contracts                                               |
|        | >                                                           |
|        | > • Blanket purchase agreements                             |
|        | >                                                           |
|        | > • Reimbursable agreements                                 |
|        | >                                                           |
|        | > • Travel orders                                           |
|        | >                                                           |
|        | > • Grants.                                                 |
+--------+-------------------------------------------------------------+
| SMB-09 | **Reimbursable agreement terms and conditions---**Capture   |
|        | the following data elements when establishing reimbursable  |
|        | agreements:                                                 |
|        |                                                             |
|        | > • Reimbursable agreement number                           |
|        | >                                                           |
|        | > • Reimbursable agreement amount                           |
|        | >                                                           |
|        | > • Billing limit                                           |
|        | >                                                           |
|        | > • Billing terms                                           |
|        | >                                                           |
|        | > • Accounting classification information                   |
|        | >                                                           |
|        | > • Source (federal, other non-federal entities, or         |
|        | > public).                                                  |
+--------+-------------------------------------------------------------+
| SMB-10 | **Funds control and tolerance levels---**Define the level   |
|        | of fund control edits and tolerance checks as one of the    |
|        | following:                                                  |
|        |                                                             |
|        | > • Rejection                                               |
|        | >                                                           |
|        | > • Warning (override authority needed to post transaction) |
|        | >                                                           |
|        | > • Information only (no override needed).                  |
+--------+-------------------------------------------------------------+
| SMB-11 | **Reject documents---**Prevent the recording of erroneous   |
|        | transactions by rejecting documents that fail transaction   |
|        | processing edits.                                           |
+--------+-------------------------------------------------------------+
| SMB-12 | **Failed edit notification---**Notify the user when online  |
|        | documents fail funds control edits, transaction processing  |
|        | edits, or tolerance checks. Provide the notification on the |
|        | document entry screen, and include the nature of each error |
|        | and the validation level (rejection, warning or information |
|        | only). Retain errors with the document until they have been |
|        | resolved.                                                   |
+--------+-------------------------------------------------------------+
| SMB-13 | **Suspended documents---**Suspend documents that fail       |
|        | transaction processing edits, funds control edits, or       |
|        | tolerance checks.                                           |
+--------+-------------------------------------------------------------+
| SMB-14 | **Hold documents---**Allow users to hold documents for      |
|        | completion or processing at a later date. Segregate held    |
|        | from suspended documents.                                   |
+--------+-------------------------------------------------------------+
| SMB-15 | **Process suspended documents---**Process "suspended"       |
|        | documents when external referenced data that caused the     |
|        | system to suspend processing of a document is corrected,    |
|        | such as when a vendor's CCR status changes from expired to  |
|        | active.                                                     |
+--------+-------------------------------------------------------------+
| SMB-16 | **Failed edit corrections---**Allow users to select         |
|        | suspended and held documents for continued processing.      |
+--------+-------------------------------------------------------------+
| SMB-17 | **Cancel posted documents---**Allow users to cancel         |
|        | (permanently close) posted documents.                       |
+--------+-------------------------------------------------------------+
| SMB-18 | **Delete unposted documents---**Allow users to delete held  |
|        | or suspended documents.                                     |
+--------+-------------------------------------------------------------+
| SMB-19 | **Over tolerances---**Define tolerances by percentage,      |
|        | "not-to-exceed" dollar amounts, or "not-to-exceed"          |
|        | quantities at the document line level, and use them to      |
|        | control overages by document line for the following         |
|        | relationships:                                              |
|        |                                                             |
|        | > • Obligations to commitments                              |
|        | >                                                           |
|        | > • Receipts to obligations                                 |
|        | >                                                           |
|        | > • Invoices to obligations                                 |
+--------+-------------------------------------------------------------+
| SMB-20 | **Over Tolerances by obligation type---**Define over        |
|        | tolerances for all obligations or by obligation type.       |
+--------+-------------------------------------------------------------+
| SMB-21 | **Accounting line item detail---**Capture the following     |
|        | accounting line item detail on all documents:               |
|        |                                                             |
|        | > • Line item number                                        |
|        | >                                                           |
|        | > • Line item amount                                        |
|        | >                                                           |
|        | > • Line item accounting classification information.        |
+--------+-------------------------------------------------------------+
| SMB-22 | **Define acquisition information---**Define the valid       |
|        | values for the following acquisition information:           |
|        |                                                             |
|        | > • NAICS business codes                                    |
|        | >                                                           |
|        | > • SIC codes                                               |
|        | >                                                           |
|        | > • Product and service codes                               |
|        | >                                                           |
|        | > • FOB shipping points                                     |
|        | >                                                           |
|        | > • Ship to locations (destination codes).                  |
+--------+-------------------------------------------------------------+
| SMB-23 | **Validate acquisition information---**Validate that valid  |
|        | values for the following acquisition information are        |
|        | captured on spending documents:                             |
|        |                                                             |
|        | > • NAICS business codes                                    |
|        | >                                                           |
|        | > • SIC codes                                               |
|        | >                                                           |
|        | > • Product service codes                                   |
|        | >                                                           |
|        | > • FOB shipping points                                     |
|        |                                                             |
|        | • Ship to locations (destination codes).                    |
+--------+-------------------------------------------------------------+
| SMB-24 | **Document line item detail on obligation                   |
|        | documents---**Capture the following document line item      |
|        | information on spending documents:                          |
|        |                                                             |
|        | > • Quantity                                                |
|        | >                                                           |
|        | > • Unit of measure                                         |
|        | >                                                           |
|        | > • Unit Price                                              |
|        | >                                                           |
|        | > • Extended Price                                          |
|        | >                                                           |
|        | > • Description                                             |
|        | >                                                           |
|        | > • Product service codes                                   |
|        | >                                                           |
|        | > • FOB shipping points                                     |
|        |                                                             |
|        | • Ship to locations (destination codes).                    |
+--------+-------------------------------------------------------------+
| SMB-25 | **Line items to document total---**Validate that the sum of |
|        | all document line items is equal to the document total.     |
+--------+-------------------------------------------------------------+
| SMB-26 | **Default transaction date---**Derive the default           |
|        | transaction date from the current system date.              |
+--------+-------------------------------------------------------------+
| SMB-27 | **Default accounting period---**Derive the default          |
|        | accounting period from the transaction date. Prevent user   |
|        | override.                                                   |
+--------+-------------------------------------------------------------+
| SMB-28 | **Override transaction date---**Capture an agency-specified |
|        | transaction date (i.e., allow the agency to override the    |
|        | default transaction date with a date in any open accounting |
|        | period).                                                    |
+--------+-------------------------------------------------------------+
| SMB-29 | **Transaction date of subsequent activity---**Record        |
|        | subsequent activity against a document with the transaction |
|        | date of that activity, e.g., the payment voucher, not the   |
|        | transaction date of the original document, e.g., the        |
|        | referenced obligation.                                      |
+--------+-------------------------------------------------------------+
| SMB-30 | **Validate ACE---**Validate transaction accounting          |
|        | classification elements. Prevent the recording of           |
|        | transactions with missing, invalid or inactive              |
|        | classification elements or values.                          |
+--------+-------------------------------------------------------------+
| SMB-31 | **Validate FACTS attributes---**Validate                    |
|        | transaction-associated FACTS attributes. Prevent the        |
|        | recording of transactions with missing, invalid or inactive |
|        | FACTS attributes.                                           |
+--------+-------------------------------------------------------------+
| SMB-32 | **Record type 7 validation---**Validate transactions that   |
|        | would post to U.S. SGL accounts (e.g., borrowing authority, |
|        | contract authority, or investments) to ensure that the      |
|        | associated fund code is designated as having the            |
|        | appropriate RT7 code.                                       |
+--------+-------------------------------------------------------------+
| SMB-33 | **Transaction dates---**Capture the following dates on all  |
|        | transactions:                                               |
|        |                                                             |
|        | > • Transaction date - The date a transaction is effective  |
|        | > in the general ledger (i.e., the date a financial event   |
|        | > is recognized).                                           |
|        | >                                                           |
|        | > • System date - The actual date a transaction is          |
|        | > processed by the system. This date is assigned by the     |
|        | > computer and may not be modified*.*                       |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

To add value to the Document and Transaction Control process, the Core
financial system **[should]{.underline}** provide automated
functionality to do the following:

  --------- -------------------------------------------------------------
  SMB-34    **Foreign currency transactions---**Record transactions in
            both foreign currency and U.S. dollars in all Core system
            modules.

  SMB-35    **Under tolerances---**Define tolerances by percentage,
            dollar amount or quantity for final payments that are less
            than the referenced obligation document line amounts, and use
            them to control erroneous de-obligations of the funds.

  SMB-36    **Under Tolerances by obligation type---**Define under
            tolerances for all obligations or by obligation type.
  --------- -------------------------------------------------------------

## Document Referencing and Modification Process

In the typical Federal spending chain, a purchase moves from the
reservation (commitment) of funds, to the execution of an obligating
document (e.g., contract or purchase order), to the acknowledgment of
goods or services received and accepted goods, and finally to payment of
the expense or asset. The Document Referencing and Modification process
defines the relationships that must be maintained between these document
types, the types of document amendments that must be accommodated by the
Core financial system, and the related querying capabilities required by
Core financial system users.

##### Mandatory Requirements

To support the Document Referencing and Modification process, the Core
financial system **[must]{.underline}** provide automated functionality
to do the following:

+--------+-------------------------------------------------------------+
| SMC-01 | **Associate documents in the processing chain---**Associate |
|        | documents in the processing chain, and bring forward        |
|        | accounting and non-financial information from one document  |
|        | to another, when the previously recorded document is        |
|        | referenced, (e.g., commitment to obligation, receivable to  |
|        | collection). This is to include accounting classification,  |
|        | vendor and customer information.                            |
+--------+-------------------------------------------------------------+
| SMC-02 | **Update referenced document balances---**Update the        |
|        | balance of open documents by accounting line item as they   |
|        | are referenced by subsequent documents in the processing    |
|        | chain. For example, reduce commitments when referenced by   |
|        | obligations, reduce obligations when referenced by          |
|        | expenditures, reclassify obligations when referenced by     |
|        | advances, reduce accounts receivable when referenced by     |
|        | collections.                                                |
+--------+-------------------------------------------------------------+
| SMC-03 | **Associate documents with source documents---**Associate   |
|        | documents with related source documents (e.g., reimbursable |
|        | agreements, purchase orders, contracts and delivery orders, |
|        | BPAs and call numbers, and grants) so that queries show all |
|        | related activity.                                           |
+--------+-------------------------------------------------------------+
| SMC-04 | **Financial modifications to documents---**Capture document |
|        | modifications at the accounting line item level that affect |
|        | the general ledger, including changes to dollar amounts and |
|        | accounting classifications. Validate that funds are         |
|        | available prior to recording the modifications.             |
+--------+-------------------------------------------------------------+
| SMC-05 | **Non-financial document modifications---**Capture document |
|        | modifications that do not affect the general ledger, such   |
|        | as changes to vendor names, descriptions, etc.              |
+--------+-------------------------------------------------------------+
| SMC-06 | **Associate modifications with original                     |
|        | documents---**Associate document modifications and          |
|        | cancellations with the original documents so that queries   |
|        | show all related activity.                                  |
+--------+-------------------------------------------------------------+
| SMC-07 | **Re-open closed document---**Re-open a closed document to  |
|        | allow further processing against it, without requiring a    |
|        | new or amended document number.                             |
+--------+-------------------------------------------------------------+
| SMC-08 | **Reference multiple prior documents---**Reference multiple |
|        | documents and document lines in the processing chain. For   |
|        | example, reference multiple commitments or commitment lines |
|        | on an obligating document, or reference multiple receivable |
|        | documents or document lines on a collection.                |
+--------+-------------------------------------------------------------+
| SMC-09 | **Document status---**Capture the latest system processing  |
|        | status on all documents.                                    |
|        |                                                             |
|        | > • Held: The user has decided to save (hold) the document  |
|        | > and not allow the system to process it. (Note: This       |
|        | > status is distinguished from invoices that are processed  |
|        | > and warehoused, then "held" from inclusion in the payment |
|        | > schedule.)                                                |
|        | >                                                           |
|        | > • Suspended: The document has failed one or more system   |
|        | > validations (edits) and is prevented by the system from   |
|        | > processing. The document is automatically stored for      |
|        | > later processing. Suspended documents may be              |
|        | > automatically processed by the system upon changes to     |
|        | > underlying data, such as available funds.                 |
|        | >                                                           |
|        | > • Pending Approval: The document has passed all system    |
|        | > validations. The system will not process the document     |
|        | > until all approvals required by the agency's workflow     |
|        | > configuration have been applied. Not all documents        |
|        | > require approvals.                                        |
|        | >                                                           |
|        | > • Approved: The document has passed all system            |
|        | > validations (edits) and all required approvals have been  |
|        | > applied. The document is available for processing.        |
|        | >                                                           |
|        | > • Processed: All related accounting events have been      |
|        | > recorded and system tables have been updated.             |
|        | >                                                           |
|        | > • Open: The document has been processed but not           |
|        | > liquidated or only partially liquidated. The document is  |
|        | > available for further processing.                         |
|        | >                                                           |
|        | > • Closed: The document has been processed and completely  |
|        | > liquidated. The system will not allow further processing  |
|        | > against the document unless it is reopened by the user.   |
|        | >                                                           |
|        | > • Cancelled: The user has permanently closed a previously |
|        | > processed document. The system will not allow further     |
|        | > processing against the document.                          |
|        | >                                                           |
|        | > • Deleted: The user has chosen not to process a held or   |
|        | > suspended document. Deleted documents are marked for      |
|        | > purging.                                                  |
|        | >                                                           |
|        | > • Converted: The document was processed through an        |
|        | > automated or manual transfer from a legacy system.        |
+--------+-------------------------------------------------------------+
| SMC-10 | **Related documents query---**Query documents. Parameter    |
|        | includes any document number. Result is a list of all       |
|        | document numbers in the document's processing chain with    |
|        | document statuses and balances at the document level.       |
|        | Drill-down from each document number to its document        |
|        | details (e.g., vendor/customer name, description, amount).  |
+--------+-------------------------------------------------------------+
| SMC-11 | **Standard document transactions query---**Query            |
|        | transactions. Parameter is any document number. Result is a |
|        | list of all general ledger transactions in the document's   |
|        | processing chain, including:                                |
|        |                                                             |
|        | > • Transaction numbers                                     |
|        | >                                                           |
|        | > • Amounts                                                 |
|        | >                                                           |
|        | > • GL debits and credits                                   |
|        | >                                                           |
|        | > • Accounting classification elements.                     |
+--------+-------------------------------------------------------------+
| SMC-12 | **Standard document query---**Query documents. Parameter(s) |
|        | include any one or a combination of the following:          |
|        |                                                             |
|        | • Document type                                             |
|        |                                                             |
|        | • Document status (e.g., open, closed)                      |
|        |                                                             |
|        | • Vendor number                                             |
|        |                                                             |
|        | • Vendor DUNS+4 number                                      |
|        |                                                             |
|        | • Customer number                                           |
|        |                                                             |
|        | • Accounting classification elements.                       |
|        |                                                             |
|        | Result is a list of selected document numbers with document |
|        | statuses and balances at the document level. Drill-down     |
|        | from each document number to its document lines and         |
|        | detailed GL transactions.                                   |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

To add value to the Document Referencing and Modification process, the
Core financial system **[should]{.underline}** provide automated
functionality to do the following:

  --------- -------------------------------------------------------------
  SMC-13    **Update accounting data---**Update accounting data at the
            accounting line level when accounting classification elements
            are restructured, i.e., by reversing GL and subsidiary ledger
            transactions and reposting them with the new values. Generate
            an audit trail from the original postings to the final
            postings.

  SMC-14    **Dating of accounting data reclassification---**Reclassify
            accounting data from the beginning of the current fiscal year
            or fiscal month.

  SMC-15    **Update open documents---**Update related open documents
            when users modify classification information on a document in
            a processing chain.
  --------- -------------------------------------------------------------

## System-Generated Transactions Process

The initial source of Core financial system activity may be any one of
the following: online data entry, other systems or modules, or
system-generated transactions. System-generated transactions include
recurring entries (and reversals), closing entries, cost assignment
entries, and transactions generated by other transactions. Agencies
define these entries in advance for subsequent posting by the Core
financial system. The general ledger postings are specified, as well as
the date or frequency of those postings. System-generated transactions
are then posted automatically by the Core financial system on the
specified dates, based on the passage of time.

##### Mandatory Requirements

To support the System-Generated Transactions process, the Core financial
system **[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| SMD-01 | **Parameters for recurring entries---**Capture start and    |
|        | end dates and posting frequency (monthly, quarterly, or     |
|        | specified number of days) of recurring entries and          |
|        | reversals such as accruals and obligations.                 |
+--------+-------------------------------------------------------------+
| SMD-02 | **Future-dated recurring entries---**Generate recurring     |
|        | entries and reversals in future accounting periods (e.g.,   |
|        | payroll and travel accruals), when the specified            |
|        | transaction dates are reached. This is to include entries   |
|        | that cross fiscal years.                                    |
+--------+-------------------------------------------------------------+
| SMD-03 | **Future-dated transactions---**Future date transactions    |
|        | for processing in subsequent accounting periods, i.e., when |
|        | the specified transaction dates are reached. Validate the   |
|        | transaction upon initial entry and re-validate the          |
|        | transaction at the point it is recorded.                    |
+--------+-------------------------------------------------------------+
| SMD-04 | **Transaction reversals---**Generate batched reversal       |
|        | transactions by any one or a combination of the following   |
|        | parameters:                                                 |
|        |                                                             |
|        | > • Accounting period\                                      |
|        | > • Transaction or document type\                           |
|        | > • Accounting classification elements\                     |
|        | > • System date\                                            |
|        | > • Transaction date\                                       |
|        | > • Source system ID.                                       |
|        |                                                             |
|        | For example, reverse payroll transactions posted on January |
|        | 1, 2006.                                                    |
+--------+-------------------------------------------------------------+
| SMD-05 | **Valid transaction reversals---**Validate that transaction |
|        | reversals do not violate the integrity of the document      |
|        | chain. For example, do not reverse obligations that have    |
|        | been liquidated by payments.                                |
+--------+-------------------------------------------------------------+
| SMD-06 | **Transaction reversal report---**Generate a report of      |
|        | posted and unposted reversal transactions. Parameters are:  |
|        |                                                             |
|        | > • Accounting period\                                      |
|        | > • Transaction or document type\                           |
|        | > • Accounting classification elements\                     |
|        | > • System date\                                            |
|        | > • Transaction date\                                       |
|        | > • Source system ID.                                       |
|        |                                                             |
|        | Result is a list of transactions including:                 |
|        |                                                             |
|        | > • System date                                             |
|        | >                                                           |
|        | > • Transaction date                                        |
|        | >                                                           |
|        | > • Original document and accounting line numbers           |
|        | >                                                           |
|        | > • Status (posted or un-posted)                            |
|        | >                                                           |
|        | > • Accounting classification elements                      |
|        | >                                                           |
|        | > • GL transaction ID number                                |
|        | >                                                           |
|        | > • GL debits and credits.                                  |
|        |                                                             |
|        | Sorting options include document number and reversal        |
|        | status.                                                     |
+--------+-------------------------------------------------------------+
| SMD-07 | **System interfaces---**Deliver the capability to           |
|        | send/receive financial transactions from Governmentwide     |
|        | mandated applications:                                      |
|        |                                                             |
|        | > • Central Contractor Registration (CCR)\                  |
|        | > • Electronic Certification System (ECS)\                  |
|        | > • Federal Agencies Centralized Trial Balance System I     |
|        | > (FACTS I)\                                                |
|        | > • Federal Agencies Centralized Trial Balance System II    |
|        | > (FACTS II)\                                               |
|        | > • Government Online Accounting Link System (GOALS II)\    |
|        | > • Intra-governmental Payment and Collection System (IPAC) |
|        | >                                                           |
|        | > • Treasury Offset Program (TOP)                           |
|        | >                                                           |
|        | > • Secure Payment System (SPS).                            |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

*To add value to the System-Generated Transactions process, the Core
financial system **[should]{.underline}** provide automated
functionality to do the following:*

+--------+-------------------------------------------------------------+
| SMD-08 | **Other system interfaces---**Deliver the capability to     |
|        | send/receive financial transactions from Government wide    |
|        | mandated applications:                                      |
|        |                                                             |
|        | > • eTravel                                                 |
|        | >                                                           |
|        | > • CA\$HLINK II                                            |
|        | >                                                           |
|        | > • GWA.                                                    |
+--------+-------------------------------------------------------------+

## Audit Trails Process

Adequate audit trails are critical to providing support for transactions
and balances maintained by the Core financial system. Although audit
trails are essential to auditors, they are also important to agencies in
their day-to-day operation of the system. Audit trails provide agencies
with information necessary to reconcile accounts, research document
history, and query the data stored in the Core financial system.

##### Mandatory Requirements

To support the Audit Trails process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| SME-01 | **Document processing audit trail---**Generate an audit     |
|        | trail of transactions recorded as a document moves from its |
|        | source through all document statuses. The initial source    |
|        | may be documents that were entered online,                  |
|        | system-generated, interfaced from other systems or modules, |
|        | or converted during implementations or software upgrades.   |
+--------+-------------------------------------------------------------+
| SME-02 | **Document activity logging---**Capture all document change |
|        | events (additions, modifications and cancellations),        |
|        | including the date/time and User ID.                        |
+--------+-------------------------------------------------------------+
| SME-03 | **Document activity query---**Query document additions,     |
|        | modifications and cancellations. Parameters include:        |
|        |                                                             |
|        | • User ID                                                   |
|        |                                                             |
|        | • Document number                                           |
|        |                                                             |
|        | • Document type                                             |
|        |                                                             |
|        | • Change type (add, modify, cancel)                         |
|        |                                                             |
|        | • Transaction date range                                    |
|        |                                                             |
|        | • Accounting period.                                        |
|        |                                                             |
|        | Results include all parameter values, document numbers,     |
|        | date and time stamps.                                       |
+--------+-------------------------------------------------------------+
| SME-04 | **Accounting classification history---**Generate an audit   |
|        | trail of all accounting classification structure additions, |
|        | changes and deactivations, including the effective dates of |
|        | the changes.                                                |
+--------+-------------------------------------------------------------+
| SME-05 | **Converted documents---**Capture the following additional  |
|        | information on converted documents:                         |
|        |                                                             |
|        | > • Legacy system identifier\                               |
|        | > • Legacy system document number.                          |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

# General Ledger Management Function

General Ledger Management is the central function of the Core financial
system. All transactions to record financial events must post to the
general ledger, regardless of the origin of the transaction.
Transactions originating in other systems may post to the general ledger
at a summary level, depending on an agency's overall financial
management system design and need. At a minimum, however, summary
transactions must post at a level that maintains the accounting
classification elements and attributes needed to support central agency
reporting.

The general ledger must summarize and maintain account balances at the
U.S. SGL account and attribute level. In addition, it must maintain
balances by the accounting classification elements established in the
System Management function. For example, account balances must be
maintained at the internal fund and organization level. An agency might
choose to classify financial data at a lower level by establishing
general ledger subaccounts or agency-specific accounting classification
elements in order to support internal reporting needs or program
management performance reporting. The general ledger must maintain
account balances at these agency-specific levels, as well.

The General Ledger Management function consists of the following
processes (the prefixes assigned to the requirements are noted in
parentheses):

-   General Ledger Account Definition (GLA)

-   Transaction Definition (GLB)

-   General Ledger Updating and Editing (GLC)

-   Upward/Downward Spending Adjustment (GLD)

-   General Ledger Analysis and Reconciliation (GLE)

-   Accounting Period Maintenance and Closing (GLF)

-   Financial Reporting (GLG).

## General Ledger Account Definition Process

OMB Circular A-127, *Financial Management Systems*, requires
implementation of the U.S. SGL at the transaction level. The U.S. SGL is
defined in the latest supplement to the Department of the Treasury's
TFM, which includes the chart of accounts, account descriptions and
postings, accounting transactions, U.S. SGL attributes, and crosswalks
to standard external reports. Each agency must implement a chart of
accounts that is consistent with the U.S. SGL and meets the agency's
information needs.

##### Mandatory Requirements

To support the General Ledger Account Definition process, the Core
financial system **[must]{.underline}** provide automated functionality
to do the following:

  --------- -------------------------------------------------------------
  GLA-01    **Chart of accounts---**Maintain a chart of accounts
            consistent with the U.S. SGL Chart of Accounts, including the
            proprietary, budgetary, and memorandum accounts, basic
            numbering structure, and account titles.

  GLA-02    **Account attributes---**Maintain an association between the
            chart of accounts and valid attribute domain values used for
            Treasury reporting (e.g., FACTS I, FACTS II and GFRS
            reporting).

  GLA-03    **Control accounts---**Define specific GL accounts as control
            accounts for purposes of tracking activity in subsidiary
            ledgers.

  GLA-04    **Sub-accounts---**Define agency-specific GL sub-accounts
            that summarize to U.S. SGL accounts.

  GLA-05    **Sub-account length---**Accommodate an additional 2 digits
            beyond the U.S. SGL account for agency-specific GL
            sub-accounts.

  GLA-06    **Memorandum accounts---**Define agency-specific memorandum
            accounts in the chart of accounts.

  GLA-07    **Account changes---**Add, change or de-activate accounts in
            the chart of accounts without programming changes.

  GLA-08    **Attribute value changes---**Add, change or de-activate U.S.
            SGL attribute domain values in order to accommodate changes
            in Treasury reporting (e.g. FACTS I, FACTS II, or GFRS)
            without programming changes.

  GLA-09    **Pre-configured U.S. SGL accounts---**Deliver the Core
            financial system software populated with the current
            published values for the U.S. SGL chart of accounts.

  GLA-10    **Pre-configured FACTS II attributes---**Deliver the Core
            financial system software populated with the current
            published values for the FACTS II attributes.
  --------- -------------------------------------------------------------

##### Value-Added Requirements

There are no value-added requirements for this process.

## Transaction Definition Process

In addition to implementing the U.S. SGL at the transaction level, OMB
Circular A-127 requires common processes to be used for processing
similar kinds of transactions throughout an integrated financial
management system. This ensures that all transactions are handled
consistently, regardless of their point of origin. Consistency in
processing transactions is accomplished by defining standard
transactions for use in recording accounting events. Standard
transactions must comply with U.S. SGL posting rules and include
budgetary, proprietary, and memorandum accounts, as applicable.

##### Mandatory Requirements

To support the Transaction Definition process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

  --------- -------------------------------------------------------------
  GLB-01    **Standard transactions---**Record like accounting events
            consistently using standard transactions. Standard
            transactions must specify the general ledger account
            postings, and update document balances and any related tables
            (e.g. available funding).

  GLB-02    **GL account posting---**Define the general ledger account
            postings used in a standard transaction.

  GLB-03    **Transaction accounts---**Define standard transactions that
            include proprietary, budgetary and memorandum accounts.

  GLB-04    **U.S. SGL consistency---**Define standard transactions
            consistent with U.S. SGL posting rules.

  GLB-05    **Posting derivation---**Define standard transactions that
            derive general ledger postings based on accounting
            classification elements or other document data elements.

  GLB-06    **Transaction rules---**Define edit rules for standard
            transactions to require, prohibit, or set a default value for
            accounting classification elements.

  GLB-07    **Number of GL account pairs---**Define up to 10 debit and
            credit pairs in a single standard transaction.
  --------- -------------------------------------------------------------

##### Value-Added Requirements

There are no value-added requirements for this process.

## General Ledger Updating and Editing Process

To ensure the consistency and completeness of financial records, the
General Ledger Update and Editing process requires that all general
ledger accounts---budgetary, proprietary, and memorandum---referenced on
a standard transaction be updated at the time of input of a transaction.
It requires general ledger updates to be balanced at all levels of the
organization and consistent with updates to subsidiary ledgers.
Subsidiary ledgers must support the general ledger at various levels of
detail, whether totally integrated as part of the Core financial system
or interfaced from other systems.

##### Mandatory Requirements

To support the General Ledger Update and Editing process, the Core
financial system **[must]{.underline}** provide automated functionality
to do the following:

  --------- -------------------------------------------------------------
  GLC-01    **Updating GL balances---**Update all general ledger account
            balances (i.e., budgetary, proprietary and memorandum
            accounts) based on a single input transaction.

  GLC-02    **Classifying transactions by attribute---**Classify
            accounting transactions by U.S. SGL attributes required for
            FACTS I, FACTS II, and GFRS reporting as specified by the
            current supplement(s) to the TFM.

  GLC-03    **Validate attributes---**Validate U.S. SGL attributes on
            transactions (whether entered or derived) prior to the
            posting.

  GLC-04    **Balanced GL postings by ACS---**Prevent transactions from
            posting that would cause general ledger debits and credits to
            be out-of-balance at any level of the agency's accounting
            classification structure specified on a transaction.

  GLC-05    **Balanced GL postings by account type---**Prevent
            transactions from posting that would cause general ledger
            debits and credits to be out of balance within the
            proprietary, budgetary, or memorandum accounts. Proprietary,
            budgetary, and memorandum accounts must each be
            self-balancing.

  GLC-06    **GL control accounts balanced with subsidiary
            ledgers---**Update general ledger control accounts consistent
            with postings made to subsidiary ledgers. Prevent
            transactions from posting that would cause the general ledger
            control accounts to be out-of-balance with the subsidiary
            ledgers.

  GLC-07    **De-activated accounts---**Prevent transactions from posting
            to general ledger accounts that have been de-activated.
  --------- -------------------------------------------------------------

##### Value-Added Requirements

There are no value-added requirements for this process.

## Upward/Downward Spending Adjustment Process

Accounting for upward and downward spending adjustments requires a
complex analysis of the types of adjustments made to prior-year spending
documents. This process requires the system to recognize when an
adjustment occurs and to determine what type of adjustment occurred.
Based upon this analysis, the system must automatically create the
appropriate adjustment entry to record the financial event.

##### Mandatory Requirements

To support the Upward/Downward Spending Adjustment process, the Core
financial system **[must]{.underline}** provide automated functionality
to do the following:

  --------- -------------------------------------------------------------
  GLD-01    **Record spending adjustments---**Derive and record the
            amount of upward or downward spending adjustments upon
            liquidating, canceling, or modifying the dollar amount of
            prior year obligations or expenditures. Record the spending
            adjustment at the time of posting the transaction which
            generated it.

  GLD-02    **Spending adjustment reversals---**When correcting documents
            that previously generated spending adjustment entries,
            reverse the original spending adjustment entries and generate
            new spending adjustments for the correct amounts.

  GLD-03    **Adjustments to expired vs. unexpired---**Determine if
            upward and downward adjustments are to expired or unexpired
            budget authority in order to derive the U.S. SGL prescribed
            entries to record spending adjustments.

  GLD-04    **Anticipated recoveries---**Determine if anticipated
            recoveries have been previously recorded in order to derive
            the U.S. SGL prescribed entries to record downward spending
            adjustments.

  GLD-05    **Adjustments to paid vs. unpaid---**Determine if upward and
            downward adjustments are to paid or unpaid obligations and/or
            expenditures in order to derive the U.S. SGL prescribed
            entries for recording spending adjustments.

  GLD-06    **Adjustments to delivered vs. undelivered
            orders---**Determine if upward and downward adjustments are
            to delivered or undelivered orders in order to derive the
            U.S. SGL prescribed entries to record spending adjustments.

  GLD-07    **Previously unrecorded obligations---**Permit recording of
            previously unrecorded obligations to prior year budget
            authority or expired budget authority and generate related
            upward spending adjustments in the current year.

  GLD-08    **Spending adjustment validation---**Identify when posting
            transactions will invoke upward spending adjustments, and
            apply the agency-defined level of validation (I.e.,
            rejection, warning or information only).
  --------- -------------------------------------------------------------

##### Value-Added Requirements

There are no value-added requirements for this process.

## General Ledger Analysis and Reconciliation Process

The Core financial system must provide information to use in analyzing
account balances and in reconciling account balances to information
contained in reports and in subsidiary ledgers. With system integration,
the likelihood of out-of-balance conditions existing between financial
reports, subsidiary ledgers, and account balances should be minimal, but
the possibility of such conditions do exist as a result of system
failures and incorrect transaction definitions.

##### Mandatory Requirements

To support the General Ledger Analysis and Reconciliation process, the
Core financial system **[must]{.underline}** provide automated
functionality to do the following:

  --------- -------------------------------------------------------------
  GLE-01    **General ledger account balances query---**Query general
            ledger account balances. Parameters include beginning and
            ending accounting period, and TAS or internal fund code.
            Result is beginning account balances, period activity, and
            ending account balances for the period and TAS, or internal
            fund code, specified. Drill-down from period activity to
            supporting general ledger transactions; from general ledger
            transactions to supporting documents; and from supporting
            documents to other documents in the document chain.

  GLE-02    **Daily GL and Subsidiary Ledger Exception
            Report---**Generate the Daily GL and Subsidiary Ledger
            Exception Report. Result is a list of GL control accounts by
            internal fund code whose balances differ from the subsidiary
            ledgers. Report lines include the GL control account balance,
            the balance of the open documents in the subsidiary ledger,
            and the difference.

  GLE-03    **GL Supporting Document Report---**Generate the GL
            Supporting Documents Report as of the current system date.
            Parameters include a GL control account and TAS or internal
            fund code. Result is the GL account balance, and a list of
            the open documents and balances supporting the GL account
            balance.
  --------- -------------------------------------------------------------

##### Value-Added Requirements

There are no value-added requirements for this process.

## Accounting Period Maintenance and Closing Process

This process segregates accounting transactions into accounting periods
and creates closing entries needed at the end of a period (month or
year) for reporting purposes. It also controls and executes period-end
system processes needed by the system to open a new reporting period,
such as rolling forward account balances or reversing certain year-end
entries. This process supports the preparation of consolidated financial
statements by identifying information needed in that process.

##### Mandatory Requirements

To support the Accounting Period Maintenance and Closing process, the
Core financial system **[must]{.underline}** provide automated
functionality to do the following:

  --------- -------------------------------------------------------------
  GLF-01    **Accounting periods---**Maintain fifteen accounting periods
            per fiscal year. Provide the option to designate one period
            for recording opening balances, twelve periods for recording
            monthly activity and two additional periods for year end
            pre-closing and closing entries.

  GLF-02    **Open accounting periods---**Record transactions to any open
            accounting period. Provide the option to keep multiple
            accounting periods (minimum of 3) open simultaneously.

  GLF-03    **Closed accounting periods---**Close accounting periods and
            prevent the posting of new transactions to any closed period.

  GLF-04    **Re-opening accounting periods---**Re-open closed accounting
            periods and record transactions to them.

  GLF-05    **Closing entries---**Provide a year-end closing process that
            records U.S. SGL prescribed closing entries in accounting
            periods separate from other accounting periods.

  GLF-06    **Multiple closings---**Perform multiple closings in a
            trial/test mode so that users can review the closing results,
            clear the closing entries and re-run the closing process.
            This functionality must be available for both "pre-closing"
            entries and "closing" entries.

  GLF-07    **Closing results---**Generate trial balances that support
            the review of the closing process run in trial/test mode.

  GLF-08    **Open fiscal years---**Record transactions to the current
            and prior fiscal year (i.e., until the closing process is
            complete).

  GLF-09    **Roll forward balances---**Derive an accounting period's
            opening balances based on the prior accounting period's
            closing balances at the U.S. SGL attribute level. The opening
            of general ledger account balances must maintain the U.S. SGL
            attribute information required to satisfy FACTS I, FACTS II,
            and GFRS reporting requirements.

  GLF-10    **Fiscal year driven tables---**Make fiscal year driven
            tables available in subsequent fiscal years.

  GLF-11    **Single year tables---**Make single year appropriation and
            fund tables available in subsequent fiscal years.
  --------- -------------------------------------------------------------

##### Value-Added Requirements

To add value to the Accounting Period Maintenance and Closing
functionality, the Core financial system **[should]{.underline}** do the
following:

  --------- -------------------------------------------------------------
  GLF-12    **Mass table changes at fiscal year end---**Deliver a
            capability to make mass changes to tables rolled forward to a
            subsequent fiscal year.

  --------- -------------------------------------------------------------

## Financial Reporting Process

The financial reporting process ensures that the system provides the
basic reports and online information access needed to review financial
information and to fulfill central agency reporting requirements. It
provides specifications for the minimum data elements to be displayed in
the internal and external financial reports, while establishing general
requirements that provide agencies with flexibility in configuring the
reports, and generating the reports for specified accounting periods.

Accounting reports that are based on the GL, such as a trial balance,
are normally run as of a specified current or prior accounting period.
If run for the current period, activity is reported through the current
date. All financial accounting reports are expected to be generated
using information maintained in the core general ledger.

##### Mandatory Requirements

To support the Financial Reporting process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| GLG-01 | **Report end dates---**Generate all standard reports as of  |
|        | any accounting period. Amounts reported must reflect the    |
|        | cumulative amount of all transactions posted to the general |
|        | ledger up through the accounting period specified for       |
|        | running the report. If reporting for the current period,    |
|        | amounts must be cumulative up through the current date.     |
+--------+-------------------------------------------------------------+
| GLG-02 | **Report consistency---**Ensure consistency between the     |
|        | data sources used to generate internal and external         |
|        | financial reports for the same accounting period. The       |
|        | following relationships must be maintained:                 |
|        |                                                             |
|        | > • The beginning and ending balances and total debit and   |
|        | > credit activity reported on the Standard Trial Balance    |
|        | > must equal the beginning and ending balances and total    |
|        | > debit and credit activity reported on the FACTS I and     |
|        | > FACTS II trial balances.                                  |
|        | >                                                           |
|        | > • The debit and credit activity reported on the           |
|        | > Transaction Register must equal the debit and credit      |
|        | > activity reported on all of the trial balances.           |
|        | >                                                           |
|        | > • The system-generated FACTS I transfer file must agree   |
|        | > with the system-generated Balance Sheet, Statement of Net |
|        | > Cost, and Statement of Changes in Net Position            |
|        | >                                                           |
|        | > • The system-generated FACTS II transfer file must agree  |
|        | > with the system-generated Statement of Budgetary          |
|        | > Resources and the SF-133.                                 |
+--------+-------------------------------------------------------------+
| GLG-03 | **Transaction register---**Generate a transaction register  |
|        | report. Parameters are: accounting period, transaction date |
|        | range, or system date range. Result is a report displaying  |
|        | the following data elements for each transaction posted     |
|        | during the accounting period or date range specified:       |
|        |                                                             |
|        | > • Fiscal year                                             |
|        | >                                                           |
|        | > • TAS                                                     |
|        | >                                                           |
|        | > • Internal fund code                                      |
|        | >                                                           |
|        | > • Document number                                         |
|        | >                                                           |
|        | > • Transaction number                                      |
|        | >                                                           |
|        | > • Transaction date                                        |
|        | >                                                           |
|        | > • System date                                             |
|        | >                                                           |
|        | > • System time                                             |
|        | >                                                           |
|        | > • Entry user ID                                           |
|        | >                                                           |
|        | > • Debit account number(s)                                 |
|        | >                                                           |
|        | > • Debit amount(s)                                         |
|        | >                                                           |
|        | > • Credit account number(s)                                |
|        | >                                                           |
|        | > • Credit amount(s)                                        |
|        | >                                                           |
|        | > • Object class                                            |
|        | >                                                           |
|        | > • U.S. SGL attribute values.                              |
|        |                                                             |
|        | Provide an option to group transactions at the TAS,         |
|        | internal fund, or organization level. Transactions which    |
|        | occur from a single posting event must be grouped together. |
|        | The report must include headings for each data element      |
|        | displayed. The report must include all transactions in all  |
|        | funds that occurred within the accounting period specified. |
+--------+-------------------------------------------------------------+
| GLG-04 | > **Trial balance---**Generate a trial balance report.      |
|        | > Parameter is the accounting period. Result is a report    |
|        | > providing the following amounts for each general ledger   |
|        | > account:                                                  |
|        | >                                                           |
|        | > • Beginning balance for the accounting period             |
|        | >                                                           |
|        | > • Total amount of debits for the accounting period        |
|        | >                                                           |
|        | > • Total amount of credits for the accounting period       |
|        | >                                                           |
|        | > • Cumulative ending balance for the accounting period.    |
|        |                                                             |
|        | Provide the option to select whether general ledger account |
|        | balances are rolled up to the TAS level, internal fund      |
|        | level, or organization level, and also whether they are     |
|        | displayed at the GL sub-account level (actual accounts used |
|        | for posting transactions) or the U.S. SGL account level.    |
|        | Sub-totals for beginning balance, accounting period         |
|        | activity, and ending balance columns must be provided after |
|        | each change in organization, internal fund and TAS on the   |
|        | report. The report must include the balances of all funds   |
|        | and all fiscal years maintained by the agency.              |
+--------+-------------------------------------------------------------+
| GLG-05 | **FACTS I trial balance---**Generate a FACTS I trial        |
|        | balance report. Parameter is the accounting period. Result  |
|        | is a report displaying the following balances for each U.S. |
|        | SGL account or U.S. SGL account and attribute combination:  |
|        |                                                             |
|        | • Beginning balance for the accounting period               |
|        |                                                             |
|        | • Total amount of debits for the accounting period          |
|        |                                                             |
|        | • Total amount of credits for the accounting period         |
|        |                                                             |
|        | • Cumulative ending balance for the accounting period.      |
|        |                                                             |
|        | Provide the option to specify whether general ledger        |
|        | account balances are rolled up to the TAS level, internal   |
|        | fund level, or organization level. The report must include  |
|        | all general ledger accounts (both FACTS I accounts and      |
|        | non-FACTS I accounts). FACTS I accounts must be displayed   |
|        | at the U.S. SGL and attribute level (I.e. separate amounts  |
|        | should be displayed when there is more than one attribute   |
|        | value within an U.S. SGL account). Non-FACTS I accounts     |
|        | must be displayed at the U.S. SGL account level. Subtotals  |
|        | for beginning balance, accounting period activity, and      |
|        | ending balance columns must be provided after each change   |
|        | in TAS, internal fund, and organization on the report.      |
+--------+-------------------------------------------------------------+
| GLG-06 | **FACTS II trial balance---**Generate a FACTS II trial      |
|        | balance report. Parameter is the accounting period. Result  |
|        | is a report displaying the following balances for each U.S. |
|        | SGL account or U.S. SGL account and attribute combination:  |
|        |                                                             |
|        | • Beginning balance for the accounting period               |
|        |                                                             |
|        | • Total amount of debits for the accounting period          |
|        |                                                             |
|        | • Total amount of credits for the accounting period         |
|        |                                                             |
|        | • Cumulative ending balance for the accounting period.      |
|        |                                                             |
|        | Provide the option to specify whether general ledger        |
|        | account balances are rolled up to the TAFS level, internal  |
|        | fund level, or organization level. The report must include  |
|        | all general ledger accounts (both FACTS II accounts and     |
|        | non-FACTS II accounts). FACTS II accounts must be displayed |
|        | at the U.S. SGL and attribute level (i.e., separate amounts |
|        | should be displayed when there is more than one attribute   |
|        | value within a U.S. SGL account). Non-FACTS II accounts     |
|        | must be displayed at the U.S. SGL account level. Subtotals  |
|        | for beginning balance, accounting period activity, and      |
|        | ending balance columns must be provided after each change   |
|        | in TAFS, internal fund, and organization on the report.     |
+--------+-------------------------------------------------------------+
| GLG-07 | **FACTS ATB---**Export bulk transfer files for FACTS I and  |
|        | FACTS II Adjusted Trial Balances (ATBs) to the Department   |
|        | of Treasury's FMS.                                          |
+--------+-------------------------------------------------------------+
| GLG-08 | **FACTS validation---**Validate FACTS I and FACTS II data   |
|        | prior to submission of the FACTS I and FACTS II ATBs and    |
|        | the GFRS report to Treasury's FMS. Provide the option to    |
|        | run validation edits on demand.                             |
+--------+-------------------------------------------------------------+
| GLG-09 | **SF 133---**Generate the Report on Budget Execution and    |
|        | Budgetary Resources (SF-133). Parameters include TAFS and   |
|        | accounting period end date. When no TAFS is specified,      |
|        | generate a report for each reportable TAFS. Results are     |
|        | reports in accordance with OMB Circular A-11 instructions   |
|        | and the U.S. SGL crosswalk to the SF-133 report.            |
+--------+-------------------------------------------------------------+
| GLG-10 | **Financial statements---**Generate the following           |
|        | consolidated agency financial statements:                   |
|        |                                                             |
|        | • Balance Sheet                                             |
|        |                                                             |
|        | • Statement of Net Cost                                     |
|        |                                                             |
|        | • Statement of Changes in Net Position                      |
|        |                                                             |
|        | • Statement of Budgetary Resources                          |
|        |                                                             |
|        | • Statement of Financing                                    |
|        |                                                             |
|        | • Statement of Custodial Activity (if applicable).          |
|        |                                                             |
|        | Parameter is the accounting period end date. Reports are to |
|        | be generated from the general ledger account balances and   |
|        | attributes crosswalked in accordance with the U.S. SGL      |
|        | Crosswalks to Standard External Reports. Results are        |
|        | reports in accordance with the current OMB Bulletin on Form |
|        | and Content of Agency Financial Statements.                 |
+--------+-------------------------------------------------------------+
| GLG-11 | **Statement customization---**Customize agency financial    |
|        | statement formats by adding or deleting line items,         |
|        | changing the name of line items, inserting additional       |
|        | subtotals, or modifying account crosswalks through table    |
|        | updates or report writing capability.                       |
+--------+-------------------------------------------------------------+
| GLG-12 | **GFRS Statements---**Generate reclassified consolidated    |
|        | agency financial statements for input to GFRS in accordance |
|        | with current TFM Agency Reporting Requirements for the      |
|        | Financial Report of the United States Government and the    |
|        | U.S SGL Crosswalks to the Closing Package.                  |
+--------+-------------------------------------------------------------+
| GLG-13 | **On-line statements---**Generate consolidated financial    |
|        | statements on-line. Drill-down from the consolidated        |
|        | amounts to the GL accounts and balances that make up the    |
|        | amounts, from the GL account balances to the individual     |
|        | balances by TAS, and to detailed GL transactions.           |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

# Budgetary Resource Management Function

Article I, section 9, of the Constitution of the United States provides
that "no money shall be drawn from the Treasury, but in Consequence of
Appropriations made by law...." From this basic provision, a body of
laws and regulations has evolved to govern the Federal budget process
and prescribe generally uniform procedures for obtaining, expending,
administering, and controlling resources. Federal appropriations law,
U.S. Comptroller General Decisions, and OMB Circular A-11, *Preparation,
Submission, and Execution of the Budget*, constitute authoritative
guidance and set governmentwide policy for budgetary resource
management.

To comply with OMB Circular A-11, each agency of the Federal Government
is responsible for preparing an agency budget estimate to request
funding and for establishing a system for ensuring that it does not
obligate or disburse funds in excess of those appropriated or
authorized. The Budgetary Resource Management function of the Core
financial system is an agency's primary tool for carrying out this
responsibility. In addition to supporting the governmentwide policies,
the Budgetary Resource Management function must support agency policies
on internal funds allocation methods and controls.

An agency will likely have many other systems in addition to the Core
financial system that affect budgetary resources. For example,
procurement and travel systems generate documents that commit and
obligate funds. These and other systems that affect funds availability
should access data in and use processes of the Core financial system to
verify that funds are available and to update balances. These systems
typically access the funds availability editing activity before allowing
an obligation to be incurred, such as when entering into a contract.
However, in some cases, such as payroll, this may not be practical.

The Budgetary Resource Management function consists of the following
processes (the prefixes assigned to the requirements are noted in
parentheses):

-   Budget Planning (FMA)

-   Budget Preparation (FMB)

-   Budget Authority (FMC)

-   Funds Distribution (FMD)

-   Funds Control (FME)

-   Funds Status (FMF).

## Budget Planning Process

Budget planning is the process of establishing the initial agency budget
plan. The budget plan is a blueprint for using financial resources
during any given fiscal period or series of periods. The Budget Planning
process includes updating the budget plan as necessary and reporting on
the use of resources against these plans throughout the year.

##### Mandatory Requirements

To support the Budget Planning process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

  --------- -------------------------------------------------------------
  FMA-01    **Financial operating plans---**Capture financial operating
            plans for any funded organization level or other accounting
            classification.

  FMA-02    **Spending plans---**Capture spending plans for any funded
            organization level or other accounting classification.

  FMA-03    **Plan periods---**Capture financial operating and spending
            plans by month, quarter and year.

  FMA-04    **Export plan data---**Export financial operating and
            spending plan data at the accounting line item level in an
            Excel or ASCII text delimited file format.
  --------- -------------------------------------------------------------

##### Value-Added Requirements

To add value to the Budget Planning process, the Core financial system
**[should]{.underline}** provide automated functionality to do the
following:

  --------- -------------------------------------------------------------
  FMA-05    **Plan measurements---**Generate plan results based on
            multiple measures including fixed dollar amounts, unit costs,
            cost allocations, labor hours or full-time equivalents
            (FTEs).

  FMA-06    **Plan versions---**Maintain current and multiple historical
            versions of plans.

  FMA-07    **Compare plans---**Compare multiple versions of plans.

  FMA-08    **Future plans---**Maintain financial operating and spending
            plans for future periods (i.e., future fiscal years).

  FMA-09    **Plan activation---**Activate future period plans based on a
            specified plan start date or on-demand.

  FMA-10    **Planned to actual---**Compare planned spending to actual
            spending.
  --------- -------------------------------------------------------------

## Budget Preparation Process

Budget preparation is the process of assembling estimates for the
upcoming fiscal year for transmittal to OMB and the congressional
appropriations committees, preparing justification materials to support
those estimates, and defending those estimates formally (at OMB and
congressional hearings) and informally (through staff contacts with
these entities).

##### Mandatory Requirements

There are no mandatory requirements for this process.

##### Value-Added Requirements

To add value to the Budget Preparation process, the Core financial
system **[should]{.underline}** provide automated functionality to do
the following:

  --------- -------------------------------------------------------------
  FMB-01    **Budget information---**Classify budget projections using
            accounting classification elements (e.g., Apportionment
            categories, Authority type, etc.).

  FMB-02    **Import budget formulation data---**Import budget
            formulation data (e.g., Presidential/OMB pass backs,
            congressional markup documents, and internal agency
            decisions).

  FMB-03    **Calculate prior year budget data---**Calculate prior year
            budgets, actual spending amounts and variances at the line
            item level.

  FMB-04    **Export prior year budget data---**Export prior year
            budgets, actual spending and variances at the line item level
            in an excel or ASCII text delimited file format.

  FMB-05    **Projected activity---**Generate projected future period
            obligations, income, and expenditures at any level of the
            organizational structure based on prior year actual activity
            using agency-defined projection rates.

  FMB-06    **Define projection rates---**Define projection rates (e.g.,
            90%, 100%, 110%) by budget object class for use in budget
            formulation.

  FMB-07    **Apply projection rates---**Calculate budget amounts for
            all, selected groups, or individual budget line items based
            on agency-defined projection rates.

  FMB-08    **What if analysis---**Generate multiple budgets based on
            alternative agency-specified accounting structures, funding
            levels, and spending criteria.

  FMB-09    **Payroll forecasts---**Generate payroll forecasts (i.e.,
            anticipated compensation and benefits) at the object class
            and individual employee level.

  FMB-10    **Modified payroll forecasts---**Generate modified payroll
            forecasts.

  FMB-11    **Projected overhead---**Generate overhead projections using
            agency defined overhead rates.

  FMB-12    I**mport budget information---**Import budget formulation
            data submitted in Excel or ASCII text delimited format.

  FMB-13    **Import budget submission guidance---**Import budget
            submission guidance, other narrative text and briefing
            material written using common PC desktop applications (e.g.,
            MS Word).

  FMB-14    **Distribute budget submission guidance---**Distribute budget
            submission guidance electronically.

  FMB-15    **Budget cycles---**Generate budget information for multiple
            budget cycles (e.g. monthly, quarterly, semi-annual, and
            yearly).

  FMB-16    **Budget and GPRA goals---**Associate budget formulation line
            items to the agency's stated goals and objectives required by
            GPRA.

  FMB-17    **Budget information---**Generate budget formulation
            information for all categories on which legally binding
            budgetary decisions are made (e.g., appropriation
            limitations).

  FMB-18    **Administrative budget information---**Generate budget
            formulation information for administrative purposes as in the
            nature of policy guidance and decision making (e.g.,
            Presidential/OMB pass backs, congressional markup documents,
            or internal agency decisions).

  FMB-19    **SF 132 TAFS data---**Capture SF-132 Schedule data by TAFS.

  FMB-20    **Export SF 132 Schedules---**Export SF-132 Schedules for
            each TAFS requiring apportionment in Excel file format
            specified by OMB.
  --------- -------------------------------------------------------------

## Budget Authority Process

Establishing budget authority, formerly referred to as Funds Allocation,
is the beginning of the budget execution process. This process records
an agency's budgetary resources and supports the establishment of legal
budgetary limitations within the agency, including appropriation
warrants, apportionments, reapportionments, transfer allocations, and
continuing resolutions. It also supports the establishment of funding to
agencies that are not subject to apportionment.

##### Mandatory Requirements

To support the Budget Authority process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

  --------- -------------------------------------------------------------
  FMC-01    **Budget execution documents---**Record funding based on
            related budget execution documents (e.g., appropriation
            warrants and apportionments).

  FMC-02    **Budget execution documents data---**Capture fund specific
            information (e.g., public law, program, authority type,
            apportionment category, etc.) on budget execution documents.

  FMC-03    **Budget authority types---**Record budgetary authority
            (defined in OMB Circular A-11) including direct
            appropriations, borrowing authority, contract authority, and
            spending authority from offsetting collections.

  FMC-04    **Internal funds control document---**Capture multiple
            internal fund codes based on a single apportionment schedule,
            ensuring that unique fund characteristics (e.g. authority
            type, apportionment category) are available for funds control
            purposes.

  FMC-05    **Changes to budget authority---**Record changes to budget
            authority including reductions; rescissions; amounts withheld
            or made unavailable; supplementals, transfers; reprogramming;
            legal limitations and changes to continuing resolutions.

  FMC-06    **Expirations of budget authority---**Record the expiration
            and cancellation of budget authority in accordance with OMB
            Circular A-11.

  FMC-07    **Continuing resolutions---**Record multiple, successive
            continuing resolutions.

  FMC-08    **CR effective dating---**Capture the start and end dates,
            amount, and public law number of a continuing resolution.

  FMC-09    **CR amendments---**Record amendments to the amount and/or
            effective dates of an existing Continuing Resolution.

  FMC-10    **Revolving funds---**Process revolving fund contracts, work
            orders, and projects. Monitor all related advances,
            prepayments and reimbursements.

  FMC-11    **Reimbursable authority---**Calculate available fund
            balances based on reimbursable agreement authority.

  FMC-12    **Advance funding edit---**Prevent the use of funds against
            reimbursable agreements with the public and other non-federal
            entities without an advance.

  FMC-13    **SF 132 apportionment data---**Record apportioned funds in
            accordance with the latest OMB approved SF 132 Apportionment
            and Reapportionment Schedule.
  --------- -------------------------------------------------------------

##### Value-Added Requirements

There are no value-added requirements for this process.

## Funds Distribution Process

Funds distribution is the part of budget execution cycle in which
legally apportioned resources are distributed within the agency to
support missions, programs, and other objectives. The process
establishes multiple levels of budgetary control by allotting and
sub-allotting apportioned resources for agency management.

##### Mandatory Requirements

To support the Funds Distribution process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| FMD-01 | **Limitations---**Capture legal (statutory) and             |
|        | administrative (agency imposed) limitations on the use of   |
|        | funds.                                                      |
+--------+-------------------------------------------------------------+
| FMD-02 | **Fund distributions---**Record allotments, sub-allotments, |
|        | allocations and                                             |
|        |                                                             |
|        | allowances (i.e. distribute funds) to multiple              |
|        | organizational levels or other                              |
|        |                                                             |
|        | elements of accounting classification.                      |
+--------+-------------------------------------------------------------+
| FMD-03 | **Fund distribution levels---**Record up to eight levels of |
|        | funds distribution including levels used for appropriation  |
|        | and apportionment of budget authority.                      |
+--------+-------------------------------------------------------------+
| FMD-04 | **Fund distribution availability---**Prevent the            |
|        | distribution of funds in excess of the amount of funds      |
|        | available at the next highest distribution level.           |
+--------+-------------------------------------------------------------+
| FMD-05 | **Fund distribution modification---**Record the             |
|        | modification of funding distributions at multiple           |
|        | organizational levels or elements of the accounting         |
|        | classification structure.                                   |
+--------+-------------------------------------------------------------+
| FMD-06 | **Withdrawal of unobligated funds by TAFS---**Record the    |
|        | withdrawal (or cancellation) of unobligated allotments and  |
|        | sub-allotments (both expired and unexpired) for all or      |
|        | selected TAFS at the end of a fiscal period or on demand as |
|        | in rescissions.                                             |
+--------+-------------------------------------------------------------+
| FMD-07 | **Withdrawal of unobligated funds by                        |
|        | organization---**Record the withdrawal (or cancellation) of |
|        | unobligated allotments and sub-allotments (both expired and |
|        | unexpired) for selected organizations at the end of a       |
|        | specific fiscal period or on demand as in rescissions.      |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

To add value to the Funds Distribution process, the Core financial
system **[should]{.underline}** provide automated functionality to do
the following:

  --------- -------------------------------------------------------------
  FMD-08    **Plan-based funding updates---**Update allotments,
            sub-allotments, allocations and legal and administrative
            limitations based on changes to operating plans.

  FMD-09    **System-generated allotments---**Generate allotment and
            sub-allotment information with sufficient detail to support
            funds control.

  FMD-10    **Distribute allotments---**Distribute system-generated
            allotment and sub-allotment information electronically to
            subordinate organizations.

  FMD-11    **Reprogramming requests---**Capture requests for
            reprogramming of funds or additional funds outside the formal
            budget process.

  FMD-12    **Reprogramming request status---**Capture submitted,
            reviewed and approved status information on re-programming
            requests.

  FMD-13    **Record reprogramming requests---**Record budget authority
            changes based upon approval of reprogramming requests.
  --------- -------------------------------------------------------------

## Funds Control Process

Funds control prevents the expenditure of funds in excess of established
budgetary limitations as established through the Funds Distribution
process. The Core financial systems must be designed to apply effective
funds control at the point that spending documents are entered. The
Funds Control process consists of the following document processing
activities:

-   *Funds Availability Editing.* This activity verifies that sufficient
    funds are available for each processed spending transaction that
    affects the agency's available fund balances.

-   *Commitments.* This activity records commitment documents (e.g.,
    requisitions). Commitments allow the agency to "reserve" funds
    before legal obligations are established. Commitments are a useful
    funds control tool, but are not appropriate for all spending
    situations. In cases where the agency determines that the use of
    commitments is appropriate, the Core financial management system
    must provide the capability to apply funds control as defined in
    this document.

-   *Obligations.* This activity records obligating documents in the
    Core system. OMB Circular A-11 defines obligations as a binding
    agreement that will result in outlays, immediately or in the future.
    Budgetary resources must be available before obligations can be
    legally incurred. Examples are amounts of orders placed, contracts
    awarded, services received, and similar transactions that require
    payments during the current or a future period.

-   *Advances.* This activity records advances made to others by the
    agency. Advances include money prepaid under a statutory
    authorization for goods, services, or other assets to be received at
    a later date. For example, payment for all or any part of the
    estimated cost of the work could be made to the provider filling the
    order in advance. Later, the advance payments are adjusted as agreed
    to on the basis of the actual cost of goods or services provided.

    All requirements relating to Funds Control are grouped by these
    activities.

##### Mandatory Requirements

To support the Funds Control/Funds Availability Editing activity, the
Core financial system **[must]{.underline}** provide automated
functionality to do the following:

  --------- -------------------------------------------------------------
  FME-01    **Monitor use of funds---**Monitor the use of funds at each
            organizational level or other accounting classification to
            which budget authority is distributed. Reject, warn or inform
            the agency by spending document line when distributed
            authority is exceeded.

  FME-02    **Spending documents---**Process spending documents that
            affect the availability of funds, including commitments,
            obligations, advances, and expenditures.

  FME-03    **Spending transactions---**Record spending transactions,
            including commitments, obligations, advances and
            expenditures, at or below the level in the accounting
            classification than they are budgeted.

  FME-04    **Prior year funds---**Record transactions against prior year
            funds, both expired and unexpired, in the current year.

  FME-05    **Closed account payments---**Monitor amounts paid out of
            current year funds to cover obligations made against a
            cancelled account (TAFS). Prevent payments that cumulatively
            exceed 1 percent of the current year appropriation or the
            total amount available prior to close of the original
            appropriation.

  FME-06    **Spending document classification---**Capture accounting
            classification information on commitments, obligations,
            advances, and expenditures at the accounting line item level.

  FME-07    **Historical spending data---**Maintain a history of changes
            made to commitment, obligation, advance, and expenditure
            documents.

  FME-08    **Open spending document detail---**Maintain open documents
            to show the status of commitments, obligations, advances,
            accruals and disbursements by document (commodity) line item.

  FME-09    **Validate funds availability---**Validate funds availability
            prior to recording spending transactions.

  FME-10    **Use of unexpired, expired or cancelled funds---**Derive
            funds availability based on the budget fiscal year of the
            originating document, i.e., whether funds cited are
            unexpired, expired, or cancelled. Record U.S. SGL prescribed
            general ledger entries when de-obligation of expired funding
            occurs.

  FME-11    **Reuse of de-obligated funds---**Validate period of
            availability. Prevent the allotment and reuse of de-obligated
            balances for new obligations in expired funds.

  FME-12    **Fund control updates---**Update balances used for funds
            controls to reflect changes in the status and amounts of
            commitments, obligations, expenditure and available balances.

  FME-13    **Monitor plans---**Monitor the use of funds against
            financial operating and spending plans.

  FME-14    **Monitor limitations---**Monitor the use of funds against
            legal (statutory) and administrative (agency imposed).

  FME-15    **Monitor object class limitations---**Monitor the use of
            funds against specific object class limitations.

  FME-16    **Monitor reimbursable agreements---**Monitor spending
            against reimbursable agreement amounts.

  FME-17    **Reduce reimbursable balance---**Reduce reimbursable
            authority and reimbursable agreement balances when customer
            orders are recorded.

  FME-18    **Monitor contracts---**Monitor the use of funds against
            contracts, work-orders, task orders, and grants.
  --------- -------------------------------------------------------------

To support the Funds Control/Commitments activity, the Core financial
system **[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| FME-19 | **Suggested vendor---**Capture a suggested vendor on        |
|        | commitment documents.                                       |
+--------+-------------------------------------------------------------+
| FME-20 | **Close commitments---**Close commitment documents and      |
|        | document lines under the following circumstances:           |
|        |                                                             |
|        | • By the system upon issuance of an obligating document     |
|        |                                                             |
|        | • By an authorized user                                     |
|        |                                                             |
|        | • As part of the year-end pre-closing process.              |
+--------+-------------------------------------------------------------+

To support the Funds Control/Obligations activity, the Core financial
system **[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| FME-21 | > **Obligating document data---**Capture the following      |
|        | > additional data elements on obligating documents:         |
|        | >                                                           |
|        | > • Obligation type                                         |
|        | >                                                           |
|        | > • Prompt pay indicator and type, or payment terms         |
|        | > (including discount terms)                                |
|        | >                                                           |
|        | > • Fast Pay indicator                                      |
|        | >                                                           |
|        | > • Matching terms (2-way, 3-way, 4-way)                    |
|        | >                                                           |
|        | > • Vendor ID number                                        |
|        | >                                                           |
|        | > • Vendor name (legal, DBA or division)                    |
|        | >                                                           |
|        | > • DUNS + 4 number                                         |
|        | >                                                           |
|        | > • NAICS code                                              |
|        | >                                                           |
|        | > • SIC code                                                |
|        | >                                                           |
|        | > • Approval date.                                          |
+--------+-------------------------------------------------------------+
| FME-22 | **Define obligation types---**Define the obligation types   |
|        | to be captured on obligation documents, based on budget     |
|        | object class (e.g., travel, payroll), agency source         |
|        | document (e.g., travel order, purchase order, grant) or     |
|        | other agency-specified criteria.                            |
+--------+-------------------------------------------------------------+
| FME-23 | **Validate CCR vendor name on obligations---**Validate that |
|        | the vendor name on an obligation is the same as the vendor  |
|        | name on the vendor file, for registered CCR vendors.        |
+--------+-------------------------------------------------------------+
| FME-24 | **No related commitment---**Record obligations when there   |
|        | is no related commitment.                                   |
+--------+-------------------------------------------------------------+
| FME-25 | **Different vendors---**Capture a different vendor on an    |
|        | obligating document than the vendor captured on a           |
|        | referenced commitment.                                      |
+--------+-------------------------------------------------------------+
| FME-26 | **Close obligations---**Close obligation documents under    |
|        | the following                                               |
|        |                                                             |
|        | circumstances:                                              |
|        |                                                             |
|        | > • By the system upon final payment for goods or services, |
|        | > or                                                        |
|        | >                                                           |
|        | > • By an authorized user.                                  |
|        |                                                             |
|        | Upon the closing of an obligation, classify any             |
|        | de-obligation of excess funds by budgetary status (i.e.,    |
|        | expired, unexpired, available for obligation or             |
|        | unavailable).                                               |
+--------+-------------------------------------------------------------+
| FME-27 | **Records of call---**Process, track, and control records   |
|        | of call against blanket purchase agreements.                |
+--------+-------------------------------------------------------------+
| FME-28 | **Delivery orders---**Process, track, and control delivery  |
|        | orders against contract limitations.                        |
+--------+-------------------------------------------------------------+

To support the Funds Control/Advances activity, the Core financial
system **[must]{.underline}** provide automated functionality to do the
following:

  --------- -------------------------------------------------------------
  FME-29    **Advance payments---**Record advance payments made, such as
            travel advances, contract prepayments, and grant advances.
            When recording an advance payment, reference an obligating
            document and bring forward all accounting information. In
            cases where no obligating document is available, reduce funds
            availability and create an obligating document to support the
            advance payment made.

  FME-30    **Expenditures against advances---**Record advance payment
            refunds by document or document line item. Update the advance
            balance.

  FME-31    **Expenditures incurred---**Record expenditures incurred
            against advance payments made, reducing the advance balance
            and liquidating the referenced obligation.
  --------- -------------------------------------------------------------

##### Value-Added Requirements

To add value to the Funds Control process, the Core financial system
**[should]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| FME-32 | **Additional obligation data---**Capture the following      |
|        | other data fields on obligating documents:                  |
|        |                                                             |
|        | > • Requester's name                                        |
|        | >                                                           |
|        | > • Telephone number of requester                           |
|        | >                                                           |
|        | > • Deliver to location (e.g., room number, division)       |
|        | >                                                           |
|        | > • Contact name                                            |
|        | >                                                           |
|        | > • COTR name                                               |
|        | >                                                           |
|        | > • COTR telephone number                                   |
|        | >                                                           |
|        | > • Comments.                                               |
+--------+-------------------------------------------------------------+

## Funds Status Process

The Funds Status process provides budgetary information to enable agency
personnel to analyze, monitor, and adjust funding for programs
throughout the fiscal year.

##### Mandatory Requirements

To support the Funds Status process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| FMF-01 | **Status of Funds Report---**Generate the Status of Funds   |
|        | Report. Parameter is the accounting period. Result is a     |
|        | report providing the following information for each         |
|        | allotment recorded by the agency:                           |
|        |                                                             |
|        | > • Accounting classification elements                      |
|        | >                                                           |
|        | > • Total Allotment                                         |
|        | >                                                           |
|        | > • Commitments                                             |
|        | >                                                           |
|        | > • Obligations                                             |
|        | >                                                           |
|        | > • Expenditures                                            |
|        | >                                                           |
|        | > • Available Balance                                       |
|        |                                                             |
|        | Available balance must equal the GL balance in the 4610 or  |
|        | 4620 account. Amounts should be cumulative from the         |
|        | beginning of the fiscal year through the accounting period  |
|        | specified. If reporting for the current period, amounts     |
|        | must be cumulative up through the current date.             |
+--------+-------------------------------------------------------------+
| FMF-02 | **Status of Funds Query---**Query status of funds.          |
|        | Parameters include accounting period, and allotment         |
|        | accounting classification. Result is a display providing    |
|        | the following information:                                  |
|        |                                                             |
|        | > • Accounting classification elements                      |
|        | >                                                           |
|        | > • Total Allotment                                         |
|        | >                                                           |
|        | > • Commitments                                             |
|        | >                                                           |
|        | > • Obligations                                             |
|        | >                                                           |
|        | > • Expenditures                                            |
|        | >                                                           |
|        | > • Available Balance (available balance must equal the     |
|        | > balance in the 4610 or 4620 account).                     |
|        |                                                             |
|        | Drill down from the commitments line, obligations line, and |
|        | the expenditures line to the detailed transactions,         |
|        | documents, and document detail that support these lines.    |
+--------+-------------------------------------------------------------+
| FMF-03 | **Contract/BPA Activity Report---**Generate a contract/BPA  |
|        | activity report. Parameters include contract/BPA number     |
|        | accounting period and period covered (monthly, quarterly,   |
|        | fiscal year-to-date, or inception-to-date). Result is list  |
|        | of accounting activity (obligations, expenditures,          |
|        | disbursements, etc.) under the contract/BPA, with vendor    |
|        | information, period of performance, document numbers,       |
|        | delivery order/task order numbers, accounting               |
|        | classification information, transaction dates and amounts.  |
|        | Sorting options include transaction date, document type and |
|        | accounting classification.                                  |
+--------+-------------------------------------------------------------+
| FMF-04 | **Reimbursable Agreement Activity Report---**Generate a     |
|        | reimbursable agreement activity report. Parameters include  |
|        | reimbursable agreement number, accounting period and period |
|        | covered (monthly, quarterly, fiscal year-to-date, or        |
|        | inception-to-date). Result is a list of accounting activity |
|        | (commitments, obligations, advances, expenditures, etc.)    |
|        | under the reimbursable agreement, with customer/vendor      |
|        | information, period of performance, document numbers,       |
|        | accounting classification information, transaction dates    |
|        | and amounts. Sorting options include transaction date,      |
|        | document type and accounting classification.                |
+--------+-------------------------------------------------------------+
| FMF-05 | **Budget query---**Query budget information. Parameters     |
|        | include accounting classifications. Result is budgetary     |
|        | authority amounts (all types, as applicable to the fund     |
|        | type), spending activity (e.g., obligations, expenditures), |
|        | and the available balance. Displayed amounts should be      |
|        | consistent with amounts derived using the U.S. SGL          |
|        | crosswalk to the SF-133.                                    |
+--------+-------------------------------------------------------------+
| FMF-06 | **System assurance for funds availability---**Validate that |
|        | funds availability balances used for funds control and      |
|        | funds status reporting agree with the general ledger.       |
+--------+-------------------------------------------------------------+
| FMF-07 | **MAX budget data---**Maintain budget data needed to        |
|        | support OMB's MAX A-11 system requirements that agencies    |
|        | currently fulfill via their FACTS II submissions to FMS.    |
+--------+-------------------------------------------------------------+
| FMF-08 | **MAX budget data reporting---**Generate Excel files that   |
|        | are consistent with the presentation of the program and     |
|        | financing schedule and the object class schedule published  |
|        | in OMB Circular A-11.                                       |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

To add value to the Funds Status process, the Core financial system
**[should]{.underline}** provide automated functionality to do the
following:

  --------- -------------------------------------------------------------
  FMF-09    **Funds availability notification by exception---**Notify the
            agency when funds availability is reduced based on the
            processing of agency-specified transaction types or sources
            (e.g., credit card payments and payroll).

  FMF-10    **Funds availability notification by percent---**Notify the
            agency when funds availability by TAFS or internal fund code
            reaches a pre-defined percent of the original total funding
            amount.

  FMF-11    **Other MAX Budget Data Reporting---**Generate Excel files
            that are consistent with the presentation of budget
            schedules published in OMB Circular A-11.
  --------- -------------------------------------------------------------

# Payment Management Function

The Payment Management function deals with accounts payable. Depending
on an agency's system architecture, specific activities relating to
payments may be supported in Core by other systems that provide payment
data to the Core financial system for control and management. For
example, payroll systems usually trigger actual disbursements to
employees through direct deposit or by check, and send only the expense
and disbursement information to the Core financial system for recording
the impact on the general ledger, funds control, and cost management
processes. Likewise, loan and grant programs might be supported by
systems that maintain their own information on payees and payments and
send transaction data to the Core financial system.

Other systems may support activities that lead up to the payment stage,
such as recording obligations and expenditures and establishing
payables, but depend on the Core financial system to manage the actual
payment process itself. For example, a travel system might calculate the
amount to be paid on a travel voucher and send transactions to the Core
financial system to record the expenses and a payable to the traveler.
The Core financial system would then schedule the payment for
disbursement and confirm that the disbursement has been made.

The Payment Management function consists of the following processes (the
prefixes assigned to the requirements are noted in parentheses):

-   Payee Information Maintenance (PMA)

-   Accounts Payable (PMB)

-   Invoicing (PMC)

-   Disbursing (PMD)

-   Payment Follow-Up (PME).

## Payee Information Maintenance Process

The term "payee" is used here to include any entity to which
disbursements may be made, for example, individuals and organizations
providing goods and services, employees, grant recipients, loan
recipients, and other government agencies. In an integrated system,
payee information needed to make payments should be coordinated with
information needed for other purposes and in other systems. For example,
a company that provides goods and services to an agency should have a
common identifier, such as a TIN, associated with it that is shared by
the procurement and payment processes. With this common identifier,
contract information and payment information can be linked, even if the
addresses for ordering and paying are different. Furthermore, such
information should also be available to the procurement and payment
processes.

Subpart 4.11 of the FAR prescribes policies and procedures for requiring
contractor registration in the CCR database, the common source of vendor
data for the Federal Government. Both current and potential government
vendors are required to register in CCR in order to be awarded contracts
by the government. The CCR validates the vendors' information and
electronically shares the data with the Federal agencies' finance
offices to facilitate paperless payments through EFT. Agencies' Core
financial systems must accommodate the data elements and definitions
used in the CCR in order to facilitate this information exchange and to
maintain current information on the vendors with which they conduct
business.

##### Mandatory Requirements

To support the Payee Information Maintenance process, the Core financial
system **[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| PMA-01 | **Vendor information---**Capture the following vendor       |
|        | information:                                                |
|        |                                                             |
|        | > • Vendor ID number (agency-assigned)                      |
|        | >                                                           |
|        | > • Vendor name (Legal)                                     |
|        | >                                                           |
|        | > • Vendor name (DBA)                                       |
|        | >                                                           |
|        | > • Vendor name (Division)                                  |
|        | >                                                           |
|        | > • Vendor address                                          |
|        | >                                                           |
|        | > • Business type (support CCR published business rules for |
|        | > business type: Federal govt., state govt., small          |
|        | > business, etc.)                                           |
|        | >                                                           |
|        | > • Organization type (support CCR published business rules |
|        | > for organization type: sole proprietorship/Individual;    |
|        | > partnership, employee, etc.)                              |
|        | >                                                           |
|        | > • US or Non-US                                            |
|        | >                                                           |
|        | > • Product Service codes                                   |
|        | >                                                           |
|        | > • SIC code                                                |
|        | >                                                           |
|        | > • NAICS code                                              |
|        | >                                                           |
|        | > • Credit Card Vendor Indicator                            |
|        | >                                                           |
|        | > • DUNS number                                             |
|        | >                                                           |
|        | > • DUNS + 4 number for each instance of banking            |
|        | > information, for CCR vendors                              |
|        | >                                                           |
|        | > • Prompt Pay indicator and type, or payment terms         |
|        | >                                                           |
|        | > • IRS 1099 indicator                                      |
|        | >                                                           |
|        | > • IRS W-2 indicator                                       |
|        | >                                                           |
|        | > • CCR registration indicator (required, exempt)           |
|        | >                                                           |
|        | > • CCR registration status (active or expired)             |
|        | >                                                           |
|        | > • Comment field                                           |
|        | >                                                           |
|        | > • Active/Inactive indicator                               |
|        | >                                                           |
|        | > • Debarment indicator                                     |
|        | >                                                           |
|        | > • Debarment start and end dates                           |
|        | >                                                           |
|        | > • GFRS and FACTS I trading partner codes for Federal      |
|        | > vendors                                                   |
|        | >                                                           |
|        | > • ALC (for Federal vendors)                               |
|        | >                                                           |
|        | > • Disbursing Office Symbol (for Federal vendors)          |
|        | >                                                           |
|        | > • Default payment method, e.g., check, EFT                |
|        | >                                                           |
|        | > • Alternate payment methods                               |
|        | >                                                           |
|        | > • TIN                                                     |
|        | >                                                           |
|        | > • Foreign address indicator                               |
|        | >                                                           |
|        | > • Four remittance addresses, for check payments           |
|        | > (including street address, city, state, zip code, and     |
|        | > country)                                                  |
|        | >                                                           |
|        | > • Contact name, telephone number and e-mail address for   |
|        | > each remittance address                                   |
|        | >                                                           |
|        | > • Four instances of EFT banking information (including    |
|        | > account number; account type (e.g., checking, savings);   |
|        | > and RTN)                                                  |
|        | >                                                           |
|        | > • Four instances of EFT bank name and address             |
|        | >                                                           |
|        | > • Contact name, telephone number and e-mail address for   |
|        | > each instance of EFT banking information, accommodating   |
|        | > contact types defined as mandatory" in CCR business       |
|        | > rules.                                                    |
+--------+-------------------------------------------------------------+
| PMA-02 | **Third-party vendor information---**Capture third-party    |
|        | payee information associated a primary vendor including:    |
|        |                                                             |
|        | > • Payee name                                              |
|        | >                                                           |
|        | > • Payee point of contact                                  |
|        | >                                                           |
|        | > • Payee telephone number                                  |
|        | >                                                           |
|        | > • Payee email address                                     |
|        | >                                                           |
|        | > • Remittance address or/banking information (account      |
|        | > number, account type, RTN).                               |
+--------+-------------------------------------------------------------+
| PMA-03 | **Vendor/customer relationships---**Associate vendor and    |
|        | customer records that represent the same entity.            |
+--------+-------------------------------------------------------------+
| PMA-04 | **CCR updates to vendor data---**Import CCR data. Update    |
|        | vendor data for relevant changes contained in the CCR's     |
|        | daily extract files. Support the data definitions (e.g.     |
|        | data types; field names; field lengths) used in CCR for     |
|        | fields that are common to the CCR and the Core vendor file. |
+--------+-------------------------------------------------------------+
| PMA-05 | **CCR company name change exception report---**Identify     |
|        | updated CCR company names (legal, DBA or division) that are |
|        | different than vendor names on obligations. Generate an     |
|        | exception report to notify agencies of contracts that       |
|        | require modification. Result is a list of selected vendor   |
|        | numbers, details of the CCR company name change, related    |
|        | obligation document numbers and associated vendor names.    |
+--------+-------------------------------------------------------------+
| PMA-06 | **Agency updates to CCR vendor data---**Prevent the agency  |
|        | from manually updating CCR vendor data for vendors required |
|        | to register in the CCR.                                     |
+--------+-------------------------------------------------------------+
| PMA-07 | **DUNS number to TIN association---**Associate multiple     |
|        | DUNS numbers with a single TIN.                             |
+--------+-------------------------------------------------------------+
| PMA-08 | **DUNS+4 to DUNS number association---**Associate multiple  |
|        | DUNS plus 4 numbers to a single DUNS number.                |
+--------+-------------------------------------------------------------+
| PMA-09 | **Banking information to DUNS+4 number                      |
|        | association---**Associate one DUNS+4 with each instance of  |
|        | a vendor's CCR banking information.                         |
+--------+-------------------------------------------------------------+
| PMA-10 | **Validate vendor TINs---**Validate for duplicate TIN when  |
|        | adding or updating vendor records. Notify the agency when   |
|        | duplicate TINs are identified. Allow the error message to   |
|        | be overridden.                                              |
+--------+-------------------------------------------------------------+
| PMA-11 | **Vendor file query---**Query vendor file. Parameters       |
|        | include:                                                    |
|        |                                                             |
|        | > • Vendor number                                           |
|        | >                                                           |
|        | > • Vendor legal name                                       |
|        | >                                                           |
|        | > • Vendor DBA Name                                         |
|        | >                                                           |
|        | > • Vendor Division                                         |
|        | >                                                           |
|        | > • Vendor TIN                                              |
|        | >                                                           |
|        | > • DUNS number                                             |
|        | >                                                           |
|        | > • IRS 1099 indicator.                                     |
|        |                                                             |
|        | Result is a display of all vendor data for the specified    |
|        | vendor. Output options include an Excel formatted data      |
|        | file.                                                       |
+--------+-------------------------------------------------------------+
| PMA-12 | **Vendor file history---**Maintain a history of changes     |
|        | made to vendor information. Capture name of data item       |
|        | changed, before and after values, entry date and time and   |
|        | ID of user who made the change.                             |
+--------+-------------------------------------------------------------+
| PMA-13 | **Vendor history query---**Query vendor history. Parameters |
|        | include vendor number, change date range. Results include   |
|        | date and time of change, ID of user who made the change,    |
|        | item name, before and after data values.                    |
+--------+-------------------------------------------------------------+
| PMA-14 | **Criteria for deactivating vendors---**Deactivate vendors  |
|        | on demand or based on agency-specified length of time with  |
|        | no activity.                                                |
+--------+-------------------------------------------------------------+
| PMA-15 | **Vendor deactivation edit---**Prevent the deactivation of  |
|        | vendors that have unliquidated obligations or unpaid        |
|        | invoices in the system.                                     |
+--------+-------------------------------------------------------------+
| PMA-16 | **Debarred vendors---**Prevent new obligations that         |
|        | reference inactive or debarred vendors.                     |
+--------+-------------------------------------------------------------+
| PMA-17 | **Expired CCR registrations---**Prevent new obligation and  |
|        | payment to vendors with expired CCR registrations.          |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

## Accounts Payable Process

This process recognizes and records accounts payable due to another
entity in the near term. These payables may be due for any of several
reasons, for example, as a result of receiving goods and services in
accordance with contract terms, under a loan or grant agreement, as an
advance payment for goods or services to be provided in the future, or
as a progress payment under a construction contract.

##### Mandatory Requirements

To support the Accounts Payable process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| PMB-01 | **Receipt and acceptance---**Record full or partial receipt |
|        | and/or acceptance of goods and services by document line    |
|        | item. This is to include the receipt and/or acceptance of   |
|        | partial quantities of goods and services on each document   |
|        | line.                                                       |
+--------+-------------------------------------------------------------+
| PMB-02 | **Accrued liability upon receipt---**Record an accrued      |
|        | liability and the reclassification of the order from        |
|        | delivered to undelivered upon receipt of goods or services. |
+--------+-------------------------------------------------------------+
| PMB-03 | **Liquidate advance/prepaid expense---**Liquidate advance   |
|        | or prepaid expense when recording an accrued liability      |
|        | (receipt of goods or services).                             |
+--------+-------------------------------------------------------------+
| PMB-04 | **Receipt document data---**Capture the following           |
|        | additional information on receipt documents (receiving      |
|        | reports):                                                   |
|        |                                                             |
|        | > • Receiving official                                      |
|        | >                                                           |
|        | > • Dates products were delivered or services were provided |
|        | >                                                           |
|        | > • Quantity/amount received                                |
|        | >                                                           |
|        | > • Vendor ID number and name                               |
|        | >                                                           |
|        | > • Ship to locations.                                      |
+--------+-------------------------------------------------------------+
| PMB-05 | **Acceptance data---**Capture the following additional      |
|        | information on the acceptance of goods/services:            |
|        |                                                             |
|        | > • Acceptance official                                     |
|        | >                                                           |
|        | > • Dates products were delivered or services were provided |
|        | >                                                           |
|        | > • Date products/services accepted                         |
|        | >                                                           |
|        | > • Quantity/amount accepted                                |
|        | >                                                           |
|        | > • Date products/services rejected                         |
|        | >                                                           |
|        | > • Quantity/amount rejected                                |
|        | >                                                           |
|        | > • Vendor ID number and name                               |
|        | >                                                           |
|        | > • Ship to locations.                                      |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

## Invoicing Process

The Invoicing process supports the recording of invoices received from
vendors and the matching of these documents to related obligation,
receipt, and acceptance documents. The matching process ensures that
payments are made in accordance with contract terms and applicable
regulations, including 5 CFR 1315. Once matched and approved, invoices
are warehoused in the Core financial system and await payment scheduling
that occurs when their payment due dates are reached. Adequate internal
controls must be in place to verify that goods and services paid for
were actually ordered, received, and accepted; that proper due dates and
payment amounts are computed; and that duplicate payments are prevented.

##### Mandatory Requirements

To support the Invoicing process the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| PMC-01 | **Invoice data---**Capture the following additional         |
|        | information on invoice documents:                           |
|        |                                                             |
|        | • Vendor invoice number or account number                   |
|        |                                                             |
|        | • Invoice date                                              |
|        |                                                             |
|        | • Invoice receipt date                                      |
|        |                                                             |
|        | • Vendor ID number and name                                 |
|        |                                                             |
|        | • Contract line/subline number                              |
|        |                                                             |
|        | • Name and address of contractor official to whom payment   |
|        | is to be sent                                               |
|        |                                                             |
|        | • EFT banking information (account number, account type,    |
|        | RTN)                                                        |
|        |                                                             |
|        | • DUNS+4 number for CCR vendors                             |
|        |                                                             |
|        | • Payment terms (including discount for prompt payment)     |
|        |                                                             |
|        | • Shipping terms (e.g., shipment number and date of         |
|        | shipment)                                                   |
|        |                                                             |
|        | • Vendor contact name and telephone number                  |
|        |                                                             |
|        | • Dates products were delivered or services were provided   |
|        |                                                             |
|        | • User comments                                             |
|        |                                                             |
|        | • Date invoice returned to vendor                           |
|        |                                                             |
|        | • Date improper invoice resubmitted by vendor.              |
+--------+-------------------------------------------------------------+
| PMC-02 | **Vendor invoice number---**Capture a vendor invoice number |
|        | of up to 30 characters or the current requirement of I      |
|        | TFM-6-5000. Report the complete number on all payment       |
|        | files, reports and query results.                           |
+--------+-------------------------------------------------------------+
| PMC-03 | **Invoice line items---**Capture up to 9,999 document line  |
|        | items per invoice document.                                 |
+--------+-------------------------------------------------------------+
| PMC-04 | **Duplicate vendor invoice edit criteria---**Define the     |
|        | criteria to be used in editing for duplicate vendor         |
|        | invoices, including one or more of the following: agency    |
|        | code, vendor number, vendor account number, vendor TIN,     |
|        | vendor invoice number, invoice date, invoice amount,        |
|        | referenced obligation document number.                      |
+--------+-------------------------------------------------------------+
| PMC-05 | **Validate for duplicate vendor invoices---**Validate for   |
|        | duplicate vendor invoices based on the agency-defined       |
|        | editing criteria.                                           |
+--------+-------------------------------------------------------------+
| PMC-06 | **Validate invoices from CCR vendors---**Validate invoices  |
|        | from registered CCR vendors for the following CCR vendor    |
|        | information:                                                |
|        |                                                             |
|        | > • Active status                                           |
|        | >                                                           |
|        | > • Vendor name on invoice or referenced obligation same as |
|        | > CCR company name (legal, DBA or division)                 |
|        | >                                                           |
|        | > • Banking information on invoice or referenced obligation |
|        | > same as banking information on vendor file.               |
+--------+-------------------------------------------------------------+
| PMC-07 | **Validate payments to CCR vendors---**At the time of       |
|        | preliminary payment scheduling, validate payments to        |
|        | registered CCR vendors for the following CCR vendor         |
|        | information:                                                |
|        |                                                             |
|        | > • Active status                                           |
|        | >                                                           |
|        | > • Vendor name same as CCR company name (legal, DBA or     |
|        | > division) on vendor file                                  |
|        | >                                                           |
|        | > • Banking information same as banking information on      |
|        | > vendor file.                                              |
|        |                                                             |
|        | Hold payments that fail these validations from inclusion in |
|        | the final payment schedules.                                |
+--------+-------------------------------------------------------------+
| PMC-08 | **Matching options---**Match invoices to obligations,       |
|        | receiving reports and acceptance information by document    |
|        | line item and quantity. Perform two-way matching            |
|        | (obligation and invoice, or obligation and receipt),        |
|        | three-way matching (obligation, simultaneous                |
|        | receipt/acceptance and invoice), and four-way matching      |
|        | (obligation, receipt, acceptance and invoice). Prevent the  |
|        | payment of invoices until the matching process is complete. |
+--------+-------------------------------------------------------------+
| PMC-09 | **Invoices for partial amount of quantities received and    |
|        | accepted---**Process invoices for payment of partial        |
|        | quantities received and accepted.                           |
+--------+-------------------------------------------------------------+
| PMC-10 | **Validate invoice period of performance---**Validate that  |
|        | invoice dates that products were delivered or services were |
|        | performed are within the period of performance dates on the |
|        | referenced obligation.                                      |
+--------+-------------------------------------------------------------+
| PMC-11 | **Validate invoice delivery/performance dates---**Validate  |
|        | that the invoice dates that products were delivered or      |
|        | services were performed are dates for which the             |
|        | products/services have been received and accepted. Prevent  |
|        | the processing of invoices with unmatched dates and the     |
|        | duplicate processing of invoices with matched dates.        |
+--------+-------------------------------------------------------------+
| PMC-12 | **Final payment---**Record an invoice as a "partial" or     |
|        | "final" payment of the referenced obligation. If "final",   |
|        | deobligate any unliquidated balance and close the           |
|        | obligation and receipt.                                     |
+--------+-------------------------------------------------------------+
| PMC-13 | **Adjust payment amounts---**Record additional shipping and |
|        | other charges to adjust the payment amount, if they are     |
|        | authorized and within variance tolerances.                  |
+--------+-------------------------------------------------------------+
| PMC-14 | **Set up recurring payments---**Define recurring payments   |
|        | in the system and schedule items (e.g. contracts, leases,   |
|        | etc.) for payment on an interval determined by the agency   |
|        | (i.e., weekly, bi-weekly, monthly, quarterly or other       |
|        | specified number of days). Capture the actual payment dates |
|        | on the individual payment records.                          |
+--------+-------------------------------------------------------------+
| PMC-15 | **Update recurring payment terms---**Update recurring       |
|        | payment information for changes in agreement terms,         |
|        | amounts, frequency, etc.                                    |
+--------+-------------------------------------------------------------+
| PMC-16 | **Warehouse Invoices---**Warehouse approved invoices for    |
|        | future scheduling.                                          |
+--------+-------------------------------------------------------------+
| PMC-17 | **Define reason codes for invoice processing                |
|        | errors---**Define reason codes and related descriptions for |
|        | invoice processing errors in the following categories:      |
|        |                                                             |
|        | > • Advantageous discount lost                              |
|        | >                                                           |
|        | > • Interest paid, and                                      |
|        | >                                                           |
|        | > • Improper payment made.                                  |
|        |                                                             |
|        | For example, DL01, Discount Lost because invoice misplaced. |
+--------+-------------------------------------------------------------+
| PMC-18 | **Define reason codes for invoice processing                |
|        | actions---**Define reason codes and related descriptions    |
|        | for invoice processing actions in the following categories: |
|        |                                                             |
|        | > • Invoice adjusted                                        |
|        | >                                                           |
|        | > • Invoice held from payment schedule                      |
|        | >                                                           |
|        | > • Invoice cancelled.                                      |
|        |                                                             |
|        | For example, PH01, Payment Held, Vendor CCR status expired, |
|        | IA03, Invoice Adjusted, Unauthorized shipping charges       |
|        | deducted, IC02, Invoice cancelled, Invoice re-submitted     |
|        | with new invoice number.                                    |
+--------+-------------------------------------------------------------+
| PMC-19 | **Define reason codes for improper invoices---**Define      |
|        | reason codes and related descriptions for improper          |
|        | invoices. For example, IP01- Improper Invoice, X data       |
|        | missing.                                                    |
+--------+-------------------------------------------------------------+
| PMC-20 | **Capture reason codes for invoice processing errors and    |
|        | actions---**Capture reason codes and related descriptions   |
|        | for the following types of invoice processing errors and    |
|        | actions:                                                    |
|        |                                                             |
|        | • Advantageous discount lost                                |
|        |                                                             |
|        | • Interest paid                                             |
|        |                                                             |
|        | • improper payment made                                     |
|        |                                                             |
|        | • Invoice adjusted                                          |
|        |                                                             |
|        | • Invoice held from payment schedule                        |
|        |                                                             |
|        | • Invoice cancelled.                                        |
+--------+-------------------------------------------------------------+
| PMC-21 | **Capture reason codes for improper invoices---**Capture    |
|        | reason codes and related descriptions for improper invoices |
|        | held or suspended (i.e., failed validations).               |
+--------+-------------------------------------------------------------+
| PMC-22 | **Notify vendor of return of improper invoice               |
|        | notice---**Generate a letter or e-mail to the vendor        |
|        | notifying them of the return of an improper invoice, upon   |
|        | the recording of an improper invoice reason code. Include   |
|        | the following information in the notice:                    |
|        |                                                             |
|        | > • Vendor invoice number and date                          |
|        | >                                                           |
|        | > • Reason code(s) and description(s) of invoice            |
|        | > discrepancies                                             |
|        | >                                                           |
|        | > • Date of notice.                                         |
|        | >                                                           |
|        | > • Request for a corrected invoice                         |
|        | >                                                           |
|        | > • Name, title, telephone number and e-mail address of     |
|        | > Agency contact person.                                    |
+--------+-------------------------------------------------------------+
| PMC-23 | **Import CCR vendor updates---**Import vendor updates from  |
|        | the CCR system and release previously suspended invoices    |
|        | and payment vouchers for the following:                     |
|        |                                                             |
|        | > • Vendor status change from expired to active             |
|        | >                                                           |
|        | > • Vendor name on document or referenced obligation now    |
|        | > the same as CCR company name (legal, DBA, or division)    |
|        | >                                                           |
|        | > • Banking information on document or referenced           |
|        | > obligation now the same as banking information on vendor  |
|        | > file.                                                     |
|        |                                                             |
|        | Calculate payment due dates for released invoices and       |
|        | re-calculate payment due dates for released payment         |
|        | vouchers.                                                   |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

## Disbursing Process

This process supports activities required to make payments that were
warehoused or to record payments made by other systems. The Core
financial system must provide the capability to prepare requests for
disbursement (payment schedules) and to create and transmit payment
files in the formats required by Treasury for the initiation of EFTs and
check payments for agencies for which Treasury does the actual
disbursing. Some agencies have delegated disbursing authority and can
print checks or initiate electronic transfers themselves. Agencies with
delegated disbursing authority must comply with the requirements
contained in I TFM Part 4 and all applicable requirements in this
function.

Federal payment regulations are documented in several different sources,
including 5 CFR 1315 (codification of OMB Circular A-125, *Prompt
Payment*), which specifies government policy for payments made to
vendors against contracts. It states, in part, that agencies must make
payments on time; pay interest when payments are late; and take
discounts only when payments are made on or before the discount date and
when it is advantageous to the government.

##### Mandatory Requirements

To support the Disbursing process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| PMD-01 | **Prompt payment---**Calculate the due date of vendor       |
|        | payments in accordance with 5 CFR 1315, including but not   |
|        | limited to the following factors:                           |
|        |                                                             |
|        | > • Commodity type                                          |
|        | >                                                           |
|        | > • Contract terms                                          |
|        | >                                                           |
|        | > • Invoice receipt                                         |
|        | >                                                           |
|        | > • Goods/services receipt and acceptance                   |
|        | >                                                           |
|        | > • Fast Payment                                            |
|        | >                                                           |
|        | > • Discount terms                                          |
|        | >                                                           |
|        | > • Accelerated payment methods                             |
|        | >                                                           |
|        | > • Governmentwide commercial purchase card rebates         |
|        | >                                                           |
|        | > • Improper invoices returned more than 7 days after       |
|        | > receipt.                                                  |
+--------+-------------------------------------------------------------+
| PMD-02 | **Invoices with multiple due dates---**Calculate multiple   |
|        | due dates when items on an invoice have different payment   |
|        | terms.                                                      |
+--------+-------------------------------------------------------------+
| PMD-03 | **Override vendor record payment terms on                   |
|        | obligation---**Capture payment terms on obligations that    |
|        | are different than those specified on the associated vendor |
|        | record.                                                     |
+--------+-------------------------------------------------------------+
| PMD-04 | **Validate invoice payment terms---**Validate payment terms |
|        | on invoices against the payment terms on the related        |
|        | obligating documents. Calculate the most advantageous       |
|        | terms, store them on the invoice documents, and use them to |
|        | calculate the payment due dates and amounts.                |
+--------+-------------------------------------------------------------+
| PMD-05 | **Payment due date override---**Capture an agency-specified |
|        | payment due date in place of a system-calculated due date   |
|        | (i.e. payment due date override).                           |
+--------+-------------------------------------------------------------+
| PMD-06 | **System calendar---**Define dates (e.g., weekends, Federal |
|        | holidays) for which payments cannot be scheduled. Prevent   |
|        | payment scheduling that falls on agency-excluded dates.     |
+--------+-------------------------------------------------------------+
| PMD-07 | **Advantageous discounts---**Calculate whether taking a     |
|        | discount is economically justified as defined in I          |
|        | TFM-6-8040.                                                 |
+--------+-------------------------------------------------------------+
| PMD-08 | **Calculate payment amounts---**Calculate amounts to be     |
|        | disbursed, including discounts, interest, and penalties, in |
|        | accordance with 5 CFR 1315. Record U.S. SGL prescribed      |
|        | transactions for discounts taken, and interest, penalties   |
|        | and principal paid.                                         |
+--------+-------------------------------------------------------------+
| PMD-09 | **Use Treasury interest rate tables---**Calculate payment   |
|        | amounts and due dates using Treasury rate tables, i.e.,     |
|        | Prompt Pay Act Interest rate and Current Value of Funds     |
|        | rate.                                                       |
+--------+-------------------------------------------------------------+
| PMD-10 | **Apply interest and discounts---**Apply interest and       |
|        | discount amounts across multiple accounting lines on an     |
|        | invoice using the ratio of the original invoice accounting  |
|        | line amounts to the invoice total.                          |
+--------+-------------------------------------------------------------+
| PMD-11 | **Record late payment interest---**Define the default for   |
|        | recording late payment interest, i.e., to the same          |
|        | accounting classification as the original payment or to     |
|        | another specified accounting classification in the same     |
|        | fund as the original payment.                               |
+--------+-------------------------------------------------------------+
| PMD-12 | **Numbering payment schedules---**Maintain a sequential     |
|        | numbering system for scheduling payments to be made by the  |
|        | disbursing office. Define different schedule number ranges  |
|        | for different payment types, such as travel schedules,      |
|        | transportation schedules, payroll schedules, vendor         |
|        | schedules, etc. Generate appropriate and unique schedule    |
|        | numbers for the payments scheduled for disbursement.        |
+--------+-------------------------------------------------------------+
| PMD-13 | **Payment certification---**Identify payments to be         |
|        | disbursed in a particular payment cycle based on their due  |
|        | date. Provide for on-line review and certification by an    |
|        | authorized certifying officer, including the holding of     |
|        | individual payments from inclusion in the payment schedule. |
+--------+-------------------------------------------------------------+
| PMD-14 | **Payment based on receipt---**Generate a payment if the    |
|        | receiver information matches the obligation, under related  |
|        | 2-way matching option.                                      |
+--------+-------------------------------------------------------------+
| PMD-15 | **Disbursements-in-transit---**Record                       |
|        | disbursements-in-transit entries when payments are          |
|        | certified.                                                  |
+--------+-------------------------------------------------------------+
| PMD-16 | **Do not disburse to negative cash position---**Validate    |
|        | that invoices selected for payment will not disburse a fund |
|        | into a negative cash position. Notify the agency of         |
|        | invoices that fail this edit.                               |
+--------+-------------------------------------------------------------+
| PMD-17 | **Manual payments---**Select and process warehoused         |
|        | invoices for manual payment.                                |
+--------+-------------------------------------------------------------+
| PMD-18 | **Statistical sample of invoices query---**Query            |
|        | preliminary payment schedule data. Identify a sample of     |
|        | invoices for certification based on agency-defined sampling |
|        | criteria and the payment due date. Result is a list of      |
|        | invoice document numbers with drill down to invoice         |
|        | details, including data required on a proper vendor invoice |
|        | per 5 CFR 1315.                                             |
+--------+-------------------------------------------------------------+
| PMD-19 | **Distribute invoice payment---**Distribute the payment of  |
|        | a single invoice to multiple bank accounts.                 |
+--------+-------------------------------------------------------------+
| PMD-20 | **Payment files---**Export check and EFT payment files in   |
|        | the current Treasury FMS defined formats.                   |
+--------+-------------------------------------------------------------+
| PMD-21 | **ACH payment formats---**Export Automated Clearing House   |
|        | (ACH) payment files in the following formats:               |
|        |                                                             |
|        | > • Corporate Trade Exchange (CTX) 820 file                 |
|        | >                                                           |
|        | > • CTX Flat File                                           |
|        | >                                                           |
|        | > • Cash Concentration or Disbursement (CCD)                |
|        | >                                                           |
|        | > • CCD Plus Addendum (CCD+)                                |
|        | >                                                           |
|        | > • Prearranged Payment and Deposit (PPD)                   |
|        | >                                                           |
|        | > • Prearranged Payment and Deposit Plus Addendum (PPD+).   |
+--------+-------------------------------------------------------------+
| PMD-22 | **NACHA payment formats---**Export NACHA payment formats    |
|        | for Non-Treasury DOs.                                       |
+--------+-------------------------------------------------------------+
| PMD-23 | **Treasury edits on EFT files---**Validate that EFT payment |
|        | file data submitted to Treasury will pass the following     |
|        | edits:                                                      |
|        |                                                             |
|        | > • RTNs exist in the Financial Organization Master File    |
|        | > (FOMF) or other verified update file, for the financial   |
|        | > institution.                                              |
|        | >                                                           |
|        | > • RTNs pass the Modulus 10 check on the validity of the   |
|        | > check digit.                                              |
|        | >                                                           |
|        | > • RTNs for domestic banks are nine-digits, numeric-only,  |
|        | > and not all zeroes                                        |
|        | >                                                           |
|        | > • RTNs for foreign banks are eight-digits, alpha-numeric, |
|        | > and not all zeroes                                        |
|        | >                                                           |
|        | > • ALCs are eight-digits and numeric only.                 |
|        | >                                                           |
|        | > • Taxpayer Identification Numbers are nine-digits,        |
|        | > numeric-only, and not all zeroes.                         |
+--------+-------------------------------------------------------------+
| PMD-24 | **Treasury edits on banking information---**Prevent the     |
|        | creation of an EFT (Fedwire, ACH or CTX) payment that does  |
|        | not contain a RTN, bank account number and account type     |
|        | (checking or savings).                                      |
+--------+-------------------------------------------------------------+
| PMD-25 | **ACH employee payments---**Validate that employee ACH      |
|        | payments are generated only as PPD or PPD+ payments.        |
+--------+-------------------------------------------------------------+
| PMD-26 | **ACH vendor payments---**Validate that vendor ACH payments |
|        | are generated only as CCD, CCD+ or CTX formats.             |
+--------+-------------------------------------------------------------+
| PMD-27 | **CTX vendor payments---**Generate CTX payment files that   |
|        | meet the following specifications:                          |
|        |                                                             |
|        | > • Reflect balanced transactions (sum of all remittance    |
|        | > records equals the transaction total).                    |
|        | >                                                           |
|        | > • Include a valid settlement date (next business day or   |
|        | > later).                                                   |
|        | >                                                           |
|        | > • Accommodate credit memos.                               |
+--------+-------------------------------------------------------------+
| PMD-28 | **Treasury edits on CTX files---**Validate that CTX vendor  |
|        | payments contain properly structured remittance             |
|        | information, as specified in the CTX payment file's         |
|        | remittance record format.                                   |
+--------+-------------------------------------------------------------+
| PMD-29 | **ECS payments---**Schedule and disburse U.S. dollar        |
|        | payments (SF 1166) through the Treasury's ECS, containing   |
|        | up to the limit of 60 payments per schedule (for            |
|        | non-summary schedules) and 100 schedules for each ECS       |
|        | terminal per day.                                           |
+--------+-------------------------------------------------------------+
| PMD-30 | **SPS payments---**Schedule and disburse U.S. dollar        |
|        | payments (SF 1166) through the Treasury's SPS containing up |
|        | to the limit of 60 payments per schedule (for non-summary   |
|        | schedules).                                                 |
+--------+-------------------------------------------------------------+
| PMD-31 | **TAFS information on Treasury payment files---**Capture    |
|        | the TAFS associated with each payment in ECS, SPS and Bulk  |
|        | Vendor/Miscellaneous payment files.                         |
+--------+-------------------------------------------------------------+
| PMD-32 | **Payment schedule totals by TAFS---**Generate totals by    |
|        | TAFS on each ECS and SPS payment file.                      |
+--------+-------------------------------------------------------------+
| PMD-33 | **ECS and SPS payment files for multiple ALCs---**Combine   |
|        | ECS and SPS payment files with multiple ALCs into single    |
|        | files for transmission to Treasury. Include summary totals  |
|        | (items and dollars) by ALC and TAFS and for the entire file |
|        | for certification purposes.                                 |
+--------+-------------------------------------------------------------+
| PMD-34 | **Bulk check payment files for multiple payee               |
|        | types---**Generate one bulk check payment file regardless   |
|        | of payee type (employee or vendor).                         |
+--------+-------------------------------------------------------------+
| PMD-35 | **Consolidate multiple payments to payee---**Consolidate    |
|        | multiple payments to a single payee in accordance with TFM  |
|        | prescribed limitations (currently up to 14 lines of 55      |
|        | characters each for check payments, up to 9,999 lines of 80 |
|        | characters each for CTX payments). Itemize all payments     |
|        | covered by the one check or EFT (CTX only). Provide the     |
|        | option to issue separate checks to a payee.                 |
+--------+-------------------------------------------------------------+
| PMD-36 | **Remittance information on Treasury payment                |
|        | files---**Generate the following identification on each     |
|        | remittance, as allowed for by Treasury payment file formats |
|        | and NACHA edits:                                            |
|        |                                                             |
|        | > • Vendor invoice number(s) or account number              |
|        | >                                                           |
|        | > • Obligating document number or other reference number    |
|        | >                                                           |
|        | > • Discount, interest and offset amounts.                  |
+--------+-------------------------------------------------------------+
| PMD-37 | **Prompt pay---**Capture prompt payment information         |
|        | required by 5 CFR 1315, including discounts taken,          |
|        | discounts lost, and interest paid.                          |
+--------+-------------------------------------------------------------+
| PMD-38 | **Prompt Pay Metric Query---**Query disbursement data.      |
|        | Parameters include accounting period range, disbursement    |
|        | type(s) to be included. Provide an option to exclude credit |
|        | card transactions. Result is the total number of payments   |
|        | made on time by disbursement type. Query returns total      |
|        | number of on-time and late payments made based on due date. |
+--------+-------------------------------------------------------------+
| PMD-39 | **Payments GL entries---**Record the U.S. SGL prescribed    |
|        | general ledger entries for the payment of advances, prepaid |
|        | expenses, loans, and grants.                                |
+--------+-------------------------------------------------------------+
| PMD-40 | **Imprest funds---**Record the establishment and            |
|        | replenishment of imprest funds.                             |
+--------+-------------------------------------------------------------+
| PMD-41 | **Imprest funds and third party U.S. SGL entries---**Record |
|        | purchases made through the use of imprest funds and         |
|        | third-party drafts.                                         |
+--------+-------------------------------------------------------------+
| PMD-42 | **Simultaneous obligation and payment---**Record "obligate  |
|        | and pay" transactions where obligation and payment occur    |
|        | simultaneously.                                             |
+--------+-------------------------------------------------------------+
| PMD-43 | **Payments for other agencies---**Record payments made on   |
|        | behalf of another agency, citing the other agency's funding |
|        | information.                                                |
+--------+-------------------------------------------------------------+
| PMD-44 | **Interfaced payment entries---**Record payment             |
|        | transactions from other systems, such as payroll and        |
|        | travel. Identify whether or not disbursement has already    |
|        | been made, and record the U.S. SGL prescribed general       |
|        | ledger entries. Schedule those disbursements not already    |
|        | made for payment through the Core financial system.         |
+--------+-------------------------------------------------------------+
| PMD-45 | **IPAC payments and collections---**Capture the following   |
|        | additional information for IPAC transactions:               |
|        |                                                             |
|        | > • Sender/originator TAS                                   |
|        | >                                                           |
|        | > • Sender ALC                                              |
|        | >                                                           |
|        | > • Sender SGL account                                      |
|        | >                                                           |
|        | > • Sender BETC                                             |
|        | >                                                           |
|        | > • Sender DO symbol                                        |
|        | >                                                           |
|        | > • Sender DUNS number                                      |
|        | >                                                           |
|        | > • Sender DUNS+4 number                                    |
|        | >                                                           |
|        | > • Customer/receiver TAS                                   |
|        | >                                                           |
|        | > • Customer ALC                                            |
|        | >                                                           |
|        | > • Customer SGL account                                    |
|        | >                                                           |
|        | > • Customer DUNS number                                    |
|        | >                                                           |
|        | > • Customer DUNS+4 number                                  |
|        | >                                                           |
|        | > • Customer BETC                                           |
|        | >                                                           |
|        | > • Customer Department Code.                               |
+--------+-------------------------------------------------------------+
| PMD-46 | **IPAC reclassifications---**Capture the following          |
|        | additional information with IPAC reclassifications:         |
|        |                                                             |
|        | > • Original DO symbol                                      |
|        | >                                                           |
|        | > • Voucher number.                                         |
+--------+-------------------------------------------------------------+
| PMD-47 | **IPAC posted SGL transactions---**Capture SGL comments     |
|        | with IPAC disbursement and collection transactions.         |
+--------+-------------------------------------------------------------+
| PMD-48 | **IPAC bulk file export---**Export a bulk file in the       |
|        | currently required format for uploading the following       |
|        | interagency transactions to IPAC:                           |
|        |                                                             |
|        | • Payment                                                   |
|        |                                                             |
|        | • Collection                                                |
|        |                                                             |
|        | • Adjustment                                                |
|        |                                                             |
|        | • Zero dollar                                               |
|        |                                                             |
|        | • SGL posting.                                              |
+--------+-------------------------------------------------------------+
| PMD-49 | **IPAC GL entries---**Record transactions to reflect        |
|        | disbursement activity initiated by other agencies and       |
|        | recorded in IPAC.                                           |
+--------+-------------------------------------------------------------+
| PMD-50 | **Credit memo processing---**Record vendor credit memoranda |
|        | as accounts receivable or negative accounts payable.        |
+--------+-------------------------------------------------------------+
| PMD-51 | **Process credit memoranda offsets---**Reduce payments to   |
|        | vendors to satisfy outstanding credit memos. Record the     |
|        | collection for the amount offset and reduce expenditures    |
|        | under the related obligation. If a credit is not fully      |
|        | liquidated by one payment, maintain the balance of the      |
|        | credit for application against a future payment.            |
+--------+-------------------------------------------------------------+
| PMD-52 | **Credit memoranda offsets across funds---**Record credit   |
|        | memo offsets against subsequent payments to the same vendor |
|        | from the same or a different funding source.                |
+--------+-------------------------------------------------------------+
| PMD-53 | **Notify vendors of credit memoranda offsets---**Notify     |
|        | vendors of payments that have been offset by credit memos.  |
|        | Specify the invoice number, invoice amount, offset amount,  |
|        | payment amount and payment date.                            |
+--------+-------------------------------------------------------------+
| PMD-54 | **Credit memo offset exclusions---**Prevent agency offset   |
|        | of vendor payments based on agency-defined criteria such as |
|        | accounting classification elements, vendor number, and      |
|        | vendor CCR business type.                                   |
+--------+-------------------------------------------------------------+
| PMD-55 | **Reverse scheduled payments---**Generate the reversal of   |
|        | an entire payment schedule or a single payment within a     |
|        | payment schedule based on a single, online action. Generate |
|        | disbursement-in-transit reversal entries, record the        |
|        | re-established accounts payable, and update related payment |
|        | records.                                                    |
+--------+-------------------------------------------------------------+
| PMD-56 | **Payments Referencing Cancelled Funds---**For payments     |
|        | that reference obligations in cancelled funds, bring        |
|        | forward accounting and non-financial information from the   |
|        | original obligation document to an invoice in the current   |
|        | year.                                                       |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

To add value to the Disbursing process, the Core financial system
**[should]{.underline}** provide automated functionality to do the
following:

  --------- -------------------------------------------------------------
  PMD-57    **Calculate foreign payment amounts---**Calculate payments to
            foreign vendors based on current exchange rates.

  PMD-58    **Foreign payment file formats---**Generate foreign payment
            file formats, including International Direct Deposit (IDD).
  --------- -------------------------------------------------------------

## Payment Follow-Up Process

This process allows for agency follow-up on payments pending and
accomplished. Core financial systems must capture the information needed
to track invoices through various stages of processing, to respond to
vendor inquiries, and to report payment activity to external entities
such as the IRS.

##### Mandatory Requirements

To support the Payment Follow-Up process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| PME-01 | **Invoice Status Query---**Query invoice status             |
|        | information. Parameters include: vendor number, vendor name |
|        | (legal, DBA or division), TIN, DUNS number and vendor       |
|        | invoice number. List the selected invoices, their due       |
|        | dates, the dates that the following stages were reached and |
|        | the number of days between each date:                       |
|        |                                                             |
|        | > • Invoice received                                        |
|        | >                                                           |
|        | > • Invoice suspended due to validation errors              |
|        | >                                                           |
|        | > • Invoice held                                            |
|        | >                                                           |
|        | > • Invoice returned to vendor                              |
|        | >                                                           |
|        | > • Invoice resubmitted by vendor                           |
|        | >                                                           |
|        | > • Invoice approved and warehoused                         |
|        | >                                                           |
|        | > • Invoice scheduled for payment (disbursement-in-transit) |
|        | >                                                           |
|        | > • Invoice paid.                                           |
+--------+-------------------------------------------------------------+
| PME-02 | **Payment history---**Maintain a history of the following   |
|        | information for each payment made:                          |
|        |                                                             |
|        | > • Accounting classification information                   |
|        | >                                                           |
|        | > • ALC                                                     |
|        | >                                                           |
|        | > • TAS/BETC                                                |
|        | >                                                           |
|        | > • Referenced obligation document number(s)                |
|        | >                                                           |
|        | > • Source document number(s) (reimbursable agreement       |
|        | > number, BPA and associated BPA call number, Contract and  |
|        | > associated delivery/task order number, and grant number)  |
|        | >                                                           |
|        | > • Total invoice amount                                    |
|        | >                                                           |
|        | > • Payment voucher document number                         |
|        | >                                                           |
|        | > • Vendor invoice number                                   |
|        | >                                                           |
|        | > • Vendor information (number, name, address, TIN, and     |
|        | > DUNS+4 number for CCR vendors)                            |
|        | >                                                           |
|        | > • Payment address or bank account number and routing      |
|        | > number                                                    |
|        | >                                                           |
|        | > • Payment method (e.g., check, EFT)                       |
|        | >                                                           |
|        | > • Payment amount                                          |
|        | >                                                           |
|        | > • Interest paid                                           |
|        | >                                                           |
|        | > • Discount taken                                          |
|        | >                                                           |
|        | > • Internal offset made                                    |
|        | >                                                           |
|        | > • Date due                                                |
|        | >                                                           |
|        | > • Date paid.                                              |
+--------+-------------------------------------------------------------+
| PME-03 | **EFT Metric Query---**Query payment data. Parameter is     |
|        | accounting period range. Result is number of payments and   |
|        | percent of total by payment method (EFT vs. check).         |
+--------+-------------------------------------------------------------+
| PME-04 | **Unmatched Invoice Document Lines Report---**Generate the  |
|        | Unmatched Invoice Document Lines Report. Result is a list   |
|        | of selected invoice document numbers with document lines    |
|        | not matched to obligations, receipts, and/or acceptance, as |
|        | required by the matching terms of the obligation (2, 3 or   |
|        | 4-way matching). Report the following information for each  |
|        | invoice document listed:                                    |
|        |                                                             |
|        | > • Vendor number and name                                  |
|        | >                                                           |
|        | > • Invoice number                                          |
|        | >                                                           |
|        | > • Invoice date                                            |
|        | >                                                           |
|        | > • Invoice receipt date                                    |
|        | >                                                           |
|        | > • Invoice amount                                          |
|        | >                                                           |
|        | > • Referenced obligation number                            |
|        | >                                                           |
|        | > • Document number                                         |
|        | >                                                           |
|        | > • Document line number(s)                                 |
|        | >                                                           |
|        | > • Document line amount(s)                                 |
|        | >                                                           |
|        | > • Document line accounting classification                 |
|        | >                                                           |
|        | > • Unmatched document(s) (obligation, receipt and/or       |
|        | > acceptance)                                               |
|        | >                                                           |
|        | > • Age, in days, that invoice document line has been       |
|        | > unmatched.                                                |
|        |                                                             |
|        | Sorting options include document number, vendor number,     |
|        | vendor name, accounting classification and unmatched age.   |
+--------+-------------------------------------------------------------+
| PME-05 | **Late Payments Pending Report---**Generate a report of     |
|        | payment vouchers past their due date, as of current system  |
|        | date. List the selected payment vouchers with the following |
|        | information:                                                |
|        |                                                             |
|        | > • Payment voucher number                                  |
|        | >                                                           |
|        | > • Referenced obligation number                            |
|        | >                                                           |
|        | > • Vendor invoice number                                   |
|        | >                                                           |
|        | > • Vendor number and name                                  |
|        | >                                                           |
|        | > • Invoice date                                            |
|        | >                                                           |
|        | > • Invoice amount                                          |
|        | >                                                           |
|        | > • Invoice due date                                        |
|        | >                                                           |
|        | > • Number of days late.                                    |
|        |                                                             |
|        | Sort options include number of days late and vendor number. |
+--------+-------------------------------------------------------------+
| PME-06 | **IRS 1099 Forms---**Generate IRS Forms 1099-MISC, 1099-INT |
|        | and 1099-G in accordance with IRS regulations and in        |
|        | current IRS acceptable format, including hard copy and      |
|        | electronic form (i.e., bulk file). For example, produce an  |
|        | IRS Form 1099-MISC for payments of \$600 or more to a sole  |
|        | proprietor for services rendered.                           |
+--------+-------------------------------------------------------------+
| PME-07 | **IRS 1099-MISC reporting of payments to third              |
|        | parties---**Report third-party payments on the principal    |
|        | vendors' IRS 1099-MISC forms.                               |
+--------+-------------------------------------------------------------+
| PME-08 | **IRS 1099-MISC query---**Query IRS 1099-MISC information.  |
|        | Parameters include calendar year, vendor name (legal or     |
|        | DBA), TIN and DUNS+4 number. Result is details supporting   |
|        | IRS 1099-MISC reporting.                                    |
+--------+-------------------------------------------------------------+
| PME-09 | **Statistical sample of payments query---**Query payments   |
|        | data. Identify a sample of payments for review based on     |
|        | agency-defined sampling criteria and the date(s) of         |
|        | payment. Result is a list of invoice document numbers with  |
|        | drill down to invoice details, including data required on a |
|        | proper vendor invoice per 5 CFR 1315.                       |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

To add value to the Payment Follow-Up process, the Core financial system
**[should]{.underline}** provide automated functionality to do the
following:

  --------- -------------------------------------------------------------
  PME-10    **Travel payment notification---**Generate e-mail
            notification to employees of travel payments made by
            disbursing offices.

  --------- -------------------------------------------------------------

# Receivable Management Function

Receivables are established to account for amounts due from others as
the result of performance of services by the agency, delivery of goods
sold, the passage of time (e.g., interest earned), overpayments, or
other actions. Receivables are accounted for as assets until funds are
collected, or determined to be uncollectible in whole or in part. In
addition, some receipts may be collected without the prior establishment
of a receivable, as in the case of goods sold for cash.

Federal debt management regulations are documented in several different
sources. The Debt Collection Act of 1982 authorized agencies to charge
interest, penalties, and administrative costs against delinquent
non-Federal debtors, and on debts due from state and local governments.
OMB Circular A-129, *Policies for Federal Credit Programs and Non-Tax
Receivables*, prescribes policies and procedures for collecting non-tax
receivables and sets standards for servicing these receivables and for
collecting delinquent debt. DCIA established a framework for improved
Federal debt collection by requiring agencies to take prompt action to
recover debts, screen potential borrowers related to credit programs,
and resolve outstanding debt through various options. DCIA centralized
the management of delinquent non-tax obligations overdue by 180 days in
the Department of the Treasury for administrative offset and
cross-servicing. In addition, DCIA allows referral of the delinquent
debt to the Department of Justice for litigation. To remain in
compliance with these requirements, Federal agencies, unless otherwise
precluded from statute, must accurately and timely report on receivables
by submitting all required information on the TROR.

Depending on an agency's system architecture, servicing and collection
activities for some receivables may be supported by other systems that
provide data to the Core financial system. This would be particularly
appropriate for receivables resulting from large programs with complex
data requirements, such as loan programs, grant programs, or
fee-for-service programs. Servicing and collection of receivables with
simpler requirements for supporting data, such as those resulting from
erroneous payments, may be supported directly by the Core financial
system with no support by other systems. Servicing of payroll
collections (benefits, judgments, etc.), however, should be maintained
in the payroll system and made available to the Core system for
recording the general ledger impact.

The Receivable Management function includes recording, billing,
monitoring, and collecting amounts due the government whether previously
established as a receivable or not. These activities must be supported
by aging schedules, exception reports, and reports used to monitor due
diligence efforts.

The Receivable Management function consists of the following processes
(the prefixes assigned to the requirements are noted in parentheses):

-   Customer Information Maintenance (RMA)

-   Receivables and Billing (RMB)

-   Debt Management (RMC)

-   Collections and Offsets (RMD).

## Customer Information Maintenance Process

The word "customer" is used here to include any entity that owes a debt
to the agency, including contractors, employees, grantees, loan
recipients, and other government agencies. Agency payees or vendors may
become customers of the agency, in the event that duplicate or
overpayments occur.

The Customer Information Maintenance process involves the maintenance of
customer information (name, address, etc.), identification of the type
of customer from which collection is due, and the recording of trading
partner codes used in the elimination of intra-governmental activity
from financial statements, as well as other critical information related
to the customer that is needed for receivable processing, maintenance,
and collection. The process ensures that customer TINs are captured in
order to report overdue receivables for potential offset and to provide
for IRS Form 1099 reporting of debts written off.

##### Mandatory Requirements

To support the Customer Information Maintenance process, the Core
financial system **[must]{.underline}** provide automated functionality
to do the following:

+--------+-------------------------------------------------------------+
| RMA-01 | Customer information**---**Maintain customer information to |
|        | support receivable management processes including the       |
|        | following:                                                  |
|        |                                                             |
|        | > • Customer name                                           |
|        | >                                                           |
|        | > • Customer ID number                                      |
|        | >                                                           |
|        | > • Customer type (Federal agency, foreign/sovereign,       |
|        | > state/local government, commercial, or consumer)          |
|        | >                                                           |
|        | > • Billing method (IPAC, 1081, paper bill, or other)       |
|        | >                                                           |
|        | > • TIN                                                     |
|        | >                                                           |
|        | > • Customer address                                        |
|        | >                                                           |
|        | > • Customer contact name                                   |
|        | >                                                           |
|        | > • Customer contact telephone number                       |
|        | >                                                           |
|        | > • Customer contact e-mail address                         |
|        | >                                                           |
|        | > • Federal vs. Non-Federal indicator                       |
|        | >                                                           |
|        | > • GFRS and FACTS I Trading Partner codes (for Federal     |
|        | > customers)                                                |
|        | >                                                           |
|        | > • ALC (for Federal customers)                             |
|        | >                                                           |
|        | > • IRS 1099-C indicator                                    |
|        | >                                                           |
|        | > • Third-party payer name                                  |
|        | >                                                           |
|        | > • Third-party payer address                               |
|        | >                                                           |
|        | > • Third-party payer contact name                          |
|        | >                                                           |
|        | > • Third-party payer contact telephone number              |
|        | >                                                           |
|        | > • Comment field                                           |
|        | >                                                           |
|        | > • DUNS+4 number                                           |
|        | >                                                           |
|        | > • Active/Inactive indicator                               |
+--------+-------------------------------------------------------------+
| RMA-02 | **Validate Customer TINs---**Validate TINs when adding or   |
|        | updating customer records. Notify the agency when duplicate |
|        | TINs are identified. Allow the error message to be          |
|        | overridden.                                                 |
+--------+-------------------------------------------------------------+
| RMA-03 | **Customer query---**Query customer file. Parameters        |
|        | include:                                                    |
|        |                                                             |
|        | > • Customer number                                         |
|        | >                                                           |
|        | > • Customer name                                           |
|        | >                                                           |
|        | > • Customer TIN                                            |
|        | >                                                           |
|        | > • DUNS+4 number                                           |
|        | >                                                           |
|        | > • IRS 1099-C indicator.                                   |
|        |                                                             |
|        | Result is a display of all data for the specified customer. |
+--------+-------------------------------------------------------------+
| RMA-04 | **Customer file history---**Maintain a history of changes   |
|        | made to customer information. Capture name of data item     |
|        | changed, before and after values, entry date and time and   |
|        | ID of user who made the change.                             |
+--------+-------------------------------------------------------------+
| RMA-05 | **Customer history query---**Query customer history.        |
|        | Parameters include customer number, change date range.      |
|        | Results include date and time of change, ID of user who     |
|        | made the change, item name, before and after data values.   |
+--------+-------------------------------------------------------------+
| RMA-06 | **Criteria for deactivating customer---**Deactivate         |
|        | customers on demand or based on agency-specified length of  |
|        | time with no activity.                                      |
+--------+-------------------------------------------------------------+
| RMA-07 | **Customer deactivation edit---**Prevent the deactivation   |
|        | of customers that have unliquidated receivables in the      |
|        | system.                                                     |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

## Receivables and Billing Process

The Receivables and Billing process supports activities to record
receivables in the system as they are recognized and to produce bills
for amounts due to the agency.

##### Mandatory Requirements

To support the Receivables and Billing process, the Core financial
system **[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| RMB-01 | **Record receivables---**Record accounts receivable and     |
|        | corresponding revenues, expense reductions,                 |
|        | advance/prepayment reclassifications, or other offsets.     |
+--------+-------------------------------------------------------------+
| RMB-02 | **Receivable adjustments---**Record adjustments to          |
|        | receivables and capture a reason and description on each    |
|        | adjustment.                                                 |
+--------+-------------------------------------------------------------+
| RMB-03 | **Receivable type---**Capture an agency-defined receivable  |
|        | type on receivable documents to identify the activity which |
|        | generated the receivable, such as: the sale of goods or     |
|        | services, overpayments, unused advances subject to refund,  |
|        | fees and fines.                                             |
+--------+-------------------------------------------------------------+
| RMB-04 | **Receivable document data---**Capture the following        |
|        | additional information on receivable documents:             |
|        |                                                             |
|        | > • Baseline receivable date (used to properly age the      |
|        | > receivable and determine the delinquency date)            |
|        | >                                                           |
|        | > • Customer ID number                                      |
|        | >                                                           |
|        | > • Reimbursable agreement number.                          |
+--------+-------------------------------------------------------------+
| RMB-05 | **Converted receivables---**Capture the original baseline   |
|        | receivable date on receivables converted from legacy        |
|        | systems, in order to properly age the receivable.           |
+--------+-------------------------------------------------------------+
| RMB-06 | **Non-reimbursable billings---**Generate bills to           |
|        | non-reimbursable customers based on receivables recorded.   |
|        | Include the following information on the bills:             |
|        |                                                             |
|        | > • Customer name                                           |
|        | >                                                           |
|        | > • Customer address                                        |
|        | >                                                           |
|        | > • Customer contact name                                   |
|        | >                                                           |
|        | > • Agency contact name, office, address and telephone      |
|        | > number                                                    |
|        | >                                                           |
|        | > • Date due.                                               |
+--------+-------------------------------------------------------------+
| RMB-07 | **Reimbursable agreement billings---**Calculate billing     |
|        | amounts and generate bills to customers based on            |
|        | reimbursable agreement billing terms, such as:              |
|        |                                                             |
|        | > • Percentage of work completed                            |
|        | >                                                           |
|        | > • Accrued expenditures                                    |
|        | >                                                           |
|        | > • Actual costs incurred (direct and indirect using data   |
|        | > from the cost management system).                         |
|        |                                                             |
|        | Include the following information on the bills:             |
|        |                                                             |
|        | > • Customer name                                           |
|        | >                                                           |
|        | > • Customer address                                        |
|        | >                                                           |
|        | > • Customer contact name                                   |
|        | >                                                           |
|        | > • Agency contact name, office, address and telephone      |
|        | > number; and                                               |
|        | >                                                           |
|        | > • Date due.                                               |
+--------+-------------------------------------------------------------+
| RMB-08 | **Reimbursable agreement billing limits---**Monitor billing |
|        | limits on a reimbursable agreement. Reject, warn or inform  |
|        | the agency when limit is exceeded.                          |
+--------+-------------------------------------------------------------+
| RMB-09 | **Scheduled billings---**Generate bills based on            |
|        | pre-defined fee schedules or payment schedules.             |
+--------+-------------------------------------------------------------+
| RMB-10 | **Bills to third-party payers---**Generate bills to third   |
|        | party payers as responsible debtors.                        |
+--------+-------------------------------------------------------------+
| RMB-11 | **Bill types---**Customize the text and data elements to be |
|        | displayed on system-generated bills, by customer type,      |
|        | receivable type, or billing method. For example, an IPAC    |
|        | bill for the sale of goods and services would need to       |
|        | contain different supporting text than a bill to an         |
|        | employee for an overpayment.                                |
+--------+-------------------------------------------------------------+
| RMB-12 | **Bill data---**List principal, interest, penalties, and    |
|        | administrative charges separately on a bill and provide a   |
|        | description of each.                                        |
+--------+-------------------------------------------------------------+
| RMB-13 | **Additional bill data---**Include advances and prior       |
|        | collections received on bills.                              |
+--------+-------------------------------------------------------------+
| RMB-14 | **Bill forms---**Generate bills in hard-copy format,        |
|        | including Standard Forms 1080 and 1081.                     |
+--------+-------------------------------------------------------------+
| RMB-15 | **Derive bill date---**Derive the bill date from the system |
|        | date. Allow for override.                                   |
+--------+-------------------------------------------------------------+
| RMB-16 | **Bill number and date---**Capture a unique bill number and |
|        | a bill date on system-generated bills.                      |
+--------+-------------------------------------------------------------+
| RMB-17 | **Consolidating receivables---**Consolidate multiple        |
|        | receivables for a customer onto one bill retaining          |
|        | identification of each receivable separately within the     |
|        | bill.                                                       |
+--------+-------------------------------------------------------------+
| RMB-18 | **Receivable status---**Update receivable status from       |
|        | unbilled to billed when bills are generated. Associate the  |
|        | receivable with the bill number and bill date.              |
+--------+-------------------------------------------------------------+
| RMB-19 | **Manual bills---**Capture information from manually        |
|        | prepared bills. Update receivable document (e.g., change    |
|        | status of receivable from unbilled to billed) with manual   |
|        | bill information.                                           |
+--------+-------------------------------------------------------------+
| RMB-20 | **Returned checks---**Re-establish a receivable when a      |
|        | check collection is cancelled due to insufficient funds or  |
|        | a when a chargeback is recorded. Capture the original       |
|        | baseline receivable date and update receivable status from  |
|        | billed to unbilled.                                         |
+--------+-------------------------------------------------------------+
| RMB-21 | **Reschedule receivables---**Reschedule existing            |
|        | receivables to be paid under installment plans.             |
+--------+-------------------------------------------------------------+
| RMB-22 | **Multiple rescheduling---**Reschedule a receivable         |
|        | multiple times.                                             |
+--------+-------------------------------------------------------------+
| RMB-23 | **Amortization schedule---**Generate a Debt Repayment       |
|        | Amortization Schedule. Parameters include the receivable    |
|        | number, final due date, begin date, frequency of payments,  |
|        | and interest rate. Result is an amortization schedule that  |
|        | displays the original amount of debt, payment dates, amount |
|        | of incremental payments, and balance remaining after each   |
|        | payment for debt being paid under an installment plan or    |
|        | rescheduled debt.                                           |
+--------+-------------------------------------------------------------+
| RMB-24 | **Customer account statements---**Generate Customer Account |
|        | Statements. Parameters include customer type, customer ID   |
|        | number, customer name, and time period (month, quarter,     |
|        | year-to-date). Result is a statement for each customer that |
|        | includes:                                                   |
|        |                                                             |
|        | > • Statement date                                          |
|        | >                                                           |
|        | > • Customer ID number                                      |
|        | >                                                           |
|        | > • Customer name                                           |
|        | >                                                           |
|        | > • Customer address                                        |
|        | >                                                           |
|        | > • Customer contact name                                   |
|        | >                                                           |
|        | > • Agency name                                             |
|        | >                                                           |
|        | > • Agency contact name                                     |
|        | >                                                           |
|        | > • Agency contact phone number                             |
|        | >                                                           |
|        | > • Agency contact email address                            |
|        | >                                                           |
|        | > • Balance brought forward                                 |
|        | >                                                           |
|        | > • Receivables established (including due dates)           |
|        | >                                                           |
|        | > • Interest                                                |
|        | >                                                           |
|        | > • Penalties                                               |
|        | >                                                           |
|        | > • Administrative costs                                    |
|        | >                                                           |
|        | > • Adjustments made                                        |
|        | >                                                           |
|        | > • Collections received (identify principal, interest,     |
|        | > penalties, and administrative charges separately to       |
|        | > indicate how collections were applied)                    |
|        | >                                                           |
|        | > • Outstanding receivable balance.                         |
|        |                                                             |
|        | Provide agency the option to generate customer statements   |
|        | in Excel format.                                            |
+--------+-------------------------------------------------------------+
| RMB-25 | **Outstanding receivable balance query---**Query            |
|        | outstanding receivable balance. Parameter is the receivable |
|        | document number. Result is the original amount of the       |
|        | receivable, the current outstanding amount of the           |
|        | receivable and a detailed list of all activity related to   |
|        | the receivable, including:                                  |
|        |                                                             |
|        | > • Adjustments                                             |
|        | >                                                           |
|        | > • Interest                                                |
|        | >                                                           |
|        | > • Penalties                                               |
|        | >                                                           |
|        | > • Administrative charges                                  |
|        | >                                                           |
|        | > • Collections                                             |
|        | >                                                           |
|        | > • Waivers                                                 |
|        | >                                                           |
|        | > • Write-offs.                                             |
+--------+-------------------------------------------------------------+
| RMB-26 | **Reimbursable agreement query---**Query reimbursable       |
|        | agreements. Parameters include Reimbursable Agreement       |
|        | Number, Customer ID Number, Customer Name, Project, or      |
|        | Fund. Result is a display of the following information for  |
|        | each reimbursable agreement selected:                       |
|        |                                                             |
|        | > • Period of performance                                   |
|        | >                                                           |
|        | > • Billing terms                                           |
|        | >                                                           |
|        | > • Reimbursable agreement amount                           |
|        | >                                                           |
|        | > • Billing limit                                           |
|        | >                                                           |
|        | > • Amount obligated                                        |
|        | >                                                           |
|        | > • Amount expended                                         |
|        | >                                                           |
|        | > • Unfilled customer order amount                          |
|        | >                                                           |
|        | > • Advances collected                                      |
|        | >                                                           |
|        | > • Advances applied to earned revenue                      |
|        | >                                                           |
|        | > • Remaining balance on advances                           |
|        | >                                                           |
|        | > • Amount earned                                           |
|        | >                                                           |
|        | > • Amount billed                                           |
|        | >                                                           |
|        | > • Amount collected on receivables                         |
|        | >                                                           |
|        | > • Outstanding accounts receivable (billed and unbilled).  |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

## Debt Management Process

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 process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| RMC-01 | **Assessing interest---**Calculate and record late payment  |
|        | interest charges on overdue non-Federal receivables based   |
|        | on the Treasury Current Value of Funds Rate (CVFR) unless   |
|        | otherwise specified by the agency.                          |
+--------+-------------------------------------------------------------+
| RMC-02 | **Interest assessment rate---**Calculate and record late    |
|        | payment interest charges on overdue non-Federal receivables |
|        | based on an agency-assigned interest rate different from    |
|        | the CVFR for a particular receivable, customer, or customer |
|        | type.                                                       |
+--------+-------------------------------------------------------------+
| RMC-03 | **Penalties and administrative charges---**Calculate and    |
|        | record penalties and administrative charges on overdue      |
|        | receivables based on an agency-assigned rate or amount for  |
|        | a particular receivable, customer, customer type, or        |
|        | receivable type.                                            |
+--------+-------------------------------------------------------------+
| RMC-04 | **Accounting classification of receivables---**Optionally   |
|        | record interest, penalties, or administrative costs to      |
|        | accounting classification elements that are different from  |
|        | those to which the principal amount is recorded.            |
+--------+-------------------------------------------------------------+
| RMC-05 | **Interest on referred debt---**Optionally cease or         |
|        | continue accruing interest on delinquent debts that have    |
|        | been referred to Treasury or another agency.                |
+--------+-------------------------------------------------------------+
| RMC-06 | **Dunning notices---**Generate dunning notices on overdue   |
|        | receivables at frequencies specified by the agency,         |
|        | including on-demand, and by agency-defined parameters,      |
|        | including customer type.                                    |
+--------+-------------------------------------------------------------+
| RMC-07 | **Dunning notice text---**Customize text used on dunning    |
|        | notices based on receivable age categories and customer     |
|        | types.                                                      |
+--------+-------------------------------------------------------------+
| RMC-08 | **Accounts Receivable Aging Report---**Generate an Accounts |
|        | Receivable Aging Report. Parameters include:                |
|        |                                                             |
|        | > • Accounting Period                                       |
|        | >                                                           |
|        | > • TAS or Internal Fund Code                               |
|        | >                                                           |
|        | > • General Ledger Account                                  |
|        | >                                                           |
|        | > • Customer type                                           |
|        | >                                                           |
|        | > • Federal/Non Federal Indicator                           |
|        | >                                                           |
|        | > • Customer ID number.                                     |
|        |                                                             |
|        | Result is a report that displays the outstanding receivable |
|        | balances in each of the Delinquent Debt Age categories      |
|        | listed on the TROR.                                         |
+--------+-------------------------------------------------------------+
| RMC-09 | **Accounts receivable aging query---**Query accounts        |
|        | receivable by age categories. Parameters include:           |
|        |                                                             |
|        | > • Accounting Period                                       |
|        | >                                                           |
|        | > • TAS or Internal Fund Code                               |
|        | >                                                           |
|        | > • General Ledger Account                                  |
|        | >                                                           |
|        | > • Customer type                                           |
|        | >                                                           |
|        | > • Federal/Non Federal Indicator                           |
|        | >                                                           |
|        | > • Customer ID number.                                     |
|        |                                                             |
|        | Result is a display of the outstanding receivable balances  |
|        | in each of the Delinquent Debt Age categories listed on the |
|        | TROR. Drill-down to a detailed list of outstanding          |
|        | receivables within any one age category.                    |
+--------+-------------------------------------------------------------+
| RMC-10 | **Receivables eligible for write-off---**Identify           |
|        | receivables that may be eligible for write-off. Selection   |
|        | criteria is:                                                |
|        |                                                             |
|        | > • Delinquent debt age category                            |
|        | >                                                           |
|        | > • Customer type                                           |
|        | >                                                           |
|        | > • Receivable type.                                        |
|        |                                                             |
|        | Display selected items on-line. Include the receivable      |
|        | number, outstanding amount, age of receivable, vendor or    |
|        | customer name, and vendor or customer ID number of each     |
|        | receivable. Provide the option to mark a receivable as      |
|        | eligible for write-off.                                     |
+--------+-------------------------------------------------------------+
| RMC-11 | **Waivers and write-offs---**Record the waiver and          |
|        | write-off of receivables, including interest, penalties,    |
|        | and administrative charges.                                 |
+--------+-------------------------------------------------------------+
| RMC-12 | **Classify write offs---**Classify receivables written off  |
|        | as "Currently not Collectible" or "Closed Out."             |
+--------+-------------------------------------------------------------+
| RMC-13 | **Waived and written-off receivables---**Maintain data on   |
|        | receivables that have been waived or written-off.           |
+--------+-------------------------------------------------------------+
| RMC-14 | **Receivables eligible for referral---**Identify            |
|        | receivables that may be eligible for referral. Selection    |
|        | criteria is:                                                |
|        |                                                             |
|        | > • Delinquent debt age category                            |
|        | >                                                           |
|        | > • Customer type                                           |
|        | >                                                           |
|        | > • Receivable type.                                        |
|        |                                                             |
|        | Display selected items on-line. Include receivable number,  |
|        | receivable amount, age of receivable, vendor or customer    |
|        | name, and vendor or customer ID number of each receivable.  |
|        | Provide the option to mark receivables as eligible          |
|        | referral.                                                   |
+--------+-------------------------------------------------------------+
| RMC-15 | **Delinquent debt referral file---**Generate a delinquent   |
|        | debt referral file for transmission to Treasury in          |
|        | accordance with the Debt Collection Improvement Act (DCIA). |
+--------+-------------------------------------------------------------+
| RMC-16 | **Receivable updates---**Update receivables with dunning    |
|        | notice dates, referral dates, and comments to support debt  |
|        | collection activities.                                      |
+--------+-------------------------------------------------------------+
| RMC-17 | **Allowance for loss---**Calculate and record the allowance |
|        | for loss on accounts receivable based on agency-defined     |
|        | criteria, including percentage of gross book value of       |
|        | receivables within an age category, customer type, and      |
|        | receivable type.                                            |
+--------+-------------------------------------------------------------+
| RMC-18 | **Delinquent debt categories---**Classify delinquent debt   |
|        | by the following categories needed for the TROR:            |
|        |                                                             |
|        | > • In Bankruptcy                                           |
|        | >                                                           |
|        | > • In Forbearance or formal appeals process                |
|        | >                                                           |
|        | > • In Foreclosure                                          |
|        | >                                                           |
|        | > • At private collection agencies                          |
|        | >                                                           |
|        | > • At DOJ                                                  |
|        | >                                                           |
|        | > • Eligible for internal offset                            |
|        | >                                                           |
|        | > • In wage garnishment                                     |
|        | >                                                           |
|        | > • At Treasury for cross-servicing                         |
|        | >                                                           |
|        | > • At Treasury for Offset                                  |
|        | >                                                           |
|        | > • At Agency                                               |
|        | >                                                           |
|        | > • Other.                                                  |
+--------+-------------------------------------------------------------+
| RMC-19 | **Treasury Report on Receivables (TROR)---**Generate the    |
|        | Treasury Report on Receivables (TROR). Parameter is the     |
|        | fiscal year and quarter. Result is the TROR in accordance   |
|        | with Treasury form and instructions. Ensure reported totals |
|        | agree with the general ledger.                              |
+--------+-------------------------------------------------------------+
| RMC-20 | **Customer receivables query---**Query customer             |
|        | receivables. Parameters include Customer ID Number,         |
|        | Customer Name, TIN, Trading partner codes. Result is a      |
|        | display of the customer's information (e.g., customer ID    |
|        | number, customer name, TIN, trading partner codes) and all  |
|        | receivable-related activity associated with the customer,   |
|        | including the following:                                    |
|        |                                                             |
|        | > • Principal                                               |
|        | >                                                           |
|        | > • Interest                                                |
|        | >                                                           |
|        | > • Penalties                                               |
|        | >                                                           |
|        | > • Administrative charges                                  |
|        | >                                                           |
|        | > • Adjustments                                             |
|        | >                                                           |
|        | > • Collections                                             |
|        | >                                                           |
|        | > • Waivers                                                 |
|        | >                                                           |
|        | > • Write-offs                                              |
|        | >                                                           |
|        | > • Receivable balance.                                     |
|        |                                                             |
|        | Group interest, penalties, and administrative charges with  |
|        | their associated principal. Drill down to the detailed      |
|        | transactions, documents, and document details (e.g.,        |
|        | document numbers, transaction dates, document reference     |
|        | numbers, receivable statuses (billed or unbilled), bill     |
|        | numbers (if billed), bill dates, dunning notice dates,      |
|        | referral dates, due dates, and delinquent debt statuses).   |
+--------+-------------------------------------------------------------+
| RMC-21 | **IRS Form 1099-C---**Generate IRS form 1099-C in           |
|        | accordance with IRS instructions.                           |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

## Collections and Offsets Process

The Collections and Offsets process supports activities to record the
receipt of funds either by currency (e.g., cash, EFT) or check 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 Collections and Offsets process, the Core financial
system **[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| RMD-01 | **Collection data---**Capture the following additional      |
|        | information on collections:                                 |
|        |                                                             |
|        | > • Vendor/customer ID number and name                      |
|        | >                                                           |
|        | > • Deposit number                                          |
|        | >                                                           |
|        | > • Deposit date                                            |
|        | >                                                           |
|        | > • Deposit confirmation date                               |
|        | >                                                           |
|        | > • Obligation reference number                             |
|        | >                                                           |
|        | > • Reimbursable agreement reference number                 |
|        | >                                                           |
|        | > • Advance reference number                                |
|        | >                                                           |
|        | > • Payment reference number                                |
|        | >                                                           |
|        | > • Source (Cash, EFT, Check, Money order, Credit card,     |
|        | > IPAC, SF 1081, Electronic file from bank, or Treasury     |
|        | > Offset Program)                                           |
|        | >                                                           |
|        | > • Comments.                                               |
+--------+-------------------------------------------------------------+
| RMD-02 | **Collections against receivables---**Record collections    |
|        | against receivables. Reference the receivable document and  |
|        | update customer records and related billing information.    |
+--------+-------------------------------------------------------------+
| RMD-03 | **Collections without receivables---**Record collections    |
|        | with corresponding revenues, expenditure reductions,        |
|        | advance/prepayment reclassifications or other offsets, when |
|        | receivables were not previously established.                |
+--------+-------------------------------------------------------------+
| RMD-04 | **Order for applying collections---**Apply collections      |
|        | against receivables in the following order: first to        |
|        | penalty and administrative costs, second to interest        |
|        | receivable, and third to outstanding debt principal, in     |
|        | accordance with the DCIA, unless otherwise stated in        |
|        | program statute.                                            |
+--------+-------------------------------------------------------------+
| RMD-05 | **Collections on closed receivables---**Record collections  |
|        | received against receivables that were waived or written    |
|        | off.                                                        |
+--------+-------------------------------------------------------------+
| RMD-06 | **Collections of overpayments---**Record collections of     |
|        | refunds of previous overpayments or erroneous payments. If  |
|        | a receivable was not previously established, reference the  |
|        | obligation. Reduce cumulative payments and expenditures     |
|        | under the obligation.                                       |
+--------+-------------------------------------------------------------+
| RMD-07 | **Collections of advance payments---**Record collections of |
|        | refunds of advance payments or prepayments. If a receivable |
|        | was not previously established, reference the advance       |
|        | obligation. Reduce cumulative advances under the            |
|        | obligation.                                                 |
+--------+-------------------------------------------------------------+
| RMD-08 | **Reimbursable agreement advances received---**Record       |
|        | advances (unearned revenue) received under reimbursable     |
|        | agreements. Update the advance balances on the reimbursable |
|        | agreements.                                                 |
+--------+-------------------------------------------------------------+
| RMD-09 | **Reimbursable agreement revenue received---**Record        |
|        | revenue received under reimbursable agreements. Update the  |
|        | earned revenue balances on the reimbursable agreements.     |
+--------+-------------------------------------------------------------+
| RMD-10 | **Refund excess advance payments---**Generate a refund      |
|        | payable when collections of advances from others exceed the |
|        | amount expended or billed on a reimbursable agreement after |
|        | all work is performed. Update the advance balances on the   |
|        | reimbursable agreements.                                    |
+--------+-------------------------------------------------------------+
| RMD-11 | **Collections query---**Query collections. Parameters       |
|        | include:                                                    |
|        |                                                             |
|        | > • Source                                                  |
|        | >                                                           |
|        | > • Customer ID number                                      |
|        | >                                                           |
|        | > • Customer name                                           |
|        | >                                                           |
|        | > • TIN                                                     |
|        | >                                                           |
|        | > • Reimbursable agreement number                           |
|        | >                                                           |
|        | > • Receivable document number                              |
|        | >                                                           |
|        | > • Deposit date range                                      |
|        | >                                                           |
|        | > • Accounting period                                       |
|        | >                                                           |
|        | > • Accounting classification.                              |
|        |                                                             |
|        | Result is a list of collections within the specified        |
|        | parameters, with the values for all the possible            |
|        | parameters.                                                 |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

# Cost Management Function

The Cost Management function encompasses the capability to accumulate,
recognize, and distribute the cost of an agency's activities in the
financial system for management information purposes. Managerial cost
accounting concepts and standards for the Federal Government are
prescribed in SFFAS 4, *Managerial Cost Accounting Concepts and
Standards for the Federal Government*, promulgated by FASAB.

The term "cost" universally refers to monetary value of resources used
or sacrificed, or liabilities incurred, to achieve an objective: such as
to acquire or produce a good, or to perform an activity or service.
However, the level of sophistication needed within the Cost Management
function of the Core financial system is dependent upon an agency's
requirements and the nature of the programs within the agency. For
example, if an agency's primary mission is to produce a product or
service for sale, the costing function typically will be accomplished in
the Managerial Cost Accounting System that is integrated with the Core
financial system. Programs with less crucial cost information needs
might perform cost management functions by analytical or sampling
methods.

The managers and executives who have the need for cost information
should drive cost management in agencies. Regardless of agency need, the
Core financial system must contain basic cost management functions. For
example, SFFAS 4 requires that cost information developed for different
purposes should be drawn from common data sources and that cost reports
should be reconcilable to each other. Once management has identified the
cost objects it needs and the corresponding structure has been set up in
the accounting system, the system accumulates cost data accordingly. A
"cost object" is any activity, output, outcome, or item whose cost and
revenue are to be measured, such as organizational units, programs,
projects, targeted outputs, specific contracts, specific customers, work
orders, GPRA programs and activities, etc. After cost information is
accumulated and prepared, it is distributed to managers.

The Cost Management function consists of the following processes (the
prefixes assigned to the requirements are noted in parentheses):

-   Cost Setup and Accumulation (CMA)

-   Cost Distribution (CMB)

-   Cost Reporting (CMC).

## Cost Setup and Accumulation Process

The Cost Setup and Accumulation process identifies and tracks cost data
associated with the specific cost objects required by management. This
process provides for the establishment of identifiers for the desired
cost objects in the processes, systems, and applications that make up
the accounting system and for the subsequent collection of cost data. An
agency's financial management system must allow the establishment of
cost object identifiers consistent with the stated needs of its
financial and operational managers. Ideally, the financial system will
allow this to be done in a straightforward manner, without undue
complexity. The Cost Setup and Accumulation process provides the data
needed for accountability over the financial execution of public
programs, meaningful comparisons to measure compliance with management
policies, evaluation of the efficiency and economy of resources used in
the various activities, and support for fees, services, or products. It
also provides a basis for linking operational results to the budget and
performance measures.

##### Mandatory Requirements

To support the Cost Setup and Accumulation process, the Core financial
system **[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| CMA-01 | **Define cost objects---**Define the following types of     |
|        | cost objects for accumulation, distribution and reporting   |
|        | purposes:                                                   |
|        |                                                             |
|        | > • Accounting classification elements                      |
|        | >                                                           |
|        | > • Specific customers, vendors, reimbursable agreements,   |
|        | > contracts, PAs, task orders, work orders, and grants      |
|        | >                                                           |
|        | > • GPRA goals.                                             |
+--------+-------------------------------------------------------------+
| CMA-02 | **Accumulate costs---**Accumulate costs and revenue by cost |
|        | object.                                                     |
+--------+-------------------------------------------------------------+
| CMA-03 | **Costs objects on prepaid expenses---**Associate the       |
|        | purchase of fixed assets and inventory and the payment of   |
|        | advances with related cost objects so that subsequent       |
|        | expenditures are identified by cost object.                 |
+--------+-------------------------------------------------------------+
| CMA-04 | **Full cost---**Accumulate the full cost of cost objects.   |
|        | Full costs include direct costs, indirect cost allocations, |
|        | implicit costs (e.g., costs provided by other government    |
|        | agencies such as pension costs), and unfunded costs (e.g.,  |
|        | annual leave costs).                                        |
+--------+-------------------------------------------------------------+
| CMA-05 | **Non-financial data---**Accumulate non-financial data      |
|        | (e.g., units purchased, units sold) by cost object at the   |
|        | transaction level.                                          |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

## Cost Distribution Process

The managerial cost accounting concepts and standards contained in SFFAS
4 are aimed at providing reliable and timely information on the full
cost of programs, their activities, and outputs. The information is used
by stakeholders, executives, and managers when making decisions about
allocating resources, authorizing and modifying programs, and evaluating
program performance. Program managers also use the cost information for
making managerial decisions to improve operating efficiency. Ultimately,
the effectiveness of a cost management program depends on the way
managers use the cost information asked for and reported to them.

##### Mandatory Requirements

To support the Cost Distribution process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

  --------- -------------------------------------------------------------
  CMB-01    **Recording cost distribution entries in GL---**Distribute
            the full cost of goods and services by cost object. Record
            the cost distribution entries in the GL.

  CMB-02    **Attributes on cost distribution---**Capture U.S. SGL
            attributes on cost distribution entries needed to prepare the
            Statement of Net Cost. For example, costs distributed to
            programs and used in the preparation of the Statement of Net
            Cost should retain the Federal/Non-Federal,
            Exchange/Non-Exchange, and Custodial/Non-Custodial
            classifications.

  CMB-03    **Multi-layer overhead distributions---**Perform multi-layer
            overhead distributions that are agency-defined (at least 3
            levels of distribution) using multiple rates and fixed amount
            allocation methods.

  CMB-04    **Re-distribute costs---**Re-distribute costs based on
            revised rates and allocation amounts.
  --------- -------------------------------------------------------------

##### Value-Added Requirements

There are no value-added requirements for this process.

## Cost Reporting Process

To support the Cost Reporting process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| CMC-01 | **Comparative income statement by cost object---**Generate  |
|        | the Comparative Income Statement by Cost Object. Parameters |
|        | include cost object and accounting periods (month and       |
|        | year). Result is a report that compares month and           |
|        | year-to-date activity to prior month and prior year-to-date |
|        | activity, by cost object. The report must list the          |
|        | following data:                                             |
|        |                                                             |
|        | > • Revenue                                                 |
|        | >                                                           |
|        | > • Direct expenses                                         |
|        | >                                                           |
|        | > • Indirect expenses (overhead)                            |
|        | >                                                           |
|        | > • Total expenses                                          |
|        | >                                                           |
|        | > • Net revenue/cost.                                       |
+--------+-------------------------------------------------------------+
| CMC-02 | **Cost object income statement---**Generate Cost Object     |
|        | Income Statement. Parameters include any cost object and    |
|        | accounting period. Result is a report with revenue, direct  |
|        | cost, and indirect cost (overhead) by cost object.          |
+--------+-------------------------------------------------------------+
| CMC-03 | **Cost object audit trail---**Maintain an audit trail of    |
|        | transactions from their origin to the final cost object(s). |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

# Fund Balance with Treasury Management Function

The Fund Balance with Treasury (FBWT) represents the money an agency can
spend on future authorized transactions. Agencies record transactions
that increase and decrease their FBWT to U.S. SGL account 1010 in their
general ledger. Appropriation warrants, non-expenditure transfers,
collections, and disbursements are some of the transactions that impact
an agency's FBWT.

Treasury requires that agencies reconcile their FBWT accounts regularly.
RFCs, Disbursing Offices, and other depositaries provide Treasury with
receipt and disbursement activity of the government. A comparison of
this receipt and disbursement activity with agency records ensures the
integrity and accuracy of internal and governmentwide financial report
data.

The Fund Balance with Treasury Management function consists of the
following processes (the prefixes assigned to the requirements are noted
in parentheses):

-   Treasury Information Maintenance (FBA)

-   Payment Confirmation (FBB)

-   Reconciliation and Reporting (FBC).

## Treasury Information Maintenance Process

Most Federal agencies process large volumes of transactions that impact
their FBWT. To facilitate automatic reconciliations with Treasury, an
agency must classify cash transactions with Treasury defined codes. The
Treasury Information Maintenance process ensures that the classification
structures and valid data element relationships are in place for an
agency's system to use to classify and identify transactions that impact
the FBWT.

##### Mandatory Requirements

To support the Treasury Information Maintenance process, the Core
financial system **[must]{.underline}** provide automated functionality
to do the following:

+--------+-------------------------------------------------------------+
| FBA-01 | **Multiple ALCs---**Maintain multiple ALCs.                 |
+--------+-------------------------------------------------------------+
| FBA-02 | **ALC Type---**Define an ALC as a GWA reporter or a non-GWA |
|        | reporter.                                                   |
+--------+-------------------------------------------------------------+
| FBA-03 | **ALC Business Activities---**Maintain ALC Business         |
|        | Activities.                                                 |
+--------+-------------------------------------------------------------+
| FBA-04 | **ALC Business Activity---**Define an ALC's Business        |
|        | Activity as:                                                |
|        |                                                             |
|        | > • IPAC only                                               |
|        | >                                                           |
|        | > • CA\$HLINK II only                                       |
|        | >                                                           |
|        | > • TDO Payments only                                       |
|        | >                                                           |
|        | > • IPAC and CA\$HLINK II                                   |
|        | >                                                           |
|        | > • IPAC and TDO payments                                   |
|        | >                                                           |
|        | > • TDO payments and CA\$HLINK II                           |
|        | >                                                           |
|        | > • IPAC, CA\$HLINK II, and TDO payments.                   |
+--------+-------------------------------------------------------------+
| FBA-05 | **GWA Reporter Categories---**Maintain GWA Reporter         |
|        | Categories.                                                 |
+--------+-------------------------------------------------------------+
| FBA-06 | **GWA Reporter Category---**Define the GWA Reporter         |
|        | Category for GWA reporter ALCs as                           |
|        |                                                             |
|        | > • IPAC Only                                               |
|        | >                                                           |
|        | > • CA\$HLINK II Only                                       |
|        | >                                                           |
|        | > • TDO Payments Only                                       |
|        | >                                                           |
|        | > • IPAC and CA\$HLINK II                                   |
|        | >                                                           |
|        | > • IPAC and TDO Payments                                   |
|        | >                                                           |
|        | > • TDO Payments and CA\$HLINK II, or                       |
|        | >                                                           |
|        | > • IPAC, CA\$HLINK II and TDO Payments.                    |
+--------+-------------------------------------------------------------+
| FBA-07 | **Capture ALC---**Capture the ALC on all transactions that  |
|        | impact the FBWT and are reported to Treasury on the FMS     |
|        | 224, Partial 224, or through the GWA system.                |
+--------+-------------------------------------------------------------+
| FBA-08 | **TAS/BETC combinations---**Maintain valid TAS/BETC         |
|        | combinations as provided by Treasury's SAM for              |
|        | classification of the agency's FBWT transactions in the GWA |
|        | system.                                                     |
+--------+-------------------------------------------------------------+
| FBA-09 | **Capture TAS/BETC---**Capture the TAS/BETC on all          |
|        | transactions that impact the FBWT and are reported through  |
|        | the GWA system.                                             |
+--------+-------------------------------------------------------------+
| FBA-10 | **FBWT transaction types---**Define transactions that       |
|        | impact the FBWT and are reported on the FMS 224, Partial    |
|        | 224, or through the GWA system as "IPAC", "CA\$HLINK II",   |
|        | "TDO Payments", or "Reclassifications".                     |
+--------+-------------------------------------------------------------+
| FBA-11 | **Treasury Document Number---**Capture the "Treasury        |
|        | Document #" on all transactions that impact the FBWT.       |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

## Payment Confirmation Process

Agencies that disburse payments through Treasury provide the details of
requested payments (e.g., vendor name, amount of payment, payment date)
on a payment schedule. The payment schedule may contain hundreds of
individual payments that an agency is requesting be made. Upon
accomplishing the payments, Treasury will notify the agency. The agency
must update its general ledger with the proper accounting entry to
record the disbursement of funds and to capture information about
individual payments that may be critical in reconciling the FBWT or
answering vendors' questions concerning payments made. Because of the
high volume of payments that most Federal agencies make, the Payment
Confirmation process must ensure that an automated process is in place
to update confirmation information.

##### Mandatory Requirements

To support the Payment Confirmation process, the Core financial system
**[must]{.underline}** provide automated functionality to do the
following:

  --------- -------------------------------------------------------------
  FBB-01    **Payment confirmation data---**Import payment confirmation
            data from the GOALS II/IAS RFC Agency Link.

  FBB-02    **Liquidate disbursements-in-transit---**Liquidate individual
            disbursement-in-transit transactions and record confirmed
            disbursements upon receipt of payment confirmation from the
            GOALS II IAS RFC Agency Link.

  FBB-03    **Update payment information---**Update payments with paid
            schedule number, confirmed date, and check number or trace
            number upon receipt of confirmation data from the GOALS II
            IAS RFC Agency Link.

  FBB-04    **Assign check numbers---**Assign check numbers to individual
            payments, based upon the payment schedule's check range
            received from the GOALS II IAS RFC Agency Link.

  FBB-05    **Correct check number---**Correct system-assigned check
            numbers on payment records that do not match the actual check
            number assigned by Treasury.

  FBB-06    **Multiple check ranges---**Assign check numbers to
            individual payment records when a payment schedule has
            multiple check ranges or a break in check numbers.

  FBB-07    **Disbursement cancellations---**Record disbursement
            cancellations for individual payments that have not been
            negotiated.
  --------- -------------------------------------------------------------

##### Value-Added Requirements

There are no value-added requirements for this process.

## Reconciliation and Reporting Process

Reconciling the FBWT is a complex and multistep process that involves an
exchange of information between an agency and the Treasury. Agencies
provide Treasury with the proper classification (e.g., Treasury Account
Symbol) information for its receipt and disbursement activity. Treasury
provides agencies with detailed support listings of receipt and
disbursement activity that agencies must compare to the detailed
transactions posted in their general ledger. The Reconciliation and
Reporting process facilitates the comparison of transactions at this
detailed level.

##### Mandatory Requirements

To support the Reconciliation and Reporting process, the Core financial
system **[must]{.underline}** provide automated functionality to do the
following:

+--------+-------------------------------------------------------------+
| FBC-01 | **Import ACR listing---**Import the ACR support listing     |
|        | from the GOALS II/IAS RFC Agency Link to facilitate         |
|        | reconciliation of agency recorded disbursements and         |
|        | cancellations with Treasury.                                |
+--------+-------------------------------------------------------------+
| FBC-02 | **Compare ACR support listing with GL---**Compare           |
|        | individual amounts on the ACR support listing with amounts  |
|        | recorded in the agency's general ledger by schedule number  |
|        | and accounting period. The accounting period is the fiscal  |
|        | month and year used for financial reporting purposes.       |
+--------+-------------------------------------------------------------+
| FBC-03 | **GL/ACR Discrepancy Report---**Generate the GL/ACR         |
|        | Discrepancy Report. Parameter is accounting period. Result  |
|        | is a report including schedule number, dollar amount, and   |
|        | confirmed date or transaction date of:                      |
|        |                                                             |
|        | > • Items on the ACR listing and not in the agency's        |
|        | > general ledger                                            |
|        | >                                                           |
|        | > • Items on the ACR listing for a different amount than in |
|        | > the agency's\                                             |
|        | > general ledger                                            |
|        | >                                                           |
|        | > • Items in the agency's general ledger and not on the ACR |
|        | > listing.                                                  |
+--------+-------------------------------------------------------------+
| FBC-04 | **Import IPAC support listing---**Import IPAC support       |
|        | listing from the GOALS II/IAS to facilitate reconciliation  |
|        | of agency recorded IPAC transactions with Treasury.         |
+--------+-------------------------------------------------------------+
| FBC-05 | **Compare IPAC support listing with GL---**Compare IPAC     |
|        | transactions on the IPAC support listing with IPAC          |
|        | transactions recorded in the agency's general ledger.       |
+--------+-------------------------------------------------------------+
| FBC-06 | **GL/IPAC Discrepancy Report---**Generate the GL/IPAC       |
|        | Discrepancy Report. Parameter is the accounting period.     |
|        | Result is report including document reference number (from  |
|        | IPAC Support Listing), dollar amount, and audit date or     |
|        | transaction date of:                                        |
|        |                                                             |
|        | > • Items on the IPAC support listing and not in the        |
|        | > agency's general ledger                                   |
|        | >                                                           |
|        | > • Items on the IPAC support listing for a different       |
|        | > amount than in the agency's general ledger                |
|        | >                                                           |
|        | > • Items in the agency's general ledger and not on the     |
|        | > IPAC support listing.                                     |
+--------+-------------------------------------------------------------+
| FBC-07 | **Import DT/DV support listing---**Import the Monthly DT/DV |
|        | support listing from the GOALS II/IAS to facilitate         |
|        | reconciliation of agency recorded deposits and debit        |
|        | vouchers with Treasury.                                     |
+--------+-------------------------------------------------------------+
| FBC-08 | **Compare DT/DV support listing with GL---**Compare         |
|        | individual amounts on the DT/DV support listing with        |
|        | amounts recorded in the agency's general ledger by document |
|        | number and accounting period.                               |
+--------+-------------------------------------------------------------+
| FBC-09 | **GL/DT/DV Discrepancy Report---**Generate the GL Deposit   |
|        | Ticket/Debit Voucher Discrepancy Report. Parameter is the   |
|        | accounting period. Result is a report including document    |
|        | number (Deposit Ticket or Debit Voucher number), dollar     |
|        | amount, and document date of:                               |
|        |                                                             |
|        | > • Items on the DT/DV support listing and not in the       |
|        | > agency's general ledger                                   |
|        | >                                                           |
|        | > • Items on the DT/DV support listing for a different      |
|        | > amount than in the agency's general ledger                |
|        | >                                                           |
|        | > • Items in the agency's general ledger and not on the     |
|        | > DT/DV support listing.                                    |
+--------+-------------------------------------------------------------+
| FBC-10 | **FMS 224 Report---**Generate the FMS 224 Report. Parameter |
|        | is the accounting period. Result is the FMS 224, Statement  |
|        | of Transactions, for non-GWA reporting ALC's. Generate the  |
|        | report in both hard copy and electronic formats required by |
|        | the Department of the Treasury.                             |
+--------+-------------------------------------------------------------+
| FBC-11 | **Partial 224 Report---**Generate the FMS Partial 224       |
|        | Report. Parameters are the ALC Business Activity, GWA       |
|        | Reporter Category, and accounting period. Result is the FMS |
|        | Partial 224 for transactions associated with the ALC's      |
|        | Business Activity (IPAC, CA\$HLINK II, TDO Payments) and    |
|        | not reported through the GWA system, and Reclassification   |
|        | transactions. Generate the report in both hard copy and     |
|        | electronic formats required by the Department of Treasury.  |
+--------+-------------------------------------------------------------+
| FBC-12 | **1219/1220 Statements---**Generate the SF1219/1220         |
|        | statements. Parameter is accounting period. Result is SF    |
|        | 1219/1220, Statement of Accountability/\                    |
|        | Transactions in both hard copy and electronic formats       |
|        | required by the Department of Treasury.                     |
+--------+-------------------------------------------------------------+
| FBC-13 | **FMS 224 Cash Transaction Detail Report---**Generate the   |
|        | FMS 224 Transaction Detail Report. Parameter is the         |
|        | accounting period. Result is a report listing the detailed  |
|        | transactions supporting each TAS total reported in each     |
|        | section of the FMS 224. Detailed transactions must include: |
|        |                                                             |
|        | > • ALC                                                     |
|        | >                                                           |
|        | > • TAS                                                     |
|        | >                                                           |
|        | > • Transaction amount                                      |
|        | >                                                           |
|        | > • Confirmation date                                       |
|        | >                                                           |
|        | > • Transaction document number or Treasury document        |
|        | > number.                                                   |
|        |                                                             |
|        | Separate report totals for disbursement and receipt         |
|        | activity by ALC and TAS must be provided.                   |
+--------+-------------------------------------------------------------+
| FBC-14 | **Partial 224 Transaction Detail Report---**Generate the    |
|        | Partial 224 Transaction Detail Report. Parameter is the     |
|        | accounting period. Result is a report listing the detailed  |
|        | transactions supporting each TAS total reported in each     |
|        | section of the Partial 224. Detailed transactions must      |
|        | include:                                                    |
|        |                                                             |
|        | > • ALC                                                     |
|        | >                                                           |
|        | > • TAS                                                     |
|        | >                                                           |
|        | > • Transaction amount                                      |
|        | >                                                           |
|        | > • Confirmation date                                       |
|        | >                                                           |
|        | > • Transaction document number or Treasury document        |
|        | > number.                                                   |
|        |                                                             |
|        | Separate report totals for disbursement and receipt         |
|        | activity by ALC and TAS must be provided.                   |
+--------+-------------------------------------------------------------+
| FBC-15 | **Partial 224 Exception Report---**Generate a Partial 224   |
|        | Exception Report. Parameter is accounting period. Result is |
|        | a list of the FBWT transactions that were posted to an ALC, |
|        | but are ineligible for inclusion on the P224 based on the   |
|        | ALC's business activity. Transactions must include:         |
|        |                                                             |
|        | > • ALC                                                     |
|        | >                                                           |
|        | > • TAS                                                     |
|        | >                                                           |
|        | > • Transaction amount                                      |
|        | >                                                           |
|        | > • Confirmation date                                       |
|        | >                                                           |
|        | > • Document number.                                        |
+--------+-------------------------------------------------------------+
| FBC-16 | **Cash Forecasting Report---**Generate the Cash Forecasting |
|        | Report. Result is a report with payment and deposit amounts |
|        | at a detail suitable for reporting large dollar             |
|        | notifications as described in I TFM-6-8500, Cash            |
|        | Forecasting Requirements.                                   |
+--------+-------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements for this process.

# Technical System Requirements

Technical requirements have been established to help ensure that a Core
financial system is fully supported and capable of processing the
workload required. It must provide transaction processing integrity and
general operating reliability; use standard procedures for installation,
configuration, and operations; provide seamless integrated workflow
processing; have the ability to query, access, and format information;
and be well documented. It must not conflict with other administrative
or program systems or with other agency-established IT standards.

Core financial systems must meet the mandatory technical requirements
specified in this section. In addition, they should strive to include
the functionality listed as value-added requirements. The technical
requirements are categorized as follows (the prefixes assigned to the
requirements are noted in parentheses):

-   General Design/Architecture (TLA)

-   Infrastructure (TLB)

-   User Interfaces (TLC)

-   Interoperability (TLD)

-   Workflow/Messaging (TLE)

-   Document Management (TLF)

-   Internet Access (TLG)

-   Security (TLH)

-   Operations (TLI)

-   Ad Hoc Query (TLJ)

-   Documentation (TLK)

-   System Performance (TLL).

Most technical requirements are stated in general terms to allow vendors
maximum flexibility in designing compliant financial systems. Individual
agencies are encouraged to add specific interoperability, system
performance, and workload requirements considered unique to their
respective IT environments when evaluating packages for acquisition.

## General Design/Architecture

The technical requirements relate to the overall product and its
structure at the highest level. Federal standards are published for the
purpose of limiting Core financial system acquisition to qualified
options. The basic design features and system architecture determine the
adaptability of the system, such as customization and upgradeability. A
Core financial system must be designed with the flexibility to respond
to the changing Federal environment.

##### Mandatory Requirements

To meet General Design/Architecture requirements, the Core system
**[must]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLA-01   **General design---**Delivered system must be modular, highly
           scalable and incorporate an open-systems architecture.

  TLA-02   **Customization---**Delivered system must be customizable to
           meet agency-defined business practices. Agency customizable
           features must be table/parameter driven.

  TLA-03   **Upgradeability---**Delivered system must be upgradeable to
           accommodate changes in laws, regulations, best practices or
           new technology.

  TLA-04   **System outputs---**Delivered system must generate output
           reports, query results and data files using multiple formats
           as specified by functional requirements. Specified formats can
           include online display, printed report, Portable Document
           Format (PDF), MS Word, Excel, ASCII or delimited text file. In
           cases where an output format is not specified within a
           requirement, the requested information must be viewable to the
           agency online, using the application user interface.

  TLA-05   **Date handling---**Deliver fault-free performance in the
           processing of date and date-related data (including,
           calculating, comparing, and sequencing) by all hardware and
           software products included as part of the application both
           individually and in combination (i.e., be Y2K compliant).
  -------- --------------------------------------------------------------

##### Value-Added Requirements

To add value to the General Design/Architecture functionality, the Core
financial system **[should]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLA-06   **Parallel transaction processing---**Delivered system should
           be capable of processing online transactions, batch jobs and
           transactions submitted via system interface simultaneously.

  TLA-07   **Report spooling---**Deliver a reports management capability
           to enable online retrieval, viewing, re-printing, and
           permanent archiving of system-generated reports.
  -------- --------------------------------------------------------------

## Infrastructure

The Core financial systems infrastructure provides the underlying base
or foundation of the computing system platforms and operating system
environments where a qualified Core system would be installed by a
Federal agency. It is necessary for the infrastructure to support a
Windows operating system and provide certain basic communications and
database functions common to Federal Government system installations.

##### Mandatory Requirements

To meet Infrastructure requirements, the Core system
**[must]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLB-01   **Relational database---**Delivered system must include a
           Structured Query Language (SQL) compliant relational database.

  -------- --------------------------------------------------------------

##### Value-Added Requirements

To add value to the Infrastructure functionality, the Core financial
system **[should]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLB-02   **Mainframe operation---**Operate in a mainframe environment
           (e.g., Multiple Virtual System (MVS), Operating System (OS/)
           390).

  TLB-03   **UNIX/NT software---**Operate in a server computing
           environment running under UNIX, LINUX, Windows Server 2000 or
           above.

  TLB-04   **Apple/Mac---**Operate in an Apple Macintosh system
           environment.
  -------- --------------------------------------------------------------

## User Interfaces

Technical User Interfaces requirements specify how agency users and
operators interact with the Core financial system. These requirements
address the ability of users to effectively configure the package, enter
transactions, query processing results, or start/stop internal
processes.

##### Mandatory Requirements

To meet User Interfaces requirements, the Core financial system
**[must]{.underline}** deliver the following:

+-------+--------------------------------------------------------------+
| T     | **GUI interface---**Deliver an online graphical user         |
| LC-01 | interface (GUI). The GUI must provide consistent data entry, |
|       | navigation and information presentation across all modules   |
|       | and sub-systems.                                             |
+-------+--------------------------------------------------------------+
| T     | **508 Compliance---**Comply with Section 508 of the          |
| LC-02 | Rehabilitation Act, as detailed in 36 CFR 1194, Subpart B.   |
+-------+--------------------------------------------------------------+
| T     | **Context-sensitive help---**Deliver a context-sensitive,    |
| LC-03 | online help facility. This facility must be customizable by  |
|       | the agency.                                                  |
+-------+--------------------------------------------------------------+
| T     | **Error message customization---**Deliver the capability to  |
| LC-04 | customize error message text.                                |
+-------+--------------------------------------------------------------+
| T     | **Data entry efficiencies---**Incorporate user interface     |
| LC-05 | features designed to reduce the amount of direct keying      |
|       | required for transaction processing, such as:                |
|       |                                                              |
|       | > • Default values based on system maintained transaction    |
|       | > and user profiles                                          |
|       | >                                                            |
|       | > • Value look-up tables                                     |
|       | >                                                            |
|       | > • Highlighting or accentuating required fields             |
|       | >                                                            |
|       | > • Grayed data fields that are unavailable for user entry   |
|       | >                                                            |
|       | > • Auto tabs                                                |
|       | >                                                            |
|       | > • Automatic data recall                                    |
|       | >                                                            |
|       | > • Auto fill text                                           |
|       | >                                                            |
|       | > • Cut, copy and paste functionality                        |
|       | >                                                            |
|       | > • Keyboard shortcuts (e.g., function keys to invoke help   |
|       | > facility, clear screen, etc.)                              |
|       | >                                                            |
|       | > • Menu mode of screen navigation                           |
|       | >                                                            |
|       | > • Undo/redo                                                |
|       | >                                                            |
|       | > • Disabling of non-supported function keys                 |
|       | >                                                            |
|       | > • Ability to select records from a list by scrolling or    |
|       | > typing only part of an entry.                              |
|       | >                                                            |
|       | > • Ability to pass common data from field to field, screen  |
|       | > to screen and transaction to transaction.                  |
+-------+--------------------------------------------------------------+

##### Value-Added Requirements

To add value to the User Interfaces functionality, the Core financial
system **[should]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLC-06   **Desktop integration---**Support integration with other
           common desktop applications (e.g., word processing,
           spreadsheets, data management).

  -------- --------------------------------------------------------------

## Interoperability

Financial transactions can be originated using multiple external feeder
applications. These feeder systems and the Core financial system must
interface seamlessly so that data can move effectively between them. The
Core system must be able to process and validate the data independent of
origination. There must also be a process for handling erroneous input
and corrections.

##### Mandatory Requirements

To meet Interoperability requirements, the Core system
**[must]{.underline}** deliver the following:

+-------+--------------------------------------------------------------+
| T     | **Application program interface (API)---**Deliver a          |
| LD-01 | capability to import and process standard transactions       |
|       | generated by other systems.                                  |
+-------+--------------------------------------------------------------+
| T     | **API record layouts---**Deliver data record layouts for all |
| LD-02 | standard transactions that can be accepted by the            |
|       | application's API facility. Transactions must include        |
|       | sufficient data to enable complete validation and processing |
|       | by the receiving system.                                     |
+-------+--------------------------------------------------------------+
| T     | **API transaction validation---**Process API transactions    |
| LD-03 | using the same business rules, program logic, and edits used |
|       | by the system in processing transactions submitted through   |
|       | the application client.                                      |
+-------+--------------------------------------------------------------+
| T     | > **API transaction suspension---**Deliver the capability to |
| LD-04 | > suspend erroneous API transactions. Suspense processing    |
|       | > must include the ability to perform the following          |
|       | > functions:                                                 |
|       | >                                                            |
|       | > • Report suspended transactions                            |
|       | >                                                            |
|       | > • Retrieve, view, correct and process, or cancel suspended |
|       | > transactions                                               |
|       | >                                                            |
|       | > • Automatically re-process transactions                    |
|       | >                                                            |
|       | > • Report re-processed transactions.                        |
+-------+--------------------------------------------------------------+
| T     | **API processing controls---**Deliver API processing         |
| LD-05 | controls to ensure real time transactions or batch           |
|       | transactions files are received from authorized sources,     |
|       | complete and not duplicates. In addition, the API must       |
|       | ensure that where batch files are used:                      |
|       |                                                              |
|       | > • The number of transactions in a received file matches a  |
|       | > control record count                                       |
|       | >                                                            |
|       | > • The dollar total of transactions in a file matches a     |
|       | > control amount                                             |
|       | >                                                            |
|       | > • The sender is notified of erroneous transactions         |
|       | >                                                            |
|       | > • The erroneous transactions are automatically returned to |
|       | > the sender.                                                |
+-------+--------------------------------------------------------------+
| T     | **API generated error notices---**Generate API transaction   |
| LD-06 | edit error records using a data layout defined by the vendor |
|       | (i.e., provide two-way interface support).                   |
+-------+--------------------------------------------------------------+
| T     | **Agency e-mail---**Deliver the capability to connect to an  |
| LD-07 | agency operated e-mail system. This capability must include  |
|       | the ability to distribute application generated text         |
|       | messages with attached files.                                |
+-------+--------------------------------------------------------------+

##### Value-Added Requirements

To add value to the Interoperability functionality, the Core financial
system **[should]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLD-08   **EDI translation---**Support direct EDI translation compliant
           with American National Standards Institute (ANSI) X-12
           standards to enable electronic data exchanges with designated
           trading partners.

  TLD-09   **XML---**Deliver an integrated Extensible Markup Language
           (XML) parsing capability.

  TLD-10   **XBRL**---Deliver a capability to exchange data using the
           Extensible Business Reporting Language.
  -------- --------------------------------------------------------------

## Workflow/Messaging

Workflow/messaging includes technical requirements that establish
standards for application interfaces and collectively define how a Core
financial system automatically manages document processing; generates,
builds, maps, and models workflow processes and business rules; and
notifies agency staff of pending work (e.g., review/approval of pending
accounting documents).

##### Mandatory Requirements

To meet Workflow/Messaging requirements, the Core financial system
**[must]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLE-01   **Integrated workflow---**Deliver an integrated workflow
           management capability to automate internal routing of
           documents, transactions, forms or reports for online approval
           processing.

  TLE-02   **Workflow process definition---**Deliver the capability to
           customize workflow processes to automate agency-defined
           business rules, required approvers, pooled or proxy approving
           authorities and workload balancing. Agency customization must
           include the capability to apply start and end dates to
           approvers and their proxies.

  TLE-03   **Document processing approval---**Deliver the capability to
           define multiple levels of document approvals based on
           agency-defined criteria, including dollar amounts, types of
           items purchased, and document types.

  TLE-04   **Document approvals---**Deliver the capability to define
           multiple approval levels to a single user. Prevent a user from
           applying more than one level of approval to the same document
           in order to conform to the principle of separation of duties.
           For example, a disbursing officer must not be allowed to
           certify payment of an invoice he/she entered, and a certifying
           officer must not be allowed to schedule a payment he/she
           certified.

  TLE-05   **Processing exception notices---**Deliver a workflow
           calendaring capability to generate date-based process
           exception reports and alerts. For example, notify an accounts
           payable office when invoices are held over 30 days with no
           matching receiving report.

  TLE-06   **Document approval tracking---**Deliver the capability to
           capture approval actions by transaction, including the
           time/date and approving party.

  TLE-07   **Document routing---**Deliver the capability to route action
           requests/status messages internally to individuals, groups or
           external trading partners. Supported communications channels
           must include agency e-mail, Blackberry, internal application
           messaging.

  TLE-08   **User alerts---**Deliver the capability to generate workflow
           event-based user alerts. For example, at the point an
           emergency travel voucher is approved, electronically notify
           the affected traveler.

  TLE-09   **User notices---**Deliver the capability to generate user
           alerts based on agency-defined thresholds (i.e., trigger
           events). For example, electronically warn a budget officer
           when available funds reach 50% of the allotment.
  -------- --------------------------------------------------------------

##### 

##### Value-Added Requirements

To add value to the Workflow/Messaging functionality, the Core financial
system **[should]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLE-10   **Workflow process modeling---**Deliver a business process
           modeling capability.

  TLE-11   **Workflow definition audits---**Generate auditable records of
           changes made to the workflow approval routing design.

  TLE-12   **Wf-XML---**Delivered system should comply with the current
           Workflow Management Coalition (WFMC) Workflow Standard -
           Interoperability.
  -------- --------------------------------------------------------------

## Document Management

Document management addresses how the Core system stores and retrieves
electronically formatted documents.

##### Mandatory Requirements

To meet Document Management requirements, the Core financial system
**[must]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLF-01   **Indexed reference materials---**Deliver the capability to
           index and store file reference materials received or generated
           by the agency in electronic format.

  -------- --------------------------------------------------------------

##### Value-Added Requirements

To add value to the Document Management functionality, the Core
financial system **[should]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLF-02   **Document imaging---**Deliver the capability to
           electronically image, index and store file reference materials
           delivered in a hard copy format (e.g., a signed contract, bill
           of lading, vendor invoices).

  TLF-03   **Image availability notification---**Deliver the capability
           to notify the user of the presence of associated document
           images. Deliver on-screen display of imaged material.
  -------- --------------------------------------------------------------

## Internet Access

The Internet is a vast collection of interconnected networks that
communicate using TCP/IP. It has become a critical infrastructure for
application access. The technical requirements relating to Internet
access represent a specialized subset defining user connectivity options
and security issues.

##### Mandatory Requirements

To meet Internet Access requirements, the Core financial system
**[must]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLG-01   **TCP/IP---**Delivered system must support Transmission
           Control Protocol/Internet Protocol (TCP/IP) for application
           component connectivity.

  TLG-02   **Browser access---**Deliver browser access to all system
           modules/functionality.
  -------- --------------------------------------------------------------

##### Value-Added Requirements

To add value to the Internet Access functionality, the Core financial
system **[should]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLG-03   **Internet-originated transactions---**Deliver the capability
           to receive vendor invoices and payments from the public via
           the Internet.

  TLG-04   I**nternet access to ad hoc queries---**Support secure
           Internet access to the integrated ad hoc data query facility.

  TLG-05   **VPN---**Support operations via a Virtual Private Network
           (VPN) system capability for secure remote access.

  TLG-06   **PKI---**Deliver the capability to use Public Key
           Infrastructure technology to control system access.
  -------- --------------------------------------------------------------

## Security

This section addresses security controls needed to protect the
confidentiality, integrity, and availability of financial data
maintained in a qualified agency system. To meet security requirements,
the core system must comply with approved standards and guidelines,
including minimum requirements, for providing adequate information
security for all agency operations and assets as are appropriate for the
specific characteristics of the system. In addition to meeting the
specified application design standards, agencies are required to comply
with the following security related regulations and guidance:

-   Title III of the E-Government Act, of the Federal Information
    Security Management Act (FISMA) of 2002, P.L. 107-347, requires each
    federal agency to develop, document, and implement an agency-wide
    information security program.

-   In accordance with the provisions of FISMA, information security
    must be effectively integrated into the system development life
    cycle.

-   All new applications must undergo a full Certification and
    Accreditation (C&A), including an initial review to ensure
    compliance with NIST SP 800-37, Guidelines for the Security
    Certification and Accreditation of Federal Information Technology
    Systems. In conjunction with C&A, an agency will perform a
    self-assessment using the guidance found in NIST SP 800-26, Security
    Self-Assessment Guide for Information Technology Systems.

-   Title II of the *E-Government Act of 2002*, Section 208, requires a
    Privacy Impact Assessment (PIA) prior to developing or procuring IT
    systems that collect, maintain, or disseminate Information in
    Identifiable Form (IIF). All systems shall have a current PIA to
    ensure compliance with the *Privacy Act of 1974* and other IT
    privacy requirements.

System specific guidance, for systems which are not national security
systems, is provided by NIST, consistent with the requirements of the
Office of Management and Budget (OMB) Circular A-130, Section 8b(3),
Securing Agency Information Systems, as analyzed in A-130, Appendix IV:
Analysis of Key Sections. Supplemental information is provided A-130,
Appendix III.

##### Mandatory Requirements

To meet Security requirements, the Core system **[must]{.underline}**
deliver the following:

+-------+--------------------------------------------------------------+
| T     | **NIST compliance---**Deliver integrated security            |
| LH-01 | functionality compliant with the National Institute of       |
|       | Standards and Technology (NIST) Security Standards.          |
+-------+--------------------------------------------------------------+
| T     | **Security controls---**Ensure that the management,          |
| LH-02 | operations and technical baseline security controls are      |
|       | implemented in accordance with Federal Information           |
|       | Processing Standards (FIPS) 199 Standards for Security       |
|       | Categorization of Federal Information and Information        |
|       | Systems and other current NIST guidance on selecting the     |
|       | appropriate security controls.                               |
+-------+--------------------------------------------------------------+
| T     | **Access control---**Deliver the capability to control       |
| LH-03 | function access (e.g., system modules, transactions,         |
|       | approval authorities) and data access (i.e., create, read,   |
|       | update, delete) by assigned:                                 |
|       |                                                              |
|       | > • User ID                                                  |
|       | >                                                            |
|       | > • Functional role (e.g., payable technician) or            |
|       | >                                                            |
|       | > • Organization.                                            |
|       |                                                              |
|       | Enable the agency to define access rules based on any        |
|       | combination of these attributes.                             |
+-------+--------------------------------------------------------------+
| T     | **Security policy---**Ensure that the appropriate security   |
| LH-04 | controls are consistently enforced in all modules, including |
|       | software used for ad-hoc data query/report generators.       |
+-------+--------------------------------------------------------------+
| T     | **Sensitive data masking---**Deliver the capability to       |
| LH-05 | restrict access to sensitive data elements, such as social   |
|       | security numbers, banking information by user ID, assigned   |
|       | role or organization.                                        |
+-------+--------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements in this category.

## Operations

In general, most users should be unaware of background system
operations, except for scheduled maintenance. The Core financial system
should run smoothly and efficiently, and it must maintain database
consistency; archive, log, and retrieve data; stop and restart the
system without losing data; and report system status.

##### Mandatory Requirements

To meet Operations requirements, the Core system **[must]{.underline}**
deliver the following:

+-------+--------------------------------------------------------------+
| T     | **Process scheduling---**Deliver a process scheduling        |
| LI-01 | capability. Allow the agency to define, initiate, monitor    |
|       | and stop system processes (e.g., online availability, batch  |
|       | jobs, and system maintenance).                               |
+-------+--------------------------------------------------------------+
| T     | **Internal database controls---**Maintain internal database  |
| LI-02 | consistency at all times. In the event of a system failure   |
|       | the system must have the capability to:                      |
|       |                                                              |
|       | > • Back out incompletely processed transactions             |
|       | >                                                            |
|       | > • Restore the system to its last consistent state before   |
|       | > the failure occurred                                       |
|       | >                                                            |
|       | > • Re-apply all incomplete transactions previously          |
|       | > submitted by the user                                      |
|       | >                                                            |
|       | > • Validate internal database consistency to ensure         |
|       | > duplicate postings are avoided                             |
|       | >                                                            |
|       | > • Report any data or transactions that failed to process   |
|       | > completely.                                                |
+-------+--------------------------------------------------------------+
| T     | **Job processing messages---**Generate online status         |
| LI-03 | messages to the operator. Include job or transaction type,   |
|       | name, when processing initiates, when it completes, and any  |
|       | processing errors encountered.                               |
+-------+--------------------------------------------------------------+
| T     | **Job restart---**Deliver a restart capability for all       |
| LI-04 | application's online and batch processing components. Batch  |
|       | jobs must be segmented to facilitate restart in the event of |
|       | a system failure.                                            |
+-------+--------------------------------------------------------------+
| T     | **Error handling---**Deliver common error-handling routines  |
| LI-05 | across functional modules. Generate meaningful and traceable |
|       | error messages that allow the user or system operator to     |
|       | identify and respond to reported problems.                   |
+-------+--------------------------------------------------------------+
| T     | **Data archiving---**Deliver a document archiving            |
| LI-06 | capability. Include the ability to define, establish, and    |
|       | maintain archival criteria, such as date, accounting period, |
|       | closed items, and vendors/customers inactive for a specific  |
|       | time period. Archiving of                                    |
|       |                                                              |
|       | closed or completed detail transactions must not affect      |
|       | related general ledger account balances.                     |
+-------+--------------------------------------------------------------+
| T     | **Data archive standards---**Support data archiving and      |
| LI-07 | record retention in accordance with rules published by the   |
|       | National Archives and Records Administration (NARA), GAO,    |
|       | and National Institute of Standards and Technology (NIST).   |
+-------+--------------------------------------------------------------+
| T     | **Archived data retrieval---**Deliver the capability to      |
| LI-08 | restore archived data based on agency-defined criteria such  |
|       | as date, accounting period, or vendor/customer.              |
+-------+--------------------------------------------------------------+
| T     | **Event logging---**Deliver an event logging capability for  |
| LI-09 | systems, transactions, tables, and system parameters. The    |
|       | logs must include the following:                             |
|       |                                                              |
|       | > • User ID\                                                 |
|       | > • System date\                                             |
|       | > • Time\                                                    |
|       | > • Type of activity (i.e., add, modify, delete)\            |
|       | > • Old value\                                               |
|       | > • New value.                                               |
|       |                                                              |
|       | (For example, provide a log of all attempts to log onto the  |
|       | system or track changes to the prompt pay interest rate      |
|       | value.)                                                      |
+-------+--------------------------------------------------------------+
| T     | **Productivity reporting---**Maintain and report application |
| LI-10 | usage statistics. Productivity statistics should include     |
|       | concurrent users, job submissions, transactions throughput,  |
|       | and system availability.                                     |
+-------+--------------------------------------------------------------+
| T     | **System date for testing---**Deliver a capability to        |
| LI-11 | override the system date value used to automatically default |
|       | document effective date and related transaction posting      |
|       | date/period. This capability is intended for system testing. |
+-------+--------------------------------------------------------------+

##### Value-Added Requirements

To add value to the Operations functionality, the Core financial system
**[should]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLI-12   **Queued jobs---**Deliver the capability to process queued
           jobs (i.e. reports, transaction files from interfacing
           systems, bulk record updates) with no online performance
           degradation.

  TLI-13   **User selected access logging---**Deliver the capability to
           customize system logging features. Allow the agency to specify
           which parameters (or tables) to log. Allow the agency to turn
           logging feature on or off as needed).
  -------- --------------------------------------------------------------

## Ad Hoc Query

Over time, demands for specific financial data are expected to change
considerably as changes occur in, for example, administrations, program
missions, budget priorities, justifications, and oversight. Ad hoc
queries are often general but are critical to enabling effective agency,
program, and financial management in the face of change. To support ad
hoc queries, the Core financial system must provide flexible data
access, download, and formatting.

##### Mandatory Requirements

To meet Ad Hoc Query requirements, the Core financial system
**[must]{.underline}** deliver the following:

+-------+--------------------------------------------------------------+
| T     | **Ad hoc query---**Deliver an integrated ad hoc query        |
| LJ-01 | capability to support agency access to and analysis of       |
|       | system maintained financial data.                            |
+-------+--------------------------------------------------------------+
| T     | **Ad hoc query origination---**Deliver the capability to     |
| LJ-02 | define parameter-based query scripts that can be queued for  |
|       | execution, stored for re-use and shared with other           |
|       | authorized agency users.                                     |
+-------+--------------------------------------------------------------+
| T     | **Ad hoc query execution---**Process submitted queries and   |
| LJ-03 | queue output on-line for access by authorized users.         |
+-------+--------------------------------------------------------------+
| T     | **Ad hoc query results---**Distribute query results or       |
| LJ-04 | notifications of online query result availability to         |
|       | pre-defined individuals or groups.                           |
+-------+--------------------------------------------------------------+
| T     | **Run-time controls---**Deliver run-time controls to prevent |
| LJ-05 | "run-away" queries and to restrict very large data download  |
|       | requests.                                                    |
+-------+--------------------------------------------------------------+
| T     | **Graphical output---**Deliver the capability to display     |
| LJ-06 | graphical output on the desktop with dynamic report          |
|       | reformatting.                                                |
+-------+--------------------------------------------------------------+
| T     | **Drill-down---**Deliver an on-line "drill-down" capability  |
| LJ-07 | from summary amounts in queries to supporting detail         |
|       | records.                                                     |
+-------+--------------------------------------------------------------+
| T     | **Data downloading---**Deliver the capability to download    |
| LJ-08 | selected query data. Reformat downloaded query information   |
|       | for direct access by common desktop applications (e.g.,      |
|       | spreadsheet, ASCII text, "," delimited).                     |
+-------+--------------------------------------------------------------+
| T     | **Query/Report preview---**Deliver the capability to preview |
| LJ-09 | a query, form, report, or other result before printing.      |
+-------+--------------------------------------------------------------+
| T     | **Available data---**Deliver capability to access current    |
| LJ-10 | year and historical financial data.                          |
+-------+--------------------------------------------------------------+
| T     | **Ad hoc query interface---**Deliver the following ad hoc    |
| LJ-11 | query interface features:                                    |
|       |                                                              |
|       | > • Graphical display of data sources                        |
|       | >                                                            |
|       | > • The ability to "point and click" on selectable table,    |
|       | > data, and link objects for inclusion in a custom query,    |
|       | > and                                                        |
|       | >                                                            |
|       | > • An active data dictionary to provide users with object   |
|       | > definitions.                                               |
+-------+--------------------------------------------------------------+

##### Value-Added Requirements

To add value to the Ad Hoc Query functionality, the Core financial
system **[should]{.underline}** deliver the following:

  -------- --------------------------------------------------------------
  TLJ-12   **Query optimization---**Deliver the capability to optimize
           queries.

  TLJ-13   **Dashboard output---**Deliver a "dashboard" reporting
           capability that can be used to continuously display
           agency-defined performance metrics on a managers desktop
           (e.g., a graphical view of the agency's budget status).
  -------- --------------------------------------------------------------

## Documentation

It is not enough for a vendor to deliver a Core financial system and
help with installation. The documentation that comes with the product is
key to the effective and efficient use of the system and its appropriate
implementation and maintenance. The documentation submitted with the
software must be written at a sufficient level of detail that users who
are familiar with the Core system and its functions, but are new to the
product, can understand and use the documentation without assistance
from the vendor.

##### Mandatory Requirements

To meet Documentation requirements, the Core financial system
**[must]{.underline}** deliver the following:

+-------+--------------------------------------------------------------+
| T     | **Hardware and software---**Deliver documentation that       |
| LK-01 | identifies all software and hardware products needed by an   |
|       | agency to install, operate, access, and maintain the         |
|       | application. Delivered hardware and software documentation   |
|       | must specifically identify those products that are intended  |
|       | to be purchased or licensed as part of the product licensing |
|       | agreement, and those products needed to meet any technical   |
|       | and functional requirement that must be acquired separately  |
|       | by the agency.                                               |
+-------+--------------------------------------------------------------+
| T     | **Application design---**Deliver application design          |
| LK-02 | documentation. This documentation must include the           |
|       | following:                                                   |
|       |                                                              |
|       | > • Description of the application's design/architecture and |
|       | > integrated                                                 |
|       | >                                                            |
|       | > technologies                                               |
|       | >                                                            |
|       | > • Database specifications                                  |
|       | >                                                            |
|       | > • Data dictionary                                          |
|       | >                                                            |
|       | > • Entity relationship diagrams                             |
|       | >                                                            |
|       | > • Internal file record layouts                             |
|       | >                                                            |
|       | > • Cross references between internal files, database tables |
|       | > and data-entry screens                                     |
|       | >                                                            |
|       | > • Program module specifications including firmware and     |
|       | > program source code                                        |
|       | >                                                            |
|       | > • System flowcharts.                                       |
|       |                                                              |
|       | Application documentation must identify known problems       |
|       | (software bugs) and recommended work around.                 |
+-------+--------------------------------------------------------------+
| T     | **Software installation and maintenance---**Deliver product  |
| LK-03 | installation and maintenance documentation. Installation     |
|       | documentation must describe the following items:             |
|       |                                                              |
|       | > • Product release content                                  |
|       | >                                                            |
|       | > • Third party software configuration requirements          |
|       | >                                                            |
|       | > • Database installation steps                              |
|       | >                                                            |
|       | > • The directory structure for locating application data,   |
|       | > programs, files, tables including drive mappings           |
|       |                                                              |
|       | • Hardware driver installation and configuration             |
|       |                                                              |
|       | > • Application security set-up and maintenance              |
|       | >                                                            |
|       | > • Software configuration instructions                      |
|       | >                                                            |
|       | > • Operating parameter definitions and any other required   |
|       | > set-up data                                                |
|       | >                                                            |
|       | > • Software build instructions                              |
|       | >                                                            |
|       | > • Vendor supplied configuration tools                      |
|       | >                                                            |
|       | > • Interface processes to be installed                      |
|       | >                                                            |
|       | > • Startup scripts needed to initiate the software          |
|       | >                                                            |
|       | > • Test steps needed to verify correct installation.        |
+-------+--------------------------------------------------------------+
| T     | **User and operating documentation---**Deliver system        |
| LK-04 | operations and user manuals. Documentation must explain the  |
|       | following system operations:                                 |
|       |                                                              |
|       | > • System start-up\                                         |
|       | > • Shutdown\                                                |
|       | > • Monitoring\                                              |
|       | > • Recovery/re-start\                                       |
|       | > • Internal processing controls\                            |
|       | > • Archiving and application security.                      |
|       |                                                              |
|       | User documentation must explain in detail how to execute     |
|       | available functionality in each application component and    |
|       | must cover instructions for the following:                   |
|       |                                                              |
|       | > • Access procedures\                                       |
|       | > • User screen layout\                                      |
|       | > • Standard report layout and content\                      |
|       | > • Transaction entry\                                       |
|       | > • Workflow\                                                |
|       | > • Batch job initiation\                                    |
|       | > • GL and transaction maintenance\                          |
|       | > • Yearend processing\                                      |
|       | > • Error codes with descriptions\                           |
|       | > • Recovery steps\                                          |
|       | > • Trouble shooting procedures.                             |
+-------+--------------------------------------------------------------+
| T     | **Updated release specific documentation---**Deliver         |
| LK-05 | documentation updates concurrent with the distribution of    |
|       | new software releases. Release notes must clearly identify   |
|       | all changes made to the system's functionality, operation or |
|       | required computing hardware and software.                    |
+-------+--------------------------------------------------------------+

##### Value-Added Requirements

There are no value-added requirements in this category.

## System Performance

This section defines system performance categories that need to be
considered when evaluating packages for potential acquisition. These
requirements were written without specific (i.e., testable) performance
criteria. Recognizing that delivered package performance is dependent on
agency-supplied computing infrastructure and workload, agencies should
customize these requirements, adding their own unique criteria (e.g.,
number of concurrent users, geographic distribution of worksites, number
of transactions, processing windows, and volume of agency information
expected to be maintained online or archived).

##### Mandatory Requirements

+-------+--------------------------------------------------------------+
| T     | **Activity workload---**Process the agency's specified       |
| LL-01 | accounting workload without adversely impacting projected    |
|       | online response time.                                        |
+-------+--------------------------------------------------------------+
| T     | **Batch processing workload---**Process all scheduled work   |
| LL-02 | (e.g., batch jobs) within an agency specified processing     |
|       | window. Scheduled work can include:                          |
|       |                                                              |
|       | > • Daily systems assurance reports                          |
|       | >                                                            |
|       | > • Daily backups                                            |
|       | >                                                            |
|       | > • Daily interface processing                               |
|       | >                                                            |
|       | > • Core GL posting                                          |
|       | >                                                            |
|       | > • Table updates                                            |
|       | >                                                            |
|       | > • Standard reporting.                                      |
+-------+--------------------------------------------------------------+
| T     | **Data volume---**Maintain the agency's specified current    |
| LL-03 | and historical financial data (e.g. general ledger records,  |
|       | documents, transactions, lines, and vendor records) storage  |
|       | needs with no degradation to online or batch processing      |
|       | performance.                                                 |
+-------+--------------------------------------------------------------+
| T     | **Concurrent user access---**Support concurrent access to    |
| LL-04 | functional modules for the agency's specified user           |
|       | community.                                                   |
+-------+--------------------------------------------------------------+

##### Value-Added Requirements

To add value to the System Performance functionality, the Core financial
system **[should]{.underline}** deliver the following:

+-------+--------------------------------------------------------------+
| T     | **Performance metrics---**Deliver computing performance      |
| LL-05 | metrics for platforms and systems environments that the      |
|       | application is certified to run on. Performance metrics      |
|       | provided by the vendor should describe:                      |
|       |                                                              |
|       | > • Transaction processing throughput capacity,              |
|       | >                                                            |
|       | > • Expected workstation client response time by transaction |
|       | > type,\                                                     |
|       | > • Data storage capacity, and                               |
|       | >                                                            |
|       | > • Limitations on concurrent user connectivity.             |
+-------+--------------------------------------------------------------+

# Appendix A---References

## Introduction

This appendix lists governmentwide accounting standards, laws,
regulations, and other guidance that pertain to Core financial system
requirements. Reference categories are as follows:

-   Federal legislation

-   U.S. Code

-   Statements of Federal Financial Accounting Standards

-   Office of Management and Budget guidance

-   Treasury Financial Manual

-   Other Federal standards, guidelines, and regulations

-   Federal Financial Management System Requirements.

The list is not all-inclusive and may not include citations supporting
agency-specific or program-specific mandates. It is every agency's
responsibility to comply with the most current versions of applicable
laws, regulations and other guidance. In addition, it is important to
note that many requirements are based on common business need in
addition to a cited laws and regulations.

## Federal Legislation

Cash Management Improvement Act of 1990 (CMIA) (Pub. L. No. 101-453),
extended by the Cash Management Improvement Act Amendments of 1992 (Pub.
L. No. 102-589)

Chief Financial Officers Act of 1990 (Pub. L. No. 101-576)

Clinger-Cohen Act of 1996 (Information Technology Management Reform Act,
Division E of Pub. L. No. 104-106)

Computer Security Act of 1987 (Pub. L. No. 100-235)

Debt Collection Improvement Act of 1996 (Pub. L. No. 104-134)

Defense Authorization Act for FY1991 (Pub. L. No. 101-510, § 1405(a))
amended 31 U.S.C. subtitle II, ch. 15, subch. IV, Closing Accounts, §§
1551--1557,

Federal Financial Management Improvement Act of 1996 (Pub. L. No.
104-208)

Federal Managers' Financial Integrity Act of 1982 (Pub. L. No. 97-255)

Federal Records Act of 1950, as amended (Records Management by Federal
Agencies, 44 U.S.C. § 3101 et seq.)

Freedom of Information Act and Amendments of 1974 (Pub. L. No. 93-502)
(5 U.S.C. § 552)

Government Management Reform Act of 1994 (Pub. L. No. 103-356)

Government Paperwork Elimination Act of 1998 (Pub. L. No. 105-277)

Government Performance and Results Act of 1993 (Pub. L. No. 103-62)

Omnibus Reconciliation Act of 1993 (Pub. L. No. 103-66)

Paperwork Reduction Reauthorization Act of 1986 (Pub. L. No. 104-13)

Prompt Payment Act of 1982 and Amendments of 1996 (Pub. L. No. 97-177)

Rehabilitation Act Amendments of 1998 (Workforce Investment Act) (Pub.
L. No. 106-246)

Sarbanes-Oxley Act of 2002 (Pub. L. No. 107-204)

Internal Revenue Service Restructuring and Reform Act of 1998 (IRS RRA)\
(Pub. L. No. 105-206)

## U.S. Code

5 U.S.C. § 552 contains provisions of the Freedom of Information Act.

31 U.S.C. § 1301(a) (the "Purpose Statute") requires that monies be
expended only for the purposes for which appropriations were made.

31 U.S.C. §§ 1341, 1342, 1349--51, and 1511--19 (jointly referred to as
the "Anti-deficiency Act") prohibit obligating more money than an agency
has or before it gets the money, accepting voluntary services or monies
not specifically allowed by law, and obligating more money than has been
appropriated or allotted in a time period.

31 U.S.C. § 1501 (the "Recording Statute") requires that an obligation
be recorded when, and only when, it is supported by written evidence of
a binding agreement (an offer and its acceptance) for goods or services
for a purpose authorized in the appropriation.

31 U.S.C. § 1502 (a) (the "Bona Fide Needs Statute") requires that
obligations against an appropriation be limited to a specific time
period and that obligations be charged to the appropriation in force
when the obligation is made.

31 U.S.C. §§1551--1557 (Closed Accounts subchapter) contains the M-year
legislation which requires that all Federal agencies close fixed-year
appropriation accounts and cancel any remaining balances by September
30th of the 5th year after the period of availability began.

31 U.S.C. § 3302 (b) (the "Miscellaneous Receipts (Deposit) Statute")
requires that, except for trust funds and revolving funds, collected
monies from any source be deposited in the Treasury as soon as
practicable without deduction for any charge or claim.

31 U.S.C. § 3512 requires the head of each executive agency to establish
and maintain systems of accounting and internal control designed to
provide effective control over, and accountability for, all assets for
which the agency is responsible.

44 U.S.C. § 3101 addresses records management within Federal agencies.

5 CFR 1315 is the codification of former OMB Circular A-125, *Prompt
Payment*.

[]{.mark}

## Statements of Federal Financial Accounting Standards

SSFAS 1, *Statement of Federal Financial Accounting Concepts*

SFFAS 3, *Accounting for Inventory and Related Property*

SSFAS 4, *Managerial Cost Accounting Concepts and Standards*

SSFAS 5, *Accounting for Liabilities of the Federal Government*

SFFAS 7, *Accounting for Revenue and Other Financing Sources*

SSFAS 10, *Accounting for Internal Use Software*

## Office of Management and Budget Guidance

OMB Circular A‑11, *Preparation, Submission, and Execution of the
Budget*

OMB Circular A-25, *User Charges*

OMB Circular A-109, *Policies for Acquiring Major Systems*

OMB Circular A‑123, *Management Accountability and Control*

OMB Circular A‑127, *Financial Management Systems*

OMB Circular A‑130, *Management of Federal Information Resources*

OMB Circular A-134, *Financial Accounting Principles and Standards*

OMB Circular A-136, *Financial Reporting Requirements*

## Treasury Financial Manual

I TFM-2-3100, Instructions for Disbursing Officers' Reports

I TFM-2-3300, Reports of Agencies for which the Treasury Disburses

I TFM-2-4000, Federal Agencies' Centralized Trial-Balance System

I TFM-2-4100, Debt Management Reports

I TFM-6-5000, Administrative Accounting Systems Requirements

I TFM-6-8040, Disbursements

I TFM-6-8500, Cash Forecasting Requirements

## Other Federal Standards, Guidelines, and Regulations

Electronic and Information Technology Accessibility Standards (issued by
the Architectural and Transportation Barriers Compliance Board)

Federal regulations established by the [National Archives and Records
Administration](http://www.nara.gov/)

Federal regulations issued by the National Institute of Standards and
Technology

Rules related to payment formats issued by The Electronic Payments
Association (also called NACHA)

## Federal Financial Management System Requirements

*Framework for Federal Financial Management Systems*, January 1995

*Inventory, Supplies, and Materials System Requirements*, August 2003

*Revenue System Requirements Document*, January 2003

*Acquisition Financial System Requirements*, June 2002

*Core Financial System Requirements*, November 2001

*Benefit System Requirements*, September 2001

*Core Financial System Requirements*, February 1999

*Direct Loan System Requirements*, June 1999

*Grant Financial System Requirements*, June 2000

*Guaranteed Loan System Requirements*, March 2000

*Human Resources and Payroll System Requirements*, April 1999

*System Requirements for Managerial Cost Accounting*, February 1998

*Seized Property and Forfeited Assets System Requirements*, December
1999

*Travel System Requirements*, July 1999

*Managerial Cost Accounting Implementation Guide*, February 1998

*Property Management System Requirements*, October 2000

# Appendix B---Requirement Drafting Guidelines

Our goal is to publish a comprehensive set of functional requirements
that can be used by agencies and vendors in developing more effective
financial systems. To help ensure that our efforts produce consistent
and accurate requirement text, we have adopted drafting guidelines for
each type of requirement we deal with. The requirement types found in
this document are:

-   Configuration

-   Input

-   Process

-   Query

-   Report

-   Interface

-   Non-functional.

    Our drafting guidelines call for starting every requirement
    statement with a standard verb as defined in this appendix.
    Definitions of other key terms that could affect an agency's
    interpretation of individual requirements can be found in the
    Glossary. In reading each functional requirement, please assume the
    following opening statement:

    *"Deliver an automated capability to:"*

    A key objective in drafting this version of the requirements was to
    eliminate ambiguous phrasing such as "as applicable," "as
    appropriate," or "at a minimum."

    Examples, where included in requirement text, are not intended to be
    definitive. They are used only to help clarify the intent. Examples
    are identified with the lead-in phrase "for example" or "such as."

## Configuration Requirements

Configuration requirements describe functionality needed by an agency to
create tables, structures, codes, labels, access rights, and rules.

-   We use "**maintain**" when specifying functionality that will allow
    the agency to directly enter or import additions, changes, or
    deletions to system configuration or operating tables. For example:

> *Maintain a revenue source code structure.*

-   We use "**define**" when the intention of the requirement is to
    allow the agency to specify edits, business rules, workflows, code
    values, or other conditional processes. For example:

> *Define specific GL accounts as control accounts for purposes of
> tracking activity in subsidiary ledgers.*

-   We use "**customize**" when referring to the ability to allow the
    agency to enter and modify displayed field labels, report titles,
    column headings, or user interface settings. For example:

> *Customize dunning text displayed on system-generated bills.*

## Input Requirements

Input requirements describe how different types of information are to be
entered into the system. Input requirements cover individual data items
and documents.

-   We use "**associate**" when referring to establishing a relationship
    (i.e., link) between data records. Associations are normally created
    automatically by the underlying database software when new records
    are added. For example:

    *Associate transactions posted to the general ledger with an
    originating document.*

```{=html}
<!-- -->
```
-   We use "**capture**" when the intention of the requirement is to
    store new information or link other stored data to a new record.
    Captured data can be user entered or system generated. The ability
    to subsequently retrieve, modify, or delete captured information is
    assumed. For example:

    *Capture item description on each line of a commitment document, or,
    capture a system derived effective date.*

```{=html}
<!-- -->
```
-   We use "**classify**" when referring to capturing attributes that
    are subject to complex business rules. For example:

    *Classify ALCs as "Governmentwide Accounting" (GWA) System reporters
    or Non-GWA System reporters.*

```{=html}
<!-- -->
```
-   We use "**update**" when the intention of the requirement is to
    allow the agency to modify an existing data record. Updates can be
    agency entered online or generated from an imported transaction
    file.

    *Update posted transactions with the Treasury confirmed schedule,
    issue date, and assigned check number.*

## Process Requirements

Process requirements describe automated tasks performed on financial
data as entered into the system. Processes include validating data,
monitoring funds, notifying users, performing calculations, and
distributing costs. Because process requirements cover a wide range of
functionality, they are written using a variety of standard syntax
rules.

-   We use "**archive**" to specify functionality used to store
    processed, non-current data to a segregated storage area, subject to
    read access and retrieval. For example:

    *Archive closed commitment, obligation, receipt, and expenditure
    documents.*

-   We use "**calculate**" when referring to system functionality needed
    to compute a result based on a defined arithmetic formula. For
    example:

    *Calculate late payment interest charges, or calculate a due date.*

-   We use "**derive**" when referring to functionality the system uses
    in applying business rules. For example:

    *Derive the amount of upward or downward spending adjustment.*

-   We use "**distribute**" when referring to allotting funds or the
    assignment of accumulated costs. For example:

    *Distribute funds to subordinate organizations.*

-   We use "**generate**" when specifying requirements where the system
    must originate information. For example:

    *Generate an audit trail of all accounting classification structure
    additions, changes, and deletions.*

-   We use "**identify**" to refer to the flagging or lookup/retrieval
    of information based on an entered parameter or defined rule. For
    example:

    *Identify payments to be disbursed in a particular payment cycle.*

-   We use "**liquidate**" when the intent is to reduce or close a line
    item on a referenced document. For example:

    *Liquidate individual disbursement-in-transit transactions.*

-   We use "**monitor**" to refer to the comparison of an accumulated
    amount against an established limit. For example:

    *Monitor the use of funds. Prevent spending, warn or inform the
    agency when distributed authority is exceeded*.

-   We use "**notify**" when the requirement is for the system to issue
    an e-mail or other online message to inform the agency of a
    processing exception. For example:

    *Notify the agency when funds availability is reduced.*

    We use "**prevent**" when the system is required to stop a user from
    completing an entry or initiating a process. In some cases, actions
    that are prevented based on funds control or line item tolerance
    checks are subject to override. For example:

    *Prevent the recording of duplicate transactions.*

```{=html}
<!-- -->
```
-   We use "**process**" to refer to the system manipulation of captured
    data. Processing can involve multiple steps. Processing can be
    triggered by user request, job submission, or other internal system
    logic. For example:

    *Process suspended documents upon changes to funding data.*

-   We use "**record**" when referring to the posting of transactions
    into the general ledger or journal. "Record" is usually followed by
    an accounting term such as assets, liabilities, accounts payable,
    equity, revenue, expenses, interest, depreciation, amortization,
    collections, receipts, payments, commitments, obligations,
    expenditures, authority, or appropriations. For example:

    *Record a payment advance.*

```{=html}
<!-- -->
```
-   We use "**reference**" to refer to the association of document line
    items to prior document lines and their automatic liquidation. For
    example:

    *Reference multiple prior documents in a processing chain.*

-   We use "**suspend**" when requiring the system to place a document
    or other work item into a holding queue subject to later retrieval,
    correction, and completed processing. For example:

    *Suspend incomplete documents and those that fail edits (i.e., save
    for later retrieval and processing)*.

-   We use "**validate**" when requiring the system to confirm the
    validity of entered information against a defined business rule. For
    example:

    *Validate that a duplicate vendor number was not entered*.

## Query Requirements

Queries describe requirements for accessing system-maintained
information online. By default, query requirements must be satisfied
using real-time Core application screen displays. Some complex,
high-volume queries can optionally be satisfied using a separately
delivered business information query (BIQ) tool (e.g., data warehouse).
Unlike Core queries, BIQ queries are generally scripted, stored, and
queued for execution.

-   We use "**query**" to specify data selection, summarization, and
    display. For example:

    *Query related transactions. Parameters include any document number.
    Result is a list of general ledger transactions from all documents
    in the requested document's processing chain.*

-   We use "**parameters include**" to specify the selection criteria.
    When multiple parameters are listed, it is understood that one or
    any combination of the parameters are to be applied. Parameters
    should allow for selection of one value, a range of values, or all
    values. For example,

    *Parameters include beginning effective date, ending effective date,
    and TAS or internal fund code.*

-   We use "**drill down**" to specify functionality used to display
    detailed supporting entries for a query summarized record. For
    example:

> *Drill down from listed documents to document details.*

## Report Requirements

Report requirements describe system-generated outputs that are subject
to predefined form and content rules. Rules for external reports are
separately defined by the GAO, OMB, Treasury, or EOP. Internal report
requirements include the data to be listed or summarized as a part of
the requirements text.

-   We use "**generate a report**" to describe the agency's requirements
    for formatted output. For example:

    *Generate an Open Commitments and Obligations Report. Select
    documents based on any combination of accounting classification
    elements (e.g., open commitments and obligations by organization).
    List the document number, unliquidated amount, vendor, and
    accounting classification string of each reported document.*

-   We use "**output options include**" to specify sorting options or
    other special format requirements. Reports must be printable by
    default. Some reports can be designated as online and subject to
    additional drill-down. For example:

    *Output options include sorting and summarizing reported data by
    fund or organization code.*

## Interface Requirements

Interface requirements define the need to exchange data with another
internal agency or an external governmentwide system. An example of an
internal interface is the requirement for an acquisition system to
generate transactions needed to establish commitments in the Core
system. An example of an external interface is the requirement for the
Core system to generate a payment file suitable for transmission to
Treasury's ECS.

-   We use "**import**" when requiring the system to receive and process
    data originated in another financial or mixed system. For example:

> *Import collection files from banks for application to open
> receivable, or import CCR updates.*

-   We use "**export**" when the intention of the requirement is to
    generate and send a transaction file to another system for
    processing. For example:

> *Export plan information at the line item level.*

## Non-Functional Requirements

Non-functional requirements are used to reference standards, rules, or
policies maintained by others to be incorporated into a delivered
system. Non-functional requirements are used throughout the technical
area.

-   We use "**comply**" with a defined external standard. For example:

    *Comply with Workflow Management Coalition (WFMC) Workflow
    Standard--Interoperability.*

```{=html}
<!-- -->
```
-   We use "**deliver**" to specify non-functional features that must be
    included as part of the baseline product. For example:

    *Deliver user, system, and operating documentation.*

-   We use "**support**" for requirements that reference a defined
    government policy. For example:

    *Support CCR rules for coding business type.*

-   We use "**incorporate**" to specify principles and best practices
    that should be reflected in a delivered package For example:

    *Incorporate open-systems architecture.*

-   We use "**operate**" to specify computing environments in which a
    package should or must be designed to run. For example:

    *Operate in a server computing environment running under UNIX, LINX,
    Windows Server 2000 or above.*

    *.*

# Appendix C---Standard Core Financial System Reports 

+-------------+------------+-----------+--------+---------+----------+
| **Title     | *          | **Level** | **B    | **Freq  | **Guid   |
| (Form)**    | *Purpose** |           | asis** | uency** | elines** |
+=============+============+===========+========+=========+==========+
| Report on   | Report     | TAS       | Mo     | On      | OMB      |
| Budget      | status of  |           | dified | demand  | C        |
| Execution   | budgetary  |           | Cash   |         | ircular\ |
| and         | resources  |           |        |         | A-11     |
| Budgetary   |            |           |        |         |          |
| Resources   |            |           |        |         |          |
| (SF 133)    |            |           |        |         |          |
+-------------+------------+-----------+--------+---------+----------+
| Federal     | Report     | Approp    | A      | Qu      | I        |
| Agencies    | data for   | riation/\ | ccrual | arterly | TF       |
| Centralized | con        | Fund      |        |         | M-2-4000 |
| Trial       | solidation | Group     |        |         |          |
| Balance     | from FACTS |           |        |         |          |
| System      | I into the |           |        |         |          |
| (FACTS I)   | Financial  |           |        |         |          |
|             | Report of  |           |        |         |          |
|             | the U.S.   |           |        |         |          |
|             | Government |           |        |         |          |
+-------------+------------+-----------+--------+---------+----------+
| Federal     | Report     | Approp    | A      | Qu      | Current  |
| Agencies    | status of  | riation/\ | ccrual | arterly | TFM U.S. |
| Centralized | budgetary  | Fund      |        |         | SGL      |
| Trial-      | resources  | Account   |        |         | Su       |
| Balance     |            |           |        |         | pplement |
| System      |            |           |        |         |          |
| (FACTS II)  |            |           |        |         | FACTS II |
|             |            |           |        |         | Client   |
|             |            |           |        |         | Bulk     |
|             |            |           |        |         | User's   |
|             |            |           |        |         | Guide    |
+-------------+------------+-----------+--------+---------+----------+
| Treasury    | Provide    | Approp    | A      | Qu      | I        |
| Report on   | i          | riation/\ | ccrual | arterly | TF       |
| Receivables | nformation | Fund      |        |         | M-2-4100 |
| (TROR)      | on the     | Account   |        |         |          |
|             | status of  | (but can  |        |         |          |
|             | public     | vary)     |        |         |          |
|             | r          |           |        |         |          |
|             | eceivables |           |        |         |          |
|             | and        |           |        |         |          |
|             | del        |           |        |         |          |
|             | inquencies |           |        |         |          |
+-------------+------------+-----------+--------+---------+----------+
| Statement   | Report     | Agency    | Cash   | Monthly | I        |
| of          | dis        | Location  |        |         | TF       |
| Tr          | bursements | Code by   |        |         | M-2-3300 |
| ansactions\ | co         | Approp    |        |         |          |
| (FMS-224,   | llections, | riation/\ |        |         |          |
| FMS-P224)   | and status | Fund      |        |         |          |
|             | of         | Account   |        |         |          |
|             | c          |           |        |         |          |
|             | ollections |           |        |         |          |
+-------------+------------+-----------+--------+---------+----------+
| Report of   | Provide an | Agency    | Cash   | Monthly | I        |
| Acco        | analysis   | Location  |        |         | TF       |
| untability\ | of         | Code and  |        |         | M-2-3100 |
| (FMS-1219)  | disbursing | D         |        |         |          |
|             | officers'  | isbursing |        |         |          |
|             | activities | Officer   |        |         |          |
|             | in         |           |        |         |          |
|             | agencies   |           |        |         |          |
|             | that do    |           |        |         |          |
|             | not do     |           |        |         |          |
|             | their own  |           |        |         |          |
|             | disbursing |           |        |         |          |
+-------------+------------+-----------+--------+---------+----------+
| Statement   | Report     | Agency    | Cash   | Monthly | I        |
| of          | dis        | Location  |        |         | TF       |
| Tr          | bursements | Code and  |        |         | M-2-3100 |
| ansactions\ | and        | Approp    |        |         |          |
| (FMS-1220)  | c          | riation/\ |        |         |          |
|             | ollections | Fund      |        |         |          |
|             | in         | Account   |        |         |          |
|             | agencies   |           |        |         |          |
|             | that do    |           |        |         |          |
|             | their own  |           |        |         |          |
|             | disbursing |           |        |         |          |
|             | (the       |           |        |         |          |
|             | c          |           |        |         |          |
|             | ounterpart |           |        |         |          |
|             | to         |           |        |         |          |
|             | FMS-224)   |           |        |         |          |
+-------------+------------+-----------+--------+---------+----------+
| Information | Provide    | Taxpayer  | Cash   | A       | IRS      |
| Returns:    | i          | Ident     |        | nnually | inst     |
| (IRS        | nformation | ification |        |         | ructions |
| 109         | to the IRS | Number    |        |         | for      |
| 9-C,1099-G, | on         |           |        |         | forms    |
| 1099-MISC)  | payments   |           |        |         | 1099,    |
|             | made or    |           |        |         | 1098,    |
|             | debts      |           |        |         | 5498,    |
|             | forgiven   |           |        |         | and W-2G |
+-------------+------------+-----------+--------+---------+----------+
| Balance     | Disclose   | D         | A      | > Qu    | OMB      |
| Sheet       | statement  | epartment | ccrual | arterly | bulletin |
|             | of assets, |           |        |         | on form  |
|             | li         |           |        |         | and      |
|             | abilities, |           |        |         | content  |
|             | and net    |           |        |         |          |
|             | position   |           |        |         |          |
+-------------+------------+-----------+--------+---------+----------+
| Statement   | Report     | > D       | A      | > Qu    | OMB      |
| of Net Cost | gross      | epartment | ccrual | arterly | bulletin |
|             | costs less |           |        |         | on form  |
|             | revenue    |           |        |         | and      |
|             | earned     |           |        |         | content  |
+-------------+------------+-----------+--------+---------+----------+
| Statement   | Report     | > D       | A      | > Qu    | OMB      |
| of Changes  | financing  | epartment | ccrual | arterly | bulletin |
| in Net      | sources,   |           |        |         | on form  |
| Position    | gains, and |           |        |         | and      |
|             | losses     |           |        |         | content  |
+-------------+------------+-----------+--------+---------+----------+
| Statement   | Report     | > D       | Obliga | > Qu    | OMB      |
| of          | available  | epartment | tion/\ | arterly | bulletin |
| Budgetary   | budgetary  |           | A      |         | on form  |
| Resources   | resources  |           | ccrual |         | and      |
|             | and status |           |        |         | content  |
+-------------+------------+-----------+--------+---------+----------+
| Statement   | Report on  | > D       | A      | > Qu    | OMB      |
| of          | reco       | epartment | ccrual | arterly | bulletin |
| Financing   | nciliation |           |        |         | on form  |
|             | between    |           |        |         | and      |
|             | p          |           |        |         | content  |
|             | roprietary |           |        |         |          |
|             | and        |           |        |         |          |
|             | budgetary  |           |        |         |          |
|             | accounts   |           |        |         |          |
+-------------+------------+-----------+--------+---------+----------+
| Statement   | Report     | > D       | A      | > Qu    | OMB      |
| of          | no         | epartment | ccrual | arterly | bulletin |
| Custodial   | n-exchange |           |        |         | on form  |
| Activity    | revenue    |           |        |         | and      |
|             |            |           |        |         | content  |
+-------------+------------+-----------+--------+---------+----------+
|             |            |           |        |         |          |
+-------------+------------+-----------+--------+---------+----------+

# Appendix D---Contributors

## Office of Management and Budget

### Office of Federal Financial Management

> Daniel Werfel
>
> Wayne Leiss
>
> Bill Apgar
>
> Hans Heidenreich

## Agency for International Development

> Steve Crabtree

## Corporation for National and Community Service

> Adam Liu
>
> Pete Rudman

## Department of Commerce

> Robert Bair
>
> Patricia Jackson
>
> Karen McBride
>
> James L. Taylor
>
> Lynn Wilson

### Patent and Trademark Office

> Michelle Picard
>
> Gita Zoks

## Department of Agriculture

> Kay Levy
>
> Pauline Myrick
>
> Jon Sandy
>
> Wendy Snow

## Department of Defense

> Mark Doehnert

### Defense Finance Accounting Service

> Tom Prince

### Defense Logistics Agency

> Jim Olaughlin

## Department of Education

Mark Carney

Angela Butler

## Department of Energy

> Deanna Ammons
>
> Linda Denoff
>
> Ed Golden
>
> Warren Huffer

### Bonneville Power Administration

> David Rubin

### National Nuclear Security Administration

> Eileen Rountree-McLennan

## Department of Health and Human Services

> Scott Brna
>
> Bill Brown
>
> Steve Cohen
>
> Eric Houser
>
> Dennis Loveless
>
> Ed Martin
>
> Margie Yanchuk
>
> Matt Zakiefarz

## Department of Homeland Security

> Gerald Ross
>
> James Mich

## Department of Justice

> Mark Busby
>
> Jeffrey Cadman
>
> Brad Callery
>
> Ken Klaus
>
> Darryl Lawson
>
> Robert Mathews
>
> Dana Rosensweig
>
> Sonal Vashi

## Department of Labor

> Pat Clark
>
> Ed Winkler

## Department of State

> Sally Zottnick

#### **Department of the Interior**

> Monica Taylor Lane

## Department of the Treasury

> Elois Adair
>
> Tajuan Brown
>
> Robert Deans
>
> David Epstein
>
> JoJo Ferguson
>
> Robin Gilliam
>
> Betty Harvey
>
> Jeff Hoge
>
> Wally Ingram
>
> Margaret Kaeser
>
> Patrick Mezzetta
>
> Matthew Miller
>
> Larry Rosenberg
>
> Judy Yuran

### Internal Revenue Service

> Mark Dale
>
> David Hensley
>
> Kathleen Miller
>
> Jack Roziner
>
> Chuck Sarahan
>
> Thuan Truong

### Office of the Comptroller of the Currency

> Sandra Butler
>
> Carolyn Horlor
>
> Angela Williams

## Department of Veterans Affairs

> Lorraine Grant
>
> Pete Mulhern
>
> Bill Walsh

## Environmental Protection Agency

> Sue Arnold
>
> Lisa Ayala
>
> Judi Brown
>
> Larry Burnham
>
> Valerie Chun
>
> Joe Dillon
>
> Juanita M. Galbreath
>
> Heidi Gross
>
> Terry Ouverson
>
> Martin Poch
>
> Charles Young

## Federal Communications Commission

> Tim Taylor

## General Services Administration

> Ameer R. Alzer
>
> Timothy Burke
>
> Lloyd Cherry
>
> Ed Cox
>
> Kenneth A. Dressner
>
> Jan Fulk
>
> Douglas A. Glenn
>
> Ed Gramp
>
> Terry Gricher
>
> David Hollar
>
> David Horn
>
> Lynne Johnson
>
> Peter Kapsales
>
> Fang Li
>
> Tim Long
>
> Ray Najib
>
> Ellen Pierzchala
>
> John W. Potocko
>
> Mark Sayr
>
> Dennis Schroff
>
> Dave Straka
>
> Anh Tang
>
> Kent Taylor
>
> Norma Tolson
>
> Kevin Young

## Government Accountability Office

> Yang Hahn
>
> Thomas Placentrat

## Department of Housing and Urban Development

> Gail B. Dise
>
> Mary L. Kohlmeier
>
> Linda Rodgers
>
> Tammy Smutney
>
> Tom Stein

## National Aeronautics and Space Administration

> Chuck Calhoun
>
> Charlene Williams

## National Science Foundation

> Ed Miller
>
> Jannell Rennie
>
> Preston Rich

## Nuclear Regulatory Commission

> Russell Allwein

## Office of Personnel Management

> Gisele Jones
>
> Jim Loiselle
>
> Gerald Thomas
>
> Dorran Thompson

## Social Security Administration

> Thomas J. Bianco

## Financial Systems Integration Office (Formerly JFMIP)

> Doris Chew, Acting Director
>
> Dennis Mitchell
>
> Stephen Balsam
>
> Steven Fisher

## Program Office Support (LMI)

> Ronald Rhodes
>
> Duane Whitt
>
> Mike Allen
>
> Rob Capozzi
>
> Kathy Crampton
>
> Debra Dunn
>
> Loan Nguyen
>
> Carol Pickens
>
> Maureen Stratford
>
> Milissa Young-Loiselle