Визнання доходу - одне з найскладніших питань фінансової звітності для софтверних компаній. Коли саме визнавати дохід від SaaS-підписки, що включає безкоштовне налаштування? Як обліковувати контракт T&M, коли клієнт щомісяця змінює обсяг робіт? Що робити з ліцензійними платежами, які залежать від кількості користувачів? МСФЗ 15 "Дохід від договорів з клієнтами" дає відповіді на ці питання через єдину структуровану модель, яка замінила попередні стандарти МСБО 18 та МСБО 11.

П'ятикрокова модель: основа всього

МСФЗ 15 пропонує універсальний алгоритм визнання доходу, що складається з п'яти послідовних кроків. Незалежно від того, чи це продаж ліцензії, надання хмарних послуг чи складний проєкт впровадження - логіка завжди однакова.

Крок 1. Ідентифікація договору

Договір існує, коли обидві сторони затвердили його, права та зобов'язання визначені, умови оплати встановлені, договір має комерційну сутність, і існує ймовірність отримання винагороди. Для IT-компаній важливо пам'ятати, що "договір" за МСФЗ 15 - це не лише підписаний документ. Це може бути онлайн-підписка, акцептована оферта або навіть усна домовленість, підкріплена практикою ведення бізнесу. Водночас рамкові угоди (Master Service Agreements) самі по собі часто не є договорами за МСФЗ 15 - договором стає кожне окреме замовлення (Statement of Work).

Крок 2. Визначення зобов'язань до виконання

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

Наприклад, у контракті на впровадження CRM-системи можуть бути такі зобов'язання: ліцензія на програмне забезпечення, послуги з налаштування та кастомізації, міграція даних, навчання персоналу, річна технічна підтримка. Чи є кастомізація окремим зобов'язанням? Залежить від ситуації. Якщо кастомізація суттєво змінює продукт і клієнт не може використовувати базову ліцензію без неї - це єдине зобов'язання. Якщо ж налаштування є типовим і клієнт може використовувати ПЗ "з коробки" - це окреме зобов'язання.

Крок 3. Визначення ціни операції

Ціна операції - це сума винагороди, яку компанія очікує отримати в обмін на передачу товарів або послуг. Для IT-компаній тут виникають специфічні питання: змінна винагорода (бонуси за досягнення KPI, знижки за обсяг, штрафи за порушення SLA), значний компонент фінансування (передоплати за довгострокові проєкти), негрошова винагорода (бартер, equity замість оплати).

Змінна винагорода включається в ціну операції лише в тій мірі, в якій є високий ступінь ймовірності, що значне сторнування визнаного доходу не відбудеться. Це так зване "обмеження змінної винагороди" (constraint on variable consideration). Наприклад, якщо контракт передбачає бонус 50 000 USD за вчасне завершення проєкту, компанія включає цю суму в ціну операції лише якщо впевнена, що термін буде дотриманий.

Крок 4. Розподіл ціни операції

Якщо договір містить кілька зобов'язань до виконання, загальна ціна розподіляється між ними пропорційно до їх окремих цін продажу (standalone selling prices). Визначення окремої ціни продажу може бути складним завданням, особливо коли компонент ніколи не продавався окремо. МСФЗ 15 дозволяє використовувати методи оцінки: скоригований ринковий підхід, підхід очікуваних витрат плюс маржа або залишковий підхід.

Крок 5. Визнання доходу

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

SaaS та плата за впровадження

SaaS-модель - це, мабуть, найпоширеніша бізнес-модель серед українських IT-компаній, які створюють власні продукти. За МСФЗ 15 SaaS-підписка зазвичай визнається протягом періоду надання послуги, адже клієнт отримує та споживає вигоди одночасно з їх наданням.

Але що робити з одноразовою платою за впровадження (setup fee, onboarding fee)? Якщо впровадження не створює окремого активу для клієнта і є лише підготовкою до надання основної послуги - це не окреме зобов'язання до виконання. У такому випадку плата за впровадження розподіляється на весь очікуваний період підписки. Наприклад, якщо клієнт платить 10 000 USD за налаштування та 2 000 USD/місяць за підписку при очікуваному терміні контракту 3 роки - 10 000 USD визнається протягом 36 місяців, а не в момент завершення налаштування.

T&M проти Fixed-Price

Для аутсорсингових та аутстафінгових компаній ключовим є розмежування між контрактами Time & Materials та Fixed-Price.

T&M контракти. Якщо компанія має право на оплату за фактично витрачений час (right to invoice), МСФЗ 15 дозволяє спрощений підхід - визнавати дохід у сумі, на яку компанія має право виставити рахунок. Це практичне полегшення (practical expedient), яке значно спрощує облік для більшості аутсорсингових компаній.

Fixed-Price контракти. Для проєктів з фіксованою ціною дохід зазвичай визнається протягом періоду методом input (на основі витрачених ресурсів) або output (на основі досягнутих результатів). Метод input (наприклад, відсоток витрачених годин від загального бюджету) є найпоширенішим для IT-проєктів. Але він вимагає надійної системи обліку витрат та регулярного оновлення оцінки загальних витрат на проєкт.

Ліцензування програмного забезпечення

МСФЗ 15 розрізняє два типи ліцензій: право на доступ (right to access) та право на використання (right to use). Право на доступ - це ліцензія, за якої клієнт отримує доступ до інтелектуальної власності в тому вигляді, в якому вона існує протягом періоду ліцензії. Дохід визнається протягом періоду. Право на використання - це ліцензія, за якої клієнт отримує право використовувати інтелектуальну власність у тому вигляді, в якому вона існує на момент передачі. Дохід визнається в момент передачі.

На практиці більшість сучасних SaaS-продуктів є правом на доступ (адже вендор постійно оновлює ПЗ). Класичні on-premise ліцензії зазвичай є правом на використання.

Модифікації договорів

IT-контракти часто змінюються: клієнт просить додаткову функціональність, збільшує або зменшує обсяг, продовжує термін. МСФЗ 15 встановлює чіткі правила для таких модифікацій. Якщо модифікація додає окремі товари або послуги за їхньою окремою ціною продажу - це, по суті, новий контракт. В інших випадках модифікація може оброблятися як припинення старого та створення нового контракту або як кумулятивне коригування.

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

Розкриття інформації

МСФЗ 15 вимагає розширених розкриттів: розподіл доходу за категоріями (тип послуг, географія, час визнання), залишки за контрактами (contract assets, contract liabilities), значні судження та оцінки. Для IT-компаній, що готуються до аудиту або залучення інвестицій, ці розкриття є критично важливими - вони демонструють, що компанія системно підходить до визнання доходу, а не застосовує довільні підходи.

Впровадження МСФЗ 15 вимагає ретельного аналізу всіх типів контрактів компанії, розробки облікових політик та побудови системи внутрішнього контролю. Але результат - прозора та порівнювана фінансова звітність, яка витримує перевірку інвесторів та аудиторів.