Don't Be Gentle It's A Rental – Or Isn't It? Correctly Classifying An IT Service In A Contract

Schoenherr Attorneys at Law


We are a full-service law firm with a footprint in Central and Eastern Europe providing local and international companies stellar advice. As the go-to legal advisor for complex commercial matters in the region, Schoenherr aims to use its proximity to industry leaders, in developing practical solutions for future challenges. We keep a close eye on trends and developments, which enables us to provide high quality legal advice that is straight to the point.
There's no such thing as a one-stop software contract that covers all services.
Austria Media, Telecoms, IT, Entertainment
To print this article, all you need is to be registered or login on

There's no such thing as a one-stop software contract that covers all services.

This is also because when creating the Austrian General Civil Code ("ABGB") the legislator wasn't thinking about the 21st century software industry with SaaS, ASP, PaaS or IaaS contracts. In most jurisdictions, including Austria, there is generally no legally regulated contract type obligation.

This makes it tricky in the software sector, because the core of every IT contract is first and foremost to identify the specific good or service owed, describe it in detail, and classify it legally under the correct contract type. Only then can the resulting legal consequences be contractually regulated. In practice, this poses a great challenge to entrepreneurs, customers and lawyers.

The problem in the software sector is that many IT goods and services offered can be the subject of different contract types, such as a purchase agreement, a work contract, a service agreement or a lease agreement. Depending on the classification, this can also result in different warranty, indemnity or risk transfer rights. It should be noted that the Austrian legislator provides special provisions for lease agreements (e.g. according to Section 1096 ABGB the landlord must hand over and maintain the property in a usable condition). On the other hand, warranty law is only applicable to work, lease and purchase agreements, but not to service agreements.

Thus, the provider of a work contract owes a specific measurable success. In practice, services or goods under a work contract are often precisely defined in Statements of Work ("SOW"). If the provider does not fulfil these, it is not entitled to any remuneration for work and services.

In a service agreement, on the other hand, only diligent efforts (to be precisely defined in the agreement) are owed, but no explicit success. The specific quality of the service is usually categorised in detail in service level agreements ("SLA"). In addition, lease elements can also be added to a service, for example when infrastructure is provided in separate units. In this case, the condition considered to be usable or unusable must be defined in the agreement, because not every fault is a defect in the legal sense and automatically makes the property/infrastructure unusable.

"In disputes over interpretation, contractual ambiguities are always at the expense of the party who has made use of them (Section 915 ABGB). A precise definition of the respective service or goods is therefore essential to avoid expensive and protracted disputes later on."

In disputes over interpretation, contractual ambiguities are always at the expense of the party who has made use of them (Section 915 ABGB). A precise definition of the respective service or goods is therefore essential to avoid expensive and protracted disputes later on.

The danger is that the overall performance (including different services or goods) offered cannot be classified under a single type of contract, but this is not regulated clearly enough in the existing contractual text. In such cases, the absorption theory may be applied to the disadvantage of one party. Accordingly, the rules of the "dominant" contract type apply to all performance (all services and goods) sections.

The legal art therefore often lies in dividing the overall performance into individual parts at the time the contract is drafted and subjecting each to the corresponding type of contract (combination theory). The following examples are intended to provide a rough outline of how complex such a classification can be.

The six most common types of IT contracts

1. Hardware contracts

The buyer acquires permanent ownership of hardware, e.g. an IT system or a physical server. This is a classic purchase agreement within the meaning of Section 1053 ff ABGB. If the purchased hardware does not meet the contractual or customary requirements, it is defective. In such cases, the seller must provide a warranty in accordance with the general rules of Section 922 ff ABGB, usually in the form of replacement/improvement or (in the case of not insignificant defects) a price reduction.

2. IT consulting contracts

This type of contract includes expert consulting for a wide variety of IT projects. Depending on the project, a distinction can be made here as to whether it relates to a concrete success, such as the performance of a penetration test on IT systems (work contract) or an accompanying consultation, e.g. in the area of IT project management (service agreement).

3. Application Service Provider ("ASP") contracts

The classification becomes more complicated when software is not implemented locally on the customer's PC (client), but is hosted as a web application on an external server. The subject matter of the ASP contract is therefore the implementation of the software, support and software maintenance in return for a monthly usage fee. The provider is obliged to make the software available on its server. An example of this is an ERP system. Depending on how they are structured, ASP contracts can therefore contain several elements (of varying degrees) of different contract types. The implementation phase can be regarded as a work contract, under which successful integration of the software into the customer's processes is owed. A lease component is the provision of this software. Software maintenance and support can be incorporated into the overall contract as an element of the service agreement.

4. Infrastructure as a Service ("IaaS") contracts

Here, the customer is offered an infrastructure in the sense of computing power, storage space, network bandwidths, virtual servers or server operating systems with firewalls. The customer is responsible for the installation and operation of its software components. However, the provider is usually responsible for a certain monitoring function and for ensuring that the infrastructure is operational. Examples of this are Amazon Web Services or Google Computer Engine. If the service is merely temporary access to storage capacity, it is a lease agreement. However, if the service includes, for example, website hosting, printing and postal services, it may also be a work contract. The support, monitoring and operating services offered are to be qualified as service agreements.

5. Platform as a Service ("PaaS") contracts

PaaS is primarily addressed to software developers in companies, SMEs and start-ups, who are provided with a development platform in which they can develop and distribute web-based applications for their end users. However, if access to this development environment is only agreed for a certain term, the underlying contract will have to be qualified as a lease. Examples of this are Google App Engine or Windows Azure. However, a work contract would have to be concluded if it is a development project for a PaaS customer. If only modules are to be sold for integration into developments of the PaaS customer, this is a purchase agreement for the respective module.

6. Software as a Service ("SaaS") contracts

SaaS is a kind of successor to ASP, but one in which cloud-based concepts are in the foreground, offering the customer even broader usability. Here, the customer buys the use of ready-to-use application software via web browser / client software that runs on third-party servers or server farms. The customer gets access to the functionalities and interfaces provided by the provider via the web interface (or a program interface with limited adaptation rights). The customer only has to take care of the data exchange between its systems and the SaaS. The provider therefore not only operates the software itself, but also the entire required infrastructure and platform, as well as all the necessary updates and upgrades. In principle, no separate software licences are granted for this, but a monthly usage fee is paid. The advantage of using an application via SaaS is usually the low usage costs due to the "pay as you go" principle. Of course, SaaS can also lead to lower hardware (less storage space) and maintenance costs. An SaaS contract is therefore most similar to a lease agreement. Depending on its structure, e.g. in the case of customising in the sense of individual adaptation of the software (e.g. a Graphical User Interface ("GUI")), it may also be structured as a work contract.

So what should you pay attention to in IT contracts?

The structure of the contract is often tied to the requirements of the individual IT project. Inaccurate service descriptions are the most frequent sources of error and therefore are the most essential component of IT contracts. The design of the legal performance description depends on the respective delivery or service. Therefore, when drafting the contract, care should be taken from the outset to divide the individual service sections if possible and to classify them under the respective contract types. In the case of software services that are structured as a work contract, it is therefore all the more important to define the specific success as precisely as possible in SOW. In the case of more complex services, it is also advisable to define just as precisely the defects for which the provider must provide a warranty.

"When drafting the contract, care should be taken from the outset to divide the individual service sections if possible and to classify them under the respective contract types."

For services, it is essential to define the service itself as well as its quality and characteristics in the SLA, according to objectively measurable criteria. In addition, it is advisable to state in the SLA that no continuous 100 % availability of the service is guaranteed.

In addition, for larger projects it makes sense to include strict penalties for violations of the SLA. The amount of these penalties is usually based on a percentage of the total or annual fee. When determining the amount of the penalty, it should be taken into account that this provides the customer with an effective control tool to persuade the provider to comply with the SLA, but that the provider is not bankrupted in the event of a breach. Finally, it should be ensured that any agreement on penalties does not exclude any additional claims for damages on the part of the customer.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.

See More Popular Content From

Mondaq uses cookies on this website. By using our website you agree to our use of cookies as set out in our Privacy Policy.

Learn More