As part of this automatic selection process, the system will examine each individual voucher on the accounts payable master file and decide

1.       Whether this voucher's company number and bank code matches the company number and bank code selected for this cycle.
2.       That the voucher's status will allow it to be paid (e.g., it is matched, approved, and not on payment hold).
3.       Based on the voucher's due date, whether it should be selected for this check run.
4.       If the voucher should be paid early to take advantage of a discount.
5.       Whether to pay additional vouchers to a vendor when one has already been selected.
6.      Whether to make other payment adjustments to the voucher's net amount (such as 1099 withholding).

Probably the most significant single parameter affecting the selection of vouchers is the "pay through" date (Figure 7-4).  Generally the system selects all vouchers that are ready to be paid and are due before this date.  As an alternative to manually entering the "pay through" date, the system may use a calendar set up by the accounts payable department to retain the dates of future check runs.  In this manner the "pay through" date automatically becomes the day before the next check run.

To add flexibility to this voucher selection logic, some systems allow a "fudge factor" to be added to the due date for particular vouchers.  Usually this is represented by a number of days, specified in the company table and/or the voucher master file.  The system adds this number of days to the voucher's duedate to yield a new due date to be used internally for calculating when the voucher will be paid.  The net effect is to delay payment of these vouchers.

Taking Vendor Discounts.  Vendors sometimes discount their invoices in an effort to encourage early payment.  The accounts payable department can take advantage of this to capture a small savings by paying invoices before the discount date.  However, to be thorough the system should base an early payment decision on the annualized rate of return implicit in taking the discount.  This can be rep-resented for any voucher by

Annualized rate from Discount

=

Discount Rate x 365 days (100% - Discount Rate) x Number of Days Paid Early

x

100%

As an example of how this calculation works, consider how the system might look at paying an invoice with terms of 1%10 Net 30.

Annualized rate from Discount

=

1% x 365 days (100% 1%) x 20 days

x

100%

=

18.43

To obtain the Discount Rate, the system must look in the terms table to find the discount rate associated with that voucher's terms code.  This example assumes that the voucher will be paid 20 days early, i.e., on the tenth day after the , invoice date.

If the cost of funds has been set parametrically at 10, the system will decide that 18.43 is a better return and pay this voucher now in order to take the discount.  Notice that the amount of the invoice does not enter into the decision.

In addition to these considerations, the system may allow discounts to be systematically taken after the discount date allowed by the invoice terms.  To do this, the system may add a specified number of days to the true discount date to arrive at a discount date used internally by the system.  This delay factor is usually stored in the company table and/or in the vendor master file.

Combining Vouchers into a Single Check.  The system will always try to combine vouchers due for the same vendor into one check.  But in addition to combining due vouchers, the system may be set up to select vouchers not yet due, but that will be shortly.  Once the system decides to pay one voucher for a particular vendor, there may be some benefit in paying other vouchers on-file, but not yet due.  The rationale here is simply to reduce the overall volume of checks.  This feature can be most useful in environments that process a large volume of small dollar invoices, such as companies that practice just-in-time manufacturing.  It avoids the effort and expense in paying a small voucher that may be the only voucher paid during the next check run.

Other Payment Adjustments.  As part of its payment processing calculations, the system may make other adjustments to the net amount paid on a particular voucher.  In instances in which the system performs 1099 backup withholding for specific vendors, the payment amount will be reduced by 20—the amount of backup withholding stipulated by the IRS.

If the vendor allows anticipation to be deducted, the system can calculate this as a small reduction in the net invoice amount if the invoice is being paid early.  Anticipation is an amount deducted for the early payment of an invoice.  This calculation, made by the system, is based on the prevailing funds rate, how early the payment is, and the invoice amount.  In effect, anticipation discounts the invoice's future amount due so that only its present value is paid.

Cash Availability.  The prepayment review also allows some cash management decisions to be made before the system prints the checks.  Management may move more funds into the account from which the funds are being drawn.  Or they may decide to forego paying a number of large vouchers to conserve funds.

HOLDS AND ADJUSTMENTS
The purpose of the prepayment review process is to show accounting management what will occur when it initiates the next accounts payable check run.  This mechanism allows the controller or the accounts payable supervisor to perform any holds or adjustments to the vouchers being paid.  Two common courses of action are

1.      Holding a voucher from payment.
2.      Forcing a voucher that would normally not be paid to be picked up during this check run.

Accounting management may hold certain vouchers from payment by changing their status code to "payment hold." Vouchers so affected will not be selected until they are released from payment hold and processed through another check run.

Another possibility is to partially pay an invoice that the system has selected for full payment.  To complete this transaction, the system may require or allow a reason code to classify why this invoice is being partially paid.  Partial payment still leaves the remaining amount due on the voucher.

Following any changes made to the vouchers and the accounts payable master file, the system will allow the prepayment register to be printed a second time.  In fact, it will allow the prepayment register to be printed any number of times.  Some continue printing this report until no more changes are made to the selected vouchers.  At this point the prepayment register should exactly mirror the check register that will be printed next.

Next Month's topic: Check Printing and Distribution

About this article and the author:

Doug Potter is the owner of The Newport Consulting Group a professional management consulting organization that provides clients with information systems planning, selection, and implementation services. He can be reached at dpotter@newportconsulting.com or through his Web site, http://www.newportconsulting.com. Note: The contents of this article were excerpted from Mr. Potters book "Automated Accounting Systems and Procedures Handbook" Copyright 1991 by Douglas A. Potter, published by John Wiley & Sons, Inc. New York