SME series · Everything turns on characterisation: depending on how the case is characterised, you have four days or you have five years
Most claims against technology suppliers are not lost on the merits. They are lost on time limits. And the time limit is not written in the contract: it depeHow to Claim Against a Technology Supplier for Damage to Your Business
nds on how what happened is characterised in law, which is the first question in the case and almost never the first one asked.
The range is vast. Depending on how the same facts are characterised, the period runs from four days to five years.
First decision: is it a defect, or is it something else?
This is the decisive question, and it should come before any other.
If what was delivered works but is defective, we are in the territory of warranty against defects, with short deadlines. If what was delivered is substantially different from what was agreed, or unfit for the purpose of the contract, there is no defect: there is delivery of a different thing, what the Spanish case law calls aliud pro alio. And then the short warranty deadlines do not apply; ordinary breach of contract does, under articles 1101 and 1124 of the Civil Code, with the general five-year limitation period.
The practical difference is most of the case. An ERP that cannot issue compliant invoices, a system that cannot carry the volume it was contracted for, software that does not perform the function it was bought for: that is not a hidden defect, it is something other than what was agreed. And many failed technology projects may fall within that category, rather than within the short-deadline regime.
Put differently: before taking alarm at the four days, ask whether the case is one of defect or of unfitness.
Second decision: what kind of contract is it, and was there really a sale of goods?
There is no such thing as “the technology contract”. There are three families, and characterisation drags the regime with it.
A contract for works — an ERP implementation, bespoke development, a migration — is the most favourable to the customer, because the supplier commits to a result: it does not perform by delivering hours and effort, it performs by delivering a system that works.
A supply of services — maintenance, support, a SaaS subscription — is ordinary breach of contract, with the general five-year limitation period of article 1964(2) of the Civil Code. There are no short deadlines.
A commercial sale of goods is where the short deadlines live, and they should not be applied lightly. Article 336 of the Commercial Code allows four days from receipt to complain of defects in quantity or quality where the goods are received packed or bundled, and denies any action for visible defects to a buyer who examined the goods on receipt and accepted them. Article 342 allows thirty days from delivery for internal defects, and it is a forfeiture period: once it passes, the right is gone.
But that regime presupposes that what was delivered is goods, and in information technology that is far from obvious. It is clear for hardware. It is arguable for a software licence. And it does not hold for a cloud service, which involves the delivery of no thing at all. Before treating article 342 as applicable, it is worth asking whether there really was a sale of goods or whether the transaction was something else.
A note on article 1490 of the Civil Code: the six months it lays down is the period for the warranty actions for hidden defects, applied subsidiarily in commercial sales. It is not a ceiling on an ordinary breach claim, and it does not extend to aliud pro alio.
The further difficulty is that most technology contracts are mixed: an ERP is bought, implemented and maintained. Three strands, three regimes. And the supplier will argue that what failed was the strand with the shortest one.
Third decision: what is being claimed?
Article 1124 allows a choice between demanding performance and terminating, in both cases with damages. The choice is not neutral: terminating means building the system again with another supplier and bearing that cost; demanding performance means staying tied to someone who has already failed.
Damages cover actual loss and lost profit under article 1106, subject to the foreseeability limit of article 1107 — except in cases of wilful breach, where the debtor answers for all damage knowingly flowing from the breach.
Lost profit is where the money is lost. The case law requires certainty, not hypothesis: “we would have billed twenty per cent more” is not compensated. What is, if documented, is the specific order lost, the penalty paid to your own client, the cost of the replacement supplier, the hours staff spent covering for the failure. The difference between a claim recovered and a claim dismissed usually lies in that list.
Fourth decision: what does the limitation clause say?
Almost every technology contract caps liability at the amount invoiced over the previous twelve months, or at service credits under the service level agreement. Between businesses, such clauses are, in principle, valid, subject to statutory limits and the circumstances of each case.
Two exceptions always deserve a look. Wilful breach: article 1102 makes void any advance waiver of the action to enforce liability for dolo, so if the supplier knew the system would not do what was promised and sold it anyway, the cap does not protect it. And service credits, which operate as a penalty clause: where they are the only agreed consequence, it must be argued whether they exclude general damages or run alongside them, with article 1154 available as a moderating tool.
What to do, in this order
Freeze the evidence before anything else. In a cloud service, the evidence of failure sits on the supplier’s server and can disappear when the subscription is cancelled. Do not cancel before extracting and preserving the logs, the tickets and the version history.
A dated formal demand, describing the breach and setting a period to remedy it. And here an important warning: an extrajudicial demand interrupts limitation under article 1973, but it does not interrupt forfeiture. If the case is one of internal defects under article 342, the thirty days run regardless of how impeccable the letter was. The demand also places the supplier in default under article 1100; what it does not do is automatically generate interest, because article 1108 concerns obligations to pay a sum of money, and damages are not a liquidated sum until determined.
Quantify with documents. Invoices, orders, customer emails, timesheets. An unsupported estimate is not a claim, it is a complaint.
And the IT expert report. Where the case turns on whether the system met the agreed functionality, the expert’s report decides it. What the expert needs is the contractual documentation of requirements.
The error behind almost every lost claim
And there lies the underlying problem. In most projects there is no document stating what the system was supposed to do. There is a sales proposal with screenshots, a chain of emails, and a specification nobody signed or annexed to the contract.
Without documented requirements it is not merely hard to prove the breach: it is hard even to characterise it, because the line between a defect and a thing different from the one agreed is drawn by comparing what was delivered with what was promised. If there is no record of the promise, there is no aliud pro alio to argue — and then the short deadlines do appear.
So the claim is won or lost at the contracting stage, not in litigation. Annexing the functional requirements, setting measurable acceptance criteria and agreeing who tests what costs one afternoon, and it decides whether, on the day of the dispute, you have four days or five years.
This article is for general information and does not constitute legal advice. The characterisation of the contract and of the facts depends on each case, and the time limits depend on that characterisation: it should be examined before claiming.