Word

Core Financial System Requirements Contents

CONTENTS

Foreword ii

Executive Summary 1

Background Information 3Chapter 1 Introduction 4

Chapter 2 The Core Financial System and How It Relates to Other Financial Systems 6

Chapter 3 Core Financial System Requirements and How They Relate to Other Standards and Artifacts 8

Requirements 11Chapter 4 General Ledger Management Function 12

Chapter 5 Reporting Management Function 18

Chapter 6 Funds Management Function 26

Chapter 7 Payment Management Function 36

Chapter 8 Receivable Management Function 51

Chapter 9 Cost Management Function 60

Chapter 10 Fund Balance with Treasury Management Function 64

Chapter 11 System Management Function 69

Chapter 12 Reimbursable Management Function 81

Chapter 13 Technical Capability Function 85

Appendices 98

Appendix A Changes to Core Financial System Requirements 99

Appendix B Accounting Standards, Laws, Regulations, and Other Guidance 100

Appendix C Requirement Drafting Guidelines 107

Appendix D List of Reports 114

Appendix E Glossary 119

Appendix F Abbreviations 135

Tables

Table 1. Requirement Introductory Phrases 107

Figures

Figure 1. Primary Capabilities of a Core Financial System 6

Figure 2. Agency Systems Supporting Financial Management Functions 7

Exposure Draft July 2009 i

Core Financial System Requirements Contents

Exposure Draft July 2009 ii

Core Financial System Requirements Foreword

FOREWORD

The January 9, 2009, update to Office of Management and Budget Circular No. A-127 introduced a requirement for agencies to use a certified configuration of commercial off-the-shelf financial management software. The Financial Systems Integration Office (FSIO) is responsible for defining governmentwide core financial system requirements, certifying the standard configuration for each software product, and assessing agency use of that configuration.

The starting point for establishing a standard configuration has been the development of standards for processes and data. Specifically, FSIO has been working with agencies to develop the following:

Standard Federal financial business processes, which are designed to standardize and streamline financial business activities common to all Federal agencies. The document describing these processes includes functional process flow diagrams, step descriptions, and business rules. FSIO has defined processes for funds management, payment management, receivable management, reports management, and reimbursable management.

Common Government-wide Accounting Classification (CGAC) structure, which establishes a standard for classifying the financial effects of government business activities to be used by all Federal agencies. The CGAC document includes standard names, definitions, and formats for the classification elements.

Each software product vendor will define a standard Federal configuration of its product that supports the standard Federal financial business processes and the use of the CGAC structure. To meet its responsibilities for certifying a standard configuration of each software product, FSIO is revising the approach from a single requirements document and testing materials to a suite of artifacts based on the standards for processes and data. Each artifact has a particular focus and a unique function. These artifacts will include the following:

Core financial system requirements (presented in this document), which describe the system functions needed by a Federal agency to support uniquely Federal financial management needs. Each requirement is a statement of a need, identifying what Federal agencies need from a core financial system to perform Federal financial management operations.

Use cases, which provide the system event flow and desired outcomes for process threads of the standard business processes. Use cases provide context for requirements to explain how they are interrelated. They provide a “flow” view of Federal financial management needs. Each use case references one or more requirement statements. FSIO’s strategy is to develop use cases for the most critical and complex process threads.

Core Financial System Requirements Foreword

Functional design specifications, which describe system functionality needed to support automated threads of the standard business processes. Functional design specifications provide detail about how the system is expected to perform within the business context described by a use case and in a manner consistent with the requirements. The functional design specifications will establish a baseline standard configuration for each core financial management software product against which it can be assessed and certified. This is the level at which compliance can be monitored.

Data exchange specifications, which provide the data and file formats, source and target data mappings, data translations, and data flows needed to achieve interoperability with governmentwide systems. This document is important for establishing a standard configuration because the certified configuration needs to include interfaces with Treasury and other governmentwide systems.

In addition to these artifacts, FSIO maintains the qualification test policy and test materials used in certifying that software products meet Federal requirements.

This document—Core Financial System Requirements—is an exposure draft containing updated core financial system requirements. The financial management community is encouraged to provide comments on this exposure draft using the instructions provided at www.fsio.gov.

Dianne CopelandDirector, Financial Systems Integration Office

http://www.fsio.gov/

Core Financial System Requirements Executive Summary

EXECUTIVE SUMMARY

The requirements in this document describe what is needed by a Federal agency from a core financial management system to provide uniquely Federal financial management services. These requirements result from a complex set of regulations and guidance for Federal financial management. The requirements are intended to do the following:

Organize Federal financial management regulations and guidance into logical categories that correspond to system functions or capability components

Relate Federal financial management business needs to system functions

Describe expected outcomes from system processes.

A core financial system is defined in Office of Management and Budget Circular No. A-127, Financial Management Systems, as

an information system that may perform all financial functions including general ledger management, funds management, payment management, receivable management, and cost management. The core financial system is the system of record that maintains all transactions resulting from financial events. It may be integrated through a common database or interfaced electronically to meet defined data and processing requirements. The core financial system is specifically used for collecting, processing, maintaining, transmitting, and reporting data regarding financial events. Other uses include supporting financial planning, budgeting activities, and preparing financial statements.

This exposure draft is part of a set of documents maintained by the Financial Systems Integration Office (FSIO) to establish Federal financial management standards. Among other key documents in the set are Standard Federal Financial Business Processes and Common Government-wide Accounting Classification Structure.

This version of Core Financial System Requirements reflects changes to the requirements to align them with the standard Federal financial business processes, to remove budget formulation requirements and value-added requirements, and to reorganize requirements into more logical groupings. Other changes are identified in Appendix A, Changes to Core Financial System Requirements.

This document has three major sections.

The background information section defines what a core financial system is and how it fits in the overall Federal financial management system environment, and it describes how this document relates to other FSIO documents.

Core Financial System Requirements Executive Summary

The requirements section presents the core financial system requirements grouped by function and subfunction. This section also includes an overview of each function and subfunction.

The appendices describe the reasons changes were made to this edition of the requirements; list governmentwide accounting standards, laws, regulations, and other guidance pertaining to core financial systems; define terms used in drafting requirements; list standard reports; provide a glossary of terms; and define abbreviations.

Core Financial System Requirements Background Information

BACKGROUND INFORMATION

Core Financial System Requirements Introduction

1 INTRODUCTION

1.1 THE NEED FOR FEDERAL FINANCIAL MANAGEMENT SYSTEM REQUIREMENTS

Financial management in the Federal government must comply with various laws, regulations, guidance, and standards contained in a number of publications. Among these publications are Office of Management and Budget (OMB) circulars, the Treasury Financial Manual (TFM), and the standards published by the Federal Accounting Standards Advisory Board (FASAB). FSIO also publishes standard Federal business processes for government-wide implementation.

To comply with Federal financial management standards and regulations, Federal agencies require specific financial system capabilities. This document identifies those capabilities as system requirements. The system requirements in this document represent the system capabilities and functionality needed by a Federal agency to comply with Federal financial management regulations, guidance, and standards. Specifically, the requirements in this document do the following:

Organize Federal financial management regulations and guidance into logical categories that correspond to system functions or capability components

Relate Federal financial management business needs to system functions

Describe expected outcomes from system processes.

Requirements are expressed in general terms, such as “generate a report,” “process a document,” or “validate that funds are available.” These requirements are not intended to represent a complete system specification. They do not, for example, specify computing logic needed to generate a report, process a document, or perform validations. These requirements are also not intended to establish accounting policy or procedures.

1.2 USE OF ABBREVIATIONS

In the introductory narrative sections, abbreviations for common financial terms and names (e.g., TFM and FASAB) are spelled out in the first instance of their occurrence. The convention of spelling out the first instance of a term is not followed within the requirements. The use of only abbreviations within the requirements (e.g., USSGL, CCR, and DUNS) is done intentionally because the requirements are not always presented in the sequence used in this document. Appendix F lists the abbreviations used in this document.

Core Financial System Requirements Introduction

1.3 ORGANIZATION

The remainder of this document is organized as follows:

Background information

Chapter 2, “The Core Financial System and How It Relates to Other Financial Systems,” defines what a core financial system is and how it fits in the overall Federal financial management system environment.

Chapter 3, “Core Financial System Requirements and How They Relate to Other Standards and Artifacts,” describes the standards and artifacts being developed to support the definition of a standard configuration.

Requirements

Chapters 4 through 13 present requirements by function, subfunction, and, in some cases, by activity. Functions represent major responsibility areas such as accounts payable. Subfunctions are common system-supported tasks such as disbursing. Activities are further divisions of subfunctions and are used when a finer grouping of requirements is helpful.

Appendices

Appendix A describes the reasons changes were made to requirements in this edition.

Appendix B lists governmentwide accounting standards, laws, regulations, and other guidance that pertain to core financial systems.

Appendix C contains detailed guidance on interpreting requirement text and attributes, and it defines the terms used in drafting requirements.

Appendix D lists reports included in the Reporting Management chapter of Standard Federal Financial Business Processes.

Appendix E is a glossary of terms used in requirements.

Appendix F defines the abbreviations used in this document.

As a companion to this document, the requirements are also published in a spreadsheet. The spreadsheet does not include the introductory narrative text, but it may be easier for agencies, software product vendors, or system implementers to use as part of their own configuration management processes.

Core Financial System Requirements The Core Financial System and How It Relates to Other Financial Systems

2 THE CORE FINANCIAL SYSTEM AND HOW IT RELATES TO OTHER FINANCIAL SYSTEMS

A core financial system is one element within the Federal financial management environment. This section defines “core financial system” and describes its relationships to other financial systems within an agency and within the Federal government.

2.1 CORE FINANCIAL SYSTEM

A core financial system is defined in OMB Circular No. A-127, Financial Management Systems, as

an information system that may perform all financial functions including general ledger management, funds management, payment management, receivable management, and cost management. The core financial system is the system of record that maintains all transactions resulting from financial events. It may be integrated through a common database or interfaced electronically to meet defined data and processing requirements. The core financial system is specifically used for collecting, processing, maintaining, transmitting, and reporting data regarding financial events. Other uses include supporting financial planning, budgeting activities, and preparing financial statements.

Figure 1 depicts the capabilities of a core financial system. These capabilities may be tightly integrated as a single system or may be standalone systems with information transferred among them.

Figure 1. Primary Capabilities of a Core Financial System

Core Financial System Requirements The Core Financial System and How It Relates to Other Financial Systems

2.2 RELATIONSHIP OF CORE TO OTHER AGENCY FINANCIAL SYSTEMS

The core financial system exchanges data with other financial and mixed systems1 that are necessary to support financial management. These systems, together with the core financial system, make up an agency’s financial management system. Figure 2 illustrates the relationship of core and other financial and mixed systems within an agency.

Figure 2. Agency Systems Supporting Financial Management Functions

2.3 RELATIONSHIP OF CORE TO GOVERNMENTWIDE SYSTEMS

Governmentwide systems provide centralized support for common business transaction processes and consolidated reporting. The primary governmentwide financial systems are maintained by Treasury and OMB.

A core financial system may interface with governmentwide systems either to complete a business transaction or to provide data for reporting. As examples, the core financial system does the following:

Provides authorized payment transactions to Treasury so that Treasury can make the payments

Provides general ledger account balances to Treasury for compilation into governmentwide financial statements

Receives vendor payee information from Central Contractor Registration (CCR).

1 An agency system that supports both financial and nonfinancial functions is referred to as a “mixed” system.

Core Financial System Requirements Core Financial System Requirements and How They Relate to Other Standards and Artifacts

3 CORE FINANCIAL SYSTEM REQUIREMENTS

AND HOW THEY RELATE TO OTHER STANDARDS AND ARTIFACTS

The January 9, 2009, update to OMB Circular No. A-127 introduced a requirement for agencies to use a certified configuration of commercial off-the-shelf financial management software. FSIO is responsible for defining governmentwide core financial system requirements, certifying the standard configuration for each software product, and assessing agency use of that configuration. This chapter describes the standards and artifacts being developed to support the definition of a standard configuration.

3.1 GOVERNMENTWIDE BUSINESS STANDARDS

The starting point for establishing a standard configuration has been the development of standards for processes and data. Specifically, FSIO has been working with agencies to develop the following:

Standard Federal financial business processes, which are designed to standardize and streamline financial business activities common to all Federal agencies. FSIO has defined processes for funds management, payment management, receivable management, reports management, and reimbursable management. The standard processes form the basis for defining the functions a core financial system must support. The processes are presented in Standard Federal Financial Business Processes. That document includes functional process flow diagrams, step descriptions, and business rules.

The standard processes correlate to the common business processes and subfunctions described in the process layer of the Federal Transition Framework (FTF) catalog, which is used to inform enterprise architecture programs. The standard business processes also directly align with the subfunctions of the Federal Enterprise Architecture (FEA)2 Business Reference Model for the financial management domain.

Common Governmentwide Accounting Classification (CGAC) structure, which establishes a standard for classifying the financial effects of government business activities to be used by all Federal agencies. As a result, the classification structure for the certified configuration can be defined. The CGAC document includes standard names, definitions, and formats for the classification elements.

2 For information about the Federal Enterprise Architecture, see http://www.whitehouse.gov/omb/e-gov/fea/


The CGAC set of data elements is among the first Federal financial management domain data sets to be standardized. Standardized Federal financial management domain data are captured in the FTF data layer. Additional work is under way to define data exchanged with the core financial system. Related information exchange packages will be identified and entered into the FTF catalog. Federal financial management domain data are being identified and stewarded in a manner consistent with the FEA Data Reference Model.

Financial management guidance from OMB, Treasury, and FASAB, itemized in Appendix B, is translated into these standards for processes and data. These efforts facilitate increasing standardization of core financial systems. Each financial system vendor will be able to define a standard Federal configuration of its product that supports the standard processes and uses the CGAC structure.

3.2 CORE FINANCIAL SYSTEM ARTIFACTS

To meet its responsibilities for establishing a certified configuration of each software product, FSIO is revising the approach from a single requirements document to a suite of artifacts based on the standards for processes and data. Each artifact has a particular focus and a unique function. The core financial system artifacts are based on information identified in the FTF catalog in a manner consistent with the guidance provided in the FEA reference models.

The artifacts will include the following:

Core financial system requirements, which describe the system functions needed by a Federal agency to support uniquely Federal financial management needs. Each requirement (presented in this document) is a statement of need, identifying what Federal agencies need from a core financial system to perform Federal financial management operations.

Use cases, which provide the system event flow and desired outcomes for process threads of the standard business processes. Use cases provide context for requirements to explain how they are interrelated. They provide a “flow” view of Federal financial management needs. Each use case references one or more requirement statements. FSIO’s strategy is to develop use cases for the most critical and complex process threads.

Use cases will provide software product vendors with the context necessary to design product enhancements before FSIO issues testing materials. Previously, only the testing materials provided context for the requirements.

Functional design specifications, which describe standard system functionality needed to support automated threads of the standard business processes. Functional design specifications provide detail about how the system is expected to perform within the business context described by a use case and in a manner consistent with the requirements.


The functional design specifications will establish a baseline standard configuration for each core financial management software product against which it can be assessed and certified. This is the level at which compliance can be monitored.

Data exchange specifications, which provide the data and file formats, source and target data mappings, data translations, and data flows needed to achieve interoperability with governmentwide systems. These specifications are important for establishing a standard configuration because the certified configuration needs to include interfaces with Treasury and other governmentwide systems.

3.3 REQUIREMENTS FOR MIXED SYSTEMS

For many agencies, financial events originate in mixed systems that interface with the core financial system. The Federal Financial Management System Requirements (FFMSR) series published by FSIO (originally by the Joint Financial Management Improvement Program, or JFMIP, staff) defines an overall framework and requirements for mixed systems.

The foundation document of the FFMSR series is Framework for Federal Financial Management Systems,3 which sets forth the vision, desired capabilities, performance outcomes, environment, and other attributes that all Federal financial management systems must be designed to support. This document also illustrates an integrated financial management infrastructure that financial applications must be designed to support, and it provides a broader context for understanding and interpreting the system requirements published by FSIO.

Core Financial System Requirements is one of the documents in the FFMSR series of governmentwide functional requirements. Other documents in the FFMSR series prescribe the capabilities to be provided by mixed financial management systems. For example, one document defines requirements for each mixed system in Figure 2.

Developed with the consensus of financial and program stakeholders and based on laws, regulations, and standards, each FFMSR document is organized around processes and financial event processing that support various mission and program delivery functions. Together, the FFMSR series of documents provides a common framework that supports compatible financial event processing and sharing of information between a core financial system and the various program delivery financial systems within an agency. Appendix B lists the documents in the FFMSR series.

3 Joint Financial Management Improvement Program, Framework for Federal Financial Management Systems, JFMIP-SR-01-04, April 2004.

Core Financial System Requirements Requirements

REQUIREMENTS

Core Financial System Requirements General Ledger Management Function

1 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 be able to maintain account balances at three conceptual levels. First, it must summarize and maintain account balances at the U.S. Standard General Ledger (USSGL) account and attribute level. Second, 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. Third, an agency may choose to classify financial data at a lower level by establishing general ledger subaccounts or agency-specific accounting classification elements 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 subfunctions:

General ledger account definition (GLA)

Transaction definition (GLB)

General ledger updating and editing (GLC)

Upward/downward spending adjustment (GLD)

Accounting period maintenance and closing (GLF).

1.1 GENERAL LEDGER ACCOUNT DEFINITION SUBFUNCTION

The USSGL is defined in a supplement to the TFM, which includes the chart of accounts, account descriptions and postings, accounting transactions, USSGL attributes, and cross-walks to standard external reports. Each agency must implement a chart of accounts that is consistent with the USSGL, but may supplement it with agency-specific accounts (to meet agency-specific information needs) as long as they summarize to the USSGL accounts for external reporting purposes.


GLA-01 The system must maintain a chart of accounts consistent with the USSGL chart of accounts, including the proprietary, budgetary, and memorandum accounts; basic numbering structure; and account titles.

GLA-02 The system must maintain an association between the chart of accounts and valid USSGL attribute domain values used in Treasury systems (e.g., FACTS I, FACTS II, GFRS, and GTAS).

GLA-03 The system must track subsidiary ledger activity attributable to specific general ledger accounts known as control accounts.

GLA-04 The system must provide the capability to establish agency-specific USSGL account extensions that summarize to USSGL accounts.

GLA-06 The system must provide the capability to establish agency-specific memorandum accounts in the chart of accounts within the 800000 to 900000 series range.

GLA-07 The system must allow a qualified end user to add, change, or deactivate accounts in the chart of accounts without requiring support from a programmer or application developer.

GLA-08 The system must allow a qualified end user to add, change, or deactivate USSGL attribute domain values in order to accommodate changes in Treasury systems (e.g., FACTS I, FACTS II, GFRS, and GTAS) without requiring support from a programmer or application developer.

GLA-09 The system must deliver the core financial system software prepopulated with the current published values for the USSGL chart of accounts.

GLA-10 The system must deliver the core financial system software prepopulated with the current published USSGL account attribute values used in Treasury systems (e.g., FACTS I, FACTS II, GFRS, and GTAS).

1.2 TRANSACTION DEFINITION SUBFUNCTION

Each time an approved transaction is recorded in the core financial system, the appropriate general ledger accounts for posting the transaction must be identified according to the rules defined in the USSGL guidance. To accomplish consistent and accurate posting, the core financial system must provide the capability to define standard transactions and business rules for use in recording like accounting events. Standard transactions must comply with USSGL posting rules and include budgetary, proprietary, and memorandum accounts, as applicable.

GLB-01 The system must provide automated functionality that records like accounting events consistently using standard transactions.


GLB-02 The system must allow a qualified end user to establish the general ledger account postings used in a standard transaction.

GLB-03 The system must allow a qualified end user to establish standard transactions that include proprietary, budgetary, and memorandum accounts.

GLB-04 The system must allow a qualified end user to establish standard transactions that reflect the accepted and/or approved posting models established by the Treasury USSGL (or other accounting authority, when not addressed by Treasury).

GLB-05 The system must allow a qualified end user to establish business rules or conditions that are used to determine the correct general ledger postings. These rules or conditions may include any accounting classification structure data element.

GLB-06 The system must allow a qualified end user to establish business rules that require, prohibit, or default accounting classification data elements for a particular general ledger account.

GLB-07 The system must provide the capability to establish multiple debit and credit pairs of general ledger accounts within a single standard transaction.

GLB-08 The system must update document balances and related tables (e.g., available funding) upon recording standard transactions.

1.3 GENERAL LEDGER UPDATING AND EDITING SUBFUNCTION

To ensure the consistency and completeness of financial records, this subfunction 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 to be 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.

GLC-01 The system must update all applicable general ledger account balances (budgetary, proprietary, and memorandum accounts) simultaneously in a single process as part of a single input transaction event.

GLC-02 The system must provide the capability to capture or derive USSGL account attributes used to classify accounting transactions for reporting to Treasury systems (e.g., FACTS I, FACTS II, GFRS, or GTAS).

GLC-03 The system must validate USSGL account attributes on transactions (whether entered or derived) prior to the posting.


GLC-04 The system must prevent transactions from posting that would cause a trial balance to become out of balance (i.e., debits must equal credits) at the internal fund level and at the accounting classification level of formal funds control.

GLC-05 The system must prevent transactions from posting that would cause general ledger debits and credits to be out of balance within the budgetary, proprietary, or memorandum accounts (i.e., budgetary, proprietary, and memorandum accounts must each be self-balancing within a single transaction).

GLC-06 The system must prevent transactions from posting that would cause the general ledger control accounts to be out of balance with the financial transaction activity of any subsidiary ledger.

GLC-07 The system must prevent transactions from posting to general ledger accounts that have been deactivated.

1.4 UPWARD/DOWNWARD SPENDING ADJUSTMENT SUBFUNCTION

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

GLD-01 The system must provide automated functionality that derives and records the amount of upward or downward spending adjustments upon liquidating, canceling, or modifying the dollar amount of prior-year obligations or expenditures, and it must record the spending adjustment at the time of posting the transaction which generated it.

GLD-02 The system must reverse the original spending adjustment entries and generate new spending adjustments for the correct amounts, when correcting documents that previously generated spending adjustment entries.

GLD-03 The system must provide automated functionality that determines if upward and downward spending adjustments are to expired or to unexpired budget authority and uses that determination to derive and record the USSGL-prescribed spending adjustment entry.

GLD-04 The system must provide automated functionality that determines if anticipated recoveries have been previously recorded and, when recording a downward spending adjustment, uses that determination to derive the USSGL-prescribed spending adjustment entry.


GLD-05 The system must provide automated functionality that determines if upward and downward adjustments are to paid or to unpaid obligations and/or expenditures and uses that determination to derive and record the USSGL-prescribed spending adjustment entry.

GLD-06 The system must provide automated functionality that determines if upward and downward adjustments are to delivered or to undelivered orders and uses that determination to derive and record the USSGL-prescribed spending adjustment entry.

GLD-07 The system must allow a qualified end user to record previously unrecorded obligations to prior-year budget authority or expired budget authority and must generate the related upward spending adjustments in the current year.

GLD-08 The system must identify when posting transactions will invoke upward spending adjustments and apply the agency-defined funds control edits.

1.5 ACCOUNTING PERIOD MAINTENANCE AND CLOSING SUBFUNCTION

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

GLF-01 The system must maintain a minimum of 15 accounting periods per fiscal year, with the option to designate the following:

One period for recording opening balances

Twelve periods for recording monthly activity

Two additional periods for year-end preclosing and closing entries.

GLF-02 The system must provide the capability to record transactions to any open accounting period and must provide the option to keep multiple accounting periods (minimum of two) open simultaneously.

GLF-03 The system must provide the automated capability to close accounting periods and prevent the posting of new transactions to any closed period.

GLF-04 The system must provide the automated capability to reopen closed accounting periods and record transactions to them.


GLF-05 The system must provide automated functionality to execute a year-end closing process that records USSGL-prescribed preclosing and closing entries in accounting periods separate from other accounting periods.

GLF-06 The system must provide the capability to perform multiple simulated closings in a trial/test mode so that users can review the closing results, clear the closing entries, and rerun the closing process. This functionality must be available for both preclosing entries and closing entries.

GLF-07 The system must provide automated capability to generate trial balances that support the review of the closing process run in trial/test mode.

GLF-08 The system must provide the capability to record transactions to the current and prior fiscal year (i.e., until the closing process is complete).

GLF-09 The system must provide automated functionality that determines an accounting period’s opening balances based on the prior accounting period’s closing balances at the USSGL attribute level. The opening general ledger account balances must maintain the USSGL attribute information required to satisfy Treasury system reporting requirements (e.g., FACTS I, FACTS II, GFRS, and GTAS).

GLF-10 The system must provide the automated capability to make fiscal year-dependent master data from a prior year available at the start of a new fiscal year (e.g., rollover, roll forward, or update master data tables).

GLF-11 The system must provide the automated capability to make internal fund codes used for a prior funding origination year, and any attributes related to the internal fund codes, available in the next fiscal year.

GLF-13 The system must provide automated functionality that groups general ledger account balances by public law number for the purpose of preparing Treasury adjusted trial balance reports (e.g., FACTS II).

Core Financial System Requirements Reporting Management Function

2 REPORTING MANAGEMENT FUNCTION

Financial management reporting functionality ensures that agencies will have the tools necessary to monitor the input, output, and operation of the core financial system and related mixed systems, as well as to produce basic data for use by both the agency and central reporting entities, such as OMB and Treasury. Because some reporting requirements can be resource intensive, care must be exercised when determining data identification, organization, and maintenance requirements, so that both reporting and transaction processing can be satisfied. The term “reports” as used in this chapter refers to all system outputs independent of the output format (hard copy, email, electronic file, or online).

The Reports Management chapter of Standard Federal Financial Business Processes groups reports into seven reporting categories:

Financial statements. Financial reporting in the Federal government must be in accordance with the Chief Financial Officers Act of 1990 (CFO Act) and the Government Management Reform Act of 1994 (GMRA). In addition, the Office of Federal Financial Management (OFFM) specifies, in OMB Circular No. A-136, the required elements and format of financial reports.

General ledger. General ledger reports provide information on overall account balances and transactions supporting those account balances for an organization.

Payment management. Payment management reports provide information to support vendor maintenance, invoice tracking, disbursement monitoring, cash flow control, and cash management decisions.

Receivable management. Receivable management reports provide information to support customer maintenance, receivable tracking, collections, delinquent account monitoring, and effective cash flow management.

Reimbursable management. Reimbursable management reports provide information to support reimbursable activity between trading partners, including partnership agreements, work in process, and billing.

System management. System management reports provide information that enables the effective control of user access, traceability of modified transactions, and override of established system controls.

Treasury reporting. Treasury reports provide information to meet Federally mandated reporting requirements and to


support the management of the Fund Balance with Treasury (FBWT) and funds held outside of Treasury.

Appendix D lists the standard reports described in Standard Federal Financial Business Processes.

2.1 REPORTING FUNCTIONALITY

The Reports Management chapter in Standard Federal Financial Business Processes describes reporting functionality that may be required of the certified configuration of each FSIO-qualified software product. In general, each product should have the capability to do the following:

Provide a user interface that allows users to identify report selection, sorting options, data retrieval parameters, run times and frequency of reports.

Allow users to schedule reports to run at predefined times or on demand.

Allow users to schedule reports to run on a recurring basis (e.g., daily, weekly, monthly).

Identify the primary and secondary sorting options identified in the Standard Federal Financial Business Processes Reports Management chapter as default or preferred sorting criteria for each individual report.

Provide users with a list of data elements included in a report and allow users to select or identify primary and secondary sorting criteria by report. User selections may differ from the preferred sorting criteria discussed above.

Prevent the selection or identification of free-text elements, such as comment fields, as a sorting option.

Allow users to select or identify accounting classification elements as data retrieval parameters. Accounting classification elements are specified in the document on the CGAC structure, which categorizes financial information as required to support financial management and reporting functions.

Allow users to select or identify ranges of values for data retrieval parameters (e.g., USSGL accounts between 4701 and 4902).

Allow users to define the period covered by the report; the period may be defined using an as-of date, beginning and ending dates, or an accounting period (e.g., daily, weekly, monthly, and yearly).

Allow a report to be printed multiple times from a single report request.


At the user’s discretion, be maintained for future use; parameters associated with the report request must also be maintained.

Contain report headings, including, at a minimum, report name, date and time run, and any parameters used, such as period or accounting classification elements, to define or stratify the data contained in the report.

Allow for subtotals and totals as appropriate for the report; calculated values such as these should allow for amounts into the trillions ($999,999,999,999,999.99).

Be viewable on screen.

Allow users to view (or drill down to) detailed data and transactions supporting values, amounts, documents, calculated totals, account balances, and categories (e.g., aging, payables, and receivables).

Allow users to export report data to third-party software, such as Microsoft Excel.

Allow users at their discretion to print all or any portion of a report.

Be maintained and downloadable for a period specified by the agency.

Include calculated values in exported data to facilitate use with third-party software.

Be available in both report and data formats.

Report format, the printed version of the report, including headers, footers, and column headings, may be provided in paper and/or electronic media.

Data format providing the data contained in the report—not the headings, footers, or column headings—will typically be provided in an ASCII text, comma-delimited, XML, or other similar format.

Be provided from stored data elements, or derived based upon multiple data elements and system tables/profiles.

Include Personally Identifiable Information (PII), such as Employer Identification Number (EIN), Federal Taxpayer Identification Number (TIN), and banking information. Any use or display of PII must conform with the provisions of OMB Memorandum 07-16, “Safeguarding Against and Responding to the Breach of Personally Identifiable Information,” which in general requires PII to be “masked” on reports unless certain conditions are met.


The reporting requirements and report specifications will be completed after the Reports Management chapter of Standard Federal Financial Business Processes is finalized.

2.2 REQUIREMENTS

Below are the core financial system requirements that support the reporting functionality.

TLL-02 The system must process scheduled work (e.g., batch jobs) within an agency-specified batch-processing window. Scheduled work can include the following:

Daily systems assurance reports

Daily backups

Daily interface processing

General ledger transaction posting

Table updates

Standard reporting.

TLJ-11 The system must deliver the following ad hoc query interface features:

Graphical display of data sources

Ability to point and click on selectable table, data, and link objects for inclusion in a custom query

Active data dictionary to provide users with object definitions.

TLJ-09 The system must provide the capability to preview a query, form, report, or other result before printing.

TLJ-03 The system must process submitted queries and queue output online for access by authorized users.

TLJ-02 The system must provide the capability to define parameter-based query scripts that can be queued for execution, stored for reuse, and shared with other authorized agency users.

TLJ-01 The system must deliver an integrated ad hoc query capability to support agency access to and analysis of system-maintained financial data.


TLI-09 The system must deliver an event logging capability for systems, transactions, tables, and system parameters. The logs must include the following information:

User ID

System date

Time

Type of activity (addition, modification, deletion)

Old value

New value.

For example, the system must provide a log of all attempts to log on to the system or track changes to the prompt pay interest rate value.

TLI-01 The system must deliver a process scheduling capability that allows the agency to define, initiate, monitor, and stop system processes (e.g., online availability, batch jobs, and system maintenance).

TLH-02 The system must ensure that the management, operations, and technical baseline security controls are implemented in accordance with current FIPS 199, Standards for Security Categorization of Federal Information and Information Systems, and other current NIST guidance on selecting the appropriate security controls.

TLH-03 The system must deliver the capability to control function access (e.g., system modules, transactions, and approval authorities) and data access (create, read, update, delete) by assigned attribute:

User ID

Functional role (e.g., payable technician)

Organization.

The system also must enable the agency to define access rules based on any combination of these attributes.

TLH-04 The system must consistently enforce the appropriate security controls in all modules, including software used for ad hoc data query/report generators.

TLH-05 The system must provide the capability to restrict access to sensitive data elements, such as social security numbers, banking information by user ID, assigned role, or organization.

TLG-04 The system must support secure Internet access to the integrated ad hoc data query facility.

TLD-09 The system must provide the capability to parse XML.


TLA-04 The 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, PDF, MS Word, Excel, ASCII, or delimited text file. If an output format is not specified within a requirement, the requested information must be viewable to the agency online, using the API.

SME-03 The system must provide automated functionality to query document additions, modifications, and cancellations using query parameters, including the following:

User ID

Document number

Document type

Change type (addition, modification, cancelation)

Transaction date range

Accounting period.

Query results must include all parameter values, document numbers, and date and time stamps.

SMC-12 The system must provide automated report, drill-down, and query capabilities for documents. The selection parameters must include any one or a combination of the following:

Document type

Document status (e.g., open, closed)

Payee identifier

Payee DUNS+4 number

Customer identifier

Accounting classification elements.

Result must be a list of selected document numbers with document statuses and balances at the document level. The result must include drill-down from document lines to accounting lines and then to the related detailed general ledger transactions.

RPB-06 The system must provide the automated capability to query document accounting data using query parameters that must include all standard and agency-defined accounting classification elements. Result is a list of selected document accounting lines that display the document number, accounting classification elements, and accounting line amounts. The system also must enable drill-down from accounting lines to general ledger transaction details, including transaction numbers, transaction and system dates, and debits and credits.


RPC-01 The system must provide the automated capability to query the payee information maintenance file using query parameters, including the following:

Payee identifier

Payee name (legal)

Payee name (DBA)

Payee name (division)

Payee TIN

DUNS number

IRS 1099 indicator.

The result must display all payee data for the specified payee. Output options include an Excel-formatted data file.

TLJ-08 The system must deliver the capability to download selected query data and to reformat downloaded query information for direct access by common desktop applications (e.g., spreadsheet, ASCII text, and comma-delimited text).

RPB-10 The system must provide automated functionality to generate a status of funds report for each allotment recorded by the agency using accounting period and one or more other accounting classification elements as parameters. The report must display the following information for each allotment recorded by the agency:

Accounting classification elements

Total allotment

Commitments

Obligations

Upward adjustments

Expenditures

Available balance.

The system must ensure that the available balance equals the general ledger balance in the 4610, 4620, or 4650 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.


RPG-03 The system must provide automated functionality that generates an FMS 224 transaction detail report using accounting period as a parameter. The report must list the detailed transactions supporting each TAS total reported in each section of the FMS 224. Detailed transactions must include the following:

ALC

TAS

Transaction amount

Confirmation date

Transaction document number or Treasury document number.

The report must provide separate report totals for disbursement and receipt activity by ALC and TAS.

Core Financial System Requirements Funds Management Function

3 FUNDS 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 budgetary resources. Federal appropriations law, U.S. Comptroller General Decisions, and OMB Circular No. A-11, Preparation, Submission, and Execution of the Budget, constitute authoritative guidance and set governmentwide policy for funds management.

To comply with OMB Circular No. A-11, each agency of the Federal government is responsible for establishing a system for ensuring that it does not obligate or disburse funds in excess of those appropriated or authorized. The funds 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 funds management function must support agency policies on internal fund distribution and control.

Processes used by agencies to manage funds have been defined as governmentwide standard business processes.4 The system requirements in this document reflect the system functions required to support the standard processes.

An agency will likely have many other systems in addition to the core financial system that affect funds. 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 funds management function consists of the following subfunctions:

Financial, operating, and spending plan development (FMA)

Budget authority (FMC)

Funds distribution (FMD)

Funds control (FME).

4 Standard Business Processes, Section 2, “Funds Management Processes,” November 2008.


3.1 FINANCIAL, OPERATING, AND SPENDING PLAN DEVELOPMENT SUBFUNCTION

Financial, operating, and spending plans are blueprints for using financial resources during any given fiscal period or series of periods. Agencies differentiate between “financial,” “operating,” and “spending” plans based on different levels of detail, different fiscal periods covered, or other variables. OMB uses the term “plan” as follows: “The Budget of the United States Government sets forth the President’s comprehensive financial plan for allocation of resources for the Federal Government” and “Before agencies can use the resources, OMB must approve their spending plans.”5

FMA-02 The system must provide the capability to capture data related to financial, operating, and spending plans for any funded organization level or any other level of the accounting classification structure for the purposes of creating and maintaining lower level distributions of funds.

FMA-03 The system must provide the capability to maintain financial, operating, and spending plans by month, quarter, and year.

FMA-04 The system must provide the automated capability to export financial, operating, and spending plan data at the accounting line level in an Excel or ASCII text delimited file format.

FMA-10 The system must provide the capability to allow a user to compare planned spending to actual spending and to calculate variances in terms of dollar amounts and quantities (e.g., FTEs).

FMA-11 The system must provide the capability to import details of the appropriated budget.

FMA-12 The system must provide the capability to modify spending plan data.

FMA-13 The system must provide the capability to export execution-year spending plan data, actual spending, and variances at the line item level in an Excel or ASCII text delimited file format for dollar amounts and quantities.

3.2 BUDGET AUTHORITY SUBFUNCTION

Establishing budget authority is the beginning of the budget execution process. This subfunction records budget authority by the type of authority and apportions budget authority in accordance with the latest OMB-approved SF 132 Apportionment and Reapportionment Schedule. Recording and apportioning of budget authority establish legal limitations on the availability of funds and set the foundation for subsequent distribution of budgetary resources into amounts available for obligation and

5 President’s Budget, Analytical Perspectives, Chapter 26, “The Budget System and Concepts.”


expenditure for a particular organization, purpose, or type of expenditure. This subfunction also includes the recording of reductions in budget authority, such as the rescission of funds.

The standard Federal financial business processes supported by this subfunction are as follows:

FM 2.1 Budget Authority Process

FM 2.1.1 Budgetary Resources

FM 2.1.2 Record Application of Budgetary Resources (Apportionment).

FMC-01 The system must record funding based on related budget execution documents (e.g., appropriation warrants and apportionments).

FMC-03 The system must record budget authority (defined in OMB Circular No. A-11), including direct appropriations, borrowing authority, contract authority, and spending authority from offsetting collections.

FMC-05 The system must record changes to budget authority, including reductions, rescissions, amounts withheld or made unavailable, supplemental appropriations, transfers, reprogramming, and legal limitations.

FMC-07 The system must record budget authority from continuing resolutions.

FMC-08 The system must capture the start and end dates, amount, and public law number of a continuing resolution.

FMC-09 The system must provide the capability to amend continuing resolutions, or to record new follow-on continuing resolutions that supersede an existing continuing resolution, and must capture the new values of the continuing resolution, including start and end dates and public law number.

FMC-11 The system must record the realization of previously anticipated reimbursable authority upon recognition of an unfilled customer order, when an advance is not required. In these cases, the amount of funds made available must equal the amount of the unfilled customer order.

FMC-12 The system must record the realization of actual reimbursable authority only upon receipt of an advance from a non-Federal source unless a law specifically allows realization of reimbursable authority without an advance. When an advance is required, the amount of funds made available must equal the amount of the advance received.

FMC-13 The system must record apportioned funds in accordance with the latest OMB-approved SF 132 Apportionment and Reapportionment Schedule.


FMC-14 The system must record anticipated budget authority, including anticipated reimbursements, collections, and recoveries.

FMC-15 The system must provide the capability to prevent reductions in budget authority (e.g., reversals, rescissions, withdrawals, and transfers) from exceeding the dollar amount of budget authority distributed and unobligated at any level of the accounting classification.

FMC-16 The system must provide the capability to decommit and deobligate balances of budget authority so that reductions in budget authority can occur up to the unexpended balance (such as in the case of rescissions).

FMC-17 The system must provide automated functionality that determines the status (unexpired, expired, or canceled) of each internal fund from the start and end dates of the associated TAS at the time of posting a transaction, viewing information about a fund (e.g., master data), or running a report.

FMC-19 The system must prevent use of anticipated budgetary resources (e.g., prior-year recoveries, offsetting collections) until they are realized, apportioned, and available for use. The amount of funds made available must equal the amount realized.

FMC-20 The system must provide the capability to establish validity periods for apportionments and reapportionments for all apportionment categories to determine whether funds are available for allotment and consumption.

3.3 FUNDS DISTRIBUTION SUBFUNCTION

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


FM 2.2 Funds Distribution

FM 2.2.1 Allotment Distribution

FM 2.2.1.1 Allotment for (Direct) Non-Anticipated, Non-Reimbursable Funding

FM 2.2.1.2 Allotment for Anticipated Reimbursable Funding


FM 2.2.1.3 Allotment for Anticipated Non-Reimbursable Funding

FM 2.2.2 Sub-Allotment Distribution

FM 2.2.3 Lower Level Distribution.

FMD-01 The system must provide the capability to capture legal (statutory) and administrative (agency-imposed) limitations on the use of funds.

FMD-02 The system must record allotments and suballotments (i.e., distribute funds) to any level in the accounting classification structure.

FMD-03 The system must record up to eight levels of funds distribution, including levels used for appropriation and apportionment of budget authority.

FMD-04 The system must prevent distributions of budget authority, including apportionments, allotments, suballotments, and lower level distributions, from exceeding the amount of funds available at the next highest level of budgetary resources.

FMD-05 The system must allow modifications to both formal and informal funding distributions at any level in the accounting classification.

FMD-06 The system must record the withdrawal (or cancellation) of unobligated allotments, suballotments (both expired and unexpired), and lower level distributions by one or more accounting classification elements (parameters) at the end of a fiscal period or on demand as in rescissions.

FMD-13 The system must provide automated functionality that extracts and loads budget planning and formulation data to and from the core financial system.

FMD-14 The system must provide the capability to distribute funds below the level at which they are controlled.

FMD-15 The system must provide the capability to establish validity periods for allotments and suballotments to determine whether funds are available for further distribution and consumption.


3.4 FUNDS CONTROL SUBFUNCTION

Funds control prevents the obligation and expenditure of funds in excess of the amount of funds made available through the apportionment and funds distribution subfunction. The core financial system must be designed to apply effective funds control at the point that spending documents are entered. This subfunction consists of the following 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 commitments (e.g., requisitions). Commitments allow the agency to “reserve” funds before legal obligations are established. A commitment is a useful funds control tool, but is not appropriate for all spending situations. When an agency determines that the use of commitments is appropriate, the core financial system must provide the capability to apply funds control as defined in this document.

Obligations. This activity records obligations in the core financial system. OMB Circular No. A-11 defines an obligation 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 of obligations include purchase orders, travel orders, and delivery orders.

Advances. This activity records advance payments to others by the agency. Advance payments are amounts of money prepaid for the later receipt of goods, services, or other assets. For example, payment for all or any part of the estimated cost of work could be made to a provider filling the order in advance of receipt of the goods or services. Later, the advance payment is adjusted based on the actual cost of goods or services provided.


FM 2.3 Funds Control Process

FM 2.3.1 Establishing Commitments and Obligations for Goods and Services

FM 2.3.2 Establishing Obligations Not Requiring Commitment

FM 2.3.3 Funds Check Prior to Obligation

FM 2.3.4 Unexpired Funds Validation and Verification

FM 2.3.5 Expired Funds Validation and Verification.


FME-01 The system must monitor the availability of funds at each level of the accounting classification structure for which budget authority is distributed and controlled and, when attempting to process a spending document that exceeds the budget authority available, must issue a rejection or warning, by accounting line, to the user.

FME-02 The system must process spending documents that affect the availability and/or status of funds, including commitments, obligations, and expenditures.

FME-03 The system must provide the capability to record spending transactions, including commitments, obligations, advances, and expenditures, at or below the level of funds distribution.

FME-04 The system must provide the capability to record transactions against prior-year funds, both expired and unexpired, in the current year.

FME-05 The system must monitor amounts paid out of current-year funds to cover obligations made against a canceled account; and it must 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-10 The system must determine whether funds are available (i.e., unexpired, expired, or canceled) based on the budget fiscal year on a spending document.

FME-11 The system must prevent the allotment and reuse of prior-year deobligated balances in expired funds from being obligated in the current year.

FME-12 The system must update balances used for funds control to reflect changes in the status and amounts of commitments, obligations, expenditures, and available balances.

FME-13 The system must provide the automated capability to monitor the use of funds against financial, operating, and spending plans.

FME-14 The system must provide the automated capability to monitor the use of funds against legal (statutory) and administrative (agency-imposed) limitations (e.g., use of funds against a specific object class limitation).

FME-16 The system must provide the automated capability to monitor spending against the amount of reimbursable authority available in a given reimbursable agreement.

FME-17 The system must reduce the amount of reimbursable authority available as customer orders are filled.


FME-18 The system must prevent the use of funds in excess of the authorized amount available for reimbursable agreements, BPAs, contracts, work orders, task orders, and grants.

FME-19 The system must provide the capability to capture a suggested vendor identifier on commitment documents.

FME-20 The system must provide automated functionality that closes commitment documents and document lines under the following circumstances:

By the system upon final obligation

By an authorized user

As part of the year-end preclosing process.

FME-21 The system must provide the capability to capture, on obligating documents, any data elements that support or facilitate subsequent spending chain activity, including the following data elements:

Payment terms (e.g., accelerated payment terms, discount terms)

Matching terms (two-way, three-way, four-way)

Vendor identifier

Vendor name (legal, DBA, or division)

Vendor DUNS (BPN) number

DUNS+4 number

Source system

Source system document number

Approval date

Third-party payee identifier

Award date.

FME-22 The system must provide the capability to allow a qualified end user to establish and maintain agency-specific obligation types to identify the activity that initiated the obligation such as a travel order, purchase order, grant award, task order, work order, or BPA call.

FME-23 The system must ensure that the CCR vendor information stored on the obligating document matches the updated CCR vendor information stored on the vendor file (i.e., recently refreshed with data from CCR) when an obligation is submitted for final approval.

FME-24 The system must provide the capability to record obligations when there is no related commitment.

FME-25 The system must provide the capability to allow a change to the vendor name on an obligating document, even after the vendor name was directly inherited from the commitment document.


FME-26 The system must provide automated functionality that closes obligation documents and document lines when an authorized user indicates that a payment is final.

FME-27 The system must process, track, and control records of calls against BPAs.

FME-28 The system must process, track, and control delivery orders against contract limitations.

FME-29 The system must record advance payments, such as travel advances, contract prepayments, and grant advances. When recording an advance payment, the system must reference an obligating document and inherit all accounting classification structure information from the obligation to the advance.

FME-31 The system must record expenditures incurred against advance payments, reducing the advance balance and liquidating the referenced obligation.

FME-32 The system must provide the capability to capture, on obligating documents, any data elements that support or facilitate funds control, invoicing, or receipt of goods or services, including the following data elements:

Requester’s name

Telephone number of requester

Deliver-to location (e.g., room number, division)

Contact name

COTR name

COTR telephone number

Comments.

FME-35 The system must provide the capability to prevent advance payments under contracts from exceeding a specific percentage of the total obligation (e.g., 15%) prior to any performance under the contract.

FME-36 The system must provide the capability to capture payment terms on obligations that are different than those specified on the associated vendor record.

FME-39 The system must provide control features that ensure consistency between the amounts reflected in the funds control structure and the related general ledger account balances at the end of each update cycle. The update cycle must be no greater than 24 hours.

FME-40 The system must track the balance advanced against an obligation.

Core Financial System Requirements Payment Management Function

4 PAYMENT MANAGEMENT FUNCTION

The payment management function consists of processes associated with receiving goods or services that result in a payable, recording payment requests received from vendors, and disbursing payments. The processes used by an agency to manage payments to vendors have been defined as governmentwide standard business processes.6 The system requirements in this document reflect the system functions required to support the standard processes.

Depending on an agency’s system architecture, payment activities may be supported by other systems that provide payment data to the core financial system. For example, payroll systems usually trigger actual disbursements to employees through direct deposit or by check and maintain the detailed information related to those disbursements. The payroll system sends only the expense and disbursement information to the core financial system for recording the impact on the general ledger, funds availability balances, and cost management functions. 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 may 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 subfunctions:

Payee information maintenance (PMA)

Accounts payable (PMB)

Payment request (PMC)

Disbursing (PMD)

Payment follow-up (PME).

4.1 PAYEE INFORMATION MAINTENANCE SUBFUNCTION

The term “payee” is used here to refer to any entity (Federal or non-Federal) to which disbursements may be made. Payee information maintenance includes maintenance of master data for payees such as commercial vendors (individuals and organizations

6 Standard Federal Financial Business Processes, July 2008.


providing goods or services), employees, grant recipients, loan recipients, and other government agencies.

Subpart 4.11 of the Federal Acquisition Regulation (FAR) prescribes policies and procedures for requiring contractor registration in the CCR, the common source of payee information for commercial vendors in the Federal government. FAR requires that prospective contractors be registered in the CCR prior to award of a contract or agreement by the Federal government. The CCR validates the vendors’ information and electronically shares the data with the agency finance offices to facilitate paperless payments through electronic funds transfer (EFT). The core financial system must accommodate the data elements and definitions used in the CCR to facilitate this information exchange and to maintain current information on vendors.

Federal agencies that buy or sell goods or services to other Federal agencies must use a Business Partner Network (BPN) identifier and register their BPN numbers in the FedReg.7 The FedReg is a repository of Federal agency data pertinent to procurement and payment for services and products. Buy and sell transactions between Federal agencies will eventually be fed through a central exchange system. The FedReg will feed this exchange system, attaching information about each trading partner to each transaction.8 The core financial system must accommodate the data elements used in the FedReg.

In addition, the core financial management system must maintain information on other types of payees such as employees, grantees, and loan recipients.

PMA-01 The system must provide the capability to establish and maintain information about non-Federal vendors (payees), which, at a minimum, must include the following:

Vendor identifier (agency assigned)

Vendor name (legal)

Vendor name (DBA)

Vendor name (division)

Vendor physical address (street address 1 and 2, city, state, zip+4, country)

Business type (as defined in CCR rules for business types: small business, woman-owned business, etc.)

Organization type (as defined in CCR rules for organization types: non-Federal government organization, corporate entity, sole proprietorship, partnership, etc.)

TIN (IRS assigned)

DUNS (BPN) number (D&B-assigned)

DUNS+4 number (for each instance of banking

7 TFM Bulletin 2007-03, “Intragovernmental Business Rules,” October 31, 2007.8 Federal Agency Register (FedReg) Software User Manual (SUM), Version 5.0, October 28,

2008.


information at same physical location)

CAGE code (agency assigned)

CCR registration indicator (required or exempt)

CCR registration status (active or expired)

PSCs

NAICS codes

Prompt Pay indicator and type, or payment terms

Credit card vendor indicator

Default payment method (EFT, check)

Alternate payment methods (EFT, check)

Four remittance addresses, for check payments (street address 1 and 2, city, state, zip+4, and country)

POC information (name, telephone number, fax number, and email address) for each remittance address

Four instances of EFT banking information (ABA routing number, account number; and account type, i.e., checking or savings)

Four instances of EFT bank name

POC information (name, telephone number, fax number, and email address) for each instance of EFT banking information, accommodating contact types defined as mandatory in CCR business rules

IRS Form 1099 indicator

IRS Form W-2 indicator

Comment field

Active/Inactive indicator

Debarment indicator

Debarment start and end dates.

PMA-02 The system must maintain information for multiple third-party payees associated with a primary vendor, which, at a minimum must include the following:

Payee name

Payee POC

Payee telephone number

Payee email address

Remittance address or banking information (account number, account type, RTN).

PMA-03 The system must provide automated functionality that links payee and customer records that represent the same entity.


PMA-04 The system must interface vendor data from CCR no less frequently than daily.

PMA-06 The system must prevent unauthorized users from manually updating CCR-originated data in the payee information file.

PMA-07 The system must provide the capability to allow a user to establish multiple DUNS numbers for the same legal entity, even if two or more DUNS numbers reference the same TIN.

PMA-08 The system must provide the automated capability to link multiple DUNS+4 numbers to a single DUNS number.

PMA-09 The system must provide the automated capability to associate each combination of the DUNS and DUNS+4 numbers with one and only one bank account for each CCR vendor.

PMA-10 The system must identify an attempt to input a duplicate TIN for a new vendor record and must provide an immediate warning message to the user when the duplication is identified.

PMA-12 The system must maintain a history of changes made to payee information, which, at a minimum, must include the following:

Name of data item changed

Before and after values

Entry date and time

ID of user who made the change.

PMA-14 The system must provide the capability to deactivate payees on demand or based on agency-specified length of time with no activity.

PMA-15 The system must provide the capability to prevent the deactivation of payees that have unliquidated obligations or unpaid payment requests in the system.

PMA-16 The system must provide the capability to prevent new obligations that reference inactive or debarred payees.

PMA-17 The system must provide the capability to prevent new obligations and payments to vendors with expired CCR registrations.

PMA-19 The system must provide the capability to allow a user to define payment methods as EFT, check, IPAC, or interfund transfer.

PMA-20 The system must provide the automated capability to default payments to a third-party payee specified on the payee information maintenance table and/or to automatically override the default value with the third-party payee designated on the obligation.


PMA-21 The system must provide automated functionality that redirects payments from the payee to a legally mandated third-party payee until redirection is no longer required.

PMA-23 The system must maintain vendor data from CCR, which requires fully supporting all CCR data formats. For example, system data types must be consistent with CCR data types, and system field lengths must be equal to or greater than CCR field lengths.

PMA-25 The system must provide the automated capability to generate a report identifying payee records that may be eligible for deactivation, based on the payee record satisfying one of the following criteria:

Expiration of agency-specified period of time with no activity

No outstanding balance in the agency’s ledger for commitments, obligations, disbursements in transit, accounts payable, accounts receivable, or advances.

The report must include, at a minimum, the payee identifier, legal name, and period of time with no activity.

4.2 ACCOUNTS PAYABLE SUBFUNCTION

This subfunction recognizes and records accrued liabilities resulting from the receipt and acceptance of goods and services. It includes capturing information related to the receipt of goods and services, such as dates of receipt, quantities and amounts received, and reason codes and related descriptions when there are discrepancies related to receipt and acceptance. The accounts payable subfunction also includes reversing accrued liabilities when goods are rejected or returned.


PM 3.1 Receipt and Acceptance of Goods

PM 3.2 Receipt and Acceptance of Services.

PMB-01 The system must record full or partial receipt and/or acceptance of goods and services by document line. This capability must include the receipt and/or acceptance of partial quantities of goods and services on each document line.

PMB-02 The system must provide automated functionality that records an accrued liability or liquidates an advance (when applicable) and reclassifies the order from undelivered to delivered, at the accounting line level, upon receipt of goods or services.


PMB-04 The system must capture information related to the receipt of goods and services, including the following:

Receiving official

Dates goods were delivered or services were performed

Quantity/dollar amount received

Payee identifier and name

Ship-to locations.

PMB-05 The system must provide the capability to allow a user to update information related to the receipt of goods and services, to specify, upon acceptance, the following:

Acceptance official

Date goods or services were accepted

Quantity/dollar amount accepted

Date goods or services were rejected

Quantity/dollar amount rejected.

PMB-06 The system must capture data related to the actual amount of goods received (even if in excess of the amount ordered) and the amount returned, without generating an accounting entry, and must make the data available for further processing on a receiving report.

PMB-07 The system must capture the following information related to goods received, in excess of the amount ordered, and returned:

Obligating document number

Actual quantity ordered

Actual quantity received

Deliver-to location

Actual quantity returned

Date goods were returned.

PMB-08 The system must provide the capability to allow a user to establish and maintain reason codes and related descriptions to identify discrepancies related to the receipt and acceptance of goods and/or services.

PMB-09 The system must reverse accrued liabilities and update related receiving reports when goods previously recorded as received are subsequently rejected during the acceptance process.

PMB-10 The system must prevent an accrual for goods and/or services received from exceeding the total of the amount ordered plus an allowable tolerance.


PMB-11 The system must provide the capability to identify a referenced obligation document line as closed after the last expected receipt, whether partial or final, has been received and accepted.

4.3 PAYMENT REQUEST SUBFUNCTION

The payment request subfunction supports the recording of payment requests received from vendors or other entities 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 Title 5 Section 1315 of the Code of Federal Regulations (CFR). Once matched and approved, payment requests are warehoused in the core financial system and await payment scheduling, which occurs when the payment due dates are reached. Adequate internal controls must be in place to verify that goods and services for which payment is requested were actually ordered, received, and accepted; that proper due dates and payment amounts are computed; and that duplicate payments are prevented.


PM 3.3 Accounts Payable and Invoicing Processes

PM 3.3.1 Invoice Entry

PM 3.3.2 Invoice Processing

PM 3.3.3 Credit Memo.

PMC-01 The system must provide the capability to capture the following information on payment request documents:

Payment request number or account number

Payment request date

Payment request receipt date

Payee identifier and name

DUNS (BPN) number

DUNS+4 number for CCR and FedReg vendors

Source system

Source system document number

Contract line/subline number

Name and address of contractor official to whom payment is to be sent

Payment terms (including discount for prompt payment)

Shipping terms (e.g., shipment number and shipment date)


Payee contact name and telephone number

Dates goods were delivered or services were provided

User comments

Date payment request was returned to payee, when improper

Date payment request was resubmitted by payee as proper, when previously improper.

PMC-02 The system must capture a payment request number of up to 30 characters or the current requirement of I TFM-6-5000 and include the complete number on all payment files, reports and query results.

PMC-03 The system must provide the capability to capture at least 9,999 payment request line items per payment request document.

PMC-04 The system must provide the capability to establish criteria to be used to identify duplicate payment requests.

PMC-05 The system must provide the automated capability to identify duplicate payment requests based on agency predefined criteria (business rules).

PMC-06 The system must provide the capability to validate, prior to recording, a payment request from a registered CCR vendor for the following CCR vendor information:

Vendor status is active.

Vendor name on payment request or referenced obligation is the same as CCR company name (legal, DBA, or division).

DUNS+4 number on referenced obligation is the same as DUNS+4 number on vendor file.

PMC-07 The system must provide the capability to validate, at the time of preliminary payment scheduling, payments to registered CCR vendors for the following CCR vendor information:

Vendor status is active.

Vendor name on payment is the same as CCR company name (legal, DBA, or division) on vendor file.

DUNS+4 number on referenced obligation is the same as DUNS+4 number on vendor file.

PMC-08 The system must provide the automated capability to match payment requests to obligations, receiving reports, and acceptance information by document line item and quantity. The system must be able to perform two-way, three-way, and four-way matching, while preventing the payment of payment requests until the matching process is complete.

PMC-09 The system must process payment requests for payment of partial quantities received and accepted or for partial periods of performance.


PMC-10 The system must provide the automated capability to validate that the period of performance dates on receipt, acceptance, and payment request documents are within the period of performance dates on prior, referenced spending chain document lines.

PMC-12 The system must allow an authorized end user to record a payment request as a partial or final payment of the referenced obligation and, if the payment is final, must deobligate any unliquidated balance and close the obligation and receipt.

PMC-13 The system must allow an authorized end user to record additional shipping and other charges, if authorized and within variance tolerances, to adjust the payment amount.

PMC-14 The system must provide the capability to do the following:

Establish recurring payments

Schedule items (e.g., contracts and leases) for payment on an interval determined by the agency (e.g., weekly, biweekly, monthly, quarterly, or other specified number of days)

Automatically trigger payments based on the scheduled frequency.

PMC-15 The system must allow an authorized end user to maintain recurring payment information, including changes in agreement terms, amounts, and frequency.

PMC-16 The system must warehouse approved payment requests for future payment scheduling.

PMC-17 The system must allow a qualified end user to establish and maintain reason codes and related descriptions for payment request processing irregularities in the following categories:

Advantageous discount lost

Interest paid

Improper payment made

Payment request adjusted

Payment request held from payment schedule

Payment request canceled.

For example, the code “DL01” could denote “Advantageous discount lost because payment request was misplaced.”

PMC-19 The system must allow a qualified end user to establish and maintain reason codes and related descriptions for improper payment requests received.

PMC-20 The system must capture reason codes and related descriptions on payment request documents when any of the following types of


payment request processing irregularities occur:

Advantageous discount lost

Interest paid

Improper payment made

Payment request adjusted

Payment request held from payment schedule

Payment request canceled.

PMC-21 The system must capture reasons and related descriptions on improper payment requests that have been received and held in the system due to failed validations.

PMC-23 The system must provide the capability to release, for further processing, previously held payment requests and scheduled payments upon a vendor record update 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)

DUNS+4 number on document or referenced obligation now the same as DUNS+4 number on vendor file.

The system must calculate payment due dates for released payment requests and must recalculate payment due dates for those that were previously scheduled and held.

PMC-24 The system must provide automated functionality that imports payment request data from payees based on the standard Federal schema.

PMC-25 The system must provide the automated capability to validate payment requests for the minimum data required under the Prompt Payment Act (e.g., payment request number and payment request date).

PMC-27 The system must provide the capability to establish and maintain matching rules that use matching terms defined as follows:

Two-way—either obligation and payment request, or obligation and receipt without payment request (e.g., for some recurring payments)

Three-way—obligation, simultaneous receipt/acceptance, and payment request

Four-way—obligation, receipt, acceptance, and payment request.


4.4 DISBURSING SUBFUNCTION

This subfunction 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 former OMB Circular No. 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.


PM 3.4 Disbursements

PM 3.4.1 Disbursements for Bulk Files (ACH/EFT, CCD, CCD+, CTX, and Checks)

PM 3.4.2 Disbursements for Small Volume and Same or Next Day Payments

PM 3.5 Returned Payments–ACH, Check, Same Day.

PMD-01 The system must provide automated functionality that calculates the due date of vendor payments in accordance with 5 CFR 1315.

PMD-02 The system must provide automated functionality that calculates multiple due dates when lines on a payment request have different payment terms.

PMD-04 The system must provide automated functionality that validates payment terms on payment requests against the payment terms on the related obligating documents. The system must calculate the most advantageous terms, store them on the payment request documents, and use them to calculate the payment due dates and amounts.

PMD-05 The system must provide the capability to schedule a payment request for payment on a date other than the system-calculated due date, as specified by the user, and it must capture a reason code for the user change in payment date.


PMD-06 The system must provide the automated capability to establish payment dates using calendars that guide the determination of the projected payment date.

PMD-07 The system must provide the capability to establish and maintain business rules needed to determine whether taking a discount is economically justified as defined in I TFM 6-8040, and it must calculate a discount in accordance with these established rules.

PMD-08 The system must calculate amounts to be disbursed, including discounts, interest, and penalties, in accordance with 5 CFR 1315, and it must record the applicable amounts on separate lines of the payment request documents.

PMD-09 The system must 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 The system must provide the capability to calculate and apply interest and discount amounts across multiple accounting lines on a payment request.

PMD-11 The system must provide the capability to validate that prompt payment interest is paid from the funds available for the administration of the program for which the penalty was incurred.

PMD-12 The system must provide the capability to establish and maintain a coding scheme for assigning identifiers to payment schedules.

PMD-15 The system must provide automated functionality that records disbursements-in-transit entries immediately after the payments are certified.

PMD-16 The system must provide automated functionality that notifies the user that the payment requests selected for payment, if disbursed, would cause the fund to enter into a negative fund balance position.

PMD-17 The system must allow a qualified end user to select and process warehoused payment requests for individual payments (e.g., off-cycle payments).

PMD-19 The system must provide automated functionality that relates a single payment request to a payment split among multiple bank accounts.

PMD-20 The system must have the automated capability to generate check and EFT payment files in the current Treasury FMS-defined formats for both Treasury and non-Treasury disbursing offices.

PMD-37 The system must capture prompt payment information required by 5 CFR 1315, including discounts taken, discounts lost, and interest paid.


PMD-40 The system must provide automated functionality that records the establishment and replenishment of imprest funds, as prescribed by the USSGL.

PMD-41 The system must record purchases made through the use of imprest funds and third-party drafts, as prescribed by the USSGL.

PMD-42 The system must provide the capability to record transactions (e.g., credit card transactions) where obligation and payment occur simultaneously.

PMD-43 The system must allow an authorized end user to record payments made on behalf of another agency, citing the other agency’s funding information.

PMD-44 The system must provide automated functionality that does the following:

Records payment transactions from other systems (e.g., payroll and travel)

Identifies whether or not disbursement has already been made

Schedules the payments for disbursement when payments have not already been made.

PMD-50 The system must record vendor credit memoranda as accounts receivable or negative accounts payable.

PMD-51 The system must provide automated functionality that does the following:

Reduces payments to vendors to satisfy outstanding credit memos

Records the collection for the amount offset

Reduces expenditures under the related obligation

Maintains the balance of the credit for application against a future payment, if a credit is not fully liquidated by one payment.

PMD-52 The system must provide the capability to record credit memo offsets against subsequent payments to the same vendor from the same or a different funding source.

PMD-54 The system must provide automated functionality that prevents agency offsets of payments based on agency-defined criteria such as accounting classification elements, payee identifier, and vendor CCR business type.


PMD-55 The system must provide automated functionality that, based on a single, online action, does the following:

Reverses an entire payment schedule or a single payment within a payment schedule

Reverses disbursement-in-transit entries

Reestablishes accounts payable

Updates related payment records.

PMD-56 The system must provide automated functionality that, for payments that reference obligations in canceled funds, inherits accounting and nonfinancial information from the original obligation document to a payment request in the current year.

PMD-59 The system must provide the automated capability to select the appropriate third-party assignment name and remittance address or banking information on manual payments to send to Treasury.

PMD-60 The system must provide automated functionality that imports credit memo data from vendors based on the standard Federal schema.

PMD-61 The system must provide automated functionality that establishes a given credit memo to be used to offset future payments or to be billed for subsequent collection.

PMD-62 The system must provide the automated capability to reschedule payments that were previously included on a payment schedule that was reversed.

PMD-63 The system must provide automated functionality that assigns a unique and sequential identifier (i.e., payment schedule number) to a payment schedule based on agency-defined business rules.

PMD-64 The system must provide the capability to distinguish different types of payment schedules (e.g., travel payment schedules and vendor payment schedules), at an agency’s discretion.

PMD-65 The system must provide the capability to identify payments that are reissued (i.e., previously canceled payments) and to evaluate the reason a reissued payment was previously canceled in order to determine whether interest should be accrued and to properly calculate the interest.

PMD-66 The system must provide automated functionality that allows an authorized certifying officer to exclude and certify individual payment vouchers from the final payment schedule; and it must rewarehouse excluded payments.


4.5 PAYMENT FOLLOW-UP SUBFUNCTION

This subfunction allows for agency follow-up on payments pending and accomplished. Core financial systems must capture the information needed to track payment requests through various stages of processing, to respond to vendor inquiries.

PME-02 The system must maintain a history of the following information for each paid payment request:


Referenced obligation document number(s)

Source document number(s) (e.g., reimbursable agreement number, BPA/BPA call number, contract number, delivery/task order number, and grant number)

Total payment request amount

System-generated payment document number

Treasury confirmation number

Payee-assigned payment request number

Payee information (number, name, address, TIN, and DUNS (BPN) number)

DUNS+4 number for CCR and FedReg payees

Payment address(es) and/or bank account number(s) and routing number(s) to which payment(s) were made

Payment method(s) (e.g., check, EFT)

Payment amounts

Interest paid

Discount(s) taken

Internal offset(s) made

Date(s) due

Date(s) paid.

PME-07 The system must provide automated functionality that enables third-party payments to be included on IRS 1099-MISC forms.

PME-10 The system must provide automated functionality to notify employees of travel payments.

Core Financial System Requirements Receivable Management Function

5 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 until the receivables are determined to be uncollectible in whole or in part.

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. OMB Circular No. A-129, Policies for Federal Credit Programs and Non-Tax Receivables, prescribes policies and procedures for collecting non-tax receivables. The Debt Collection Improvement Act of 1996 (DCIA) requires agencies to take prompt action to recover debts, screen potential borrowers related to credit programs, and resolve outstanding debt through various options. Delinquent debt overdue by 180 days is centrally managed by Treasury. DCIA allows for referral of the delinquent debt to the Department of Justice for litigation. Treasury requires Federal agencies to report on receivables by submitting all required information on the Treasury Report on Receivables and Debt Collection Activities (TROR).

Depending on an agency’s system architecture, receivable and collection activities may be performed directly in the core financial system or supported by other systems that provide data to the core 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.

The receivable management function includes recording, billing, monitoring, and collecting amounts due the government whether previously established as a receivable or not. The system requirements in this document reflect the system functions required to support the standard Federal financial business processes.

The receivable management function consists of the following subfunctions:

Customer information maintenance (RMA)

Receivables and billing (RMB)

Debt management (RMC)

Collections and offsets (RMD).

5.1 CUSTOMER INFORMATION MAINTENANCE SUBFUNCTION

The word “customer” is used here to include any entity—including contractors, employees, grantees, loan recipients, and other government agencies—that owes a


debt to an agency. An entity that is a payee or vendor to the agency may become a customer of the agency, in the event that duplicate or overpayments occur.

This subfunction involves the maintenance of customer information (name, address, etc.) that is needed for receivable processing, maintenance, and collection. The subfunction 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.

RMA-01 The system must maintain non-FedReg customer information to support receivable management processes, including the following:

Customer name

Customer identifier

Customer type (foreign/sovereign, state/local government, commercial, or consumer)

DUNS (BPN) number

Billing method (electronic, hard copy, or other)

TIN

Customer address

Customer contact name

Customer contact telephone number

Customer contact email address

Federal vs. non-Federal indicator

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

Active/Inactive indicator.

RMA-02 The system must provide automated functionality that immediately identifies an attempt to input a duplicate TIN for a new customer record and provides a warning message to the user about the duplication.

RMA-04 The system must maintain a history of changes made to customer information, including the following:

Name of data item changed

Before and after values

Entry date and time

ID of user who made the change.


RMA-06 The system must deactivate customers on demand or based on agency-specified length of time with no activity.

RMA-07 The system must provide automated functionality that prevents the deactivation of customers that have unliquidated receivables in the system.

5.2 RECEIVABLES AND BILLING SUBFUNCTION

This subfunction supports activities to record receivables in the system as they are recognized and to produce bills for amounts due to the agency.


RM 4.1 Establish Accounts Receivable Due From the Public

RM 4.3 Billing

RM 4.10 Return of a Negotiable Instrument

RM 4.12 Installment Plans.

RMB-01 The system must record accounts receivable and corresponding revenues, expense reductions, advance/prepayment reclassifications, and other offsets.

RMB-02 The system must record adjustments to receivables and, on each adjustment, must capture one of the agency’s predefined reason codes and a description.

RMB-03 The system must provide the capability to establish and maintain receivable types that identify the activity generating the receivable (e.g., sale of goods or services, overpayment, unused advance subject to refund, fees, and fines) so that the receivable type can be captured on receivable documents.


RMB-04 The system must capture the following information on receivable documents:

Baseline receivable date (used to age receivable and determine the delinquency date)

Description of goods/services or other basis for debt

Item type to be billed

Receivable type

Dates of performance

Customer identifier

Customer name

Customer purchase order number

Reimbursable agreement number

Billing terms.

RMB-06 The system must provide automated functionality that determines amounts to be billed to customers, when the amount billed is not based on a reimbursable agreement (such as in most cases when the customer is non-Federal).

RMB-09 The system must provide automated functionality that generates bills consistent with predefined fee schedules or payment schedules.

RMB-10 The system must provide automated functionality that generates bills to third-party payers.

RMB-11 The system must provide the capability to customize the text and data elements to be displayed on system-generated bills, by customer type, receivable type, or billing method. For example, a 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-15 The system must provide the automated capability to default the bill date based on a system date and to allow an end user to modify the defaulted bill date.

RMB-17 The system must provide automated functionality that consolidates multiple receivables for a customer onto one bill, while retaining identification of each receivable separately within the bill.

RMB-18 The system must provide automated functionality that updates receivable status from unbilled to billed when bills are generated and associates the receivable with the bill number and bill date.

RMB-19 The system must capture information from manually prepared bills and must update the receivable document (e.g., change status of receivable from unbilled to billed) with manual bill information.


RMB-20 The system must provide automated functionality that does the following:

Reestablishes a receivable when a check collection is canceled due to insufficient funds or when a chargeback is recorded

Captures the original baseline receivable date on a reestablished receivable

Supports the rebilling of a reestablished receivable.

RMB-21 The system must provide the automated capability to reschedule existing receivables to be paid under installment plans.

RMB-22 The system must provide the capability to reschedule a receivable multiple times.

RMB-28 The system must provide the capability to capture and maintain agency-defined receivable adjustment types (e.g., credit memo cancellation).

5.3 DEBT MANAGEMENT SUBFUNCTION

The debt management subfunction supports activities related to analyzing accounts receivable and managing delinquent debt. It includes aging accounts receivable; assessing interest, penalties, and administrative charges on delinquent debt; pursuing collection; calculating the allowance for uncollectible amounts; and recording write-offs.


RM 4.2 Analyze Accounts Receivable

RM 4.6 Dunning

RM 4.7 Allowance for Loss on Accounts Receivable

RM 4.8 Write-off of Accounts Receivable

RM 4.11 Waiver of Interest, Administrative Costs, and Penalties.

RMC-01 The system must provide automated functionality that calculates and records late payment interest charges on overdue non-Federal receivables based on the Treasury CVFR unless otherwise specified by the agency.


RMC-02 The system must provide the automated capability to calculate and record late payment interest charges on overdue non-Federal receivables based on an agency-assigned interest rate that is different from the CVFR, when specified for a particular receivable, customer, or customer type.

RMC-03 The system must provide automated functionality that calculates and records penalties and administrative charges on overdue receivables based on an agency-assigned rate or amount for a particular receivable, receivable type, customer, or customer type.

RMC-04 The system must provide the automated capability to record interest, penalties, and administrative costs received to a TAS that is different than that of the principal receivable.

RMC-05 The system must provide automated functionality that ceases or continues accruing interest on delinquent debts that have been referred to Treasury or another agency, when specified for a particular referred debt.

RMC-11 The system must provide the capability to record the waiver and write-off of receivables, including interest, penalties, and administrative charges, and to capture an agency-defined reason code.

RMC-12 The system must provide the capability to classify receivables written off as currently not collectible or as closed out.

RMC-13 The system must maintain data on receivables that have been waived or written off.

RMC-16 The system must associate receivables with dunning notice dates, referral dates, and comments to support debt collection activities.

RMC-17 The system must calculate and record the allowance for loss on uncollectible 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 The system must group delinquent debt into user-defined categories based on stored or derivable system values, including 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-22 The system must provide the capability to establish and maintain agency-specific reason codes and related descriptions for write-offs of receivables.

RMC-23 The system must provide the automated capability to suppress the generation of dunning notices and cease collection efforts for the following:

Individual receivables selected by a qualified end user

Categories of receivables as defined using parameters such as the delinquent debt category (e.g., in bankruptcy, at private collection agency)

Receivables for which the agency has issued a 1099-C.

5.4 COLLECTIONS AND OFFSETS SUBFUNCTION

The collections and offsets subfunction 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.


RM 4.4 Collection of Receipts

RM 4.5 Application of Receipts

RM 4.9 Issue Credit Memo.


RMD-01 The system must provide the capability to capture information on collections, including the following:

Customer identifier and name (or vendor/payee identifier and name, if collection is due to a previous overpayment)

Deposit number

Deposit date

Deposit confirmation date

Obligation reference number

Reimbursable agreement reference number

Advance reference number

Payment reference number

Bill number

Source (cash, EFT, check, money order, credit card, IPAC, SF 1081, electronic file from bank, or TOP)

Transaction authorization number (relevant to credit card collection)

Credit card account number

Comments.

RMD-02 The system must do the following:

Record collections against receivables

Reference the receivable document

Update customer records and related billing information.

RMD-03 The system must record collections with corresponding revenues, expenditure reductions, advance/prepayment reclassifications, or other offsets, when receivables were not previously established.

RMD-04 The system must provide automated functionality that applies collections against receivables 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 The system must record collections received against receivables that were waived or written off.


RMD-06 The system must provide the capability to do the following:

Record receipt of refunds of previous overpayments, for which a receivable was not established

Reference the obligating document associated with the overpayment

Reduce the cumulative amount expended on the obligating document by the amount refunded.

RMD-07 The system must provide the capability to do the following:

Record receipt of refunds of unused advances or prepayments, for which a receivable was not established

Reference the obligating document associated with the advance

Reduce the cumulative amount advanced on the obligating document by the amount refunded.

RMD-10 The system must provide automated functionality that records a refund payable when collections for a particular receivable exceed the outstanding balance of the receivable.

RMD-14 The system must provide automated functionality that records and classifies cash and check collections as deposited or undeposited.

RMD-15 The system must provide the capability to generate a deposit ticket (SF 215) from the cash and check collections recorded in the system.

RMD-16 The system must provide automated functionality that updates the status of a collection from undeposited to deposited upon receipt of confirmation of the deposit from Treasury.

Core Financial System Requirements Cost Management Function

6 COST MANAGEMENT FUNCTION

The term “cost” refers to the 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. The cost management function includes the capability to accumulate, distribute, and monitor 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, developed by FASAB.

The managerial cost accounting concepts and standards contained in SFFAS 4 are aimed at providing reliable and timely information on the costs attributable to programs, their activities, and outputs. This information is useful when making decisions about allocating resources, evaluating program performance, or improving operating efficiency.

The cost management function of the core financial system provides the data needed for meaningful financial accountability over public programs and evaluation of the efficiency of resources used in various activities. In addition, it provides the basis for setting fees and prices for services or products provided by a Federal agency. It should also provide a basis for linking operational results to the budget and performance measures. The level of sophistication needed with respect to cost management will vary depending on the nature of an agency’s programs. For example, if an agency produces a product for sale, the cost function may be fairly complex and accomplished in a separate managerial cost accounting system that is integrated with the core financial system.

SFFAS 4 requires that cost information developed for different purposes be drawn from common data sources and that cost reports 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.

The cost management function consists of the following subfunctions:

Cost setup and accumulation (CMA)

Cost distribution (CMB)

Cost monitoring (CMC).

6.1 COST SETUP AND ACCUMULATION SUBFUNCTION

This subfunction 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 core financial system must allow the establishment of cost object identifiers consistent with the stated needs of its financial and operational managers. Ideally, the core financial system will allow this to be done straightforwardly, with the level of complexity appropriate for the agency’s needs.

CMA-01 The system must provide the capability to establish and maintain cost data objects to be used for the accumulation, distribution, and reporting of costs.

CMA-02 The system must provide automated functionality that accumulates costs by cost object and that enables costs incurred in the generation of revenue to be reported in association with that revenue.

CMA-03 The system must provide the capability to 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 The system must provide the capability to accumulate direct costs, indirect cost allocations, implicit costs (e.g., costs of pensions provided by other government agencies), and unfunded costs (e.g., accrued annual leave costs) by cost object.

CMA-05 The system must provide automated functionality that accumulates nonfinancial data (e.g., units purchased, units sold) by cost object at the transaction level.

CMA-06 The system must provide automated functionality that accumulates, distributes, and reports both planned and actual costs by cost object.

CMA-07 The system must provide the automated capability to accumulate and report costs by accounting classification element and by specific customers, vendors, reimbursable agreements, contracts, BPAs, task orders, work orders, and grants.

6.2 COST DISTRIBUTION SUBFUNCTION

The cost distribution subfunction assigns costs to cost objects. SFFAS 4, under “Costing Methodology,” describes several costing methods that can be used, but it does not require the use of a particular type of costing system or method. If the cost distribution process affects the values of general ledger accounts, the summarized impact of cost assignments must be reflected in the core financial system.

CMB-01 The system must provide the capability to distribute and assign the full cost of goods and services to cost objects.


CMB-02 The system must provide the capability to associate the USSGL attributes captured on expense and expenditure transactions with cost assignment transactions, so that they can be used in the preparation of the Statement of Net Cost. For example, costs assigned to programs reported on the Statement of Net Cost must be able to be distinguished by the USSGL attribute classifications of Federal/non-Federal, exchange/non-exchange, and custodial/non-custodial.

CMB-03 The system must provide automated functionality to perform agency-defined multilayered cost distributions (at least three levels of distribution) using multiple rates and fixed-amount allocation methods.

CMB-04 The system must provide automated functionality that redistributes costs based on revised rates and allocation amounts.

6.3 COST MONITORING SUBFUNCTION

The cost monitoring subfunction supports management’s review of the costs of operations and performance of programs. It also provides relevant and reliable cost information to assist the Congress and the executive branch with making decisions about allocating Federal resources, authorizing and modifying programs, and evaluating program performance. The cost monitoring subfunction must ensure consistency between costs reported in general-purpose financial reports and costs reported to program managers.

The core financial system should be able to produce the Statement of Net Cost for the agency’s financial statements, the Comparative Income Statement by Cost Object, and the Cost Object Income Statement.

CMC-01 The system must provide automated functionality that generates a comparative income statement by cost object using the following parameters:

Cost object

Accounting period (current year and prior year).

The report must display the month and year-to-date activity for the cost object compared to the prior year’s month and year-to-date activity. The report must list the following data for each accounting period column and year-to-date column:

Revenue

Direct expenses

Indirect expenses

Total expenses

Net revenue/cost.


CMC-02 The system must provide the capability to generate a cost object income statement using the following parameters:

Cost object

Accounting period (current year and prior year).

The report must display revenue, direct cost, and indirect cost assigned to the cost object for the accounting period.

CMC-03 The system must maintain an audit trail of cost assignment transactions from their origin to the final cost objects.

Core Financial System Requirements Fund Balance with Treasury Management Function

7 FUND BALANCE WITH TREASURY MANAGEMENT FUNCTION

The FBWT represents the money an agency can spend on future authorized transactions. Agencies record transactions that increase and decrease their FBWT to USSGL account 1010 in their general ledger. Appropriation warrants, nonexpenditure transfers, collections, and disbursements are some of the transactions that affect an agency’s FBWT.

Treasury requires that agencies reconcile their FBWT accounts regularly. Regional Finance Centers (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 FBWT management function consists of the following subfunctions:

Treasury information maintenance (FBA)

Payment confirmation (FBB)

FBWT reconciliation and reporting (FBC).

7.1 TREASURY INFORMATION MAINTENANCE SUBFUNCTION

Most Federal agencies process large volumes of transactions that affect their FBWT. To facilitate automatic reconciliations with Treasury, an agency must classify cash transactions with Treasury-defined codes. The Treasury information maintenance subfunction 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 affect the FBWT.

FBA-01 The system must provide automated functionality that maintains multiple ALCs.

FBA-02 The system must maintain an attribute of the ALC that specifies whether the ALC is a GWA reporter or a non-GWA reporter.

FBA-04 The system must maintain an ALC’s business activity in accordance with Treasury Partial FMS 224 guidance.

FBA-06 The system must maintain the GWA reporter category for GWA reporter ALCs in accordance with Treasury Partial FMS 224 guidance.


FBA-07 The system must provide automated functionality that captures the ALC on transactions that affect the FBWT and are reported to Treasury on FMS 224 or Partial FMS 224, or through the GWA system.

FBA-08 The system must provide automated functionality that imports and maintains valid TAS/BETC combinations provided by a Treasury source system (e.g., SAM) for classification of the agency’s FBWT transactions in the GWA system.

FBA-09 The system must provide automated functionality that captures the TAS/BETC on transactions that affect the FBWT and are reported through the GWA system.

FBA-10 The system must provide automated functionality that classifies transactions that affect the FBWT, and are reported on FMS 224 or Partial 224, or through the GWA system, according to the Treasury system of origin (e.g., IPAC, CA$HLINK II, TDO Payment, or Reclassification).

FBA-11 The system must provide the capability to capture the unique Treasury document reference number on all transactions that affect the FBWT.

7.2 PAYMENT CONFIRMATION SUBFUNCTION

Agencies that disburse payments through Treasury provide the details of requested payments (vendor name, amount of payment, payment date, etc.) 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 notifies 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 subfunction must ensure that an automated process is in place to update confirmation information.

FBB-01 The system must provide the automated capability to import payment confirmation data from a Treasury governmentwide system (e.g., SPS, PAM, or GOALS II/IAS RFC Agency Link).

FBB-02 The system must provide automated functionality that liquidates individual disbursement-in-transit transactions and records confirmed disbursements upon receipt of payment confirmation from a Treasury governmentwide system (e.g., SPS, PAM, or GOALS II/IAS RFC Agency Link).


FBB-03 The system must provide automated functionality that updates payments with the paid schedule number, payment confirmation date, and check number or trace number upon receipt of confirmation data from a Treasury governmentwide system (e.g., SPS, PAM, or GOALS II/IAS RFC Agency Link).

FBB-04 The system must provide automated functionality that assigns check numbers to individual payments, based on the payment schedule’s check range received from a Treasury governmentwide system (e.g., SPS, PAM, or GOALS II/IAS RFC Agency Link).

FBB-05 The system must provide the capability to correct system-assigned check numbers on payment records that do not match the actual check number assigned by Treasury.

FBB-06 The system must provide automated functionality that assigns check numbers to individual payment records when a payment schedule has multiple check ranges or a break in check numbers.

FBB-07 The system must record disbursement cancellations for individual payments that have not been negotiated.

7.3 FBWT RECONCILIATION AND REPORTING SUBFUNCTION

Reconciling the FBWT is a complex, multistep process that involves an exchange of information between an agency and the Treasury. Each agency provides Treasury with the proper classification information (e.g., Treasury Account Symbol) for its receipt and disbursement activity. Treasury provides the agency with detailed lists of receipt and disbursement activity that the agency must compare to the detailed transactions recorded in its general ledger. The FBWT reconciliation and reporting subfunction facilitates the comparison of transactions at this detailed level.

FBC-01 The system must provide automated functionality that imports a disbursement support listing (e.g., ACR support listing) from a Treasury governmentwide system (e.g., GOALS II/IAS RFC Agency Link) to facilitate reconciliation with Treasury of agency-recorded disbursements and cancellations.

FBC-02 The system must provide the automated capability to compare individual amounts from a Treasury disbursement support listing (e.g., ACR support listing) with amounts recorded in the agency’s general ledger by payment schedule number and accounting period.


FBC-03 The system must provide automated functionality that generates a discrepancy report showing the differences between disbursements recorded in the agency’s general ledger and disbursements listed on a Treasury disbursement support listing (e.g., ACR support listing) by accounting period. The report must display the payment schedule number, dollar amount, Treasury confirmation date, agency document number, and agency transaction date, as appropriate, of the following items:

Items on the Treasury disbursement support listing and not in the agency’s general ledger

Items on the Treasury disbursement support listing for a different amount than in the agency’s general ledger

Items in the agency’s general ledger and not on the Treasury disbursement support listing.

FBC-04 The system must provide the automated capability to import an intragovernmental transaction support listing (e.g., IPAC support listing) from a Treasury system (e.g., IPAC) to facilitate reconciliation of agency-recorded intragovernmental transactions processed through a Treasury intragovernmental processing system.

FBC-05 The system must provide the capability to compare individual amounts from an intragovernmental transaction support listing (e.g., IPAC support listing) with amounts recorded in the agency’s general ledger.

FBC-06 The system must provide automated functionality that generates a discrepancy report showing the differences between intragovernmental payment and collection transactions recorded in the agency’s general ledger and items on a Treasury intragovernmental transaction support listing (e.g., IPAC support listing) by accounting period. The report must display the Treasury document reference number, the Treasury confirmation date, dollar amount, agency document number, and agency transaction date, as appropriate, of the following items:

Items on the intragovernmental transaction support listing and not in the agency’s general ledger

Items on the intragovernmental transaction support listing for a different amount than in the agency’s general ledger

Items in the agency’s general ledger and not on the intragovernmental supporting listing.

FBC-07 The system must provide automated functionality that imports a detailed list of deposit and debit voucher activity (e.g., DT/DV support listing) from a Treasury collection system to facilitate reconciliation of agency-recorded deposits and debit vouchers with Treasury.


FBC-08 The system must provide the capability to compare individual amounts from a detailed list of deposit and debit voucher activity (e.g., DT/DV support listing) obtained from a Treasury collection system with the amounts recorded in the agency’s general ledger by document number and accounting period.

FBC-09 The system must provide automated functionality that generates a discrepancy report showing the differences between deposit and debit voucher transactions recorded in the agency’s general ledger and items on a Treasury listing of deposit and debit voucher activity (e.g., DT/DV support listing) by accounting period. The report must include the Treasury document reference number, Treasury confirmation date, dollar amount, agency document number, and agency transaction date, as appropriate, of the following items:

Items on the Treasury listing of deposit and debit voucher activity and not in the agency’s general ledger

Items on the Treasury listing of deposit and debit voucher activity for a different amount than in the agency’s general ledger

Items in the agency’s general ledger and not on the Treasury listing of deposit and debit voucher activity.

Core Financial System Requirements System Management Function

8 SYSTEM MANAGEMENT FUNCTION

The system management function ensures that the capabilities exist to capture, classify, process, and report the financial activity of Federal agencies. This 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 subfunctions:

Accounting classification (SMA)

Document and transaction control (SMB)

Document referencing and modification (SMC)

System-generated transactions (SMD)

Audit trails (SME).

8.1 ACCOUNTING CLASSIFICATION SUBFUNCTION

The accounting classification subfunction 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 agency reporting and management needs.

The CGAC structure establishes a standard for classifying the financial effects of government business activities. It provides the name, definition, authoritative source, and field size of classification elements to be used by all agencies in their financial management systems. At the same time, the CGAC structure provides flexibility for agency mission-specific needs.

The accounting classification management subfunction 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, asset, or liability 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


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

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

SMA-01 The system must provide the capability to maintain an accounting classification structure that includes the following elements, as described in the CGAC structure:

TAS

Internal fund

Agency

Bureau

Internal organization

Strategic goal/strategic goal extension

Program

Project

Governmentwide project

Line of business subfunction

USSGL account/USSGL account extension

USSGL account attributes

Accounting period

Object class/object class extension

Revenue source

Business event type

ALC

Cost center

Activity.

The system must maintain each classification element independently.

SMA-02 The system must provide the capability to establish and maintain at least five agency mission-specific accounting classification data elements in conformity with CGAC guidance.

SMA-03 The system must classify transactions by any element of the accounting classification structure, including any of the five agency mission-specific classification elements.

SMA-05 The system must allow a qualified end user to maintain accounting classification elements without the need to request technical support.


SMA-06 The system must provide automated functionality that controls the use of accounting classification elements by validity period. In other words, the system must activate or deactivate accounting classification changes based on start and end dates (effective period or validity period) during which each element will be available for use.

SMA-09 The system must allow for the entry, import, retrieval, summarization, and reporting of a TAS structure that includes the following components defined by Treasury and OMB:

Sublevel prefix

Allocation transfer agency identifier

Agency identifier

Beginning period of availability

Ending period of availability

Main account code

Subaccount code.

SMA-10 The system must provide the capability to establish additional (lower) levels of hierarchical CGAC data elements, such as internal organization, program, project, object class/object class extension, and cost center (e.g., establish parent-child relationships with the ability to summarize, distribute funds, and report data at all defined levels).

SMA-11 The system must provide the automated capability to maintain an accounting classification structure and related data relationships as prescribed in CGAC guidance for common governmentwide and agency-specific data relationships, including the following:

TAS to multiple internal funds

Internal fund to multiple USSGL attributes and fund attributes

Program to multiple USSGL attributes, internal funds, projects, organizations, or activities

Strategic goal to multiple programs and projects.

SMA-12 The system must maintain an object class structure consistent with the standard object class codes defined in OMB Circular No. A-11 and for the lower level agency-specific object class extension codes permitted by the CGAC structure.

SMA-13 The system must be delivered pre-populated with the object classification codes specified in OMB Circular No. A-11.

SMA-14 The system must provide the automated capability to load governmentwide (e.g., Treasury, OMB) and agency-specific classification elements.


SMA-15 The system must provide automated capability to derive accounting classification element values based on agency-defined data relationships or business rules.

SMA-16 The system must provide the capability to derive USSGL account attributes used to classify accounting transactions for reporting to Treasury systems (e.g., FACTS I, FACTS II, GFRS, and GTAS) from the internal fund code, including, at a minimum, apportionment category, BEA category, borrowing source, budget function or subfunction, custodial or noncustodial, definite or indefinite, direct or reimbursable, and exchange or nonexchange.

SMA-17 The system must provide the capability to link a fund origination year to an internal fund.

8.2 DOCUMENT AND TRANSACTION CONTROL SUBFUNCTION

The document and transaction control subfunction defines the rules for recording, editing, and processing transactions that are entered directly in 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 control transactions 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 must 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 subfunction defines these required data elements and validations.

SMB-01 The system must capture a unique system-generated or agency-assigned document number for each document and document modification.

SMB-02 The system must capture a unique system-generated number to identify each general ledger transaction, and it must associate one or more general ledger transactions with a document and document modifications.

SMB-03 The system must provide automated capability to link referenced documents in the processing chain, including purchasing (or spending chain) documents. For example, when an obligation document references multiple commitment documents, that obligation must remain linked to each commitment document.


SMB-04 The system must provide the capability to inextricably link financial management transactions to related reimbursable agreements, while maintaining traceability to the associated source documents, including purchase requisitions, contracts, delivery orders, task orders, purchase orders, BPAs, grants, and travel orders.

SMB-06 The system must provide automated internal control functionality designed to do the following:

Prevent the entry of duplicate documents

Identify potential duplicate documents

Correct duplications.

SMB-07 The system must capture the source system identifier and the source system unique document number (or other unique identifier) of each interfaced or converted document.

SMB-08 The system must capture goods delivery and service performance period start and end dates at the document and document line level on documents where the period of performance is a validation for future processing, such as the following:

Spending documents

Contracts

BPAs

Reimbursable agreements

Grants.

SMB-10 The system must provide automated functionality to define and maintain funds control edits and tolerance checks (on variances in document quantity or dollar amount) as one of the following:

Rejection

Warning (override authority needed to post transaction)

Information only (no override needed).

SMB-11 The system must provide the capability to prevent the recording of erroneous transactions by rejecting documents that fail transaction processing validity checks (e.g., edits) or lack required verifications.

SMB-12 The system must provide automated functionality that notifies the user when online documents fail funds control edits, transaction processing edits, or tolerance checks. The system must provide the notification on the document entry screen and include the nature of each error and the validation edit (rejection, warning, or information only). The system must retain errors with the document until they have been resolved.


SMB-13 The system must provide the capability to suspend documents that fail transaction processing edits, funds control edits, or tolerance checks.

SMB-14 The system must provide the capability to allow users to hold documents for completion or processing at a later date and to segregate held documents from suspended documents.

SMB-15 The system must provide the capability to reprocess suspended documents when external referenced data that caused the system to suspend processing of a document is corrected (e.g., when a vendor’s CCR status changes from expired to active).

SMB-16 The system must provide automated functionality that allows users to select suspended and held documents for continued processing.

SMB-17 The system must provide automated functionality that allows users to cancel (reverse) posted documents, including all associated general ledger transactions and system table updates (e.g., funds availability updates.)

SMB-18 The system must provide the capability to allow users to delete unposted documents in a held or suspended status.

SMB-19 The system must provide the capability to establish tolerances for both quantity and dollar amounts at the document line level in percentages and/or “not-to-exceed” amounts, and the system must use tolerances to validate against variations in both quantity and dollar amounts at the document line level for the following relationships:

Obligations to commitments

Receipts to obligations

Payment requests to obligations.

SMB-20 The system must provide the capability to define dollar and quantity tolerances by type of obligation or for all obligations independent of their obligation type.

SMB-21 The system must capture the following accounting line detail on all documents:

Line number

Line amount

Line accounting classification information.


SMB-22 The system must provide the capability to establish and maintain acquisition data elements and values, including the following:

NAICS business codes

SIC codes

Product and service codes

FOB shipping points

Ship to locations (destination codes).

SMB-23 The system must provide the capability to validate acquisition data values captured on spending documents (e.g., product and service codes).

SMB-24 The system must provide the capability to capture the document line item information on spending documents, including the following:

Quantity

Unit of measure

Unit price

Extended price

Description

Product and service codes

FOB shipping points

Ship to locations (destination codes).

SMB-25 The system must validate that the sum of all document lines is equal to the document total.

SMB-26 The system must provide the capability to derive the default transaction date from the current system date.

SMB-27 The system must provide the capability to derive the accounting period from the transaction date and to prevent user override.

SMB-28 The system must 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 The system must record subsequent activity against a document with the transaction date of that activity, not the transaction date of the original document (e.g., a receiving report must capture the transaction date of the receipt of goods or services, not the transaction date of the referenced obligation).

SMB-30 The system must validate accounting classification elements and prevent the recording of transactions when the accounting classification elements or values are missing, invalid, or inactive.


SMB-31 The system must validate Treasury trial balance system (e.g., FACTS I, FACTS II, or GTAS) attributes associated with transactions and prevent the recording of transactions when these attributes are missing, invalid, or inactive.

SMB-32 The system must validate transactions that would post to USSGL accounts (e.g., those used to record borrowing authority, contract authority, or investments) to ensure that the associated TAS is designated as having the appropriate RT7 code.

SMB-33 The system must capture a transaction date and system date on all transactions.

SMB-37 The system must provide the capability to inextricably link financial management transactions to related contracts, while maintaining traceability to the associated source documents, including purchase requisitions, delivery orders, task orders, purchase orders, BPAs, grants, and travel orders.

SMB-38 The system must provide the capability to establish and maintain a reimbursable (interagency) agreement identifier.

SMB-39 The system must record one or more accounting lines for each document line.

8.3 DOCUMENT REFERENCING AND MODIFICATION SUBFUNCTION

This subfunction defines the relationships that must exist between the documents in a processing chain. An example of a processing chain is the Federal spending chain, in which a commitment of funds moves to an obligating document (e.g., contract or purchase order), to the acknowledgment of goods or services received and accepted, and finally to the resulting payment. As each successive event is recorded, it references the document of the previous event’s document, inheriting information from the previous document and updating it accordingly. The document referencing and modification subfunction also describes the types of document amendments that must be accommodated by the core financial system.

SMC-01 The system must link documents in the processing chain and must inherit accounting and nonfinancial information from one document to another, when the previously recorded document is referenced (e.g., commitment to obligation, receivable to collection). This must include accounting classification, payee, and customer information.


SMC-02 The system must provide automated functionality that updates the dollar amount and quantity balances of open documents by accounting line as they are referenced by subsequent documents in the processing chain. For example, it must reduce commitments when referenced by obligations, reduce obligations when referenced by expenditures, reclassify obligations when referenced by advances, and reduce accounts receivable when referenced by collections.

SMC-03 The system must 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 The system must capture document modifications at the accounting line level that affect the general ledger, including changes to dollar amounts and accounting classifications, and it must validate that funds are available prior to recording the modifications.

SMC-05 The system must capture document modifications that do not affect the general ledger or the status of budgetary resources (e.g., adding or changing reason codes and descriptions).

SMC-06 The system must associate document modifications and cancellations with the original documents so that queries show all related activity.

SMC-07 The system must provide the capability to reopen a closed document to allow further processing (i.e., modifications, referencing activity such as collections against receivables) against it, without requiring a new or amended document number.

SMC-08 The system must provide the capability to reference multiple documents, document lines, and accounting lines in a processing chain. For example, it must provide the capability for an obligating document to reference multiple commitment documents, commitment document lines, and commitment accounting lines.

SMC-09 The system must provide the capability to capture the latest system processing status on all documents, for example, a status of “held” on all documents for which the user has saved (held) the document for later processing. Other system statuses include open, closed, and canceled.

SMC-16 The system must provide the capability to reference one document with multiple subsequent documents, document lines, and accounting lines in the processing chain. For example, the system must allow a commitment to be referenced by multiple obligations and obligation lines.


SMC-17 The system must maintain open documents to show the dollar amount and quantity balances of documents by accounting line. Examples of documents are commitments, obligations, advances, receiving reports, accruals, and receivables.

SMC-18 The system must associate document references with the original documents so that queries show all related activity (a history of the document chain).

8.4 SYSTEM-GENERATED TRANSACTIONS SUBFUNCTION

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, specifying the debits and credits, the date or frequency of the entry, and business rules that trigger the entry. System-generated transactions are then recorded automatically by the core financial system on the specified dates, based on the passage of time.

SMD-01 The system must 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 The system must provide automated functionality that generates recurring entries and reversals in future accounting periods (e.g., payroll and travel accruals), when the specified transaction dates are reached. This must include entries that cross fiscal years.

SMD-03 The system must provide the capability to enter and store future-dated transactions, so that the recording of transactions and updates to funds availability balances occurs automatically when the specified transaction date is reached and the applicable accounting period is open. The system must validate the future-dated transaction upon initial entry and revalidate the transaction at the point it is recorded.


SMD-04 The system must provide the capability to be configured to generate batched reversal transactions by any one or a combination of the following parameters:

Accounting period

Transaction or document type


System date

Transaction date

Source system ID.

For example, the system must be able to reverse payroll transactions posted on January 1, 2009.

SMD-05 The system must provide automated functionality that validates that transaction reversals do not violate the integrity of the document chain. For example, the system should not allow reversal of obligations that have been liquidated by payments.

SMD-07 The system must provide the automated capability to interface financial data and financial transactions to and from systems mandated for governmentwide use (e.g., GTAS, IPAC, TOP, SPS, FedReg, and CCR).

8.5 AUDIT TRAILS SUBFUNCTION

Audit trails provide detailed records that support 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.

SME-01 The system must capture and maintain an audit trail from the original postings to the final postings of a document. The audit trail must include, at a minimum, the following:

Document number (or other unique identifier)

Source system identifier

Document line number

Accounting line number

General ledger accounts

Transaction amounts

Transaction number

Transaction date

System date and time


User ID

Type of activity (addition, modification, liquidation, cancellation).

SME-02 The system must capture all document change events (additions, modifications, and cancellations), including the date and time of the change and the user ID.

SME-03 The system must provide automated functionality to query document change events (additions, modifications, and cancellations) using one or a combination of the following query parameters:

User ID

Document number

Document type

Change event type (addition, modification, cancellation)

Transaction date range

Accounting period.

Query results must include all parameter values, document numbers, and date and time of the event.

SME-04 The system must provide the automated capability to generate an audit trail of all accounting classification structure additions, changes, and deactivations, including the system date and time of the change and the effective date of the change.

Core Financial System Requirements Reimbursable Management Function

9 REIMBURSABLE MANAGEMENT FUNCTION

Reimbursable management refers to the capabilities specific to recording, executing, and reporting on transactions for the exchange of goods and services between a buyer and seller (sometimes referred to as trading partners), under a reimbursable agreement. Most reimbursable agreements are between Federal agencies in which one Federal agency (the seller) supplies goods and services to another Federal agency (the buyer). However, reimbursable agreements can also exist between a Federal agency and a non-Federal entity. The term interagency agreement is used when referring specifically to a reimbursable agreement between Federal agencies.

This chapter covers capabilities related to both interagency agreements between Federal agencies and reimbursable agreements with non-Federal entities. This chapter also covers activity related to both the buyer side and the seller side of a reimbursable agreement.

The reimbursable management function consists of the following subfunctions:

Reimbursable customer and payee maintenance (RBA)

Establishment of reimbursable agreement (RBB)

Billing, collections, and payments under reimbursable agreements (RBC)

This chapter will be updated after the reimbursable management standard business process is finalized.

9.1 REIMBURSABLE CUSTOMER AND PAYEE MAINTENANCE

This subfunction includes maintenance of master data specific to Federal customers and payees. Most of the information maintained is obtained from FedReg. Master data related to commercial and non-Federal customers and payees is covered in the receivable management and payment management chapters in this document.

The term “payee” is used here to refer to an entity to which disbursements may be made (the seller). The term “customer” is used here to refer to an entity that owes a debt to the agency (the buyer).

RBA-01 The system must provide the capability to establish and maintain an agency-assigned customer identifier for Federal customers.

RBA-02 The system must provide the capability to establish and maintain an agency-assigned payee identifier for Federal payees.


RBA-03 The system must maintain customer and payee (Federal trading partner) data from FedReg, which requires fully supporting all FedReg data formats. For example, system data types must be consistent with FedReg data types, and system field lengths must be equal to or greater than FedReg field lengths.

RBA-04 The system must interface customer and payee data from FedReg no less frequently than daily.

RBA-05 The system must provide the capability to prevent unauthorized users from manually updating customer and payee data that originated in FedReg.

9.2 ESTABLISHMENT OF REIMBURSABLE AGREEMENT

This subfunction addresses the establishment of a reimbursable or interagency agreement ensuring that all data elements necessary for tracking the agreement are captured by the system.

This subfunction will be updated after the reimbursable management standard business process is finalized.

RBB-01 The system must provide the capability to capture reimbursable agreement data elements, including the following:

Reimbursable agreement number

Reimbursable agreement amount

Billing limit

Billing terms

Accounting classification information.

9.3 BILLING, COLLECTIONS, AND PAYMENTS UNDER REIMBURSABLE AGREEMENTS

This subfunction covers capabilities related to the execution of a reimbursable agreement by both the seller and the buyer. Activities of the seller include billing and collecting under a reimbursable agreement. Activities of the buyer include obligating and disbursing monies under a reimbursable agreement. Some activities that are not unique to reimbursable management, such as obligating funds are covered by other subfunctions and not duplicated in this subfunction. This subfunction also covers the processing of collections and payments through the Treasury intragovernmental transaction system.


RBC-01 The system must provide automated functionality that determines amounts to be billed consistent with reimbursable agreement billing terms, including the following:

Percentage of work completed

Accrued expenditures

Actual costs incurred (direct and indirect).

RBC-02 The system must provide automated functionality that monitors the cumulative amount billed for a given reimbursable agreement and applies the agency-defined validation edits (reject further attempts to bill, or warn the user) when the authorized amount (i.e., billing limit) on the reimbursable agreement has been or is about to be exceeded.

RBC-03 The system must provide automated functionality that records revenue collected under a reimbursable (interagency) agreement and updates the earned revenue balance on the reimbursable agreement.

RBC-04 The system must provide automated functionality that records advances (unearned revenue) received under reimbursable agreements and updates the advance balances of the reimbursable agreements.

RBC-05 The system must provide automated functionality that records a refund payable when advances collected exceed the amount expended or billed on a reimbursable agreement after all work is performed and that updates the advance balances of reimbursable agreements.

RBC-06 The system must have the capability to capture data related to intragovernmental transactions (e.g., IPAC transactions), including the following:

Interagency agreement number

Voucher number

USSGL comments with Treasury system (e.g., IPAC) disbursement and collection transactions

Sender/originator TAS

Sender ALC

Sender USSGL account

Sender BETC

Sender DO symbol

Sender DUNS number

Sender DUNS+4 number

Customer/receiver TAS

Customer ALC

Customer USSGL account

Customer DUNS number

Customer DUNS+4 number


Customer BETC

Customer department code.

RBC-07 The system must provide automated functionality that generates and exports bulk files for intragovernmental payments and collections in the formats required by Treasury systems that perform intragovernmental transactions (e.g., IPAC).

RBC-08 The system must provide the capability to validate FedReg information required for generating the bulk file for intragovernmental payments and collections (e.g., IPAC bulk file).

RBC-09 The system must record transactions to reflect disbursement activity initiated by other agencies and recorded in the Treasury system that performs intragovernmental disbursements and collections (e.g., IPAC).

Core Financial System Requirements Technical Capability Function

10 TECHNICAL CAPABILITY FUNCTION

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:

General design/architecture (TLA)

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 core financial systems. Individual agencies are encouraged to add specific interoperability, system performance, and workload requirements considered unique to their respective IT environments when evaluating software products for acquisition.

10.1 GENERAL DESIGN/ARCHITECTURE

The general design/architecture requirements relate to the overall product and its structure at the highest level. The basic design features and system architecture determine the adaptability of the system, such as customization and upgradability. A


core financial system must be designed with the flexibility to respond to the changing Federal environment.

TLA-01 The delivered system must be modular and highly scalable, and it must incorporate an open-systems architecture.

TLA-02 The delivered system must be customizable to meet agency-defined business practices.

TLA-03 The delivered system must be upgradable to accommodate changes in laws, regulations, best practices, or new technology.

TLA-04 The 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, 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 API.

TLA-05 The system must 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).

10.2 USER INTERFACES

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

TLC-01 The system must deliver at least one online GUI that, at the agency’s discretion, can provide consistent data entry, navigation, and information presentation across all modules and subsystems used in the online transaction processing environment to satisfy core financial system requirements.

TLC-02 The system must comply with Section 508 of the Rehabilitation Act provisions, as detailed in 36 CFR 1194, Subpart B.

TLC-03 The system must provide a context-sensitive, online help facility that is customizable by the agency.

TLC-04 The system must provide the capability to customize error message text.

TLC-05 The system must provide automated functionality that increases system usability for end users, including user interface features designed to reduce the amount of direct keying required for


transaction processing. The following are examples of such functionality:

Default values based on system maintained transaction and user profiles

Value look-up tables

Highlighting or accentuating of required fields

Grayed data fields that are unavailable for user entry

Auto tabs

Automatic data recall

Auto-fill text

Cut, copy, and paste

Keyboard shortcuts (function keys to invoke help facility, clear screen, etc.)

Menu mode of screen navigation

Undo/redo

Disabling of unsupported 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.

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

TLD-01 The system must provide automated functionality that imports and processes standard transactions generated by other systems.

TLD-03 The system must process interfaced transactions applying the same business rules, program logic, and validity checks used by the system in processing transactions submitted through a GUI.


TLD-04 The system must deliver the capability to 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 reprocess transactions

Report reprocessed transactions.

TLD-05 The system must deliver strong interface processing controls that ensure both real-time and batch files are received from authorized sources, are complete, and are not duplicates. For batch processing, the interface controls must ensure the following:

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.

TLD-06 The system must provide the automated capability to capture interface transactions that fail validity checks. Both the reason for the error and the transaction that produced the error must be stored.

TLD-07 The system must provide the automated capability to connect to a SMTP-compliant email system. This capability must include the ability to distribute application-generated text messages with attached files.

TLD-11 The system must provide the automated capability, when needed, to allow those records in a batch processed interface file that pass validity checks to be processed even though some records in the same batch failed the validity checks.

TLD-12 The system must provide the capability to determine interface import statuses like success, pending (for routing to others for further analysis), or reject.

10.4 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 and approval of pending accounting documents).


TLE-01 The system must deliver an integrated workflow management capability to automate internal routing of documents, transactions, forms, or reports for online approval processing.

TLE-02 The system must provide 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 The system must provide 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 The system must enable a single user to establish and maintain multiple approval levels and must 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 a payment request he/she entered, and a certifying officer must not be allowed to schedule a payment he/she certified.

TLE-05 The system must deliver a workflow calendaring capability to generate date-based process exception reports and alerts. For example, the system must notify an accounts payable office when payment requests are held over 30 days with no matching receiving report.

TLE-06 The system must provide the capability to capture approval actions by transaction, including the time and date and the user ID of the approving official.

TLE-07 The system must deliver automated functionality that routes action requests and status messages internally and externally to individuals, groups, and trading partners using communication channels, including agency email, Blackberry, and internal application messaging.

TLE-08 The system must provide the capability to generate workflow event-based user alerts. For example, it must notify a traveler when an emergency travel voucher is approved.

TLE-09 The system must deliver automated functionality that generates user alerts based on agency-defined thresholds (trigger events) (for example, notify a budget officer when available funds reach 50% of the allotment).

10.5 DOCUMENT MANAGEMENT

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


TLF-01 The system must provide the capability to index and store file reference materials received or generated by the agency in electronic format.

TLF-02 The system must provide 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, or vendor payment request).

10.6 INTERNET ACCESS

The Internet is a vast collection of interconnected networks that communicate using Transmission Control Protocol/Internet Protocol (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.

TLG-01 The delivered system must support TCP/IP for application component connectivity.

TLG-02 The system must deliver browser access to all system modules/functionality.

TLG-03 The system must provide the capability to receive vendor payment requests and payments from the public via the Internet.

TLG-04 The system must support secure Internet access to the integrated ad hoc data query facility.

10.7 SECURITY

Security controls are needed to protect the confidentiality, integrity, and availability of financial data maintained in the core financial system. To meet security requirements, the core financial system must comply with approved standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets as 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 must 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 must 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 OMB Circular No. A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular No. A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in OMB Circular No. A-130, Appendix III.

TLH-01 The system must deliver integrated security functionality compliant with the current NIST security standards.

TLH-02 The system must ensure that the management, operations, and technical baseline security controls are implemented in accordance with current FIPS 199 Standards for Security Categorization of Federal Information and Information Systems and other current NIST guidance on selecting the appropriate security controls.

TLH-03 The system must provide the capability to control function access (e.g., system modules, transactions, approval authorities) and data access (create, read, update, delete) by attribute:

User ID

Functional role (e.g., payable technician)

Organization.

The system must enable the agency to define access rules based on any combination of these attributes.

TLH-04 The system must consistently enforce the appropriate security controls in all modules, including software used for ad hoc data query and report generators.

TLH-05 The system must provide the capability to restrict access to sensitive data elements, such as social security numbers, banking information by user ID, assigned role, and organization.


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

TLI-01 The system must deliver a process scheduling capability that allows the agency to define, initiate, monitor, and stop system processes (e.g., online availability, batch jobs, and system maintenance).

TLI-02 The system must maintain internal database consistency at all times. In the event of a system failure, the system must have the capability to do the following:

Back out incompletely processed transactions

Restore the system to its last consistent state before the failure occurred

Reapply all incomplete transactions previously submitted by the user

Validate internal database consistency to ensure that duplicate postings are avoided

Report any data or transactions that failed to process completely.

TLI-03 The system must generate online status messages to the operator that indicate the job or transaction type, name, time processing initiates, time processing is completed, and any processing errors encountered.

TLI-04 The system must deliver a restart capability for all application online and batch-processing components. Batch jobs must be segmented to facilitate restart in the event of a system failure.

TLI-05 The system must deliver common error-handling routines across functional modules, and it must generate meaningful, traceable error messages that allow the user or system operator to identify and respond to reported problems.

TLI-06 The system must provide a document archiving capability, including 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.

TLI-07 The system must support data archiving and record retention in accordance with rules published by NARA, GAO, and NIST.

TLI-08 The system must provide the capability to restore archived data based on agency-defined criteria such as date, accounting period, or vendor/customer.


TLI-09 The system must deliver an event logging capability for systems, transactions, tables, and system parameters. The logs must include the following:

User ID

System date and time

Type of activity (addition, modification, deletion)

Old value

New value.

For example, the system must provide a log of all attempts to log on to the system or a log of changes made to the interest values in a prompt payment interest rate table.

TLI-10 The system must provide the automated capability to maintain and report application usage statistics. Productivity statistics should include concurrent users, job submissions, transactions throughput, and system availability.

TLI-11 The system must provide the capability to simulate different dates to support testing over multiple periods.

TLI-12 The system must provide the capability to process queued jobs (reports, transaction files from interfacing systems, bulk record updates) with no online performance degradation.

TLI-13 The system must provide the capability to customize system logging features. The system must allow the agency to specify which parameters (or tables) to log and must allow the agency to turn logging feature on or off as needed.

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

TLJ-01 The system must deliver an integrated ad hoc query capability to support agency access to and analysis of system-maintained financial data.

TLJ-02 The system must provide the capability to define parameter-based query scripts that can be queued for execution, stored for reuse, and shared with other authorized agency users.


TLJ-03 The system must process submitted queries and queue output online for access by authorized users.

TLJ-04 The system must route query results to designated individuals or groups of individuals or notify individuals that query results are available online.

TLJ-05 The system must deliver run-time controls to prevent “run-away” queries and to restrict very large data download requests.

TLJ-06 The system must provide the capability to display graphical output on the desktop with dynamic report reformatting.

TLJ-07 The system must deliver an online drill-down capability from summary amounts in queries to supporting detail records.

TLJ-08 The system must provide the capability to download selected query data and to reformat downloaded query information for direct access by common desktop applications (spreadsheet, ASCII text, comma-delimited text, etc.).

TLJ-09 The system must provide the capability to preview a query, form, report, or other result before printing.

TLJ-10 The system must provide the capability to access current-year and historical financial data.

TLJ-11 The system must deliver the following ad hoc query interface features:

Graphical display of data sources

Ability to point and click on table, data, and link objects for inclusion in a custom query

Access to object definitions through a data dictionary.

10.10 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 provided with the software product must be written at a sufficient level of detail that users who are familiar with core financial system functions in general, but are new to the product, can understand and use the documentation without assistance from the vendor.


TLK-01 The system must be delivered with documentation that identifies all software and hardware products needed by an agency to install, operate, access, and maintain the application. The 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.

TLK-02 The system must be delivered with application design 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-arounds.

TLK-03 The system must be delivered with product installation and maintenance documentation. Installation documentation must describe the following items:

Product release content

Third-party software configuration requirements

Database installation steps

Directory structure for locating application data, programs, files, and tables, including drive mappings

Hardware driver installation and configuration

Application security setup and maintenance

Software configuration instructions

Operating parameter definitions and any other required setup 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.


TLK-04 The system must be delivered with system operations and user manuals. Documentation must explain the following system operations:

System start-up

Shutdown

Monitoring

Recovery and restart

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

General ledger and transaction maintenance

Year-end processing

Error codes with descriptions

Recovery steps

Troubleshooting procedures.

TLK-05 The system must be delivered with 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.

10.11 SYSTEM PERFORMANCE

This section defines system performance categories that need to be considered when evaluating software products for potential acquisition. These requirements were written without specific (i.e., testable) performance criteria. Recognizing that delivered product 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).


TLL-01 The system must process the agency’s specified accounting workload without adversely impacting projected online response times.

TLL-02 The system must process scheduled work (e.g., batch jobs) within an agency-specified batch-processing window. Scheduled work can include the following:

Daily system assurance reports

Daily backups

Daily interface processing

General ledger posting

Table updates

Standard reporting.

TLL-03 The system must maintain the agency’s specified current 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.

TLL-04 The system must support concurrent access to functional modules for the agency’s specified user community.

TLL-05 The system must be delivered with computing performance metrics for platforms and systems environments on which the application is certified to run. Performance metrics provided by the vendor should describe the following:

Transaction processing throughput capacity

Expected workstation client response time by transaction type

Data storage capacity

Limitations on concurrent user connectivity.

Core Financial System Requirements Appendices

APPENDICES

Core Financial System Requirements Changes to Core Financial System Requirements

APPENDIX A CHANGES TO CORE FINANCIAL SYSTEM REQUIREMENTS

The Federal government has been using automated systems to support accounting and financial management for years. Federal financial management requirements were defined as agencies sought to acquire software products that would most closely fit their business needs. In 1988, JFMIP brought together requirements that had been defined by many agencies into a single set and published them as Core Financial System Requirements. Since then, JFMIP and its successor organization, FSIO, published requirements in 1994, 1999, 2001, and 2006. This document represents the most recent update to the requirements.

Changes have been made to this document for the following reasons:

To align the requirements with Standard Federal Financial Business Processes, published by FSIO under the FMLoB. This document reflects changes made to requirements to align with the standard business processes for funds management, payment management, and receivable management. Changes to requirements resulting from standardization of reports management and reimbursable management will be reflected in a subsequent publication.

To remove budget formulation requirements in recognition of their ownership by the budget community and the Budget Formulation and Execution Line of Business.

To remove value-added requirements. All of the requirements in this document are mandatory.

To reorganize requirements into more logical groupings. Requirements related to reimbursable management and financial reporting have been moved to separate sections.

Additional changes to this document include the reinsertion of the glossary and the rewording of requirement text, wherever needed, to help clarify the intent. Several functional areas have not been substantially changed. These include the cost management function and the FBWT management function. The FBWT requirements will be updated once the Department of the Treasury finalizes changes to the central accounting systems.

Core Financial System Requirements Accounting Standards, Laws, Regulations, and Other Guidance

APPENDIX B ACCOUNTING STANDARDS, LAWS, REGULATIONS, AND OTHER GUIDANCE

B.1 INTRODUCTION

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

Federal Legislation

U.S. Code

Statements of Federal Financial Accounting Concepts and Standards

Office of Management and Budget Guidance

Treasury Financial Manual

Other Federal Standards, Guidelines, and Regulations

Federal Financial Management System Requirements

Financial Management Line of Business Standards.

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.

B.2 FEDERAL LEGISLATION

Accountability of Tax Dollars Act of 2002

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

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

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

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

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

Economy Act (31 U.S.C. 1535)

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


Federal Managers’ Financial Integrity Act of 1982 (Pub. L. 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. 93-502) (5 U.S.C. 52)

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

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

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

Improper Payments Information Act of 2002

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

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

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

Privacy Act of 1974 (Pub. L. 93-579)

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

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

Reports Consolidation Act of 2000

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

Tax Increase Prevention and Reconciliation Act of 2005

B.3 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 “Antideficiency 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 No. A-125, Prompt Payment.

B.4 STATEMENTS OF FEDERAL FINANCIAL ACCOUNTING CONCEPTS AND STANDARDS

FASAB is responsible for developing accounting standards for the U.S. government. These standards are recognized as generally accepted accounting principles (GAAP) for the Federal government and are applied by Federal agencies in preparing financial statements. FASAB publishes these standards in Statements of Federal Financial Accounting Standards (SFFAS), Interpretations, Technical Bulletins, Technical Releases, and Staff Implementation Guides. In addition to the standards, FASAB publishes Statements of Federal Financial Accounting Concepts that are not GAAP but that provide a framework of objectives and concepts describing the purposes, content, and characteristics of information provided in Federal financial reports.

FASAB’s standards foster financial information and reporting that is understandable, relevant, and reliable concerning the financial position, activities, and results of operations for the Federal government and its departments and agencies. Furthermore, the standards prescribe accounting systems and internal controls that help demonstrate that Federal programs are in compliance with laws and regulations.

The following concepts and standards are particularly relevant to core financial system requirements.

SFFAC 1, Objectives of Federal Financial Reporting

SFFAC 2, Entity and Display

SFFAS 1, Accounting for Selected Assets and Liabilities

SFFAS 4, Managerial Cost Accounting Concepts and Standards

SFFAS 5, Accounting for Liabilities of the Federal Government

SFFAS 7, Accounting for Revenue and Other Financing Sources.


B.5 OFFICE OF MANAGEMENT AND BUDGET GUIDANCE

OMB provides guidance and standards for executive departments and agencies to follow concerning preparation and execution of the budget, management and implementation of financial systems, internal controls, and preparation of financial reports:

OMB Circular No. A-11, Preparation, Submission, and Execution of the Budget, provides guidance on preparing and submitting materials to OMB in support of agency budget requests and includes instructions on budget execution. It provides guidance on the apportionment and reapportionment process, report on budget execution and budgetary resources (SF 133), and a checklist for fund control regulations. It establishes formats and values for classification elements such as budget accounts, subfunction classes, and object classes used for reporting budget data through the OMB MAX A-11 Data Entry System (MAX).

OMB Circular No. A-127, Financial Management Systems, prescribes policies and standards for executive departments and agencies to follow when managing their financial management systems. This circular requires agencies to use a FSIO-certified core financial system that is a commercial off-the-shelf system, to use a certified configuration, to adopt standard financial business practices,9 and to use financial management SSPs to implement and maintain their core financial system. In addition, the circular includes and clarifies the guidance for reporting substantial compliance with FFMIA.

OMB Circular No. A-123, Management’s Responsibility for Internal Control, requires internal controls to be in place over information systems. These controls include ensuring that transactions are properly authorized and processed accurately and that data are valid and complete. Controls should also be established in the applications interface to verify the data input and output.

OMB Circular No. A-130, Management of Federal Information Resources, requires agencies to use commercial off-the-shelf 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. It also provides guidance on collecting and managing information and records management, as well as on managing information systems and information technology.

OMB Circular No. A-136, Financial Reporting Requirements, provides guidance on preparing an agency’s Performance and Accountability Report and the Agency Financial Report, as well as on the form and content of annual financial statements.

9 The standard business processes are defined by FSIO in Standard Federal Financial Business Processes.


Many of the standards and policies reflected in these OMB circulars, especially with respect to funds control, budget execution, internal controls, and preparation of financial statements, are incorporated into Core Financial System Requirements.

Financial management guidance is also provided in OMB Circular No. A-25, User Charges, and OMB Circular No. A-134, Financial Accounting Principles and Standards.

B.6 TREASURY FINANCIAL MANUAL

Treasury’s Financial Management Service (FMS) publishes the TFM, which provides guidance to Federal agencies on central accounting and reporting and on other fiscal matters. The underlying purpose of Treasury’s guidance is to make it possible to consolidate accounting results of all agencies and to report on the financial operations of the Federal government. Two parts of the TFM are of particular relevance to core financial systems:

Volume I, Part 2, of the TFM includes requirements for the form, content, and submission of financial data required by FMS.

U.S. Standard General Ledger, a supplement to the TFM, provides a uniform chart of accounts and standard posting logic (transaction codes) for recording financial events across government. The USSGL also includes cross-walks that map the general ledger accounts to standard external reports required by OMB and FMS.

Key sections of the Treasury Financial Manual include the following:

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

I TFM 2-3300, Statement of Transactions (FMS 224) Reporting by Agencies for which the Treasury Disburses

I TFM 2-4100, Debt Management Reports

I TFM 2-4700, Agency Reporting Requirements for the Financial Report of the United States Government

I TFM 4-2000, Payment Issue Disbursing Procedures

I TFM 4-7000, Cancellations, Deposits, and Claims for Checks Drawn on the U.S. Treasury

I TFM 6-3100, Certifying Payments and Recording Corresponding Intragovernmental Receivables in the Federal Government’s Judgment Fund

I TFM 6-4000, Intra-Governmental Payment and Collection (IPAC) System


I TFM 6-5000, Administrative Accounting Systems Requirements in Support of the Debt Collection Improvement Act of 1996

I TFM 6-5100, Recovering Unclaimed Federal Financial Assets

I TFM 6-8040, Disbursements

I TFM 6-8500, Cash Forecasting Requirements

TFM Supplement S2 08-03, U.S. Government Standard General Ledger

TFM Supplement for Treasury Report on Receivables and Debt Collection Activities.

B.7 OTHER FEDERAL STANDARDS, GUIDELINES, AND REGULATIONS

Electronic and Information Technology Accessibility Standards (issued by the Architectural and Transportation Barriers Compliance Board) as required by Section 508 of the Rehabilitation Act) (http://www.access-board.gov/508.htm)

Federal regulations established by the National Archives and Records Administration (www.nara.gov)

Federal regulations issued by the National Institute of Standards and Technology (www.nist.gov)

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

B.8 FEDERAL FINANCIAL MANAGEMENT SYSTEM REQUIREMENTS

Acquisition/Financial Systems Interface Requirements, June 2002

Benefit System Requirements, September 2001

Core Financial System Requirements, February 1999, November 2001, January 2006

Direct Loan System Requirements, June 1999

Framework for Federal Financial Management Systems, January 1995, April 2004

Grant Financial System Requirements, June 2000

Guaranteed Loan System Requirements, March 2000

Human Resources and Payroll System Requirements, April 1999

Inventory, Supplies, and Materials System Requirements, August 2003

Managerial Cost Accounting Implementation Guide, February 1998

Managerial Cost Accounting System Requirements, February 1998

Property Management System Requirements, October 2000


Revenue System Requirements Document, January 2003

Seized Property and Forfeited Assets System Requirements, December 1999

Travel System Requirements, July 1999

B.9 FINANCIAL MANAGEMENT LINE OF BUSINESS STANDARDS

Common Government-wide Accounting Classification Structure, Version 1.0, July 2007

Standard Federal Financial Business Processes, November 2008 (includes funds management, payment management, and receivable management processes)

Standard Federal Financial Business Processes, Reports Management Exposure Draft, February 2009

Standard Federal Financial Business Processes, Reimbursables Management Exposure Draft, March 2009

Core Financial System Requirements Requirement Drafting Guidelines

APPENDIX C REQUIREMENT DRAFTING GUIDELINES

Our goal is to publish a comprehensive set of 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 requirements, we have adopted standard drafting guidelines.

C.1 REQUIREMENT INTRODUCTORY PHRASES

Our drafting guidelines call for starting every requirement with a standard phrase such as “The core financial system must provide automated functionality that…” Table 1 shows the standard phrases we used.

Table 1. Requirement Introductory Phrases

Introductory Phrase Explanation of Use

The system must provide the capability to …

The capability must be delivered whether or not the agency chooses to use it. (The capability may or may not be used by all agencies in all implementations.)

The system must provide the automated capability to …

The automated capability must be delivered whether or not the agency chooses to use it. (The capability may or may not be used by all agencies in all implementations.) The requirement is to be performed by the system without manual intervention.

The system must provide automated functionality that …

The functionality must be delivered and performed by the system in all implementations, as it is inherent in a Federal implementation (e.g., prompt payment functionality). However, there may be conditions under which it is not applicable. The requirement is to be performed by the system without manual intervention.

The system must provide the capability to allow a user to …

The capability must be at the discretion of a user; user intervention is required.

The system must allow a qualified end user to …

Expert knowledge is required to effectively and correctly trigger the system operation.

The system must allow an authorized end user to …

Special authorization is required to simultaneously satisfy this requirement and system management and financial management internal control requirements.

The system must be delivered prepopulated with …

The requirement specifies governmentwide data values that must be provided with the product.

C.2 REQUIREMENT TYPES

The requirement types found in this document are as follows:


Configuration requirements describe functionality needed by an agency to establish and maintain master data, access rights, and business rules.

Input requirements describe the different types of information that is captured by the system. Input requirements cover individual data items and documents.

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.

Report requirements describe system-generated outputs that are subject to defined form and content rules and queries used for accessing information in the system.

Interface requirements define the need to exchange data internally within the agency or externally with a governmentwide system. An example of an internal interface is an acquisition system that generates transactions needed to establish commitments in the core financial system. An example of an external interface is the generation of a payment file suitable for transmission to Treasury’s disbursing system.

C.3 KEY VERBS USED

In addition to starting every requirement with a standard phrase, our drafting guidelines call for the use of a standard verb.

The key verbs used in this document are explained in alphabetical order as follows.

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:

The system must provide the automated capability to associate each combination of the DUNS and DUNS+4 numbers with one and only one bank account for each CCR vendor. (PMA-09)

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

The system must provide automated functionality that calculates multiple due dates when lines on a payment request have different payment terms. (PMD-02)

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 derived. The ability to subsequently retrieve, modify, or delete captured information is assumed. For example:

The system must provide the capability to capture payment terms on obligations that are different than those specified on the associated vendor record. (FME-36)

We use “classify” when referring to the capability to categorize financial transactions along various dimensions in order to enable retrieval, summarization, and reporting of information. For example:

The system must classify transactions by any element of the accounting classification structure, including any of the five agency mission-specific classification elements. (SMA-03)

We use “customize” when referring to the ability for an agency to enter new and modified displayed text, field labels, report titles, column headings, or user interface settings. For example:

The system must provide the capability to customize the text and data elements to be displayed on system-generated bills, by customer type, receivable type, or billing method. For example, a 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-11)

We use “deactivate” when referring to making a master data element or record inactive. For example:

The system must provide the capability to deactivate payees on demand or based on agency-specified length of time with no activity. (PMA-14)

We use “define” when the intention of the requirement is to allow a qualified end user to specify edits, business rules, workflows, code values, or other conditional processes. For example:

The system must provide the capability to allow a user to define payment methods as EFT, check, IPAC, or interfund transfer. (PMA-19)

We use “deliver” to specify nonfunctional features that must be included as part of the baseline product. For example:

The system must deliver the core financial system software prepopulated with the current published values for the USSGL chart of accounts. (GLA-09)

We use “derive” when referring to functionality the system uses in applying business rules. For example:

The system must provide the capability to capture or derive USSGL account attributes used to classify accounting transactions for reporting to Treasury systems (e.g., FACTS I, FACTS II, GFRS, or GTAS). (GLC-02)


We use “determine” when requiring the system to choose the appropriate action based on predefined business rules. For example:

The system must provide automated functionality that determines if upward and downward spending adjustments are to expired or to unexpired budget authority and uses that determination to derive and record the USSGL-prescribed spending adjustment entry. (GLD-03)

We use “distribute” when referring to allotting funds or the assignment of accumulated costs. For example:

The system must provide the capability to distribute funds below the level at which they are controlled. (FMD-14)

We use “establish” to specify functionality that allows direct entry or import of system referential data or master data. For example:

The system must provide the capability to allow a user to establish and maintain reason codes and related descriptions to identify discrepancies related to the receipt and acceptance of goods and/or services. (PMB-08)

We use “export” when the intention of the requirement is to generate and transport a transaction file external to the confines of the core system. For example:

The system must provide automated functionality that generates and exports bulk files for intragovernmental payments and collections in the formats required by Treasury systems that perform intragovernmental transactions (e.g., IPAC). (RBC-07)

We use “generate” when specifying requirements where the system must produce a formatted output. For example:

The system must have the automated capability to generate check and EFT payment files in the current Treasury FMS-defined formats for both Treasury and non-Treasury disbursing offices. (PMD-20)

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

The system must identify when posting transactions will invoke upward spending adjustments and apply the agency-defined funds control edits. (GLD-08)

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


The system must provide the automated capability to import payment confirmation data from a Treasury governmentwide system (e.g., SPS, PAM, or GOALS II/IAS RFC Agency Link). (FBB-01)

We use “link” when referring to establishing a relationship between data records. A link is normally created automatically by the underlying database software when new records are added. For example:

The system must provide the automated capability to link multiple DUNS+4 numbers to a single DUNS number. (PMA-08)

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

The system must provide automated functionality that liquidates individual disbursement-in-transit transactions and records confirmed disbursements upon receipt of payment confirmation from a Treasury governmentwide system (e.g., SPS, PAM, or GOALS II/IAS RFC Agency Link). (FBB-02)

We use “maintain” when requiring the system to store master data elements, business rules, or other data (e.g., spending plan data) used in the processing of transactions. For example:

The system must provide the capability to allow a qualified end user to establish and maintain agency-specific obligation types to identify the activity that initiated the obligation such as a travel order, purchase order, grant award, task order, work order, or BPA call. (FME-22)

We use “monitor” to refer to the comparison of an accumulated amount against an established limit. For example:

The system must provide automated functionality that monitors the cumulative amount billed for a given reimbursable agreement and applies the agency-defined validation edits (reject further attempts to bill, or warn the user) when the authorized amount (i.e., billing limit) on the reimbursable agreement has been or is about to be exceeded. (RBC-02)

We use “notify” (“notifies”) when the requirement is for the system to issue an electronic message, such as an email or other online message to inform a user or external party of an event or processing exception. For example:

The system must provide automated functionality that notifies the user when online documents fail funds control edits, transaction processing edits, or tolerance checks. The system must provide the notification on the document entry screen and include the nature of each error and the validation edit (rejection, warning, or information only). The system must retain errors with the document until they have been resolved. (SMB-12)


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:

The system must prevent unauthorized users from manually updating CCR-originated data in the payee information file. (PMA-06)

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:

The system must provide the capability to record transactions to any open accounting period and must provide the option to keep multiple accounting periods (minimum of two) open simultaneously. (GLF-02)

We use “reference” to refer to the association of document line items to prior document lines and their automatic liquidation. For example:

The system must provide the capability to reference multiple documents, document lines, and accounting lines in a processing chain. For example, it must provide the capability for an obligating document to reference multiple commitment documents, commitment document lines, and commitment accounting lines. (SMC-08)

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:

The system must provide the capability to suspend documents that fail transaction processing edits, funds control edits, or tolerance checks. (SMB-13)

We use “update” when requiring the system to automatically modify an existing data record or balance (e.g., funds availability or general ledger) or to allow a qualified end user to modify a record. For example:

The system must provide automated functionality that updates payments with the paid schedule number, payment confirmation date, and check number or trace number upon receipt of confirmation data from a Treasury governmentwide system (e.g., SPS, PAM, or GOALS II/IAS RFC Agency Link). (FBB-03)

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


The system must validate USSGL account attributes on transactions (whether entered or derived) prior to the posting. (GLC-03)

C.4 OTHER DRAFTING GUIDELINES

A key objective in drafting the requirements is to avoid ambiguous phrasing such as “as applicable,” or “as appropriate.”

Examples, when included in requirements, 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.”

Definitions of other key terms that could affect an agency’s interpretation of individual requirements can be found in Appendix E, Glossary.

Core Financial System Requirements List of Reports

APPENDIX D LIST OF REPORTS

This appendix lists the standard reports described in Reports Management Standard Business Process. That document groups reports into seven categories:

6.1 Financial Statements. Financial reporting in the Federal government must be in accordance with the CFO Act and GMRA. Moreover, OMB’s OFFM specifies, in OMB Circular No. A-136, the required elements and format of financial reports.

6.2 General Ledger. General ledger reports provide information on overall account balances or transactions supporting those account balances for an organization.

6.3 Payment Management. Payment management reports provide information to support vendor maintenance, invoice tracking, disbursement monitoring, cash flow control, and sound cash management decisions.

6.4 Receivable Management. Receivable management reports provide information to support customer maintenance, receivable tracking, collections, delinquent account monitoring, and effective cash flow management.

6.5 Reimbursable Management. Reimbursable management reports provide information to support reimbursable activity between trading partners, including partnership agreements, work in process, and billing.

6.6 System Management. System management reports provide information that enables the effective control of user access, traceability of modified transactions, and override of established system controls.

6.7 Treasury Reporting. Treasury reports provide information to meet Federally mandated reporting requirements and to support the management of fund balances with Treasury and funds held outside of Treasury.

D.1 FINANCIAL STATEMENTS

Balance Sheet

Balance Sheet–Comparative Analysis

Budgetary Resources–Comparative Analysis


Changes in Net Position–Comparative Analysis

Custodial Activity–Comparative Analysis

Net Cost–Comparative Analysis

Reconciliation of Net Cost of Operations (Proprietary) to Budget

Reconciliation of Net Cost of Operations (Proprietary) to Budgetary Accounts–Comparative Analysis

Statement of Budgetary Resources

Statement of Changes in Net Position

Statement of Custodial Activity

Statement of Net Cost

D.2 GENERAL LEDGER REPORTS

Abnormal Balance

Budget Execution

Chart of Accounts

Daily General Ledger and Subsidiary Ledger Exception Report

Document History

General Ledger Account Activity

General Ledger Account Detailed Activity

Open Commitments

Open Obligations

Status of Funds

Suspense/Error Report

Tie Point Reconciliation

Transaction Register

Trial Balance

D.3 PAYMENT MANAGEMENT REPORTS

CCR Company Name Change Exception


Discounts Lost

Final Payment Register

Interfaced Commitment

Interfaced Obligation

Interfaced Payment Request

IRS Form 1042

IRS Form 1099-G

IRS Form 1099-INT

IRS Form 1099-MISC

Late Payment

Payment Request Aging Report

Payment Request Date Override

Payment Notification

Payments by Vendor

Payments Exceeding Threshold Amounts

Potential 1099 Vendor Address Error

Preliminary Payment Register

Prompt Pay Metric by Payment Request Type

Statistical Sample of Invoices to be Processed for Payment

Vendor File Listing

Vendor File Modification

Vendor Notification of an Improper Payment Request

Vendor Notification of Held Payments

D.4 RECEIVABLE MANAGEMENT REPORTS

Accounts Receivable Aging

Accounts Receivable Collection Referral


Adjustments to Receivables

Allowance for Doubtful Accounts

Average Number of Days Outstanding/Late by Receivable Type

Bill

Collections by Category

Credit Memo

Credit Memo Aging

Customer Activity

Customer File Modification

Dunning Letter

Interfaced Receivable and Collection Transactions

IRS Form 1099-C

Receivables Eligible for Referral to a Third Party Collector

Receivables Eligible for Write-off

Summary of Collections by Category

Summary of Dunning Process

D.5 REIMBURSABLE MANAGEMENT REPORTS

Earned-Unbilled

Inter-agency Agreement Accounting

Inter-agency Agreement Activity

Inventory of Inter-agency Agreements

Reconciliation

Summary of Inter-agency Agreements

Unfilled Customer Orders

Work in Process


D.6 SYSTEM MANAGEMENT REPORTS

Access by Type

Application Usage Statistics

Batch Processing

General Ledger Posting Models

Period Status

System Audit

System Override

Transaction Suspension Report

User Status

D.7 TREASURY REPORTING

Comparison of SF 133, Report on Budget Execution and Resources, and the Statement of Budgetary Resources

Deposit Ticket (DT) (SF 215)

FACTS I (Federal Agencies Centralized Trial Balance System)

FACTS II (Federal Agencies Centralized Trial Balance System)

Federal Transaction File

FMS 2108, Year-End Closing Statement

FMS 1219/1220, Statement of Accountability (FMS) and Transactions (FMS)

Foreign Currency Report

GFRS Statements

GTAS–Adjusted Trial Balance System

Partial 224

Partial 224–Exception Report

SF 133, Report on Budget Execution and Resources

Treasury Report on Receivables and Debt Collection Activities

Core Financial System Requirements Glossary

APPENDIX E GLOSSARY

Accomplished PaymentsA term used by Treasury and agency personnel to refer to payments submitted to Treasury (requested by the agency) and released to the payee by Treasury or a non-Treasury disbursing office on the behalf of that agency.

Accounting Classification StructureThe data elements used for categorizing financial transactions along several dimensions that enable retrieval, summarization, and reporting of information in a meaningful way. An accounting classification structure is a comprehensive language that supports the traceability and data interoperability of financial information to support budget, financial accounting, and performance reporting requirements. It includes multiple classification elements that allow data to be categorized along various dimensions and analyzed from different perspectives to support a variety of information needs.

Accounting LineThe accounting information, including accounting classification elements, general ledger entry, and amount, related to a document line.

Accounting PeriodThe time period in which a transaction is effective in the general ledger. In most instances, this time period pertains to a fiscal month within a fiscal year. In some instances, an accounting period represents a period that falls before or after the fiscal month and is used for recording opening balances to the period or period-end adjustments applicable to a month, quarter, or fiscal year. Accounting periods are used to group transactions by the time period in which they are reported.

Activity“The actual work task or step performed in producing and delivering products and services. An aggregation of actions performed within an organization that is useful for purposes of activity-based costing.”10 An activity in this context is not the same as a “budget activity.” Budget activity is generally another name for a program. Examples of activities include completing a study, preparing financial statements, or maintaining roads.

Adjusted Trial BalanceA list of general ledger accounts and the corresponding balances (including adjustments) as of a specific date. The total debit balances must equal the total credit balances. In reference to FACTS (I and II) reporting, the ATB includes USSGL attributes, and the USSGL account balances should reflect preclosing adjusting entries.

10 SFFAS 4.


Administrative FeeA charge assessed to cover administrative costs incurred as a result of delinquent debt.

Age CategoryA classification of age assigned to receivables owed to a Federal agency (and the Federal government’s debt portfolio). Age categories include “current” as well as the delinquent debt age categories used by Treasury and reported on the TROR (1–90 days, 91–180 days, etc).

AgencyAny executive department, military department, government corporation, government-controlled corporation, or other establishment in the executive branch of the Federal government or any independent regulatory agency.

Agency-AssignedAn indicator that the values used for referential data (e.g., document numbers), master data (e.g., customer identifiers), or other supporting document information were provided by an agency end user or generated by the system based on an agency-defined coding structure.

Agency Location CodeAn identifier of the particular accounting office within an agency that reports disbursements and collections to Treasury. The ALC is required when reporting transactions through the GWA system and on the FMS 224, Statement of Transactions; FMS 1218 and 1219, Statement of Accountability; and FMS 1220 and 1221, Statement of Transactions.

AllotmentAuthority delegated by the head or other authorized employee of an agency to agency employees to incur obligations within a specified amount, pursuant to OMB apportionment or reapportionment action or other statutory authority making funds available for obligation.

Application (Financial or Mixed System)A group of interrelated components supporting one or more functions and having the following characteristics: a common database, common data element definitions, standardized processing for similar types of transactions, and common version control over software.

ApportionmentA distribution made by OMB of amounts available for obligation in an appropriation or fund account into amounts available for specified time periods, programs, activities, projects, objects, or any combinations of these. The apportioned amount limits the obligations that may be incurred. An apportionment may be further subdivided by an agency into allotments, suballotments, and allocations.

AppropriationA provision of law (not necessarily in an appropriation act) authorizing the expenditure of funds for a given purpose. Usually, but not always, an appropriation provides budget authority.


ATB CodeA unique identifier code for a record in the Master Appropriation File. The code denotes a department, bureau, and Treasury appropriation/fund group.

Attribute DomainsThe possible valid choices within an attribute. For example, the valid domains for the Direct or Reimbursable Code attribute are D (for Direct) and R (for Reimbursable).

AutomaticallyThe occurrence of a system process or operation that happens without manual intervention, but based on defined business rules.

Borrowing AuthorityA type of budget authority that permits obligations and outlays to be financed by borrowing.

BudgetThe budget of the U.S. Government, which sets forth the President’s comprehensive financial plan for allocating resources and indicates the President’s priorities for the Federal government.

Budget AccountAccounts that finance the programs and activities of the Federal government. Budget accounts include the expenditure accounts and receipt accounts that are presented in the President’s Budget. A budget account may be composed of one or more Treasury accounts.

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

Budget Fiscal YearThe fiscal year in which an obligation is made and captured on the obligating document. Used to distinguish whether subsequent adjustments affect a prior year or the current year. Agencies must maintain the budget fiscal year in their obligating documents to properly use the USSGL-prescribed entries for recording both upward and downward prior-year adjustments. Agencies must retain the budget fiscal year on the obligating document even when the obligation remains unliquidated in a subsequent fiscal year.

Budgetary ResourceAn amount available to enter into new obligations and to liquidate them. Budgetary resources are made up of new budget authority (including direct spending authority provided in existing statute and obligation limitations) and of unobligated balances of budget authority provided in previous years.

BureauA major suborganization of an agency. Sometimes called administration, service, or agency. Not all agencies have bureaus.


Business Event Type CodeUsed to classify transactions that are reported to Treasury through all GWA-compliant FMS systems. Used in combination with the Treasury Account Symbol to identify the type of activity (gross disbursement, offsetting collection, investment in Treasury securities, etc.) and the effect of a transaction on the FBWT.

CancellationThe process of rendering a check nonnegotiable after it has been issued and of repaying the amount of the check (whether available or unavailable) to an appropriation or fund account.

CA$HLINKA Treasury system used primarily to manage the collection of U.S. Government funds and to provide deposit information to Federal agencies.

Central Contractor RegistrationThe primary vendor database for all Federal agencies, maintained by the Integrated Acquisition Environment. The CCR collects, validates, stores, and disseminates data concerning all parties that receive payments from the Federal government. Agencies that engage in buying or selling goods/services to other Federal agencies are required to register in FedReg.

Closeout (a debt)An event that occurs concurrently with, or subsequent to, an agency decision to write off a debt for which the agency has determined that future additional collection attempts would be futile. At closeout, an agency reports to the IRS the amount of the closed out debt as income to the debtor on IRS Form 1099-C, in accordance with Treasury requirements. No additional collection action may be taken by the agency after issuing the IRS Form 1099-C.

CollectionA transfer of money from a source outside the Federal government to an agency or to a financial institution acting as an agent of the U.S. Government. A collection by the government may be recorded in the budget as a receipt, an offsetting collection, or an offsetting receipt.

CommitmentThe amount of allotment or suballotment set aside in anticipation of an obligation.

Compromise (a debt)An agreement to settle a debt at a lower amount than initially claimed.

Continuing ResolutionJoint resolution that provides continuing appropriations for a fiscal year. Continuing resolutions are enacted when Congress has not yet passed new appropriation bills and a program’s appropriations are about to expire or have expired, or when the President has vetoed congressionally passed appropriations bills.

Contract AuthorityA type of budget authority that permits an agency to incur obligations in advance of an appropriation, offsetting collections, or receipts to make outlays to liquidate the


obligations. Typically, Congress provides contract authority in an authorizing statute to allow the agency to incur obligations in anticipation of the collection of receipts or offsetting collections that will be used to liquidate the obligations.

Core Financial SystemAn information system that supports the key functions of an agency’s financial management, including general ledger management, funds management, payment management, receivable management, reimbursable management, FBWT management, cost management, and financial reporting. The core financial system is the system of record that maintains all transactions resulting from financial events. It is used for collecting, processing, maintaining, transmitting, and reporting data regarding financial events. Other uses include supporting financial planning and budgeting activities. The applications that make up the core financial system may be tightly integrated through a common database or interface electronically to meet defined data and processing requirements.

CostThe monetary value or quantity 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.

Cost CenterA logical grouping of one or more related activities or organizational units into a common pool for the purpose of identifying the cost incurred. As an example, an agency could collect all costs associated with a specific building into a common pool (cost center) and then allocate them to specific outputs or activities.

Cost ObjectAny activity, output, or item whose cost and revenue are to be measured, such as organizational units, programs, and projects.

CustomerAny entity, including employees and other government agencies, that purchases goods or services from the agency or that owes a debt to the agency. A vendor may become a customer of the agency, in the event that the agency overpays the vendor.

DisbursementA payment made using cash, a check, or an electronic transfer in which Federal moneys are transferred to an outside recipient or to another Federal agency. Disbursements include advances to others, payments for goods and services received, and other types of payments.

Disbursing OfficeOffices of the Treasury Financial Management Service, established to provide disbursing services for Federal agencies. Also referred to as RFCs.

DocumentThe complete electronic record of a captured financial event. This record can include descriptive data, processing dates (transaction date, system date, accounting period), balances, accounting lines, general ledger transaction history, referenced data records, and audit trail entries.


Document LineA line of information about the document being recorded. The document line includes information such as dollar amount, description, quantity, and unit price (if applicable). A document can have multiple document lines and each document line can have one or more accounting lines.

Document NumberA number or text string used to uniquely identify a document captured by the system. Document numbers can be system generated or assigned by an end user when a new document is entered.

Document StatusThe current processing state of a document in the system.

Document TypeA document classification used to identify like accounting events—for example, appropriations, commitments, payment vouchers, receivables, and closing entries—processed by the system.

Electronic Funds TransferAny deposit or payment accomplished electronically, including wire transfers via CA$HLINK and Taxlink, Fedwire, and Vendor Express.

Expended AuthorityPaid and unpaid expenditures for goods and tangible property received, or services performed by employees, contractors, vendors, carriers, grantees, lessors, or other government organizations. Expended authority also includes amounts becoming owed under programs for which no current service or performance is required (annuities, insurance claims, other benefit payments, etc.).

ExpenditureThe actual spending of money; an outlay.

ExpenseThe outflow of assets or incurrence of liabilities during a period resulting from rendering services, delivering or producing goods, or carrying out other normal operating activities.

Federal Agencies Centralized Trial-Balance System (FACTS)System used by agencies to electronically transmit a preclosing adjusted trial balance at the TAS level (FACTS II) or fund group level (FACTS I) using USSGL accounts and other specified elements. FACTS I supports consolidated financial statement reporting. FACTS II supports centralized budget execution reporting.

Federal Agency RegistrationA requirement in OMB Memorandum M-03-01 and Treasury Financial Manual Bulletin 2007-03, Intergovernmental Business Rules that all Federal agencies buying or selling goods/services to other Federal agencies register in FedReg.


Federal Supply Classification CodesFour-digit numeric classification codes for products, similar to Standard Industrial Classification (SIC) codes.

Filled Customer OrderOrder received from a customer for which goods or services have been provided. Filling a customer order establishes the receivable and recognizes earnings. Also referred to as a filled order.

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

Financial Management SystemThe hardware and software used to facilitate control, monitoring, and reporting of an agency’s fiscal resources, including “mixed financial systems” also used for nonfinancial management purposes.

Financial, Operating, and Spending PlansBlueprints for using financial resources during any given fiscal period or series of periods. Agencies differentiate between “financial,” “operating,” and “spending” plans based on different levels of detail, different fiscal periods covered, or other variables. OMB uses the term “plan” as follows: “The Budget of the United States Government sets forth the President’s comprehensive financial plan for allocation of resources for the Federal Government;” and “Before agencies can use the resources, OMB must approve their spending plans.”11

Financing AccountThe account that collects the cost payments from a credit program account and includes all cash flows to and from the government resulting from direct loan obligations or loan guarantee commitments made on or after October 1, 1991.

FMS 224, Statement of TransactionsA monthly report submitted by an agency to Treasury. FMS 224 classifies the agency’s collections, payments, and intragovernmental transactions by a Treasury Account Symbol. The FMS 224 is being gradually phased out by the Governmentwide Modernization Project that will require agencies to provide a standard classification that includes a TAS at the inception of all transactions.

Full-Time EquivalentThe basic measure of the levels of employment used in the budget. It is the total number of hours worked (or to be worked) divided by the number of compensable hours applicable to each fiscal year.

11 President’s Budget, Analytical Perspectives, Chapter 26, “The Budget System and Concepts.”


FundResources set aside for a specific purpose. Often used interchangeably with the term “account” when referring to the accounts established by Treasury in which transactions are recorded and the accounts presented in the President’s Budget.

Funds ControlThe mechanism, in a software product, used to keep obligations and expenditures from exceeding apportionments and allotments or from exceeding budgetary resources available for obligation, whichever is smaller. (No obligations should be incurred against any anticipated budgetary resources, even if the funds are apportioned and allotted.)

Future-Dated TransactionsFinancial transactions that are input, held, and scheduled to be posted to a later accounting period.

Imprest FundA fixed-cash or petty-cash fund in the form of currency, coin, or government check, which has been advanced as Funds Held Outside of Treasury and charged to a specific appropriation account by a government agency official to an authorized cashier for cash payment or other cash requirement as specifically authorized. The fund may be a revolving type, replenished to the fixed amount as spent or used, or may be of a stationary nature such as a change-making fund.

In Forbearance/In Formal Appeals ProcessA delinquent debt that is in a formal appeals process or forbearance program. The results of the appeal affect whether a debt is considered valid and legally enforceable and/or the dollar amount to be collected. Debts in a formal forbearance program represent debts that are still in negotiation.

In ForeclosureA delinquent debt for which a notice of default has been filed.

Integrated Financial Management SystemA unified set of financial systems and the financial portions of mixed systems encompassing the software, hardware, personnel, processes (manual and automated), procedures, controls, and data necessary to carry out financial management functions, manage financial operations of the agency, and report on the agency’s financial status to central agencies, Congress, and the public. “Unified” means that the systems are planned for and managed together, operated in an integrated fashion, and linked electronically to efficiently and effectively provide financial system support necessary to carry out the agency’s mission and support the agency’s financial management needs.

Interagency AgreementA reimbursable agreement with another Federal agency. (See definition for “reimbursable agreement.”)

InterestA charge assessed when a debt is considered delinquent. The interest rate assessed is that of the current value of funds to Treasury, i.e., the Treasury tax and loan rate.


Internal ControlA subset of management controls used to ensure the prevention or timely detection of unauthorized acquisition, use, or disposition of the entity’s assets.

Internal FundA subdivision of an appropriation, receipt, or other fund account identified by a Treasury Account Symbol, used for internal agency reporting. Could also refer to the account as a whole.

In Wage GarnishmentA delinquent debt for which the agency is pursuing administrative wage garnishment (attaching money due to the debtor in order to satisfy a third-party debt).

Level of Funds DistributionSubdivision of funds made available for obligation (allotted) by an agency. A distinction is made between formal funds distribution and information funds distribution. Formal funds distribution is subject to the Antideficiency Act; in other words, obligations may not exceed the amount of funds available. Formal funds distribution reflects statutory (legal) limitations. Informal distribution refers to a subdivision made by an agency to further monitor spending for management purposes. Administrative limitations on the use of funds are usually an informal funds distribution.

LimitationA restriction on the amount of budgetary resources that can be obligated or committed for a specific purpose. Limitations may be placed on a program, administrative expenses, direct loan obligations, guaranteed loan commitments, or other uses of funds. Limitations based on language contained within appropriation or authorizing legislation are termed “legal limitations.” Spending limitations imposed at the department or agency level are “administrative limitations.” Limitations may exist at any level within a funding structure or may be imposed using an independent structure.

Master DataStable information that is incorporated by reference into transactions, is key to the operation of business, and is stored in the system to support transactional processes, operations, analysis, and reporting. Examples of master data are information about vendors and customers, funds (e.g., appropriation symbols, validity periods), and general ledger accounts.

MAX A-11 Data Entry SystemA computer system used to collect and process most of the information required for preparing the budget. MAX collects the budget data using a series of schedules, or sets of data, within the MAX database.

Mixed SystemAn information system that supports both financial and nonfinancial functions.

ModuleA component of an information system that carries out a specific function or functions and may be used alone or combined with other components.


NovationSubstitution of a new legal obligation for an old one as a result of a contractor’s legal change of name. The following FAR clauses reference novation: 42.12 (Novation and Change-of-Name Agreements), 42.1203 (Novation and Change-of-Name Agreements: Processing Agreements), 42.1204 (Applicability of Novation Agreements), 42.1205 (Novation and Change-of-Name Agreements: Agreement to Recognize Contractor’s Change of Name), 53.242-1 (Novation and Change-of-Name Agreements, SF 30), and 2.101 (Definition: Novation Agreement).

Object Classification“A uniform classification identifying the obligations of the Federal government by the types of goods or services purchased (such as personnel compensation, supplies and materials, and equipment) without regard to the agency involved or the purpose of the programs for which they are used.”12

Object Class CodeA code that classifies obligations by the items or services purchased by the Federal government (e.g., personnel compensation, supplies, rent, or equipment). Object classification is required when reporting obligations in accounts presented in the President’s Budget. OMB establishes the standard codes, titles, and definitions of the object class. Many agencies use an extension to the OMB object class for capturing additional detail to support internal information needs.

Obligated BalanceThe cumulative amount of budget authority that has been obligated but not yet outlayed and also known as unpaid obligations (made up of accounts payable and undelivered orders) net of accounts receivable and unfilled customer orders.

ObligationA binding agreement that will result in outlays, immediately or in the future. Budgetary resources must be available before obligations can be incurred legally.

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

OnlineA capability or function that is available on a computer or computer network (e.g., online display, online access) or an action accomplished on a computer (e.g., online data entry, online approval processing).

Organization StructureThe offices, divisions, branches, etc., established within an entity based on responsibility assignments, whether functional or program related.

OutlayA payment to liquidate an obligation (other than the repayment of debt principal). Outlays are the measure of government spending. Outlays generally are equal to cash disbursements but also are recorded for cash-equivalent transactions, such as the

12 Government Accountability Office, A Glossary of Terms Used in the Federal Budget Process, September 2005, p. 70.


subsidy cost of direct loans and loan guarantees and the interest accrued on public issues of the public debt.

Payment Confirmation DateThe date a check schedule was processed at Treasury and mailed or was deposited at the payment recipient’s bank.

Payment DateThe date on which a check for payment is dated or the date an EFT payment is deposited at the payment recipient’s bank (settlement date).

Payment Due DateThe date by which a payment must be made by an agency without incurring an interest penalty. The payment due date is calculated in accordance with provisions of the Prompt Payment Act.

Payment RequestAn invoice or other form submitted requesting payment for goods and services or reimbursement for expenses incurred. The goods and services may have already been rendered or will be rendered in the future.

Payment ScheduleRefers to the basic disbursement voucher, SF 1166, Voucher and Schedule of Payments, prescribed by Treasury for use by Federal Treasury-disbursing agencies to request and schedule check and electronic payments to individuals, commercial entities, and nonprofit entities.

Payment TermsThe terms or standards the agency negotiates with, or requires of, the payer, for settlement of a debt or obligation.

PenaltyA charge assessed after a debt is delinquent for more than 90 calendar days. The rate is set at 6 percent per annum.

Period of AvailabilityThe period during which a Federal agency can incur new obligations, as defined in the law appropriating the budget authority. The period of availability for incurring new obligations is shorter than the period of availability for making disbursements, which is covered by a general law. As indicated by the Authority Duration Code associated with a fund, the period of availability to incur obligations is annual, multiyear, or no-year.

Posted TransactionData from financial transactions that have been processed, accepted, and recorded in the general ledger.

Product and Service CodesFour-digit alphanumeric classification codes for products and services, similar to SIC codes. The PSC manual may be found at www.fpdsng.com/downloads/service_product_codes.pdf.


Program“Generally, an organized set of activities directed toward a common purpose or goal that an agency undertakes or proposes to carry out its responsibilities. Because the term has many uses in practice, it does not have well-defined, standard meaning in the legislative process. It is used to describe an agency’s mission, functions, activities, services, projects, and processes.”13 “Program code” has been defined as an element to classify obligations by program activities, to classify transactions by the programs assessed using the Program Assessment and Rating Tool, to classify transactions by the programs reported in the agency’s financial statements, to derive the USSGL account attributes for category B programs, or to derive the USSGL account attributes for program report categories.

ProjectA planned undertaking of something to be accomplished or produced, or an undertaking having a finite beginning and finite end. Examples are a construction project, a research and development project, and a reimbursable project.

QueryA method of delivering financial information to agency users in which the user specifies parameters and the system displays the requested data online.

ReappropriationAn extension in law of the availability of unobligated balances of budget authority that have expired or would otherwise expire as a result of legislation enacted subsequent to the law that provided the budget authority. A reappropriation counts as budget authority in the year in which the balance becomes newly available for obligation.

Reason CodeA unique character or set of characters that identifies the reason for certain occurrences such as failed document validations, document modifications, the write-off of receivables, and user overrides.

ReceivableA debt owed to the government.

Referenced DocumentA source document that is linked to a current document.

Reimbursable AgreementA contractual relationship under which an agency provides a product or service to another entity (Federal or non-Federal) in return for payment. The payment made by the recipient (buyer) represents reimbursement of the costs incurred by the provider (seller) under the agreement.

RejectionAction taken by the system that prevents a document from processing. Rejection is a system response to agency-defined validation edits.

13 Government Accountability Office, A Glossary of Terms Used in the Federal Budget Process, September 2005, p. 79.


RequirementsStatements that describe capabilities, functionality, or operating characteristics that a system is to provide.

Rescheduled DebtModified terms and conditions to facilitate repayment of a debt. This includes establishing new terms as a result of changes in authorizing legislation. “Rescheduled debt” may also refer to the set of repayments contractually required to be made through the life of the debt, including principal and interest; an agreement between a borrower and a lender that establishes the terms and conditions governing the recovery of a debt; or the repayment stream of principal by due date and installment amounts.

RescissionA decision to reduce budgetary resources (new budget authority or unobligated balances of budget authority) pursuant to the requirements of Title X of the Congressional Budget and Impoundment Control Act of 1974.

Scheduled Payment DateThe calendar date that a pending disbursement is scheduled (requested) to be paid.

SF 132, Apportionment and Reapportionment ScheduleA report that provides information on the sources and uses of budgetary resources. The report contains two general sections: Budgetary Resources, and Application of Budgetary Resources. Under Budgetary Resources are found the sources of actual and anticipated resources, as well as actual and anticipated reductions to those resources. Under Application of Budgetary Resources are found the intended use of the resources, whether by fiscal quarter, activity, project, object, or a combination thereof.

SF 133, Report on Budget Execution and Budgetary ResourcesA report on the status of funds that were apportioned on the SF 132, Apportionment and Reapportionment Schedule, and funds that were not apportioned. The SF 133 fulfills the requirements in 31 U.S.C. 1511–1514 that the President review Federal expenditures at least four times a year. The SF 133 lists the sources of budgetary resources, the status of budgetary resources, the change in obligated balances, and net outlays by Treasury Appropriation Fund Symbol (TAFS). The SF 133 is prepared for each unexpired and expired TAFS, excluding clearing accounts, deposit funds, and closed TAFS. SF 133 budget execution information is submitted electronically through Treasury’s FACTS II.

Spending AdjustmentAn increase (upward adjustment) or a decrease (downward adjustment) to the amount of a prior-year obligation.

Spending Authority from Offsetting CollectionsA type of budget authority, provided in permanent law, that permits an agency to credit offsetting collections to an expenditure account, to incur obligations, and to make payments using the offsetting collections.


Spending ChainA connected sequence of purchase-related events that have financial and budgetary impact on a Federal agency. The sequence of events usually begins with a commitment and ends with a payment. Data related to spending chain events, including general ledger transactions, are captured by the core financial system in a spending document. The following are common spending chain events:

Commitment

Obligation

Receipt/acceptance

Payment request (invoice)

Payment.

Spending DocumentAny one of the purchase-related documents in a spending chain.

Standard Generalized Markup LanguageAn international standard identifying the basic structural elements of a text document. SGML addresses the structure of a document, not its format or presentation.

Standard Industrial Classification CodesFour- or eight-digit all-numeric classification codes for products and services. SIC codes may be found at www.osha.gov/oshstats/sicser.html.

Standard TransactionA predetermined set of general ledger debits and credits (posting model) used for the consistent recording of like accounting events. Standard transactions should follow the accepted and approved posting model established by Treasury (or other accounting authority, when not addressed by Treasury) for recording an accounting event. Agency-defined standard transactions are intended to accommodate agency-specific account extensions (subaccounts) to the USSGL accounts.

Subsidiary LedgerThe detailed information that supports the balance of a summary account (control account) in the general ledger. An example of a subsidiary ledger is the detailed information and customer account balances that make up the accounts receivable balance in the general ledger.

Suspended (debt)Collection activity on a debt that is temporarily stopped for one of the following reasons: (1) the agency cannot locate the debtor, (2) the debtor’s financial condition is expected to improve, or (3) the debtor has requested a waiver or review of the debt.

System DateThe actual date a transaction is processed by the system. This date is assigned by the computer. Because of its use in system audits, the system date may not be modified.

http://www.osha.gov/oshstats/sicser.html


System GeneratedRefers to document data, transactions, or reports that are automatically supplied or produced by the system.

System Processing EditsEdits performed by the system to prevent document/transaction processing errors such as system assurance failures, missing or invalid values in specific fields, duplicate documents, etc.

Tolerance LevelsThe percentage or dollar variance amount that a related transaction can exceed a control amount, such as the amount by which payment can exceed a referenced receipt or obligation.

TransactionA balanced set of general ledger debits and credits posted as a result of agency input of a financial event. Multiple general ledger transactions can exist for a given document or document line.

Transaction DateThe date a transaction is effective in the general ledger (i.e., the date a financial event is recognized). This date determines the accounting period for financial reporting.

Transaction NumberA unique set of characters that identifies a specific general ledger transaction recorded in the core financial system.

TransferAn action in which budgetary resources are moved from one budget account to another. Depending on the circumstances, the budget may record a transfer as an expenditure transfer, which involves an outlay, or as a nonexpenditure transfer, which does not involve an outlay.

Treasury Account SymbolA group of elements that together make up the identification code assigned by Treasury, in collaboration with OMB and the owner agency, to an individual appropriation, receipt, or other fund account. The term “Treasury Account Symbol” is a generic term used to describe any one of the account identification codes assigned by Treasury. The term “Treasury Appropriation/Fund Symbol” is used to describe a particular type of TAS—one with budget authority. The terms TAS and TAFS are sometimes used synonymously.

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

Unfilled Customer OrderOrder received from a customer for which goods or services have not yet been provided. Also referred to as an unfilled order.


Unobligated BalanceThe cumulative amount of budget authority that is not obligated and that remains available for obligation under law.

U.S. Standard General LedgerA supplement to the Treasury Financial Manual that provides a uniform chart of accounts and standard posting logic (transaction codes) for recording financial events across government. The USSGL also includes cross-walks that map the general ledger accounts to standard external reports required by OMB and FMS.

USSGL Account AttributesCharacteristics of a USSGL account captured and used to meet a specific reporting requirement. Examples are Apportionment Category Code, Authority Type Code, Current or Subsequent Code, and Direct or Reimbursable Code. Agency systems must record transactions using USSGL account codes plus attributes in order to capture information needed to meet external reporting requirements.

Validity PeriodThe period of time for which an object (master data element, allotment, apportionment, continuing resolution, etc.) is valid.

WaiverA forgiveness of debt. The debtor is not held responsible and is not subject to collection efforts.

Warehoused PaymentAn account payable that is awaiting payment scheduling.

WarningAction taken by the system that requires override authority to continue processing a document. Warning is a system response to agency-defined validation edits.

WarrantAn official document issued by the Secretary of the Treasury, pursuant to law, that establishes the amount of money authorized to be withdrawn from the central accounts maintained by the Treasury.

Write-offThe removal of an uncollectible amount from an entity’s receivables. Amounts are written off when an authorized official determines that a debt will not be repaid. Collection attempts can be made after receivables are removed.

Core Financial System Requirements Abbreviations

APPENDIX F ABBREVIATIONS ABA American Bankers Association

ACH Automated Clearing House

ACR Agency Confirmation Report

ALC Agency Location Code

API Application Programming Interface

ASCII American Standard Code for Information Interchange

ATB Adjusted Trial Balance

BEA Budget Enforcement Act of 1990

BETC Business Event Type Code

BPA Blanket Purchase Agreement

BPN Business Partner Network

C&A Certification and Accreditation

CAGE Commercial and Government Entity

CCD Cash Concentration or Disbursement

CCD+ Cash Concentration or Disbursement Plus Addendum

CCR Central Contractor Registration

CFO Chief Financial Officer

CFO Act Chief Financial Officers Act of 1990

CFR Code of Federal Regulations

CGAC Common Government-wide Accounting Classification

CMA Cost Setup and Accumulation (subfunction)

CMB Cost Distribution (subfunction)

CMC Cost Monitoring (subfunction)

COTR Contracting Officer’s Technical Representative


CTX Corporate Trade Exchange

CVFR Current Value of Funds Rate

D&B Dun and Bradstreet

DBA Doing Business As

DCIA Debt Collection Improvement Act of 1996

DO Disbursing Office(r)

DOJ Department of Justice

DT Deposit Ticket

DV Debit Voucher

DUNS Data Universal Numbering System

EFT Electronic Funds Transfer

EIN Employer Identification Number

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

FBA Treasury Information Maintenance (subfunction)

FBB Payment Confirmation (subfunction)

FBC FBWT Reconciliation and Reporting (subfunction)

FBWT Fund Balance with Treasury

FEA Federal Enterprise Architecture

FedReg Federal Agency Registration database

FIPS Federal Information Processing Standards

FISMA Federal Information Security Management Act

FFMIA Federal Financial Management Improvement Act of 1996


FFMSR Federal Financial Management System Requirements

FMA Financial, Operating and Spending Plan Development (subfunction)

FMC Budget Authority (subfunction)

FMD Funds Distribution (subfunction)

FME Funds Control (subfunction)

FMLoB Financial Management Line of Business

FMS Department of the Treasury Financial Management Service

FOB Free On Board

FSC Federal Supply Classification

FSIO Financial Systems Integration Office

FTE Full-Time Equivalent

FTF Federal Transition Framework

GFRS Governmentwide Financial Report System

GLA General Ledger Account Definition (subfunction)

GLB Transaction Definition (subfunction)

GLC General Ledger Updating and Editing (subfunction)

GLD Upward/Downward Spending Adjustment (subfunction)

GLF Accounting Period Maintenance and Closing (subfunction)

GMRA Government Management Reform Act of 1994

GOALS Government Online Accounting Link System

GTAS Governmentwide Treasury Account Symbol

GUI Graphical User Interface

GWA Governmentwide Accounting

IAS Information Access System (GOALS II)

ID Identification

IIF Information in Identifiable Form


IPAC Intra-Governmental Payment and Collection

IRS Internal Revenue Service

IT Information Technology

JFMIP Joint Financial Management Improvement Program

MIME Multipurpose Internet Mail Extensions

MAX MAX A-11 Data Entry 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

OFFM Office of Federal Financial Management

OMB Office of Management and Budget

PAM Payment Automation Manager

PDF Portable Document Format

PIA Privacy Impact Assessment

POC Point of Contact

PMA Payee Information Maintenance (subfunction)

PMB Accounts Payable (subfunction)

PMC Payment Request (subfunction)

PMD Disbursing (subfunction)

PME Payment Follow-Up (subfunction)

PPD Prearranged Payment and Deposit

PPD+ Prearranged Payment and Deposit Plus Addendum

PSC Product Service Code

RFC Regional Finance Center

RBA Reimbursable Customer and Payee Maintenance (subfunction)


RBB Establishment of Reimbursable Agreement (subfunction)

RBC Billing, Collections, and Payments under Reimbursable Agreements (subfunction)

RMA Customer Information Maintenance (subfunction)

RMB Receivables and Billing (subfunction)

RMC Debt Management (subfunction)

RMD Collections and Offsets (subfunction)

RTN Routing Transit Number

SAM Shared Accounting Module

SFFAC Statement of Federal Financial Accounting Concepts

SFFAS Statement of Federal Financial Accounting Standards

SGML Standard Generalized Markup Language

SIC Standard Industrial Classification

SLA Service Level Agreement

SMA Accounting Classification (subfunction)

SMB Document and Transaction Control (subfunction)

SMC Document Referencing and Modification (subfunction)

SMD System-Generated Transactions (subfunction)

SME Audit Trails (subfunction)

SSP Shared Service Provider

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


TLA General Design/Architecture (subfunction)

TLC User Interfaces (subfunction)

TLD Interoperability (subfunction)

TLE Workflow/Messaging (subfunction)

TLF Document Management (subfunction)

TLG Internet Access (subfunction)

TLH Security (subfunction)

TLI Operations (subfunction)

TLJ Ad Hoc Query (subfunction)

TLK Documentation (subfunction)

TLL System Performance (subfunction)

TOP Treasury Offset Program

TROR Treasury Report on Receivables and Debt Collection Activities

U.S.C. United States Code

USSGL U.S. Standard General Ledger

XML Extensible Markup Language

Y2K Year Two Thousand

Word

Documents

Transcript of Word