When we are using an optical character recognition system, sometimes we get the feeling that epithets like “one-trick pony” or “fair weather friend” are appropriate. OCR is excellent when things are going well, but when things are not going well, there is some risk of being left in the lurch.

Suppose that the client has very heavily annotated the bank statements. OCR will be useless, even when we can scan each statement on our blink comparator and make direct amendments to what we see based upon the ability of human beings to compare patterns. In this circumstance, we do not want to fall off a cliff edge.

We have taken a lot of time to develop other systems. In the case of the bank statements, we would have to type it in, but we would do it by the column in the order numbers, dates and narratives. We have lots of devices to help out here, so although we will take a bit longer to do the job, it won’t be disproportionately or catastrophically longer. Technologists call this graceful degradation.

In fact, we would be very competitive with our non-OCR systems even if other accountants were using OCR and we were not. One big alternative to OCR is Narrative Prediction. After we have typed in a few narratives, we can get the computer to guess the rest, and then just overtype the ones that it gets wrong. Often this gets it all right first time, or with only a few amendments needed. With the narratives being typed in last, it is obvious how NP will work with standing orders, but with other transactions our software can do a statistical analysis and make a prediction. In practice, we use NP all the time, even when we could have used OCR.

The combination of OCR and NP definitely isn’t a one-trick pony. NP is relatively invulnerable to poor scannability and can do handwritten records, so it is only in processing numbers and dates that we can have problems. We only really need to process about one in ten dates of material items, and can interpolate for the rest. As for numbers, well accountants can expect to have to deal with them. We normally enter numbers in debit-positive convention, which is fast and minimises the number of keystrokes required.

 
We have now given some thought as to how we would tackle certain difficult jobs. Possibly the worst kind of job is a private bank account being used for the business. There are a huge number of small transactions, of which about one in ten are relevant to the business. What would we do?

To begin with, we scan in all the bank statements using optical character recognition. This reads in dates and numbers, but not narratives. We then start adding narrative to income items, but every expenditure item is just labelled with the letter X. After a month or so, we run the Narrative Prediction routine. This guesses all the remaining income narratives, with a fair chance of getting it all right first time since income tends to be repetitive. We then overtype the guesses that are wrong, which won’t take long.

All expenditure items will now be labelled with an X after Narrative Prediction. We look through the bank statements and start overtyping with obvious business expenses. For petrol, we just tap the F9 key to generate the narrative “Petrol”, and this is easy to change to “Diesel fuel” by typing Alt-F9. For telephone expenses, we use the F7 key, which is easy to change to generate “O2” or “Vodafone Ltd” or “Virgin Mobile” or whoever else is the provider of telephone services. For rarer expenses, we just type in the full narrative, and the autocomplete system will help out the second time. It is good policy to add narrative to large items and to standing orders, even if they turn out to be private, and we can add narrative to standing orders in bulk if we want to.

We think that this system is the best way to do it. The large number of transactions dictates the use of OCR, but we don’t want to have to start processing a large number of private narratives when we don’t have to.

The point about this type of job is that many of the transactions are computer-generated, as direct debits or standing orders or similar, and computers can churn them out in a way which a human cannot. If we just get a pile of invoices to type in, there tends to be just not that many invoices in the first place, because each invoice requires the action of a human being. Likewise, handwritten records are seldom more than 72 transactions or half a dozen per month. It’s the computer-generated stuff that we fear.

 
Suppose that a client’s records are just a pile of invoices. We cannot sensibly scan them with optical character recognition, so we will need to type them in. We can guess that a fair number of the invoices will be for petrol, and now we only need to press the F9 key on the keyboard to enter “Petrol” as a narrative. If the client changes to a Diesel-engined car during the year, we can press Alt-F9 and this will enter “Diesel fuel” as a narrative. It will also make a permanent change to Diesel, which will be remembered in future years.

If we press Alt-F9 again it will switch to “EV Charge”, and if we press Alt-F9 yet again it will cycle back to “Petrol”. Let’s say we have a car powered by a new type of fuel, say hydrazine, then we will need to type in “Hydrazine” and then press F9 while on the same line to teach the software to remember it, which will then be done for all future years.

After we run the Ctrl-T macro, a mapping table will be generated which the clerk can code up. If the clerk moves the cursor over “EV Charge” or “Hydrazine” in the table and presses Ctl-Alt-G, then the software will start up Google and search for “EV Charge Carlisle” or “Hydrazine Carlisle” to ascertain what they are. We can easily change Carlisle to some other town depending upon where the client is located. The mapping table is of course re-used in future years.

All these new facilities will speed up the work of processing client information, especially when we cannot use OCR. One of our key ambitions is “graceful degradation”, a concept which says that we should not fall off a cliff edge when OCR is useless. What may be called the OCR mentality should go on working for us even in the most difficult circumstances.

 
We have now formalised our thinking on what sort of technology we want to enter client information into our system. If we can then we will use optical character recognition for all numbers, and possibly for dates as well. If we cannot use OCR for dates, then we will just use datepointing and enter the dates as the day only from a toolpad. If we cannot use OCR for numbers, then usually we will use our own single-sweep system to type them in. Sometimes we may be able to use an OCR mouse scanner for numbers, but possibly only for credit card statements.

Narratives will always be entered using our own narrative prediction system, even when they could have been entered using OCR. This makes us a lot less vulnerable to the vagaries of OCR, and gives us a single technology for both printed matter and handwritten material which many clerks may prefer. We begin by typing in narratives for the first month or so, and at the same time we can use teachable function keys to help out. When we run our narrative prediction routine, teachability is switched off as a by-product, and then we just use the keyboard plus the function keys to overtype narratives as necessary. We think that this system will normally outperform OCR in a real accountant’s office, granting that there may be ideal conditions where OCR is better.

Future OCR development work can concentrate on optimising systems to scan numbers and dates, which is an easier task. With non-OCR systems, development work will come to a full stop at some point in the near future, because there will only be so many things we can invent before arriving at something like the Carnot or Betz efficiency. At some time in the future, we may use OCR for narrative, but for the time being we feel that the market for accountancy services is best served by competition between different approaches.

Generally dates and narratives have low information density or low entropy, and are therefore amenable to inventions to speed up data entry. Numbers have high entropy, so apart from OCR there is nothing more to invent after the single sweep system. With OCR we have a choice of the pen, the mouse, the wand or the flatbed scanner. The pen is simply not as good as typing it in plus datepointing, and this is unlikely to change. The mouse and the wand are essentially the same type of device and may have some minor potential. The flatbed scanner with a sheet feeder will make most of the running. Let’s see how this assessment plays out in a few years’ time.

 
Every accounts clerk must have had the experience of finding an indecipherable scribble on a cheque book stub. After a while, you realise that the payee is your employer!

An optical character recognition system is never going to be able to deal with this situation. There are OCR systems which claim to be able to recognise handwriting. We think that they will be not worth the bother. Come back and ask us again in a hundred years’ time. For the moment, OCR is for printed matter.

Some clients keep all-handwritten records which are pretty good, almost like a handwritten bank statement. Other clients annotate the printed bank statements so heavily that OCR will be useless, even in its blink comparator form. A5-sized statements won’t go through the sheet feeder, so they might as well be handwritten. Gringotts Bank issue handwritten statements anyway.

The key to processing handwritten information is to do it by the column, which should at least mean some economies of scale. We do all the numbers, followed by the dates, and then the narratives, in that order. We type in the numbers manually, but we have a single-sweep system which normally works in debit-positive convention. If we type in a negative number, it is interpreted as income and moved to the “paid in” column automatically. The system can work in credit-positive convention as well.

The time at which we type in the number is also recorded, and if we take a long time, then a “datepoint” is generated. After we complete a page, we check that the running total is in agreement if this is possible, and reach for the new page. By the time we have done this, the datepoint time will have been exceeded, so we always get a datepoint set at the top of each new page. Other datepoints will be set for any material items on that page. Datepoints which get set accidentally or after interruptions do no harm.

After entering all the numbers, we can jump through all the datepoints and enter the dates manually, and our software helps us to do this. All the missing dates can then be entered by interpolation, which is good enough for items which are not material.

When we come to enter narratives, we enter the first page or two, and then run a Narrative Prediction routine which guesses the rest. Sometimes this gets it all right first time, and sometimes the result is disappointing, but usually this is a useful thing to do. We then overtype the narratives that were guessed wrong. This overtyping still has the assistance of our super-autocomplete system, or alternatively of our teachable onscreen toolpad (we first teach the system to generate required narratives, possibly based on notes made from last year, and then switch off teachability so we can overtype narratives).

Narrative Prediction is a principal alternative to OCR. It spots the standing orders first of all by looking at their regular amounts, and enters the relevant narratives. It then guesses the other narratives using statistics, working on a logarithmic scale. If a variable payment is made at the same time every month, then at least in theory Narrative Prediction will spot this as well, but we are not claiming too much for this. Generally Narrative Prediction works well when populations of transactions are easy to tell apart. On the income side, if all large receipts are sales income, but all small receipts are bank interest, then Narrative Prediction will operate correctly. However, a few receipts of 5,000 or 10,000 which turn out to be capital introduced may not be spotted.

Another reason why OCR may be useless may be simply the state of the bank statements. If they arrive heavily stapled or crinkled, then we may just use manual data entry as above. We could think of photocopying everything and scanning the photocopies, but by the time this is done, they might have been entered manually in less time anyway, simply because our manual systems are so fast. One alternative is to scan the statements with an OCR mouse scanner, which we are still working on.

We have our own looseleaf bookkeeping system which of course we designed on a spreadsheet. We can give this to our clients in order to encourage them to keep handwritten records in a standard format, so we can easily come along and process everything by the column. Any bank statements can be attached to the back of this system using the treasury tags provided. Clients only need to keep records for cash transactions.

Sometimes we get a mixture of regular bank statements and faint computer print-outs, the latter usually in inverted format and overlapping. We can use a mixture of OCR for the regular statements, and columnwise typing for the awkward bits. We want a robust OCR system which does not fail catastrophically when conditions are less than ideal, and now we have one. We use Narrative Prediction for everything, even when we could scan the narratives after all, simply because this is less vulnerable to poor scanning conditions. This is the right technology to be working on as of 2017 in our judgement, and we welcome competition from anyone who disagrees with us.

Having OCR also stimulates the imagination. We often ask ourselves how we could have something which is almost as good as OCR when OCR is impossible. We do find useful answers to this question. Working with OCR, we pick up some programming knowledge on Visual Basic for Excel. We then apply that knowledge to non-OCR systems.