Payment Request

Process Group/Policy Details

• Subject: Payment Requests

• Process Group: Accounts Payable

• Title of Policy: AP 102 Payment Requests

• Effective Date: 06/2014

• Approved/Revision Date: 06/2014

• Approved by: 

Policy Statements:

Payment Request Policy – AP.PR.01

• Specifies how and why a payment request transaction should be used to integrate Procurement with Accounts Payable (if error occurs in this process then this must go back to the originating area to be corrected and approved).

• Requires matching manager program for all commodity-based award (i.e. PO, etc.) payments (2-way or 3-way match).

• State departments must follow all statute and authoritative guidance (Fiscal Rules & Procurement Rules) related to payments in CORE.

• Expedites payment process (all payment approved today, will be sent to vendor tomorrow).

• General Accounting Expenditure (GAX) transaction can be used for payments that don’t require a commitment document and/or are exempt from Fiscal Rules.

• Discuss special payment needs including third party payments, retainage, recurring payments, payment holds, and payment modifications.

• Prior to submitting any transaction for approval, ensure you have verified and reviewed all data i.e. discount tab, remit addresses, disbursement type (Warrant vs. EFT) (REQUIRED)

• Each Department needs to develop an electronic document process for scanning and attaching documents (any confidential documents such as HIPPA can not be attached in CORE).

• Each Department can use Accounting Templates to populate fund and detail accounting lines if designated by the department.

Disbursements Policy – AP.PR.02

• Automated Disbursement is the process that disburses payments (2-way match, 3-way match and GAX) that have been authorized in accounts payable.

• Transforms payment request transactions into a warrant (AD document) or Electronic Funds transfer (EFT).

• Require use disbursement options to provide communication for warrant printing and processing, which allows for more efficient and effective means of handling warrants by Integrated Document Solutions (IDS).

• Requires to review and approve each payment document.

• Use of EFT payment process is recommended rather than warrants. 

• EFT provides more detailed payment data to vendor than in COFRS via Remittance advice email.

• Ability to provide more detailed payment information on the warrant stub encouraging automatic mailing of warrants rather than holding for inserts.

• Enter in the disbursement format field “WARR” if need to process as a warrant. Otherwise leave field blank, it will default at vendor level.

Payment Request Transaction Review

• Transaction Code:  AD

  • Transaction Name: Automated Disbursement

  • Business Purpose: Transaction liquidates the payable and generates payment. The payment is in the form of a warrant.

• Transaction Code:  Award = RQS, PO, POGG1, CT, CTGG1, MA, DO

  • Transaction Name: Various Types of Procurement Transactions

  • Business Purpose:  Transactions used to procure goods and services and restrict budget with an encumbrance

• Transaction Code:  EFT/ACH

  • Transaction Name: Electronic Funds Transfer

  • Business Purpose: Transaction liquidates the payable and generates payment. The payment is in the form of Electronic Funds Transfer (EFT)/ACH.

• Transaction Code:  GAE

  • Transaction Name:  General Accounting Encumbrance  (RQ in COFRS )

  • Business Purpose:  Optional encumbrance transaction used with a GAX transaction to record budget restrictions when award is not required

• Transaction Code:  GAX

  • Transaction Name: General Accounting Expenditure (PV in COFRS)

  • Business Purpose: Payment transaction not requiring an award i.e. travel expense

• Transaction Code:  IN

  • Transaction Name:  Invoice (VI in COFRS)

  • Business Purpose: Records vendor’s invoice and initiates payment

• Transaction Code:  MD

  • Transaction Name:  Manual Disbursement - MD (JA in COFRS)

  • Business Purpose: Transaction used to record accounting transactions for wire payments directly with State Treasury

• Transaction Code:  PHM

  • Transaction Name:  Payment Hold Maintenance

  • Business Purpose:  Transaction used to hold a submitted and/or approved PR transaction prior to disbursement or hold a payment with a future scheduled payment date.

• Transaction Code:  PRC, PRCI

  • Transaction Name:  Payment Request Commodity Based (PV in COFRS), PRCI (IT in COFRS)

  • Business Purpose:  Payment request transactions requiring an award and matching manager process to internal and external vendors

• Transaction Code:  PRCI

  • Transaction Name:    Commercial Card - P-card, Travel Card,
    Event Card, One Card (PV and/or JV in COFRS)

  • Business Purpose:  Payment request transaction used to upload Citibank commercial card transactions

• Transaction Code:  PRM, PRMI

  • Transaction Name:  PRM - Automated Payment Request Commodity based (PV/AV in COFRS)
    PRMI - (IT in COFRS)

  • Business Purpose:   Automated payment request transaction requiring an award and matching manager process to internal and external vendors

• Transaction Code:  PRN

  • Transaction Name:  Negative Payment Request  (Credit Memo)

  • Business Purpose:  Transaction used to decrease the amount of payment to vendor when next payment is processed

• Transaction Code:  RC

  • Transaction Name:  Receiver (RC in COFRS)

  • Business Purpose:  Transaction used to receive goods by Procurement (not used by accounts payable)

• Transaction Code:  RTGPF

  • Transaction Name:  Retainage Payment/Forfeiture

  • Business Purpose:  Transaction is an output of retainage payout or forfeiture chain.

Event Type Discussion

• Event type is used to record the accounting transaction for the payment. Please be aware that event type impacts the prior and subsequent event accounting in the system.

• Event type AP01 records a debit to an expenditure object code and credit to voucher payable liability code which is the most common payment accounting transaction.

• The system automatically applies the AP01 event type in 2-way and 3-way match payments that result in a PRM transaction.

• PRC transaction allows the use of only two event types – AP01 and XR02

• GAX transaction allows many different event types.

Most Commonly Used Event Types

• Event Code:  AP01

  • Event Name:  Authorize Normal Payment

  • Applicable Payment Transaction:  GAX, PRC, PRM, PRCI, PRMI, PRC1

  • Business Purpose:  Debit to Expense and Credit to Liability (cash is impacted when EFT or warrant has cleared bank).

• Event Code:  XR02

  • Event Name:  Authorize Pre Payment

  • Applicable Payment Transaction:  GAX, PRC, PRC1

  • Business Purpose:  Debit to Prepaid Balance Sheet Account and Credit to Liability (will require JV transaction to record expense).

• Event Code:  AP06

  • Event Name:  Authorize Deposit Refund

  • Applicable Payment Transaction:  GAX

  • Business Purpose:  Debit to Asset and Credit to Liability.  Use to record deposit refund. Must be used with AR21 to clear accounting.

• Event Code:  AP10

  • Event Name:  Authorize Earned Revenue Refund

  • Applicable Payment Transaction:  GAX

  • Business Purpose:  Debit to Earned Revenue and Credit to Liability.  Must be used with prior event of AR02 to clear accounting.

• Event Code:  AP17

  • Event Name:  Liability Payout Authorization

  • Applicable Payment Transaction:  GAX

  • Business Purpose:  Debit to Liability and Credit to Liability.

• Event Code:  AP18

  • Event Name:  Asset Payout Authorization

  • Applicable Payment Transaction:  GAX

  • Business Purpose:  Debit to Asset and Credit to Liability.

Procedures:

AP.PR.01.02 - Manual PR Procedure - GAX 

• General Accounting Expenditure (GAX) document procedure:

• Does not require a commitment transaction (award) and/or is exempt from fiscal rules. For example, payments such as travel reimbursements, utility payments, cell phones, and miscellaneous vendors.

• Is manually entered rather than using the matching manager program.

• GAE encumbrance transaction is optional used with the GAX if needed for restricting budget. GAE detail data can be automatically populated into the GAX transaction using the copy forward CORE functionality.

• Populating the Disbursement Options include the following critical fields:

  • Disbursement Category

  • Disbursement Format

  • Handling Code

• USE the single payment box to ensure payment is not consolidated across Departments and/or Cabinets. 

• Requires entry of Event Types (GAX):

  • • Event Code:  AP01

• • Event Name:  Authorize Normal Payment

  • Business Purpose:  Debit to Expense and Credit to Liability

• Event Code:  XR02

  • Event Name:  Authorize Pre Payment

  • Business Purpose:  Debit to Prepaid Balance Sheet Account and Credit to Liability

• Event Code:  AP03

  • Event Name:  Authorize Retainage Payment

  • Business Purpose:  Debit to Liability and Credit to Liability.  

• Event Code:  AP06

  • Event Name:  Authorize Deposit Refund

  • Business Purpose:  Debit to Asset and Credit to Liability.  (Must use with AR21)

• Event Code:  AP07

  • Event Name:  Authorize Prepayment Refund

  • Business Purpose:  Debit to Liability and Credit to Liability.  (Must use with AR13)

• Event Code:  AP08

  • Event Name:  Authorize Unreserved Credit Balance Refund

  • Business Purpose:  Debit to Liability and Credit to Liability.  (Must use with AR40)

• Event Code:  AP09

  • Event Name:  Authorize Reserved Credit Balance Refund

  • Business Purpose:  Debit to Liability and Credit to Liability.  (Must use with AR41)

• Event Code:  AP10

  • Event Name:  Authorize Earned Revenue Refund

  • Business Purpose:  Debit to Earned Revenue and Credit to Liability.  (Must use with prior event of AR02)

• Event Code:  AP17

  • Event Name:  Liability Payout Authorization

  • Business Purpose:  Debit to Liability and Credit to Liability.

• Event Code:  AP18

  • Event Name:  Asset Payout Authorization

  • Business Purpose:  Debit to Asset and Credit to Liability.

• Requires invoice number and allows entry of 30 characters.

• Check Description is on the accounting line level. This field allows 58 characters and data on this field will be printed on warrant.

• Unit is required “if” using the departmental expense budget.

AP.PR.01.01 - Matching PR Procedure - IN, PRM, PRMI, PRC, PRCI

• Procurement policy requires that commodity and object code are selected at the award level which drives matching process.

• This Matching Procedure specifies how and why a payment request transaction will be used to integrate Procurement with Accounts Payable.

• Requires use of matching manager program for all commodity based award payments unless exempt from fiscal and procurement rules:

  • three-way match (invoice, receiver, award i.e. purchase order) for goods

  • two-way match (invoice, award) for services

Invoice Transaction (IN)

• Invoice transaction (IN) is one of the transactions required to initiate the nightly matching manager process that will create a PRM transaction.

• IN replaces the VI in COFRS but the IN transaction will be the final approved payment transaction prior to disbursement.

• Populates data from the award into the IN transaction creating a connection between procurement and AP.

• Vendor invoice date and invoice number (30 characters) are required to be populated from the actual invoice submitted.

• Disbursement Category and Handling Code should be completed to communicate to IDS (integrated document solutions) and ensure that payments are not consolidated across Departments and/or Cabinets.

• Enter in the disbursement format field “WARR” if needed to process as a warrant. Otherwise, leave field blank, it will default at vendor level.

• Verify information such as remit address, discounts, "Invoiced Quantity” reflects what is on your invoice.

• IN transaction is where the approval for the payment is applied.  This means that the payment will be sent to the vendor the next business day.

PRM, PRC, PRMI/PRCI

• Transaction Name:

  • PRM- Payment Request Matching

  • PRC- Payment Request Commodity

  • PRMI- Payment Request Matching Internal

  • PRCI- Payment Request Commodity Internal

• PRM and PRMI transactions will be automatically generated after the nightly matching process.

• Generate PRC/PRCI if special circumstance requires recording accounting transaction other than expense such as balance sheet account using an event type other than the common AP01 (debit expense, credit payable).

• PRC/PRCI transactions must go through workflow for approval.

• Payments are made to external vendors (PRM/PRC) and internal vendors (PRMI/PRCI).

• Internal vendor payments (PRMI/PRCI) will be used instead of an internal transaction when you must liquidate an award i.e. Colorado Correctional Industries (CCI).

AP.PR.01.03 - Wire PR 

• Payments made by Treasury via Wire Transfer.

• MD transaction replaces COFRS JA for wire payments.

• Send bank details to Treasury to transfer cash.

• The MD transaction is not eligible for disbursement- MD will not create a Warrant or an EFT.

• MD trans will not liquidate the encumbrance; still need a Award modification.

• Event Types: DI51–Pay from Expenditure, DI57–Pay from Asset, D160-Pay from Liability, DI90-Pay from Revenue.

AP.PR.01.06 - Retainage PR Request Procedure

• Retainage functionality allows for automatic calculation & deduction of retainage into Balance Sheet account- then tracks retainage withheld, and subsequent release or forfeiture.

• To verify retainage use the following tables:

  • Retainage Summary by Award table (RTGA) shows the Awards that have Retainage

  • Retainage Summary by Commodity Line (RTGSUM) shows the balance of retainage on each Commodity associated with an Award

• Retainage starts in Procurement; Retainage is withheld depending on how it is built into the Award.

• Most Common Event Types:

  • AP03 – Authorize Retainage Payment

AP.PR.01.04 - Third Party PR Procedure

• Third Party Payment – A payment to a party other than the original payee, e.g. Settlement Payments.

• A primary and third party vendor must be established by the Central Unit using legal documentation, as required by the VCUST.PO.O1 Policy.

• Before processing the payment, locate and verify that the primary and third party vendors are linked on VCUST table to ensure payment to third party.

• Requires in the vendor section of a GAX transaction to check the Pay Third Party box.

• Ensure the payment is made to third party vendor by using the DISRQ table.

AP.PR.01.05 - Recurring PR Procedure

• Future Transaction Triggering (FDT) provides functionality for automatic creation of recurring payment transactions.

• This process allows for an automatically generated payment transaction to be created for a predefined frequency, such as monthly or quarterly.

• You can access the Future Transaction Triggering (FDT) function from inside the original final payment transaction.

Credit Memo and other Payment Request Correction Methods

• State Policy that use of journal voucher transactions will be more limited for corrections.

• Do NOT complete a $0 warrant as it will be sent to the vendor.

• Use of other correction methods included in the following procedures are preferred:

  • Payment Hold Maintenance Procedures AP.PR.01.08

  • Payment Request Modifications and Discards Procedure AP.PR.01.09

  • Matching PRN Credit Memo AP.PR.01.10

• Use of each method depends upon timing of the payment disbursement.

AP.PR.01.07 - Automatic Transaction Submission (ATS)

• ATS is an automated spreadsheet that will be used to upload IN or GAX payment details creating a transaction in CORE.

• Used for payments with the same payment details with only a few field changes i.e. Utility payments.

• Replaces the COFRS utility copy process functionality.

• Will follow the same workflow approval process as normal IN and GAX transactions.