Договір як дані: дивись

Що асистент бачить у договорі

1. Договір поставки надходить файлом, і людина додає його до розмови з асистентом, щоб той оцінив умови. Сучасний асистент читає договір цілком, проте читає він не сам файл, а текст, який із файла дістали. Фільм показує, яким цей текст виходить із файла Word, із PDF і зі скану, що в нього не потрапляє і як за хвилину переконатися, що асистент прочитав саме той договір.

2. Текст із файла дістає не модель. Мовна модель, яка складає відповіді, приймає тільки текст, тому продукт, тобто програма, в якій працює асистент, спершу розгортає файл: відкриває його і виписує вміст рядок за рядком. Сторінку такою, як її бачить людина, модель здебільшого не отримує. Що саме вдасться виписати, залежить від формату, тож той самий договір у трьох форматах дає три різні тексти.

3. Найповніший текст виходить із файла Word, бо він і всередині є текстом із розміткою: редактор позначає в ньому, де заголовок розділу, де нумерований пункт, де клітинка таблиці. Програма переносить це без втрат, і модель отримує розділи в тому самому порядку і з тими самими номерами. Пункт 3.1 про аванс 120 000,00 грн протягом 5 банківських днів доходить до неї слово в слово.

4. Проте у файлі Word лежить більше, ніж видно на сторінці. Після роботи в режимі виправлень редактор зберігає в ньому видалений текст і коментарі на полях: тут у пункті 3.1 строк 10 днів замінили на 5 і запитали, чи не забагато 40 %. Одні продукти передають моделі лише остаточний текст, інші додають видалене й коментарі, тож в пункті стоять два строки поруч. Тому правки перед завантаженням приймають або відхиляють.

5. У PDF розмітки вже немає: такий файл зберігає кожен шматок тексту разом із його місцем на аркуші, але не позначає, де абзац і де клітинка таблиці. Програма збирає рядки за координатами, і суцільний текст виходить добре. Таблицю ж вона може прочитати стовпцями, і тоді суми стоять окремо від слів «аванс» і «залишок». Котру суму до якого рядка віднести, модель вирішує сама і в складній таблиці може помилитися.

6. Скан теж часто зберігають як PDF, але всередині немає жодної літери, тільки знімок аркуша. Літери на ньому впізнає програма розпізнавання тексту, а в деяких продуктах сама модель, якщо вона вміє читати зображення. Схожі знаки при цьому плутаються, найчастіше цифри: під печаткою програма прочитала 180 000,00 як 130 000,00. Розпізнаний текст такий самий рівний, як текст із Word, і помилки в ньому не видно.

7. Частина договору в текст не потрапляє за жодного формату. Печатка й підпис є зображеннями, тому з тексту не видно, чи договір підписано. Пункт 1.2 згадує Додаток 1 зі специфікацією, але файла з ним не додали. Дуже довгий документ продукт може передати не цілим. Про ці прогалини модель повідомляє не завжди: відповідь вона складає з того тексту, який має, і звучить та так само впевнено.

8. Що саме дійшло до моделі, зʼясовують до аналізу, двома проханнями: перелічити розділи з номерами і згадані в тексті додатки та дослівно процитувати один пункт із цифрами, наприклад 3.1. Відповідь звіряють із файлом: девʼять розділів на місці, цитата збігається до знака, а про Додаток 1 асистент пише, що файла з ним немає. Коли розділу бракує або цифра інша, спершу виправляють файл, а не запит.

Контекст збирає людина

1. Людина дає договір поставки асистентові, тобто програмі, яка відповідає на запит текстом, і пише: «перевір договір». За хвилину приходить охайний перелік зауважень, проте кожне з них підійшло б до будь-якого договору поставки. Асистентові бракувало контексту, тобто відомостей про угоду, яких у самому договорі немає. Фільм показує, з чого контекст складається, де він лежить і чому збирати та перевіряти його доводиться людині.

2. Сам договір асистент прочитав цілком, і зауваження в нього слушні. Проте хто його питає, Покупець чи Постачальник, він не знає, тому про аванс 40 % пише для обох одразу: для одного це ризик, для другого захист. Від сторони залежить, чи є таке зауваження проблемою взагалі. Тож без контексту виходить огляд договору, а не порада, що з ним робити.

3. Контекст починається з двох відомостей: на чиєму ви боці і навіщо вам угода. У прикладі людина дописує, що її компанія - Покупець і товар потрібен до 30 вересня, бо з 1 жовтня з нього виконують власне замовлення. Після цього аванс 40 % стає ризиком для Покупця, а строк поставки - головним питанням: якщо аванс надійде в останній день, 17 вересня, товар можуть привезти аж 1 жовтня.

4. Друга частина контексту - те, про що сторони домовилися ще до договору. У листі від 3 вересня Постачальник погодився на аванс 30 %, а в проєкті договору стоїть 40 %. З самого тексту цього не видно: 40 % виглядає там як звичайна умова. Лише маючи лист, асистент називає це розбіжністю з домовленістю, і порада стає конкретною: повернути погоджені 30 %.

5. Третя частина - шаблон і позиції компанії. Шаблон - це її власний типовий договір, а позиції - перелік того, на що вона погоджується і на що ні: аванс не більше 30 %, пеня за прострочення поставки обовʼязкова, гарантія від 12 місяців. З цим переліком асистент звіряє пункт за пунктом. Гарантію він приймає, а про пеню пише, що в договорі вона є лише за прострочення оплати.

6. Четверта частина - попередні договори з тим самим контрагентом. Торік «Зерно-Трейд» дав гарантію 24 місяці, тож 12 місяців у новому проєкті - це крок назад, і про 24 можна просити знову. У тій самій теці лежить претензія: минулу поставку затримали на шість днів. Для асистента це ще одна причина наполягати на пені за затримку, бо цього разу запасу в строках у Покупця немає.

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

8. Зібрати контекст можна двома способами. Людина сама знаходить потрібний лист, позиції й торішній договір і вкладає їх у запит. Або вона дає асистентові доступ, тобто підключення, через яке той шукає в пошті й на диску від її імені. Шукає при цьому окрема програма, і повертає вона все, що збіглося за назвою контрагента: потрібний лист, а поруч лист про іншу поставку і застарілий шаблон.

9. Знайдене ще не є контекстом, поки його не переглянула людина. Лист про іншу поставку і застарілий шаблон вона прибирає, бо цієї угоди вони не стосуються. За самим текстом асистент не відрізнить чинну домовленість від скасованої, а затверджені позиції від чернетки: це знає людина, яка веде угоду. Вона ж дописує те, чого не було в жодному файлі: товар потрібен до 30 вересня.

10. Той самий договір з тим самим запитом, але вже з контекстом, дає інший аналіз. Замість загального «ризик для Покупця, захист для Постачальника» у відповіді стоїть: у листі погоджено 30 %, повернути 30 %. Строк поставки асистент звірив із датою, до якої потрібен товар, а пені бракує саме за прострочення поставки. Почати можна з трьох рядків у запиті: на чиєму ви боці, навіщо угода і що вже погоджено.

Як асистент аналізує договір

1. Договір поставки на кілька сторінок сучасний асистент читає цілком і за кілька хвилин повертає звіт: що в договорі написано, де пункти суперечать один одному і що варто змінити. Асистент - це програма, якій пишуть запит словами, а відповідь у ній складає мовна модель. Фільм показує, які кроки модель робить сама, які доручає іншим програмам і чому від набору цих програм залежить точність звіту.

2. Асистент без підключених програм має лише дві речі: текст, який ви дали, і те, що модель засвоїла під час навчання на великому масиві текстів. Договір він і так прочитає цілком, випише умови, знайде суперечності й запропонує правки, бо все це робота з текстом. А про закон і реєстр компаній він відповідає з памʼяті, яка буває застарілою або хибною, дати й суми рахує без калькулятора, і звіритися йому нема з чим.

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

4. Спершу модель читає весь текст, від преамбули до додатків, і складає карту договору: хто сторони, що є предметом, скільки і коли платять, які строки, хто за що відповідає і як договір розривають. Біля кожного запису вона ставить номер пункту, з якого вона його взяла. Тут Покупець платить 300 000,00 грн, із них 40 % авансом, а товар Постачальник привозить за 14 календарних днів після авансу.

5. Маючи карту, модель звіряє пункти між собою, і це їй вдається добре, бо вона тримає в увазі весь текст одразу. У пункті 6.1 гарантія становить 12 місяців, а в додатку 1 на той самий товар записано 24. Знаходить вона і прогалини, тобто те, чого в тексті бракує: аванс сплачують за 5 банківських днів, але договір ніде не каже, які дні вважати банківськими, а пеню передбачає лише за прострочення оплати.

6. Далі модель порівнює договір із позиціями нашої сторони. Позиції - це перелік умов, на які компанія погоджується і на які ні; його складає людина, і без нього модель оцінює договір лише загалом. Ми тут Покупець і авансом платимо не більше 30 %, а в договорі стоїть 40. Для кожної розбіжності модель пише, чим вона загрожує саме Покупцеві: більший аванс означає більшу суму, яку доведеться повертати, якщо товар не привезуть.

7. Наприкінці модель пропонує правки і позицію для переговорів. Для пункту 6.1 вона дає готове формулювання з гарантією 24 місяці, як у додатку, а в розділ про відповідальність додає пеню за прострочення поставки. Окремо вона радить, з чого почати розмову і де можна поступитися: просити аванс 30 %, а на 40 погодитись лише разом із пенею для Постачальника. Усі ці кроки - робота з текстом, і модель виконує їх сама, без інструментів.

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

9. Викликати не означає запустити: програм модель сама не запускає. Вона пише запит із точними даними: дата договору 10.09.2026, пʼять днів і правило «з понеділка по пʼятницю». Продукт, у якому працює асистент, запускає калькулятор строків і вставляє відповідь у текст, який модель читає далі: четвер 17.09.2026. Друга програма множить 300 000,00 на 40 % і повертає аванс 120 000,00 та залишок 180 000,00. Ці числа модель переносить у звіт без змін.

10. Так само модель чинить із фактами, які легко «пригадати» неточно. Вона пише запит із кодом Постачальника, продукт передає його програмі, що шукає в державному реєстрі юридичних осіб, і повертає моделі запис із назвою компанії. Текст закону модель теж отримує з бази законодавства, а не з памʼяті: за статтею 253 Цивільного кодексу строк починають рахувати з наступного дня після події. Без підключених програм обидві відповіді були б здогадом.

11. Готовий звіт змішує два види тверджень, і за виглядом їх не розрізнити. Дата 17.09.2026, суми 120 000,00 і 180 000,00, запис реєстру й текст статті прийшли від програм, і вони точні настільки, наскільки точними були вхідні дані. Оцінка ризику, пояснення і запропоновані формулювання належать моделі, і саме їх варто читати уважно. Хороший звіт показує, яке число який інструмент порахував; якщо цього не видно, асистента можна про це спитати.

12. Набір інструментів не сталий: його розширює людина. Свої позиції вона оформлює як чеклист, за яким модель проходить кожен договір, додає калькулятор пені, довідник перевірених контрагентів, шаблон звіту. Зібраний навколо одного типу договору, такий набір працює однаково для одного документа і для тисячі: модель щоразу читає новий текст, а рахують і звіряють ті самі програми. Почати можна з малого: записати три власні позиції і дати їх асистентові разом із договором.

Людина перевіряє і відповідає

1. Асистент прочитав договір поставки, який надіслав постачальник, і за кілька хвилин повернув покупцеві звіт: звів умови в перелік, назвав ризики і запропонував правки. Звіт виглядає завершеним, і саме тому його легко переслати далі без перевірки. Фільм показує, як перевірити такий звіт, не перечитуючи весь договір, і що після перевірки все одно лишається за людиною: рішення і відповідальність за нього.

2. Сучасний асистент читає договір цілком і помічає більшість типових проблем, тож звіт здебільшого правильний. Помиляється він інакше, ніж людина: не втомлюється і не пропускає сторінок, зате може впевнено послатися на пункт, якого в договорі немає, загубити цифру або промовчати про документ, якого йому не дали. Хибне твердження він пише тим самим рівним тоном, що й правильні, тому на вигляд їх не розрізнити.

3. Перша перевірка стосується тексту: кожне твердження звіту має вести до пункту договору. Асистента просять додати до кожного рядка номер пункту і дослівну цитату, а цитату шукають у файлі звичайним пошуком. Слова про аванс 40 % у пункті 3.1 знаходяться одразу. Пені за прострочення поставки в пункті 7.2 немає, там ідеться лише про оплату. Це твердження асистент вигадав, і покупцеві варто знати, що такої пені в договорі немає взагалі.

4. Друга перевірка стосується цифр і дат. Модель складає число так само, як слова, тому в арифметиці й рахунку днів може схибити. Точне вона доручає інструментові, тобто окремій програмі на зразок калькулятора, і у звіті просять позначити, де вона так зробила. Аванс 120 000,00 грн порахував інструмент. Останній день оплати, 15.09.2026, асистент назвав сам; після перерахунку виходить 17.09.2026, бо дні в пункті банківські.

5. Третя перевірка стосується того, чого у звіті немає. Про непрочитане й неперевірене асистент сам зазвичай не згадує, тому його питають прямо: чого він не перевірив і яких документів йому бракувало. У відповіді три рядки. Торішнього договору з цим постачальником йому не дали, тож порівняти умови він не міг. Код постачальника з реєстром він не звірив, бо доступу до реєстру не мав. Листування, яке передувало договору, він не бачив.

6. Четверта перевірка - другий незалежний прохід. Той самий договір дають асистентові в новій розмові, без першого звіту, і ставлять те саме завдання. Нова розмова потрібна тому, що в старій він спирається на вже написане і здебільшого повторює власні висновки. Два звіти порівнюють: де вони збігаються, помилка менш імовірна, хоча й не виключена. Де розходяться, як-от щодо гарантії, людина відкриває пункт і додаток і читає їх сама.

7. Перевірений звіт лишається пропозицією. Асистент радить три правки: додати пеню за прострочення поставки, зменшити аванс із 40 до 30 % і записати гарантію 24 місяці, як у додатку. Яку з них вимагати, а якою поступитися, залежить від речей поза текстом: чи потрібен саме цей постачальник, як терміново потрібен товар, про що вже домовилися усно. Це зважує і вирішує людина, а асистент під її рішення готує формулювання.

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

Договір це поля

1. Новий договір, рахунок чи довіреність рідко пишуть з нуля: беруть попередній документ, зберігають копію і замінюють у ній назви, суми й дати. Десь при цьому лишається стара сума, а підсумок цифрами перестає збігатися з підсумком прописом. У таких помилок спільна причина: дані документа перемішані з його текстом. На прикладі договору поставки видно, як їх розділити і які помилки після цього зникають.

2. У договорі поставки на кілька сторінок від угоди до угоди змінюється небагато: назва сторони, її код, кількість, ціна, дата, строк і рахунок. Це дані, тобто значення, які описують саме цю угоду. Решта - текст: формулювання пунктів, які юрист погодив один раз і які переходять з договору в договір без змін. На сторінці одне від другого не відрізнити, бо надруковані вони однаково.

3. Щоб розділити дані й текст, кожне значення виносять в окреме поле. Поле - це комірка з назвою для одного значення: назва «ціна за тонну» і саме значення, 12 400,00. За назвою значення можна знайти й підставити, не перечитуючи текст. Зберігається воно в одному місці, тому назву сторони, яка стоїть і на початку договору, і біля підпису, виправляють один раз, і розбіжностей між сторінками не буває.

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

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

6. Поля теж неоднакові, і різнить їх те, звідки береться значення. Змінне поле для кожної угоди вводить людина: сторону, ціну, строк. Похідне поле ніхто не вводить, його обчислюють з інших полів, як-от суму чи ПДВ. Ще два види стосуються тексту: фіксований текст, однаковий у всіх договорах, і опція, тобто вибір із кількох готових формулювань, наприклад передоплата або оплата після поставки.

7. З чотирьох видів похідне поле найбільше важить для помилок: власного значення воно не зберігає, його щоразу обчислюють з інших полів. Кількість 15, помножена на ціну 12 400,00, дає 186 000,00. ПДВ 20 % від цієї суми становить 37 200,00, а разом виходить 223 200,00. Суму прописом програма складає з того самого числа, тому слова й цифри розійтися не можуть, а якщо змінити ціну, перерахується весь ланцюжок.

8. Без похідних полів той самий ланцюжок набирає людина, і тримається він лише на її уважності. У рядку суми стоїть 168 000,00 замість 186 000,00, бо дві цифри помінялися місцями. У сумі прописом людина пропустила слово «три», тож словами вийшло 220 200, а цифрами 223 200. Сторінка виглядає охайно, і під час читання такі розбіжності здебільшого минають непоміченими. Коли ж числа рахує програма, такій помилці нема звідки взятися.

9. Готовий договір збирає програма: бере шаблон і на місце кожного пропуску ставить значення поля з такою самою назвою, а похідні поля дораховує сама. Для «Зерно-Трейд» це 15 тонн по 12 400,00 і підсумок 223 200,00. Людині лишається заповнити картку із семи полів і перевірити саме її, а не перечитувати кілька сторінок у пошуках того, що змінилося.

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

Хто ловить помилку

1. Договір приходить по-різному: кривим сканом із печаткою, файлом Word або охайним PDF з таблицею. У кожному є значення, від яких залежать гроші і строки: код компанії, номер рахунку, сума, дата. На трьох таких договорах видно, якими способами перевіряють значення в документі і яку помилку ловить кожен спосіб. Звідси ж зрозуміло, чому охайний файл заслуговує на довіру не більше, ніж скан.

2. Вигляд документа залежить від того, як його виготовили, а не від того, чи правильні в ньому дані. PDF зазвичай зберігають із того самого файлу Word, а скан - це роздрукований і сфотографований аркуш. Код, суму й дату в усіх трьох хтось набрав на клавіатурі або переніс із попереднього договору. Помилка набору переходить у будь-який формат без змін, тому перевірка для всіх трьох однакова.

3. Перша перевірка не потребує нічого, крім самого значення. Код ЄДРПОУ, за яким компанію записано в державному реєстрі, має вісім цифр, і остання з них контрольна: її обчислено з попередніх семи, щоб помилку набору було видно одразу. Кожну із семи цифр множать на свою вагу, добутки додають і суму ділять на 11. Для коду 31316718 сума дорівнює 96, остача 8, і восьма цифра теж 8.

4. У сканованому договорі той самий код записано як 31361718: дві сусідні цифри помінялись місцями. Добутки стали іншими, сума тепер 91, остача 3, а восьма цифра лишилась 8. Така розбіжність означає, що в коді, найімовірніше, помилка, і його звіряють із реєстром. Одну хибну цифру формула майже завжди ловить так само. Для остачі 10 правило окреме: рахунок повторюють з іншими вагами.

5. Таку перевірку називають алгоритмічною: вона можлива всюди, де значення має формулу. Рахунок IBAN містить дві власні контрольні цифри, і в скані він їх не проходить. У договорі з Word добуток 15 на 12 400 записано як 168 000 замість 186 000, а в PDF стоїть дата 31 квітня, якої немає в календарі. Проте код 47645196 з того самого PDF формулу проходить: вона перевіряє форму запису, а не існування компанії.

6. На питання, чи існує компанія, відповідає тільки реєстр. ЄДР - це державний реєстр юридичних осіб із відкритим пошуком, де за кодом видно назву, адресу й керівника. За кодом 47645196 з охайного PDF реєстр запису не знаходить. Це ще не означає, що компанії немає: помилка могла бути в самому коді, тому пошук повторюють за назвою. У покупця запис є, але в договорі будинок 6-Б, а в реєстрі 6-К.

7. Лишаються помилки, яких не бачить ні формула, ні реєстр: кожне значення окремо правдоподібне, а суперечать вони одне одному. Їх знаходить перехресне читання, коли людина звіряє різні місця одного документа. Договір датовано 21 травня, а додаток посилається на договір від 12 травня. У преамбулі директор має ініціали О. С., а під підписом стоять О. В. Гарантія в пункті 6.1 становить 12 місяців, у додатку 24.

8. ШІ-асистент, тобто програма, яка відповідає на запит текстом, прискорює всі три перевірки, але результат залежить від формулювання. На загальне «перевір договір» він відповідає впевнено і може написати «помилок не знайдено», не звіривши дат. На точний запит «звір дату договору з датою в додатку 1» він наводить обидві дати й показує розбіжність. Упевнений тон відповіді не свідчить про те, скільки він перевірив.

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

10. Три перевірки ловлять різні помилки, тому жодна не замінює інших. Починають із формул, бо це швидко й нічого не коштує, далі йде запит до реєстру, а найповільніше, читання звʼязків між пунктами, лишається людині. Скан, файл Word і охайний PDF проходять цей шлях однаково. В охайному PDF з цього прикладу знайшлися і дата, якої немає в календарі, і код, якого немає в реєстрі.

Від пункту до дати

1. Сторони підписали договір поставки і з цього дня мають зобовʼязання одна перед одною: сплатити аванс, привезти товар, прийняти його, доплатити решту. Строки цих дій розкидані по тексту, і майже жоден не записаний готовою датою. Фільм показує, як із пунктів договору скласти перелік того, що і до якого числа треба зробити, і чому частину дат неможливо вписати заздалегідь.

2. Перелік складають по одному пункту. За пунктом 3.1 Покупець сплачує аванс 40 % ціни, тобто 120 000,00 грн, протягом 5 банківських днів з дати підписання Договору. Це речення розкладають на пʼять полів: хто виконує, що саме, строк, тип днів і тригер, тобто подія, від якої починають рахувати строк. Окремо їх записують тому, що кінцеву дату визначають три останні поля, і помилка в будь-якому її зсуває.

3. Тип днів визначає, які дні входять у рахунок. Календарні дні йдуть поспіль, разом із суботою й неділею, а робочі вихідних не включають. Рахувати починають з наступного дня після події, тож від підписання в четвер 10.09.2026 пʼять календарних днів закінчуються у вівторок 15.09, а пʼять робочих - у четвер 17.09. Той самий строк дає дві різні дати, тому тип днів переписують із пункту дослівно.

4. Пункт 3.1 називає дні банківськими, а закон не визначає, що таке банківський день. Зміст цього терміна задає сам договір, а якщо визначення в ньому немає, останній день строку стає предметом спору. Для цього прикладу припустімо, що банківські дні - це дні з понеділка по пʼятницю. За такого припущення в рахунок потрапляють 11, 14, 15, 16 і 17 вересня, і останній день оплати авансу - четвер 17.09.2026.

5. Тригер так само беруть із тексту пункту, а не з позначок на папері. На скані цього договору стоїть вхідний штамп із датою 11.09.2026: того дня примірник надійшов до канцелярії. Якщо рахувати від штампа, пʼять банківських днів закінчаться в пʼятницю 18.09, на день пізніше від справжнього строку. Пункт 3.1 привʼязує відлік до підписання, тож правильною лишається дата 17.09.2026.

6. Договір привʼязує строк поставки до події, якої в день підписання ще не було. За пунктом 4.1 Постачальник поставляє товар протягом 14 календарних днів з дня, коли банк зарахував аванс на його рахунок. Покупець може заплатити в перший день свого строку, в останній або із запізненням, і наперед цього ніхто не знає. Тому в полі дати пишуть «чекає на подію»: дата, порахована від очікуваного дня оплати, була б здогадом.

7. Дату тригера беруть із документа, який підтверджує подію. Для зарахування авансу це банківська виписка Постачальника: за нею 120 000,00 грн надійшли у вівторок 15.09.2026. Від цього дня відлічують 14 календарних днів, тепер уже разом із вихідними, і останнім днем поставки стає вівторок 29.09.2026. Рядок отримує дату лише зараз, а поруч записують документ, з якого взяли день події.

8. Поставка, своєю чергою, стане тригером для наступних строків. Від її дня Покупець має 5 робочих днів на приймання товару за якістю, і від нього ж рахують гарантію, 12 місяців. Підписана видаткова накладна запускає оплату залишку: 180 000,00 грн протягом 10 банківських днів. Виходить ланцюг, у якому кожна дата чекає на попередню подію, тому наперед відома тривалість строків, а не числа в календарі.

9. Є й зобовʼязання, тригер яких може не настати взагалі. Їх називають умовними: обовʼязок виникає лише тоді, коли сталася подія, названа в пункті. Товар із дефектами замінюють за 10 календарних днів після акта, про форс-мажор повідомляють протягом 10 календарних днів, аванс у разі відмови від Договору повертають за 5 банківських днів. У перелік їх вносять без дати, і якщо договір виконають без порушень, дата так і не зʼявиться.

10. Розібрані пункти зводять в одну таблицю, яку називають трекером зобовʼязань. Кожне зобовʼязання займає в ній рядок, а стовпці повторюють поля: пункт, хто, що, тригер, дата і статус. Потрібна вона тому, що в договорі строки розташовані за розділами, а не за календарем, і найближчої дати з тексту не видно. Дата стоїть лише в рядках, де тригер уже настав: аванс не пізніше 17.09.2026, поставка не пізніше 29.09.2026.

11. Трекер переглядають після кожної події. Припустімо, товар був на складі, і його привезли вже в середу 16.09.2026, а Покупець того ж дня підписав накладну. Три рядки, які чекали на це, отримують дати: приймання до середи 23.09.2026, залишок до середи 30.09.2026, гарантія до 16.09.2027. Умовні рядки лишаються порожніми. Спробуйте так розібрати один свій договір: пʼять полів із кожного пункту зі строком і позначка, чи настав тригер.