Перейти к основному содержимому

Фиксированный минимум плюс превышение: как ASC 606 на самом деле требует признавать выручку SaaS с оплатой по факту использования

Опубликовано 10 мин чтенияMike ThriftMike Thrift
Фиксированный минимум плюс превышение: как ASC 606 на самом деле требует признавать выручку SaaS с оплатой по факту использования
Содержание страницы

Вы только что закрыли самую крупную сделку в недолгой истории компании: годовой минимум на $120 000 плюс $0,10 за каждый вызов API сверх включенного лимита. Ваша биллинговая система уже считает потребление, и очевидный бухгалтерский подход, кажется, таков: «признавать выручку, когда они используют». Этот инстинкт верен ровно для половины контракта — и достаточно ошибочен для другой половины, чтобы подарить вашему аудитору корректировку на конец года.

Оплата по факту использования сегодня — способ выставления счетов по умолчанию для SaaS-компаний, а не экзотическое исключение: более 59% SaaS-бизнесов имели структуру с оплатой по факту использования в 2025 году против примерно 40% двумя годами ранее. Большинство таких сделок — не чистый pay-as-you-go. Это гибриды: фиксированный минимум, который дает скидку, плюс измеряемое превышение сверху. По 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 рассматривает как исполняемые во времени. Правильная мера прогресса — истекшее время, и простейшая достоверная схема — равномерная: одна двенадцатая минимума каждый месяц.

Каждый крупный поставщик с оплатой по факту использования приходит к одному и тому же решению по этой половине. В отчете 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 миллиона вызовов ниже общего лимита, а контракт предусматривает «используй или потеряй», этот дефицит не становится автоматически бонусной выручкой в декабре. Неиспользованные предоплаченные суммы — неиспользование — признаются только в рамках дисциплинированной политики: пропорционально использованию по мере осуществления прав или когда вероятность осуществления становится маловероятной. Напишите политику до декабря, применяйте ее последовательно и раскрывайте ее. Обнаружение неиспользования во время аудита — это способ задержать чистое заключение.

Ваш чек-лист закрытия месяца для схемы «минимум плюс превышение»​

Превратите правила выше в повторяемое закрытие. Каждый месяц, в таком порядке:

  1. Выгрузите данные счетчика и сверьте их с системой тарификации. Тарифицированное использование по клиентам должно сверяться с входными данными для счетов биллинговой системы с точностью до вызова. Исследуйте расхождения до того, как что-либо проведете, — сбой счетчика это проблема полноты выручки, а не заявка в IT.
  2. Высвободите базовую часть. Одну двенадцатую каждого активного минимума из отложенной выручки в выручку по подписке. Водопад отложенной выручки, который сводит входящий остаток плюс новые счета минус высвобождения к исходящему остатку, — это контроль, который аудиторы запрашивают первым; просмотрите его в Fava с фильтром по вашим счетам отложенной выручки, и ошибки формы сразу бросятся в глаза.
  3. Проведите превышения по счетчику, затем начислите невыставленный хвост. Выставленное превышение дебетует дебиторскую задолженность; использование, измеренное после последнего биллингового цикла, дебетует начисленную выручку. Оба кредитуют выручку по использованию в месяце использования.
  4. Скорректируйте любые оценки. Если вы оцениваете превышения равномерно, сравните признанное с начала года с измеренным с начала года и проведите досчет. Если вы признаете по мере возникновения, этот шаг превращается в пятиминутную проверку на разумность — еще одна причина, по которой стартапам следует начинать именно с этого.
  5. Проанализируйте покрытие обязательств. Для каждого клиента сравните накопленную стоимость использования с накопленной высвобожденной базовой частью. Клиент, расходующий значительно выше своего минимума, — это разговор о расширении; клиент значительно ниже — риск непродления и, возможно, будущая проводка по неиспользованию. В любом случае финансы должны заметить это раньше продаж.

Начните с выгрузки счетчика за этот месяц: сверьте ее с тем, что признала ваша книга, в разрезе базовой части и использования, и подтвердите, что два графика идут независимо. Если это так, ваш учет по схеме «минимум плюс превышение» уже опережает большинство компаний вашего размера — и ваш следующий аудит только что стал короче.

Источник: https://beancount.io/ru/blog/2026/11/09/committed-baseline-plus-overage-asc-606-usage-based-revenue-recognition-guide

Опубликовано: 9 ноября 2026 г.

9 мин чтения

Признание выручки для биллинга SaaS с оплатой по факту использования: руководство основателя по ASC 606

Согласно ASC 606, выручка на основе потребления признается по мере того, как…

revenue-recognition
saas
10 мин чтения

Клиент оспорил счёт за превышение лимита API: почему сторнирование метрической выручки — это не то же самое, что возврат средств

Оспоренный счёт за превышение сторнирует признанную выручку в обязательство по…

revenue-recognition
saas
8 мин чтения

Биллинг токенов: Руководство по признанию выручки для SaaS-сервисов с оплатой по использованию AI

ASC 606 по-прежнему регулирует ценообразование на основе токенов AI, но оценки…

revenue-recognition
saas
10 мин чтения

Гарантия доступности вашего SaaS — это не просто юридическое обещание: почему компенсации за простои уменьшают выручку по ASC 606

Компенсации за простои по SLA являются переменным возмещением по ASC 606 — они…

saas
revenue-recognition
11 мин чтения

Ценообразование на основе результата для агентного ИИ-программного обеспечения как услуги: как признавать выручку, когда клиенты платят за каждый успешный результат

Согласно ASC 606, договор на агентный ИИ, оплата по которому производится за…

revenue-recognition
saas