IPAC is the collection and payment system used by Federal Program Agencies (FPAs) to transfer funds from one agency to another. This chapter explains the procedures by which FPAs process Buy/Sell intragovernmental transactions (IGTs) through IPAC and G-Invoicing
IGTs are transactions that occur in IPAC when goods or services are purchased by one FPA from another. This activity has historically been documented through the issuance of an Interagency Agreement and related records.
G-Invoicing replaces the former reimbursement agreement process with an application for the electronic origination, review, and approval of Buy/Sell interagency agreements and transactions. FPAs that have migrated to G-Invoicing continue to use IPAC to conduct non-Buy/Sell IGT transactions (such as grants, pensions, loans, and investments). IPAC also continues to manage the settlement of funds and report transactions to Treasury's Central Accounting Reporting System (CARS).
Finally, this chapter presents a general overview of IPAC and G-Invoicing system requirements and certain technical specifications established by the Department of the Treasury (Treasury), Bureau of the Fiscal Service (Fiscal Service).
This chapter applies to all FPAs that use IPAC to transfer funds for Buy/Sell IGTs and conduct Buy/Sell IGTs, intragovernmental fiduciary activities, or other intragovernmental expenditure activities. As G-Invoicing is fully implemented, its use will be required by all FPAs for the creation and management of Interagency Agreements and supporting reports for Buy/Sell activity. FPAs must ensure their procedures, accounting systems, and users' access align with the procedures and system requirements outlined in this chapter.
Fiscal Service requires agencies to use G-Invoicing under the authority of 31 U.S.C. 3512(b) and 3513.
IPAC Background - Currently, the terms of Buy/Sell IGTs are negotiated by FPAs and documented in an Interagency Agreement known as a reimbursable agreement. Approvals for agreements and payment/collection transactions exist between autonomous communication channels at the agency level, while transactions are manually processed or uploaded directly into IPAC, which performs the fund settlement. Thus, IPAC is the only point during the Buy/Sell lifecycle in which a consistent, system-negotiated, business event is produced that will trigger the related accounting activities which must take place in each FPA’s respective accounting system.
G-Invoicing Background - As part of Fiscal Service’s broad-based effort to increase transparency and enhance governmentwide financial management, G-invoicing will improve the quality and reliability of Buy/Sell IGT data, G-Invoicing is an online platform for funding officials, program officials, and payment approvers to originate and settle Buy/Sell IGT Interagency Agreements, Orders, and invoices electronically. FPAs will use G-invoicing to reflect their agreement on the funding terms and the accounting treatment of their reimbursable activity and to exchange that data with one another for consistent financial reporting. In summary, G-invoicing serves as:
An agreement broker (the mechanism by which FPAs arrange and negotiate the terms of the Interagency Agreement electronically);
A data exchange utility (the facilitation of the exchange of information between FPAs that ensures well-defined lines of communication; and
A conduit for sharing data and exchanging information on Buy/Sell IGT activity.
The FPA staff involved with IGT Buy/Sell activity will use G-Invoicing as the means by which to originate and settle IGT Agreements, Orders, and invoices. G-Invoicing will manage the processing and approvals of data and activity throughout the transaction lifecycle, either online or via automated data exchange. Trading partners will agree upon terms at each phase of the Intragovernmental Buy/Sell transaction lifecycle and G-Invoicing will capture respective approvals. An invoice will be created for each payment/collection, but FPAs will not have to initiate a transaction within IPAC. G-Invoicing will then submit transaction detail to IPAC for settlement, before posting in the Central Accounting Reporting System (CARS) Account Statements.
G-Invoicing is not an accounting or procurement system. Each FPA will still be responsible for preparing its respective USSGL entries, following appropriate USSGL attributes and guidance. However, IGT activity documented in G-Invoicing will allow FPAs to accurately identify the respective accounting triggers. Additionally, the data captured in G-Invoicing will facilitate in identifying any reconciliation issues regarding reciprocal USSGL entries.
G-Invoicing will be implemented in a phased approach to enhance the application’s functionality. Each release cycle targets specific activities throughout the IGT transaction cycle (e.g., Agreements and Invoices). After full implementation, G-Invoicing will be mandatory.
FPAs may execute transactions within IPAC and G-Invoicing applications either manually online or via bulk data file connections. Each FPA determines the connection type in accordance with standards the Fiscal Service specifically developed for the IPAC and G-Invoicing networks.
IPAC - IPAC is an internet-based collection and payment system that facilitates IGT transactions between FPAs. It facilitates these transactions by transferring funds, with related descriptive data and Treasury Account Symbol/Business Event Type Code (TAS/BETC), from one FPA to another and posts the transaction data from both FPAs to their respective CARS Account Statements.
IPAC enables FPAs to exchange accounting information and to transfer funds between one another for the following interrelated subsystems and transaction types:
Buy/Sell - The IPAC application that processes IGT federal funds transfers between agencies for Buy/Sell reimbursable activity;
Fiduciary - The IPAC application that allows for fiduciary activity, conducted on behalf of FPAs for certain investment or Trust Fund transactions;
RITS - The Retirement and Insurance Transfer System (RITS) that processes retirement and health insurance payments by FPAs to the Office of Personnel Management (OPM) ;
TRACS - The Treasury Receivable Accounting and Collection System (TRACS) that processes interagency transfers related check disbursement data returned to FPAs ; and
Miscellaneous - Other miscellaneous payment and collection transactions.
 For more detailed information on the RITS components, contact the Treasury Support Center (see the Contacts section).
 For more detailed information on the TRACS components, contact the Treasury Support Center (see the Contacts section).
IPAC establishes standardized interagency payment, collection, and adjustment procedures through an internet-based application. To process interagency transactions, agencies should use IPAC per TFM Volume I, Part 2, Chapter 4700, Appendix 10.
G-Invoicing - Whereas IPAC processes all Buy/Sell transactions, G-Invoicing provides a web-based pathway to facilitate the exchange of information and to complete all information needed for Buy/Sell IGT processing. G-Invoicing will manage the processing and approvals of Buy/Sell IGTs and activity between FPAs throughout the three stages of the transaction lifecycle:
(1) 7600A: General Terms and Conditions (GT&C) Agreement. FPAs should ensure they have the statutory authority to conduct transactions reimbursable activity (such as the Economy Act, a revolving fund, a working capital fund, or other authority), and document such authority in the Interagency Agreement (IAA);
(2) 7600B: Order and Funding; and
(3) A standardized Seller-Generated Interagency Invoice. An invoice will be created for each payment/collection, and FPAs will not have to initiate a transaction within IPAC.
G-Invoicing will then submit transaction detail to IPAC for settlement, before posting in the CARS Account Statements. FPAs should continue communicating with one another outside of G-Invoicing, while using the system to record key transaction details.
G-Invoicing accommodates Buy/Sell IGTs from reimbursable agreements only. G-Invoicing cannot be used for activities that will continue to be processed through IPAC, even after FPAs have transitioned to G-Invoicing, including:
Warrant, Nonexpenditure Transfer transactions, and non-reimbursable fund transfers should be completed via another mechanism. Procedures are documented in TFM Volume I, Part 2, Chapter 2000, Warrant and Nonexpenditure Transfer (NET) Transactions.
Accomplished Date—The date that an IPAC transaction was successfully processed by IPAC.
Adjustment—A transaction that a FPA initiates to adjust an erroneous or incorrect payment or collection. Agencies can only use adjustments: (1) to reduce (adjust down) the original transaction amount and (2) to process an adjustment against a payment or collection that is 90 or fewer days old.
The following are two types of adjustment transactions processed through IPAC:
Agency Administrator (AA)—The AA signs the IPAC User Request Forms. AAs also perform the annual recertification of their agency users, and they must make sure that users turn in a revocation form when they no longer require access to IPAC.
Agency Transaction Module (ATM)—A Fiscal Service web-based enterprise application that allows users to input transactions and view vital accounting information using a standard web browser.
Central Accounting Reporting System Non-Reporter (CARS Non-Reporter)—FPAs who are not authorized by Memorandum of Understanding (MOU) to provide TAS/BETC data on transactions reported to CARS by the Central Accounting Front End System (CAFE). CAFE captures TAS/BETC data files from source systems and translates them to CARS. These agencies are identified by Agency Location Code (ALC) and source system (for example, IPAC, the Secure Payment System for external vendor invoice payments, and the Collections Information Repository for deposits).
Central Accounting Reporting System Reporter (CARS Reporter)—FPAs authorized by MOU to provide TAS/BETCs on incoming daily transactions to CAFE/CARS. These organizations are identified by ALC and source system (for example, IPAC, Secure Payment System for external vendor invoice payments, and the Collections Information Repository for deposits).
Collection—A transaction that an agency initiates to pull money, in the form of an online transfer, from FPAs within IPAC.
Detail Amount—The amount entered by the user on the detail section of the IPAC transaction screens. IPAC does not automatically calculate this amount from the Quantity and Unit Price fields; however, the Quantity multiplied by the Unit Price must equal the Detail Amount.
Disbursing Office Symbol (DO Symbol)—An identifier that is automatically assigned when an agency becomes an IPAC application user. Each ALC has a unique DO symbol for each IPAC application (IPAC and RITS).
General Terms and Condition (GT&C)—The partnership section of the IAA that sets the relationship between trading partners and identifies the terms governing the trading partner relationship for Buy/Sell transactions.
Intragovernmental Business Rules—See TFM Volume I, Part 2, Chapter 4700, Appendix 10. These rules apply to all intragovernmental business, specifically, transactions that entail: (1) The exchange of good and services (reimbursable agreements); (2) Investments and borrowings (fiduciary); (3) Transfers between federal entities; and (4) General Fund transactions.
Invoice—A Servicing Agency-generated form within G-Invoicing upon delivery of agreed-upon goods/services within the Bill of Lading and approved Order, that delivers payment information for the transfer of fund from one agency to another.
IPAC Adjustment Voucher Number—A unique identification number that is automatically assigned to each adjustment a customer agency enters into the IPAC application. Bulk file users have the capability to assign their own IPAC adjustment voucher numbers.
IPAC Customer Agency—Recipient of an IPAC transaction. Also referred to as the “Requesting” Agency.
IPAC Document Reference Number—A unique identification number that is automatically assigned to each interagency transaction entered into IPAC. It is a sequential number assigned by DO symbol. This number, when combined with a DO symbol, is unique. Bulk file users have the capability to assign their own IPAC document reference number.
IPAC Originating Agency—The initiator of an IPAC transaction. Also referred to as the “Servicing” Agency.
IPAC Trace Number—A unique identification number that is automatically assigned to each zero dollar interagency transaction entered into IPAC. Bulk file users have the capability to assign their own IPAC trace number.
Master Administrator (MA)—The MA signs the Agency Administrator Designation Forms and certifies the agency’s AAs during recertification. MAs can recertify lower level users when the AA is not available. They also should assure that AAs turn in a revocation form when required. The MA cannot be an AA or an IPAC System user.
Miscellaneous Information Field—An optional IPAC field for storing additional information about a transaction.
Order—The funding section of the IAA that creates a fiscal obligation, exchanges accounting data, and sets specific requirements for the delivery of goods/services.
Payment—A transaction that an agency initiates to disburse money, in the form of an online transfer, to FPAs within IPAC.
Post-USSGL Transactions—An IPAC transaction type used to update the originating agency’s U.S. Standard General Ledger (USSGL) information or to add or change the receiver (customer) agency’s USSGL information.
Requesting Agency—The FPA that is purchasing goods/services in IGT Buy/Sell transactions, also known as the Buyer.
Servicing Agency—The FPA that is selling goods/services in IGT Buy/Sell transactions, also known as the Seller.
Single Sign On User ID—The alphanumeric characters that are assigned to uniquely identify a user for Fiscal Service applications.
Statutory Authority—The legal authority that allows the Servicing Agency to provide products and/or services to another FPA and to be reimbursed.
Zero Dollar Transaction—Used to provide USSGL account information to trading partners, correct information sent in an earlier transaction, or convey additional information. Agencies do not use zero dollar transactions to transfer funds.
Buy/Sell IGTs represent the exchange of goods or services between two federal entities and are accomplished through the issuance of a reimbursable agreement. Fiscal Service advises that any trading partner requirements or business rules be negotiated through the IAA, completed with all necessary data elements. The Fiscal Service IAA includes two sections: (1) The 7600A – General Terms and Conditions (GT&C) Section, and (2) the 7600B – Order Requirements and Funding Information.
Fiscal Service encourages trading partners to work closely with one another and to continue to collaborate throughout the transaction lifecycle when establishing IAAs. Neither Treasury nor Fiscal Service executes IAAs on behalf of other FPAs. The parties to the agreement must raise disputes/disagreements in a timely manner using the dispute resolution process outlined in TFM Volume 1, Part 2, Chapter 4700, Appendix 10, Section 2, Subsection 2.3.2.
Personally identifiable information (PII) and Classified Data may not be included within any IPAC transactions, including Miscellaneous, Description, or Custom fields.
For more information and instructions for completing the Form 7600A, see the Fiscal Service Financial Management and Budget Standardization website.
Buyers and sellers follow the IAA instructions to capture the necessary data elements to ensure a complete reimbursable agreement before beginning any performance of the Order. An IAA must contain one GT&C and at least one Order, but may contain many Orders to one GT&C.
The GT&C section identifies the general terms that govern Buy/Sell trades between the Requesting Agency and Servicing Agency, including roles and responsibilities for both trading partners to ensure effective management of the IAA. GT&C data elements and information include contact information, agreement period dates, points of contact for each agency, and any terms for resolution or agreement termination. No fiscal obligations are created through the execution of the GT&C and no accounting events are recorded. Fiscal Service recommends preparing a GT&C for all IGT Buy/Sell activities. Furthermore, other sources of guidance (such as OMB) may require a GT&C for certain transaction types, such as assisted acquisitions.
To originate the GT&C, either a Requesting Agency (Buyer) or Servicing Agency (Seller) may begin to complete Form 7600A. After completion, the form may be transferred electronically or through mail to its trading partner.
Buyers and sellers must complete the reimbursable agreement before beginning any performance of the Order. An IAA must contain one GT&C and at least one Order, but may contain many Orders to one GT&C.
The Order is the funding section of the IAA that creates a fiscal obligation when the Requesting Agency demonstrates a bona fide need and provides the necessary product(s)/service(s) requirements. Funding information is exchanged by both trading partners, and all required points of contact sign to authorize the Order. The Order identifies the specific Requesting Agency requirements for the expected delivery of products and/or services by the Servicing Agency. It identifies certain responsibilities for both trading partners to ensure effective management of the Order and use of the related funds. Order data elements and information will include specific accounting information, such as the TAS/BETC, quantities, price, capitalization and revenue recognition methodology, and receipt and acceptance details.
A copy of the GT&C must be kept with the Orders that it supports. Trading partners must include adequate descriptive information on the requisition or Order form included in the description section of the IPAC transaction. This enables the Requesting Agency to match the IPAC transaction bill, when received, with the originating requisition.
The Requesting Agency must provide data for all IPAC required fields as well as the Servicing Agency’s special requirements. Both partners must include their respective ALC on all requisitions and/or order forms. The ALC identifies the customer agency that is to be billed for services or supplies. Both trading partners should provide one another with clear and appropriate instructions for transmitting requisition/order information.
After approval of a completed GT&C (Form 7600A) and Order (Form 7600B) by both trading partners, the IPAC transaction may be initiated. The Servicing agency (originating agency) must input/upload the appropriate data in all the IPAC required data fields. Also, it must input/upload the Requesting agency’s special requirements and any descriptive information, supplied with the requisition/order, in the appropriate fields of the IPAC transaction.
Upon entry, payments and collections are processed through IPAC immediately. Transactions will be validated with Shared Accounting Module (SAM) data and subsequently post to both FPAs’ CARS Account Statements, usually the following business day. For payment transactions, IPAC credits the originating agency’s ALC and charges the customer agency’s ALC. For collection transactions, IPAC charges the originating agency’s ALC and credits the customer agency’s ALC. The transaction includes all IPAC required fields, as well as all agency-specific required data, as stipulated by their trading partner and IAA.
If the originating agency does not comply with this procedure, reconciliation problems for the trading partner may result. Noncompliance with or abuse of these established billing procedures may result in Fiscal Service revoking privileges of IPAC. Fiscal Service provides specific instructions for the reporting of Buy/Sell transactions and resolving disputes in TFM Volume I, Part 2, Chapter 4700, Appendix 10.
The IPAC database is updated immediately when processing online transactions and as close to real time as possible for bulk data file transmissions. While completed transactions appear in real-time in IPAC, transactions will not appear in CARS Account Statements until after validation with SAM. The system automatically issues a unique IPAC document reference number for each completely processed transaction (bulk file users have the capability to assign their own IPAC document reference numbers). IPAC ensures that no two transactions are assigned the same number for the same ALC/DO Symbol combination. FPAs billed via IPAC receive transactions based upon the Treasury Account Symbol used by the originating agency, regardless of whether or not the ALC has access to IPAC.
FPAs using IPAC may print/save their transactions immediately after the originating agency enters the transactions into IPAC. In addition, FPAs may retrieve their transactions by downloading data directly into their computer systems to aid in the reconciliation process.
Originating agencies have through the last day of each month to enter transactions for that month. For Buy/Sell transactions only, no IPAC(s) can be processed during the last three business days of the month during quarter-end. FPAs have 90 days after the billing date to enter adjustments to payments or collections.
IPAC is a web-based application and no additional software is needed. To access IPAC, users must have the following:
Before accessing IPAC, each FPA must assign an IPAC AA, MA, and Chief Financial Officer (CFO) for each of its ALCs. The FPA CFO or Deputy CFO, who must be verified by Fiscal Service, signs the MA Designation Forms.
The MA signs the Agency Administrator Designation Forms and certifies the agency’s AAs during recertification. The MA also recertifies lower level users when the AA is not available.
The AA processes the IPAC User Request and registers agency personnel as IPAC users. If Fiscal Service has not assigned an AA to the agency, the agency should contact Fiscal Service (see the Contacts section). To gain access, users must self-enroll in the IBM Tivoli Identity Manager (ITIM).
IPAC users must have a Treasury Enterprise ID (ITIM) and Password. If a user does not have an ITIM ID, please visit the IPAC - Getting Started webpage and follow the instructions for registration.
Follow the enrollment screens sequentially to get your user ID and password.
(For users who already have an ITIM ID and password, please visit the ITIM Self Service page and enter your user ID and password.)
1. On the Treasury ITIM main screen, click "Request Account".
2. Find and click on IPAC from the list of applications.
3. Select the role you need from the drop down menus.
4. Search and select the Agency Administrator(s) of your ALC(s).
a. Click the Search button.
b. In the "Search by" select email address and then enter your Administrator's email address.
5. Click on your Administrator's name.
***If you cannot find your Administrator; that means he or she is not enrolled in ITIM. You cannot proceed until your Administrator has access to approve your request.
6. After your selection, click "Next" and then "Request Account".
7. An email will be sent to your supervisor to approve your access request.
8. Once your Administrator approves your access, Fiscal Service will notify you via email that your access is complete.
For questions regarding IPAC enrollment, please contact the Treasury Support Center as listed in the Contacts section.
IPAC allows each FPA to control which data fields in an IPAC transaction it deems required, beyond those that Fiscal Service has made mandatory. At this time, the Fiscal Service mandatory fields include the following:
Payment and Collection Transactions
Contact Telephone Number
Contact E-mail Address
Unit of Issue*
Obligating Document Number
Purchase Order Number
Sender Treasury Account Symbol
Contact Telephone Number
Contact E-mail Address
Original IPAC Document Reference Number
Original DO Symbol
Sender Treasury Account Symbol
Original Accomplished Date
Zero Dollar Transactions
Contact Telephone Number
Contact E-mail Address
*See the Unit of Issue list on the IPAC website.
Fiscal Service requires the IPAC originating agency to complete the Sender TAS and Sender BETC fields with valid data on all transactions it originates. FPAs may supply additional information in the description areas, including the Description and Miscellaneous Information fields, provided for such information.
FPAs who are CARS TAS/BETC reporters must report a valid TAS/BETC for the sender side of each IPAC transaction when originating IPAC transactions. Also, when FPAs process IPAC transactions with a CARS TAS/BETC reporter, they must report a valid IPAC TAS/BETC for the reporting ALCs on the receiver side of the transaction. IPAC rejects any reporting agency ALC transactions that do not contain a valid TAS/BETC combination. A list of valid TAS and BETCs is available for download on the SAM website.
When an agency requests to become a CARS TAS/BETC reporter, the agency must submit an IPAC special requirements request to the GWA Customer Relationship Team. The IPAC special requirements ensure that a FPA’s trading partner originating IPACs on behalf of it must include a valid TAS/BETC, and requires valid data input/uploaded into the Receiver TAS, Sender BETC, and Receiver BETC fields for all transaction types of each ALC designated as a CARS TAS/BETC Reporter. These transaction types include IPAC payments, collections, and adjustments.
All FPAs should break out the TAS/BETC for each Schedule Line on the Order (Form 7600B), and monitor their CARS Account Statements and IPAC Reports throughout each month to ensure the accuracy of TAS/BETC reporting. FPAs should also monitor their accounts and TAS/BETC activity for IPAC transactions not originated within their agency.
CARS will automatically post any IPAC transactions with an invalid or missing TAS to a SAM default account. For IPAC transactions, the SAM default TAS is XXXF3502. For further information and timeframes on clearing the SAM default account balances, please see TFM Bulletin No. 2016-04, Reporting Suspense Account Activity Using F3875 and F3885 and Using Default Accounts F3500 and F3502 as a Central Accounting Reporting System (CARS) Reporter.
At the time of onboarding to G-Invoicing, all IPAC transactions must be reported with the TAS/BETC on both the sender and receiver sides of the IPAC transaction. However, agencies are encouraged to submit the TAS/BETC for both the sender and receiver sides as soon as possible. For more information on becoming a CARS reporter, see the CARS website.
IPAC accepts only a valid TAS/BETC. A list of valid TAS and BETCs is available for download on the SAM website. Most “F” clearing/suspense accounts are not valid for use through IPAC. However, FPAs may use these suspense accounts, such as the F3885, with discretion to temporarily account for transactions that belong to the government until the transaction is matched to a specific receipt or expenditure account. FPAs should not use clearing/suspense accounts for outlays or payments. For additional information, please see guidance from OMB Circular A-11.
In support of standardizing data elements, Fiscal Service implemented an eight-digit component TAS, as originally introduced in the CGAC V1.0 July 2007 document. On March 23, 2012, Fiscal Service issued a CFO Letter that provided guidance to FPAs to begin using the component TAS format on all financial transactions.
Fiscal Service has updated its transaction and reporting systems to collect and display the component TAS. Some applications, such as GTAS, require all agencies to submit their accounting data only in the component TAS format. IPAC allows the flexibility to accept and display either the string-based TAS format or the component TAS format, allowing for multiple formats to represent the same TAS. FPAs may access a list of available and valid component TAS on the SAM website.
In addition, the BETC code is (up to eight-character code) used in CARS to indicate the type of activity being reported, such as payments, collections, borrowings, etc. This code must accompany the TAS and the dollar amount(s) in order to classify the transaction against the Fund Balance with Treasury (FBwT). The BETC replaces transaction codes and standard subclasses used in old central accounting reports.
For the manual entry of transactions in IPAC, the component TAS is the only structure that is accepted. However, the IPAC bulk file application allows for multiple formats to represent the same TAS. Once the component format is mandated, the capability to accept multiple TAS formats via IPAC bulk file will be discontinued. This will affect pensions/grants/loans, fiduciary activity, and other non-Buy/Sell activity still conducted in IPAC after the time of G-Invoicing onboarding.
Prior to onboarding to G-Invoicing, FPAs will be required to document and report the standard component TAS/BETC for both the Requesting and Servicing sides of all Buy/Sell transactions. However, agencies are encouraged to submit the component format TAS/BETCs for both the Requesting and Servicing sides of all IPAC transactions as soon as possible. GWA currently provides a crosswalk from the current TAS formats to the standard GWA format. Further information and a list of valid TAS/BETCs can be found on the CARS website. The spreadsheet on the CARS website displays the component pieces of the TAS, along with the concatenated format for current reporting in IPAC, and the new standard GWA TAS format.
The IPAC System was the first feeder system to require the new standard component format. In the future, the component TAS will be required in all Fiscal Service payment and collection systems, including G-Invoicing. For more information, refer to the Financial Management and Budget Standardization website.
Fiscal Service does not allow submission of unsupported payments, collections, or adjustments to IPAC. IPAC agencies should be diligent in their transaction procedures, and FPAs must only use the adjustment procedure when the transactions have been charged under IPAC. FPAs must not use the IPAC adjustment procedure to adjust charges that originated under other billing systems.
For IPAC transactions that are rendered for services purchased or supplies shipped, an agency should not consider a charge erroneous simply because it receives the billing statement before the supplies. If the agency subsequently finds that the charge is erroneous, it should make the adjustment at that time. However, the FPA is limited to 90 days, upon receipt or sending of its IPAC transaction, to process the adjustment.
The FPA should first contact its trading partner agency to discuss the error and the considerations underlying each adjustment before adjusting any erroneous charges. The name, telephone number, and email address for the agency's designated contact person appears on the top of each IPAC transaction.
After discussing the charges with their trading partner and arriving at a solution, FPAs may originate an adjustment within IPAC. The agency should access IPAC and selects “IPAC Adjustments” from the menu. Next, it should enter the original document reference number and the originator’s DO symbol to locate the original transaction to be adjusted.
An agency must input an adjustment into IPAC on or before the end of each month for that adjustment to be included in that month’s net total. Otherwise, the adjustment will be reflected in the subsequent month’s net total and CARS Account Statements.
If the agency concludes that the adjustment (or a portion thereof) was improper, it must communicate this to the trading partner agency, preferably by telephone or email. When an agreement is reached, the sender or receiver agency prepares a second IPAC transaction charging the appropriate amount. Agencies cannot modify or reverse an adjustment transaction.
Since IPAC is an online, interactive system, the edit program does not allow entry of invalid ALCs. However, it is possible for an IPAC agency to prepare a transaction to a valid but incorrect ALC. Therefore, erroneous charges only involve differences concerning the dollar amount charged or the transaction itself.
Erroneous charges are corrected by initiating an adjustment transaction. Adjustment transactions can be initiated by a Sender or Receiver agency. FPAs can use adjustments: (1) to reduce (adjust down) the original transaction amount and (2) to process an adjustment against a payment or collection that is 90 or fewer days old.
G-Invoicing supports the brokering of IGTs and facilitates the processing and approval of GT&Cs, Orders, and Invoices, prior to IPAC settlement.
Upon onboarding to G-Invoicing, FPAs submitting Buy/Sell IGTs first need to broker and establish a GT&C with their trading partners. When used in G-Invoicing, the GT&C is a Federal Intragovernmental Data Standards (FIDS)-compliant IAA, centered on a standard set of data elements. Both trading partners’ requirements for a reimbursable agreement should be negotiated through the IAA, as the agreement enables the Requesting Agency and Servicing Agency to agree on the terms of the reimbursable transaction and respective data elements before business begins. IAAs provide business rules authorized by the approving official within each FPA, and provide documentation that each partner has the required statutory authority to be engaging in the intragovernmental business. Trading partners must provide data for all required fields, as well any of their trading partners’ special requirements.
Agencies may include attachments within the GT&C, Order, or Invoice to provide more descriptive information, if necessary. Personally identifiable information (PII) and Classified Data may not be included with IGT reports, including Orders and Invoices. This includes any Miscellaneous, Description, Custom fields, and Attachments.
Fiscal Service encourages trading partners to work closely with one another and to continue to collaborate throughout the transaction lifecycle when establishing IAAs in G-Invoicing. Neither Treasury nor Fiscal Service executes IAAs on behalf of other FPAs. The parties to the agreement must raise disputes/disagreements in a timely manner using the dispute resolution process outlined in TFM Volume 1, Part 2, Chapter 4700, Appendix 10, Section 2, Subsection 2.3.2. Fiscal Service will continue to resolve Intragovernmental Disputes and Major Differences.
Either a Requesting Agency or Servicing Agency may create a GT&C in G-Invoicing. The partner who creates the GT&C is responsible for entering the other partner’s agency name and ALC. Both partners may review and edit the respective data elements and information before approving the document. Buyers and sellers follow the GT&C instructions within G-Invoicing to capture the necessary data elements and to ensure a complete reimbursable agreement. Once approved by both sides, the GT&C will be open for Orders.
The Order is the funding section of the IAA utilized when the Requesting Agency demonstrates a bona fide need for product(s)/service(s) supplied by the Servicing Agency within the time limitations of the Requesting Agency’s appropriations. G-Invoicing contains data fields that the FPAs can use to properly record obligation accounting in their respective accounting systems. Funding information is exchanged by both trading partners, and all required points of contact sign the Order. The Order identifies the specific Requesting Agency requirements for the expected delivery of products and/or services by the Servicing Agency. The Order also identifies the parties’ responsibilities to ensure effective management of the Order and use of the related funds.
When establishing Orders, FPAs should obtain all pertinent accounting information needed to process the transaction within the applicable data elements. The appropriate TAS/BETC should also be included for both agencies to ensure correct reporting on agencies’ CARS Account Statements. The BPN, Description of Products and/or Services, and Bona Fide Need are also required. Other necessary accounting data elements include: revenue recognition methodology, capitalization policy, accrual policy, etc.
Only the Buyer may initiate an Order from an approved GT&C within G-Invoicing, although both partners will enter their respective TAS/BETC and additional accounting information and may make any changes before approving. Both partners’ Program Officials and Funding Officials must approve the Order. After officials from both sides approve the Order, it will be complete and ready to process invoices.
Users entering and/or approving the Order should take extra precautions when entering the TAS/BETC at each Order Schedule line level because the TAS/BETC pre-populates into each invoice and will be reported to CARS.
Only the Seller may initiate an Invoice from an open Order in G-Invoicing. The Invoice will populate TAS/BETC and other accounting data directly from the corresponding Order Schedule Lines. Both partners have the chance to review and make changes to the Invoice Line items. Invoice data elements include quantities, prices, and net payment amounts. After both partners approve, the Invoice is completed and no further action is required on behalf of either side.
G-Invoicing validates the invoice TAS/BETC items and then sends a file of the invoice’s line items to IPAC for funds settlement. Subsequently, the invoice payment/collection is posted to each agency’s respective CARS Account Statement. G-Invoicing will feed the payment and descriptive data to IPAC, so no more user interaction with IPAC will be required for Buy/Sell transactions. FPAs may view the payment/collection transaction history in G-Invoicing, or in the IPAC application’s “IPAC Transaction Report Download” query.
The IPAC database is updated immediately when processing online transactions from G-Invoicing and as close to real time as possible for bulk data file transmissions. While completed transactions appear in real-time in IPAC, transactions will not appear in CARS Account Statements until after validation with SAM. The system automatically issues a unique IPAC document reference number for each completely processed transaction (bulk file users have the capability to assign their own IPAC document reference numbers). IPAC ensures that no two transactions are assigned the same number for the same ALC/DO symbol combination.
FPAs may print/save their transactions from IPAC after the invoice is validated with SAM and accepted in G-Invoicing. In addition, agencies may retrieve their transactions by downloading data directly into their computer systems to aid in the reconciliation process.
No invoice(s) can be processed during the last three business days of the month.
G-Invoicing is a web-based module and no additional software is needed. To access G-Invoicing, users must have the following:
Access to the internet;
A browser with 128-bit encryption and cookies enabled. We recommend users use Internet Explorer for G-Invoicing;
Software to view Portable Document Format (PDF) files (such as Adobe Acrobat Reader™); and
A user ID and password.
To access G-Invoicing users must be enrolled by a user administrator for an FPA Disburser Account. Contact the Treasury Support Center to identify user administrators for each FPA.
G-Invoicing will accompany a new standard set of data standards to enhance consistency of reporting IGT activity, referred to as Federal Intragovernmental Data Standards (FIDS). This new set of elements may be accessed by viewing the Fiscal Service Data Registry. The Data Registry is an authoritative reference for information about government-wide financial data elements – specifically those data elements commonly used across multiple agencies. The purpose of the Data Registry is to promote the common identification, use, and sharing of data and information across the federal government. The registry contains information about definitions, authoritative sources, data types, formats, and uses of common data.
For a complete listing of IGT Buy/Sell data elements, see the Fiscal Service Data Registry.
Fiscal Service requires FPAs to be a Central Accounting Reporting System (CARS) TAS-BETC Reporter in order to leverage G-Invoicing. Before onboarding to G-Invoicing, agencies should work closely with Fiscal Service to make the CARS Reporting transition if they have not already done so. For more information, please refer to the CARS website.
When completing the Order Schedule Lines, users will select a valid TAS/BETC from a drop-down menu of TAS/BETC combinations available to their Agency Identifier (AID). The Buyer and Seller will both select their own TAS/BETC fields, and approve before the Order is completed. The TAS/BETC field will be populated daily from SAM to ensure all TASs available for selection are valid.
Agencies will need to capture the Component TAS format in their internal accounting systems and in IPAC bulk files to leverage G-Invoicing. Reporting transactions in the String TAS format will not be an available option in G-Invoicing.
Agencies may access a list of available and valid Component TAS on the SAM website.
Each FPA's accounting office must verify the accuracy of the transactions retrieved from IPAC and G-Invoicing. FPAs follow standard procedures to record the transactions applicable to their TAS as of the accomplished/transaction date reflected in IPAC and G-Invoicing. CARS serves as the system of records for FBwT activity.
Each agency’s respective Enterprise Resource Planning (ERP) system serves as the system of record for procurement/obligation balances, not G-Invoicing. Users will be able to see remaining obligation balances, but should not use G-Invoicing as the source of record to reconcile total Orders or obligations. Each agency's accounting system will still be the definitive source for financial reporting, Purchase Order reconciliations, and Anti-Deficiency Act (ADA) monitoring.
Agencies must post account transactions to the USSGL as prescribed by Treasury. Please refer to the respective USSGL Implementation Guidance.
Reporting requirements for CARS and GTAS will not be affected by the implementation of G-Invoicing.
All FPAs should monitor their CARS Account Statements and IPAC Reports throughout each month to ensure the accuracy of TAS/BETC reporting. FPAs should also monitor their accounts and TAS/BETC activity for any Buy/Sell transactions not originated to/from their agency or trading partners.
CARS IPAC Reporters are not required to report any monthly IGT receipt or disbursement activity to Treasury since transactions were already reported to Treasury at the time of origination. However, they must reconcile monthly IGT activity to their FBwT for each TAS and identify if the TAS/BETC combination included on the IPAC originations was correct or should be reclassified. FPAs may reclassify transactions in the CARS Classification, Transactions and Accountability (CTA) Module anytime during the reporting month, or on a CTA Statement prior to each month-end close. The Net Total of all reclassifications on the CTA Statement should be $0.00, since transactions are only reclassified between TAS/BETC.
CARS Reporters may view all IPAC Transactions in the CARS CTA Module throughout the month, and reclassify between TASs as necessary before the month-end reporting window closes. All FPAs should print/save reports of all IPAC transactions at the end of each month to reconcile TAS/BETC activity and to prepare for a potential submission of the CTA Statement or SF 1220/1221, if necessary. FPAs may query the “IPAC Transaction Report Download” to retrieve transaction data by ALC and transaction date range. They may also retrieve the “IPAC Support Listing” report of monthly transactions from the Statement of Difference module within CARS.
For further guidance and complete details on end-of-month reporting, please refer to TFM Volume I, Part 2, Chapter 5100, Reconciling Fund Balance with Treasury Accounts.
IPAC provides online data retention for 18 months after a transaction is accepted. Any records older than 18 months must be requested via the Treasury Support Center.
Non-CARS Reporters must report their monthly receipt and disbursement activity to Treasury via the SF 224/CTA, the SF 1218: Statement of Accountability (Foreign Service Account), or the SF 1219: Statement of Accountability. Non-CARS Reporters should refer to TFM Volume 1, Part 2, Chapter 5100, Reconciling Fund Balance with Treasury Accounts, for further guidance on month-end CARS Reporting.
Transactions not reported to CARS by Non-TAS/BETC Reporters will result in an out-of-balance condition. Non-TAS/BETC Reporters should refer to TFM Volume 1, Part 2, Chapter 5100, Reconciling Fund Balance with Treasury Accounts, for further guidance on Statements of Difference and resolving these differences.
CARS Reporters should ensure any transactions posting to the “F3502” SAM default account (transactions originated with an invalid or missing TAS) are reclassified within the established timeframe. For further information and timeframes on clearing the SAM default account balances, please see TFM Bulletin No. 2016-04, Reporting Suspense Account Activity Using F3875 and F3885 and Using Default Accounts F3500 and F3502 as a Central Accounting Reporting System (CARS) Reporter.
CARS TAS/BETC Reporters should reconcile all their monthly cash activity, but cannot receive a SF 6652 Statement of Difference. Since cash transactions are reported to CARS at the time of origination, and no new transactions can be reported to CARS on the CTA submission or SF 1220/1221, the net amount of cash transactions will always agree to the amounts of transactions maintained in Fiscal Service central accounts. The Net Cash Total of the CTA submission or SF 1220/1221 reports must equal $0.00, and only reclassifications to correct transactions between TASs, or to move funds between TASs in non-cash transactions, are submitted.
Reporting requirements for CARS and GTAS will not be affected by the implementation of G-Invoicing.
For the year-end closing process, agencies report all disbursement activity, including IPAC transactions charged to an agency’s ALC, to the applicable TAS for the fiscal year to which it relates.
If, at the end of a fiscal year, a Non-CARS TAS/BETC Reporter does not have sufficient time to determine the amount of an adjustment for its regular monthly reporting, the FPA should report the erroneous charge to its regular appropriation or fund symbol. A TAS/BETC Reporter can reclassify the transaction within the CTA module, but if the agency chooses to correct the erroneous charge, it must coordinate the correction with the charging entity. Once the agency determines the correct amount of the erroneous transaction, it adjusts the transaction through IPAC.
For year-end Federal Agencies’ Centralized Trial-Balance System reporting, the agency should contact Fiscal Service's Budget Reports Division (BRD) to request adjustments and required documentation (see the Contacts section). Treasury reserves the right to review and determine if it will accept the adjustments based on established criteria.
In the event that FPAs are unable to reconcile Buy/Sell differences involving IGT transactions, FPAs should first refer to the terms and conditions agreed up in the signed IAA. If FPAs are still unable to resolve differences with trading partners, they should use the dispute resolution process outlined in TFM Volume 1, Part 2, Chapter 4700, Appendix 10, Section 2, Subsection 2.3.2.
Fiscal Service reserves the right to remove any FPA from IPAC or G-Invoicing, if that FPA fails to comply with the rules and regulations set forth in this TFM chapter.
Direct inquiries regarding the IPAC application to:
Treasury Support Center
1421 Dr. Martin Luther King Drive
St. Louis, MO 63106-3716
You may also visit the Fiscal Service IPAC website.
Direct inquiries regarding Monthly Treasury Reporting of Differences to:
Department of the Treasury
Bureau of the Fiscal Service
Cash Accounting Division
3201 Pennsy Drive, Building E
Landover, MD 20785
Direct inquiries regarding year-end reporting to:
Department of the Treasury
Bureau of the Fiscal Service
Budget Reports Division
3201 Pennsy Drive, Building E
Landover, MD 20785
Direct inquiries regarding the IAA, including Forms 7600A & 7600B, to:
Bureau of the Fiscal Service
Department of the Treasury
PO Box 1328
Parkersburg, WV 26106-1328
You may also visit the IPAC IAA website.
Direct inquiries regarding G-Invoicing, including FIDS and the G-Invoicing Release Schedule, to:
Bureau of the Fiscal Service
Department of the Treasury
PO Box 1328
Parkersburg, WV 26106-1328
You may also visit the Fiscal Service G-Invoicing website.