Written evidence submitted by Mark Kelly (POH0027)
My name is Mark Kelly and I ran Brondeg Post Office, located in Swansea, with my wife from January 2003 to June 2006. The office was transferred to ourselves from my parents who due to ill health could no longer run it after an armed robbery and the stress caused by running the Horizon system. During our period of running the Post Office, we too were victims of two armed robberies which took place on November 2003 and November 2004.
After the last armed robbery, the PO auditor and Police took an inventory of what was stolen, following which, in spite of the trauma suffered by myself, my wife and a customer, we were advised by the retail line manager to remain closed the following day to balance and roll over, and open the following day, or not reopen at all. Under threat of losing our business, we followed the line manager’s orders, only to find during the balancing of the system that a shortfall of a couple of thousand pounds had been generated. This was inexplicable, especially in consideration of the fact that an audit had just been carried by the Police and Audit team, who confirmed there was no cash or transactions outstanding. After a series of disputes during which I contested why I should be held responsible for this shortfall, it was eventually agreed that the loss be placed in the branch suspense account, where it remained until the Office was closed due to my resignation under duress, off-set by a grant that was outstanding at the time.
Following the robbery, and after experiencing further losses from within my branch and hearing about similar issues from other members, I started to investigate possible reasons for the generation of these losses on our systems. One such error I found (see images below) I reported to Post Office on January 2006. I informed both Post Office and Fujitsu through the helpline about the error. I also informed the NFSP as both branch secretary and as postmaster to my EO of the Welsh region. A couple of months later, the bug had still not been fixed, and when I asked Post Office whether they were going to resolve the issue, or at least inform the network of the error, they informed me that they were not. This continued until June where I informed Post Office that if they did not take the problem seriously and either fix or inform the network as a whole of the issue within 14 days, I would inform members myself. A few days following this communication, my retail line manager arrived to do an on-the-stop inspection of our cash, where suddenly a £6K shortfall was discovered that had not been there the night before. By the time the Audit member arrived, the loss had now risen to £11K.
At this point, they informed me that if I were to resign from my position, they would not take the matter any further, but that if I did not resign, they would place me on suspension and look at charging me with false accounting and theft. Under extreme duress I resigned from my position and then contacted the EO Wales region of NFSP regarding the matter, who said he knew about it all but that I was “on my own”. We had previously experienced his negligence and lack of support with the two violent armed robberies we had been victim of whilst he was branch secretary, where in both instances Post Office tried to claim the losses against us, even after the police had caught one of the perpetrators of the armed robbery.
The only good advice I received was from Mark Baker EO for South West region, who advised my wife to obtain legal assistance, which we did. Our solicitor refused to let Post Office interview me under caution whilst I was under the Mental Health Act, which they had wanted to do. Also, when they finally interiewed me, our solicitor advised Post Office that if they proceeded with the charges, the fact that the system generated a loss after the robbery in November 2004 and that I had found the error and reported it would be used against them. The case was then dropped on condition that I could not make the Horizon problem I had identified public knowledge.
Now, what made this bug even more serious as I found out later, was that a fellow postmaster - Janet Skinner - was being prosecuted for false accounting/theft and Post Office was telling herself and the defence solicitor that there were no known bugs at the time, despite Post Office knowing that this bug existed.
Ever since this began, I have been suffering from depression, anxiety and PTSD from it all, and often, especially when I hear about other postmasters losing their positions due to losses, I wonder if in part, it is due to the bug I found, that many did not know about, and which the Post Office did not fix.
Below is a step-by-step of how the bug on Horizon was generated, which I reported to the Post Office through the helpline. The helpdesk staff relayed the problem to Fujitsu at the same time I reported it in January (the date can be seen in these screenshots). From the time I reported it until my contract was terminated/I resigned under duress (June 2006), it had still not been fixed, nor was a memoview sent to the network to inform them of the bug. I will first show the bug and then in summary I will explain the issue of the bug/error for the subpostmaster with their branch accounts.
I will first show how the system should work, by selling 150g 1st class service letter, as 64p of loose stamps.
At this screen, the counter clerk to sell “64p” of loose stamps would click on “other postage stmp icon” or press F3 on keyboard.
Once the clerk has entered “other Postage stmp” icon, they enter the value of stamp they want to sell, in this case £0.64, click on enter and then icon for £0.64 is on the transaction stack. To get to the settlement stage, they either press enter on the keyboard, or click on “finish £ take £0.64 icon”
At this stage, the clerk asks the customer how they are going to pay for the transaction, i.e. cash, cheque, chip card, saving stamps, etc. To show the bug, I will be “selecting chip card (F7)” icon.
At this stage (the bug is not yet triggered). On the right-hand payment panel, it shows the session total as 0.64 and max amount as 0.64. Because the bug has not been triggered, if the amount is changed from 0.64 to 1.28 it will give the correct message as shown in the step below.
As you can see above, it comes up saying “the amount entered (£1.28) is greater than the maximum permitted. The value may not exceed £0.64.” From the next step onwards, we will trigger the bug and then explain what it means for the Postmaster accounts.
Back at the home screen again, we will now click on “smart post”, which seems to be the code that causes the bug, as you will see later. Smart post was a new product at the time, where instead of selling physical stamps to post an item, you used the Horizon system to generate a stamp/label on the fly, which was then stuck on the letter/parcel for it to be posted. Until this transaction is carried out, whatever the value of the stock, does not exist in the current stock level, unlike the “loose stamps.” i.e. the horizon computer system generates that stock value in postmaster transaction accounts.
Once the clerk has gone into smart post, they get this screen - here it reminds the clerk to ask the three important questions which are – “Is it urgent, is it valuable, or does it need to be signed for / tracked.” These are just a reminder for the clerk/a shortcut menu. On this occasion we are going to say it is a normal mail and click on continue F16. The bug would still get triggered if any of those shortcut menus is chosen because it is the smart post subroutine itself that generates the bug once one goes into it.
After you click on continue, you enter the weight of the item from the scale (or if the office has an electronic scaled link to the terminal, it will read the weight automatically from the scales and give you services, like 1st class, 2nd class, etc). In this case I chose 1st Class service. If you click 1st stamp icon it will go to next step below.
Here, if one chooses “sell stamps” it will be selling loose stamps from the post office physical stock. In this case we will actually “print a label” so smart post will generate the stock value on the fly for the transaction, for the value of 64p.
When one chooses print a label, it starts the process of creating the physical stamp on the fly by using the counter receipt label printer, and the next few steps will guide you step by step.
When the user has put the stamp label into the counter receipt label printer and clicked on OK, the system will start generating the label as seen above.
Once the label has been printed, this screen comes up, asking if the label has been OK and hence can be used. Here if for some technical reason with the printer (like a paper jam) it does not print correctly, one selects “NO” and it will not generate the stock value on the system at that time and the user can repeat the process. In this case, it did print OK, hence we will click on Yes and so the value of 64p transaction is generated.
On the transaction serve customer screen after using smart post subroutine. The transaction stack on the right, is 1st Class with a value of £0.64 product on it, instead of the loose stamp stock “post stamp” as before. This is because the “1st Class” is an electronic stock value that the system generated. We will now go to settlement screen by clicking on finish and show the bug.