Akaunting за пару долларов в месяц? Считаем настоящий счёт

MAATRIX

Реклама самостоятельного хостинга обычно звучит так: «поставьте Akaunting на сервер за пару долларов в месяц и забудьте про подписки на бухгалтерский SaaS». Формально это правда — Akaunting бесплатен, ядро открытое, а минимальный VPS под небольшую компанию действительно стоит копейки. Но эта арифметика считает только одну строку расхода из пяти. Если вы уже решили перенести учёт на свой сервер или только сравниваете варианты, честнее сначала посчитать полную стоимость владения — сколько на самом деле стоит держать Akaunting не в первый месяц, а на дистанции года-двух.

Почему цена сервера — это не цена решения

Akaunting — open-source система для выставления счетов, учёта доходов/расходов и базовой бухгалтерии малого бизнеса, написанная на Laravel. Она действительно легковесна: не требует мощного железа, ставится на обычный LAMP/LEMP-стек или в Docker, и в большинстве случаев ей достаточно недорогого VPS с парой гигабайт памяти. Отсюда и рождается упрощённый расчёт: «сервер стоит N долларов в месяц, значит, бухгалтерия стоит N долларов в месяц».

Проблема в том, что аренда сервера — это стоимость железа, а не стоимость работающей системы учёта. Между «сервер существует» и «на сервере крутится Akaunting, в который можно спокойно заносить реальные финансовые данные компании» лежит работа: установка, настройка окружения, первичная конфигурация плана счетов и налогов, интеграция с почтой для отправки счетов клиентам, резервное копирование, регулярные обновления и — рано или поздно — разбор проблемы, которую придётся решать самостоятельно, потому что бесплатный продукт не продаёт вам SLA вместе с лицензией.

Ниже — пять статей расходов, которые обычно не попадают в исходный расчёт «сервер за пару долларов», но реально формируют стоимость владения Akaunting на self-hosted.

Установка и первичная настройка: не пять минут

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

• подготовка сервера — ОС, веб-сервер (Nginx или Apache), PHP нужной версии с обязательным набором расширений (BCMath, Ctype, Fileinfo, JSON, Mbstring, OpenSSL, PDO, Tokenizer, XML, GD или Imagick, Zip — конкретный список и версия PHP зависят от релиза Akaunting, который вы ставите, и его стоит сверить с документацией непосредственно перед установкой, а не брать по памяти из старой инструкции);
• база данных — MySQL или MariaDB, отдельный пользователь и права, при необходимости настройка репликации, если данные критичны;
• очередь задач и cron — часть операций (напоминания по счетам, повторяющиеся инвойсы, плановые отчёты) в Akaunting работает через очередь и планировщик, и без правильно настроенного cron-задания часть функциональности просто не будет срабатывать вовремя, а вы узнаете об этом не сразу;
• почта — исходящие письма со счетами клиентам требуют рабочего SMTP с настроенными SPF/DKIM, иначе счета будут либо не доходить, либо падать в спам получателя — для системы, через которую вы просите клиентов заплатить, это критично;
• HTTPS и сертификат — бухгалтерские данные и логины не должны ходить по открытому каналу, это не опция, а обязательное условие;
• первичная настройка внутри системы — компания, валюта, налоговые ставки, план счетов, шаблоны документов, права пользователей, если работает не один человек.

Если этим занимается специалист, знакомый со стеком PHP/Laravel, разумная оценка — от нескольких часов до одного полного рабочего дня в зависимости от того, сколько нюансов (почта, бэкапы, несколько компаний в одном инстансе) нужно закрыть сразу. Если этим занимается человек, который видит LEMP-стек впервые, время увеличивается в разы, а вероятность оставить дыру в конфигурации (например, забытый деплой без HTTPS или дефолтные права на директорию storage) заметно растёт. Это время стоит денег, даже если формально бесплатно — оно не потрачено на что-то ещё.

Обновления и администрирование: разовой работы не бывает

Установка — это точка на графике, администрирование — это линия, которая тянется весь срок жизни системы. Akaunting как любой активно развивающийся open-source проект регулярно выпускает обновления — исправления безопасности, совместимость с новыми версиями PHP, новую функциональность. Каждое из них требует внимания:

• проверка changelog перед обновлением — не все версии обратно совместимы без миграций базы данных;
• бэкап перед обновлением — обязательный шаг для системы, где хранятся финансовые данные, а не опциональная предосторожность;
• собственно обновление и проверка, что после него интерфейс, отправка писем и генерация PDF-документов по-прежнему работают корректно;
• параллельно — обновления самой ОС и веб-стека (PHP, MySQL), которые Akaunting не контролирует, но от которых зависит.

Отдельная головная боль — привязка к версии PHP. Laravel-приложения обычно жёстко требуют определённый диапазон версий PHP, и когда провайдер дистрибутива или хостинг обновляет PHP до новой мажорной версии, старая версия Akaunting может перестать работать до тех пор, пока вы не обновите и её саму. Это означает, что «просто оставить сервер как есть и не трогать» — плохая стратегия: заброшенный инстанс с бухгалтерскими данными на устаревшем PHP без патчей безопасности — это не экономия, а отложенный риск, причём риск не абстрактный, а связанный напрямую с финансовыми данными компании.

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

Платные приложения: бесплатное ядро — это не вся функциональность

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

Что обычно попадает в разряд дополнительных модулей, а не базового ядра (конкретный состав и цены меняются от релиза к релизу, и их нужно проверять непосредственно в магазине приложений на момент планирования бюджета, а не брать за истину из старой статьи):

• интеграции с банками для автоматической загрузки выписок;
• расширенные отчёты сверх базового набора;
• модули для конкретных вертикалей — точки продаж, учёт рабочего времени, складской учёт;
• коннекторы к внешним сервисам — платёжным шлюзам, e-commerce платформам, CRM.

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

Отсутствие вендорской поддержки: время вместо счёта

У коммерческого SaaS для бухгалтерии почти всегда есть служба поддержки: написали в чат — получили ответ, эскалировали критичный баг — получили приоритет. У self-hosted open-source продукта эта роль по умолчанию не куплена вместе с лицензией, потому что лицензии в классическом смысле и нет. Доступные каналы — документация, форум сообщества, issue-трекер на GitHub. Это работает, но по другим правилам:

• время ответа не гарантировано — сообщество отвечает, когда у кого-то есть время и мотивация, а не по SLA;
• решение проблемы часто требует самостоятельного чтения кода или логов, а не диалога с оператором поддержки, который уже видел эту проблему у сотни других клиентов;
• если баг специфичен для вашей конфигурации (версия PHP, особенности хостинга, конфликт с другим ПО на том же сервере), готового ответа в сообществе может просто не быть, и разбираться придётся своими силами.

Это не претензия к проекту — открытая модель разработки по определению устроена так, а не иначе. Но при расчёте TCO стоит закладывать не абстрактное «а вдруг что-то сломается», а конкретное время специалиста на разбор нештатных ситуаций в течение года: обновление, которое повело себя не так, как ожидалось, письмо со счётом, которое перестало отправляться после смены хостинга почты, конфликт версии PHP после планового апдейта сервера. Ни одна из этих ситуаций не редкость на дистанции года эксплуатации любой self-hosted системы — разница только в том, готовы вы закладывать время на них заранее или каждый раз реагировать в режиме аврала.

Бухгалтерские данные требуют дисциплины, а не только места на диске

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

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

Всё это выполнимо на self-hosted инстансе, и Akaunting не создаёт для этого искусственных препятствий — но выполнимо не «само по себе», а как результат осознанной настройки, которую нужно один раз спроектировать и дальше поддерживать. В стоимость сервера эта работа не входит ни в каком виде.

Честная таблица: наивный расчёт против реального TCO

Свести пять статей расходов в одну таблицу — самый быстрый способ увидеть разницу между «сервер стоит копейки» и «система учёта стоит столько-то в год».

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

Это не значит, что self-hosted Akaunting невыгоден — для компании, у которой уже есть человек, способный администрировать LAMP/LEMP-стек, и для которой набор нужных функций укладывается в бесплатное ядро плюс пара модулей, реальный TCO всё равно обычно ниже подписки на сопоставимый облачный сервис, особенно на дистанции нескольких лет. Общую логику, когда self-hosted решение выгоднее облачного, а когда нет, стоит прогнать через те же четыре критерия, что применимы к любому self-hosted сервису — предсказуемость нагрузки, критичность экспертизы, размер команды, цену отказа. Если же нужна более тяжёлая функциональность — складской учёт, производство, полноценный ERP вокруг бухгалтерии — стоит сразу сравнить с Odoo или ERPNext, где TCO считается по похожей логике, но с другим порогом сложности.

Частые вопросы