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

A statement of work (SOW) is the document that describes one project in detail: what is delivered, by when, for how much, and how it is accepted. In Poland an SOW usually sits under a master services agreement, and one Civil Code question drives everything: is the engagement a contract for specific work, where the supplier owes a result, or a mandate, where the supplier owes careful effort. The answer changes the warranty, the liability, and even the social-insurance treatment. This guide covers the law, the key clauses and a working skeleton. It is general information, not legal advice; confirm a live deal with a Polish lawyer. ## What law governs an SOW in Poland? There is no SOW statute. The SOW is a contract document under the Polish Civil Code (Kodeks cywilny) of 23 April 1964, inheriting the terms of the master services agreement it hangs off. The key is which Civil Code contract type fits the work: - Contract for specific work (umowa o dzielo, Article 627): a result contract. The supplier must deliver a defined product of work, carries the risk of achieving it, and answers for defects under a statutory warranty. Acceptance (odbior dziela) of the completed work triggers payment.

• Mandate (umowa zlecenia, Article 734): a best-efforts contract. The supplier must carry out the agreed activity with due care, but does not guarantee a particular result.
• Unnamed service contracts (Article 750): where a service fits neither cleanly, the mandate rules apply by analogy. Courts classify by the real nature of the work, not the label. A firm, measurable deliverable points to a contract for specific work; an open-ended activity points to a mandate. The distinction also affects social-insurance contributions, which the social insurance authority (ZUS) can reassess, so it is not only a private-law question. ## Key clauses in a Polish SOW - Link to the master agreement: reference the MSA and its order of precedence.
• Scope and deliverables: a precise list of outputs with specifications. Vague scope is the main cause of disputes and of misclassification.
• Contract type: state whether the engagement is a contract for specific work or a mandate, consistent with how the work is actually performed.
• Timeline and milestones: dates, dependencies and the effect of customer delay.
• Acceptance (odbior): objective acceptance criteria, a review window, and what happens if the customer does not respond.
• Charges and payment: fixed price, time and materials, or capped time and materials, tied to acceptance or milestones.
• Change control: how scope changes are requested, priced and signed off.
• Intellectual property: if deliverables include copyright works, assign or licence them with the fields of exploitation (pola eksploatacji) named, as the Copyright Act requires.
• Contractual penalties (kara umowna): for non-monetary breaches only, under Articles 483 and 484, and reducible by a court.
• Liability: within the Article 473 limit on excluding intentional harm.
• Data protection: reference the data processing agreement where personal data is involved. ## A simple drafting skeleton 1. SOW reference and link to the MSA

2. Project summary and objectives
3. Scope and detailed deliverables
4. Contract type (specific work or mandate)
5. Timeline, milestones and dependencies
6. Acceptance criteria and process (odbior)
7. Charges and payment schedule
8. Change control
9. Customer responsibilities
10. Intellectual property and fields of exploitation
11. Contractual penalties (kept within the Code)
12. Assumptions and exclusions
13. Data protection reference
14. Signatures ## Common mistakes - Leaving scope vague, which invites both disputes and misclassification by a court or ZUS.

• Labelling an engagement a contract for specific work when the work is really ongoing effort, or vice versa.
• Assigning copyright deliverables without naming the fields of exploitation, so the uses are not transferred.
• Writing no acceptance (odbior) process, so payment and sign-off stall.
• Setting a contractual penalty on a monetary obligation, where it does not work. ## Keeping statements of work under control If you run many SOWs under one master agreement, the hard part is tracking which is active, which milestone is due, and whether the contract type, IP and penalty clauses are consistent. That work (drafting from a tuned template, flagging risky clauses, tracking milestones and keeping versions straight) is what an AI contract workspace can hold in one place. Adira is built for this, with per-clause risk review and plain-English clause editing; it is India-first today with other jurisdictions on its roadmap, so verify local depth before relying on it for Polish law. More at Adira. The law above stands on its own. ## Bottom line A Polish SOW is a project-level contract under the Civil Code that inherits its master agreement's terms. Decide whether the engagement is a contract for specific work (Article 627) or a mandate (Article 734), write a clear acceptance process, assign IP with the fields of exploitation named, keep penalties within the Code, and get Polish advice before signing a real deal.