ІТ-бізнес повинен заробляти, але буває так, що через пробіли або помилки в контракті він натомість має збитки. Це може бути як упущена вигода, так і штрафи, які подекуди сягають мільйонів доларів.

У своїй колонці СЕО Tretten Lawyers Максим Носарєв перерахував 5 пунктів ІТ-контакту, відсутність яких може вилитись у фінансові втрати для ІТ-компанії. А також розповів, як усунути або повністю нівелювати ризики. 

Процедура прийняття інвойсу

Оплата послуг ІТ-компаній відбувається через інвойс. Тому дуже важливо, щоб процедура його прийняття й оплати була чітко визначена в договорі із замовником.

Я нерідко бачив договори, в яких положення про прийняття інвойсу взагалі відсутні або процедура описана з помилками. Нижче — найпоширеніші з них і чим вони небезпечні:

  1. У договорі відсутні терміни, в які клієнт має розглянути інвойс і прийняти або відхилити його. Або ж прописаний термін оплати, але не уточнюється, з якого моменту починається відлік часу: з виставлення інвойсу чи з моменту його прийняття. Таке формулювання дає змогу клієнту ігнорувати ваш інвойс, затягуючи оплату за надані послуги. Крім того, в ІТ-компанії відсутні важелі впливу на клієнта, щоб змусити його заплатити.
  2. У договорі визначено, що з моменту виставлення інвойсу клієнт має, скажімо, 15 днів на те, щоб його прийняти або оскаржити. Здавалося б, все ок, але насправді ні. Тому що ми прописали лише два варіанти розгортання подій — клієнт може прийняти або відхилити інвойс. Але що буде, якщо він не дасть жодної відповіді? Як-то кажуть, дивись пункт перший. Тому, щоб клієнт не міг безкарно затягувати оплату, нам потрібно також прописати, що якщо протягом цих 15 днів клієнт не висловлює ані прийняття, ані заперечення, то інвойс автоматично вважається прийнятим.

Таким чином, ми страхуємо себе від затримки оплати, а заразом усуваємо зайву бюрократію, тому що добросовісному клієнту не доведеться кожного разу формально повідомляти вас про те, що інвойс прийнятий.

Автоматичний перегляд рейтів

Здавалося б, очевидна річ, але тут знову ж таки є нюанси і вони можуть боляче вдарити по майбутній маржі ІТ-компанії. 

У договорі питання перегляду рейтів може бути а) взагалі не врегульовано, б) прописано, що зміна рейтів здійснюється за загальною згодою сторін. І перше, і друге означає, що про підвищення рейтів нам кожного разу необхідно домовлятися з клієнтом індивідуально, і без його формальної згоди підняття рейтів неможливе. 

Виникає незручна ситуація. Зрозуміло, що ІТ-компанії очікують на перегляд рейтів (як правило, раз на рік), а їхні контрагенти не зацікавлені платити більше. І якщо клієнт не хоче піднімати рейти, компанія не має жодних механізмів впливу на нього, окрім розірвання договору. Як наслідок — втрата коштів або через інфляцію (витрати зростають, а доходи — ні), або через припинення співпраці з клієнтом.

Тому я раджу передбачити автоматичний перегляд рейтів на щорічній основі. Ось як прописати це в контракті правильно:

  • Взяти за орієнтир індекс споживчих цін із привʼязкою до валюти. Наприклад, якщо валютою договору є USD, то беремо індекс споживчих цін у США, якщо EUR — відповідно у ЄС. Чому саме ІСЦ? Тому що, по суті, це — індексація. Ми підвищуємо рейти на відсоток, на який зростають ціни на споживчі товари в обраній країні. Зазвичай це 3–7%. І це справедливе і обгрунтоване зростання, яке навряд чи викличе заперечення з боку замовника.
  • Якщо індекс інфляції відʼємний, рейти не зменшуються. Хоч дефляція відбувається дуже рідко, варто чітко прописати, що, згідно з нашим договором, рейти тільки зростатимуть. 
  • Підняття відбувається автоматично і не потребує додаткових документів. Достатньо просто проінформувати контрагента, що з наступного місяця рейт підвищується, умовно, на 3% і виставляти інвойс вже за збільшеними рейтами.
  • Момент підвищення рейтів. Як правило, це відбувається з 1 січня наступного календарного року — і це ок, якщо ми підписуємо договір у першій половині року. Але якщо ми підписали його наприкінці листопада, то збільшувати рейти вже через два місяці не дуже етично. 

Порада: якщо ви підписуєте договір у другій половині року, ми рекомендуємо передбачити відтермінування автоматичного перегляду рейтів на 6 місяців після підписання. Тобто підписали договір до кінця липня — рейти змінюємо в січні, підписали в грудні — рейти змінюємо у травні наступного року. 

Прописавши ці моменти, ми уникаємо ситуації, коли ІТ-компанія роками працює з клієнтом, з яким не хоче припиняти співпрацю, але при цьому не може підняти рейти через відсутність такої процедури в договорі. Натомість ми автоматизуємо справедливе підняття рейтів, звільняючи сторони від зайвих формальностей. 

Ліміт відповідальності

Уявімо, що через якийсь баг у коді компанія замовника понесла збитки. Наприклад, впав сайт, і клієнт, за його оцінками, недоотримав замовлень на $10 млн. Вгадайте, до кого він піде за відшкодуванням у такому випадку? 

Щоб уникнути неприємностей, дуже важливо прописати в договорі пункт про ліміт відповідальності. Він передбачає, що:

  1. ІТ-компанія не несе відповідальності за непрямі збитки та упущену вигоду;
  2. Якщо це прямі збитки, ліміт відповідальності ІТ-компанії обмежується прописаною сумою (як правило, не більше ніж клієнт заплатив вам за ваші послуги).

Що виходить? Завдяки ліміту відповідальності ви вже не маєте сплатити ті $10 млн, тому що це — упущена вигода, а не прямі збитки!

Припустимо, стається інша прикрість. Ваш код зламав клієнту архітектуру вартістю $10 млн. На жаль, це вже прямі збитки. Повертаємося до нашого контракту, де ми обмежили ліміт відповідальності сумою, яку ми отримали від клієнта в рамках проєкту. Нехай клієнт заплатив нам $500 000 за наш код. Отже, ми винні йому лише цю суму. Вимагати від нас більше клієнт не може.

А якби ми не прописали ліміт відповідальності (зокрема пункт 2), то довелося б заплатити $10 млн.

Що робити, якщо дуже важливий клієнт вимагає безлімітну відповідальність? Найкраще на таке не погоджуватися. Але якщо це не варіант, дуже раджу передбачити такі пункти:

  1. Встановити чіткий перелік випадків, коли буде застосовуватися безлімітна відповідальність. Наприклад, збитки завдані здоровʼю чи життю людини, збитки, що виникли внаслідок порушення прав конфіденційності та інтелектуальної власності. Можна розширити перелік у межах цієї логіки. Головне, не погоджуватись на все.
  2. Прописати можливість відреагувати. Наприклад, клієнт вказав вам на порушення в сфері інтелектуальної власності, яке підпадає під вищезазначений перелік. Але перед тим, як застосовувати до вас нелімітовану відповідальність, він зобовʼязується дати вам можливість виправити ситуацію. Важливо прописати, що на це має відводитися певний час, скажімо, два місяці. Якщо збиток не виправлено, то лише після того контрагент має право застосовувати до ІТ-компанії нелімітовану відповідальність.
  3. Застрахувати свою професійну відповідальність у брокера на той перелік випадків, який визначили в пункті 1. Тож якщо вже станеться ситуація, коли клієнт отримає право стягнути з вас $10 млн, їх вам покриє страховка! Головне, уважно вичитати страховий поліс (бо там свої нюанси).

Заборона на переманювання

Розробники — це наш головний ресурс. Тож, думаю, всім зрозуміло, які збитки загрожують ІТ-компанії за відсутності пункту про непереманювання в договорі. Він обовʼязково має бути, і добре пропрацьований, оскільки помилки тут можуть дорого обійтися.

Помилка №1

Я часто зустрічав в ІТ-контрактах таке формулювання: «переманювання забороняється на час дії контракту». Звучить логічно, але що заважає клієнту достроково припинити дію договору або ж дочекатися завершення його строку дії і, замість того щоб продовжити працювати з вами — просто забрати собі всю вашу команду? 

Тому я рекомендую зафіксувати заборону на переманювання протягом терміну дії договору плюс якийсь час після його закінчення — мінімум пів року, а краще рік чи більше. А ще обовʼязково пропишіть відповідальність за порушення, інакше заборона залишиться формальністю і в реальності не матиме наслідків. 

Помилка №2

Часто ми бачимо в договорах фіксовану суму штрафу, наприклад, $50 000 чи $100 000, але я не рекомендую так робити. Клієнт може переманити джуна, і тоді це окупиться, але що як він забере собі архітектора? Щоб це було справедливо стосовно як до компанії, так і до клієнта, краще робити привʼязку до рейту. Я рекомендую встановлювати штрафи за переманювання в розмірі 12-місячного рейту, який клієнт платить за спеціаліста.

Клієнту не подобаються суворі вимоги до непереманювання. Що робити? 

  • Можна прописати терміни, в які клієнт, якого піймали на переманюванні, має змогу відкликати свій офер вашому спеціалісту — і тоді штраф до нього не застосовується. 
  • Прописати buy out — це процедура, коли ІТ-компанія офіційно надає згоду на те, щоб спеціаліста «викупили». Тобто, ми розуміємо, що для клієнта ця людина дуже важлива, і ми можемо погодитися на те, що клієнт забере її собі в штат, але ми отримаємо за це винагороду. Рекомендую встановити цю суму на рівні 3–6 місячного рейту.

Це компроміс, на який ви можете піти в договорі. Якщо клієнту цього недостатньо, раджу подумати двічі, чи потрібен вам цей клієнт.

Врегулювання суперечок

В ідеальному світі, де немає війн, пандемій і росії, ІТ-компанія та її клієнт будуть найкращими партнерами і ніколи не висуватимуть один одному претензій. На жаль, як ми всі знаємо, росія є, а отже, і решта світу не ідеальна. Тому, як-то кажуть, сподіваймося на краще, але готуймось до гіршого. 

У будь-якому договорі обовʼязково є пункт про врегулювання суперечок. Якщо це шаблон нашого контрагента, то зазвичай в ньому буде вказана його «домашня» юрисдикція: суд штату Делавер, Лондонський Міжнародний Арбітраж, суди Ер-Ріяда тощо залежно від того, де базується клієнт. Це означає, що якщо виникнуть якісь проблеми, — наприклад, клієнт не виплачує кошти — вам доведеться звертатися за справедливістю у вказаний суд. А відповідно знадобляться послуги місцевих юристів (про вартість юридичних послуг у США чи Великій Британії я тут писати не буду). 

У результаті маємо вельми складну ситуацію. Компанія ще не отримала свої чесно зароблені гроші за чесно надані послуги, а вже додатково платить дорогим адвокатам, плюс судові збори тощо. Суди — це завжди дорого. А ще — довго. Якщо в Україні судовий процес може йти 2 місяці, то в США чи в Ер-Ріяді він може тягнутися до року, а то й більше. 

Саме тому дуже важливо, щоб в договорі інстанція для вирішення спорів була комфортною для вас. Але й такою, на яку погодиться клієнт. Суди України, що, звичайно, було б найкомфортніше для української ІТ-компанії, навряд чи підходять, тому я рекомендую компромісний варіант — Міжнародний Комерційний Арбітраж. Його переваги для обох сторін:

  • досить легка процедура вирішення суперечок; 
  • не потрібно залучати місцевих юристів — ваш інхаус-спеціаліст впорається (якщо звісно він знає англійську);
  • притомна вартість зборів;
  • можливість вести процес онлайн, тож нікому нікуди не потрібно їхати;
  • рішення цього арбітражу є обовʼязковими до виконання в більшості цивілізованих країн світу.

Звісно, не всі клієнти на це погоджуються, інколи вони можуть наполягати на своїх домашніх юрисдикціях. У таком випадку, рекомендую заздалегідь підшукати місцевого юриста, який допоможе вам у разі виникнення неприємностей. 

А ще, прописати ось такий пункт: всі супутні витрати на процес — так звані attorney and court fees — стороні-переможцю відшкодовує сторона, яка програла. В такому разі, ми отримаємо назад кошти, які витратили на суд у комфортній для клієнта юрисдикції.

У підсумку

Кожен із вищезазначених кейсів може загрожувати бізнесу збитками. Десь вони притомні, і на ризик можна піти, а десь (як-от у випадку з безлімітною відповідальністю) це можуть бути величезні грошові втрати, які здатні зруйнувати ваш бізнес.

У цій колонці я перерахував основні ризики та способи їх мінімізувати або повністю усунути. Але нюанси все ж таки трапляються, тому рекомендую проконсультуватися з юристами перш ніж підписувати договір, наданий контрагентом. 

Автор: Максим Носарєв, СЕО Tretten Lawyers