We feel that our work on optical character recognition for bank statements is complete. We are now aiming to automate the rest of our business to a consistent standard. Among the points to note are:

We have a Staff Procedure Manual to tell us how to do various things, particularly where we interact with the Revenue. We aim to make the most effective use of online systems of varying quality, and a combination of set procedures and our own spreadsheet proformas is the way to do this.

We have little databases of company and unincorporated clients, so we do not miss deadlines for the submission of the accounts or the Confirmation Statement. We can provide any other qualified accountant with a free blank copy if they contact us.

Most accountancy firms now use a spreadsheet-based system for their working papers of a type where the client details are typed in at the front and they appear on every page. On our system, there are many extra pages which are normally hidden away, but which can be summoned up as needed. As an example, there is a page which deals with the depreciation of a revalued asset. We have another page to use as a ready reckoner to add up a pile of sales invoices where many of the invoices have the same value, which speeds data processing in some cases. Since many pages like this are only used occasionally, it makes sense to keep them hidden until required.

Everything is colour-coded, blue for companies, red for unincorporated clients, green for VAT and yellow for PAYE. These colours can be subdivided dark blue for company secretarial and light blue for corporation tax, orange for partnerships (sometimes), and emerald, apple and olive green for the three VAT months. In the VAT month coming up (end of July), we will know to pick out all the emerald files. We often include views from the Revenue website or from a spreadsheet in our e-mails to clients, giving a colourful result.

When we have to type in a pile of invoices, we use logically the fastest possible procedure which uses the least number of keystrokes. When we have to process handwritten records, we believe that OCR is useless, at least for the time being. We can still type in by the column and use a Narrative Prediction routine to help out. Also the keys F1 … F10 on the keyboard can be reprogrammed to help out.

Coding up transactions uses last year’s coding table plus this year’s new items which are manually coded. Our table has a direct link to allow things to be looked up on the Internet.

We use a spreadsheet-based Extended Trial Balance to prepare the accounts, but this is cross-linked to a ledger with entries alternately in black and blue. We maintain full audit trail.

We have separate systems to deal with overdrawn directors’ loan accounts where we usually charge interest on a daily basis, and to deal with hire purchase accounts where we always use the actuarial method.

We are expecting some other accountants to use OCR in the near future. Our plan will be to out-compete them across the board, so we are not just a one-trick pony. What might take us by surprise is the use of OCR on a pile of invoices and/or on handwritten records. Well good luck to any competitor who is aiming to do this, but we will consolidate on the systems that we have. Probably someone somewhere will take us by surprise with something we didn’t think of, but we can insure ourselves against this with all-round competence in implementing new technology.

 
If we are scanning bank statements by optical character recognition, then we will find that some bank statements are better than others. For example, if we have pristine bank statements with “Balance brought forward” and “Balance carried forward” indicated on every page, then there are likely to be few processing errors, and often none at all. We are still going to insist that the accounts clerk views every statement on our blink comparator, but we will make it easy to cycle round the statements rapidly to check them.

We feel that this is as far as we should go with automated scanning. We will not program a system which just cycles round the statements automatically because that would be an abdication of responsibility by the human operator. OCR systems have some risk of going haywire, or some risk of the clerk looking like a sorcerer’s apprentice, and we will stamp on these risks by making the clerk look at every individual bank statement and take responsibility for its correct processing. This is likely to maximise the clerk’s productivity in the long run.

Our policy puts the emphasis on human control and graceful degradation when dealing with poor bank statements. It does not try to be too clever. We have to deal with OCR as an industrial process in the real world. Anything to do with OCR gives such a big improvement in productivity that we can afford to sacrifice a little time on the best jobs in order to get a decent result on the worst jobs. We want always to be able to do a standard job in a standard predictable time, and any minor underperformance on the best jobs can be rationalised by the principle that time spent in reconnaissance is seldom wasted.