Одного лютневого п'ятничного дня 2026 року сотні бухгалтерських фірм відкрили свої поштові скриньки й дізналися, що платформа ШІ-бухгалтерії, яка вела облік їхніх клієнтів, закривається — назавжди і майже негайно. Botkeeper, компанія автоматизації з венчурним фінансуванням, яка провела 11 років і майже 90 мільйонів доларів, перетворюючись на бек-офіс для сотень бухгалтерських практик, зникла протягом кількох тижнів після перших ознак проблем.
Якщо ви передаєте на аутсорс будь-яку частину свого фінансового обліку стороній платформі — а у 2026 році це робить майже кожен — варто на хвилину над цим замислитися. Не тому, що інструменти ШІ-бухгалтерії погані. Більшість із них справді корисні. А тому, що "постачальник може зникнути" — це реальний операційний ризик, а не гіпотетичний, і дуже мало малих підприємств мають план на цей випадок.
Що насправді сталося з Botkeeper
Botkeeper побудувала свій бізнес на простій ідеї: дозволити ШІ обробляти категоризацію транзакцій, звірки та звітність, щоб бухгалтерські фірми могли масштабувати свої послуги без пропорційного збільшення штату. Це працювало достатньо добре, щоб залучити майже 90 мільйонів доларів венчурних інвестицій і протриматися понад десятиліття — вічність за стандартами стартапів.
Потім, наприкінці 2025 року, бухгалтерську галузь охопила несподівана хвиля консолідації. Botkeeper мала концентровану клієнтську базу: за деякими оцінками, 30–40% її доходу надходили лише від десяти великих бухгалтерських фірм-клієнтів. Коли кілька з цих фірм об'єдналися, були придбані або змінили платформи в межах цієї консолідації, дохідна база Botkeeper не зменшувалася поступово — вона тріснула одразу.
Пізніше генеральний директор Enrico Palmerino описав це як "ідеальний шторм макроекономічних змін", зазначивши, що фінансові перспективи компанії кардинально змінилися "за лічені тижні". Примітно, що Botkeeper не залучала нового фінансування з листопада 2021 року — чотири роки без залучення капіталу в епоху, коли ШІ-компанії залучали кошти безперервно, з висоти сьогодення виглядають як сигнал того, що компанія була або тихо прибутковою, або вже працювала економно на скороченому запасі. Коли найбільші клієнти захиталися, не вистачило ні капіталу, ні часу, щоб пом'якшити удар. Попри пошуки покупця чи проміжного фінансування, Palmerino сказав, що компанія "не досягла рівня відповідності продукту ринку, достатньо міцного, щоб витримати стрімкі зміни в галузі", і не змогла знайти варіант, який би її врятував.
Наслідки настали негайно: приблизно 600 співробітників втратили роботу майже без попередження, сотні бухгалтерських фірм змушені були терміново шукати заміну бухгалтерській інфраструктурі, а тисячі кінцевих клієнтів — малих підприємств, чий облік вівся через Botkeeper, причому більшість із них навіть не знали цієї назви бренду, — зіткнулися зі збоями у звірках, категоризації та робочих процесах звітності. У результаті угоди з поглинання конкурент Xendoo придбав основну технологію Botkeeper ("Botkeeper Infinite"), але це мало чим допомогло фірмам, яким потрібна була безперервність зараз, а не майбутня інтеграція.
Чому це не лише проблема Botkeeper
Спокуса прочитати цю історію як розповідь про невдачу однієї компанії велика. Насправді це історія про структурний ризик, вбудований майже в кожні сучасні відносини з фінансовим програмним забезпеченням.
Ризик концентрації діє в обидва боки. Botkeeper зазнала невдачі частково тому, що надто сильно залежала від невеликої кількості великих клієнтів. Але бухгалтерські фірми та малі підприємства на іншому боці цих відносин мали дзеркальну проблему: вони повністю залежали від одного постачальника у функції, ключовій для ведення бізнесу. Коли концентрована клієнтська база Botkeeper тріснула, тріснув і кожен бізнес, зосереджений на Botkeeper.
Швидкість важливіша, ніж більшість планує. Це не був повільний занепад із роком попередження. Фінансове погіршення та рішення про закриття відбулися протягом кількох тижнів. Фірми, які мали місяці на планування плавного виходу, — виняток; більшість збоїв постачальників стискають часову шкалу "знайти заміну" до кількох днів.
Ваші дані не переходять до вас автоматично. Botkeeper порадила постраждалим фірмам експортувати всі дані — історичні транзакції, звірки, правила категоризації, конфігурації клієнтів — до втрати доступу. Це правильна порада, але вона надається під час кризи, коли інструменти експорту можуть підтримуватися мінімальним персоналом, а формати можуть не відповідати чітко тій заміні платформи, яку ви поспішаєте розгорнути.
У США немає запобіжної сітки. Закон ЄС про дані (Data Act) тепер вимагає від SaaS-постачальників, що працюють там, підтримувати експорт даних і надавати клієнтам можливість переходити до інших постачальників з обмеженим попередженням. У Сполучених Штатах немає еквівалентного федерального закону. Ваші права у разі закриття постачальника — це те, що прописано у вашій угоді про надання послуг, а більшість малих підприємств ніколи не читають цей пункт, доки він їм не знадобиться.
Як захистити свій облік, ще до того як це знадобиться
Вам не потрібно передбачати, який постачальник може зазнати невдачі наступним. Потрібно лише зробити так, щоб невдача була переживаною. Кілька конкретних звичок виконують більшу частину роботи:
Експортуйте рано, експортуйте часто. Не чекайте повідомлення про закриття, щоб дізнатися, які у вас є варіанти експорту. Робіть повний експорт даних — транзакції, план рахунків, історію звірок — за регулярним графіком (щомісяця цілком розумно для більшості малих підприємств) і зберігайте копії десь поза платформою постачальника. Якщо постачальник ускладнює, уповільнює або робить це дорогим, сприймайте це як тривожний сигнал щодо самих відносин, а не просто як незручність.
Наполягайте на стандартних форматах. Перш ніж впроваджувати будь-який інструмент бухгалтерії чи обліку, перевірте, чи експортує він дані у відкриті, широко підтримувані формати (CSV, стандартні формати книг обліку, простий текст), а не у власницький формат, який може прочитати лише програмне забезпечення вашого поточного постачальника. Файл, який можна відкрити в текстовому редакторі або імпортувати в будь-яку іншу систему, — це файл, який переживе закриття. Файл, замкнений у власницькій схемі бази даних, — ні.
Читайте пункт про вихід у контракті до підписання, а не тоді, коли він вам знадобиться. Шукайте конкретно формулювання про право власності на дані, права на експорт, терміни попередження про припинення обслуговування та будь-які збори, пов'язані з виходом. Якщо умови постачальника нечіткі щодо цих моментів, це питання, яке варто поставити прямо під час процесу продажу.
Стежте за ризиком концентрації на боці постачальника, а не лише на своєму власному. Постачальник із невеликою, концентрованою клієнтською базою (як залежність Botkeeper від десяти великих клієнтів у третині свого доходу) більш крихкий, ніж той, що має широкий, диверсифікований клієнтський мікс. Це важко оцінити ззовні, але історія фінансування, тенденції штату та те, скільки часу минуло відтоді, як компанія востаннє залучала капітал, — усе це публічні сигнали, варті швидкого пошуку перед тим, як ви візьмете на себе зобов'язання.
Відокремте свої першоджерельні записи від прикладного рівня будь-якого окремого постачальника. Це глибший урок. Якщо ваші фактичні фінансові записи — книга обліку того, що сталося, коли і чому — існують лише всередині власницької бази даних однієї компанії, ви за один крок від повідомлення про закриття до паніки. Якщо ваші записи живуть у довговічному, портативному, читабельному для людини форматі, який може прочитати будь-який інструмент, невдача постачальника стає незручністю, а не кризою.
Останній пункт — це саме той аргумент на користь бухгалтерії у форматі простого тексту. Коли ваш облік ведеться у файлах простого тексту під контролем версій — модель, на якій побудований Beancount.io — немає власницької бази даних, до якої можна втратити доступ, немає кнопки експорту, яка може перестати працювати, і немає постачальника, чиє банкрутство визначало б, чи зможете ви побачити свою власну історію транзакцій наступного місяця. Ваша книга обліку живе у файлах, якими ви володієте, читабельних будь-яким інструментом, з резервними копіями будь-де, де вам зручно, з повною історією, яку Git зберігає незалежно від того, чи все ще працює компанія, що створила ваше бухгалтерське програмне забезпечення. Почніть безкоштовно і подивіться, як це — вести облік, що не залежить від платоспроможності жодного окремого постачальника.
Більша тенденція, за якою варто стежити
Крах Botkeeper — це не поодинокий інцидент, а попередній перегляд. У міру того як дедалі більше функцій бухгалтерії та обліку автоматизуються платформами на основі ШІ, а венчурне фінансування таких платформ звужується після початкового циклу хайпу, подібні закриття стають більш імовірними, а не менш. Категорія ШІ-бухгалтерії за останні кілька років залучила хвилю добре фінансованих гравців; не всі з них знайдуть стійкі бізнес-моделі, а консолідація в суміжних галузях (як це сталося з клієнтською базою бухгалтерських фірм Botkeeper) може вибити дохід способами, які окремі постачальники не можуть повністю контролювати.
Ніщо з цього не означає, що вам варто уникати автоматизації — приріст продуктивності реальний, і більшість постачальників будуть у порядку. Це означає, що питання "що станеться з моїм обліком, якщо ця компанія зникне наступного кварталу" заслуговує на реальну відповідь до того, як вона вам знадобиться, а не після.
Тримайте свої записи портативними, а не лише автоматизованими
Автоматизація — це функція. Портативність — це страховий поліс. Оцінюючи будь-яку платформу бухгалтерії — на основі ШІ чи іншу — запитуйте не лише "чи заощаджує це мій час", а й "з чим я залишуся, якщо цей постачальник зникне за шість місяців". Підхід Beancount.io з простим текстом означає, що ваші фінансові записи завжди належать вам: прозорі, під контролем версій і читабельні без нічого екзотичнішого за текстовий редактор. Дослідіть beancount.io і побудуйте свій облік на фундаменті, що не залежить від виживання жодної окремої компанії.