Accounts Payable - AP vs GL Verification

Pgm: APGLBCH – AP vs GL Verification; standard Treeview path: Accounts Payable > Utilities > AP vs GL Verification

This utility is used for routine verifications and to verify imported and converted data. It identifies batches with which the AP module’s account of its GL postings are inconsistent with the GL module’s account of its postings. These batches are referred to as inconsistent batches, and they are listed in the Inconsistent Batches section.

Details about the inconsistent batches can then be viewed by running the AP Aged Report (which provides posting details according to AP module) and the GL Trial Balance Report (which provides posting details according to GL module).

Users can also verify the inconsistent batches by printing the posting reports for the AP voucher posting batch and the GL posting batch and if the AP Control account is tying correctly with the GL, then there is no issue, as shown in the reports below.

Inconsistent Batches

When a batch created in the AP module is posted to the GL, the AP module keeps a record of the batch sent to the GL module for posting. In the GL module, a corresponding record of the received and posted batch from the AP module is also kept. So, both modules have their own records of the batch created in AP and posted to the GL.

However, for a batch created in the GL module, via its GL Transaction Entry screen, and posted against AP sub-ledger accounts, a record of the posted batch only exists in the GL module.

The following screenshot shows an example of a direct GL posting to a subledger control account, in this case AP 2000.100. Only users with the system privilege ‘SUBLGACC – GL: Allows the user to post to GL Subledger Control Accounts’ can enter this type of transaction.

Example of a direct GL posting to a subledger control account (Pgm: TRANENT; standard Treeview path: General Ledger > Transactions > Enter Transactions

This transaction will only post to GL and not to AP, therefore, the AP vs GL Verification screen will report this as an inconsistent batch.

Inconsistent batch identified due to direct GL posting to a subledger account

This utility identifies inconsistent batches by checking that the corresponding records for each posted batch exist in the AP and GL modules. This provides extra assurance that a sent batch was received and posted. If this utility finds a record of a posted batch in the AP module, but it does not find the corresponding record of the posted batch in the GL module, or vice versa, it will list the batch in the Inconsistent Batches section. Thus, a batch created via the GL Transaction Entry screen to post against AP sub-ledger accounts will always be listed in the Inconsistent Batches section, because there is no corresponding record of the batch in the AP module (i.e. it is an unusual transaction that should be noted).

Also, for each pair of posted batch records (one in AP and other in GL), this utility checks that the amounts posted to the accounts are the same.

Lastly, it checks that each posting is consistent with what was intended, in order to try and catch errors with the accounts used for postings. For instance, for a vendor, if either of their voucher’s default AP, Discount, or Retainage accounts (set on Accounting tab of Maintain Vendors screen) are accidentally set to the same account, this utility will catch that its posted vouchers were not distributed in a standard fashion.

Selection Criteria

Company

The company code will automatically default to the user’s AP logon company, which may be changed if required.

Start Date (optional)

Date from which this utility should start looking for inconsistent batches.

Cut-Off Date (required)

The cut-off date represents the posting date being reconciled to. In most cases, this is the last day of a month or of a fiscal period.

Acc Type

Three AP account types are available in this field’s drop-down menu: “Payables Control” (AP Control Accounts), “Retainage” (AP Retainage Accounts), or “Deposit” (AP Deposit Accounts). Select the type of account you are trying to reconcile.

Each of the three account types have specific accounts defined in the AP Control File, as shown in the screenshot above. When using the AP vs GL Verification screen, it’s important that the correct accounts for the AP and GL are being compared. Therefore, when specifying an AP account type, ensure that the account specified in the AP Control file matches the account selected in the Account List field for the GL module’s account.

Account List

This field is used to enter the GL module account to be considered by this utility. The account selected from the Account List field should match the account for the selected account type in the Acc Type field, as shown in the screenshot above.

NOTE: To find all inconsistent batches, all appropriate accounts must be entered. In most cases, when unexpected results are returned, the cause is an incorrect list of the accounts to consider via this field.

If necessary, up to five accounts can be selected from the GL, separated by commas.

Data Type (Entered Data Only, Converted Data Only, or All Data)

Select whether the utility can be used for entered data, converted data, or all data. The default for this field is “Entered Data Only”.

Include Lines with Missing AP – Checkbox

If checked, posted batches with missing records of the posting in the AP module will be displayed. This happens when postings originate from the GL module, via its GL Transaction Entry screen.

Include Lines with Missing GL – Checkbox

If checked, posted batches that originated from the AP module that do not have a corresponding record of the posting in the GL module will be displayed.

Group Converted Data by Batch # – Checkbox

If checked, converted data will be grouped by batch numbers; otherwise converted data will be shown as one batch.

NOTE: It is recommended that this box is unchecked because AP and GL data is converted in separate batches, therefore these batches will always show up as inconsistencies.

Inconsistent Batches

This section lists all inconsistent batches, according to the parameters set in the Selection Criteria section.

NOTE: No batches will be displayed if no discrepancies exist.

For each inconsistent batch, the following is displayed: batch number, the AP amount, the GL amount, the variance, the currency, and what types of AP transactions were within the batch (number of transactions of that type displayed under type’s column).

The AP Amount column shows posted amounts according to the AP module, and the GL Amount column shows posted amounts according to the GL module. If an amount only shows up in one column, it means that a record of the posting only exists in the corresponding module; and if amounts show up in both columns, it means that a record of the posting exists in both corresponding modules.

Details about the inconsistent batches can be viewed by running the AP Aged Report (provides posting details according to AP module) and a GL Trial Balance report (provides posting details according to GL module).

Common Examples

If there is no AP amount at all, this usually indicates that the user ‘DA’ has entered a journal entry directly to a control account.

If there is no AP amount at all and the data was imported, this means the imported distribution contained the wrong account codes.

If there is no GL, then this usually indicates that the user ‘DA’ overrode the default GL account on an AP transaction.

If there is no GL and the data was imported, this usually indicates that you brought in AP without posting it to the GL and the GL was imported via a different batch number.

If all of the appropriate accounts were not entered via the Account List field, an unexpected batch may be listed.

Discount Summary

Discount Summary contains a breakdown of the total difference in discount for the specific date range of the query

The Discount Summary section of the screen displays the total difference in discount for the query’s specified date range, which is the sum of voucher discount taken amount, check discount taken amount, and discount available. Adding up the three discount fields provides the total difference in discount for the specific date range of the query.

NOTE: Even if there are no batches out of balance, a value may still appear in the Discount Difference field to display the discount amounts.

The read-only fields in the Discount Summary section are calculated as follows:

  • When checks are posted with discounts, they are displayed in the first two fields, Voucher Discount Taken and Check Discount Taken.

  • When checks are posted but no discount taken, they are displayed in the Discount Available field.

  • When vouchers are posted with discounts recorded, they are displayed in the Discount Available field.

  • The Total Difference in Discount field is the sum of the first three fields, Voucher Discount Taken, Check Discount Taken, and Discount Available.

The value in the Discount Difference field on the AP vs GL Verification screen will change as the specified start and cut-off dates in the Selection Criteria for the query are changed.

To understand why, it is important to remember that the AP vs GL Verification utility is used when there is a discrepancy between the GL Trial Balance and the AP Aged Report. Specifically, it is used to determine where the difference originated from. Just as these two reports are dynamic and produce results based on the specific period/cut-off dates, so does this verification utility. This dynamic nature explains why there is a need to show the discount difference.

When dates are specified in the Selection Criteria section, the AP amount is calculated the same way as the AP Aged Report would present it, as of the same end date. The AP Aged Report always calculates the discount amount available as of the aged date and subtracts this amount from the outstanding AP amount, thus lowering the outstanding AP. At the same time, the AP GL account contains the full AP amount, so the two reports may have a difference which is equal to the total value of discounts available as of the aged date.

Therefore, the value in the Discount Difference field should be changing as the specified start and cut-off dates in the query are changed.