# Vad är ett statement of work? Så fungerar ett SOW i avtalet URL: https://legalysis.co/sv/journal/vad-ar-ett-statement-of-work Type: blog Locale: sv Published: 2026-10-19 Updated: 2026-10-22 --- > Ett statement of work anger vad som ska levereras, när, av vem och till vilket pris. Så skriver du ett SOW som håller när projektet ändras. Vad är ett statement of work? Det är den del av ett tjänsteavtal som anger exakt vad som ska levereras, när, av vem och till vilket pris. Ett statement of work, förkortat SOW, ligger under de juridiska villkoren och styr själva projektet. I praktiken är det här de flesta tvister om att "det var inte det vi kom överens om" vinns eller förloras. ## Vad innehåller ett statement of work egentligen? Ett SOW beskriver ett enskilt arbete. Det försöker inte täcka hela relationen mellan två företag, eftersom det är uppgiften för huvudavtalet. Ett välskrivet SOW brukar ändå innehålla samma kärnblock. - **Omfattning:** vad leverantören gör, uttryckt med tydliga verb, och vad den inte gör. - **Leveranser:** de konkreta resultaten, till exempel en migrerad databas, en varumärkesguide eller 40 timmars support. - **Tidplan och milstolpar:** datum eller löptider kopplade till leveranserna, inte till ett vagt "i slutet av kvartalet". - **Pris och betalningsplan:** fast pris, löpande räkning eller en blandning, med tydliga utlösare för fakturor. - **Godkännandekriterier:** hur kunden avgör att en leverans är klar. - **Roller och beroenden:** vem som levererar åtkomst, data, godkännanden eller testmiljöer, och till vilken dag. - **Ändringsprocess:** hur omfattning, pris eller datum ändras när arbetet väl har börjat. Så här fungerar strukturen i praktiken. SOW:et gör om en muntlig idé till något som en utomstående kan läsa och kontrollera. Den utomstående är ofta en domare, en revisor eller en ny kollega som tar över projektet efter dig. Om dokumentet bara går att tolka av de personer som skrev det, är det inte färdigt. ![Händer som pekar på flikade avsnitt i ett tryckt avtal](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/legalysis/2026-10/856bc2-i1.webp) ## Hur skiljer sig ett SOW från ett huvudavtal, en offert eller en inköpsorder? Förvirringen uppstår oftast för att dokument som liknar varandra används i samma affär, ofta under samma vecka. Ett huvudavtal (MSA, master services agreement) innehåller de generella juridiska villkoren: ansvar, immateriella rättigheter, sekretess, personuppgifter, uppsägning och tillämplig lag. Det skrivs under en gång. Varje SOW hänger sedan på avtalet och täcker ett enskilt projekt. Ett huvudavtal kan bära ett tiotal SOW under flera år. En offert är ett säljdokument. Den beskriver vad leverantören hoppas göra och varför du ska välja just dem. Den är oftast inte bindande, men den återanvänds ofta som första utkast till SOW:et, och där börjar problemen, eftersom försäljningsspråk hamnar i ett avtal som ska gälla i flera år. En inköpsorder är ett betalningsgodkännande. Den anger ett pris och en mängd, men sällan någon omfattning. Om du bara använder en inköpsorder för ett tjänsteprojekt är arbetet i praktiken odefinierat, och den som utför det kan tolka uppdraget hur den vill. För ett engångsuppdrag kan ett kombinerat avtal, där SOW:et är en bilaga, fungera utmärkt. Uppdelningen mellan huvudavtal och SOW lönar sig när du köper från samma leverantör återkommande och vill slippa förhandla juridiska villkor varje gång. ## Vilken klausul gäller när huvudavtalet och SOW:et inte stämmer överens? Det här är frågan de flesta hoppar över, och det är den som kostar pengar. Noggrant skrivna avtal följer oftast ett enkelt mönster. Huvudavtalet styr de juridiska villkoren. SOW:et styr omfattning, tidplan och avgifter. En prioriteringsklausul säger det i en eller två meningar och anger vilket dokument som gäller vid konflikt. Saknas en sådan klausul får man förlita sig på hur en domstol tolkar dokumenten tillsammans. Enligt engelsk rätt läses avtalshandlingar i allmänhet som ett enda avtal, så en motsägelse upphävs inte av sig själv. Den skapar en diskussion, och diskussioner brukar bli fakturerbara för båda parter. Så här kan en sådan formulering se ut, som ett exempel på avtalstext och inte som juridisk rådgivning för din jurisdiktion: `§ Vid konflikt gäller huvudavtalets villkor före SOW:et, med undantag för att SOW:et gäller för omfattning, leveranser, tidplan och avgifter för det projekt det beskriver.` Se upp för en fälla. Ett SOW som i tysthet åsidosätter ansvarstaket eller äganderätten till immateriella rättigheter "för just detta projekt" är legitimt när båda parter avser det. Det blir ett problem när ingen har märkt det. Den som skriver under ett SOW bör läsa det som ett avtal, inte som en projektplan, och särskilt de rader som säger att något gäller "trots huvudavtalet". ![Vägg med post-it-lappar lagda som en tidslinje för projektmilstolpar](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/legalysis/2026-10/50c55e-i2.webp) ## Vad gör omfattningstexten hållbar? Omfattningen är där SOW:n brister. En vag omfattning är inte neutral. Den gynnar den part som är mest villig att argumentera senare, och i praktiken är det oftast den med mest inflytande över projektet. Tre vanor gör omfattningen hållbar. För det första: skriv ut undantagen. En lista över vad som inte ingår är ofta mer användbar än listan över vad som ingår. Meningen "omfattar inte integration med kundens befintliga faktureringssystem" avgör en diskussion som annars hade tagit tre möten och två e-postväxlingar. För det andra: knyt leveranserna till substantiv, inte adjektiv. "En responsiv webbplats" går att ifrågasätta, eftersom var och en har sin egen bild av vad responsiv betyder. "Åtta mallar, testade i de två senaste versionerna av fyra namngivna webbläsare" går att kontrollera med ja eller nej. För det tredje: skriv ner antagandena. Om tidplanen förutsätter att kunden återkopplar inom fem arbetsdagar, säg det, och säg vad som händer med schemat om de inte gör det. Förseningskrav är betydligt enklare att hantera när beroendet har dokumenterats från början, och ännu enklare när det står i ett dokument som båda har signerat. Låt bli att kopiera en mall och fylla i luckorna. En mall visar rubrikerna, men den kan inte säga vilka antaganden som är specifika för just ditt projekt. Det är de antagandena som oftast visar sig vara fel. ## Hur bör godkännande och ändringsbegäranden skrivas? Godkännandekriterierna besvarar en enda fråga: när är en leverans tillräckligt klar för att betalas? "Hög kvalitet" och "till kundens belåtenhet" besvarar inte frågan. Ett testbart kriterium gör det. För en datamigrering kan det till exempel vara "alla poster har överförts och en avstämningsrapport visar inga oförklarade skillnader". Lägg också till en mekanism för fingerat godkännande. Ett vanligt upplägg är att en leverans räknas som godkänd om kunden inte skickar skriftliga brister inom en bestämd period, ofta runt tio arbetsdagar. Utan en sådan regel kan kunden dröja med godkännandet, och därmed med slutfakturan, hur länge som helst. Om du är kunden bör du i stället driva på för en tydlig rättelseperiod, så att leverantören hinner åtgärda det du rapporterat. Då blir klockan rättvis för båda sidor. Ändringsbegäranden förtjänar samma omsorg. Omfattningsglidning kommer sällan som en stor förfrågan. Den kommer som tio små, som var och en verkar rimlig när den ställs. En ändringsprocess på ett stycke löser det: varje ändring av omfattning, pris eller datum kräver en skriftlig ändringsorder som signeras av båda parter innan arbetet påbörjas. Många leverantörer tappar marginal i projekt just för att SOW:et tillät muntliga överenskommelser som sedan aldrig dokumenterades. Den ändringsorder som behövs är inte särskilt lång. Den bör ange vad som ändras, vilken effekt det har på leveranser och datum, vad det kostar, och vilket SOW den hör till. Ett exempel: "Lägg till en fjärde språkversion av webbplatsen. Förlänger leveransen med fyra arbetsdagar och ökar priset enligt det fasta priset per språk." Den meningen tar en minut att skriva och sparar en lång diskussion senare. ![Handslag över en signerad mapp i ett mötesrum](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/legalysis/2026-10/dd4a94-i3.webp) ## Fast pris eller löpande räkning: vad passar ett SOW? Prisavsnittet förändrar hur risken fördelas, så välj med eftertanke. Ett fast pris lägger leveransrisken hos leverantören. Det fungerar när omfattningen är väl förstådd och sannolikt inte ändras. Det fungerar dåligt när omfattningen är otydlig, eftersom leverantören då räknar in en buffert i priset eller kämpar mot varje ändring som kommer. Löpande räkning lägger insatsrisken hos kunden. Det passar utforskande arbete, där ingen i förväg vet hur mycket tid som krävs. Men det behöver ett tak eller en maxgräns, annars är budgeten bara en åsikt om vad projektet kommer att kosta. En hybrid med fast pris per milstolpe är ofta den ärligaste kompromissen. Varje milstolpe har en egen leverans, ett eget godkännandetest och en egen faktura. Det gör SOW:et lätt att granska och lätt att stoppa om projektet börjar gå snett, eftersom du bara förlorar den milstolpe som inte blev klar. ## Var går det fel när man skriver under ett SOW? Efter att ha läst många sådana dokument återkommer samma misstag. - Man skriver under ett SOW innan huvudavtalet finns, så projektet körs utan några ansvars- eller immateriella villkor alls. - Datum lämnas som "ungefärliga" utan någon konsekvens om de missas. - Leveranser beskrivs med aktivitet ("tillhandahålla support") i stället för resultat ("svara på prioriterade ärenden inom fyra arbetstimmar"). - Dataskyddet glöms bort när leverantören ska hantera personuppgifter. Inom EU och Storbritannien innebär det oftast ett personuppgiftsbiträdesavtal vid sidan av SOW:et, och de rätta detaljerna beror på vilka jurisdiktioner som är inblandade. - Man uppdaterar aldrig SOW:et efter en muntlig ändring och förlitar sig sedan på minnet ett år senare, när någon frågar vem som bestämde vad. Det här är ingen teoretisk risk. Det är vad jurister ser regelbundet i verkliga projekt. Ingen av felen kräver juridisk briljans för att undvikas. De kräver att någon läser dokumentet långsamt innan man skriver under, och att någon ansvarar för att det uppdateras när projektet ändras. ## Vilka verktyg hjälper dig att utarbeta, signera och granska ett SOW? Verktyg skriver inte en bra omfattning åt dig, men de kan ta bort det repetitiva arbetet runt omkring den. För att skapa dokument av återanvändbara block, med godkännanden och e-signatur i samma flöde, är en dokumentplattform praktisk. För enbart signering, med spårbarhet och bred acceptans bland motparter, räcker en dedikerad e-signaturtjänst. För team som hanterar många SOW per år och behöver koppla dem till ett huvudavtal håller en plattform för avtalslivscykeln kopplingen mellan de generella villkoren och varje projektdokument. Då går det att se vilka SOW som hänger på vilket avtal utan att leta i mappar. För en första genomgång av klausulrisker i Word kan ett AI-granskningstillägg flagga saknade undantag eller motstridiga ansvarsklausuler innan en människa läser texten. Det är en sorteringshjälp, inte ett omdöme. Inget av det här ersätter en jurist när insatserna är höga. Använd programvaran för att fånga de rutinmässiga problemen, och ta allt ovanligt, stort eller gränsöverskridande till din rådgivare. Verktyget analyserar, men beslutet fattas av en människa. ## Det här gör du innan du signerar nästa SOW Tre åtgärder täcker större delen av risken. - Kontrollera att ett huvudavtal finns, och att SOW:et anger vilket dokument som gäller för juridiska villkor kontra omfattning och avgifter. - Skriv om varje leverans så att en utomstående kan avgöra, ja eller nej, om den levererats. Lägg till uttryckliga undantag och antaganden. - Bekräfta godkännandefönstret, rättelseperioden och regeln om skriftliga ändringsorder, och bifoga varje ändring till SOW:et självt. Om projektet är stort, innehåller personuppgifter eller går över gränser bör din rådgivare läsa dokumentet innan du signerar. Svaret beror på tillämplig lag, och en kort granskning kostar betydligt mindre än en tvist. ## FAQ ### Vad är skillnaden mellan ett SOW och ett huvudavtal? Huvudavtalet innehåller de generella juridiska villkoren, som ansvar, immateriella rättigheter och sekretess. Ett SOW beskriver ett enskilt projekt, med omfattning, leveranser, tidplan och pris, och hänger på huvudavtalet. ### Vilket dokument gäller om SOW:et och huvudavtalet säger olika saker? Det beror på prioriteringsklausulen i avtalet. Saknas en sådan klausul tolkas dokumenten tillsammans, och en motsägelse kan leda till tvist. Be en jurist granska avtalet om något är oklart. ### Vad måste ett statement of work innehålla? Ett SOW bör innehålla omfattning, leveranser, tidplan och milstolpar, pris och betalningsplan, godkännandekriterier, roller och beroenden samt en ändringsprocess. ### Hur lång tid ska kunden ha på sig att godkänna en leverans? Vanligt är en period runt tio arbetsdagar, med regeln att leveransen räknas som godkänd om inga skriftliga brister lämnas inom den tiden. Perioden ska stå i avtalet. ### Hur ska ändringar i ett SOW dokumenteras? Varje ändring av omfattning, pris eller datum bör göras skriftligt i en ändringsorder som signeras av båda parter innan arbetet påbörjas, och bifogas SOW:et. ### Behöver ett SOW granskas av en jurist? Vid stora belopp, personuppgifter eller gränsöverskridande projekt bör en jurist läsa dokumentet. Svaret beror på tillämplig lag, och en kort granskning är billigare än en tvist.