NONCONFIDENTIAL // EXTERNAL 

System Interface Specifications

Push JSON

A guide to transmit, insert and process Orders, Performance and 

7600EZ in G-Invoicing using JSON 

Orders, Performance and 7600EZ 

Version 1.3

March 2024
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

2

Table of Contents 

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

1.1 Purpose ...................................................................................................................................................................... 3

1.2 Scope ......................................................................................................................................................................... 3

1.3 References ................................................................................................................................................................. 3

2 Assumptions/Constraints ............................................................................................................... 3

2.1 Assumptions .............................................................................................................................................................. 3

2.2 Constraints................................................................................................................................................................. 3

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

3.1 Physical Interface ....................................................................................................................................................... 4

3.2 Protocols ..................................................................................................................................................................... 4

3.2.4 Common Headers.................................................................................................................................................... 4

3.2.5 Resource: Create New Documents........................................................................................................................ 5

3.2.5 Resource: Update Order......................................................................................................................................... 5

3.2.6 Resource: Delete Performance/7600EZ ................................................................................................................ 6

3.2.7 New Attachment....................................................................................................................................................... 6

3.2.8 Delete Attachment .................................................................................................................................................. 7

3.3 Supported Environments.............................................................................................................................................. 8

4 Interface Specification .................................................................................................................... 8

4.4 Processing Logic ......................................................................................................................................................... 8

4.4.1 Orders..................................................................................................................................................................... 8

4.4.2 Performance........................................................................................................................................................... 14

4.4.3 7600EZ.................................................................................................................................................................... 15

4.5 Business Rules .......................................................................................................................................................... 15

4.5.1 Common Rules ................................................................................................................................................... 15

4.5.2 Order Rules ........................................................................................................................................................ 16

4.5.3 Performance Rules ............................................................................................................................................ 20

4.5.4 7600EZ Rules ..................................................................................................................................................... 25

4.6 File Naming Convention .......................................................................................................................................... 29

4.7 Interface Timing ...................................................................................................................................................... 29

4.8 Retransmissions ...................................................................................................................................................... 29

4.9 Interface Data Details ............................................................................................................................................. 29

4.9.1 Attachment - Data Elements ............................................................................................................................. 30

4.9.2 Response – Data Elements ................................................................................................................................ 30

5 Error Specifications ................................................................................................................... 32

6 Interface Integrity ....................................................................................................................... 33

6.1 Treasury Web Application Infrastructure (TWAI) .................................................................................................... 33

6.2 Communication Channel ......................................................................................................................................... 33

7 Security ........................................................................................................................................33

8 Revision History ......................................................................................................................... 34

Appendix A: Constructive Receipt .................................................................................................... 35

Appendix B: Deferred Payments ....................................................................................................... 36
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

3

1 Introduction 

1.1 Purpose 

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

7600EZ 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, 

Performance and 7600EZ 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, Performance and 7600EZ

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 and 7600EZ data elements because transactions 

have only two resources available to agencies through the API: Create and Delete.

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

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, Performance and 7600EZ 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 and the Department 

of the Treasury Bureau of the Fiscal Service. Similar operating agreements may be made with 

other agencies as needed.
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

4

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

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 Protocols

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

with a JSON payload. All services below are referenced via URLs in the following format. 

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

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 

3.2.2 Base Path: /ginv 

3.2.3 Resource: /services 

3.2.4 Common Headers 

Component Detail / Description

Name: SystemID 

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

Paths: order, performance and ez 

In: header 

Type: string [100] 

Required: true 

Name: Accept 

Description: Indicates the service client expects content in JSON format. 

Value: application/json 

Required: true

Name: Agency-Tracking-Identifier 

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

Paths: order, performance and ez 

In: header 

Type: string [50] 

Required: false
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

5

Headers

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 make multiple requests more 

efficiently. 

Value: keep-alive 

Required: false 

Highly suggested when making multiple calls. Failure to use keepalives will slow concurrent calls and 

strain both the client and server.

3.2.4 Resource: Create new document 

Component Detail / Description

Paths

/ginv/services/v3_0/order 

/ginv/services/v3_0/order/performance 

/ginv/services/v1_0/ez 

Method POST 

Description Creates a new document in G-Invoicing 

Consumes

Required: application/json 

Document Body: Order, Performance or 7600EZ 

Produces

Status Code: 200 

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

Content Type: application/json 

Document Response: Call Detail: Order, Performance or 7600EZ

3.2.5 Resource: Update Order 

Component Detail / Description

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

Method PUT 

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

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

6

Parameter

Name: id 

Description: A Unique ID referencing an individual Order. 

In: path (required) 

Type: string [20] 

Required: true 

Consumes

Required: application/json 

Document Body: Order 

Produces

Status Code: 200 

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

Content Type: application/json 

Document Request: Call Detail, Order 

3.2.6 Resource: Delete Performance/7600EZ 

Component Detail / Description

Paths /ginv/services/v3_0/order/performance/<id> 

/ginv/services/v1_0/ez/<id> 

Method DELETE 

Description Deletes a Performance or 7600EZ transaction from G-Invoicing. 

Note: Only possible if Performance Date is in the future (Status = Pending) 

Parameter

Name: id 

Description: A Unique ID referencing a Performance or 7600EZ Number. 

In: path (required) 

Type: string [20] 

Required: true 

Consumes No input is necessary aside from the DELETE request 

Produces

Status Code: 200 

Description: Successful call returns Call Detail data. 

Content Type: application/json 

Document Response: Call Detail, Performance or 7600EZ 

3.2.7 Resource: New Attachment 

Component Detail / Description

Paths

/ginv/services/v3_0/order/attachment 

/ginv/services/v3_0/order/performance/attachment 

/ginv/services/v1_0/ez/attachment 

Method POST 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

7

Description Add a new attachment to a document. 

Example See example in Open API document 

Parameter

Name: Content-Type 

Description: The MIME type of the body of the request 

Value: multipart/form-data

Required: true 

References: RFC 7578

Consumes

Required: application/json, application/octet-stream 

Schema: Attachment Push 

Produces

Status Code: 200 

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

Content Type: application/json 

Document Response: Call Detail, Attachment Response

3.2.8 Resource: Delete Attachment 

Component Detail / Description

Paths

/ginv/services/v3_0/order/attachment/<id> 

/ginv/services/v3_0/order/performance/attachment/<id> 

/ginv/services/v1_0/ez/attachment/<id> 

Method DELETE 

Description Deletes an Attachment from the System. 

Parameter

Name: id 

Description: A Unique ID referencing an individual Attachment. 

In: path (required) 

Type: string [30] 

Required: true 

Consumes Required: application/json 

Schema: Attachment Push 

Produces

Status Code: 200 

Description: Successful call returns Call Detail data. 

Content Type: application/json 

Document Response: Call Detail 

 

3.3 Supported Environments 

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

environments. G-Invoicing operates both Production and Contingency environments. Fail-over by GInvoicing from Production to contingency environments will be transparent.
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

8

Table 1: Supported External Environments 

G-Invoicing TWAI Use

Quality Assurance - Future (QA-F) Future view of Production (new release) – used for UAT & interface testing 

Quality Assurance - Current (QA-C) Current view of Production environment – used for agency & vendor 

testing.

Production Production 

4 Interface Specification 

4.4 Processing Logic 

4.4.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 shows 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
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

9

Diagram 2: Standard Order API States (Does not represent Bidirectional Modification)

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

although, there are seven possible states for an Order, only five are supported by the API: Shared with Partner 2 

(SP2), Open (REC), Rejected (REJ), Closed (CLZ) and Revert (REV).

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

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

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

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

(aka, state). 

Either trading partner may originate an Order depending on conditions established on 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. 

Table 2: Standard 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 on the GT&C, the current state of the Order, the proposed new state, the requested 

method, and the permissions granted to the agency system.
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

10

Table 2: Standard Order Processing (Does not represent Bidirectional Modification)

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 Standard 

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

• 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

• 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

• 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.
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

11

Table 3: Order Processing (with Bidirectional Modification)

See Modification Status (Mod Status) table for Order States indicated as “Modified” in the below table.

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 Standard 

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

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

Partner 2 Bidirectional 

Modified 

Order 

PUT Open, 

Rejected or 

Closed

Modified • Required data for Partner 2 in request (see SM&VR)

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

• Both trading partners must have feature enabled

Partner 1 Bidirectional 

Modified 

Order 

PUT Modified Open • Required data for Partner 1 in request (see SM&VR)

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

• Partner 1 may submit without feature enabled to move 

Order out of Modified state

Partner 1 Bidirectional 

Modified 

Order 

PUT Modified Modified • Required data for Partner 1 in request (see SM&VR)

• All other Partner 2 data in request will be ignored

• Partner 1 may submit without feature enabled to continue 

to move Order out of Modified state

Partner 2 Bidirectional 

Modified 

Order 

PUT Modified Modified • Required data for Partner 2 in request (see SM&VR)

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

• Partner 2 may submit without feature enabled to continue 

to move Order out of Modified state

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

• 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

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

SFO, depending on the situation) with How to Update 

‘Admin Change’ in FIDS may be altered
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

12

Bidirectional Order Modification

Prerequisite: Both Partner 1 and 2 must have the feature enabled to utilize Bidirectional Order 

Modification at an account level. Bidirectional Order Modification is not a Bizapp that is determined on 

a GT&C, so it may be utilized on any Order within the account without having to specify access at the 

document level. 

• Only Partner 2 based on the specific Order’s Order Originator Partner Identifier (OOPI) may 

initiate a Bidirectional Order Modification. 

o OOPI=Requesting then the Servicing agency may initiate a modification using this 

feature. 

o OOPI=Servicing then the Requesting agency may initiate a modification using this 

feature. 

The Order will use a new Modified (MOD) state to handle state changes while in the Bidirectional 

modification flows (see Order state diagrams below). Once an Order is in the MOD state G-Invoicing 

will allow the Order to proceed through approvals and rejections until it’s in an Open (REC) state, 

even if either account determines to not allow new Orders to enter the MOD state by turning off the 

feature.

G-Invoicing will return the Modification Originator (MO) & Order Modification Status (Mod Status) in 

the response when an Order is within the Modified (MOD) state. This will be used to determine where 

the Order Modification is in within G-Invoicing and should be used within any consuming system to 

determine the Order’s modification state.

• MO - Indicates which agency initiated the Order modification, fields are either Requesting (R) 

or Servicing (S). 

• Mod Status - Indicates the progress through the Modified state, where the Order modification 

is currently within the modification process. The combination of the two fields is used to 

indicate which state the Order modification may enter next.

Once an Order is in the Modified (MOD) state it must continue to progress within the Modified state 

until it is either reverted (back to its original Open or Closed state) or Open. 

As with the standard Order processing there are additional UI states that are supported within GInvoicing that aren’t states the API will utilize, this is the same for Bidirectional Order Modification.

Table 4: Mod Statuses

Requesting Agency Statuses

Mod Status Name Mod Status Code UI Status Name API and/or UI Mod Status

Requesting Update (MO=R) RU Draft UI Only

Requesting Approval RA Pending Requesting Approval UI Only

Shared with Requesting (MO=S) SR Shared with Requesting API & UI

Rejected by Requesting RR Rejected API & UI
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

13

Servicing Agency Statuses

Mod Status Name Mod Status Code UI Status Name API and/or UI Mod Status

Servicing Update (MO=S) SU Draft UI Only

Servicing Approval SA Pending Servicing Approval UI Only

Shared with Servicing (MO=S) SS Shared with Servicing API & UI

Rejected by Servicing RS Rejected API & UI

Diagram 3: Bidirectional Order State Diagram: Seller Facilitated Order (SFO)
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

14

Diagram 4: Bidirectional Order State Diagram: Buyer Initiated Order (BIO)

4.4.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.

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). 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

15

Diagram 5: 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). 

4.4.3 7600EZ 

It is assumed that Partner 1 is the Servicing Agency for 7600EZ, and Partner 2 is the 

Requesting Agency. The Servicing Agency can create a new 7600EZ Invoice or reference an 

existing 7600EZ Invoice to reverse or delete. The Requesting Agency can respond with an 

Accept or Reject transaction, referencing the Servicing Agency’s Invoice, but no action by the 

Requesting Agency is required. The Requesting Agency can also delete an Accept or Reject 

transaction in certain circumstances. There are validation rules described below in Business 

Rules (Section 4.5) and in the Federal Intragovernmental Data Standards (FIDS) that outline 

the requirements for creating a new 7600EZ Invoice and approving, and rejecting, reversing, 

or deleting an 7600EZ invoice. 

Two types of 7600EZ transactions can be submitted by Partner 1: Invoice (011) and Reversed (324), 

which both transfer funds. Partner 2 can also submit two types of 7600EZ transactions: Accepted (201) 

and Rejected (598). Rejected (598) transactions will transfer funds (back) if submitted before the 

expiration of the Rejection Days of the referenced 7600EZ transaction. If the Rejected (598) 

transaction is submitted after the expiration of the Rejection window, then the Rejected (598) will be 

Informational (i.e., INF status) and won’t transfer funds. All Accepted (201) transactions are 

Informational and won’t affect funds transfer. 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

16

Diagram 6: 7600EZ Logical Data Model

4.5 Business Rules 

4.5.1 Common Rules 

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

data being submitted for processing with G-Invoicing.

4.5.1.2 G-Invoicing uses both date and time when validating and persisting data through the 

application program interface (API) & user interface (UI). Through the API we allow the 

agency system to send a specific time with their body request. G-Invoicing does honor 

daylight savings time. So, if a date is transmitted within that period additional logic may 

need to be coded to follow daylight savings time logic when handling time zone offsets.

4.5.1.3 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 typically ignored and 

sometimes not allowed.

4.5.1.4 Attachments may be added to, and deleted from, existing records using the Attachment 

service. 

4.5.1.5 For the add Attachment requests, the attachment ‘FileNm’ in the JSON payload must 

match exactly. 

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

4.5.2 Order Rules 

4.5.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.5.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 (OOPI) on the GT&C agreement. 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

17

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

4.5.2.4 Every change made to an Order will force a new Business Transaction Identifier (BTI) to 

be assigned to that record. The BTI is returned for all Pull and Push Order requests. 

4.5.2.5 When calling the Update Order resource, agency systems must return the BTI in the 

JSON payload, thus ensuring they are updating the most recent version of the Order 

record. 

4.5.2.6 An out of sequence or invalid BTI 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”). 

4.5.2.7 Order requests may only be submitted with a Document Status Code of SP2 – Shared 

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

submitted with a Document Status Code other than those listed here will result in an error. 

4.5.2.8 For close Order requests: 

• Only the requesting agency may close an Order. 

• 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). 

• 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.5.2.9 Orders having Performance in ‘PND’ (pending settlement) status cannot be closed (until 

the Performance has settled). 

4.5.2.10 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 that the servicing agency 

considers the Schedule fully performed. 

• Schedule has been Cancelled.
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

18

4.5.2.11 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.5.2.12 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., Group Name). 

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

result in an error. (See SM&VR document for details). 

4.5.2.13 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.5.2.14 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, C- Cancelled) for 

Order Line Status and Order Schedule Status. 

• 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). 

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

with missing lines or schedules will be rejected. 

• 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.5.2.15 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.5.2.16 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.5.2.17 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.5.2.18 Administrative Changes are only allowed when the Order is in Open status. 

4.5.2.19 Any attempt to Administratively Change values of data elements on a Schedule against 

which Performance has been reported will result in an error.

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

their agency’s data. 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

19

• Any attempt to make Administrative Changes with neither the Requesting nor 

Servicing Order Manager roles will result in an error. 

• Any attempt to Administratively Change their trading partner’s data without 

proper permissions will be ignored (not resulting in an error). 

• 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.5.2.21 Opportunities for Administrative Changes are the same regardless of which partner 

originated the Order. 

4.5.2.22 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): 

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

performance reported against it. 

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

Quantity performed for any Performance Type.

• This includes the sum of Advance(s), the sum of Delivered/Performed and the 

sum of Received/Accepted, all which cannot exceed the Order Schedule 

Quantity. 

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

had already Advanced, Delivered/Performed or Received 15 units, 

the Schedule Quantity cannot be changed to below 15 units. 

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

Delivered/Performed plus the Quantity of a Deferred Payment in INF 

(informational) status reported in an open Accounting Period. 

• For example, if the Schedule Quantity is 20 units and the servicing agency has 

delivered 10 units and deferred 5 units, the Schedule Quantity cannot be 

changed to below 15 units (10 + 5). 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

20

4.5.2.23 Reverting an Order is only allowed when both Trading Partners have enabled the 

feature for their agency account.

4.5.2.24 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 (P1A):

▪ BIO: Pending Requesting Approval

▪ SFO: Pending Servicing Approval

▪ Rejected (REJ)

• API: Allows Order Revert in the following state:

▪ Rejected (REJ)

▪ Through the API the client submits a Revert (REV) to an 

Order that is in Rejected and G-Invoicing reverts the 

Order back to is previous Open or Closed status.

4.5.2.25 When an Order is Reverted the current version of the Order is physically deleted 

and the previous Order is returned; along with the Modification Number, Business 

Transaction ID (BTI) and Order status Open (REC) or Closed (CLZ). 

4.5.2.26 The Order Revert event is captured in the Order’s audit log which can be viewed 

within the G-Invoicing UI.

4.5.3 Performance Rules 

4.5.3.1 Agencies granted data access to an Order will be allowed to access Performance related 

to that Order. 

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

4.5.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 Line within 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.

• Performance may only be submitted against an Order schedule(s) that 

have already received Performance prior to the modification. This is to 

make sure that data isn’t changed on the Order Line/Schedule during a 

modification that would be used on the initial Performance transaction. 

Performance locks down data to allow additional Performance to occur 

during the Order modification.
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

21

4.5.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.5.3.4 Each performance transaction must originate from the appropriate trading partner, as 

defined for Performance Type in the FIDS. 

• The requesting agency can only submit Received/Accepted transactions. 

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

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

4.5.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). 

• Despite this condition, a Delivered/Performed transaction does not reference 

an Advance. This allows one delivery to cover multiple advances 

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

Delivered/Performed detail with a positive quantity. 

• See Performance FIDS for information on how to reference a performance 

transaction and its detail record(s). 

4.5.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. 

4.5.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) 

• When two Accounting Periods are open simultaneously, Deferred Payment 

cannot be reported against the later of the two periods. 

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

4.5.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. 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

22

• This rule is needed because Performance Status is tracked at the header 

level, and this “mixture” could result in one or more detail records of Status 

‘PND’ (pending) with other detail records of Status ‘INF’ (informational), which 

cannot be supported. 

Performance Date Rules

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

4.5.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.5.3.14 For all non-Advance Performance, the Accounting Period submitted with the transaction 

must be an open period. 

4.5.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.5.3.16 The servicing agency is not allowed to submit a future dated Deferred Payment. 

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

4.5.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.5.3.19 Adjustments are made by submitting Performance having a negative quantity that 

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

4.5.3.20 A future dated Performance can be deleted until the point at which the Performance Date 

is no longer in the future. 

• Future dated Performance transactions that have been logically deleted are 

set to ‘XXX’ (deleted) status. 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

23

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

Order is eligible for closure or modification. 

4.5.3.22 Future dated Performance cannot be adjusted. 

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

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

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

4.5.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.5.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.5.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. 

• This includes the sum of Advance(s), the sum of Delivered/Performed and 

the sum of Received/Accepted. 

4.5.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 reported 

through the accounting period of the new Deferred Payment). 

• Example: Schedule Quantity = 50 and two accounting periods are open (May 

and June). Servicing agency reports Delivered/Performed of 30 in May and 

20 in June. The servicing agency is allowed to report a Deferred Payment of 

20 in May because June’s Delivered/Performed (of 20) does not count 

against May’s Undelivered Balance (of 20). 

• A previously reported Deferred Payment (for a specific accounting period) 

does not count against the Undelivered Balance because the newly reported 

Deferred Payment will replace the old one (for the same accounting period). 

4.5.3.28 The quantity of a Delivered/Performed reported against a Schedule may not exceed the 

Undelivered Balance of that Schedule (i.e., Schedule Quantity minus the sum of all 

Delivered/Performed minus any active Deferred Payment for the same accounting period 

as the new Delivered/Performed). 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

24

• In this case a previously reported Deferred Payment (in the same accounting 

period as the newly reported Delivered/Performed) counts against the 

Undelivered Balance because it represents goods delivered (or work 

performed) but not yet paid for. 

4.5.3.29 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.5.3.30 Performance quantity of zero is not allowed for Advance Payment transactions submitted 

by the servicing agency. 

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

agency and Received/Accepted from the requesting agency. 

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

references a previous performance detail. 

• 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.5.3.33 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.5.3.34 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 on Constructive Receipts. 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

25

4.5.3.35 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. 

Performance Settlement Rules

4.5.3.36 Performance which does not result in settlement is set to ‘INF’ (informational only) or 

‘PRE’ status. 

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

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

4.5.3.39 Performance Type 548 (Advance) always triggers settlement and is the only way to trigger 

settlement when the Advance Payment Indicator is True on the Schedule. 

4.5.3.40 Performance requiring settlement but having a future Performance Date is settled when 

that Performance Date occurs. 

4.5.3.41 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.5.3.42 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.5.3.43 Exceptions: 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.5.3.44 Performance for which settlement has occurred is set to ‘STL’ (settled) status. 

4.5.4 7600EZ Rules 

4.5.4.1 7600EZ transactions do not reference a G-Invoicing Order, but they do reference either a 

GT&C or a 7600EZ Invoice (011) 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

26

4.5.4.2 Referenced GT&C’s must be in an Open status and allow 7600EZ transactions, meaning 

that the Business Application (Bizapp) selected on the GT&C aligns with 7600EZ. 

4.5.4.3 The Servicing Agency can submit transaction types of Invoice (011) and Reversed (324). 

4.5.4.4 The Requesting Agency can submit transaction types of Rejected (598) and Accepted 

(201). 

4.5.4.5 Invoice (011) transactions must reference a GT&C when sending a request with a POST 

method. 

4.5.4.6 The Servicing Agency may submit a request with a DELETE method, but it can only 

reference an Invoice (011) with a status of Pending (PND). This changes the Invoice (011) 

status from Pending (PND) to Deleted (XXX). 

• The Servicing Agency cannot delete an Invoice (011) that is in Settled (STL) 

status. 

4.5.4.7 The Requesting Agency may submit a request with a DELETE method, but it can only 

reference a Rejected (598) or Accepted (201) in Informational (INF) status. This changes 

the status from Informational (INF) to Deleted (XXX). 

• The Requesting Agency cannot delete a Rejected (598) that is in Settled 

(STL) status. 

4.5.4.8 Reversed (324), Rejected (598) and Accepted (201) must always reference an existing 

Invoice (011). 

• All referencing transaction are for the full Performance Amount of the 

referenced Invoice (011). 

• 7600EZ doesn’t allow partial adjustments, rejections, or acceptance. 

▪ Example: Servicing Agency submits an Invoice (011) for $100 

which is Settled (STL). If the Servicing Agency submits a 

Reversed (324) transaction, it would be for the full $100. Same if 

the Requesting Agency either submits a Rejected (598) or 

Accepted (201), it would be for the full $100 Performance 

Amount. 

4.5.4.9 The Requesting Agency may submit a Rejected (598) within an Invoice (011) Rejection 

window. When this occurs the Rejected (598) status will be Pending (PND) until Settled 

(STL). This transaction will move funds back to the Requesting Agency. 

• The Rejection Days window is based on the GT&C’s BizApp condition. For 

example, GSA Fleet 7600EZs can have a Rejection Days of 30 days from 

when the Invoice is created and other EZ types could have Rejection Days 

more or less than 30 days. This BizApp condition data is configurable and 

the current BizApp conditions are available via the Feature Management 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

27

APIs, additional information is available here: Feature Management and 

BizApp 

4.5.4.10 The Servicing Agency may submit a Reversed (324) transaction after the referenced 

Invoice (011) is Settled (i.e., status is STL) if the following has not occurred: 

• The Requesting Agency has not submitted a Rejected (598) within the 

Rejection window. 

4.5.4.11 The Requesting Agency may submit a Rejected (598) or Accepted (201) at any time, even 

before the Invoice (011) has Settled (STL) unless the Servicing Agency has already 

submitted a referencing Reversed (324) to the Invoice (011). 

• If the Invoice (011) is in Pending (PND) status (i.e., the Invoice’s 

Performance Date is in the future and Settlement has not occurred) when 

the Requesting Agency submits a Rejected (598) it will cause the Invoice 

(011) to move from Pending (PND) to Informational (INF) status. The 

Rejected (598) will be in Informational (INF) status, as it won’t affect funds 

transfer. Neither the Invoice nor the Rejected transaction will generate funds 

settlement in this case. If the Rejected (598) is Deleted (XXX) the Invoice 

(011) will remain in Informational (INF) status.

4.5.4.12 The Requesting Agency may submit a Rejected (598) or Accepted (201) if the referenced 

Invoice (011) doesn’t have an Informational (INF) or Pending (PND) Rejected (598) or 

Accepted (201) transaction. 

• The Requesting Agency can delete a Rejected (598) or Accepted (201) and 

resubmit a new Rejected (598) or Accepted (201) in this case. 

4.5.4.13 The Requesting and Servicing Agency can’t reference a EZ transaction that is in Deleted 

(XXX) status with another EZ transaction but can view or pull transactions that are in 

Deleted (XXX) status. 

7600EZ Date Rules

4.5.4.14 7600EZ Performance Date must always fall within the GT&C Start and End dates. 

4.5.4.15 All 7600EZ transactions must always be within an open Accounting Period and depending 

on when a 7600EZ transaction is received by G-Invoicing this will determine which 

Accounting Period(s) are available at that date/time. The Performance Date doesn’t have 

to be within the provided Accounting Period and in many cases with past dating a 

Performance Date it will not. 

4.5.4.16 The Servicing Agency may record an Invoice (011) with a future Performance Date, 

provided the date falls within the current open Accounting Period. 

• Example: On May 27 the Servicing Agency reports Invoice (011) 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 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

28

Date, that transaction would result in an error and would not be created, 

because the June Accounting Period is not open. 

4.5.4.17 The Servicing Agency may record an Invoice (011) with a past Performance Date; 

although, the Accounting Period submitted with the transaction must be an open period. 

• Example: On May 2 the Servicing Agency reports an Invoice (011) with a 

Performance Date of February 10. This is allowed, but the Accounting 

Period submitted with the transaction must be either the April or May period 

as both are open on the May 2 Transaction Date (when the transaction was 

created in GInvoicing). 

4.5.4.18 The Servicing Agency can Delete an Invoice (011) with a future Performance Date while 

the Invoice (011) is in Pending (PND) status. 

4.5.4.19 The Servicing Agency cannot submit a Reversed (324) with a future Performance Date. 

4.5.4.20 The Servicing Agency may submit a Reversed (324) with a past Performance Date, but it 

must not be before the referenced Invoice (011) Performance Date. 

• The Accounting Period submitted with the Reversed (324) must be an open 

Accounting Period. 

▪ Example: On March 20 the Servicing Agency submits an Invoice 

(011) with a Performance Date of February 10. On May 20 the 

Servicing Agency submits a Reversed (324) with a Performance 

Date of April 15. 

▪ This is allowed, but the Accounting Period submitted with the 

Reversed (324) must be for the May Accounting Period, which is 

the only open Accounting Period when the Reversed (324) is 

submitted on May 20. 

4.5.4.21 The Requesting Agency is not allowed to submit a future dated 7600EZ transaction. 

4.5.4.22 The Requesting Agency may reference an Invoice (011) when submitting either an 

Accepted (201) or Rejected (598) with a Performance Date in the past. 

• When the referenced Invoice’s Performance Date is less than the 

Transaction Date then the Accepted/Rejected Performance Date must be 

greater than or equal to the Invoice’s Performance Date. i.e., the Servicing 

Agency backdated the Invoice’s Performance Date.

• When the referenced Invoice’s Performance Date is equal to or greater than 

the Transaction Date then the Accepted/Rejected Performance Date must 

be equal to or greater the Invoice’s Transaction Date. 

▪ Example: The Servicing Agency submits an Invoice with the same 

Performance date and Transaction Date or the Servicing Agency 

future dates the Invoice’s Performance date. 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

29

▪ Example: On June 10 the Servicing Agency reports an Invoice 

(011) with a Performance Date of June 5. On June 15, the 

Requesting Agency may reference the Invoice (011) with a 

Performance Date between June 5 and June 15. 

• The Accounting Period submitted with the Accepted (201) or Rejected (598) 

must be an open Accounting Period. 

7600EZ Settlement Rules

4.5.4.23 The Requesting Agency Accepted (201) is always Informational (INF), which means it will 

not result in settlement or funds transfer. 

4.5.4.24 7600EZ transactions for which settlement has occurred are set to Settled (STL) status. 

4.5.4.25 An Invoice (011) with a future Performance Date will be Settled (STL) when that 

Performance Date occurs. 

• An Invoice (011) to be Settled (STL) is set to Pending (PND) status. 

4.5.4.26 The Requesting Agency Rejected (598) will result in settlement or funds transfer when 

submitted within the Rejection window of the Invoice (011). If the Rejected (598) is 

submitted outside the Rejection window, then it will be Informational (INF). 

• The Rejection window is determined by the 7600EZ Business Application 

(BizApp) assigned to the referenced GT&C. 

▪ Example: The Rejection window for the ‘EZ 10k’ BizApp is 30 calendar 

days, and BizApp ‘EZ 10k’ is assigned to the referenced GT&C. The 

Servicing Agency submits an Invoice (011) on December 5 with a

Performance Date of December 10, the Rejection window for the Invoice 

(011) will end on January 9 (30 days after December 10). So, if the 

Requesting Agency submits a Rejected (598) on or before January 9 

then the Rejected (598) will result in a Settled (STL). (i.e., It will generate 

a funds transfer to reverse the Invoice settlement that occurred on 

December 10). 

4.5.4.27 7600EZ transactions for which settlement has failed is set to ‘ERR’ (error) status. 

• Errors will be corrected by the G-Invoicing Production Support team (if 

possible, not by an agency user or agency system) 

4.6 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 JSON 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 G- Invoicing 

application. (Search for ‘attachment’). 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

30

4.7 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.8 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 GInvoicing (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.9 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 JSON OpenAPI 

documents published on the Fiscal Service G-Invoicing Resource site.

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 JSON OpenAPI documents.

4.9.1 Attachment - Data Elements 

Table 5: Attachment Push Data Elements 

Familiar Name JSON Attributes Definition Constraints Optionality

Attachment File 

Name 

“fileNm” The actual name of the attachment 

file. 

Note: Not passed on Delete 

String [1, 132] 

Maximum length = 

132 String UTF-8 

Required 

Delete: N/A 

Attachment File 

Alias 

“fileNameAlias” Descriptive name for an attachment. 

Different from the name assigned to 

the file itself. 

Note: Not passed on Delete 

String [0,132] 

Maximum length = 

132 String UTF-8 

Optional 

Delete: N/A 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

31

Document 

Number 

“documentNumber” Unique identifier for a document 

which the attachment will be 

associated. 

String [1, 20] 

Maximum length = 

20 String UTF-8 

Required 

Buy Sell 

Indicator 

Note: G-Invoicing 

needs this info in 

case the client has 

access to the 

transaction from both 

the servicing and 

requesting sides.

“buySellIndicator” 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.9.2 Response – Data Elements 

The data elements in Table 4 below will be returned in the body of every response generated by GInvoicing. 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

32

Table 6: Call Detail Response Data Elements 

Familiar Name JSON Attributes 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 

Optional 

length = 50 

String UTF8 

G-Invoicing 

Tracking Identifier 

“ginvTrackingID” Unique tracking identifier, generated by 

G-Invoicing. 

String 

[50] 

Minimum 

length = 0 

Maximum 

length = 50 

String UTF8 

Required 

Environment “environment” Describes the environment in which the 

system interface resides. 

String 

[30] 

Minimum 

length = 0 

Maximum 

length = 30 

String UTF8 

Required 

Request Type “requestType” Type of request that was submitted to 

G-Invoicing by the agency system. 

 String 

[30] 

Minimum 

length = 0 

Maximum 

length = 30 

String UTF8 

Note: Values are derived from the 

service that is being accessed. 

Required 

Record Count “recordCount” The total number of records in the 

payload. 

Integer Required 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

33

Table 7: Attachment Response Data Elements 

Familiar Name JSON Attributes Definition Constraints Optionality

Attachment File 

Name 

“fileNm” The actual name of the attachment 

file. String [1, 132] Maximum 

length = 132 String UTF8 

Required 

Attachment File 

Alias 

“fileNameAlias” Descriptive name for an attachment. 

Different from the name assigned to the 

file itself. 

String [0,132] Maximum length 

= 132 String UTF8 

Optional 

Attachment ID “iddrz ” Unique identifier for an attachment. Integer 

Maximum length = 30 

Required 

Attachment 

Updated By 

“createUsr” The user’s name or partner (Buyer or 

Seller) that uploaded the attachment String [0,100] Maximum length 

= 100 String UTF8 

Required 

Attachment Date 

Time 

“uploadDtTm” 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 UTF8 

Required 

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 “errors” element will 

vary depending on the error 

condition. 

{ 

 "callDetail": { 

 "environment": "Production", 

 "recordCount": "1" 

 }, 

 "errors": [ 

 { 

 "code": "400", 

 "message": "EZ record not found" 

 } 

 ] 

}
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

34

2 403 – Unauthorized 

AccessDeniedException 

Note: Message text included 

in the "errors" element will 

vary depending on the error 

condition. 

{ 

 "callDetail": { 

 "environment": "Production", 

 "recordCount": "1" 

 }, 

 "errors": [ 

 { 

 "code": "403", 

 "message": "No authorized user found for partner: partnerId, system: systemId." 

 } 

 ] 

}

3 500 – Internal Server Error 

ServerException 

Note: Message text included 

in the "errors" element will 

vary depending on the error 

condition. 

{ 

 "callDetail": { 

 "environment": "Production", 

 "recordCount": "1" 

 }, 

 "errors": [ 

 { 

 "code": "500", 

 "message": "An unexpected error was encountered.." 

 } 

 ] 

}

6 Interface Integrity 

6.1 Treasury Web Application Infrastructure (TWAI) 

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. 

6.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. 

7 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-
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

35

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. 

8 Revision History 

Vers. 

Num. 

Date of 

Change 

G-Inv 

Rel. Change/Revision Description Page/Section Affected 

1.0 2/27/2023 5.1 Initial Draft of JSON documentation All 

1.1 6/23/2023 5.2 Updated Order and Performance for new 

Order Revert and Performance while 

Mod features

Update Diagram 2

Table 2

4.5.2.7

4.5.3.2

Added 4.5.2.15

1.2 7/17/2023 5.2 Corrected EZ attachment version number 3.2.8 Resource: 

New Attachment

1.3 3/01/2024 7.0 Update Order section for Bidirectional 

Modification feature

Included additional verbiage on 

restrictions to the Performance while 

Mod feature

4.4.1

4.5.3.2
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

36

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: (a) need not respond to zero quantity Performance by 

the servicing agency, and (b) must actively receive/accept an adjustment to 

Delivered/Performed. 

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. 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

37

Appendix B: 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. 

End of Month 

Unlike some accounting systems, G-Invoicing does not physically reverse Deferred Payments (aka, 

accruals) at the month when an accounting period is closed. Instead, G-Invoicing no longer counts 

previous months’ Deferred Payment(s) as accruals in the current period. 

To reduce confusion, G-Invoicing only permits reporting of Deferred Payments in the earlier accounting 

period when two periods are open. Thus, any attempt to report a Deferred Payment in the later open 

period will result in an error. 

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. 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

38

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). 

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 
NONCONFIDENTIAL // EXTERNAL 

G-Invoicing System Interface Specifications – Push: Order, Performance and 7600EZ

Version 1.3 – March 2024

39

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 

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.