****

**What is JFMIP?**

The Joint Financial Management Improvement Program (JFMIP) is a joint undertaking of the U.S. Department of the Treasury, the General Accounting Office, the Office of Management and Budget (OMB), and the Office of Personnel Management (OPM), working in cooperation with each other and other agencies to improve financial management practices in Government.  The Program was given statutory authorization in the Budget and Accounting Procedures Act of 1950 (31 USC 65 as amended).  The four Principals of the JFMIP – Comptroller General of the United States, Secretary of the Treasury, and the Directors of the OMB and OPM provide leadership and program guidance.  Each Principal designates a representative to serve on the JFMIP Steering Committee, which is responsible for the general direction of the Program. The JFMIP Executive Director and a program agency representative (who serves for 2 years) are also on the Steering Committee.  

The Program promotes strategies and guides financial management improvement across Government, reviews and coordinates central agencies’ activities and policy promulgations, and acts as a catalyst and clearinghouse for sharing and disseminating information about good financial management practices. This information sharing is done through conferences and other educational events, newsletters, meetings with interagency groups and agency personnel, and through the Internet.

The JFMIP has worked on interagency projects that developed a financial systems framework and financial systems requirements.  The Program Management Office (PMO) has also revised the Federal Government’s requirements definition, testing, and acquisition processes. The objectives of the PMO are to develop systems requirements, communicate and explain Federal and agency needs, provide agencies and vendors with information to improve financial systems and ensure that products meet relevant systems requirements.  

For information on JFMIP, call (202) 219-0526, or visit the JFMIP website: www.JFMIP.gov.

Date:June 11, 2001

To:Senior Financial Officials       

From:Executive Director, JFMIP – Karen Cleary Alderman

Subject:JFMIP Core Financial System Requirements Document

The JFMIP Core Financial System Requirements document Exposure Draft is attached for comment.  This effort was supported by the JFMIP; the Chief Financial Officers’ (CFO) Council Financial Systems Committee; OMB; U.S. GAO; Department of Treasury and others.

The *Core Financial System Requirements* document was developed by a task force led by Stephen Balsam, JFMIP.  The task force included selected representatives from agency CFO communities (listed in *Appendix D: Contributors*) and individuals who participated in the prior tests of core financial system software.  This document addresses updates to the prior document (JFMIP SR-99-4, February 1999).  The revisions are the result of meetings with agencies that are currently implementing core financial systems, input from the software vendor community, information obtained during JFMIP’s testing of vendor core financial system software, and new requirements.

The document is intended to assist agencies when reviewing new core financial systems and when improving or evaluating existing core financial systems.  It provides the baseline functionality that core financial systems must have in order to support agency missions and comply with laws and regulations.  The final issuance of this JFMIP Core Financial System Requirements document will augment existing Federal financial management system functional requirements used in assessing compliance with the Federal Financial Management Improvement Act (FFMIA).

We are particularly interested in your comments on the following changes that have been reflected in this exposure draft:

1. **Requirement type format.**In the JFMIP SR-99-4 document the mandatory requirements were included and the technical and value-added requirements were referenced.  In the JFMIP SR-01-02 document both mandatory and value-added requirements are now presented, along with the technical requirements. 

2. **Requirement number format.**  The specific requirements are now identified with the numbering scheme that is currently available in the requirements section in the Knowledgebase.  The exposure draft used this numbering scheme and reorders the requirements in a new logical flow.  The final document will renumber them to reflect their listed order.

3. **Cost Management.**The revolving fund requirements, which were previously value-added, have been expanded and are now mandatory in the Cost Management Function.

4.**Ad hoc reporting** requirements are now mandatory versus value-added.

5.**Requirements that state “automatically.”**Periodically the requirements will indicate that the system must "automatically" do something.  While most requirements should be met through the system, JFMIP recognizes that occasionally manual intervention may be necessary.  However, "automatically" is specified for those requirements that the system must meet without manual intervention.

6.**Authorized user.**In preparing these requirements, agencies commented that requirements should in some cases state "authorized user".  In lieu of stating this on each requirement, JFMIP has added mandatory technical requirements TS-4 through TS-6 as global requirements to require system changes only by "authorized users".

7. **Mandatory vs. value-added requirements.**Is the categorization of system requirements between mandatory and value-added appropriate? Are there requirements that should be changed from mandatory to value-added or vice-versa?

8. **Automated method to reclassify accounting data.**  All requirements should be reviewed.  However, JFMIP asks specific comment on draft mandatory requirement CF-15 (Core Financial System Management mandatory requirement CF-15), which specifies “...an automated method to reclassify accounting data.”  This requirement, currently value-added, has equal requests by agencies for classification as value-added and mandatory.  Should this be a value-added or mandatory requirement?

9. **Glossary.**Are all terms sufficiently defined?  Are there additional terms that need to be defined?

10. **Format Standards.**  Please comment on the use of format standards for transmitting electronic information, (e.g., Electronic Data Interchange (EDI), Extensive Mark-up Language (XML) and other formats.)

This document is being circulated widely within the Federal government’s financial and oversight communities and to private sector system providers.  It is also being posted in electronic *Word* format on JFMIP’s website at: *WWW.JFMIP.GOV***.**

Please provide your comments by August 20, 2001.  Comments on any section of this document are encouraged.  If possible, we would appreciate responses in the electronic form, placing the comment as a “redline” within the available *Word*document.  At a minimum, responses should reference the specific requirement number or narrative section related to each comment. Responses will be more helpful if the underlying rationale is also provided.  Respondents should also indicate the capacity in which they are responding.  Comments should be sent to:

Joint Financial Management Improvement Program

Suite 430

1990 K Street NW

Washington, DC 20006

Attn:  Core Financial System Requirements, Steve Balsam

Attachment

**Foreword**

This document represents the latest update to the *Core Financial System Requirement*s document, first issued in January 1988. This most recent update reflects recent changes in laws and regulations and in government-wide reporting systems, such as the Department of Treasury’s Federal Agencies Centralized Trial Balance System (FACTS) II system.  Also, some of the existing requirements have been clarified, redundant or outdated requirements have been deleted, vague or open-ended requirements have been addressed, and the priority (mandatory or value-added) of certain requirements has been changed and new requirements have been added to reflect the current core financial system needs of Federal agencies. 

The provisions in this document constitute Federal requirements for core financial systems.  They are stated as either mandatory (required) or value-added (optional) system requirements. Agencies must use the mandatory functional and technical requirements in planning their core financial system improvement projects.  Value-added requirements should be used as needed by the agency. It is each Agency’s responsibility to be knowledgeable of the legal requirements governing its core financial operations; therefore, agencies may develop additional technical and functional system requirements as needed to support unique mission responsibilities.  Agencies must also develop strategies for interfacing or integrating other systems with the core financial system.

These requirements also remain the basis for the Federal government to test compliance of commercially based, core financial software. In FY 1999, the JFMIP’s PMO developed a new testing and qualification process, directly linking tests to these requirements.  Also, the testing/qualification process was separated from the acquisition phase of the software selection process governed by the General Services Administration (GSA) Financial Management Systems Software (FMSS) Schedule processes.

This document should be used in conjunction with JFMIP’s Web based electronic repository, called the Knowledgebase, which can be reached through the JFMIP website at http://www.JFMIP.gov.  These requirements form a major portion of the Knowledgebase.  In addition, vendor support requirements are included in the Knowledgebase. 

The CFO Act of 1990 places specific responsibility for developing and maintaining effective financial systems with the CFOs in Federal agencies. This update to the *Core Financial System Requirements*, along with the other system requirements published by the JFMIP PMO and the information provided in its Knowledgebase, demonstrates the commitment of the CFO community to continually improve Federal financial systems.

We appreciate their support, and thank the CFOs Council Financial Systems Committee, OMB, the GAO, the GSA, and other agencies that participated in improving the requirements document. 

Karen Cleary Alderman

Executive Director

#### Acronyms

ACHAutomated Clearing House

ALCAgency Location Code

ANSIAmerican National Standards Institute

APIApplication Program Interface

ATBAdjusted Trial Balance

BPABlanket Purchase Agreement

CCD+Cash Concentration or Disbursement Plus Addendum

CFO Chief Financial Officer

CFRCode of Federal Regulations

CMIACash Management Improvement Act

COTS Commercial Off-the-Shelf

CTXCorporate Trade Exchange

DCIADebt Collection Improvement Act

DMADocument Management Alliance

DOJDepartment of Justice

DUNSData Universal Numbering System

ECSElectronic Certification System

EDIElectronic Data Interchange

EFTElectronic Funds Transfer

EINEmployee Identification Number

FACTSFederal Agencies Centralized Trial Balance System

FASAB Federal Accounting Standards Advisory Board

FFMIA Federal Financial Management Improvement Act of 1996

FFMSR Federal Financial Management System Requirements

FMS Department of the Treasury Financial Management Service

FOMFFinancial Organization Master File

FTEFull Time Equivalent 

GAO General Accounting Office

GMRA Government Management Reform Act of 1996

GOALSGovernment Online Accounting Link System

GPRA Government Performance and Results Act of 1994

GUIGraphical User Interface

IPACIntragovernmental Payment and Collection System

IRSInternal Revenue Service

JFMIP Joint Financial Management Improvement Program

MAFMaster Appropriation File

MAPI-WFMessaging API-Workflow

MVSMultiple Virtual System

NARANational Archives and Records Administration

ODA/ODIFOpen Document Architecture/Open Document Interface Format

ODMAOpen Document Management Architecture

OMB Office of Management and Budget

OPACOn-line Payment and Collection System

OSOperating System

PDFPortable Document Format

PMOProgram Management Office

PKIPublic Key Infrastructure

P. L.Public Law

**Acronyms (continued)**

PPDPrearranged Payment and Deposit

RTNRouting Transit Number

SFFASStatements of Federal Financial Accounting Standards

SGL Standard General Ledger

SGMLStandard Generalized Markup Language

SQLStandard Query Language

TAFSTreasury Account Fund Symbol

TCP/IPTransaction Control Protocol/Internet Protocol

TFMTreasury Financial Manual

TINTaxpayer Identification Number

U.S.C.United States Code

VIMVendor Independent Messaging 

WFMCWorkflow Management Coalition 

XMLExtensible Markup Language

**Illustrations (List)**

1.  Financial System Improvement Projects5

2.  Integrated Model for Federal Information Systems 8

3.  Agency Systems Architecture9

4.  Core Financial System10

**Table of Contents**

Introduction1

Federal Financial Management Framework3

Integrated Financial Management Systems6

Agency Financial Management Systems Architecture7

Core Financial System Overview9

Summary of Functions10

Summary of Technical Requirements14

Information Stores—Data Requirements16

Functional Requirements18

Core Financial System Management Function18

General Ledger Management Function25

Funds Management Function28

Payment Management Function36

Receipt Management Function45

Cost Management Function49

Reporting Function53

Technical Requirements55

General Design/Architecture56

Interoperability57

Security58

Operations and Computing Performance59

Year 2000 Compliance60

Infrastructure60

User Interfaces61

Workflow/Messaging62

Document Management63

Internet Access63

Data Import/Reconciliation64

Ad Hoc Query64

Appendix A: References66

Appendix B: Glossary67

Appendix C: Summary of External Reporting Requirements72

Appendix D: Contributors75

**Introduction**

The Federal Government recognizes the importance of using state-of-the-art financial systems to support Government operations and to provide quality and timely financial and related information to program and financial managers. Congress enacted the CFO Act of 1990, GMRA, and FFMIA of 1996 to improve financial management, assign clearer responsibility for leadership to senior officials, and require new financial organizations, enhanced financial systems, and audited financial reporting.  

Improving Federal financial management systems is critical for financial and program managers. The improvements provide better information for decision-making, and increase the efficiency and effectiveness of services provided by the Federal Government. Proper financial management and reliable financial systems must provide for:

*Accountability*. Inform taxpayers, agency personnel, and the Congress, in terms they can readily understand, on how the Nation’s tax dollars are being spent, and that Federal assets are being protected.

*Efficiency and Effectiveness*. Provide efficient and effective service to the Federal agencies’ internal and external customers (e.g. general public, contractors, partnerships, state and local Governments, other Federal agencies/organizations, the military, and foreign governments).

*Better Decision-Making*. Provide agency heads, program managers, and the Congress with timely reports linking financial execution and program results.

The OMB Circular A-127, “*Financial Management Systems*”, sets forth general policies for Federal financial management systems. Each agency is required to develop and maintain a single, integrated financial management system. To support this objective, each agency must have an ongoing financial systems improvement planning process and periodic reviews of financial system capabilities. In addition, each agency must maintain financial management systems that comply with the requirements of the Federal accounting standards established by the Federal Accounting Standards Advisory Board (FASAB) in its Statements of Federal Financial Accounting Standards (SFFAS) and with the requirements of OMB’s Form and Content of Agency Financial Statements.

System requirements for common systems have been prepared under JFMIP direction as a series of publications entitled Federal Financial Management System Requirements (FFMSR). The FFMIA statute codified the FFMSR as key benchmarks that agency systems must meet to be substantially in compliance with system requirements provisions under FFMIA. The *Core Financial System Requirements* document has been prepared as a continuation of the FFMSR series that began with the first *Core Financial Systems Requirements* document in published January 1988.

This document is intended for financial system analysts, systems accountants, systems developers, program managers, and others who design, develop, implement, operate, and maintain or audit financial management systems.

Information that applies to all financial management systems, such as internal controls, system security, training, documentation, and support are discussed in the JFMIP *Framework for Federal Financial Management Systems* document.  The Framework document, published in January 1995, facilitates the design, implementation, and operations of financial management systems to support the increased emphasis being placed on improving government operations. However, the internal controls and security considerations for Core financial systems are interspersed throughout this document.

This document is the basis for evaluating Core financial system software for compliance with JFMIP requirements, through a testing process that links test scenarios to the requirements presented in this document. The JFMIP’s PMO tests commercial software functionality against these requirements, qualifies the software as meeting mandatory requirements, and publishes the results in the Knowledgebase, at http://www.JFMIP.gov.

The next chapters in this document set forth the framework for the establishment and maintenance of an integrated Federal financial management system.  An overview of the Core financial system, including a summary of functions, technical requirements, and data requirements is provided in the System Overview chapter. Specific requirements are presented in detail in the functional and technical requirements chapters. Appendices provide source for References, a Glossary, a Summary of External Reporting Requirements, and a list of Contributors.

**Federal Financial Management Framework**

The *Core Financial System Requirements*document establishes standard requirements for the “backbone” modules of an agency’s integrated financial management system.  It provides common processing routines, supports common data for critical financial management functions affecting the entire agency, and maintains the required financial data integrity control over financial transactions, resource balances, and other financial management systems.  This document is a part of a broad program to improve Federal financial management that involves the establishment of uniform requirements for financial information, financial systems, reporting, and financial organization.

As shown in Illustration 1, *Financial Systems Improvement Projects*, establishing uniform requirements is only part of the process of improving financial management systems and information. Improvements can be achieved through the selection, development, and/or purchase of applications that meet approved functional requirements and technical and data management specifications. Agencies must continue to improve their financial systems and implement new requirements as they are issued so that continuing efforts to standardize and upgrade data and reporting requirements, in accordance with OMB’s Government-wide 5-year financial management plan, will be successful.

Well-defined and effective Government-wide functional requirements assist agencies in developing strong systems and information by eliminating duplicate work among agencies and providing a common framework so that outside vendors can more economically provide systems software. Development of Government-wide functional requirements for each application is a critical effort that will affect internally developed systems and the evaluation and selection of commercially available systems. In support of this vision, the Federal Government must establish Government-wide financial management systems and compatible agency systems, with standardized information and electronic data exchange, to support program delivery, safeguard assets, and manage taxpayer dollars.

Each agency should integrate its unique requirements with these Government-wide standard requirements to provide a uniform basis for the standardization of financial management systems as required by the CFO Act of 1990, FFMIA of 1996, and other statutes.

Financial management systems in the Federal government must be designed to support the vision articulated by the government’s financial management community.  This vision requires financial management systems to support the partnership between program and financial managers and to assure the integrity of information for decision-making and measuring of performance.  This includes the ability to:

· Collect accurate, timely, complete, reliable, and consistent information;

· Provide for adequate agency management reporting;

· Support government-wide and agency level policy decisions;

· Support the preparation and execution of agency budgets;

· Facilitate the preparation of financial statements, and other financial reports in accordance with Federal accounting and reporting standards;

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

· Provide a complete audit trail to facilitate audits.

It is critical that financial management system plans support the agency’s mission and programs, including planned changes to them, and that the financial management systems plans are incorporated into the agency’s plans for information technology (IT) infrastructure and information systems as a whole.  Further, system design efforts should include an analysis of how system improvements, new technology supporting financial management systems, and modifications to existing work processes can together enhance agency operations and improve program and financial management. Reassessing information and processing needs and redesigning processes, procedures, and policies are essential steps to meeting user needs.

**Integrated Financial Management Systems**

Financial management systems must be designed with effective and efficient interrelationships between software, hardware, personnel, procedures, controls, and data contained within the systems.  To be integrated, financial management systems must have, as a minimum, the following four characteristics:

(1) Standard data classifications (definition and formats) established and used for recording financial events; 

(2) Common processes used for processing similar kinds of transactions; 

(3) Internal controls over data entry, transaction processing, and reporting applied consistently; and 

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

The financial management systems policy stated in OMB Circular A-127 “Financial Management Systems,” requires that each agency establish and maintain a single, integrated financial management system.  Without a single, integrated financial management system to ensure timely and accurate financial data, poor policy decisions are more likely due to inaccurate or untimely information; managers are less likely to be able to report accurately to the President, the Congress, and the public on government operations in a timely manner; scarce resources are more likely to be directed toward the collection of information rather than to delivery of the intended programs; and modifications to financial management systems necessary to keep pace with rapidly changing user requirements cannot be coordinated and managed properly. The basic requirements for a single, integrated financial management system are outlined in Section 7 of OMB Circular A-127.

Having a single, integrated financial management system does not necessarily mean that each agency must have only one software application covering all financial management system needs.  Rather, a single, integrated financial management system is a unified set of financial systems and the financial portions of mixed systems 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 and managed together, operated in an integrated fashion, and linked together electronically in an efficient and effective manner to provide agency-wide financial system support necessary to carry out the agency’s mission****and support the agency’s financial management needs.

“Integrated” means that the user is able to have one view into the system such that, at whatever level the individual is using the system, needed information may be efficiently and effectively obtained through electronic means.  However, it does not mean that all information is physically located in the same database. 

Interfaces, where one system feeds data to another system following normal business/transaction cycles, (e.g. salary payroll charges are recorded in general ledger control accounts when the payroll payments are made) may be acceptable as long as the supporting detail is maintained and accessible. In such cases, interface linkages must be electronic unless the number of transactions is so small that it is not cost-beneficial to automate the interface. Easy and timely reconciliation between systems, where interface linkages are appropriate, must be maintained to ensure data accuracy.

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

· The scope of the functions to be supported (processes),

· How data quality will be assured (data stewardship),

· Information to be processed (management information),

· How systems fit together to support the functions (systems architecture), and

· Safeguards needed to ensure the integrity of operations and data (internal control).

All of these pieces must be brought together in a model such as the one shown in Illustration 2. These pieces must work together to form an effective integrated information system.  A change to any part of the model will require determination of the implications on other parts of the model.  For example, a new reporting requirement may require changes throughout the entire model.

**Agency Financial Management Systems Architecture**

Agency financial management systems are information systems which track financial events and summarize information to support the mission of an agency, provide for adequate management reporting, support agency level policy decisions necessary to carry out fiduciary responsibilities, and support the preparation of auditable financial statements.  Agency financial management systems fall into four categories: 

(1) Core financial systems, 

(2) Other financial and mixed systems (such as inventory systems), 

(3) Shared systems, and 

(4) Departmental executive information systems (systems to provide management information to all levels of management). 

These systems must be linked together electronically to be effective and efficient.  Summary data transfers must be provided from agency systems to central systems to permit summaries of management information and agency financial performance information on a Government-wide basis.

Subject to government-wide policies, the physical configuration of financial management systems, including issues of centralized or decentralized activities, processing routines, data, and organizations, is left to the Agency to decide the optimal manner in which to support the agency mission.  The physical design of the system, however, should consider the agency’s organizational philosophy, the technical capabilities available, and the most appropriate manner to achieve the necessary single, integrated financial management system for the agency.

The systems architecture shown in Illustration 3 provides a logical perspective identifying the relationships of various agency system types.  Although this does not necessarily represent the physical design of the system, it does identify the system types needed to support program delivery/financing and financial event processing for effective and efficient program execution.

**Core Financial System**

As shown in Illustration 3, the Core financial system is an integral part of an agency’s single, integrated financial management system.  It controls and supports the key functions of an agency’s financial management, including general ledger management, funds management, payment management, receipt management, cost management, and reporting. The Core financial system receives data from all other financial and mixed systems and from direct user input, and it provides data and supports processing for those systems that need it.

Financial management system development and implementation efforts shall seek cost effective and efficient solutions as required by OMB Circular A-130, “Management of Federal Information Resources.” Agencies are required to use commercial-off-the-shelf (COTS) software to reduce costs, improve the efficiency and effectiveness of financial system improvement projects, and reduce the risks inherent in developing and implementing a new system. However, as stated previously, the agency has the ultimate responsibility for implementing sound financial management practices and systems, and cannot depend on a vendor or contractor to do this for them. 

The JFMIP PMO has been responsible for two major functions: 

· Updating and communicating financial management system requirements so that COTS software vendors and agencies can better understand the Federal market requirements; and

· Testing and qualifying COTS software and creating an open Knowledgebase, with information available on the functional, design, and performance characteristics of certified Core financial management systems software. The availability of this information to agencies should reduce acquisition costs and risks of implementing COTS products; they will have already been tested and certified as meeting JFMIP requirements.

Only software that has been qualified as meeting JFMIP Core Financial System Requirements has been certified.  

**Core Financial System Overview**

This chapter provides an overview of a Core financial system.  The overview has the following sections:

· Summary of Functions, which presents a high-level description of the functions supported by the Core financial system and describes how Core financial systems interact with other systems.

· Summary of Technical Requirements, which summarizes the functionality that core financial systems either must have or should have.

· Information Stores - Data Requirements, which discusses the types of data needed to perform the various functions of a Core financial system.

**Summary of Functions**

The following is a brief description of the major functions of a Core financial system.  The Functional Requirements chapter provides a detailed description of each function, including the lower level processes within each function. Illustration 4 depicts the functions within the Core financial system.

A single financial event will require processing by more than one function within the Core financial system. The Core Financial System Management function affects all financial event transaction processing because it maintains reference tables used for editing and classifying data, controls transactions, and maintains security. Likewise, the General Ledger Management function is involved either directly or indirectly with  financial events since transactions to record financial events must be posted to the general ledger either individually or in summary.  Any transactions involved in budget execution will use the Funds Management function.

An example of a financial event affecting multiple functions is a payment including additional charges not previously recorded, such as interest costs due to late payment or additional shipping charges allowed by the contract.  This transaction would originate in the Payment Management function, would be edited for funds availability and update balances in the Funds Management function for the excess costs and to move the undelivered order amount to an expenditure status, would update cost amounts controlled by the Cost Management function, would update the general ledger balances in the General Ledger Management function, and would be edited against reference data and update audit trails in the Core Financial System Management function.

***Core Financial System Management***

The Core Financial System Management function consists of the processes necessary to maintain system processing rules consistent with established financial management policy.  This function sets the framework in which all other Core financial system functions operate.  The Core Financial System Management function consists of the following processes:

· Accounting Classification Structure Management

· Transaction Control

· Archiving and Purging.

***General Ledger Management***

General Ledger Management is the central function of the Core financial system.  The general ledger is the highest level of summarization and must maintain account balances by the fund structure and individual general ledger accounts established in the Core Financial System Management function.  Depending on the agency’s reporting requirements, some or all general ledger accounts may have balances broken out by additional elements of the accounting classification structure.  All transactions to record financial events must post, either individually or in summary, to the general ledger, regardless of the origin of the transaction.

Subsidiary ledgers at various levels of detail support the general ledger.  These subsidiary ledgers may be maintained within the Core financial system or in other systems.  For example, detailed property records supporting the equipment account in the general ledger might be maintained in a system devoted to controlling and maintaining equipment.  The payroll system might contain detailed employee pay records that support records of expenditure by object class and organization in the Core financial system, which in turn provide partial support for expenditure and expense accounts in the general ledger.

The General Ledger Management function consists of the following processes:

· General Ledger Account Definition

· Accruals, Closing, and Consolidation

· General Ledger Analysis and Reconciliation

***Funds Management***

Each agency of the Federal government is responsible for establishing a system for ensuring that it does not obligate or disburse funds in excess of those appropriated and/or authorized.  The Funds Management function of the Core financial system is an agency’s primary tool for carrying out this responsibility.

OMB Circular A-34, “Instructions on Budget Execution,” and, to a lesser extent, OMB Circular A- 11, “Preparation and Submission of Budget Estimates,” set government-wide policy for funds management with which the Core financial system must conform.  In addition to supporting the government-wide policies, the Funds Management function must support agency policies on internal funds allocation methods and controls.

An agency may have many other systems in addition to the Core financial system that affects funds management.  For example, procurement and travel systems prepare documents that commit and obligate funds.  These and other systems that affect funds availability should access data and use processes of the Core financial system to verify that funds are available and to update balances.  When possible and cost-effective, these systems should access the funds availability editing activity before allowing an obligation to be incurred, such as a contract being signed.  In some cases, such as payroll, this may not be practical.

The Funds Management function consists of the following processes:

· Budget Preparation

· Budget Formulation

· Funds Allocation

· Budget Execution

· Funds Control

***Payment Management***

The Payment Management function should provide appropriate control over all payments made by or on behalf of an agency.  Agencies make payments to vendors in accordance with contracts; to state governments under a variety of programs; to employees for salaries and expense reimbursements; to other Federal agencies for reimbursable work performed; to individual citizens receiving Federal benefits; to recipients of Federal loans; and for many other reasons.

Title 5 Part 1315 of the Code of Federal Regulations (CFR) requires that agencies must make payments to vendors on time, pay interest penalties when payments are late, and take discounts only when payments are made on or before the discount date.  The Cash Management Improvement Act (CMIA) specifies requirements for payments made to states.  Regulations implementing CMIA are at Title 31 CFR 205.  Other regulations affect payments made for travel, payroll, benefits, and other purposes.

Depending on an agency’s system architecture, specific activities performed relating to payments may be supported by other systems that provide transaction data to the Core financial system for control and management purposes. For example, payroll systems usually trigger the actual disbursement process to pay employees through direct deposit or by check and send only the expense and disbursement information to the Core financial system for recording by the general ledger, funds control, and cost management processes.  Likewise, large loan and grant programs might be supported by systems that maintain their own detailed information on payees and payments and send transaction data to the Core financial system.  If this situation exists, these other systems must meet the requirements listed here for payment management.

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

The Payment Management function consists of the following processes:

· Payee Information Maintenance

· Payment Warehousing

· Payment Execution

· Payment Confirmation and Follow-up.

***Receipt Management***

The Receipt Management function supports activities associated with recording agency cash receipts, including servicing and collecting receivables.  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), loans made to others that must be repaid, or other actions.  Some receipts may be collected without the prior establishment of a receivable, as in the case of goods sold for cash.

A receivable is recognized when the agency establishes a claim to cash or other assets against other entities, either based on goods or services provided or on legal provisions, such as a payment due date (e.g., taxes not received by the date they are due).  If the exact amount is unknown, a reasonable estimate is made.  Receivables are accounted for as assets until funds are collected, converted into other resources, or determined to be uncollectible in whole or in part.

Depending on an agency’s system architecture, servicing and collection activities for some receivables may be supported by other systems that provide transaction data to the Core financial system.  This would be particularly appropriate for receivables resulting from large programs with complex supporting data requirements, such as loan programs, grant programs, or fee-for-service programs.  Servicing and collection for receivables with simpler requirements for supporting data, such as those resulting from erroneous payments, may be supported directly by the Core financial system with no support by other systems.

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

The Receipt Management function****consists of the following processes:

· Receivable Establishment

· Receivable Management

· Collections

· Offset Process.

***Cost Management***

The Cost Management function of the Core financial system attempts to measure the total cost of Federal programs, and their various elements, activities and outputs. Cost Management is essential for providing accurate program measurement information, performance measures, and financial statements with verifiable reporting of the cost of activities.  The term “cost” refers to the monetary value of resources used or sacrificed or liabilities incurred to achieve and objective, such as to acquire or produce a good or to perform an activity or service. A “cost object” is any activity, output or item whose cost is to be measured. 

The level of sophistication of the Cost Management function needed by an agency is depends on the requirements of the agency and the operational nature of the programs involved (appropriation only, appropriation with reimbursable authority, revolving fund).  For example, if an agency’s primary mission is to produce a product or service for sale, the costing function typically will be accomplished in the Managerial Cost Accounting System that is integrated with 

the Core Financial System.  However, in any Core system, certain basic functions must be present.

The Cost Management function consists of the following processes: 

· Cost Setup and Accumulation

· Cost Recognition

· Cost Distribution

· Working Capital and Revolving Fund.

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. Finally, cost information is prepared and distributed to managers.

***Reporting***

The Core financial system must be able to provide timely and useful financial information to support: (1) management’s fiduciary role; (2) budget formulation and execution functions; (3) fiscal management of program delivery and program decision making; and (4) internal and external reporting requirements, including, as necessary, the requirements for financial statements prepared in accordance with the form and content prescribed by OMB, reporting requirements prescribed by Treasury, and legal, regulatory and other special management requirements of the agency.

Information maintained by the Core financial system must be provided in a variety of formats to users according to their needs.  Methods of providing information include on-line inquiries, extract data files, and hard-copy reports.  These requirements could be satisfied by (1) application software that is part of the Core financial system, (2) generalized reporting/inquiry software that works with a variety of applications, or (3) a combination of both.

**Summary of Technical Requirements**

Technical requirements have been established to help ensure that a Core financial system (1) is capable of meeting a wide variety of workload processing demands; (2) provides transaction processing integrity and general operating reliability; (3) is easy to install, configure and operate; and (4) does not conflict with other administrative/program systems or other agency established IT standards. 

Core financial systems subject to JFMIP qualification must meet the mandatory technical requirements specified in this section. Additionally they should strive to include the functionality listed as value-added requirements. The requirements listed in the following subcategories are mandatory:

· General Design/Architecture

· Interoperability

· Security

· Operations and Computing Performance 

· Year 2000 Compliance

The following subcategories include requirements that are value-added:

· Infrastructure

· User Interfaces

· Workflow/Messaging

· Document Management 

· Internet Access

The following subcategory is comprised of both mandatory and value-added requirements:

· Ad Hoc Query

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

**Information Stores - Data Requirements**

The Core financial system stores, accesses, and updates several types of data.  In this document, a grouping of related types of data is referred to as an “information store.” The term “information store” is used rather than “database” or “file” to avoid any reference to the technical or physical characteristics of the data storage medium.  Actual data storage (physical databases and files) must be determined by each agency during system development and implementation based upon agency statutory requirements, technical environment, processing volumes, organizational structure, and degree of system centralization or decentralization.

The information stores defined here are logical groupings of data.  Some of this data may be derived from summarizing more detailed data and, as a result, may not be stored in a permanent, physical form in some systems.  In other cases, implementation of a single information store may involve several record types or files.  As stated above, the physical storage characteristics are considered part of the specific system implementation strategy, which is outside the scope of this document.

The information stores used by the Core financial system are as follows:

**General Ledger.**This refers to data summarized to the level of a trial balance for each fund by fiscal year; includes control totals for all general ledger accounts.

**Funds Availability.**This refers to data supporting the funds allocation and funds control processes; tracks budgetary resources and usages (such as, but not limited to, allotments, commitments, undelivered orders, and expenditures) at the various levels within an agency’s  accounting classification structure (ACS) that an agency wishes to control its funds.

**Operating Data.**This refers to subsidiary ledger supporting data for general ledger accounts tracked at the lowest level of the accounting classification structure; typically used for cost data, detailed funds reporting, and similar purposes that require data by organization, program, etc. may be used to support some or all general ledger accounts, depending on an agency’s internal management and reporting needs.

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

**Posted Transactions.**This refers to data from financial transactions that have been processed, accepted and posted to the system; used to provide an audit trail of financial transactions.

**Suspended Transactions.**This refers to data from financial transactions that have been placed in a suspended status,  (i.e. not posted to the other information stores) due to errors in the data or due to the timing of the processing cycle for them, such as holding for overnight processing.

**Logging Data.**This refers to data used for audit trails to record activity in the system other than financial transactions, such as table changes.

**Reference Data.**This refers to data used to control actions of the system, define codes and descriptive titles, etc., such as accounting classification structure code tables, general ledger account definitions, transaction definitions, and security control tables.

**External Entities.**This refers to data concerning other entities the agency deals with, such as payees and customers, including name, address, taxpayer identification number, banking information, or other appropriate data depending on the function associated with the entity.

Functional Requirements

This chapter identifies the government-wide requirements for a Core financial system to support the fundamental financial functions of a Federal agency. The major functions supported by a Core financial system are as follows:

· Core Financial System Management

· General Ledger Management

· Funds Management

· Payment Management

· Receipt Management

· Cost Management

· Reporting.

Together, these functions provide the basic information and control needed to carry out financial management functions, manage the financial operations of an agency, and report on the agency’s financial status to central agencies, Congress, and the public. This includes data needed to prepare the six principal financial statements for Federal agencies in accordance with the current OMB Bulletin on the form and content of agency financial statements.

**Core Financial System Management Function**

The Core Financial System Management function consists of the processes necessary to operate and maintain the core system consistent with established financial and related (e.g., record retention) laws, regulations, governmentwide policy, and best practices. This function sets the framework in which all other Core financial system functions operate. The Core Financial System Management function consists of the following processes:

· Accounting Classification Structure Management

· Transaction Control

· Archiving and Purging.

The core financial system management function ensures that the procedures for capturing, classifying, communicating, processing, and storing data and transactions are uniform (or translatable among the various subsystems or system components as necessary). 

***Accounting Classification Structure Management Process***

Within each department or agency, the accounting classification structure and definitions must be standardized to ensure consistency, uniformity, and efficiency in accounting treatment, classification, and reporting. The Accounting Classification Structure Management process provides a consistent basis for:

· Consolidating government-wide financial information.

· Integrating planning, budgeting, and accounting.

· Capturing data at the lowest level of detail-at the point of data entry-throughout the agency in a manner that ensures that when data is rolled up to the level that is standardized, it is consistent at the standardized level,

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

The OMB Circular A-127, “Financial Management Systems,” requires financial management systems to reflect an agency-wide financial information classification structure that is consistent with the U.S. Government Standard General Ledger (SGL), provides for tracking of specific program expenditures, and covers financially related information. Additionally, it states:

Financial management system designs shall support agency budget, accounting, and financial management reporting processes by providing consistent financial information for budget formulation, budget execution, programmatic and financial management, performance measurement, and financial statement preparation.

The accounting classification structure is a subset of the agency financial information classification structure, which also includes financially related personnel information, performance measurement information, and other financial information needed by the agency.  It provides the means for categorizing financial information along several dimensions as needed to support financial management and reporting functions.  The data elements a particular agency includes in its accounting classification structure will depend in part on the implementation strategy for the SGL (e.g., use of sub-accounts versus data elements), data aggregation requirements for preparation of financial statements under the CFO Act, appropriation structure, and other reporting and management needs of the agency.

Mandatory Requirements

To support the Accounting Classification Structure Management process, the Core financial system **must** provide the capability to:

· Classify accounting transactions by the following structures: fund, program, organization, project, activity, and budget sub function code, cost center and object class.  (CF-1)

· Achieve consistency in budget and accounting classifications and synchronization between those classifications and the organizational structure. Consistency will include maintaining data relationships between budget formulation classifications (budget functional classification code, see OMB Circular A-11) and budget execution and accounting classifications (Treasury Account Fund Symbols (TAFS)), and the agency’s organizational structure. (CF-2)

· Provide a fund structure that identifies appropriation and fund accounts established by OMB and Treasury, with additional detail below the appropriation level to support fiscal year accounting, appropriation sub-accounts used for reporting to Treasury, and financial statement preparation. (CF-3)

· Differentiate among the type of budgeting, accounting, and reporting treatments to be used for each funding mechanism (e.g., annual appropriation, multiyear appropriation, no-year appropriation, revolving fund, trust fund, receipt account, reimbursable fund). At a minimum, these characteristics must be supported: fund type, (e.g., general fund, deposit fund, trust fund, revolving fund); borrowing source: OMB function designations; budget status (e.g., on budget, off budget, or financing account); and the fiscal year designation (e.g., annual, multiyear, no-year obligation authority, reimbursable funds). (CF-4)

· Provide a program structure with sufficient levels of detail to allow reporting for all categories on which budgetary decisions are made, whether legally binding, as in appropriation limitations, or in the nature of policy guidance, as in Presidential pass-backs, or congressional markup tables. (CF-5)

· Establish an organization structure based on responsibility segments, such as offices, divisions, and branches. Provide for the ability to tie responsible organizational units to programs and projects. (CF-6)

· Capture Agency Location Codes (ALC’) and TAFS’ on all transactions and reports involving Treasury and other disbursing centers, including, but not limited to, the SF-224, “Statement of Cash Transactions”; SF-215, “Deposit Ticket,” and SF-5515, “Debit Voucher.” (CF-7)

· Provide a project structure that is independent of the other classification structures to allow multiple organizations, programs, and funding sources to be associated with a project. (CF-8)

· Provide an object class structure consistent with the standard object class codes contained in OMB Circular A-11, “Preparation and Submission of Budget Estimates.”   Provide flexibility to accommodate additional levels (higher and/or lower) in the object class structure. (CF-9)

· Provide a revenue source code structure to identify and classify types of revenue and receipts in sufficient detail to facilitate proper representation and/or eliminations on agency financial statements. At a minimum, the revenue source code structure must enable the user to differentiate between federal and non-federal revenue sources. For Federal sources, the structure must enable the user to differentiate between inter and intra-agency transactions, and the internal source entities for intra-agency transactions. (CF-10)

· Process additions, changes and deletions to the accounting classification structure without extensive program or system changes, (e.g., through on-line table updates). (CF-13)

· Enter, edit and store table changes for automatic processing at a future effective date. (CF-13C)

· Maintain historical reference tables for each fiscal year for all elements of the account structure for use in reconstruction of prior-year reports. (CF-13B)

· Provide for an automated method to reclassify accounting data at the document level when a reorganization of the classification structure is necessary.  Maintain an audit trail from the original postings to the final posting. (CF-15)  

· Prohibit new transactions from posting to accounting classification structures that have been deactivated. Provide a warning when table updates/changes affect pending transactions. (CF-15B)

· Account for budgetary resources at a lower level in the accounting classification structure than they are budgeted and controlled. (CF-14)

Value-added Requirements

To support the Accounting Classification Structure Management process, the Core financial system **should** provide the capability to:

· Test all transactions involving Treasury and other disbursing centers for valid combinations of ALC and fund, as defined by the user. (CF-7B)

· Derive the expanded accounting classification structure from abbreviated user input so that user input is minimized, data entry is made easier, and errors are controlled and reduced. Examples of methods include entering "shorthand codes", using a keyboard function to look up additional elements, "clicking" on a "pop-up menu," and scanning a bar code. (CF-12)

***Transaction Control Process***

The Transaction Control process defines, maintains and executes the posting and editing rules for transactions that are processed in the Core financial system.    In addition to recording transactions originally entered into the Core financial system, the Core financial system must be able to process and record transactions originating in other systems, as well as  keep track of such transactions and related information, in order to provide the basis for central financial control. 

The Transaction Control Process is further categorized as Transaction Definition and Processing activities, and Audit trail activities.

**Transaction Definition and Processing.** OMB Circular A-127 requires common processes to be used for processing similar kinds of transactions throughout an integrated financial management system to enable transactions to be reported in a consistent manner.  It also requires financial events to be recorded applying the requirements of the SGL at the transaction level. This is accomplished by defining a standard transaction(s) for each accounting event. SGL accounting transactions typically update multiple budgetary and proprietary accounts based on a single accounting event. The core financial system must ensure that all transactions are handled consistently, regardless of their point of origin.  It also must ensure that transactions are controlled properly to provide reasonable assurance that the recording, processing, and reporting of financial data are properly performed and that the completeness and accuracy of authorized transactions are ensured.

Mandatory Requirements

To support the Transaction Definition and Processing activity, the Core financial system **must** provide the capability to:

· Allow users to define standard transactions and posting and editing rules for all accounting events, including the associated accounting entries (i.e., debit and credit accounts) to be generated. (CF-26)

· Provide the ability to require or omit individual data elements of the accounting classification structure for each debit and credit of the transaction.  (CF-26B)

· Update all applicable SGL account balances (i.e., budgetary, proprietary and memorandum accounts) based on a single input transaction. (CF-27)

· Define, generate and post compound SGL debit and credit entries (at least 10 pairs) based on a single transaction. (CF-28)

· Define and process system-generated transactions, such as automated accruals (e.g., depreciation entries), pre-closing and closing entries, cost assignment transactions, recurring payments, and transactions that generate other transactions in those cases where a single transaction is not sufficient. (CF-29)

· Automatically liquidate, partially or in full, the balance of open documents by line item. This capability will be used in the liquidation of commitments, obligations, undelivered orders, payables, receivables and advances, upon the processing of subsequent related transactions (e.g., liquidate an obligation upon entry of the related receiving report). (CF-30)

· Provide controls to prevent the alteration of financial data except through the posting of transactions that are subject to the core financial system security, edits, validations and error correction procedures. (CF-40B)

· Control the correction and reprocessing of all erroneous transactions through the use of error/suspense files. Erroneous transactions must be maintained until either corrected and posted or deleted at the specific request of a user. (CF-41)

· Provide immediate, on-line notification to the user of erroneous transactions.  Advise reason for error and provide the ability to enter corrections on-line. (CF-41B)

· Query and modify, on-line, any interfaced data failing the edit routines. (CF-42B)

· Provide transaction edits that control, at a minimum, fund availability, accounting classification structure, and tolerance levels between related transactions, such as between an obligation and its related accrual. (CF-46)

· Provide controls to prevent the creation of duplicate transactions. (CF-47)

· Validate all codes entered by users on transactions, including, but not limited to: ACS, SGL, vendor, and transaction codes. Also, provide user inquiry capabilities through drop-down boxes or query screens. (CF-48) 

· Enter, edit, and store transactions in the current accounting period for automatic processing in a future accounting period. (CF-49).

· Put transactions in a hold status (saved, but not processed or posted) within the core system.  Allow users to select held transactions and continue processing at a later date. (CF-49B)

· Capture trading partner codes in the processing of intra-governmental and inter-governmental transactions. (CF-50)

· Capture transaction dates (effective date of the transaction), posting date (date transaction posted to general ledger), accounting period (year, quarter, month), and fiscal year for all transactions. (CF-56)

· Automatically determine the posting date from the system date for all transactions. Automatically insert a default accounting period on transactions, but allow user to override. (CF-57)

· Automatically reverse entries by user-defined parameters such as type, schedule, etc. (CF-58)

· Post to the current and prior months concurrently until month-end closing; maintain and provide on-line queries and reports on balances separately for the current and prior months. At a minimum, balances must be maintained on-line for both the current and prior months until prior month closing. (CF-39)

· Post to the current fiscal year and prior fiscal year concurrently until year-end closing. Provide on-line queries and reports on balances separately for the current and prior fiscal year. (CF-40)

Value-Added Requirements:

To support the Transaction Definition and Processing activity, the Core financial system **should** provide the capability to:

· Automatically generate pro forma transactions by accounting event or source/type of document without requiring the user to enter specific transaction codes and associated SGL accounts. (CF-33)

· Define, generate and post compound SGL debit and credit entries (more than ten pairs) based on a single transaction. (CF-28B)

· Perform validation checks for use of certain SGL accounts associated with specific Record Type 7 authority (e.g., imprest fund, borrowing authority) prior to posting a transaction. (CF-33B)

· Have all functions of the system, including budgeting, spending, accounts payable, and accounts receivable, process and track transactions in both foreign currency and U.S. dollars. (CF-51) 

· Calculate progress payments to foreign vendors based on current exchange rates. (CF-51B)

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

Mandatory Requirements

To support the Audit Trail activity, the Core financial system **must** provide the capability to:

· Provide audit trails to trace transactions from source documents, original input, other systems, system-generated transactions, and internal assignment transactions through related system processing.  (CF-34)

· Provide audit trails to trace source documents and transactions through successive levels of summarization to the financial statements data.  (CF-35) 

· Perform on-line "drill downs" from general ledger summary balances to detail transactions and associated source documents (e.g., purchase orders, receiving reports, etc.). (CF-34B)

· Select items for review based on user-defined criteria by type of transaction. Examples of reasons to select items are payment certification and financial statement audits. (CF-37)

· Provide audit trails that identify document input, change, approval, and deletions by user. (CF-38)

Value-added Requirements

To support this activity, the Core financial system **should**provide the capability to:

· Notify the feeder system of all errors identified for interface transactions that fail core financial system edits, (New)

· Propagate data input fields with values from existing tables or files, such as vendor information. (New)

***Archiving and Purging Process***

The Archiving and Purging process supports data management for the Core financial system.  It removes data that is no longer needed for immediate access from the system data stores used for inquiry and reporting on current information. Archiving moves data to a more permanent storage medium that generally also has a longer access time, for example, moving records from disk to tape. Purging deletes data altogether.  To balance user needs with resource limitations, the system administrator and users should jointly agree on archiving and purging criteria. 

Mandatory Requirements

To support the Archiving and Purging process, the Core financial system **must**provide the capability to:

· Establish and maintain user-defined archival and purging criteria, such as date, accounting period, closed items, vendors inactive for a specific time period. Allow for selective archiving and purging of those documents that meet the one or more of the criteria. (CF-54)

· Selectively retrieve archived records. (CF-52)

· Retain system records in accordance with Federal regulations established by the National Archives and Records Administration (NARA), GAO, and others.  (CF-55) 

General Ledger Management Function

General Ledger Management is the central function of the Core financial system. The general ledger is the highest level of summarization and must maintain account balances by the fund structure and individual general ledger accounts established in the Core Financial System Management function.  Depending on the agency’s reporting requirements, some or all general ledger accounts may have balances broken out by additional elements of the accounting classification structure and by attributes required to meet FACTS reporting requirements.

The General Ledger Account Definition process establishes the general ledger account structure for the agency in accordance with the SGL, and establishes the transaction edit and posting rules to record financial events. The prescribed basis for Federal agency accounting is the accrual basis (31 U.S.C. 3512(e)). The SGL account and transaction definitions and the form and content requirements for financial statements were developed consistent with this concept.

Subsidiary ledgers at various levels of detail support the general ledger.  These subsidiary ledgers may be maintained within the Core financial system or in other systems.  For example, detailed property records supporting the equipment account in the general ledger might be maintained in a system devoted to controlling and maintaining equipment.  The payroll system might contain detailed employee pay records that support records of expenditure by object class and organization in the Core financial system, which in turn provide partial support for expenditure and expense accounts in the general ledger.

All transactions to record financial events must post, either individually or in summary, to the general ledger, regardless of the origin of the transaction.  Posting of transactions whose initial point of entry is the Core financial system normally would be expected to occur for each transaction individually.  Posting of transactions originated in other systems may occur either for individual transactions or for summarized transactions as long as an adequate audit trail is maintained.  The Core financial system is not expected to maintain duplicates of every transaction occurring in other systems.  For example, rather than posting every payroll transaction for every employee, summary transactions by organization could be passed to the Core financial system for posting.

The General Ledger Management function consists of the following processes:

· General Ledger Account Definition 

· Accruals, Closing, and Consolidation

· General Ledger Analysis and Reconciliation.

***General Ledger Account Definition Process***

OMB Circular A-127, “Financial Management Systems,” requires implementation of the SGL at the transaction level. The SGL is described in a supplement to the Treasury Financial Manual (TFM) which includes the chart of accounts, account descriptions and postings, accounting transactions, suggested data elements/sub-accounts, and crosswalks to standard external reports.  Each agency must implement a chart of accounts that is consistent with the SGL and meets the agency’s information needs.

Mandatory Requirements

To support the General Ledger Account Definition process, the Core financial system **must** provide the capability to:

· Define and maintain a chart of accounts consistent with the SGL, including account titles and the basic numbering structure.  (CF-18)

· Incorporate both proprietary, budgetary and memorandum (credit reform) accounts in the system, and maintain the relationships between accounts as described in the SGL. (CF-19)

· Provide SGL control accounts for detailed subsidiary accounts in the core or external systems. (CF-21)

· Create additional sub-accounts to the SGL for agency specific tracking and control.  These sub-accounts will summarize to the appropriate SGL accounts. (CF-24)

· Capture general ledger information, including attributes, required for FACTS I and FACTS II reporting by TFM Transmittal Letter No. S2-01-01 or its successor.  (CF-18B)

· Provide flexibility so that the system can adapt to changing FACTS II data model and reporting requirement changes, such as by maintaining attributes in user updated tables. (R-8B)

· Process additions, deletions, and changes to the chart of accounts without extensive program or system changes, (e.g., through on-line table updates.) Provide a warning when table updates/changes affect pending transactions. (CF-20B)

· Prohibit new transactions from posting to general ledger accounts that have been de-activated. (CF-20C)

***Accruals, Closing and Consolidation Process***

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

Mandatory Requirements

To support the Accruals, Closing, and Consolidation process, the Core financial system **must** provide the capability to:

· Allow for accruals of contracts or other items that cross fiscal years. (SGL-6)

· Automatically generate selected recurring accrual entries and reversals in subsequent accounting periods based on user-defined criteria. (SGL-5)

· Close an accounting period and prohibit subsequent postings to the closed period. (SGL-3)

· Automatically determine an accounting period’s opening balances based on the prior accounting period’s closing balances, without intervention or adjustment. The rollover of SGL balances must be accomplished in a detailed manner so as to maintain FACTS attribute information (e.g. vendor type –government, non-government, department/bureau codes, funded/unfunded). (SGL-3B)

· Perform multiple preliminary year-end closings, while maintaining the capability to post current and prior period data.  (SGL-4)

· Generate fiscal year end pre-closing and closing entries as they relate to fund types and as defined by the user. (SGL-7)

· Automatically generate intra-entity elimination transactions, based on a six-digit trading partner codes or other alternative, reporting purposes only (with no effect on actual account balances). Provide for exception reporting of out-of-balance eliminations. (SGL-8)

· Provide for an automated year-end rollover of appropriate system tables into the new fiscal year. (SGL-11)

· Record and control upward and downward adjustments and recoveries of prior-year obligations in the appropriate fiscal year. (SGL-12)

***General Ledger Analysis and Reconciliation Process***

This process supports the control functions of the General Ledger.  The Core financial system provides information for accountants to use in determining that amounts posted to general ledger control accounts agree with more detailed subsidiary accounts and in reconciling system balances with financial information contained in reports from Treasury and other agencies.  As internal controls improve and system integration increases, the likelihood of out-of-balance conditions decreases; however, the possibility of such conditions will always exist as a result of system failures, incorrect transaction definitions, etc.

Mandatory Requirements

To support the General Ledger Analysis and Reconciliation process, the Core financial system ***must*** provide the capability to:

· Compare amounts in the general ledger accounts with the amounts in the related subsidiary records and report those accounts that are out of balance. This capability must be available for all open accounting period balances and at frequencies defined by the user. (SGL-13)

· Record the on-line correction of out-of-balance conditions discovered during the reconciliation of general ledger controls accounts to subsidiary records. Maintain an audit trail of all such corrections. (SGL-15)

· Perform on-line "drill downs" from general ledger summary balances to detail transactions and associated documents (e.g., purchase orders, receiving reports, etc.). (CF-34B)

· Maintain historical data to produce comparative financial reports and statements. (SGL-2)

· Allow closed documents to be reopened at the document control level with all associated transaction history. The control totals and balances in the month in which the document was closed will not be affected by a reopened document. Adjustments to the reopened document will only affect control totals and balances in the open accounting period in which the document was reopened. (CF-53)

**Funds Management Function**

Each agency of the Federal government is responsible for establishing a system for ensuring that it does not obligate or disburse funds in excess of those appropriated and/or authorized.  The Funds Management function of the Core financial system is****an agency’s primary tool for carrying out this responsibility.

OMB Circular A-34, “Instructions on Budget Execution,” and, to a lesser extent, OMB Circular A-11, “Preparation and Submission of Budget Estimates,” set government-wide policy for funds management with which the Core financial system must conform.  In addition to supporting the government-wide policies, the Funds Management function must support agency policies on internal funds allocation methods and controls.

An agency may have many other systems in addition to the Core financial system that affects funds management.  For example, procurement and travel systems prepare documents that commit and obligate funds.  These and other systems that affect funds availability should access data and use processes of the Core financial system to verify that funds are available and to update balances.  When possible and cost-effective, these systems should access the funds availability editing activity before allowing an obligation to be incurred, such as a contract being signed.  In some cases, such as payroll, this may not be practical.

The Funds Management function consists of the following processes:

· Budget Preparation

· Budget Formulation

· Funds Allocation

· Budget Execution

· Funds Control

***Budget Preparation Process***

Budget preparation is the process of establishing initial agency financial resource plans and updating them as necessary throughout the fiscal year.  The function includes reporting on the use of resources against these plans throughout the year.  

Mandatory Requirements

To support the Budget Preparation process, the Core financial system **must** provide the capability to:

· Establish and maintain operating plans at or below the level of funds control. (FD-8)

· Establish operating plans by month and quarter at any level of the organizational structure specified by the user. (BP-2)

· Track and report on the use of funds against operating plans. (FD-50 and FD-51)

Value-added Requirements

To support the Budget Preparation process, the Core financial system **should** provide the capability to:

· Prepare operating plans based on multiple measures, including obligations, costs, labor hours, and full-time equivalents (FTEs). (BP-5)

· Modify/revise an existing operating plan by line item. (BP-1)

· Maintain original and modified operating plans. (BP-4)

· Identify legal and administrative limitations on funds in operating plans. (BP-6)

· Automatically generate allotments and sub-allotments (including limitations based on approved changes to obligation-based financial plans) and upload them to the core financial system. (BP-7)

· Enter financial plans for future operating periods. (BP-3)

· Roll future plans into active budget plans based on future date or retrieval function. (BP-8)

***Budget Formulation Process***

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

Value-added Requirements

To support the Budget Formulation process, the Core financial system **should** provide the capability to:

· Report for all categories on which budgetary decisions are made, whether legally binding (e.g., appropriation limitations) or in the nature of policy guidance and decision-making (e.g., Presidential/OMB pass-backs, congressional markup documents, or internal agency decisions). (BF-1)

· Populate the budget formulation system with prior-year budgeted and actual amounts. (BF-3)

· Perform projections of obligations, income, and expenditures at any level of the organizational structure (e.g., projecting obligations based on prior periods and applying these to a future period.) (BF-4)

· Adjust projection rates (e.g., 90 percent, 100 percent, and 110 percent) and exclude specified obligations from projection. (BF-11)

· Create, store, and modify payroll forecasts, including anticipated monthly compensation and benefits, at the individual employee level. (BF-11B)

· Incorporate overhead distribution as part of budget formulation. (BF-11D)

· Develop budgets on-line and via upload from spreadsheets. (BF-2)

· Prepare budget submission guidance, budget narratives, and budget briefing packages on-line and via upload from desktop software applications. (BF-6)

· Distribute budget submission guidance to subordinate organizations electronically. (BF-5)

· Establish and maintain multiple budget cycles. (BF-10)

· Tie budget formulation and execution to Government Performance and Results Act (GPRA) goals and objectives. (BF-11C)

***Funds Allocation Process***

This process records an agency’s budgetary resources and supports the establishment of budgetary limitations at each of the levels required within the agency.  The higher levels, such as appropriation, apportionment and allotment, have the weight of legal authority behind the limitations.  Lower levels of control are generally used for internal management purposes.

Mandatory Requirements

To support the Funds Allocation process, the Core financial system **must** provide the capability to:

· Record funding and related budget execution documents (e.g., warrants, apportionments, allotments) and limitations. (FD-1)

· Control the use of funds against limitations consistent with appropriation and authorization language (including congressional intent and continuing resolutions) and administrative limitations established by agency management. (FD-2)

· Distribute, track, control, and report funds authorized at various funding levels, based on the accounting classification structure and project structure. (FD-4)

· Verify that funds allocated do not exceed the amount of funds available at each distribution level. (FD-4B)

· Support 1990 Public Law (P. L.) 101-510 M-year legislation by assuring that amounts paid out of current year funds to cover obligations made against a closed account do not exceed 1 percent of the current year appropriation. (FD-4C)

· Record and control funds that receive other budgetary authority in addition to appropriations, including offsetting collections, receipts (when authorized by law); reimbursements; and trust funds and donations. Identify the type of authority and track obligations by funding source (e.g. reimbursable, appropriated direct). (FD-6)

· Record the expiration and cancellation of appropriation authority in accordance with OMB Circular A-34 and the SGL. (FD-7)

· Account for spending transactions at a lower level in the accounting classification structure than they are budgeted. (FD-10)

Value-added Requirements

To support the Funds Allocation process, the Core financial system **should** provide the capability to:

· Automatically generate SF-132 Apportionment and Reapportionment Schedule and store associated financial information. (FD-1B)

· Support 1990 P. L. 101-510 M-year legislation by assuring that amounts paid out of current year funds to cover obligations made against a closed account do not exceed 1 percent of the current year appropriation and also do not exceed the original appropriation of the closed account. (FD-4C)

· Prepare apportionment requests on-line and electronically transmit them to OMB. Store prepared requests as submitted for future use. (FD-11)

· Generate budget execution data in format required by OMB's MAX system.  (FD-11B)

· Automatically prepare the formal allotment and sub-allotment documents based on changes to obligation-based financial plans and electronically distribute them to subordinate organizations. (FD-12)

***Budget Execution Process***

The Budget Execution process is the highest level of an Agency’s funds control and consists of processes needed to ensure that where the agency’s fund control systems are fully supported by its accounting systems. It also consists of processes needed to track an agency’s budget authority and manage prior-year funds in the current year. The timeframe covered by an agency’s fund control system will correspond to the agency’s financial plans. Allotment systems should be designed so that responsibility for budget control is placed at the highest practical organizational level consistent with effective and efficient management and control.

Mandatory Requirements

To support the Budget Execution process, the Core financial system **must** provide the capability to:

· Record budget authority at multiple levels of distribution (at least five). (BE-1)

· Track and record all changes to budget authority - including rescissions, supplementals, transfers between appropriations, reprogramming, limitations and changes to continuing resolutions prior to appropriation enactment - at multiple levels of distribution (at least five). (BE-1B)

· Track actual amounts (e.g., commitments and obligations) against the original budget as revised, consistent with each budget distribution level. (BE-2) 

· Modify funding distribution (including allotments and apportionments) at multiple organizational levels (at least five).  (BE-3)

· Manage and control prior-year funds in the current year. Identify and report current year increases and decreases to prior-year obligations (i.e., prior-year recoveries) by fiscal year appropriated. (BE-4)

· Establish and maintain user-defined tolerances by document type, percentage, and/or a not-to-exceed dollar threshold. (BE-6)

· Automatically withdraw (or cancel) uncommitted and/or unobligated allotments and sub-allotments for all or selected appropriations at the end of a specific fiscal period. (BE-7)

· Automatically withdraw (or cancel) uncommitted and/or un-obligated allotments and sub-allotments for selected organizations at the end of a specific fiscal period. (BE-8)

Value-added Requirements

To support the Budget Execution process, the Core financial system **should** provide the capability to:

· Perform automated distribution of changes in budget authority (e.g., rescissions). (BE-3B)

· Request approval for reprogramming and request additional funds outside the periodic budget review process.  Allow such requests to be submitted, reviewed, revised, and approved.  Approval would update current operating budgets. (BE-3C)

· Establish limitations in accordance with credit reform objectives for loan programs, including program lending limits and available subsidy amounts. (BE-5)

· Create continuing resolution funding levels based on a percentage of prior-year funding. (BE-10)

· Generate budget execution transactions from the budget formulation structure and accounts. (BE-13)

***Funds Control Process***

This process records transactions affecting the resource usage accounts in the budgetary section of the SGL (e.g., commitments, undelivered orders, expenditures, reimbursements earned).  It also provides appropriate warnings and controls to ensure that budgetary limitations are not exceeded.  The Funds Control process consists of the following activities: 

· Funds Availability Editing

· Commitments

· Obligations

· Analysis.

**Funds Availability Editing.**This activity verifies that sufficient funds are available at the various control levels specified in the Funds Allocation process for each processed transaction that may affect available fund balances.  If sufficient funds are not available, notification is provided so that appropriate action may be taken.

Mandatory Requirements

To support the Funds Availability Editing activity, the Core financial system **must** provide the capability to:

· Establish and modify multiple levels of funds control using elements of the classification structure, including object class, program, organization, project, and fund.  (FD-15)

· Establish and modify the system’s response (either reject transaction or provide warning) to the failure of a funds availability edit for each transaction type.  (FD-16)

· Perform on-line checking of funds availability prior to the processing of spending transactions (commitments, obligations, and expenditures). (FD-13)

· Use appropriate calculations to determine funds availability based on whether funds cited are current, expired, or canceled and record appropriate accounting entries for the use of these funds.  Properly account for prior-year de-obligations and do not allow the use of these funds for current year expenditures. (FD-21)

· Provide the capability for external modules or systems to access the financial system to perform funds availability checking. (FD-13B)

· Record transactions that affect the availability of funds, including commitments, obligations, undelivered orders, and expenditures. (FD-18)

· Provide for modification to spending documents (commitments, obligations and expenditures), including ones that change the dollar amount or the accounting classification structure cited.  Check available funds for changes. (FD-23)

· Provide on-line notification to users of transactions failing funds availability edits, and place the rejected transactions in an error/suspense file for corrective action.  This is to include transactions entered directly to the core system and those received from external modules or systems. (FD-19)

· Override funds availability edits, including transactions rejected for exceeding user-defined tolerances. Produce a report or otherwise notify management of the over obligation of funds.  (FD-14 and FD-17)

· Update all appropriate accounts to ensure that the system always maintains and reports the current status of funds. (FD-20)

· Check available funds when the obligation exceeds the commitment document or the expenditure (upon receipt or disbursement) exceeds the obligating document due to quantity or price variances, additional shipping charges, etc., within tolerances. Provide on-line notification when tolerances are exceeded. Within tolerances, adjust the obligation accordingly. (FD-24 and FD-24B)

· Adjust available fund balances as reimbursable orders are accepted. In the case of reimbursable orders from the public, an advance must also be received before additional funding authority is recorded. (FD-25)

· Track all activity related to an individual reimbursable agreement. Check available funds for commitments, obligations, and expenditures incurred in support of reimbursable agreements against the amount authorized by the agreement and the corresponding start and end dates. (FD-26)

· Record and maintain reimbursable agreements, (e.g., inter-agency agreements,) so that monthly, quarterly, and fiscal year-to-date as well as inception-to-date information can be presented. (FD-26B)

Value-added Requirements

To support the Funds Availability Editing activity, the Core financial system **should** provide the capability to:

· Automatically notify users when funds availability is reduced by transactions from external systems (e.g., credit card payments, and payroll). (FD-14B)

**Commitments.**This activity records commitment documents, such as requisitions. Commitments are an optional stage prior to the establishment of an obligation. Commitments can be a useful tool in funds management by helping users to anticipate future procurements.  They should be used when helpful to an agency’s management process, but are not necessary, or even appropriate, for all obligations.

Mandatory Requirements

To support the Commitment activity, the Core financial system **must** provide the capability to:

· Allow commitment documents to be entered into the Core financial system on-line and from multiple locations, as well as through interfaces with other systems. (FD-27)

· Maintain information related to each commitment document, including amendments. At a minimum, the Core financial system must capture:

· requisition number,

· accounting classification structures, and

· estimated amounts. (FD-28)

· Input line item detail for commitment, obligation, receiving, and invoice/voucher documents, including item description, unit price, quantity of goods and/or services, accounting information, and amounts. (FD-29B)

· Future-date, store, and automatically post commitment documents at the appropriate date. Subject these documents to edit and validation procedures prior to posting. Provide notification when transactions are posted. (FD-30)

· Close commitments by document and line item under the following circumstances: (1) by the system upon issuance of an obligating document, (2) by an authorized user, and (3) as part of the year-end pre-closing process. (FD-31)

**Obligations.**OMB Circular A-34 defines obligations as amounts of orders placed, contracts awarded, services received, and similar transactions during a given period that will require payments during the same or a future period. Such amounts include outlays for which obligations had not been previously recorded and reflect adjustments for differences between obligations previously recorded and actual outlays to liquidate those obligations.

Mandatory Requirements

To support the Obligation activity, the Core financial system **must** provide the capability to:

· Allow vendor used on obligation to be different from suggested vendor recorded on a commitment document. (FD-32B)

· Record obligations for which there is no related commitment. (FD-33)

· Maintain information related to obligation documents and related amendments, including obligating document number and type; vendor information, accounting classification structures, referenced commitment (if applicable); and dollar amounts. (FD-34)

· Future-date, store, and automatically post obligation documents at the appropriate date. Subject these documents to edit and validation procedures prior to posting. Provide notification when transactions are posted. (FD-36)

· Enter recurring obligation transactions that will be automatically posted at user-defined time intervals. (FD-36B)

· Allow multiple commitments to be combined into one obligating document and one commitment document to be split between multiple obligating documents. (FD-37)

· Combine multiple funding sources on a single commitment or obligation. (FD-37B)

· Allow authorized modifications and cancellations of posted obligating documents. (FD-38)

· Provide on-line access to all obligations by selection criteria, (e.g., document number.) (FD-39)

· Maintain an on-line history file of closed-out documents for a user-defined period of time. (FD-40)

· Close obligation documents under the following circumstances: (1) automatically by the system upon final payment for goods or services, or (2) by an authorized user.  Upon the closing of an obligation, automatically return excess obligated funds to the appropriate budgetary account code structure. (FD-42)

· Record and maintain contracts and grants so that fiscal year-to-date and inception-to-date information can be presented. (FD-44)

· Record blanket purchase agreements (BPAs), and record, control, and track records of call. (FD-45)

· Record, control, and track delivery orders against a contract limitation. (FD-46)

· Record advance payments made, such as travel advances, contract advances, and grants. Ensure that an obligation exists prior to recording an advance. (FD-48B)

· Record expenditures claimed against advance payments made, and automatically liquidate the advance either partially or fully, as appropriate. (FD-48)

· Automatically link transactions in the spending chain, and bring forward accounting and non-financial information from one document to another, when the previously accepted document is referenced, e.g., commitment to obligation, obligation to receiving report). (FD-48B)

· Provide the capability to have more than one ALC per Agency. (FD-59C)

Value-added Requirements

To support the Obligation activity, the Core financial system **should** provide the capability to:

· Maintain the following additional data fields for each obligating document:

· Reference number

· Requester’s name

· Telephone number of requester

· Contract number/GSA schedule number

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

· Comment field

· Contact name

· COTR name

· COTR telephone number

· Prompt Pay indicator

· Approval date

· Discount indicator. (FD-34B)

· Record Central Contract Registration (CCR) numbers and track activity against them. (New)

**Analysis.**The Analysis activity provides information necessary to support analysis of the Funds Management function.  It provides information on funds availability at the levels defined and compares data in the Funds Management function to data in other functions to ensure consistency.

Mandatory Requirements

To support the Analysis activity, the Core financial system **must** provide the capability to:

· Maintain current information on commitments and obligations according to the accounting classification structure. (FD-49)

· Produce detailed listings and summary reports of commitments, obligations and expenditures by the defined accounting classification structure and by user-defined criteria. (FD-53)

· Provide control features that ensure that the amounts reflected in the fund control structure agree with the SGL account balances at the end of each update cycle. (FD-54)

· Maintain historical data on all commitment, obligation, payment and collection transactions. (FD-55)

· Maintain open documents to show the status of commitments, obligations, accruals, and disbursements by document line item. (FD-56)

**Payment Management Function**

The Payment Management function should provide appropriate control over all payments made by or on behalf of an agency.  Agencies make payments to vendors in accordance with contracts; to state governments under a variety of programs; to employees for salaries and expense reimbursements; to other Federal agencies for reimbursable work performed; to individual citizens receiving Federal benefits; to recipients of Federal loans; and for many other reasons.

Title 5 Part 1315 of the CFR (codification of OMB Circular A-125, “Prompt Payment”) specifies government policy for payments made to vendors against contracts. It states, in part, that agencies must make payments on time, pay interest penalties 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.  The CMIA specifies requirements for payments made to states.  Regulations implementing CMIA are at 31 CFR 205. The Debt Collection Improvement Act of 1996 (DCIA) provides for access to taxpayer identification numbers (TINs) and enhanced administrative offset and salary offset authorities. Other regulations affect payments made for travel, payroll, benefits, and other purposes.

Depending on an agency’s system architecture, specific activities performed relating to payments may be supported by other systems that provide transaction data to the Core financial system for control and management purposes.  For example, payroll systems usually trigger the actual disbursement process to pay employees through direct deposit or by check, and send only the expense and disbursement information to the Core financial system for recording by the general ledger, funds control, and cost management processes.  Likewise, large loan and grant programs might be supported by systems that maintain their own detailed information on payees and payments and send transaction data to the Core financial system.  If this situation exists, these other systems must meet the requirements listed here for payment management.

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

The Payment Management function consists of the following processes: 

· Payee Information Maintenance

· Payment Warehousing

· Payment Execution

· Payment Confirmation and Follow-up.

***Payee Information Maintenance Process***

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

Mandatory Requirements

To support the Payee Information Maintenance process, the Core financial system **must** provide the capability to:

· Maintain payee (vendor) information to support obligation, accounts payable, and disbursement processes, including, at a minimum:

· Vendor name

· Vendor ID number

· Vendor type

· TIN

· Multiple payment address(es)

· Multiple bank account and routing information 

· Multiple contact names

· Multiple contact telephone numbers

· Federal vs. Non-Federal indicator

· six-digit Trading Partner codes

· Entity type (e.g., small business, 8A, women owned business,)

· Multiple vendor payment methods (e.g., cash, EFT, or check)

· Third-party information

· Data Universal Numbering System (DUNS) number

· ALC number (for federal vendors)

· Internal Revenue Service (IRS) -1099 indicator

· W-2 indicator

· Comment field

· Date of last update

· User ID of last update.(PM-4)

· Support payments made to third parties (payees) that act as an agent for the payee (vendor). Maintain IRS -1099 information for the principal party rather than the agent. (PM-2)

· Prevent the duplicate entry of vendor records, (e.g., by editing TINs, vendor ID numbers, or vendor names.)  Provide an on-line warning message to the user when duplication is identified. (PM-4D)

· Track and maintain a history of vendor file changes, including the retention of information with payment history. (PM-4B)

· Query and report on payee information by user-defined criteria, such as payee name, payee number, and IRS -1099 reporting status. (PM-5)

· Activate and deactivate vendors that meet user selected criteria. (PM-4C)

Value-added Requirements

To support the Payee Information Maintenance process, the core financial system **should** provide the capability to:

· Maintain payee information that includes, at a minimum, the following elements:

· Subject to Prompt Pay Indicator

· Country Code

· Payee TIN for Notice of Assignment.

***Payment Warehousing Process***

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

Title 5, Part 1315 of the CFR requires documentation to support payment of invoices and interest penalties, including information from contracts, purchase orders, invoices, and receiving reports.  These documents should be matched through a process, which may be automated, manual, or a combination, that ensures that payments are made in accordance with contract terms and applicable regulations.  Adequate internal controls should be in place to verify that goods and services paid for were actually ordered and received and are paid for only once and at the agreed-upon price.

Mandatory Requirements

To support the Payment Warehousing process, the Core financial system **must** provide the capability to:

· Record an accrued liability upon receipt and acceptance of goods and services and properly identify them as capital asset, expense, prepaid expense, or construction. (PM-8)

· Record "full" or "partial" receipt and/or acceptance of goods and services by line item, and link with the matching process. (PM-8B)

· Automatically update the funds control and budget execution balances to reflect changes in the status of undelivered orders and expended appropriations, as well as changes in amounts. (PM-15)

· Warehouse payments for future scheduling.

· Allow a warehoused payment to be modified, cancelled, or put on hold. (PM-18)

· Automatically match invoices to obligations and receiving reports by document and line item. Provide for two-way matching (obligation and invoice) and three-way matching (obligation, receiving report, and invoice). (PM-55D)

· Process "obligate and pay" transactions where payment scheduling and obligation occurs simultaneously. (PM-55E)

· Reference multiple obligations on a single invoice document. (PM-55F)

· Set up recurring payments in the system and to automatically schedule for payment, (e.g. contracts, leases, etc.) (PM-55G)

· Modify recurring payment information for changes in agreement terms, amounts, frequency, etc. (PM-55I)

· Capture, store, and process invoices received in electronic format through an electronic commerce arrangement or from another system. (PM-24)

· Capture, store, and process invoice information required by Title 5, Part 1315 of the CFR, including: 

· invoice number

· invoice amount

· obligating document references

· vendor TIN

· vendor number

· IRS -1099 indicator

· DUNS number

· payee name and address 

· country code

· payee banking information

· discount terms

· unit price and quantity

· invoice amount

· invoice date

· invoice receipt date, and 

· description. (PM-7B) 

· Edit the TIN field to ensure that it is a 9 digit numeric field, does not include dashes, and is not all zeroes. Allow for override. (PM-37E)

· Accommodate an invoice number field of up to 30 characters or the current requirement of 1 TFM 6-5000. (PM-25)

· Allow single invoice documents to reference multiple obligations. (PM-55F)

· Determine the due date and amount of vendor payments in accordance with Title 5, Part 1315 of the CFR which states that payment is due on either: 1) the date specified in the contract; 2) in accordance with discount terms when discounts are offered an taken; 3) in accordance with Accelerated Payments Methods; or 4) 30 days after the start of a payment period, when a proper invoice is received. (PM-10)

· Manually override a system-calculated payment due date. (PM-10D)

· Split an invoice into multiple payments on the appropriate due dates when items on the invoice have different due dates or discount terms. (PM-11)

· Record discount terms and automatically determine whether taking the discount is economically justified as defined in Volume I, section 6-8040 of the TFM. (PM-12)

· Record additional shipping and other charges to adjust the payment amount, if they are authorized. (PM-13)

· Set tolerances as a percentage or amount, between commitments and obligations, obligations and invoices, obligations and receipts, and receipts and invoices.  Establish tolerances for both unit price and extended amount at the line-item level. (PM-14B)

· Provide-line notification of spending transactions that exceed user-defined tolerances.  Allow for override of the rejection of these. (PM-14C)

· Record obligations, expenses, assets, etc., associated with payments made through use of imprest funds, third-party drafts, and government credit cards. Establish payables to replenish the imprest fund. (PM-21)

· Record detailed transactions associated with credit card purchases, including merchant data to allow for IRS -1099 reporting.  Allow users to change accounting information by line item for specific transactions. (PM-21B)

· Schedule payments of advances, prepaid expenses, loans, and grants, with the appropriate accounting entries for each. (PM-22)

· Establish payables and make payments on behalf of another agency, citing the other agency’s funding information. (PM-16)

· Record expense or assets upon the performance that was funded by advances, prepaid expenses, and grants, and make the appropriate liquidations. Check available funds and automatically update funds control balances to reflect obligation changes. Ensure that total advances and disbursements do not exceed obligated amounts. (PM-23)

· Indicate if a payment is "partial" or "final."  If "final", automatically de-obligate any unliquidated balances. (PM-25B)

· Allow closed obligations to be reopened after final payment has been made. (PM-17)

· Reverse disbursement transactions for voided checks or for other payments that have not been negotiated. (PM-20)

***Payment Execution Process***

This process supports activities required to make a payment that was warehoused or to record a payment made by another system. The system should provide the capability to capture, store and process information needed to create EFT payments for agencies for which Treasury does the actual disbursing and prepare requests for disbursements that are transmitted to Treasury.  Some agencies have their own disbursing authority and can print checks or make electronic transfers themselves.

Mandatory Requirements

To support the Payment Execution process, the Core financial system **must** provide the capability:

· Automatically identify and select payments to be disbursed in a particular payment cycle based on their due dates. Provide for on-line review and certification by an authorized certifying officer. (PM-28).

· Automatically compute amounts to be disbursed, including discounts, withholdings, interest, or penalties, in accordance with Title 5, Part 1315 of the CFR. Generate the appropriate transactions to reflect the above deductions and additions. (PM-30)

· Apply interest and discount across multiple accounting lines on an invoice. (PM-30B)

· Apply the appropriate Treasury interest rate tables, (e.g., Prompt Pay rate, Current Value of Funds rate, and Late Payment Charge rate for debt collection.) Allow for override. (PM-30C)

· Capture prompt payment information required by Title 5, Part 1315 of the CFR, including discounts taken, discounts lost, and interest penalties paid. (PM-32)

· Automatically include relevant identification information on each payment, including invoice number, obligating document number, discounts, withholdings, offsets, and interest. (PM-31)

· Record user comments for each voucher/invoice. (PM-55B)

· Record reason codes for returned and adjusted invoices, lost discounts, and late payments. (PM-55C)

· Identify and report payment/deposit amounts at a detail suitable for reporting large dollar notifications as described in I TFM, Part 6, Chapter 8500, Cash Forecasting Requirements. (PM-33B)

· Include on each payment the applicable payment type and CASH TRACK line item code(s) used for cash management purposes. (PM-33C)

· Generate Automated Clearing House (ACH) payments in CTX (820 or Flat File), CCD+, PPD, and PPD+ formats.  (PM-34)

· Ensure that employee ACH payments are generated only as PPD or PPD+ payments, and that vendor ACH payments are generated only as CCD+ or CTX formats.

· Prohibit the creation of an ACH payment in any format (PPD, PPD+, CCD+, or CTX) that does not contain an Routing Transit Number (RTN) and an account number. (PM-37G)

· Consolidate multiple payments to a single payee in accordance with TFM prescribed limitations (currently up to 14 lines of 55 characters each for check payments, up to 9,999 lines of 80 characters each for CTX payments). Itemize all payments covered by the one check or EFT (CTX only). Allow for separate checks to a payee.  (PM-35)

· Split a single payment into separate bank accounts (e.g., benefit payments.)

· Create payment files (all formats) using different media (telecommunications, tape, Electronic Certification System (ECS), third-Party upload). (PM-37)

· Provide an edit on the bank electronic routing number  RTN field.  The field is a nine-digit numeric-only field.  Prohibit fewer or more characters, allow for only numeric characters, and prohibit the entry of all zeroes in this field.  Edit RTN’s against the data supplied by in the Financial Organization Master  File (FOMF) to ensure the validity of the check digit (Modulus 10 check). (PM-37B)

· Edit the invoice number field to ensure it is populated.  Prohibit the generation of a (vendor) payment that does not contain properly structured remittance information. (PM-37C)

· Generate multiple payments using the same invoice number, since utility and telecommunications companies use an account number as a recurring invoice number.  (PM-37D)

· Edit the ALC field to ensure it is an eight digit numeric field. (PM-37F)

· Create one check or ACH file regardless of payee type (employee or vendor). (PM-37H)

· Combine files from multiple ALCs into a single file for transmission to Treasury.  Provide summary totals (items and dollars) by ALC and for the entire file for certification purposes. (PM-37I)

· Make CTX payments using a separate file.  The transactions need to be balanced (sum of all the remittance records must equal the transaction total).  The file must include a valid settlement date (next business day or later).  The file must be able to accommodate the inclusion of Credit Memos.  (PM-37J)

· Provide the capability to schedule and disburse U.S. dollar payments (SF1166) through the Treasury’s ECS.  ECS has a limitation of 60 payments per schedule and 200 schedules for each ALC per day. (PM-37K)

· Process payment transactions from other systems, such as payroll and travel.  Identify whether or not disbursement has already been made, and record the appropriate accounting entries.  Schedule those disbursements not already made for payment through the core financial system.  (PM-39)

· Record disbursements made by another federal agency, on behalf of the agency using agency funds, through central electronic systems such as Intra-governmental Payment and Collection (IPAC) system. (PM-40)

· Flag payment transactions that will disburse a fund into a negative cash position. (Reimbursable work can result in this type of transaction with appropriate authority.) (PM-43)

· Process credit memoranda for returned goods or other adjustments. Apply the credit to the specific obligation that resulted in the credit, reducing the expense attributed to that obligation. If a credit is not fully liquidated by one payment, maintain the balance of the credit (e.g., as an account receivable) for application against a future payment. Create the appropriate notice to the vendor that a credit has been applied to the affected payment. (PM-19)

· Apply credits against subsequent disbursements to the same vendor regardless of the funding source. (PM-27)

· Automatically offset payments to vendors for amounts due to the agency, i.e., credit memos, outstanding accounts receivable, and open advances. When an entire payment is offset, create the appropriate notice to the vendor that the offset has been made. (PM-55J)

· Allow for the exclusion of certain payments from the offset function based on user-defined criteria such as object class, vendor, vendor type, and funding source. (New)

· Provide, generate, and maintain a sequential numbering system for scheduling payments to the disbursing office.  Assign different schedule number ranges for different payment types, such as travel schedules, transportation schedules, payroll schedules, vendor schedules, etc.  Require each schedule number to be unique. (PM-7B)

· Report the total amount by appropriation on each payment schedule. (PM-33)

· Provide statistical sampling capabilities to support final payment certification. (New)

· Cancel an entire payment schedule or a single payment within a payment schedule, prior to actual disbursement by Treasury. Allow for reversal of an entire schedule in a single, interactive action. (PM-42) 

Value-added Requirements

To support the Payment Execution process, the Core financial system **should** provide the capability to:

· Provide unlimited line items per invoice. (PM-44B)

· Track the status of invoices in the payment process, including those that were not accepted and returned to the vendor and those that are awaiting administrative approval.  Maintain the time and aging of approvals in relation to payments. (PM-44D)

***Payment Confirmation and Follow-up Process***

This process confirms that disbursements were made as anticipated and supports inquiries from vendors regarding payments and reporting requirements relating to the Payment Management function.

Mandatory Requirements

To support the Payment Confirmation and Follow-up process, the Core financial system **must** provide the capability to:

· Provide information about each payment to reflect the stage of the scheduling process that the payment has reached and the date each step was reached for the following processing steps:

· Payment scheduled

· Schedule sent to appropriate disbursing office

· Payment issued by appropriate disbursing office. (PM-45)

· Automatically update the payment information when confirmation is received from the disbursing office, including the paid schedule number, check numbers or trace numbers, and date, amount of payment, payment method (check or EFT). (PM-47)

· Automatically liquidate the in-transit amount and reclassify budgetary accounts from unpaid to paid when the payment confirmation updates the system. (PM-55)

· Accommodate the assignment by Treasury of more than one check range to a payment schedule, along with a break in check numbers. (New)

· Maintain a history of every payment by the Core financial system, including authorizing document number, payment schedule number, payment date, invoice number, vendor number, vendor name, payment address, appropriation charged, and prompt payment information. (PM-48)

· Maintain a history of payment calculations made by the core financial system to include discounts, withholdings, interest, or penalties that resulted in deductions or additions to the original invoice amount. (PM-48A)

· Provide on-line access to vendor and payment information. (PM-49)

· Provide on-line access to open documents based on agency selection criteria, including accounting classification structure, document number, and vendor number. (PM-50)

· Produce IRS-1099s (including 1099-INT, 1099-MISC, 1099-C and 1099-G) in accordance with IRS regulations, such as for services only (1099-C) or for activity over a specified dollar amount (1099-MISC). Produce IRS -1099s in current IRS acceptable format, including hard copy and electronic form. (PM-51)

**Receipt Management Function**

The Receipt Management function supports activities associated with recording agency cash receipts, including servicing and collecting receivables.  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), loans made to others that must be repaid, or other actions.  Some receipts may be collected without the prior establishment of a receivable, as in the case of goods sold for cash.

A receivable is recognized when the agency establishes a claim to cash or other assets against other entities, either based on goods or services provided or on legal provisions, such as a payment due date (e.g., taxes not received by the date they are due).  If the exact amount is unknown, a reasonable estimate is made.  Receivables are accounted for as assets until funds are collected, converted into other resources, or determined to be uncollectible in whole or in part.

Depending on an agency’s system architecture, servicing and collection activities for some receivables may be supported by other systems that provide data to the Core financial system.  This would be particularly appropriate for receivables resulting from large programs with complex supporting data requirements, such as loan programs, grant programs, or fee-for-service programs.  Servicing and collection for receivables with simpler requirements for supporting data, such as those resulting from erroneous payments, may be supported directly by the Core financial system with no support by other systems.

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

The Receipt Management function consists of the following processes:

· Receivable Establishment

· Receivable Management

· Collections

· Offset.

***Receivable Establishment Process***

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

Mandatory Requirements

To support the Receivable Establishment process, the Core financial system **must** provide the capability to:

· Record the establishment of receivables along with the corresponding revenues, expense reductions, or other offsets. (RM-2)

· Support the automatic establishment and tracking of receivables to be paid under installment plans, including plans for which payments have been rescheduled.  

Provide for the generation of repayment schedules for delinquent indebtedness. (RM-3)

· Accept transactions that generate receivables from other systems in a standard format for entry into the Core financial system. (RM-10)

· Support the calculation, automatic generation, and posting of (billed or unbilled) customer bills based upon billing source, event and/or time period, and type of claim. Bases used for billing may include:

· percentage of reimbursable obligations, accrued expenditures, or costs, using data recorded by the cost accumulation function;

· fee schedules for goods or services provided;

· duplicate payments;

· erroneous payments; and

· payment schedules or other agreements with other entities. (RM-1)

· Receive automated billing files from an outside source and use to create bills in the applicable format (EDI or non-EDI). (RM-36)

· Uniquely identify multiple types of bills (e.g., reimbursable agreements, user fees) and the supporting data used to verify the specific charges, each with the appropriate data fields. (RM-2B)

· Record billings and collections by line item in order to identify unique financial data such as accounting classification codes, claim numbers, customer order numbers, and descriptive information. (RM-2C)

· Print bills, accommodating the generation of standard forms, such as SF-1080s or SF-1081s, and turnaround documents to be used as a remittance advice. Allow for customized text in generated billing documents. (RM-4)

· Support bills and collections between Federal agencies through the use of electronic systems. Provide supporting data to agencies billed which can be used to verify the charges. (RM-5)

· Allow transactions related to manually prepared bills to be entered by authorized personnel. (RM-6)

· Record adjustments to bills and post to customer accounts. (RM-7)

· Date the bills with the system-generated date and/or with the date supplied by the user. (RM-8)

· Generate statements to customers showing account activity. (RM-9)

· Perform consolidated billing. (RM-46B)

***Receivable Management Process***

The Receivable Management process supports activities to maintain information (name, address, etc.) on entities owing the government; identify the type of customer from which collection is due; age receivables; make efforts to collect amounts due including related interest, penalties, and administrative charges; liquidate receivables; record adjustments to receivables including IPAC charge-backs; maintain a proper allowance for uncollectible amounts; and record write-offs.  

Mandatory Requirements

To support the Receivable Management process, the Core financial system **must** provide the capability to:

· Identify the type of customer from which collection is due, including: other federal agency, state/local government., commercial entity, individual, and employee. (RM-11)

· Maintain detailed information by customer account (such as customer name, address, account balance, account number, Employee Identification Number (EIN)/TIN, date due, reimbursable order number, government agency) to provide audit trails and to support billing, reporting and research activities. (RM-11B)

· Support the maintenance of additional customer data such as multiple addresses, contact names, telephone numbers, and comment fields. (RM-11C)

· Add, modify, and delete non-financial account data. (RM-14)

· Maintain accounts for reimbursable orders and identify government and non-government accounts that are designated as advance funding. (RM-12)

· Uniquely record, classify, and report on reimbursable funds including: billing limit, amount obligated, amount expended, amount billed, advanced amount (unearned revenue), and earnings and collections received, based on customer and customer agreement number.  The system should also support the ability to query and report on these items by any segment of the account code structure (e.g., fund or object class). (RM-33)

· Update each account when billing documents are generated and collections are received. (RM-13)

· Maintain data on individual receivables and referenced transactions supporting the receivable. (RM-15)

· Automatically calculate interest, administrative and penalty charges using user-defined criteria (e.g., customer, customer type) and automatically generate a separate line item to reflect charges on the bill. (RM-18)

· Automatically generate dunning (collection) letters for overdue receivables when accounts become delinquent, and incorporate, as appropriate, due process notices for referring delinquent accounts. (RM-22)

· Customize the dunning process parameters and dunning letter text. (RM-23)

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

· Identify and report receivables that meet predetermined criteria for bad debt provisions, write-off, or referral. (RM-19).

· Calculate and record the allowance for loss on accounts receivable. (RM-35)

· Provide information to allow either manual or automated reporting of delinquent accounts to commercial credit bureaus and referral to collection agencies or other appropriate governmental organizations. (RM-24)

· Maintain data for receivables referred to other Federal agencies and/or outside organizations for collections. (RM-20)

· Record the waiver or write-off of receivables (including interest, penalties, and administrative charges) with reason codes.  Maintain data to monitor closed accounts. (RM-21)

· Automatically produce IRS 1099’s in the amounts of debts forgiven which meet or exceed a user-defined dollar threshold (e.g., $600 or more). (RM-25)

· Perform on-line queries of account activity (billing, collection, and adjustment) by customer and receivable. (RM-16)

· Perform on-line queries of miscellaneous cash receipts by customer and accounting period. (RM-16B)

***Collection Process***

The Collections process supports activities to record the receipt of funds either by currency (e.g., cash, electronic funds transfer) or check, and the deposit of such funds in accordance with Treasury and agency regulations.

Mandatory Requirements

To support the Collections process, the Core financial system **must** provide the capability to:

· Automatically record the application of complete and partial payments made by the debtor on a delinquent debt to penalties, admin fees, interest, and then to principal, unless otherwise stated in program statute. (RM-37)

· Record revenues, expenditure reductions, or other appropriate offsets associated with collections for which no receivable was previously established. (RM-38)

· Post collections and reference reimbursable agreements where no billing document has been established. (New)

· Process cash or credit card collections. Match collections to the appropriate receivables and update related bills and customer accounts. (RM-40 and RM-27)

· Record information associated with a collection at the time of application, including the deposit ticket number and date, and ALC code. (RM-27B)

· Support the receipt of collection files from lock box banks and EFT for application to open receivables. (RM-42)

· Support the ability to utilize other electronic payment and collection systems such as IPAC. (RM-46)

· Record collections received against outstanding advances. (New)

· Apply collections to more than one receivable. (RM-28)

· Identify and report those receivables that have been reduced by some means other than cash collections, such as waivers or write-offs. (RM-30)

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

· Automatically reconcile, on a periodic basis (e.g. monthly), recorded deposits and debit vouchers with confirmation information provided by the Disbursing Center (Treasury) or the banking system. (RM-39)

Value-added Requirements

To support the Collections process, the Core financial system **should** provide the capability to:

· Interface with CASHLINK, in order to reconcile Treasury recorded collections to the collections recorded in the core financial system and generate exception reports.  CASHLINK is a Treasury System used to manage and monitor the collection of government revenues and report the balances to Federal Agencies.

***Offset Process***

This requirement will ensure that TINs of Federal payment recipients are available to facilitate debt collection by offset of Federal payments under the DCIA, and for vendor income reporting to the Internal Revenue Service (IRS) as mandated.

Mandatory Requirements

To support the Offset process, the Core financial system **must** provide the capability to:

· Capture TIN data for the debtor in order to report overdue receivables for potential offset. (RM-43)

· Generate the automated files required by Government offset programs.  Support the receipt of collection files from offset programs for application to open receivables. (RM-44)

· Record and report on the date and nature of a change in the status of an accounts receivable, including the following: 

· Held, 

· Reinstated, 

· Judgment received, 

· Appealed, 

· Waived/unwaived, 

· Referred for government. offset, 

· Referred to collection agency, 

· Referred to Department of Justice (DOJ), 

· Offset,

· Suspended, 

· Compromised, 

· Written-off.  (RM-44B)

**Cost Management Function**

The Cost Management function of the Core Financial System attempts to measure the full****cost of Federal programs, and their various elements, activities, and outputs.  Cost Management is essential for providing accurate program measurement information, performance measures, and financial statements with verifiable reporting of the cost of activities.  SFFAS No. 4,*Managerial Cost Accounting Concepts and Standards for the Federal Government,* promulgated by FASAB, prescribes the managerial cost accounting concepts and standards for the Federal government. The managers and executives who have the need for cost information should drive Cost Management in agencies. SFFAS 4 standards are:

*..based on sound cost accounting concepts and are broad enough to allow maximum flexibility for agency managers to develop costing methods that are best suited to their operational environments.”*

The term “cost” refers to monetary value of resources used or sacrificed or liabilities incurred to achieve an objective, such as to acquire or produce a good or to perform an activity or service. 

The level of sophistication of the Cost Management function needed by an agency is dependent on the requirements of the agency, and the operational nature of the programs involved (appropriation only, appropriation with reimbursable authority, revolving fund).  For example, in an agency’s primary mission is to produce a product or service for sale, the costing function typically will be accomplished in the Managerial Cost Accounting System that is integrated with the Core Financial System. Programs with less crucial cost information needs might perform cost management functions by analytical or sampling methods. However, in any Core system, certain basic functions must be present. For example, SFFAS 4 requires that cost information developed for different purposes should be drawn from common data sources, and that cost reports should be reconcilable to each other. The Cost Management function****consists of the following processes:

· Cost Setup and Accumulation

· Cost Recognition

· Cost Distribution 

· Working Capital and Revolving Fund

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.  Finally, cost information is prepared and distributed to managers. A “cost object” is any activity, output or item whose cost is to be measured, such as, organizational units, programs, projects, targeted outputs, specific contracts, specific customers, work orders, etc.

***Cost Setup and Accumulation Process***

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

Mandatory Requirements

To support the Cost Setup and Accumulation process, the Core financial system **must** provide the capability to:

· Use the agency’s accounting classification structure to identify and establish unique cost objects (for the purpose of cost and revenue capture, accumulation and reporting). Cost objects might include: organizational units, programs, projects, targeted outputs, specific contracts, specific customers, work orders, etc. (CM-3)

· Track current cost information against prior month and prior-year-to date cost data for selected cost objects, and track progress against pre-determined plans. (CM-7C)

· Identify all costs incurred by the agency in support of activities of revolving funds, trust funds, or commercial functions, including the applicable portions of the related salaries and expense accounts identified with those activities. (CM-6)

· Accumulate non-financial data relating to cost objects such as output units to allow the calculation of both total and unit costs. (CM-4B)

· Transfer (and trace) cost data directly to and from other cost systems/applications that produce allocation information. (CM-7B) 

· Calculate prices, fees, and user charges for reimbursable agreements and other purposes using full cost, consistent with the guidance of OMB Circular A-25 (User Charges). (CM-5)

***Cost Recognition Process***

Recognition of the effects of transactions in financial systems is fundamental to the accounting process. Recognition determines when the results of an event are to be included in financial statements and ensures that the effects of similar events and transactions are accounted for consistently within the Federal government.

Mandatory Requirements

To support the Cost Recognition process, the Core financial system **must** provide the capability to:

· Use the accrual basis of accounting when recognizing costs and revenue. Recognize costs in the period of time when the events occurred regardless of when ordered, received or paid for. Recognize revenue when earned. (CM-1)

· Associate with the appropriate cost objects, the reductions of balances such as inventories, prepaid expenses and advance payments as the balances are used or liquidated. (CM-2)

· Identify and record costs incurred by each cost object, including input on costs from feeder systems, such as inventory, travel, property management (depreciation), or payroll. (CM-9)

· Assign indirect costs on a cause-and-effect basis, or allocate costs through any reasonable and consistent basis such as a percentage of total cost incurred, direct labor hours used, square footage, or metered usage. (CM-10)

· Perform multi-layer overhead distributions that are user-defined (at least 3 levels of distribution) using multiple rates, fixed amount and other appropriate allocation methods. (CM-11)

***Cost Distribution Process***

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

Mandatory Requirements

To support the Cost Distribution process, the Core financial system **must** provide the capability to:

· Accumulate and distribute information on costs and revenue associated with cost objects. (CM-8B)

· Use historical information to conduct variance and time-series analyses, and justify rate adjustments based on actual costs. (CM-12) 

· Distribute costs to other cost objects regardless of how they were originally assigned. (CM-13)

· Provide an audit trail that traces a transaction from its origin to the final cost object(s). (CM-14)

***Working Capital and Revolving Fund Process***

Agencies may elect to use revolving funds, which include working capital funds and franchise funds, for their organizations.  These funds require separate legislation and have specific charters that focus on specific purposes.  Such charters have the potential to make program management much more flexible by lifting apportionment controls while adding operational safeguards.  If an agency uses revolving funds, the core system must be able to track service level agreements, verify funds availability, bill customers, and measure costs.

Mandatory Requirements

To support the revolving fund function, the core financial system **must** provide the capability to:

· Use cost management in revolving funds, including working capital programs. (CM-15)

· Create and track the funding associated with cost objects (e.g. contracts, work-orders, projects, reimbursable agreements) and provide funding status on FY-to-date and project inception-to-date bases. (CM-16)

· Support the aggregation of project funding status to a higher lever, such as from work order level to customer level. (new CM-17)

· Verify funds availability for orders placed against a specific contract, work-order or agreement for a particular customer of the revolving fund operation. (CM-18)

· Support funding of revolving fund contracts, work-orders, and projects through the use of advances, prepayments or reimbursements. (CM-19)

· Reconcile information in revolving fund customer and contract/work-order/project/reimbursable agreement status reports with bills and statements generated for customers by the receivables processes. (CM-23)

Reporting Function

The Core financial system must be able to provide timely and useful financial information to support:  (1) management’s fiduciary role; (2) budget formulation and execution functions; (3)  fiscal management of program delivery and program decision making; and (4) internal and external reporting requirements, including, as necessary, the requirements for financial statements prepared in accordance with the form and content prescribed by OMB, reporting requirements prescribed by Treasury, and legal, regulatory, and other special management requirements of the agency.

Information maintained by the Core financial system must be provided in a variety of formats to users according to their needs.  Methods of providing information include on-line inquiries, extract data files, and hard-copy reports.  These requirements could be satisfied by (1) application software that is part of the Core financial system, (2) generalized reporting/inquiry software that works with a variety of applications, or (3) a combination of both.

For financial information to be timely and useful, the Core financial system must provide for ready access to the information it contains.  Information must be easily accessible and understandable to personnel with varying levels of technical knowledge of systems and financial data.  Personnel with relatively limited knowledge of the system or of financial accounting concepts and principles should be able to access and retrieve data with minimal training on the system. The system should be capable of storing recurring data search requirements for future use.

***Financial Reporting Process***

The Core financial system must provide complete, reliable, consistent, timely and useful financial management information on operations to enable central management agencies, individual operating agencies, divisions, bureaus and other subunits to carry out their fiduciary responsibilities; deter fraud, waste, and abuse of resources; and facilitate efficient and effective delivery of programs by relating financial consequences to program performance.  The Core financial system must be designed to support agency budget, accounting, and financial management reporting processes by providing consistent information for budget formulation, budget execution, programmatic and financial management, performance measurement and financial statement preparation.

Mandatory Requirements

To support the Financial Reporting process, the Core financial system **must** provide the capability to:

· Produce internal or external reports or data transmissions from data that can be traced directly to SGL accounts and attributes. (R-11) 

· Produce, at a minimum, the following standard internal reports: 

· Summary and detailed trial balances

· Summary and detailed trial balances with attributes

· Transaction register with attributes.  (SGL-9)

· Produce an on-line current status of funds report down to the lowest level of the accounting classification structure, including such data as:

· annual budget (including revisions):

· outstanding or total appropriations

· apportionments

· allotments, and

· allowances;

· open commitments;

· open obligations;

· net payments/liquidated obligations; and

· balance available. (R-20)

· Provide data in the hard copy and electronic formats required by central agencies, including the SF-133, SF-224, SF-1219, SF-1220, FMS-2108, FACTS I and FACTS II. (R-14)

· To ensure the accuracy of data transmitted for FACTS I and FACTS II reporting, perform the validation edits specified by Treasury.  (CF-43B)

· Report financial activity by any element within the accounting classification structure (e.g., individual or hierarchical organization code, project code). (R-15)

· Provide information for the managerial cost accounting decision-making process, the management of the agency, and external reporting. For each cost object, identify and accumulate data to support:

· Schedules and operating statements for audit, and for financial statement preparation (including the Statement of Net Cost)

· Cost and revenue reports to be utilized in the analysis of programmatic activities

· Program and unit cost information needed to support program, financial and financial management performance measures as required by GPRA

· Comparison with other program data to determine compliance with planned or budgeted activities. (CM-7)

· Generate accounting statements by revolving fund customer and/or contract/work-order/project at month-end to include financial statements, revenue and funding status reports, cost reports and other reports with data sufficient to justify fees charged. (CM-22)

· Prepare and distribute agency-specific formatted reports. (R-17)

Value-added Requirements

To support the Financial Reporting process, the Core financial system **should** provide the capability to:

· Automate the preparation of consolidated financial statements as required by the current OMB Bulletin on Form and Content of Agency Financial Statements. (R-13)

· Report on aged unliquidated requisitions by organization and line item. (R-27B)

· Report on aged outstanding obligating documents by entry date and expected receipt date. (R-27C)

· Report on aged receiving reports without an acceptance. (R-27D)

· Report on aged, unmatched vendor invoices. (R-27E)

· Track and report on spending agency-wide by state and congressional district. (R-27F)

## Technical Requirements

Technical requirements have been established to help assure that a Core financial system (1) is capable of meeting a wide variety of workload processing demands, (2) provides transaction processing integrity and general operating reliability, (3) is easy to install, configure and operate and (4) does not conflict with other administrative/program systems or other agency established IT standards. 

Core financial systems subject to JFMIP qualification must meet the mandatory technical requirements specified in this section. Additionally, they should strive to include the functionality listed as value-added requirements. The requirements listed in the following subcategories are mandatory:

· General Design/Architecture

· Interoperability

· Security

· Operations and Computing Performance 

· Year 2000 Compliance

The following subcategories include requirements that are value-added:

· Infrastructure

· User Interfaces

· Workflow/Messaging

· Document Management 

· Internet Access

· Data Import/Reconciliation

The following subcategory is unique in that it is comprised of both mandatory and value-added requirements:

· Ad Hoc Query

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

**General Design/Architecture**

This category includes technical requirements relating to an application’s design, internal data management, and general ease of use. 

Mandatory Requirements

To meet JFMIP application architectural requirements, the core system **must**: 

· Be modular in design and upgradeable to accommodate regular changes in laws, regulations, best practices and new technology. (TA-1)

· Base application configuration management on commercially available product versions and standard releases. (TA-2)

· Incorporate a standard relational database product into the application design. Financial data maintained in this database must be accessible through an SQL-compliant API. (TA-3)

· The application design must include internal transaction processing controls, including the capability in the event of a system failure to automatically:

· back out incompletely processed (in-flight) transactions, 

· restore the system to its last consistent state before the crash (e.g., database checkpoint), and 

· re-apply all incomplete transactions previously posted by the user community. (TA-4)

· Ensure internal database consistency during update operations, including distributed databases, if applicable. (TA-5)

· Control access and updates to the same record by concurrent users. (TA-6)

· Support cascading record updates and deletions. (TA-7)

· Be designed to simultaneously process on-line transactions and transactions submitted via system interface. (TA-8)

· Have fully documented restart capabilities for the application on-line and batch processing components.  Batch jobs must be segmented to facilitate their recovery in the event of a system failure. (TA-9)

· Include vendor provided services for complete installation, operating and system maintenance documentation covering:

· Product installation and configuration steps,

· Application access procedures,

· User screen layout and content,

· Transaction entry procedures,

· Batch job set-up, processing and recovery/re-start procedures,

· Error codes with full descriptions and recovery steps,

· Standard report layout and content,

· Internal processing controls, 

· Application security,

· Operating specifications and system flowcharts,

· Database entity relationships,

· table formats and data element descriptions, and

· Program module descriptions. (TA-10)

· Include revised documentation provided by the vendor concurrent with the distribution of new software releases. (TA-11)

· Employ common error-handling routines across functional modules and present error messages that allow the user or system operator to respond to reported problems. Common error message text must be customizable by the agency. (TA-12)

· Provide an application user interface that complies with the software application standards required by Section 508 of the Rehabilitation Act, as detailed in 36 CFR 1194, Subpart B. (TA-13)

· Be capable of generating output using computer screen displays; to data file for FACTS I, FACTS II, and Treasury payment schedules; and hardcopy reports. Where not otherwise specified by a functional requirement, requested information must be viewable using the application’s on-line user interface. Where the term report is used, the application must be capable of generating a formatted, hardcopy report containing the specified information. Other special output requirements are specified by the technical requirements addressing Interoperability and Ad Hoc Query. (TA-14)

## Interoperability

Financial transactions can be originated using external, feeder applications. Typically, these feeders are considered legacy systems and are based on older computing technologies. 

Mandatory Requirements

To ensure that data can move effectively between the core financial system and other financial applications operated by the agency, the core system **must**:

· Include an application program interface (API) to accept accounting activity generated by external applications (e.g., accounting feeders, EDI gateways, program area mixed systems, travel, payroll). This interface must support the following functional transaction groups:

Core Accounting

Budget

Payables

Receivables

Fixed Asset

Accounting Classification Structure Tables

Vendor Table Maintenance (TD-1)

· Process API submitted transactions using the same program logic, table entries and business rules as are used by the application in editing transactions submitted on-line (e.g., via user interface). The core system must maintain the erroneous transactions until either corrected and posted or deleted. (TD-2)

· Provide internal controls with the API (e.g., control totals, record counts) to ensure the integrity of received and processed transactions. (TD-3)

· For the API, generate transaction editing error records in a standard format defined by the vendor for return to the originating feeder application (i.e., provide two-way interface support). (TD-4)

· For the API, include the ability to automatically re-process suspended transactions. (TD-5)

## Security

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

Mandatory Requirements

To meet JFMIP Security requirements, the core system **must**: 

· Have integrated security features that are configurable by the system administrator to control access to the application, functional modules, transactions, and data. (TS-1)

· Ensure that the agency’s access policies are consistently enforced against all attempts made by users or other integrated system resources including software used to submit ad-hoc data query requests or to generate standard reports. (TS-2)

· Require the use of unique user identifications and passwords for authentication purposes. Passwords must be non-printing and non-displaying. The application must allow the enforcement of password standards, (e.g., minimum length and use of alpha, numeric and special characters.) The application must also allow for the establishment of a specified period for password expiration and accommodate prohibiting the user from reusing at least the most recent 3 passwords. (TS-3)

· Enable the system administrator to define functional access rights (e.g., to modules, transactions, approval authorities) and data access rights (e.g., record create, read, update and delete) by assigned user ID, functional role (e.g., payable technician) and owner organization. (TS-4)

· Permit the system administrator to assign multiple levels of approval to a single, but prevent that user from applying more than one level of approval to a given document in order to conform to the principle of separation of duties. (TS-5)

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

· Maintain an audit logging capability to record access activity including:

· all log-in/log-out attempts by user and workstation, 

· user submitted transactions, 

· initiated processes, 

· system override events; and 

direct additions, changes or deletions to application maintained data. (TS-7)

· Provide the ability to query the audit log by type of access, event date time stamp range, user identification, or terminal id. (TS-8)

## Operations and Computing Performance

Technical computing performance requirements define batch transaction loads; concurrent users and agency determined processing time constraints. Specific workload requirements will come from an agency. 

Mandatory Requirements

To meet JFMIP Operations and Computing Performance requirements, the core system **must**:   

· Include vendor provided computing performance metrics, for platforms and systems environments that the application is certified to run. Performance metrics provided by the vendor must describe:

· transaction processing throughput capacity,

· expected workstation client response time by transaction type,

· data storage capacity, and limitations in concurrent user connectivity. (TX-1)

· Provide the ability to complete routine batch processing (e.g., backups, nightly interface processing, core GL posting, table updates, standard reporting, and systems assurance) within an agency’s specified batch processing window. (TX-2)

· Be capable of storing, updating and retrieving the agencies financial data (e.g. vendors records, transactions, documents, lines and subsidiary ledger records) with no degradation to on-line or batch processing performance. (TX-3)

· Support concurrent access by the agency's user community with no negative impact on standard response time. (TX-4)

· Be designed to include a flexible scheduling capability to enable the operator to initiate, monitor and stop scheduled processing (e.g., on-line availability, batch jobs and system maintenance). (TX-5)

· Provide online status messages indicating when requested processing starts, completes and system errors. (TX-6)

· Include automated system assurance routines (e.g., data integrity verification reports) that can be regularly run and used to detect systemic posting problems*.* (TX-7)

· Allow reports to be produced in the background while other system processing takes place. (TX-8)

· Provide the capability to process batched transactions during online hours and accept online transactions from interfacing systems with no on-line performance degradation. (TX-9)

· Provide the system administrator the ability to determine whether records are to be archived or purged. The system must include the capability to establish and maintain user-defined archival criteria, such as date, accounting period, closed items, vendors inactive for a specific time period. The system must allow selective action on those documents that meet the criteria. (TX-10)

· Retain system records in accordance with Federal regulations established by the National Archives and Records Administration (NARA), GAO, and others. (TX-11)

· Provide the ability to selectively retrieve archived records. (TX-12)

· Maintain and report on productivity statistics about application usage. (TX-13)

· Provide audit trails to identify changes made to system parameters and tables that would affect the processing or reprocessing of any financial transactions. (TX-14)

## Year 2000 Compliance

Year 2000 compliance requirements ensure that the core system is not impacted by date based calculations. 

Mandatory Requirements

To be year 2000 compliant the core financial system **must:**

· Be warranted for fault-free performance in the processing of date and date-related data (including, but not limited to calculating, comparing, and sequencing) by all hardware and software products delivered under this contract, individually and in combination, upon installation. (TY-1)

· Include fault-free performance during the manipulation of any data with dates prior to, through, and beyond January 1, 2000 and shall be transparent to the user. (TY-2)

· Successfully transition to the year 2000 with the correct system date, without human intervention, including leap year calculations. (TY-3)

· Provide correct results when moving forward and backward in time across the year 2000. (TY-4)

## Infrastructure

This requirement category identifies computing platforms and operating system environments where a JFMIP qualified core system could be installed by a Federal agency.  Individual packages do not need support every specified platform and operating environment. 

Value-added Requirements

To meet JFMIP infrastructure related requirements, the core financial system **should:**

· Operate in a centralized mainframe environment (e.g., MVS, OS/390) or in a distributed computing environment running under UNIX or NT (Windows Server 2000). (TB-1)

· Operate on TCP/IP network to support application, database and workstation connectivity. (TB-2)

· Support application client operation on a 32-bit, Microsoft Windows compatible operating system. (TB-3)

· Support EDI translation compliant with ANSI X-12 standards and Federal implementation conventions to enable electronic data exchanges with designated trading partners such as a bank credit card service provider, major supplier or customer. (TB-4)

· Support automated touch-tone telephone access for standardized, commonly requested, inquiries (such as payment status). (TB-5)

· Support automated fax-back access for standardized, commonly requested, documents (such as account statements). (TB-6)

· Provide the capability to accept bar-coded documents. (TB-7)

## User Interfaces

Technical user interface requirements specify how agency users and operators interact with the core financial system.  To enable users to effectively configure the package, enter transactions, query processing results, or start/stop internal processes the system interfaces should meet the following requirements.

Value-added Requirements

To meet JFMIP infrastructure related requirements, the core financial system **should:**

· The application should provide a consistent Windows-based, graphical user interface (GUI) across all modules and integrated subsystems. Interface consistency includes the use of common command syntax, dialog window styles, data entry structures and information presentation (both hard-copy and on-line). Desired GUI characteristics include mouse activated:

· Icons, 

· Buttons, 

· Scroll bars, 

· Drop-down lists, 

· Check boxes, 

· Menu bars, 

· Text boxes, 

· Tool tips, 

· Resizable windows, 

· Cut, copy, and paste functions. (TC-1)

· The application interface should incorporate features designed to reduce the amount of direct keying required to initiate processing. Data entry efficiency features include the use of default values, look-up tables and automatic data recall. Other desirable features include:

· The use of single function windows (e.g., one input screen per transaction),

· The ability to pass common data from screen to screen,

· Highlighting of required fields,

· The use auto tabs,

· The use of function keys (e.g., retrieve previous data, invoke help facility, suspend transaction, clear screen, etc.),

· Disabling of non-supported function keys,

· A menu mode and an expert mode of screen navigation,

· The ability to retrieve suspended transactions by user, document, vendor, etc.,

· Transaction entry undo/redo,

· Context-sensitive on-line help, and

· The ability to select records from a list by scrolling or by typing in only part of an entry. (TC-2)

· The application interface should support desktop integration with other common workstation applications. (TC-3)

## Workflow/Messaging

Workflow/messaging includes technical requirements that collectively define how a core financial system automatically manages document processing and notifies agency staff of pending work (e.g., review/approval of pending accounting documents). 

Value-added Requirements

To meet JFMIP workflow and messaging related requirements, the core financial system **should:**

· The application should provide an integrated workflow management capability, including generation and routing of internal forms, reports, and other financial documents for on-line approval or subsequent processing based on user-defined and modifiable business rules via a graphical definition facility. (TE-1)

· The application should provide a graphical facility to enable authorized users to define workflow processes and business rules, including approval levels and to modify workflow (e.g. assign a proxy approving authority). (TE-2)

· The application should provide the capability to establish multiple levels of document approvals based on user-defined criteria, including dollar amounts; types of items purchased, and document types. (TE-3)

· The application should provide an internal calendar or user-defined routing tables to generate rule-based or exception reports to support the generation of work flow messages (i.e., notification of Accounts Payable Office for invoices warehoused over 30 days with no matching receiving report). (TE-4)

· The application should provide the ability to track the approval event, including the time/date and approving party. (TE-5)

· The application should provide the capability to automatically generate electronic routing and status messages to individuals or groups. (TE-6)

· The application should provide an interface to the agency electronic mail system, or groupware application to distribute application generated documents and messages electronically (i.e., to intranet/Internet connected users). (TE-7)

· The application should provide on-line query capability and customizable queries to track the status of transactions through the workflow process. (TE-8)

· The application should provide capability to support Workflow Management Coalition (WFMC). (TE-9)

· The application should provide capability to support Messaging API-Workflow (MAPI-WF). (TE-10)

· The application should provide capability to support Vendor Independent Messaging (VIM). (TE-11)

## Document Management

Document management includes technical requirements that define how the Core system is to store and retrieve electronically formatted documents.  

Value-added Requirements

To meet JFMIP document management related requirements, the core financial system **should:**

· Provide the capability to support Document Management Alliance (DMA). (TF-1)

· Provide the capability to support Open Document Management Architecture (ODMA). (TF-2)

· Provide the capability to support Open Document Architecture/Open Document Interface Format (ODA/ODIF). (TF-3)

· Provide the capability to support Portable Document Format (PDF). (TF-4)

· Provide the capability to support Standard Generalized Markup Language (SGML). (TF-5)

· Provide the capability to support imaging of hard-copy document reference material (e.g., signed contracts, purchase orders and vendor invoices). (TF-6)

· Provide the capability to notify the user of the presence of an associated electronic file and allow an on-screen display. (TF-7)

## Internet Access

Technical requirements relating to internet access represent a specialized infrastructure subset. These requirements generally define user connectivity options.  

Value-added Requirements

To meet JFMIP all connectivity options document management related requirements, the core financial system **should:**

· Support secure web browser access to work queues, review status of documents, approve documents, and enter transactions such as commitments, obligations, disbursements, and receiving reports. (TN-1)

· Support secure web-browser access to its integrated ad hoc data query facility. (TN-2)

· Provide the capability to accept vendor invoices and other external originated transactions over the Internet using XML. (TN-3)

· Provide the capability to receive public payment collections via the Internet (e.g., Web-based collection of reimbursable activity using credit cards. (TN-4)

· Support the use of standard *Public Key Infrastructure* (PKI) technology to control access to sensitive data over the Internet. (TN-5)

## Data Import/Reconciliation

Federal agencies are required to reconcile financial data maintained in their core system with fund data maintained by U.S. Treasury. To facilitate this reconciliation process, Treasury makes their fund balance data available to electronic format. Agencies need a facility that can "import" this information and automatically report discrepancies. This technical requirements sub-section defines requirements for specific reconciliation scenarios suggested by Federal agencies that need to be addressed.

Value-added Requirements

To meet JFMIP Data Import/Reconciliation related requirements, the core financial system **should:**

· Provide the ability to import Treasury Master Appropriation File (MAF) data, including Treasury fund balances at the TAFS and Record Type 7 level for automatic comparison against FACTS data generated by the Agency. (TM-1)

· Perform automatic monthly cash reconciliation with Treasury (e.g., 6653) and provide detail data on of balance items. (TM-2)

## Ad Hoc Query

Ad hoc query requirements define how a Core financial system supports retrieval of financial data for analytical purposes. 

Mandatory Requirements

To effectively support ad hoc data access, the core financial system **must:**

· Provide a data query facility that will enable ad hoc access to financial information and analytical/reporting tools. Utilization of this facility must not impact normal on-line and batch processing system performance. (TG-1)

· Include a user interface that allows users to create/edit parameter-based query scripts and to submit them for immediate execution and/or store them in a common library for future use. (TG-2)

· Allow users to run selected queries automatically in batch mode and to stage the “report” output for later access by agency users. (TG-4)

· Include on-line tools to help optimize query scripts and identify potential resource-intensive submissions ands provide run-time controls to limit "run-away" queries and large data download requests. (TG-5)

· Support simultaneous access to multiple data sources using standard query language (SQL) or a functionally similar query mechanism. (TG-6)

· Support output display on the desktop. The facility must also support dynamic report reformatting, regrouping and drill-down to detail records from summary report lines. (TG-7)

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

· Provide the ability to preview a report, form or other query result before printing. (TG-9)

· Support access to current and historical financial information (i.e., prior-year data). (TG-10)

· Provide the ability to perform document cross-referencing in which a user can query on any document and receive information on associated documents in the processing "chain" (e.g., querying on a purchase order would provide any amendments to purchase orders, receiving reports, requisitions, and invoices; querying on a receivable would provide any associated cash receipts). (TG-11)

# Value-Added Requirements

To provide additional ad hoc data access functionality, the core financial system **should:**

· Include a graphical display of data sources and allow users to *point and click* on selectable table, data, and link objects for inclusion in a custom query.  (TG-12)

· Include an active data dictionary to provide users with object definitions. (TG-13)

· Allow users to transmit copies of report/query results electronically via e-mail to multiple pre-identified individuals. (TG-14)

**Appendix A: References**

Applicable references can be found on the JFMIP Knowledgebase website at http://www.JFMIP.gov.

Appendix B: Glossary

This section prescribes certain terms that have been used throughout this document.  The source of each definition is identified in parentheses following the definition; the terms are all found in one of the following sources:

· OMB Circular A-34, “Instructions on Budget Execution”; referred to as A-34.

· OMB Circular A-11 “Preparation and Submission of Budget Estimates”; referred to as A-11.

· *Treasury Financial Manual*; referred to as TFM.

· U.S. Government Standard General Ledger; referred to as SGL.

· Commonly used terms within the Federal sector; referred to as Common Term.

***Accomplished payments***

A term used by Treasury and agency personnel to refer to payments requested by an entity and made by Treasury or a non-Treasury disbursing office on the behalf of that entity. (Common Term)

***Activity*****

Agency-defined financial summary accumulator.

***Agency***

Any department, agency, commission, authority, administration, board, or other independent establishment in the executive branch of the government, including any corporation wholly or partly owned by the United States that is an independent instrumentality of the United States, not including the municipal government of the District of Columbia. (A-34, Part 11, Section 21.1, p. 11-2)

***Agency location code (ALC)***

Code assigned by Treasury to each reporting unit requiring the preparation of an SF-224, Statement of Transactions.  The first two digits of the symbol identify the department or agency, the third and fourth digits identify the particular bureau within that department, and the remaining four digits identify the lowest level of reporting required for the particular agency accounting station within that bureau (e.g., Letter of Credit, Trust Funds, all other, etc.). The ALC must be shown on all correspondence, forms, and other documentation forwarded to financial institutions, FMS, other Federal agencies, and to Treasury Regional Financial Centers, and particularly on all SF-215s: Deposit Tickets, and/or related SF-5515s: Debit Vouchers. (I TFM 2-3320.10)

***Apportionment***

A distribution made by OMB of amounts available for obligation in an appropriation or fund account into amounts available for specified time periods, activities, projects, objects, or combinations thereof.  The amounts so apportioned limit the obligations that may be incurred. (A-34, Part 11, Section 21.1, p. 11-1)

· Category A Apportionments are apportionments that are made on a quarterly basis.

· Category B Apportionments are apportionments made on a basis other than a quarterly basis. 

· Category C Not subject to apportionment..

· Category D Apportionments made on the basis of reimbursements for goods or services provided.

***Appropriations***

One of the basic forms of budget authority.  Statutory authority that allows Federal agencies to incur obligations and to make payments out of the Treasury for specified purposes.  An appropriation act is the most common means of providing budget authority, but in some cases the authorizing legislation itself provides the budget authority. (A-34, Part 11, Section 21.1 (Budget authority), p. 11-3)

***Authority to borrow***

One of the basic forms of budget authority.  Statutory authority that permits a Federal agency to incur obligations and make payments for specified purposes out of borrowed monies. (A-34, Part 11, Section 21.1 (Budget authority), p. 11-3)

***Budget authority***

Authority provided by law, including joint resolutions making continuing appropriations (also known as continuing resolutions), and becoming available during the year to incur obligations.  The basic forms of budget authority are appropriations, authority to borrow, and contract authority. (A-34, Part 11, Section 21.1, p. 11-3)

***Commitment***

The amount of allotment or lower level authority committed in anticipation of an obligation. (SGL, definition of account 4700)

***Contract authority***

One of the basic forms of budget authority.  Statutory authority under which contracts or other obligations may be entered into prior to an appropriation for the payment of such obligations.  The later enacted appropriation provides cash to liquidate such obligations. (A-34, Part 11, Section 21.1 (Budget authority), p. 11-3)

***Cost Center***

An identifiable department or area within a recipient’s organization that has been assigned an account number in the recipients accounting system for the purpose of accounting costs.

***Disbursements***

Payments made using cash, checks, or electronic transfers.  Disbursements include advances to others as well a payments for goods and services received and other types of payments made. (Common Term)

***Expended authority***

Paid and unpaid expenditures for (a) services performed by employees, contractors, vendors, carriers, grantees, lessors, or other government funds; (b) goods and tangible property received; and (c) amounts becoming owed under programs for which no current service or performance is required (i.e., annuities, insurance claims, other benefit payments). (SGL, definition of accounts 4901, expended authority - unpaid, and  4902, expended authority - paid)

***Expense***

The outflows of assets or incurrence of liabilities during a period resulting from rendering services, delivering or producing goods, or carrying out other normal operating activities. (SGL, definition of 6000 series)

***Federal Agencies Centralized Trial-Balance System (FACTS)***

System used by agencies to electronically transmit a pre-closing adjusted trial balance(s) (ATB) at the Treasury appropriation/fund group level using U.S. Government Standard General Ledger account and other specified elements. FACTS I supports consolidated financial statement reporting. FACTS II supports centralized budget execution reporting.

***Fund account***

(See Appropriation or fund account)

***Future-dated transactions***

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

***GOALS***

Government Online Accounting Link System.  The electronic network which ties agencies to Treasury and each other for the exchange of information.  Over the network, agencies can transfer funds to each other and receive notification that Treasury has accomplished disbursements.  Also, agencies and Treasury can submit and receive reports once exchanged in hard copy format by mail.  The GOALS network can be used with a wide variety of terminals and modems. (Common Term)

***Imprest fund***

A 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. (I TFM 4-3020)

***Information Stores***

Logical grouping or categories of data.

***Limitation***

A funding restriction, imposed by OMB, a department, or an agency, that places a ceiling for obligational/spending authority.  The limitation may exist at any level within a funding structure or may be imposed using an independent structure. (Common Term)

***Object classification***

A method of classifying obligations and expenditures according to the nature of services or articles procured, (e.g., personal services, supplies and materials, and equipment.)  Obligations are classified by the initial purpose for which they are incurred, rather than for the end product or service provided.  OMB Circular A-11 provides current object classifications for reporting budget estimates to OMB.  Many agencies have defined lower levels of object classification for internal use. (A-11, Sec 35.1)

***Obligation***

Obligations are amounts of orders placed, contracts awarded, services received, and similar transactions for bona fide needs existing during a given period that will require payments during the same or a future period and that comply with applicable laws and regulations.  Such amounts will include outlays for which obligations had not been previously recorded and will reflect adjustments for differences between obligations previously recorded and actual outlays to liquidate those obligations. (A-34, Sec. 21.1, p.11-7)

***Organization structure***

The offices, divisions, branches, etc. established within an entity based on responsibility assignments, whether functional or program related. (Common Term)

***Outlay***

The measure of government spending for budget purposes.  Payments to liquidate obligations (other than the repayment of debt).  Except where outlay figures are labeled as gross, they are stated net of any related refunds and offsetting collections.  Outlays generally are equal to cash disbursements, but they are also recorded for cash-equivalent transactions, such as the subsidy cost of direct loans and loan guarantees, and interest accrued on public issues of the public debt. (A-11, Section 14.1, p. 35) (Note that, although not technically correct, the terms ‘expenditures’ and “net disbursements’ are sometimes used interchangeably with ‘outlays’.)

***Pro forma* transactions**

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

***Program***

Generally defined as an organized set of activities directed toward a common purpose, or goal, undertaken or proposed by an agency in order to carry out its responsibilities.  In practice, however, the term program has many uses and thus does not have well-defined, standard meaning in the legislative process.  Program is used to describe an agency’s mission, programs, functions, activities, services, projects, and processes.

***Program structure***

The budget programs, activities, etc. on which budgetary decisions are made, whether legally binding, as in appropriation limitations, or in the nature of policy guidance, as in Presidential passbacks, Congressional markup tables, or internal agency decisions. (SGL p. IV-1)

***Project***

A planned undertaking of something to be accomplished, produced, or having a finite beginning and finite end.  Examples are a construction project or a research and development project. (SGL p. IV-7)

***Reimbursable order***

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

***Requirements***

JFMIP systems requirements are either mandatory or value-added.  The definitions of these two categories are:

**Mandatory** - Mandatory requirements describe what the system must do and consist of the minimum functionality necessary to establish a system, or are based on Federal laws and regulations.  Mandatory requirements are those against which agency heads evaluate their systems to determine substantial compliance with systems requirements under the Federal Financial Management Improvement Act (FFMIA).  These requirements apply to existing systems in operation and new systems planned or under development.

**Value-added** - Value-added requirements describe features or characteristics and may consist of any combination of the following:  (1) using state of the art technology, (2) employing the preferred or best business practices, or (3) meeting the special management needs of an individual agency.  Value-added, optional, and other similar terminology may be used to describe this category of requirements. Agencies should consider value-added features when judging systems options.  The need for these value-added features in agency systems is left to the discretion of each agency head.

***Standard General Ledger at the transaction level***

Implementing the SGL at the transaction level requires that the core financial system general ledger management function is in full compliance with the SGL chart of accounts descriptions and posting rules; transactions from feeder systems are summarized and fed into the core financial system’s general ledger following SGL requirements through an interface (automated or manual); detail supporting the interface transactions can be traced back to the source transactions in the feeder systems; and the feeder systems process transactions consistent with SGL account descriptions and posting.

***System Integration***

The ability for the user to have one view into the system and can get to the information needed efficiently and effectively through electronic means.

***Tolerance levels***

The percentage or dollar variance of related transaction amount that can exceed a control amount, such as obligation to commitment; accrual to obligation; and obligation to payment.

***Treasury appropriation fund symbol***

A summary account established in the Treasury for each appropriation and/or fund showing transactions to such accounts.  Each such account provides the framework for establishing a set of balanced accounts on the books of the agency concerned.  As used in OMB Circular A-34, this phrase refers to general fund expenditure accounts, special fund expenditure accounts, public enterprise revolving funds, intra-governmental revolving funds, management funds, trust fund expenditure accounts, and trust revolving fund accounts. (A-34, Part 11, Section 21.1, p. 11-4 and 5)

***Unified systems***

Systems that are planned for and managed to work together using common data elements, operated in an integrated fashion, and linked together electronically in an efficient and effective manner to provide agency-wide financial system necessary to carry out the agency’s mission and support the agency’s financial management needs.

Appendix C: Summary of External Reporting Requirements 

**Title**

**Form**

**Purpose**

**Level**

**Basis**

**Frequency**

**Guidelines**

Program and Financing Schedule (actual data columns)

Prior-year data

Supporting information for agency budget submissions to OMB

Appropriation/ Fund Account

Cash

Annually

OMB Cir.A-11 SGL Crosswalk

Federal Agencies; Centralized Trial Balance System (FACTS I)

Electronic Reporting replacement of 

SF-220

SF-220-1

SF-221

SF-222

and SF-223

Report data for consolidation from FACTS into the U.S. Government Consolidated Financial Statement

Appropriation/ Fund Group

Accrual

Quarterly/ Annually

1 TFM 2-4000

Federal Agencies; Centralized Trial- Balance System (FACTS II)

Electronic Reporting replacement of SF-133 and TFS-2108

Report data for consolidation from FACTS II into the U.S. Government Consolidated Financial Statement

Appropriation/ Fund Group

Accrual

Quarterly/ Annually

TFM Transmittal Letter S2-01-01 

Report on Guaranteed Loans

SF-220-8

Provides information for monitoring status of guaranteed loans

Appropriation/ Fund Account but can vary

Accrual

Quarterly/

Annually

TFM Bulletin 92-04 Bulk Transfer User’s Guide

Report on Receivables Due from the Public

Replaces SF-220-9

Provides information on the status of public receivables and delinquencies

Appropriation/ Fund Account but can vary

Accrual

Quarterly/

Annually

Bulk Transfer Instructional Workbook (March 1994)

Statement of Transactions

SF-224

Reports disbursements, collections, and status of collections

Agency location code by Appropriation/ Fund Account

Cash

Monthly

1 TFM-3300 Bulk Transfer user’s Guide

Report of Accountability

SF-1219

Provides an analysis of disbursing officers’ activities in agencies which do not do their own disbursing

Agency location code and Disbursing Officer

Cash

Monthly

1 TFM 3100

Statement of Transactions

SF-1220

Reports disbursements and collections in agencies which do their own disbursing  (the counterpart to SF-224)

Agency Location code and Appropriation Fund Account

Cash

Monthly

1 TFM 3100

Information Returns

1099-MISC, 1099-G, etc.

Provide information to the Internal Revenue Service on payments made or debts forgiven

Taxpayer Identification number

Cash

Annually

IRS instructions for forms 1099, 1098, 5498, and W-2G

Balance Sheet

N/A

Disclose statement of assets, liabilities, and net position

Trust and revolving funds, accounts substantially commercial

Obligation/Accrual

Annually

OMB’s Bulletin on Form and Content

Statement of Net Cost

N/A

Reports gross costs less revenue earned

Trust and revolving funds, accounts substantially commercial

Accrual

Annually

OMB’s Bulletin on Form and Content

Statement of Changes in Net Position

N/A

Reports financing sources, gains and losses

Trust and revolving funds, accounts substantially commercial

Accrual

Annually

OMB’s Bulletin on Form and Content

Statement of Budgetary Resources

N/A

Available budgetary resources and status

Trust and revolving funds, accounts substantially commercial

Obligation/ Accrual

Annually

OMB’s Bulletin on Form and Content

Statement of Financing

N/A

Report on reconciliation between proprietary and budgetary accounts

Trust and revolving funds, accounts substantially commercial

Accrual

Annually

OMB’s Bulletin on Form and Content

Statement of Custodial Activity

N/A

Report of non-exchange revenue

Trust and revolving funds, accounts substantially commercial

Accrual

Annually

OMB’s Bulletin on Form and Content

**Appendix D: Contributors**

###### JFMIP Steering Committee

Jeffrey C. Steinhoff, Chair, *U.S. GAO*

Donald V. Hammond, *U.S. Department of the Treasury*

Karen Cleary Alderman, *Executive Director, JFMIP*

Joseph L. Kull, Office of Management and Budget

William B. Early, *General Services Administration*

Kathleen M. McGettigan, Office of Personnel Management

**Joint Financial Management Improvement**

**Program**

Karen Cleary Alderman, *Executive Director, JFMIP*

Stephen Balsam

Steven Fisher 

Dennis Mitchell

**Core Financial System Requirements Project Team**

*Corporation for National Service*

Wynn Cooper

*Department of Commerce*

Patricia Jackson

*Department of Defense*

Gerald Thomas

*Environmental Protection Agency*

Martin Poch

*Department of Energy*

Warren Huffer

Ike Smith

*General Accounting Office*

Chris Martin

Janett Smith

Sally Thompson

*General Services Administration*

William Topolewski

*Health and Human Services*

Norbert Juelich

Teresa Wright

Margie Yanchuk

*Housing and Urban Development*

Rhea Riso

*Department of Interior*

R. Schuyler Lesher,   Deputy Chief Financial , Chair, Financial Systems Committee, 

   Chief Financial Officers’ Council

*Department of Justice*

Robert Karas

*Department of Labor*

Patricia Clark

Lee Jones

*NASA*

Mela Jo Kubacki

*Office of Management and Budget*

Neil Lobron

Jerry Williams

*Office of Personnel Management*

Robert Loring

Maurice Duckett

*Railroad Retirement Board*

Kenneth Boehne

*Social Security Administration*

Tom Bianco

*Department of State*

Lauretta Pridgen

*Department of the Treasury*

Richard Aaronson

David Epstein

Carolyn Dockett-Butler

Betty Harvey-Tauber

Jeff Hoge

*Department of Veterans Affairs*

Jesse Symlar

*CFO Fellows Participant*

David Cauthon, Office of Personnel Management

Executive Leadership Program Participants

Dotty Willey, Federal Deposit Insurance Corporation

*Logistics Management Institute*

James Atherton

Kathy Crampton

Frank Duesing

Steven Mead

Catherine Nelson

Ronald Rhodes

Susan Smith

Duane Whitt

Joint Financial Management

Improvement Program

� EMBED CorelDRAW.Graphic.9  ���

1990 K Street NW

Suite 430

Washington, DC  20006

Principals 

David M. Walker

Comptroller General of the United States

Paul H. O’Neill

Secretary of the Treasury

Mitchell E. Daniels, Jr.

Director

U.S. Office of Management and Budget

Steven R. Cohen

Acting Director

U.S. Office of Personnel Management

Steering Committee

Jeffrey C. Steinhoff (Chair)

Managing Director

Financial Management and Assurance

U.S. General Accounting Office

Donald V. Hammond

Fiscal Assistant Secretary

Department of the Treasury

Joseph L. Kull

Deputy Controller

U.S. Office of Management and Budget

Kathleen M. McGettigan

Chief Financial Officer

U.S. Office of Personnel Management

William B. Early, Jr.

Chief Financial Officer

General Services Administration

Karen Cleary Alderman

Executive Director, JFMIP

� EMBED CorelDRAW.Graphic.9  ���

# _1041855510.unknown

# _1053775614.unknown