EU sues IBM, Atos and Leonardo: contract lessons for NZ projects

What happened

The European Union's IT agency is suing IBM, Atos and Leonardo over the delays to the Entry/Exit System (EES), Europe's biometric border control platform. The Financial Times broke the story on 9 November, and iTnews reported the FT's account that the consortium "repeatedly missed deadlines and disputed the agency's warnings and fines." The claim was filed in December 2025 in the Harju County Court in Estonia, where the agency eu-LISA is based. The filing only became public through eu-LISA's annual accounts and the FT's reporting. The Next Web says a court spokesperson has confirmed the filing, and no hearings have been held or scheduled yet.

The project's numbers explain why the case reached court. According to The Next Web, the 2019 contract for the core infrastructure was worth €142m, and its value had climbed to €212m by 2021. The system was due to launch in 2022. Atos Belgium and IBM Belgium contested a fine in October 2021 and blamed external factors including Covid-19. The EES rollout finally began on 12 October 2025 and reached full implementation on 10 April 2026. The original contract expired in 2025 and a new group of suppliers took over, although eu-LISA says the three defendants stayed responsible for the project until August 2026. Leonardo and Atos declined to comment to the FT, and IBM didn't respond. The amount eu-LISA is claiming hasn't been published.

Why a European border system matters to a Kiwi business

Most NZ organisations will never sign a €200m contract. The EES case still shows how large technology programmes tend to fail, and the same pattern turns up in an ERP replacement for a 200-person distributor or a council's move off a decades-old system. The deadline slips, the supplier points to outside causes, the contract value goes up partway through, the client issues fines the supplier disputes, and the disagreement runs for years after the system goes live.

Two details in the reporting deserve attention. The contract value rose by about half within two years of the award, and the system arrived roughly four years late. eu-LISA could issue fines because its contract had enforceable deadlines with penalties attached. Even with those terms, the agency ended up in a lawsuit that will be heard years after the work was meant to be finished. Penalty clauses give a client some leverage. They don't make a supplier deliver on time, and they don't make up for the operational cost of running the old process for an extra four years.

The handover also needs a look. A new consortium took over when the original contract expired, yet the incumbents stayed responsible until August 2026, which suggests an overlap of several months. For a mid-sized NZ firm, changing implementation partners partway through a project is where knowledge, documentation and accountability most often get lost. If a contract has no clear transition obligations, the client ends up paying twice for the same discovery work.

eu-LISA's own statement is worth reading as well. The agency told the FT the dispute had "no impact on the functioning" of the live system. Keeping the legal fight separate from operations is good practice, and it only works if the client controls its environments, data and documentation well enough to run the system without the supplier under dispute.

What NZ organisations can take from the case

Many NZ firms are working through overdue replacements of finance, CRM and operational systems. Recent local examples show how much technical debt builds up. Tasman District Council replaced a 35-year-old bespoke CRM as part of a multi-year programme. The council and its testing partner made a point of keeping the automated test capability in-house after the project ended. The EES dispute is a reminder of why that matters: whatever capability a client keeps is capability that can't be held up in a disagreement with a supplier.

Smaller organisations sign their contracts with less legal support than a European agency has, so the terms need to be right from the outset. Off-the-shelf statements of work from integrators usually describe effort and roles. They often say much less about what gets accepted, by when, and what happens when a date slips. Those gaps cost very little at signing and can cost a great deal two years later.

The EES case also shows how blame gets argued in practice. The consortium cited Covid-19 when it challenged the 2021 fine. Outside events do affect delivery, and a contract should say ahead of time how relief for those events is claimed and assessed. If the contract is silent, every missed date becomes an argument about causes, and the client loses months that should have gone into fixing the plan.

Practical next steps

Before your next platform replacement or major upgrade goes to contract, we'd suggest working through the following:

• Tie payments to accepted deliverables. Pay against working outputs that meet written acceptance criteria. Calendar dates and hours burned are weak triggers. Agree in advance who signs off and how long sign-off can take.
• Write down how variations work. Cap the total value of variations, or require board-level approval once they pass a set percentage of the original price. The EES contract grew from €142m to €212m within two years, and growth on that scale needs a visible decision point.
• Define relief events and how they're claimed. List the outside events that can justify a delay, the notice period for raising one, and the evidence the supplier has to provide. Disputes over a pandemic, a vendor licence change or a dependency on a third party then follow an agreed process.
• Set transition and exit obligations. Require an incoming partner handover, an agreed overlap period, and delivery of documentation, configuration and code in usable form. Make sure you own your test suites and environment access throughout.
• Track schedule risk monthly at governance level. If a key milestone slips by more than a set threshold, escalate it straight away and don't wait for the next phase gate. Projects rarely go four years late in one step.
• Keep operations separate from the commercial relationship. Make sure your team can run, support and patch the live system even while a dispute with the original builder is under way.

None of these steps needs a large legal budget. They need someone on the client side who reads the statement of work closely and asks how each clause would play out on a bad day. Our digital transformation team helps NZ and Australian organisations set up programmes along these lines. For finance and operations platforms, our ERP practice works through the same questions when choosing a system and an implementation partner.

The Harju County Court hasn't scheduled a hearing, so the claim amount and each side's arguments could stay private for a while. What's already on the record shows how a client's governance can go wrong on a large project long before anyone files a claim.