Federal

Financial 

Management

System

Requirements

Acquisition/

Financial

Systems

Interface

Requirements

JFMIP-SR-02-02

June 2002
What is JFMIP? 

The Joint Financial Management Improvement Program (JFMIP) is a joint undertaking of the 

U.S. Department of the Treasury, General Accounting Offie (GAO), Office of Management and 

Budget (OMB), and Office of Personnel Management (OPM), working in cooperation with one 

another, with other agencies, and with the private sector, to improve financial management in the 

Federal government. The program was given statutory authorization in the Budget and Accounting Procedures Act of 1950 (31 U.S.C. 65). Leadership and program guidance are provided by 

the four principals of JFMIP: Comptroller General of the United States, Secretary of the Treasury, Director of OMB, and Director of OPM. Each principal designates a representative to serve 

on the JFMIP Steering Committee, which is responsible for the general direction of the program. 

The Executive Director of JFMIP is a permanent member of the Steering Committee and is responsible for the day-to-day operations of JFMIP. Additionally, a representative from the Federal 

community serves on the Steering Committee for a two-year term. 

The program promotes strategies and sponsors projects to improve financial management across 

the Federal government, participates in the financial management activities of central policy organizations, and facilitates the sharing of information about good financial management practices. Information sharing is accomplished through conferences and other educational events, 

newsletters, meetings with interagency groups and agency personnel, and the Internet. 

For more information on JFMIP, call (202) 219-0526, or visit the JFMIP website at

http://www.jfmip.gov. 
Foreword 

Acquisition/Financial Systems Interface Requirements is one of a series of functional systems requirements documents published by JFMIP dealing with Federal financial management systems. The first of 

these requirements documents, Core Financial System Requirements, was originally published by JFMIP 

in January 1988, and has since been updated. JFMIP also published Framework for Federal Financial 

Management Systems in January 1995. That document provides a comprehensive description of the basic 

elements of a model for integrated financial management systems in the Federal government including, 

system integration, data stewardship, and internal controls. Other documents have subsequently been issued and additional documents are planned in the future. 

This document is prepared in support of the Federal Financial Management Improvement Act (FFMIA) of 

1996, and the Strategic Plans of the Procurement Executives Council (PEC) and Chief Financial Officer’s 

(CFO) Council. This Act and these strategic plans strongly reaffirm the need for the Federal government 

to provide financial systems that facilitate the effective management of government programs and services for the proper stewardship of public resources. Additionally, this document, in part, meets the goal 

of the President’s Management Council (PMC) and JFMIP to improve the efficiency and quality of financial management in the Federal government. Jointly sponsored and formally chartered by the PEC and 

JFMIP, it is a collaborative effort on the part of more than 20 agencies, led by the Senior Procurement 

Executive at the U.S. Department of Agriculture, staffed by finance and acquisition professionals 

throughout government, and supported by Logistics Management Institute (LMI). 

Acquisition/Financial Systems Interface Requirements addresses the shared information requirements between Federal financial and acquisition management systems. To this end, it identifies existing governmentwide statutory and regulatory requirements associated with the mutual functional interfaces between 

finance and acquisition (See Appendix A for a complete list of applicable references and authoritative 

sources). Agencies must use these functional requirements, in addition to agency-unique mission requirements, in planning their financial management and acquisition systems improvement projects. Acquisition/financial management system interface functionality does not necessarily reside in a single software application or functional system. In fact, the interface between acquisition and financial management systems information may reside in a number of applications or systems, whether automated or manual. 

We thank the agency officials and other participants from the acquisition, financial, oversight, and information technology communities who contributed to this document. It was particularly gratifying to see 

the finance and acquisition communities unite so effectively behind a common objective. We especially 

wish to acknowledge the PEC for chartering this project; the U.S. Department of Agriculture Senior Procurement Executive for leading the effort; and his co-leaders from the Office of Management and Budget, 

Department of Defense, Department of Justice, and Department of Housing and Urban Development (See 

Appendix D for a list of contributors). With continuing support such as theirs, we can confidently face the 

acquisition and financial management challenges of this century. 

 ___________________________________________ 

Karen Cleary Alderman 

Executive Director 

June 2002 
(LEFT BLANK INTENTIONALLY) 
Table of Contents 

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

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

Federal Acquisition System Overview ..........................................................................................11

Introduction to Acquisition/Financial Systems Interface Requirements .......................................17 

Funds Certification.........................................................................................................................21 

Obligation ......................................................................................................................................25 

De-Obligation ...............................................................................................................................31 

Payment .........................................................................................................................................33 

Closeout .........................................................................................................................................47 

Micropurchases Made with Purchase Cards..................................................................................51 

General Systems Requirements .....................................................................................................59 

Records Retention..........................................................................................................................63 

Appendix A: References/Authoritative Sources............................................................................65 

Appendix B: Glossary....................................................................................................................69 

Appendix C: Factors Influencing the Environment.......................................................................87 

Appendix D: Contributors..............................................................................................................93 
Illustrations 

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

2. The Agency’s Enterprise Architecture........................................................................................8 

3. Agency Systems Architecture...................................................................................................10 

4. Federal Acquisition System Process.........................................................................................12 

5. Funds Certification Process Flow .............................................................................................22 

6. Obligation Process Flow...........................................................................................................26 

7. De-Obligation Process Flow.....................................................................................................32 

8. Payment Process Flow ..............................................................................................................34 

9. Closeout Process Flow..............................................................................................................48 

10. Micropurchases Made with Purchase Cards Process Flow......................................................54
Acronyms 

ACES Access Certificates for Electronic Services 

ALC Agency Location Code 

A/OPC Agency/Organization Program Coordinator 

BPA Blanket Purchase Agreement 

CCR Central Contractor Registration 

CFO Chief Financial Officer 

CFR Code of Federal Regulations 

CIO Chief Information Officer 

COTS Commercial Off-the-Shelf 

DoD Department of Defense 

DOE Department of Education 

DUNS Data Universal Numbering System 

EA Enterprise Architecture 

EC Electronic Commerce 

ECC (PEC) Electronic Commerce Committee (Procurement Executives Council) 

EDI Electronic Data Interchange 

EFT Electronic Funds Transfer 

EIN Employer Identification Number 

EIT Electronic and Information Technology 

FAI Federal Acquisition Institute 

FAR Federal Acquisition Regulation 

FASAB Federal Accounting Standards Advisory Board 

FFMIA Federal Financial Management Improvement Act 

FFMSR Federal Financial Management System Requirements 

FMFIA Federal Managers’ Financial Integrity Act 

FSC Financial Systems Committee (Chief Financial Officers Council) 

FY Fiscal Year 

GAO General Accounting Office 

GPEA Government Paperwork Elimination Act 

GPRA Government Performance and Results Act 

GSA General Services Administration 
ID Identification 

IPAC Intragovernmental Payment and Collection 

IT Information Technology 

JFMIP Joint Financial Management Improvement Program 

LMI Logistics Management Institute 

NARA National Archives and Records Administration 

OMB Office of Management and Budget 

OPM Office of Personnel Management 

PEC Procurement Executives Council 

PIN Personal Identification Number 

PL Public Law 

PMC President’s Management Council 

PO Purchase Order 

PP&E Property, Plant and Equipment 

PR Purchase Request 

RTN Routing and Transit Number 

SFFAS Statement of Federal Financial Accounting Standards 

SOW Statement of Work 

TFM Treasury Financial Manual 

TIN Taxpayer Identification Number 

U.S.C. United States Code 

USAID United States Agency for International Development 

U.S.SGL United States Standard General Ledger 

XML eXtensible Markup Language 
 

Acquisition/Financial Systems Interface Requirements 1

Introduction 

The U.S. Federal Government is the world’s largest and most complex enterprise, involving the 

collection, management, and disposition of billions of taxpayer dollars. Financial, acquisition, 

and program officials face tremendous challenges in managing Federal programs. Improvements 

in agency acquisition and financial systems are critical to government’s efforts to obtain complete and reliable information needed to manage this enterprise efficiently. Increasingly, integrated systems are expected to simultaneously support multiple users (program managers, financial managers, and acquisition managers) while systems and data are being shared by agencies 

with common needs. Information supplied by these systems is expected to become more timely, 

accurate, and consistent across the government. 

Representatives from acquisition and financial management functions governmentwide formed 

the partnership that developed this document. Its purpose is to provide a common set of acquisition/financial shared information requirements with which each agency’s integrated financial 

management system must be consistent. These shared information requirements, frequently arising from Federal statutes or regulations, constitute information available in one system that is 

required for the performance of another system. This document delineates those interface requirements between acquisition and finance, that are critical to the performance of both functions. These requirements are intended to be available to all users who rely on the information to 

carry out their responsibilities. This document does not address system requirements associated 

solely with the acquisition or financial process. 

The PEC and CFO Council represent the acquisition and financial communities from a wide 

range of major Federal agencies. The issuance of Acquisition/Financial Systems Interface Requirements (a first-time effort) demonstrates the commitment of the Federal financial and acquisition communities to improving information management systems, providing the best service 

possible to support program managers, and utilizing the taxpayer dollars entrusted to them as efficiently and as effectively as possible. 

The Federal government also has consistently recognized the importance of having high-quality 

information management systems that contain financial, acquisition, and other information necessary to support government operations. As a result, Congress enacted a variety of recent statutes, including the Federal Financial Management Improvement Act (FFMIA) of 1996 and the 

Information Technology Management Reform Act (Clinger-Cohen Act) of 1996 to assure that 

high-quality information management systems are developed to enable effective and efficient 

decision making by program officials. The Office of Management and Budget (OMB) also issued several relevant publications, including Circular A-127, “Financial Management Systems” 

and Circular A-130, “Management of Federal Information Resources,” which outlines the requirement that all electronic systems, including financial and acquisition systems, have a defined 

association to an agency’s enterprise architecture. The FFMIA and OMB Circular A-127 specifically provide the vision for a single, integrated Federal financial management system. As mentioned earlier, in support of that vision, JFMIP publishes requirements documents for financial 

systems and the financial aspects of mixed systems (such as acquisition). Acquisition/Financial 

Systems Interface Requirements should be considered in the context of all the other JFMIP re-
Introduction 

2 Acquisition/Financial Systems Interface Requirements 

quirements documents, which form the basis for total governmentwide financial system requirements.1

 

The first three sections of this document (“Federal Financial Management Framework,” “Integrated Financial Management Systems,” and “Agency Financial Management Systems Architecture”) set forth the framework for the establishment and maintenance of a single integrated Federal financial management system, provide information on integrating an agency’s financial 

management system, and identify the relationships of various system types. 

The next section, “Federal Acquisition System Overview,” discusses the high-level processes of 

the acquisition system, while “Introduction to Acquisition/Financial Systems Interface Requirements” describes the methodology used to identify and develop specific information requirements. 

“Funds Certification,” “Obligation,” “De-Obligation,” “Payment,” and “Closeout,” are the sections that define in detail the individual interfaces between the acquisition and financial systems 

and list the data elements associated with each of these interfaces. These sections are followed by 

“Micropurchases Made with Purchase Cards,” which addresses the process and information requirement using a purchase card as a purchasing method. 

The section, “General Systems Requirements,” sets forth the general requirements that apply to 

all agency core and mixed financial management systems, which is followed by a short chapter 

on “Records Retention.” 

Appendix A lists the statutes, laws and regulations upon which these interface requirements are 

based, followed by Appendix B, which is a glossary of the acquisition and financial terms used 

in this document. 

“Appendix C: Factors Influencing the Environment,” provides highlights of the activities that are 

particularly relevant to the acquisition and financial management communities. The last section 

of this document (Appendix D) lists those individuals who contributed their time, effort and vision to the development of this document. 

 

1

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

Acquisition/Financial Systems Interface Requirements 3

Federal Financial Management Framework 

Financial management systems in the Federal government must be designed to support the vision 

articulated by the government’s financial management community. This vision requires financial 

management systems to support the partnership between acquisition and financial managers and 

to ensure the integrity of information for decision making and measuring performance. This includes the following abilities: 

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

♦ Provide for adequate agency management reporting. 

♦ Support governmentwide and agencywide policy decision making. 

♦ Support the preparation and execution of agency budgets. 

♦ Facilitate the preparation of financial statements and other financial reports in accordance 

with Federal accounting and reporting standards. 

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

♦ Provide a complete audit trail to facilitate audits. 

♦ Provide adequate security controls to minimize the risk that data could be disclosed to 

unauthorized individuals, improperly used or manipulated, or destroyed due to unauthorized access or use. 

As shown in Illustration 1, establishing uniform requirements is only part of the process of improving financial management systems and information. Improvements are also achieved 

through the selection, development, and/or purchase of software applications that meet approved 

functional requirements and technical and data management specifications. Agencies must continue to improve their financial systems and implement new requirements as they are issued so 

that continuing efforts to standardize and upgrade data and reporting requirements, in accordance 

with the OMB’s governmentwide five-year financial management plan, will be successful. 

Well-defined and effective governmentwide functional requirements assist agencies in developing strong systems and information by eliminating duplicate work among agencies and providing 

a common framework so that commercial vendors can more economically provide systems software. Development of governmentwide functional requirements is a critical effort that will affect 

internally developed systems and mature manual systems, as well as the evaluation and selection 

of commercially available systems. In support of this vision, the Federal government must establish governmentwide financial management systems and compatible agency systems, with standardized information and electronic data interchange, to support program delivery, safeguard information and agency resources, and manage taxpayer dollars. 
Federal Financial Management Framework

4 Acquisition/Financial Systems Interface Requirements 

Each agency should supplement the governmentwide standard requirements, described in this 

document, with its unique agency requirements to provide a uniform basis for the standardization 

of financial management systems as required by the Chief Financial Officers (CFO) Act of 1990, 

FFMIA, and other statutes. Furthermore, each agency’s requirements for its financial management systems should be based upon, and integrated with, its efforts to develop and implement an 

enterprise architecture as called for in Federal legislation and clarified in OMB Circular A-130. 

However, standard core requirements must be maintained. 
Federal Financial Management Framework 

Acquisition/Financial Systems Interface Requirements 5

Financial System Improvement Projects 

Agency Implementation

Standards/

Requirements

• Standard Reporting

Requirements

• U.S. Government Standard

General Ledger

• Core Financial System

Requirements

• Human Resources &

Payroll Systems

Requirements

• Travel System

Requirements

• Seized Property and

Forfeited Assets Systems

Requirements

• Direct Loan System

Requirements

• Guaranteed Loan

System Requirements

• Inventory System

Requirements

• System Requirements

for Managerial Cost

Accounting

• Other Standards

• Additional

Agency

Functional

Requirements

• Additional

Agency

Technical

Requirements

• Integration

Strategy

• Software/

Hardware

Evaluation

• Software

Selection

• Adaptation

• Procedures

• Training

• Documentation

• Conversion

• Maintenance

Subject of

this report

• Property Management

Systems Requirements

• Acquisition/Financial

Systems Interface

Requirements

• Benefit System

Requirements

Illustration 1 
Federal Financial Management Framework

6 Acquisition/Financial Systems Interface Requirements 

It is critical that financial management systems support the agency’s mission and programs, including changes to them, and that financial management system’s plans are incorporated into the 

agency’s plans for information technology (IT) infrastructure and information systems as a 

whole. Further, systems design efforts should include an analysis of how systems improvements, 

new technology supporting financial management systems, and modifications to existing work 

processes can together enhance agency operations and improve program and financial management. Reassessing information and processing needs, and redesigning processes, procedures, and 

policies are essential steps to meeting user needs. 

Aligning technology with business needs is an important aspect of Enterprise Architecture (EA). 

Agencies are required by the Clinger-Cohen Act to provide this function within their organization. The EA function provides for analysis of business needs and monitoring business direction. 

Knowledge of this information helps to design better technology solutions and allows the organization to be better positioned to respond to internal and external change factors. As such, business programs and technology investments are linked in support of the agency’s mission. The 

EA function monitors emerging technologies and charts a course for the use of technology in the 

agency. This is very useful for planning any new systems development, as the system architecture must be compatible with what is in existence or “targeted” for future implementation. In this 

manner, the EA function contributes to the use of standards for consistent operations, as well as 

interoperability. 

It cannot be too strongly emphasized that the general success of these enterprise application initiatives may be dependent not so much on standard products, but on levels of interoperability that 

must be achieved by Federal agencies. Additionally, a Federal-level model of information that 

has standard definitions could be critical for effective integration and sharing of information. The 

data that moves upward should have definitions or descriptions of the data implemented governmentwide. Without the use of commonly defined data, inconsistencies may result in inaccurate reporting.

Integrated Financial Management Systems 

Financial management systems must be designed with effective and efficient interrelationships 

between software, hardware, personnel, procedures, controls, and data contained within the systems. To be integrated, financial management systems must have, as a minimum, the following 

four characteristics: 

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

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

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

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

The financial management system’s policy, described in OMB Circular A-127, requires that each 

agency establish and maintain a single, integrated financial management system. Without a sin-
Federal Financial Management Framework 

Acquisition/Financial Systems Interface Requirements 7

gle, integrated financial management system to ensure timely and accurate financial data, poor 

policy decisions may occur. Managers are less likely to be able to report accurately to the President, the Congress, and the public on government operations in a timely manner. Scarce resources are more likely to be directed toward the collection of information rather than to delivery 

of the intended programs. Further, modifications to financial management systems are necessary 

to keep pace with rapidly changing technology and user requirements that cannot be coordinated 

and managed properly. 

Having a single, integrated financial management system does not necessarily mean having only 

one software application within each agency covering all financial management system’s needs. 

Rather, a single, integrated financial management system is a unified set of financial systems and 

the financial portions of mixed systems (e.g., acquisition) encompassing the software, hardware, 

personnel, processes (manual and automated), procedures, controls, and data necessary to carry 

out financial management functions, manage the financial operations of the agency, and report 

on the agency’s financial status to central agencies, Congress, and the public. 

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

that are documented as part of the agency’s EA. 

Integrated means that the user is able to have one view into systems such that, at whatever 

level the individual is using the system, he or she can obtain the information needed efficiently and effectively through electronic means. It does not necessarily mean that all information is physically located in the same database. However, as data warehousing becomes more of a standard, the data may indeed be stored centrally and accessed remotely. 

These structured design aspects of how and where the data are located are decisions which 

get made in conjunction with the to-be view, data, applications and technology sections of 

an agency’s EA. 

Unified means that systems are planned and managed together, operated in an integrated 

fashion, and linked together electronically in an efficient and effective manner to provide 

agency-wide financial system support necessary to carry out the agency’s mission and support the agency’s financial management needs. It also means that this unification is resultant from having adhered to the approved architectural plans. 

Interfaces, where one system feeds data to another system following normal business/transaction 

cycles, such as depreciation charges recorded in general ledger control accounts at specific time 

intervals, may be acceptable as long as the supporting detail is maintained and accessible to 

managers. In such cases, interface linkages must be electronic unless the number of transactions 

is so small that it is not cost-beneficial to automate the interface. Reconciliations between systems, where interface linkages are appropriate, must be performed to ensure data accuracy. Similarly, such reconciliations should be automated when cost beneficial. 
Federal Financial Management Framework

8 Acquisition/Financial Systems Interface Requirements 

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

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

♦ How data quality will be ensured (data stewardship) 

♦ Data needed to support management decisions (information) 

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

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

All of these pieces must be brought together in a model, or integrated framework or architecture, 

such as the one shown in Illustration 2. These pieces must work together to form an efficient integrated information system. Federal agencies are required to adopt an enterprise-level system 

architecture to provide for the most efficient and effective utilization of technology in support of 

agency strategic and tactical goals. Modular design considerations are necessary to minimize the 

impact of future changes to information needs. Preliminary data analysis should drive the structure of system modules to isolate changes within a subject area. The following discusses agency 

financial management systems architecture and relates that discussion to system integration at 

the enterprise level as called for in Federal legislation and OMB guidance. 

The Agency’s Enterprise Architecture 

Internal Control

Processes

Management

Information

Systems

Architecture

Data Stewardship

Illustration 2 
Federal Financial Management Framework 

Acquisition/Financial Systems Interface Requirements 9

Agency Financial Management Systems Architecture 

Agency financial management systems are information systems that support the preparation of 

auditable financial statements, track financial events, and summarize financial information to 

support the mission of an agency. These systems are necessary to provide adequate management 

reporting and support agency-level policy decisions necessary to carry out fiduciary responsibilities. 

Agency financial management systems fall into three categories: 

(1) Core financial systems 

(2) Other financial and mixed systems, including acquisition management systems 

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

These systems must be linked together electronically to be effective and efficient. Moreover, systems in all three of these categories likely have dependencies upon and some data exchange relation to other information management systems used by the agency, such as project management 

systems or performance tracking systems. Summary data transfers must be provided from a wide 

range of agency systems to central systems to permit summaries of management information and 

agency financial performance information on a governmentwide basis. 

Subject to governmentwide policies, the physical configuration of financial management systems, including issues of centralized or decentralized activities, processing routines, data exchange and management, and organizational responsibility, is a decision best left to the individual agency, which can determine the optimal manner in which to support its mission. As financial management is but one aspect of back office support of each Federal agency’s overall mission, it is appropriate to endeavor to develop and operate core financial and other related information systems in concert with one another, enabling consolidation of common requirements and 

electronic interchanges. In keeping with guidance provided by the Federal Chief Information Officers’ (CIO) Council, agencies are recommended to steer toward use of open industry-wide supported standards and nonproprietary interfaces in their architectural designs. The physical design 

of systems, however, should consider the agency’s organizational philosophy, the technical capabilities available, and the most appropriate manner in which to achieve the necessary single 

integrated financial management system for the agency. 

The systems architecture shown in Illustration 3 provides a finance system-centric logical perspective identifying the relationships of various financial system types. Although this does not 

necessarily represent the physical design of the system, it does identify agency system types generally needed to support program delivery/financing and financial event processing for effective 

and efficient program execution. Also, there is a requirement for an agency’s financial management systems of record, especially those supporting central agency reporting, to use the U.S. 

Standard General Ledger (U.S.SGL) Chart of Accounts. The acquisition system box highlighted 

in Illustration 3 signifies the financial interface requirements between an agency’s acquisition 

and core financial systems—not those associated with the entire acquisition process. 
Federal Financial Management Framework

10 Acquisition/Financial Systems Interface Requirements 

An agency’s financial management system architecture is an important subset of the agency’s 

overall enterprise and IT architecture. Maintaining an agencywide view of systems’ development 

and use is especially critical to discussions involving financial systems’ deployment, as an enterprise architecture’s primary purpose is to support IT capital investment and help define a direction for future technology acquisitions. Thus, both financial system reporting and expenditure 

decisions, as well as procurement actions, are necessarily core functions addressed within the 

business layer of the enterprise architecture. Each agency’s core financial systems grow from a 

set of articulated requirements that are, by definition, relevant to the entire federal enterprise. 

The degree of integration of all of an agency’s systems should be reflected in the design and operational configuration decisions pertaining to its financial system architecture.

Agency Systems Architecture

	



















	






	










 











	







 !
 

 



	








"









#


$




 






%	





&

$		






	








 
		
 

		
 	 		

	 
 
  

Illustration 3 

As shown in Illustration 3, acquisition systems are an integral part of the total financial management system for all Federal agencies. They support programmatic objectives and interact with 

core financial, property management, inventory, and other systems, to certify funds availability, 

commit/de-commit funds, obligate/de-obligate funds, make payments, and support contract 

closeout processes. 

The following section provides an overview of the Federal acquisition system. 
 

Acquisition/Financial Systems Interface Requirements 11

Federal Acquisition System Overview 

This section provides an overview of the acquisition system. It is provided as a background for 

delineating the high-level processes whereby the acquisition and financial systems must share 

information requirements. 

The Federal acquisition system encompasses the processes, policies, and procedures the government employs to acquire products and services for its use. Those processes, policies, and procedures are applicable to all executive agencies and are published in the Federal Acquisition Regulation (FAR) and various agency regulations that implement or supplement the FAR. The dollar 

value of all products and services acquired by the Federal government amounted to over $230 

billion in fiscal year (FY) 2000 and involved almost 30 million transactions.2

 This total includes 

23.5 million transactions worth $12.3 billion using purchase cards. 

The following are some of the principles guiding the system: 

♦ Providing quality products, on a timely basis, at reasonable costs to the taxpayer 

♦ Promoting competition while rewarding contractors for successful past performance 

♦ Maintaining a system open to all responsible contractors while meeting special public 

policy objectives, e.g., environmental, socio-economic. 

Responsible government officials implement the system in the broad areas of requirements definition, solicitation, negotiation, source selection, award, and contract administration. Those officials are free to apply sound business judgment to these various aspects of the system, provided 

such judgment: (1) is consistent with the FAR; other regulations that apply to agencies and organizations not covered by the FAR, and various agency regulations that supplement the FAR, 

(2) does not violate law, executive order, or other regulations; and (3) is in the best interests of 

the government. 

The Federal acquisition system relies on, and interacts with, many other agency-specific systems. 

For example, inventory systems may trigger the decision to procure, while the delivery of contract end items may be used to establish the agency’s property management system record. Similarly, the acquisition system’s issuance of an award can trigger the establishment of the financial 

system’s obligation transaction by means of an electronic interface. The principal system, however, that shares information requirements and creates two-way dependencies with the acquisition system is the financial system. These dependencies help to ensure integrity and control in 

the areas of budget, program management and delivery, external reporting, and data integrity. 

The Federal acquisition system is represented in the following high-level process flow diagram 

(Illustration 4). The diagram shows critical interfaces between the acquisition and financial systems (highlighted boxes) as well as a myriad of acquisition-related activities that occur within 

this process. Within this life cycle, there are two procurement methods that differentiate the 

 

2

 Federal Procurement Report, Fiscal Year 2000 through Fourth Quarter, (October 1, 1999 through September 30, 

2000). 
Federal Acquisition System Overview

12 Acquisition/Financial Systems Interface Requirements 

processes that occur between acquisition and finance and define the resulting interface requirements that occur. These distinguishing procurement methods are (1) micropurchases made with 

purchase cards and (2) procurements (for purposes of this document, transactions other than micropurchases made with purchase cards).3

Federal Acquisition System Process 

(Financial Interfaces Highlighted)

Is this a

micropurchase?

Use FAR Part 13

(micropurchase

procedures)

to conduct

acquisition

Decision to procure

FUNDS

CERTIFICATION

Use authorized

purchase card or

prepare funded

PR

No

Select procurement

method, contract type,

and evaluation plan

Develop solicitation

package

Receive quotes, bids,

and offers

Evaluate quotes, bids,

and offers

Obtain contract

approvals and document

files

OBLIGATION

 Award contract and

obligate funds

If applicable, determine

competitive range and

conduct negotiations

Conduct preaward

survey and determine

responsibility

Debrief unsuccessful

offerors and conduct

postaward orientation

OBLIGATION/

DE-OBLIGATION

Manage contract funding

changes

Respond to queries and

requests for information

FUNDS CERTIFICATION

Obtain funding approval

Develop procurement

request package:

Statement of work,

purchase request,

JOFOC, specification,

and evaluation

criteria

Issue

solicitation

PAYMENT

Conduct myriad

contract administration

actions related to

receipt and acceptance

CLOSEOUT

Conduct contract

closeout

Conduct market research

and develop acquisition

plan, if applicable

Yes

Illustration 4 

 

3

 It should be noted that payment for micropurchases can also be accomplished with imprest fund transactions, third 

party drafts, or convenience checks, however these techniques occur with less frequency than payment with purchase cards. 
Federal Acquisition System Overview 

Acquisition/Financial Systems Interface Requirements 13

The Federal Acquisition Streamlining Act of 1994 created a new procurement category called 

micropurchases for open market purchases below a dollar threshold (currently $2,500). Streamlined micropurchases use purchase cards as the preferred method of procurement.4

 Funding, obligation, and payment may often be executed on a bulk basis rather than on an individual transaction basis. Generally, micropurchases require more limited interface with finances than procurements. See the section titled Micropurchases Made with Purchase Cards in this document for a 

discussion of the process used to accomplish micropurchase acquisitions. 

For procurements, four basic processes between acquisition and finance are involved: funds certification, obligation/de-obligation, payment, and closeout. It is these processes (which may not 

be universally applicable) that form the structure for organizing shared information requirements 

described in detail in later sections of this document and summarized below. 

To begin the procurement process, the agency conducts market research and may develop an acquisition plan. The agency program (requiring) office develops a procurement request to be sent 

to the contracting office. The government may set forth its requirements for products or services 

in a statement of work (SOW). The SOW reflects the government’s market research and maximizes the use of commercial products and services. The agency then determines the evaluation 

criteria that will be used to select a source. 

At this point in the procurement process, the first acquisition/financial information exchange occurs as the financial system is accessed to perform a funds availability certification or funds certification to verify that funds are available for the contemplated purchase. Where possible and 

cost effective, an electronic interface at this point may enable the establishment of commitment 

records. Through funds certification, funds may be committed or reserved in the financial system 

in anticipation of future obligations. The commitment, or reservation of funds, prevents those 

funds from being used for any other purpose. 

Following funds certification, the procurement action typically proceeds through the remainder 

of the acquisition process, i.e., solicitation, negotiation, and award. A determination is made as to 

the method of procurement, e.g., negotiated procurement, or purchase from an agency or governmentwide contract. A solicitation is then issued and responses are received and evaluated. In 

the case of negotiated procurements, the competitive range is established, negotiations are conducted, and a contract is awarded. In some cases, agencies use contracting vehicles from other 

agencies (e.g., General Services Administration [GSA] Multiple Award Schedules, governmentwide acquisition contracts) to perform more streamlined acquisitions by placing delivery 

orders against these contracting vehicles. 

Once a contract is awarded, if funds are to be contemporaneously obligated, the acquisition system’s record can be used to establish the financial system’s initial obligation transaction by 

means of an electronic interface. The obligation is then recorded in the finance system and eventually results in outlays as the terms of the contract are satisfied. Similarly, an obligation or a deobligation record can be produced when modifications, cancellations, task orders or other adjustments affecting contract funding are processed against awards. In addition, certain modifica-

 

4

 Purchase cards can also be used as a payment method for other procurements. Information requirements for this 

type of payment method are discussed in the section on payments. 
Federal Acquisition System Overview

14 Acquisition/Financial Systems Interface Requirements 

tions require no obligation or de-obligation of funds, but may generate information important to 

finance and acquisition, e.g., name changes. 

As part of contract administrative management activities, receipt and acceptance of products and 

services are routinely addressed so that contractor performance and related payments can be accomplished in accordance with the contract’s terms and conditions. These actions also relate to 

the payment management function within the core financial system5 that maintains the necessary 

information to effect and manage the payment process. Documentation supporting payment, such 

as evidence of receipt and acceptance, may be provided through interfaces with acquisition, 

property management, inventory, or other systems involved in the receipt and acceptance of 

products or services. 

The closeout process occurs as a result of the government’s determination that the contract has 

been physically completed and all administrative actions, including final receipt and final payment, have been made. 

This document establishes the shared information requirements for acquisition and financial systems, within the functional interface processes described above. 

Information Technology in the Acquisition Process 

Advancements in information technology are of particular importance to agency acquisition and 

financial systems, organizations, and communities. This importance is demonstrated by the significant amount of information requirements and processes that are common to the Federal acquisition and financial communities, and systems. This document identifies some general and 

specific information technology requirements. However, it is through each agency’s EA development that articulation and application of its knowledge of relevant technology and business 

trends to meet their unique financial management information systems requirements occurs. (See 

section on Agency Financial Management System Architecture for a more in-depth discussion of 

this point.) 

Many solutions are still evolving in order to implement mandatory requirements contained in 

several public laws that have been enacted during the past several years, such as: 

♦ Government Paperwork Elimination Act (GPEA) of 1998—requires Federal agencies to 

allow, by October 21, 2003, individuals or entities, as an option, to interact with them 

electronically where practicable. 

♦ The Debt Collection Improvement Act (DCIA) of 1996—requires Federal disbursing officials to offset an eligible payment to a payee to satisfy a delinquent non-tax debt owed 

by the payee to the government. The DCIA requires agencies to include the taxpayer 

identification number (TIN) on payment vouchers and mandates the use of electronic 

funds transfer (EFT) when making Federal payments. To comply with these DCIA provisions, OMB’s budget guidance of June 7, 2001, requires vendors and agencies to use the 

Central Contractor Registration (CCR), beginning October 1, 2002. 

 

5

 JFMIP Core Financial System Requirements (SR-99-4). 
Federal Acquisition System Overview 

Acquisition/Financial Systems Interface Requirements 15

♦ Section 508 of the Rehabilitation Act of 1973, as amended—requires that all Federal 

agencies’ electronic and information technology (EIT) be accessible to people with disabilities (See Appendix C). 

♦ Information Technology Management Reform Act (ITMRA) of 1996, as amended (also 

known as Clinger-Cohen Act of 1996)—establishes the role of CIOs in the government, 

and forms the interagency CIO Council. The intent of the Act is to improve government 

performance through the effective application of information technology and calls for “an 

integrated framework (or enterprise architecture) for evolving or maintaining existing information technology and acquiring new information technology to achieve the agency’s 

strategic goals and information resource goals.” 

Appendix A should be consulted for additional statutes containing provisions that are currently 

applicable, or may be in the future. Appendix C should also be consulted for significant, timely 

information regarding the environment within which financial and acquisition systems interface. 

The following section provides an introduction to shared information (interface) requirements of 

acquisition and financial systems. 
(LEFT BLANK INTENTIONALLY) 
 

Acquisition/Financial Systems Interface Requirements 17

Introduction to Acquisition/Financial Systems Interface 

Requirements 

This document identifies the shared information requirements necessary within the acquisition 

and financial systems to facilitate efficient and reliable data sharing between the acquisition and 

financial management processes. These requirements are based upon statute, regulation, or best 

practice and were deliberated and concurred upon by the acquisition and financial communities 

represented by the participants of this study. Financial and mixed systems must comply with 

these requirements to ensure the sharing of data among systems and to form the basis for an 

agency’s single integrated financial management system. These acquisition/financial system interface requirements have been prepared separately as a step in documenting all mixed systems 

requirements. For this reason, readers are advised that this publication’s contents must be assimilated by users in the context of all requirements contained within the unified set of financial systems and the financial portion of mixed systems (e.g., acquisition) which comprise the single integrated financial management system. 

To develop these shared information requirements, a team was established and members were 

assigned responsibility for each of four processes: funds certification, obligation/de-obligation, 

payment, and closeout. Fifty-four team members from 23 government agencies participated in 

this effort and represented approximately equal membership from both the acquisition and finance communities. The team included members from governmentwide policy and audit organizations such as the GAO, the OMB, and the Federal Accounting Standards Advisory Board 

(FASAB). 

Methodology 

As a first step in identifying shared information requirements, the team created flow diagrams 

associated with each of the four interface processes. These diagrams depict various crossfunctional interactions during the acquisition process. Next, the team identified, from statutory or 

regulatory source documents, the information-specific requirements that must be available to enable the execution of the activity in the process flow. The exact language of the requirement was 

identified as it appeared in statute and implementing documents, e.g., FAR and Core Financial 

System Requirements. In addition to reviewing Core Financial System Requirements, the team 

evaluated other relevant JFMIP documents covering related functions, e.g., property, inventory, 

and seized property and forfeited assets. After much deliberation, the team derived specific 

shared information requirements, and these requirements were then documented. 

Concurrently, the team identified the information that must be available within the single integrated financial management system and accessible to the acquisition and financial systems 

through an interface. Note that an information interface requirement may take a number of 

forms: a data element, a reporting need, an internal control, or an edit requirement. 

Interface requirements in this document are designated as either mandatory or value-added. The 

following definitions govern the distinction between mandatory—signified by the word 

“must”—and value-added—signified by the word “should.” 
Introduction to Acquisition/Financial Systems Interface Requirements 

18 Acquisition/Financial Systems Interface Requirements 

♦ Mandatory requirements describe what the system must do and consist of the minimum 

acceptable functionality necessary to establish a system, or are based on Federal laws and 

regulations. Mandatory requirements are those against which agency heads evaluate their 

systems to determine substantial compliance with systems requirements under the 

FFMIA. These requirements apply to existing systems in operation and new systems 

planned or under development. 

♦ Value-added 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 system options. The need for these value-added features in agency systems 

is left to the discretion of each agency head. 

The various steps and information requirements associated with the financial and acquisition 

processes do not necessarily occur in all cases in the order presented. Any information requirement identified as mandatory, is mandatory throughout the acquisition process, if applicable to 

the transaction, no matter when in the process the associated data becomes available. For example, in the case of a new procurement, contractor name may only become available during the 

obligation process. In contrast, contractor name is available during the funds certification process 

for contract modifications. 

During the development of the shared information requirements, the team also differentiated between the two alternative procurement methods—micropurchases made with purchase cards and 

procurements. Within each of these alternatives, the process flow diagrams in each respective 

process section display the activities executed by one of the following: the agency’s designated 

official, contracting, finance, contractor or disbursing. Note that for a given activity, the performing organization is not necessarily the same in every agency. Designated official refers to the organizational element responsible for the process step, such as the program office, receiving and 

acceptance officials, and sometimes contracting or finance representatives. The contracting function is the actual contracting office that has been delegated contracting authority pursuant to the 

FAR.6

 The finance function could include the finance, accounting, program, or budget office(s) 

or be an automated part of the financial system. Contractor refers to the commercial organization 

that performs the service or supplies the products and disbursing is the government payment organization that makes physical payment. 

This document may be used when developing new acquisition and financial systems, and related 

interfaces, or improving/evaluating current systems. It, however, does not provide hardware/software performance requirements for such systems; rather, it provides the high-level interface requirements necessary for the acquisition and financial communities to effectively complete the integration of their systems. 

 

6

 FAR 1.602-1 “Career Development, Contracting Authority, and Responsibilities—Authority.” 
Introduction to Acquisition/Financial Systems Interface Requirements 

Acquisition/Financial Systems Interface Requirements 19

Data Elements and Data Entry 

The data elements identified in the subsequent process sections include all data required to execute the identified functionality. In some cases, the same data element may appear in more than 

one functionality. This allows system developers to understand the entire set of data required for 

a specific functionality within an interface process. It is not meant to suggest multiple entries of 

data. 

Information requirements are identified within each interface process. For example, invoices, 

receiving reports, payment, and acceptance documents are sources for information requirements 

associated with the payment process. Many important data elements may be included within an 

information requirement. As an example, a receiving report may include the following data elements: product/service description, quantity received, and date received. 

Data entered at any point in the acquisition process should be retrievable at a subsequent point or 

points. As a specific example, assume that products previously ordered have been received. 

Some systems allow the receiving official to electronically select items from the purchase order 

(PO) and indicate receipt of just these items. Under these circumstances, the official does not 

have to reenter all of the detailed receiving report data. The data related to the receipt includes 

certain data from the PO (e.g., product description and elements of accounting information) as 

well as data not previously entered (e.g., date received and quantity received) which a designated 

official would enter into the acquisition, property management or inventory system, as applicable. The goal is to have full accessibility and portability of the previously entered data within the 

agency’s single integrated financial management system. 

Access to Information 

The acquisition/finance interface requirements in this publication have been identified as essential to the performance of both the finance and acquisition functions. This information is critical 

at the time of its initial entry into the agency’s single integrated financial management system 

and retains its importance as long as it is necessary for it to be contained in this system. As such, 

these requirements, regardless of their form, must be made available to all users—both from the 

finance and acquisition communities—who require it to carry out their respective responsibilities. 

The flow diagrams for each process (funds certification, obligation, de-obligation, payment, and 

closeout) are presented in their respective sections. The following section covers the funds certification process.
(LEFT BLANK INTENTIONALLY) 
 

Acquisition/Financial Systems Interface Requirements 21

Funds Certification 

Funds availability certification, or funds certification, is part of the funds control process that 

verifies that funds or budget authority is available for the contemplated acquisition. This is the 

first point at which the acquisition process interfaces with the financial system. Funds are generally restricted by law or regulation, as to purpose, amount, and period of availability. Once the 

budgetary authority is received and recorded in the accounting system, purchases can be made 

within its limitations. Funds certification accounting records help ensure that subsequent entry of 

undelivered orders or accrued expenditures does not exceed the balance of funds available, i.e., 

the budgetary restrictions on amount and availability. The acquisition system can access data 

electronically, in some cases, and use capabilities of the core financial system to verify that funds 

are available and comply with appropriation law. 

Commitment accounting, often accomplished as part of funds certification, is a practice whereby 

agencies can make an administrative reservation of funds when a known procurement requirement exists. It is essentially used as a placeholder until there is an order placed, contract 

awarded, or service rendered. While not all agencies’ accounting systems require the formal recording of commitments, if used, they are able to produce commitment records and update financial balances, which aids in overall fiscal management. 

Funds Certification Process Flow (see Illustration 5) 

The funds certification process begins with a requirement for supplies and/or services and a decision to obtain the needed items through acquisition. The result is a purchasing action for which 

funds are certified and, if necessary under agency policy, committed. In the first step of funds 

certification, the designated official (e.g., the program manager) develops a requirement and initiates a purchase request (PR) to submit to finance for funding. The PR describes the requirement 

and its estimated value. In addition, it should contain or have attached an accounting citation of 

the actual funds to be certified. The initial PR may be later modified to adjust funding (or subsequent PR’s may be issued to adjust funding) for incremental funding, price adjustments, 

cost/price incentives, etc. For agencies using commitment accounting, these adjustments may 

result in additional commitments or decommitments. Finance then posts the initial funds commitment (or decommitment) and subsequent funding adjustments through transactions to the accounting record. Once funds have been identified and certified as to availability, finance indicates that funds are certified either on or with the PR forwarded to contracting. The contracting 

officer checks for funds certification prior to beginning the procurement action. PR’s may be initiated for future period activity, in which funding is not yet available, e.g. start of a fiscal year. 

The process flow diagram of funds certification for procurements is shown in Illustration 5. 
Funds Certification 

22 Acquisition/Financial Systems Interface Requirements 

Funds Certification Process Flow 

Procurements - Acquisition/Finance Cross-Functional Interface

Contracting Finance* Contractor Disbursing Designated

 Official Finance

Funds Certification

Develops PR &

identifies funds for

commitment

Receives and reviews

requirement documents

May post

commitment/

reservation of funds

transactions, or

adjusted

commitments

transactions

Verifies funds

availability

Illustration 5 

Mandatory Requirements for Funds Certification 

To support the funds certification process, the agency’s single integrated financial management 

system must provide the following capability: 

♦ Access the following information 

3⁄4 FY; 

3⁄4 appropriation/Treasury fund symbol; 

3⁄4 organization code; 

3⁄4 cost center; 

3⁄4 object classification; 

3⁄4 estimated amount; 

3⁄4 project code; 

3⁄4 program code; 

3⁄4 PR number; 

3⁄4 transaction date; 

3⁄4 action code (original/new/modification); 
Funds Certification 

Acquisition/Financial Systems Interface Requirements 23

3⁄4 subject to funds availability indicator; 

3⁄4 asset identifier code;7

3⁄4 contractor code/name; 

3⁄4 trading partner; and 

3⁄4 trading partner code. 

Value-Added Requirements for Funds Certification 

To support the funds certification process, the agency’s single integrated financial management 

system should provide the following capability: 

♦ Access the following information 

3⁄4 intra-governmental business partner code (will become mandatory upon issuance of 

governmentwide implementing standard requirements); 

3⁄4 interagency agreement number; 

3⁄4 performance measure code; 

3⁄4 description; 

3⁄4 estimated amounts increased and/or decreased; 

3⁄4 revenue source code; and 

3⁄4 agency location code (ALC). 

♦ Access the estimated quantity associated with establishing the obligation where applicable, such as for property or inventory purchases. 

♦ Enable electronic approvals, notification alerts, and point-of-entry automated requisition 

forms. 

The next interface process, obligation, is discussed in the following section.

 

7 The asset identifier code is a new information requirement used to identify assets or multiple assets, as in the case 

of inventory or pooled property, plant, and equipment (PP&E) items, for which costs are incurred. Federal accounting standards require that recorded costs for inventory and PP&E assets include all costs incurred to bring these assets to the form and location suitable for their intended use. Since more than one contract or acquisition activity may 

be utilized to acquire and place PP&E (including national defense PP&E) in the form and location suitable for its 

intended use, this code will facilitate the accounting for total acquisition/contracting costs. The need for total costs is 

important for cost accounting, financial reporting, and asset valuation purposes. Therefore, the asset-identifier code 

has been included throughout the interface processes. Agencies will have to determine what organization. (e.g., program, finance) will determine the coding of assets. 

 

Acquisition/Financial Systems Interface Requirements 25

Obligation 

Obligation Process Flow (see Illustration 6) 

An obligation is a binding agreement that will result in outlays. The signing of a contract by a 

contracting officer creates a bona fide obligation. However, the obligation to pay is conditional 

upon satisfactory performance by the contractor. This obligation to pay is recorded in the 

agency’s financial records based on the accounting information contained in the signed contract. 

Finance is provided a copy of the contract to record the obligation and to obtain payment instructions. In the case of fully integrated systems, this function is performed through the routing and 

approval process and the obligation is done upon approval by the last approver, i.e., contracting 

officer. 

Once the contract is awarded, the acquisition system’s award record can be used to verify funds 

availability and establish the financial system’s obligation transaction by means of an electronic 

interface, thus eliminating erroneous transaction entry duplication. Similarly, de-obligation records can be produced when modifications, cancellations, or other adjustments are processed 

against awards. If a commitment record was previously established, the related obligation may 

differ in amount, vendor, or other attributes. Alternatively, an obligation record can be created 

without a related commitment. At this point in the process, vendor information captured in an 

acquisition system may also be used to establish payee records in the payee maintenance8

 portion 

of the payment management system. 

Budgetary resources must normally be available before obligations can be incurred. To meet this 

requirement, three elements must be satisfied prior to recording an obligation against an appropriation account: 

♦ Purpose—the obligation must be for a purpose for which the appropriation was made. 

♦ Time—the obligation must be incurred within the time that the appropriation was made 

available for new obligations. 

♦ Amount—the obligation may not exceed the amount of funds available for obligation 

against the appropriation. 

Procurement systems must be able to record, track, and report complete obligations, whether 

funded by current or planned future appropriations. These elements of the obligation concept are 

applied to individual transactions on a case-by-case basis. Although funds may have been certified as available for obligation just prior to contract award, appropriation law and accounting 

controls necessitate testing these elements prior to recording the obligation. The process of obligating funds primarily applies to appropriated funds. Other types of funds (i.e., revolving, nonappropriated, and working capital) do not necessarily obligate funds. Such funds should follow 

applicable procedures for the commitment of funds as specified by the enacting legislation/authorities. 

 

8

 For more information on requirements related to core financial system functions such as payee maintenance, refer 

to Core Financial System Requirements.
Obligation 

26 Acquisition/Financial Systems Interface Requirements 

The process flow diagram of obligation for procurements is shown in Illustration 6. 

Obligation Process Flow 

Procurements - Acquisition/Finance Cross-Functional Interface

Contracting Finance* Contractor Disbursing Designated

 Official Finance

Obligation

CO creates bona

fide obligation

Records CO's

obligation

Provides payment

instructions to finance

CO verifies funds

availability before

signing contract

Illustration 6 

Mandatory Requirements for Obligation 

To support the obligation process, the agency’s single integrated financial management system 

must provide the following capability: 

♦ Access the following information 

3⁄4 FY; 

3⁄4 appropriation/Treasury fund symbol; 

3⁄4 organization code; 

3⁄4 cost center; 

3⁄4 object classification; 

3⁄4 project code; 

3⁄4 program code; 
Obligation 

Acquisition/Financial Systems Interface Requirements 27

3⁄4 obligation amount; 

3⁄4 PR number; 

3⁄4 funded through date (for those contracts that are incrementally funded) 

3⁄4 contract number and all associated delivery order numbers or task order numbers (including modification number, if any); PO number (including modification number, if 

any); blanket purchase agreement (BPA) number and all associated BPA call numbers (including modification number, if any); 

3⁄4 contractor name; 

3⁄4 contractor TIN; 

3⁄4 Data Universal Numbering System (DUNS) identification; 

3⁄4 interagency agreement number; 

3⁄4 trading partner; 

3⁄4 award (transaction) date; 

3⁄4 effective date; 

3⁄4 action code; 

3⁄4 product or service description; 

3⁄4 amounts increased and/or amounts decreased; 

3⁄4 subject to funds availability indicator; and 

3⁄4 asset identifier code. 

♦ Use account definitions consistent with the account definitions in the U.S.SGL. Any 

expansion to the chart of accounts must roll up to the accounts as defined in the U.S.SGL. 

However, a pseudo code can be used instead of the exact U.S.SGL account numbers, 

providing the account descriptions and posting rules are the same as those used in the 

U.S.SGL for relevant transactions. 

♦ Provide the capability to create additional subaccounts to the general ledger for agency 

specific tracking and control. These subaccounts will summarize to the U.S.SGL accounts. 

♦ Access the full estimated cost of the interagency agreement (both direct and indirect costs 

need to be provided for evaluation). 

♦ Provide transaction details to support account balances. 
Obligation 

28 Acquisition/Financial Systems Interface Requirements 

♦ Provide access to a hard copy or an electronic copy (where cost effective) of the entire 

executed (signed) contract,9 including the following data elements captured at obligation 

and necessary for payment and/or other financial processes 

3⁄4 obligating document number (if different from contract number); 

3⁄4 contractor name and address; 

3⁄4 contract administration office; 

3⁄4 payment office; 

3⁄4 unit of measure; 

3⁄4 unit price; 

3⁄4 extended price; 

3⁄4 quantity; 

3⁄4 variance amount or percentage allowed; 

3⁄4 total amount; 

3⁄4 payment terms and conditions (e.g., discount terms, applicable payment clauses, 

withhold indicator, withhold percentage, etc.); 

3⁄4 delivery/performance schedule; 

3⁄4 estimated completion date; 

3⁄4 payment type (e.g., prompt pay, fast pay, progress pay, or partial pay); 

3⁄4 names of government-designated receiving, invoice-approving, and acceptance officials; 

3⁄4 shipping costs; and 

3⁄4 shipping terms, e.g., FOB destination. 

♦ Identify the method of acquisition, e.g., purchase or lease. 

 

9

 Per FAR 4.201, the entire signed contract is provided to the paying office. 
Obligation 

Acquisition/Financial Systems Interface Requirements 29

Value-Added Requirements for Obligation 

To support the obligation process, the agency’s single integrated financial management system

should provide the following capability: 

♦ Access other information where applicable and available 

3⁄4 performance measure code; 

3⁄4 revenue source code; 

3⁄4 additional funding indicator, including increases and decreases; 

3⁄4 line item number, including access to contract line item data; and 

3⁄4 ALC. 

♦ Provide an indicator (e.g., Y/N) as to whether payments to the contractor are exempt 

from EFT. 

♦ Access the following information related to an EFT payment 

3⁄4 contract number and all associated delivery order numbers or task order numbers (including modification number, if any); PO number (including modification number, if 

any); BPA number and all associated BPA call numbers (including modification 

number, if any); name and remittance address; 

3⁄4 signature, title, and telephone number of the contractor official authorized to provide 

EFT information; 

3⁄4 name, address, and nine-digit routing and transit number (RTN) of the contractor’s financial agent; 

3⁄4 contractor’s account number and type of account (checking, savings, or lockbox); 

3⁄4 the Fedwire Transfer System telegraphic abbreviation of the contractor’s financial 

agent; and 

3⁄4 the name, address, telegraphic abbreviation, and nine-digit RTN of the financial institution receiving the wire transfer payment, if the contractor’s financial agent is not 

connected directly to the Fedwire Transfer System online. 

♦ Provide the ability to cross-reference contract numbers and related interagency agreements. 

♦ Access lease information 

3⁄4 amount; 
Obligation 

30 Acquisition/Financial Systems Interface Requirements 

3⁄4 agency option to purchase at end of lease (include purchase price if agency has option 

to purchase); 

3⁄4 life expectancy of leased property when new, and remaining life when leased; 

3⁄4 current retail or fair value of leased property; 

3⁄4 agency option to property ownership transfer at end of lease; and 

3⁄4 access to the lease agreement, including terms and conditions, e.g., discount terms 

and lease period. 

♦ Enable electronic contracting, obligation of funds, approvals and signatures, and notification alerts for pending actions. 

♦ Record periodic obligations 

3⁄4 appropriate periodic obligations against appropriated funding and contracts; and 

3⁄4 appropriate contract-specified cost escalations to existing contract line numbers. 

♦ Access information associated with contract changes 

3⁄4 change in product or service descriptions; 

3⁄4 change in unit of measure; 

3⁄4 change in quantity; 

3⁄4 change in unit price; 

3⁄4 change in total amount; 

3⁄4 change in extended price; 

3⁄4 change to payment terms and conditions; 

3⁄4 change to delivery/performance schedule; and 

3⁄4 revised estimated completion date. 

When an agency cancels or makes a downward adjustment to a previously recorded obligation, 

the result is a de-obligation. This process is described in the next section.
 

Acquisition/Financial Systems Interface Requirements 31

De-Obligation 

De-Obligation Process Flow (see Illustration 7) 

A de-obligation is an adjustment or modification downward to an existing obligation. It typically 

frees up funding which may then be applied to alternative activities. A de-obligation may be initiated in one of two ways: 

♦ As part of the payment process, finance performs periodic or year-end reconciliations of 

actual expenditures to obligations. If finance concludes, as a result of these reconciliations, that obligated funds have exceeded expenditures, finance contacts the contracting 

officer to determine whether additional expenses have been incurred, but not billed. If 

additional expenses have not been incurred and the contract is complete, the contracting 

officer de-obligates or modifies the funded contract amount. The contracting officer contacts both finance and the designated official of this action. Finance records the deobligation. In the case of fully integrated systems, this function is performed through the 

routing and approval process and the de-obligation is done upon approval by the last approver, i.e., the contracting officer. 

♦ The designated official may initiate the request for the de-obligation action, perhaps because of a funding realignment or reduced requirements. The contracting officer is notified by the designated official (if other than the contracting officer) and the contracting 

officer, with the assistance of finance, then verifies whether the affected funds have been 

expended and if further expenses have been incurred and not yet billed. The contracting 

officer then de-obligates or modifies the contract to de-obligate the funding. The 

contracting officer notifies both finance and the designated official of this action and finance records the de-obligation. 

The process flow diagram of de-obligation for procurements is shown in Illustration 7. 
De-obligation

32 Acquisition/Financial Systems Interface Requirements 

De-Obligation Process Flow 

Procurements - Acquisition/Finance Cross-Functional Interface

Contracting Finance Contractor Disbursing Designated

 Official

Records CO's

de-obligation

Compares

expenditures to

obligations (e.g. final

payment, other)

CO de-obligates

funds/modifies

contract amount

after verifying funds

not paid

Informed of deobligation of funds

Either initiates action Requests deobligation action

Proceed with

closeout If contract complete

De-Obligation

Illustration 7 

Mandatory Requirements for De-Obligation 

To support the de-obligation process, the agency’s single integrated financial management system must provide the capability to access all information previously supplied for the original obligation. 

Value-Added Requirements for De-Obligation 

To support the de-obligation process, the agency’s single integrated financial management system should provide the capability to access all information previously supplied for the original 

obligation. 

The subject of the next section is the payment process. 
 

Acquisition/Financial Systems Interface Requirements 33

Payment 

Payment is the process by which the government disburses monies to a contractor in accordance 

with contract terms. As a rule, the government requires receipt of products and services prior to 

making payment. However, there are exceptions to the rule. Advance payments and progress 

payments are methods of contract financing accomplished by specific clauses included in the 

contract. Payments are to be made in an expedient manner, in compliance with prompt payment 

provisions. Other objectives in the payment process are: to ensure that payments are charged to 

the correct obligation; to ensure that the invoice description of items, services, quantities, and 

prices match those of the contract to be charged; to minimize the cost to the government by taking advantage of discounts and purchase card rebates; and to ensure the payment is proper (e.g., 

not a duplicate payment), and that remittance information is complete. Payments require authorization by an authorized approving official and certification by the certifying officer that the 

payment is owed, the invoice is proper, an internal proper match to the receipt and obligation 

documents has been performed, and funds are available for the payment. 

Depending on an agency’s systems architecture, specific activities performed relating to payments may be supported by interfaces with other financial systems that provide transaction data 

to the core financial system. For example, to support the payment process, the receiving function 

can be performed in an acquisition or core financial system. The receiving action provides one 

element of the information needed for proper matching performed by the finance office when an 

invoice arrives and is certified for payment by a designated official. Once payments are made, 

payment history and other funds status information must be made available to program, acquisition, budget, and finance offices. More elaborate systems may accept electronic invoices, and 

allow receipt and acceptance indications to be sent to the payment management function electronically. 

Payment Process Flow (see Illustration 8)

Generally, but not always, the payment process for acquisitions begins when the contractor delivers products or performs services, and ends upon the disbursement of funds to the contractor. 

Designated approving officials receive and accept the products or services ordered and provide 

information necessary, such as receiving and acceptance reports, to support the contract management and finance functions. The contractor submits to the government an invoice, voucher, or 

financing payment request in accordance with contract terms and conditions. It is then forwarded 

to the designated approving official who determines whether it is proper and instructs finance on 

the payment amount. In the event of a disputed invoice, the contracting officer must be involved 

in the resolution of the dispute. Finance also verifies the availability of funds, and the designated 

approving official approves the payment request based on satisfactory evidence of acceptance 

and compliance with contract terms. The disbursing office, after funds certification, then remits 

the funds to the contractor. Finance also provides payment-related information to designated officials in the program and contracting offices. 

The process flow diagram of payment for procurements is shown in Illustration 8. 
Payment

34 Acquisition/Financial Systems Interface Requirements 

Payment Process Flow 

Procurements - Acquisition/Finance Cross-Functional Interface

Contracting Finance* Contractor Disbursing Designated

 Official

Verifies funds

availability

Makes payment to

contractor in

accordance with

payment instructions

Submits invoice,

voucher, or financing

payment request

Approves (modifies/

disapproves as

appropriate) payment

request based on

satisfactory evidence of

payment request/

acceptance,

compliance with

contract terms

Evaluates payment

request, and instructs

on payment amount

Acknowledge receipt/

acceptance of products/

services

Receives payment

request/determines if

proper

Certifies funds for

payment

Finance

Payment

Delivers products/

 performs services

Resolves issues with

payment request

If ok

If questioned

Illustration 8 

Procurements Using the Purchase Card for Payment 

Some agencies authorize contracting officers and other authorized individuals to cite a purchase 

card account number for payment purposes on contract and PO award documents valued greater 

than $2,500.10 A specific individual is selected and trained to be a cardholder and delegated purchase authority; if their authority exceeds $2,500, they are given a Certificate of Appointment, 

commonly known as a warrant. 

Procurements valued greater than $2,500, that use the purchase card solely as a method of payment, are almost always documented through a written contract or order. Consequently, the information requirements for obligation, payment and closeout are, with few exceptions, the same 

as those required by procurements. A notable difference is the contractor (i.e., vendor providing 

products or services) is not paid directly, but through a third party financial institution who pays 

the contractor and bills the government. 

 

10 The current threshold for micropurchases is $2,500, per USC Title IV, Section 4302 of the Federal Acquisition 

Streamlining Act of 1994. 
Payment 

Acquisition/Financial Systems Interface Requirements 35

Mandatory Requirements for Payment 

1) To support the payment process, the agency’s single integrated financial management system 

must provide the following capability related to the contractor: 

♦ Access the contractor’s nine digit, numeric TIN and DUNS identification. 

♦ Provide an indicator (e.g., Y/N) as to whether payments to the contractor are exempt 

from EFT. 

♦ Access the following information related to an EFT payment 

3⁄4 contract number and all associated delivery order numbers or task order numbers (including modification number, if any); PO number (including modification number, if 

any); BPA number and all associated BPA call numbers (including modification 

number, if any); name and remittance address; 

3⁄4 signature, title, and telephone number of the contractor official authorized to provide 

EFT information; 

3⁄4 name, address, and nine-digit routing and transit number (RTN) of the contractor’s financial agent; 

3⁄4 contractor’s account number and type of account (checking, savings, or lockbox); 

3⁄4 the Fedwire Transfer System telegraphic abbreviation of the contractor’s financial 

agent; and 

3⁄4 the name, address, telegraphic abbreviation, and nine-digit RTN of the financial institution receiving the wire transfer payment if the contractor’s financial agent is not 

connected directly to the Fedwire Transfer System online. 

2) To support the payment process, the agency’s single integrated financial management system 

must provide the following capability related to the contract: 

♦ Access the following information related to the contract, captured at obligation 

3⁄4 contract number and all associated delivery order numbers or task order numbers (including modification number, if any); PO number (including modification number, if 

any); BPA number and all associated BPA call numbers (including modification 

number, if any); 

3⁄4 award date; 

3⁄4 obligating document number (if different from contract number); 

3⁄4 contractor name and address, including any previous company name(s) used for the 

particular contract; 
Payment

36 Acquisition/Financial Systems Interface Requirements 

3⁄4 contract administration office; 

3⁄4 payment office; 

3⁄4 product or service description; 

3⁄4 unit of measure; 

3⁄4 unit price; 

3⁄4 extended price; 

3⁄4 quantity; 

3⁄4 payment terms and conditions (e.g., discount terms, applicable payment clauses, 

withhold indicator, withhold percentage, etc.); 

3⁄4 payment type (e.g., advance pay, progress pay, or partial pay); 

3⁄4 accounting information; 

3⁄4 names of government-designated receiving, certifying, and acceptance officials; 

3⁄4 variance amount or percentage allowed; and 

3⁄4 total amount. 

♦ Provide access to a protest decision that resulted in the award of costs. 

♦ Access the specified duration of land rights acquired. 

♦ Access any restrictions on the use or convertibility of general property, plant and equipment (PP&E) acquired, e.g., land donated to an agency for its use with the provision that 

if the agency ceases operations at that location, the land would revert back to the donor. 

♦ Provide access to the following required information associated with the payment for 

PP&E acquired under lease 

3⁄4 lease agreement and terms; 

3⁄4 amount of lease; and 

3⁄4 discount rate (if a lease). 

♦ Access the costs and asset identifier(s) associated with the cleanup of PP&E. 

♦ Access the asset identifier and/or project/program code and asset category (e.g., national 

defense assets, multi-use heritage assets, and investments in non-Federal property) associated with the payment. 
Payment 

Acquisition/Financial Systems Interface Requirements 37

♦ Access the following information associated with acquisitions related to software development 

3⁄4 total acquisition costs by line item description of phase (e.g., completion of conceptual formulation, design, and testing); 

3⁄4 transaction purpose (e.g., acquisition, data conversion, or repair); 

3⁄4 asset identifier or associated project/program; and 

3⁄4 elements of products and services acquired, e.g., training, licenses, and manuals. 

♦ Access assignment of claim information, as in the case of a bankruptcy or court ordered 

restructuring, to ensure payment is made in accordance with the assignment. 

♦ Access the contract terms regarding delivery or constructive delivery. 

♦ Access the advance/prepayment terms associated with a contract financing agreement. 

3) To support the payment process, the agency’s single integrated financial management system 

must provide the following capability related to the payment request: 

♦ Provide access to the bill, invoice, or written request for payment. 

♦ Access the following proper invoice11 information 

3⁄4 name and address of contractor; 

3⁄4 contract number and all associated delivery order numbers or task order numbers (including modification number, if any); PO number (including modification number, if 

any); BPA number and all associated BPA call numbers (including modification 

number, if any); 

3⁄4 description of products or services for each item; 

3⁄4 quantity for each item; 

3⁄4 unit of measure for each item; 

3⁄4 unit price for each item; 

3⁄4 extended price for each item; 

3⁄4 total invoice amount; 

3⁄4 shipping terms; 

 

11 See glossary. 
Payment

38 Acquisition/Financial Systems Interface Requirements 

3⁄4 payment terms; 

3⁄4 name and address of contractor official to whom payment is to be sent; 

3⁄4 name, title, phone number, and mailing address of person to notify if invoice is defective; 

3⁄4 invoice date; 

3⁄4 invoice receipt date; 

3⁄4 proper invoice date; 

3⁄4 proper invoice receipt date; 

3⁄4 transportation costs; 

3⁄4 prompt payment terms; 

3⁄4 vendor invoice number; and 

3⁄4 proper invoice acceptance date. 

♦ Provide an indicator to mark whether an invoice has been paid (including Treasury 

schedule and trace number). 

♦ Access the estimated cost of work completed by a contractor for facilities or equipment 

constructed or manufactured by contractors in accordance with contract specifications. 

4) To support the payment process, the agency’s single integrated financial management system 

must provide the following capability related to receipt: 

♦ Access the following information from the receiving report 

3⁄4 contract number and all associated delivery order numbers or task order numbers (including modification number, if any); PO number (including modification number, if 

any); BPA number and all associated BPA call numbers (including modification 

number, if any); 

3⁄4 description of products delivered or services performed; 

3⁄4 quantity of items delivered; 

3⁄4 unit of measure; 

3⁄4 date products delivered, or dates from/to services performed; 

3⁄4 date products received; and 
Payment 

Acquisition/Financial Systems Interface Requirements 39

3⁄4 signature, printed name, phone number, and mailing address of receiving official. 

5) To support the payment process, the agency’s single integrated financial management system 

must provide the following capability related to acceptance: 

♦ Access the following acceptance information 

3⁄4 contract number and all associated delivery order numbers or task order numbers (including modification number, if any); PO number (including modification number, if 

any); BPA number and all associated BPA call numbers (including modification 

number, if any); 

3⁄4 product or service description; 

3⁄4 unit of measure; 

3⁄4 delivery/performance schedule; 

3⁄4 quantities accepted; 

3⁄4 quantity rejected; 

3⁄4 date rejected (returned); 

3⁄4 date products delivered or dates from/to services performed; 

3⁄4 receipt date; 

3⁄4 acceptance of products and services date; 

3⁄4 progress payment approval date; 

3⁄4 signature (or electronic alternative) of acceptance official; 

3⁄4 name, title, phone number, and mailing address of acceptance official; and 

3⁄4 interest calculation date in accordance with Title 5, Part 1315 of the Code of Federal 

Regulations (CFR). 

♦ Access the following information associated with final acceptance at closeout relative to 

final payment 

3⁄4 date of acceptance; 

3⁄4 evidence of performance (e.g., receiving report approved by designated official); and 

3⁄4 receipt of products and services. 

♦ Provide notification that receipt and acceptance of products/services has occurred, title 
Payment

40 Acquisition/Financial Systems Interface Requirements 

has passed, terms of the contract have been met, or progress under the contract has been 

made for a contract financing payment. 

♦ Access the acquisition cost of each item and the proper accounting classification. 

♦ Provide evidence of performance indicator if payment was made prior to performance in 

accordance with the fast or advance payment clause. 

♦ Provide access to information on the history of contractor deficiencies to determine if fast 

pay abuse exists. 

6) To support the payment process, the agency’s single integrated financial management system 

must provide the following capability related to the payment: 

♦ Access the contract number and all associated delivery order numbers or task order numbers (including modification number, if any); PO number (including modification number, if any); BPA number and all associated BPA call numbers (including modification 

number, if any); 

3⁄4 contractor invoice number; 

3⁄4 total invoice amount; and 

3⁄4 name and address of contractor official to whom payment is to be sent. 

♦ Access the name, signature, and phone number of financial approving and certifying officers for a voucher. 

♦ Access the appropriation or fund symbol for each voucher. 

♦ Provide partial payment indicator. 

♦ Provide the ability to recognize, for an invoice, that supplies or services have been received and accepted. 

♦ Provide the ability to make payment without an invoice based on the contract schedule of 

payment. 

♦ Access the following information associated with the payment of an asset 

3⁄4 asset identifier code(s); 

3⁄4 total asset or improvement costs, broken out by land or structures/buildings (if possible and significant); 

3⁄4 category of PP&E (e.g., heritage assets, multi-use assets, general PP&E, stewardship); and 
Payment 

Acquisition/Financial Systems Interface Requirements 41

3⁄4 quantity. 

♦ Provide the capability to flag payments for accelerated/special processing. 

♦ Identify project(s) associated with a payment. 

♦ Match receipt, acceptance and payment to funding source(s) in accordance with contract. 

♦ Provide the total amount paid and the amount of funds remaining for each contract, delivery order, task order, and BPA call. 

♦ Verify the contracting officer’s approval, including amount and accounting information, 

for a performance-based payment. 

♦ Permit progress payments in the amount approved by the contracting officer. 

♦ Permit payment without evidence of performance (for contract financing, including advance payments and commercial contract financing). 

♦ Provide an indicator (e.g., Y/N) as to whether the payment is for a commercial purchase 

card issuer. 

♦ Permit payment to commercial purchase card issuers prior to evidence of receipt or 

performance. 

♦ Provide an indicator (e.g., Y/N) as to whether the associated contract has a fast payment 

clause. If yes, the contractor’s invoice triggers payment. 

♦ Access the following information for intragovernmental payment and collection (IPAC) 

transactions 

3⁄4 ALC contact; 

3⁄4 contact telephone number; 

3⁄4 contact email address; 

3⁄4 originating ALC; 

3⁄4 customer ALC; 

3⁄4 amount; 

3⁄4 obligating document number; 

3⁄4 PO number; 

3⁄4 invoice number; 
Payment

42 Acquisition/Financial Systems Interface Requirements 

3⁄4 pay flag; 

3⁄4 quantity; 

3⁄4 unit price; 

3⁄4 unit of issue; 

3⁄4 sender Treasury account symbol (e.g., appropriation); and 

3⁄4 receiver department code. 

♦ Access the following information for IPAC adjustment transactions 

3⁄4 ALC contact; 

3⁄4 contact telephone number; 

3⁄4 contact email address; 

3⁄4 originating ALC; 

3⁄4 customer ALC; 

3⁄4 amount; 

3⁄4 original IPAC document reference number; 

3⁄4 original date accomplished; and 

3⁄4 original accounting date. 

♦ Access the following information for IPAC zero-dollar transactions 

3⁄4 ALC contact; 

3⁄4 contact telephone number; 

3⁄4 contact email address; 

3⁄4 originating ALC; and 

3⁄4 customer ALC. 

♦ Provide access to the following information for purchase card payments: 

3⁄4 card number; 

3⁄4 accounting data associated with card number; 
Payment 

Acquisition/Financial Systems Interface Requirements 43

3⁄4 FY; 

3⁄4 appropriation/Treasury fund symbol; 

3⁄4 organization code; 

3⁄4 cost center; 

3⁄4 object class; 

3⁄4 project code; 

3⁄4 program code; and 

3⁄4 individual name/office name of cardholder. 

7) To support the payment process, the agency’s single integrated financial management system 

must provide the following process controls: 

♦ Support the following pre-audit verifications 

3⁄4 contract number is valid, and payee name is correct; 

3⁄4 required administrative authorizations for the procurement and approvals for payment 

were obtained (names, titles, and phone numbers); 

3⁄4 TIN or payee ID number provided; 

3⁄4 payment is not a duplicate payment; 

3⁄4 delivered items or services are in accordance with the contract (quantities, prices, and 

amounts); 

3⁄4 payment amount is in accordance with the contract (including any adjustments); 

3⁄4 payment tracking control number, i.e., the number that links the invoice to the government payment; 

3⁄4 description of items and services, quantity, and price on the invoice match the same 

elements in the contract to ensure that the correct contract/order number has been 

cited by the vendor, the correct obligation charged, and only contracted items/services 

and quantities are paid for; 

3⁄4 cost effective discounts have been taken; 

3⁄4 all applicable deductions were made and credited to the proper account in the correct 

amount; 
Payment

44 Acquisition/Financial Systems Interface Requirements 

3⁄4 receipt, acceptance and payment are matched to funding source(s) in accordance with 

the contract; and 

3⁄4 financing payments have been properly liquidated against delivery payments. 

♦ Verify that the appropriate government officials have signed the appropriate form authorizing payment. 

♦ Verify funds availability before making payment. 

♦ Verify that electronic payments are within the maximum amount specified in the Treasury Financial Manual (TFM).12

Value-Added Requirements for Payment 

To support the payment process, the agency’s single integrated financial management system 

should provide the following capability: 

♦ Capture vendor information required when registering with the CCR and track activity by 

CCR identifier (will become mandatory upon issuance of governmentwide implementing 

standard requirements). 

♦ Provide an indicator (e.g., Y/N) as to whether the contractor is registered through the 

CCR (will become mandatory upon issuance of governmentwide implementing standard 

requirements). 

♦ Provide an indicator (e.g., Y/N) as to whether the contractor is exempt from registering 

through the CCR (will become mandatory upon issuance of governmentwide implementing standard requirements). 

♦ Provide the ability to produce aged accounts payable information. 

♦ Provide the ability to cross-reference contract numbers and related interagency agreements. 

♦ Access the following optional data elements of the contract 

3⁄4 line item number; and 

3⁄4 estimated completion date. 

♦ Access the contract payment method (e.g., payment to be made by purchase card or other 

noninvoice means, or payment to be made by invoice) which triggers a rejection of any 

invoice, if the payment method specified by the invoicediffers from that allowed for in 

the contract. 

 

12 I TFM 4-2000. 
Payment 

Acquisition/Financial Systems Interface Requirements 45

♦ Access the names of individual(s) who must approve the invoice before payment can be 

made. 

♦ Allow contracting staff to determine whether a contractor is a first-time contractor or 

abuser of fast pay (so that contracting can determine whether or not to include a fast pay 

clause). 

♦ Enable electronic receiving report processing, submission of invoices, approval and signatures, and notification alerts for pending actions. 

♦ Provide the ability to compare the electronic invoice data elements (contract/order 

number, description of items or services, quantity, and price) to the contract data and 

advise of “match” or “no match.” 

♦ Provide the ability to “forward” or make available the invoice data to others outside the 

finance office (receiving and accepting personnel, contracting office personnel) for receipt and acceptance sign-offs on-line. 

♦ Record or recognize if invoiced quantities exceed, match or are less than contract quantities, and keep track of quantities yet to be invoiced/received. 

The final interface process, closeout, is discussed in the next section. 
(LEFT BLANK INTENTIONALLY) 
 

Acquisition/Financial Systems Interface Requirements 47

Closeout 

Closeout is the process by which a Federal agency determines that a contract has been physically 

completed and all applicable administrative actions, including final payment or recovery of 

overpayment, have been accomplished. Contracts are considered to be physically completed 

when: 

♦ The contractor has completed required deliveries followed by government inspection and 

acceptance; all contractor services have been performed and accepted by the government; 

and existing option provisions have expired; or 

♦ The government has issued a notice of complete contract termination. 

Normally, once the contract is physically complete and final payment has been made, the contract administration office initiates administrative closeout of contract files. At this point, the 

contract administration office begins the process of reviewing the contract funds status. As part 

of this process, the contract administration office may, as appropriate, notify the contracting officer that: 

♦ No additional actions are required by the contractor or government, 

♦ A potential availability of excess funds for de-obligation exists, or 

♦ Recoupment actions may be necessary before the contract files can be closed. 

The timeframe for completing the closeout process varies by contract type; however, quick 

closeout procedures, as defined in the FAR 42-708, “Quick-Closeout Procedures,” should be 

used when appropriate. Contracts in the process of litigation or termination cannot be closed and 

some contracts may require receipt of a contractor’s release of claims before they may be closed. 

Closeout Process Flow (see Illustration 9) 

The closeout process begins with the contractor’s delivery of final products or services and subsequent submission of a final or completion invoice. The designated official reviews the completion invoice to establish that it is proper in all respects for payment, and records final acceptance. 

Should recoupment of overpayments be needed, the contracting officer conducts necessary negotiations to secure the return of identified funds. Finance receives the approved final/completion 

invoice, verifies funds availability, posts payment of the invoice, and notifies both the contracting officer and disbursing of this action. Disbursing makes the final payment to the contractor. 

The contracting officer effects the actions to perform administrative closeout. 

The process flow diagram of closeout for procurements is shown in Illustration 9. 
Closeout 

48 Acquisition/Financial Systems Interface Requirements 

Closeout Process Flow 

Procurements - Acquisition/Finance Cross-Functional Interface Closeout

Contracting Finance Contractor Disbursing Designated

 Official

Delivers final products/

performs final services

Acknowledge receipt/

acceptance of

products/services

Posts payment of final/

completion invoice/

liquidates accrual/posts

de-obligation/retains

financial record

Receives notice of final

payment/acceptance/

deobligation

Submits final/

completion invoice/

payment request

 Receives approved

final/completion

invoice/payment

request

Verifies funds

availability

 Performs administrative

closeout (including any

contract modifications)/

completion and retains

records

Receives payment

request/determines if

proper/records final

acceptance

Negotiates

adjustments, including

recoupment, and

modifies contract as

appropriate Recoups funds

Makes final

payment to

contractor

Illustration 9 

Mandatory Requirements for Closeout 

To support the closeout process, the agency’s single integrated financial management system 

must provide the following capability: 

♦ Provide a receiving report containing a final indicator, with acceptance acknowledged by 

a designated agency official including 

3⁄4 contract number and all associated delivery order numbers or task order numbers (including modification number, if any); PO number (including modification number, if 

any); BPA number and all associated BPA call numbers (including modification 

number, if any); 

3⁄4 date of receipt; 

3⁄4 date of acceptance; and 

3⁄4 final acceptance indicator. 
Closeout 

Acquisition/Financial Systems Interface Requirements 49

♦ Access or provide evidence that the contractor’s final invoice has been submitted. 

♦ Provide evidence that a final invoice payment has taken place with the following 

3⁄4 final payment indicator (including any resolution of contract withholds); 

3⁄4 invoice number; and 

3⁄4 total amount paid. 

♦ Where excess funds have been identified, provide the document number under which the 

funds were obligated, the amount of the de-obligation, and the date of the de-obligation. 

Value-Added Requirement for Closeout 

To support the closeout process, the agency’s single integrated financial management system 

should provide the following capability: 

♦ Provide an accounting document number. 

♦ Enable electronic contracting, obligation of funds, approvals and signatures, and notification alerts for pending actions. 

This and the four preceding sections have focused on procurements. The subsequent section 

deals with micropurchases made with purchase cards where processes and information requirements differ from those previously described for procurements. 
(LEFT BLANK INTENTIONALLY) 
Acquisition/Financial Systems Interface Requirements 51

Micropurchases Made with Purchase Cards 

Introduction 

This section describes information requirements for micropurchases made with purchase cards. 

These simplified transactions follow processes and procedures that differ from those used for 

procurements and thus have unique information requirements from those previously described. 

Pursuant to the Federal Acquisition Streamlining Act of 1994, the FAR, Part 13, “Simplified Acquisition Procedures,” contains the primary guidance for this method of procurement. Robust and 

properly controlled purchase card programs reduce the administrative lead time for procurements; streamline financial and purchasing processes; enable more efficient business processes; 

and streamline post-certification reviews by approving or certifying officials. 

Some of the more significant objectives and benefits of these programs are to 

♦ Gain cost efficiencies. 

♦ Improve government operations, particularly accountability and performance reporting. 

♦ Outsource transaction processing and record keeping. 

♦ Provide procedural checks and feedback to improve security and management control on 

financial transactions and processes. 

♦ Improve government cash management practices including compliance with the Prompt 

Payment Act. 

♦ Consolidate payments where possible. 

♦ Reduce/eliminate imprest funds. 

♦ Streamline ordering, procurement, payment and administrative procedures. 

♦ Expedite vendor payment. 

♦ Reduce vendor paperwork. 

♦ Obtain detailed and tailored management reports. 

♦ Follow commercial rules, procedures and best practices. 

♦ Provide convenience to government employees. 

♦ Take advantage of state-of-the-art technology and technological advances. 

Agencies that take advantage of purchase card programs are required to establish procedures for 

use and control of the card that comply with the TFM. 
Micropurchases Made with Purchase Cards 

52 Acquisition/Financial Systems Interface Requirements 

When a government purchase card is used, the merchant providing the products/services to the 

Federal agency is paid by the card-issuing financial institution that provides the card services to 

the government. The government agency reimburses the institution in accordance with the terms 

and conditions of a card services contract and the Prompt Payment Act, as amended.13 

Micropurchases 

The Federal Acquisition Streamlining Act of 1994 created a new procurement category for openmarket purchases and designated such actions as micropurchases. The micropurchase threshold 

is currently $2,500. The FAR implementation of micropurchases encourages the delegation of 

micropurchase authority14 and designates the purchase card as the preferred method for micropurchases.15

A designated official (e.g., a program manager, facility engineer or office manager) recognizes a 

recurring need to acquire low-dollar-value products and/or services. A cardholder account is established with preset spending limits and limitations on the types of commodities and services 

that can be acquired. After completion of micropurchase/purchase card training,16 a purchase 

card is issued to the cardholder. 

Agencies using the governmentwide commercial purchase card must establish procedures for use 

and control of the card that comply with the TFM (TFM Vol. 1 - Part 4 - Chapter 4500), and that 

are consistent with terms and conditions of the GSA Federal Supply Service Contract Guide for 

Governmentwide Commercial Purchase Card Service. 

The GSA Federal Supply Service Contract requires that the card issuing institution provide its 

standard commercial authorization controls and have the ability to void cards or personal identification numbers (PIN’s) at the request of the agency or GSA contracting officer. Different authorization controls may be requested by the agency. These include: default limits; dollars per 

transaction and dollars per month limits; transactions per day and transactions per month limits; 

merchant category code (restricts the types of purchases made by each card/account as set by the 

Agency/Organization Program Coordinator (A/OPC); preferred contractor listing (prohibits purchases at certain merchants); and automatic controls that flag and deny invalid cards (lost, stolen, 

suspended/canceled). Additionally, restrictions are in place to prevent the use of the card for 

♦ Long-term rental or lease of land or buildings. 

♦ Major telecommunications (telephone) services (i.e., FTS2000 or DSN). However, telephone equipment, cellular telephones, pagers, and Internet subscriptions, etc., may be 

purchased unless restricted by an agency. 

 

13 I TFM 4535 - Review and Approval of Billing Statement for Payment 

14 FAR 13.201(a) 

15 FAR 13.201(b) 

16 FAR 13.201(c). 
Micropuchases Made with Purchase Cards 

Acquisition/Financial Systems Interface Requirements 53

♦ Travel or travel-related purposes. All authorizations for merchants that are classified as 

travel subsistence types of businesses shall be denied, unless specifically authorized. The 

types of businesses denied will include airlines, restaurants, bars, hotels, travel agencies, 

and car rental agencies. However, it may be used for travel purposes where the GSA 

travel card is not accepted or under an integrated solution card which includes the travel 

card program. 

♦ Fuel, oil, services, maintenance and repairs for those users of IFMS and the GSA Fleet 

Management Program. However, it may be used for fuel and fleet-related purposes under 

an integrated solution card which includes the fleet card program. 

♦ Cash advances (unless permitted by agency selected value-added option or an integrated 

solution card which includes the travel card program). 

As indicated earlier, there are significant objectives and benefits that Federal agencies derive 

from the use of purchase card programs, especially in the area of process simplification. As such, 

the information requirements that are common to the four processes used in this document for 

procurements are significantly different. 

Illustration 10 provides the high-level process flow for micropurchases made with purchase 

cards. 
Micropurchases Made with Purchase Cards 

54 Acquisition/Financial Systems Interface Requirements 

Micropurchases Made with Purchase Cards Process Flow 

Micropurchases Made with Purchase Cards - Acquisition/Finance Cross-Functional Interface Obligation and Payment Closeout Funds Certification

Finance Card Issuing

Institution Cardholder Merchant A/OPC or

Approving Official

Adds cardholder to the

'system' and issues

card, implements

exception reporting,

and establishes card

usage limitations

A/OPC establishes

cardholder authority and

limits (e.g., commodity

class, monthly volume)

and exception reporting

requirements

Authorizes payment

prior to or after

cardholder review

depending on agency

practice

Accomplishes payment to

card issuing institution,

less returns and

adjustments from previous

periodic billing statement

review

Certifies funds for

payment

Authorization

Receives card

Submits periodic

billing statement for

payment, net of

returns

 (de-obligation)

Determines funds

availability and records

obligation in financial

system

Receives statement of

account from card

issuing institution

Submits current

period's questionable

charges to merchant

for credit

Receives payment

Notifies financial

institution of

accepted

adjustments

Reviews/approves

statement

Applies

adjustment to next

statement and

next invoice

Validates current

charges and prior

month adjustments

Resolves dispute

If merchant disagrees per contract terms

Records

adjustment as part

of next invoice

Submits detailed

periodic transaction

statement to

cardholder

Responsible for

determining that

funds are available

prior to purchase

Submits unresolved

disputes for

resolution per

contract terms

Evaluates

questionable

charge

If merchant agrees

Reviews and acts on

exception reports

Receives products/

services or verifies

delivery to alternative

destination

Makes purchase

Provides products

or services, and

bills card issuing

institution

Generates

exception reports,

as appropriate

Illustration 10 
Micropuchases Made with Purchase Cards 

Acquisition/Financial Systems Interface Requirements 55

Funds Certification 

Cardholders and approving officials are responsible for ensuring that funds are available prior to 

using the purchase card to purchase products and/or services. Beyond that, no specific funds certification requirements exist for purchases with purchase cards. 

Obligation/De-obligation 

Obligations are recorded in bulk or individually in agency financial systems, based on purchases 

completed by cardholders. 

Payment 

The payment process for purchases with purchase cards is highly streamlined. The process begins when the merchant submits invoices for payment. The merchant is reimbursed by its servicing bank which then “clears” the payment through an internal settlement process eventually leading to the final payment transaction between the government agency and the financial institution 

it has selected as its purchase card provider. 

The purchase card provider presents statements/invoices to the agency. The statement/invoice 

may represent the transactions of many cardholders and hundreds of transactions totaling a significant amount. Agencies require cardholders and approving officials to reconcile each individual cardholder’s posted transactions to the statement of account. Some agencies elect to pay the 

invoice before this reconciliation, while other agencies wait and pay the invoice after reconciliation. In both cases, the agency must match the individual cardholder's statement to the financial 

institution statement, and confirm receipt and acceptance of products and services paid for with a 

purchase card. 

The EFT data provided in the obligation and payment information requirements should be for the 

card-issuing financial institution and not the merchant selling the products and/or services. The 

TIN of the merchant is acquired either through the financial institution, the card association, or 

directly from the merchant. 

Closeout

If a discrepancy between the bank statement and supporting documentation is identified, (including evidence of receipt and acceptance) the invalid/disputed charge may be resolved by contacting the merchant and requesting an adjustment/credit. If the merchant does not honor this request, the cardholder or approving official would initiate a dispute under the terms of the applicable contract with the card-issuing financial institution. Unauthorized charges that should be 

blocked by the card issuer, but are not, still need to go through the dispute resolution process. 

Disputed card transactions are closed out when: 

♦ a credit is authorized by the merchant and shown on a subsequent statement of account, 
Micropurchases Made with Purchase Cards 

56 Acquisition/Financial Systems Interface Requirements 

♦ a decision is made by the card-issuing institution against the dispute and a charge back is 

made for the disputed amount against the account and shown on a subsequent invoice and 

statement of account, or 

♦ the cardholder accepts the disputed amount and notifies the card-issuing institution. 

The cardholder or a designated official monitors disputed transactions to ensure that credits are 

received and properly recorded.

The individual purchase action made through a purchase card is closed out when the transaction 

included in the billing statement is accepted. 

Information Requirements for Micropurchases Made with Purchase Cards 

The documents that provide the information requirements for purchases made by purchase cards 

are different from procurements. Micropurchases using a purchase card are typically documented 

through a purchase receipt provided by the merchant, the cardholder’s monthly statement of 

transactions provided by the financial institution, and the periodic billing statement or invoice 

provided to finance by the card-issuing financial institution. The typical purchase card transaction identifies the card number, expiration date, merchant identification, transaction date, and the 

purchase amount. This information is used by the cardholder and/or approving official to establish a purchase/receipt record. 

Information requirements for funds certification, obligation/de-obligation, payment and close-out 

are met from: 

♦ the amount of funds authorized by each account, 

♦ the purchase card transaction, as reflected in the invoice, 

♦ the statements of account, and 

♦ any purchase/receipt log or receiving report required by the agency. 

Agency management controls will also generally require receipts and/or shipping reports. 

Except as discussed above, the information requirements for procurements that solely use the 

purchase card as a method of payment can be derived from the procurement information requirements stated earlier in this document. The information requirements for micropurchases 

made with purchase cards as both a procurement instrument and method of payment are listed 

below.

The agency’s single integrated financial management system must provide the following capability related to micropurchases with purchase cards: 

♦ Access the following information at time of purchase card approval 

3⁄4 card number; 
Micropuchases Made with Purchase Cards 

Acquisition/Financial Systems Interface Requirements 57

3⁄4 FY; 

3⁄4 appropriation/Treasury fund symbol; 

3⁄4 organization code; 

3⁄4 cost center; 

3⁄4 object class; 

3⁄4 project code; 

3⁄4 program code; and 

3⁄4 individual name/office name of cardholder. 

♦ Access the following information at time of invoice/payment recorded by card issuing 

institution 

3⁄4 amount; 

3⁄4 card number; and 

3⁄4 individual name/office of cardholder. 

The following section discusses general systems requirements. 
(LEFT BLANK INTENTIONALLY) 
 

Acquisition/Financial Systems Interface Requirements 59

General Systems Requirements 

This section describes general requirements that apply to all agency core and mixed financial 

management systems, including the financial aspects of acquisition systems, and the shared information requirements and interface processes covered in this document, i.e., funds certification, obligation/de-obligation, payment, and closeout. This section also identifies some of the 

statutes, topics, and more specific statutory requirements that the governmentwide acquisition, 

financial, and other professionals who developed this document identified as extremely important to the organizations, systems, and processes involved. These requirements contribute to an 

agency’s ability to ensure that its single integrated financial management system is designed, implemented, and operated in accordance with existing laws and regulations, and in particular, that 

the systems are operating as intended. 

All components of an agency’s integrated financial management system must provide, at a 

minimum, the following qualities: 

♦ Complete and accurate funds control. 

♦ Complete, accurate, and prompt recording of obligations. 

♦ Complete, accurate, and prompt payment of payment requests. 

♦ Complete, accurate, and prompt generation and maintenance of acquisition/financial records and transactions. 

♦ Timely and efficient access to complete and accurate information, without extraneous 

material, to those internal and external to the agency who require the information. 

♦ Timely and proper sharing of common information between the acquisition and core financial systems, and other mixed systems, e.g., property management systems. 

♦ Adequate management controls, including internal and security controls, policies, and 

procedures intended to protect the agency’s key systems, data, and interfaces from disruption and unauthorized access or alteration, as prescribed in a variety of statutes and 

regulations, including, but not limited to, OMB Circulars A-123 and A-130. 

Agencies must also develop strategies for interfacing or integrating other systems with the core 

financial system. As Illustration 3 in this document shows, the core financial system provides the 

fundamental or “backbone” capabilities to support the interfaces with all of the component 

mixed systems, which taken together form an agency’s systems architecture for the single integrated financial management system. 

The JFMIP Core Financial System Requirements document highlights additional general qualities of the single integrated financial management system that must be supported relative to the 

sharing of information and processes between and among the core financial system, acquisition 

system, and other mixed systems. The following qualities vary in specificity: 
General Systems Requirements 

60 Acquisition/Financial Systems Interface Requirements 

♦ To facilitate the reconciliation of information that is common to the core financial management system and to one or more of the financial mixed systems (e.g., acquisition systems and property management systems) described in the JFMIP Framework document 

and other JFMIP requirements documents, the single integrated financial management 

system must provide for: 

3⁄4 multiple levels of system access, transaction authorization, and approval authority; 

3⁄4 single source data entry; 

3⁄4 validation of funds availability prior to scheduling payment; 

3⁄4 communication of the need for additional funds; 

3⁄4 simultaneous posting of budgetary and proprietary accounts; 

3⁄4 prepayment examinations from diverse locations; 

3⁄4 controls to ensure transaction processing in proper chronological/numeric sequence; 

and 

3⁄4 standard edits for shared data. 

♦ Provide audit trails to trace transactions from source documents, original input, other systems, and system-generated transactions. 

♦ Provide transaction details to support account balances. 

♦ Provide the capability to relate data elements to each other as discussed, through an integrated data query facility that supports ad hoc query access to financial information described in the document and also provides data analysis reporting tools. 

Technical Requirements

Some level of technical requirements is included in all JFMIP functional requirements documents, and especially in the Framework for Federal Financial Management Systems and Core 

Financial System Requirements documents. As indicated elsewhere in this document, financial 

aspects of mixed systems, such as acquisition systems, are part of an agency’s single integrated 

financial management system. As such, mixed systems are subject to the technical requirements 

contained in the Framework document and to those aspects of the Core document that apply in 

particular cases to particular agencies. Agencies must consult these and other documents in determining appropriate technical requirements for a specific agency operating environment. Requirements contained in the Core document, including technical requirements are categorized as 

mandatory or value-added. Mandatory requirements are used to develop scenarios for testing 

commercial core software packages. Most technical requirements are stated in general terms to 

allow vendors maximum flexibility in designing compliant systems. Individual agencies must 

identify and test agency functional requirements. All agencies must perform acceptance and in-
General Systems Requirements 

Acquisition/Financial Systems Interface Requirements 61

dependent verification and validation (IV&V) to ensure a system meets performance requirements and integrates within the agency’s specific IT environment. 

Security and Internal Controls

With regard to security and internal controls, the system must: 

♦ Provide flexible security facilities to control user access at varying degrees including: 

overall system access, capability to perform specific functions (inquiry, update), and access to certain functionality. 

♦ Provide capability to define access to specific functions by user name, class of user, and 

position. 

♦ Provide for multiple levels of approvals based on user-defined criteria, including dollar 

limits, type of document processed, etc. 

♦ Provide the capability to perform: reconciliation routines for internal participant accounts, ledgers, and funds; and to identify unsuccessful reconciliations via error log or error report 

♦ Establish appropriate administrative, technical and physical safeguards to ensure the security and confidentiality of records and to protect against anticipated threats or hazards 

to record security or integrity which could result in substantial harm, embarrassment, 

inconvenience, or unfairness to any individual on whom information is maintained 

♦ Provide a mechanism to monitor changes to software coding and the responsible individual (authorized user) 

Contract Financial Status Reporting 

During the development of this document, acquisition, financial, and other professionals from 

across Federal government deemed the shared information requirements relative to contract 

payment history such an important item, that it was necessary to address this subject separately. 

Accordingly, the following information, relative to contract payment history, should be noted 

with regard to the shared information requirements of the acquisition and core financial systems, 

functions, and processes. 

Timely information about contract amounts (whether they are obligated, obligated and expended, 

modified, or amended) is vital to program managers, financial managers and acquisition managers. Some contracts, or orders under contracts, span several fiscal years, yet the need to summarize contract amounts against a particular contract remains. Therefore, to support the overall 

management of contracts, the agency’s single integrated financial management system must

have the ability to report on contract funding and payment by: (1) contract number and all associated delivery order or task order numbers, (2) PO number, and (3) BPA number and all associated BPA call numbers. 
General Systems Requirements 

62 Acquisition/Financial Systems Interface Requirements 

In order to produce these reports: (1) all delivery order or task order numbers must be associated 

with a contract number, (2) all BPA call numbers must be associated with a BPA number, and 

(3) modification numbers applicable to contract numbers, delivery or task order numbers, BPA 

or BPA call numbers, and PO numbers must be associated with the modified document. 

The next section provides information on the retention of records. 
 

Acquisition/Financial Systems Interface Requirements 63

Records Retention 

Agency systems must maintain, store, and permit ready retrieval of financial information. The 

time frames for various parts of this requirement differ depending on the subject matter. The single integrated financial management system must be sufficiently flexible to retain and purge information consistent with varying record keeping requirements. The National Archives and Records Administration (NARA) must approve the destruction of records created within the Federal 

government per 36 C.F.R 1228. General Records Schedule 7, Expenditure Accounting Records, 

and General Records Schedule 20, Electronic Records, are the current authorities for disposal of 

Expenditure Accounting Records. (Copies may be obtained from an agency’s records officer or 

from NARA.) For expenditure records not covered by this authority, or for any questions regarding the disposition of Federal records, please contact: 

National Archives and Records Administration (NARA) 

7th Street and Pennsylvania Avenue NW 

Washington, DC 20408 
(LEFT BLANK INTENTIONALLY) 
 

Acquisition/Financial Systems Interface Requirements 65

Appendix A: References/Authoritative Sources 

Laws 

♦ PL 93-344, Anti-Deficiency Act of 1974 

♦ PL 97-177, Prompt Payment Act of 1982 

♦ PL 97-255, Federal Managers’ Financial Integrity Act (FMFIA) of 1982 

♦ PL 100-235, Computer Security Act of 1987 

♦ PL 101-576, Chief Financial Officers (CFO) Act of 1990 

♦ PL 103-62, Government Performance and Results Act (GPRA) of 1993 

♦ PL 103-355, Federal Acquisition Streamlining Act of 1994, as amended 

♦ PL 103-356, Government Management Reform Act (GMRA) of 1994, as amended 

♦ PL 104-13, Paperwork Reduction Act of 1995 

♦ PL 104-106, National Defense Authorization Act for Fiscal Year 1996 

♦ PL 104-106, Division E, Information Technology Management Reform Act (ITMRA) of 

1996, as amended (AKA Clinger-Cohen Act of 1996) 

♦ PL 104-134, Debt Collection Improvement Act of 1996 

♦ PL 104-134, Omnibus Consolidated Rescissions and Appropriations Act of 1996, as 

amended 

♦ PL 104-208, Federal Financial Management Improvement Act (FFMIA) of 1996 

♦ PL 105-277, Title XVII, Government Paperwork Elimination Act (GPEA) 

♦ PL 106-229, Electronic Signatures in Global and National Commerce Act 

♦ PL 106-398, National Defense Authorization Act for Fiscal Year 2001 

♦ Economy Act (FAR 17.502, 17.503, 17.504) 

United States Code 

♦ 26 USC 6041, Information at Source 

♦ 26 USC 6050M, Returns relating to persons receiving contracts from Federal executive 

agencies 
Appendix A: References/Authoritative Sources 

66 Acquisition/Financial Systems Interface Requirements 

♦ 26 USC 6941A, Returns regarding payments of remuneration for services and direct sales 

♦ 31 USC 1341, Money and Finance—Limitations on expending and obligating amounts 

♦ 31 USC 1501, Money and Finance—Documentary evidence requirement for government 

obligations 

♦ 31 USC 1517, Money and Finance —Prohibited obligations and expenditures 

♦ 31 USC 1535, Money and Finance—Agency agreements 

♦ 31 USC 1553, Money and Finance —Availability of appropriation accounts to pay obligations 

♦ 31 USC 3325, Money and Finance—Vouchers 

♦ 31 USC 3332, Money and Finance—Required direct deposit 

♦ 31 USC 3901-3908, Money and Finance—Prompt payment 

♦ 31 USC 7701, Money and Finance—Taxpayer identifying number 

♦ 41 USC 11, Public Contracts—No contracts or purchases unless authorized or under adequate appropriation; report to the Congress 

♦ 44 USC 3504, Coordination of Federal Information Policy—Authority and functions of 

Director 

Office of Management and Budget Documents 

♦ OMB Bulletin 97-01, Form and Content of Agency Financial Statements 

♦ OMB Circular A-11, Overview of the Budget Process 

♦ OMB Circular A-34, Instructions on Budget Execution 

♦ OMB Circular A-123, Management Accountability and Control 

♦ OMB Circular A-127, Financial Management Systems, including Transmittal Memorandum No. 2 

♦ OMB Circular A-130, Management of Federal Information Resources 

Regulations 

♦ Federal Acquisition Regulation 
Appendix A: References/Authoritative Sources 

Acquisition/Financial Systems Interface Requirements 67

Code of Federal Regulations 

♦ 5 CFR, Administrative Personnel 

♦ 5 CFR, Part 1315, Prompt Payment 

♦ 26 CFR, Internal Revenue 

♦ 31 CFR, Money and Finance: Treasury 

Treasury Financial Manual 

♦ TFM Announcement A 2001-02 (FAST Book) 

♦ TFM Release S2-01-02 (FACTS I & FACTS II Reporting) 

♦ TFM SGL Section V 

♦ I TFM 2-1500, Description of Accounts Relating to Financial Operations (T/L 598) 

♦ I TFM 2-4000, Federal Agencies’ Centralized Trial-Balance System (FACTS I) (T/L 

593) 

♦ I TFM 4-2000, Payment Issue Disbursing Procedures 

♦ I TFM 4-4535.10, Government Purchase Cards, Payments 

♦ I TFM 6-5000, Administrative Accounting Systems Requirements in Support of the Debt 

Collection Improvement Act of 1996 

Joint Financial Management Improvement Program Documents 

♦ JFMIP Core Financial System Requirements (SR-02-01) 

♦ JFMIP Framework for Federal Financial Management Systems (FFMSR-0) 

♦ JFMIP Inventory System Requirements (FFMSR-7) 

♦ JFMIP Property Management Systems Requirements (SR-00-4) 

♦ JFMIP Seized Property and Forfeited Assets Systems Requirements (SR-99-4) 

Accounting Standards 

♦ SFFAS 3, Accounting for Inventory and Related Property 

♦ SFFAS 4, Managerial Cost Accounting Concepts and Standards 
Appendix A: References/Authoritative Sources 

68 Acquisition/Financial Systems Interface Requirements 

♦ SFFAS 5, Accounting for Liabilities of the Federal Government 

♦ SFFAS 6, Accounting for Property, Plant and Equipment 

♦ SFFAS 7, Accounting for Revenue and Other Financing Sources 

♦ SFFAS 8, Supplementary Stewardship Reporting 

♦ SFFAS 10, Accounting for Internal Use Software 

♦ SFFAS 11, Amendments to Accounting for PP&E: Definitions (amends SFFAS 6 and 8) 

♦ SFFAS 16, Amendments to Accounting for PP&E: Multi-use Heritage Assets (amends 

SFFAS 6 and 8) 

Additional Cross-Reference Information 

♦ Statutory, regulatory, accounting standards, and other guidance used as a basis for identifying the information requirements and capabilities discussed in this document is available on the JFMIP website (JFMIP.gov) entitled “Mandatory Requirements Sources Matrix for Acquisition/Financial Systems Interface Requirements,” and located at 

http://www.jfmip.gov/jfmip/download/documents/acquisition_systems_requirements_ma

ndatory_requirements_sources_matrix.doc . 
 

Acquisition/Financial Systems Interface Requirements 69

Appendix B: Glossary 

Term Definition Source17

 

Acceptance Also referred to as acceptance of work. The act of an authorized 

representative of the government by which the government, for 

itself or as agent of another, assumes ownership of existing identified supplies tendered or approves specific services rendered as 

partial or complete performance of the contract. 

Federal Acquisition 

Institute (FAI) 

Glossary of 

Acquisition 

Terms

 

Accounting 

Classification 

A subset of the agency financial information classification. The 

accounting classification structure provides a 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 U.S.SGL, data aggregation requirements for 

preparation of financial statements under the CFO Act, appropriation structure, and other reporting and management needs of 

the agency. 

JFMIP Core 

Financial System Requirements 

 

Acquisition Acquiring by contract of supplies or services (including construction) by and for the use of the Federal government through 

purchase or lease, whether the supplies or services are already in 

existence or must be created, developed, demonstrated, and 

evaluated. Acquisition begins at the point when agency needs 

are established and includes: 

3⁄4 the description of requirements to satisfy agency needs, 

3⁄4 solicitation and selection of sources, 

3⁄4 award of contracts, 

3⁄4 contract financing, 

3⁄4 contract performance, 

3⁄4 contract administration, and 

3⁄4 those technical and management functions directly related to 

the process of fulfilling agency needs by contract. 

FAR 2.101 as 

modified by 

Team 

 

Acquisition 

Cost 

Total costs paid to acquire products and services. For assets, this 

includes all costs incurred to acquire the assets and bring them to 

the form and location suitable for their intended use. Maintenance costs are excluded from this definition. 

 

17 Sources are provided if available, otherwise the term definition was developed for clarification of terminology. 
Appendix B: Glossary 

70 Acquisition/Financial Systems Interface Requirements 

 

Acquisition/ 

Financial Interface 

The points during the acquisition and financial management 

processes where: 

3⁄4 the financial community (budget, accounting/finance, and 

disbursing) interfaces with the program/contracting function 

in order to obtain information needed to accomplish its functional requirements (including core financial system general 

ledger management, funds management, payment management, receipt management, cost management, and reporting). 

See JFMIP Core Financial Systems Requirements document. 

3⁄4 the Acquisition community (receiving, program, and contracting) interfaces with the budget/finance function in order 

to fulfill an information need, accomplish a necessary functional process, or conduct internal control activities. 

 

Acquisition 

System 

All agency resources committed to the acquisition process, including, but not limited to, human resources, information hardware and software systems, acquisition process documentation, 

as well as applicable regulations, policies, procedures and 

agency-implementing guidance and instruction. 

 

Action Code Identifies whether the transaction is a new action or a modification of an existing record. JFMIP Seized 

Property and 

Forfeited Assets Systems 

Requirements

 

Advance/ 

Advance 

Payments 

Advances of money by the government to a prime contractor 

before, in anticipation of, and for the purpose of complete performance under one or more contracts. They are expected to be 

liquidated from payments due to the contractor incident to performance of the contract. Since they are not measured by performance, they differ from partial, progress, or other payments 

based on the performance or partial performance of a contract. 

Advance payments may be made to prime contractors for the 

purpose of making advances to subcontractors. 

FAI Glossary 

of Acquisition 

Terms

 

Agency Location Code A numeric symbol used to identify accounting reports and 

documents prepared by or for agency accounting stations and 

disbursing offices, e.g., eight-digit agency accounting station 

code, four-digit disbursing office symbol, and three-digit Treasury disbursing center symbol (I TFM 2-3315 and 3320). 

I TFM, 5-

1030 

 
Appendix B: Glossary 

Acquisition/Financial Systems Interface Requirements 71

Agency/Organi

zation Program 

Coordinator 

An individual that may be designated by the ordering 

agency/organization to perform task order contract administration within the limits of delegated authority and to manage the 

card program for the agency/organization. This individual shall 

have overall responsibility for the card program within their 

agency/organization and may determine who participates in the 

card program. 

1998 GSA 

SmartPay 

Master Contract 

 

Agency Single 

Integrated 

Financial 

Management 

System 

A unified set of financial systems and the financial portions of 

mixed systems (e.g., acquisition) encompassing the software, 

hardware, personnel, processes (manual and automated), procedures, controls, and data necessary to carry out financial management functions, manage the financial operations of the 

agency, and report on the agency’s financial status to central 

agencies, Congress, and the public. 

OMB Circular 

A-127 

 

AntiDeficiency Act Enacted legislation that: 

3⁄4 prohibits the making of expenditures or the incurring of obligations prior to appropriations; 

3⁄4 prohibits the incurring of obligations or the making of expenditures in excess of amounts available in appropriation or 

fund accounts unless specifically authorized by law; 

3⁄4 requires agencies to apportion appropriated funds and other 

budgetary resources; 

3⁄4 requires a system of administrative controls within each 

agency; 

3⁄4 prohibits incurring any obligation or making any expenditure 

in excess of an apportionment or reapportionment or in excess of other subdivisions; 

3⁄4 specifies penalties for anti-deficiency violations; 

3⁄4 requires apportionment of appropriation or fund accounts to 

prevent the need for supplemental or deficiency appropriation; and 

3⁄4 assists in bringing about the most effective and economical 

use of appropriations and funds. 

 

Appropriation A provision of law (not necessarily an appropriations act) authorizing the expenditure of funds for a given purpose. Usually, 

but not always, an appropriation provides budget authority. 

JFMIP Core 

Financial System Requirements 

 
Appendix B: Glossary 

72 Acquisition/Financial Systems Interface Requirements 

Asset Identifier A code used to identify the asset or multiple assets, as in the case 

of inventory or pooled property, plant, and equipment (PP&E) 

items, for which costs were incurred. Federal accounting standards require that recorded costs for inventory and PP&E assets 

include all costs incurred to bring these assets to the form and 

location suitable for their intended use (see SFFAS No. 6, par. 

26 and SFFAS No. 3, par. 21). Since more than one contract or 

acquisition/contracting activity may be utilized to acquire and 

place these assets in the form and location suitable for their intended use, a mechanism such as an asset identifier is necessary 

to capture total contracting costs associated with a specific asset. 

The need for total costs is important for both cost accounting and 

financial reporting purposes. 

 

Award Date The date the contract was signed by the contracting officer.. 

Blanket Purchase Agreement (BPA) A simplified method of filling anticipated repetitive needs for 

supplies or services by establishing charge accounts with qualified sources of supply. 

FAR 13.303 - 

1(a) 

 

Blanket Purchase Agreement Call 

Number 

A unique number assigned by the BPA issuing office that is used 

to track orders against the BPA. 

 

Budget Authority The authority provided by law to incur financial obligations that 

will result in outlays. Specific forms of budget authority include 

appropriations, borrowing authority, contract authority, and 

spending authority from offsetting collections. 

OMB Circular 

A-34, 2000 

 

Bulk Funding A system whereby the contracting officer receives authorization, 

from a fiscal and accounting officer, to obligate funds on purchase documents against a specified lump sum of funds reserved 

for the purpose for a specified period of time rather than obtaining individual obligation authority on each purchase document. 

Bulk funding is particularly appropriate if numerous purchases 

using the same type of funds are to be made during a given period. 

FAR 13.101 

(b) (4) 

 

Cardholder Any Federal employee that has a purchase card issued in his or 

her name. 

GSA Card 

Program 

definitions 

 
Appendix B: Glossary 

Acquisition/Financial Systems Interface Requirements 73

Certifying 

Officer 

An accountable officer responsible for and required to personally reimburse the government for any illegal or otherwise improper payment made by a disbursing officer because of his or 

her certification. 

GAO Policy 

and Procedures Manual

 

Claim A written demand or written assertion by one of the contracting 

parties seeking, as a matter of right, the payment of money in a 

sum certain, the adjustment or interpretation of contract terms, or 

other relief arising under or relating to the contract. 

FAI Glossary 

of Acquisition 

Terms

 

Closeout The process by which a Federal agency determines that a contract has been physically completed and all applicable administrative actions, including final payment or recovery of overpayment, have been completed. 

Note: A contract is considered physically completed when (1) 

the contractor has completed the required deliveries and the government has inspected and accepted the supplies; (2) the contractor has performed all services and the government has accepted 

these services; and (3) all option provisions, if any, have expired; or the government has given the contractor a notice of 

complete contract termination. 

 

Commitment An administrative reservation of funds (including increases to 

existing commitments) in anticipation of obligation(s). 

Completion 

Invoice 

Contractor invoice marked as final or supplemental evidence 

that all invoices have been submitted and the contractor believes 

physical completion has occurred. 

 

Contract A mutually binding legal relationship obligating the seller to 

furnish the supplies or services (including construction) and the 

buyer to pay for them. It includes all types of commitments that 

obligate the government to an expenditure of appropriated funds 

and that, except as otherwise authorized, are in writing. In addition to bilateral instruments, contracts include (but are not limited to) awards and notices of awards; job orders or task letters 

issued under basic ordering agreements; letter contracts; orders, 

such as POs, under which the contract becomes effective by 

written acceptance or performance; and bilateral contract modifications. Contracts do not include grants and cooperative 

agreements covered by 31 U.S.C. 6301, et seq. 

FAR 2.101 

 
Appendix B: Glossary 

74 Acquisition/Financial Systems Interface Requirements 

Contract 

Action 

An action in a contract, including contract modifications for additional supplies or services, but not including contract modifications that are within the scope and under the terms of the contract, such as contract modifications issued pursuant to the 

Changes clause, or funding and other administrative changes. 

FAI Glossary 

of Acquisition 

Terms

 

Contract 

Administration 

Office 

An office that performs a) assigned post-award functions related 

to the administration of contracts; and b) assigned pre-award 

functions. 

FAR 2.101 

 

Contract 

Award 

The act of executing a draft contract instrument, whereby 

authorized signatory representatives of the parties to the draft 

instrument sign all portions of the contract. This act commences 

execution of all respective responsibilities spelled out in the 

various portions of the contract. 

 

Contract 

Closeout 

(See Closeout) 

Contract 

Number 

An alphanumeric designator created by each agency for a contract. Per GAO Policy and Procedures Manual for Guidance of 

Federal Agencies, Title 7—Fiscal Guidance (Feb 1990): The 

contract number should consist of alpha characters in the first 

positions to indicate the agency, followed by alpha-numeric 

characters identifying bureaus, offices, or other administrative 

subdivisions authorized to enter into contacts. The last portion of 

the contract number should be sequential with a unique number 

series for each contracting activity. 

 

Contracting Purchasing, renting, leasing, or otherwise obtaining supplies or 

services from nonfederal sources. Contracting includes description (but not determination) of supplies and services required, 

selection and solicitation of sources, preparation and award of 

contracts, and all phases of contract administration. It does not 

include making grants or cooperative agreements. 

FAR 2.101 

 

Contracting 

Activity 

An element of an agency designated by the agency head and 

delegated broad authority regarding acquisition functions. 

FAR 2.101 

 

Contracting 

Office 

An office that awards or executes a contract for supplies or services and performs post award functions not assigned to a contract administration office. FAR 2.101 

 
Appendix B: Glossary 

Acquisition/Financial Systems Interface Requirements 75

Contracting 

Officer 

A person with the authority to enter into, administer, and/or terminate contracts and make related determinations and findings. 

The term includes certain authorized representatives of the contracting officer acting within the limits of their authority as delegated by the contracting officer. 

FAR 2.101 

 

Core Financial 

System 

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. 

JFMIP Core 

Financial System Requirements 

 

Cost Center A logical grouping of one or more related activities and/or organizational units into a common pool for the purpose of identifying the cost incurred for performing all of those activities. JFMIP Core 

Financial System Requirements

 

Credit Any transaction that reduces the government’s amount due. GSA SmartPay Contract 

definitions 

 

Decommitment The downward adjustment (including cancellation) of previously 

recorded commitments. 

Delivery Order An order for supplies placed against an established contract or 

with government sources. 

FAR 2.101 

De-Obligate or 

De-Obligation 

An agency’s cancellation or downward adjustment of previously 

recorded obligations. 

 

Designated 

Official 

Refers to the organizational element responsible for the process 

step, such as the program office, receiving and acceptance officials, and sometimes contracting or finance representatives. 

 
Appendix B: Glossary 

76 Acquisition/Financial Systems Interface Requirements 

Direct Cost Costs that can be specifically identified with an output. All direct 

costs should be included in the full cost of outputs. Typical direct costs in the production of an output include: (a) Salaries and 

other benefits for employees who work directly on the output; 

(b) Materials and supplies used in the work; (c) Various costs 

associated with office space, equipment, facilities, and utilities 

that are used exclusively to produce the output; and (d) Costs of 

products or services received from other segments or entities that 

are used to produce the output. 

SFFAS 4 

 

Disbursement Payment made using cash, check, or electronic transfer. Disbursements include advances to others as well as payments for 

products and services received and other types of payments 

made. 

JFMIP Core 

Financial System Requirements

 

Disbursing Authority Authority to disburse public money to officers and employees of 

other Federal agencies in accordance with 31 U.S.C. § 3321(b). 

I TFM 4-

10000 

 

Effective Date The date of contract award or the stipulated date, whichever is 

later. 

 

Electronic 

Commerce 

Electronic techniques for accomplishing business transactions 

including electronic mail or messaging, World Wide Web technology, electronic bulletin boards, purchase cards, EFT, and 

electronic data interchange (EDI). 

FAR 2.101 

 

Electronic Data 

Interchange 

A technique for electronically transferring and storing formatted 

information between computers utilizing established and published formats and codes, as authorized by the applicable Federal 

Information Processing Standards. 

FAI Glossary 

of Acquisition 

Terms

 

Electronic 

Funds Transfer 

A transfer transaction instruction given to the Federal Reserve 

System to execute an outlay or disbursement. 

 

Enterprise Architecture A strategic information asset base that defines the business, information necessary to operate the business, technologies necessary to support the business operations, and transitional processes for implementing new technologies in response to the 

changing needs of the business. 

Federal Enterprise Architecture 

Framework, 

V.1.1, Federal 

CIO Council, 

September 

1999 

Expenditure See Outlay 

 
Appendix B: Glossary 

Acquisition/Financial Systems Interface Requirements 77

Expenditure 

Variance 

The percentage or dollar variance of an expenditure amount that 

can exceed an obligation amount. Some organizations refer to 

this as “tolerance level.” 

Adapted from 

the definition 

of “Tolerance 

Levels” in the 

JFMIP Core 

Financial System Requirements

 

Expense The outflow of assets or incurrence of liabilities during a period 

resulting from rendering services, delivering or producing products, or carrying out other normal operating activities. 

JFMIP Core 

Financial System Requirements 

 

Federal 

Agency 

Any executive agency or any independent establishment in the 

legislative or judicial branch of the government (except the Senate, the House of Representatives, the Architect of the Capitol, 

and any activities under the Architect’s direction). 

FAR 2.101 

 

Federal Wire 

Transfer 

An electronic transfer system developed and maintained by the 

Federal Reserve. The system connects Federal Reserve Banks 

(FRB), the Treasury and government agencies, and depositary 

institutions, which maintain an account at an FRB. The Treasury 

Fedwire Deposit System (FDS) is a computer-to-computer link 

between Treasury and the Federal Reserve Bank of New York 

(FRBNY). This system provides the capability for: (1) automated receipt and processing of funds transfers and (2) computer-assisted generation of funds transfers between Treasury, 

FRB’s, and other banks utilizing Fedwire 

I TFM 5-4500 

 

Final Acceptance Indicator Designated agency official acknowledgement that final acceptance has occurred. 

 

Final Invoice The very last invoice paid upon contract closeout. 

Final Payment The last payment made to the contractor to include the balance 

of any costs and/or profit/fee owed after the completion of all the 

contractor’s obligations (including deliveries, data, and releases) 

under the terms of the contract. 

 

Final Payment 

Indicator 

Finance system acknowledgement that final payment has been 

made. 

 
Appendix B: Glossary 

78 Acquisition/Financial Systems Interface Requirements 

Financial 

System 

An information system, comprised of one or more applications, 

that is used for any of the following: 

3⁄4 collecting, processing, maintaining, transmitting, and reporting data about financial events; 

3⁄4 supporting financial planning or budgeting activities; 

3⁄4 accumulating and reporting cost information; or 

3⁄4 supporting the preparation of financial statements. 

A financial system supports the financial functions required to 

track financial events, or provide financial information significant to the financial management of the agency, and/or is required for the preparation of financial statements. A financial 

system encompasses automated and manual processes, procedures, controls, data, hardware, software, and support personnel 

dedicated to the operation and maintenance of system functions. 

A financial system may include multiple applications that are 

integrated through a common database or are electronically interfaced, as necessary, to meet defined data and processing requirements. 

OMB Circular 

A-127 

 

Financing 

Payment 

Payment made under a contract for purposes of financing, e.g., 

progress payment, performance-based payment, or voucher 

payment. 

 

Fiscal Year The government’s accounting period. It begins on October 1 and 

ends on September 30, and is designated by the calendar year in 

which it ends. 

OMB Circular 

A-34 

 

Funds 

Certification 

The process of affirming that funds or budget authority is available for potential purchases of products or services. It is part of 

the funds control process that reserves funds in anticipation of an 

obligation. 

 

Hardware 

System 

Two or more individual items (equipment components) that are 

part of a self-contained group; are joined physically, electronically, or electromechanically; are programmed or designed specially to rely on each other; cannot function independently if 

separated; and cannot be easily disconnected and reconfigured to 

function with or within another unit or “system”. 

JFMIP Property Management Systems 

Requirements

 

Head of the 

Agency 

(also called 

Agency Head) 

The Secretary, Attorney General, Administrator, Governor, 

Chairperson, or other chief official of an executive agency, 

unless otherwise indicated, including any deputy or assistant 

chief official of an executive agency. 

FAR 2.101 
Appendix B: Glossary 

Acquisition/Financial Systems Interface Requirements 79

 

Incremental 

Funding 

The provision or recording of budgetary resources for a program 

or project based on obligations estimated to be incurred within a 

fiscal year when such budgetary resources will not cover all the 

program’s or project’s obligations. 

 

Indirect Cost Costs of resources that are jointly or commonly used to produce 

two or more types of outputs but are not specifically identifiable 

with any of the outputs. Typical examples of indirect costs include costs of general administrative services, general research 

and technical support, security, rent, employee health and recreation facilities, and operating and maintenance costs for buildings, equipment, and utilities. 

SFFAS 4 

 

Information 

Technology 

Any equipment, or interconnected system(s) or subsystem(s) of 

equipment, that is used in the automatic acquisition, storage, 

manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the agency. 

FAR 2.101 

 

Interagency 

Agreement 

Number 

Identifier associated with an agreement between two Federal entities. The agreement, similar to a statement of work, specifies 

the business partners involved, the products/services to be provided, and other pertinent information. 

 

Interface 

Requirement 

A need for information, such as data requirements, reporting 

needs, internal controls, or edit requirements, required by the 

acquisition and finance functions as a result of transactions 

within the single integrated financial management system. 

 

Internal 

Control 

Plan of organization, methods, and procedures adopted by management to ensure that (1) resource use is consistent with laws, 

regulations, and policies; (2) resources are safeguarded against 

waste, loss, and misuse; and (3) reliable data are obtained, maintained, and fairly disclosed in reports. 

 

Intragovernmental 

Business Partner Code 

Similar in concept to a vendor or contractor code. It is an identifier for a Federal entity engaged in acquiring or providing products/services from another Federal entity 

 

Invoice A contractor’s bill or written request for payment under the contact for supplies delivered or services performed. FAR 32.902 

 
Appendix B: Glossary 

80 Acquisition/Financial Systems Interface Requirements 

Lease A contract granting occupation or use of property during a certain period in exchange for a specified rent. 

Webster’s II 

New Riverside 

University 

Dictionary. 

 

Liability Assets owed for items received, services received, assets acquired, construction performed (regardless of whether invoices 

have been received), an amount received but not yet earned, or 

other expenses incurred. Liabilities include (1) amounts owed 

for products in the hands of contractors under the constructive 

delivery concept (when an agency, the seller, meets long-term 

contract obligations) and (2) amounts owed under grants, pensions, awards, and other indebtedness not involving the furnishing of products and services. 

 

Micropurchase An acquisition of supplies or services (except construction), the 

aggregate amount of which does not exceed $2,500, except that 

in the case of construction, the limit is $2,000. 

FAR 2.101 

 

Micropurchase 

with Purchase 

Card 

Purchases valued at $2,500 or less that use a government-issued 

purchase card to purchase and pay for the supplies or services 

purchased. 

 

Mixed System An information system that supports both financial and nonfinancial functions of the Federal government or components 

thereof. 

FFMIA of 

1996 

 

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. 

OMB Circular 

A-11 

 
Appendix B: Glossary 

Acquisition/Financial Systems Interface Requirements 81

Obligating 

Document 

Number(s) 

An identifier that refers to a specific document representing an 

obligation of Federal funds, which can be a task or delivery order number and its associated contract number; a BPA call number and its associated BPA number; a contract number; or a PO 

number. 

Part of the obligating document number(s) is any modification 

number associated with any of the above numbers. Acquisition 

obligating documents often have more than one number that 

must be recorded to properly record the obligation. 

 

Obligation A binding agreement that will result in outlays, immediately or 

in the future. Budgetary resources must be available before obligations can be incurred legally. 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. 

JFMIP Grant 

Financial System Requirements and

Core Financial System 

Requirements 

 

Obligation 

Amendment 

Amendment to an obligation amount resulting from a contact 

modification. (See also Contract Action). 

 

Organization 

Code 

A code representing the offices, divisions, branches, etc., established within an entity based on responsibility assignments, 

whether functional or program related; can also reflect the distribution of operating plans or other funding. 

 

Outlay A payment to liquidate an obligation. Outlays are the measure of 

government spending. Outlays generally are equal to cash disbursements but also are recorded for cash-equivalent transactions. 

JFMIP Core 

Financial System Requirements 

 

Partial 

Payments 

Payments for accepted supplies and services that are only a part 

of the contract requirements. OMB A-125 requires agencies to 

pay for partial delivery of supplies or partial performance of services unless specifically prohibited by the contract. 

FAR 

32.102(d) 

 
Appendix B: Glossary 

82 Acquisition/Financial Systems Interface Requirements 

Payment A government disbursement of monies to a contractor in accordance with contract terms. The payment management function 

consists of the following processes: payee information maintenance, payment warehousing, payment execution, and payment 

confirmation and follow-up. 

FAR 32.902 

and JFMIP 

Core Financial System 

Requirements 

 

Payment Date The date on which a check for payment is dated or, for an EFT, 

the specified payment date. 

FAR 32.902 

Payment Office The office or employee responsible for scheduling invoices for 

payment. 

PL 97-177, 

Prompt Pay 

Act of 1982 

 

Performance 

Measure Code 

A code used to identify the performance goal that would be associated with the PO, so that it would be easy to link performance execution (obligations) to the approved performance 

plans/measures. The code is intended to serve as an agency option to comply with Government Performance and Results Act 

(GPRA) requirements, to deploy resources in accordance with 

strategic plans and objectives, and measure results against them. 

 

Physical 

Completion 

The point in time at which all contract items and services have 

been delivered and accepted or the term of the contract has expired. The contract administration office may issue a contract 

completion certificate. 

 

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 has many uses and thus does not have a welldefined, standard meaning in the legislative process. It is used to 

describe an agency’s mission, programs, functions, activities, 

services, projects, and processes. 

JFMIP Core 

Financial System Requirements

 

Program Code A code to which expenses incurred or assets acquired relate to a 

program. 

JFMIP Core 

Financial System Requirements

 

Progress 

Payment 

Payments for contractor progress under a fixed-price contract. 

Payments are based on a percentage of the costs incurred by the 

contractor in performing the contract, considering limits related 

to the fixed price. This form of contract financing does not include: 

FAR 

32.102(b) 
Appendix B: Glossary 

Acquisition/Financial Systems Interface Requirements 83

3⁄4 payments based on the percentage or stage of completion 

accomplished; 

3⁄4 payments for partial deliveries accepted by the government; and 

3⁄4 partial payments for a contract termination proposal or 

performance-based contracts. 

 

Project Code A code to which expenses incurred or assets acquired relate. A 

project is 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. Project code is also referred to as job code in some 

organizations. 

JFMIP Core 

Financial System Requirements 

 

Proper Invoice A bill or written request for payment that meets the minimum 

standards specified in the applicable prompt payment clause and 

other terms and conditions contained in the contract for invoice 

submission. A “proper invoice” must meet the requirements of 5 

CFR, Chapter 3, Sec. 1315.9(b) and can include receiving reports and delivery tickets when contractually designated as invoices. 

FAR 32.902 

 

Proper 

Matching 

An example, for purposes of payment, is a comparison of the: 

(1) acceptance/receipt document or receiving report, (2) obligation, and (3) request for payment (invoice). 

 

Purchase Card “Governmentwide commercial purchase card” means a purchase 

card, similar in nature to a commercial credit card, issued to authorized agency personnel to use to acquire and to pay for supplies and services. 

FAR 13.001 

 

Purchase Card 

Reconciliation 

The task of matching and resolving purchase card transactions 

made by the cardholder with the purchases listed on the periodic 

account statement provided to the agency by the card-processing 

financial institution. 

 

Purchase Order An offer by the government to buy supplies or services, including construction and research and development, upon specified 

terms and conditions, using simplified acquisition procedures. 

FAR 13.001 

 
Appendix B: Glossary 

84 Acquisition/Financial Systems Interface Requirements 

Receiving 

Report 

Written evidence meeting the requirements of FAR 32.905(f) 

that indicates government acceptance of supplies delivered or 

services performed by the contractor. 

FAR 32.902 

 

Requirements 

– Mandatory 

Mandatory requirements describe what the system must do and 

consist of the minimum acceptable functionality necessary to 

establish a system, or are based on Federal laws and regulations. 

Mandatory requirements are those against which agency heads 

evaluate their systems to determine substantial compliance with 

systems requirements under the FFMIA. These requirements apply to existing systems in operation and new systems planned or 

under development. 

JFMIP Core 

Financial System Requirements 

 

Requirements 

– Value-Added 

Value-added requirements describe optional features or characteristics and may consist of any combination of the following: 

(1) using state-of-the-art technology, (2) employing the preferred 

or best business practices, or (3) meeting the special management needs of an individual agency. Value-added, optional, and 

other similar terminology may be used to describe this category 

of requirements. Agencies should consider value-added features 

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

head. 

JFMIP Core 

Financial System Requirements 

 

Revenue 

Source Code 

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

Financial System Requirements 

 

Signature or 

Signed 

The discrete, verifiable symbol of an individual which, when 

affixed to a writing with the knowledge and consent of the individual, indicates a present intention to authenticate the writing. 

This includes electronic symbols. 

FAR 2.101 

 

Simplified 

Acquisition 

Procedure 

The methods prescribed in FAR Part 13 for making purchases of 

supplies or services. 

FAR 2.101 

 

Software The application and operating system programs, procedures, 

rules, and any associated documentation pertaining to the operation of a computer system. 

JFMIP Property Management Systems 

Requirements

 
Appendix B: Glossary 

Acquisition/Financial Systems Interface Requirements 85

Specified 

Payment Date 

The date that the government has placed in the EFT payment 

transaction instruction given to the Federal Reserve System as 

the date on which the funds are to be transferred to the contractor’s account by the financial agent. If no date has been specified 

in the instruction, the specified payment date is three business 

days after the payment office releases the EFT payment transaction instruction. 

FAR 32.902 

 

Standard 

General Ledger 

A uniform list of accounts and support transactions that standardizes Federal agency accounting and supports the preparation 

of standard external reports. The U.S. Government Standard 

General Ledger Chart of Accounts (1) provides control over all 

financial transactions and resource balances, (2) satisfies basic 

reporting requirements of OMB and Treasury, and (3) integrates 

proprietary and budgetary accounting. 

 

Subject to 

Funds 

Availability 

Funds have not yet been certified as available. Solicitations to 

industry may include a clause that provides a caveat to this effect, so as not to project the program as funded and thereby raising unwarranted hopes by companies for potential sales. 

 

Task Order An order for services placed against an established contract or 

with government sources. 

FAR 2.101 

Taxpayer 

Identification 

Number 

The number required by the IRS to be used by the offeror in reporting income tax and other returns. The TIN may be either a 

Social Security Number or an Employer Identification Number 

(EIN). Also, the number is defined by the Treasury Financial 

Management Service Tax Identification Policy as follows: “A 

nine digit Employer Identification Number or Social Security 

Number as defined in Section 6109 of the Internal Revenue 

Code of 1986.” 

 

Trading 

Partner 

A customer, contractor, or service provider (such as a bank, hospital, or manufacturer) that conducts business with another 

organization. 

 

Trading Partner Code Codes assigned by the Department of Treasury, Financial Management Service (FMS) to certain Federal agencies to facilitate 

disbursement, reconciliation, and other activity/reporting by 

FMS. 

 

Transaction 

Type 

Type of accounting transaction processed. For example, partially 

liquidating obligation or fully liquidating obligation. 

 
Appendix B: Glossary 

86 Acquisition/Financial Systems Interface Requirements 

Undelivered 

Orders 

The value of products and services ordered and obligated that 

have not been received. This amount includes any orders for 

which advance payment has been made but for which delivery of 

performance has not yet occurred. 

 

Vendor Any person, organization, or business concern engaged in a profession, trade, or business, and any not-for-profit entity operating 

as a contractor (including State and local governments and foreign entities and foreign governments, but excluding Federal entities). 

5 CFR, Chapter III, Sec. 

1315 

 

Voucher The Standard Form 1034, Public Voucher for Purchases and 

Services Other Than Personal, or similar form; a type of request 

for payment. 

FAR 

49.103(c) 
 

Acquisition/Financial Systems Interface Requirements 87

Appendix C: Factors Influencing the Environment 

At any particular point in time, there are multiple on-going or planned projects or activities with 

interlocking goals, objectives, and plans, which frequently involve some form of system automation, electronic data interchange (EDI), or electronic commerce (EC). This appendix provides 

highlights of three activities that were identified during the development of this document that 

are particularly relevant to the acquisition management and financial management communities, 

i.e., Information Technology in the Acquisition Process, Intragovernmental Transactions, and the 

FASAB effort to develop a standard for National Defense PP&E. 

This appendix is not comprehensive or exhaustive in terms of the aspects of each project or activity or their relevance to each other. Also, these and other projects change over time, i.e., some 

are completed, some are terminated, and others are established. The projects and activities discussed in this appendix, and others, should be considered in an agency’s efforts to develop, implement, operate, and maintain agency financial management systems. 

Information Technology in the Acquisition Process 

As previously discussed, IT is a critical factor influencing acquisition processes and interfaces. 

Its application allows paperless processes, better buying decisions, and ultimately, improved customer service. IT enables the reengineering of acquisition and financial processes. 

The information technology approach chosen to implement the functional shared information 

requirements identified in this document do not require any specific IT solution in either hardware or software. However, agencies should recognize the availability of governmentwide IT 

solutions designed to achieve congressional goals to reduce paper processes, to secure electronic 

information and to improve access to information. Any agency implementing these acquisition/financial functional requirements must take into account these influences when developing 

its IT strategy. 

Besides enabling improved processes, IT allows better functional integration by automating the 

exchange of information from one function to another. Information is acquired at its source and 

shared across functional boundaries so that a particular contract award record in a financial system is identical to the record in the acquisition system. 

Objectives 

The PEC has identified technology as one of its strategic priorities.18 The PEC’s Electronic 

Commerce Committee (ECC) was established to enhance the effective use of EC. Its specific 

objective is to maximize the efficiency and effectiveness of Federal acquisition systems in order 

to improve business processes with a focus in procurement-related EC. The ECC works to meet 

these objectives through: 

♦ A single governmentwide point of entry for EC. 

 

18Procurement Executives Council, Fiscal Year 2001-2005 Strategic Plan, Strategic Priority: Optimize Technology 

As A Key Business Enabler, pg. 7. 
Appendix C: Factors Influencing the Environment 

88 Acquisition/Financial Systems Interface Requirements 

♦ Internet security. 

♦ A re-engineered Federal Procurement Data System. 

♦ Partnering with CFO and CIO communities on electronic government initiatives. 

♦ Governmentwide standards for acquisition and financial system interface. 

♦ Common Federal acquisition architecture evolving toward interoperability. 

Electronic Commerce 

The primary IT acquisition initiative, EC, is the exchange of business information through electronic means. Three EC technologies are currently significant to acquisition: the Internet and 

World Wide Web, of which a key example is FedBizOpps for posting synopses and solicitations; 

EDI transaction standards for electronic ordering and invoicing; and EFT payment transaction 

standards for paying contractors electronically. 

The FedBizOps web portal is one approach toward meeting the single point of entry objective, 

while the use of EDI and EFT standards provide governmentwide interface standards for acquisition and finance. The acquisition and financial EDI and EFT standards are being updated to a 

new interchange standard called Extensible Markup Language (XML), which allows greater integration with web applications. As these electronic interface technologies evolve, system developers should be cognizant of their support of the functional interface requirements contained in 

this document and stand ready to integrate them into existing systems. 

Electronic Government (E-government) 

The OMB’s E-Government Strategy describes twenty-four initiatives to improve the quality of 

services to citizens, businesses, governments and government employees, as well as the effectiveness and efficiency of the Federal government. The initiatives influencing the acquisition/financial interface requirements environment are: 

♦ Integrated Acquisition Environment—allows agencies to begin sharing common data 

elements to enable other agencies to make more informed procurement, logistical, payment and performance assessment decisions. 

♦ E-Authentication—builds and enables the mutual trust needed to support widespread use 

of electronic interactions between the public and government and across governments. 

This will establish a method for satisfactorily establishing “identity,” without which the 

promise of E-Government will never reach its full potential. 

Information Security 

Another IT influence on acquisition is the requirement for adequate security controls on systems, 

the security of business communications, and the ability to rely on electronic signed documents. 

These requirements impact acquisition and finance due to their considerable paper interface with 

the public and the need to store sensitive business information in their computer systems. The 
Appendix C: Factors Influencing the Environment 

Acquisition/Financial Systems Interface Requirements 89

solutions are computer system access controls, public key cryptography and digital signature 

technology. Electronic signatures and internet security, essential for paperless purchasing and 

payment, will be provided to the acquisition community through the Access Certificates for Electronic Services (ACES) program administered by the GSA. ACES facilitates secure online access by the public to government information and services through the use of public key infrastructure/digital signature technology. For more sensitive transactions DoD will be using the 

Common Access Card and Public Key Infrastructure to comply with GPEA provisions relative to 

the use and acceptance of electronic signatures. 

Information security has gained greater emphasis since the Government Information Security 

Reform Act amended the Paperwork Reduction Act of 1995 by adding a new subchapter on information security. The Security Act, which was enacted as part of the National Defense Authorization Act for Fiscal Year 2001 (PL 106-398), codifies existing OMB security policies, Circular A-130 (Appendix III) and reiterates security responsibilities outlined in the Computer Security Act of 1987, the Paperwork Reduction Act, and the Clinger-Cohen Act of 1996. In addition, the Security Act requires annual agency program reviews and annual independent evaluations for both unclassified and national security programs. 

Enabling Process Change 

The effect of IT is a reengineering of acquisition and finance processes. Examples are: 

♦ Purchase card technologies enable traditional customers of the procurement process to 

individually acquire their own micropurchases, which in turn permits thousands of individual invoices to be consolidated into one monthly statement for payment to the cardprovider bank. 

♦ Electronic catalog technologies that enable online ordering via GSA Advantage! or other 

agency internet ordering systems to speed sourcing, placement, and receipt of supplies 

and services. 

♦ Internet and email technologies that allow agencies, through the FedBizOps portal, not 

only to post solicitations directly on the Internet but send interested contractors an email 

notice with a link to the solicitation. The results are one-stop access to all Federal business opportunities, a paperless solicitation process, greater competition, and ultimately, 

better customer service. 

Electronic Signature Requirement 

Although OMB is neutral as to the best approach for electronic signatures, there is a general requirement to accept electronic signatures. This requirement, which must be adhered to, stems 

from the following: 

♦ The FAR defines signature19 or signed to mean the discrete, verifiable symbol of an individual which, when affixed to a writing with the knowledge and consent of the individual, indicates a present intention to authenticate the writing. This includes electronic 

 

19 FAR 2.101, Definitions. 
Appendix C: Factors Influencing the Environment 

90 Acquisition/Financial Systems Interface Requirements 

symbols. Simply stated, systems which produce electronic signatures must be capable of 

ensuring that these signatures are: (1) unique to the signer, (2) under the signer’s sole 

control, (3) capable of being verified, and (4) linked to the data in such a manner that, if 

the data are changed, the signature is invalidated upon verification. 

♦ The Electronic Signatures in Global and National Commerce (E-SIGN) Act (Public Law 

106-229) provides that a signature or contract may not be denied legal effect solely because it is in electronic form. The E-SIGN Act does not require Federal agencies to use or 

accept electronic signatures or records for contracts. However, a Federal agency and its 

contractor may choose by mutual agreement to use electronic signature methodologies 

(OMB Guidance on Implementing the Electronic Signatures in Global and National 

Commerce Act, dated September 25, 2000). 

♦ GPEA20 requires Federal agencies to allow, by October 21, 2003, individuals or entities 

that deal with the agencies, the option to submit information, transact with the agency, 

and maintain records electronically when practicable. Like the E-SIGN Act, the act specifically states that electronic records and their related electronic signatures are not to be 

denied legal effect, validity, or enforceability merely because they are in electronic 

form.21 The act also encourages the Federal government’s use of a range of electronic 

signature alternatives. 

♦ Appendix II of OMB Circular A-130, “Management of Federal Information Resources,”22 implements the GPEA and calls for the Federal government to develop a public key infrastructure to enable the widespread use of cryptographically-based digital signatures. For example, some agencies have successfully developed secure electronic transaction systems using personal identification numbers for security. 

Central Contractor Registration 

A general requirement exists for the identification of contractors through a common system. Although the FAR does not mandate one system, the OMB’s June 7, 2001, for the FY 2003 

Budget23 states, 

“An outcome for expanding electronic government will include the establishment of a governmentwide single point of vendor registration. In FY 2003, agencies will use the Central Contractor Registration (CCR), an existing on-line database, as the single validated source of data on 

vendors doing business with the government. Beginning October 1, 2003, agencies will cease to 

collect the Standard Form 129 known as the Solicitation Mailing List Application.” 

The CCR provides a standard means of providing taxpayer identification data and EFT routing 

information to financial systems. Internet technology allows firms doing business with the government to register in one database for use by all Federal contracting and finance offices needing 

to determine contractor identity. The result is a standard process that eliminates contractors hav-

 

20 44 USC 3504. 

21 OMB Memorandum, M-00-10, dated April 25, 2000, entitled “OMB Procedures and Guidance on Implementing 

the Government Paperwork Elimination Act.” 

22 Revised Feb. 8, 1996. 

23 OMB’s June 7, 2001, Budget Guidance for FY 2003. 
Appendix C: Factors Influencing the Environment 

Acquisition/Financial Systems Interface Requirements 91

ing to submit Standard Form 129 to each contracting office, as well as eliminating maintenance 

of separate contractor databases throughout the government.24

While not currently a requirement, all agencies will soon be required to have their vendors registered within this system. Therefore, to support the overall financial/acquisition interface, the 

agency’s single integrated financial management system should enable interface with the CCR. 

Accessibility for the Disabled 

Section 508 of the Rehabilitation Act of 1973 (as amended), requires that all Federal agencies’ 

EIT be accessible to people with disabilities. Subsection 508(a)(1) requires that when Federal 

departments or agencies develop, procure, maintain, or use EIT, they must ensure that the EIT 

allows Federal employees with disabilities to have access to and use of information and data that 

is comparable to the access to and use of information and data by other Federal employees. Section 508 also requires that individuals with disabilities, who are members of the public seeking 

information or services from a Federal department or agency, have access to and use of information and data that is comparable to those provided to the public without disabilities. Comparable 

access is not required if it would impose an undue burden on the agency. 

Intragovernmental Transactions

During program operations, the need frequently arises for one government agency or component 

to acquire products or services from another government agency or component. When this occurs, that is, one government agency “contracts” with another agency for products or services, 

financial information associated with these transactions is reflected in the financial systems and 

financial reports of two different Federal agencies or components. These “intragovernmental” 

transactions must be eliminated from the various agencies’ financial statements in order to avoid 

double counting and prepare a consolidated, governmentwide financial statement. Disparate 

business practices and widely divergent data structures across agencies result in significant transaction differences. The inability to identify and reconcile intragovernmental transactions has 

been cited as a material weakness governmentwide and is a factor in the GAO’s disclaimer of 

opinion on the U.S. financial statements. 

The OMB is working with the acquisition and financial communities to develop and implement 

policies, procedures, and electronic exchange mechanisms for intragovernmental business transactions. The approach that is being used to address intragovernmental business transactions is 

modeled after the purchase order/invoice concept used for simplified, commercial purchases. 

Emerging FASAB Standard for National Defense PP&E 

When this document was issued, FASAB was in the process of making changes to the national 

defense PP&E accounting standards contained in several FASAB standards documents, including the elimination of national defense PP&E, as a separate category of PP&E. While only two 

agencies—the Department of Defense and the Department of Transportation—account for na-

 

24 OMB’s June 7, 2001, Budget Guidance for FY 2003 states: “In FY 2003, agencies will use the Central Contractor 

Registration (CCR), an existing on-line database, as the single validated source of data on vendors doing business 

with the government.” 
Appendix C: Factors Influencing the Environment 

92 Acquisition/Financial Systems Interface Requirements 

tional defense PP&E, acquisition costs associated with acquiring this type of PP&E are significant to the U.S. Government. 

While reporting requirements differ, both current and proposed national defense accounting 

standards remain consistent in one important area: the need for full cost information. Examples 

of some of the basic information required for both national defense PP&E and other types of 

PP&E include: 

♦ Category of PP&E: critical information needed by the financial system to determine how 

the acquisition of a particular asset category should be accounted for, e.g., capitalized or 

expensed, and reported. 

♦ Asset identifier code: used to identify the asset or multiple assets, as in the case of pooled 

PP&E items, for which costs were incurred. 

♦ Program/project code: current accounting standards require agencies to recognize the full 

cost of their programs and operations. 

♦ Quantity: this information is required under both the current and proposed accounting 

standards for national defense PP&E. 

♦ Costs, including total acquisition or cleanup costs: this information is required under both 

the current and proposed accounting standards for national defense PP&E. 
 

Acquisition/Financial Systems Interface Requirements 93

Appendix D: Contributors

Joint Financial Management Improvement Program (JFMIP) Steering 

Committee 

Jeffrey C. Steinhoff, Chair, General Accounting Office 

Karen Cleary Alderman, Executive Director, JFMIP 

Donald V. Hammond, Department of the 

Treasury 

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 

Dennis Mitchell, Systems Accountant 

Kookie Mitchell, Executive Leadership 

Program, Department of the Interior 

Acquisition/Financial Systems Interface Requirements Project Management 

W.R. (Russ) Ashworth, Director, Department of Agriculture - Project Leader 

Gary Krump, Vice Chair, Procurement 

Executives Council 

Paul Denett, (Retired) Vice Chair, Procurement Executives Council 

Karen Cleary Alderman, Executive Director, JFMIP 

Project Team Leaders 

Team 1: Funds Certification & 

 Obligation/De-Obligation 

 Barbara Diering, OMB 

 Rhea Riso, HUD 

Team 2: Payment & Closeout 

 Carol Covey, DoD 

 Lee Lofthus, DOJ 

Co-leaders: Debbie Streufert, DoD 

 Brian Wolfe, DOT 

Chief Financial Officers Council, Financial Systems Committee 

R. Schuyler Lesher, Chair, Department 

of the Interior 

Office of Management and Budget 

Julie Basile, Procurement Policy Analyst 

Barbara Diering, Management Analyst 

Sandra R. Swab, Financial Analyst 

Team Members Acquisition/Financial 

Systems Interface Requirements Project 

Team 

Department of Agriculture (Sponsoring 

Agency) 

W.R. (Russ) Ashworth, Project Leader 

Agency for International Development 

Debbie Banks 

Joanne Swan 

Department of Agriculture

W.R. (Russ) Ashworth 

Tish Tucker 

Janice Baker 

Jeffery Boudreaux 

Dennis Secketa 

Department of Commerce 

John Thompson 

Department of Defense 

Richard Muth 

Debbie Streufert 

Carol Covey 

Pat Lehtma 

Chuck Crichley 

David Guinasso 

Lester Murray 
 

Acquisition/Financial Systems Interface Requirements 94

Department of Education

Rosemary Evans 

Jean Milazzo 

Department of Energy 

Ellen Colligan 

Department of Health and Human Services 

Norbert Juelich 

Jeanette Pang 

Department of Housing and Urban Development 

Rhea L. Riso 

Cherryl Cornelious 

Barry McVay 

Department of the Interior 

Don K. Haines 

Samantha Goldstein 

Department of Justice 

Lee Lofthus 

Lorine Alston 

Harold Belcher 

Department of Transportation 

Brian Wolfe 

Department of the Treasury

Margaret Hunt 

Richard Miller 

Tim Clower 

Gary Fletcher 

Department of Veterans Affairs 

Katherine Galos 

Steve Graves 

Federal Accounting Standards Advisory 

Board 

Andrea Palmer 

Federal Communications Commission 

Dennis O. Dorsey 

Federal Emergency Management Agency 

JoAnn Lee 

Harold Washington 

General Accounting Office 

Evelyn Logue 

General Services Administration 

Pat Brooks 

National Aeronautics and Space Administration 

Ken Stepka 

David Moede 

Shelley Meredith 

National Science Foundation 

Jannell Rennie 

Patricia Williams 

Social Security Administration

Terra Falconer 

Paris Greene 

Cheri Rudolf 

Barbara McCann 

Logistics Management Institute 

Karen Sorber, Project Leader 

Jim Hooker 

Susan Smith Johnson 

Caroline Nelson 

Dan Drake 

Marcella Schurter 

Additional Contributors on Purchase Card 

Program Requirements

Sean Allan, Logistics Management Institute 

Wiley R. (Pete) Horsley, Department of the 

Interior 

Martha Orr, Department of Veterans Affairs 

Ronald Rhodes, Logistics Management Institute 

Debra Sonderman, Department of the Interior 

Ronald Taylor, General Services Administration 

Tammy Watson, Department of Veterans Affairs 
Requests for JFMIP Publications 

JFMIP documents may be accessed electronically on the Internet: 

http://www.jfmip.gov 

The JFMIP uses the General Accounting Office’s Document Distribution Center to fulfill publication requests made after mail list distribution. The first copy of each publication requested is 

free. Additional copies are $2 each. Orders for 100 or more copies to be mailed to a single address are discounted 25 percent. Orders should be sent to the following address, accompanied by 

a check or money order made out to the Superintendent of Documents, when necessary: 

Orders by mail: 

U.S. General Accounting Office 

441 G St NW 

RM LM 

Washington, DC 20548 

Orders by phone: 

 Voice: 202/512-6000 

Fax: 202/512-6061 

TDD: 202/512-2537. 
Presorted Standard 

Postage & Fees Paid 

GAO 

Permit number G100

1990 K Street NW 

Suite 430 

Washington, DC 20006 

O F F I C I A L B U S I N E S S 

Penalty for Private Use $300