NONCONFIDENTIAL // EXTERNAL

Recent G-Invoicing 

Development 

Release 4.5 – 7.0

03/16/2024
NONCONFIDENTIAL // EXTERNAL

Page 2 L EAD ∙ T RANSFORM ∙ D ELIVER

• JSON APIs

• Organization API Updates

• Feature Management & Business Applications (BizApp)

• Constructive Order Acceptance (COA) – GSA Rent

• 7600EZ

• Previously (PRE) Settled Advances

• Order Enhancements

– Performance while Order Modification

– Order Revert

– Bidirectional Modification

• Appendix

Agenda
NONCONFIDENTIAL // EXTERNAL

Page 3 L EAD ∙ T RANSFORM ∙ D ELIVER

Recent Releases 4.5 to 7.0

Release Number Release Date Major Features

4.5 06/30/22 Internal GTAS API and ATB Summary Report

4.6 09/15/22 Order/Performance UI rewrite, ATB Summary Report, GT&C Whitelist

5.0 02/16/23 Order Upload, 7600EZ, Feature Management, Date Time Standardization to EST and 

Advance PPQ

5.1 05/18/23 COA, Order/Performance JSON and Order/Performance Whitelist

5.2 07/27/23 Order Revert & Performance while Mod

6.0 09/14/23 CAIA

7.0 03/16/24 Bi-Directional Order Mod, GTC 508 Improvements and DLA BizApp
NONCONFIDENTIAL // EXTERNAL

JSON APIs
NONCONFIDENTIAL // EXTERNAL

Page 5 L EAD ∙ T RANSFORM ∙ D ELIVER

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

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

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

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

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

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

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

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

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

Orders, Performance or 7600EZ documents.

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

o Get Groups for a GT&C

o Get Groups in an Agency Account (New Parameter)

o Get TAS-BETCs for a Group

o Get Accounts (New)

o Get ALCs by Agency Account (New)

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

o Get Feature Flags

o Get BizApps

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

Available APIs
NONCONFIDENTIAL // EXTERNAL

Organization API Updates
NONCONFIDENTIAL // EXTERNAL

Page 7 L EAD ∙ T RANSFORM ∙ D ELIVER

• New endpoint: Get Agency Accounts

– This endpoint allows systems to extract a list of active Agency Accounts from G-Invoicing. The resulting 

JSON will be a list of all Agency Accounts within the environment unless the system passes the optional 

parameter to reduce the changes to a specified date/time. This endpoint will relate G-Invoicing’s 

Account IDs to their Agency Names.

– Path: /ginv/services/v1_0/groups/accounts

• Opional Parameter Name: lastModifiedDateTime

• Description: Limits results to Agency Accounts that have been updated since the passed date/time. 

• Type: dateTime Format: YYYY-MM-DDThh:mm:ss.SSSZ or YYYY-MMDDThh:mm:ss.SSS+|-00:00 

– Can be formatted in Zulu (UTC) or with a time zone offset. All responses in JSON will be returned in Zulu (UTC) 

• Business Rule: 

– The lastModifiedDateTime is incremented when the Agency Account updates their Organizational Group 

structure within G-Invoicing. 

• Field is updated when an Account Admin adds a new group, deletes an existing group, or updates an existing group 

– Updates to a group may include any or all the following actions: 

» Adding/removing ALC(s), TAS filters, updating the Group Name or Description, or changing the status of the group. 

– Only active Agency Accounts are returned in the response. 

Org API Updates: Get Agency Accounts

lastModifiedDateTime
NONCONFIDENTIAL // EXTERNAL

Page 8 L EAD ∙ T RANSFORM ∙ D ELIVER

• New endpoint: Get ALCs

– This endpoint allows systems to extract a list of Agency Location Codes (ALCs) that are assigned to Agency 

Accounts from G-Invoicing. The resulting JSON will be a list of all (A=Active or I-Inactive) ALCs within the 

environment unless the system passes the optional accountId query parameter to reduce the ALCs returned to that 

specific Agency Account.

– Path: /ginv/services/v1_0/groups/accounts

• Parameter Name: accountId

• Description: Limits results to an Agency Account 

• Type: string [38]

• Required: False

Org API Updates: Get ALCs by Agency Accounts

lastModifiedDateTime
NONCONFIDENTIAL // EXTERNAL

Page 9 L EAD ∙ T RANSFORM ∙ D ELIVER

• Get Agency Accounts Response 

Example:

Org API Updates
NONCONFIDENTIAL // EXTERNAL

Page 10 L EAD ∙ T RANSFORM ∙ D ELIVER

• Endpoint: Get Groups in an Agency Account

– This endpoint allows clients to extract detail data describing all organizational Groups within either the 

Agency Account for the requested System ID or if the optional accountId is passed for a specific Agency 

Account other than the one assigned to the System ID. The resulting JSON is in a hierarchical format, 

suitable for simulating the organizational tree in G-Invoicing. 

– Path: /ginv/services/v1_0/groups/

• New Parameter: accountId

• Description: Identifies the Agency Account which data will be provided.

– Clients may now pull Org group hierarchical data for specific Agency Accounts other than their own. This 

may used to store Agency group structures locally instead of having to call for this data.

Org API Updates: Get Groups in an Agency Account

lastModifiedDateTime
NONCONFIDENTIAL // EXTERNAL

Feature Management & 

Business Application (BizApp)
NONCONFIDENTIAL // EXTERNAL

Page 12 L EAD ∙ T RANSFORM ∙ D ELIVER

• BizApp is a data element on the GT&C 

– Definition: A particular product line or type of operation, typically documented on an agreement between two business 

partners, and used to control attributes of that agreement and/or characterize transactions occurring under that 

agreement

• Allows G-Invoicing to apply conditional logic to govern documents

• The data structures for Features and BizApps intersect. Two basic rules are that all BizApps are Features, 

but not every Feature is a BizApp. The connector between these two data sets is the Feature Code contained 

in the BizApp data, which points to a Feature.

Feature Management & Business Application

lastModifiedDateTime
NONCONFIDENTIAL // EXTERNAL

Page 13 L EAD ∙ T RANSFORM ∙ D ELIVER

• There are two Endpoints for Feature Management: Get Feature Flags & Get BizApps

• Get Feature Flags

– This endpoint allows clients to extract all reference data describing G-Invoicing’s features, along with agency Feature 

Flags indicating agency availability to use each a specific feature as a requesting partner and (separately) as a 

servicing partner.

– Path: /ginv/services/v1_0/feature/feature-flags/ 

– The response contains all active Features, and each feature is available to 0:M (zero-to-many) agencies, separately 

on the requesting side and on the servicing side

Feature Management & Business Application

lastModifiedDateTime
NONCONFIDENTIAL // EXTERNAL

Page 14 L EAD ∙ T RANSFORM ∙ D ELIVER

• Get BizApps

– This endpoint allows clients to extract all reference data 

describing G-Invoicing’s features, along with agency Feature 

Flags indicating agency availability to use each a specific 

feature as a requesting partner and (separately) as a 

servicing partner.

– Path: /ginv/services/v1_0/reference/bizapp/

– The response contains all active BizApps and all active 

BizApp Conditions.

Feature Management & Business Application

lastModifiedDateTime
NONCONFIDENTIAL // EXTERNAL

Constructive Order Acceptance (COA)
NONCONFIDENTIAL // EXTERNAL

Page 16 L EAD ∙ T RANSFORM ∙ D ELIVER

• Trading partners must agree to allow COA Orders on a GT&C

• Orders will automatically move to Open or Rejected status after COA Days expire

– COA Days is an attribute of the COA BizAPP (Currently set to 7 days)

• COA applies to both new and modified Orders

• GT&C Validations

– Order Originating Partner Indicator = Servicing 

– Assisted Acquisition Indicator = No

• Order Validations

– FOB Point must be ‘Source’

– Assisted Acquisition Indicator must be No

• Additional Fields may be supplied by Servicing Agency on Order

• Requesting Bona Fide Need & Requesting TAS/BETCs 

– May be supplied on an Order Modifications by Servicing Agency )

– Requesting Agency may still edit fields

Constructive Order Acceptance (COA)
NONCONFIDENTIAL // EXTERNAL

Page 17 L EAD ∙ T RANSFORM ∙ D ELIVER

• Conditions when to constructively accept an Order (REC)

– Order is in either SP2 (shared with partner 2) or P2A (pending partner 2 approval) status

– COA Days expires

– All required data is valid

– When Order is moved to REC:

• Any missing approval date will be set to the current date

• Any missing approver name will be set to ‘System’

• Any missing approver title will be set to ‘Constructive Order Acceptance’

• Any missing approver e-mail address will be set to ‘Do not reply’

• Any missing approver phone number will be set to ‘Do not call’

– Note: There are two approvals required for each partner (i.e., program and funding officials). COA will supply the missing 

data for one or two Partner 2 approvers.

• Conditions when to constructively Reject an Order (REJ)

– Order is in either SP2 (shared with partner 2) or P2A (pending partner 2 approval) status

– COA Days expires

– Any required data is invalid

Constructive Order Acceptance (COA)
NONCONFIDENTIAL // EXTERNAL

7600EZ
NONCONFIDENTIAL // EXTERNAL

Page 19 L EAD ∙ T RANSFORM ∙ D ELIVER

7600EZ API & UI process that will transfer funds through G-Invoicing.

– The process is a combination of existing Order & Performance data

• Required data has been reduced

• Does not require approval within G-Invoicing to transfer funds, but does allow the Requesting Agency to Reject or 

Approve a transaction

– Trading partners must agree to allow 7600EZ transactions on a GT&C

• Servicing Agency initiates the transaction by submitting an Invoice

– 7600EZ transactions will reference the agreed upon GT&C

• There won’t be an Order stored in G-Invoicing for this process, but Order & Performance data will be stored with 

the 7600EZ Invoice.

– Transactions will be limited to $10,000.00 or less and will be transmitted in dollar amounts

• Exemptions to the threshold amount are allowed for these specific business lines (others may be added later at a 

future date):

– GSA Fleet Leasing (7600EZ)

– GSA Global Supply (7600EZ)

– GPO Print/Publishing (7600EZ)

– DLA Materiel (7600EZ)

7600EZ - Overview 
NONCONFIDENTIAL // EXTERNAL

Page 20 L EAD ∙ T RANSFORM ∙ D ELIVER

The Servicing Agency may submit the following transaction types:

Invoice

• Invoices must reference a specific Open GT&C that has a Business Application of 7600EZ.

• Servicing Agency may create multiple Invoices on a single GT&C

– If the referenced GT&C is setup for multiple documents

• The Invoice amount could be limited based on the Business Application on the GT&C 

• The 7600EZ Invoice amounts will be deducted from the GT&C amount

– Trading partners may still agree to limit the amount of the Invoices to not exceed the estimated GT&C amount

• Invoices will settle funds when the Performance Date occurs

– If it’s not Deleted or Rejected before the Performance Date

Reversed

• Reversed transactions must reference an Invoice

• The Servicing Agency may reverse an Invoice in Settled status which hasn’t been Rejected within the Rejection Days* or 

already Reversed. 

• The Servicing Agency may Delete an Invoice that is in Draft (User Interface only) or Pending status. 

*Rejection Days are explained on slide 20

7600EZ - Servicing Agency Actions
NONCONFIDENTIAL // EXTERNAL

Page 21 L EAD ∙ T RANSFORM ∙ D ELIVER

The Requesting Agency may submit the following transaction types:

Accepted

• Accepted transactions must reference an Invoice

• Accepted transactions are always Informational and never move to Settled status i.e., will never transfer funds

Rejected

• Rejected transactions must reference an Invoice

• Rejected transactions can be Informational or Settled

– If a Rejected transactions is submitted within the Rejection Days*, then the Rejected response will 

transfer funds when it moves to Settled status

– If a Rejected transaction is submitted outside the Rejection Days*, then the Rejected response 

transaction will not transfer funds and the status will be Informational

7600EZ - Requesting Agency Actions (1 of 2)
NONCONFIDENTIAL // EXTERNAL

Page 22 L EAD ∙ T RANSFORM ∙ D ELIVER

Rejection Days:

• The Rejection Days are the length of time (in full calendar days) for the Requesting Agency’s Rejected 

transaction to initiate funds reversal of the referenced Invoice.

• The Rejection Days window is determined by the specific Business Application on the GT&C. Each Business 

Application may have different number of days to allow the Requesting Agency to reject an Invoice 

transaction. 

• The Rejection Days are calculated based on the Transaction Date (when the Invoice was created in GInvoicing) or Performance Date (when the service or good occurred and settlement was initiated for the 

event) 

– Rejection Days will use the Transaction Date when the Invoice’s Performance Date is backed dated into the past

– Rejection Days will use the Performance Date when the Invoice’s Performance Date is future dated or it’s later than 

the date of the Transaction Date

• The Requesting Agency may Delete an Accepted or Rejected transaction that is in Informational status, 

which is a status update and not a transaction type.

See Appendix for additional information 

7600EZ - Requesting Agency Actions (2 of 2)
NONCONFIDENTIAL // EXTERNAL

Previously (PRE) Settled Advances
NONCONFIDENTIAL // EXTERNAL

Page 24 L EAD ∙ T RANSFORM ∙ D ELIVER

• Allows the Servicing Agency to record an Advance transfer that processed outside of G-Invoicing 

in which future Delivered/Performed transactions will be transmitted within G-Invoicing

• Only allowed on Orders that have an In-Flight Order Indicator as “Yes”

– In-Flight Order Indicator may only be update through the Order Upload or G-Invoicing UI

Previously (PRE) Settled Advances
NONCONFIDENTIAL // EXTERNAL

Page 25 L EAD ∙ T RANSFORM ∙ D ELIVER

• Order Document Type:

– APIOrder: Created through API

• No way to differentiate a new vs a IFO through the API push

– UIOrder: New Order created through UI

– UIOrderUpload: New Order created through Order 

Upload

• These two fields would allow a PRE Advance:

– UIOrderIFO: In-flight Order created through our UI

– UIOrderUploadIFO: In-flight Orders created through our 

Order Upload feature

Order Pulls: Order Document Type 
NONCONFIDENTIAL // EXTERNAL

Page 26 L EAD ∙ T RANSFORM ∙ D ELIVER

Create PRE Advance through API
NONCONFIDENTIAL // EXTERNAL

Order Enhancements

Performance while Order Modification

Order Revert

Bidirectional Modification
NONCONFIDENTIAL // EXTERNAL

Page 28 L EAD ∙ T RANSFORM ∙ D ELIVER

• Order Revert (Released in 5.2): 

‒ Allow the agency that initiated the modification (Partner 1) to Revert the Order back to its previous 

version

‒ Is available for v2 and v3 APIs

• Performance while Order Mod (Released in 5.2): 

‒ Allow Performance to be reported while previously open Order is being modified

‒ Is available for v2 and v3 APIs

• Order Bidirectional Mod (Future Release): 

‒ Allow partner 2 to initiate Order modification

‒ Only functions with the v3 API

v2: XML endpoints

v3: JSON endpoints

Order Enhancements
NONCONFIDENTIAL // EXTERNAL

Page 29 L EAD ∙ T RANSFORM ∙ D ELIVER

Current Order flow for rejection by Partner 2

1. Partner 1 introduces modification to open Order, then approves

2. Partner 2 rejects the modification (with Reason)

3. Partner 1 must then restore previous values of the Order – New option will be Revert

4. Both partners must re-approve the Order (as it was)

Order Mod and Archives

• The highest Order Modification Number (Mod ‘n’) is still considered the active Order

• Previous Mod Numbers are archived (Open or Closed status)

• Access to previous Mods:

• New optional parameter for v2 (XML) & v3 (JSON) Order detail pull to query on “modNbr” to access 

previously archived Order data

• UI users will have the same availability to access previous mods through the Order detail page

Order Revert 
NONCONFIDENTIAL // EXTERNAL

Page 30 L EAD ∙ T RANSFORM ∙ D ELIVER

• Partner 1 Order Manager/Approvers are provided new Revert option

‒ Partner 1 will have the ability to Revert from the following Order states:

• API: Revert (REV) an Order in REJ (Rejected) or MOD (Modification) if Mod Status is Rejected by Servicing (RS) 

or Rejected by Requesting (RR)

• UI: Revert an Order in DR (Draft), P1A (Pending Requesting/Servicing Approval), REJ (Rejected) or MOD 

(Modification) when Mod Status is RS or RR

• Active Order is replaced by archived version (Mod ‘n – 1)

• Can only revert an Order back 1 Mod number (the previous one)

• Must supply a reason for the Revert action - will be stored with the Order until the status is updated

• Business Transaction ID (BTI) from archived Order will be restored

• Last Updated Date/Time will be updated

• Abandoned modification (number ‘n’) is audited, deleted (no record will remain), and the Mod Number will be 

made available for reuse

Example: Order in Mod 5 is currently in Rejected status and Partner 1 decides to revert it back to Mod 4

• The changes, approvals, and all data saved with the mod 5 will be deleted and mod 4 will be the active Order 

once again

• Partner 1 decides to modify the Order at a later date the Mod number will be 5 again and not mod 6

Order Revert (Cont.)
NONCONFIDENTIAL // EXTERNAL

Page 31 L EAD ∙ T RANSFORM ∙ D ELIVER

• Order Revert (Cont.)
NONCONFIDENTIAL // EXTERNAL

Page 32 L EAD ∙ T RANSFORM ∙ D ELIVER

• Allows Performance to be reported while previously open Order is being modified

– Performance will be allowed when all three conditions are met:

• Order is being modified

• Previous modification number (n -1) is open (REC status) 

• Feature flag for ‘Order Mod’ is Yes for both partners 

– Both partners must be able to handle this action

– Performance may only be submitted against Order schedules that were present on previous modification 

number (n-1)

• May not submit Performance on any newly added schedules until the modification is approved by both trading 

partners

– Performance may only be submitted against Order schedules that have already received Performance 

prior to the modification

• (Post 6.0.1 patch) May allow 1st Performance against a schedule during a modification in the future if the following 

fields have not been modified:

– FOB-point has not been modified

– ALC(s) has not been modified

– Order Line/Schedule data has not been modified 

Performance while Modification
NONCONFIDENTIAL // EXTERNAL

Page 33 L EAD ∙ T RANSFORM ∙ D ELIVER

• Allows Partner 2 to initiate an Order modification

‒ Feature is dependent on using v3 Order endpoints

‒ Feature flag for ‘ORDER_MOD’ must both be “True” 

for both partners

• Both partners must be able to handle this action and 

state to be able to utilize this feature

‒ Modifications may be pushed to MOD (Modification) 

state if both partner’s feature flag are True.

• If using the v2 Order endpoints regardless of feature 

flags being on the Order will continue to utilize the 

SP2 Order flows

• If using the v3 Order endpoint Mod initiator may send 

to SP2 or MOD depending on Order status that is 

passed in the PUT if this feature is enabled by both 

partners

– If one trading partner doesn’t have the feature 

enabled, this error will be returned. 

Bidirectional Order Modification
NONCONFIDENTIAL // EXTERNAL

Page 34 L EAD ∙ T RANSFORM ∙ D ELIVER

• Additional Info:

‒ Partner 2 may process an Order modification from Open or Closed (same as Partner 1)

‒ Business Transaction ID (BTI) & Last Updated Date/Time will be updated

‒ Two new fields:

‒ Modification Originator (MO) & Modification Status (Mod status)

‒ Modification Originator (MO)

• Indicates who initiated the modification and will be retained with Order header until Order is reverted or Order is 

moved back to a MOD state

• ‘R’ = Requesting & ‘S’ = Servicing

• Will be provided on the Order API 

– Modification Status (Mod Status)

• G-Invoicing manages this field is returned in the API response

• Mod Status is used to determine the state within the modification process the Order is currently (see next slide)

Bidirectional Order Modification
NONCONFIDENTIAL // EXTERNAL

Page 35 L EAD ∙ T RANSFORM ∙ D ELIVER

• Mod Status field

‒ Indicates the status of the Order modification

‒ Persisted with Order header while Order is in MOD state

‒ Will be provided through Order API v3 response or pull detail request

Bidirectional Modification: Mod Statuses

Mod Status Name Mod Status 

Code

UI Status Mod Status Mod Status 

Code

UI Status

Requesting Statuses Servicing Statuses

Requesting Update (MO=R) RU Draft Servicing Update (MO=S) SU Draft

Requesting Approval RA Pending Requesting 

Approval

Servicing Approval SA Pending Servicing 

Approval

Shared with Requesting 

(MO=S)

SR Shared with 

Requesting

Shared with Servicing 

(MO=R)

SS Shared with 

Servicing

Rejected by Requesting RR Rejected Rejected by Servicing RS Rejected
NONCONFIDENTIAL // EXTERNAL

Page 36 L EAD ∙ T RANSFORM ∙ D ELIVER

Bidirectional Modification: API when MO=S

API: Servicing Agency modifies a BIO 

Order

• Modification Originator (MO) = S

• Order Status = MOD (Modification)

• Mod Status = SR (Shared with 

Requesting)

• Order Status in UI = Shared with 

Requesting
NONCONFIDENTIAL // EXTERNAL

Page 37 L EAD ∙ T RANSFORM ∙ D ELIVER

Bidirectional Modification: Requesting Agency
NONCONFIDENTIAL // EXTERNAL

Page 38 L EAD ∙ T RANSFORM ∙ D ELIVER

Bidirectional Modification: Servicing Agency
NONCONFIDENTIAL // EXTERNAL

Appendix
NONCONFIDENTIAL // EXTERNAL

Page 40 L EAD ∙ T RANSFORM ∙ D ELIVER

7600EZ - Create Invoice

• Servicing Agency creates an Invoice Additional Information

• Invoice’s Performance Date must be within 

the GT&C’s start and end date. It may be 

dated as far back as the GT&C’s start date 

and in the future through the current 

Accounting Period or the GT&C’s end date 

(which ever is sooner)

• Invoice transactions are Pending until 

Settled (when the Performance Date 

occurs)
NONCONFIDENTIAL // EXTERNAL

Page 41 L EAD ∙ T RANSFORM ∙ D ELIVER

7600EZ - Reversed Transaction

• Servicing Agency reverses an Invoice Additional Information

• Invoice will remain in Settled status 

• Reversed transaction will be Pending until 

Settled

• Servicing Agency may submit a Reversed 

transaction at anytime after the Invoice is 

in Settled status

• Limitations: 

• Requesting Agency Rejected the 

Invoice within the Rejection Days*

• Invoice already has a referencing 

Reversed transaction

*Rejection Days are explained on slide 9
NONCONFIDENTIAL // EXTERNAL

Page 42 L EAD ∙ T RANSFORM ∙ D ELIVER

7600EZ - Deleted Transaction

• Servicing Agency reverses an Invoice Additional Information

• May only Delete an Invoice that is Draft (UI 

only) or Pending Status

• Invoice’s status is updated from Draft or 

Pending to Deleted

• Deleted status transactions are accessible 

through the UI and API

• Invoices with a Deleted status will not 

Settle when the Performance Date occurs
NONCONFIDENTIAL // EXTERNAL

Page 43 L EAD ∙ T RANSFORM ∙ D ELIVER

7600EZ – Accepted Transaction

• Requesting Agency accepts an Invoice Additional Information

• Accepted transactions are optional and 

aren’t required for Invoice funds transfers 

to occur

• Accepted transactions are always 

Informational

• Does not affect settlement

• Accepted transactions may be submitted 

on either Pending or Settled Invoice

• Accepted transactions are not allowed 

when an Invoice already has a referencing 

Accepted or Rejected transaction (that is 

not in Deleted status)

• Requesting Agency may delete an 

Accepted transaction to allow a new 

Accepted or Rejected transaction to be 

submitted
NONCONFIDENTIAL // EXTERNAL

Page 44 L EAD ∙ T RANSFORM ∙ D ELIVER

7600EZ – Rejected Transaction

• Requesting Agency accepts an Invoice Additional Information

• Rejected transactions are optional

• Rejected transactions may be submitted on 

Pending or Settled Invoices

• Rejected transactions are not allowed 

when an Invoice already has a referencing 

Accepted or Rejected transaction (that is 

not in Deleted status).

• Rejected transactions submitted within the 

Rejection Days window will go from 

Pending to Settled status

• Rejected transactions will stop settlement 

from occurring on the Performance Date -

when it’s submitted within the Rejection 

Days window

• The Requesting Agency is not allowed to 

delete a Rejected transaction that’s in 

Settled status 
NONCONFIDENTIAL // EXTERNAL

Page 45 L EAD ∙ T RANSFORM ∙ D ELIVER

7600EZ – Rejected Transaction

• Requesting Agency rejects an Invoice after the Rejection Days 

window

Additional Information

• Rejected transactions are optional

• Rejected transactions may be submitted on 

Pending or Settled Invoices

• Rejected not allowed when an Invoice 

already has a referencing Accepted or 

Rejected transaction (that’s not in 

Deleted status).

• Rejected transactions submitted after the 

Rejection Days window will always be 

Informational

• Requesting Agency may delete an 

Informational Rejected transaction to allow 

a new Accepted/Rejected transaction to be 

submitted
NONCONFIDENTIAL // EXTERNAL

Page 46 L EAD ∙ T RANSFORM ∙ D ELIVER

7600EZ - Deleted Transactions

• Requesting Agency deletes an Accepted or Rejected transaction

Additional Information

• May only Delete an Accepted or Rejected 

transaction that’s in Informational status

• The Accepted or Rejected transaction 

status will change from Informational to 

Deleted

• Deleted status transactions are accessible 

through the UI and API
NONCONFIDENTIAL // EXTERNAL

Page 47 L EAD ∙ T RANSFORM ∙ D ELIVER

7600EZ – New transactions after Deleted

• Requesting Agency may submit a new Accepted or Rejected 

transaction to the Invoice, once the previous referencing 

transaction has been Deleted

Additional Information

• There may only be one “active” referencing 

Requesting Agency transaction on an 

Invoice. To replace an Accepted with a 

Rejected or vice-versa the Requesting 

Agency must Delete the prior transaction 

before submitting the new referencing 

Accepted or Rejected transaction.

• Deleted transactions will be viewable in 

the UI and available in the Pull API
NONCONFIDENTIAL // EXTERNAL

Page 48 L EAD ∙ T RANSFORM ∙ D ELIVER

7600EZ – Reversals after Requesting’s Action

• Servicing Agency may submit a 

Reversed after the Requesting 

Agency submits an Informational 

Accepted or Rejected transaction to 

the Invoice