Грантова звітність у Horizon Europe: як керувати deliverables, бюджетом і дедлайнами

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

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

У цьому гіді розбираємо, як влаштована звітність у Horizon Europe та інших EU-funded projects: continuous reporting, periodic reports, deliverables, milestones, фінансова звітність, amendments і роль координатора. Плюс два практичні чеклисти: що зробити в перші 30 днів проєкту і за 60 днів до звіту.

Що таке грантова звітність насправді

Грантова звітність – система доказів того, що команда виконує обіцяне в заявці: рухається за планом робочих пакетів (Work Packages), досягає контрольних точок (milestones), подає результати (deliverables), витрачає кошти за правилами, фіксує ризики і може пояснити донору, що відбулося за звітний період.

У Horizon Europe та подібних програмах звітність грантового проєкту має дві площини. Технічна відповідає на питання «що зроблено?». Фінансова – «як використано бюджет?». Обидві мають сходитися між собою: якщо технічний звіт каже, що робочий пакет виконано на третину, а витрати за ним закрито на 90%, у Єврокомісії з’являться запитання.

І головне про те, як звітувати за грант: звітність працює як операційна система проєкту. Якщо команда фіксує прогрес, витрати, ризики й рішення щомісяця, periodic report складається з готових блоків. Якщо ні – звіт перетворюється на археологічну експедицію по старому листуванню.

Грантова угода: момент, коли заявка стає зобов’язанням

Після підписання грантової угоди (Grant Agreement) робочі пакети, deliverables, milestones, бюджет і ролі партнерів перестають бути елементами красивої заявки. Вони стають формальними зобов’язаннями консорціуму, зафіксованими в Описі дій (Description of Action, Annex 1 до угоди).

Ми вже детально розбирали, як структурувати робочі пакети на етапі заявки. Під час реалізації ті самі WP стають основою звітності: кожен звіт будується навколо прогресу за пакетами, їхніми завданнями і результатами.

Погано спроєктований робочий пакет болить двічі: спочатку під час оцінювання заявки, а потім під час звітування. Розмиті deliverables, нереалістичні строки і незрозумілий розподіл ролей між партнерами повертаються до команди саме у звітний період.

Continuous reporting: звітність триває весь проєкт

Continuous reporting – регулярне оновлення інформації про проєкт у модулі на Funding & Tenders Portal. Модуль відкривається зі стартом проєкту і залишається активним протягом усієї реалізації. Саме з цих даних система потім автоматично формує частину periodic report.

Що команда оновлює в continuous reporting:

• статус deliverables і milestones;
• critical risks – ризики, які загрожують виконанню плану;
• публікації та результати досліджень;
• комунікаційні активності й заходи;
• права інтелектуальної власності (IPR);
• публічне резюме проєкту (publishable summary);
• індикатори, специфічні для програми.

Приклад. Deliverable D2.1 має бути поданий у місяці M12. Це означає, що вже у M3–M6 команда розуміє, хто його готує, які дані потрібні, хто перевіряє якість, де зберігається чернетка і які докази виконання треба прикріпити. Згадка про D2.1 у M11 гарантує затримку.

Periodic report: що відбувається у звітний період

Реалізація грантового проєкту в Horizon Europe поділена на звітні періоди, визначені у грантовій угоді. Після завершення кожного періоду консорціум подає periodic report, і на це офіційно відводиться 60 днів. Звіт складається з двох частин: технічної та фінансової.

Технічний звіт (Technical Report)

• Part A – структуровані таблиці з даними про проєкт. Система генерує їх автоматично на основі continuous reporting. Тут окупається дисципліна попередніх місяців: якщо дані оновлені, Part A майже готова.
• Part B – наративна частина. Команда описує виконану роботу, пояснює відхилення, затримки, зміни в планах і невиконані роботи. Part B готують за шаблоном поза порталом і завантажують як PDF.

Фінансовий звіт (Financial Report)

• індивідуальні фінансові звіти (individual financial statements) кожного учасника та його афілійованих організацій;
• зведений фінансовий звіт консорціуму, який система формує автоматично;
• деталізація використання ресурсів (use of resources) або таблиці витрат, якщо програма цього вимагає;
• сертифікат про фінансову звітність (Certificate on the Financial Statements, CFS) від незалежного аудитора – якщо внесок ЄС для окремого учасника сягає 430 000 євро. CFS подають разом із фінальним звітом.

Якщо коротко: технічний звіт грантового проєкту розповідає історію періоду, а фінансова звітність гранту показує, скільки ця історія коштувала і чи відповідають витрати правилам. Єврокомісія перевіряє обидві частини на узгодженість, і саме розбіжності між ними породжують більшість додаткових запитань від Project Officer.

Найгірша помилка: збирати звіт в останній місяць

Типова сцена. За місяць до дедлайну координатор просить партнерів надіслати оновлення. Один партнер надсилає три абзаци загального тексту. Другий – торішню презентацію. Третій питає, який саме deliverable він мав вести. Четвертий ще не закрив витрати за період. Координатор перетворюється на людину-нагадування, а звітність – на стрес для всього консорціуму.

Написати сам текст звіту команда зазвичай здатна. Їй бракує іншого: системи, яка накопичує матеріали для звітності протягом усього періоду. Щомісячні оновлення від партнерів, актуальні статуси deliverables, зафіксовані ризики і зібрані докази перетворюють підготовку periodic report із тримісячного авралу на кілька тижнів спокійної редакторської роботи.

Evidence library: папка, яка рятує проєкт

Для звітності потрібні докази, і збирати їх треба з першого дня. Evidence library – структуроване сховище всього, що підтверджує виконання робіт і витрат:

• протоколи зустрічей і списки учасників (attendance lists);
• фото заходів, записи вебінарів, презентації;
• версії deliverables і докази досягнення milestones;
• листування з рішеннями, які вплинули на хід проєкту;
• договори, рахунки, підтвердження оплат;
• облік робочого часу (timesheets) або еквівалентні записи;
• скриншоти комунікаційних кампаній, публікації;
• посилання на datasets, репозиторії, вебсайти проєкту.

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

Deliverables і milestones: власник, дедлайн, доказ

Deliverable – конкретний результат, який треба подати до Єврокомісії або зафіксувати: звіт, документ, прототип, платформа. Milestone – контрольна точка, яка підтверджує, що проєкт досяг важливого етапу і може переходити до наступної фази.

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

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

Бюджет і фінансова звітність: де найчастіше виникає хаос

Фінансова звітність рідко ламається на самих цифрах. Вона ламається на відсутності зв’язку між витратами і реально виконаними роботами. Типові проблеми в консорціумах:

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

Звітність працює краще, коли бюджет живе поруч із календарем робіт, deliverables і ролями партнерів. Тоді питання «чому за WP3 витрачено 80% коштів при 40% виконання» команда бачить у M9, а Project Officer ніколи його не поставить.

Amendments: коли зміни оформлюють офіційно

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

• зміна складу консорціуму або зміна координатора;
• суттєві зміни в Описі дій (Annex 1);
• суттєві зміни у запланованих роботах;
• зміни, які впливають на бюджет або юридичні умови угоди.

Amendment – робочий інструмент, який приводить офіційний документ у відповідність до реального життя проєкту. Проблеми починаються тоді, коли команда місяцями ігнорує зміни, а потім намагається пояснити їх постфактум у Part B. Складні випадки варто заздалегідь обговорювати з Project Officer: письмова консультація перед amendments заощаджує тижні листування після.

Роль координатора: тримати систему

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

• reporting calendar – єдиний календар звітності для всього консорціуму;
• ролі партнерів і шаблони регулярних оновлень;
• регулярні статуси з лідерами робочих пакетів;
• контроль deliverables і якість Part B;
• узгодження фінансових звітів партнерів;
• комунікація з Project Officer;
• узгодженість між Part A, Part B і фінансовими даними.

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

KanriFlow: як тримати звітність в одному просторі

Коли партнерів більше пʼяти, а звітних елементів десятки, Excel і чати перестають витримувати навантаження. Reporting calendar живе в одному файлі, статуси deliverables у другому, бюджет у третьому, а докази розкидані по поштових скриньках. Кожне оновлення потребує ручного зведення.

Саме для цього створений KanriFlow – робочий простір для координаторів EU-funded projects у Horizon Europe, Erasmus+, Interreg і LIFE. Якщо GetGrant допомагає знайти релевантні грантові можливості й підготувати сильну заявку, KanriFlow підхоплює проєкт після перемоги: допомагає координувати партнерів, контролювати deliverables і milestones, вести reporting calendar, стежити за бюджетом, фіксувати ризики й готуватися до periodic reports без паніки в останній тиждень.

Що це дає на практиці:

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

Чеклист: перші 30 днів після старту проєкту

• створити master calendar для звітних періодів, deliverables і milestones;
• призначити власника для кожного deliverable;
• погодити внутрішні дедлайни, раніші за офіційні;
• створити evidence library зі структурою за WP і періодами;
• зробити шаблон щомісячного оновлення від партнерів;
• провести kickoff щодо правил звітності для всього консорціуму;
• пов’язати робочі пакети з бюджетними категоріями;
• завести реєстр ризиків (risk register);
• визначити відповідального за Part B і відповідального за контроль фінансових звітів;
• налаштувати регулярний статус із партнерами;
• запровадити просту систему «green / yellow / red» для deliverables і ризиків.

Чеклист: за 60 днів до periodic report

• перевірити, чи актуальні дані в continuous reporting;
• оновити статуси milestones і deliverables;
• зібрати оновлення від партнерів за шаблоном;
• перевірити узгодженість між прогресом за WP і використанням бюджету;
• зібрати пояснення затримок і відхилень для Part B;
• перевірити повноту evidence library за період;
• підготувати наратив для Part B і провести внутрішнє рецензування;
• нагадати партнерам про фінансові звіти і строки їх заповнення;
• підготувати список питань до Project Officer, якщо є складні зміни.

Звітність як інструмент керування проєктом

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

Сильна заявка допомагає виграти грант. Сильна система управління допомагає його реалізувати. Побудуйте її в перші 30 днів, і кожен наступний periodic report буде плановою подією в календарі команди.