U.S. Federal G-Invoicing Processing
The U.S. Federal Government Department of the Treasury implemented the G-Invoicing system to manage intra-governmental (IGT) buy sell transactions. IGT transactions result from business activities conducted between two federal entities known as trading partners. G-Invoicing provides a common platform for all IGT Buy/Sell activity.
G-Invoicing supports all four stages of the IGT Buy/Sell transaction lifecycle:
General Terms and Conditions (GT&C): Identify the general terms that govern Buy/Sell trades between the Requesting Agency and the Selling Agency, including roles and responsibilities for both agencies to ensure effective management of the inter-agency agreement.
Orders: Specifies the quantity of goods or services ordered.
Performance: Goods/services are delivered/performed by the Selling Agency and received by the Requesting Agency.
7600EZ: This business process allows direct vouchering by the supplier and eliminates the entry of an order in the G-Invoicing system. Note that a voucher is to be created in the PeopleSoft business process based on the G-Invoicing order type (Accepted, Invoice, Rejected, and Reversed).
Funds Settlement: Funds are transferred directly between G-Invoicing and the Federal government Intragovernmental Payment and Collection system (IPAC).
PeopleSoft provides Buying Agency integration with the U.S. Federal Government G-Invoicing system.
G-Invoicing Process
PeopleSoft Payables supports the Requesting Agency’s Procure-to-Pay business process for G-Invoicing with the following functionality:
GT&C: For more information, see Understanding U.S. Federal G-Invoicing Processing
Orders: For more information, see Understanding U.S. Federal G-Invoicing Processing
Performance
Pull Performance API pulls transactions including Advances and Delivered/Performed transactions.
The Update Advances workbench is used to view and also update G-Invoicing advance transactions with General Ledger Account and Entry Event values so prepaid vouchers can automatically be created.
Voucher Build automatically creates Prepaid Vouchers using the Advance performance transactions and Journal Vouchers for negative Advance performance transactions.
Delivered/Performed transactions are built into receipts in Purchasing and can leverage Evaluated Receipt Settlement to create PO vouchers. The Evaluated Receipt Settlements process has been updated to create G-Invoicing vouchers and payments and reference associated prepaid vouchers so it can automatically be applied.
The G-Invoicing Budget Checking process is used to run budget checking, document tolerance, and matching as well as create manual payments for G-Invoicing vouchers.
Refer to Understanding U.S. Federal G-Invoicing Processing for more information on how Received/Accepted performance transactions are processed.
7600EZ
It primarily supports the high volume of transactions for the General Services Administration (GSA) and the Government Publishing Office (GPO).
Regular and reversal vouchers can be created by referring to the EZ number.
EZ invoices can be rejected by entering a Reversal Voucher and send notification to the G-Invoicing system using push 7600EZ API.
7600EZ APIs use pull/push REST Services to transfer transactions.
Funds Settlement: G-Invoicing initiates the transfer of funds using IPAC. A process is available to record G-Invoicing vouchers as manual payments since the funds have been settled with IPAC.
PeopleSoft provides integration that supports the G-Invoicing Requesting Agency intragovernmental Procure-to-Pay business process. The G-Invoicing Procure-to-Pay process includes several APIs and processes in PeopleSoft as well as some manual steps.
G-Invoicing Procure-to-Pay Process
|
Stage |
G-Invoicing Steps |
PeopleSoft Steps |
|---|---|---|
|
1. GT&Cs |
GT&Cs are entered directly into G-Invoicing. |
Refer to Understanding U.S. Federal G-Invoicing Processing for more information. |
|
2. Orders |
Orders are entered manually into G-Invoicing. |
Refer to Understanding U.S. Federal G-Invoicing Processing for more information. |
|
3. Performance Transactions |
Performance transactions are pulled into PeopleSoft or pushed into G-Invoicing using the Performance API. |
|
|
4. 7600EZ |
Select 7600EZ as Business Application on the Header Details. |
All new G-Invoicing APIs will employ a push/pull model utilizing REST services. Vouchers are entered into PeopleSoft with a reference EZ number. EZ Invoices can be rejected by entering a Reversal Voucher. |
|
Advance payments (‘548’) |
Entered into G-Invoicing by the seller. |
Advances are loaded to the Advances workbench for updating using the Pull Performance API. Advances can be built into prepaid vouchers using Voucher Build. |
|
Adjustments to advances (negative ‘548’) |
Entered into G-Invoicing by the seller. |
Advance adjustments can be built into journal vouchers using Voucher Build. |
|
Delivered/performed transactions (‘035’) |
Entered into G-Invoicing by the seller. |
Delivered/Performance transactions are loaded as Advanced Shipping Notices (ASNs) in Purchasing using the Pull Performance API. ASNs can be built into Receipts by Load Receipts and leverage ERS for Payables to create vouchers. |
|
Received/accepted transactions (‘050’) |
Received from PeopleSoft using API. |
Refer to Understanding U.S. Federal G-Invoicing Processing for more information. |
|
Adjustments to received/accepted transactions (negative ‘050’) |
Received from PeopleSoft using API. |
Refer to Understanding U.S. Federal G-Invoicing Processing for more information. |
|
Adjustments to delivered/performed transactions (negative ‘035’) |
Entered into G-Invoicing by the seller. |
Adjustments are received through the Pull Performance API. These transactions must be reviewed and handled manually in PeopleSoft. |
|
Deferred payment transactions (‘014’) |
Entered into G-Invoicing by the seller to communicate the amount/percentage of work completed for work in progress transactions. |
Deferred payment transactions are received through Pull Performance API. They are stored for informational purpose only. |
|
7600EZ Seller Invoice transactions (011) |
Entered into G-Invoicing by the seller to communicate invoice amount. |
Invoices are received through 7600EZ Pull API and referenced on Vouchers. |
|
7600EZ Seller Invoice Reversed (324) |
Entered into G-Invoicing by the seller to communicate invoice has been completely reversed. |
Reversed invoice transactions are received through 7600EZ Pull API and referenced on Reversal Vouchers to liquidate the original voucher. |
|
7600EZ Buyer Invoice Rejection (598) |
Invoice rejections are initiated by the Buyer in PeopleSoft and pushed to G-Invoicing using the 7600 Push API. |
These transactions are initiated by the Buyer by creating Reversal Voucher and reference the original voucher. This will be available for 7600EZ Push process to notify the Seller. |
|
4. Funds Settlement |
G-Invoicing initiates funds transfers using IPAC. |
The PeopleSoft G-Invoicing Budget Checking process runs budget checking, matching, and document tolerance as well as creates manual payments for G-Invoicing PeopleSoft vouchers. |
Refer to Understanding U.S. Federal G-Invoicing Processing for information on enabling G-Invoicing integration and configuring G-Invoicing definition.
G-Invoicing vouchers can be created using the Evaluated Receipt Settlement process (ERS), which is run using Voucher Build.
If there are errors in the creation of the voucher, the Entry Status will be Recycle. The errors must be manually corrected and the voucher saved to proceed.
ERS uses Freight Terms entered on a receipt, or those appearing by default from a PO, to determine the ERS invoice date. If the freight terms on the receipt are FOB ORIGIN, the system uses the ship date as the invoice date. Otherwise, the system uses the receipt date.
Following table lists G-Invoicing performance type transaction along with the FOB Point which is used by G-Invoicing to determine when payment by IPAC is triggered. PeopleSoft is represented by the Buyer Action column.
|
G-Invoicing Performance Transaction/Performance Type |
Push/ Pull |
Buyer/Seller Initiated |
FOB Point |
Seller Action |
PeopleSoft (Buyer) Action |
|---|---|---|---|---|---|
|
Advance (548) |
Pull |
Seller |
Source or Destination |
Seller requests an Advance from the Buyer. This triggers IPAC settlement. |
Pull performance API receives the ‘548’ transaction. Advance is recorded using a Prepaid Voucher which is automatically created by a new process. |
|
Delivered/Performed (035) |
Pull |
Seller |
Source |
Seller reports delivery of goods or services using a performance transaction. IPAC settlement is triggered. If the Reference Performance field contains a value, this is considered an adjustment. |
Pull performance API receives the ‘035’ transaction. PeopleSoft ASN process used to create a receipt (will NOT process ‘035’ Adjustments) with FOB Terms set to Source, Ship Date, and Receipt Status set to Open. The PeopleSoft ERS process automatically creates an invoice in PeopleSoft. |
|
Delivered/Performed (035) |
Pull |
Seller |
Destination |
Seller reports delivery of goods or services using a performance transaction. |
Pull performance API receives the ‘035’ transaction. PeopleSoft ASN process used to create a receipt (will NOT process ‘035’ Adjustments) with FOB Terms set to Destination, Ship Date, Receipt Status set to Open. The PeopleSoft ERS process automatically creates an invoice in PeopleSoft. |
|
Received/Accepted (050) |
Push |
Buyer |
Source |
Seller receives and reviews G-Invoicing receipt. IPAC settlement already occurred with ‘035’ Performance transaction. |
Buyer updates the receipt in PeopleSoft, and a process triggers the Push Performance API to send a performance transaction to G-Invoicing. |
|
Received/Accepted (050) |
Buyer |
Destination |
Seller reviews G-Invoicing receipt. An IPAC settlement transaction is triggered in G-Invoicing. |
Buyer updates the receipt in PeopleSoft, and a process triggers the Push Performance API to send a performance transaction to G-Invoicing. The PeopleSoft ERS process automatically creates an invoice in PeopleSoft. |
The Agency Location Code associated with the bank on the Voucher Payments tab must equal the Requesting ALC on the referenced GT&C. Please refer Defining Bank Information for more information on bank set up.
For additional information, refer Running the Voucher Build Process and Reviewing Messages .
Recording G-Invoicing Payments without using ERS
G-Invoicing vouchers can be created without using the delivered Evaluated Receipt Settlement process (ERS). The following items need to be considered when using this approach:
Ensure ERS is disabled for the Supplier.
A PeopleSoft G-Invoicing PO must be referenced.
Payment should be recorded manually by either using G-Invoicing Budget Checking or creating a manual payment from the Voucher Payment page.
Ensure that the Invoice Date matches the G-Invoicing Performance Date.
Ensure that the Payment Date matches the G-Invoicing Payment Date based on the FOB Point of Source or Destination.
If the invoice needs to reference a prepayment, enter the PO Number in the Prepaid Reference field on Voucher Attributes.
G-Invoicing Bank Account
A separate G-Invoicing Bank Account must be created with Cash Clearing turned off to avoid issues in creating G-Invoicing adjustments.
Use Voucher Build to create prepaid vouchers for staged G-Invoicing advance performance transactions.
G-Invoicing advances can have multiple schedules but only one distribution line per schedule. Each schedule is equivalent to one prepaid voucher in PeopleSoft since PeopleSoft only supports one-line prepaid vouchers.
Navigation:
If there are errors in the creation of the voucher, the Entry Status will be Recycle. The errors must be manually corrected and the voucher saved to proceed.
The Prepaid Ref field is set to PO ID by Voucher Build to assist in the application of advances.
Please refer Running the Voucher Build Process and Reviewing Messages for more details.
Creating G-Invoicing Prepaid Vouchers Manually
It is possible to create G-Invoicing prepaid vouchers manually. The following items need to be considered when using this approach:
The Advances Workbench is populated with G-Invoicing Advances by Pull Performance API but should not be used to update Account and Entry Event.
The PO ID must be entered in the Prepaid Ref field on Voucher Attributes.
A PeopleSoft G-Invoicing PO must be entered in the Advance Payment Option PO Number field.
Payment should be recorded manually by either using G-Invoicing Budget Checking or creating a manual payment from the Voucher Payment page.
Ensure that the Invoice Date matches the G-Invoicing Performance Date.
Ensure that the Payment Date matches the G-Invoicing Payment Date.
Note: A decision must be made to enter prepaid vouchers OR create them using Voucher Build. Entering them using both methods will cause errors and reconciliation issues.
Applying G-Invoicing Advances to Vouchers
Since G-Invoicing applies an advance payment to a specific order line this means that there is a many to many relationship between advance and invoice in G-Invoicing.
PeopleSoft allows you to apply multiple vouchers to multiple prepayments using the Prepaid Reference field on the Voucher Attributes page. As long as the Prepaid Vouchers and the PO Vouchers have the same Prepaid Reference value, the prepaids are appropriately applied to the Vouchers with the same Order Number by Voucher Post. ERS is updated to populate the prepaid reference field with PO ID on the prepaid voucher as well as the PO Voucher.
Generate AP Journal Vouchers for Negative Advance Transactions check box on the Federal Processing Installation Options page indicates whether Journal Vouchers are created for negative Advance Adjustment performance transactions received from G-Invoicing. Since we do not know the reason for the adjustment and whether the returned amount will be closed, this check box allows the user to handle the adjustment manually.
An adjustment to an advance can be submitted to G-Invoicing as a negative Advance Performance Transaction by the Seller to modify the advance payment previously collected from the Buyer. Adjustment quantities are negative for the entire performance transaction and must reference an existing advance performance transaction. Completion of this performance transaction automatically initiates fund settlement through the IPAC application using G-Invoicing.
Use Voucher Build to create journal vouchers for staged G-Invoicing advance adjustment performance transactions. This is the same process that creates prepaid vouchers for Advances.
If there are errors in the creation of the voucher, the Entry Status will be Recycle. The errors must be manually corrected and the voucher saved to proceed.
G-Invoicing reversal vouchers are entered to account for the following scenarios:
The seller sends a 324 Reversed transaction to reverse their original invoice (011).
The buyer wants to reject the seller's invoice (011) which can occur within or outside the number of rejection days designated for the G-Invoicing Business Application Type. This will create a 598 Rejected transaction and send to G-Invoicing using 7600EZ push API.
Following are the steps for each of these business processes.
Seller 324 Reversed Transaction
The seller creates Invoice (011) in G-invoicing.
The buyer runs 7600EZ pull for Invoice (011) transaction and subsequently enters a Regular Voucher and reference the Invoice EZ number.
The seller determines they want to reverse the transaction and process a G-Invoicing Reversed (324) transaction that will be settled in IPAC.
The buyer creates Reversal Voucher to account for the Reversed (324) transaction and populates the Reversed EZ Number. The reversal voucher will be fully processed.
This example illustrates the fields and controls on the Reversal Vouchers G-Invoicing page.
Buyer Invoice Rejection 598 within Business Application Type Rejection Days
The seller creates Invoice (011) in G-invoicing.
The buyer runs 7600EZ pull for Invoice (011) transaction and subsequently enters a Regular Voucher and reference the Invoice EZ number.
The buyer creates Reversal Voucher to reject the invoice with a date that is inside the number of rejection days. The reversal voucher can be fully processed to reflect so the payment is reversed. This will initiate the 598 Rejection transaction that is pushed using 7600EZ API to G-Invoicing. This will be reflected in the G-Invoicing system with a Settled (STL) status and funds returned by IPAC.
Note that G-Invoicing generates the EZ numbering for transactions that are pushed to the system. When the 7600EZ pull process is run again, the generated EZ number will be retrieved and populated for the 598 transaction.
Buyer Invoice Rejection 598 outside Business Application Type Rejection Days
The seller creates Invoice (011) in G-invoicing.
The buyer runs 7600EZ pull for Invoice (011) transaction and subsequently enters a Regular Voucher and reference the Invoice EZ number.
The buyer creates Reversal Voucher to reject the invoice with a date that is outside the number of rejection days. Since this is outside the number of days, the Reversal Voucher is put on hold and will initiate the 598 Rejection that is pushed using 7600EZ API to G-Invoicing. This will be reflected in the G-Invoicing system with an Informational (INF) status. INF transactions are not settled by IPAC.
Note that G-Invoicing generates the EZ numbering for transactions that are pushed to the system. When the 7600EZ pull process is run again, the generated EZ number will be retrieved and populated for the 598 transaction.
The seller will need to determine whether they take action in G-Invoicing and enter a Reversed (324) transaction. If they send the 324 transaction, the Reversal Voucher needs to be updated with the Reversed EZ Number and document taken off hold and fully processed.
If the seller does not agree to reverse the original voucher, the buyer can delete the Reversal Voucher.