Search This Blog

Wednesday, 24 September 2014

G/L Reconciliation Report Differences – Wrong Data Entry Dates

The G/L Reconciliation report is an invaluable tool in PCLaw to detect data inconsistencies and any corruption in the accounting data. This report is typically run at end month to spot any anomalies.

Any differences appearing on this report most likely points to data corruption. However there are cases when differences appearing are a result of data entry issues.

For firms on Accrual systems the following control accounts can get skewed due to wrong dates used at data entry:

·         Accounts Receivable (“AR”)

·         General Liabilities (“AP”)

For a mismatch in AR the cause at times can be current receipt dates used to receive payment for forward dated invoices. For example a user posts a receipt dated March against an invoice on a matter billed in April. This will definitely cause an imbalance in AR between G/L, Journal and Client balances.

When users exit a data entry screen that was used to process a backdated entry, the date stays when they re-open the same data entry window again (Receive Payment window in this case). They often times forget to change the date in the date box when opening the data entry window again to enter a new transaction.

In the case of AP a user may process a forward dated Payable using a cheque of current date. For Example: Payable is dated July and the cheque to settle the payable is dated June.

For AP Process Payables the issue is unlikely to be the date but what happens is at times Vendors send post dated invoices. For instance an ISP sends an advance invoice for internet use for the following month. Accounts Payable staff will enter the payable dated the following month and process payment in the current month. They do not realize that there is a difference in a) processing a current or old payable and b) making an advance payment to a Vendor for a future payable – there are steps for making advance payment to a Vendor.
With a little bit of vigilance above errors can be avoided.

No comments:

Post a Comment