Automated Disbursement Processing

The Automated Disbursement Chain (AD Chain) in Advantage Financial is a group of jobs that work together to create disbursement transactions from the payment request transactions. The Automated Disbursements process selects authorized payments, edits payments for validity, processes payment adjustments, groups the payments, formats payments, and posts payment transactions. In short, it is the process that takes payment data (posted in the form of a Commodity Payment Request, Matching Payment Request, or General Accounting Expenditure transaction), and transforms this into a disbursement instrument. This process also generates the transactions to record the Intercept Transfers.  

The Automated Disbursement process uses the Disbursement Parameters (DISPA) table to drive the selection of disbursement requests from the Disbursement Request (DISRQ) table. Each record on DISPA is a complete set of selection parameters. Individual records may be set as either Active or Inactive.  When the Automated Disbursements process is initiated, each active record in the Disbursement Parameters (DISPA) table is evaluated as disbursement request selection criteria.

The batch process will determine if the records that remain on the DISRQ table, after the vendor editing steps complete, are eligible for any adjustments in the amount that will be disbursed.  This includes calculations for discounts, tax, penalties, interest, 1099 backup withholding, contract withholding, 1042S withholding, and credit memos.

Below is a brief description. For detailed information on the Automated Disbursement Chain process (such as when to run, input, output, calculation logic, and process parameters) refer to the associated run sheet in the CGI Advantage Accounts Payable Run Sheets guide.

Amount CalculationAmount Calculation

The batch process will determine if the records that remain on the DISRQ table, after the vendor editing steps complete, are eligible for any adjustments in the amount that will be disbursed. This includes calculations for discounts, tax, penalties, interest, backup withholding, contract withholding, 1042S withholding, and credit memos.

DiscountsDiscounts

For the DISRQ records that contain a discount term with the Discount Always checkbox set to true, the batch process will use this discount term for calculating the discount.

For the DISRQ records that do not contain a discount term with the Discount Always checkbox set to True, the batch process will determine if any of the discount terms are still eligible for discount.

TaxTax

If discounts are taken for a record on the DISRQ and the tax type specified for the DISRQ record is a percentage tax (i.e., not a flat tax as a flat tax will result in the same amount), the batch process will determine if the tax amount needs to be recalculated for the new payment amount (i.e., Line Amount – Discount Amount). If the SOPT record for the current fiscal year has the Recalculate Tax check box set to true, then the DISRQ records that have a discount amount will have the Tax Amount recalculated (if one exists).

PenaltiesPenalties

DISRQ records that did not have discounts taken are considered for penalty payments.

If the SOPT record for the current fiscal year has the Calculate Penalties on Disbursement check box is set to true, then the DISRQ records are eligible to calculate a penalty amount.

InterestInterest

The interest calculation within the AD chain will only be performed if the SOPT option Calculate Interest Outside of Disbursement is unchecked and Calculate Interest on Disbursement is checked. Interest maybe calculated outside disbursement by Automated Interest Calculation process.

Backup WithholdingBackup Withholding

DISRQ records are subject to backup withholding if a record meets the following criteria:

  1. The Backup Withholding check box is set to true on the 1099P table AND

  2. One of the conditions marked as A or B below is true:

  3. The 1099 Backup Withholding Status CVL on the 1099I table is set to Eligible and the 1099 Reportable flag is checked for the record’s Vendor, TIN and TIN Type combination (as defined on VCUST table), AND

For at least one of the following 4 COA elements (using this precedence order: Sub BSA, BSA, Sub Object, Object) the 1099 Income Code and Income Type fields are populated (as defined on SBSA, BSA, SOBJ, or SOBJ tables respectively), AND

Backup Withholding flag is checked for the corresponding Form Type and the 1099 Type of Income on TINC;

OR

  • The 1099 Backup Withholding Status CVL on the 1099I table is set to a value other than Eligible and the 1099-INT Backup Withholding and the 1099 Reportable flags are checked for the record’s Vendor, TIN and TIN Type combination (as defined on VCUST table), AND

For at least one of the following 4 COA elements (using this precedence order: Sub BSA, BSA, Sub Object, Object) the 1099 Income Code and Income Type fields are populated (as defined on SBSA, BSA, SOBJ, or SOBJ tables respectively), AND

For the reportable COA element (per previous condition) and the 1099 Type of Income it is associated with, the Form Type field on the respective COA table = I, AND

The Backup Withholding flag is checked for the corresponding Form Type and the 1099 Type of Income on TINC.

  1. No matching record exists on 1099E table using any of the following 3 lookups based the Fiscal Year specified on the record’s Accounting Line:

  • Actual Fund and Department from the Accounting Line;

  • Actual Fund, but Department is ALL;

  • Fund is ALL and actual Department.

1042S Backup Withholding1042S Backup Withholding

DISRQ records are subject to 1042S withholding if a record meets ALL of the following criteria:

  • The 1042S Withholding check box is set to true on the 1099P table for the Calendar Year defined by the disbursement record’s Check Date.

  • The 1042-S Ch.3 Recipient Code flag is checked for the Vendor Code on the VCUST table or the 1042-S Ch. 4 Status Code flag is checked for the Vendor Code on the VCUST table.

  • The 1042-S Backup Withholding Status on 1042I is either blank or Pending.

  • The 1042-S Recipient Account Number associated with the Vendor Code on the VCUST table has the 1042S Withholding check box set to true on the 1099 Reporting Information table.

  • The Object, Balance Sheet Account, Sub-Object or Sub Balance Sheet Account contains a 1042 Income Code and Income Type (that is, it is 1042 Reportable).

  • The combination of 1042-S Income Code, 1042-S Income Type associated with the applicable COA (Object, Sub Object, BSA or Sub BSA) and the 1042-S Ch.3 Recipient Code or 1042-S Ch. 4 Status Code associated with the Vendor Code is defined on the 1042-S Type of Income table with the Backup Withholding flag checked.

If the vendor is found to be eligible for 1042-S Withholding, the system will then retrieve the current applicable tax rate for this vendor as follows and calculate the actual 1042-S Withholding Amount of the Accounting Line:

If the vendor is determined to be a Ch. 3 vendor (that is, 1042-S Ch. 3 Recipient Code is selected on VCUST), then the system retrieves the 1042-S Tax Rate from the ICTX table for the combination of 1042-S Income Code (defined by eligible COA element), IRS Country of Residence and IRS Country Sub Code (defined on VCUST by the transaction’s Vendor);

  • If the 1042-S Backup Withholding Status on 1042I is set to blank and a matching record is found on ICTX table, then the value in the 1042-S Ch.3 Tax Rate field is inferred from the matching record to the 1042-S Tax Rate field on the Accounting Line of the AD Transaction and use the Tax Rate during calculation;

  • If no matching record is found on ICTX, then the value in the 1042-S Backup Withholding Rate field on 1099P table (for the Calendar Year of the Record Date specified on the Header) is inferred to the 1042-S Tax Rate field on the Accounting Line of the AD Transaction and the Tax Rate is used during calculation.

  • If the 1042-S Withholding Status on 1042I is set to Pending, a look up is not performed on ICTX. The value in the 1042-S Backup Withholding Rate on 1099P is inferred. This rate is used to calculate 1042-S backup withholding on the transaction.

  • If the 1042-S Backup Withholding Status on 1042I is set to Not Eligible, then the 1042-S Backup Withholding Rate on 1099P is inferred, but the system does not calculate or withhold the backup withholding tax. The tax rate is used for reporting to the IRS.

If the vendor is determined to be a Ch. 4 vendor (that is, 1042-S Ch. 4 Status Code is selected on VCUST), then the system retrieves the 1042-S Tax Rate from the ICTX4 table for the combination of 1042-S Income Code (defined by eligible COA element), IRS Country of Residence and IRS Country Sub Code (defined on VCUST by the transaction’s Vendor);

  • If the 1042-S Backup Withholding Status on 1042I is set to blank and a matching record is found on the ICTX4 table (based on 1042-S Income Code and IRS Country of Residence) then the tax rate from the matching record is inferred to the 1042-S Tax Rate field on the Accounting Line of the AD Transaction. This is the rate used if backup withholding calculation is required based on the 1042T BWH flag.

  • If no matching record is found on ICTX4, then the value in the 1042-S Ch. 4 Tax Rate field on 1099P table (for the Calendar Year of the Record Date specified on the Header) is inferred to the 1042-S Tax Rate field on the Accounting Line of the AD transaction and use the Tax Rate during calculation.

  • If the 1042-S Withholding Status on 1042I is set to Pending then the system does not perform a look up to ICTX4. The value in the 1042-S Chapter 4 Tax Rate on 1099P is inferred. This rate is used to calculate 1042-S backup withholding on the transaction.

  • If the 1042-S Backup Withholding Status on 1042I is set to Not Eligible, then the 1042-S Ch. 4 Tax Rate on 1099P is inferred, but the system does not calculate or withhold the backup withholding tax. The tax rate is used for reporting to the IRS.

Contract WithholdingContract Withholding

  1. A payment request line is exempt from Contract Withholding if the Contract Withholding Exempt check box is selected on DISRQ, Vendor, Object, Sub Object, Commodity, Program, Appropriation, Balance Sheet, or Sub Balance Sheet tables.  

  2. A payment request line is not eligible for Contract Withholding if any of the following conditions is satisfied:

    1. The payment request line is exempt from Contract Withholding  (see above)

    2. The calculated Backup Withholding Amount or 1042S Withholding Amount is not zero.

    3. The Contract Withholding flag on 1099P is not selected for the year portion of the Application Date.

    4. The payment request line has Procurement Card Payment set to Yes on DISRQ and Apply Contract Withholding to PCard Payments is not selected on 1099P.

RetainageRetainage

If the referenced Award contains applicable retainage terms, a portion of each vendor payment is withheld for retainage. The amount withheld is determined by retainage terms that are stored on the Award. Retainage amount is calculated on the PR transaction and not during the AD process. The AD process only uses the Retainage amount stored on the DISRQ record to make the adjustment.

Credit Memo AdjustmentsCredit Memo Adjustments

In Advantage, payment request accounting Lines with negative amounts are considered Credit Memo Lines. Credit memos are applied against the related positive payment request lines. There are two options you may use to control how credit memos are consolidated:

  • The PCard Consolidation Option on the SOPT table controls Credit Memo consolidation and payment creation for non-single-check PCard payments.

  • The Consolidate Credit Memo by Disbursement Grouping, Consolidate Credit Memo by AL Department, Consolidate Credit Memo by Payment Request Transaction Department, Include Address in Credit Memo Consolidation, and Match on Disbursement Priority fields on Disbursement Parameters control Credit Memo consolidation for non-PCard and non-single-check payments.

The system determines if selected DISRQ records are eligible for any credit memo adjustments in the amount that will be disbursed. The system consolidates credit memos (negative lines) based on certain criteria, groups positive lines based on payment grouping, and then compares each credit memos total to the related positive lines totals to determine if the credit memos can be liquidated fully by the positive line groupings. If so, the credit memos and related positive lines will be disbursed. If not, the credit memos and related positive lines will be placed on system hold.

When Credit Memos cannot be fully liquidated during Disbursements, the process puts the Credit Memo transactions on System Hold on DISRQ with one of the two possible Hold Reasons applied to the records:

  • Credit Memo Not Fully Liquidated (9) – Which indicates that the amount of the Credit Memo exceeded the positive lines.

  • Credit Memo Application Not Possible (16) – Which indicates that the Credit Memo maximum line amount is exceeded.

For more information on credit memo logic, refer to the Automated Disbursement Chain run sheet in the CGI Advantage Accounts Payable Run Sheets guide.

Disbursement Limit CheckDisbursement Limit Check

The disbursement limit check step determines if the eligible DISRQ records meet the Disbursement Limit amount criteria defined on all active DISPA records.

Payment InterceptsPayment Intercepts

The Payment Intercept step determines if any outstanding receivables that have been identified for intercept are eligible for intercept against the records selected by the disbursement process and are currently on the DISRQ and not on system, user, or disbursement management hold. The Payment Intercept check box on SOPT must be set to true and the Intercept Selection batch parameter must have at least one value defined in order for any disbursement to take a payment intercept. The payment intercept process goes through the following steps:

  • Select the eligible records from the Intercept Request Table (INTR)

  • The batch process will determine which INTR records are eligible for intercept. The INTR records eligible for intercept are selected as follows:

  • The Claim Status of the INTR record is set to active.

  • The INTR record must have an outstanding intercept amount.

  • Internal Debt Outstanding Intercept Amount = (INTR) Outstanding Amount – (INTR) Disbursement Intercept Amount

  • External Debt Outstanding Intercept Amount = (INTR) Outstanding Amount – (INTR) Disbursement Intercept Amount – (INTR) Transferred Amount

  • At least one of the Intercept Selection values from the AD Chain batch parameter (Intercept Selection field) must match an Intercept Selection value of the Entity associated with the debt record.  The Intercept Selection value(s) for the Entity is recorded on the Entity (ENTY) table. If the Intercept Selection batch parameter is ‘null’ then no records will meet this condition resulting in all records on INTR being ineligible for intercept.

  • The INTR record does not meet the criteria of any active record on the Receivable Intercept Exception (INTREX) table.

  • If the Evaluate Intercept by Debt Type parameter on the Application Parameters (APPCTRL) table is Yes, then the job will verify if the INTR and DRL combination exists as an allowable payment/intercept combination on the Allowable Payments for Intercept by Debt Type (APIDT) table. If FY/Debt Type combination does exist on the APIDT and the INTR/DRL combination does not satisfy any APIDT record combination, the DRL record will be bypassed from intercept processing and will be processed for disbursement. Refer to the AD Chain run sheet in the CGI Advantage Financial – Accounts Payable Run Sheets Guide for more information. Also, refer to the “Allowable Payments for Intercept by Debt Type (APIDT)” topic of the CGI Advantage - Intercept User Guide for use of the parameter and the APIDT page.

Payment Grouping and ConsolidationPayment Grouping and Consolidation

After the Vendor editing and Amount calculation, the job groups selected DISRQ records into the following five categories:

  • Payments to Miscellaneous Vendors – One check will be generated for each Vendor Line and the miscellaneous vendors payments will not grouped with any other payments.

  • Payments to Non-Miscellaneous Vendors with Single Check – One Check / EFT will be generated for each Vendor line. The payments will be made in full for that Vendor line and no partial payments will be made.

  • Payments to Non-Miscellaneous Vendors with Non-Single Check – Payments for the same Vendor will be consolidated across the payment requests. It is possible that one Check / EFT will be generated for more than one payment request transaction.

  • Payments to Procurement Cards- The procurement card payments will be grouped and consolidated based on the SOPT option Pcard Consolidation Options.

  • Payments to Third-Party / Payees – Payments to Third parties / Payees will be grouped and consolidated based on the Payee code.

Within each of these groups, the AD Chain batch process groups selected payment request accounting lines with positive amounts by the following consolidation fields:

  • Disbursement Format

  • Procurement Card Flag (set to “true” for only Procurement Card payment requests)

  • Bank Account

  • Cleared Date (applicable only for EFT payments)

  • Disbursement Priority

  • Consolidation Object 1 (i)

  • Consolidation Object 2 (i)

  • Handling Code

  • Consolidation Object 3 (i)

  • Consolidation Object 4 (i)

  • Disbursement Category

  • Payee Code

  • Payee Legal Name

  • Payee Address ID

  • Payee Address Line 1

  • Payee Address Line 2

  • Payee City

  • Payee State

  • Payee Zip Code

  • Payee Country

  • Payee Email Address ID (ii)

  • Payee Phone Number  (ii)

  • Payee Phone Extension (ii)

  • Payee Fax Number (ii)

  • Payee Fax Extension (ii)

  • Payee Contact Name (ii)

  • Payee County (ii)

  • Payee Contact ID (ii)

  • Vendor Code

  • Vendor Legal Name

  • Vendor Address ID

  • Vendor Address Line 1

  • Vendor Address Line 2

  • Vendor City

  • Vendor State

  • Vendor Zip Code

  • Vendor Country

  • Vendor Email Address ID (ii)

  • Vendor Phone Number  (ii)

  • Vendor Phone Extension (ii)

  • Vendor Fax Number (ii)

  • Vendor Fax Extension (ii)

  • Vendor Contact Name (ii)

  • Vendor County (ii)

  • Vendor Contact ID (ii)

  • Consolidation Object 5 (i)

  • Consolidation Object 6 (i)

  • APEVXW Check/EFT Number Flag (true or false) (iii)

  • APEVXW Checks/EFT Status (disbursed or warranted) (iii)

The following fields are considered along with the above fields when consolidating payment requests for miscellaneous vendors or non-miscellaneous vendors with single check:

  • PR Transaction Code

  • PR Transaction Department Code

  • PR Transaction ID

For each payment grouping, the job determines if the sum of Line Amount less Discount and Retainage over the records within the payment group is greater than or equal to the 1099P Contract Withholding Threshold. If not, Contract Withholding is reset to $0 for the records within the payment group.

  1. There are few options in baseline to populate Consolidation Object fields.  Please refer to the “Disbursement Request Table” section and the “Consolidation Objects Configuration” section for more information.

  2. The Advantage Disbursement Request (DISRQ) table does not store the payee fields: Payee Email Address ID, Payee Phone Number, Payee Phone Extension, Payee Fax Number, Payee Fax Extension, Payee Contact Name, Payee Country and Payee Contact ID.

  3. The APEVXW Check/EFT Number Flag and APEVXW Check/EFT Status are populated from the Advantage AP Event Type Crosswalk (APEVXW) table. The inference is based on the Disbursement Transaction Type (i.e. “AD”), Disbursement Option specified on the SOPT table (for example, Check/EFT), Disbursement Type of referenced PR Accounting Line (for example, Check, EFT), and Event Type of referenced PR Accounting Line.

Generation of Automated Disbursement TransactionsGeneration of Automated Disbursement Transactions

The Advantage Transaction Component Requirements (DCREQ) table can be used to limit the number of lines on any component per a transaction type. Limiting the number of accounting lines for generated AD transactions will prevent the creation of large AD transactions that can crash or cause performance degradation upon processing during the Automated Disbursement batch process, particularly, when utilizing multi-threading processing.

For eligible payment requests for consolidation, if the sum amount of accounting lines exceeds $99,999,999.99 OR the number of accounting lines exceeds the maximum number of accounting lines specified for the Transaction Type “AD” on the DCREQ table, the AD Chain process will generate another AD transaction for the remainder accounting lines. Therefore, the accounting lines associated with a payment request could potentially be paid out by more than one AD transaction.

Note that the Contract Withholding Threshold will not be re-evaluated within each transaction because the evaluation is performed during Payment Grouping and is not affected by breaking up of the transaction due to the amount or line limitation. For example, an AD was to be created for $100,001,000 but the application ACH limit is $99,999,999. Two checks will be created; one for $99,999,999 and another for second check will be created for $1001. Both of these AD transactions will have Contract Withholding applied to them even though the second check is less than the $10,000 Contract Withholding threshold.

The Advantage AD Chain batch process creates an XML file with generated AD and EFT transactions and assigns a unique Run ID for all generated AD and EFT transactions within each run.

Updates Made by the AD XML Creation jobUpdates Made by the AD XML Creation job

The following tables get updated during the AD chain:

  • Disbursement Request Table: Selected for Disbursement Flag gets updated for those records that were selected for processing. When this flag is selected, modification to that DISRQ record is prohibited.

  • Intercept Request Table: If intercepts are taken then the Intercepted bucket on the Intercept Required Table gets updated with the Intercepted amount.

  • Disbursement Intercept Request Table: If intercepts are taken then records will be inserted into this table to track the intercept. This table is also as the input for generating the Intercept Transfer transactions.

Note: Even though the above jobs in the chain can be run individually by disabling other jobs, it is recommended to always run the entire chain. Please refer the CGI Advantage Accounts Payable Run Sheets guide for more information about how to run the AD Chain Job.