G-Invoicing System Integration Guide
Government Invoicing (G-Invoicing)
System Integration Guide
Document Version 1.1.4
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 ................................................................................................. 6
2.2 Manual Data Exports ................................................................................................. 6
2.3 Automated “Push” Services ....................................................................................... 6
2.4 Automated “Pull” Services ........................................................................................ 8
2.5 Use Cases ................................................................................................................... 9
Appendix A: Resources .................................................................................. 12
Appendix B: Glossary .................................................................................... 13
Appendix C: Revision History ......................................................................... 14
G-Invoicing System Integration Guide
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 G-
Invoicing 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 will manage the receipt and acceptance of General Terms and Conditions (GT&C) Agreements,
Orders, and Performance. It also will initiate fund settlement for Buy/Sell transactions based on performance. 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. The General Terms and Conditions (GT&C) will
begin facilitating trading partner communication in a common repository. This will support the alignment of
processes between trading partners and the use of a common set of terms, which will replace the various manual
forms used today like the Fiscal Service Form 7600A/B, Military Interdepartmental Purchase Request (MIPR),
etc. 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 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
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
1.2.1 API Gateway
An API gateway is used to secure and accelerate XML and 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 the Treasury Web Application Infrastructure (TWAI). 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 XML 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
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.
G-Invoicing System Integration Guide
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). 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. See the Administration User Guide for instructions on how to subscribe a user.
1.2.4 User/System Directory
The User/System directory is an LDAP-based directory that contains information for all users and systems
requiring access to Treasury infrastructure and applications. Once a user or system is authenticated, authorization
information from the LDAP is provided to the application for additional security and other application
functionality.
1.2.5 User/System Provisioning Authorization
Agency administrators must properly authorize system (and human) users before they access G-Invoicing.
Organizational Administrators create and manage organizational structures containing Groups that are used
control access to G-Invoicing 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. Group access for System IDs is applied top-
down, such that a System ID will have access to all Groups which are descendants of the assigned Group(s).
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.
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 and
Performance, along with any attachments to these documents.
Supporting the IGT buy/sell and administrative functions, G-Invoicing currently provides ten
Application Program Interfaces (API) to authorized client users:
1. Push Order allows clients to upload Orders to so they can be shared with their trading partners.
2. Push Performance allows clients to upload Performance data to G-Invoicing.
3. Push Attachment allows clients to attach files to Order and Performance documents.
4. Pull GT&C allows clients to extract new and updated GT&C agreements and attachments.
5. Pull Order allows clients to extract Orders and attachments submitted by their trading partners.
6. Pull Performance allows clients to extract Performance transactions and attachments.
G-Invoicing System Integration Guide
7. Pull Attachment allows clients to download files which have been attached to GT&C agreements,
Orders or Performance transactions.
8. Pull Organization allows clients to extract Groups, ALCs and TAS that can be used to create
Orders.
9. Pull Remittance Advice will allow clients to extract data that has been settled.
10. Pull Accruals will allow clients to extract data to be reported as IGT buy/sell accruals.
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.
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
G-Invoicing does not currently allow any importing of data by users. There are plans to support importing of
Users in the future.
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.
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) for their
trading partners to access. Attachment services allow agency clients to stream attachments to G-Invoicing to be
associated with these documents. The G-Invoicing-System Interface Specifications - Push describes these
services in detail, including the business rules which are enforced.
G-Invoicing System Integration Guide
The “Push” services utilize XML 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.
Sample XML payloads may be found on the G-Invoicing website for each XML schema supported. Examples of
API requests may be found in the System Interface Specifications.
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 users 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 agency can initiate a request to the New Order resource. Once the servicing
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.
Diagram 2 of the Orders/Performance Push shows the state transitions possible and Table 2 shows all
possible types of Push Order requests. The System Mapping & Validation Rules document (SM&VR)
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).
• 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. These
two attachment resources work the same for Order and Performance attachments.
2.3.2 Timing
Documents and attachments are pushed individually to G-Invoicing. In other words, there is no mechanism to
push “batches” of Orders or Performance. Further, the interface is synchronous such that the agency client must
wait for a response from G-Invoicing, which will include the data needed to retrieve the document or attachment
at a later time. G-Invoicing can support simultaneous requests.
It is up to the agency to determine how frequently and when to send updates to G-Invoicing. Agencies are
encouraged to push updates throughout the day, as they occur. If batch processing is necessary (e.g., Orders for
the day are imported from another system at close of business), agencies are encouraged to consult with G-
Invoicing Support by opening a request through the Treasury Support Center (1-877-440-9476) before scheduling
recurring jobs to push hundreds or thousands of documents to G-Invoicing.
G-Invoicing System Integration Guide
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 or
Performance) that are new or have been updated by their own users or their trading partners. The G-Invoicing-
System Interface Specifications - Pull describes these XML-based services in detail.
The other type of Pull API is for extracting administrative and reporting data (e.g., Organizations, Accruals). 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.
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
It is up to the agency to decide how frequently to invoke Pull services. Choosing “odd” times (e.g., hourly at 37
minutes after the hour) and/or “off hours” (i.e., not mid-morning or mid-afternoon) may be the best choice to
reduce contention, but is not required. All of G-Invoicing’s APIs are synchronous, so if every agency decides to
pull all their changes once a day at 2:00 pm ET, the wait times will be longer.
2.4.3 API Resources (XML-based)
Agency clients pull changes from G-Invoicing by invoking three API resources within the XML-based APIs.
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 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 or Performance 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.
G-Invoicing System Integration Guide
2. Single <Document Type> by ID allows agency clients to extract all non-empty data elements in the
XML 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 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.4 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 Integration Point(s)
An agency may have separate systems for procurement, fulfillment and/or financial management. Each of
these systems may invoke G-Invoicing services separately through their own Partner IDs. It’s also
possible for all three of these systems communicate with G-Invoicing through a single channel (e.g., a
service bus). See Figure 2 Partner ID/System ID Relationship above.
A Partner ID (and authenticating digital certificate) must be established for that single channel, with
distinct System IDs representing each of the agency systems, in both the test and production
environments. For this use case, the partnering client will send an API request to G-Invoicing within
which they declare the System (ID) they are representing for that particular request. G-Invoicing will
validate the Partner/System relationship and use the permissions granted to the System ID user.
All API resources used by clients to push/pull documents and attachments to/from G-Invoicing are
equipped with a System ID parameter for this purpose. G-Invoicing Support personnel will help agencies
establish a Partner ID and any System IDs under that partner, but it is up to the agency’s User
G-Invoicing System Integration Guide
Administrator(s) to authorize the System users to perform the necessary functions and access the
appropriate data.
Extending this concept, several agencies (operating in separate agency accounts) may agree to create a
single integration point to/from G-Invoicing. In this case the Partner ID will reside in a single agency
account and the System IDs can be spread across as many accounts as needed.
2.5.2 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.3 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)
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 G-
Invoicing 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 G-
Invoicing website) if your agency has not yet been assigned an AIT representative.
2.5.4 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
G-Invoicing System Integration Guide
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.5 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 the customer base is alerted. Agencies may choose to rely on G-
Invoicing 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-
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 G-
Invoicing if that information is repeatedly requested. Agencies (and their vendors) are encouraged to use
their best judgement when designing a solution.
2.5.6 Groups on Demand
Agency systems submitting Orders to G-Invoicing will need to know what organizational Groups and ALCs may
be assigned to an Order, based on the Group assigned to the GT&C. The Pull Organization API provides this
information and can be accessed in four ways:
1. Once a GT&C is pulled for the first time or after a change, the requesting and servicing Groups eligible to
use that GT&C to create Orders may be obtained. The list returned is static, however, and changes made
later to the descendant Groups (e.g., new Group, inactivated Group) will not be known.
2. Groups eligible for each open GT&C may be pulled on a periodic basis to account for organizational
changes otherwise not known.
3. The Pull Org API allows agencies to pull down entire organizations, to which rules may be applied to
determine Groups eligible to use a GT&C to create Orders. This too must be refreshed periodically to
account for organizational changes otherwise not known.
4. The Pull Org API may be accessed in real-time to support a user of an agency system attempting to create
an Order that will eventually be sent to G-Invoicing. The Groups returned are guaranteed to work for an
Order, and contain the TAS filters G-Invoicing uses to validate TAS.
If necessary, the new Order can be assigned to the same Group as the GT&C, although TAS filters may vary
between Groups.
G-Invoicing System Integration Guide
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
Trading Partner Directory
An OMB MAX site user account is required to access
the Trading Partner Directory. Accounts are free for
all government personnel and contractor support. To
obtain access, follow the registration instructions
listed on their homepage here. Once you are logged
in, navigate to the Fiscal Service G-Invoicing page by
searching for “G-Invoicing” or clicking this link
where you will find the Trading Partner Directory
hyperlink that will open the document. We
recommend saving the file locally and opening it in
excel rather than using the web browser view.
https://community.max.gov/pages/viewpage.action?spaceKey=Cross
AgencyExternal&title=Bureau+of+the+Fiscal+Service+G-
Invoicing&preview=/1702115251/1737369822/G-
Invoicing%20Trading%20Partner%20Directory.xlsx
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/g-
invoicingplaybook.pdf
G-Invoicing System Integration Guide
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
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
LDAP (Lightweight Directory Access Protocol) – is used to house access information
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
Trading Partner – an agency that buys goods/services from or sells goods/services to another federal agency
TWAI (Treasury Web Application Infrastructure) – is the environment in which the G-Invoicing application runs
UI (User Interface) – is a web-based application hosted on the TWAI for authorized user to access G-Invoicing
G-Invoicing System Integration Guide
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
1. Removed links to user guides (no longer on public website)
2. Updated access to Trading Partner Directory (in MAX)
3. 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
1.1.4
3/19/2021
1. Removed remaining references to Data Access Groups
2. Updated links that had changed
