Accounts Receivable - AR vs GL Verification

Pgm: ARGLBCH – AR vs GL Verification; standard Treeview path: Accounts Receivable > Utilities > AR vs GL Verification

This utility is used for routine verifications and to verify imported and converted data. It identifies batches with which the AR 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 under the Inconsistent Batches section.

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

For example, when one compares the GL Trial Balance report to the AR Aged Report, they add together balances of AR Subledger Account and AR Deposit account - because the AR Aged Report also combines invoices and deposits. This is why you always need to specify the deposit account when running this AR vs GL Verification utility for the receivables account.

Inconsistent Batches

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

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

This utility identifies inconsistent batches by checking that the corresponding records for each posted batch exist in the AR 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 AR 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 under the Inconsistent Batches section. Thus, a batch created via the GL Transaction Entry screen to post against AR sub-ledger accounts will always be listed under the Inconsistent Batches section, because there is no corresponding record of the batch in the AR module (i.e. it is an unusual transaction that should be noted).

Also, for each pair of posted batch records (one in AR 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 customer, if either of their invoice’s default AR, discount, or retainage accounts (set on the Accounting tab of Maintain Customers screen) are accidentally set to the same account, this utility will catch that its posted Invoices were not distributed in a standard fashion.

Selection Criteria

Company

The company code will automatically default to the user’s AR log-on company, which may be changed if required.

Start Date

Enter/select the date from which this utility will look for inconsistent batches.

Cut-Off Date

Enter/select the posting date being reconciled to. In most cases, this would be the last day of a month or of a fiscal period.

Acc Type

There are three choices: AR Control Accounts, AR Retainage Accounts, and AR Deposit Accounts. Select the type of account being reconciled.

Account List

This field is used to enter the accounts to be considered by this utility. Account codes are separated by commas, and up to 19 accounts can be listed.

The account code must match the account type to get the correct results. For example, to view retainage only use retainage accounts. Do not use both the AR control and retainage accounts.

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.

Data Type

Select the data type by clicking the relevant radio button. The default is “Entered Data Only”, but this utility may be used on converted or imported data as well.

Include Lines with Missing AR – Checkbox

If checked, posted batches with missing records of the posting in the AR 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 AR 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 number, otherwise converted data will be shown as one batch.

NOTE: It is recommended that this box is unchecked because AR 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 under the Selection Criteria section.

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

The AR Amount column shows posted amounts according to the AR 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 AR Aged Report (provides posting details according to AR module) and a GL Trial Balance report (provides posting details according to GL module).

Common Examples:

If you have No AR amount at all, this usually indicates that the user ‘DA’ has entered a Journal Entry directly to a Control Account.

If you have No AR amount at all and the Data was imported, is means the imported distribution contained the wrong account codes.

If you have No GL, then this usually indicates that the user ‘DA’ overrode the default GL account on an AR transaction.

If you have No GL and the Data was imported, this usually indicates that you brought in AR 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.