Contractul de implementare ERP

Contractul de implementare ERP este un contract complex (nenumit) prin care un furnizor configurează și pune în funcțiune un sistem informatic integrat de gestiune (ERP) pentru un beneficiar, contra unui preț. Juridic, el îmbină antrepriza (art. 1851 Cod Civil), prestarea de servicii și licențierea software (Legea nr. 8/1996), plus protecția datelor (art. 28 GDPR). Punctele sensibile sunt recepția, nivelul de serviciu (SLA), migrarea datelor și clauzele de ieșire (exit).

Pe scurt

Contractul de implementare ERP este un contract complex (nenumit) prin care un furnizor se obligă să configureze, să adapteze și să pună în funcțiune un sistem informatic integrat de gestiune (ERP – Enterprise Resource Planning) pentru un beneficiar, în schimbul unui preț. Juridic, el combină elemente de antrepriză (art. 1851 și urm. Cod Civil), de prestări servicii și de licențiere software (Legea nr. 8/1996), la care se adaugă obligații de protecție a datelor (art. 28 GDPR). Punctele sensibile sunt fazele de implementare și recepția, nivelurile de serviciu (SLA), migrarea datelor, licențele terților și clauzele de ieșire (exit).

Cadrul legal

Contractul de implementare ERP nu are o reglementare proprie în dreptul român. Este un contract nenumit (complex), căruia i se aplică regulile generale ale contractelor și, prin analogie, regulile contractului cu care se aseamănă cel mai mult — de regulă antrepriza.

Art. 1168 Cod Civil — Contractul nenumit — Contractelor nereglementate de lege li se aplică prevederile prezentului capitol, iar dacă acestea nu sunt îndestulătoare, regulile speciale privitoare la contractul cu care se aseamănă cel mai mult. Sursa: Codul Civil, Legea 287/2009 (accesat 2026-08-21)

1. Antrepriza — nucleul obligației de „a face"

Obligația caracteristică a furnizorului — de a realiza o lucrare (configurarea și punerea în funcțiune a sistemului) pe riscul său — este specifică antreprizei.

Art. 1851 alin. (1) Cod Civil — Prin contractul de antrepriză, antreprenorul se obligă ca, pe riscul său, să execute o anumită lucrare, materială ori intelectuală, sau să presteze un anumit serviciu pentru beneficiar, în schimbul unui preț. Sursa: Codul Civil, art. 1851–1880 (accesat 2026-08-21)

Din regimul antreprizei (art. 1851–1880 Cod Civil) sunt relevante: obligația de informare a antreprenorului, verificarea și recepția lucrării, precum și suportarea riscului până la predare. Delimitarea față de vânzare se face după scopul principal al contractului (art. 1855 Cod Civil): dacă esența este realizarea lucrării, iar nu livrarea unui bun-standard, contractul este de antrepriză.

2. Licențierea software — Legea nr. 8/1996

Programul ERP este o operă protejată prin drept de autor. Clientul primește, de regulă, un drept de utilizare (licență), nu proprietatea codului.

Legea nr. 8/1996, Capitolul IX — Programele pentru calculator — În lipsa unei convenții contrare, printr-un contract de utilizare a unui program pentru calculator se prezumă că utilizatorului i se acordă dreptul neexclusiv de utilizare și că acesta nu poate transmite altei persoane dreptul de utilizare. Cesiunea dreptului de utilizare nu implică transferul dreptului de autor. Sursa: Legea 8/1996 (accesat 2026-08-21)

Tot din Legea nr. 8/1996 rezultă că, pentru dezvoltările „la comandă" (module făcute special pentru client), în lipsa unei clauze exprese drepturile patrimoniale pot rămâne la furnizor (regula de la programele create de angajați se aplică în raportul angajator–angajat, nu automat în raportul furnizor–client). De aceea, apartenența drepturilor asupra personalizărilor trebuie stabilită expres în contract.

3. Protecția datelor — Regulamentul (UE) 2016/679 (GDPR)

Într-o implementare ERP, furnizorul care prelucrează date cu caracter personal în numele clientului este persoană împuternicită, iar între părți trebuie încheiat un contract de prelucrare (DPA).

Art. 28 alin. (3) GDPR — Prelucrarea de către o persoană împuternicită este reglementată printr-un contract care prevede, între altele, prelucrarea numai pe baza instrucțiunilor documentate ale operatorului, confidențialitatea, securitatea prelucrării (art. 32), asistarea operatorului, precum și ștergerea sau returnarea datelor la încetarea serviciilor. Sursa: Regulament (UE) 2016/679 (accesat 2026-08-21)

La nivel național se aplică și Legea nr. 190/2018 de punere în aplicare a GDPR.

4. Regimul general al obligațiilor

• Forța obligatorie a contractului — art. 1270 Cod Civil (pacta sunt servanda);
• Buna-credință la executare — art. 1170 Cod Civil;
• Răspunderea contractuală pentru neexecutare — art. 1350 Cod Civil; forța majoră — art. 1351;
• Remedii: executarea în natură, rezoluțiunea/rezilierea și reducerea prestațiilor — art. 1516 și art. 1549–1554 Cod Civil;
• Clauza penală (evaluarea anticipată a daunelor) — art. 1538–1543 Cod Civil.

Explicație detaliată

Ce este, de fapt, un ERP și de ce contractul e „complex"

Un sistem ERP integrează într-o singură platformă procesele-cheie ale unei companii: contabilitate, stocuri, aprovizionare, producție, vânzări, resurse umane. Implementarea nu înseamnă doar „instalarea unui program", ci un proiect care presupune analiză de business, configurare, personalizări (dezvoltări la comandă), migrarea datelor din sistemele vechi, testare, instruirea utilizatorilor și punerea în producție.

Din această cauză, un singur contract acoperă mai multe tipuri de prestații:

• licențierea software-ului de bază (dreptul de a folosi ERP-ul);
• serviciile de implementare (configurare, dezvoltare, migrare) — regim de antrepriză/prestări servicii;
• mentenanța și suportul ulterior (adesea un contract-cadru pe durată nedeterminată);
• eventual găzduirea (dacă sistemul e livrat în model cloud/SaaS).

Tocmai fiindcă amestecă aceste elemente, contractul este un contract nenumit (art. 1168 Cod Civil), interpretat prin analogie cu antrepriza (art. 1851 Cod Civil) pentru partea de realizare a lucrării și cu regulile licenței (Legea nr. 8/1996) pentru partea de software.

On-premise vs. SaaS: două regimuri juridice diferite

Modelul de livrare schimbă radical drepturile părților:

• On-premise (instalat local): clientul primește o copie a programului, instalată în infrastructura proprie, și un drept de utilizare asupra acesteia; controlează mediul tehnic, datele și momentul actualizărilor.
• SaaS (Software as a Service): clientul primește acces la o platformă găzduită de furnizor; furnizorul controlează infrastructura, versiunea și actualizările, iar accesul, de regulă, încetează odată cu abonamentul.

⚠️ Opinie specialistă — avocați specializați în dreptul tehnologiei (News.ro / opinii-avocat) atrag atenția că „un simplu contract de licență nu este suficient pentru un SaaS dacă nu spune nimic despre disponibilitate, securitate sau exportul datelor". Sursa: Contractele SaaS – ce trebuie să știe juriștii și antreprenorii tech, News.ro (accesat 2026-08-21)

Fazele implementării și recepția

Un proiect ERP se derulează pe faze (analiză → configurare → dezvoltare → migrare → testare → go-live). Din perspectiva antreprizei, fiecare fază se încheie, ideal, cu o recepție parțială consemnată printr-un proces-verbal, iar proiectul se finalizează cu o recepție finală.

Recepția are efecte juridice majore:

• marchează momentul transferului riscului și, adesea, scadența plăților;
• declanșează curgerea termenelor de garanție;
• separă neconformitățile care intră în garanție de solicitările noi (care se facturează suplimentar).

De aceea, contractul trebuie să prevadă criterii de acceptanță clare (acceptance criteria) — de regulă, trecerea unui set de teste funcționale agreate — și ce se întâmplă dacă recepția este refuzată (termene de remediere, penalități, dreptul de reziliere).

Garanția: ce regim se aplică unui ERP

Nucleul contractului fiind antrepriză, antreprenorul răspunde pentru buna executare și pentru viciile lucrării, iar termenul de garanție începe să curgă de la recepție (parțială, pentru faza recepționată; finală, pentru sistemul integrat). Atenție însă la o confuzie frecventă: termenul special de garanție de 10 ani din materia construcțiilor (art. 1879-1880 Cod Civil coroborate cu Legea nr. 10/1995) este specific lucrărilor de construcții și nu se transferă unui sistem informatic. Pentru un ERP se aplică regimul general al garanției contra viciilor (inclusiv viciile ascunse), completat — și, în practică, definit — de garanția convențională din contract și din SLA (uzual 12–24 de luni de la recepția finală). De aceea durata, momentul de început și întinderea garanției trebuie stabilite expres în contract, corelate cu obligațiile de mentenanță.

Recepția într-un proiect agil

Modelul de mai sus (faze secvențiale → go-live → proces-verbal de recepție finală) reflectă o abordare de tip waterfall. Tot mai multe implementări ERP sunt însă agile/iterative (sprinturi, livrări incrementale, MVP), unde nu există un „produs finit" clar delimitat. Adaptarea juridică se face fără a părăsi regimul antreprizei:

• Recepții incrementale: fiecare sprint/increment acceptat funcționează ca o recepție parțială (recunoscută de art. 1862-1863 Cod Civil), cu criterii de acceptanță definite ca Definition of Done (funcționalitate testată, documentată).
• Transfer progresiv al riscului pe măsura recepției fiecărui increment, nu la un singur go-live.
• Scadența plăților legată de recepția tranșei (model time & material sau preț pe increment), nu de un livrabil final unic.
• Perimetru evolutiv: un mecanism contractual de ajustare a scope-ului între sprinturi, cu impact transparent pe preț și termene.

Fără aceste criterii per sprint, „gata" redevine o chestiune de opinie și apar litigii pe scadența plăților — de aceea Definition of Done și lista de teste trebuie anexate contractului.

Nivelurile de serviciu (SLA)

Pentru partea de disponibilitate, suport și mentenanță, contractul include un SLA (Service Level Agreement) care cuantifică obligațiile furnizorului: procent de disponibilitate (uptime), timpi de răspuns și de rezolvare pe categorii de incidente (critic/major/minor), ferestre de mentenanță și penalități (adesea sub formă de credite de serviciu) pentru nerespectare. Aceste penalități funcționează juridic ca o clauză penală (art. 1538 Cod Civil).

Este esențial ca SLA-ul să distingă tipurile de modificări ale sistemului — actualizări de securitate, îmbunătățiri obișnuite și schimbări care elimină o funcție importantă — pentru că o clauză care permite furnizorului „să modifice serviciul oricând și în orice mod" este prea largă și dezechilibrată.

Migrarea datelor și riscul de vendor lock-in

Migrarea datelor din sistemele vechi este una dintre cele mai riscante faze: erori de mapare, pierderi de date istorice sau duplicate pot bloca activitatea. Contractul trebuie să stabilească responsabilitățile (cine curăță și validează datele), criteriile de succes ale migrării și răspunderea pentru erori.

La fel de important este dreptul de a-ți exporta datele la încetarea contractului, într-un format utilizabil. În lipsa lui, clientul rămâne dependent de furnizor — fenomenul de vendor lock-in — fără posibilitatea reală de a migra la alt sistem.

Licențele terților

Un ERP înglobează frecvent componente ale unor terți (baze de date, sisteme de operare, module de raportare, biblioteci open source). Contractul trebuie să clarifice cine achiziționează și cine plătește aceste licențe, dacă prețul lor este inclus sau separat și cum se transferă ele clientului. Nedeclararea corectă a licențelor terților expune clientul la riscul de audit de licențiere și la costuri neprevăzute.

Clauzele de ieșire (exit)

Fiind un contract de durată și cu miză critică pentru operațiuni, contractul trebuie să reglementeze ieșirea: notificarea, asistența de tranziție (exit assistance) către client sau către un nou furnizor, predarea documentației și a configurațiilor, exportul și ștergerea datelor, precum și soarta licențelor și a personalizărilor. Pentru codul-sursă al dezvoltărilor critice se recurge uneori la un escrow (depozitarea codului la un terț, eliberat la anumite evenimente — insolvență, încetarea suportului).

Aspecte practice

Clauze care nu ar trebui să lipsească

• Obiectul și perimetrul (scope): descrierea exactă a modulelor, proceselor și personalizărilor. Un scope vag este principala sursă de litigii („asta nu era în contract").
• Plan de proiect pe faze, cu jaloane (milestones), livrabile și recepții parțiale prin proces-verbal.
• Criterii de acceptanță și procedura de recepție (teste, termene de remediere, ce se întâmplă la refuz).
• Licența: tip (neexclusivă/exclusivă), număr de utilizatori, teritoriu, durată; regimul actualizărilor.
• Proprietatea asupra personalizărilor și a codului dezvoltat la comandă — stabilită expres (cesiune de drepturi patrimoniale către client sau licență).
• SLA cu indicatori măsurabili și penalități/credite de serviciu.
• DPA (contract de prelucrare a datelor) conform art. 28 GDPR, dacă se prelucrează date personale.
• Migrarea datelor: responsabilități, criterii de succes, răspundere pentru erori.
• Clauze de exit: asistență de tranziție, export și ștergere date, escrow pentru cod (după caz).
• Limitarea răspunderii: plafon (de regulă raportat la valoarea contractului) și excluderi — negociate echilibrat, dar în limita imperativă a art. 1355 Cod Civil: plafoanele și excluderea daunelor indirecte sunt valabile doar pentru culpa ușoară; ele nu pot înlătura sau limita răspunderea pentru prejudiciul cauzat cu intenție (dol) sau din culpă gravă (ex. pierderea iremediabilă a datelor prin neglijență flagrantă), iar clauzele care exclud răspunderea pentru integritatea fizică/sănătate sunt lovite de nulitate.
• Change request: mecanism formal de modificare a perimetrului, cu impact pe preț și termene.

Greșeli frecvente

• Confundarea licenței cu serviciile. Un contract care reglementează doar dreptul de a folosi programul, dar tace despre implementare, migrare, SLA și exit, lasă clientul descoperit exact acolo unde apar problemele.
• Lipsa criteriilor de acceptanță. Fără teste agreate, „gata" devine o chestiune de opinie, iar plata și garanția rămân în aer.
• Neclarificarea drepturilor asupra personalizărilor. Clientul plătește dezvoltări la comandă, dar descoperă că nu le poate refolosi sau muta la alt furnizor.
• Ignorarea licențelor terților — costuri și riscuri de audit descoperite după go-live.
• DPA absent sau formal. Politica de confidențialitate nu ține loc de contract de prelucrare (art. 28 GDPR); la un control ANSPDCP, lipsa lui este o neconformitate.
• Clauze de exit inexistente — vendor lock-in: clientul nu-și poate recupera datele într-un format utilizabil.
• Clauză de modificare a serviciului „oricând, oricum" — dezechilibrată, mai ales când sunt afectate funcții esențiale.

Recomandări de negociere

• Din perspectiva clientului: insistă pe criterii de acceptanță obiective, pe dreptul de export al datelor, pe proprietatea/licența personalizărilor și pe penalități reale în SLA; negociază plafonul și excluderile de răspundere.
• Din perspectiva furnizorului: definește clar perimetrul și dependențele de la client (date, acces, decizii), leagă plățile de recepții și include un mecanism ferm de change request pentru a evita „scope creep".
• Pentru ambele părți: un capitol distinct de modificare a contractului și o clauză de mediere/escaladare reduc riscul de blocaj pe un proiect de lungă durată.

⚠️ Opinie specialistă — pe JURIDICE.ro se subliniază că, la contractele de durată, orice intervenție asupra clauzelor „trebuie realizată numai cu acordul părților semnatare", altfel lucrările suplimentare pot să nu fie recunoscute de beneficiar și pot conduce chiar la rezilierea unilaterală. Sursa: Etapele procesului de modificare a contractului, JURIDICE.ro (accesat 2026-08-21)

Aspecte avansate: fiscal, insolvență, securitate cibernetică, achiziții publice și drept internațional privat

Implementarea unui ERP ridică, dincolo de dreptul contractelor, o serie de probleme conexe cu miză economică și de conformare majoră. Le tratăm punctual mai jos.

Regimul fiscal: licență vs. servicii, TVA și reținerea la sursă

Fiscal, contractul trebuie defalcat pe componente, pentru că regimul diferă:

• Licența/software-ul achiziționat este o imobilizare necorporală amortizabilă — se deduce prin amortizare pe durata de utilizare, conform art. 28 din Codul fiscal (Legea nr. 227/2015), nu integral în anul plății.
• Serviciile de implementare (configurare, migrare, instruire) sunt, de regulă, cheltuieli deductibile în perioada efectuării, dacă nu majorează valoarea imobilizării.

Când licențele se plătesc unui furnizor nerezident (SAP, Oracle etc.), plata poate fi calificată drept redevență (art. 7 pct. 36 Cod fiscal) și devine venit impozabil obținut din România supus impozitului cu reținere la sursă — art. 223 alin. (1) Cod fiscal, cotă internă 16% (art. 224). Convențiile de evitare a dublei impuneri pot reduce cota (frecvent 0–10%), dar numai dacă furnizorul prezintă certificatul de rezidență fiscală. La achiziția de servicii electronice de la un nerezident (B2B), locul prestării este la beneficiar (art. 278 Cod fiscal), aplicându-se taxarea inversă — beneficiarul român autoevaluează TVA la cota standard de 21% (majorată de la 19% prin Legea nr. 141/2025, în vigoare de la 1 august 2025).

Sursa: Codul fiscal, Legea nr. 227/2015, art. 28, 223, 224 (accesat 2026-08-21)

Insolvența furnizorului: escrow, acces la date și clauzele „ipso facto"

Dacă furnizorul ERP intră în insolvență (Legea nr. 85/2014), soarta sistemului este guvernată de art. 123 (contractele în derulare). Reguli esențiale:

• Contractele se consideră menținute la deschiderea procedurii; administratorul judiciar poate menține sau denunța contractul pentru maximizarea averii debitorului. Cocontractantul îl poate notifica să opteze, iar tăcerea timp de 30 de zile echivalează cu denunțarea.
• Clauzele de reziliere automată la insolvență (clauze „ipso facto") sunt nule — art. 123 alin. (1) le lipsește de efect; o clauză „contractul se reziliază de drept la deschiderea insolvenței furnizorului" nu este opozabilă procedurii.
• În modelul SaaS, escrow-ul codului-sursă este insuficient fără infrastructura de găzduire. De aceea clientul trebuie să prevadă contractual, ca obligații distincte, dreptul de acces și export imediat al datelor și, ideal, continuitatea găzduirii (escrow „operațional" la un terț), nu doar depozitarea codului.

Sursa: Legea nr. 85/2014, art. 123 (accesat 2026-08-21)

Securitate cibernetică: NIS2 și DORA se propagă către furnizor

Obligațiile de securitate cibernetică nou-intrate în vigoare se transmit contractual către furnizorul ERP:

• NIS2 — Directiva (UE) 2022/2555, transpusă în România prin OUG nr. 155/2024 (aprobată cu modificări prin Legea nr. 124/2025; autoritate: DNSC). Dacă beneficiarul este entitate esențială sau importantă, are obligații de gestionare a riscurilor care includ securitatea lanțului de aprovizionare (art. 21 din Directivă) — adică trebuie să impună clauze de securitate furnizorului ERP (măsuri tehnice, notificarea incidentelor, drept de audit).
• DORA — Regulamentul (UE) 2022/2554 (aplicabil din 17 ianuarie 2025). Când beneficiarul este entitate financiară care externalizează un serviciu TIC critic (un ERP poate fi astfel), art. 28-30 impun cerințe contractuale stricte față de prestatorul terț: drepturi de audit și acces, notificarea incidentelor, condiții de subcontractare și strategii de ieșire.

Sursa: Directiva (UE) 2022/2555 (NIS2) · Regulamentul (UE) 2022/2554 (DORA) · transpunere RO: OUG 155/2024 / Legea 124/2025 (accesat 2026-08-21)

Beneficiar entitate publică: regimul Legii nr. 98/2016

Când beneficiarul este o autoritate contractantă, achiziția ERP intră sub Legea nr. 98/2016, cu consecințe majore:

• Nu există negociere liberă a clauzelor — regula este atribuirea prin procedură (licitație deschisă), cu clauze prestabilite în documentația de atribuire.
• Modificarea contractului este strict reglementată (art. 221): sunt permise doar modificările nesubstanțiale și cele de minimis (sub 10% din preț pentru servicii/produse, 15% pentru lucrări); modificările substanțiale sunt interzise (art. 221 alin. (7)) și impun o nouă procedură.
• Impact asupra change request și exit: solicitările de modificare a perimetrului trebuie să încapă în limitele art. 221, iar rezilierea urmează regimul art. 222-223 — flexibilitatea tipică a contractelor private nu este disponibilă.

Sursa: Legea nr. 98/2016, art. 221 (accesat 2026-08-21)

Furnizor nerezident: legea aplicabilă și instanța competentă

Marii furnizori ERP fiind nerezidenți, contractul are dimensiune de drept internațional privat:

• Legea aplicabilă — Regulamentul (CE) nr. 593/2008 (Roma I): părțile pot alege legea (art. 3), iar clauzele-tip ale furnizorilor globali (ex. „legea Angliei") sunt, în principiu, valabile; în lipsa alegerii se aplică legea prestatorului caracteristic (art. 4).
• Norme de aplicație imediată (art. 9 Roma I): anumite dispoziții imperative române rămân aplicabile indiferent de legea aleasă — în special GDPR și Legea nr. 190/2018, precum și, dacă beneficiarul e consumator, protecția consumatorului. O clauză „legea străină" nu înlătură obligațiile GDPR ale operatorului din România.
• Instanța competentă — Regulamentul (UE) nr. 1215/2012 (Bruxelles I bis): clauzele atributive de competență (art. 25) sunt, de regulă, valabile și obligatorii; în lipsa lor operează forurile legale (domiciliul pârâtului, locul executării).

Sursa: Regulamentul (CE) nr. 593/2008 (Roma I) · Regulamentul (UE) nr. 1215/2012 (Bruxelles I bis) (accesat 2026-08-21)

Legislație europeană

Contractul de implementare ERP nu are o reglementare unitară la nivelul UE, dar se așază la intersecția a patru corpuri de drept european: protecția software-ului (drept de autor), conformitatea serviciilor digitale, protecția datelor și, pentru soluțiile în cloud, portabilitatea și schimbarea furnizorilor.

Directive și regulamente aplicabile

Directiva 2009/24/CE privind protecția juridică a programelor pentru calculator — programele se protejează prin drept de autor ca opere literare (art. 1). Titularul are drepturi exclusive de reproducere, adaptare și distribuire (art. 4), însă prima vânzare a unei copii în UE epuizează dreptul de distribuție asupra acelei copii (art. 4 alin. 2). Dobânditorul legal poate reproduce/adapta programul în măsura necesară utilizării, inclusiv corectarea erorilor, iar copia de rezervă nu poate fi interzisă prin contract (art. 5); decompilarea este permisă strict pentru interoperabilitate (art. 6). Sursa: Directiva 2009/24/CE (accesat 2026-08-21)

Directiva (UE) 2019/770 privind contractele de furnizare de conținut digital și de servicii digitale — stabilește standardul de conformitate și obligația de actualizare pentru servicii digitale (inclusiv soluții de tip SaaS), precum și regimul „plății cu date personale". Domeniul ei este comerciant–consumator (B2C). Sursa: Directiva (UE) 2019/770 (accesat 2026-08-21)

Regulamentul (UE) 2016/679 (GDPR) — art. 28 (persoana împuternicită) și art. 32 (securitatea prelucrării); pentru transferurile către state terțe (subcontractanți cloud non-UE) se aplică art. 44-46 (clauze contractuale standard). Sursa: Regulamentul (UE) 2016/679 (accesat 2026-08-21)

Regulamentul (UE) 2023/2854 (Data Act) — aplicabil de la 12 septembrie 2025. Capitolul VI (art. 23-31) obligă furnizorii de servicii de prelucrare a datelor (cloud/edge) să elimine obstacolele comerciale, tehnice, contractuale și organizatorice care împiedică schimbarea furnizorului, impunând un conținut minim al contractului (preaviz, perioadă de tranziție, date portabile, echivalență funcțională, ștergerea datelor). Taxele de trecere sunt reduse până la 12 ianuarie 2027 și interzise ulterior. Sursa: Regulamentul (UE) 2023/2854 (accesat 2026-08-21)

Transpunerea în dreptul român

• Directiva 2009/24/CE este transpusă prin Capitolul IX din Legea nr. 8/1996 (programele pentru calculator) — vezi cadrul legal. Legea română reproduce fidel regimul UE: licență (drept de utilizare) neexclusivă în lipsa unei clauze contrare, dreptul la copie de rezervă și corectarea erorilor de către dobânditorul legitim, decompilarea pentru interoperabilitate. Nu există gold-plating semnificativ.
• Directiva (UE) 2019/770 este transpusă prin OUG nr. 141/2021 (în vigoare de la 1 ianuarie 2022; transpunere cu întârziere — termenul UE fusese 1 iulie 2021). Fiind un regim B2C, nu se aplică direct unui contract ERP între profesioniști, dar devine relevant dacă beneficiarul este consumator; perechea sa este OUG 140/2021 (Directiva 2019/771, „bunuri cu elemente digitale").
• GDPR se aplică direct, completat de Legea nr. 190/2018.
• Data Act este regulament — direct aplicabil, fără transpunere; în România este în pregătire legea de aplicare (desemnare autorități competente, prin ANCOM și ministerul de resort).

Jurisprudență CJUE

Cauza C-128/11, UsedSoft GmbH / Oracle (2012) — epuizarea dreptului de distribuție (art. 4 alin. 2 Dir. 2009/24) se aplică și copiilor descărcate online; titularul unei licențe pe durată nedeterminată poate revinde copia, iar noul dobânditor devine „dobânditor legal", cu condiția ca vânzătorul să-și dezactiveze copia. Sursa: CJUE, C-128/11 (accesat 2026-08-21)

Cauza C-406/10, SAS Institute / World Programming (2012) — funcționalitatea unui program, limbajul de programare și formatul fișierelor de date nu sunt protejate, ca atare, de dreptul de autor asupra programului; se protejează doar exprimarea (codul). Sursa: CJUE, C-406/10 (accesat 2026-08-21)

Cauza C-311/18, „Schrems II" (2020) — clauzele contractuale standard rămân valabile pentru transferul de date către state terțe, dar exportatorul trebuie să evalueze nivelul de protecție și să adopte măsuri suplimentare acolo unde este necesar. Sursa: CJUE, C-311/18 (accesat 2026-08-21)

Aspecte practice din perspectivă europeană

• Licențiere și revânzare: din UsedSoft, o licență perpetuă poate fi, în principiu, revândută — o clauză contractuală de interdicție totală a transferului trebuie evaluată prin prisma epuizării dreptului; invers, modelul SaaS (abonament) nu declanșează epuizarea.
• Interoperabilitate și exit: SAS Institute confirmă că formatele de date și funcționalitatea nu sunt „proprietatea" furnizorului — un argument util pentru clauzele de portare a datelor și de integrare cu alte sisteme. Pentru ERP-ul în cloud, Data Act (Cap. VI) transformă portabilitatea și schimbarea furnizorului într-o obligație legală, cu eliminarea treptată a taxelor de switching — de aliniat cu clauzele de ieșire și SLA.
• Transfer internațional de date: dacă infrastructura ERP sau subcontractanții cloud sunt în afara UE/SEE, contractul de prelucrare (art. 28 GDPR) trebuie completat cu clauze contractuale standard și evaluarea Schrems II.
• Conformitatea serviciului digital: chiar și în B2B, standardul din Directiva 2019/770 (conformitate, actualizări) este un reper de bună practică pentru redactarea SLA și a obligațiilor de mentenanță.

Întrebări frecvente

Ce fel de contract este contractul de implementare ERP? Este un contract nenumit (complex), care combină elemente de antrepriză (realizarea lucrării de implementare), prestări servicii, licențiere software și, adesea, găzduire. I se aplică regulile generale ale contractelor (art. 1168 Cod Civil) și, prin analogie, regulile antreprizei (art. 1851 și urm. Cod Civil).

Cine deține drepturile asupra personalizărilor plătite de client? Depinde de ce prevede contractul. Programul de bază rămâne al furnizorului, iar clientul primește o licență de utilizare (Legea nr. 8/1996). Pentru dezvoltările „la comandă", drepturile patrimoniale trebuie cesionate expres clientului; în lipsa unei clauze clare, ele pot rămâne la furnizor.

Am nevoie de un contract separat de protecție a datelor (DPA)? Da, dacă furnizorul prelucrează date cu caracter personal în numele tău. Art. 28 GDPR impune un contract de prelucrare care să reglementeze instrucțiunile, confidențialitatea, securitatea, subcontractarea și ștergerea/returnarea datelor. Politica de confidențialitate nu îl înlocuiește.

Ce este recepția și de ce contează? Recepția (parțială și finală), consemnată prin proces-verbal, marchează finalizarea lucrării, transferul riscului, adesea scadența plății și începutul garanției. Fără criterii de acceptanță clare, este greu de dovedit că sistemul funcționează conform așteptărilor.

Ce se întâmplă cu datele mele la încetarea contractului? Contractul ar trebui să îți garanteze exportul datelor într-un format utilizabil, un termen de disponibilitate și ștergerea ulterioară. Absența acestor clauze creează dependență de furnizor (vendor lock-in).

Ce este un SLA și ce ar trebui să conțină? Un Service Level Agreement stabilește nivelul de serviciu: disponibilitate (uptime), timpi de răspuns și de rezolvare a incidentelor, ferestre de mentenanță și penalități (credite de serviciu) pentru nerespectare — care funcționează ca o clauză penală (art. 1538 Cod Civil).

Ce sunt licențele terților și de ce sunt importante? ERP-ul poate include componente ale altor producători (baze de date, module de raportare). Contractul trebuie să spună cine le achiziționează și le plătește, pentru a evita costuri neprevăzute și riscuri la un audit de licențiere.

Practică și opinii

⚠️ Opinie specialistă — practicieni în dreptul tehnologiei (ZIC Legal) subliniază distincția juridică esențială între modelele de livrare: în aplicația clasică (on-premise) clientul primește „un drept de utilizare asupra unei copii a programului", pe când în SaaS primește „acces la o platformă găzduită de furnizor", care controlează infrastructura și actualizările. Consecința practică: clauzele de disponibilitate, securitate și export al datelor devin obligatorii în SaaS. Sursa: Contracte SaaS vs. aplicații clasice, ZIC Legal (accesat 2026-08-21)

⚠️ Opinie specialistă — aceiași practicieni avertizează asupra clauzelor de limitare a răspunderii, „aproape întotdeauna prezente în contractele SaaS", care exclud daunele indirecte (ex. pierderea de profit). O formulare prea generală „poate lăsa clientul fără niciun recurs real" și trebuie negociată. Sursa: Contractele SaaS, News.ro / opinii-avocat (accesat 2026-08-21)

Limita legală imperativă a plafoanelor de răspundere. Dincolo de negociere, aceste plafoane au o graniță pe care contractul nu o poate depăși: art. 1355 Cod Civil interzice înlăturarea sau limitarea răspunderii pentru prejudiciul cauzat cu intenție (dol) sau din culpă gravă, iar clauzele care exclud răspunderea pentru integritatea fizică ori sănătate sunt nule. Un plafon „standard" (ex. cap la valoarea contractului pe 12 luni) rămâne valabil pentru culpa ușoară, dar cade în măsura în care furnizorul a acționat cu culpă gravă — de pildă pierderea iremediabilă a datelor prin neglijență flagrantă (lipsa oricărui backup, ignorarea unui incident notificat). „Culpa gravă" se apreciază in concreto, ca neglijență pe care nici cel mai neîngrijit profesionist nu ar comite-o.

Sursa: Codul Civil, art. 1355 (accesat 2026-08-21)

Din practica achizițiilor. Modelele de contract pentru achiziția și implementarea de soluții ERP consacră recepția prin proces-verbal semnat de comisia de recepție a beneficiarului și de furnizor, precum și interdicția transferului total sau parțial al obligațiilor contractuale către terți fără acord. Deși provin din zona achizițiilor publice, aceste clauze reflectă bune practici transferabile și în contractele comerciale private.

Sursa: Model contract achiziție soft ERP, romarm.ro (accesat 2026-08-21)

Referințe

1. Codul Civil (Legea nr. 287/2009), republicat în Monitorul Oficial nr. 505 din 15 iulie 2011 — art. 1168 (contract nenumit), art. 1170 (buna-credință), art. 1270 (forța obligatorie), art. 1350–1351 (răspundere, forță majoră), art. 1516 și 1549–1554 (remedii), art. 1538–1543 (clauza penală), art. 1851–1880 (antrepriză). legislatie.just.ro
2. Legea nr. 8/1996 privind dreptul de autor și drepturile conexe — Capitolul IX, Programele pentru calculator (drepturi patrimoniale, contract de utilizare/licență, acte permise dobânditorului legitim). legislatie.just.ro
3. Regulamentul (UE) 2016/679 (GDPR) — art. 28 (persoana împuternicită de operator) și art. 32 (securitatea prelucrării). eur-lex.europa.eu
4. Legea nr. 190/2018 privind măsuri de punere în aplicare a Regulamentului (UE) 2016/679. legislatie.just.ro
5. ⚠️ „Contractele SaaS: ce trebuie să știe juriștii și antreprenorii tech despre software-ul ca serviciu" — News.ro (opinii-avocat). news.ro
6. ⚠️ „Contracte SaaS vs. aplicații clasice — diferențe juridice" — ZIC Legal. zic.legal
7. ⚠️ „Etapele procesului de modificare a contractului" — JURIDICE.ro. juridice.ro
8. Model „Contract achiziție soft ERP și servicii adiacente" — romarm.ro. romarm.ro
9. Codul fiscal (Legea nr. 227/2015) — art. 28 (amortizarea imobilizărilor necorporale), art. 223 și 224 (venituri ale nerezidenților, redevențe, reținere la sursă), art. 278 (locul prestării serviciilor / taxare inversă). legislatie.just.ro
10. Legea nr. 85/2014 privind procedurile de prevenire a insolvenței și de insolvență — art. 123 (contractele în derulare; nulitatea clauzelor „ipso facto"). legislatie.just.ro
11. Legea nr. 98/2016 privind achizițiile publice — art. 221 (modificarea contractului; interdicția modificărilor substanțiale). legislatie.just.ro
12. Directiva (UE) 2022/2555 (NIS2) — securitatea rețelelor și sistemelor informatice; art. 21 (gestionarea riscurilor, securitatea lanțului de aprovizionare). Transpusă în România prin OUG nr. 155/2024, aprobată cu modificări prin Legea nr. 124/2025 (autoritate: DNSC). eur-lex.europa.eu
13. Regulamentul (UE) 2022/2554 (DORA) — reziliența operațională digitală a sectorului financiar; art. 28-30 (prestatori terți de servicii TIC). eur-lex.europa.eu
14. Regulamentul (CE) nr. 593/2008 (Roma I) — legea aplicabilă obligațiilor contractuale; art. 3, 4, 9 (autonomie, lege supletivă, norme de aplicație imediată). eur-lex.europa.eu
15. Regulamentul (UE) nr. 1215/2012 (Bruxelles I bis) — competența judiciară; art. 25 (clauze atributive de competență). eur-lex.europa.eu