Statement of Work in Portugal: 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 Portugal there is no SOW statute. A SOW takes its legal character from what it commits the parties to. The general law of obligations in the Civil Code separates a contract for services (prestacao de servicos), where the supplier owes its careful effort, from a works contract (empreitada), where the supplier owes a defined result. A SOW that promises a fixed deliverable can pull the engagement into works-contract territory, with its rules on acceptance and defect liability. This guide sets out the local law that actually bites, the clauses a Portugal SOW should contain, and a section-by-section skeleton you can adapt. It is general information, not legal advice; confirm the detail with qualified Portuguese counsel before you sign. ## Portugal: the local law that shapes your SOW The key question is what the SOW promises. The Civil Code distinguishes: - Prestacao de servicos (services). The supplier commits to perform services with due care, but does not guarantee a specific outcome. Think advisory work, ongoing support or staff augmentation.

• Empreitada (works contract). The supplier commits to produce a defined result for a price. This brings in rules on acceptance of the work, on defects and the client's remedies, and on the point at which risk passes. Think a built, tested and accepted deliverable. Most SOWs are a mix, and the label the parties use is not decisive; a Portuguese court will look at what was actually agreed and done. If you promise a concrete, acceptance-tested deliverable, draft as if works-contract 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 Portugal's Law 58/2019 through the data processing agreement attached to the MSA, not reinvented in the SOW. ## The clauses a Portugal 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 works-contract 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 (VAT/IVA).
• 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 works-style deliverable never gets cleanly accepted, and payment and defect liability 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 services versus works line. A SOW that promises a fixed result can trigger empreitada rules on acceptance and defects. Draft deliberately for the character of the work.
• 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 Portuguese law is on its roadmap rather than live, so treat it as a workflow layer here and keep local counsel for the legal substance.