Запитайте засновника SaaS у 2022 році, який дохід вони очікують цього місяця, і відповіддю була б формула електронної таблиці: кількість місць помножена на ціну, пропорційно до кількості днів, що залишилися в контракті. Запитайте того ж самого засновника, орієнтованого на ШІ, сьогодні, і чесна відповідь буде "це залежить від того, наскільки наші клієнти використовували модель". Споживання токенів може подвоїтися за тиждень, коли клієнт впроваджує функцію у виробництво, або вийти на плато, коли вони призупиняють експеримент. Немає кількості місць, на яку можна було б орієнтуватися у прогнозі.
Цей перехід від підписки до споживання – це не просто рішення про ціноутворення. Це бухгалтерська проблема, і вона цілком вписується в ASC 606 — той самий стандарт визнання доходу, який регулює SaaS з 2018 року, але застосовується до набагато менш передбачуваного вхідного параметру. Якщо ви зробите це неправильно, ви зіткнетеся не з похибкою округлення; ви зіткнетеся з переглянутим роком під час належної перевірки, саме тоді, коли ви найменше можете собі це дозволити.
Чому ціноутворення на основі токенів порушує старий порядок
Традиційне визнання доходу SaaS є відносно поблажливим. Клієнт платить 12 000 доларів за річний план, ви визнаєте 1 000 доларів на місяць, і найбільше рішення полягає в тому, чи вимагає зміна контракту перерозподілу. Компенсація фіксована. Зобов'язання щодо виконання — доступ до програмного забезпечення з часом — є простим. Аудитори бачили тисячі подібних контрактів.
ШІ та ціноутворення на основі використання усувають фіксовану частину. Клієнти платять за оброблені токени, зроблені виклики API, завершені цикли висновків або спожиті обчислювальні секунди. Ця компенсація є змінною за задумом, і ASC 606 має цілий розділ — рекомендації щодо "змінної компенсації" в ASC 606-10-32-11 до 32-13 — присвячений саме цій проблемі. Основна проблема не філософська, вона практична: скільки доходу ви визнаєте за період, коли ви справді не знаєте, в момент закриття ваших книг, скільки саме клієнт зрештою буде винен?
Для компанії ШІ на ранній стадії це стає складніше, перш ніж стане легше. Зрілий SaaS-бізнес може спиратися на роки історії використання, щоб впевнено оцінювати споживання. Компанія, яка запустила свою модель ціноутворення на основі токенів вісім місяців тому, не має таких порівнянних даних. Використання може сильно коливатися, оскільки клієнти переходять від пілотного проекту до виробництва, і модель минулого кварталу може мало що сказати про поточний квартал.
Дві форми контракту, які визначають все
Перш ніж ви зможете правильно визнати долар доходу на основі використання, вам потрібно знати, в якій із двох структур ви насправді перебуваєте — тому що вони обліковуються по-різному.
Чисте споживання, без зобов'язаного мінімуму. Клієнт купує пул кредитів або погоджується платити за одиницю споживання, без нижнього порогу. Якщо домовленість є простою послугою (ви надаєте доступ до розміщеної моделі, а не ліцензуєте інтелектуальну власність, яку клієнт експлуатує самостійно), ви, як правило, не можете використовувати вузьке виключення "роялті на інтелектуальну власність на основі використання" в ASC 606-10-55-65 — це створено для ліцензійних угод, таких як роялті на патент, а не для розміщеного API. Натомість, ви оцінюєте змінну компенсацію, використовуючи метод очікуваної вартості або найбільш ймовірної суми, за умови, що ви не повинні визнавати суми, де "значне скасування" є ймовірним після усунення невизначеності.
Зобов'язаний мінімум плюс перевищення. Клієнт зобов'язується, наприклад, використовувати послуги на суму 2000 доларів на місяць і платить більше, якщо перевищує цей ліміт. Тут нижній поріг поводиться як фіксована компенсація — визнавайте її на систематичній основі, коли клієнт отримує цінність — тоді як будь-що понад мінімум є змінною компенсацією, що підлягає тим самим правилам оцінки та обмежень. Цей гібрид постійно зустрічається в ціноутворенні ШІ: базова плата за платформу плюс обчислення за лічильником зверху.
Знання того, в якій формі ви перебуваєте, змінює ваші бухгалтерські записи, примітки до розкриття інформації та те, наскільки схвильованим має бути ваш аудитор щодо ваших оцінок.
Практичне спрощення, яке використовує більшість компаній ШІ
Ось гарна новина: ASC 606 має вбудований ярлик саме для цієї ситуації, і більшість добре структурованих контрактів на основі використання відповідають йому.
"Право на виставлення рахунку" як практичне спрощення (ASC 606-10-55-18) дозволяє вам взагалі уникнути оцінки загальної компенсації за контрактом. Якщо те, що ви виставляєте як рахунок за кожен період, безпосередньо відповідає цінності, отриманій клієнтом у цьому періоді — ви стягнули 0,002 долара за 1000 токенів, клієнт використав 4 мільйони токенів, ви виставляєте рахунок на 8 доларів — ви можете просто визнати ці 8 доларів як дохід у періоді, коли вони були зароблені. Жодного прогнозування, жодного аналізу обмежень, жодного переоцінювання при кожному закритті.
Заковика полягає у фразі "безпосередньо відповідає". Якщо ваше ціноутворення має рівні, де ставка за одиницю падає зі збільшенням обсягу, або пакетні знижки, які не чітко відповідають періоду, в якому відбулося використання, спрощення може зламатися — сума рахунку перестає відображати вартість цього періоду, і ви повертаєтеся до повної оцінки змінної компенсації. Перегляньте свою структуру ціноутворення з урахуванням цього тесту, перш ніж припускати, що спрощення застосовується рівномірно до всієї вашої договірної книги.
Більшість контрактів ШІ на основі споживання також підпадають під обробку серіями згідно з ASC 606-10-25-14: замість обліку кожного виклику API як окремого мікро-зобов'язання щодо виконання, ви розглядаєте весь потік використання як одне єдине зобов'язання щодо виконання, задоволене з часом. Це те, що робить спрощення виставлення рахунків адміністративно працездатним — ви не відстежуєте тисячі окремих зобов'язань, ви відстежуєте одну поточну послугу зі змінною ціною.
Передоплачені кредити: Відкладений дохід і проблема невикористаних залишків (Breakage)
Багато ШІ-платформ продають пакети передоплачених кредитів — купіть токени на $500 наперед, використовуйте їх протягом наступних місяців. Ця структура популярна, оскільки вона покращує грошовий потік і забезпечує лояльність, але вона створює два бухгалтерські зобов'язання, які засновники зазвичай ігнорують.
Відкладений дохід від невикористаного залишку. У момент надходження готівки за пакет передоплати, жодна її частина ще не є доходом. Це зобов'язання — ви винні клієнту або послугу, або повернення коштів. Дохід переходить з рядка відкладеного доходу до звіту про прибутки та збитки лише тоді, коли токени фактично споживаються. Засновник, який враховує повні $500 у день їх отримання, завищує дохід і буде змушений переглянути його, зазвичай у найгірший можливий час: під час перевірки належної обачності (due diligence) при залученні коштів, коли аудитор переробляє графік і вилучає різницю з періоду, який вже був представлений інвесторам.
Невикористані залишки (Breakage) за кредитами, які ніколи не були використані. Деякі клієнти купують пакет кредитів і ніколи не використовують його повністю до закінчення терміну дії. Цей невикористаний залишок — невикористані залишки (breakage) — це не просто безкоштовні гроші, які ви визнаєте в день закінчення терміну дії кредитів. Згідно зі стандартом ASC 606, очікується, що ви оціните коефіцієнт невикористаних залишків на основі історичних даних про використання та визнаєте ці оцінені невикористані залишки пропорційно, як невелике збільшення доходу поряд з фактичним використанням, а не чекаючи закінчення терміну дії, щоб зарахувати все відразу. Якщо у вас ще немає історії використання (що часто буває для нової кредитної програми), консервативний підхід полягає в тому, щоб зачекати, поки вона з'явиться, визнаючи невикористані залишки лише після закінчення терміну дії, а потім переглянути політику, коли у вас буде декілька когорт даних.
Де дисципліна обмежень дійсно має значення
"Обмеження" щодо змінної винагороди звучить абстрактно, поки ви не переживете квартал, коли використання великого клієнта зросло в 4 рази, а потім повернулося до норми. ASC 606 вимагає включати змінну винагороду до вашої оцінки доходу лише тією мірою, наскільки ймовірно, що значне сторнування не знадобиться пізніше. На практиці це означає:
- Перший рік нової моделі ціноутворення: дотримуйтесь консервативного підходу. Впевнено визнавайте зобов'язані мінімуми та фактичні показники; ставтеся до всього, що прогнозується понад виставлене/фактичне використання, з реальним скептицизмом, оскільки у вас немає порівнянних контрактів для бенчмаркінгу.
- З накопиченням історії використання: ваші обмеження можуть послабитися, оскільки тепер у вас є обґрунтована основа (використання цього клієнта коливалося між X і Y протягом шести місяців поспіль) для більш точної оцінки.
- На кожному закритті періоду: переоцінюйте. Змінна винагорода — це не число, яке можна "встановити й забути" — воно переглядається в кожному звітному періоді по мірі надходження нової інформації, при цьому кумулятивне коригування (catch-up adjustment) проходить через поточний період.
Для фінансової команди, що керує цим по сотнях або тисячах контрактів, оперативне рішення полягає в узгодженні вашої білінгової системи та вашого реєстру визнання доходу до закриття періоду, а не після — щоб дані про використання узгоджувалися автоматично, замість того, щоб щомісяця вимагати ручного аудиторського сліду.
Чому це важливо, навіть якщо ви малі
Якщо ви стартап з розробки ШІ-інструментів з двома співробітниками, який виставляє рахунки кільком клієнтам за токени, спокусливо розглядати все це як "те, чим ми займемося, коли залучимо фінансування Series A". Це реальний ризик. Помилки у визнанні доходу є одними з найпоширеніших висновків під час перевірки належної обачності (due diligence) при залученні коштів у SaaS-компаніях, а ціноутворення на основі використання збільшує кількість суб'єктивних рішень, які аудитор захоче бачити задокументованими: які контракти використовують спрощений метод виставлення рахунків, який коефіцієнт невикористаних залишків ви припустили і чому, як ви впоралися з кварталом, коли використання клієнта різко зросло.
Правильне налагодження механізмів з першого дня — навіть у невеликих масштабах — означає, що вам не доведеться пізніше відтворювати вісімнадцять місяців історії доходів під тиском термінів. Це також означає, що цифри, які ви використовуєте всередині компанії для прийняття рішень щодо ціноутворення та найму, є фактично точними, а не завищеними через невизнаний відкладений дохід, що знаходиться там, де йому не місце.
Тримайте свої книги такими ж прозорими, як і ваша модель ціноутворення
Ціноутворення на основі використання та токенів справді складніше для обліку, ніж фіксована щомісячна підписка, але ця складність є аудитованою — вона лише вимагає документування структури вашого контракту, обґрунтування ваших обмежень та припущень щодо невикористаних залишків у міру їх виникнення, а не доопрацювання їх пізніше. Ведення обліку в текстовому форматі за допомогою Beancount.io робить цей документаційний слід явним: кожен запис про визнання доходу, залишок відкладеного доходу та коригування невикористаних залишків зберігаються у версіонованому тексті, який ви (або ваш аудитор) можете відстежувати рядок за рядком, а не закопаним у системі білінгу "чорного ящика". Почніть безкоштовно і тримайте свій регістр таким же прозорим, як і модель ціноутворення, яку ви будуєте на його основі.