Architektura

Britská pošta: Jak se ze zdvojeného zápisu stane tisíc odsouzených?

Účetní systém Horizon dvacet let ukazoval pobočkám manka, která tam nebyla. Pošta je po lidech vymáhala a sama je za ně trestně stíhala.

Michal Katuščák
Michal Katuščák
Navrhuji a vyvíjím aplikace nad Symfony a Reactem, zajímám se architekturu softwaru. Žiju v Českých Budějovicích.
24. srpna 2026 · 20 min čtení
// obsah 11
  1. 01 Co je Horizon a co se stalo?
  2. 02 Jaké to teda byly chyby?
  3. 03 Proč to ten poštmistr nemohl ustát?
  4. 04 Kdo mohl sáhnout do účtu pobočky?
  5. 05 A co na to smlouva?
  6. 06 Jak se z rozdílu v účtu stane obžaloba?
  7. 07 Co to stálo?
  8. 08 Věděli to?
  9. 09 Jak to vypadá dnes?
  10. 10 Co si z toho beru
  11. 11 Zdroje

Poštmistryně na skotské pobočce převedla 8 000 liber do výjezdní pobočky. Systém jí ukázal příjem 32 000 liber a manko 24 000 liber, protože ten převod zaúčtoval čtyřikrát. Měla obrovské štěstí, protože byla na obou koncích transakce a šlo to dohledat.

Ostatní takové štěstí neměli. Britská pošta provozuje pobočky přes poštmistry (anglicky subpostmasters), což jsou lidé někde mezi franšízantem a vedoucím pobočky. Od roku 2000 jim účetní systém Horizon ukazoval manka, která na pobočce reálně nebyla. Pošta je po nich vymáhala z jejich vlastních peněz, a když nezaplatili, sama je trestně stíhala. Vyšetřovací komise odhaduje, že takhle bylo stíháno a odsouzeno zhruba tisíc lidí.

Tohle je asi nejhorší softwarový průšvih, o jakém jsem kdy četl. Ke mně se to doneslo přes seriál Pan Bates versus Britská pošta (v originále Mr Bates vs The Post Office, na iVysílání už bohužel není) a říkal jsem si, že to bude taková ta obvyklá story „zlá korporace versus člověk“, kde technika je jenom kulisa. Jenže tady je technika gró problému.

Ty chyby v Horizonu byly přitom celkem obyčejné. Neuvolněný zámek, zdvojený zápis, zápis, co nedojel do backendu. Takové věci má v backlogu skoro každý. Do vězení ale ty chyby lidi samy neposlaly, poslalo je to, co bylo postavené kolem nich.

Co je Horizon a co se stalo?

Horizon je pokladní a účetní systém pro přepážky. Postavila ho britská ICL, kterou Fujitsu ovládalo už od roku 1990 a od roku 1998 vlastnilo celou. U Horizonu bylo Fujitsu od začátku.

Systémy jsou vlastně dva. Legacy Horizon (2000 až 2010) stál na middlewaru Riposte od firmy Escher: data pobočky žila na counteru a replikovala se na „correspondence servery“. Horizon Online přišel v roce 2010 s centrální databází a tenkým klientem na přepážce. Přechod na online verzi podle rozsudku funkčnost systému nijak podstatně nezlepšil. Vyměnila se architektura a chyby zůstaly, jen jiné. (Všechno, co je v článku dál, je o těchhle starých verzích, zhruba do roku 2017. Ta dnešní je podle obou soudních znalců relativně robustní a soudce výslovně varuje, že jeho zjištění na ni vztahovat nejde.)

Datum Co se dělo
1996 Pošta a úřad pro dávky zadávají obří PFI zakázku konsorciu kolem ICL, odhad zhruba miliarda liber
1999 Vláda ruší dávkovou část projektu; z toho, co zbylo, se stává Horizon
2000 Plošné nasazení; pobočky začínají hlásit nevysvětlitelné rozdíly
2000–2015 Působí chyby Callendar Square, Receipts and Payments Mismatch, Dalmellington a další
prosinec 2019 Rozsudek Horizon Issues: starý Horizon nebyl podle soudu ani vzdáleně robustní
duben 2021 Odvolací soud ruší 39 ze 42 odsouzení a stíhání označuje za zneužití soudního řízení
leden 2024 ITV vysílá seriál; o devět dní později vláda ohlašuje plošné zrušení odsouzení

Mezi prvními hlášeními problémů a rozsudkem, který dal poštmistrům za pravdu, je devatenáct let.

Jaké to teda byly chyby?

V soudním řízení vznikla společná tabulka znalců, tzv. Bug Table, a je v ní 29 položek. Aspoň u dvanácti z nich připustil i znalec pošty, že existuje důkaz, že trvale změnily účty poboček. Rozeberu tři hlavní.

Callendar Square (2000–2006). Zámek uvnitř Riposte, který se neuvolnil, takže zápisy pobočky se nedostaly tam, kam by měly, a v účtu vznikl rozdíl. Postihlo to 30 poboček a v 19 z nich to rozdíly v účtech opravdu udělalo. Podstatné je ale něco jiného: ta chyba byla v cizím produktu. Znalec pošty to použil jako obranu ve smyslu, že „to není naše chyba, to Escher“, a soudce ten argument odmítl jako irelevantní. Řešila se totiž funkčnost systému, ne to, kdo za chybu může.

Dalmellington (2010–2015). Tahle chyba je ta z úvodu. Skript pro přihlášení se korektně neuzavřel a zůstal na zásobníku nedokončených procesů. Skript pro příjem hotovosti na pobočce si kvůli tomu myslel, že sám ještě neskončil, a zopakoval svou poslední část, včetně zaúčtování převodu a tisku účtenky. Když to Fujitsu v roce 2015 začalo vyšetřovat, našlo 112 výskytů v 88 pobočkách za předchozích pět let. Svědek Fujitsu to u soudu shrnul takhle: kvůli té chybě to vypadalo, jako by uživatel prostě udělal něco vícekrát.

Receipts and Payments Mismatch (2010). Při závěrce a přechodu do nového účetního období (v systému rollover) systém našel rozdíl a zeptal se uživatele, jestli ho má přesunout do místního účtu. Když uživatel dal Cancel, rozdíl se na přepážce vynuloval. Jenže do backendu (systémy POLSAP a Credence) v tu chvíli nešlo nic, takže tam rozdíl zůstal. Když uživatel závěrku hned zopakoval, prošla bez rozdílu a pobočka byla přesvědčená, že má srovnáno.

Mřížka dvou drah a čtyř kroků rolloveru. Horní dráha je přepážka: rozdíl, vynulován, žádný, nakonec „srovnáno“. Dolní dráha je back-end: rozdíl, drží dál, drží dál, manko trvá. Mezi prvním a druhým krokem je svislá přerušovaná čára s popiskem, že tady se obě dráhy rozejdou

Zdroj: interní dokument pošty a Fujitsu citovaný v rozsudku Bates v Post Office (No. 6: Horizon Issues), odst. 428.

To by byl normální bug. A tady se to celé láme, protože o téhle chybě existuje interní dokument, který soud cituje doslova. Postižených bylo asi 40 poboček a šlo zhruba o 20 tisíc liber. A pak jsou tam tyhle body pod nadpisem Impact:

  • pobočka si myslí, že má srovnáno, přitom může mít ztrátu nebo zisk,
  • naše účetní systémy nebudou souhlasit s tím, co je zaznamenané na pobočce,
  • kdyby to bylo široce známé, mohlo by to způsobit ztrátu důvěry v Horizon,
  • mohlo by to pobočkám dát munici, aby z budoucích rozdílů vinily Horizon.

Jedna z variant řešení byla dopsat správnou hodnotu do účtu pobočky ručně a zamítla se s tím, že to má „significant data integrity concerns“. Vyhrála varianta vymáhat nebo vracet peníze běžným procesem, aniž by se pobočce řeklo proč. Soudce k tomu napsal, že je to nanejvýš znepokojivý dokument, a to je ještě slušně řečeno, si myslím.

Proč to ten poštmistr nemohl ustát?

Proč to prostě neodmítl podepsat a nešel domů? Protože bez uzavřené závěrky pobočka další den neotevřela. Přijmout to číslo byla podmínka provozu.

  • V Horizonu nešlo nic rozporovat. Znalci se shodli a svědek Fujitsu to u soudu potvrdil: tlačítko „nesouhlasím“ v systému není, a není tam záměrně, by design. Spor se dal vznést jedině telefonem na helpline, což je mimo systém, takže v datech po něm nezůstala stopa.
  • Systém zapisoval i čísla, o kterých obě strany věděly, že jsou špatně. Soud to říká takhle přímo.
  • Historii viděl poštmistr 42 dní, později 60. Šla vytisknout na účtenkovou roli. Svědek pošty u soudu názorně ukazoval velikostí soudní síně, jak dlouhá by ta role byla za jediný rušný den.
  • Kompletní audit existoval, ale ne pro něj. Fujitsu ukládalo úplný záznam včetně všech stisků kláves do takzvaného audit store, což je klasické WORM úložiště. Pošta se do těch dat před rozhodnutím o opravě účtu vůbec nepodívala, a i kdyby chtěla, musela by si o ně požádat Fujitsu, které za to mělo účtovat poplatky.
  • Diagnostiku uměl jenom dodavatel. Jestli rozdíl způsobila chyba systému, to poště mohlo říct jedině Fujitsu.

Ještě dvě čísla, která tu asymetrii dokreslují. Ručních oprav účtů (Transaction Corrections) posílala pošta pobočkám přes 100 000 ročně, tedy víc než 2 000 týdně. A ve vzorku, který soud zkoumal, se skoro každá čtvrtá oprava, kterou poštmistr rozporoval, ukázala jako chybně vystavená.

A pak je tu věc, která tu kauzu nejspíš protáhla na dvacet let. Ti lidé se neměli jak dozvědět jeden o druhém. Každý seděl na své pobočce, viděl svoje čísla a spor mohl vznést jedině telefonem. Kdyby ten nesouhlas šel zapsat do systému, byl by za pár let vidět jako vzorec. Takhle to bylo za dvacet let tisíc oddělených případů, u kterých je vždycky problém ten člověk u přepážky.

Kdo mohl sáhnout do účtu pobočky?

Pošta roky veřejně tvrdila, že do účtů poboček nikdo zvenčí sáhnout nemůže. Bývalý zaměstnanec Fujitsu Richard Roll tvrdil opak a nikdo mu nevěřil. U soudu to svědci Fujitsu nakonec potvrdili.

Soud položil otázku: mohlo Fujitsu v účtech poboček vkládat, upravovat nebo mazat data (a) vůbec, (b) bez vědomí poštmistra a (c) bez jeho souhlasu? Tři typy operací krát tři podmínky je devět otázek a odpověď je devětkrát ano. Nástrojů na to bylo víc, od širokých rolí až po nástroj, který uměl vložit transakci přímo do účtu pobočky. Nejhorší detail je ale to, že vložená transakce vypadala, jako by ji zadal sám poštmistr.

A logy? Před rokem 2009 žádné logy přístupů neexistovaly. Od roku 2009 do července 2015 se logovalo jenom přihlášení a odhlášení, ne co ten člověk dělal. A i po červenci 2015 se oba znalci shodli, že ty logy nejsou použitelný zdroj informací o vzdálených zásazích. Práva k přidání/úpravě/mazání transakcí mělo přitom roky celé oddělení podpory. Znalec žalobců zjistil, že se ta práva použila 2 175krát mezi lety 2009 a 2019, což vychází skoro na každý pracovní den, a přesněji to spočítat nešlo, protože záznamy Fujitsu na to nestačily.

Uprostřed je účet pobočky, do kterého vedou tři šipky zápisu: shora od pošty s ručními opravami, zleva silná od Fujitsu, zprava od poštmistra. Zpátky od poštmistra vede spodem přerušovaná cesta označená jako nesouhlas, kterou přerušuje křížek, protože do účtu nikdy nedojde

Zdroj: rozsudek Bates v Post Office (No. 6: Horizon Issues), odpovědi na Horizon Issues 7 až 13.

Když se na to podívám jako na návrh systému, vyjde z toho, že ten, kdo nesl finanční i trestní odpovědnost (poštmistr), měl nejmíň dat, žádnou možnost zapsat nesouhlas a vůbec neviděl, kdo mu do účtu sáhl. A kdo měl plná práva na zápis do produkčních dat, o svých zásazích nevedl použitelné záznamy.

A co na to smlouva?

Všechno předchozí byla technika. Druhá vrstva odpovědi je v rozsudku Common Issues z března 2019, kde stejný soudce řešil samotné smlouvy mezi poštou a poštmistry. Pošta svou vlastní smlouvu vykládala tak, že poštmistr odpovídá za všechna manka a je na něm, aby se z toho vyvinil. Soudce ten výklad odmítl: ta klauzule vyžaduje zavinění a prokázat ho musí pošta.

Čili to břemeno, které poštmistři dvacet let nesli, jim smlouva nikdy neuložila. Uložily jim ho dopisy, kterými pošta manka vymáhala. O nich napsal soudce tohle: pro instituci jako pošta není omluva, aby v dopisech s hrozbou žaloby takhle výslovně zkreslovala rozsah smluvní povinnosti, a jediný důvod k tomu musel být ten, aby příjemce uvěřil, že mu nezbývá než zaplatit. To je šikana.

Pošta přitom ve svědeckých výpovědích důsledně psala, že poštmistři ta čísla „chose to accept“, tedy že se rozhodli je přijmout. Soudce k tomu uvádí, že to není pravdivý popis, protože na výběr neměli. Jediná volba, kterou skutečně měli, byla zaplatit hned, nebo si vyjednat splátky.

Software, vzdálený zápis, smlouva: nic z toho samo o sobě nikoho neodsoudí.

Jak se z rozdílu v účtu stane obžaloba?

V Anglii a Walesu může trestní stíhání vést i soukromý subjekt. Pošta toho využívala systematicky. Nedala podnět policii, ona sama byla žalobcem. Kvůli tomuhle bych ten článek napsal, i kdyby v něm nic jiného nebylo. Odvolací soud v dubnu 2021:

Tím, že pošta prezentovala Horizon jako spolehlivý a odmítala připustit jakýkoli jiný názor, fakticky obrátila důkazní břemeno: zacházela s rozdílem, který vypsal nespolehlivý účetní systém, jako s nezpochybnitelnou ztrátou, a postupovala, jako by bylo na obviněném, aby prokázal, že žádná taková ztráta nenastala. A protože obvinění nedostali materiály, kterými se dala obžaloba zpochybnit, nemohli tomuhle nepatřičnému břemenu dostát. S každým dalším úspěšně dokončeným stíháním se pak tvrzená spolehlivost Horizonu navenek dál potvrzovala.

Ta poslední věta je ukázková smyčka zpětné vazby. Každé odsouzení sloužilo jako důkaz, že systém funguje, a čím víc lidí bylo odsouzeno, tím pevnější to tvrzení bylo.

Zaujalo mě ještě něco. Do roku 2000 musela obžaloba v Anglii a Walesu prokázat, že počítač v rozhodné době fungoval správně, jinak jeho výstup nešel použít jako důkaz. Law Commission v roce 1997 usoudila, že ten paragraf neplní žádný užitečný účel, a zrušil se.

Zůstala obecná domněnka, že přístroj fungoval správně, dokud někdo neprokáže opak. V praxi to znamená, že vyvrátit spolehlivost systému měl ten, kdo do něj neviděl a neměl ani přístup k záznamům chyb. A ty záznamy obhajobě prostě nikdo nedal: odvolací soud píše, že pokud je mu známo, nebyl ve stíháních těch 42 lidí vydán ani jeden takový dokument.

Co to stálo?

Odsouzených bylo zhruba tisíc a přesné číslo se podle komise určit nedá. Poškozených je ale mnohem víc, protože většina lidí, kterým Horizon vyrobil manko, nikdy stíhaná nebyla. Ti jenom zaplatili.

Hromadná žaloba skončila v prosinci 2019 smírem na 57,75 milionu liber. Jenže náklady řízení byly kolem 46 milionů, takže na 555 žalobců zbylo dohromady zhruba 12 milionů, v průměru okolo dvaceti tisíc liber na osobu. Za dvacet let života, u některých za vězení a bankrot. Pak přišel seriál, zákon a státní odškodňovací schémata. Ke konci června 2026 bylo vyplaceno 1,628 miliardy liber více než 12 900 lidem.

Dva vodorovné pruhy ve skutečném poměru. Smír z roku 2019 pro 555 žalobců je tenká čárka odpovídající 12 milionům liber, odškodňovací schémata k červnu 2026 pro více než 12 900 lidí zabírají celou šířku a odpovídají 1 628 milionům liber. Poměr je zhruba jedna ku sto třiceti pěti

Zdroj: Department for Business and Trade, Post Office Horizon financial redress data k 26. 6. 2026; údaje o smíru z roku 2019 podle Law Gazette a Computer Weekly.

Mezi tím prvním pruhem a tím druhým se nestala žádná nová skutečnost. Soudy rozhodly už v letech 2019 a 2021. Změnilo se jenom to, kdo platí.

Fujitsu na tom odškodnění k březnu 2026 nezaplatilo ani penci. Veřejně uznává morální závazek a čeká, až komise dokončí zprávu. Celkem si přitom na Horizonu za víc než pětadvacet let vydělalo přes 2,5 miliardy liber.

A pak je tu cena, která se v librách vyčíslit nedá. Pošta na výzvu komise jmenovala třináct bývalých poštmistrů, o kterých jejich rodiny tvrdí, že si kvůli Horizonu vzali život. Nejméně 59 dalších uvedlo, že o sebevraždě uvažovali, deset z nich se o ni pokusilo. Předseda komise píše, že příčinnou souvislost u všech třinácti potvrdit nemůže, ale nevylučuje ji, a že skutečné číslo může být vyšší.

Věděli to?

Vraťme se k té věci, že obhajobě nebyl ve stíháních těch 42 lidí vydán jediný dokument o chybách Horizonu. Někdo ty dokumenty držel a věděl, co v nich je. Je to nepříjemná otázka a já na ni odpovídat nechci, protože policie pořád vyšetřuje a nikdo nebyl obviněný. Ale dva dokumenty mluví samy za sebe.

První je interní zpráva pošty ze srpna 2010, kde se řeší, jestli si objednat nezávislý přezkum Horizonu. Autor v ní varuje, že jakékoli šetření by se muselo vydat soudu, a pokračuje: kdyby vzniklo sebemenší zdání, že pošta pochybuje o vlastních systémech, musela by se všechna trestní stíhání zastavit, a otevřelo by to otázku minulých stíhání a uvěznění u odvolacího soudu. Přezkum si pošta objednala až v roce 2012 a došel k tomu, že Horizon může být z pohledu uživatele systémově vadný.

Druhý dokument se týká chyby Receipts and Payments Mismatch. Je datovaný 29. září 2010 a plán nasazení opravy počítal s dokončením k 21. říjnu 2010.

  1. října 2010 byla odsouzena Seema Misra za krádež 74 609,84 libry. Dostala 15 měsíců vězení. Znalcem obžaloby v jejím procesu byl inženýr Fujitsu, který vyloučil, že by za manko mohla chyba systému. Toho inženýra od listopadu 2020 vyšetřuje londýnská policie pro podezření z křivé výpovědi a zatím nebyl obviněn.

Jak to vypadá dnes?

Horizon pořád běží.

Nahradit ho vlastním vývojem se poště nepovedlo, vládní hodnotitelé ten projekt označili za neproveditelný a zrušil se. V květnu 2026 to zadala ven: provoz převezme Accenture, nový software má dodat One View Commerce. Druhá smlouva ale pořád není podepsaná, protože zadání napadl neúspěšný uchazeč. Je to firma Escher, tedy ta, jejíž middleware Riposte běžel v původní verzi Horizonu a v něm ten neuvolněný zámek. (Kdo za tu chybu může, soud nikdy neřešil a Escher nebyl účastníkem řízení.)

Ten samý Escher přitom dostal od pošty v srpnu 2026 jinou zakázku za 14,4 milionu liber, bez soutěže. Odůvodnění stojí za přečtení: Escher poště písemně potvrdil, že ke svému kódu nedá přístup žádnému jinému dodavateli, a pošta si sama otestovala a zaprotokolovala, že cesta přes třetí stranu neexistuje. Je to ten samý vzorec, na kterém Horizon ztroskotal. Tenkrát uměl diagnostiku jenom dodavatel, teď jenom dodavatel rozhoduje i o tom, co se s tím produktem dá dělat dál. O pětadvacet let později a tentokrát černé na bílém v úředním dokumentu.

Takže šestadvacet let po nasazení a skoro sedm let po rozsudku: Horizon pořád běží, pět ze šesti svazků zprávy komise (mezi nimi ten o technice a o stíháních) není venku, obžaloby nepadly a smlouva na náhradu není podepsaná. Odškodňování je jediná část, která se hnula, a tam to trvalo taky.

Co si z toho beru

U Lidlu a SAPu byla pointa v tom, že ohýbat zavedený systém je drahý špás, u Birminghamu a Oracle v tom, že kontrolní mechanismy svítily zeleně, dokud to nespadlo, a u digitalizace stavebního řízení architektura držela a selhalo všechno okolo ní. Tady je to horší, protože nejde o peníze.

Slovo „robustní“ používala pošta roky a nikdy za ním nebylo měření. U soudu se ukázalo, že se na jeho definici strany neumí shodnout, a tu definici nakonec musel napsat sám soudce. Kdykoli mi někdo řekne, že systém je stabilní a nejsou v něm žádné chyby, říkám si, jak to ví. Většinou se totiž ukáže, že to ví jen z toho, že si nikdo nestěžoval.

Pokud si z toho něco odnáším, tak to, že se na spolehlivost systémů, co programuju, dívám trochu kritičtěji.

Zdroje

Michal Katuščák
Michal Katuščák

Navrhuji a vyvíjím aplikace nad Symfony a Reactem, zajímám se architekturu softwaru. Žiju v Českých Budějovicích.

Spolupracujme
// pokračovat

Co byste mohli číst dál

Všechny články →
Architektura 16. srpna 2026

Kdy je CQRS v PHP overkill? 3 signály, že si komplikujete život

CQRS je jen rozdělení jednoho objektu na dva. Složité je všechno, co si k němu lidi přibalí, aniž by to potřebovali. Tři signály, že platíte režii, ze které nic nemáte.

11 min čtení číst
Architektura 13. srpna 2026

Haribo, SAP a zmizelí medvídci

Legenda říká, že SAP připravil Německo o gumové medvídky. Zdroje říkají něco jiného. Co se u Haribo doopravdy rozbilo a proč to bolelo i bez customizace.

15 min čtení číst