Ви щойно закрили найбільшу угоду в недовгій історії вашої компанії: річний фіксований обсяг на $120 000 плюс $0,10 за кожен виклик API понад включений ліміт. Ваша білінгова система вже веде облік, і очевидна бухгалтерська логіка начебто така: «визнавати дохід, коли вони його споживають». Цей інстинкт правильний рівно для половини цього контракту — і достатньо хибний щодо іншої половини, щоб наприкінці року отримати від аудитора коригувальне проведення.
Ціноутворення за споживанням тепер є стандартним способом, яким SaaS-компанії стягують плату, а не екзотичним винятком: понад 59% SaaS-бізнесів мали структуру з оплатою за споживання у 2025 році, порівняно з приблизно 40% двома роками раніше. Більшість цих угод не є чистою оплатою за фактом споживання. Вони гібридні — фіксована база, що купує знижку, плюс вимірюване перевищення зверху. За ASC 606 цей єдиний підпис розпадається на два потоки доходу з протилежними правилами щодо часу визнання. База — це фіксована винагорода, яку розподіляють протягом строку контракту, незалежно від того, чи клієнт зробить хоч один виклик API. Перевищення — це змінна винагорода, яка чекає на лічильник. У цьому посібнику пояснюється чому, разом із бухгалтерськими проведеннями, що це реалізують.
Один контракт, два підходи до визнання доходу
Почнімо зі структури, бо все інше з неї випливає. Угода з фіксованою базою плюс перевищенням має три складові:
- Фіксований мінімум. Клієнт платить $120 000 за рік незалежно від усього. Натомість він отримує доступ до платформи плюс включений ліміт — скажімо, 1 мільйон викликів API на місяць — за ефективною ставкою, значно нижчою за прайс-лист.
- Лічильник перевищення. Споживання понад ліміт тарифікується за ставкою перевищення, зазвичай щомісяця постфактум. У нашому прикладі — $0,10 за виклик.
- Один підпис, один строк. Зазвичай дванадцять місяців, часто з виставленням рахунку авансом або щокварталу, хоча послуга надається поступово протягом року.
ASC 606 проводить цей контракт через свою п'ятикрокову модель — визначити контракт, визначити зобов'язання за виконанням, визначити ціну операції, розподілити її, визнати дохід у міру виконання зобов'язань — і доходить до роздільного вердикту. Фіксовані $120 000 — це фіксована ціна операції за послугу, що надається безперервно протягом дванадцяти місяців, тож вона визнається в часі, зазвичай прямолінійно — по $10 000 на місяць. Перевищення — це змінна винагорода: її сума залежить від майбутнього споживання, тож вона визнається в міру виникнення споживання, або оцінюється авансом лише якщо ви можете подолати навмисно високу планку, що зветься обмеженням. Той самий клієнт, той самий рахунок, два різні графіки.
Практичний наслідок виникає одразу. У повільний місяць, коли клієнт витрачає лише 400 000 викликів, ви все одно визнаєте повні $10 000 базового доходу — клієнт купив рік доступу, і дванадцята частина січня надана. У піковий місяць із 1,5 мільйона викликів ви визнаєте $10 000 плюс 500 000 викликів перевищення по $0,10, тобто $50 000 доходу за споживання. База ніколи не знижується разом зі споживанням, а перевищення ніколи не згладжується в місяці, коли нічого не відбувалося.
Чому база визнається прямолінійно
Бухгалтерська логіка для бази — це спокійніша половина історії. Ваше зобов'язання за виконанням — не «1 мільйон викликів API», а готовність обслуговувати клієнта весь місяць, низка окремих щоденних або щомісячних періодів обслуговування, які ASC 606 вважає виконаними в часі. Правильний показник прогресу — плин часу, і найпростіша вірна модель — прямолінійна: одна дванадцята фіксованого обсягу щомісяця.
Кожен великий постачальник із оплатою за споживання доходить до того самого висновку щодо цієї половини. У формi 10-K Datadog зазначено, що для фіксованої договірної суми, розподіленої пропорційно, дохід визнається пропорційно протягом строку підписки, починаючи з моменту, коли платформа стає доступною. Alkami, що продає банківське програмне забезпечення на основі транзакцій за щомісячними мінімумами, формулює це ще простіше: мінімальні комісії за транзакції визнаються прямолінійно, тоді як комісії за транзакції понад мінімум визнаються в місяці, коли транзакції оброблено. Мінімуми — за плин часу; перевищення — за лічильником.
Є один відомий опонент, про якого варто знати, бо ваш аудитор про нього згадає. Snowflake визнає дохід у міру того, як клієнти споживають обчислення, зберігання та передачу даних — навіть за багаторічними зобов'язаннями щодо потужності — аргументуючи тим, що вартість передається в момент споживання, а не в часі. Ця позиція розкривається помітно й захищається фактами, специфічними для компанії. Якщо ви не готові написати цю аналітичну записку й захищати її під час аудиту, визнавайте базу прямолінійно. Це підхід, якого аудитори очікують від SaaS-компанії на ранній стадії, а відхилення потребують письмової позиції, а не знискання плечима.
Чому перевищення чекають на лічильник
Перевищення — це змінна винагорода, а ASC 606 ставиться до змінної винагороди з підозрою. Ви можете включити її до ціни операції лише тією мірою, якою ймовірно, що жодного значного сторнування не станеться, коли невизначеність буде вирішено, — це обмеження. Для споживання, яке вже відбулося й було виміряне, невизначеності не залишилося, тож визнання доходу від перевищення в місяці споживання завжди проходить планку. Ось чому «визнавати, коли вони споживають» — це типовий вибір більшості SaaS-компаній, і той, який аудитори оскаржують найменше.
Альтернатива — оцінити загальне перевищення за рік авансом і визнавати його пропорційно разом із базою. New Relic робить саме це: він прогнозує споживання понад фіксований обсяг на основі історичних даних плюс перспективних чинників, обмежує оцінку тим, на що очікує мати право, і визнає цю суму протягом строку. Це відповідає стандарту й дає рівніший дохід — але зверніть увагу, що це вимагає. Вам потрібно достатньо історії для достовірного прогнозу, задокументований метод оцінки, аналіз обмеження й процес коригування, коли фактичні дані відхиляються. Для стартапу з шістьма місяцями даних вимірювання й одним великим клієнтом, чиє споживання подвоюється щокварталу, такого файлу ще не існує. Визнавайте перевищення в міру виникнення, доки ваша історія не дасть вам права оцінювати.
Ще одна частина стандарту тихо підтримує простий підхід. Оскільки ваш підписка — це низка окремих щомісячних періодів обслуговування, комісії за споживання, що стосуються конкретного місяця, можна повністю віднести до цього місяця згідно з винятком щодо розподілу змінної винагороди. Простими словами: вам не потрібно прогнозувати рік, щоб правильно облікувати січень. Показник лічильника за січень належить січню — і крапка.
Остання пастка щодо часу — плутанина між виставленням рахунків і визнанням. Якщо ви виставляєте рахунок на фіксований обсяг $120 000 авансом у січні, дохід за січень усе одно становить $10 000 — решта $110 000 лежить у відстроченому доході. І навпаки, споживання перевищення, надане в січні, але виставлене рахунком лише під час лютневого білінгового циклу, усе одно є доходом січня; наприкінці місяця ви нараховуєте його як невиставлений або нарахований дохід. Грошові кошти й рахунки — це події білінгу. Плин часу й лічильник — це події доходу. Ваш контрольний список закриття має тримати ці дві речі окремо.
Бухгалтерські проведення з реальними цифрами
Ось приклад угоди в обліку. Acme підписує 5 січня: річний фіксований обсяг $120 000, 1 мільйон включених викликів на місяць, $0,10 за виклик понад ліміт. Споживання в січні становить 1 021 000 викликів — 21 000 понад ліміт, тобто $2 100. Лютий спокійний — 800 000 викликів, тож перевищення немає взагалі.
2026-01-05 * "Invoice Acme annual platform commit"
Assets:Receivable:Acme 120000.00 USD
Liabilities:Deferred-Revenue:Acme -120000.00 USD
2026-01-31 * "January: release 1/12 of commit"
Liabilities:Deferred-Revenue:Acme 10000.00 USD
Income:Subscription-Revenue -10000.00 USD
2026-01-31 * "January overage: 21000 calls over allowance at 0.10"
Assets:Receivable:Acme 2100.00 USD
Income:Usage-Revenue -2100.00 USD
2026-02-28 * "February: release 1/12 of commit, usage under allowance"
Liabilities:Deferred-Revenue:Acme 10000.00 USD
Income:Subscription-Revenue -10000.00 USDПрочитайте історію, яку розповідає книга обліку. У січні визнається $12 100 на $120 000 виставлених рахунків — різниця в $110 000 є відстроченим доходом, зобов'язанням за ще не надану послугу, а не прибутком. У лютому визнається рівно $10 000, хоча споживання впало на п'яту частину, бо база оплачує доступ, а не виклики. А проведення перевищення існує лише в місяці, коли лічильник перевищує ліміт. Якщо ваш рахунок доходу не показує саме таку форму — рівна база плюс пікове споживання — щось вище за течією налаштовано неправильно.
Зверніть увагу на окремі рахунки доходу. Розділення базового підписного доходу від доходу за споживання — це не косметика: саме це дозволяє вам звітувати про чисте утримання доходу, коефіцієнт приєднання споживання та покриття фіксованого обсягу з головної книги, а не з електронної таблиці. Налаштуйте обидва рахунки в перший день контракту, а не під час першого аудиту.
Чотири помилки, що провокують коригування від аудитора
Визнання фіксованого обсягу як доходу при підписанні. Рахунок на $120 000 відчувається як продаж, і відділ продажів скаже вам, що угоду закрито в січні. Але ви надали один місяць дванадцятимісячної послуги. Усе понад січневі $10 000 — це відстрочений дохід. Компанії, які визнають повний фіксований обсяг авансом, не просто викривляють один місяць — вони позичають одинадцять місяців майбутнього доходу й повертають його у вигляді ганебного перерахунку звітності.
Згладжування нерівномірних перевищень по спокійних місяцях. Усереднення $50 000 перевищення пікового місяця по сусідніх кварталах виглядає акуратно й є неправильним, якщо ви не оцінили загальну суму авансом, не задокументували аналіз обмеження й не скоригували її. Без такого файлу показник лічильника кожного місяця залишається у своєму місяці. Аудитори перевіряють це, порівнюючи визнаний дохід за споживання з виміряним споживанням за періодами; згладжена лінія проти пікового лічильника — найшвидший спосіб провалити цю перевірку.
Дозвіл календарю виставлення рахунків керувати визнанням. Річний авансовий білінг спокушає команди визнавати дохід за датами рахунків. Щоквартальні коригувальні рахунки спокушають їх визнавати перевищення лише тоді, коли виставлено рахунок. Обидва напрямки порушують правило: база йде за календарем обслуговування, перевищення йде за календарем споживання, і жодне не йде за календарем виставлення рахунків. Нарахування наприкінці місяця за виміряним, але невиставленим споживанням — це проведення, якого найчастіше бракує молодим фінансовим командам; закривайте книги через кілька днів після кінця місяця саме для того, щоб лічильник устоявся.
Забути про невикористаний фіксований обсяг. Якщо Acme закінчує рік на 2 мільйони викликів нижче свого загального ліміту й контракт каже «використай або втрать», цей дефіцит не стає автоматично бонусним доходом у грудні. Невикористані передоплачені суми — втрати від невикористання — визнаються лише за дисциплінованою політикою: пропорційно споживанню в міру реалізації прав, або коли ймовірність реалізації стає мінімальною. Напишіть політику до грудня, застосовуйте її послідовно й розкривайте її. Виявлення втрат від невикористання під час аудиту — це те, як затримується чистий висновок.
Ваш контрольний список закриття місяця для «фіксована база плюс перевищення»
Перетворіть наведені вище правила на повторюване закриття. Щомісяця, у такому порядку:
- Вивантажте дані лічильника й звірте їх із рушієм тарифікації. Тарифіковане споживання за клієнтами має звірятися з вхідними даними рахунків білінгової системи до останнього виклику. Досліджуйте розбіжності, перш ніж щось проводити — збій у вимірюванні є проблемою повноти доходу, а не ІТ-тікетом.
- Визнайте базову частину. Одна дванадцята кожного активного фіксованого обсягу з відстроченого доходу в підписний дохід. Каскад відстроченого доходу, що зводить початковий залишок плюс нові рахунки мінус визнання до кінцевого залишку, — це контроль, який аудитори запитують першим; перегляньте його у Fava, відфільтрованому за вашими рахунками відстроченого доходу, і помилки форми одразу впадуть в око.
- Проведіть перевищення з лічильника, потім нарахуйте невиставлений залишок. Виставлене перевищення дебетує дебіторську заборгованість; споживання, виміряне після останнього білінгового циклу, дебетує нарахований дохід. Обидва кредитують дохід за споживання в місяці споживання.
- Скоригуйте будь-які оцінки. Якщо ви оцінюєте перевищення пропорційно, порівняйте визнане з початку року з виміряним з початку року й проведіть донарахування. Якщо ви визнаєте в міру виникнення, цей крок — лише п'ятихвилинна перевірка на розумність; ще одна причина, чому стартапам варто починати саме з цього.
- Перегляньте покриття фіксованого обсягу. Для кожного клієнта порівняйте сукупну вартість споживання з сукупною визнаною базою. Клієнт, який споживає набагато більше свого фіксованого обсягу, — це привід для розмови про розширення; той, хто набагато менше, — це ризик непродовження й, можливо, майбутнє проведення втрат від невикористання. У будь-якому разі фінансовий відділ має помітити це раніше за відділ продажів.
Почніть із цього місячного вивантаження лічильника: звірте його з тим, що визнала ваша книга обліку, розділіть за базою та споживанням і переконайтеся, що два графіки йдуть незалежно. Якщо так, ваш облік за моделлю «фіксована база плюс перевищення» вже випереджає більшість компаній вашого розміру — і ваш наступний аудит щойно став коротшим.
