On July 22, 2026, the District Court of The Hague ruled in a major dispute between HTM and Siemens Mobility. Under an agreement concluded in 2011, Siemens had ultimately delivered 70 trams to HTM. Years later, a dispute arose concerning, among other things, the classification of malfunctions, the penalties owed for them, and delays in repairing corrosion. For the IT contract practice, what is particularly interesting is why the parties ended up in conflict.
Unclear Definitions of KPIs and SLAs
The agreement defined three types of malfunctions:
- A-malfunction: “vehicle no longer drivable”;
- B-failure: “vehicle drivable until the end of the trip or the end of the shift with passengers”;
- C-malfunction: “vehicle to be repaired in the workshop after the shift.”
Different contractual penalties were attached to these categories. The problem: the parties turned out to have fundamentally different interpretations of exactly what those definitions meant. HTM emphasized the vehicle’s availability for transporting passengers. Siemens took a more technical approach and focused on technical malfunctions occurring during a trip.
The parallel with SLAs
Anyone who drafts IT contracts will recognize this immediately. Consider an SLA that states: “P1 Critical Incident: system unavailable.”
That seems clear—until an incident actually occurs. Is an application “unavailable” if users can still log in but the checkout function isn’t working? If a single business-critical process is down? If a workaround exists? Or only in the event of a complete technical failure? That’s virtually the same discussion as “car no longer drivable.”
The important lesson, therefore, is that an SLA must not only define which categories of incidents exist, but also:
- From which perspective severity is determined;
- Which functionality is relevant;
- What the measurement point is;
- Which exceptions apply;
- Which operational consequences lead to which classification.
The difference between technical availability and operational availability deserves special attention in this context.
A technical document does not automatically amend an IT agreement
A second interesting issue concerned a later “Design Freeze” document.
Siemens argued that this document had replaced the original definitions of malfunctions in 2014. The court did not agree. According to the court, the signing of the Design Freeze did not indicate that the parties had reached a consensus on new definitions of malfunctions. The original definitions therefore remained in effect. However, the subsequent Recovery Concept could be used in interpreting them.
Another striking parallel with IT
In IT projects, the contractual reality rarely consists of a single document. For example, there are:
- The master agreement;
- A statement of work;
- Requirements;
- Functional and technical designs;
- Backlog items;
- Change requests;
- Acceptance documentation;
- Steering committee reports;
- Emails;
- A solution design.
Over time, the actual solution may deviate further and further from what was originally contracted. However, a modified design does not automatically mean that the contractual obligation has also changed. That distinction is essential. A solution design can serve as excellent evidence of how the parties understood a requirement. However, this does not necessarily mean that the parties have also legally modified that original requirement.
Practical Tip
Therefore, explicitly state which documents can actually amend the agreement. For example, by stipulating that a change only has contractual effect once it has been approved by authorized representatives of both parties in accordance with an agreed-upon change procedure. Otherwise, years later, the same question that arose here will surface:“Did we amend the contract, or did we merely provide further details on how the contract is to be executed?”
Contract documents must be read in context
In this case, the definitions in the SLA for the various priorities were strikingly brief. For example, one term was defined as:“A-malfunction: vehicle no longer drivable.” The court was therefore required to further clarify this term.
In doing so, the court does not consider a single definition or document in isolation. It takes various contractual documents into account in its interpretation and ultimately even aligns with external VDV definitions. A contributing factor here is that the original definitions were very brief. The shift from brief definitions to an external document seems striking at first glance, especially now that the court itself has determined that tender documents must be read literally and contra preferentem. What appears to be a factor here, however, is that it seems to follow from other documents that the (admittedly very) concise definitions appear to have drawn their inspiration from those external VDD definitions. The Salvage Concept, later drafted by Siemens, also plays a role, as the definitions used therein align with the interpretation chosen by the court.
This serves as a warning for IT contracts against blindly copying definitions, KPIs, and requirements into various appendices. Terms such as “Availability,” “Incident,” “Defect,” “Severity 1,” or “Acceptance Criterion” can easily appear in five different documents, sometimes worded slightly differently. The longer a project lasts, the greater the risk that these documents will each tell a plausible story on their own, but together no longer form an unambiguous contract.
This also means that a ranking or hierarchy provision is certainly not just empty “boilerplate” text. When it comes down to it, a ranking can be decisive. Still, I would ultimately prefer not to “gamble” on a technical provision like a boilerplate clause, but rather ensure that the entire set of documents is unambiguous and complete.
Vague SLA? The court can help
As discussed above, the court ultimately provided an interpretation of several key terms from the SLA in this case.
From a legal-technical perspective, it is interesting that this interpretation was ultimately granted as a declaratory judgment. Siemens had argued that such a declaratory judgment would not be permissible, because the court would thereby be rewriting the agreement. The court expressly rejected that defense. The court grants the requested declaratory judgment and thereby establishes, in a binding manner, how the SLA definitions are now to be interpreted.
To the best of my knowledge, it is very rare for an SLA to be interpreted in this manner. The timeframes involved in a full-fledged lawsuit are simply too long for that. Nevertheless, the relatively short procedure under Article 96 of the Dutch Code of Civil Procedure might still offer a solution here, or, for example, the route of arbitration.
Be cautious with KPIs, thresholds, and service credits
Another point of contention concerned penalties for service disruptions. Siemens invoked a 5 percent margin of uncertainty specified elsewhere in the contract documentation. According to Siemens, penalties were only due if that threshold was exceeded. The court did not agree with this interpretation.
The agreement contained two separate penalty regimes. The margin of uncertainty applied to penalties related to the LCC model, while a separate penalty regime applied to other deficiencies. A penalty could be imposed separately for each failure falling within that second category. The agreement also contained a provision regarding the accumulation of penalties from both categories.
This issue also has a clear parallel in IT law. In various types of IT contracts, including outsourcing and cloud contracts, different mechanisms often coexist:
- Availability KPIs;
- Incident SLAs;
- Response times;
- Resolution times;
- Service credits;
- Penalties;
- Separate compensation, if applicable.
It must be crystal clear how these provisions relate to one another.
For example, a monthly availability of 99.9% can be achieved even while multiple Priority 1 incidents have occurred simultaneously. Can the supplier be held separately liable for this? And can service credits be accumulated?
The lesson from this ruling: do not leave it implied which remedies coexist and which thresholds apply to them.
An announced delay does notchange a deadline
The discussion regarding the repair work is also very familiar.
The parties had agreed that June 30, 2024, was the deadline for repairing corrosion. Siemens was behind schedule and had informed HTM well in advance that this date would not be met.
According to Siemens, this course of events affected the strict nature of the deadline.
The court ruled otherwise. It was sufficiently clear from the agreement that June 30, 2024, was a strict deadline. The mere fact that Siemens announced in advance that it would not meet that deadline did not make the deadline any less strict. Siemens had not agreed on a new completion date or made any additional arrangements with HTM. As of July 1, 2024, Siemens was therefore in default without the need for a notice of default.
Highly relevant for delayed IT implementations
This is a familiar pattern in IT:“Everyone knew, after all, that the January 1 go-live was no longer feasible, right?” Contractually speaking, that is by no means always sufficient.
On a slightly more nuanced level, we also see this happen frequently. It’s common for different arrangements to have been explored—or even finalized—at the operational level for quite some time, even while the contract still assumes a different (and thus illusory?) reality. This can sometimes lead to very “gray” discussions, especially when the actual decision-makers are also involved in the conversation at that operational level.
That’s why, with a delayed IT project, the question is always:
Has only the operational schedule been adjusted, or have the parties also amended the contractual milestone? A status report stating “expected go-live: March” does not necessarily prove that the contractual deadline of January 1 has been abandoned.
For suppliers, this is a significant risk. Conversely, it is prudent for clients to expressly reserve their rights when agreeing to an adjusted schedule.
A shortcoming does not automatically mean there iscompensable damage
The part of the ruling concerning damages also contains a very interesting lesson.
HTM claimed, among other things, to have suffered damages because work tracks and trams were unavailable for a longer period due to the delay. HTM attempted to relate the value of that lost use to rental prices and depreciation costs, among other factors. The court did not agree with this.
Because the tracks and trams are intended to generate economic benefits, the court held that HTM must sufficiently demonstrate that it actually incurred additional costs or lost revenue—or a realistic opportunity for benefits—due to the loss of use. In other words: the issue is not whether HTM could theoretically have leased the work tracks, but whether such a lease was actually a realistic option. And the latter was evidenced by certain facts. Furthermore, with regard to the trams, depreciation costs would have been incurred even without the breach.
The IT parallel: downtime does not automatically equate to damages
This is particularly relevant for IT disputes.
Suppose an ERP system is unusable for a week. A client cannot simply reason as follows:
system costs €3 million per year → unusable for one week → damages amount to 1/52 × €3 million.
One must examine the financial position with and without the system failure.
Consider, for example, demonstrable:
- Additional personnel costs;
- Costs for a temporary alternative;
- Loss of revenue;
- Costs for remediation or workarounds;
- Loss of a sufficiently concrete economic opportunity.
The ruling thus clearly illustrates the difference between operational disruption and legally compensable financial loss.
Internal personnel costs are also not automatically considered damages resulting from delay
HTM also claimed personnel costs because employees were involved for a longer period in, among other things, shunting and inspecting the trams. That claim was also rejected.
The court found that those tasks would have had to be performed in any case. Due to the delay, the same tasks were simply spread out over a longer period. The number of hours in the hypothetical situation without the breach would therefore not have been lower.
We see this in IT projects as well. When an implementation fails, a spreadsheet is quickly created with:
10 employees × 100 hours × internal hourly rate = €X in damages.
But the crucial question is not merely how many hours employees spent on the project. The question is which costs or economic losses were specifically caused by the breach.
The legal distinction between “hours spent on the project” and “additional hours caused by the failure” can have enormous financial implications.
A limitation of liability may also apply to supplementary agreements
A final interesting parallel concerns the limitation of liability (exoneration).
The original agreement limited Siemens’ liability, among other things, to direct damages. The subsequent supplementary agreement regarding the corrosion repair did not itself contain a general limitation of liability.
Nevertheless, the court ruled that the original liability provision also applies to it. Among other things, it is significant that the parties had stipulated that the original and supplementary agreements formed a single, indivisible whole and that the original agreement could be regarded as a framework agreement containing general provisions. According to the court, if the parties had wished to deviate from this, they would have had to make specific provisions to that effect.
For IT contracts, this is immediately recognizable in the sequence:
MSA → SOW → Change Request → supplemental order.
For each subsequent assignment, it must be determined which provisions from the main agreement remain in effect. Relying on implied consistency is particularly risky when it comes to liability.
It is better to state explicitly:
“The liability provisions in Article X of the Master Services Agreement apply in full to this Change Request.”
Or, conversely, if a different risk profile has been agreed upon for a specific assignment.
From Trams to IT Projects: Lessons for Practice
The interesting thing about this ruling is that it shows that complex technical contracts, regardless of what is technically being delivered, can always follow the same legal fault lines.
A tram and an ERP system have little in common technologically. Contractually, however, they have surprisingly much in common .
As far as I’m concerned, the most important lessons for IT projects are:
- Define terms based on business impact, not just on technical specifications. Without context, “unavailable” is just as problematic as “unable to run.”
- Make it clear when technical documentation takes on contractual significance. A design freeze or solution design does not automatically constitute a contract amendment.
- Establish the document hierarchy. Ensure that the SLA, requirements, design, and master agreement do not provide conflicting answers.
- Make the relationship between KPIs, service credits, and penalties explicit.
- Do not confuse an adjusted project schedule with a changed contractual deadline.
- In the event of a delay, distinguish between inconvenience and demonstrable financial loss.
- For follow-up assignments, explicitly specify which liability provisions apply.
Ultimately, this issue is much more than just a matter of defects and corrosion on The Hague’s trams. It serves as a useful checklist of potential stumbling blocks for long-term IT contracts as well.
