There are hundreds of cases, all different. Many involve software bugs but at least one does not. You can read about that one in the common issues judgement paragraph 217.
My comment was about the Hertz car rental system, not Horizon.
Regarding software bugs in Horizon: Some of the bugs are mentioned in the early chapters in the book by Nick Wallis. I first read an article by the Guardian which only mentioned two of the bugs (as far as I remember) but also said many other bugs were discovered [1]. I first thought these were mostly UX issues [2] [3] that caused user input errors, but reading some of the inquiry reports and the book made it more apparent that there were system bugs, e.g. [4] on top of a sub-optimal message system [5]. Of course, you can say UX issues are also some kind of bug, error or defect.
[1]
>As early as 2001, McDonnell’s team had found “hundreds” of bugs. A full list has never been produced, but successive vindications of post office operators have revealed the sort of problems that arose.
[2]
>“The Dalmellington Bug entailed a user repeatedly hitting a key when the system froze as she was trying to acknowledge receipt of a consignment of £8,000 in cash. Unknown to her each time she struck the key she accepted responsibility for a further £8,000. The bug created a discrepancy of £24,000 for which she was held responsible.”
[3]
>"If a bunch of products sit in a basket for long enough on the screen Horizon will turn them into a sale automatically." -- ‘It is an example of Horizon doing what it was supposed to do.’ -- ‘It is evidence of the system doing something without the user choosing to do it.’ retorts Mr Coyne.
>"This stance of blaming the users if they were confused by Horizon’s design was taken to an extreme with “phantom transactions”. These were transactions generated by the system but which were recorded as if they had been made by a user"
[4] >In April 2003, Horizon version S30 was released by Fujitsu. It had not been properly tested, and it introduced a bug known as the Reversal bug. If a Subpostmaster inputted a series of transactions, and then for some reason wanted to cancel them, the transactions would have to be reversed out of Horizon. The Reversal bug appeared to reverse a transaction, but in fact doubled it. This was due to a plus sign in the code which should have been a minus sign. The Reversal bug was discovered by Fujitsu after Subpostmasters began to complain about the growing amount of non-existent money Horizon calculated as being in their accounts at the end of the week. When one Subpostmaster reversed an internal £13,910 cash transfer out of one stock unit and into another, he managed to create a £27,820 negative discrepancy in his accounts.”
[5] > "The biggest problem, however, was the information being written to something called a message store.”
>“According to Clint, Horizon’s developers had spent the last couple of years ‘firing any old shit’ into the message store as they changed and developed the product. Clint explained that this was a recipe for disaster. If a message was given a new data field, but this wasn’t retrospectively applied, the counter software could retrieve an old message with what it would now perceive to be a missing data field. The reaction of the application would be unpredictable.”
The SPMs were forced to sign and take responsibility for accounts that were prepared by the Horizon system, which claimed the SPMs owed the Post Office tens of thousands of pounds of imaginary money. If they later claimed that the accounts were wrong (which they were), they'd be prosecuted for signing them, and if they didn't do that they would be prosecuted for not paying the PO the money they supposedly owed. So they would lose either way, and the actual accuracy of the accounts was never tested in court, because in any individual case the PO did not disagree with the SPM about that.
The point being that this can't be blamed on software bugs alone. It was caused by different departments of the PO having completely contradictory ideas about how the software was supposed to work.
In fact very few of prosecutions relied on actual numbers. The problem was that Horizon handles both POS and accounting, and would shut down the entire store unless SPMs signed off on the accounts. Then if there was a dispute, the PO helpline would tell SPMs "just accept the accounts, we'll investigate later". The investigators would then decide it was fraud, but drop the fraud charge in return for a guilty plea to false accounting - which technically did happen when the SPM first accepted the disputed figures.
So none of the criminal trials ever got as far as actually looking at the disputed figures, because the defended would plead guilty or the PO would just lie about how the system worked to "prove" false accounting. As Justice Fraser wrote in the 2019 common issues judgement:
"This means that, even for disputed items going back as far as the year 2000, this litigation is the first time that there will be any independent consideration of disputed items showing in the branch accounts for the vast majority of the Claimants."
Indeed many of the disputes were not even caused by software errors but human error on the part of the SPM. Errors that they attempted to resolve but could not due to the way PO handled disputes.
So this is far more than just a code quality problem.
