Version 2.0 Last Update: 5/25/2023

Page 1 of 16

NONCONFIDENTIAL // EXTERNAL

Government Invoicing (G-Invoicing) 

System Integration Guide 

Document Version 2.0

Table of Contents

How to Use This Document ............................................................................ 2

1 Overview ................................................................................................. 2

1.1 G-Invoicing Business Overview................................................................................ 2

1.2 G-Invoicing Technical Overview .............................................................................. 3

2 Services and Options................................................................................ 6

2.1 Manual Data Imports................................................................................................. 7

2.2 Manual Data Exports................................................................................................. 7

2.3 Automated “Push” Services....................................................................................... 7

2.4 Automated “Pull” Services........................................................................................ 9

2.5 Use Cases.................................................................................................................12

Appendix B: Glossary ...................................................................................15

Appendix C: Revision History ........................................................................16
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 2 of 16

NONCONFIDENTIAL // EXTERNAL

How to Use This Document

The purpose of the G-Invoicing System Integration Guide is to communicate how Federal Program Agencies 

(FPA) may utilize automated data exchanges to communicate IGT Buy/Sell activities to/from G-Invoicing. This 

document describes the automated data exchanges, provides references to additional information, and details steps 

needed to establish system interfaces with G-Invoicing.

The document is intended for FPA technical resources and/or their vendors, who will be working with the GInvoicing Team to implement automated interfaces to/from G-Invoicing. This guide is organized into three

sections:

Section 1: Overview describes the business purpose and technical capabilities of G-Invoicing at a high level. 

Additional business information is available on the G-Invoicing website. 

Section 2: Services and Options define the various resources available through G-Invoicing’s services. This 

information will be used to select the most effective interface options for each agency. 

Appendices provide additional information such as points of contact and glossary of terms. 

For instructions on how your agency can begin preparing for G-Invoicing, see the Playbook on the G-Invoicing

website. 

1 Overview

1.1 G-Invoicing Business Overview

G-Invoicing is a Fiscal Service application designed to improve the quality and reliability of Intragovernmental 

Transactions (IGT) Buy/Sell data in support of increased transparency and enhanced government-wide financial 

management. G-Invoicing is the government’s long-term sustainable solution for Buy/Sell transactions. The 

application is required to be used by all FPAs and is offered at no charge.

G-Invoicing handles General Terms and Conditions (GT&C) Agreements, Orders, Performance/EZ. It also will 

initiate fund Settlement for Buy/Sell transactions based on Performance/EZs. As each step of the Buy/Sell 

lifecycle is implemented in G-Invoicing, the information sharing between trading partners improves the accuracy 

of accounting and reporting. Once trading partners begin entering Orders in the G-Invoicing system, data in the 

common repository will be leveraged to support improved accuracy in accounting and reporting. At the time of 

the payment or collection, the Performance/EZs and Settlement steps will be fully supported by brokered GT&Cs 

and the accounting details included on the Orders. 

With the increased sharing of information in a common repository coupled with the agreement between trading 

partners at each step of the lifecycle, a decrease in Buy/Sell intragovernmental elimination differences is 

expected. If an intragovernmental elimination difference still occurs, G-Invoicing will provide a repository of 

detailed information to research the difference, which will help both the trading partners and Fiscal Service 

resolve the difference.
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 3 of 16

NONCONFIDENTIAL // EXTERNAL

1.2 G-Invoicing Technical Overview

Figure 1 (G-Invoicing High-Level Logical Architecture) depicts the technical architecture that provides the 

security and functionality necessary to support the various G-Invoicing services. 

The technical architecture supports the following major functions: 

• API Gateway • Authentication Subsystem

• E-Mail Server • User/System Directory

• User/System Provisioning • G-Invoicing Database 

• Business Logic

G-Invoicing utilizes secure Representational State Transfer (REST) web services to exchange data with agency 

systems. Agency clients initiate G-Invoicing services as needed. 

Figure 1. G-Invoicing High-Level Logical Architecture
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 4 of 16

NONCONFIDENTIAL // EXTERNAL

1.2.1 API Gateway

An API gateway is used to secure and accelerate Web Services processing. This gateway provides a variety of 

functionality, including terminating the server side SSL (Secure Sockets Layer) connection between a web service 

client and G-Invoicing. SSL provides a two-way connection requiring both a client and a server digital certificate 

to authenticate both ends of the connection. Without a valid digital certificate, the API gateway will not establish 

the connection between G-Invoicing and the agency client, and access to services will be denied.

Once the two-way SSL connection has been established, the API Gateway provides the same client digital 

certificate used to establish the connection to the Authentication System, which authenticates the client to the 

application/web service.

1.2.2 Authentication Subsystem

The Authentication system utilizes the client digital certificate to look up the web services client in the 

User/System directory, by subject name. Finding the web services client in the User/System directory 

authenticates the client to the web service. Otherwise the client is not authenticated and the Authentication 

System instructs the web services client that it is not authorized for G-Invoicing services.

G-Invoicing requires a Partner ID be established for each agency client. The Partner ID will be assigned a digital 

certificate to access G-Invoicing through the API Gateway. The Partner ID may represent one-to-many agency 

systems, each assigned a System ID. A single System ID can only access one agency account, but a single Partner 

ID can point to many System IDs spread across multiple agency accounts. Permissions for System IDs (i.e., roles 

and data access) are controlled by agency User Administrators. 

Figure 2. Partner ID/System ID Relationship

G-Invoicing Support personnel are primarily responsible for working with FPAs to set up new Partner IDs, digital 

certificates and System IDs. Your Agency Implementation Team (AIT) resource can assist in the steps necessary 
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 5 of 16

NONCONFIDENTIAL // EXTERNAL

to work with the G-Invoicing team to set up automated test and production users. Please refer to the G-Invoicing 

Playbook (on the G-Invoicing website) if your agency has not yet been assigned an AIT representative. 

1.2.3 E-Mail Service

The e-mail service is used to distribute notifications via e-mail. User Administrators may subscribe a user to 

receive notifications for one or more document types (e.g., GT&C, Order, Performance, EZ). Each time a 

document changes status or an attachment is added/removed, an e-mail will be sent to any subscribed user that has 

access to that document and has a corresponding role for the specific document status changes. See the 

Administration User Guide for instructions on how to subscribe a user. This is available within the application 

under the Help menu. 

1.2.4 User Access

The CAIA Federation Service is a web-based Federation Hub which facilitates a "Common Approach to Identity 

Assurance", also referred to as "CAIA".

The CAIA Federation Service enables Federated Service Provider (SP) applications to accept authenticated user 

credentials from multiple external Federated Identity Providers (IDP) and Credential Service Providers (CSP). 

Federated Service Provider applications only need to configure federated authentication with the CAIA 

Federation Service. The CAIA Federation Service facilitates authenticating Federated SP application users via 

external Federated IDPs/CSPs.

1.2.5 User/System Provisioning Authorization

Agency administrators must properly authorize system (and human) users before they access G-Invoicing. 

Administrators create and manage organizational structures called Org Groups that are used control access to GInvoicing documents. User Administrators assign roles to users to grant read/write privileges and assign Groups

to control access to documents. These assignments must be made for System IDs before G-Invoicing web services 

will allow update and retrieval of documents. System IDs gain access to all Org Groups at or below the Org 

Group they’re assigned. This allows a system to manage all documents within an Account without having to be 

assigned multiple Org Groups.

1.2.6 G-Invoicing Database

The G-Invoicing database is a repository that contains agency configuration and user data, as well as the 

transactional data exchanged between IGT Buy/Sell trading partners. The database is fully replicated and 

clustered to handle scalability and fault tolerance requirements.

1.2.7 Business Logic

Contained within the G-Invoicing web application is the business logic that drives G-Invoicing capabilities. The 

business logic is broken out into the following areas. 
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 6 of 16

NONCONFIDENTIAL // EXTERNAL

1.2.7.1 Central administration functions are used by G-Invoicing Operations personnel to establish new agency 

accounts. Initial agency configurations are established and Master Administrators are created and 

maintained. FPAs are not granted access to the Central administration functions. 

1.2.7.2 Agency administration functions allow agency users holding privileged roles to manage their 

organizational structure, manage users and grant users access to roles and organizations. 

1.2.7.3 Requesting and servicing agency functions allow users (human or system) to manage, approve and view 

documents related to IGT Buy/Sell. Documents include the General Terms and Conditions, Orders, 

Performance and 7600EZs, along with any attachments to these documents. 

Supporting the IGT buy/sell and administrative functions, G-Invoicing currently provides Application 

Program Interfaces (APIs) to authorized client users:

1. Push Order (JSON & XML) allows clients to upload Orders to so they can be shared with their 

trading partners.

2. Push Performance (JSON & XML) allows clients to upload Performance data to G-Invoicing.

3. Push 7600EZ (JSON) allows clients to upload 7600EZ data to G-Invoicing.

4. Push Attachment (JSON & XML) allows clients to attach files to Order, Performance and 7600EZ

documents.

5. Pull GT&C (JSON & XML) allows clients to extract new and updated GT&C agreements. 

6. Pull Order (JSON & XML) allows clients to extract Orders and attachments submitted by their 

trading partners. 

7. Pull Performance (JSON & XML) allows clients to extract Performance transactions. 

8. Pull 7600EZ (JSON) allows clients to extract 7600EZ transactions.

9. Pull Attachment (JSON & XML) allows clients to download files which have been attached to 

GT&C agreements, Orders, Performance or 7600EZ documents. 

10. Pull Organization (JSON) allows clients to extract Org data used to create Orders and 7600EZs:

o Get Accounts

o Get Groups in an Agency Account

o Get Groups for a GT&C

o Get TAS-BETCs for a Group

11. Pull Features (JSON) allows clients to extract which Account supports different G-Invoicing 

features. Turning features on our Account-wide and allows for additional functionality within the UI 

and APIs. Both trading partners must have a feature activated to be able to use the feature within GInvoicing. This API gives out that information to clients. 

12. Pull Remittance (JSON) allow clients to extract data that has been settled. 

2 Services and Options

This section provides an overview of the G-Invoicing service and connectivity options for agencies. This 

information can be used to determine how best to interact with G-Invoicing. 
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 7 of 16

NONCONFIDENTIAL // EXTERNAL

Agencies may also choose to automate their own import procedures, but software releases which often include UI 

changes may interrupt these types of robotic process automation (RPA) or “bot” interfaces. Wherever possible, 

agencies are encouraged to automate data updates and extractions by taking advantage of the APIs, which will be 

maintained for backwards compatibility. G-Invoicing reserves the right to modify the UI in any release, but 

agencies will be given time to move off of older versions of the APIs.

2.1 Manual Data Imports

2.1.1 Orders may be imported by Administrators.

G-Invoicing does allow administrators to import Orders as of the 5.0 release, this is a feature that must be 

activated by a Master Administrator to be available within an Account, this has been added to support the In-flight 

mandate to allow agencies an alternative to manually creating Orders through the user interface (UI). See the 

Administrator Guide within the G-Invoicing application for further details. 

2.2 Manual Data Exports

2.2.1 User Profiles may be exported by User Administrators. 

2.2.2 GT&Cs may be filtered and exported by users assigned GT&C Viewer permissions. See the User Guide 

within the G-Invoicing application for further details.

2.2.3 Orders may be filtered and exported by users assigned Order Viewer permissions. See the User Guide 

within the G-Invoicing application for further details.

2.2.4 Performance transactions may be filtered and exported by users assigned Order Viewer permissions. 

See the User Guide within the G-Invoicing application for further details.

2.2.5 7600EZ transactions may be filtered and exported by users assigned 7600EZ permissions. See the User 

Guide within the G-Invoicing application for further details.

2.2.6 Performance/7600EZ transactions may export via the Reports section. This allows a user to filter and 

export Order & Performance Data and/or 7600EZ together in a single report. User will need at least Order

Viewer permission to export Order/Performance Data or 7600EZ viewer to export 7600EZ data. See the 

User Guide within the G-Invoicing application for further details.

2.2.7 Feature Management Reports provides access to a report to indicate an Accounts readiness for a 

specific Feature with G-Invoicing. See the User Guide within the G-Invoicing application for further 

details.

Additional manual data exports are planned and will be described in Release Notes and User Guides as they 

become available. G-Invoicing is intended to “improve the quality and reliability of IGT Buy/Sell data”, so an 

emphasis is being placed on data extraction in common formats (e.g., CSV) for agency use.

2.3 Automated “Push” Services

G-Invoicing allows agency clients to upload data and attachments through automated “Push” services. These 

APIs allow agencies to automate uploading of new and updated documents (e.g., Order, Performance, or 7600EZ) 
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 8 of 16

NONCONFIDENTIAL // EXTERNAL

for their trading partners to access. Attachment services allow agency clients to stream attachments to GInvoicing to be associated with these documents. The G-Invoicing-System Interface Specifications - Push (Push 

GSIS) describes these services in detail, including business rules that will be enforced.

The “Push” services utilize XML or JSON to carry payloads and to format any request and response messages.

XML schemas may be found on Treasury’s Data Exchange Listing under G-Invoicing Downloads. Look in the 

accounting file folder for the schemas. Supporting elements may be found in the Core file folder. JSON format 

and property names/values may be found on the G-Invoicing website. All APIs are available using either XML or

JSON. It is highly recommended that a new system interfacing with G-Invoicing utilizes the JSON APIs.

It is important to note that not all trading partners will be automated, and some agencies may choose to automate 

parts of their process (e.g., Orders, Advances through API) but not others (e.g., Performance reported via UI).

Another consideration is that agency User Administrators control the permissions and access by system users. 

Best practice is to grant update access to system or human users (not both) for the same document type. For 

example, if Orders are pushed through the API, human users should not be permitted to update Orders via the UI 

in G-Invoicing to ensure Agency systems remain in sync with G-Invoicing.

2.3.1 API Resources

• Push Order is an API which allows agency clients to contribute their respective portions of the Order 

documents. The requesting/servicing agency can initiate a request to the New Order resource. Once the 

servicing/requesting agency has pulled down a new Order from G-Invoicing, that agency client makes the 

next call to the Update Order resource. The remainder of the Order lifecycle is a series of Pull requests 

followed by Update Order requests until the requesting agency finally closes the Order. There are 

situations in the Order lifecycle where an agency request may be denied because it is not that agency’s 

turn to act. The System Mapping & Validation Rules document (SM&VR), which is accessible on the GInvoicing resource website shows data requirements for each state transition. 

• Push Performance is an extension of the Push Order API which allows agency clients to report 

Performance (e.g., Delivered/Performed, Received/Accepted) against an Order. Unlike Orders, 

Performance transactions are stateless (i.e., there is no lifecycle). Each partner independently sends 

requests to the New Performance resource. The requesting agency always reports Performance in 

response to the servicing agency’s Performance. Data requirements for Performance may be found 

directly in the Federal Intragovernmental Data Standards for Performance (Performance FIDS) on the GInvoicing resource website.

• Push 7600EZ is an API which allows agency clients to report 7600EZs (e.g., Invoices, Reversed, 

Accepted, or Rejected) against an GT&C. Like Performance transactions, these too are stateless (i.e., 

there is no lifecycle). Each partner independently sends requests to the New 7600EZ resource. The 

servicing agency always reports Invoices or Reversed transactions and the requesting responds to 

Servicing agency’s Invoice transactions. Data requirements for 7600EZ may be found directly in the 
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 9 of 16

NONCONFIDENTIAL // EXTERNAL

Federal Intragovernmental Data Standards for 7600EZ (7600EZ FIDS) on the G-Invoicing resource 

website.

• Push Attachment is an API which allows agency clients to invoke the New Attachment resource or the 

Delete Attachment resource. Only the partner that added an attachment will be allowed to delete it. The 

attachment resources work the same for Order, Performance or 7600EZ attachments.

2.3.2 Timing

G-Invoicing recommends each agency determines the best approach for their estimated volume and tailor their 

call frequency and concurrent calls to that estimated volume. It is not recommended to push less than 15 minutes 

and in some cases 15 minutes may be excessive for some agencies that have low volume. Hourly or longer may 

be more aligned with their expectations of documents flowing through G-Invoicing. 

2.4 Automated “Pull” Services

G-Invoicing allows agency clients to download data and attachments through automated “Pull” services. There 

are two types of Pull APIs supported, one for downloading IGT buy/sell documents (i.e., GT&C, Order, 

Performance, or 7600EZs) that are new, have been updated by their own users, or their trading partners. All APIs 

are available using either XML or JSON. It is highly recommended that a new system interfacing with GInvoicing utilizes the JSON APIs. 

The other type of Pull API is for extracting administrative data (e.g., Organizations, Feature Services). Each of 

these JSON-based services is described by its own interface specification on the G-Invoicing website (e.g., Pull 

Remittance Advice). In some cases, the specifications will be published before the services are available, so that 

agencies and their software providers may develop their side of the interface in advance.

The client system should store data pulled for future use, but there may be a need to refresh data for business 

needs. Most likely this is due to Admin Change or Modification to a GT&C or an organization change. These may 

affect the groups and data available to create an Order or 7600EZ from a GT&C. It is highly recommended to 

minimize the pull frequencies to only request updated data where it’s determined that the data may have been 

changed by a last modified timestamp or an organization change is completed by a Trading partner or your own 

account. Please see the below recommendations for accessing Group data for Orders & 7600EZ Invoices through 

APIs.
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 10 of 16

NONCONFIDENTIAL // EXTERNAL

Best Practices for utilizing the Org API

• Modification or Admin Changes to a GT&C

o Increment the Last Modified Date/Time, which should be used to pull updated data using the 

GT&C List (#4 API). 

o It’s recommended that a system pulls the GT&C Detail (#5 API).

o It’s recommended that a system pulls the Get Groups for GT&C (#6 API).

o It is highly recommended that a system stores this data and doesn’t rely on GInvoicing for every Order or 7600EZ Invoice creation within their system.

• Organizational Group Changes

o It’s recommended that a system pulls the Get Accounts (#1 API) no more than once a day. 

 By using the lastModifiedDateTime parameter G-Invoicing will only return Accounts 

that have been updated since the last time the system has pulled data from this endpoint.
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 11 of 16

NONCONFIDENTIAL // EXTERNAL

o If using the Get Groups for Account (for either their own Account or Trading Partners) we 

recommend storing the data and only repulling if the account appears in the Get Accounts 

response. 

 This would pull in any new, updated, or deactivated Org groups due to an organization 

change.

As G-Invoicing matures this data will become more and more static over time, but there are always a potential for 

Organizational changes to occur governmentwide.

2.4.1 Parameters

Agencies are encouraged to pull only documents that have changed since the last successful exchange. Other use 

cases are possible, depending on the Parameters (aka, filters) supplied in the request. The interface specifics 

describe which parameters apply to each API. Some of the parameters are described below:

• Agency Location Code may be supplied in cases where the System ID has access to multiple ALCs.

• Status allows agency clients pull documents of a particular status (e.g., Open). This applies only to 

document types which support multiple statuses, such as GT&C and Order.

• Last Modified Date Time is used to pull recent changes and additions. It is up to the agency system to 

track the last successful date/time for each type of Pull request. Best practice is to pull changes that have 

occurred since the last successful exchange.

• System ID identifies the specific system that the interfacing Partner ID represents for the request. The 

Partner ID is certified to represent multiple agency systems. The System ID is used to limit data access 

and permissions. See G-Invoicing Technical Overview (above) for information on user authentication and 

authorization. See section on Use Cases below for ideas on a single point of integration.

• Transfer Date is used for the Pull Remittance Advice API to limit the data to a specific settlement date. 

This parameter is required, and agencies are encouraged to pull Remittance Advice daily. 

2.4.2 Timing 

G-Invoicing recommends each agency determines the best approach for their estimated volume and tailor their 

call frequency and concurrent calls to that estimated volume. It is not recommended to call less than 15 minutes 

and in some cases 15 minutes may be excessive for some agencies that have low volume. Hourly or longer may 

be more aligned with their expectations of documents flowing through G-Invoicing. 

API Resources

Agency clients pull changes from G-Invoicing by invoking three API resources. Detailed descriptions and 

examples of all the API resources for pulling documents and attachments from G-Invoicing may be found in 

section 3 of the G-Invoicing-System Interface Specifications – Pull. In summary, the following steps are taken:

1. <Document Type> List (e.g., GT&C List) returns a subset of data in XML or JSON from the requested 

document type, qualified by access permissions and parameters. The initial request to G-Invoicing will 

return a list of GT&C’s, Orders, Performance or 7600EZ based on the API resource invoked and the 

user’s permissions. The list returned in the response will contain metadata about each document as well as 

the link (URL) to request the individual documents in a subsequent request.

2. Single <Document Type> by ID allows agency clients to extract all non-empty data elements in the 

XML or JSON payload for a specific instance of a document (e.g., Order Number O1903-123-234-

000345), identified by the URL found in the document list. The document returned will contain metadata 
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 12 of 16

NONCONFIDENTIAL // EXTERNAL

about attachments (if any exist) associated with the document. This metadata contains links (URLs) for 

agency systems to pull individual attachments.

3. Single Attachment by ID allows agency clients to download a specific attachment, identified by the 

URL found in the document payload. 

The data sets returned by the JSON-based APIs are smaller (relative to the XML-based interfaces), and there are 

no variably sized attachments involved, so these services are provided in one synchronous step consisting of a 

request from the client and a response by G-Invoicing. 

2.4.3 Upgrades to System Interfaces 

There may be occasions when system interfaces will need to be enhanced by G-Invoicing, but those same services 

are being used by agency systems. APIs and schemas will be versioned as follows:

• Versions that are not backwards compatible will be assigned a major version number (e.g., v2.0, v5.0). 

• Versions that are backwards compatible will be assigned a minor version number (e.g., v2.1, v3.3).

• Versions that do not materially change the interface will be assigned a “dot-dot” version (e.g., 2.3.1). 

These typically involve updates to documents (e.g., data standards) supporting the APIs.

Version numbers of APIs and schemas are separate from software release numbers. For example, the 2.1 release 

of the G-Invoicing application introduces a new 1_0 version of the Pull (XML-based) API carrying a 2.0 version 

of the GT&C payload (XML).

Clients of XML-based APIs should not validate XML payloads returned in G-Invoicing’s responses to Pull API 

requests. This is because G-Invoicing may change to a new XML schema version while keeping the API version 

the same. For example, the 3.2 release of G-Invoicing introduced a new (2.1) version of the GT&C schema, 

adding optional Requesting and Servicing Group Name(s) to the XML, while keeping the Pull API at version 1_0. 

If a client were to validate the v2.1 XML against the v2.0 schema, the presence of either Group Name would have 

rendered that XML invalid. 

2.5 Use Cases

2.5.1 Summarizing Data

It’s possible that servicing agencies with their own systems or portals may be collecting very detailed 

Order information from their customers. GSA, for example, may possess an Order for office supplies 

containing many line items that all reference the same line of accounting. GSA’s customer has access to 

this detail data through their portal. Once the supplies have been delivered, G-Invoicing does not need all 

this detail data to settle this transaction. The various line item amounts may be summarized onto a single 

line item for the G-Invoicing Order bearing the description “office supplies” (for example). The details 

may remain in the servicing agency’s system or made available through an Order or Performance 

attachment sent to G-Invoicing. Once the servicing agency reports Delivered/Performed against the 

Order, the requesting agency may (2-way) match the Delivered/Performed to the Order and either close 

the Order or report Received/Accepted to dispute the reported Delivered/Performed.

2.5.2 Mixing Automated and Manual Interfaces

G-Invoicing allows Master Administrators to manage data access for System IDs, just as User 

Administrators set permissions for human users. As previously mentioned, assigning the same (update) 
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 13 of 16

NONCONFIDENTIAL // EXTERNAL

roles and org Groups to human and system users is strongly discouraged. (Assigning view-only roles to 

both human and system users is perfectly safe). 

System IDs are treated differently than human users in that they are granted access to their assigned 

Group(s) and (implicitly) all descendant Groups for the Order Manager/Approver role. This eliminates the 

need for Master Administrators to grant System IDs explicit access to every Group in the organization to 

create Orders and Performance. That convenience must be tempered when the Master Administrator does 

not want the System ID to have access to all Groups. 

Agencies may decide to mix and match roles/Groups by business line. For example, the creation of 

Orders may be automated for several business lines (whereby Partner and System IDs are established for 

full automation), but a smaller business line may want users to maintain their Orders directly in GInvoicing through the user interface. To support this use case the business lines must be separated within 

the organization, and the System ID only assigned to the portions of the organization which are

automated. 

A representative from the G-Invoicing Agency Implementation Team (AIT) can help you devise the 

appropriate strategy to mix human and system users. Please refer to the G-Invoicing Playbook (on the GInvoicing website) if your agency has not yet been assigned an AIT representative.

2.5.3 Download Documents by Status 

Previously it was recommended that agency systems pull only documents and attachments which are new 

or have changed since a particular date/time. This method is recommended because it keeps 

communications to a minimum. Other options are possible, however.

An agency client could choose to pull a list of documents by a specific status on a regular basis. For

example, a servicing agency could pull Orders that are in SP2 (Submitted to Partner 2) status each 

evening, followed by a call to pull only Orders in REC (open) status. That agency could compare those 

two lists to what they have on file, making updates as needed. If a known Order falls off both of these 

lists, it can be assumed that no further action is required for that Order. If a new Order appears on the 

SP2 list, the agency client may then pull the entire Order. 

An agency client could choose to pull a list of all documents of a specific type (e.g., GT&C), although 

this is not recommended. That list will contain all GT&C agreements for that agency, regardless of status. 

That means that closed GT&Cs will be on the list, no matter how old they are. Obviously, such a list can 

grow very large, depending on the age of the system and the number of documents handled annually. 

2.5.4 Attachments on Demand

Data retention policies have not yet been established, but G-Invoicing will not delete data or attachments 

until such policies are defined and reviewed by their customer base. Agencies may choose to rely on GInvoicing to store complete document data and attachments so they can be accessed only when needed. 

For example:

• Metadata describing the existence of an attachment (e.g., file name, size, type, URL) can be saved 

in an agency system so that a specific attachment can be retrieved by an agency user on demand. 

• Data describing the existence of a GT&C agreement (e.g., GT&C number, title, status, URL) can 

be saved in an agency system so a user of that system may select a valid GT&C from a drop-
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 14 of 16

NONCONFIDENTIAL // EXTERNAL

down list or search facility. If that agency user wishes to view the full GT&C, it can be retrieved 

from G-Invoicing by the agency system at that time. 

Relying on G-Invoicing to store complete document data and attachments will reduce an agency’s data 

and file storage requirements, but may greatly increase system-to-system communications with GInvoicing if that information is repeatedly requested. Agencies (and their vendors) are encouraged to use 

their best judgement when designing a solution.

 

Appendix A: Resources 

Topic Address

Additional Information on G-Invoicing https://www.fiscal.treasury.gov/g-invoice/ 

Treasury Financial Manual https://www.fiscal.treasury.gov/g-invoice/resources.html#tfman 

System Interface Specifications https://www.fiscal.treasury.gov/g-invoice/resources.html#interface 

Federal Intragovernmental Data 

Standards / Data Elements

https://www.fiscal.treasury.gov/g-invoice/resources.html#standards 

System Mapping and Validation Rules https://www.fiscal.treasury.gov/g-invoice/resources.html#mapping 

Agency Implementation Plan/Template https://www.fiscal.treasury.gov/g-invoice/training.html 

Frequently Asked Questions https://www.fiscal.treasury.gov/g-invoice/faqs.html 

G-Invoicing Playbook https://www.fiscal.treasury.gov/files/g-invoice/ginvoicingplaybook.pdf 
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 15 of 16

NONCONFIDENTIAL // EXTERNAL

Appendix B: Glossary

Agency Account – a logical segmentation of G-Invoicing representing an agency organization that is configured 

and administered together

Agency Implementation Team (AIT) – is a Program resource assigned to your Agency to assist in planning, 

training and on-boarding activities necessary to implement G-Invoicing.

ALC (Agency Location Code) – identifies a virtual or physical location of a Federal agency

API (Application Program Interface) – is a web service which allows agency clients to push data to and pull data 

from G-Invoicing

Backwards Compatible – the practice of introducing a new version of software (e.g., API) that is interoperable 

with older versions

Certificate – see Digital Certificate

Client – is an authorized system user that initiates a call to one of G-Invoicing’s API services

CSV (Comma Separated Value) – is a data format commonly used as input to spreadsheet applications

Digital Certificate – is an electronic "passport" that allows an agency system to exchange information securely 

over the Internet using the public key infrastructure (PKI)

FPA (Federal Program Agency) – is a government organization that uses G-Invoicing to report IGT activities

Group – describes a single node in an Organization, to which ALCs, TAS Filters, users and documents are 

assigned

GSIS (G-Invoicing System Interface Specification) – is a detailed document describing a system-to-system 

interface

IGT (Intragovernmental Transactions) – describes the buying/selling of goods/services between agencies

JSON (JavaScript Object Notation) – is a lightweight data-interchange format, easy to read, parse and generate

Organization – describes the use of a hierarchical structure to control data access, with each node in the tree being 

called a Group

Partner ID – a user set up by G-Invoicing (with a digital certificate) under which System IDs are established

Push Service – an API used by agency clients to upload permitted data into G-Invoicing

Pull Service – an API used by agency clients to extract permitted data from G-Invoicing

Requesting Agency – a trading partner acting as the “buyer” in an IGT Buy/Sell relationship

Service – see API

Servicing Agency – a trading partner acting as the “seller” in an IGT Buy/Sell relationship

SSL (Secure Sockets Layer) – provides security and data integrity for communications over the Internet

Synchronous – meaning that that client code execution will wait for a response from the API before continuing

System ID – a user set up by G-Invoicing (subordinate to a Partner ID) and authorized by an agency User 

Administrator to exchange data with G-Invoicing

TAS Filter – a set of TAS component values assigned to a Group to govern the assignment of TAS to Orders
G-Invoicing System Integration Guide

Version 2.0 Last Update: 5/25/2023

Page 16 of 16

NONCONFIDENTIAL // EXTERNAL

Trading Partner – an agency that buys goods/services from or sells goods/services to another federal agency

UI (User Interface) – is a web-based application hosted on the TWAI for authorized user to access G-Invoicing

URL (Uniform Resource Locator) – is a Web address

User – in this context is a human who has been authorized to access the G-Invoicing user interface, unless

specified (e.g., system user)

Web Service – see API

XML (eXtensible Markup Language) – is a self-describing format of data

Appendix C: Revision History

Ver. Revised Description

0.1 1/25/2019 Initial version 

0.2 2/4/2019 Updates following internal FRB feedback 

0.3 4/2/2019 Replaced section 3 with references to G-Invoicing Playbook

1.0 5/13/2019 Published first version on G-Invoicing website

1.1 5/8/2020 Updated to include: (1) changes to permissions for r4.0, and (2) 

additional (JSON based) pull APIs 

1.1.1 5/18/2020 Removed links to user guides (no longer on public website).

Updated access to Trading Partner Directory (in MAX). 

Updated section 2.5.3 Mixing Automated and Manual Interfaces.

1.1.2 6/1/2020 Minor changes after internal review

1.1.3 6/9/2020 Removed highlights showing recent changes

2.0 5/24/2023 Updated entire document for JSON APIs, 7600EZ APIs, new Org 

endpoint and other general updates about user provisioning, group 

access, and removal of TWAI references. Updated interface timing 

and recommendations for call frequency and Org API call design.