This is written for accountants and anyone interested in new technology. We aim to use the very latest technology to prepare accounts and tax returns. In summary, we process bank statements using a combination of optical character recognition and our own system of narrative prediction and correction, which we find works best when the bank statements we receive are less than perfect.

Wouldn’t it be nice to have a magic wand that we wave at a pile of bank statements, and they appear at once copied onto our spreadsheet? After that, we can easily write a computer program to turn the information we get into a set of accounts. We do have such a program, and it can code up transactions by re-using last year’s coding table plus updates typed in manually by the accounts clerk, which never takes long. In the first year we use a generic coding table for a small business in Carlisle. Basically, once the data has been captured on a spreadsheet, we’re laughing.

This gives us plenty of incentive to look at optical character recognition for scanning bank statements. The trouble here is that real bank statements tend to be faint photocopies done on a cheap printer. Some statements have been replaced by even fainter computer print-outs which are upside-down. The client has helpfully written on some statements, and has “highlighted” some transactions with a dark marker pen. There are a huge number of small transactions so typing it in is out of the question if we have to meet a budget. Some narrative is meaningless and there are a few cheque payments, though not so many these days. There are coffee stains and other marks to contend with. Welcome to the real world.

To scan the statements we use Able2Extract OCR software. After the scan the statements are displayed on a blink comparator (as used by astronomer Clyde Tombaugh to discover the planet Pluto) so they can be manually corrected, making use of the human ability to compare patterns quickly. There is a visual run-through with a typical bank statement here.

Our software can make subsequent corrections by reference to the running total as long as the error rate is low, which it will be by now. It can detect automatically if the transaction order is inverted and if the columns have been transposed, either by looking at dates and column headings, or as a backup by looking at the internal logic of the numbers. Errors in income and expenditure items show up as single errors which allow their correction. Errors in the running total itself show up as double or reversing errors so they can be corrected as well. Our software corrects for unambiguous errors first of all, and then makes a best effort at ambiguous errors which can be checked by a human supervisor.

Many of the bank statements we get seem to fall into the awkward category, but our systems will go on working when simple OCR will fail. This is called graceful degradation and it’s what we need in a real accountant’s office. We are happy to trade off some ideal-case performance in favour of the ability to do a standard job in a standard time in all real cases.

Some bank statements arrive torn or stapled to death. Supposing that OCR is impossible to use, we can enter numbers using a handheld numeric keypad working in debit-positive convention, and there is a timer which adds “datepoints” if we are slow, as we would be at the start of each new page. We can then enter dates by jumping through the datepoints, and we only need to click on a button to enter the day, with month and year being copied down automatically. We have Narrative Prediction software which allows us to type in the first couple of dozen narratives by hand, and then to guess the rest. We overtype the guesses that are wrong. NP works well when the narratives are repetitive, and it also works with handwritten records when they resemble bank statements.

We can use our full OCR system with all the main high street banks. With some other banks, the narrative can be somewhat convoluted and difficult to process. For such banks, we use OCR to scan the dates and numbers, and NP to enter the narratives. For credit cards, we just type them in, which is often made easier by the fact that the typical credit card payment is for petrol or Diesel fuel, and we can just reprogram the F9 key to generate the narrative even before using NP.

Our software generates working papers as a by-product, namely the cash control account, the bank control account and bank reconciliation, and any VAT control account. We have an additional pack of working papers which allows us to show whatever we need to do the job, and to hide whatever we don’t need. For example, we have a schedule to deal with the depreciation of a revalued asset which we hardly ever use, so it is normally hidden away, but if we need it we can unhide it and we will see that it deals with the Revaluation Reserve as if it were a negative asset.

Sometimes all we get is a pile of invoices. If these represent the cash records, then we first sort them by the month, but we don’t have to bother to further sort them by the day. We then type in each invoice in a sequence of date, narrative and amount. On the second invoice, we only need to type in the day, and the month and year will be copied down automatically. We have Excel’s autocomplete to help out with typing in narratives, and we can also reprogram the keyboard function keys F1 .. F10 to enter common narratives like Diesel Fuel. The amount does need to be typed in in the usual way. When entering the date, it is normally assumed that each date is later than the preceding date (“ordinal mode”), but we can change the system so it is normally assumed to be in the same month (“instant mode” from a second meaning of the word “instant” which accountants should be aware of).

If the pile of invoices represents the VAT records, then we first sort them by supplier and then by date. For the first invoice we enter the date, narrative and consideration (the bottom line), and then run a macro with Ctrl-V to estimate the value as 5/6 of the consideration. If this is wrong by a penny or two, we can run Ctrl-N or Ctrl-M to nudge it up or down. Usually it is right first time.

If the next invoice is from the same supplier, then we just enter the day (we are in ordinal mode by default in both the software and in our sorted pile of invoices) and the consideration. When we run Ctrl-V the empty narrative will be filled in from above as a by-product of working out the value.

These methods of dealing with a pile of invoices are inspired by OCR and by looking at electronic touchscreen displays in supermarkets and are designed to minimise the number of keystrokes we have to use. Where a lot of VAT invoices are from just one supplier, we have a special mode where we sort them only by the month and can enter data more quickly in instant mode.

With all our clients we keep an aide-memoire to remind next year’s clerk of how to process a job. If 90% of bank statements can be processed by OCR, it doesn’t really matter if the other 10% need to be typed in as long we don’t dither and just get on with it. It is common to overlook the usefulness of Narrative Prediction and the aide-memoire can help here.

Our use of new technology enables us to quote fixed fees with confidence. The speed of our system enables us to respond quickly if anything needs to be done in a hurry. We can also talk about free bookkeeping when all the transactions are through the bank account. In this case we would prefer clients not to do any bookkeeping.

With our system we can rapidly assemble a director’s current account and charge interest at the official rate (currently 3%) on a daily basis if it is overdrawn, subject to holding meetings of the shareholders and directors to agree to do this. This type of interest, however, may not be chargeable retrospectively, so it would be best to see us as soon as possible. All our hire purchase calculations use the actuarial method so any cash flow statements we do are accurate and we can deal with early terminations of the loan.