Funktionsudbud og systemleverancer: Placér projekteringsansvaret før udførelsen
Byggejura i praksis · Før aftalen
Gør funktionskrav, projekteringsansvar, systemgrænser og prøvning målbare, før en teknisk løsning bliver til en juridisk gråzone.
Kort svar
Et funktionskrav beskriver det resultat, anlægget eller bygningsdelen skal levere, men overlader helt eller delvist løsningen til entreprenøren. Hvis arbejdet i en AB 18-aftale er beskrevet ved funktionskrav, skal entreprenøren udføre den projektering, der er nødvendig for at opfylde kravet.
Det betyder ikke, at enhver teknisk idé eller produktvalgsdialog flytter hele projekteringsansvaret. Aftalen skal vise, hvilke funktioner entreprenøren skal projektere, hvilke forudsætninger bygherren bærer, og hvor grænserne til det øvrige projekt ligger.
Er der tale om et funktionskrav eller en foreskrevet løsning?
Et krav som “ventilationsanlægget skal sikre et bestemt luftskifte og støjniveau” peger mod en funktion. Et krav om et bestemt fabrikat, en bestemt dimension og en fuldt projekteret føringsvej peger mod en foreskrevet løsning. Mange udbud blander de to modeller.
Blandingen kan skabe konflikt, hvis den foreskrevne komponent ikke kan levere den krævede funktion. Aftalen bør derfor angive:
- hvilke resultater og tolerancer entreprenøren garanterer
- hvilke materialer eller løsninger bygherren har foreskrevet
- hvilke oplysninger entreprenøren må lægge til grund
- hvem der bærer risikoen, hvis et krav eller en forudsætning viser sig uforenelig
- hvordan uklarheder skal afklares før tilbud og udførelse.
Placér projekteringsansvaret i aftalen
Efter AB 18 § 17 skal entreprenøren kun projektere, hvis det er aftalt. Funktionskrav udløser dog den nødvendige projektering for den pågældende funktion. Entreprenørens forslag, som bygherren implementerer, flytter ikke i sig selv projekteringsrisikoen til entreprenøren.
Under ABT 18 er udgangspunktet anderledes, fordi totalentreprenøren normalt udfører al projektering. Også her skal bygherrens krav, eventuelle foreskrevne løsninger og grænseflader beskrives klart. Overskriften på entrepriseformen kan ikke erstatte en præcis ydelsesbeskrivelse.
| Spørgsmål | Aftalen bør svare |
|---|---|
| Hvad projekteres? | System, delsystem, komponent, dimensionering, styring og integration. |
| På hvilket grundlag? | Belastninger, brugerdata, myndighedskrav, eksisterende forhold og bygherreoplysninger. |
| Hvem koordinerer? | Navngiven projekteringsleder og klare informationsfrister. |
| Hvornår er ydelsen godkendt? | Dokumentleverancer, granskning, prøvning, kriterier og protokol. |
Systemleverancen slutter sjældent ved komponenten
En systemleverance afhænger ofte af strøm, netværk, plads, konstruktioner, andre tekniske anlæg, brugerdata og bygningsautomatik. Uklare grænser bliver let til ekstraarbejder eller mangler.
Brug en grænsefladematrice, der for hver forbindelse angiver:
- hvem der projekterer og leverer
- hvem der stiller data og fysiske forudsætninger til rådighed
- format, kvalitet og leveringstidspunkt
- hvem der integrerer og tester
- hvem der afhjælper, hvis den samlede funktion ikke nås.
AB 18 placerer koordineringen af det samlede projekt og fastlæggelsen af grænseflader hos bygherren, mens entreprenøren skal beskrive sit projekts forbindelse til det øvrige projekt og deltage i tværfaglig granskning. Den konkrete aftale kan supplere eller fravige dette.
Systemleverancen i underentreprisekæden
Leveres systemet af en underentreprenør eller specialleverandør, skal hovedaftalens funktions- og dokumentationskrav omsættes til en anvendelig underentreprisekontrakt. Det gælder blandt andet projekteringsydelse, systemgrænser, input fra andre fag, informationsfrister, prøvning, idriftsættelse, driftsdata, aflevering og afhjælpning.
Fristerne skal give hovedentreprenøren tid til kontrol og samlet afprøvning, før kravene skal opfyldes over for bygherren. Samtidig bør kontrakten angive, hvem der bærer risikoen, hvis andre fag ikke leverer de forudsætninger, som systemet afhænger af.
Se også guiden om underentreprise og back-to-back og Nexus’ rådgivning om udarbejdelse og gennemgang af entreprisekontrakter.
Prøvning og godkendelse skal være aftalt på forhånd
“Anlægget skal virke” er ikke et tilstrækkeligt acceptkriterium. Beskriv målemetode, målepunkt, belastning, klimaforhold, tolerance, antal forsøg og konsekvensen af et afvist resultat. Aftal også, hvem der leverer testdata, energi, adgang og medvirkende anlæg.
Entreprenørens færdigmelding af projekteringen efter AB 18 § 17 skal ledsages af resultatet af kvalitetssikringen. Bygherrens godkendelse som grundlag for det videre arbejde bør ikke forveksles med en generel overtagelse af entreprenørens projekteringsansvar.
Når forudsætningerne ændres
Ændrede brugerdata, belastninger, myndighedskrav eller grænseflader kan ændre den nødvendige løsning. Registrér straks, hvilken forudsætning der er ændret, hvem der har leveret den, og hvordan ændringen påvirker projektering, indkøb, test, pris og tid.
Behandl ændringen efter kontraktens ændringsprocedure. En teknisk godkendelse er ikke nødvendigvis en accept af merpris eller tidsfristforlængelse.
Praktisk eksempel: Kølekravet kan ikke nås
Entreprenøren skal levere en systemløsning til et serverrum ud fra et angivet kølebehov. Efter kontraktindgåelsen øger bygherren udstyrets effekt, mens den foreskrevne plads til føringsveje fastholdes. Ved testen nås temperaturkravet ikke.
Sagen kan ikke løses ved alene at spørge, om anlægget “virker”. Parterne må identificere den aftalte belastning, den ændrede forudsætning, systemgrænserne og om løsningen kan ændres. Pris og tid skal behandles samtidig med den tekniske beslutning.
Afklar. Dokumentér. Handl.
Afklar
Skeln mellem funktionskrav, foreskrevne løsninger og entreprenørens egne projekteringsvalg.
Dokumentér
Fastlæg forudsætninger, systemgrænser, leverancer, testmetoder og godkendelseskriterier.
Handl
Få uklarheder og ændringer besluttet, før projektering, indkøb eller udførelse låser løsningen.
Fem fejl, der skaber ansvarstvivl
- At kalde en ydelse “funktionsudbud” uden målbare funktionskrav.
- At foreskrive løsningen og samtidig placere hele funktionsrisikoen hos entreprenøren.
- At mangle en grænsefladematrice for systemleverancen.
- At behandle bygherrens godkendelse som overtagelse af projekteringsansvaret.
- At aftale test uden at fastlægge belastning, data og acceptkriterier.
Tjekliste til udbud og kontrakt
- Er hvert funktionskrav målbart og teknisk muligt?
- Er foreskrevne produkter og entreprenørens valgfrihed tydeligt adskilt?
- Er projekteringsydelsen og leverancerne beskrevet?
- Er grunddata, belastninger og bygherreforudsætninger oplistet?
- Er system- og faggrænser placeret?
- Er projekteringsleder, granskning og informationsfrister aftalt?
- Er prøvning, tolerancer og godkendelse beskrevet?
- Er ændringsproceduren koblet til pris og tid?
- Er drift, instruktion, data og som-udført-materiale med?
- Entreprenørprojektering og grænseflader
- Stipulerede ydelser
FAQ om funktionsudbud og systemleverancer
Skal entreprenøren altid projektere ved funktionskrav?
Efter AB 18 § 17 skal entreprenøren udføre den projektering, der er nødvendig for de funktioner, som arbejdet er beskrevet ved. Omfanget afhænger af den konkrete aftale.
Flytter et løsningsforslag projekteringsansvaret?
Ikke i sig selv. AB 18 angiver, at entreprenørens forslag, som bygherren implementerer, ikke automatisk indebærer, at entreprenøren påtager sig projekteringen eller risikoen for forslaget.
Hvem bærer de samlede grænseflader efter AB 18?
AB 18 § 17 placerer koordineringen af det samlede projekt og fastlæggelsen af grænseflader hos bygherren, mens entreprenøren har pligter for eget projekt og dets grænser. Fravigelser og entrepriseform kan ændre billedet.
Er bygherrens godkendelse en ansvarsfrihed?
Nej, ikke automatisk. Godkendelsens rækkevidde afhænger af aftalen og den konkrete meddelelse. Den bør ikke læses som en generel ansvarsoverførsel.
Hvad er den vigtigste dokumentation?
Et fælles sæt af funktionskrav, forudsætninger, grænseflader, projekteringsleverancer, testkriterier og beslutninger om ændringer.
Hvordan kobles systemleverancer og back-to-back-aftaler?
Hovedaftalens relevante funktionskrav, grænseflader, test, dokumentationskrav og tidsfrister skal oversættes til den underentreprise, hvor systemet leveres. Der skal være sammenhæng mellem kontraktleddene, men vilkårene skal tilpasses rollerne og give hovedentreprenøren tid til kontrol og videre varsling.
Kan Nexus hjælpe med kontrakter om systemleverancer?
Ja. Nexus Advokater rådgiver om udbud, kontrakter og tvister ved systemleverancer, herunder funktionskrav, entreprenørprojektering, grænseflader, accepttest og back-to-back-vilkår. Gennemgangen tager udgangspunkt i den konkrete hovedaftale, leverance og projektorganisation.
Juridisk grundlag og relateret indhold
Guiden tager navnlig udgangspunkt i AB 18 §§ 4, 12 og 16-18 samt ABT 18’s regler om totalentreprenørens projektering. Regelsættene gælder kun, hvis de er vedtaget, og konkrete fravigelser, ydelsesbeskrivelser og forudsætninger kan ændre vurderingen.
Læs også Projektgennemgang og Ekstraarbejder og aftalesedler.
Af Simon Heising, advokat (H) og partner, Nexus Advokater.
Senest opdateret 13. august 2026.
Har du brug for at få næste skridt afklaret?
Vi hjælper med at afgrænse risikoen, få dokumentationen på plads og vælge det næste konkrete skridt.
Ring til entreprisehotlinen på 31 10 22 58 · Skriv til info@nexusadvokater.dk
