Ваш API только что превысил $18 000 ежемесячной повторяющейся выручки на 340 клиентах, ваша панель Stripe показывает здоровую валовую маржу в 78%, и ваш бухгалтер просит показать график признания выручки. Вы открываете свою бухгалтерию — и там нечего показать: только расчетный счет с поступлениями, которые никогда не сходятся с отчетами Stripe, и электронная таблица, которую вы перестали обновлять в марте.
Именно в этом разрыве ломается бухгалтерия микро-SaaS. Бизнес выглядит обманчиво простым — нет запасов, нет склада, маржа, от которой розничный продавец заплакал бы, — но деньги движутся так, что стандартная книга «доходы минус расходы» это не улавливает. Измеряемое использование, предоплаченные кредитные пакеты, комиссии процессора, вычитаемые до того, как вы увидите деньги, глобальные налоги, собираемые за вас, и отложенная выручка, из-за которой ваш банковский баланс вам лжет. Ошибитесь в любом из этих пунктов — и вы исказите выручку, переплатите налоги или установите цену на следующий тариф на основе фантазийной математики.
Это руководство охватывает бухгалтерию, которая действительно подходит для микро-SaaS или API-бизнеса: как структурировать биллинг на основе использования, чтобы ваши книги оставались чистыми, как сверять платежные процессоры, не сходя с ума в конце месяца, и почему даже бизнес с маржой выше 70% нуждается в реальном учете по методу начисления с первого дня.
Почему книги микро-SaaS сложнее, чем кажутся
Традиционные малые предприятия фиксируют продажу, когда деньги переходят из рук в руки или оплачивается счет. Микро-SaaS редко делает и то, и другое. Рассмотрим типичный месяц для небольшого API или AI-инструмента:
- 120 клиентов на плане Starter за $29/месяц с 500 включенными API-вызовами
- 40 клиентов на плане Pro за 0,02 за вызов сверх лимита
- 60 клиентов, купивших предоплаченные кредитные пакеты ($49 за 2 000 кредитов) и расходующих их неравномерно
- Несколько корпоративных клиентов на годовой предоплате, которую вы получили в январе
В любой день вы получаете деньги, которые еще не являются выручкой, признаете выручку, полученную недели назад, должны комиссии процессору, которые вы никогда не выставляли, и предоставляете использование, которое еще не выставлено в счет. Книги на кассовой основе сводят всё это к «деньги пришли, деньги ушли» и почти ничего не говорят о том, растет ли бизнес на самом деле.
Три вещи, которые отличают микро-SaaS
Переменная стоимость за единицу. Каждый API-вызов, генерация ИИ или доставка вебхука вам что-то стоит — комиссия за токены вышестоящей LLM, вычисления, пропускная способность или сторонний API, который вы перепродаете. Плоские подписки скрывают эту изменчивость, пока активный пользователь не потребляет в 50 раз больше среднего и не стирает маржу целой когорты. Ваши книги должны показывать себестоимость проданных услуг (COGS) за единицу, а не просто общие расходы на хостинг.
Переменная выручка на клиента. Два клиента на одном плане за $29 могут приносить совершенно разную выручку, когда в игру вступают перерасходы и пополнения кредитов. Если вы учитываете только абонентскую плату и рассматриваете перерасходы как случайные, вы занижаете выручку от ваших лучших клиентов и неправильно устанавливаете цены на тарифы.
Предоплаченная и отложенная выручка. Кредитные пакеты и годовые планы дают вам деньги сегодня за услуги, которые вы будете предоставлять неделями или месяцами. Эти деньги — обязательство, незаработанная выручка, — пока клиент фактически не израсходует кредиты или не истечет период обслуживания. Записывать их как доход при получении завышает прибыль сейчас и занижает ее позже, что важно в тот момент, когда вам нужен кредит, оценка или налоговая декларация, соответствующая реальности.
Выбор модели биллинга, с которой может жить ваша книга
Модель биллинга, которую вы выбираете, — это решение по бухгалтерии не меньше, чем по ценообразованию. Каждая создает разные события признания, сверки и налогообложения.
Плоская подписка
Все платят одинаковую плату независимо от использования. Бухгалтерия тривиальна: один повторяющийся счет на клиента за период, выручка признается равномерно в течение периода. Проблема экономическая, а не учетная — вы субсидируете активных пользователей и оставляете деньги на столе с легкими. Плоское ценообразование работает как этап обучения, пока вы измеряете потребление, но редко выживает, когда вы понимаете свою стоимость за единицу.
Чистое использование (оплата за вызов, за токен, за место-час)
Вы измеряете потребление и выставляете счет после факта. Выручка и затраты движутся вместе, что приятно на электронной таблице и пугает корпоративного покупателя, который не может прогнозировать расходы. С точки зрения бухгалтерии, чистое использование создает невыставленную выручку на конец каждого месяца: услуги предоставлены, но счета еще нет. Вам нужно начислять ее. Вам также нужен надежный учет использования, которому ваша книга может доверять, потому что счет точен настолько, насколько точен счетчик.
Лучше всего подходит для API, ориентированных на разработчиков, где покупатель достаточно технически подкован, чтобы прогнозировать использование. Менее подходит для инструментов для «prosumer», где предсказуемость продает.
Гибрид: базовая подписка + включенная квота + перерасход
Это стандарт, который возник для большинства микро-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
Для микро-SaaS или API-бизнеса COGS — это не «хостинг». Это все затраты, которые масштабируются напрямую с использованием и которых не было бы, если бы вы обслуживали ноль клиентов:
- Затраты на вышестоящие API и токены LLM (OpenAI, Anthropic или ваш собственный вывод на GPU)
- Измеряемая инфраструктура (вычисления за запрос, исходящая пропускная способность, секунды генерации изображений)
- Сторонние API данных или обогащения, которые вы перепродаете
- Затраты на лицензии за место для встроенных компонентов
Хостинг, который не масштабируется с использованием — ваш статический фронтенд, админ-панели, фиксированные базы данных — это операционный расход, а не COGS. Правильное разделение позволяет рассчитать истинную валовую маржу по плану и по клиенту. План Starter за 1,50 на LLM и вычисления при среднем использовании; тот же план с активным пользователем на 2 000 генераций может стоить $12. Если оба показывают одинаковую «валовую прибыль» в ваших книгах, вы не можете правильно установить цены.
Нацеливайте цены на перерасход в 3–5 раз выше вашего COGS за единицу. Если генерация стоит вам 0,01–$0,015. Это поддерживает валовую маржу на перерасходе в 70–80% и защищает вас, когда затраты на модели растут или клиент обнаруживает автоматизацию.
Отложенная выручка заставляет ваш банковский баланс лгать
Микро-SaaS, который продает годовые предоплаты и кредитные пакеты, может выглядеть богатым деньгами и бедным прибылью — или наоборот — в зависимости от того, когда вы получаете деньги. Пример: вы продаете 40 годовых планов Pro по 39 600. На кассовой основе январь — ваш лучший месяц за всю историю. На основе начислений вы заработали 36 300 за будущие услуги. Если вы потратите январские деньги так, как будто это январская прибыль, к декабрю у вас будет нехватка.
Учет по методу начисления исправляет это, признавая выручку, когда вы выполняете обязательство, а не когда получаете деньги. Запишите годовую продажу как:
- Дебет денег, кредит отложенной выручки (обязательство)
- Каждый месяц дебет отложенной выручки, кредит дохода от подписки на одну двенадцатую
Та же логика применима к кредитным пакетам: выручка при расходовании, а не при продаже. Это больше работы, и это разница между знанием, растете ли вы, и простым наблюдением за тем, как плещутся деньги.
Юнит-экономика определяет ваше следующее решение
Инвесторы, кредиторы и даже вы в 11 вечера, решая, поднимать ли цены, задают одни и те же вопросы:
- Какова чистая удержание выручки — тратят ли существующие клиенты больше со временем?
- Какова валовая маржа по планам, и какой тариф субсидирует какой?
- Какова окупаемость затрат на привлечение клиента с учетом реального 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 в одного человека
Вам не нужна финансовая команда, чтобы правильно закрывать книги. Вам нужен повторяемый чек-лист, который занимает час раз в месяц:
-
Скачайте отчет о расчетах процессора за полный месяц и запишите валовую выручку по продуктам, с комиссиями, возвратами и налогами отдельно.
-
Сверьте банковские депозиты — каждая выплата в банке должна соответствовать партии расчетов в вашей книге. Отметьте любую ожидающую партию, по которой были списания, но еще не было выплат.
-
Обновите графики отложенной выручки. Для каждого годового плана и кредитного пакета переместите заработанную часть из обязательств в доход. Если кредитные пакеты не имеют срока действия, рассмотрите политику «breakage» для устаревших кредитов (непогашенные пакеты старше 12–18 месяцев) и задокументируйте ее — здесь находится бухгалтерское суждение, поэтому запишите его.
-
Начислите невыставленное использование. Если вы выставляете счета за перерасходы задним числом, оцените или измерьте невыставленную сумму на конец месяца и запишите ее как начисленную выручку.
-
Сверьте COGS. Сопоставьте счета вышестоящих API (OpenAI, облачный провайдер) с периодом использования, который они покрывают, а не с датой оплаты. Счет за вывод на $2 400, оплаченный 5-го числа за токены прошлого месяца, принадлежит прошлому месяцу.
-
Просмотрите неудачные платежи и отток. Неудачные списания, которые будут повторены, — это еще не потерянная выручка; поместите их в вспомогательную корзину. После закрытия окна повторных попыток спишите их и точно запишите отток.
-
Сверьте отложенные и начисленные остатки. Ваше отложенное обязательство должно соответствовать графику — каждый доллар привязан к конкретному клиенту и периоду обслуживания. Если сумма отклонилась от графика, что-то было записано дважды или не записано вовсе.
Налоги и соблюдение требований без финансовой команды
Если вы продаете только клиентам в США и остаетесь ниже порогов экономического привлечения (economic nexus) по штатам, прямая интеграция Stripe управляема. Как только вы продаете глобально, налоговое соответствие умножается: НДС в ЕС по ставке клиента, GST в Австралии, HST в Канаде, различное обращение с SaaS в штатах США и пороги дистанционной продажи, которые запускают обязательства по регистрации, о которых вы не знали.
Merchant of Record поглощает эту сложность. Они собирают и перечисляют налоги в каждой юрисдикции, выставляют соответствующие счета, обрабатывают чарджбэки и становятся продавцом записи, так что вы никогда не подаете иностранную декларацию по НДС. Компромисс — более высокая комиссия за транзакцию (обычно 4–5% плюс фиксированная сумма) против 2,9% + $0,30 у Stripe плюс отдельная надбавка за расчет налогов. Для небольшой команды, выходящей на глобальный рынок с первого дня, комиссия MoR почти всегда дешевле, чем инженерное и бухгалтерское время на самостоятельное решение — и гораздо дешевле, чем ошибка.
Если вы остаетесь на Stripe напрямую, как минимум: зарегистрируйтесь в системе OSS (One-Stop Shop) для НДС в ЕС, когда у вас есть любые клиенты в ЕС, включите Stripe Tax для расчета, подавайте квартальные отчеты OSS, отслеживайте экономический nexus в США по штатам (во многих штатах порог продаж составляет $100 000) и ведите соответствующие записи для каждой юрисдикции, в которую продаете. Расчет без перечисления помогает вам указать правильную цену, но не выполняет обязательство.
Также планируйте налог на прибыль: выплаты процессора — это валовая выручка до комиссий, поэтому ваша 1099-K будет отражать более высокое число. Если вы записали только чистые депозиты, ваша декларация не сойдется с формой, и вы потратите лишние часы, объясняя разницу. Записывайте валовую выручку, и сверка станет арифметикой.
Что дают вам чистые книги
Чистые книги для микро-SaaS не просто держат вас в соответствии с требованиями. Они дают ответы, необходимые для управления бизнесом: у какого плана лучшая маржа после реального COGS, кредитные пакеты или подписки дают лучшую окупаемость, когда поднимать включенную квоту против цены перерасхода, и был ли тот «прибыльный» месяц на самом деле просто годовыми предоплатами, маскирующимися под рост.
Настройте разделение — подписка против перерасхода против погашения кредитов, COGS против OPEX, заработанное против отложенного, валовая выручка против чистой после комиссий — в первый месяц, а не в двенадцатый. Ретрофит года сведенных выплат и неправильно классифицированного хостинга — это работа, из-за которой основатели жалеют, что не начали с настоящей книги.
Упростите свое финансовое управление
Когда ваш микро-SaaS переходит от скромного измеряемого биллинга к полному гибридному механизму ценообразования, поддержание четких финансовых записей — это то, что делает решения о ценах честными, а налоговый сезон спокойным. Beancount.io предоставляет текстовую бухгалтерию, которая дает вам полную прозрачность и контроль над вашими финансовыми данными — каждый тариф подписки, обязательство по кредитным пакетам, комиссия процессора и строка COGS с версиями в книге, которой вы владеете. Начните бесплатно и узнайте, почему разработчики и финансовые специалисты переходят на текстовую бухгалтерию.