Systems Supply


A clear specification is essential in a contract for the provision of an IT system.  It should set out what the system is supposed to do and how it is supposed to perform.  Compatibility with existing systems may be critical, where the system is not entirely new or standalone. Large bespoke systems may be the subject of a tender.

The specifications, whether in the case of a tendered contract or a negotiated contract, should clearly define what is required. It should define a date for delivery and specify what is to be provided.  If elements of the system are to be provided in installments, there should be provision for the timing, testing, and implementation.

There may be phases involving the evolution of the functional specification, system specification, programme specification, development, commissioning, testing, debugging, retesting and acceptance. The timetables with key dates and deliverables will be commonly employed.  The dates will be commonly linked to payment obligations What is required will depend on the nature of the system and its complexity.

Delivery and Acceptance

The provisions for determining satisfactory delivery including the requisite tests should be provided for.  If it is necessary that the system is tested in operation, then appropriate timelines and procedures should be provided.

If the system is delivered late, the consequences of late delivery should be provided.  Where no date is specified, it will be implied that the system is to be delivered within a reasonable time.  Time will not be presumed to be of the essence in the sense that failure to deliver on time entitles the customer to cancel the contract.  Provision may be made for making time as the essence, where there is a prolonged failure and final notice has been given.

The acceptance procedure should be defined.  In IT systems, the testing and verification of the system’s operation are critical. The acceptance tests will depend on the nature of the project.

There may be a provision that if the system operates for the period, it is deemed accepted, if not rejected in that period.  Alternatively, there may be a positive commissioning process and verification of compliance with specification or as the customer’s requirements as defined by the standards or criteria provided for.

The contract is likely to provide that on acceptance, al or the bulk of the remaining payments obligations fall due.  There may be a further period in which the supplier agrees to remedy problems and retest.  Continued failures may be grounds for termination of any ongoing maintenance and service contracts or may provide for a refund.


The pricing arrangements will depend on the commercial terms of the agreements.  There may be a single charge for the entire project and related services.  Commonly, this will be followed by ongoing charges for maintenance and support.  There may be separate purchases of hardware and software and ongoing licensing fees.  There may be services for ongoing use of services such as cloud computing services.

The timing of payment obligations should be defined by the contract.  There may be sums paid at stages of the project, with a retention relative to the value of work done, pending implementation and commissioning.  The pricing should incentivise the supplier both in terms of time and performance.

The consequence of non-payment should be expressed or may be implied. There may be interest due on overdue payment.   Generally, the supplier may be entitled to suspend work and in the case of prolonged non-payment after notice. It may be entitled to terminate the contract and claim for loss.

Where hardware is supplied, the title may be retained by the supplier.  This acts in part as security for the price. See generally the sections on the retention of title in the context of the supply of goods.


There may be changes and variations in the scope of the contract as it progresses.  Changes in the specification and scope of the project usually lead to changes in price, timeline and the deliverable.

The contract should provide a mechanism for the pricing of variations and any attendant time extensions that are justified.  There may be outside party or project manager who determines the effect of the variation.

The supplier will not wish to agree unconditionally to provide whatever changes might be specified. The customer will wish to have the ability to provide for changes, whether caused by circumstance or choice without having to renegotiate the price in circumstances of vulnerability with the contractor/.

In the normal course, any such changes would be outside the scope of the project and would require a complete negotiation.  However, because IT systems customer requirements are often complex, the parties will commonly build in an allowance for changes and variations in the scope of the original works.

Intellectual Property Issues

IT supply contracts will usually involve elements of the development and supply of intellectual property.  This may arise from the specifications and be reflected in the software that gives effect to them.

Intellectual property issues may arise in relation to the customer’s confidential business information in a development agreement, copyright in the case of software and database rights in the case of bureau services.  See generally the sections on intellectual property in relation to the issues that arise in the development, ownership, and use of intellectual property.

The contract should provide who is the owner of any intellectual property which may be developed.

Issues may arise in relation to third-party copyright in software.  The customer will want an assurance that the supplier is entitled to provide the requisite software without the risk of infringement proceedings by a third party. There may be a warranty in respect of compliance with or the absence of third-party intellectual property rights and indemnity in respect of any infringement or claims that may arise.

Infringement Issues

There may be an obligation on the supplier to deal with alleged infringement and to indemnify the customer.  The supplier may be liable for the consequences of threats from third-party claims and their consequences.

The supplier may be entitled to take over litigation, rather than having to fully indemnify the customer.  It may be entitled to settle the action, provided that the customer’s loss is made good.  He may be entitled to change the system so that the infringement ceases

The customer’s business information will commonly be visible to the supplier in many IT systems, servicing and maintenance contracts.  The customer will wish to ensure that this is kept confidential and cannot be disclosed.  The general issues which arise in the context of confidentiality apply and appropriate protections may be incorporated.

Escrow of Source Code

The software source code may be retained by the supplier while an object code is given to the customer.  There may be a right to require the production of the source code for maintenance or development purposes.   The supplier may seek to protect his own interests in the material. Under an escrow agreement, the supplier may deposit the code with a third-party to deal with the conflicting requirements of the parties.

An agreement may be entered with that third party as escrow agent regarding its release.  There may be provision for the release of the source code or for its evolution through new editions and releases.  If the supplier goes out of business or fails to provide service, it may provide that the escrow agent may release the code to the customer to facilitate it obtaining alternative services.  Certain bodies provide escrow services to the software industry.


Warranties are likely to be given regarding the performance of the system.  This may be defined by reference to standards, a performance specification or other description of outputs. A breach of warranty will give the customer a right to damages or in the case of a fundamental breach, a right to terminate and recover damages.

The warranty may be restricted.  It may be for a limited period only, after which maintenance obligations only apply.  The obligation will commonly be limited to remediation of non-compliant aspects, without further liability for loss or damage.

Warranties may cease if any changes are made by the customer to the system.  This will generally be limited to additions and changes which are relevant to the particular breach. It may be cast on wider terms.

The Extent of Liability I

Because of the scope for significant business loss on the part of the customer, the supplier may seek to limit its liability for breach.  The Unfair Contract terms provisions, apply only in the context of supplies to consumers.

As a matter of contract law, a supplier will not be liable for indirect consequential loss unless it has specific knowledge that such loss is likely or probable.   What constitutes consequential loss can be difficult to define.  It is generally expressed in broad terms by the courts and its determination in particular case is a matter of degree and judgment.

In accordance with the most famous common law formulation, contract damages are those fairly and reasonably considered either as arising naturally, according to the usual course of things or such as may reasonably be supposed to be in the contemplation of the parties at the time they enter the contract.

The Extent of Liability II

Under the second “leg” or category, where there are special circumstances which the supplier does or should reasonably contemplate, then the amount of loss or damages is those that ordinarily flow under those special circumstances.  Then, where they are known to the supplier, the damages may be awarded if such loss arises.

The distinction between the two headings is sometimes described as that between direct loss on the one hand and consequential or indirect loss on the other. Consequential loss is sometimes used to describe more remote loss than that following in the natural and ordinary course of things.  This does not accurately summarise the rule. The type of loss recoverable under the first head and what might be labelled consequential loss are not mutually exclusive.

Consequential loss often is taken to refer to the loss of profits which will be commonly recoverable as the natural and probable consequence of the breach.  Some consequential loss may be recoverable provided that it occurs in the ordinary course of things in accordance with the above test. The business loss that arises naturally from the breach generally will be recoverable under general principles.

Allocation of Risks

A more modern approach in the context of IT contract has sought to draw the line between recoverable and irrecoverable loss with reference to the respective assumption of risk and responsibility on the part of the parties. The traditional position is seen as a starting point or presumptive position subject to a broader economic analysis of what the parties contemplated or expressed in relation to the economics and commercial apportionment of risks.

The courts focus on whether the parties expressly or implied assumed responsibility for particular types of loss at the time the contract is made.  Loss not so assumed, is too remote. The partiers should focus on the type of risks that are involved and allocate risk responsibility.  Implied terms and generic exclusion clauses may lead to considerable uncertainty and litigation after the event of a breach.

Limitation of Liability

There may be caps on liability.  The provisions applicable to exclusion clauses generally, apply.  Commonly, liability is limited to the price.

The courts have held that clauses which seek to entirely exclude liability for anticipated saving and damage to data or third-party claims, may be unreasonable because they remove the very thing that is to be provided and leave no remedy.  Where the clause is overly broad and leaves no effective remedy, courts may refuse to uphold it. –

Remoteness of Loss

Remoteness of damages refers to damages that are too removed from the loss to be the subject of compensation. Under the general law, the courts consider what liability the parties have impliedly assumed, in light of the context and purpose of the contract.  The test focuses on the likelihood or probability of the loss arising.

Difficult matters of judgment and interpretation arise as to whether particular categories of loss are recoverable.  Generally, once a particular type of loss is recoverable, the full extent of that type of loss may be recovered.  This leads to questions of interpretation of the type of loss.


The parties may specify the rights and remedies of the “innocent” party in the event of a breach.  Liquidated damages are pre-agreed payments for breach of contract.  They may arise where the contract deliverable is delivered late. Provided that the estimated sum is a good faith, estimate of the loss and cost, then it will be upheld. In contrast, a penalty is not enforceable common-law.  See generally the sections on contract and damages for breach of contract.

An alternative remedy may be by way of service credits in respect of support and maintenance.  This may be appropriate where the system fails to meet non-critical criteria in the short term.  If the relevant criteria are not met, then service credits of a defined value may arise.  This remedy most commonly arises in large-scale projects, outsourcing, and public-private partnership arrangements.

As with any contract, the parties may define the circumstances of the breach, which are so fundamental that the other party is entitled to terminate the contract. They may include

  • The insolvency of the other party,
  • failure to deliver by longstop dates,
  • failure to make payments after a remedy period,
  • failure to deliver key elements such as minimum functionality etc.