Как сверять выплаты Stripe, если вы выставляете счета раз в год, а признаёте выручку ежемесячно

В марте вы закрыли пять годовых сделок, и на ваш счёт в Stripe поступило $60 000. Дашборд сияет, остаток на банковском счёте выглядит героически — а бухгалтер только что сказал, что выручка за март составила $5 000. Никто не ошибается. Вы смотрите на два разных числа, которые просто оказались на одном и том же счёте Stripe: на деньги, которые вы получили, и на выручку, которую вы фактически заработали. Пока вы не сверите эти две величины, каждая выплата от Stripe — это загадка, которую должна решить ваша бухгалтерия.

Это руководство показывает, как SaaS-компании, которые выставляют счета раз в год, но признают выручку ежемесячно, сверяют выплаты Stripe, не задваивая выручку, не искажая отложенную выручку и не давая себя обмануть метрике, которая скрывает весь этот разрыв.

Почему выплаты Stripe — неправильная отправная точка для выручки​

Выплата Stripe выглядит как доход. Она приходит на ваш банковский счёт одним депозитом, у неё есть дата, и кажется, что это заработок за месяц. Но это не так. Выплата — это чистое взаиморасчётное сальдо: валовые списания минус комиссии за обработку, минус возвраты, минус списанные суммы по спорным операциям, собранные вместе по графику выплат Stripe, а не по вашему.

Это создаёт два отдельных искажения, если вы учитываете выплаты как выручку.

Во-первых, вы занижаете выручку. Если клиент заплатил $12 000 за годовой тариф, Stripe удерживает примерно $348 плюс 30 центов и выплачивает остальное. Учитывая выплату, вы записываете чистую сумму как свои продажи и прячете комиссию туда, где вы никогда не сможете её проанализировать — или чисто вычесть.

Во-вторых, и это гораздо опаснее для годового выставления счетов, вы искажаете распределение по времени. Полные $12 000 поступают одной выплатой в январе, но по методу начисления вы зарабатываете их по $1 000 в месяц по мере оказания услуги. Учтите выплату как январскую выручку — и январь выглядит впечатляюще, а с февраля по декабрь всё выглядит мёртвым, хотя бизнес делал ровно одно и то же каждый месяц.

Решение — относиться к выплате как к тому, чем она является, — к денежному переводу, — и признавать выручку по совершенно отдельному треку, определяемому вашими договорами, а не вашими депозитами.

Три числа, которые путают основатели: bookings, billings и выручка​

Любая сверка при годовом выставлении счетов начинается с разделения трёх чисел:

• Bookings (заключённые контракты) — это общая стоимость подписанных договоров. Клиент подписывает годовой контракт на $12 000 в январе: $12 000 в bookings за январь. Booking — это обязательство, а не деньги и не заработок.
• Billings (выставленные счета) — это то, что вы выставляете и получаете. Если по контракту счёт выставляется раз в год авансом, январские billings составят $12 000. Если счёт выставляется ежемесячно, январские billings составят $1 000, хотя booking был $12 000.
• Выручка (revenue) — это то, что вы заработали, оказывая услугу. Один месяц из двенадцатимесячного контракта приносит одну двенадцатую: $1 000 январской выручки в любом случае.

Разрыв между billings и выручкой — это отложенная выручка (также называемая незаработанной выручкой), обязательство в вашем балансе, представляющее услугу, которую вы всё ещё должны оказать. Получите $12 000 в январе и признайте $1 000 — и вы переносите $11 000 отложенной выручки в февраль. Это обязательство не проблема — это доказательство того, что ваша бухгалтерия честна. Оно раскручивается на $1 000 каждый месяц до окончания контракта.

Проще говоря: bookings говорят вам, как идут продажи, billings говорят, как идут деньги, а выручка говорит, как на самом деле работал бизнес. Сверка ломается в тот момент, когда вы позволяете одному из них подменять другое.

Постройте график отложенной выручки, который управляет ежемесячным признанием​

График отложенной выручки — это двигатель всего процесса. Это простая таблица по каждому контракту — клиент, дата начала контракта, срок, общая стоимость контракта, сумма ежемесячного признания, выручка, признанная на текущий момент, остаток отложенной выручки — и это единственный документ, который когда-либо должен запускать проводку по выручке.

Для годового тарифа на $12 000, начинающегося 1 января, проводки выглядят так:

On collection (January):
  Dr  Stripe clearing          $12,000
      Cr  Deferred revenue              $12,000
 
Each month, January–December:
  Dr  Deferred revenue          $1,000
      Cr  Subscription revenue            $1,000

Обратите внимание, чего не хватает: выплата нигде не фигурирует в проводках по выручке. Получение денег кредитует отложенную выручку, обязательство. Выручка рождается позже, по одному месяцу за раз, из графика.

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

Сверьте саму выплату с помощью клирингового счёта​

Пока график управляет сроками признания выручки, вам всё ещё нужно учитывать деньги, проходящие через Stripe. Чистый метод — это клиринговый счёт Stripe, счёт активов, представляющий «деньги, находящиеся внутри Stripe».

Каждое событие Stripe проводится по клиринговому счёту по валовой сумме:

Customer charged $1,000:
  Dr  Stripe clearing            $1,000
      Cr  Deferred revenue                $1,000
 
Stripe fee of $29.30 on that charge:
  Dr  Processing fees              $29.30
      Cr  Stripe clearing                   $29.30
 
Payout of $970.70 lands in your bank:
  Dr  Bank checking               $970.70
      Cr  Stripe clearing                  $970.70

Возвраты и списания по спорным операциям проводятся так же, в обратную сторону. Когда списание выплаты проходит, клиринговый счёт обнуляется по операциям этой выплаты — именно это делает его инструментом сверки, а не просто бухгалтерским соглашением. Ненулевой остаток означает, что комиссия, возврат или корректировка остались неучтёнными.

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

True-ups: изменения в середине цикла, которые ломают графики​

Годовые контракты редко остаются неизменными двенадцать месяцев, и каждое изменение требует корректирующей проводки (true-up) против графика отложенной выручки:

• Апгрейды и расширение числа мест увеличивают остаток отложенной выручки. Клиент, который переходит с $12 000 на $18 000 в год, когда осталось шесть месяцев, добавляет примерно $3 000 новой отложенной выручки (шесть месяцев по дополнительным $500 в месяц) сверх непризнанного остатка.
• Даунгрейды уменьшают его. Понизьте тариф, когда осталось шесть месяцев, — и вы переносите разницу из отложенной выручки, часто как кредит в счёт будущих счетов, а не как денежный возврат, что всё равно требует проводки, даже если деньги не двигаются.
• Пропорциональные расчёты (prorations) — это механизм: Stripe обрабатывает изменения подписки через кредиты за неиспользованное время, и эти кредиты точно указывают, сколько отложенной выручки перевести между старым и новым тарифом.
• Отмены с возвратом за предоплаченное время уменьшают отложенную выручку, но никогда — выручку текущего месяца. Возврат за шесть неиспользованных месяцев годового тарифа на $12 000 — это дебет отложенной выручки на $6 000; отнесение его против выручки этого месяца занизило бы месяц, который ни в чём не провинился.
• Неудачные платежи по годовым продлениям требуют внимания в обратную сторону: нет полученных денег — нет нового остатка отложенной выручки, поэтому график не должен продолжать признавать выручку по контракту, который перестал финансироваться.

Практическое правило: никаких изменений подписки в Stripe без соответствующего обновления графика в том же месяце. Команды, которые позволяют этим двум расходиться, проводят каждый квартальный закрывающий период, реконструируя произошедшее по PDF-файлам счетов.

SaaS-метрика, которая всё это скрывает: MRR на дашборде — это не выручка​

Вот ловушка, которую скрывает вся эта конструкция. Ваш дашборд Stripe показывает MRR, красиво растущий: годовые тарифы конвертируются в месячные эквиваленты, апгрейды мгновенно добавляют expansion MRR, и график устремляется вверх и вправо. Основатели совершенно естественно начинают думать об этом числе как о «том, что мы зарабатываем в месяц».

Это не так. MRR — это нормализованная метрика текущего темпа: месячная стоимость активных подписок, если бы ничего не менялось. Признанная выручка — это то, что вы фактически заработали по методу начисления в этом месяце. Они постоянно расходятся: годовые предоплаты, полученные в этом месяце, едва ли составляют выручку этого месяца, expansion MRR от апгрейда в середине месяца — это лишь половина месяца заработка, и ни одна из цифр дашборда не знает о вашем графике отложенной выручки, ваших возвратах или ваших true-up.

Расхождение невидимо, пока не укусит. Налогооблагаемый доход следует за признанной выручкой, а не за MRR, поэтому квартал с огромными bookings может привести к налоговому счёту, который удивит основателей, следивших за дашбордом. А приобретатели и кредиторы проводят due diligence по выручке по GAAP, а не по MRR — каждый доллар «выручки», который на самом деле был непризнанными billings, корректируется в разговоре об оценке.

Держите оба числа, но никогда не позволяйте одному выполнять работу другого. Полезная ежемесячная проверка на здравость: признанная выручка за месяц плюс изменение остатка отложенной выручки должны сходиться с billings. Если MRR говорит, что вы выросли, а это уравнение говорит обратное, доверяйте уравнению.

Ваш ежемесячный чек-лист закрытия для SaaS на Stripe​

Выполняйте это каждый месяц, и части останутся связанными:

1. Свяжите выплаты с банком. Выгрузите данные о сверке выплат, подтвердите, что валовая сумма минус комиссии минус возвраты равна каждому депозиту, и проведите списание через клиринговый счёт.
2. Обнулите клиринговый счёт по каждой выплате. Любой оставшийся остаток — это неучтённая комиссия, возврат, спорная операция или корректировка — найдите его до конца месяца.
3. Прокатите график отложенной выручки. Добавьте новые контракты и продления, проведите проводки по признанию за месяц и подтвердите, что начальный остаток плюс billings минус признанная выручка равны конечному остатку.
4. Сделайте true-up изменений в середине цикла. Сопоставьте каждый апгрейд, даунгрейд, пропорциональный расчёт, отмену и возврат в Stripe с корректировкой графика.
5. Сверьте MRR с признанной выручкой. Объясните разрыв между текущим темпом на дашборде и заработанной выручкой; разберитесь со всем, что не можете объяснить одним предложением.
6. Рассматривайте комиссии и возвраты отдельно. Валовая выручка, комиссии за обработку и возвраты — каждый рассказывает свою историю; их сальдирование скрывает все три.

При последовательном выполнении это превращает конец месяца из судебно-следственных раскопок в рутину: сторона выплат доказывает, что ваши деньги полны, а сторона графика доказывает, что ваша выручка заработана.

Держите выручку вашего SaaS готовой к инвесторам​

По мере масштабирования годового выставления счетов поддержание связи между признанной выручкой, остатками отложенной выручки и денежными средствами в Stripe каждый месяц — это то, что делает ваши числа достоверными для бухгалтеров, налоговых органов и будущих приобретателей. Beancount.io предлагает учёт в виде простого текста, который даёт вам полную прозрачность и контроль над вашими финансовыми данными — никаких чёрных ящиков, никакой привязки к вендору. Начните бесплатно и узнайте, почему разработчики и финансовые специалисты переходят на учёт в виде простого текста.