У березні ви закрили п'ять річних угод, і $60 000 надійшло на ваш рахунок у Stripe. Ваш дашборд сяє, баланс у банку виглядає героїчно — а бухгалтер щойно сказав вам, що дохід за березень становив $5 000. Ніхто не помиляється. Ви дивитеся на два різні числа, які просто живуть на одному рахунку Stripe: гроші, які ви зібрали, і дохід, який ви насправді заробили. Поки ви не звірите ці два показники, кожна виплата, яку надсилає Stripe, буде загадкою, яку має розв'язати ваша бухгалтерія.
Цей посібник показує, як SaaS-компанії, які виставляють рахунки щорічно, але визнають дохід щомісяця, звіряють виплати Stripe без подвійного обліку доходу, без викривлення відкладеного доходу і без обману з боку метрики, яка приховує весь розрив.
Чому виплати Stripe — неправильна відправна точка для доходу
Виплата Stripe виглядає як дохід. Вона надходить на ваш банківський рахунок одним депозитом, має дату і здається заробітком за місяць. Це не так. Виплата — це чисте розрахункове сальдо: валові нарахування мінус комісії за обробку, мінус повернення, мінус списання за спори, зібрані разом за графіком виплат Stripe, а не за вашим.
Це створює два окремі викривлення, якщо ви обліковуєте виплати як дохід.
По-перше, ви занижуєте дохід. Якщо клієнт заплатив $12 000 за річний план, Stripe залишає собі приблизно $348 плюс 30 центів і виплачує решту. Облік виплати фіксує чисту суму як ваші продажі та ховає комісію там, де ви ніколи не зможете її проаналізувати — або чисто вирахувати.
По-друге, і набагато небезпечніше для щорічного виставлення рахунків, ви викривлюєте розподіл у часі. Уся сума $12 000 надходить однією виплатою в січні, але за методу нарахування ви заробляєте її по $1 000 на місяць, надаючи послугу. Облікуйте виплату як січневий дохід — і січень виглядатиме вражаюче, тоді як з лютого по грудень виглядатимуть мертвими, хоча бізнес робив точно те саме щомісяця.
Рішення — ставитися до виплати як до того, чим вона є — грошовим переказом — і визнавати дохід на цілком окремому шляху, керованому вашими контрактами, а не депозитами.
Три числа, які плутають засновники: замовлення, рахунки та дохід
Кожна звірка щорічного виставлення рахунків починається з розділення трьох чисел:
- Замовлення (bookings) — це загальна вартість підписаних контрактів. Клієнт підписує річний контракт на $12 000 у січні: $12 000 у січневих замовленнях. Замовлення — це зобов'язання, а не гроші і не заробіток.
- Рахунки (billings) — це те, що ви виставляєте та збираєте. Якщо контракт передбачає щорічну передоплату, січневі рахунки становлять $12 000. Якщо виставлення щомісячне, січневі рахунки становлять $1 000, хоча замовлення було $12 000.
- Дохід (revenue) — це те, що ви заробили, надаючи послугу. Один місяць дванадцятимісячного контракту заробляє одну дванадцяту: $1 000 січневого доходу в будь-якому випадку.
Розрив між рахунками та доходом — це відкладений дохід (також званий незаробленим доходом), зобов'язання на вашому балансі, що представляє послугу, яку ви ще винні. Зберіть $12 000 у січні та визнайте $1 000 — і ви переносите $11 000 відкладеного доходу в лютий. Це зобов'язання не є проблемою — це доказ того, що ваша бухгалтерія чесна. Воно розкручується на $1 000 щомісяця, поки контракт не закінчиться.
Простіше кажучи: замовлення показують, як справи у продажах, рахунки показують, як справи з грошима, а дохід показує, як насправді працював бізнес. Звірка ламається в той момент, коли ви дозволяєте одному з них замінити інший.
Побудуйте графік відкладеного доходу, який керує щомісячним визнанням
Графік відкладеного доходу — це двигун усього процесу. Це проста таблиця по кожному контракту — клієнт, дата початку контракту, тривалість, загальна вартість контракту, сума щомісячного визнання, визнаний на сьогодні дохід, залишок відкладеного доходу — і це єдиний документ, який повинен коли-небудь запускати проведення з визнання доходу.
Для річного плану на $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Зверніть увагу, чого тут немає: виплата ніде не з'являється в проведеннях з доходу. Збір грошей кредитує відкладений дохід, зобов'язання. Дохід народжується пізніше, місяць за місяцем, з графіка.
Два дисциплінарні моменти визначають успіх або провал графіка. По-перше, кожен новий річний контракт, поновлення та розширення мають потрапити до нього того місяця, коли починаються — контракт, відсутній у графіку, це дохід, який ніколи не буде визнаний. По-друге, звіряйте графік з головною книгою щомісяця: початковий залишок відкладеного доходу плюс нові рахунки мінус визнаний дохід має дорівнювати кінцевому залишку відкладеного доходу. Якщо ні, щось оминуло графік — зазвичай повернення, зміна посеред циклу або виплата, яку хтось облікував прямо як дохід.
Звірте саму виплату за допомогою клірингового рахунку
Поки графік керує розподілом доходу в часі, вам усе ще потрібно обліковувати гроші, що проходять через 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». Якщо ваш обсяг невеликий, тижневий ритм із кліринговим рахунком виявляє дрібні розбіжності, поки їх ще легко простежити.
Коригування: зміни посеред циклу, що ламають графіки
Річні контракти рідко залишаються незмінними дванадцять місяців, і кожна зміна потребує проведення коригування проти графіка відкладеного доходу:
- Апгрейди та розширення кількості місць додаються до залишку відкладеного доходу. Клієнт, який переходить з $12 000 на $18 000 на рік із шістьма місяцями, що залишилися, додає приблизно $3 000 нового відкладеного доходу (шість місяців за додаткові $500 на місяць), поверх невизнаного залишку.
- Даунгрейди зменшують його. Зменште план із шістьма місяцями, що залишилися, і ви переносите різницю з відкладеного доходу — часто як кредит на майбутні рахунки, а не грошове повернення, що все одно потребує проведення, навіть якщо гроші не рухаються.
- Пропорційні розрахунки — це механізм: Stripe обробляє зміни підписки за допомогою кредитів за невикористаний час, і ці кредити точно вказують, скільки відкладеного доходу перемістити між старим і новим планом.
- Скасування з поверненням передоплаченого часу зменшують відкладений дохід, а не дохід поточного місяця. Повернення шести невикористаних місяців плану на $12 000 — це дебет $6 000 на відкладений дохід — облік цього проти доходу цього місяця занизив би місяць, який ні в чому не завинив.
- Невдалі платежі за річними поновленнями потребують нагляду в іншому напрямку: немає зібраних грошей — немає нового залишку відкладеного доходу, тож графік не повинен продовжувати визнавати дохід за контрактом, який перестав фінансуватися.
Практичне правило: жодна зміна підписки в Stripe без відповідного оновлення графіка того ж місяця. Команди, які дозволяють цим двом розійтися, витрачають кожен кінець кварталу на реконструкцію того, що сталося, за PDF-рахунками.
SaaS-метрика, яка все це приховує: MRR на дашборді — це не дохід
Ось пастка, яку приховує вся ця конструкція. Ваш дашборд Stripe показує, як MRR гарно зростає — річні плани конвертуються в місячні еквіваленти, апгрейди миттєво додають MRR розширення, і графік нахиляється вгору й праворуч. Засновники цілком природно починають думати про це число як про «те, що ми заробляємо на місяць».
Це не так. MRR — це нормалізована метрика поточного темпу: місячна вартість активних підписок, якби нічого не змінювалося. Визнаний дохід — це те, що ви насправді заробили за методу нарахування цього місяця. Вони постійно розходяться — річні передоплати, зібрані цього місяця, ледве становлять дохід цього місяця, MRR розширення від апгрейду посеред місяця — це лише півмісяця заробітку, і жодна з цифр дашборда не знає про ваш графік відкладеного доходу, ваші повернення чи ваші коригування.
Розбіжність невидима, поки не вкусить. Оподатковуваний дохід слідує за визнаним доходом, а не за MRR, тож великий квартал замовлень може спричинити податковий рахунок, який здивує засновників, котрі стежили за дашбордом. А покупці та кредитори перевіряють дохід за GAAP, а не MRR — кожен долар «доходу», який насправді був невизнаними рахунками, виключається з розмови про оцінку.
Тримайте обидва числа, але ніколи не дозволяйте одному виконувати роботу іншого. Корисна щомісячна перевірка на здоров глузд: визнаний дохід за місяць плюс зміна вашого залишку відкладеного доходу мають звірятися назад до рахунків. Якщо MRR каже, що ви зросли, а це рівняння каже інше — довіряйте рівнянню.
Ваш щомісячний контрольний список закриття для Stripe SaaS
Виконуйте це щомісяця, і всі частини залишаться пов'язаними:
- Прив'яжіть виплати до банку. Експортуйте дані звірки виплат, переконайтеся, що валова сума мінус комісії мінус повернення дорівнює кожному депозиту, і проведіть списання через кліринговий рахунок.
- Обнуліть кліринговий рахунок за кожною виплатою. Будь-який залишковий баланс — це необлікована комісія, повернення, спір або коригування — знайдіть його до кінця місяця.
- Прокрутіть графік відкладеного доходу. Додайте нові контракти та поновлення, проведіть визнання за місяць і переконайтеся, що початковий залишок плюс рахунки мінус визнаний дохід дорівнює кінцевому залишку.
- Скоригуйте зміни посеред циклу. Зіставте кожен апгрейд, даунгрейд, пропорційний розрахунок, скасування та повернення в Stripe з коригуванням графіка.
- Звірте MRR з визнаним доходом. Поясніть розрив між поточним темпом на дашборді та заробленим доходом; дослідіть усе, що не можете пояснити одним реченням.
- Перегляньте комісії та повернення окремо. Валовий дохід, комісії за обробку та повернення кожен розповідають свою історію — їхнє згортання приховує всі три.
За послідовного виконання це перетворює кінець місяця з криміналістичних розкопок на рутину: бік виплат доводить, що ваші гроші повні, а бік графіка доводить, що ваш дохід зароблений.
Тримайте дохід вашого SaaS готовим для інвесторів
У міру масштабування щорічного виставлення рахунків підтримання зв'язку між визнаним доходом, залишками відкладеного доходу та грошима Stripe щомісяця — це те, що робить ваші цифри переконливими для бухгалтерів, податкових органів і майбутніх покупців. Beancount.io надає бухгалтерію у форматі простого тексту, яка дає вам повну прозорість і контроль над вашими фінансовими даними — жодних чорних скриньок, жодної залежності від постачальника. Почніть безкоштовно і дізнайтеся, чому розробники та фінансові фахівці переходять на бухгалтерію у форматі простого тексту.
