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.

Sunday 21 September 2014

Multi Currency - Billing

PCLaw is not a multi currency accounting program. However, it is possible to account and track multi currency transactions. I plan to discuss here in a series of blog posts about multi currency.

I begin with Billing. The hardest part of all foreign currency transactions is in billing. How do you bill clients in foreign currency and track the A/R balances?

There is a way to reverse engineer the bill templates such that you can have all charges - Fees and Expenses appear in desired currency. This is a trial and error method and unless you are a freak you should engage aCIC to design bill templates to bill clients in foreign currency. This involves creating a custom tab for putting in the currency and rate and then creating formula tokens on the templates. The problem with this is that the custom tab token information is not available in all sections of the template. To get round this few users are able to find and replace the desired token from another section to the section that lacks that token. It involves intricate steps that involve opening a template on notepad and playing around...As I say you got to be freakish to be able to do this, otherwise better to hire an expert to do it.

Once the template is designed you simply insert the custom tab and indicate the exchange rate. Then bill the matter with the charges in local currency using the correct bill template. The bill will appear in foreign currency ready to be sent out.

Note that the accounting is still in system currency. You would have to make use of the Collection Memos to indicate that the A/R is in foreign currency.