NONCONFIDENTIAL // EXTERNAL

G-Invoicing

XML System Interface 

Specifications - Push

A Guide to transmit, insert, and process Orders and

Performance data in G-Invoicing

using theXML format

Orders

Performance

Version 6.3

June 2023
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

2

NONCONFIDENTIAL // EXTERNAL

Table of Contents

1 Introduction ...................................................................................................................................3

2 Assumptions/Constraints ............................................................................................................4

3 Interface Mechanism.....................................................................................................................4

4 Interface Specification................................................................................................................13

4.2.1 Common Rules.................................................................................................................17

4.2.2 Order Rules ......................................................................................................................17

4.2.3 Performance Rules...........................................................................................................21

4.2.4 Settlement Rules ..............................................................................................................25

5 Error Specifications ....................................................................................................................29

6 Security........................................................................................................................................30

7 Interface Integrity ........................................................................................................................30

8 Revision History..........................................................................................................................31

Appendix A: Constructive Receipt ...................................................................................................34

Appendix B: Messaging Protocol & Data Encapsulation ...............................................................35

Appendix C: Deferred Payments ......................................................................................................38
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

3

NONCONFIDENTIAL // EXTERNAL

1 Introduction

1.1 Purpose

This artifact defines the interface specification to define the transmission of Order and Performance 

data from Federal Program Agency systems to the G-Invoicing application. It serves as an 

agreement between G-Invoicing, agencies with interfacing systems, their software provider 

development teams and Bureau of the Fiscal Service business owners, upon which the system-tosystem interface will be based.

1.2 Scope

This artifact defines the G-Invoicing specifications to transmit, insert, and process IGT Buy/Sell 

Order and Performance data and the communication channel that carries these messages. The 

focus is on the specifications that must be mutually agreed upon by G-Invoicing and agencies with 

interfacing systems. The G-Invoicing team owns the maintenance of this document.

1.3 References

The artifacts listed below support the current Production release of this specification and may be 

downloaded from the provided location. Artifacts that support future enhancements and releases of 

this specification can be made available upon request.

1.3.1 The Federal Intragovernmental Data Standards (FIDS) Orders Data Elements

The Federal Intragovernmental Data Standards (FIDS) Performance Data Elements 

https://www.fiscal.treasury.gov/fsservices/gov/acctg/g_invoice/g_invoice_home.htm

1.3.2 System Mapping and Validation Rules (SM&VR) for Orders, explains how each data 

element in the FIDS maps to G-Invoicing and the validation rules enforced for each change 

in status.

https://www.fiscal.treasury.gov/fsservices/gov/acctg/g_invoice/g_invoice_home.htm

Note: There is no SM&VR for Performance data elements because Performance 

transactions have only two resources available to agencies through the API: New and 

Delete. Subsequently, the validation rules are relatively simple and appear in the FIDS.

1.3.3 XML Schema Documentation

• Order.xsd (payload)

• Performance.xsd (payload)

The following schemas are used generically for Orders and Performance:

• Order_Attachment_Push.xsd

• Order_Attachment_Response.xsd

• Order_Error.xsd

https://www.fiscal.treasury.gov/data/
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

4

NONCONFIDENTIAL // EXTERNAL

2 Assumptions/Constraints

2.1 Assumptions

1. While this artifact represents an agreement by G-Invoicing, Federal Program Agencies 

and their software providers, it does not imply a release schedule or project plan. Those 

topics are described by other artifacts for the respective projects and are not referenced 

here.

2. The interface is limited to the transmission of Order and Performance data and 

associated attachments inbound from agencies with interfacing systems to G-Invoicing.

2.2 Constraints

1. This interface will be delivered via web services, access governed by the Treasury Web 

Application Infrastructure (TWAI), as per agreement between FRB St Louis, the 

Department of the Treasury Bureau of the Fiscal Service and Defense Logistics Agency 

(DLA) Transaction Services, and is consistent with the Bureau of the Fiscal Service’s 

desire to move towards delivering system-to-system interfaces via web services.

a. Similar operating agreements may be made with other agencies, as-needed.

2. Messages will be sent over the internet utilizing the HTTPS protocol.

3. The Bureau of the Fiscal Service reference data XML Schemas will be published by the 

Enterprise Data Architecture group at https://www.fiscal.treasury.gov/data/. These 

schemas will be used to format the payload portion of the data transmission.

a. XML namespaces may vary with each new schema version

3 Interface Mechanism

3.1 Physical Interface

The G-Invoicing to agency system interface will communicate using HTTPS with 2-way TLS 

(Transport Layer Security) using a client certificate through the TWAI. The TWAI will employ a web 

service proxy to serve as a focal route for incoming web service requests so that the web service 

provider is only configured to receive requests from a single point of origination. The web service 

response is routed back on the same stream to the initial requestor.

3.2 Protocol

The G-Invoicing to agency system interface will employ a push/pull model utilizing RESTful 

Services with an XML payload. All services below are referenced via URLs in the following format. 

https://host-name:port/base-path/resource-path

Note: XML is the U.S. Treasury’s standard data format.

3.2.1 Host names:

Production: ws.igt.fiscal.treasury.gov

Quality Assurance Current: qa.ws.igt.fiscal.treasury.gov 

Quality Assurance Future: qaf.ws.igt.fiscal.treasury.gov 

Functional Test: ft.ws.igt.fiscal.treasury.gov

3.2.2 Base Path: /ginv
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

5

NONCONFIDENTIAL // EXTERNAL

3.2.3 Resource: /services

Note: G-Invoicing supports a one-to-many relationship between a Partner ID and a System 

ID whereby one Partner created and managed within a single agency account can 

represent multiple Systems spread across many agency accounts. Policy requires that at 

least one System ID must be created and managed in each agency account to push data. 

The Partner ID must be assigned a client certificate to access G-Invoicing.

Each System ID must be granted full access (by agency Master administrators) to push 

data for all documents residing in that agency account. Policy requires that at least one 

System ID is created and authorized, even in situations where the Partner is only 

accessing data in a single agency account.

3.2.3.1 Resource: New Order

Component Detail / Description

Path /ginv/services/v2_0/order

Method POST 

Description Creates a new Order in the System.

Example POST /ginv/services/v2_0/order

Host: ws.igt.fiscal.treasury.gov

Parameters

Name: Accept 

Description: Indicates the service client expects content in XML format. No other format is 

currently supported.

Value: application/xml 

Required: true

Name: Accept-Encoding

Description: Allows the service client to indicate it supports compressing the response 

payload using gzip compression.

Value: gzip, deflate

Required: false (highly suggested: if not supplied, server will send back uncompressed 

response data resulting in a larger payload)

Name: Transfer-Encoding

Description: The type of transformation that has been applied to the message body in order 

to safely transfer it between the sender and the recipient.

Value: chunked 

Required: false

Name: Connection

Description: Indicates the service client wants to use HTTP keep-alive to more efficiently 

make multiple requests.

Value: keep-alive

Required: false (highly suggested when making multiple calls. Failure to use keep-alives will 

slow concurrent calls and strain both the client and server).
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

6

NONCONFIDENTIAL // EXTERNAL

Component Detail / Description

Name: SystemID 

Description: Identifies the system that is exchanging data with G-Invoicing. 

In: header

Type: string [100] 

Required: true

Name: Agency-Tracking-Identifier

Description: Unique identifier from agency system, optionally supplied in the request. 

In: header

Type: string [50] 

Required: false

Consumes Required: application/xml 

Schema: Order

Produces

Status Code: 200

Description: Successful call returns Call Detail and the newly created Order data. 

Content Type: application/xml

Schema: Call Detail, Order

3.2.3.2 Resource: Update Order

Component Detail / Description

Path /ginv/services/v2_0/order/<id>

Method PUT

Description Updates an existing Order referenced by the passed unique identifier <id>.

Example PUT /ginv/services/v2_0/order/O1610-017-021-012345 

Host: ws.igt.fiscal.treasury.gov

Parameters

Name: Accept 

Description: Indicates the service client expects content in XML format. No other format is 

currently supported.

Value: application/xml 

Required: true

Name: Accept-Encoding

Description: Allows the service client to indicate it supports compressing the response 

payload using gzip compression.

Value: gzip, deflate

Required: false (highly suggested: if not supplied, server will send back uncompressed 

response data resulting in a larger payload)

Name: Transfer-Encoding

Description: The type of transformation that has been applied to the message body in order 

to safely transfer it between the sender and the recipient.

Value: chunked 

Required: false
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

7

NONCONFIDENTIAL // EXTERNAL

Component Detail / Description

Name: Connection

Description: Indicates the service client wants to use HTTP keep-alive to more efficiently 

make multiple requests.

Value: keep-alive

Required: false (highly suggested when making multiple calls. Failure to use keep-alives will 

slow concurrent calls and strain both the client and server).

Name: id

Description: A Unique ID referencing an individual Order. 

In: path (required)

Type: string [20] 

Required: true

Name: SystemID 

Description: Identifies the system that is exchanging data with G-Invoicing. 

In: header

Type: string [100] 

Required: true

Name: Agency-Tracking-Identifier

Description: Unique identifier from agency system, optionally supplied in the request. 

In: header

Type: string [50] 

Required: false

Consumes Required: application/xml 

Schema: Order

Produces

Status Code: 200

Description: Successful call returns Call Detail and the newly updated Order data. 

Content Type: application/xml

Schema: Call Detail, Order

3.2.3.3 Resource: New Attachment

Component Detail / Description

Path /ginv/services/v1_0/order/attachment

/ginv/services/v1_0/order/performance/attachment

Method POST 

Description Creates a new Attachment in the System.

Example See Multipart Form-Data example in Appendix B below. 

Host: ws.igt.fiscal.treasury.gov

Parameters

Name: Accept 

Description: Indicates the service client expects content in XML format. No other format is 

currently supported.

Value: application/xml 

Required: true
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

8

NONCONFIDENTIAL // EXTERNAL

Component Detail / Description

Name: Accept-Encoding

Description: Allows the service client to indicate it supports compressing the response 

payload using gzip compression.

Value: gzip, deflate

Required: false (highly suggested: if not supplied, server will send back uncompressed 

response data resulting in a larger payload)

Name: Transfer-Encoding

Description: The type of transformation that has been applied to the message body in order 

to safely transfer it between the sender and the recipient.

Value: chunked 

Required: false

Name: Content-Type

Description: The MIME type of the body of the request 

Value: multipart/form-data; boundary=

Required: true 

References: RFC 7578

Name: Connection

Description: Indicates the service client wants to use HTTP keep-alive to more efficiently 

make multiple requests.

Value: keep-alive

Required: false (highly suggested when making multiple calls. Failure to use keep-alives will 

slow concurrent calls and strain both the client and server).

Name: SystemID 

Description: Identifies the system that is exchanging data with G-Invoicing. 

In: header

Type: string [100] 

Required: true

Name: Agency-Tracking-Identifier

Description: Unique identifier from agency system, optionally supplied in the request. 

In: header

Type: string [50] 

Required: false

Consumes Required: application/xml 

Optional: application/octet-stream 

Schema: Order Attachment Push

Produces

Status Code: 200

Description: Successful call returns Call Detail and the Attachment Response data. 

Content Type: application/xml

Schema: Call Detail, Order Attachment Response

3.2.3.4 Resource: Delete Attachment

Component Detail / Description

Path /ginv/services/v1_0/order/attachment/<id>

/ginv/services/v1_0/order/performance/attachment/<id>
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

9

NONCONFIDENTIAL // EXTERNAL

Component Detail / Description

Method DELETE 

Description Deletes an Attachment from the System.

Example DELETE /ginv/services/v1_0/order/attachment/1234567890 

Host: ws.igt.fiscal.treasury.gov

Parameters

Name: Accept 

Description: Indicates the service client expects content in XML format. No other format is 

currently supported.

Value: application/xml 

Required: true

Name: Accept-Encoding

Description: Allows the service client to indicate it supports compressing the response 

payload using gzip compression.

Value: gzip, deflate

Required: false (highly suggested: if not supplied, server will send back uncompressed 

response data resulting in a larger payload)

Name: Transfer-Encoding

Description: The type of transformation that has been applied to the message body in order 

to safely transfer it between the sender and the recipient.

Value: chunked 

Required: false

Name: Connection

Description: Indicates the service client wants to use HTTP keep-alive to more efficiently 

make multiple requests.

Value: keep-alive

Required: false (highly suggested when making multiple calls. Failure to use keep-alives will 

slow concurrent calls and strain both the client and server).

Name: id

Description: A Unique ID referencing an individual Attachment. 

In: path (required)

Type: string [30] 

Required: true

Name: SystemID 

Description: Identifies the system that is exchanging data with G-Invoicing. 

In: header

Type: string [100] 

Required: true

Name: Agency-Tracking-Identifier

Description: Unique identifier from agency system, optionally supplied in the request. 

In: header

Type: string [50] 

Required: false

Consumes Required: application/xml

Produces

Status Code: 200

Description: Successful call returns Call Detail data. 

Content Type: application/xml

Schema: Call Detail
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

10

NONCONFIDENTIAL // EXTERNAL

3.2.3.5 Resource: New Performance

Component Detail / Description

Path /ginv/services/v1_0/order/performance

Method POST 

Description Creates a new Performance transaction in the System.

Example POST /ginv/services/v1_0/order/performance 

Host: ws.igt.fiscal.treasury.gov

Parameters

Name: Accept 

Description: Indicates the service client expects content in XML format. No other format is 

currently supported.

Value: application/xml 

Required: true

Name: Accept-Encoding

Description: Allows the service client to indicate it supports compressing the response 

payload using gzip compression.

Value: gzip, deflate

Required: false (highly suggested: if not supplied, server will send back uncompressed 

response data resulting in a larger payload)

Name: Transfer-Encoding

Description: The type of transformation that has been applied to the message body to safely 

transfer it between the sender and the recipient.

Value: chunked 

Required: false

Name: Connection

Description: Indicates the service client wants to use HTTP keep-alive to more efficiently 

make multiple requests.

Value: keep-alive

Required: false (highly suggested when making multiple calls. Failure to use keep-alives will 

slow concurrent calls and strain both the client and server).

Name: SystemID 

Description: Identifies the system that is exchanging data with G-Invoicing. 

In: header

Type: string [100] 

Required: true

Name: Agency-Tracking-Identifier

Description: Unique identifier from agency system, optionally supplied in the request. 

In: header

Type: string [50] 

Required: false

Consumes Required: application/xml 

Schema: Performance 

Produces

Status Code: 200

Description: Successful call returns Call Detail and the newly created Payload data. 

Content Type: application/xml

Schema: Call Detail, Performance
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

11

NONCONFIDENTIAL // EXTERNAL

3.2.3.6 Resource: Delete Performance

Component Detail / Description

Path /ginv/services/v1_0/order/performance/<id>

Method DELETE 

Description Deletes a Performance transaction from the System.

Note: Only possible if Performance Date is in the future.

Example DELETE /ginv/services/v1_0/order/performance/P1904-123-234-000345 

Host: ws.igt.fiscal.treasury.gov

Parameters

Name: Accept 

Description: Indicates the service client expects content in XML format. No other format is 

currently supported.

Value: application/xml 

Required: true

Name: Accept-Encoding

Description: Allows the service client to indicate it supports compressing the response 

payload using gzip compression.

Value: gzip, deflate

Required: false (highly suggested: if not supplied, server will send back uncompressed 

response data resulting in a larger payload)

Name: Transfer-Encoding

Description: The type of transformation that has been applied to the message body in order 

to safely transfer it between the sender and the recipient.

Value: chunked 

Required: false

Name: Connection

Description: Indicates the service client wants to use HTTP keep-alive to more efficiently 

make multiple requests.

Value: keep-alive

Required: false (highly suggested when making multiple calls. Failure to use keep-alives will 

slow concurrent calls and strain both the client and server).

Name: id

Description: A Unique ID referencing a Performance Number. 

In: path (required)

Type: string [20] 

Required: true

Name: SystemID 

Description: Identifies the system that is exchanging data with G-Invoicing. 

In: header

Type: string [100] Required: true

Name: Agency-Tracking-Identifier

Description: Unique identifier from agency system, optionally supplied in the request. 

In: header

Type: string [50] Required: false
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

12

NONCONFIDENTIAL // EXTERNAL

Component Detail / Description

Consumes No input is necessary aside from the DELETE request

Produces

Status Code: 200

Description: Successful call returns Call Detail data. 

Content Type: application/xml

Schema: Call Detail

3.3 Supported Environments

The G-Invoicing application operates within the Treasury Web Application Infrastructure (TWAI) 

environments. Interface testing will take place in G-Invoicing’s Functional Test and Quality 

Assurance environments. G-Invoicing operates both Production and Contingency environments.

Fail-over by G-Invoicing from Production to Contingency environments will be transparent.

Table 1: Supported Environments

G-Invoicing TWAI Use

Functional Test (FT) Future view of Production (new release) – will be used on a limited basis 

for interface testing.

Quality Assurance - Current (QAC) Current view of Production environment – used for agency testing.

Quality Assurance - Future (QAF) Future view of Production (new release) – used for UAT.

Production Production
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

13

NONCONFIDENTIAL // EXTERNAL

4 Interface Specification

4.1 Processing Logic

4.1.1 Orders

An Order consists of three parts: Header, Line(s) and Schedule(s). While some data elements at 

the Order Header level are common, most are split between the Requesting and Servicing 

agencies. The logical data model below shows this division, and the Order FIDS show the level of 

each data element (i.e., header/line/schedule) and which partner provides each element 

(depending on the partner that originated the Order).

Each Order must contain at least one Line, and each Line must contain at least one Schedule. 

There are no limits to how many Lines and Schedules are allowed, but once the Order is shared 

between partners, Lines and Schedules cannot be physically deleted (only cancelled). The trading 

partner that originates the Order supplies most of the Order Line data. That partner also controls 

the Quantity and Price on each Schedule. There are many other data elements broken out by 

requesting or servicing agency at the Schedule level.

Diagram 1: Orders Logical Data Model

Up to 25 attachments are allowed for each Order. Both trading partners have access to all 

attachments, but each partner can only delete their own attachment(s). These same attachment 

rules also apply to Performance and GT&C agreements.

The G-Invoicing workflow determines which actions may be executed on an Order based on its 

current status (aka, state). Diagram 2 (below) shows the various states that an Order may be 

reported through the API (i.e., states where arrow heads terminate, specifically ‘Shared with 

Partner 2’, ‘Open’, ‘Rejected’ and ‘Closed’).
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

14

NONCONFIDENTIAL // EXTERNAL

Either trading partner may originate an Order depending on conditions established in the GT&C. 

The originating agency system is known as Partner 1 in this document. The other agency system 

responds to the Order, and is known as Partner 2. This Partner 1-2 relationship remains constant 

for the life of the Order, and any other Order under the same GT&C agreement.

Three swim lanes are shown below: Partner 1, Partner 2 and one for the requesting agency (aka, 

Buyer) that exclusively closes the Order (when certain conditions have been met).

G-Invoicing will reject any service request which does not conform to the Order States diagram.

Diagram 2: Order States

Note: The G-Invoicing processing states are represented by vertical lines just to the right of the name ofeach 

state. Although there are seven possible states for an Order, only the four shown above are supported by the 

API: Shared with Partner 2 (SP2), Open (REC), Rejected (REJ) and Closed (CLZ).

Note: The Revert action relies on the feature being enabled by both trading partner’s accounts. This can be 

completed by the account Master Admin. The Originating Partner may Revert (REV) an Order in Rejected 

(REJ) state by passing a REV status to a specific Order using a PUT method. 

States available through the User Interface but not the API (i.e., ‘Draft’, ‘Pending Partner 1 

Approval’ and ‘Pending Partner 2 Approval’).
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

15

NONCONFIDENTIAL // EXTERNAL

Table 2: Order Processing (below) summarizes the different types of requests G-Invoicing will 

accept as an Order moves through its lifecycle. Agency system actions are controlled by conditions 

set in the GT&C, the current state of the Order, the proposed new state, the requested Method, 

and the permissions granted to the agency system.

Table 2: Order Processing

Requested 

By

Type of 

Request Method

Current 

State New State Data Validation Rules

Partner 1 New Order POST N/A Shared with 

Partner 2 

• All required Partner 1 data in request (see SM&VR)

• Partner 2 (only) data in request will be ignored 

Partner 2 Approved 

Order

PUT Shared with 

Partner 2 

Open • All required Partner 2 data in request (see SM&VR)

• Partner 1 (only) data in request will be ignored 

Partner 2 Rejected 

Order

PUT Shared with 

Partner 2 

Rejected • Required data for rejection in request (see SM&VR)

• All other Partner 2 data in request will be ignored 

• Partner 1 data not in request 

Partner 1 Modified 

Order

PUT Open, 

Rejected or 

Closed 

Shared with 

Partner 2 

• All required Partner 1 data in request (see SM&VR)

• Changes detected to Partner 1 data elements (xml)

• Partner 2 (only) data in request will be ignored 

Partner 1 Revert 

Order

PUT Rejected Open or 

Closed 

• Required data for revert in request (see SM&VR)

• All other Partner data in request will be ignored 

• Both trading partners must have feature enabled 

Requesting 

Agency 

Closed 

Order

PUT Open Closed • Required data for closure in request (see SM&VR)

• All other Buyer data in request will be ignored 

• All Seller data in request will be ignored 

Requesting 

Agency 

Requesting 

Admin 

Changes 

PUT Open Open • All required Buyer data in request (see SM&VR)

• Administrative changes detected to Buyer data (xml)

• Only data elements Provided By ‘Requesting’ (BIO or 

SFO, depending on the situation) with How to Update 

‘Admin Change’ in FIDS may be altered 

Servicing 

Agency 

Servicing 

Admin 

Changes 

PUT Open Open • All required Seller data in request (see SM&VR)

• Administrative changes detected to Seller data (xml)

• Only data elements Provided By ‘Servicing’ (BIO or 

SFO, depending on the situation) with How to Update 

‘Admin Change’ in FIDS may be altered 

Note: Specific data element and state validations may be found in the System Mapping and Data Validation 

Rules (SM&VR) document referenced in section 1.3.

The last two rows in Table 2 allow agencies to make Administrative Changes to Orders involving data 

elements that do not require review and approval from either partner. These changes are audited, and will be 

included in subsequent Pull requests for changes.
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

16

NONCONFIDENTIAL // EXTERNAL

4.1.2 Performance

Performance transactions do not follow a prescribed workflow. They cannot be approved or 

changed. There are validation rules (described below in Business Rules and in the Federal 

Intragovernmental Data Standards), but the only options are to post a new Performance 

transaction, related to a specific Order, Line and Schedule, or to delete a future 

Performance transaction.

Negative numbers are allowed for the Quantity for most Performance Types, so errant transactions 

may be fully or partially negated. For example, the servicing agency may have recorded 

Delivered/Performed 20 units but later realized it was only 15. The agency would submit a 

performance detail of -5 units, referencing the original 20, which nets down to 15. Beginning with 

release 4.2, the Deferred Payment type is handled differently, as described below.

Performance Transaction consists of two parts: Performance Header and Performance 

Detail(s). The header identifies the type of performance (e.g., Received/Accepted) and must 

reference a single Order. Each detail record within that header must reference a single Schedule 

on the same Order. Two details may not reference the same Schedule. Multiple performance

transactions may be submitted against a single Order (e.g., delivered 40 now, 20 later).

Each positive Received/Accepted detail record submitted by the requesting agency must reference 

a (positive) Delivered/Performed detail record previously submitted by the servicing agency.

Multiple performance details may reference the same performance detail record (e.g., 

received/accepted 25 now, 15 later).

Diagram 3: Performance Logical Data Model

In essence, the servicing agency performs against the Order/Line/Schedule and the requesting 

agency responds to the servicing agency’s performance with their perspective (e.g., we 

received/accepted the delivery in full). Performance detail records from the requesting agency 

containing zero (0) for quantity are acceptable, signifying that no performance of that type has 

been recorded (e.g., requesting agency has not yet received/accepted a delivery).
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

17

NONCONFIDENTIAL // EXTERNAL

4.2 Business Rules

4.2.1 Common Rules

4.2.1.1 The agency system must be granted permissions (aka, user role) to transmit the type 

of data being submitted for processing.

4.2.1.2 The Servicing Agencies are not allowed to change the data elements belonging to the 

requesting agency and vice versa. Submission of partner’s data is ignored.

4.2.1.3 All requests must comply with the appropriate XML schema. (See 1.3 References).

4.2.1.4 Attachments may be added to, and deleted from, existing Order or Performance 

records using the Attachment service.

4.2.1.5 For add Attachment requests, the attachment FileName in the XML payload must 

exactly match the filename in the Content-Disposition parameter within the multipart

form-data. 

4.2.1.6 An attachment may only be deleted by that trading partner that added the attachment.

4.2.2 Order Rules

4.2.2.1 For any Order updates (e.g., new, reject, modify, close), the GT&C referenced by the 

Order must be in “open for orders” status.

4.2.2.2 For new Orders, the agency system presenting the Order must have Requesting Order 

Manager or Servicing Order Manager access as required by the Order Originating 

Partner Indicator in the GT&C agreement.

4.2.2.3 The agency system must be provisioned for the Group to which the Order is assigned.

4.2.2.4 Every change made to an Order will force a new Business Transaction Identifier to be 

assigned to that record. The BusinessTransactionIdentifier is returned for all Pull and 

Push Order requests.

4.2.2.5 When calling the Update Order resource, agency systems must return the Business 

Transaction Identifier in the XML payload, thus ensuring they are updating the most 

recent version of the Order record.

4.2.2.6 An out of sequence or invalid Business Transaction Identifier will result in error code 

400 (“The transaction ID for this order does not match the latest version. Please 

request the latest version before updating”).
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

18

NONCONFIDENTIAL // EXTERNAL

4.2.2.7 Order requests may only be submitted with a DocumentStatusCode of SP2 – Shared 

with Partner 2, REC – Open, REJ – Rejected, REV – Revert or CLZ – Closed. 

Requests submitted with a DocumentStatusCode other than those listed here will be

rejected.

4.2.2.8 For close Order requests:

4.2.2.8.1 Only the requesting agency can close an Order.

4.2.2.8.2 The requesting agency must send only those data identified as required in the 

SM&VR document. All other data will be ignored. (G-Invoicing business rules 

prevent updating and closing an Order simultaneously).

4.2.2.8.3 The net sum of certain Performance details recorded against each Schedule in 

the Order by the servicing agency and sometimes by the requesting agency 

must be equal. Specifically:

- Advanced quantity (including future advances) must equal the quantity 

Delivered/Performed, if the Schedule is Advanced.

- Total quantity Delivered/Performed against a Schedule must equal the total 

quantity Received/Accepted, if (a) FOB Point is ‘Destination’ or ‘Other’and

(b) the Schedule is not Advanced.

- Total quantity Delivered/Performed against a Schedule must equal the total 

quantity Received/Accepted, if the quantity Received/Accepted is provided. 

Note: Received/Accepted is not required when FOB Point is ‘Source’.

4.2.2.8.4 Orders having Performance in ‘PND’ (pending settlement) status cannotbe 

closed (until the Performance has settled).

4.2.2.8.5 Each Schedule within the Order must be concluded in at least one of the 

following ways:

- Unpaid quantity is zero, meaning that the Schedule was fully performed (and 

paid), or that the Schedule Quantity has been modified down to the amount 

that was performed (and paid).

- The most recently reported Performance of Type ‘035’ (Delivered/ 

Performed), be it positive or negative (aka, adjustment) has a Final 

Performance Indicator of ‘F’ (final), meaning thatthe servicing agency 

considers the Schedule fully performed.

- Schedule has been Cancelled.

4.2.2.9 For rejected Order requests, Partner 2 (i.e., the agency that did not originate the Order)

must send only those data identified as required in the SM&VR document. All other 

data will be ignored. (Business rules prevent the modification and rejection of an Order 

simultaneously).

4.2.2.10 There are required elements that may be sent by both the Requesting and Servicing 

Agencies and they will be validated by the System (e.g., Line Number, Schedule 

Number, Order Number). In some cases the trading partner that originated the Order 

can propose a value, but then “partner 2” takes over maintenance (e.g., GroupName).
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

19

NONCONFIDENTIAL // EXTERNAL

When changes to data elements violate validation rules, the request will be rejected. 

(See SM&VR document for details).

4.2.2.11 Agency Systems are limited to the state changes described in Table 2 (Order 

Processing). Requests outside of those described in Table 2 will be rejected.

4.2.2.12 During a Modification, the originating partner (aka, Partner 1) may logically delete 

Order Line items and Schedules using the appropriate codes (e.g., A-Active, CCancelled) for Order Line Status and Order Schedule Status.

4.2.2.12.1 All lines and schedules must be pushed for an Order, even those that have 

been logically deleted. (See SM&VR for line and schedule requirements).

4.2.2.12.2 Physical deletion of lines or schedules is not permitted. Requests submitted 

with missing lines or schedules will be rejected.

4.2.2.12.3 Missing lines or schedules will result in error code 400 – “The lines and 

schedules provided for this order do not match existing data. Please send all 

lines and schedules for this order.”

4.2.2.13 Values of certain “administrative” data may be changed without going through the 

Modification process (which involves re-approval of the Order). Administrative 

Changes allow Order Managers to update points of contact and other administrative 

data while the Order remains in Open status, and without need for re-approval.

4.2.2.13.1 The Order FIDS shows the subset of administrative data that may be changed 

by each partner agency without approval by either partner. Filter the “How to 

Update” column for ‘Admin Change’.

4.2.2.13.2 Any attempt to Administratively Change the value of a data element not 

marked for ‘Admin Change’ will be ignored. In other words, G-Invoicing will 

only examine candidates for Admin Change.

4.2.2.13.3 Administrative Changes are only allowed when the Order is in Open status.

4.2.2.13.4 Any attempt to Administratively Change values of data elements on a 

Schedule against which Performance has been reported will be rejected.

4.2.2.13.5 The client must be assigned the Order Manager role to make Administrative 

Changes to their agency’s data.

4.2.2.13.5.1 Any attempt to make Administrative Changes with neither the 

Requesting nor Servicing Order Manager roles will be rejected.

4.2.2.13.5.2 Any attempt to Administratively Change their trading partner’s data 

without proper permissions will be ignored (not rejected).

4.2.2.13.5.3 System users possessing both requesting and servicing agency 

permissions must submit both sides of the Order so G-Invoicing can 

make all necessary administrative changes at one time.

4.2.2.13.6 Opportunities for Administrative Changes are the same regardless of which 

partner originated the Order.
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

20

NONCONFIDENTIAL // EXTERNAL

4.2.2.14 Modifications of Orders (Header, Lines and Schedules), initiated by the

originating partner (aka, Partner 1), are limited based on the presence of 

(undeleted) Performance against a Schedule.

• Data elements eligible for modification are shown in the FIDS under the “How to 

Update” column, filtered to contain ‘Admin’ or ‘Modification’. Almost 70 of these 

data elements are marked ‘N/A if Performance’, meaning that they cannot be 

modified if Performance has been reported against a Schedule.

Note: Data elements eligible for Administrative Changes may also be updated by 

Modifying the Order, with re-approval.

• Specific rules are shown in the SM&VR, including (but not limited to):

o An Order Line or Schedule cannot be cancelled if there has been any 

performance reported against it.

o Order Schedule Quantity cannot be reduced to a point below the sum of the 

Quantity performed for any Performance Type other than ‘014’ (Deferred 

Payment) by itself.

- For example, if the Schedule Quantity is 20 units and the partners 

had already advanced, delivered or received 15 units, the 

Schedule Quantity cannot be changed to below 15 units.

o Order Schedule Quantity cannot be reduced to a point below the sum of the 

Delivered/Performed plus the most recent Deferred Payment Quantity 

reported in the current open Accounting Period.

- For example, if the Schedule Quantity is 20 units and the servicing 

agency has already delivered 10 units and deferred 5 units, the 

Schedule Quantity cannot be changed to below 15 units.

4.2.2.15 Reverting an Order is only allowed when both Trading Partner have enabled the 

feature for their agency account.

4.2.2.15.1 This is controlled by Master Admins within the Feature Management UI.

- This will either allow or disallow Revert for all Orders in the 

agency account.

4.2.2.15.2 Only the Originating Partner may Revert an Order when the Modification 

number is greater than zero.

- UI: Allows Order Revert in the following states:

• Draft (DR), Partner 1 Approval (BIO = Pending Requesting 

Approval or SFO = Pending Servicing Approval) (P1A), 

Rejected (REJ)

- API: Allows Order Revert in the following state:

• Rejected (REJ)

• The client submits a Revert (REV) Order status to an 

Order that is in REJ state to Revert the Order back to is 

previously Open or Closed status.

4.2.2.15.3 When an Order is Reverted the current version of the Order is physically 

deleted and the previous Order is returned; along with the Modification 
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

21

NONCONFIDENTIAL // EXTERNAL

Number, Business Transaction ID (BTI) and Order status (Open (REC)

or Closed (CLZ). 

4.2.2.15.4 The Order Revert event is captured in the Order’s audit log which can 

be viewed within the G-Invoicing UI. 

4.2.3 Performance Rules

General Performance Rules

4.2.3.1 Agencies granted data access to an Order will be allowed to access Performance 

related to that Order. 

Note: Users must be assigned a Performance Manager role to create transactions.

4.2.3.2 A performance transaction must reference an open Order, and each detail record 

within that transaction must reference an active Schedule from an active Linewithin 

that open Order. 

• Note: Enabling the Performance while Order Modification feature allows 

Performance to continue against the previous Open Order and all active Lines 

and Schedules that were present on the Order when the current Modification 

Number (version) is not in an Open state.

4.2.3.3 The Performance API resource supports a POST method for new Performance 

transactions and a DELETE method to (logically) delete (future) Performance. 

Performance Type Rules

4.2.3.4 Each performance transaction must originate from the appropriate trading partner, as 

defined for Performance Type in the FIDS.

Note: The requesting agency can only submit Received/Accepted transactions. 

4.2.3.5 When Advance Payment Indicator is False, performance type Advance is not allowed.

4.2.3.6 When Advance Payment Indicator is True, Deferred Payments are not allowed.

4.2.3.7 When Advance Payment Indicator is True, the net quantity of Delivered/Performed may 

not exceed the net quantity of paid Advance (i.e., type 548 and status STL or PRE). 

Note: Despite this condition, a Delivered/Performed transaction does not reference an 

Advance. This allows one delivery to cover multiple advances.

4.2.3.8 Each Received/Accepted Performance detail having a positive quantity must reference 

a Delivered/Performed detail with a positive quantity.

Note: See Performance FIDS for information on how to reference a performance

transaction and its detail record(s).

4.2.3.9 The requesting agency is not permitted to respond to a Delivered/Performed detail 

recorded by the servicing agency having a negative quantity.

• For example, if the servicing agency reports Delivered/Performed of 5 then adjusts 

that by -2, the requesting agency must reference the 5 (not the -2) when reporting 

their Received/Accepted performance.
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

22

NONCONFIDENTIAL // EXTERNAL

4.2.3.10 Performance of type Deferred Payment are considered life-to-date, representing a 

single Accounting Period 

• The most recently reported quantity replaces any previously reported quantity for 

that Accounting Period.

• Previously reported Deferred/Payment Performance set to deleted status (XXX) 

• See Appendix C for a more detailed description of Deferred Payments.

4.2.3.11 The servicing agency is not allowed to report a single Performance transaction of 

Type 035 (Delivered/Performed) against a mixture of Advance and non-Advance 

Schedules.

Note: This rule is needed because Performance Status is tracked at the header level, and 

this “mixture” would result in one or more detail records of Status ‘PND’ (pending 

settlement) with other detail records of Status ‘INF’ (informational only), which cannot be 

supported. 

Performance Date Rules

4.2.3.12 Performance Date must fall within the Performance Period of the Order. 

4.2.3.13 The servicing agency may record an Advance with a future Performance Date, 

provided the date falls within the Accounting Period submitted with the transaction.

4.2.3.14 For all non-Advance Performance, the Accounting Period submitted with the 

transaction must be an open period.

4.2.3.15 The servicing agency may record a Delivered/Performed with a future Performance 

Date, provided the date falls within an open Accounting Period.

• Example: On May 27 the servicing agency reports Delivered/Performed with a 

Performance Date of May 30. This is allowed because the May period is open. If 

on May 27 the servicing agency submits a June 15 Performance Date, that 

transaction will be rejected.

4.2.3.16 The servicing agency is not allowed to submit a future dated Deferred Payment.

4.2.3.17 The requesting agency is not allowed to submit a future dated Received/Accepted.

4.2.3.18 The Performance Date of an adjusting transaction may not precede the Performance 

Date of the adjusted transaction.

• Example: Servicing agency reports Delivered/Performed with a Performance Date

of May 27. The servicing agency may not then reference that May 27 delivery with 

an adjusting Delivered/Performed with a Performance Date prior to May 27.

• However, the requesting agency may reference that May 27 Delivered/Performed 

with a Received/Accepted having a Performance Date prior to May 27.

Adjusting and Deleting Performance

4.2.3.19 Adjustments are made by submitting Performance having a negative quantity that 

references a prior (positive) Performance of the same Type.

4.2.3.20 A future dated Performance can be deleted until the point at which the Performance 
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

23

NONCONFIDENTIAL // EXTERNAL

Date is no longer in the future.

• Future dated Performance transactions that have been logically deleted are set 

to ‘XXX’ (deleted) status.

4.2.3.21 Deleted Performance records do not count towards validation rules to determine if an 

Order is eligible for closure or modification.

4.2.3.22 Future dated Performance cannot be adjusted.

Note: This prevents refunding a collection that has not yet occurred.

4.2.3.23 Performance of Type ‘014’ (Deferred Payment) can be “overridden”, but not adjusted.

4.2.3.24 All other Performance transactions (aside from Deferred Payment) can be adjusted by 

submitting a new Performance transaction (containing a negative quantity) that 

references the Performance transaction being adjusted. 

4.2.3.25 The servicing agency is not allowed to respond to a performance detail that is itself a 

response to a performance detail (i.e., an adjustment).

Note: This is not true for the requesting agency because any (-) adjustments to 

Received/Accepted performance must reference the (+) Received/Accepted 

performance which itself must reference the servicing agency’s (+) 

Delivered/Received performance.

Performance Quantity Rules

4.2.3.26 The net quantity of any one Performance Type (other than ‘014’ Deferred 

Payment) reported against a single Schedule may not exceed the Order 

Schedule Quantity, thus preventing balances from falling below zero.

4.2.3.27 The quantity of a Deferred Payment may not exceed the Undelivered Balance of 

the Schedule (i.e., Schedule Quantity minus the sum of all Delivered/Performed). 

• The sequence that Delivered/Performed and Deferred Payment are 

submitted to G-Invoicing is important. For example, if on March 2 a servicing 

agency wishes to report a Deferred Payment for the remainder of the 

Undelivered Balance in February and a Delivered/Performed for the same 

quantity in March, they must report those two transactions in that sequence. 

If the agency attempts to report the Delivered/Performed followed by the 

Deferred Payment, the latter will be disallowed because the Undelivered 

Balance is zero at the time the Deferred Payment is submitted. 

4.2.3.28 The net quantity of any one performance type reported against a single Schedule may 

not fall below zero, thus preventing overcorrection resulting in balances rising above 

the Order Schedule Quantity.

4.2.3.29 Performance quantity of zero is not allowed for Advance Payment transactions 

submitted by the servicing agency.

4.2.3.30 Zero quantity is allowed for Delivered/Performed and Deferred Payment from the 

servicing agency and Received/Accepted from the requesting agency.

4.2.3.31 The servicing agency cannot report a positive quantity in in a Performance detail that 

references a previous performance detail.
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

24

NONCONFIDENTIAL // EXTERNAL

• For example, if the servicing agency reports Delivered/Performed of 5 then adjusts

that by -2, the servicing cannot then readjust the -2 (net 3) back up by +1. Instead 

they must create a new (non-referencing) Performance transaction and detail with a 

quantity of 1.

4.2.3.32 The total quantity of performance details referencing any performance detail may not 

exceed the quantity of the original performance detail.

• For example, if servicing agency reports Delivered/Performed of 5, the total 

quantity of subsequent (-) adjustments by the servicing agency must be between

0.01 and -5 (inclusive).

• For example, if servicing agency reports Delivered/Performed of 5, the total 

quantity of subsequent Received/Accepted by the requesting agency must be 

between 0.00 and 5 (inclusive).

• For example, if requesting agency reports Received/Accepted of 5, the total 

quantity of subsequent (-) adjustments by the requesting agency must be between

0.01 and -5 (inclusive).

Note: This rule is more specific than 4.2.3.11-12 (which keeps the performed quantity 

between zero and the Scheduled quantity). The rule above keeps the net of 

subsequent performed quantities between zero and the original (positive) 

Performance quantity which was referenced.

4.2.3.1 When reported, the total quantity of Received/Accepted performance details (by the 

requesting agency) may not exceed the total quantity Delivered/Performed (by the 

servicing agency) which reference and include the original performance detail.

• For example, if servicing agency reports Delivered/Performed of 5 followed by an 

adjustment of -2, the total quantity of Received/Accepted by the requesting agency 

referencing the Delivered/Performed of 5 must be between 0 and 3 (inclusive).

• For example, if servicing agency reports Delivered/Performed of 5 and the 

requesting agency reports a Received/Accepted of 5, the servicing agency may 

report an adjustment of -2. The requesting agency could then report an adjustment 

of -2 to bring the Performance back in balance.

Note: As of release 4.2, either partner may adjust their Performance, introducing an 

out-of-balance condition. Prior to release 4.2 the requesting agency had to make their 

adjustment first.

4.2.3.2 When the feature Performance while Order Modification is enabled, and the 

previous Order was in an Open (REC) state:

• All the above rules remain the same.

• The quantity allowed to perform is always based on the previous Order state 

and not the version that is currently being approved, which means that 

Performance will be allowed to exceed the value of the Order that is currently 

being approved. G-Invoicing will allow Performance to continue up to the 

amount that was previously approved. 
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

25

NONCONFIDENTIAL // EXTERNAL

Other Rules

4.2.3.3 For Orders with FOB Point of ‘Destination’ or ‘Other’, G-Invoicing will generate a 

Constructive Receipt after the number of Constructive Receipt Days on the Order has 

elapsed. See Appendix A for more information. 

4.2.4 Settlement Rules

4.2.4.1 Settlement Status for each Performance transaction is set as follows:

4.2.4.1.1 Performance which does not result in settlement is set to ‘INF’ (informational 

only) or ‘PRE’ (Previously Settled) status.

4.2.4.1.1.1 Performance Type 014 (Deferred Payment) never triggers settlement.

4.2.4.1.2 Performance to be settled is set to ‘PND’ (pending) status.

4.2.4.1.2.1 Performance Type 548 (Advance) will trigger settlement when the 

Do Not Settle indicator is ‘N’ (No or null) and is the only way to 

trigger settlement when the Advance Payment Indicator is True on 

the Schedule.

4.2.4.1.2.2 Performance Type 548 (Advance) is set to ‘PRE’ (Previously 

Settled) status when the Do Not Settle indicator is ‘Y’ (Yes or 

checked in the UI).

4.2.4.1.2.3 Performance requiring settlement (status is Pending) but having a 

future Performance Date is settled when that Performance Date

occurs.

4.2.4.1.2.4 Performance Type 035 (Delivered/Performed) triggers settlement 

when the Advance Payment Indicator is False on the Schedule and 

FOB Point is Source/Origin on the Order. 

4.2.4.1.2.5 Performance Type 050 (Received/Accepted) triggers settlement when 

the Advance Payment Indicator is False on the Schedule and FOB 

Point is not ‘S’ (i.e., it is FOB Destination or Other) on the Order. 

4.2.4.1.2.6 Exception: Performance details having a Quantity of zero (0) are not 

sent for settlement. Status is set to:

• ‘INF’ (informational) if all Quantities are 0

• ‘STL’ (settled) if Quantity 0 mixed in with other details

having Quantity greater than 0.

4.2.4.1.3 Performance for which settlement has occurred is set to ‘STL’(settled) 

status.

4.2.4.1.4 Performance for which settlement has failed is set to ‘ERR’ (error) status.

Note: Errors will be corrected by G-Invoicing Production Support (if 

possible), not by the agencies.
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

26

NONCONFIDENTIAL // EXTERNAL

4.3 File Naming Convention

Attachments to Orders and Performance transactions are streamed in the request to GInvoicing and described by data elements (e.g., file name) in the XML of the request. 

There are limitations on special characters used in file names and the types of files that 

can be attached. Details are available in the on-line User Help available from the GInvoicing application. (Search for ‘attachment’). 

4.4 Interface Timing

The web services are generally available 24 hours per day, 7 days per week. G-Invoicing 

may have scheduled outages for maintenance as noted below.

• Monday – Saturday 3:45 AM - 4:15 AM EST 

• Sunday 11:00 AM - 11:30 AM EST 

Agency systems are in full control of the frequency and the timing of this interface.

4.5 Retransmissions

N/A – Retransmissions are not needed because the G-Invoicing web services provide for 

synchronous operation in that the agencies with interfacing systems will be waiting for the 

response from G-Invoicing before continuing.

Should the web service connection somehow fail in the middle of a series of client requests 

to G-Invoicing (e.g., multiple Order requests, multiple attachment requests) the client (i.e., 

interfacing agency system) is responsible for continuing the requests when services are 

restored.

4.6 Interface Data Details

The documents referenced below, along with the details contained in this interface 

specification, show the required data for the request type and state of an Order transaction 

via these web services. For additional documentation, refer to the XML schemas published 

on the Fiscal Service Data Registry.

Orders require data from both trading partners, and some of that Order data may (at times) 

be provided by either partner. The “Provided By (BIO)” and “Provided By (SFO)” columns of 

the Order FIDS (referenced in section 1.3 above) indicate which partner contributes each 

data element for Buyer Initiated Orders and for Seller Facilitated Orders, respectively. Table 

2 (above), the Order FIDS and the Order SM&VR (also referenced in section 1.3) can be 

used together to determine the required data elements for type of request and state of a 

transaction. The SM&VR also contains the business rules for each type of request and state 

at the data element level.

The Order FIDS is the source for all data element specifications (e.g., data type, size, etc.) 

for this interface and is the system agnostic standard for all IGT Buy/Sell data. The FIDS 

does contain data elements that can be derived from other data (i.e., calculated values).

Generally, these derived data elements do not appear in the XML schema.
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

27

NONCONFIDENTIAL // EXTERNAL

4.6.1 Business – Data Elements

The business data for Orders may be accessed from the Bureau of the Fiscal Service GInvoicing website then clicking the Data Elements – Orders link.

Table 3: Attachment Push Data Elements

Familiar Name XML Tag Definition Constraints Optionality

Attachment File 

Name 

<FileName> The actual name of the 

attachment file. 

String [1, 132] 

Maximum length = 132 

String UTF-8 

Required 

Attachment File 

Alias

<FileNameAli 

as> 

Descriptive name for an 

attachment. Different from the 

name assigned to the file itself. 

String [0,132] 

Maximum length = 132 

String UTF-8 

Optional 

Document 

Number 

<DocumentNu 

mber> 

Unique identifier for a document 

to which the attachment will be 

associated. 

String [1, 20] 

Maximum length = 20 

String UTF-8 

Required 

Buy Sell 

Indicator 

<BuySellIndic 

ator> 

Indicates whether the submitter of 

the attachment is the buyer 

(Requesting) or seller (Servicing). 

String [1,1] 

Maximum length = 1 

String UTF-8 

Values: “R” – Requesting, 

“S” – Servicing 

Note: G-Invoicing will verify that 

the user has update privileges 

based on the submitted Buy Sell 

Indicator and will reject the request 

if they do not. 

Required 

Note: The attachment service and supporting schema is generic, but the path name 

differentiates the type of document targeted for the attachment.

4.6.2 Response – Data Elements

The data elements in Table 4 below will be returned in the body of every response 

generated by G-Invoicing.

Table 4: Call Detail Response Data Elements

Familiar Name XML Tag Definition Constraints Optionality

Agency Partner ID <PartnerID> Identifies the intended 

recipient of the 

transmission. 

String [100] 

Minimum length = 0 

Maximum length = 100 

String UTF-8 

Required 

Agency System 

ID 

<SystemID> Identifies the system that 

is exchanging data with 

G-Invoicing. 

String [100] 

Minimum length = 1 

Maximum length = 100 

String UTF-8 

Required 

Agency Tracking 

Identifier 

<RequestID 

> 

Unique identifier 

optionally supplied in the 

request and echoed 

back in the response. 

String [50] 

Minimum length = 0 

Maximum length = 50 

String UTF-8 

Optional 
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

28

NONCONFIDENTIAL // EXTERNAL

Familiar Name XML Tag Definition Constraints Optionality

G-Invoicing 

Tracking Identifier 

<GINVTracki 

ngID> 

Unique tracking 

identifier, generated by 

G-Invoicing. 

String [50] 

Minimum length = 0 

Maximum length = 50 

String UTF-8 

Required 

Environment <Environme 

nt> 

Describes the 

environment in which the 

system interface resides. 

String [30] 

Minimum length = 0 

Maximum length = 30 

String UTF-8 

Required 

Request Type <RequestTy 

pe> 

Type of request that was 

submitted to G-Invoicing 

by the agency system. 

String [30] 

Minimum length = 0 

Maximum length = 30 

String UTF-8 

Values: Order Create, Order Upload, 

Attachment Create, Attachment Delete, 

Performance Create, Performance 

Delete 

Note: Values are derived from the service 

that is being accessed. 

Required 

Record Count <RecordCou 

nt> 

The total number of 

records in the payload. 

Integer Required 

Table 5: Attachment Response Data Elements

Familiar Name XML Tag Definition Constraints Optionality

Attachment File 

Name 

<FileName> The actual name of the attachment 

file. 

String [1, 132] 

Maximum length = 132 

String UTF-8 

Required 

Attachment File 

Alias

<FileNameAli 

as> 

Descriptive name for an attachment. 

Different from the name assigned to 

the file itself. 

String [0,132] 

Maximum length = 132 

String UTF-8 

Optional 

Attachment ID <AttachmentI 

D> 

Unique identifier for an attachment. Integer 

Maximum length = 30 

Required 

Attachment 

Updated By 

<FullName> The user name or partner (Buyer or 

Seller) that uploaded the attachment 

String [0,100] 

Maximum length = 100 

String UTF-8 

Required 

Attachment Date 

Time

<UploadDate 

Time>

The time and date the file was 

uploaded into G-Invoicing. 

DateTime 

Format: YYYY-MMDDThh:mm:ss.SSS+|-00:00 

All time should be specified in 

local time zone with time zone 

offset from UTC in hours and 

minutes ahead (+) or behind (-) 

UTC. 

Required 

File Size <FileSize> The size of the attachment 

expressed in kilobytes (kB). 

Integer 

Minimum length = 1 

Maximum length = 8 

Required 

Document URL <URL> The URL that will be used in a 

subsequent request by the agency 

system to retrieve the document. 

String [0, 4000] 

Maximum length = 4000 

String UTF-8 

Required 
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

29

NONCONFIDENTIAL // EXTERNAL

5 Error Specifications

Standard web service faults are generated for exceptions that can cause the request to not be 

processed. If the agency system cannot be authenticated or authorized, then a fault is returned. If 

the requested resource is unavailable then a fault will be thrown. All services may return the 

following HTTP status codes along with variable error message text describing the error(s) in the 

response.

Error ID HTTP Status Code Example

1 400 – Bad Request 

ValidationFailedException 

Note: Message text included 

in the <ErrorDesc> element 

will vary depending on the 

error condition.

<ns0:ErrorDetail> 

<ns0:ErrorDesc>ValidationFailedException message = Requesting agency Point Of Contact Full 

Name is required.</ns0:ErrorDesc> 

<ns0:ErrorTitle>400 ValidationFailedException</ns0:ErrorTitle> 

<ns0:RequestDateTime>2018-05-24T15:43:27.578-04:00</ns0:RequestDateTime> 

<ns0:RequestTypeIdentifier>Order Create</ns0:RequestTypeIdentifier> 

<ns0:Status>400</ns0:Status> 

</ns0:ErrorDetail> 

2 403 – Unauthorized 

AccessDeniedException 

Note: Message text included 

in the <ErrorDesc> element 

will vary depending on the 

error condition.

<ns0:ErrorDetail> 

<ns0:ErrorDesc>AccessDeniedException message = User is not authorized to the 

system.</ns0:ErrorDesc> 

<ns0:ErrorTitle>403 AccessDeniedException</ns0:ErrorTitle> 

<ns0:RequestDateTime>2018-05-23T08:33:04.426-04:00</ns0:RequestDateTime> 

<ns0:RequestTypeIdentifier>Order Create</ns0:RequestTypeIdentifier> 

<ns0:Status>403</ns0:Status> 

</ns0:ErrorDetail> 

</Ginv_Error> 

3 500 – Internal Server Error 

ServerException 

Note: Message text included 

in the <ErrorDesc> element 

will vary depending on the 

error condition.

<ns0:ErrorDetail> 

<ns0:ErrorDesc>ServerException message = Multiple users found.</ns0:ErrorDesc> 

<ns0:ErrorTitle>500 ServerException</ns0:ErrorTitle> 

<ns0:RequestDateTime>2018-05-23T08:29:07.566-04:00</ns0:RequestDateTime> 

<ns0:RequestTypeIdentifier>Order Create</ns0:RequestTypeIdentifier> 

<ns0:Status>500</ns0:Status> 

</ns0:ErrorDetail> 
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

30

NONCONFIDENTIAL // EXTERNAL

6 Security

The TWAI will accept web service traffic, perform certificate-based authentication against security 

policies, and route the requests to G-Invoicing. Separate certificates are needed for test and 

production environments.

No Personally Identifiable Information (PII) is being transported by this system interface. There is 

no risk that this interface will allow additional access to G-Invoicing data.

The Department of Defense has rated information contained in G-Invoicing as Mission Assurance 

Category III. The MAC III rating is for systems handling information that is necessary to conduct 

day-to-day business, but does not materially affect support to deployed or contingency forces in 

the short term. The consequences of loss of integrity or availability can be tolerated or overcome 

without significant impacts on mission effectiveness or operational readiness. The consequences 

could include the delay or degradation of services or commodities enabling routine activities.

Mission Assurance Category III systems require protective measures, techniques or procedures 

generally commensurate with commercial best practices.

7 Interface Integrity

7.1 Treasury Web Application Infrastructure

TWAI security infrastructure, policies and procedures guarantee that only authenticated and 

authorized entities are permitted access to the G-Invoicing application and its assets. Virus 

detection, intrusion detection, and network and infrastructure monitoring software and hardware 

are provided by and operated in the TWAI.

7.2 Communication Channel

Adhere to the Guidelines for protecting sensitive data during electronic dissemination across 

networks as stated in the NIST Special Publication (SP) 800-52 (rev 1), Selection, Configuration, 

and Use of Transport Layer Security (TLS) Implementations.

Meet security requirements for NIST Special Publication (SP) 800-53 (rev 4), Recommended 

Security Controls for Federal Information Systems, and other applicable guidance, such as 

Treasury Directive Publication (TDP) 85-01.
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

31

NONCONFIDENTIAL // EXTERNAL

8 Revision History

Vers.

Num.

Date of

Change

G-Inv

Rel. Change/Revision Description Page/SectionAffected

0.1 04/26/2017 2.2 Initial Draft All

0.2 06/01/2017 2.2 Additional document updates All

0.3 06/09/2017 2.2 Added attachments to Order schema 3.2.3, 4.6.2, B

0.4 06/23/2017 2.2 Updates after peer review. All

0.5 06/29/2017 2.2 Updates after internal review. All

1.0 07/06/2017 2.2 Baselined for Fiscal Service approval. All

1.1 07/11/2017 2.2 Added Data Act elements (PIID, PAID). 4.6.2, 2.1

1.2 07/17/2017 2.2 Incr. System & Partner ID to 100 chars 3.2.3, 4.6.1

1.3 07/21/2017 2.2 Added references to FIDS and SM&VR 1.3.2, 4.6

1.4 07/27/2017 2.2 Updated external references 1.3, Table 2

1.5 08/02/2017 2.2 Updated processing logic, business rules,

XML schema information.

4.1, 4.2, Appx B

1.6 08/08/2017 2.2 Removed Order data table. 4.6.1

1.7 08/21/2017 2.2 Updates after peer review. All

1.8 12/18/2017 2.2 Updated schema and XML information Appendix B

1.9 01/19/2018 2.2 Updates based on data standards. All

1.10 02/01/2018 2.2 Updated schema and XML information Appendix B

1.11 04/03/2018 2.2 Updates after internal review. 3, 4.2

1.12 04/10/2018 2.2 Updates after peer review. 4

1.13 04/10/2018 2.2 Final wording and drop yellow highlights 4

1.14 04/13/2018 2.2 Updated date/time format

Added new Order state

4.1, 4.2.4, 5,

Tbl 2, 5, Dgm 1

1.15 05/21/2018 2.2 1787 move Org Ref data to Header Appx B

1.16 5/30/2018 2.2 Updated HTTP error status codes 5

1.17 6/6/2018 2.2 Updated Multipart Form-Data,

Updated Resource information

Appx B

3.2.3

2.0 6/8/2018 2.2 Baseline All

2.0.1 6/27/2018 2.2 Updated Header App B

2.1 7/30/2018 2.3 Added Performance Transaction 1, 2, 3, 4, Appx B

2.2 8/6/2018 2.3 Updated following internal review 1, 2, 3, 4, Appx B

2.3 8/28/2018 2.3 Updated following Treasury review: (1) 

updated Partner/System note, (2)

removed GTC and Order XML samples

3.2.3

Appx B

3.0 9/04/2018 2.3 Approved – see GINV-1933 N/A

3.1 10/18/2018 2.3 Clarified permissions for Performance 4.2.3

3.1.1 10/21/2018 2.3 Added note regarding IPAC adjustments 4.1.1

3.1.2 10/24/2018 2.3 Minor corrections after internal review

3.2 11/2/2018 2.3 Removed ability to send Buyer/Seller

data at once (not supported by user role)

Table 2

3.3 12/17/2018 2.3 Revised to reflect Dec 4-6 decisions 4.1.2, 4.2.2, 4.2.3

3.4 12/18/2018 2.3 Updated after internal review. Added 

new Appendix A, pushed old A to B.

4.2.3, Appx A

3.5 12/20/2018 2.3 (a) Updated after DB review. (b) GINV174: Allow “admin” changes toOrders.4.1.2, Table 2,

4.2.2.12
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

32

NONCONFIDENTIAL // EXTERNAL

3.5.1 1/2/2019 2.3 The delete attachment service consumes 

no XML

3.2.3.4

3.6 1/9/2019 2.3 Reuse summary, attachment and error 

“order” schemas for Performance.

Updated Treasury system owner name.

Update order state diagram.

1.3.3, 2.3.3.3,

2.3.3.4-5, 3.2.3.3- 

4, Diagram 3

3.6.1 1/28/2019 2.3 Clarified some text and fixed typos. Appx A

3.7 2/6/2019 2.3 Zero quantity Perf not allowed by seller 4.2.3

4.0 2/25/19 2.3 Baseline for Performance Txn All

4.1 3/20/19 2.3 Deferred Pay cannot exceed

Delivered/Performed to close Order.

Prohibit future performance by Buyer.

4.2.2.6

4.2.3.7

4.2 4/5/19 2.3 Clarified some Performance validations. 4.2.3

4.3 4/10/19 2.3 Buyer adjustments must reference the 

initial (positive) Received/Accepted

4.2.3

4.4 4/15/19 3.0 Clarified performance examples as being 

inclusive (e.g., 0 to 5 inclusive).

Added settlement rules to performance.

4.2.3

4.5 4/18/19 3.0 Disallowed future adjustments.

Allow deletion of future Performance.

Referenced FIDS and SM&VR for Mods. 

Distributed for Settlement approval.

4.2.3

3.2.3.1, 4.2.3

4.2.2.11

5.0 4/29/19 3.0 Baselined for Settlement. History

5.0.1 5/14/2019 3.0 Clarified rules triggering settlement 4.2.4.1.3

5.0.2 5/14/2019 3.0 Delete attachment consumes XML, distinguish buyer vs seller, reversing 1/2/19.3.2.3.4

5.1 6/6/2019 3.0 Dropped ‘FUT’ status for Performance.

Status Code ‘DEL’ changed to ‘XXX’.

4.2.4.1.3.2

4.2.4.1.6

5.2 6/24/2019 3.0 Performance details having Quantity 0 

are not settled. Deleted Performance is

treated as if it never existed.

4.2.4.1.3.4.1

4.2.3.19

5.3 7/29/2019 3.0 1. Can’t close Order in PND status.

2. Can’t deliver against Adv and non-Adv

3. Status ERR is not typically corrected

4.2.2.6.2

4.2.3.27

4.2.4.1.5

5.3.1 8/6/2019 N/A Clarified policy requiring at least one

System ID per Partner ID.

3.2.3

5.4 9/13/2019 3.0 DO Symbol and Document Reference 

Number are not set by G-Invoicing 

for Constructive Receipts

Appendix A

5.4.1 3/20/2020 N/A XML namespaces may vary with each

new schema version

2.2.3a

5.4.2 6/12/2020 N/A Clarified a closing rule that changed in 

r3.1 regarding FOB Destination on

Advance Schedules

4.2.2.8.3

5.5 5/15/2020 4.0 Org Group controls data access 4.2.2.3

5.6 6/23/2020 4.0 System ID is now required Every resource

5.6.1 12/03/2020 4.0 Only Master Admin(s) can manage System

ID’s access

3.2.3

6.0 5/15/2020 4.1 Draft to support Seller Facilitated Orders All of Orders

6.0 5/29/2020 4.2 Draft to support Accruals and Refunds 4.2.2, 4.2.3
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

33

NONCONFIDENTIAL // EXTERNAL

6.0.1 6/3/2020 N/A Corrected “reject” on State Diagram.

Dropped two repetitive Perf rules.

Diagram 2

4.2.3

6.0.2 6/16/2020 N/A Clarified a modification rule for Orders 4.2.2.14

6.1 1/11/2021 4.2 (1) Accounting Period will be generated 

for Constructive Receipt.

(2) Cannot reference future Performance.

(3) Limits on file name special chars.

(4) Removed reference to TWAI diagram.

(1) Appendix A

(2) 4.2.3.20

(3) 4.3

(4) 7.1

6.1.1 2/05/2021 4.2 Performance rules changes will be 

included in release 4.2

4.2.3.33

6.1.2 2/16/2021 4.2 Clarified rule that excludes Deferred Pay 4.2.2.14

6.1.3 3/8/2021 4.2 Clarification of rules:

1. Added cancelled schedule condition to 

Order Closure rules. 

2. Sum of Delivered/Performed may not 

exceed sum of paid Advances. 

3. Final Performance Indicator can come 

from positive or negative delivery.

4. Created appendix to explain logical 

deletion of Deferred Payments 

5. Two Performance Details cannot point 

to same Schedule

6. Add reference to Appendix A

7. Clarified quantity limit for Deferred Pay 

8. Moved explanation of deleted future 

Performance from 4.2.4 to 4.2.3

4.2.2.8.5

4.2.3.7

4.2.2.8.5

Appendix C

4.1.2

4.2.3.34

4.2.3.27

4.2.3.20

6.1.4 4/30/2021 4.2 Correction: Updated values returned for 

Request Type after verifying this is not 

being used by any known client. 

Table 4 Call Detail 

Response Data 

Elements

6.1.5 5/3/2021 4.2 Constructive Receipt will always fall within 

Order’s period of performance

Appendix A

6.2 10/12/2022 5.0 Update Performance rules to include PRE 

status for Advance

4.2.3.7,

4.2.4

6.3 06/09/2023 5.2 Updated Order and Performance for new 

Order Revert and Performance while Mod 

features 

Updated: 

Diagram 2

Table 2

4.2.3.2

Added: 

4.2.2.15

4.2.3.2
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

34

NONCONFIDENTIAL // EXTERNAL

Appendix A: Constructive Receipt

Under certain conditions the G-Invoicing system will generate a Constructive Receipt to guarantee 

timely reimbursement for goods delivered or services performed by the servicing agency:

• Conditions:

o FOB Point is Destination (or Other) for the Order.

o The number of Constructive Receipt Days (CRD) for the Order have elapsed since the 

Performance Date of the Delivered/Performed transaction.

o The number of CRDs for the Order have elapsed since the Transaction Date of the 

Delivered/Performed transaction.

o The Quantity of the unanswered Delivered/Performed detail record is greater than zero, 

because the requesting agency need not respond to negative or zero Performance by the 

servicing agency.

o The requesting agency has not submitted a Received/Accepted performance detail record 

which references a positive Delivered/Performed detail record submitted by the servicing 

agency.

Note: The constructive receipt will be generated the morning after the Constructive Receipt 

Days period elapses.

• The system-generated performance transactions will have the following characteristics:

o Prepared By Name will be set to ‘System’.

o Transaction Date will be set to the current date.

o Performance Date will be set to the current date, or to the Order End Date if in the past.

o Accounting Period will align with the Performance Date.

o Comments will be set to ‘Constructive Receipt generated because requesting agency did 

not respond to servicing agency’s Delivered/Performed detail record within the agreed 

upon timeframe’.

o Status will be set to ‘PND’ (pending).

o Performance Type will be set to ‘Received/Accepted’.

o Quantity will be set to the Quantity of the Delivered/Performed detail record which went 

unanswered by the requesting agency.

o All other optional data elements will be omitted.

o If more than one Schedule in the Order went unanswered on the same day, multiple 

performance detail records will be grouped within a single performance transaction.

Note: Settlement requests are not being generated at this time. Performance 

transactions (including Constructive Receipts) are informational only.
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

35

NONCONFIDENTIAL // EXTERNAL

Appendix B: Messaging Protocol & Data Encapsulation

1 G-Invoicing Message Encapsulation

Transmissions into and out of G-Invoicing will utilize RESTful web-services over the internet 

with an XML payload. The HTTP Request and Response will have the structure depicted in 

diagrams in 1.1 and 1.2 below.

The HTTP Request will have an empty Body when the Header contains a “GET” command. 

When the Request contains a “POST” or “PUT” command the Body will contain an XML 

payload.

1.1 HTTP Request

1.2 HTTP Response

Call Detail data will be returned in every response generated by G-Invoicing. Call Detail 

contains metadata about the Request/Response. The Call Detail data will be part of the 

HTTP Body and precede any data included in the response that satisfies the initial request.
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

36

NONCONFIDENTIAL // EXTERNAL

2 Error

3 Attachment

3.1 Attachment Push

Error Sample XML

<?xml version="1.0" encoding="UTF-8"?>

<!--Sample XML file generated by XMLSpy v2017 sp2 (x64) 

(http://www.altova.com)-->

<cmn:ErrorDetail xmlns:cmn="urn:us:gov:treasury" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

xsi:schemaLocation="urn:us:gov:treasury:ginv:error Error.xsd">

<cmn:ErrorDesc/>

<cmn:ErrorTitle/>

<cmn:RequestDateTime>2017-05-09T17:30:00.000Z</cmn:RequestDateTime>

<cmn:AgencyLocationCodes>a</cmn:AgencyLocationCodes>

<cmn:RequestTypeIdentifier>a</cmn:RequestTypeIdentifier>

<cmn:Status>a</cmn:Status>

</cmn:ErrorDetail>

Attachment Push Sample XML 

3.2 Attachment Response 

Attachment Response Sample XML

4 Multipart Form-Data

The following is an example of the multipart form-data when submitting an attachment. The method for 

submitting an attachment is POST and the DocumentNumber is required in the XML body of the 

attachment request in order to add the attachment to the appropriate document.

POST /ginv/services/v1_0/order/attachment 

Host: www.igt.fiscal.treasury.gov

Accept: application/xml 

Accept-Encoding: gzip,deflate 

Transfer-Encoding: chunked

Content-Type: multipart/form-data; boundary=wyh0b_2-92vSvGKh-nHe7HA3qyIggPjPG
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

37

NONCONFIDENTIAL // EXTERNAL

Connection: Keep-Alive

--wyh0b_2-92vSvGKh-nHe7HA3qyIggPjPG

Content-Disposition: form-data; name="attachment-meta-data" 

Content-Type: application/xml

Content-Transfer-Encoding: binary

<?xml version="1.0" encoding="UTF-8"?>

<!--Sample XML file generated by XMLSpy v2017 sp2 (x64) (http://www.altova.com)-->

<n1:GINV_Attachment xmlns:cmn="urn:us:gov:treasury" 

xmlns:n1="urn:us:gov:treasury:ginv:OrderAttachmentPush" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

xsi:schemaLocation="urn:us:gov:treasury:ginv:OrderAttachmentPush Order_Attachment_Push.xsd">

<cmn:FileName>testfile1</cmn:FileName>

<cmn:FileNameAlias>my first test file</cmn:FileNameAlias>

<cmn:DocumentNumber>O1702-3060-3060-0032</cmn:DocumentNumber>

<n1:BuySellIndicator>R</n1:BuySellIndicator>

</n1:GINV_Attachment>

--wyh0b_2-92vSvGKh-nHe7HA3qyIggPjPG

Content-Disposition: form-data; name="attachment-file"; filename="testfile1.txt" 

Content-Type: application/octet-stream

Content-Transfer-Encoding: binary

Lorem ipsum dolor sit amet, consectetur adipiscing elit. In aliquet condimentum eleifend. Fusce nec efficitur magna. Duis odio 

nulla, scelerisque eget efficitur vitae, volutpat nec ex. Aliquam nisl quam, faucibus et tempus nec, accumsan at nibh. Quisque 

ultrices lacus quis consectetur faucibus. Duis velit dui, venenatis eget nisl ac, volutpat suscipit massa. Nullam cursus lacus quis 

quam hendrerit, a tristique lorem tristique. Vestibulum malesuada viverra augue at convallis. Curabitur nunc enim, aliquam sit 

amet fringilla ac, molestie quis nisi. Phasellus maximus vehicula convallis. Nullam fringilla quam placerat magna pulvinar, non 

ullamcorper tortor dapibus. Nam euismod auctor odio, at rhoncus elit hendrerit eleifend. Fusce aliquam leo non hendrerit 

ullamcorper. Cras convallis mollis felis, sagittis commodo nulla dictum ut.
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

38

NONCONFIDENTIAL // EXTERNAL

Appendix C: Deferred Payments

Beginning with release 4.2 of G-Invoicing, Performance Type 014 (Deferred Payment) is handled 

differently than the other three types. Deferred Payments are evaluated as life-to-date entries, 

replacing any prior entry for the same Schedule and Period. Performance reported against each of 

the other three types (i.e., Advance Payment, Delivered/Performed and Received/Accepted) are 

summed together and handled as an aggregate. The impacts of this Type 014 distinction are 

described within this appendix as an aide to software developers. 

Informational Only 

Deferred Payment is the only Performance Type that never triggers settlement. It is purely 

informational (i.e., Status ‘INF’), used by the servicing agency to communicate a work in progress 

accrual. This was the case prior to G-Invoicing release 4.2 and is the case afterwards.

Replacements

When a second Deferred Payment is reported against the same Schedule in the same Accounting 

Period the previous Deferred Payment Performance Transaction (Header and Details) are logically 

deleted. The client or user may just want to replace one (of many) Details, but the Status is stored at 

the Header level, so all Details are assigned the same Status. There can be more than one active 

(‘INF’ormational status) Header referencing an Order, each containing Detail(s) which reference 

(non-overlapping) Schedules. Logically deleted Performance have a Status of ‘XXX’ in their Header.

This concept of Replacement is new as of the 4.2 release.

Reporting Options

Reporting Deferred Payment performance may be handled in two ways. Regardless of which option 

is chosen, the servicing agency must consistently use one of the two options to avoid inadvertently 

deleting Performance Details. 

A. Report one Detail per Header. One of the ERP vendors has chosen this option, reporting only 

one Performance Detail per Header, even when there are multiple Schedules involved. This 

vendor’s solution will be able to pull down multiple Details when necessary. This design does not 

limit how that vendor’s offering may present accruals for an Order containing multiple Schedules. 

Rather, it is a choice on how to communicate that information to G-Invoicing.

B. Report every Detail that has ever been assigned a value in the Accounting Period. This is the 

way that G-Invoicing and two other ERP vendors will communicate Deferred Payments. For 

Orders with only one Schedule, there is no difference between the two options. But for multiple 

Schedules a complete set of deferred payments for the entire Order will be reported within each 

Accounting Period. These systems will send Details for any Schedule that has a value now or at 

any time during the Period. 

If these two approaches were to be co-mingled (e.g., system user representing an ERP system 

employing option A followed by a human user in G-Invoicing reporting Deferred Payments against the 

same Order in the same period), Performance Details could be inadvertently deleted. To prevent this, 

G-Invoicing recommends that Master and User Administrators do not assign the Performance Manager 

role to system users and human users assigned to the same organizational group(s).
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

39

NONCONFIDENTIAL // EXTERNAL

Example: Order has one Line with five Schedules. Below please find a series of Deferred Payments 

reported against a single Accounting Period, once using option A and again using option B.

Option A (7 Headers and 7 Details)

On Day 1 the following Deferred Payments are submitted (separately)

1. 10 units deferred payment for Schedule 1

2. 20 units deferred payment for Schedule 2

3. 30 units deferred payment for Schedule 3

On Day 2 the following Deferred Payments are submitted (separately)

1. 0 units deferred payment for Schedule 1

2. 0 units deferred payment for Schedule 2

3. 40 units deferred payment for Schedule 4

On Day 3 the following Deferred Payments are submitted (separately)

1. 300 units deferred payment for Schedule 3

Option B (3 Headers and 11 Details)

On Day 1, Deferred Payment #1 submitted containing these Detail Quantities per Schedule 

1. 10 

2. 20 

3. 30 

4. no value ... meaning there is no Detail submitted for this Schedule

5. no value 

On Day 2, Deferred Payment #2 submitted containing these Detail Quantities per Schedule

1. zero (0) ... replaces 10

2. zero (0) ... replaces 20 

3. 30 ... unchanged

4. 40 ... new Performance Detail for Schedule 4

5. no value ... this is okay because there has never been a value for schedule 5 

On Day 3, Deferred Payment #3 submitted containing these Detail Quantities per Schedule

1. zero (0) ... could send no value instead because it was already zero

2. zero (0) ... could send no value instead because it was already zero

3. 300 ... replaces 30

4. 40 ... unchanged 

5. no value ... this is okay because there has never been a value for schedule 5

Processing Deferred Payments

Each Performance Header submitted may contain 1-to-‘n’ Details, where ‘n’ is the number of 

Schedules in the referenced Order. G-Invoicing will follow these steps when creating Deferred 

Payments: 

1. When G-Invoicing receives a Deferred Payment, it will look for existing Performance 

Header(s) and Detail(s) possessing the following characteristics:

a. Type 014 (deferred payment)

b. Same Accounting Period as new Performance
G-Invoicing System Interface Specifications – Push Order and Performance

Version 6.3 – June 2023

40

NONCONFIDENTIAL // EXTERNAL

c. Same referenced Schedule as appears with a Quantity value (0+) in the new 

Performance

d. Status = INF (not XXX)

2. If such Performance Header(s) and Detail(s) are found, they will be logically deleted (i.e., 

status set to XXX at the Header level) when new deferred payment(s) are saved. This 

logically deletes all Details associated with the old Header(s).

3. The new Performance Header and Detail(s) replace the old Header(s) and Detail(s), 

when applicable, and will be set to INF status.

a. Performance Quantity of zero (or more) will be saved as a Performance Detail.

b. Performance Quantity is required with each Detail submitted.

c. If no Detail is submitted for a referenced Schedule, no Performance Detail will be 

saved.

Note: This does not mean that an existing Performance Detail (for that referenced 

Schedule and Period) wasn’t deleted under Step 2.