Ваш API щойно перетнув $18 000 щомісячного повторюваного доходу на 340 клієнтах, ваш дашборд Stripe показує здорову валову маржу 78%, а ваш бухгалтер просить показати графік визнання доходу. Ви відкриваєте свою бухгалтерію — і там нічого немає: лише поточний рахунок із депозитами, які ніколи не збігаються зі звітами Stripe, та електронна таблиця, яку ви перестали оновлювати в березні.
Саме в цьому розриві ламається бухгалтерія Micro-SaaS. Бізнес виглядає оманливо простим — немає запасів, немає складу, маржа, від якої розплакався б рітейлер, — але гроші рухаються так, що стандартна книга «доходи мінус витрати» цього не відображає. Метричне використання, передоплачені кредитні пакети, комісії процесора, вираховані ще до того, як ви побачили готівку, глобальні податки, зібрані за вас, і відкладений дохід, через який ваш банківський баланс вам бреше. Помиліться в будь-чому з цього — і ви спотворите дохід, переплатите податки або встановите ціну наступного тарифу на основі фантастичної математики.
Цей посібник охоплює бухгалтерію, яка справді підходить для Micro-SaaS або API-бізнесу: як структурувати білінг за використанням, щоб ваші книги залишалися чистими, як звіряти платіжні процесори без втрати розуму наприкінці місяця та чому навіть бізнес із маржею 70%+ потребує справжнього обліку за методом нарахування з першого дня.
Чому книги Micro-SaaS складніші, ніж здаються
Традиційні малі підприємства фіксують продаж, коли гроші змінюють власника або оплачується рахунок-фактура. Micro-SaaS рідко робить або одне, або інше. Розгляньмо типовий місяць для невеликого API або AI-інструменту:
- 120 клієнтів на тарифі Starter за $29/місяць із 500 включеними API-викликами
- 40 клієнтів на тарифі Pro за 0.02 за кожен виклик понад ліміт
- 60 клієнтів, які придбали передоплачені кредитні пакети ($49 за 2 000 кредитів) і витрачають їх нерівномірно
- Кілька корпоративних клієнтів на річній передоплаті, яку ви отримали в січні
Будь-якого дня ви отримуєте готівку, яка ще не є доходом, визнаєте дохід, отриманий тижні тому, заборговуєте комісії процесора, які ніколи не виставляли в рахунках, і надаєте використання, яке ще не було виставлене в рахунку. Книги на касовій основі зводять усе це до «гроші прийшли, гроші пішли» і майже нічого не говорять про те, чи бізнес насправді зростає.
Три речі, які роблять Micro-SaaS особливим
Змінна вартість за одиницю. Кожен API-виклик, AI-генерація чи доставка вебхука чогось вам коштує — плата за токени upstream LLM, обчислення, пропускна здатність або сторонній API, який ви перепродуєте. Фіксовані підписки приховують цю мінливість, поки енергійний користувач не споживе в 50 разів більше середнього та не зітре маржу цілої когорти. Ваші книги мають показувати собівартість проданих товарів (COGS) на одиницю, а не лише загальні витрати на хостинг.
Змінний дохід на клієнта. Два клієнти на однаковому тарифі за $29 можуть генерувати зовсім різний дохід, коли спрацьовують перевищення ліміту та поповнення кредитів. Якщо ви обліковуєте лише плату за підписку, а перевищення вважаєте другорядним, ви занижуєте дохід від найкращих клієнтів і неправильно встановлюєте ціни на свої тарифи.
Передоплачений і відкладений дохід. Кредитні пакети та річні плани дають вам готівку сьогодні за послугу, яку ви надаватимете тижнями чи місяцями. Ця готівка є зобов'язанням — незаробленим доходом — доки клієнт фактично не витратить кредити або не завершиться період послуги. Враховувати її як дохід при отриманні завищує прибуток зараз і занижує його пізніше, що має значення, щойно вам знадобиться кредит, оцінка вартості чи податкова декларація, яка відповідає реальності.
Вибір моделі білінгу, з якою може жити ваш облік
Модель білінгу, яку ви обираєте, є рішенням для бухгалтерії так само, як і рішенням про ціноутворення. Кожна з них створює різні події визнання, звірки та оподаткування.
Фіксована підписка
Усі платять однакову плату незалежно від використання. Бухгалтерія тривіальна: один повторюваний рахунок на клієнта за період, дохід визнається рівномірно протягом періоду. Проблема економічна, а не бухгалтерська — ви субсидуєте активних користувачів і залишаєте гроші на столі з легкими користувачами. Фіксоване ціноутворення працює як фаза навчання, поки ви вимірюєте споживання, але рідко виживає, коли ви розумієте свою собівартість за одиницю.
Чисто за використанням (оплата за виклик, за токен, за годину місця)
Ви вимірюєте споживання та виставляєте рахунок постфактум. Дохід і витрати рухаються разом, що тішить на електронній таблиці та лякає корпоративного покупця, який не може спрогнозувати витрати. З погляду бухгалтерії, чисте використання створює невиставлений дохід наприкінці кожного місяця: послугу надано, але ще не виставлено рахунок. Вам потрібно нарахувати його. Вам також потрібен надійний облік використання, якому довіряє ваш облік, оскільки рахунок настільки точний, наскільки точний лічильник.
Найкраще підходить для API, орієнтованих на розробників, де покупець достатньо технічний, щоб прогнозувати використання. Менше підходить для просьюмерських інструментів, де продає передбачуваність.
Гібрид: базова підписка + включена квота + перевищення ліміту
Це стандарт, який став типовим для більшості Micro-SaaS та AI-інструментів: щомісячна підписка включає квоту (кредити, виклики, генерації); споживання понад квоту виставляється за ставкою за одиницю, часто в 2–4 рази вищою за вашу фактичну собівартість.
Чому це виграє операційно: покупці отримують передбачуваність для типового використання, ви отримуєте більше доходу від активних користувачів, не відлякуючи легких, а валові маржі захищені, оскільки перевищення цінуються значно вище собівартості. Для ваших книг гібридний білінг означає два потоки доходу на клієнта — повторюваний дохід від підписки, який визнається рівномірно, і змінний дохід від перевищення, який визнається, коли перевищення відбувається. Тримайте їх в окремих рахунках обліку. Коли пізніше ви запитаєте «який відсоток MRR насправді змінний?», ви матимете відповідь без копання в рахунках-фактурах.
Практичний нарис тарифів:
- **Starter 0.05 за генерацію понад ліміт
- **Pro 0.04 за генерацію понад ліміт
- **Scale 0.03 за генерацію понад ліміт
Розмір кожної квоти має бути таким, щоб приблизно 80% клієнтів на цьому тарифі ніколи не досягали ліміту. Продукт здається безмежним; ті 20%, які досягають ліміту, фінансують вашу інфраструктуру.
Передоплачені кредитні пакети
Клієнти купують кредити наперед і витрачають їх із часом. Кредити дають вам кращий грошовий таймінг — ви отримуєте оплату до надання послуги — і природний тригер апселу, коли баланси знижуються. Але кожен продаж кредитів створює відкладений дохід із першого дня. Ви дебетуєте готівку, кредитуєте рахунок зобов'язань, як-от Liabilities:UnearnedRevenue:CreditPacks, і лише переміщуєте його на Income:CreditUsage, коли кредити споживаються. Продати 1 000 пакетів по 49 000 як дохід того місяця — це нормально для вашого банківського рахунку та неправильно для вашого звіту про прибутки та збитки.
Поширена структура, яка добре конвертує:
- 500 кредитів за $14 (не діють)
- 2 000 кредитів за $49 (знижка 14%)
- 10 000 кредитів за $199 (знижка 29%, пріоритетна обробка)
- Щомісячне поповнення: 1 500 кредитів за $39/місяць із бонусом 10% порівняно з еквівалентним пакетом
Покупці пакетів, які регулярно поповнюються, є вашими найкращими кандидатами на щомісячне поповнення — зробіть математику за кредит очевидною, і апсел продасть себе сам.
Ціноутворення на основі результату
Стягуйте плату за успішний результат — за вирішений тикет підтримки, за конвертованого ліда, за завершений робочий процес. Це переконливо, коли результат вимірюваний і цінний, але потребує інфраструктури для відстеження та підтвердження, що результат насправді стався. Для бухгалтерії кожен «результат» — це зобов'язання до виконання, яке ви задовольняєте в певний момент часу, і вам потрібні аудиторські сліди для підтримки кожного рахунка.
Звірка з платіжним процесором: куди насправді йдуть гроші
Якщо ви використовуєте Stripe, Paddle, Lemon Squeezy або Merchant of Record, як-от Fungies чи Dodo Payments, готівка, яка надходить на ваш банківський рахунок, ніколи не є числом, яке показує ваш дашборд. Типова виплата Stripe виглядає так:
- Валові продажі: $12 400
- Мінус комісії Stripe (2.9% + 412
- Мінус повернення: -$180
- Мінус диспути та чарджбеки: -$45
- Чиста виплата на ваш банківський рахунок: $11 763
Якщо ви проведете ці 637 і повністю приховаєте свої витрати на обробку, рівень повернень і ризик диспутів від власних фінансів.
Патерн звірки
Звіряйтеся зі звітом процесора, а не з банківським депозитом. Наприкінці місяця:
-
Імпортуйте звіт про розрахунки процесора — валові продажі за продуктом/тарифом, комісії, повернення, диспути, зібрані податки. Кожен поважний процесор надає CSV або API-експорт із цими колонками, розбитими щодня.
-
Проведіть валові суми на правильні рахунки доходу. Базова підписка, перевищення та погашення кредитних пакетів отримують власні рахунки. Це дохід, який ваші клієнти фактично заплатили до того, як хтось узяв свою частку.
Assets:Bank:Checking $11 763 Expenses:ProcessorFees:Stripe $412 Assets:AccountsReceivable:RefundsPending $180 Expenses:Disputes:Chargebacks $45 Income:Subscriptions:Starter Income:Subscriptions:Pro Income:Usage:Overage Income:CreditPacks:RedeemedТочні назви рахунків — на ваш вибір, але принцип фіксований: валові суми входять, комісії та повернення виходять, чиста сума — на банк.
-
Проводьте комісії як витрати, а не як зменшення доходу. Комісії процесора — це вартість отримання доходу, а не зменшення доходу. Віднімання їх приховує вашу реальну ставку утримання та унеможливлює аналіз маржі за когортами.
-
Правильно обробляйте податки, зібрані Merchant of Record. Якщо ви продаєте через Merchant of Record, MoR є юридичним продавцем і відповідає за збір і перерахування ПДВ, GST та податку з продажів США. Рядок «податок» у вашому звіті MoR — це не ваше зобов'язання з перерахування — це їхнє зобов'язання — але вам все одно потрібно його записувати, щоб ваш валовий показник збігався зі звітом, а чистий — із банком. Деякі засновники віднімають його з доходу; чистіше провести його на транзитне зобов'язання, яке обнуляється, коли MoR перераховує кошти.
-
Відстежуйте повернення та чарджбеки окремо. Повернення — це скасування доходу; чарджбек додає комісію за диспут. Якщо ви їх об'єднуєте, ви не можете відповісти на питання «чи зростає наш рівень повернень?» і не можете вчасно помітити патерн шахрайства.
Поширені помилки звірки
Проведення виплат як доходу. Найпоширеніша помилка серед соло-засновників. Це занижує дохід, завищує маржу (бо комісії зникають) і створює розбіжність між вашою формою 1099-K і вашими книгами наприкінці року.
Ігнорування незавершених виплат. Баланси процесора, які були стягнуті, але ще не виплачені, є дебіторською заборгованістю. Якщо ви закриваєте книги 31 січня, а Stripe ще не виплатив кошти за 29–31 січня, цей дохід належить січню, а не лютому.
Забування про комісії за застосунки на підключених рахунках. Якщо ви керуєте маркетплейсом або берете комісію за застосунок поверх керованого платежу, комісія за застосунок — це ваш дохід, а основний платіж — ні. Проводьте лише те, що належить вам.
Незвірка продажів кредитних пакетів із відкладеним доходом. Кожен продаж кредитного пакета має мати відповідний запис зобов'язання, який згортається в міру витрачання кредитів. Якщо ваш відкладений баланс зростає щомісяця, а визнаний дохід — ні, ви продаєте пакети швидше, ніж клієнти їх споживають — корисний сигнал для грошового потоку, невидимий, якщо ви проводили пакети як дохід при продажу.
Чому валові маржі 70%+ все одно вимагають реальних книг
Спокусливо думати, що високомаржинальному програмному бізнесу не потрібна складна бухгалтерія. Хостинг дешевий, запасів немає, і прибуток, здається, сам себе забезпечує. Три реальності швидко це виправляють.
Що насправді входить у COGS
Для Micro-SaaS або API-бізнесу COGS — це не «хостинг». Це кожна вартість, яка масштабується безпосередньо з використанням і якої не було б, якби ви обслуговували нуль клієнтів:
- Витрати на upstream API та токени LLM (OpenAI, Anthropic або ваш власний GPU-інференс)
- Метрична інфраструктура (обчислення за запит, вихідна пропускна здатність, секунди генерації зображень)
- Сторонні API для даних або збагачення, які ви перепродуєте
- Витрати на ліцензії за місце для вбудованих компонентів
Хостинг, який не масштабується з використанням — ваш статичний фронтенд, адмін-дашборди, фіксовані бази даних — це операційні витрати, а не COGS. Правильний розподіл цього дозволяє розрахувати справжню валову маржу за тарифом і за клієнтом. Тариф Starter за 1.50 за LLM та обчислення за середнього використання; той самий тариф з активним користувачем на 2 000 генерацій може коштувати $12. Якщо обидва показують однаковий «валовий прибуток» у ваших книгах, ви не можете правильно встановити ціни.
Ціліться на ціну перевищення в 3–5 разів більшу за вашу собівартість за одиницю. Якщо генерація коштує вам 0.01–$0.015. Це підтримує валову маржу 70–80% на перевищенні та захищає вас, коли вартість моделей зростає або клієнт відкриває автоматизацію.
Відкладений дохід робить ваш банківський баланс брехнею
Micro-SaaS, який продає річні передоплати та кредитні пакети, може виглядати багатим на готівку та бідним на прибуток — або навпаки — залежно від того, коли ви отримуєте платежі. Приклад: ви продаєте 40 річних планів Pro по 39 600. На касовій основі січень — ваш найкращий місяць за всю історію. На основі нарахування ви заробили 36 300 за майбутні послуги. Якщо ви витратите січневу готівку, ніби це січневий прибуток, до грудня у вас буде дефіцит.
Облік за методом нарахування виправляє це, визнаючи дохід, коли ви виконуєте зобов'язання, а не коли отримуєте оплату. Проведіть річний продаж так:
- Дебет готівки, кредит відкладеного доходу (зобов'язання)
- Щомісяця дебетуйте відкладений дохід, кредитуйте дохід від підписки на одну дванадцяту
Та сама логіка застосовується до кредитних пакетів: дохід, коли витрачено, а не коли продано. Це більше роботи, і це різниця між знанням, чи ви зростаєте, і просто спостереженням, як гроші хлюпаються.
Економіка одиниці визначає ваше наступне рішення
Інвестори, кредитори та навіть ви о 23:00, вирішуючи, чи підвищити ціни, ставлять однакові питання:
- Яке утримання чистого доходу — чи витрачають наявні клієнти більше з часом?
- Яка валова маржа за тарифом, і який рівень субсидує який?
- Яка окупність вартості залучення клієнта з урахуванням справжнього COGS і комісій процесора?
- Який відкладений дохід і чи покриває він наступні два місяці зобов'язань?
Жодне з цих питань не можна відповісти з балансу поточного рахунку. Вони вимагають обліку, який розділяє підписку від перевищення, валові суми від чистих, зароблене від відкладеного, а COGS від OPEX. Текстова бухгалтерія тут сяє, тому що ці категорії є явними рахунками у файлі, який ви контролюєте, відстежується в git, піддається аудиту в будь-який момент — а не поховані в дашборді, який змінює свої визначення без попередження.
Мінімальний план рахунків, який працює
Вам не потрібен план рахунків на 200 рядків. Вам потрібно достатньо структури, щоб відповісти на питання вище:
Income:Subscriptions:Starter/Pro/ScaleIncome:Usage:OverageIncome:CreditPacks:Redeemed(продажі пакетів спочатку йдуть наLiabilities:UnearnedRevenue:CreditPacks)Expenses:COGS:Inference(витрати на LLM / моделі)Expenses:COGS:MeteredInfra(обчислення за запит, пропускна здатність)Expenses:COGS:DataAPIs(перепродані сторонні API)Expenses:ProcessorFees:Stripe(або Paddle / MoR)Liabilities:UnearnedRevenue:AnnualPlansтаLiabilities:UnearnedRevenue:CreditPacksAssets:AccountsReceivable:ProcessorPending(зароблено, але ще не виплачено)
Почніть із цього. Додавайте рахунки, коли у вас є питання, на яке поточна структура не може відповісти, а не раніше.
Закриття місяця для соло-SaaS
Вам не потрібна фінансова команда, щоб правильно закривати книги. Вам потрібен повторюваний чеклист, який займає годину раз на місяць:
-
Завантажте звіт про розрахунки процесора за повний місяць і проведіть валові суми за продуктом, з окремими комісіями, поверненнями та податком.
-
Звірте банківські депозити — кожна виплата в банку має збігатися з партією розрахунків у вашому обліку. Позначте будь-яку незавершену партію, яка була стягнута, але ще не виплачена.
-
Оновіть графіки відкладеного доходу. Для кожного річного плану та кредитного пакета перемістіть зароблену частину зі зобов'язань у дохід. Якщо кредитні пакети не мають терміну дії, розгляньте політику залишків для прострочених кредитів (непогашені пакети старші 12–18 місяців) і задокументуйте її — це місце, де живе бухгалтерське судження, тому запишіть його.
-
Нарахуйте невиставлене використання. Якщо ви виставляєте рахунки за перевищення постфактум, оцініть або виміряйте невиставлену суму на кінець місяця та проведіть її як нарахований дохід.
-
Звірте COGS. Зіставляйте рахунки upstream API (OpenAI, хмарний провайдер) із періодом використання, який вони покривають, а не з датою оплати. Рахунок за інференс на $2 400, оплачений 5-го числа за токени минулого місяця, належить минулому місяцю.
-
Перегляньте невдалі платежі та відтік. Невдалі списання, які будуть повторені, ще не є втраченим доходом; помістіть їх у сегмент нагадування про оплату. Після закриття вікна повторних спроб спишіть їх і точно зафіксуйте відтік.
-
Звірте відкладені та нараховані залишки. Ваше відкладене зобов'язання має бути зіставним із графіком — кожен долар, прив'язаний до конкретного клієнта та періоду послуги. Якщо загальна сума відхилилася від графіка, щось було проведено двічі або взагалі не проведено.
Податки та відповідність без фінансової команди
Якщо ви продаєте лише клієнтам у США та залишаєтеся нижче порогів економічного зв'язку штатів, пряма інтеграція Stripe керована. Щойно ви починаєте продавати глобально, податкова відповідність множиться: ПДВ в ЄС за ставкою клієнта, GST в Австралії, HST у Канаді, різне регулювання SaaS у штатах США та пороги дистанційних продажів, які запускають обов'язки з реєстрації, про які ви не знали.
Merchant of Record поглинає цю складність. Вони збирають і перераховують податки в кожній юрисдикції, видають відповідні рахунки-фактури, обробляють чарджбеки та стають продавцем рекорду, тож ви ніколи не подаєте іноземну декларацію з ПДВ. Компроміс — вища комісія за транзакцію (зазвичай 4–5% плюс фіксована сума) порівняно з 2.9% + $0.30 у Stripe плюс окремий додаток для розрахунку податків. Для невеликої команди, яка продає глобально з першого дня, комісія MoR майже завжди дешевша за інженерний і бухгалтерський час, необхідний для самостійного виконання — і набагато дешевша за помилку.
Якщо ви залишаєтеся на прямому Stripe, як мінімум: зареєструйтеся в європейській системі One-Stop Shop (OSS) для ПДВ, коли маєте будь-яких клієнтів в ЄС, увімкніть Stripe Tax для розрахунку, подавайте квартальні декларації OSS, відстежуйте економічний зв'язок у штатах США (багато штатів використовують поріг продажів у $100 000) і ведіть відповідні записи для кожної юрисдикції, у яку продаєте. Розрахунок без перерахування допомагає цитувати правильну ціну, але не виконує зобов'язання.
Також плануйте податок на прибуток: виплати процесора є валовими до комісій, тому ваша форма 1099-K відображатиме вище число. Якщо ви проводили лише чисті депозити, ваша декларація не збігатиметься з формою, і ви витратите зайві години на пояснення різниці. Проводьте валові суми — і збіг буде арифметикою.
Що вам дають чисті книги
Чисті книги для Micro-SaaS не лише тримають вас у відповідності. Вони дають вам відповіді, необхідні для управління бізнесом: який тариф має найкращу маржу після справжнього COGS, чи кредитні пакети чи підписки забезпечують кращу окупність, коли підвищувати включену квоту проти ціни перевищення та чи той «прибутковий» місяць насправді був просто річними передоплатами, що маскуються під зростання.
Налаштуйте розділення — підписка проти перевищення проти погашення кредитів, COGS проти OPEX, зароблене проти відкладеного, валові суми проти чистих від комісій — у свій перший місяць, а не дванадцятий. Ретрофітинг року знешкоджених виплат і неправильно класифікованого хостингу — це та робота, через яку засновники шкодують, що не почали з реального обліку.
Спростіть ваше фінансове управління
Коли ваш Micro-SaaS переходить від примітивного метричного білінгу до повного гібридного механізму ціноутворення, підтримка чітких фінансових записів — це те, що робить рішення про ціни чесними, а податковий сезон спокійним. Beancount.io надає текстову бухгалтерію, яка дає вам повну прозорість і контроль над вашими фінансовими даними — кожен тариф підписки, зобов'язання за кредитні пакети, комісія процесора та рядок COGS, відстежувані у версіях в обліку, яким ви володієте. Почніть безкоштовно і побачте, чому розробники та фінансові професіонали переходять на текстову бухгалтерію.