Kickstarter link - please help fund this site

Monday, November 12, 2018

Post Office internal memos: Serious Horizon errors

Both the following documents were referred to in court on 7 November 2018, Day 1 of the Common Issues trial, part of the Bates and others v Post Office group litigation at the High Court.

I requested to see them, and they were released to me late on Friday.

The first document, which was written in August 2010 (although it isn't visibly dated, I understand the Post Office does not dispute this) should be visible to you below. If it isn't, you should be able to find it online here.

It is a note of a meeting in which a Horizon IT error is discussed between senior people at the Post Office and senior people at Fujitsu. Fujitsu used to operate Horizon under contract to the Post Office.

The error discussed is serious. It affects around ("circa") 40 branches. It could cause those branches to have a negative balance, even though the individual Postmaster in charge of each branch believes they have successfully balanced to zero.

The impact of this error is discussed:

"If widely known could cause a loss of confident in the Horizon System by branches"
"It could provide branches ammunition to blame Horizon for future discrepancies"
"Our accounting systems will be out of sync with!what is recorded at the branch"
"The branch has appeared to have balanced, whereas in fact they could have a loss or a gain."
"Potential impact upon ongoing legal cases where branches are disputing the integrity of Horizon Data."

We'll come back to that last point in a moment, but it is telling that the memo also notes:

"At this time we have not communicated with branches affected"

There is good news for those who are in the know:

"Fujitsu are writing a code fix which stop the discrepancy disappearing from Horizon in the future. They are aiming to deliver this into test week commencing 4th October [2010]. With live proving at the model office week commencing 11th October. With full roll out to the network completed by the 21st of October. We have explored moving this forward and this is the earliest it can be released into live."

but there is also bad news:

"The code fix will on stop the issue occurring in the future, but it will not fix any current mismatch at branch."

So what to do? Three options are discussed:

SOLUTION ONE- Alter the Horizon Branch figure at the counter to show the discrepancy. Fujitsu would have to manually write an entry value to the local branch account.
IMPACT - When the branch comes to complete next Trading Period they would have a discrepancy, which they would have to bring to account.
RISK- This has significant data integrity concerns and could lead to questions of "tampering" with the branch system and could generate questions around how the discrepancy was caused.This solution could have moral implications of Post Office changing branch data without informing the branch.

SOLUTION TWO - P&BA will journal values from the discrepancy account into the Customer Account and recover/refund via normal processes.This will need to be supported by an approved POL communication. Unlike the branch "POLSAP" remains in balance albeit with an account (discrepancies) that should be cleared.
IMPACT - Post Office will be required to explain the reason for a debt recovery/refund even though there is no discrepancy at the branch.
RISK - Could potentially highlight to branches that Horizon can lose data.

SOLUTION THREE - It is decided not to correct the data in the branches (ie Post Office would prefer to write off the "lost" [sic]
IMPACT - Post office must absorb circa £20K loss
RISK - Huge moral implications to the integrity of the business, as there are agents that were potentially due a cash gain on their system

The meeting decides to go for solution two. Note it is accepted as fact that all three solutions are possible. Bearing in mind that until January 2017 the Post Office maintained it was impossible to remotely alter branch accounts, this is significant.

[In January 2017, the Post Office admitted in court it was perfectly possible to alter branch accounts (a practice a former Fujitsu employee told the BBC's Panorama was rife when he was working there), and explained the reason it had been denied for so long is because the people doing the denying were not aware of the truth]

Returning to the point about impact discussed in the memo: "Potential impact upon ongoing legal cases where branches are disputing the integrity of Horizon Data."

The memo was written in August 2010. In October 2010 the trial of Seema Misra, Postmaster at West Byfleet branch in Surrey began. She was accused of theft by the Post Office. She claimed it was a bug in Horizon causing the problems.

One of the people listed as being present at the meeting in the note below is Gareth Jenkins, a Fujitsu technical specialist. Gareth Jenkins was also the IT expert supplied by the Post Office to explore possible Horizon errors in the Misra case with the defence's own IT expert witness Charles McLachlan.

To the best of my knowledge (I have read the transcript and done a search for the relevant terms just now) the receipts and payments mismatch of 2010 was not discussed in court at Seema Misra's trial. Mr Jenkins was examined by both the prosecution and defence barristers about a receipts and payments mismatch in 2005 (the Calander Square incident), but this latest one, to the best of my knowledge, was not disclosed.

Please note - Mr Jenkins seems to have spent a lot of time looking at the Horizon system in Seema Misra's branch. I am sure he would have raised any problems as he found them. I am not suggesting for one second that he, Fujitsu or the Post Office found and then hid a problem at Seema Misra's branch. However, just because they didn't find one, it doesn't mean there wasn't one.

Despite the judge pointing out in his summing up that there was no direct evidence Seema Misra had stolen anything, she was unanimously convicted of theft by a jury at Guildford Crown Court. Seema was sent to prison on her son's birthday, whilst eight weeks pregnant. She has vociferously insisted upon her innocence and she is both a claimant in Bates v Post Office and her case is currently under review by the Criminal Cases Review Commission, which I hope reads this blog.



The other memo is much more straightforward. You should be able to read it below, or online here:

It is an internal Post Office memo during which a Post Office manager discusses visiting Pam Stubbs, now a Lead Claimant in Bates v Post Office. Pam took the witness stand on Friday and will continue today. The memo is dated 2000, but must have been written in the first part of 2010, as Pam's problems started in the latter part of 2009 and she was eventually suspended in the summer of 2010.

Whilst Pam's temporary Horizon terminal, installed by the Post Office, is throwing up discrepancies in the thousands, she is going through hell. I remember when I first started recording my conversations with Pam. She described spending late nights ploughing through her receipts and Horizon printouts time and time again in order to find out where she'd gone wrong, standing at her counter the next morning in floods of tears, whilst receiving demands from the Post Office that she make good the discrepancies showing up on her Horizon terminal or risk losing her branch.

The memo below is unequivocal. "It is" says the Post Office manager about Pam's problems, in bold type, "Horizon related."

Pam was never told about the existence of this memo until this current trial. I am sure there is a very good reason for that.

Pam is due to re-start her cross examination in court in at 10.30am today (in 16 minutes, at the time of writing). If you would like to read my live tweets from the trial, follow me @nickwallis on twitter.

1 comment:

  1. I think what is being said is that the power problem is Horizon related - as part of installation of Horizon new power sockets were installed in branches and so the power problems are referred to as 'Horizon related' as they didn't exist before the Horizon install- in this email 'steady state'.

    ReplyDelete