ASC 606 для SaaS-стартапів: п'ятикрокова модель, відкладений дохід та помилки, що руйнують аудити

Засновник отримав $120 000 річних передоплат в останній день грудня і облікував їх усі як дохід за четвертий квартал. Рада директорів святкувала успіх. Через шість місяців, під час дью-ділідженсу раунду Series A, аудиторська фірма перерахувала показники за рік, перенесла $90 000 доходу назад у категорію відкладеного доходу, і закриття раунду затрималося на два місяці. Угоду все ж закрили — але за нижчою оцінкою, ніж було вказано в початковому терм-шиті.

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

Якщо ви керуєте підписочним бізнесом, ось що насправді вимагає ASC 606, п’ятиетапна модель, яку ваш аудитор буде перевіряти рядок за рядком, і повторювані помилки, які непомітно псують чисті показники доходу.

Чому ASC 606 існує і чому це має хвилювати фаундерів SaaS

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

ASC 606 — виданий Радою з розробки стандартів фінансового обліку (FASB) і введений у дію для приватних компаній з 2019 року — замінив цю розрізненість єдиною універсальною базою. Головний принцип простий: визнавати дохід у міру передачі контролю над товаром або послугою клієнту в сумі, яка відображає очікувану винагороду.

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

Три причини, чому це важливо ще до появи аудитора:

1. Інвестори читають звітність за GAAP. Досвідчені інвестори моделюють вашу юніт-економіку на основі ваших фінансових показників. Якщо ваші показники MRR, ARR та валової маржі ґрунтуються на політиці визнання не за GAAP, ви витратите час під час дью-ділідженсу на їх перерахунок.
2. Перерахунки лякають раду директорів. Чітка політика доходу з першого року коштує значно дешевше, ніж відновлення трирічної історії під час раунду Series A.
3. Податковий та бухгалтерський облік розходяться. Касовий метод може підходити для ранньої податкової звітності, але згодом вам знадобиться фінансова звітність за методом нарахування. Початок роботи за методом нарахування з першого дня запобігає болісним ретроактивним виправленням.

П’ятиетапна модель у перекладі для SaaS

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

Етап 1: Ідентифікація договору з клієнтом

Договір згідно з ASC 606 повинен мати схвалення обох сторін, ідентифіковані права та зобов’язання, визначені умови оплати, комерційну суть та ймовірність отримання винагороди. Для більшості SaaS-бізнесів підходять підписана форма замовлення, електронна угода (click-through agreement) або генеральна угода про надання послуг разом із технічним завданням (SOW).

Остерігайтеся двох пасток:

• Безкоштовні пробні версії та пілоти. 30-денна безкоштовна пробна версія зазвичай не є договором згідно з ASC 606, оскільки клієнт не має зобов’язання платити. Договір починається, коли набувають чинності платні умови.
• Автопролонгації. Якщо ваш клієнт перебуває на щомісячному автоподовженні, розглядайте кожен період поновлення як відповідний термін договору, якщо тільки не передбачено штрафу за розірвання.

Етап 2: Ідентифікація зобов’язань до виконання

Зобов’язання до виконання — це обіцянка передати окремий товар або послугу. Питання, яке варто поставити: чи отримає клієнт вигоду від цього самого по собі, і чи можна це ідентифікувати окремо від інших обіцянок у договорі?

Для типової SaaS-угоди загальні зобов’язання до виконання включають:

• Основну SaaS-підписку (доступ до платформи)
• Послуги з впровадження, онбордингу або міграції даних
• Навчання, преміум-підтримку або послуги клієнтського успіху
• Кастомні інтеграції або розробку
• Одноразові збори за налаштування або активацію

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

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

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

Ціна операції — це сума відшкодування, на яку ви очікуєте мати право в обмін на передачу обіцяних товарів або послуг. Для фіксованої річної передплати у розмірі 24 000 доларів США без жодних змінних це досить просто.

Ситуація ускладнюється, якщо контракт містить:

• Знижки та кредити (мають бути розподілені між зобов’язаннями до виконання)
• Змінне відшкодування, наприклад, комісії на основі обсягу використання, багаторівневе ціноутворення або знижки за обсяг
• Права на повернення коштів або кредити за рівень обслуговування (SLA), які фактично обмежують суму відшкодування
• Значні фінансові компоненти у багаторічних угодах із передоплатою

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

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

Крок 4: Розподіл ціни операції між зобов’язаннями до виконання

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

Приклад. Клієнт підписує річний контракт на:

• 20 000 доларів — річна передплата
• 5 000 доларів — проєкт із впровадження
• Загальна сума контракту: 25 000 доларів

Якщо ви продаєте передплату окремо за 20 000 доларів, а впровадження окремо за 5 000 доларів, то SSP відповідають контрактним цінам, і перерозподіл не потрібен. Дохід від впровадження у розмірі 5 000 доларів визнається після завершення впровадження; дохід від передплати у розмірі 20 000 доларів визнається по 1 666,67 доларів на місяць протягом дванадцятимісячного терміну.

Але припустимо, що ви об’єднали цей самий контракт у пакет за фіксовану ціну 22 000 доларів, щоб виграти угоду. Тепер у вас є знижка у 3 000 доларів, яку потрібно розподілити. Використовуючи відносну SSP, ви розподіляєте знижку пропорційно: 2 400 доларів на передплату та 600 доларів на впровадження. Дохід від впровадження визнається у сумі 4 400 доларів після завершення; дохід від передплати визнається у сумі 17 600 доларів, розподіленій на дванадцять місяців.

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

Крок 5: Визнання доходу під час (або в міру) виконання зобов’язання

Нарешті, ви фактично відображаєте дохід в обліку. Тригером є передача контролю — момент, коли клієнт отримує можливість керувати використанням товару чи послуги та отримувати практично всі залишкові вигоди від них.

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

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

Саме тут у вашому балансі з’являється механізм відкладеного доходу. Грошові кошти, отримані за послуги, які ще не надані, знаходяться на рахунку зобов’язань під назвою відкладений дохід (або контрактне зобов’язання згідно з термінологією ASC 606). Щомісяця ви рекласифікуєте частину, яка тепер є заробленою, як визнаний дохід.

Графік відкладеного доходу: роз’яснення

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

Чіткий графік відображає для кожного активного контракту:

• Дату початку та дату закінчення контракту
• Загальну ціну операції, розподілену на кожне зобов’язання до виконання
• Модель визнання (щомісячно лінійним методом, у певний момент часу, за відсотком готовності)
• Накопичену суму, визнану на сьогодні
• Залишок відкладеного доходу

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

Три правила, що підтримують надійність графіка:

1. Звіряйтеся щомісяця, а не щокварталу. Помилки накопичуються. Виявляйте їх у тому місяці, коли вони виникли.
2. Прив’язуйте графік до контрактів, а не до рахунків-фактур. Рахунки — це події білінгу; контракти визначають зобов’язання щодо визнання доходу. Завжди використовуйте контракт як єдине джерело істини.
3. Негайно документуйте зміни. Оновлення, зниження рівня послуг, скасування та продовження контрактів потребують чіткого бухгалтерського обліку. Зміна, яка подвоює обсяг і термін, зазвичай розглядається як новий контракт; зміна, яка доповнює існуючий контракт, зазвичай є його продовженням. Документуйте, який підхід ви обрали і чому.

Ведення точних фінансових записів з першого дня є критично важливим — графік відкладеного доходу неможливо реконструювати заднім числом, якщо ваша історія транзакцій заплутана. Текстовий бухгалтерський облік (plain-text accounting) робить таку дисципліну природною, оскільки кожен запис підлягає аудиту, підтримує контроль версій та може бути перевірений через порівняння змін (diff).

Шість помилок, що гублять аудити

Нижче наведено повторювані помилки, які з'являються у висновках SaaS-аудитів, розкриттях про перерахунок звітності та звітах про затримки в перевірці (diligence). Кожній з них можна запобігти за допомогою дисциплінованого ведення бухгалтерії.

Помилка 1: Визнання річної передоплати як доходу в перший день

Річна передоплата в розмірі $24,000 — це не $24,000 доходу. Це $2,000 визнаного доходу на місяць і $24,000 готівки, що надходить у категорію відкладеного доходу в день отримання коштів. Це найпоширеніша помилка серед SaaS-компаній з виторгом менш як $10 млн, і саме вона найчастіше стає причиною перерахунку звітності.

Помилка 2: Визнання вартості багаторічного контракту авансом

Трирічний контракт на суму $360,000 генерує $10,000 щомісячного доходу протягом тридцяти шести місяців. Він не генерує $360,000 доходу в рік підписання контракту, навіть якщо клієнт вніс повну передоплату.

Помилка 3: Неправильна класифікація послуг із впровадження

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

Помилка 4: Відсутність обліку модифікацій

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

Помилка 5: Недбала оцінка змінної винагороди

Компанії з ціноутворенням на основі фактичного використання (usage-based pricing) часто записують у дохід те, що вказано в рахунку, не застосовуючи тест на обмеження. Якщо використання є сильно мінливим, а клієнт має положення про мінімальні зобов'язання або рівні обсягів, визнання доходу має відображати обмежену очікувану вартість, а не максимально можливу суму рахунку.

Помилка 6: Недостатня документація

Коли аудитор запитує: «Чому ви виділили $4,400 знижки на впровадження?», відповіддю має бути письмова записка з доступними даними про окрему ціну продажу (SSP), а не «нам здалося, що так буде правильно». Недостатня документація змушує аудитора за замовчуванням застосовувати консервативний підхід, що зазвичай означає менший обсяг визнаного доходу.

Налаштування готового до аудиту процесу визнання доходу з першого дня

Більшість SaaS-компаній на ранніх стадіях чекають, поки їм знадобиться аудит — зазвичай під тиском раунду Series A — щоб серйозно взятися за ASC 606. На той час їм доводиться відновлювати дво- або трирічну історію в умовах дефіциту часу. Кращий план дій:

На стадії Seed:

• Застосовуйте метод нарахування (accrual basis) з першого платного клієнта.
• Ведіть графік відкладеного доходу з першого дня, навіть якщо це просто чиста електронна таблиця.
• Задокументуйте письмову політику визнання доходу. Однієї сторінки цілком достатньо.
• Позначайте кожен контракт датою початку, датою закінчення та схемою визнання.

Під час масштабування до Series A:

• Перенесіть графік відкладеного доходу з таблиць у систему, яка пов'язана з вашими даними про виставлення рахунків.
• Створіть ARR-бридж (звірку), який щомісяця узгоджується з доходом за GAAP.
• Залучіть сертифікованого бухгалтера (CPA) для перевірки вашої політики визнання доходу та шаблонів основних контрактів.
• Проведіть «репетицію перевірки» — уявіть, що ви відповідаєте на запитання аудитора щодо десяти ваших найбільших контрактів.

Перед залученням коштів:

• Проведіть аналіз якості прибутку (QofE) або попередній аудит принаймні за шістдесят днів до запуску раунду. Ризик перерахунку, виявлений до перевірки, — це лише примітка; виявлений під час перевірки — це зміна оцінки компанії.

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

Чисте визнання доходу починається з чистого обліку. Кожен контракт із клієнтом, кожна передоплата, кожна модифікація повинні потрапляти в систему, якій ви можете довіряти та яку можна перевірити. Beancount.io пропонує текстову бухгалтерію (plain-text accounting), яка забезпечує повну прозорість і контроль версій ваших фінансових даних — кожен запис зрозумілий людині, кожна зміна відстежується в git, а ваш графік відкладеного доходу ніколи не розходиться з основними транзакціями. Почніть безкоштовно та побудуйте фундамент, готовий до аудиту, раніше, ніж про це запитає ваш перший інвестор.