<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=41671&amp;fmt=gif">

 

My previous blogs on the Post Office introduced you to the most widespread miscarriage of justice in British history and the critical role of leadership. This blog cover matters related to the fields of fraud and revenue and business assurance. We will start with the relatively obscure subject of suspense accounts. But first of all, allow me to thank Bath Publishing for their permission to publish several extracts from Nick Wallis’ excellent book.

When is a suspense account not required?

This is a subject that should be close to the heart of revenue assurance professionals. But what is a suspense account? The Oxford Dictionary defines it as:

“Book-keeping an account in which items are temporarily entered until their proper place is determined.”

Clearly there is a role for a suspense account and this concept is certainly familiar to Revenue Assurance professionals. In fact, it is arguably one of the most important points to monitor a network’s billing integrity. Questions arise such as why are records entering the suspense account and how can they be recovered? Why has the size of suspense suddenly increased? I recall back at T-Mobile UK that Revenue Assurance monitored the suspense account very carefully – in effect it was a pot of money waiting to be billed and collected, just as long as the technical issues impacting the contents could be fixed.

Nick Wallis captures the Post Office’s approach to dealing with discrepancies through suspense accounts in the following extract:

“The other option was to put the discrepancy into a local suspense account; that is, lift it out of the weekly figures and park it somewhere to be investigated. This had to be done with the authority of an area manager or the Post Office Suspense Account team.

 

But what happened then? Who was responsible for that discrepancy? The Subpostmaster or the Post Office? The Post Office was not obliged to investigate the cause of the discrepancy, and Subpostmasters were only responsible if the discrepancy was down to their carelessness, negligence or error. After a few years of Horizon’s operation, branch suspense accounts up and down the country were filled with disputed discrepancies. The sums involved were growing by the thousand. The Post Office was leaning on Subpostmasters to make the discrepancies good with some success (the threat of being sacked for refusing was an effective motivator), but many Subpostmasters were refusing to accept responsibility for gaps in branch accounts which they were certain had nothing to do with them. It was becoming a real headache for both Subpostmasters and the Post Office.

 

In 2005, the Post Office came up with an elegant solution. It removed the branch suspense account option from Horizon. Subpostmasters could no longer park discrepancies in suspense. They had to accept discrepancies as debts. Great for the Post Office. Not so good for Subpostmasters.”[1]

Rather than addressing the underlying issues that were creating the reconciliation differences, the Post Office decided to remove the suspense account option. This had the effect of giving SPMs two options in the face of accounting differences - either falsely signing off their accounts or refusing to sign off their counts. The first was a criminal offence, the second a breach of contract with the Post Office. They were facing a Hobson’s choice – risk going to prison or risk losing their business, livelihood and investment. The suspense account option, the proper option for such a discrepancy had cynically been removed.

So to answer this section’s question, when is a suspense account not required? Never, unless you live in a perfect world!

(a brief addendum – whilst watching the UK’s Business and Trade Committee recently - see previous blog - I was a little surprised to see that suspense accounts were the topic of discussion in the House of Parliament. You can watch it here!)

Don’t blindly trust computers

Little Britain was a hit of the 2000s and had many funny characters and scenes. One particular character still resonates, even today. The scene is of David Walliams playing a lady sat behind a computer and, irrespective of the question, responding “the computer says no”. I think there is a reason why the general public relates to this scenario. We are all slightly suspicious of computers and find it uncomfortable to trust the output of systems that we don’t understand. That is normal and healthy behaviour.

If you searched for a flight from London to Paris in nine months’ time and the cheapest price was £1,000 you wouldn’t just assume the result was correct and buy the ticket. You had formed an expectation, which has not been met, so you will rightly treat the results with scepticism. You might double check your input data (dates, destination, class of fare) and even run the query again on another site.

If only the Post Office had applied similar scrutiny to their own work. Let’s face it, nobody should ever take data from a computer system and blindly trust it. You should always form an expectation of what is reasonable and, if the output is not in line with your expectations, question it. This was one of the biggest mistakes the Post Office made, they simply assumed that their Fujtsu system was infallible. Let me quote from the BBC Inside Out news story I referenced at the beginning of my first blog. The Post Office stated “the Horizon computer system is absolutely accurate and reliable and has operated successfully in over 11,000 branches for more than 10 years it has been fully and robustly tested and meets the relevant banking industry standards”.

Judger Fraser found differently in the High Court. He stated that the Post Office’s approach "has amounted, in reality, to bare assertions and denials that ignore what has actually occurred… It amounts to the 21st century equivalent of maintaining that the earth is flat.” [2]

Who on earth works in telecommunications and thinks that switches, routers, intelligent networks, mediation platforms, charging and billing systems etc. are infallible? Certainly no one that works in revenue and business assurance! In fact, it is those fallibilities that explain the very existence of these departments.

When procuring anything – political convenience and lowest price are not the best measures

When I started my telecoms career, my first job was as a finance project manager and my main customer was the Head of Revenue Assurance. I was tasked with leading the replacement of a new mediation platform and new interconnect billing platform. Serious objections had been raised to simply awarding the project to the incumbent and a thorough exercise was launched to review the market. This taught me a lot about procurement. Whilst I will never suggest I am an expert in the subject, I do wonder if I knew, even at that stage, more than the Post Office did!

It turns out that the Post Office was not the original customer of the Horizon system. It was meant to be the Benefits Agency who wanted to migrate benefits payments to a computerised payment card system. The National Audit Office revealed that Fujitsu scored bottom in eight of the eleven scoring categories during the procurement phase.[3] Nonetheless, they were narrowly the cheapest and they were selected.

However, the UK Treasury lost confidence in Fujitsu’s ability to deliver the payment card system (note, at the time, the company was still known in the UK as ICL, which has been acquired by Fujitsu) and the contract was at the cusp of cancellation. Except it was never cancelled. In fact, the National Audit Office report states:

“in May 1999 the government decided that removing the payment card from the project offered better value for money than complete cancellation. Very importantly, it would simplify the project, reduce the risks and protect the early automation of the Post Office by 2001, and was preferable to continuation.

What the report doesn’t state, because it was only revealed in the ongoing Public Inquiry, is that there was also pressure from the Japanese government[4] not to cancel the project to protect Anglo-Japanese relations and Fujitsu jobs in the UK. Taken together, a political decision was taken with the Post Office automation used as a convenient way of avoiding truly tough decisions. Political decisions are almost always compromises and very rarely signs of strong leadership.

The lesson for all of us is abundantly clear. When purchasing any solution, especially a hugely complicated solution, make decisions on sound technical and commercial grounds. Be bold, show leadership, even if the decision is a tough decision. If you are a Revenue Assurance professional insist that you are involved in the selection of any system that gets close to billing and make sure that you are the one fighting for technical excellence and robust end to end controls.

Remember, just as with Horizon, cheapest is not necessarily best. One of my pet peeves is the use of reverse auctions. Sure, when I buy or sell on eBay, I totally understand the role of auctions, especially for commoditised items. However, even eBay recognise auctions are not always appropriate and hence offer a “buy it now” option. So, when a telecoms operator is procuring highly complex software, it amazes me that they will sometimes procure through an auction mechanism. Remember, if you use an auction you are effectively stating all vendors are equal other than price i.e. you are buying a commodity. Nothing could be further from the truth.

Understand the risk of placing all your data eggs in one basket

We are all familiar with the idiom of not placing all of your eggs in one basket. This sage advice applies to many scenarios and could have helped the Post Office with respect to its data. Rather than blindly trusting Horizon, their new computer system, the Post Office should have used multiple sources of data and compared one to the other. Differences should have been analysed, understood and explained. Consideration should also have been given to the most persistent differences – even if they were of a lower value.

The Post Office simply took Horizon data, assumed it was correct, enforced their incredible, and eventually unenforceable, contractual rights which meant the onus to explain discrepancies was placed upon the SPMs.

Understand your own systems

Data has no value if you don’t understand it. To understand data you must understand the systems that produce it, beginning to end. That means the network, the architecture, the security and audit features, the process flows and the checks and balances, amongst others. Back when I worked at T-Mobile, I recall being amazed at the level of details my colleagues in Revenue Assurance had over the dozens of platforms our business operated. (Paul Reed, if you are reading this, I am thinking of a session we had when you walked me through the entire billing chain from switch to bill some 20 years ago!).

Sadly, this was not the case for the Post Office. They either had zero understanding of their business or they lied about it. The fact that Justice Fraser referred the testimony of two Fujitsu employees (the company that built the Horizon system) to the Director of Public Prosecutions for potential perjury suggests it was lies rather than ignorance.

One of the most contentious points was whether the Post Office had the ability to remotely access and amend the local systems of SPMs. The Post Office, all the way down from the CEO, consistently denied that this was possible. Frankly, this always sounded preposterous – how on earth could remote support and fixes be provided if remote access, with the ability to at least create data, was not available? Eventually the Post Office did own up to the truth – they had full ability to remotely change branch accounts, without the consent of SPMs, and without such changes being visible to SPMs. This capability totally undermined the Post Office’s claim that the SPMs were solely responsible for the accounts their branch produced and subsequent cash shortfalls.

Ensure your staff have the basic capabilities to fulfil their role

The one constant in this scandal has been doubts about the performance of the Horizon system. It is normal that any software has bugs – afterall, it is developed by humans and humans make mistakes. Throughout the period of scandal there were bug and issues logs – albeit their existence was denied for many years.

However, one inescapable fact became clear during the Inquiry. The quality of the development team left much to be desired. I recall reading this Computer Weekly article[5] and my jaw literally dropping. The quote from an internal Post Office report stating Whoever wrote this code clearly has no understanding of elementary mathematics or the most basic rules of programming” is shocking. Whilst computer code may well be the foundation of any software, the main ingredient of that code is the intellectual rigour of the person who wrote it. If they lack elementary mathematics and a know-how of programming, the software is doomed before it has even been written.

The lesson here is clear. Hire appropriately qualified staff, review their work and, if the work is found to be sub-standard, take remedial action – either scrap the code or bring in a new team to fix it. Sadly, this was not a path the Post Office chose to take.


[1] p. 37, “The Great Post Office Scandal”, Nick Wallis, Bath Publishing, 2021

[2] Paragraph 929, “Alan Bates and others vs. Post Office Limited, Judgement 6 “

Horizon Issues”, https://www.judiciary.uk/wp-content/uploads/2022/07/bates-v-post-office-judgment-1.pdf

[3] National Audit Office Report, “Value for money - The Cancellation of the Benefits Payment Card project” https://www.nao.org.uk/reports/the-cancellation-of-the-benefits-payment-card-project/

[4] “Fujitsu put pressure on UK government to sign off troubled Horizon project, public inquiry hears” https://www.computerweekly.com/feature/Fujitsu-put-pressure-on-UK-government-to-sign-off-troubled-Horizon-project-public-inquiry-hears

[5] “Horizon system EPOSS code writers lacked basic programming skills, public inquiry hears” https://www.computerweekly.com/news/252526586/Horizon-system-EPOSS-code-writers-lacked-basic-programming-skills-public-inquiry-hears

Subscribe Our Blog

Let Us Know What You Thought about this Post.

Put your Comment Below.

You may also like:

Lessons qualified professional staff should learn from the Post Office Scandal

Welcome back to my fourth blog on the scandal of the Post Office’s Horizon system and the devastating consequences of th...

How the lack of leadership and values created the Post Office IT Scandal

Last week, I published my first blog on the scandal of the UK’s Post Office IT Scandal. I described how this IT scandal ...

The £1bn Post Office IT System Scandal – Lessons for Telecommunications Professionals

At the time of publication, there is no bigger story in the United Kingdom than the IT Scandal that affected the Post Of...