Ваш счёт за вебхуки — это себестоимость, а не накладные расходы: учёт событийного SaaS на Svix и Hookdeck

Ваша выручка за прошлый квартал выросла на 20%, а счёт за доставку вебхуков утроился — и вы узнали об этом из выписки по карте, а не из учётных регистров. Если вы развиваете событийный SaaS-продукт на Svix или Hookdeck, такой сюрприз — практически обряд посвящения: один разговорчивый корпоративный клиент, один шторм повторных попыток или одна функция веерной рассылки способны многократно увеличить объём событий, пока подписочная выручка почти не меняется. Проявится ли это красным флагом в вашей валовой марже или спрячется внутри обобщённой статьи «Подписки на ПО» — зависит исключительно от того, как вы отражаете эти расходы в учёте.

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

Сколько на самом деле стоит инфраструктура вебхуков в 2026 году​

Оба ведущих вендора сочетают платформенный сбор с измеряемым потреблением, и именно поэтому счёт оказывается сюрпризом: базовая плата предсказуема, а счётчик — нет.

Svix предлагает три тарифных плана. Бесплатный план ($0, 200 сообщений в секунду, 30-дневное хранение содержимого) подходит для pet-проектов и прототипов. Professional начинается от $490 в месяц: 800 сообщений в секунду, 90-дневное хранение и SLA доступности 99.99%. Enterprise — с индивидуальной ценой, SLA 99.999%, SSO и опциями on-prem. Важно, что Svix засчитывает в потребление только сообщения с попыткой доставки или трансформированные сообщения — повторные попытки и сообщения, отфильтрованные из-за отсутствия подписчиков у эндпоинта, бесплатны.

Hookdeck устроен похоже, но с более гранулярным учётом. Developer — $0 за объём до 10,000 событий в месяц с 3-дневным хранением. Team начинается от $39 в месяц с оплатой по факту использования и 7-дневным хранением. Growth начинается от $499 в месяц с SLA по доступности и задержкам и 30-дневным хранением. Каждый платный план включает 10,000 событий в месяц; сверх этого доставленные события тарифицируются по убывающим ступеням — от $3.00 за 100,000 событий при малых объёмах до $0.35 за 100,000 событий при объёме свыше полумиллиарда событий. Пропускная способность сверх включённых 5 событий в секунду на получателя — отдельный аддон, повторные попытки включены, а статический IP стоит дополнительно $100 в месяц.

Посчитаем на реалистичном примере продукта средней стадии: 10 миллионов событий в месяц на Hookdeck Team. Первые 10,000 включены, около 5 миллионов попадают в ступень $3.00 ($150), а следующие 5 миллионов — в ступень $2.00 ($100): около $250 за потребление плюс базовые $39, итого примерно $289 в месяц. Это кажется мелочью, пока неправильно настроенный эндпоинт клиента, веерная рассылка по тенантным эндпоинтам и новая функция реального времени тихо не увеличат показания счётчика в 10x. Это затраты, которые масштабируются вместе с чужим поведением, поэтому им нужна собственная строка в главной книге, а не захоронение в накладных расходах.

Себестоимость, а не накладные расходы: почему классификация имеет значение​

Самое важное учётное решение здесь — куда этот счёт попадает в вашем отчёте о прибылях и убытках. Для событийного SaaS-продукта доставка вебхуков — это себестоимость выручки (COGS): сторонний сервис, напрямую встроенный в то, что купил клиент. Если ваш продукт обещает «доставку событий на ваши эндпоинты в реальном времени», счёт от Svix или Hookdeck — такой же прямой расход на доставку, как и счёт за хостинг в AWS. Отражение его в составе общих подписок на ПО или офисных накладных расходов завышает валовую маржу и скрывает именно те затраты, которые масштабируются вместе с потреблением.

Валовая маржа — это показатель, на который инвесторы, кредиторы и покупатели смотрят в первую очередь: по бенчмарку OpenView хорошая себестоимость SaaS составляет 10–20% выручки, а данные 2026 года по стадиям дают 50–65% для SaaS на ранней стадии и 65–78% — на стадии роста. Каждый пункт затрат на вебхуки, ошибочно отнесённый к операционным расходам, приукрашивает маржу сегодня и создаёт головную боль с пересчётом отчётности завтра на due diligence, когда кто-то реклассифицирует расходы и спросит, почему ваш бизнес с «маржой 80%» на деле оказывается бизнесом с маржой 71%.

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

Настройте план счетов, отделяющий счётчик от платформы​

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

• Себестоимость выручки
  • Хостинг и вычислительные мощности (AWS/GCP/Fly)
  • Доставка вебхуков и событий
    • Svix — платформенный сбор (постоянные)
    • Svix — потребление сверх лимита (переменные)
    • Hookdeck — платформенный сбор (постоянные)
    • Hookdeck — потребление сверх лимита (переменные)
    • Пропускная способность и дополнения (статические IP, дополнительное хранение)
  • Распределение затрат на поддержку клиентов

Именно такое разделение делает возможным анализ отклонений: платформенная строка почти не должна двигаться, а измеряемая — двигаться вместе с объёмом событий. Когда измеряемая строка прыгает на 40%, а число событий выросло лишь на 10%, вы знаете, где искать: пересечение границы тарифа, забытый аддон пропускной способности или клиент, злоупотребляющий «пожарным шлангом», — вместо того чтобы смотреть на единое усреднённое число.

Если вы ведёте учёт в простом тексте, такое разделение — это всего лишь одна иерархия счетов. Ежемесячный счёт Hookdeck может отражаться так (если вы новичок в текстовых регистрах, см. документацию по синтаксису Beancount):

2026-09-30 * "Hookdeck" "September event delivery - 10.2M events"
  Expenses:Cost-of-Revenue:Webhook-Delivery:Hookdeck:Platform-Fee    39.00 USD
  Expenses:Cost-of-Revenue:Webhook-Delivery:Hookdeck:Metered-Usage  250.00 USD
  Liabilities:Accounts-Payable:Hookdeck                             -289.00 USD

Прикрепите к журнальной записи число событий из дашборда вендора. Через полгода именно этот тег позволит ответить на вопрос «сколько нам стоили 10 миллионов событий в сентябре?», не открывая ни одного счёта.

Брутто или нетто? Вопрос принципала и агента при перепродаже доставки​

Многие событийные продукты берут с клиентов плату за то, за что вендор выставляет счёт вам: плату за превышение лимита событий, дополнительные тарифные ступени вебхуков или планы с оплатой по факту, где доставка — отдельная строка. Когда вы перепродаёте стороннюю доставку, ASC 606 требует оценки «принципал против агента», чтобы решить, отражаете ли вы выручку брутто (со счётом вендора в себестоимости) или нетто (только вашу наценку как выручку).

Критерий — контроль: контролируете ли вы оговорённую услугу до её передачи клиенту? Согласно ASU 2016-08, принципал признаёт выручку брутто и отражает затраты третьих сторон в себестоимости, а агент — тот, кто лишь организует оказание услуги другой стороной, — признаёт только своё вознаграждение. Признаки контроля включают основную ответственность за исполнение, риск запасов и свободу в установлении цены.

Большинство SaaS-продуктов уверенно оказываются на стороне принципала. Ваш клиент не может направить свои эндпоинты на ваш аккаунт в Svix, не может позвонить в поддержку Svix по поводу ваших событий и платит цену, которую установили вы, — вы контролируете доставку от начала до конца: отражайте выручку от событий брутто, а счёт вендора — в себестоимости. Агентом вы были бы лишь в случае, если по-настоящему передаёте клиента вендору (у клиента собственные отношения с вендором, а вы получаете реферальную комиссию). Ошибётесь в сторону нетто — занизите и выручку, и себестоимость; ошибётесь в сторону брутто без контроля — завысите и то, и другое. В любом случае зафиксируйте анализ в служебной записке: аудиторы попросят её, а ответ «мы всегда так делали» — не ответ.

Начисляйте счётчик до получения счёта​

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

Исправьте это регулярным начислением. В последний день месяца:

1. Заберите число событий из дашборда вендора или API потребления и зафиксируйте его (скриншот плюс выгрузка CSV).
2. Умножьте на вашу эффективную ставку ступени, чтобы оценить измеряемую плату; прибавьте фиксированный платформенный сбор.
3. Отразите начисление: дебет счёта доставки вебхуков (измеряемая часть), кредит счёта начисленной задолженности перед вендорами.
4. Когда счёт придёт, сторнируйте начисление и отразите факт, отнеся разницу на тот же измеряемый счёт, чтобы корректировка оставалась видимой.

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

Сверяйте счётчик вендора с собственными журналами событий​

Вы не оплатили бы счёт за перевозку, не сверив его с журналом отгрузок. Не оплачивайте счёт за сообщения, не сверив его с вашим событийным конвейером. Измеряемая оплата рассчитывается счётчиком вендора, а у счётчика вендора есть определения, которые вы обязаны понимать: Svix исключает повторные попытки и отфильтрованные сообщения; Hookdeck включает повторные попытки, но учитывает отброшенные запросы отдельно. «Доставленное событие» в счёте может не равняться «сгенерированному событию» в ваших журналах.

Выработайте привычку ежемесячной сверки:

• Привязывайте счёт к дашборду. Число событий в счёте должно сходиться с представлением потребления вендора за период, с точностью до округления. Если не сходится — открывайте тикет до оплаты, а не после.
• Привязывайте дашборд к своим журналам. Число сгенерированных вами событий, умноженное на средний коэффициент веерной рассылки (эндпоинтов на событие), должно примерно равняться числу попыток доставки. Устойчивый разрыв означает мёртвые эндпоинты, срабатывающие мимо фильтры или баги двойной генерации — всё это стоит денег.
• Следите за окнами хранения. Хранение содержимого и метрик — 30 дней на Svix Free и 90 на Pro; 3, 7 или 30 дней на разных ступенях Hookdeck. Если спор возникнет после истечения срока хранения, доказательств уже не будет. Выгружайте месячные сводки потребления в собственное хранилище в рамках чек-листа закрытия выше.
• Настройте алерты на веерную рассылку, а не только на объём. Общее число событий может выглядеть стабильным, пока конфигурация одного клиента с 60 эндпоинтами тихо умножает ваш счёт. Отслеживайте стоимость доставки на клиента для самых тяжёлых потребителей событий так же, как инфраструктурная команда отслеживает «шумных соседей».

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

Юнит-экономика, которую стоит отслеживать​

Совокупная себестоимость показывает маржу; юнит-экономика показывает, помогает или вредит следующий клиент. Для событийного SaaS основную информацию несут четыре коэффициента:

• Стоимость 1,000 доставленных событий в разрезе вендоров, ежемесячно. Это ваша смешанная ставка после ступеней и аддонов. Она должна снижаться с ростом объёма (скидки за объём), а если растёт — вы докупаете пропускную способность или сидите не на той ступени.
• Себестоимость вебхуков в процентах от выручки — в целом и по каждой тарифной ступени. Распространённый порог срабатывания — доставка свыше 5% выручки на любой ступени или рост быстрее выручки этой ступени два квартала подряд.
• Затраты на доставку на клиента для верхнего дециля потребителей событий. Сравнивайте со стоимостью их контракта. Корпоративный логотип, платящий $2,000 в месяц и генерирующий $400 затрат на доставку, имеет совсем иную маржу, чем предполагает средняя по плану.
• Валовая маржа по тарифной ступени с распределением доставки по фактическому потреблению, а не поровну. Равномерное распределение скрывает правду о том, что ваша ступень «Pro» субсидирует три API-шланга.

Когда коэффициент пробивает порог, у вас есть четыре рычага в порядке болезненности: пересогласовать ступень вендора (объёмные обязательства снижают ставку за единицу), оптимизировать генерацию (пакетирование, фильтрация, дебаунс), переоценить тяжёлую ступень (плата за превышение с явным указанием доставки событий) и, в крайнем случае, ограничить или ухудшить доставку для злоупотребляющих потребителей. Алерты по марже работают, только если базовые счета чистые, — поэтому разделение плана счетов предшествует дашборду, а не следует за ним.

Разработка или покупка глазами бухгалтера​

Каждая страница тарифов вендора вебхуков содержит матрицу «разработка или покупка», и её стоит читать глазами бухгалтера, потому что два варианта отражаются в отчётности совершенно по-разному.

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

Разработка запускает ASC 350-40 — ПО для внутреннего использования. Затраты, понесённые на стадии разработки приложения — внешние прямые затраты на материалы и услуги, вознаграждения третьим сторонам за разработку ПО, оплата труда разработчиков, назначенных на проект, — капитализируются как актив и амортизируются в течение срока полезного использования ПО. Работы предварительной стадии (оценка вендоров, прототипирование) и затраты после внедрения (обучение, поддержка, операции по конверсии данных) относятся на расходы по мере возникновения. Таким образом, собственная служба доставки проявляется как амортизация (обычно в себестоимости для системы, встроенной в продукт, или рядом с НИОКР — в зависимости от вашей учётной политики) плюс текущая инфраструктура для её работы, а время инженеров, потраченное на тушение очереди в 2 часа ночи, — это расходы на поддержку, а не актив.

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

Ошибки, которые тихо портят учёт событийного бизнеса​

• Захоронение счётчика в общем счёте подписок. Как только затраты на доставку делят строку с вашим менеджером паролей, вы теряете способность видеть эрозию маржи. Выделяйте их в том месяце, когда начинается оплата по факту, а не в том, когда становится больно.
• Закрытие по кассовому методу. Отражение измеряемых счетов вендоров по оплате вместо начисления заставляет себестоимость дёргаться вслед за сроками счетов, а не за потреблением. Начисляйте, затем корректируйте.
• Забытые аддоны. Ступени пропускной способности, статические IP, дополнительное хранение и годовые предоплаты платформы с ежемесячной амортизацией — всё это относится к себестоимости доставки. Итог счёта и строка «потребление» в дашборде редко совпадают — сверяйтесь со счётом.
• Игнорирование вопроса перепродажи. Если вы берёте плату за событие, напишите записку «принципал против агента» до первого аудита, а не во время него.
• Истечение срока хранения доказательств. Выгружайте потребление ежемесячно. Окно вендора в 3 или 30 дней не станет ждать вашего спора.

Держите инфраструктурные затраты на виду с первого миллиона событий​

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

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