Ваш рахунок за вебхуки — це COGS, а не накладні витрати: бухгалтерія для event-driven SaaS на Svix та Hookdeck

Ваш дохід зріс на 20% минулого кварталу, але ваш рахунок за доставку вебхуків потроївся — і ви дізналися про це з виписки по кредитній картці, а не зі своїх книг. Якщо ви запускаєте event-driven SaaS-продукт на Svix або Hookdeck, така несподіванка — майже обряд посвячення: один балакучий корпоративний клієнт, одна буря повторних спроб (retry storm) або одна функція fan-out може помножити обсяг подій, поки ваш дохід від підписок ледь рухається. Чи постане це як червоний прапорець у вашій валовій маржі, чи сховається в загальній статті витрат «Програмні підписки», залежить повністю від того, як ви це проведете в обліку.

Ось як правильно класифікувати витрати на вебхук-інфраструктуру за повідомленнями, нараховувати їх наприкінці місяця до отримання рахунку, звіряти лічильники постачальника з власними журналами подій та відстежувати одиничну економіку, яка показує, коли витрати на доставку з'їдають вашу маржу.

Що насправді коштує вебхук-інфраструктура у 2026 році​

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

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

Hookdeck має схожу структуру, але з дрібнішим метруванням. Developer — $0 (до 10 000 подій на місяць, 3-денне зберігання). Team починається від $39 на місяць із pay-as-you-go метруванням та 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 на місяць. Це здається дрібницею, доки неправильно налаштована кінцева точка клієнта, ваш fan-out на кінцеві точки кожного клієнта та нова real-time функція непомітно не збільшать лічильник у 10 разів. Це витрати, які масштабуються від поведінки когось іншого, і саме тому вони потребують окремого рядка в головній книзі, а не поховання в накладних витратах.

COGS, а не накладні витрати: чому класифікація має значення​

Найважливіше рішення в бухгалтерії тут — де рахунок ляже у вашому звіті про прибутки та збитки. Для event-driven SaaS-продукту доставка вебхуків — це собівартість доходу (COGS) — це сторонній сервіс, вбудований безпосередньо в те, що купив клієнт. Якщо ваш продукт обіцяє «доставку подій у реальному часі на ваші кінцеві точки», рахунок від Svix або Hookdeck є таким же прямим витратами на доставку, як ваш рахунок за AWS-хостинг. Проведення його за загальними програмними підписками або офісними накладними витратами завищує вашу валову маржу та ховає саме ті витрати, які масштабуються разом із використанням.

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

Правило великого пальця: якби ви завтра вимкнули постачальника, чи втратили б клієнти функцію, за яку вони платять? Якщо так — це COGS. Ваш внутрішній інструмент відстеження помилок — це накладні витрати; канали, які доставляють платні сповіщення про події, — це собівартість доходу.

Налаштуйте план рахунків, який відокремлює лічильник від платформи​

Дайте доставці вебхуків власні субрахунки, щоб постійні та змінні витрати ніколи не змішувалися. Структура, яка працює для більшості event-driven продуктів:

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

Цей розподіл робить можливим аналіз відхилень: рядок платформи майже не рухається, тоді як метровий рядок рухається разом з обсягом подій. Коли метровий рядок стрибає на 40%, а кількість подій зросла лише на 10%, ви знаєте, що шукати — перехід межі тарифу, забуте доповнення пропускної здатності або клієнта, який зловживає потоком даних — замість того, щоб дивитися на одне змішане число.

Якщо ви ведете книги у вигляді звичайного тексту, той самий розподіл — лише один крок до ієрархії рахунків. Щомісячний рахунок Hookdeck може бути проведений так (див. документацію синтаксису Beancount, якщо ви новачок у текстових книгах обліку):

2026-09-30 * "Hookdeck" "Доставка подій за вересень - 10.2M подій"
  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 мільйонів подій у вересні?», не відкриваючи жодного рахунку.

Валова чи чиста? Питання principal-vs-agent, коли ви перепродуєте доставку​

Багато event-driven продуктів стягують з клієнтів те, що постачальник виставляє вам: плату за понадлімітні події, тарифи вебхук-доповнень або плани з usage-based білінгом, де доставка є окремим рядком. Коли ви перепродуєте сторонню доставку, ASC 606 вимагає оцінки principal-versus-agent, щоб вирішити, чи звітувати дохід як валовий (з рахунком постачальника в COGS), чи як чистий (лише ваша націнка як дохід).

Тест — це контроль: чи контролюєте ви зазначену послугу до її передачі клієнту? Згідно з ASU 2016-08, principal визнає дохід як валовий і записує сторонні витрати в COGS, тоді як агент — той, хто лише організовує надання послуги іншою стороною — визнає лише свою винагороду. Індикатори контролю включають первинну відповідальність за виконання, ризик запасів і свободу у встановленні цін.

Більшість SaaS-продуктів однозначно перебувають на боці principal. Ваш клієнт не може направити свої кінцеві точки на ваш акаунт Svix, не може звертатися до підтримки Svix щодо ваших подій і платить ціну, яку ви встановили — ви контролюєте доставку від початку до кінця: звітуйте дохід від подій як валовий, а рахунок постачальника як COGS. Ви були б агентом лише якби справді передавали клієнта постачальнику (клієнт тримає відносини з постачальником, а ви отримуєте реферальну частку). Якщо помилитися в бік чистого доходу, ви занизите і дохід, і COGS; якщо помилитися в бік валового без контролю — завищите обидва. У будь-якому разі задокументуйте аналіз у меморандумі — аудитори про це питають, і «ми завжди так робили» — не відповідь.

Нараховуйте лічильник до надходження рахунку​

Постачальники з метруванням фіналізують рахунки через кілька днів після закінчення місяця — AWS зазвичай фіналізує між третім і п'ятим числом наступного місяця, і API-постачальники з usage-based білінгом дотримуються тієї ж схеми. Якщо ви закриваєте книги першого числа та проводите рахунки постачальників, коли вони надходять, кожне закриття місяця або чекає на постачальників, або мовчки скидає місяць витрат на доставку в неправильний період.

Виправте це постійним нарахуванням. В останній день місяця:

1. Отримайте кількість подій із панелі постачальника або usage API та зафіксуйте її (скриншот плюс CSV-експорт).
2. Помножте на ефективну ставку тарифу, щоб оцінити метрову плату; додайте постійну платформенну плату.
3. Проведіть нарахування: дебет Webhook Delivery (метровий), кредит Accrued Vendor Payables.
4. Коли рахунок надійде, сторнуйте нарахування та проведіть фактичну суму, віднісши різницю на той самий метровий рахунок, щоб коригування було видимим.

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

Звіряйте лічильник постачальника зі своїми журналами подій​

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

Сформуйте щомісячну звичку звіряння:

• Прив'яжіть рахунок до панелі. Кількість подій у рахунку має збігатися з представленням використання постачальника за період, у межах округлення. Якщо ні — відкрийте тикет до оплати, а не після.
• Прив'яжіть панель до ваших журналів. Кількість надісланих подій, помножена на середній fan-out (кінцеві точки на подію), має приблизно дорівнювати спробам доставки. Стійкий розрив означає мертві кінцеві точки, неправильно налаштовані фільтри або баги подвійної відправки — все це коштує грошей.
• Слідкуйте за вікнами зберігання. Зберігання корисного навантаження та метрик становить 30 днів на Svix Free і 90 на Pro; 3, 7 або 30 днів на тарифах Hookdeck. Якщо суперечка виникає після закінчення зберігання, докази зникли. Експортуйте щомісячні зведення використання у власне сховище як частину чек-листа закриття вище.
• Слідкуйте за fan-out, а не лише обсягом. Загальна кількість подій може виглядати стабільною, поки конфігурація одного клієнта з 60 кінцевими точками мовчки збільшує ваш рахунок. Відстежуйте вартість на клієнта для ваших найважчих споживачів подій так, як інфраструктурна команда відстежує гучних сусідів.

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

Одинична економіка, яку варто відстежувати​

Агрегований COGS розповідає вам про маржу; одинична економіка — про те, чи допомагає наступний клієнт, чи шкодить. Для event-driven SaaS чотири коефіцієнти несуть більшу частину сигналу:

• Вартість на 1000 доставлених подій, за постачальником, щомісяця. Це ваша змішана ставка після тарифів і доповнень. Вона має знижуватися зі зростанням обсягу (знижки за тарифами) — якщо вона зростає, ви купуєте доповнення пропускної здатності або сидите в неправильному тарифі.
• COGS на вебхуки як відсоток доходу, загалом і за тарифними планами. Поширений тригер — доставка понад 5% доходу на будь-якому тарифі або зростання швидше, ніж дохід цього тарифу, протягом двох кварталів поспіль.
• Вартість доставки на клієнта для верхнього дециля споживачів подій. Порівняйте із вартістю їхніх контрактів. Корпоративний клієнт, який платить $2000 на місяць, генеруючи $400 витрат на доставку, має зовсім іншу маржу, ніж середня по плану.
• Валова маржа за тарифним планом із розподілом доставки за фактичним використанням, а не рівномірно. Рівномірний розподіл приховує правду, що ваш тариф «Pro» субсидує три API-потоки.

Коли коефіцієнт перетинає свій тригер, у вас є чотири важелі, за зростанням болю: переглянути тариф постачальника (зобов'язання за обсягом знижують ставку за одиницю), оптимізувати відправку (батчинг, фільтрація, дебаунс), переглянути ціну важкого тарифу (usage-based оверідж, який називає доставку подій) і, як крайній засіб, обмежити або погіршити доставку для зловживаючих споживачів. Сигнали про маржу працюють лише якщо базові рахунки чисті — саме тому розподіл плану рахунків іде перед панеллю, а не після.

Build vs. Buy, версія бухгалтера​

Кожна сторінка цін вебхук-постачальника містить матрицю build-vs-buy, і її варто читати оком бухгалтера, бо два варіанти впливають на вашу фінансову звітність у зовсім різних місцях.

Купівля проста: платформенна плата та метрове використання — це періодичні витрати COGS. Жодного активу, жодного графіка амортизації, жодного тесту на знецінення — ваша валова маржа відображає справжню вартість доставки щомісяця.

Будівництво запускає ASC 350-40, програмне забезпечення для внутрішнього використання. Витрати, понесені на стадії розробки застосунку — прямі зовнішні витрати на матеріали та послуги, плата третім особам за розробку ПЗ, зарплата розробників, призначених на проєкт — капіталізуються як актив і амортизуються протягом корисного строку служби ПЗ. Витрати на попередній стадії (оцінка постачальників, прототипування) та після впровадження (навчання, обслуговування, операції з конвертації даних) списуються в момент понесення. Отже, саморобний сервіс доставки з'являється як амортизація (зазвичай у COGS для системи, вбудованої в продукт, або поруч із R&D залежно від вашої політики) плюс постійна інфраструктура для його роботи — тоді як час інженерів, витрачений на гасіння черги о 2 ночі, — це витрати на обслуговування, а не актив.

Жоден варіант не «кращий», але вони не порівнянні без коригування. Якщо ви зважуєте рішення build-vs-buy, моделюйте сторону купівлі як повністю завантажений COGS проти сторони будівництва як амортизацію плюс хостинг плюс альтернативну вартість команди — і пам'ятайте, що якщо ви спочатку будуєте, а потім мігруєте на постачальника, капіталізований актив знецінюється до нуля в день виведення з експлуатації. Це списання вже не раз ставило крапку в історіях «ми просто самі побудуємо вебхуки».

Помилки, які мовчки псують книги event-driven бізнесу​

• Поховання лічильника в загальному рахунку підписок. Щойно вартість доставки ділить рядок із вашим менеджером паролів, ви втратили здатність бачити ерозію маржі. Розділіть це в місяць, коли починається usage-білінг, а не в місяць, коли це починає боліти.
• Закриття за касовим принципом. Проведення метрових рахунків постачальників під час оплати, а не виникнення, робить COGS стрибкоподібним через таймінг рахунків, а не використання. Нараховуйте, потім коригуйте.
• Забування доповнень. Тарифи пропускної здатності, статичні IP, додаткове зберігання та річні передплати за платформу, які амортизуються щомісяця, — усе це належить до COGS доставки. Підсумок рахунку та рядок «використання» в панелі рідко бувають однаковими — звіряйтеся з рахунком.
• Ігнорування питання перепродажу. Якщо ви берете плату за подію, напишіть меморандум principal-vs-agent до першого аудиту, а не під час нього.
• Дозвіл тому, щоб строк зберігання з'їв докази. Експортуйте використання щомісяця. 3-денне чи 30-денне вікно постачальника не чекатиме вашої суперечки.

Тримайте витрати на інфраструктуру видимими з першого мільйона подій​

Обсяг подій — це той вид витрат, які накопичуються мовчки: кожен новий клієнт, кінцева точка та політика повторних спроб множать лічильник, який виставляє рахунок постфактум і надходить після закриття. Класифікуйте доставку як COGS з першого дня, нараховуйте щомісяця, звіряйте зі своїми журналами та відстежуйте вартість на тисячу подій як важіль маржі, яким вона і є.

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