Команда з трьох осіб, що займається хаос-інжинірингом, проводить ігровий день для клієнта-фінтеху середнього ринку, виставляє рахунок на $18,000 за дворічневе заангажування, а також перевиставляє клієнту річну ліцензію Gremlin або AWS Fault Injection Simulator вартістю $4,000, яку клієнт не хотів закуповувати напряму. Через півроку засновник дивиться на звіт про прибутки й збитки, де фігурує $22,000 "консалтингового доходу", і не може відповісти на просте запитання: наскільки прибутковою була саме інженерна робота, окремо від ролі неоплачуваного реселера програмного забезпечення?
Це дедалі поширеніша проблема. Оскільки хаос-інжиніринг перетворився з суто netflix-івської цікавинки на стандартний рядок у корпоративних програмах забезпечення стійкості, навколо нього сформувалася хвиля бутикових консалтингових компаній, які проводять аудити стійкості, фасилітують воркшопи-ігрові дні та будують автоматизовані конвеєри впровадження збоїв для клієнтів, які не хочуть наймати окрему SRE-команду. Інженерна частина роботи зрозуміла добре. А от бухгалтерський облік — зазвичай ні, адже такі компанії фактично ведуть два принципово різні бізнеси в межах однієї юридичної особи: сервісний бізнес із нерівномірним, проєктним доходом і бізнес перепродажу програмного забезпечення з регулярним, низькомаржинальним, транзитним грошовим потоком. Змішування їх в одному плані рахунків приховує, який саме з них насправді приносить вам гроші.
Чому в компаній з хаос-інжинірингу ця проблема гостріша, ніж у більшості консалтингових фірм
Звичайна стратегічна консалтингова компанія виставляє рахунок за час — і на цьому все. А практика хаос-інжинірингу зазвичай має три-чотири окремі потоки доходу, що працюють одночасно:
- Аудити стійкості — заангажування з фіксованою оплатою або погодинною оплатою, у межах якого перевіряється архітектура клієнта, граф залежностей і точки відмови ще до будь-якого впровадження збоїв. Це діагностична робота, яка зазвичай оформлюється як звіт разом із пріоритизованим бэклогом експериментів.
- Фасилітація ігрового дня — власне жива подія, під час якої команда планує сценарії відмов, запускає їх на стейджингу чи в продакшені та супроводжує інженерів клієнта в процесі реагування на інцидент. Ігрові дні перевіряють не лише систему, а й людей та операційні регламенти навколо неї, тому їх оцінюють і скоупять інакше, ніж постійне автоматизоване тестування хаосу.
- Автоматизація та розбудова платформи — впровадження регулярних хаос-експериментів у CI/CD, що ближче до постачання програмного забезпечення, ніж до воркшопу, і часто виставляється рахунком як проєкт із віхами.
- Перепродаж інструментів або транзитні платежі — перепродаж чи адміністрування ліцензій на такі платформи, як Gremlin, Harness Chaos Engineering, або налаштування хмарних сервісів на кшталт AWS Fault Injection Simulator і Azure Chaos Studio від імені клієнта — іноді з націнкою, іноді за собівартістю, як зручність.
Кожен з цих напрямків має інакшу структуру витрат, інакший профіль маржі та — що критично важливо — інакше трактування визнання доходу за ASC 606, якщо ви є юридичною особою у США, що готує GAAP-подібну звітність для банку, інвестора чи для власного прийняття рішень. Об'єднайте все це в один рахунок "Консалтинговий дохід" — і ви втратите можливість побачити, що ваша фасилітація ігрових днів має маржу 80%, а перепродаж інструментів — маржу 8% і ледь виправдовує адміністративні витрати.
Побудова плану рахунків за потоком доходу, а не за клієнтом
Найефективніша зміна в бухгалтерському обліку, яку може зробити компанія з хаос-інжинірингу, — це розділити рахунки доходу за типом виконаної роботи, а не за клієнтом чи рахунком-фактурою. Типова структура виглядає так:
Income:Consulting:ResilienceAudits
Income:Consulting:GameDayFacilitation
Income:Consulting:AutomationBuildOut
Income:ToolingResale:Licenses
Income:ToolingResale:CloudUsagePassThroughКоли ви виставляєте клієнту рахунок за пакетне заангажування — скажімо, аудит стійкості, за яким слідує ігровий день, з включеною ліцензією Gremlin, — цей один рахунок потрібно розподілити щонайменше на три з цих рахунків в обліку, а не проводити як один сукупний рядок "Проєкт X — $22,000". У подвійному запису, у текстових форматах на кшталт Beancount, це одна транзакція з кількома проведеннями:
2026-07-16 * "Fintech Client Co" "Resilience audit + game day + Gremlin license"
Assets:AccountsReceivable:FintechClientCo 22000.00 USD
Income:Consulting:ResilienceAudits -6000.00 USD
Income:Consulting:GameDayFacilitation -12000.00 USD
Income:ToolingResale:Licenses -4000.00 USDЩойно ця транзакція існує, вона дозволяє в будь-який момент отримати реальний звіт про прибутковість за напрямком послуг — замість того, щоб відновлювати його з пам'яті чи старих пропозицій, коли ваш бухгалтер у березні запитує, чому маржа виглядає непослідовно.
Пастка перепродажу інструментів: транзитний платіж проти націнки проти агентства
Перепродаж чи адміністрування ліцензій на сторонні інструменти хаос-інжинірингу — це саме те місце, де такі компанії найчастіше помиляються в обліку — і в податковому трактуванні. Існує три окремі схеми, і вони ніколи не повинні ділити один рахунок обліку:
- Чистий транзитний платіж: ви платите Gremlin $4,000 за ліцензію, виставляєте клієнту рахунок рівно на $4,000 і не берете жодної націнки. Деякі компанії проводять це нетто (лише маржу, яка становить $0), а не брутто. Якщо ваш договір про заангажування встановлює вас як закупівельного агента клієнта, а не реселера-власника, це може підпадати під трактування "агент проти принципала" за ASC 606 — тобто ви записуєте платіж постачальнику та відшкодування від клієнта як взаємозалік, а не роздуваєте одночасно і дохід, і собівартість. Це важливо, бо змінює вашу цифру валового доходу, яка впливає на все — від кредитних коефіцієнтів до того, як покупець оцінює вашу компанію за мультиплікатором доходу.
- Перепродаж із націнкою: ви купуєте ту саму ліцензію за $4,000 і виставляєте клієнту рахунок на $5,000, залишаючи собі спред у $1,000. Тут ви виступаєте як принципал — ви контролюєте товар чи послугу до їх передачі клієнту — і повинні записати повні $5,000 як дохід, а $4,000 як собівартість реалізованої продукції, а не згортати це до $1,000. Проведення нетто занижує обидва рядки — доходу і собівартості, — які покупець чи кредитор можуть захотіти бачити окремо.
- Клієнт закуповує напряму: найчистіша схема — у клієнта є власний контракт з Gremlin чи FIS, а ви лише адмініструєте його. Ваш облік це взагалі не зачіпає, тому дедалі більше консалтингових компаній, зростаючи, підштовхують клієнтів до прямої закупівлі: це прибирає з їхнього P&L цілий низькомаржинальний напрямок бізнесу з ризиком щодо термінів грошового потоку.
Яку б схему ви не використовували, оберіть одну для кожних клієнтських відносин і дотримуйтеся її послідовно — змішування трактувань "агент" і "принципал" для того самого постачальника в різних клієнтів без задокументованої причини — це саме та непослідовність, яка перетворює рутинну перевірку обліку на затяжну.
Визнання доходу за аудитами з фіксованою оплатою проти ігрових днів за віхами
Аудити стійкості та воркшопи-ігрові дні зазвичай продаються за фіксованою оплатою, що за ASC 606 не означає "визнати весь дохід у момент оплати рахунка". Стандарт вимагає визнавати дохід у міру виконання зобов'язання за договором — або в певний момент часу, або протягом певного періоду, залежно від того, чи отримує й споживає клієнт вигоду в міру того, як ви її надаєте.
- Аудит стійкості, який постачається у вигляді єдиного звіту наприкінці дворічневого заангажування, зазвичай визнається в певний момент часу: жодна сума не потрапляє в дохід, доки звіт не буде надано й прийнято, навіть якщо ви виставили рахунок на 50% авансом. Цей аванс перебуває на рахунку зобов'язань (
Liabilities:DeferredRevenue:ResilienceAudits) до моменту постачання. - Багатоденне заангажування з ігровим днем із щоденними результатами роботи — документами сценаріїв відмов, хронологіями інцидентів, підсумковим ретро — часто підпадає під визнання доходу протягом періоду, оскільки клієнт отримує й використовує цінність поступово, а не одним великим постачанням наприкінці.
- Розбудову автоматизації з договірними віхами (запуск конвеєра на стейджингу, заплановані продакшн-експерименти, передача дашборда) слід визнавати поетапно, за кожною віхою, що також істотно полегшує прогнозування грошового потоку, оскільки ви не чекаєте на один великий платіж наприкінці проєкту.
Помилка тут створює не лише головний біль під час аудиту в майбутньому — вона спотворює ваше власне уявлення про бізнес у реальному часі. Компанія, що записує аванс у $30,000 як дохід у день його надходження, а потім постачає аудит через два місяці, у першому місяці виглядатиме значно прибутковішою, а в третьому — значно менш прибутковою, ніж є насправді, а це погана основа для рішення про найм наступного інженера.
Відстеження завантаженості та реальної маржі за типом заангажування
Щойно дохід розділено правильно, наступний крок — зіставити з ним витрати. Консультанти з хаос-інжинірингу зазвичай виставляють рахунки за старшими ставками, тому розподіл витрат на робочу силу тут важливіший, ніж у сервісних бізнесах з нижчою маржею. Для кожного типу заангажування відстежуйте:
- Прямі години праці, віднесені до конкретного заангажування (а не просто "консалтингові години" загалом) — саме це показує, що аудит стійкості, розрахований на 40 годин, насправді зайняв 65, і його потрібно переоцінити наступного разу.
- Витрати на інструменти, віднесені до конкретних клієнтських відносин, що спричинили покупку ліцензії, а не звалені в загальний рядок витрат на програмне забезпечення.
- Витрати на відрядження та роботу на місці для очних ігрових днів, які можуть суттєво змінити маржу порівняно з ідентичним віддаленим заангажуванням.
Результатом стає звіт про маржу за типом заангажування, який дійсно дає корисну інформацію: багато компаній у цій сфері виявляють, що аудити стійкості та розбудова автоматизації мають найсильнішу маржу, бо це чистий інженерний час, тоді як фасилітовані ігрові дні — попри преміальні денні ставки — мають тоншу маржу, коли повністю враховано час старшого фасилітатора, відрядження та попередній дизайн сценаріїв. Без розділеного обліку це непомітно; з ним — це проста розмова про ціноутворення з наступним потенційним клієнтом.
Тримайте інженерну дисципліну і у своєму фінансовому обліку
Тут є природна паралель, яку практики хаос-інжинірингу зазвичай одразу оцінюють: уся дисципліна побудована на ідеї, що не можна довіряти системі, яку ви не протестували, а непрозора, важка для інспекції інфраструктура приховує режими відмов, які зрештою вас підкосять. Те саме стосується електронної таблиці чи закритого SaaS-інструменту обліку, який згортає ваш перепродаж інструментів із консалтинговим доходом без вашого відома, — ви не дізнаєтеся, що маржа була неправильною, доки шкода вже не завдана. Текстовий, версіонований облік означає, що кожне проведення можна проінспектувати, порівняти за версіями і перевірити так само, як ви хотіли б це робити зі своєю інфраструктурою-як-кодом, а розділення потоків доходу на рівні транзакції (а не відновлене пізніше з пам'яті) — це те, що насправді робить можливим щомісячний огляд прибутковості, а не щомісячний археологічний проєкт.
Спростіть управління фінансами
У міру того як ваша практика хаос-інжинірингу переростає з одноосібного бізнесу засновника в команду з кількома паралельними заангажуваннями, чітке розділення доходу від аудитів стійкості, фасилітації ігрових днів і перепродажу інструментів — це те, що взагалі уможливлює рішення щодо ціноутворення та аналіз маржі. Beancount.io пропонує текстовий бухгалтерський облік, що дає вам повну прозорість і контроль над вашими фінансовими даними — без чорних скриньок, без прив'язки до постачальника. Почніть безкоштовно і дізнайтеся, чому розробники та технічні консалтингові компанії переходять на текстовий облік.