In this piece
Werkvertrag vs Dienstvertrag: What the Word "Dienstleister" Actually Commits Your Vendor To
Quick verdict: a Werkvertrag owes a defined result. An employment-style Dienstvertrag owes labour under personal direction, while a freier Dienstvertrag covers ongoing labour with greater independence. "Softwaredienstleister" is only a marketing label. The contract's price, scope, cooperation, change and completion clauses decide how estimation and delivery risk are actually shared.
This is a legal-mechanics post, not legal advice. We work with an Austrian commercial lawyer for the actual contracts. The point here is the conceptual map, so you can brief your own lawyer with sharp questions instead of paying them to explain the basics.
Deciding how to contract a build?
Book Free ConsultationWhat is the difference between a Werkvertrag and a Dienstvertrag?
Austrian law separates these arrangements primarily by what is owed and how independently the work is performed. A Werkvertrag under ABGB §1165 and following owes a defined work product, the "Werk". The contractor normally organises the work independently and bears responsibility for producing a conforming result. A Dienstvertrag in the employment sense owes labour under personal direction and organisational integration. Between them sits the freier Dienstvertrag, which owes ongoing labour with little or no personal dependence. The WKO comparison of Austrian engagement types describes these distinctions. Payment is not automatically triggered by a formal acceptance event: ABGB §1170 says remuneration is generally due after the work is completed, unless the agreement or applicable practice provides otherwise.
The everyday German word for a supplier, Dienstleister, is built on the same root as Dienstvertrag. That is a linguistic accident, not a legal one: a Softwaredienstleister can and usually does contract on a Werkvertrag. But the accident matters, because it nudges buyers toward evaluating vendors on effort (day rates, headcount, hours available) when the thing they actually need to evaluate is a promise of result.
| Dimension | Werkvertrag | Dienstvertrag | Freier Dienstvertrag |
|---|---|---|---|
| What is owed | A defined result | Labour under direction | Labour, no integration |
| Who bears scope risk | Contractor bears result risk; price and scope risk depend on the agreed fee and clauses | Client usually bears more open-scope risk under time billing | Client usually bears more open-scope risk under time billing |
| Direction and schedule | Contractor decides how and when | Client directs (weisungsgebunden) | Largely the worker's own |
| Payment trigger | Generally completion of the work (§1170), subject to the contract | Elapsed time | Elapsed time |
| Warranty | Gewährleistung applies to the Werk | None on outcomes | None on outcomes |
| Substitution | Contractor may use its own team | Personal performance owed | Usually personal |
| Typical software use | Scoped build, discovery, migration, takeover | Employment | Staff augmentation, ongoing capacity |
Why does this matter when buying custom software?
Because the two contracts answer different questions, and only one is centred on "will this defined result exist and conform to the agreement". With a capped fixed fee, the contractor will usually carry more estimation risk. A Werkvertrag by itself does not make every overrun the contractor's problem: the agreed price model, cost estimate, client cooperation, scope definition and change mechanism still matter. ABGB §1170a, for example, distinguishes guaranteed from non-guaranteed cost estimates. Under an effort-based contract, the client normally carries more open-scope risk. Neither model is inherently dishonest. They allocate risk differently, and the written terms decide much of that allocation.
This is also why comparing day rates across the two is meaningless. A lower hourly rate attached to an obligation of effort is not cheaper than a higher rate attached to an obligation of result, any more than a cheaper lottery ticket is cheaper than a bond. You are pricing different instruments. We laid out the surrounding model choice in the software build models.
Does "Softwaredienstleister" mean the vendor works on a Dienstvertrag?
No. Softwaredienstleister, Softwareagentur, Software-Dienstleister and Entwicklungspartner are marketing labels for the same category of firm, and most of them contract on a Werkvertrag for scoped work. The label tells you nothing about the contract. Ask for the contract type explicitly, in the first call, and treat a vague answer as information.
The label that does signal something different is IT-Dienstleister or Systemhaus. That is a different business: running your existing IT under an SLA, which genuinely sits on a Dienstvertrag or framework agreement plus availability commitments. If a shortlist mixes both categories, the proposals will not be comparable, and that is usually the first sign the brief went to the wrong place.
"Ask what the vendor owes you if the estimate was wrong. The answer is the contract type, whatever the website calls the company."
What does a Werkvertrag actually commit us to?
A defined SoW for a defined fee. If we misjudge the complexity, we absorb the cost and do not invoice extra for having been wrong. What a Werkvertrag does not mean is a refund if a date slips: the term means legally bound to deliver the agreed result, and client remedies follow the standard Gewährleistung path of improvement, price reduction, or withdrawal in serious cases. The milestone schedule and the acceptance criteria live in the SoW so both sides know when the work is finished.
When is an effort-based contract the honest answer?
Three cases where insisting on a Werkvertrag is the wrong instinct:
- The scope is genuinely unknowable. Pure research, or integration against an undocumented third-party API. A fixed result promise here is a bet dressed as a contract, and the price will carry the risk premium.
- You need capacity inside a team that already has direction. That is staff augmentation, and forcing it into a Werkvertrag creates a fiction about who decides what gets built.
- Maintenance and small changes. A retainer with a monthly cap is the right shape for on-call and occasional tweaks.
For a scoped build with a genuinely capped fixed fee, a Werkvertrag often fits. The pricing-model side of this, fixed price against time and materials, is worked through separately in Werkvertrag vs time and materials for Austrian SaaS.
The Scheinselbständigkeit trap
If a contract is labelled Werkvertrag but the working reality is a Dienstvertrag, Austrian authorities look at the reality, not only the label. ASVG §539a expressly prioritises the true economic substance over the external form for social-insurance classification. Relevant indicators include daily direction, prescribed hours, organisational integration, lack of independent business infrastructure and personal labour rather than an independently produced result. Reclassification can bring retroactive social-insurance and payroll consequences, so obtain case-specific advice rather than relying on one checklist.
The practical consequence for buyers is simple. If what you want is a person embedded in your team taking your direction, contract for that honestly as a freier Dienstvertrag or through an employment arrangement. Do not dress it as a Werkvertrag because the paperwork is easier. Ask your accountant and your lawyer before the first invoice, not after an audit letter.
How completion and acceptance criteria change the conversation
A formal acceptance procedure is useful for software projects, but it does not arise from ABGB §1167 alone. The current ABGB §1167 sends defective-work claims to the general warranty rules in §§922 to 933b. The contract should separately define delivery, inspection, defect notice, cure, deemed acceptance if desired, and the point when milestones become payable. Acceptance criteria work best at the level of outcomes and observable behaviour. They are an explicit output of our discovery process because vague criteria make completion and defect disputes harder to resolve.
Effort-based contracts typically have no result-based acceptance moment unless the agreement creates one. Approval usually follows time records or service reporting. That is appropriate when you are buying capacity, but it is a mismatch when you expected a finished product.
Five questions to ask any vendor before you sign
- Werkvertrag or an effort-based contract? If the answer takes more than a sentence, ask again.
- Who bears the cost if the estimate was wrong? This is the same question, phrased so the answer cannot hide.
- What are the acceptance criteria, and who writes them? Without clear criteria, completion and defects become harder to prove and enforce.
- Who owns the source code and IP on full payment? Get it in the clause, not the sales deck.
- How do change requests get priced and how does the timeline shift? Every real Werkvertrag has this clause. Use it instead of quietly expanding scope.
How we answer those in practice sits on our custom software development service. For a build shaped exactly this way, the Bond Analytics case study shows a scoped engagement with a defined result rather than a rented team.
Final thoughts
Match the contract to the risk shape of the work, and never to the noun on the vendor's homepage. A defined result with a capped fixed fee often fits a Werkvertrag, but the written price, cooperation, change and acceptance clauses determine how scope and completion risk are actually shared. Genuinely open-ended work or embedded capacity is more honestly handled through an effort-based arrangement, and disguising dependent work can create Scheinselbständigkeit exposure.
Whatever you sign, have an Austrian commercial lawyer review the actual agreement and working model before performance begins. This article is a decision aid, not a substitute for advice on your facts.