Замовлення, рахунки та дохід: трикутник звірки SaaS

Засновник SaaS-компанії укладає трирічну угоду на суму $360 000 у березні. Відділ продажів святкує букінг на суму $360 000. Фінансовий відділ виставляє рахунок на $120 000 за перший рік і отримує оплату у квітні. Бухгалтерія визнає $10 000 доходу у звіті про прибутки та збитки за березень. Наприкінці року генеральний директор дивиться на три цифри — $360 000, $120 000 та $100 000 — і дивується, чому жодна з них не збігається, яка з них має бути в презентації для інвесторів і чи не є якась із них помилковою.

Жодна з них не є помилковою. Це три різні вимірювання одного і того ж контракту в трьох різних точках його життєвого циклу. Завдання фінансової команди — не обирати улюблену цифру. Воно полягає в тому, щоб тримати всі три показники в синхронізації, доводити їхню відповідність та розгортати баланс доходів майбутніх періодів так, щоб звіт про прибутки та збитки, баланс і графік ARR розповідали ту саму історію місяць за місяцем.

Це операційне ядро обліку підписок згідно з ASC 606 — і саме тут більшість фінансових функцій SaaS-компаній або підтверджують свою кваліфікацію, або тихо накопичують помилки, які випливуть під час аудиту перед залученням інвестицій через вісімнадцять місяців.

Три цифри та чому вони відрізняються

Кожна угода за передплатою генерує три економічні події, розділені в часі:

Букінг (Booking) — момент підписання контракту клієнтом. Це загальна вартість контракту (TCV), яку клієнт зобов'язався сплатити протягом терміну дії угоди. Букінг відображається в результатах відділу продажів, а не у звіті про прибутки та збитки.
Виставлення рахунку (Billing) — момент видачі інвойсу. Багаторічний контракт може передбачати один щорічний рахунок щороку, дванадцять щомісячних рахунків або один великий авансовий рахунок на всю суму TCV. Білінг визначає надходження грошових коштів та дебіторську заборгованість.
Визнаний дохід (Recognized revenue) — GAAP-вимірювання послуг, фактично наданих протягом періоду. Відповідно до ASC 606, дохід визнається рівномірно (або в міру виконання зобов'язань), незалежно від того, коли був підписаний контракт або коли надійшли кошти.

Ці три цифри майже ніколи не будуть рівними між собою в конкретному місяці. Це не помилка — це принцип методу нарахування. Вам потрібен надійний спосіб показати, як гроші переміщуються з одного "кошика" в інший, і звірка, яка доводить, що нічого не було втрачено.

Приклад розрахунку

Розглянемо ще раз ту саму трирічну угоду на $360 000. Ціна становить $10 000 на місяць, рахунок виставляється щорічно авансом.

Букінги: $360 000 зафіксовано в березні (місяць підписання контракту).
Виставлені рахунки: $120 000 виставлено у квітні за перші дванадцять місяців, $120 000 — наступного квітня і $120 000 — на третій рік.
Визнаний дохід: $10 000 на місяць, щомісяця, протягом тридцяти шести місяців, починаючи з дати початку надання послуг за контрактом.

До тринадцятого місяця ви забронювали $360 000, виставили рахунків на $120 000, визнали $130 000 доходу і маєте нульовий залишок доходів майбутніх періодів (перша щорічна передоплата була повністю зароблена). Безпосередньо перед виставленням другого рахунку ви переходите в зону контрактного активу — ви визнали дохід, за який ще не виставили рахунок. Другий інвойс конвертує цей контрактний актив назад у дебіторську заборгованість, і цикл повторюється.

Саме такі нюанси втрачаються, коли стартап намагається керувати SaaS-бізнесом за допомогою касового методу обліку.

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

ASC 606 (який кілька років тому замінив сукупність старих галузевих правил) зводить визнання доходу до п'яти кроків, які ви застосовуєте до кожного контракту:

Ідентифікація контракту. Він може бути письмовим, усним або таким, що мається на увазі, — але обидві сторони мають його схвалити, права та умови оплати мають бути зрозумілими, контракт повинен мати комерційну сутність, а отримання оплати має бути ймовірним.
Ідентифікація зобов'язань до виконання. "Зобов'язання до виконання" — це окрема обіцянка. Для стандартної SaaS-підписки зобов'язання зазвичай одне: надання безперервного доступу до платформи протягом терміну підписки.
Визначення ціни операції. Це винагорода, яку ви очікуєте отримати — фіксована плата плюс оцінка змінних елементів, таких як доплата за перевищення лімітів використання, знижки або об'ємні дисконти (з урахуванням обмежень, щоб ви не переоцінили дохід).
Розподіл ціни операції. Якщо контракт містить кілька зобов'язань до виконання (підписка + впровадження + преміум-підтримка), ви розподіляєте загальну ціну між ними на основі їхніх окремих цін продажу.
Визнання доходу. У міру виконання кожного зобов'язання. Для поточних послуг підписки це відбувається рівномірно протягом часу. Для результатів, що надаються в певний момент часу (онбординг, певні професійні послуги), — у момент надання.

Стандарт звучить просто. Складність полягає в професійних судженнях на кожному кроці — особливо на другому (що є "окремим"?) та третьому (який обсяг змінної винагороди є занадто спекулятивним для визнання?). Документуйте ці рішення зараз, поки угода ще свіжа. Через шість місяців ніхто не згадає, чому плата за впровадження розглядалася як окреме зобов'язання, а ваш аудитор обов'язково запитає про це.

Каскад відкладеного доходу

Каскад відкладеного доходу (deferred revenue waterfall) — це операційний двигун SaaS-бухгалтерії. Це графік, який за кожним контрактом окремо демонструє, коли саме кожен долар виставленого, але ще не заробленого доходу, перейде в категорію визнаного доходу. Правильно побудований каскад одночасно створює три артефакти: сальдо відкладеного доходу для балансу, показник визнаного доходу для звіту про фінансові результати та прогноз доходу на майбутнє, який ви вже бачите, оскільки він закріплений контрактами.

Механіка перенесення залишків

У найпростішому вигляді каскад щомісяця підпорядковується єдиній тотожності:

Початковий відкладений дохід + Новий створений відкладений дохід − Визнаний дохід = Кінцевий відкладений дохід

Розглянемо приклад. SaaS-компанія починає квітень із $500,000 відкладеного доходу в балансі. Протягом квітня вона виставляє рахунки на $180,000 за новими річними підписками та продовженнями. У квітні вона визнає $90,000 доходу за раніше виставленими контрактами (а також із тієї частини нових рахунків за квітень, що стосується послуг у квітні). Кінцеве сальдо:

$500,000 + $180,000 − $90,000 = $590,000

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

Розподіл на поточні та довгострокові зобов'язання

Згідно з GAAP, відкладений дохід є зобов'язанням, а зобов'язання класифікуються як поточні (погашаються протягом дванадцяти місяців) або довгострокові (погашаються пізніше). У разі однорічної підписки з річною оплатою весь відкладений залишок є поточним. У трирічній угоді з річною оплатою кожен рахунок-фактура генерує повністю поточний відкладений залишок, оскільки ця попередня оплата буде визнана протягом дванадцяти місяців. Але у трирічному контракті з повною передоплатою $360,000 ви робите розподіл: $120,000 поточних (1–12 місяці обслуговування) та $240,000 довгострокових (13–36 місяці).

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

Що прогнозує каскад

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

Місток Бронювання → Рахунки → Дохід → Готівка

Коли каскад запущений, ви можете об'єднати його з рештою циклу "від замовлення до готівки" (order-to-cash):

Нові бронювання (підписана TCV)
    ↓
Виставлені рахунки (Billings) ──→ Дебіторська заборгованість
    ↓                                   ↓
Відкладений дохід ←────────────── Отримана готівка
    ↓
Визнаний дохід (Звіт про прибутки та збитки)

Кожного періоду кожна з цих стрілок створює число. Нові бронювання з'являються у звіті з продажів. Виставлені рахунки — у звіті про дебіторську заборгованість. Отримана готівка — у звіті про рух грошових коштів. Відкладений дохід — у звіті про рух зобов'язань. Визнаний дохід — у звіті про прибутки та збитки. Якщо ці п'ять чисел не узгоджуються між собою — якщо ви не можете провести стейкхолдера від "ми підписали на $X у цьому кварталі" до "ми визнали$ Y у цьому кварталі" через проміжні зміни в балансі — у вашій історії є прогалина, і вам потрібно знайти її раніше за інших.

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

Місток ARR та чому він має узгоджуватися з каскадом

ARR (річний повторюваний дохід) — це управлінська метрика, а не метрика GAAP. Вона приблизно оцінює вартість вашого портфеля підписок у річному вимірі — як би виглядав дохід від підписки протягом наступних дванадцяти місяців у конкретний момент часу, якби жоден контракт не змінився?

ARR змінюється через чотири канали кожного періоду:

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

Початковий ARR + Новий + Розширення − Скорочення − Відтік = Кінцевий ARR

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

П'ять граничних випадків, які руйнують більшість моделей

Стандартні SaaS-субрегістри добре справляються з простими ситуаціями — чистою річною передплатою, сплаченою авансом без жодних змін. Але саме у складних випадках виникає більшість помилок. Готуйтеся до них з першого дня.

1. Початок надання послуг у середині періоду

Контракт, підписаний 18 квітня з датою початку надання послуг 22 квітня, має визнавати 9/30 місячного регулярного доходу (MRR) у квітні, а не повний місяць. Якщо ваш субрегістр округлює дані до повних місяців, ви будете помилятися на кілька сотень доларів за кожним контрактом — це здається дрібницею, поки у вас не з'являться тисячі контрактів, а сукупна помилка не стане шестизначною.

2. Модифікації контрактів

Клієнт додає ще 20 робочих місць на середині другого року трирічної угоди. Стандарт ASC 606 встановлює конкретні правила: якщо модифікація додає окремі товари або послуги за ціною, що відображає їхню ціну відокремленого продажу, вона розглядається як окремий контракт. В іншому випадку вам може знадобитися перерозподілити ціну транзакції, що залишилася, між зобов'язаннями до виконання, які ще не були закриті. Більшість субрегістрів добре справляються з простим сценарієм «окремого контракту» і непомітно дають збій на другому. Перевірте свій.

3. Багатокомпонентні контракти

Річна передплата на платформу за 30 000 доларів у пакеті з одноразовою платою за впровадження у 6 000 доларів — це два зобов’язання до виконання, якщо впровадження є відокремленою послугою. Розподіліть ціну транзакції у 36 000 доларів між ними на основі ціни відокремленого продажу (яка може відрізнятися від ціни за позицією в інвойсі, якщо була надана знижка), потім визнайте частину впровадження в момент фактичного надання послуги, а частину передплати — пропорційно протягом терміну дії. Якщо ви звалите все в одну купу і визнаєте дохід рівномірно, ви занизите дохід за перший квартал і завищите його за решту року.

4. Змінна винагорода

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

5. Скасування та повернення коштів

Клієнт скасовує підписку на сьомому місяці річного передплаченого контракту. Якщо ваші умови не передбачають повернення коштів, ви продовжуєте визнавати дохід за решту п'яти місяців — отримані кошти належать вам, і хоча послуга більше не надається, зобов'язання до виконання вже було передано клієнту (це оціночне судження, яке варто задокументувати). Якщо ви пропонуєте пропорційне повернення коштів, ви сторнуєте залишок доходу майбутніх періодів і виплачуєте гроші клієнту. Графік визнання доходу (waterfall) повинен враховувати цю різницю. Якщо ваш субрегістр розцінює кожне скасування як повернення коштів, ваш дохід буде хронічно занижений.

Чому це важливо не лише для аудиту

Засновники іноді запитують, чи дійсно вся ця складність необхідна при виторгу (ARR) в 1 млн доларів. Чесна відповідь: технічно ви можете це відкласти. Практично — не варто. Три причини:

Перевірка на наступному раунді зачепить минуле. Інвестор раунду B попросить фінансову звітність, що відповідає стандарту ASC 606, за останні два-три роки. Якщо ви перейдете з касового методу на метод нарахування за день до підписання умов угоди (term sheet), ви проведете весь період перевірки (due diligence), відтворюючи графіки визнання доходу за два роки під тиском часу. Саме тоді з'являються критичні помилки.
Ви почнете керувати бізнесом на основі хибних цифр. Засновник, який приймає рішення щодо ціноутворення, найму та витрат на основі касових надходжень у передплатному бізнесі, діє наосліп. Саме графік визнання доходу показує, чи був минулий місяць справжнім місяцем зростання, чи просто артефактом білінгового циклу.
Дисципліна — це ваша конкурентна перевага. Передплатні бізнеси, які чітко звітують про ARR, доходи майбутніх періодів та визнаний дохід, виглядають в очах інвесторів зовсім інакше, ніж ті, що не можуть цього зробити. Покупці та інвестори платять значну премію за прозорість і зрозумілість.

П'ятикрокова модель, графік визнання доходів майбутніх періодів та звірка замовлень, рахунків і доходів — це не бюрократичні витрати. Це інструменти, які дозволяють вам бачити власний бізнес. Налаштуйте їх раніше, запускайте щомісяця і дозвольте їм працювати на ваш капітал.

Тримайте свої бухгалтерські книги підписок готовими до аудиту з першого дня

Успіх SaaS або бізнесу за підпискою залежить від достовірності показників доходу. Інвестори, аудитори та кредитори прагнуть одного — чіткого шляху від підписання контракту до визнання доходу, з узгодженням залишку відкладених доходів на кожному етапі. Beancount.io пропонує систему обліку у форматі простого тексту з контролем версій, яка забезпечує засновникам та фінансовим командам повну прозорість кожної транзакції та кожного контракту — без «чорних скриньок», прив'язки до постачальника та з повним аудиторським слідом, у якому можна здійснювати пошук за допомогою grep. Почніть безкоштовно та створюйте такі записи про доходи, які перетворять перевірку (due diligence) з авралу на просту формальність.