Спросите основателя SaaS-компании в 2022 году, какой доход они зафиксируют в этом месяце, и ответом будет формула в электронной таблице: количество мест умножить на цену, скорректированную пропорционально оставшимся дням контракта. Задайте тот же вопрос сегодня основателю AI-компании, и честный ответ будет: "Это зависит от того, сколько наши клиенты использовали модель." Потребление токенов может удвоиться за неделю, когда клиент запускает новую функцию в производство, или застопориться, когда он приостанавливает эксперимент. Нет фиксированного количества мест, на которое можно было бы опереться при прогнозировании.
Этот переход от подписки к потреблению — это не просто ценовое решение. Это бухгалтерская проблема, и она напрямую подпадает под стандарт 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. Вместо этого вы оцениваете переменное вознаграждение, используя метод ожидаемой стоимости или наиболее вероятной суммы, при условии, что вы не должны признавать суммы, по которым "значительная реверсия" вероятна после устранения неопределенности.
Минимальное обязательство плюс превышение. Клиент обязуется, скажем, потреблять на $2 000 в месяц и платит больше, если превышает это значение. Здесь минимальный порог ведет себя как фиксированное вознаграждение — признавайте его на систематической основе по мере получения клиентом стоимости — в то время как все, что превышает минимум, является переменным вознаграждением, подпадающим под те же правила оценки и ограничений. Этот гибрид постоянно встречается в ценообразовании ИИ: базовая плата за платформу плюс тарифицируемый вывод сверху.
Знание того, в какой форме вы находитесь, меняет ваши бухгалтерские проводки, примечания к раскрытию информации и степень беспокойства вашего аудитора по поводу ваших оценок.
Практический метод, который фактически используют большинство AI-компаний
Вот хорошие новости: в ASC 606 есть упрощенный подход, созданный именно для такой ситуации, и большинство хорошо структурированных контрактов на основе использования соответствуют ему.
Практический метод "права на выставление счета" (ASC 606-10-55-18) позволяет вам полностью пропустить оценку общего вознаграждения по контракту. Если то, что вы выставляете по счету за каждый период, напрямую соответствует стоимости, полученной клиентом в этом периоде — вы взимали $0.002 за 1 000 токенов, клиент использовал 4 миллиона токенов, вы выставляете счет на $8 — вы можете просто признать эти $8 в качестве выручки в том периоде, когда она была заработана. Никакого прогнозирования, никакого анализа ограничений, никакой переоценки при каждом закрытии периода.
Подвох кроется во фразе "соответствует напрямую". Если ваше ценообразование имеет уровни, где ставка за единицу падает по мере увеличения объема, или пакетные скидки, которые нечетко соотносятся с периодом, в котором произошло использование, этот метод может выйти из строя — выставленная сумма перестает представлять стоимость этого периода, и вы возвращаетесь к полной оценке переменного вознаграждения. Внимательно проверьте свою структуру ценообразования с учетом этого теста, прежде чем предполагать, что этот метод применяется единообразно ко всем вашим контрактам.
Большинство контрактов на основе потребления ИИ также подпадают под серийную обработку согласно ASC 606-10-25-14: вместо учета каждого вызова API как отдельного микро-обязательства по исполнению, вы рассматриваете весь поток использования как одно единое обязательство по исполнению, удовлетворяемое со временем. Именно это делает метод выставления счета административно осуществимым — вы не отслеживаете тысячи отдельных обязательств, вы отслеживаете одну непрерывную услугу с переменной ценой.
Предоплаченные кредиты: отложенная выручка и проблема сгорания
Многие ИИ-платформы продают пакеты предоплаченных кредитов — купите токены на 500 долларов авансом, и используйте их в течение следующих месяцев. Эта структура популярна, поскольку она улучшает денежный поток и обеспечивает приверженность клиентов, но она влечет за собой два бухгалтерских обязательства, которые основатели регулярно упускают из виду.
Отложенная выручка по неиспользованному остатку. В момент поступления денежных средств за предоплаченный пакет ни одна из этих сумм еще не является выручкой. Это обязательство — вы должны клиенту либо услугу, либо возврат средств. Выручка переходит из строки отложенной выручки в отчет о прибылях и убытках только по мере фактического потребления токенов. Основатель, который учитывает полные 500 долларов в день их получения, завышает выручку, и ему придется это исправить, обычно в самое неподходящее время: во время комплексной проверки при привлечении финансирования, когда аудитор пересчитает график и вычтет разницу из периода, который уже был представлен инвесторам.
Сгорание кредитов, которые так и не были использованы. Некоторые клиенты покупают пакет кредитов и не успевают использовать его полностью до истечения срока действия. Этот неиспользованный остаток — сгорание — это не просто "бесплатные деньги", которые вы признаете в день истечения срока действия кредитов. Согласно ASC 606, вы должны оценить коэффициент сгорания на основе исторических моделей использования и признавать этот расчетный объем сгорания пропорционально, как небольшое увеличение выручки наряду с фактическим использованием, вместо того чтобы ждать истечения срока, чтобы учесть все сразу. Если у вас еще нет истории использования (что часто бывает для новой программы кредитов), консервативный подход заключается в том, чтобы подождать, пока она появится, признавая сгорание только по истечении срока действия в это время, и пересмотреть политику, как только у вас будет несколько когорт данных.
Где дисциплина ограничения действительно имеет значение
"Ограничение" на переменную компенсацию звучит абстрактно, пока вы не пережили квартал, когда использование крупного клиента выросло в 4 раза, а затем вернулось к норме. ASC 606 требует включать переменную компенсацию в вашу оценку выручки только в той степени, в которой вероятно, что значительная корректировка не потребуется позднее. На практике это означает:
- Первый год новой ценовой модели: придерживайтесь консервативного подхода. С уверенностью признавайте согласованные минимумы и фактические показатели; относитесь к любым прогнозам, выходящим за рамки выставленного счета/фактического использования, с реальным скептицизмом, поскольку у вас нет сопоставимых контрактов для сравнения.
- По мере накопления истории использования: ваше ограничение может стать менее строгим, потому что теперь у вас есть обоснованная база (использование этим клиентом варьировалось между X и Y в течение шести месяцев подряд) для более точной оценки.
- При каждом закрытии периода: переоценивайте. Переменная компенсация — это не число "установил и забыл" — она пересматривается в каждом отчетном периоде по мере поступления новой информации, при этом кумулятивная корректировка доначисления проходит через текущий период.
Для финансовой команды, управляющей этим по сотням или тысячам контрактов, оперативное решение заключается в согласовании вашей биллинговой системы и вашего реестра признания выручки до закрытия периода, а не после — так данные об использовании сверяются автоматически, вместо того чтобы требовать ручного аудиторского следа в конце каждого месяца.
Почему это важно, даже если вы небольшая компания
Если вы стартап по ИИ-инструментам из двух человек, выставляющий счета нескольким клиентам по токенам, заманчиво рассматривать все это как "то, чем мы займемся, когда привлечем инвестиции серии A". Это реальный риск. Ошибки в признании выручки — одни из наиболее частых замечаний при комплексной проверке SaaS-компаний в рамках привлечения финансирования, и ценообразование на основе использования умножает количество экспертных суждений, которые аудитор захочет увидеть задокументированными: какие контракты используют упрощенный порядок выставления счетов, какой коэффициент сгорания вы приняли и почему, как вы справились с кварталом, когда использование клиентом резко возросло.
Правильное выстраивание механики с первого дня — даже в небольших масштабах — означает, что вам не придется позже восстанавливать восемнадцать месяцев истории выручки в условиях сжатых сроков. Это также означает, что цифры, которые вы используете внутри компании для принятия решений о ценообразовании и найме, на самом деле точны, а не завышены за счет непризнанной отложенной выручки, находящейся там, где ее не должно быть.
Ведите учет так же прозрачно, как и вашу модель ценообразования
Ценообразование на основе использования и токенов действительно сложнее учитывать, чем фиксированную ежемесячную подписку, но эта сложность поддается аудиту — она просто требует документирования структуры вашего контракта, обоснования ваших ограничений и ваших допущений по сгоранию по мере работы, а не их ретроспективного внедрения позже. Учет Beancount.io в виде обычного текста делает этот документационный след явным: каждая запись о признании выручки, остаток отложенной выручки и корректировка по сгоранию хранится в версионированном тексте, который вы (или ваш аудитор) можете отследить построчно, вместо того чтобы быть скрытым в "черном ящике" биллинговой платформы. Начните бесплатно и ведите свою бухгалтерскую книгу так же прозрачно, как и модель ценообразования, которую вы на ней строите.