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.

 
If the client’s records consist of just a pile of invoices and nothing else, then optical character recognition is likely to be useless. We have tried playing around with an OCR pen, an OCR mouse and an OCR scanner, but by the time any of these devices have done anything useful, it will have proved quicker just to type it in. However, our use of OCR does make us ambitious across the board, so let’s see what we can do.

If the invoices represent the client’s accounting records and are not VAT-related, then just sort them first of all by the month, but not by the day. Put to one side those invoices which don’t actually fall within the accounting period of interest. Now we will just type the invoices into our system.

If we type in a date like 15/3/2017, followed by a date like 16, then the second date will automatically be expanded by our system to read 16/3/2017. The default mode for our system is “ordinal mode” which assumes that all dates are in chronological order, so if we then type in a date like 1, this will be expanded to read 1/4/2017. We can instead run our software in “instant mode” which assumes that all dates fall within the same month (this is another meaning of the word “instant” to be found in Chambers Dictionary). Typing in 1 then results in an expansion to 1/3/2017. If we actually want the following month, then in instant mode we type in 1+ (and if we want the same month in ordinal mode, then we type in 1-). We type in 1* to switch between the two modes.

With our pile of invoices sorted by the month, we switch the software to instant mode, and then just type in the day for most of our invoices. We will encourage our clients to sort the invoices for us and to put them in a concertina folder (currently costing 2 pounds from Morrisons). They will need a second folder for the second year, but in the third year they can just move the invoices to a cheaper file for archiving (50p from Morrisons) and re-use the concertina folder (so a budget of 4.50 goes a long way).

When we type in narrative, we can summon up an onscreen toolpad with the commonest narratives shown by buttons which we can just click to enter them. This toolpad also reprograms the function keys F1 to F10 so we can use them to enter very common narratives such as Telephone (F7) and Petrol (F9). If the client switches from petrol to Diesel during the year, then the first time we need to enter “Diesel fuel” manually, but if we then press F9 immediately, the new narrative will be picked up and used instead of Petrol from then on. We are relying upon the smart accounts clerk being able to remember from job to job that F9 is some sort of motor fuel expense, and then using that key whenever any sort of fuel receipt is found.

Most piles of invoices have quite a few motor fuel receipts, along with telephone, stationery, and a couple of principal suppliers such as Toolstation Carlisle and Wickes. Having teachable function keys where the user can amend the narrative should be able to speed up data entry quite a bit. Any key can be taught to generate any narrative, but the standard layout has F5 for the principal purchase, F6 as another cost of sales item, F8 for stationery, F10 for bank charges and so on. F7 often gets amended to generate “O2”, the mobile phone supplier most commonly found in client records. The onscreen toolpad can also be locked to switch off teachability when required. At the end of a data entry job, we can run a macro which shows us the commonest narratives that were found for a particular client, and make a note for next year in the client’s file.
 

---

 
The usual occasion of processing a pile of invoices is doing the VAT return. To enter an amount and its associated VAT, logically we need to type in two numbers. We can instead type in the bottom line or “consideration”, and run a macro Ctrl-V which estimates the VAT as one sixth of the consideration. Usually this estimate is right first time, but if it isn’t then we can nudge a penny up with Ctrl-N, or a penny down with Ctrl-M, or at the worst we can just type in the value net of VAT. This system was invented a long time ago.

Given the fact that we are going to be using some software, we can make that software look at the narrative, and if there is none, then it can be programmed to copy down the previous narrative. If we first sort our invoices by supplier, then we only need to type in the name of each supplier once, and the software can do the rest.

Suppliers with many invoices to enter can be put on one side. Where a supplier has just a few invoices, we sort these by date, meaning both month and day, and enter the dates in ordinal mode.

We then switch to instant mode and sort our big suppliers with many invoices by the month but not the day. Now with the average invoice all we need to enter is the day and the consideration, and run Ctrl-V. The month and year are copied down automatically as soon as we enter the day, and the narrative is copied down and the VAT amount calculated when we run Ctrl-V. Actually we have another mode in which to run our software where staying in the same column, we enter the day and the consideration, and the software does everything else, which minimises the number of keystrokes required.

This system is about three times as fast as a conventional system in which we need to enter day/month/year, narrative, consideration and value. It gives us OCR-like speed when we cannot use OCR, and we are sure that the reader will take our word for it that it is faster than any of the OCR systems we have tried. If a piece of A4 paper has a number on it, but just one number, then typing it in will always be quickest. A second number which can usually be estimated accurately by Ctrl-V does not alter this fact.

When we are having to enter invoices on an industrial scale, the distinction between ordinal mode and instant mode matters. We have been very much influenced by Frederick Taylor, an American work-study engineer, in developing our system. Taylor’s approach was to look at the work that is done in great detail and to try to determine how time could be saved. The main thing after this is that when we get a pile of invoices, we know what to do at once and there is no dithering.