Ваша страница статуса светилась красным четыре часа в прошлый вторник. К пятнице вы выдали сервисные компенсации каждому пострадавшему клиенту — 10 процентов месячной платы одному, 25 процентов другому — и ваш бухгалтер отразил их так, как это делает большинство небольших SaaS-компаний: как расход на поддержку или маркетинговую уступку, где-то ниже строки выручки. Теперь ваша выручка за месяц завышена, ваш показатель удержания чистой выручки неверен, и если кредитор или покупатель когда-нибудь откроет ваши книги, первый же вопрос будет тем, на который вы не сможете ответить: какую часть заявленной выручки вы вообще имели право оставить себе?
Это не редкий случай. В среднем сейчас на устранение сбоя уходит 196 минут, а малый и средний бизнес оценивает стоимость часа простоя примерно в $8 000 — еще до того, как выдана хотя бы одна компенсация. Каждая компенсация, которую вы предоставляете после сбоя, — это уменьшение цены, которую согласился платить ваш клиент, и по ASC 606 это делает ее переменным возмещением: суммой, которая уменьшает вашу выручку, а не расходом, который находится под ней. В этой статье объясняется, к чему обязывает вас ваш SLA в финансовом выражении, как стандарт предписывает это учитывать и что исправить при следующем закрытии месяца.
Что на самом деле обещает ваш SLA — в долларах, а не в «девятках»
Большинство SaaS-контрактов указывают доступность в «девятках»: 99,9 процента (около 43 минут простоя в месяц), 99,95 процента, 99,99 процента (около 4 минут). Для ваших книг важно не число «девяток», а привязанная к ним шкала компенсаций. Типичный корпоративный SLA звучит примерно так: доступность ниже 99,9 процента дает клиенту 10-процентную сервисную компенсацию; ниже 99,0 процента — 25 процентов; ниже 95,0 процента — полный месяц бесплатно. Некоторые контракты идут дальше, предоставляя право на расторжение, если доступность не достигает целевого уровня несколько месяцев подряд.
Три особенности этой шкалы определяют учет:
Компенсации — это договорная корректировка цены, а не жест доброй воли. Клиент не платит полную цену, а затем получает подарок. Контракт говорит, что цена за плохой месяц — это более низкая цена. Это различие — уменьшение цены против расхода — и есть весь вопрос учета, и контракт отвечает на него еще до того, как ваш бухгалтер откроет главную книгу.
Компенсации обычно ограничены и требуют заявления, а не предоставляются автоматически. Многие SLA требуют, чтобы клиент запросил компенсацию в течение 30 дней, и ограничивают общую сумму компенсаций 30–100 процентами месячной платы. Это значит, что ваша подверженность риску при любом данном сбое ограничена и поддается оценке: вы знаете шкалу, знаете, какие клиенты пострадали, и знаете историческую долю заявлений.
Момент движения денежных средств и момент признания выручки не совпадают. Компенсация, выданная в феврале за январский сбой, обычно появляется как кредит-нота против будущего счета. Денежный эффект наступает тогда, когда счет оплачен, но эффект на выручку относится к январю — периоду, когда вы не предоставили обещанное. Отражение компенсации в месяце ее выдачи против выручки этого месяца искажает сразу два периода.
Почему ASC 606 называет компенсацию за простой переменным возмещением
Основная идея ASC 606 проста: признавайте выручку в размере возмещения, которое вы рассчитываете получить в обмен на предоставление обещанного. Шаг 3 пятишаговой модели — определение цены сделки — это место, где в игру вступает ваш SLA. Цена сделки — не указанная цена в бланке заказа. Это указанная цена минус все, что может вернуться: возвраты, скидки, бонусы за результаты — и сервисные компенсации за недостигнутую доступность.
Руководство PwC по выручке прямо относит компенсации по SLA к этой категории. Переменное возмещение должно оцениваться при заключении договора и обновляться каждый отчетный период одним из двух методов:
- Ожидаемое значение — взвешенное по вероятности среднее по возможным исходам. Хорошо подходит для портфеля клиентов: если история говорит, что 3 процента месячных выставленных счетов обычно возвращаются в виде компенсаций по SLA, ваша ожидаемая компенсация на $100 000 месячных выставлений составляет $3 000.
- Наиболее вероятная сумма — единственный наиболее вероятный исход. Хорошо подходит для бинарной ситуации: один крупный клиент, чей контракт либо запускает компенсацию в $20 000 в этом месяце, либо не запускает ничего.
Затем идет ограничение — та часть, которую основатели чаще всего пропускают. Вы можете включить переменное возмещение в цену сделки — то есть признать выручку — только в той степени, в какой вероятно, что значительного сторнирования не произойдет, когда неопределенность разрешится. Проще говоря: если есть реальный шанс, что вы должны будете вернуть эту компенсацию, не считайте эту часть выручкой пока. Отразите ее как обязательство по возврату средств и скорректируйте, когда станет известна доступность за месяц.
Обратите внимание, что ограничение подразумевает для SaaS-бизнеса со значительной историей сбоев. Если ваш сервис не выполнил SLA в четырех из последних двенадцати месяцев, «мы рассчитываем ничего не задолжать» — это не защитимая оценка. Ваша собственная страница статуса — это Exhibit A для аудитора.
Бухгалтерские проводки: месяц со сбоем
Предположим, один клиент платит $10 000 в месяц, и ваш SLA на 99,9 процента предоставляет 10-процентную компенсацию за любой месяц, когда доступность опускается ниже целевого уровня. Доступность в январе составила 99,4 процента. Вот полный цикл.
При выставлении счета выставленная сумма — это доходы будущих периодов, как обычно: полученные денежные средства (или начисленная дебиторская задолженность) за еще не предоставленную услугу:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Receivable:Customer USD
2026-01-01 open Income:SaaS:Subscription USD
2026-01-01 open Liabilities:Deferred-Revenue:SaaS USD
2026-01-01 open Liabilities:Refund:SLA-Credits USD
2026-01-01 * "Customer" "January invoice — 10,000 monthly subscription"
Assets:Receivable:Customer 10000.00 USD
Liabilities:Deferred-Revenue:SaaS -10000.00 USD
2026-01-31 * "Month-end" "Recognize January revenue net of 500 expected SLA credits"
Liabilities:Deferred-Revenue:SaaS 10000.00 USD
Liabilities:Refund:SLA-Credits -500.00 USD
Income:SaaS:Subscription -9500.00 USD
2026-02-05 * "Customer" "Outage credit issued — January uptime 99.4 percent vs 99.9 SLA"
Liabilities:Refund:SLA-Credits 500.00 USD
Assets:Receivable:Customer -500.00 USDПройдемся по тому, что произошло. На конец месяца вы признали $9 500 выручки и отразили $500 как обязательство по возврату средств — вашу оценку компенсации, которую вызовет январский сбой. Когда фактическая кредит-нота выходит в феврале, она дебетует обязательство, а не выручку и не счет расходов. Январская выручка была верна с самого начала, а февральская выручка не затронута январским сбоем.
Если оценка и факт различаются, разница корректирует выручку в периоде, когда неопределенность разрешается. Оценили $500, но выдали $1 000, потому что заявили два клиента вместо одного? Дополнительные $500 уменьшают выручку, когда вы об этом узнаете. Оценили $500, но никто не заявил? Высвободите $500 в выручку. Счет обязательства — это амортизатор; выручка никогда не пересчитывается из-за рутинной корректировки.
Две детали, которые стоит сделать правильно. Во-первых, обязательство по возврату средств отдельно от доходов будущих периодов: доходы будущих периодов — это за услугу, которую вы еще не предоставили, а обязательство по возврату средств — за предоставленную услугу, которую вы, возможно, должны вернуть. Сведение их вместе скрывает обе истории. Во-вторых, если компенсация относится к будущему периоду — бесплатный месяц, предоставленный в качестве извинения, а не договорная компенсация за прошлый сбой, — это другой анализ, ближе к изменению контракта или существенному праву, и он корректирует будущую выручку, а не прошлую.
Три ошибки, которые основатели SaaS допускают с компенсациями по SLA
Ошибка 1: отражение компенсации как расхода. Это самая распространенная ошибка и самая разрушительная. Запись компенсации за простой в $10 000 как дебет «расходов на поддержку клиентов» или «маркетинговых уступок» оставляет выручку завышенной на $10 000 и изобретает $10 000 расходов, которых не было. Валовая маржа, рост выручки и каждый коэффициент, построенный на выручке, читаются завышенными. По ASC 606 суммы, причитающиеся клиенту, которые не являются платой за отдельный полученный взамен товар или услугу, уменьшают цену сделки. Компенсация за ваш собственный сбой не покупает вам ничего отдельного — она уменьшает выручку, и точка.
Ошибка 2: признание полной выручки сейчас и исправление позже. Некоторые компании отражают полные $10 000 как январскую выручку, а затем учитывают компенсацию в $1 000 против февральской выручки, когда выходит кредит-нота. Теперь оба месяца неверны: январь завышен, февраль занижен. Хуже того, ошибка накапливается в ваших метриках — удержание чистой выручки в январе выглядит отлично, в феврале — слабо, и ни то, ни другое не отражает реальность. Схема с обязательством по возврату средств выше существует именно для того, чтобы каждый период был честным.
Ошибка 3: оценка ноль, потому что сбой «больше не повторится». Ограничение работает на вероятности, а не на оптимизме. Если ваша инфраструктура имела три месяца, запустивших SLA, в прошлом году, оценка в ноль ожидаемых компенсаций не консервативна и не агрессивна — она необоснованна. Аудиторы проверяют эту оценку против истории инцидентов, и покупатели при должной осмотрительности сделают то же самое. Небольшой постоянный резерв, рассчитанный по историческим ставкам заявлений и корректируемый ежемесячно, и точнее, и гораздо легче защитить, чем уверенный ноль, которому противоречит ваша страница статуса.
Как это влияет на метрики, которые читают покупатели и кредиторы
Отражение компенсаций по SLA выше строки выручки или ниже нее меняет каждое число, по которому оценивается SaaS-компания:
- MRR и ARR должны быть за вычетом ожидаемых компенсаций. Если 2 процента выставлений исторически возвращаются как компенсации по SLA, заголовок ARR в $1 млн — это на самом деле $980 000 ожидаемой выручки. Публикация валовой цифры — это то, как основатели в итоге объясняют при должной осмотрительности «проблему оттока», которая на самом деле все время была проблемой компенсаций.
- Удержание чистой выручки поглощает компенсации как сокращение. Клиент, плативший $120 000 в прошлом году и $114 000 в этом после компенсаций за простои, удержался на 95 процентов, а не на 100 — даже если он ни разу не сократил число мест.
- Валовая маржа парадоксальным образом растет, когда вы исправляете ошибку. Перенос компенсаций из расходов на поддержку в контрвыручку уменьшает и выручку, и себестоимость выручки, и, поскольку компенсация превышает связанные с ней расходы, процент маржи улучшается, а выручка падает. Ожидайте этого вопроса и держите наготове пересчитанную историю.
Если вы используете plain-text бухгалтерию, исправление структурное, а не процедурное: выделенный счет Liabilities:Refund:SLA-Credits, проводка на конец месяца, признающая выручку от подписки за вычетом ожидаемой компенсации, и корректирующая проводка, когда выходят кредит-ноты. Документация beancount по схемам признания выручки описывает общую структуру учета доходов будущих периодов, на которой это строится, а история остатка счета возвратов на балансе служит двойным назначением — вашим аудиторским следом для оценки.
Чек-лист на конец месяца, который занимает двадцать минут
- Соберите доступность по уровням клиентов. Ваш мониторинг уже вычисляет это; запросите месячное значение относительно каждого порога SLA, а не только среднее по всему парку.
- Составьте перечень запущенных компенсаций. Для каждого клиента ниже порога вычислите договорную компенсацию по шкале — прежде чем проверять, кто фактически заявил.
- Примените историю ставки заявлений. Если исторически заявляется примерно 60 процентов запущенных компенсаций, ваше ожидаемое значение — 60 процентов от запущенного итога. Задокументируйте ставку и пересматривайте ее ежеквартально.
- Отразите выручку за вычетом оценки. Признайте выручку от подписки с ожидаемой компенсацией, отраженной в обязательстве по возврату средств, как в примере выше.
- Скорректируйте оценку прошлого месяца. Сравните резерв прошлого месяца с фактически выданными кредит-нотами; высвободите или пополните разницу через выручку текущего периода.
- Сверьте остаток обязательства. На счете возвратов должны оставаться только неразрешенные оценки. Все, что старше вашего окна заявлений (обычно 30–60 дней), должно было быть уже высвобождено — растущий устаревший остаток означает, что корректировки пропускаются.
Начните в этом месяце, а не в следующем квартале. Возьмите отчет о доступности за прошлый месяц, вычислите компенсации, которые по вашей шкале SLA вы должны, и сравните это число с тем, что ваши книги показывают как уменьшение выручки. Если книги показывают ноль — а для большинства SaaS-компаний на ранней стадии они показывают ноль — вы нашли свою первую корректирующую проводку, и ваша выручка была завышена ровно на эту сумму каждый подобный месяц.
