Statement of Work in Austria: Template, Key Clauses and Local Law (2026)

A statement of work (SOW) is the document that describes a specific piece of work: what will be done, what will be delivered, by when, by whom and for how much. It almost always sits under a master services agreement (MSA), which holds the legal terms once, so the SOW can stay focused on scope. The SOW is where a project succeeds or fails, because it is the only place that defines what good looks like and when the supplier has actually finished. In Austria there is no SOW statute. A SOW takes its legal character from what it commits the parties to. The Allgemeines Buergerliches Gesetzbuch (ABGB) separates the service contract (Dienstvertrag), where the supplier owes its work over a period, from the works contract (Werkvertrag), where the supplier owes a defined result. A SOW that promises a fixed deliverable can pull the engagement into Werkvertrag territory, with its rules on acceptance and warranty for defects. This guide sets out the local law that actually bites, the clauses an Austria SOW should contain, and a section-by-section skeleton you can adapt. It is general information, not legal advice; confirm the detail with qualified Austrian counsel before you sign. ## Austria: the local law that shapes your SOW The key question is what the SOW promises. Paragraph 1151 ABGB draws the line: - Dienstvertrag (service contract). The supplier commits to perform services for a period, and the work itself is the performance. No specific result is guaranteed. Think advisory work, ongoing support or staff augmentation.

• Werkvertrag (works contract). The supplier commits to produce a defined result (a Werk) for a price, under Paragraph 1165 and following. This brings in rules on acceptance of the work, on warranty for defects (Gewaehrleistung), and on the point at which the fee falls due. A Werk can be intangible, such as a software build or a report, not only a physical object. Most SOWs are a mix, and Austrian courts have been clear that the label the parties use is not decisive: what matters is the arrangement actually carried out and the overall practical picture of the work. If you promise a concrete, acceptance-tested deliverable, draft as if Werkvertrag rules may apply: define acceptance criteria, a testing window and the remedy for defects, so that acceptance and sign-off are clear rather than disputed. Because the SOW sits under an MSA, the master normally carries liability, IP, confidentiality and data protection. The SOW should not repeat those; it should reference them and add only what is specific to this engagement. Where the work involves processing personal data, that is governed by the GDPR and Austria's Datenschutzgesetz (DSG) through the data processing agreement attached to the MSA, not reinvented in the SOW. ## The clauses an Austria SOW should contain A good SOW answers who, what, when, how much and how we know it is done. The core clauses are: - Reference to the MSA. State that the SOW is governed by the named master agreement and its terms, and the order of precedence if they conflict.
• Scope of work. A precise description of the services or deliverables, and, just as important, what is out of scope.
• Deliverables. Each deliverable, its format, and the standard it must meet.
• Acceptance criteria and process. How deliverables are reviewed, the testing or review window, what counts as acceptance, and what happens if a deliverable is rejected. This is the clause that decides whether Werkvertrag defect rules bite cleanly.
• Timeline and milestones. Dates, dependencies and the consequence of slippage on either side.
• Team and responsibilities. Named roles, the customer's dependencies and inputs, and who signs off.
• Charges and payment. Fixed price, time and materials, or milestone-based; the rate card; invoicing against milestones or acceptance; and taxes (USt/VAT).
• Change control. How scope, price or timeline changes are agreed, usually pointing back to the MSA's change process.
• Assumptions and dependencies. What the estimate relies on, so a missed customer input does not become the supplier's breach.
• Project-specific IP or confidentiality notes. Only where this engagement differs from the MSA default. ## A statement of work skeleton you can adapt Use this running order as a drafting checklist. It is a skeleton, not a finished contract, and it is not legal advice. 1. SOW reference and link to the MSA

2. Background and objectives
3. Scope of work (and out of scope)
4. Deliverables and standards
5. Acceptance criteria and acceptance process
6. Timeline, milestones and dependencies
7. Team, roles and customer responsibilities
8. Charges, payment model and invoicing
9. Assumptions and dependencies
10. Change control (referencing the MSA)
11. Any project-specific terms (IP, data, confidentiality) by exception
12. Signatures and effective date ## Common mistakes to avoid - Vague scope. The most common and most expensive SOW failure. If the scope is fuzzy, every disagreement becomes a change request or a dispute. Say what is in and what is out.

• No acceptance criteria. Without a clear test for done, a Werkvertrag-style deliverable never gets cleanly accepted, and the fee trigger and defect warranty blur. Define acceptance and the review window.
• Repeating the MSA. Copying liability, IP and data terms into the SOW creates conflicts with the master. Reference them instead and add only what is specific.
• Ignoring the Dienstvertrag versus Werkvertrag line. A SOW that promises a fixed result can trigger Werkvertrag rules on acceptance and warranty. Draft deliberately for the character of the work, because the label alone will not decide it.
• No assumptions clause. If the estimate depends on timely customer inputs and that is not written down, a customer delay can look like supplier failure. ## Keeping the agreement alive after signing The work does not stop at signature. A SOW carries milestone dates, acceptance windows, dependency deadlines and change orders, each with its own version and its own trigger, all tied back to a master agreement. Most disputes come not from a badly drafted clause but from a milestone that slipped unnoticed, a deliverable accepted by silence, or a change agreed by email and never recorded. That is the case for keeping drafting, review, version history and obligation tracking in one place rather than spread across inboxes, a shared drive and a spreadsheet. Adira is one such AI workspace: you draft from your own templates, see each clause flagged as favourable, neutral or unfavourable to you, edit clauses in plain English, and keep a live timeline of every milestone, acceptance and change order, built on Anthropic's Claude. Adira is India-first today; deeper support for Austrian law is on its roadmap rather than live, so treat it as a workflow layer here and keep local counsel for the legal substance.