It is quite common to invoice a customer with terms of “30 days or net monthly account”. Small customers will be expected to pay within 30 days, while large customers will be expected to pay at the end of the month following the month of the invoice, so an invoice sent in May 2018 would be settled by 30 June 2018.
Large companies do it this way because they may receive several invoices from a supplier, and will want to settle all of them with a single payment when they do their computerised cheque run. It would therefore be a good idea for the supplier to have sent a statement at the start of June listing all outstanding invoices. Typically the cheque run would be about the 25th of the month, which is the date of this posting. If you give credit and have debts to collect, then you might like to have a discussion with us. Most accountants are also general business advisers as well.
The “net” in “net monthly account” has “nett” as an alternative spelling.
Archives for June 2018
We would like to scan all our clients’ bank statements using optical character recognition. Experience suggests that our typical bank statement is a photocopy of a photocopy with ticks and scribbles, and maybe a coffee stain and a dead insect. Shouldn’t we just type it in?
Let’s give the score “alpha” to pristine original bank statements with a running total on every line which are easy to scan by OCR. A pack of such statements may be called an Alpha Pack.
Let’s give the score “omega” to the worst bank statement we actually get. It’s a skewed photocopy of a photocopy where every number has been ticked off, several annotations have been added, several running totals are missing, and so on. A pack of statements where the first statement scores alpha, the second beta, the third gamma, and so on until the last scores omega, may be called an Omega Pack. Technologists may recognise that we are about to talk about Graceful Degradation.
So what is our OCR system like with an Omega Pack? How soon will it be before we abandon OCR and resort to typing it in? For us these are key questions. Any fool can design an OCR system to process Alpha Packs. Our average statements score between epsilon and sigma. We aim to be able to scan them all anyway.
As well as a computer, our other principal resource is the human visual system which is good at pattern recognition and seeing the big picture, and we aim to exploit it. The spreadsheet version of each scanned bank statement will be displayed on a blink comparator in a simple “in your face” style one at a time so the accounts clerk can look back and forth between the display and the original statement. In addition, if a running total is wrong by a penny or two, the computer can detect and highlight this, but leave it for the clerk to fix by overtyping wrong numbers after inspecting the original paper statement.
If some numbers are missing off the end of a statement, the human will spot this easily and can just add them. The computer will find this impossible to fix. If a number is wrong within a statement, the computer will find this easy to spot, while the human will struggle. Computer and human have complementary abilities which we will exploit.
With this system, we are able to process statements scoring between alpha and sigma, let’s say. Statements scoring between tau and omega will need to be typed in, but we have a system to do this quickly by the column. After entering numbers, the system can use “datepointing” to ask us to only enter the dates of material transactions (it interpolates the rest), and it can use “narrative prediction” to make a first guess at the narratives so we only need to overtype the narratives that are wrong.
When things go wrong, OCR systems tend to go haywire. If the reader has ever tried to use an OCR device, this is probably his or her first experience of them. We use Able2Extract OCR software which is “best of breed” at spotting tables of information as a matter of experience, and never goes crazy, but then we force the software to stick to a rigid five column template (date, narrative, number, number, running total). This stamps on the haywire problem. Every bank has its own template which the clerk must select, but selection of the wrong template with common British bank statements merely means that column widths need to be adjusted, which is easy. It could be said that we are using the OCR software like a glorified bulk OCR pen scanner.
We assert our control in the horizontal direction with the five column template. In the vertical direction, our blink comparator display will pick up extraneous material (“rubbish”) from above and below the working area. Since many working areas begin and end with lines like “Balance brought forward” and “Balance carried forward”, we can easily program our blink comparator to highlight the working area for the benefit of the clerk, but to leave it to the clerk to take the actual decision to delete the rubbish. The clerk could instead choose a different working area before deletion, but the software usually gets it right first time.
Our software can recognise and deal with errors like “alance brought forward” and “etails” which may appear occasionally. We can simulate these errors by overtyping on OCR output and then we program our own software to fix or tolerate them.
The process of picking out and tidying up the working area we call idealisation, and the result is an ideal bank statement where the running total is always correct and there is no extraneous matter. Normally idealisation only takes a minute or so and is much faster than typing it in. Towards the back of the Omega Pack idealisation is going to take a bit longer, but not out of proportion to the degree of deterioration of the statement. This is called Graceful Degradation and it is the basic aim.
Ideal bank statements can then be easily processed by the rest of our OCR system. Actually, if we deliberately leave a few errors in, but not too many, our software can make repairs by reference to the running total, so we have massive defence in depth. However, since the computer is just a stupid machine, we recommend that the clerk does not rely on it too much.
So what is OCR software like with the Omega Pack that we encounter in the real world? As we said, any fool can produce an OCR system to process an Alpha Pack. We need something that gives sensible results when things are less than perfect. If we work through an Omega Pack, we are likely to find that the scanning of narrative is the first to suffer as the statements progressively deteriorate because there is no independent way to check narratives. At some point we may abandon scanning of narratives and just scan dates and numbers. The alternative technology is then Narrative Prediction where we predict future narratives from what has been entered already, and then overtype the predictions that turn out to be wrong. In some cases, the narratives are so predictable that no overtyping whatsoever is needed, so NP can be a good backup technology. Sometimes it is actually better than OCR and an accountancy firm which chooses to use NP all the time is not necessarily at any disadvantage.
As we continue to work through the Omega Pack, dates will begin to suffer. Dates which are obviously wrong are just deleted and then interpolated from nearby successfully-scanned dates. Once we are deleting all the dates, we can resort to just scanning numbers and use a “datepointing” system. This asks the user to enter the dates of material items, and also the first date of every new bank statement. It then completes the dates by interpolation.
Continuing through the Omega Pack, numbers are the last to go because bank statements have a running total which we can use to check them and highlight obvious errors. Once we cannot even scan numbers, we must resort to typing them in for which we have a “single sweep numeric keypad” system. Both OCR and SSNK can be used on the same run of bank statements, and can be intermixed with datepointing and Narrative Prediction, so we have lots of options.
Some client records consist of handwritten transactions for which OCR is useless. We see these as merely omega quality bank statements for which we would use SSNK, datepointing and NP. Gringotts Bank provide handwritten statements as a matter of course, while the printed statements of some banks are little better.
Value Added Tax returns for the quarter ended 31 May 2018 should be submitted by 7 July 2018, and any payment which is due should be made electronically by the same date.
P11D returns are due to be submitted by 6 July 2018. These are for the income tax year ended 5 April 2018.
If an employee was given any benefits in kind during the income tax year, then a P11D return needs to be filed. Examples of benefits in kind are a company car or private medical insurance.
In addition, if an employee has been reimbursed for any expenses, then this also needs to be reported on the P11D return.
Small private companies with a year end of 30 September 2017 and into their second or later year of existence should submit their accounts to Companies House by 30 June 2018 in order to avoid a Late Filing Penalty.
In looking for a system which can scan bank statements using optical character recognition, what we are looking for is a decent rise in productivity. We are not looking for a magic wand. The bank statements we scan are of variable quality, and we accept that the accounts clerk will need to review the results one page at a time. Most obviously, if cheques have been written then the clerk will need to look at the cheque book stubs and may need to type them in.
After scanning, we show each page as scanned to the spreadsheet on a “blink comparator”. The clerk can visually compare the result with the original. Our software flags up obvious errors, and it now also highlights the presumed business area of the statement. If the clerk accepts this highlighting as correct, then one click of a button removes anything extraneous. This does have to be done one page at a time, but let us repeat that the bank statements we get are of variable quality. Some are photocopies of photocopies with ticks and handwriting added.
Once everything is scanned into one big bank statement on our spreadsheet system, the clerk needs to review the narrative. There are buttons to help with tidying up narrative, and if anything is actually missing, then the clerk can run a narrative prediction routine to guess what it was, which is often successful. The clerk then overtypes anything that is wrong.
A little time spent looking at the bank statements can also be regarded as the reconnaissance phase of the job, and proverbially “time spent in reconnaissance is seldom wasted”. We don’t necessarily want everything just a bit too streamlined because then things might get missed.
It can happen sometimes that when you are an employer, you have not actually made any wage or salary payments for a PAYE month such as the month from 6 May to 5 June 2018. In that case you must submit electronically an Employer Payment Summary as a NIL return by 19 June. This is too easy to overlook.
If you engage a local accountant and business advisor or a payroll bureau to do your wages, then this will be taken care of. In our case we keep a diary and do a batch of payrolls at about the same time each month. Our payroll files are bright yellow like the old P30BC booklet so we do not overlook them.
Let’s say that Britain and Germany put their passport printing out to tender, while France reserves passport printing to a French company, supposedly for security reasons. Now the British passport contract is up for renewal. Companies from Britain, Germany and France all put in a bid.
The French company has its fixed costs covered by its domestic contract with the French Republic, and so it can put in a bid at marginal cost. The British company was never able to bid for the French contract, and so this is not fair competition because the British bid has to be at full cost.
The British company could have put in a bid for the German contract, so any successful German bid for the British contract is merely them doing to us what we were aiming to do to them. This is fair competition.
Frankly our Government has been too soft on this one, whatever its complexion, and Gateshead is suffering for it. Someone like Donald Trump would not stand for this nonsense. Mr Trump gets a lot of unfavourable publicity, but let’s not forget why he won the U.S. presidential election.
This sort of thing has happened just too often while we have been members of the European Community, and it is one of the drivers of the Brexit vote. Remainers have usually failed to grasp an issue that is obvious to anyone living in Gateshead, even if they don’t know what we mean by full cost and marginal cost. If ever it is proposed that we rejoin the European Community, the Remainers are going to have to tell us how we will get fair treatment for places like Gateshead.
Construction Industry Scheme returns for the month from 6 May to 5 June 2018 should be submitted online by 19 June. This includes NIL returns.
It is only too easy to get caught out by the need to submit a NIL return when no payments to subcontractors have been made. If you engage a local accountant to do your CIS returns, then this will be taken care of. In our case we keep a diary and do a batch of work at about the same time each month. We aim to be the Carlisle accountants that businesses will turn to for a range of advice and services.
If your company had a deadline of 31 May 2018 for the submission of its accounts to Companies House, and this deadline has been missed, then you still have something to play for, and you should contact Carlisle accountants such as David Porthouse and Co at once. You will incur a penalty of £150, but this penalty rises to £375 after 30 June 2018 if you still haven’t submitted your accounts. These penalties are £300 and £750 if you miss the deadline two years’ running. We can readily prepare and submit your accounts within the month if you contact us straight away.