CASE NUMBER 1HQ16X01238
ALAN BATES & OTHERS [CLAIMANT]
Vv
POST OFFICE LIMITED [DEFENDANT]
SECOND JOINT STATEMENT OF
JASON COYNE
AND
DR ROBERT WORDEN
25 FEBRUARY 2019
POLO0266866
POL00266866
POL-BSFF-0104929
POLO0266866
POL00266866
Introduction
This Joint Statement sets out further areas of agreement between the Experts. The structure of the document captures i) A table of bugs/errors/defects
containing evidence of financial impact upon branch accounts that both experts agree (or indicate if they do not), ii) all expert agreements grouped by
Horizon issue, and iii) additional comments and observations input by the respective expert.
Because of time pressures and the complexity of the issues, we have not been able to address all the Horizon issues in this joint statement. We will issue a
subsequent joint statement addressing those issues we have not yet addressed. For those issues we have addressed in this statement (issues 1, 2, 9, 14 and 15),
the layout and references are not as polished as we would have wished, and there may be further points we need to address in the next joint statement, which
will address the other Horizon issues. We apologise to the court for these shortcomings.
Jason Coyne — In this Joint Statement I have sought to document my agreement or disagreement with Dr Worden in respect of the Horizon Issues. It is my
understanding that this document is not a responsive report to Dr Worden’s supplemental report, therefore I have not provided comments, criticisms or
observations of his report in this Joint Statement. Where Dr Worden seeks to provide rebuttals and responsive comments to my supplemental report, I do not
address them in this document, but seek to focus only on agreement on the Horizon Issues as they are stated in the pleadings. Where an additional statement
under an agreed issue is attributed by me, It is made to clarify or qualify the agreements made in that issue section.
Jason Coyne — Dr Worden wishes to include a table of what he believes are the financial impacts of the Bugs Errors and Defects discovered to date. I have
not considered such a calculation and therefore the data within this table is not agreed.
Robert Worden — I believe this joint statement (and those to come after it) can serve as a concise roadmap for the court, of the areas of agreement and
disagreement between the experts, as they are at the date of issue. As such, this statement should express the disagreements as concisely as possible but
describing the differences between the experts’ opinions with sufficient precision to assist the court. I have attempted to do that.
POL-BSFF-0104929_0001
POLO0266866
POL00266866
Table of Bugs/Errors/Defects with acknowledged or disagreed evidence of financial impact
Index I Bug/Error/Defect I Identified Year/ I Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
1 Receipts and 2010 Identified approx. 60 branch accounts I This is a bug acknowledged by PO, PEAKs PC0204765,
Payments impacted which had impact on branch PC0204263,
Mismatch Bug accounts. PC0203864
(acknowledged KELs
bug) Peak PC0204765 and others show wrightm33145J,
that Fujitsu were able to establish the I ballantj1759Q,
branches affected and the amounts, chitkelaS1953M,
even if they had not been reported by I BrailsfordS130S
the Subpostmaster. Coyne
Supplemental
Therefore, the extent of this bug is Report 3.27
well established, in the GJ analysis.
Gareth Jenkins
analysis
RW 650-659
2 Callendar 2000-2006 Thirty branches affected when This is a bug acknowledged by PO, PEAKs, PC0126042,
Square/Falkirk investigated in 2005. which had impact on branch PC0126376,
Bug accounts. PCO0103864,
(acknowledged PCO116670,
bug) Peak PC0103864 shows that PO/FJ PC0075892,
were able to detect occurrences of the I PC0083101,
fault, (by reconciliation on the Host) PC0086212,
even if they had not been reported by I PC0193012
an Subpostmaster. KELs
JSimpkins338Q,
The bug arose from a fault in the JBallantyneS245K
underlying Riposte sofware, so itis I Coyne
not surprising that it took Fujitsu Supplemental
some time to understand it, or that Report 3.27
they had to rely on the suppliers to fix
POL-BSFF-0104929_0002
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
it. It does not show poor system Godeseth WS
design or support by Fujitsu.
RW 660-669
3 Suspense Account I 2010-2013 It was reported that 14 branches were I This is a bug acknowledged by PO, PEAKs PC0223870
Bug affected when investigated in 2013. and the technical account of the bug I KELs acha2230K
(acknowledged is well established. Coyne
bug) The PEAK notes that Horizon needs Supplemental
to change in the future; “This change I It was a transient effect arising not Report 3.43
would alert support teams to the from a fault in the software, but from
existence of a system problem a change in database archiving policy I Gareth Jenkins
affecting branch accounts, rather in 2010. The delay in correcting it Analysis
than having to wait for it to be arose from a failure of
reported. Such a problem, affecting communication between PO and RW 670- 686
14 branches, was not reported until Fujitsu. Because the bug would only
15 months after it first could have manifest itself annually for any
been noticed.” affected branch, the effects of this
delay were not widespread.
Peak PC0223870 shows that Fujitsu
were able to identify the branches
affected, even when Subpostmasters
did not report it. There is evidence
that the branches were compensated,
as I would expect from the normal
error correction processes.
4 Dalmellington 2000-2005 (actual 112 occurrences of the bug impacting I Dalmellington was analysed in my PEAKs PC0246949,
Bug/ Branch fix to Horizon 88 branches across a five year period, I first report under KEL acha621P, PC0247207,
Outreach Issue recorded in KEL as _I some branches impacted five separate I although I did not there identify it KELs acha621P
(not 12" Jan 2016) times. The contemporaneous with Dalmellington, which is a cash Coyne
acknowledged but investigations suggest that the remming error. Supplemental
dealt with in discrepancies were not detected in a Report 3.46
Responsive timely manner. PO had a well-tested process of
Witness reconciliation and TCs to detect and RW Supp 144 - 163
Statements) correct errors in cash remming (used
POL-BSFF-0104929_0003
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
The 2015 Audit report into the bug 20,000 times per year), whatever their I RW 938 (Table 9.3)
reported that four occurrences with source. It is straightforward for
financial discrepancies’ have Horizon to detect any discrepancy
“unknown outcomes” between a 'rem out’ and the
corresponding 'rem in’ (a mismatch
arising either from a miscount, or a
multiple count of a pouch), and then a
TC can be issued.
This process catches and corrects
remming errors, whatever their cause
- including if they arise from, or are
provoked by, sofiware faults.
The bugs/errors/defects below have been identified by review of PEAK and KEL records. The number of bugs/errors/defect and supporting
evidence referenced may n
ot be exhaustive nor depict the full extent of the issues.
E ‘Remming In’ March — August Para 3.63 Coyne Supplemental As for the Dalmellington bug, above I PEAKs see Coyne
Bug (not 2010 recorded as Report for 14 example branches ~ PO had a robust process for Supplemental Report
acknowledged) fixed approx. 2011 I impacted. detecting and correcting remming paras below for
errors, whatever their origin. PEAK references
KELs acha4221Q
So, there were no lasting effects on Coyne
branch accounts. Supplemental
Report paras 3.56 —
3.66
RW Supp 144-153
RW 938 (Table 9.3)
6(i) I ‘Remming Out’ February/April Para 3.70 of Coyne Supplemental As for the Dalmellington bug, above I PEAKs see Coyne
(i) Bug (not 2007 recorded as report for 57 branches impacted. — PO had a robust process for Supplemental Report
acknowledged) fixed approx. 2007. detecting and correcting remming KELs achaS08S
errors, whatever their origin. Coyne
Supplemental
POL-BSFF-0104929_0004
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
Report paras 3.67 —
3377
RW Supp 144-153
RW 938 (Table 9.3)
6 (ii) I ‘Remming Out’ May 2005 Para 3.73 of Coyne Supplemental As for the Dalmellington bug, above I KEL
(ii) Bug (not Report, One example branch —PO had a robust process for GMaxwell3853P_
acknowledged) impacted detecting and correcting remming PEAK PC0120937
errors, whatever their origin. Coyne
Supplemental
So, there were no lasting effects on Report 3.73
branch accounts.
RW Supp 144-153
7 Local Suspense 2010 reported as Utilising PCO197409 as the search The KEL acha5259Q implies that PO. I PEAKs PC0198077,
Issue (not
acknowledged &
not “Suspense
Account Bug)
fixed in September
2010
term returns four associated KELs
(see Supporting Evidence column).
Mr Parker’s first Witness Statement
identifies 33 branches impacted. .
However, the associated PEAK
records have not been provided and
the four associated KELs to the above
PEAK illustrate this problem may
have been larger than 33 branches as.
KEL acha5838T records “Two
different but similar problems”.
Utilising the KEL as the search term
returns the following PEAK numbers:
acha5259Q — 6 PEAKs
cardc2043L — 10 PEAKs
and Fujitsu were able to identify all
occurrences of the problem, without
being notified by any Subpostmaster.
I would therefore expect them to have
corrected any impact on branch
accounts as part of normal error
correction processes.
I would not expect evidence of all
corrections to accounts to have
survived to the present day. Peaks and
KELs are not used to record
corrections of financial impact.
Fujitsu analysed the KEL (Parker
WS) and said: ‘Temporary financial
impact which would have been
cancelled out in the following period
by a corresponding discrepancy”
PCO197409,
PC0197797
PC0204396,
PCO0197409 + those
displayed in table at
3.81 of Coyne
Supplemental Report
KELs acha5259Q,
PorterS199P
Coyne
Supplemental
Report paras 3.78 —
3.83
RW analysis of KEL
— Appendix D.5
POL-BSFF-0104929_0005
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
PorterS199P — 3 PEAKs Fujitsu analysis of
acha5259Q — 6 PEAKs KEL — attached to
Parker WS
8 Recovery Issues The text within the PEAKS and KELs I The KELs and Peaks cited by Mr PEAK PC0197769,
(not suggests that in each case a branch Coyne are not indicative of errors in I PC0198352,
acknowledged) account discrepancy would be evident I Horizon. They provide guidance on PC0256566,
and would require correction by the I how to correct discrepancies caused I PC0256502,
Post Office. by human errors or other errors in PC0264632,
transaction recovery (‘recoverable PC0223229.
transactions’)
“Wrong Trading I 2010 PC0198352 reports; “This problem KEL acha5650L,
or Balancing caused a loss at the branch for which I Because there were many such errors, I acha959T,
Period” they should not be liable” there were many calls to the help desk I dsed4010N,
and many Peaks and KELs cardce464Q,
seng2048K,
PC0256502 & PC0256566 report: Normally, correction of errors dsed2640M
“Subpostmaster 2017 “advised them to do the necessary involved back office reconciliation
processed a reconciliation for this sum of cash and issuing TCs. This was accurate Coyne
transaction that (Cash withdrawal for £244). We have I and effective; I have derived an upper I Supplemental
did not appear on no way of knowing the internal POL _ I limit of £2 per branch per month on _I Report para 3.84 to
the transaction process as to when they will do the the mean impact of erroneous TCs 3.98
log” reconciliation if not done already.”
One important KEL acha959T was RW sect 9.6
‘AUTHORISED’ PC0264632 reports;: “As the guidance to the back office MSU, not
receipt was successful receipt was printed, PM for Subpostmasters RW supp sect 7 and
printed but should have collected 54 EUR appendix
transaction lost from the customer but we are not sure
from log. the customer account was credited
with this amount because the
transaction was not recorded
“investigation of anywhere to check this.”
transaction(s) ina I 2017- No
state other than resolution reported
POL-BSFF-0104929_0006
POL00266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
Final as showing I although still acha959T is referred to by 2,473
in daily chasing up to Aug I other PEAKs from 2010 to 2018,
Reconciliation 2018 each of these may (but may not)
report” indicate a similar issue with the
Horizon recovery process and
potentially creating a discrepancy
within branch accounts.
9 Reversals Identified impact in I In April 2003 due to a failure in Transaction reversals are a complex PEAK PC0089918
April 2003, KEL regression testing, Horizon version area which, like recoverable (25" April 2003),
PSteed2847N S30 was released by Fujitsu and this _ I transactions, are less familiar to PC0091284
created April 2003 I introduced a bug where the value of I Subpostmasters and are more prone to
last updated 20 transactions reversed by human error. They lead to many calls I KEL PSteed2847N
June 2003 Subpostmasters was shown twice in to the help line and to many KELs
the amount of the reversal in branch _I and Peaks - not necessarily related to I Coyne
accounts. any fault in Horizon. Supplemental
PSteed2847N (the KEL associated to
the PEAK record (see Supporting
Evidence column)) records: “the PM
should be contacted to say that the
problem is due to a software error
and that they should ask the NBSC
for balancing procedures”.
Coyne supp. 3.99 - 3.101 refer to a
cash remming reversal issue.
Whether or not this was caused by a
fault in Horizon, all remming errors.
are detected by Horizon and corrected
by TCs (or previously, error notices).
Therefore, there was no lasting effect
on branch accounts.
Coyne Supp. 3.103 and 3.104 further
address the same remming reversal
issue. My opinions are as for other
remming issues.
Report 3.99 — 3.104
POL-BSFF-0104929_0007
POL00266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
The KEL indicates that, as this
remming issue was caused by a
software bug, PO and FJ wanted
discrepancies to be corrected early to
reassure the Subpostmaster. In my
opinion, a remming TC would have
corrected the discrepancy in any case.
10 Data Tree Build Identified impacts: I Text within the PEAK reads “Data There was a bug which has potential I PEAKs PC0033128
Failure PC0033128 dated _I trees have been failing to build fully, I impact on branch accounts, early in (10 November 1999),
Discrepancies 1999, and the system has not been detecting I the lifetime of Horizon. PC0132133,
this.” PC0046811,
3 x PEAKs in 2000, Soon after it arose, the error was PC0055964,
Dugannon branch suffered a £43,000 I trapped and detected by DEP and was I PC0058161
Associated KEL discrepancy but the cause was not then soon fixed.
MSCardifield2219S I immediately known. KEL
created July 2005 The fault was easily noticeable at MSCardifield2219S
last updated £52,814.29 at the Yate Sodbury branches before the error trapping
November 2007. Branch which was soon introduced and Coyne
would be even more noticeable after I Supplemental
£9,368.40 at the Appleby that. Only three branches appear to Report 3.106 to
Westmoreland branch have been affected, as described by 3.118
Mr Coyne.
PC0033128 sates “... There have been
a number of calls relating to this kind I Because it was so noticeable at the
of issue.”) branch, and the Peak is concerned
with a software error rather than any
other cause, I would expect any
discrepancies in branch accounts to
have been corrected.
ip Girobank Identified period I Eight instances of this defect are Peak PC004432, cited at Coyne Supp I PEAKs PC0044232
Discrepancies
May — September
2000,
identified in the PEAKS as
relative to KEL MWright531
which was associated to one
manifestation of this issue. The
3.119, shows that the first fault
concerns reports. A fault in a report is
not a discrepancy in branch accounts,
and only causes one if it causes a
(5" May 2000),
PC0044101,
PC0050418 (17" July
2000), PC0050861
9
POL-BSFF-0104929_0008
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
PC0068633 dated discrepancy values identified from I person to make a mistake. I have not I (21* July 2000),
2001, those PEAKs referenced range yet seen evidence that it did so, and PC0052575 (13
from £40 - £500. Mr Coyne cites no such evidence. September 2000),
3 X PEAKs dated Discrepancies in reports are of PC0052704 (18""
2002 (associated «ati . concern to Subpostmasters and give August 2000),
with KEL Hrvestigations relative to TEAK I rise to Peaks and KELs. PCO052804 (21*
AChambers4410R). y August 2000),
were actually further problems in I ty the second Peak PC0068633 cited I PC00S3975 (13%
relation to this bug, in summary, — I aj 3.124, it is clear that the error September 2000)
asa result of process timing notice cleared the error, which was an
issues. example of normal error correction. KELs MWright53 1p,
The extract cited by Mr Coyne at AChambers4410R
Further KELs are associated with I 3.125 indicates that this fault also
the varying manifestations of this I affected reports. Coyne
bug. Each KEL in turn applying ___ I Supplemental
to varying numbers of PEAKs (see i Covad eoncks I do peeing Report 3.119 — 3.128
ir Coyne's conclusion at 3.
Coyne Supplemental references). branch accounts were affected.
12 Counter PC0058528 dated I When replacing a counter within a I Mr Coyne's description at 3.129 is Coyne
Replacement 2000, KEL branch the process could result in that this was a receipts/payment Supplemental
Issues (Rebuild/ I JBallantyneS328R I the “oral loss of a transaction”. __ I mismatch. It was therefore obvious to I Report 3.129 3.131
One sided created December the Subpostmaster and unlikely to
Transactions) 2000 last updated I Identifying the branches impacted have been attributed to human error. I Example Peaks
J ‘ . He says that 'there is no further detail I PC0058528,
uly 2007 (returns I by such issues is not ae a :
. within the PEAK record as to how PC0071836,
88 further straightforward, PEAK this was resolved financially for the I PC0133822,
PEAKs). PC0058528 is used as an example, Subpostmaster.’ PCO153851,
KEL however, this bug/error/defect PC0058686
DRowe4629L could apply in varying ways. The I The KEL makes this clearer. The
raised in 2002 KELs indicate these were KEL records both the cause: 'Riposte I KELs
records other intermittent but ongoing problems I is coming online from Recovery JBallantyneS5328R,
occurrences of mode too early and causing messages I DRowe4629L
this issue noted in
2003 and 2009.
and could result in gains, losses or
no effect due to both sides of a
transaction being missing.
to be overwritten’ and the nature of
the correction: 'To find the
10
POL-BSFF-0104929_0009
POLO0266866
POL00266866
Index
Bug/Error/Defect
Identified Year /
Year(s) in Effect
Coyne Opinion as to branch
account impact
Worden Opinion
Supporting
Evidence
overwritten transactions for
reconciliation we need to look at the
Ripostemirror messagestore',
followed by detailed instructions.
It therefore seems clear that,
following any reported discrepancy,
reconciliation and a routine Error
Notice would correct it. So, I do not
agree with Mr Coyne's implication at
3.129 that there were potential
discrepancies in branch accounts; or
with his conclusion at 3.131.
The incident arose from a hardware
replacement (probably from a
hardware fault) not from a fault in
Horizon. It is a different kind of
recovery issue.
This conclusion appears to apply
equally to the 88 further Peaks which
refer to this KEL, as noted by Mr
Coyne in para 3.130.
Withdrawn Stock
Discrepancies
Identified
occurrences
January to April
2011
The full extent of branch impact
has not been identified,
PC0209602 states “Can cause
confusion and unexpected (though
hopefully temporary)
discrepancies at branches by
allowing them to declare stock
which has already been
withdrawn. Additional problems
T analysed this KEL in the appendix
to my first report because Mr Coyne
had cited it in his report at para 5.165.
I said: 'Some impact on branch
accounts cannot be ruled out,
although it is small’.
Fujitsu's analysis of the same KEL
was: ‘This may have had a financial
impact but, if so, it would be due to
Peaks PC0207834,
PC0209602,
PC0208918
KEL
pothapragadac4359R
Coyne
Supplemental
Report 3.132 — 3.139
11
POL-BSFF-0104929_0010
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
Spring 2011 highlighted that at human error (i.e. declaring that it
least 60 or so branches managed to I held an item of stock that it couldn't
do this.” transact). This discrepancy would be
removed if the branch accurately
The word “additional” implies this declared that it had no such stock.
defect oun, 4 have been operational Mr Coyne at para 135 cites the Peak:
before spring 2011. 'Can cause confusion and unexpected
(though hopefully temporary)
discrepancies at branches by allowing
them to declare stock which has
already been withdrawn’.
Since the discrepancies in branch
accounts appear to be both temporary,
and caused by human error, these are
not a case of a bug in Horizon
causing lasting effects on branch
accounts.
14 Bureau Exampled The PEAK detail records the impact I This appears to be a system error with I Coyne
Discrepancies occurrences August I of a Horizon bug which left a branch I impact on branch accounts. Although I Supplemental
and December 2017 I £204.59 short after Horizon initially _ I it is possible that a subsequent Report 3.140 — 3.146
recorded the complete currency order I discrepancy between branch
but only actually processed one out of I accounting and POLSAP would PEAKs
two currencies reveal the problem, leading to a PC0261541
correction (e.g. see Peak PC0265443, I PC0261710
and Mr Coyne's para 3.146), I cannot I PC0265443
be certain of this.
The first Peak, cited in para 3.141,
contains a comment which confirms
that any issue with potential financial
impact was treated as high priority:
'SSC; please raise the priority of this
12
POL-BSFF-0104929_0011
POL00266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
PEAK. As a general rule of thumb,
any financial-related errors resulting
in losses should be at least C
priority.
15 Phantom Whilst no specific branch account The master Peak PC0065021 has PEAK: PC0065021,
Transactions PC0052025 August I discrepancies are noted, many events I status 'closed- no fault in product’. PC0052025,
2000, PC0065021 recorded in the PEAK PC0065021
April 2001 suggesting multiple ‘Phantom Throughout the master Peak there is KEL
Transactions’ at branch during the no suggestion of any bug in Horizon -
period of 14" April 2001 to 12" only hardware and environmental RColemanat 0H
November 2001. It is therefore problems were suspected, and finally (no —v
possible (with the unpredictable user error was suspected. There is no I ‘“isclosed)
nature of Phantom Transactions) that I pattern indicative of a software bug.
branch accounts could have been The Peak concludes: ‘Phantom Txns Se vtemental
impacted. have not been proven in mt
circumstances which preclude user Report 3.148 — 3.153
Observations recorded on 19" June error. In all cases where these have
2001 by Fujitsu’s Patrick Carroll “7 occurred a user error related cause
now have pressing evidence to can be attributed to the phenomenon.
suggest that unwanted peripheral 1 am therefore closing this call as no
input is occurring, the likely source I fault in product.’
being the screen... I have observed
system activity corresponding to Peak PC0052025 appears to have a
screen presses happening with no straightforward explanation, as being
correpsonding [sic] evidence of caused by user error.
either routine system activity or
human interference There is no evidence for bugs in
Horizon with impact on branch
accounts.
16 Reconciliation Incidents identified I PC0039832 —The bug/error/defect Peak PC0039832 does not relate to Example PEAKs
Issues
March Exampled
Incidents:
PC0039832 dated
2000 (reportedly
reported in this PEAK caused
discrepancies to be displayed to the
Subpostmaster that did not actually
appear in the accounts.
‘reconciliation’ in the sense of the
back-office process addressed
elsewhere in the expert reports. It
relates to a counter reconciliation
PC0039832,
PC0045847,
PC0075240,
13
POL-BSFF-0104929_0012
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
Relating to fixed Aug 2000), 3 report in the branch, so it does not go I PC0075415,
Horizon Issues 1, I x PEAKs dated PC0039832 details small to reconciliation as in Horizon issues I PC0049578,
4&5 2002, PC0204872 I discrepancies reported on Horizon Sand 15. ;
dated 2010, reconciliation report. The problem PC0236246,
PC0236246 dated with any discrepancy, however small I As it concerns an issue in reporting, PC0204872
2014 is that it may reduce the the software fault (which was fixed
Subpostmasters ability to resolve after 5 months) had no direct impact KEL DRowe304L
discrepancies of greater values on branch accounts. The only effect
because the net discrepancy does not I of an error in this report would be to (not formally
match any of the transactions on the _I mislead or confuse the Subpostmaster disclosed)
report. - probably leading him to check his
figures more carefully and costing Coyne
PC0049578 — Records that Horizon him some time. Supplemental
incorrectly counted the number of
cash a/c outlet files and transaction
outlet files. This would have
impacted the integrity of the
reconciliation checking within
Horizon and therefore may have
allowed branch accounts to have
suffered impact from TC’s being
issued by Post Office in error.
PC0045847 — reports message store
corruption that resulted in a branch
discrepancy of £4462.46. The PEAK
recording that this is a duplicate of an
earlier incident; “supposed to be fixed
in the near future“.
PC0236246 — reports of discrepancies
within Client Transaction Summary
files (CTS). Client Transaction
Summaries are totals derived from
The Peaks referred to in paras 3.158 -
3.162 relate to a cash rounding error
in the back-end TIP system, causing
discrepancies of Ip in certain back-
end reports. So, the bug being
discussed here is: (a) a back-end
reporting problem, with no direct
impact on branch accounts, and (b)
involves tiny financial discrepancies,
which would usually be dismissed as
human error.
The effort spent in chasing this issue
down illustrates how precisely
Horizon was expected to balance the
accounts.
In Peak PC0049578 there is a
software fault and the fix is to
‘Update TPSC260 to correctly count
Report 3.154 — 3.173
14
POL-BSFF-0104929_0013
POL00266866
POL00266866
Index
Bug/Error/Defect
Identified Year /
Year(s) in Effect
Coyne Opinion as to branch
account impact
Worden Opinion
Supporting
Evidence
the aggregation of all branch
accounts. Any discrepancies within
the CTS may indicate discrepancies.
at branch account level.
PC0204872 provides a specific
example of where CTS discrepancies
may relate directly to branch
accounts: “7th May 2010 - CTS was
greater than vendor figures by 84.86.
POL have suggested that this may
have been related to an event from
27th February for FAD 490519,
although we can find no BIMS record
of this from a Reconciliation
perspective.”
the number of files read.' Mr Coyne
concludes: 'The implications of this
might have affected reconciliation’. 1
agree that they might have done.
However, in my opinion the effect is
remote from branch accounts, and the
chances of causing a reconciliation
error (leading to an erroneous TC) are
slight - as a mis-count of the number:
of files (the fault) is not a financial
discrepancy.
Coyne supp paras 3.170- 3.174
concern errors in the Client
Transaction Summary (CTS) which,
as Mr Coyne states at 3.171, are
produced by the Automated Payments
System (APS). The APS High Level
Design document
(DES/APP/HLD0026.docx) states:
‘Following the delivery of the Client
Files, a Client Transmission
Summary is generated that contains
totals by product of all the
transactions delivered today for each
client. This program (APSC2083)
uses the raw AP transactions as the
prime source of information.’
From this, it is clear that the CTS file
has no role in reconciliation or TCs,
because it only contains totals by
product per day. From these totals, it
a5
POL-BSFF-0104929_0014
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
is not possible to locate a discrepancy
in an individual transaction, or to
relate it to any branch. The use of the
CTS file is explained in Peak
PC0236246 and has no connection to
branch accounts. Discrepancies in
individual transactions can only be
seen in the more detailed Client Files
delivered by APS.
17 Branch Customer I Exampled Incident I PC0156246 details a situation Coyne Paragraph 3.175 cites Peak PEAK PC0156246
Discrepancies March 2008 where the Subpostmaster declined I PC0156246, which describes a
a transaction but the Customer was I banking incident involving
(Horizon Issue 4) still debited by his bank leaving transaction recovery, as described in Coyne
the customer with a shortfall. The I te general recovery KEL acha959T I Supplemental
PEAK suggests the position with which has title 'HNGx banking Report 3.174 — 3.78
i reconciliation - state 4'.
regards to the Subpostmaster is
unclear: “So it is likely that the I There is no evidence in the Peak of
branch balanced but the any software fault in Horizon.
customer's account now needs
rectifying for the loss so lam The Peak says 'This transaction was
passing this call back with the in State 4 yesterday and call
note to MSU: that before this PC0156174 was raised for the
customer's a/c is rectified for his _ I investigation. The branch was
loss of £165.26 that POL contact _ I contacted, and the recovery messages
the PM at the branch to double were written’. ‘his shows that the
check that NO money did change incident was detected at the back
hands for certain, before finally office, rather than the branch.
ensuring that this financial
discrepancy is dealt with.”
18 Concurrent Exampled incident I Branch Account discrepancies In 1999 -2000, users were able to log I PEAKS
Logins PC0027581 9" July I resulted from a user in a branch in at two terminals at once, and PC0027581
16
POL-BSFF-0104929_0015
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
1999 — until at least I logging in on two different branch discrepancies could occur - PC0051327
2001
terminals.
The discrepancies would appear as a
receipts and payments mismatch.
The Riposte bug that appears to be
the cause of this issue appears to be
within Horizon from July 1999 and
was not fixed by July 2001. No fix
date noted.
manifesting themselves as a
receipts/payments mismatch. This.
had the potential to affect branch
accounts. The mismatch would bring
it to the attention of the
Subpostmaster, who would require it
to be investigated, except possibly in
the case of small mismatches, which
he might pass off as an error in the
branch (e.g. of counting stock).
In the first Peak PC0027581, cited at
3.180, Fujitsu believed it was a
problem with the underlying Riposte
software, and passed it to Escher. In
September 2000, the problem was
‘Now formally fixed in Build 223
update 19 which was released
overnight.’ However, the new release
from Escher did not, as it was
expected to, fix the problem. Escher
denied that is was a bug in Riposte,
but Fujitsu believed in July 2001 that
'This is clearly a bug in the Supplier's
code’.
Peak PC0051327 is another example
of concurrent logon with a different
cause.
In my opinion these faults had the
potential to produce discrepancies in
PC0051813 (classed
as duplicate of above
PEAK)
PC0051485 (classed
as duplicate of above
PEAK PC0051327)
Coyne
Supplemental
Report 3.179 — 3.183
17
POL-BSFF-0104929_0016
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
branch accounts, of small amounts,
for a short period of time.
19 Post & Go / TA Exampled Incidents I This problem impacted at least one The problem, as analysed by Ann PEAK: PC0220393,
discrepancies in 2012 branch account for 43 days and the Chambers (and cited by Mr Coyne at_ I PC0218702
POLSAP evidence of the discrepancy appeared I para 3.187) involves 2 tills at a PC0219432
repeatedly in a daily report to Post branch being deliberately not
(Horizon Issue 4) Office from Fujitsu, but the Peak associated with stock units, as a result
explains that the matter was not dealt _I of some previously understood
with in a timely manner and problem. The problem was visible in I Coyne
therefore evidence that might have the POLSAP discrepancies, so posed Supplemental
led to understanding the discrepancy
had already been purged from the
Wincor Nixdorf data which is only
stored for a relativity short period of
time.
no risk of any undetected effect on
branch accounts. It involved the
RDS/DEA countermeasure detecting
a potential problem.
The duration of the problem appears
from the Peak to have been from 29
August 2012 to 17 September 2012 -
about 19 days, with the final
comment from Ann Chambers 'We
strongly recommend that POL
monitor the SubfilesOnHold report
which is sent to them daily' This does
not imply to me that PO should have
been monitoring that report for that
purpose beforehand.
I therefore do not understand Mr
Coyne's observations in para 190,
which seem to imply that PO should
have been monitoring the report for
43 days - or that it impacted branch
accounts at all.
Report 3.185 — 3.190
18
POL-BSFF-0104929_0017
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
20 Recovery Failures I Exampled Incidents I PC0220532 — is a confusing PEAK Peak PC0220532 concerns an PEAKs:
(Horizon Issue 4) I PC0220532 dated _I and may not indicate a Horizon Subpostmaster who believed that a PC0220532,
5" September 2012, I bug/error or defect memory dump on one of her counters I PC0241242,
had caused her a loss of £300. Since I PC0197643
PC0197643 dated Peak PC0241242 records: “The all transaction data was held remotely
2010, problem is in transaction Recovery on the BRDB by that date (2012) this I KEL:
software which we are currently seems to be a misunderstanding by surs1034R,
P0241242 February I looking at” the Subpostmaster; the Peak records I acha959T
2015, the sequence of activities to try to
The peak refers toa KEL surs1034R I establish the actual cause of her
which records “Jt is not clear if the discrepancies. Coyne
failure was due to ADCScript failure Supplemental
or a bug in the counter code
software” either of which confirms a
Horizon bug/error/defect. The result
of the investigation appears to be that
a transaction needs to be deleted by
Fujitsu and that this is awaiting
authorisation by Post Office. This
suggests impact of Branch Account
certainly for a period of time until
deletion of the offending transaction.
PEAK PC0197643 refers to KEL
acha959T which is one of the most
referred to Horizon KEL’s when
looking in theat PEAKS.
This KEL documents the challenges
faced by a Subpostmaster when
initially Horizon fails and then the
recovery process is unsuccessful
leaving transactions in a state of
There was some implication of
hardware faults, with a replacement
of a base unit, but the Peak has no
evidence of sofiware faults in
Horizon.
The Peak also says ‘The PM also
stated that she was getting error
messages on the system before the
loss but did not write these error
messages down' so Fujitsu may have
been trying to unravel a confusing
situation.
Peak PC0241242 is a long Peak that
involves both transaction recovery
and hardware replacements, and
issues of authorisation. It is hard to
draw any simple conclusion from it.
Peak PC0197643 refers to the widely
used recovery KEL acha959T. Mr
Report 3.191 — 3.196
a9
POL-BSFF-0104929_0018
POL00266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
confusion (at least to the Coyne notes an uncertainty as to
Subpostmaster) as to whether whether money was handed to the
Horizon has completed the customer. This is a frequent
transaction and if cash should be uncertainty in recovery situations and
given to or taken from the customer is unremarkable. His comment in his
at the counter in the Branch following I next para ‘it is unclear...’ simply
the failure. follows from the limitations of
evidence available at this remove.
There is no evidence of any fault in
Horizon.
21 Transaction 2005-2010 Transaction Correction bugs/errors Peak PC0129587 involves a counter I PEAKs
Correction Issues and defects do not cause freezing during acceptance of a TC. PC0129587,
discrepancies with Branch Accounts I In my opinion this bug would result PCO130056,
(Horizon Issue 4 but do: in an inconvenience to the PC0120459,
& 15) a) Reduce the Subpostmaster’s Subpostmaster (inability to roll over I PCO118562,
ability to resolve any to the next TP) but a not result in I PCO114154,
. . . inaccurate processing of any TC, or PCO121331,
discrepancies Watch nisy have any cimpact on branch accounts, PCO130057,
already occurred. PC0129774,
b) Prevent Branches from “rolling I peak PC0120459, and others cited I PC0204350,
over” to the next trading period I from paras 3.201 - 3.203, show the PC025567.
(if not processed in some form same problem - freezing of the
on the Counter). counter while accepting TCs. Like
c) Provide the opportunity for the hain cori these do not impact Coyne a
a . ranch accounts. upplemental
Subpostmaster to incorrectly Report 3.197 — 3.210
accept an erroneous Transaction I paras 3,203- 3.210 relate to a Peak in
Correction due to previously which a Subpostmaster was trying to
accepted Transaction Corrections I understand TCs over an extended
being missing from reports. time period. In my opinion it is not
surprising that the Subpostmaster
would find this difficult, after even a
few days. There is no implication of
any fault in Horizon.
20
POL-BSFF-0104929_0019
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
22 Bugs/Errors Exampled Incidents I PC0098230 — Branch accounts would I The fault described in Peak PEAKs:
Defects 4 x PEAKs dated be affected by this bug which would I PC0053160, cited at para 3.212, PC0053160,
introduced by 2000, PC0098230 I cause a discrepancy when handling appears not to have affected branch PC0098230,
previously applied I dated 2004, cheques where the value of the accounts. PC0052776,
PEAK Fixes cheque would be doubled. Whilst the PC0049702
Subpostmaster was in fact processing I Paras 3.213 - 3.216 refer to Peak
Horizon Issue 4 the cheque in a different manner than I PC0098230. Here a fault would affect
and to an extent was recommended, the branch accounts when the user was
10) Subpostmaster had operated in the handling cheques ‘outside of process’
same way for the previous two years. I as noted by Mr Coyne at para 3.214.
In the Peak, Ann Chambers noted "J
PC0052776 & PC0049702 Report think the PM should not be declaring
small discrepancies in branch his 'rest home' cheques in this way". I Coyne
accounts. There is no impact on branch Supplemental
accounts if the Subpostmaster follows I Report 3.211 — 3.219
correct procedures.
Para 3.218 cites Peak PC0049702.
This describes a payments
discrepancy in a back-office report
TPSC252, which was an error of two
pence resulting from a sign error ina
figure of lp. Thus, its effect was
trivial, and in any case, it had no
direct effect on branch accounts.
There is no evidence of impact on
branch accounts.
23 Bureau de Change I 2005, 2006, 2010 PC0129767 — Horizon allowed the When analysing the first KEL (2005) I PEAKs
reversal of the same transaction twice I I noted that it concerned a user error, I PC0129767
(differs from Impacting branch accounts. which would be corrected at monthly I PC0151787
previous 2017 PC0137437 — User Error balancing; but that a very small error I PC0137437
Bureau entry) in the margin might not be corrected. I PC0200042
PC0200090
21
POL-BSFF-0104929_0020
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
KEL PC0151787 — Discrepancy of Analysing the second KEL (2010) I PC0200435
agnihovtriv245L (8 I £907.97 whilst reversing a currency _I noted: ‘Impact small until bug fixed - I PC0201340
further associated rounding errors 10° in exchange PC0209240
PEAKs date range rates.” PC0226573
2010 — 2018) PC0254447
PC0260834
KEL
AChambers2252R
Agnihotriv245L
RW 742
RW App D.4
24 Wrong branch November — The KEL explains that “the cash When analysing this KEL I noted PEAKs:
customer change I December 2005 amount entered is multiplied by the ‘Sounds like a genuine problem PC0129835,
displayed Qty and hence the new stack total is _ I which may have led to giving the PCO129811,
(reported as fixed I wrong”, this Horizon bug was due to I customer the wrong amount - i.e. not I PC0128728,
8" December 2005) I incorrect reference data and led to an I recoverable.’ PC0128264
incorrect amount of change being
displayed on the branch screen And ‘Peak: fixed by a ref data
leading to the operator to provide the I change. No record that any other RW 742
branch customer with the wrong branch was RW App D.4
amount of money thereby leaving a affected.”
discrepancy in Branch Accounts. It is KEL
possible that the amount of change AChambers4134R
shown on screen is more than the
actual money tendered by the
customer.
The PEAKS report that the following
Subpostmasters spotted the bug and
reported the errors in their branches.
22
POL-BSFF-0104929_0021
POL00266866
POL00266866
Index
Bug/Error/Defect
Identified Year /
Year(s) in Effect
Coyne Opinion as to branch
account impact
Worden Opinion
Supporting
Evidence
FAD 275207
FAD 173641
FAD 175504
25
Lyca top up
2010
PC0202925 reports that this defect is
caused by incorrect reference data
within Horizon.
PC0202894 explains that when
selling Lyca mobile phone top-up
cards, the transaction is recorded
within Horizon at the appropriate
value but the receipt which is
required by the customer to top up
their mobile phone displays a zero
value. The Fujitsu operator records;
“Can we find out if the customer has
had any more of this issue? The
offices are tending not to do the
transactions after the problem as they
know any issues with e-vouchers can
result in a loss to them, they tend to
try it twice and then leave it. I have
however sent details of 3 separate
office s that have had this issue.”
PC0203108 regarding FAD400422
The Fujitsu operators' words suggest
that the defect was impacting more
than a single branch.
When analysing this KEL I noted:
‘Possible impact on branch accounts,
as may cause a reconciliation error -
could result in TC, erroneously
accepted. Reference data issue, soon
fixed.’
PEAKs:
PC0202925,
PC0202894,
PC0203108
PC0203215
PC0203137
PC0203284
RW 742
RW App D.4
KEL ballantj020)
23
POL-BSFF-0104929_0022
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
26 TPSC250 report KEL The KEL AChambers253L explains I When analysing this KEL I noted Example PEAKs
AChambers253L the branch account impact when “Some possible financial impact, as it I PCO115804
raised February postage labels are printed in error isa PCO0117659
2005 last updated with a minus value. reconciliation failure — but sounds. PCO118350
April 2008 has 24 very small’. PCO118677
associated PEAK PCO115804 - FAD218227 PCO119978
records date range I PCO117659 - FAD17005 I now believe that as it was a back- PCO120063
2005 — 2009 PC0118350 - FAD003210 end reporting problem, the chances of I PC0122147
(majority of PC0118677 - FAD86104 impact on branch accounts are small. I PC0122304
incidents 2005). PC0119978 - FAD417207 PCO122354
PC0120063 - FAD 017005 PC0122357
PC0122147 - FADO10012 PC0122630
PC0122304 - FAD156946 PCO122631
PC0122354 - FAD166013 PCO122664
+15 others which reference PC0122766
AChambers253L PC0123056
PCO123058
Typically, the values are less than £2 PC0189625
which may mean that PCO156718
Subpostmasters are unlikely to spot
the reasons for such a discrepancy RW 742
and may write it off as human error, RW App D.5
which would be incorrect.
KEL
AChambers253L,
27 TPS 40 associated This Horizon bug does impact branch I My analysis of this KEL was: Example PEAKs
PEAKs date range I accounts. “Sounds like a back-end discrepancy I PC0157357
from 2006 — 2010 in TPS. Possible financial impact?’ PC0159273
approx 25. Are It appears at first pass to create a PC0196893
diagnosed with root I reconciliation error, but on more Fujitsu’s analysis of the KEL was ‘no I PC0174587
cause as detailed review has doubled both the I impact’. OCR 19774
‘Development — credit and debit side of the transaction OCR 18815
Code’.
24
POL-BSFF-0104929_0023
POLO0266866
POL00266866
Index I Bug/Error/Defect I Identified Year / Coyne Opinion as to branch Worden Opinion Supporting
Year(s) in Effect account impact Evidence
and therefore whilst there is an T include this for completeness, in RW App D.5
impact the net impact is zero. case Fujitsu’s evidence on this KEL
is not accepted. KEL ballantj2547K
PC0196893 & PC0174587 state:
“**This may also have caused a I now believe that as it was a back- Parker WS
receipts and payments error, can end reporting problem, the chances of
EDSC please confirm whether this is_ I impact on branch accounts are small.
a gain or loss at the counter and the
amount.**” Indicating that support
believed this error may have caused a
discrepancy in some instances.
28 Drop and Go July 2017 PC0260269 reports a branch account I I include this for completeness, in PEAK:
discrepancy caused by a Duplicate case Fujitsu’s evidence on this KEL PC0260269
£100 ‘drop &go’ transaction leaving I is not accepted.
a shortfall of £100. The transaction KEL carde235Q
reported a failure on several attempts _I My analysis of this KEL was
but then finally displayed a success. ‘Possible financial impact. Seems RW App D.5
The customer was credited with £100 I very visible on the counter. Script =
but the branch was debited with £200. I reference data - Parker WS
therefore fixed easily’
Fujitsu’s analysis of the KEL was
‘This would have caused a loss in the
branch accounts, although the issue
was identified by the Subpostmaster
and it would have been resolved by a
transaction correction’
29 Network Banking I Exampled Incidents I Horizon appears to mis-handle T have been trying to establish PEAK:
Bug identified: communications, leading to errors whether the Peak has any indication PC0109020
within network banking and in turn of a bug in Horizon. It is mainly PCO142872
KEL causing the potential for branch about a communication problem from
CHawkes1745L account discrepancies. BT, outside Horizon. However, it also I KEL:
raised 2004 last refers to a'CNIM own goal’ which I CHawkes1745L
updated May 2005 need to investigate further.
25
POL-BSFF-0104929_0024
POLO0266866
POL00266866
Index
Bug/Error/Defect
Identified Year /
Year(s) in Effect
Coyne Opinion as to branch
account impact
Worden Opinion
Supporting
Evidence
has 12 associated
PEAK records date
range 2004 — 2010.
PC0109020 dated “Spoken to the PM and she told me
October 2004 that, her customer complained about
PC0142872 dated money taken out of the bank, and she
2007 (no financial
impact recorded)
Horizon displays that Pensions
transaction are declined but payments
are taken from accounts.
had to pay £50 back to her customer.
She told me that she is £50 out of
pocket.”
Expert Agreements/Disagreements by Horizon Issue
For additional clarity, Horizon Issue 0 records areas of agreement in relation to generic points that both Experts agree that are global across several Horizon
issues. For example, support processes, Horizon architecture and documentation observations.
Horizon Issue 0 — Global Agreements
Index I Topic Agreed / Statement Coyne Refs Worden Refs
JC/ RW.
0.1 Horizon Agreed The experts’ descriptions of the Horizon architecture are consistent with Section 4 Sections 3, 4, 5
Architecture one another and can be taken together as an agreed description.
0.2 Horizon Agreed The experts’ descriptions of Horizon support processes are consistent with I 4.66 — 4.95 6.7 (332-352);
Support one another and can be taken together as an agreed high-level description. App C.7
0.3 KELs and Agreed KELs and Peaks together form a useful source of information about bugs in I S4.88(b);
PEAKs Horizon but are a limited window on what happened. It is sometimes $5.164
necessary to use evidence from both to try to understand, but even so they
are not a comprehensive picture. It is to be expected that both KELs and
Peaks are incomplete in various respects.
0.4 KELs and Agreed KELs are aimed to help provide useful guidance to helpdesks in supporting I $3.2, S3.15-18 I 348 — 350; 402;
PEAKS the Subpostmaster, and to the back-end support function. As such they 430- 434
often give information about the impact of a bug or user error and may also
give information about causes.
26
POL-BSFF-0104929_0025
POLO0266866
POL00266866
Index I Topic Agreed / Statement Coyne Refs Worden Refs
JC/ RW.
0.4a_ I KELs and RW KELs are written in shorthand, by people who know Horizon very well. 430.1
PEAKS
0.5 KELs and Agreed Peaks record a timeline of activities to fix a bug or a problem. They $3.3
PEAKS sometimes contain information not found in KELs about specific impact on
branches or root causes — what needs to be fixed. They are written, by
people who know Horizon very well. They do not contain design detail for
any change. They are generally about development activities and timeline
rather than about potential impact. Peaks typically stop when development
has done its job, so they are not likely to contain information about follow-
on activities, such as compensating branches for any losses.
0.6 Peaks Agreed Some Peaks record observations of financial impact
Horizon Issue 1 — To what extent was it possible or likely for bugs, errors or defects of the nature alleged at §§23 and 24 of the GPOC and referred
to in §§ 49 to 56 of the Generic Defence to have the potential to (a) cause apparent or alleged discrepancies or shortfalls relating to Subpostmasters’
branch accounts or transactions, or (b) undermine the reliability of Horizon accurately to process and to record transactions as alleged at §24.1
GPOc?
Index I Topic Agreed / JC I Statement Coyne Refs Worden Refs
J RW.
1. The extent Agreed We agree that bugs were possible, and the table above displays a number See above table I Summarise table
bugs were which in the opinion of either or both experts appeared to have impacted
possible or branch accounts.
likely
1.2 The extent Agreed Referring to the table of bugs above, the experts agree that the bugs in rows
bugs were 1, 2, 3, 10, 13, 14, 18, 23, 24, 25, 27 and 28 may have had financial impact
possible or on branch accounts. Other rows, the impact is not agreed between the
likely experts.
13 Extent Agreed Horizon has produced more than 3 million sets of monthly branch accounts. I Dr Worden’s 8.5
estimation is
agreed
1.4 Extent Agreed ‘There is no technical reason to assume that there is any correlation between I $5.330(b); 8.10
the likelihood of a bug’s occurrence and the value of its effect’ 85.438;
$5.439(b)
27
POL-BSFF-0104929_0026
POL00266866
POL00266866
Index I Topic Agreed / JC I Statement Coyne Refs Worden Refs
/RW.
1.4a_ I Extent Dr Worden Dr Worden has never made the assumption described in 1.4 above, nor has he 8.5, 8.7, 8.10
built it into any of his estimates
1.6 Bugs affecting I Agreed When Dr Worden makes a statement regarding what Post Office could have
branch done following the notification of a bug, error or defect causing a
accounts discrepancy to “correct accounts” or “issue a TC”, the experts agree that this
is what the process should be. Evidence has not been seen that this actually
happened in respect of the bugs/errors and defects identified.
1.6a I Bugs affecting I Dr Worden I With respect to what the correction processes should be, in agreement 1.6:
branch Since these were normal correction processes, Dr Worden would not expect
accounts the evidence that the process was carried out to have persisted to this day.
1.7 Bugs affecting I Agreed The term ‘Receipts/Payments Mismatch’ is commonly used within Horizon
branch to describe a symptom, which is evident to the Subpostmaster during his
accounts monthly balancing and should not arise, but which may arise from many
different causes.
A number of the distinct bugs that we have discovered caused a
‘Receipts/Payments Match’.
In this dispute the same term has been used to describe a specific bug which
caused a receipts/payments mismatch.
1.7a I Bugs affecting I RW In any case of a Receipts/payments mismatch. It is very obvious to the
branch Subpostmaster (almost like a hardware failure) and would be unlikely to be
accounts attributed to human error.
Therefore, it is very likely that in these cases, any discrepancy in branch
accounts would be corrected at no cost to the Subpostmaster.
1.8 Extent RW In order to address Horizon issue 1, it is necessary to define measures of the $5.24 - 5.25; 8.4; 8.5; 8.7
extent of bugs with possible impact on branch accounts. $5.208; S5.490;
$3.33; $3.37
1.9 Branch Agreed The experts have differing views on “branch impact”. Mr Coyne refers to
Account any discrepancy that caused a loss (or gain) within branch accounts that
Impact needed corrective action as an “impact to branch accounts”. Dr Worden only
considers an effect or impact on branch accounts where a discrepancy loss (or
gain) was not rectified by a correction such as a Transaction Correction.
28
POL-BSFF-0104929_0027
POL00266866
POL00266866
Index I Topic Agreed / JC I Statement Coyne Refs Worden Refs
/ RW.
1.10 I Corrections of I RW Dr Worden believes that transient inaccuracies in branch accounts, which
financial needed some form of correction, have arisen so frequently and from so many
impact of bugs causes that to list them is not useful; and that evidence of each correction
being carried out is unlikely to persist to this day.
1.11 I Corrections of I RW I would not expect to see such evidence after 15 years. I have measured the
financial error rate in TCs and found that the mean magnitude of the impact of
impact of bugs erroneous TCs on branch accounts is less than £2 per branch per month.
1.12. I KELs and JC PEAKS and KELs are Fujitsu recording tools and a discrepancy would only
Peaks appear in a PEAK or KELs if a Horizon system problem is suspected.
1.13 I KELs and JC Discrepancies caused by human errors should not appear in PEAKs and
Peaks KELS as these should be dealt with by the Subpostmaster or Post Office and
its helpdesk subcontractors in the earlier stages of the support process.
1.14 I KELs and RW Peaks and KELs are frequently about complex situations involving the
Peaks correction of human errors (or other adverse events such as hardware failures
and communication failures) and in these cases there is usually no
implication of any error in the Horizon software.
1.15 I Bugs affecting I Agreed The number of distinct bugs, for which the experts have seen strong evidence I $3.22 Bugs table above
branch of the bug causing a lasting discrepancy in branch accounts, is between 12
accounts and 29.
1.16 I Bugs affecting Of the bugs acknowledged by Post Office (‘acknowledged bugs’) it is Paras 3.21 — Consider KEL
branch JC observed that the Callendar Square/Falkirk and Suspense Account bug were I 3.146 Coyne dates and PO docs
accounts in operation for many years before Subpostmasters reported the issues that Supplemental for years in effect
led to their respective identification.
1.17 I Bugs affecting I JC Similarly, for those bugs not acknowledged by Post Office (e.g., Please review
branch Dalmellington) there is evidence that these also operated within Horizon for Godeseth WS
accounts several years before Subpostmaster reported error led to their identification.
1.18 I Bugs affecting I RW Any bug which, like the Dalmellington bug, would cause an error in $3.46 — $3.77; I $6.2 (S144 — 153)
branch remming in or remming out, is easily detected by Horizon as a discrepancy $4.49- $4.53
accounts between a rem in and a rem out. This leads to a TC which corrects any
discrepancy in branch accounts (as remming TCs do approximately 20,000
times per year).
1.19 I Bugs affecting I RW I have ‘engaged with the impact of the other bugs which can be identified $5.9, $5.307
branch
accounts
from the documents’.
29
POL-BSFF-0104929_0028
POL00266866
POL00266866
Index I Topic Agreed / JC I Statement Coyne Refs Worden Refs
/ RW.
Ihave surveyed large numbers of KELS and Peaks and have identified some
bugs in them with potential impact on branch accounts. I have analysed the
evidence which Mr Coyne considers indicate bugs with financial impact. The
latest results of that analysis are described in this joint statement.
1.20 I Bugs affecting I RW In his para 5.43 Mr Coyne has misunderstood my para 166. As the context $5.43 166, 167
branch makes clear, I was referring to a hypothetical bug.
accounts
1.21 I Bugs affecting I RW ‘if Dr Worden is suggesting ...’. 1am not. $5.284 Section 8.11
branch
accounts
1.22 I Bugs affecting I RW ‘I have analysed the evidence relating to bugs which reveals information $5.285; $5.291
branch about the system and the potential for other similar bugs to arise.’
accounts
Similar bugs which may arise is not a relevant question. Mr Coyne has hardly
at all analysed the potential of identified bugs to have lasting impact on
branch accounts, in the presence of countermeasures.
1.23 I Bugs affecting I RW ‘evidence to show that they were the cause’ [of discrepancies] $5.288
branch
accounts Mr Coyne has not presented the evidence or analysis
1.24 I Bugs affecting I RW This bug concerns an inaccuracy in the CTS report. From DES/APP/
branch DES/APP/HLD0026.doex: HLD0026
accounts
‘Following the delivery of the Client Files, a Client Transmission Summary is
generated that contains totals by product of all the transactions delivered
today for each client. This program (APSC2083) uses the raw AP
transactions as the prime source of information.’
The CTS report has no connection with individual transactions or branches.
Errors in the CTS report do not impact branch accounts.
1.25 I Bugs affecting I RW Many Peaks or KELs cited by Mr Coyne in section 3 of his supplemental Supplemental
branch report are about complex recovery situations, with no indication of any fault I report, sections
accounts in Horizon. Examples are: 3 and 5
30
POL-BSFF-0104929_0029
POLO0266866
POL00266866
Index
Topic
Agreed / JC
/ RW.
Statement
Coyne Refs
Worden Refs
PC0197643, PCO156246, PCO156246, acha959T, PC0220532, PC0198352,
PC0256566, PC0256502, 2,473 different associated PEAKs (cited in Coyne
Supp 3.94), PC0071836, PC0133822, PC0241242, PC0197643, PC0058435,
PCO197987.
1.26
Bugs affecting
branch
accounts
RW
Many Peaks or KELs cited by Mr Coyne are about bugs which only affect
reports and have no direct effect on branch accounts. In these cases, it is far
from obvious that there will be any effect on branch accounts. Examples are:
PC0039832, PC004432, MSCardifield2219S, PC0265443, PC0075415,
PC0049578, PC0236246, PC0204872, PC0129587, PC0049702, PC0143503,
PC0143504, PCO143511, PC0144386, MWright531P, PC0052575,
PC0052804, PC0039832, PC0075240, PC0077508, PC0075415, PC0049578,
PC0220393, PC0204350, PC0049702, PC0159445, PC0159702, PC0159759,
PC0057909.
Supplemental
report, sections
3 and 5
Bugs affecting
branch
accounts
RW
Some Peaks or KELs cited by Mr Coyne are about situations which stop the
Subpostmaster working, and there is no evidence of any effect on branch
accounts. In these situations, it seems highly likely that any effect on branch
accounts will be corrected by the countermeasures (e.g. those needed for
hardware failures). Examples are:
PC0053160, PCO129587, PC0120459, PCO120459, PCO130056, PC0121331,
PC0197592.
Supplemental
report, sections
3 and 5
1.28
Bugs affecting
branch
accounts
RW
Many Peaks or KELs cited by Mr Coyne are about remming errors, where the
normal process of remming TCs (or previously, error notices) would prevent
any lasting effect on branch accounts. Examples are:
PC0098230, PC0203085, acha4221Q, PC0195380, PC0196154, PCO195511,
PC0197032, PC0197753, PCO197838, PCO197873, PC0251952, PC0143435,
achaS08S, PC0143440, PC0143499, PC0143502, PC0143515, PC0143839,
PC0144937, PCO120937, GMaxwell3853P, PC0089918,
Supplemental
report, sections
3and5
Bugs affecting
branch
accounts
Agreed
Review of the PEAK records has highlighted that between Horizon inception
to present day, there are varying bugs/errors and defects that have been
operating for varying periods of time and sometimes, only appear to have
been discovered upon a the Subpostmaster report of error.
31
POL-BSFF-0104929_0030
POLO0266866
POL00266866
Index I Topic Agreed / JC I Statement Coyne Refs Worden Refs
/ RW.
1.30 I Bugs affecting I Agreed Review of Peaks and KELs shows that many adverse events, which may arise
branch from defects in Horizon or may not, can be detected by back end monitoring
accounts or reports, without any reporting from the branch. For certain adverse events
it is also often possible by back end monitoring to establish the branches
affected and any financial impact.
1.31 I Extent RW In section 8.7.8 of my report, at paragraph 742, I estimated the mean impact 8.7, 742
of a bug with financial impact on all branches. The table at paragraph 742
contained the 7 bugs which I then thought might impact branch accounts and
estimated the mean impact across those 7 bugs. My conservative estimate,
from the table, was £6000 (para 744), and my central estimate was £2000
(Para 745; changed to £1000 in my supplemental report). I explained at at
para 743 that these estimates were very approximate.
From the discussions with Mr Coyne leading to this joint memorandum, as
summarised in the table of bugs above, there are now 12 bugs which in my
opinion might have had impact on branch accounts. I have therefore re-
estimated the mean financial impact of a bug, using the larger sample of these
12 bugs, with the same method of estimation.
The result of this re-estimate is that the central estimate is again about £2000,
but the conservative estimate has increased from £6000 to £13,300. The
conservative estimate has increased mainly because of the inclusion of the
Data Tree Build bug, described in Mr Coyne’s supplemental report, which
had a large financial impact of about £105,000 (as in the table above). This
large figure now dominates the mean.
The central estimate, as I described at paragraph 745, includes my estimate of
the probability that branches were compensated for any discrepancy, so that
the Subpostmaster would suffer no loss. In my opinion, the data tree build
bug was very prominent (a small number of large losses), and there is a very
high likelihood that branches were compensated for it.
However, the issue of whether or not branches were compensated for a
particular bug is a factual issue, and I do not know what the court will find
32
POL-BSFF-0104929_0031
POLO0266866
POL00266866
Index
Topic
Agreed / JC
/ RW.
Statement
Coyne Refs
Worden Refs
for any specific bug. For my conservative estimate, therefore, I assume that
the branches were not compensated for any of these bugs — leading to a larger
total which favours the claimants. With that assumption, the data tree build
bug dominates the average of 12 bugs.
T have included a spreadsheet of this revised calculation, with an explanation
of it, as an annex to this joint statement. The calculation is not agreed
between the experts.
The conservative estimate of the mean impact of a bug has increased from
£6000 to £13800 — just over a factor 2. As a result, my estimate of the
maximum possible proportion of claimants’ claimed shortfalls which might
arise from bugs in Horizon has increased, from 0.181% to about 0.4%. The
maximum is still not sufficient to account for even a small part of the claimed
shortfalls.
1,32
Extent
RW
Claimants’ branches are, on average, smaller than the average branch across
the PO network (in terms of customer transactions per month)
8.5, S5.1
Extent
RW
In my opinion, there is no evidence or reason to suppose that a claimant’s
branch, in any given month, would be much more susceptible to bugs
affecting branch accounts, than other branches in the PO network.
$5.25
App F
Extent
RW
Mr Coyne has given no reason why my analysis of the financial impact of
bugs is ‘ultimately flawed’. I corrected the estimates of impact for many
effects, such as shortcomings in the process of creating KELs, archiving
KELs, sampling of KELs, or claimant branch sizes. Mr Coyne has given no
reason why claimant branches should be more prone to bugs, compared with
other branches.
My final estimate of 0.181% (the maximum proportion of claimants’
shortfalls caused by bugs, now altered to 0.4%) includes many conservative
assumptions, designed to favour the claimants. The effect of the conservative
assumptions is to increase the estimate by about a factor of 30, over an
estimate from my best assumptions.
$4.90, $5.23
8.7, S133
1.35
Extent
RW
‘further assumptions’
85.292, 294(a)
8.5
33
POL-BSFF-0104929_0032
POL00266866
POL00266866
Index
Topic
Agreed / JC
/ RW.
Statement
Coyne Refs
Worden Refs
The only further assumption used in section 8.5 of my report is that
claimants’ branches are not especially prone to bugs, more so than other
branches. Mr Coyne has given no evidence or analysis to question this
assumption (see above)
1.36
Extent
RW
“Claimants are more likely than non-claimants to make errors’
This was a conservative assumption, introduced to favour the claimants.
Bugs induced by human error are a second-order effect, and so have very
small impact.
$5.294(b) i
App 435
1.37
Extent
RW
‘many other factors’ can induce a bug.
Mr Coyne has not identified any factors which particularly impact claimants’
branches, more than other branches.
85.295
8.7
Extent
RW
‘many assumptions I do not agree with’
Mr Coyne has not given any detailed analysis to support his disagreements or
described what they are.
$5.311-315
8.7
139
Extent
RW
Mr Coyne’s first point in this paragraph is already agreed between the parties
and does not address the issue of extent.
Mr Coyne’s analysis of my section 8.7, where I derived the upper limit of
0.181% of claimants’ claimed shortfalls caused by bugs in Horizon,
concludes here at his para $5.315, without having defined any of the
assumptions he says he disagrees with. The conservative estimate of 0.181%
is now increased to 0.4%, for reasons described above.
85.315
8.7
1.40
Extent
RW
Mr Coyne does not define the assumptions he does not agree with.
$5.316-317
8.8 —8.9
1.41
Extent
{raindrops analogy]
Dr Worden’s raindrops analogy at para 804 was possibly ill-chosen.
Raindrops occur with uniform probability and high frequency. A better
analogy would have been lightning strikes — which occur with uniform
probability but low frequency. The observed distribution of lightning strikes
is not uniform. They are isolated and sporadic, but with uniform probability
per acre of field.
$5.320- 321;
$5.330(a)
804
34
POL-BSFF-0104929_0033
POL00266866
POL00266866
Index
Topic
Agreed / JC
/ RW.
Statement
Coyne Refs
Worden Refs
T agree with Mr Coyne’s para 5.321 — because bugs are more like lightning
strikes - but it does not affect Dr Worden’s analysis.
Extent
RW
‘Dr Worden’s graph at 813 would actually be consistent with the idea that
bugs were the primary cause of issues’
This is not correct, because the average tenure of a claimant was about 90
months. Therefore, to account for their losses, each claimant would have to
have suffered losses in several months. Their average loss per month (as in
the graph) would then cluster around the mean value of £360 per month. Mr
Coyne has confused individual loss events with the mean loss per month.
This was accounted for in my detailed statistical analysis - which showed that
the evidence is not consistent with bugs as the cause of the shortfalls.
$5.330(¢)
813
1.42a
Extent
RW
I agree that Mr Coyne’s alternative explanation of the increased rate of loss
per month for claimants with short tenures at his 5.336 is a possible
explanation.
85.336
820
1.43
Extent
RW
‘more claimants were reporting losses over a period of 10 years.’
Mr Coyne has mis-interpreted the graph at his figure 7. It has nothing to do
with reported losses, or bugs, or human errors. It shows only the numbers of
claimants who were in post for each year — as derived from their claims.
Therefore Mr. Coyne’s assertions at 336-338 are incorrect.
85.335 —
85.338
821
1.43a
Extent
RW
Lagree with Mr Coyne that any interpretation of the fluctuating graph at 821
which he refers to at 5.343 is not straightforward. It is not immediately
obvious what should be regarded as random fluctuations, and what has some
other cause.
85.343
821
1.44
Extent
RW
‘there is no technical reason to assume that bugs would have the same effect
in all cases.’
Mr Coyne is again confusing averages (which para 383 refers to) with
individual events.
$5.349(d)
App 383
35
POL-BSFF-0104929_0034
POL00266866
POL00266866
Index
Topic
Agreed / JC
/ RW.
Statement
Coyne Refs
Worden Refs
Extent
RW
‘A bug, error or defect could theoretically account for 100% of a claimant's
claimed monthly loss.’
This is possible. if I had made this assumption, the resulting upper limit
would have been lower than the 8% I derived.
$5.349(e)
‘App 384, 389
1.46
Extent
RW
‘there is no reason to assume that bugs (or even any given bug) will affect all
claimants equally’
Mr Coyne is again confusing averages (which 389 refers to) with individual
events. Clearly individual events may have large random fluctuations around
the average. This was accounted for in my calculations.
$5.349(f)
App 389
1.47
Extent
RW
‘Dr Worden assumed that losses from horizon bugs were never, or very
rarely, cancelled out by gains from human error’
If I were to relax this assumption, the resulting upper limit would have been
lower than the 8% I derived.
$5.349(g)
App 385
Extent
RW
‘Horizon was continuously updated over the course of many years’
This calculation was an average over all years, so fluctuations over years do
not affect it. I separately calculated rates of loss from bugs in 3-year periods.
$5.349(h)
App 387.5
Extent
RW
Dr Worden assumes that “good months” compensate for “bad months”, so
the amount of fluctuation between claimants is small. There is no technical
foundation for this assumption as bugs could vary wildly in their effect.
This is not a technical assumption about Horizon. It follows from elementary
statistics, that an average of many values (monthly losses) has a small
random fluctuation, even though the values themselves may have larger
fluctuations. This is known as the ‘law of averages’.
$5.349(i)
App 393
1.50
Extent
RW
Dr Worden assumes that the uncertainty caused by factors such as variation
in the size of branches is small. Dr Worden gives no basis for this
assumption.
At 401, I said I would investigate the effects of this assumption in my
supplemental report. I have now made this analysis, and the resulting upper
$5.349(1)
App 401
36
POL-BSFF-0104929_0035
POL00266866
POL00266866
Index I Topic Agreed / JC I Statement Coyne Refs Worden Refs
/ RW.
limit of 8% is unchanged. The description can be made available to the court
if required.
1.51 I Extent RW ‘it is very unlikely that an analysis which uses these assumptions as a basis 5.350 8.10, 8.7, $5.3
will result in an accurate conclusion’
Mr Coyne has given no valid reasons to question the conclusion. In any case,
the upper limit of 8% (derived from the claimants’ claims, in section 8.10) is
much weaker than the upper limit of 0.181% (now 0.4%) derived in section
8.7 and in section 5.3 of my supplemental report.
37
POL-BSFF-0104929_0036
POLO0266866
POL00266866
Horizon Issue 2 — Did the Horizon IT system itself alert Subpostmasters of such bugs, errors or defects described in (1) above and if so how?
Index Sub Topic Agreed or I Statement Coyne Refs Worden Refs
JC/RW.
2.1 Alert of bugs to Agreed Horizon did not, in general, alert Subpostmasters
Subpostmasters
to any significant bugs or other defects in the
system itself.
That said, the extent to which any IT system can
automatically alert its users to bugs within the
system itself is necessarily limited. Whilst
Horizon has automated checks, there are types of
bugs that would circumvent such checks.
38
POL-BSFF-0104929_0037
POLO0266866
POL00266866
Horizon Issue 9 - At all material times, what transaction data and reporting functions (if any) were available through Horizon to Subpostmasters
for: a. identifying apparent or alleged discrepancies and shortfalls and/or the causes of the same; and b. accessing and identifying transactions
recorded on Horizon?
Index
Sub Topic
Agreed or JC/
RW.
Statement
Coyne Refs
Worden Refs
9.1
Facilities for
Subpostmasters
Agreed
In the experts’ experience, any competent IT support operation is
grateful to its users, when they draw its attention to any problem
which can be fixed, to reduce the future costs of support.
$5.389
9.2
Facilities for
Subpostmasters
Agreed
The experts would not expect Subpostmasters to have detailed
knowledge of the system.
85.391
9.3
Facilities for
Subpostmasters
Agreed
The causes of some types of apparent or alleged discrepancies and
shortfalls may be identified from reports or transaction data available
to Subpostmasters. Other causes of apparent or alleged discrepancies
and shortfalls may be more difficult or impossible to identify from
reports or transaction data available to Subpostmasters, because of
their limited knowledge of the complex back-end systems.
Identification requires cooperation of Post Office staff and
Subpostmasters.
85.393
9.4
Human errors
RW
“most discrepancies are caused by human error’
Some classes of TC (e.g. remming TCs) arise almost entirely for the
correction of human errors. The number of such TCs (20,000 per
year) gives an indication (a lower limit) of the level of human errors.
In contrast, the experts have identified in total a far smaller number
of discrepancies caused by software errors — even when (as I have
done) they have tried to correct for the limitations of their sampling.
$5.396-397
958
9.5
Human errors
RW
‘Dr Worden’s analysis does not appear to account for issues caused
by 3rd parties’
This is not correct. For instance, my analysis of the level of
erroneous TCs includes TCs which were in error because of errors
by third parties such as Santander.
85.398
9.6, ST
39
POL-BSFF-0104929_0038
POLO0266866
POL00266866
Index
Sub Topic
Agreed or JC/
RW.
Statement
Coyne Refs
Worden Refs
9.6
Human errors
RW
Mr Coyne is referring here to remming errors, which are detected
automatically by Horizon and corrected by TCs. So, there is no need
for the Subpostmaster to ‘identifv the cause of that discrepancy’.
$5.399
$6.2
9.7
Support
knowledge
RW
I do not agree that support teams ‘still have access to the same
information as a Subpostmaster’. They do not know at first hand
what happened in the branch.
$5.402
9.8
Evidence
RW
There are gaps in the evidence of how those bugs acknowledged by
Post Office were handled.
The main sources of evidence including KELs and Peaks and
witness statements, are necessarily incomplete — especially at this
remove in time.
S5.408B
Horizon Issue 14 — How (if at all) does the Horizon system and its functionality:
a. enable Subpostmasters to compare the stock and cash in a branch against the stock and cash indicated on Horizon? b. enable or require
Subpostmasters to decide how to deal with, dispute, accept or make good an alleged discrepancy by (i) providing his or her own personal funds or
(ii) settling centrally? c. record and reflect the consequence of raising a dispute on an alleged discrepancy, on Horizon Branch account data and, in
particular: d. does raising a dispute with the Helpline cause a block to be placed on the value of an alleged shortfall; and e. is that recorded on the
Horizon system as a debt due to Post Office? f. enable Subpostmasters to produce (i) Cash Account before 2005 and (ii) Branch Trading Statement
after 2005? g. enable or require Subpostmasters to continue to trade if they did not complete a Branch Trading Statement; and, if so, on what basis
and with what consequences on the Horizon system?
Index Sub Topic Agreed or I Statement Coyne Refs Worden Refs
JC/ RW
14.1 Facilities for Agreed The descriptions by the experts of facilities 719 -7.38 Section 10.4
Subpostmasters available to the Subpostmasters are consistent (987 — 1009)
with one another and can be taken together as an
agreed description.
14.2 Stock on Hand Agreed Subpostmaster comparison of Cash and Stock in
branch and figures recorded within Horizon can
be determined by the Subpostmaster/Auditor
physically counting the cash and stock in branch
and inputting those values derived into Horizon
40
POL-BSFF-0104929_0039
POL00266866
POL00266866
Index Sub Topic Agreed or I Statement Coyne Refs Worden Refs
JC/ RW
for a comparison to be made against the
electronically derived figures held by Horizon.
14.3 Subpostmasters Agreed It is agreed that functionality enabling the
handling discrepancies
Subpostmasters to deal with, dispute, accept or
make good alleged discrepancies is as follows:
At the end of the Trading Period, Horizon reports
to the user the amount of any discrepancy. The
system invites the user to transfer this amount into
the local suspense account and continue to roll
over — or to discontinue this operation.
If, at the end of a Trading Period, there is a
discrepancy (i.e. either a surplus or a shortfall) of
less than £150, the Subpostmaster must 'make
good' the discrepancy — either by removing money
from the till (in the event of a surplus) or by
adding money to the till (in the event of a
shortfall). The ability to make good through
Horizon was also available before 2005 under
Cash Accounting. ‘Making good’ causes the
derived cash position to remain the same and the
actual cash position to change accordingly. The
next Trading Period can then begin with a
balanced account (both physical cash and
electronically recorded). If, at the end of a
Trading Period, a branch has a discrepancy of
more than £150, they have the option to either
make good or settle the discrepancy centrally.
The ability to ‘settle centrally’ was not available
under Cash Accounting. If the Subpostmaster
chooses to settle centrally, they do not have to
physically place cash in the till (in the case of a
shortfall) at the time. Instead, a message is sent to
Post Office's Finance Services Centre and the
41
POL-BSFF-0104929_0040
POL00266866
POL00266866
Index
Sub Topic
Agreed or
JC/ RW
Statement
Coyne Refs
Worden Refs
discrepancy is moved to a central account. A
Subpostmaster may wish to dispute a discrepancy.
This only appears to have been available post
2005.
The Subpostmaster cannot dispute a discrepancy
on Horizon or record that they have raised a
dispute. This is done through contacting the
helpline.
14.4
Trading
Agreed
The experts agree that no technical controls have
been identified within the disclosure that would
indicate Subpostmasters were prevented from
trading if they did not complete a Branch Trading
Statement.
14.5
Correction / Dispute
Process
Agreed
The experts agree that the Transaction Correction
Flow Chart 1 [A_19] and Flow Chart 2 Branch
Trading Statement [A_20] documents produced
for the Common Issues trial are reflective of their
understanding of the processes.
14.6
Discrepancies
Agreed
Horizon does not record disputes. It is Post
Office’s back office accounting facilities that
record disputes and make decisions upon
discrepancy investigations and the issuing of error
notices/TCs
[see 15.5 below for further]
14.7
Discrepancies /
Investigations
Jc
With the above in mind (14.4), Post Office’s
operational back office accounting processes and
their adequacy were crucial to ensuring branch
accounts were not adversely affected by
discrepancy or error arising from Horizon
generated events (i.c., bugs/errors/defects) or
manual error / lack of policy adherence in respect
of decision-making processes regarding
discrepancy disputes.
42
POL-BSFF-0104929_0041
Issue 15 — How did Horizon process and/or record Transaction Corrections?
POL00266866
POL00266866
Index
Sub Topic
Agreed or JC/
RW
Statement
Coyne Refs
Worden Refs
15.1
TCs Issued
Agreed
Transaction Corrections arise (in the majority of occasions) as a
result of a either POL or a Subpostmaster identifying an
imbalance/discrepancy.
Between the years of 2006 to 2017 TCs were applied more than
100,000 times each year.
928
15.1a
TCs Issued
JC
For the years 2005 and 2018 the figure was less than 100,000
928
15.1b
TCs Issued
RW
The smaller figures for 2005 and 2018 in the table at para 928
arose because they were part years. TCs started in 2005, and the
table only reflected part of 2018
928
Erroneous TCs
Agreed
The Transaction Correction process could lead to Transaction
Corrections being issued in error and when disputed, some TCs.
are corrected by issuing another TC (when disputes are upheld).
Smith 1% WS
TCs
Agreed
Post Office does not inspect Audit Data before issuing a TC. As
there are typically more than 100,000 TCs per annum, it would
incur additional cost and delay for Post Office to inspect audit data
before issuing any TC.
TCs
Agreed
When a TC is disputed, we would expect Post Office to
investigate/validate with more data sources than utilised in the
initial determination.
Errors in TCs
RW
Those TCs disputed and still wrongly issued (not upheld), are
probably fewer in number than those disputed and upheld -
because of the careful process of investigation.
Errors in TCs
RW
I have derived an upper limit on the financial impact of errors in
the TC process. The magnitude of the mean financial impact per
branch per month of erroneous TCs is less than £2.
$5.150
9.6, S7
15.7
Errors in TCs
RW
The reference to my para 993 should be to para 933.
“77% of 2,890 Transaction Correction disputes were upheld in
2016/2017 in relation to Santander Manual Deposits’
$5.357- 359
933
43
POL-BSFF-0104929_0042
POL00266866
POL00266866
Index
Sub Topic
Agreed or JC/
RW
Statement
Coyne Refs
Worden Refs
The figure of 77%, taken from Mr Smith’s witness statement, does
not support Mr Coyne’s conclusions up to his para $5.359. It only
shows that for the small proportion of Santander TCs that were
disputed, the resulting investigation found in favour of the
Subpostmaster rather than the PO client.
This does nothing to alter my conclusion in S7 that the losses to
claimants from erroneous TCs were very small, compared to their
claimed shortfalls.
15.8
Errors in TCs
RW
The figure of 77% shows that correction by PO of possible errors
by Santander was effective - the opposite of what Mr. Coyne
implies
$5.370
15.9
Errors in TCs
RW
Mr. Coyne has misunderstood. The examples at 924 and 925 were
hypothetical.
85.371
924, 925
15.10
Errors in TCs
RW
The assumption that Mr. Coyne disagrees with is addressed in my
supplemental report
$5.373
931, S App I1-
12
15.11
Errors in TCs
RW
The experts have still not achieved clarity on the 10,000
transactions per week’ referred to by Mr. Coyne. This amounts to
500,000 transactions per year, considerably larger than the number
of TCs per year.
85.377
15.12
Errors in TCs
RW
Mr Coyne’s comments at 377 and 378 do not alter my opinion that
the losses to claimants from erroneous TCs were very small,
compared to their claimed shortfalls.
$5.377 - 378
9.6, ST
15.13
Errors in TCs
RW
PC0129587 dated 1 December 2005 relates to Transaction
Corrections (TC) and issues with counter freezes during
acceptance of the Transaction Correction.
There is nothing in the Peak to indicate a fault in Horizon, or that
there would have been any inaccuracy ina resulting TC.
$3.198
Approved for service 25‘ February 2019
44
POL-BSFF-0104929_0043
POLO0266866
POL00266866
Dr Robert Worden
45
POL-BSFF-0104929_0044