Embedded Accounting: собственная разработка или покупка для маркетплейсов
Список задач, модель затрат с четкими допущениями и условия, при которых каждое из решений оказывается верным.
Раньше или позже каждый маркетплейс создает собственный бухгалтерский регистр (ledger). Вопрос лишь в том, делается ли это осознанно, как управляемая система с четким контролем, или случайно, в виде колонки balance, в которую пишут три разных сервиса, а доверять ей до конца не может никто.
Эта статья поможет сделать осознанный выбор. В ней описан реальный объем работ, методика честного расчета затрат и те специфические условия, при которых собственная разработка оправданна, ведь иногда это действительно правильный путь.
Что такое встроенная бухгалтерия (embedded accounting) в данном контексте
Встроенная бухгалтерия означает, что учетные регистры находятся внутри вашего продукта, а не в сторонней программе, которую кто-то открывает отдельно. Ваше программное обеспечение фиксирует проводки по мере возникновения событий, пользователи видят всю необходимую информацию в вашем интерфейсе, а в конце месяца никому не нужно выгружать таблицы для бухгалтера.
Для маркетплейса это как минимум включает: полученные от покупателей платежи, задолженность перед продавцами, заработанную комиссию, сборы за обработку платежей, НДС с вашей комиссии и с основной поставки, возвраты, чарджбеки, резервы, выплаты и сверку всего этого с банковскими выписками или платежным провайдером.
Что на самом деле входит в собственную разработку
Сам регистр — это лишь малая часть задачи. Команды обычно оценивают по трудозатратам только первый пункт, а со всеми остальными сталкиваются уже позже.
| Компонент | Что он включает |
|---|---|
| Журнал и счета | Сбалансированные проводки, план счетов, типы счетов, начальные сальдо |
| Неизменяемость (immutability) | Хранение только с возможностью добавления (append-only), рабочий процесс сторнирования и исправления, отсутствие правок «по месту» |
| Закрытие периодов | Закрытие, блокировка, отклонение проводки задним числом, контролируемое открытие с сохранением аудиторского следа |
| Идемпотентность | Ключи, сохранение предыдущих ответов, обнаружение коллизий при изменении полезной нагрузки |
| Работа с денежными суммами | Арифметика с фиксированной точкой для точного расчета десятичных знаков или в минимальных единицах валюты, коды валют, источники курсов обмена, счета для округления |
| Налоговый модуль (VAT engine) | Ставки по странам с датами их действия, определение места реализации (place of supply), обратное начисление (reverse charge), правила выполнения обязанностей налогового агента (deemed supplier rules), льготы |
| Проверка идентификационных номеров налогоплательщиков (VAT identification checks) | Валидация по официальному реестру, кэширование, метки времени, идентификаторы запросов, очередь ручной проверки при сбоях |
| Документы | Счета-фактуры, кредитные ноты, сквозная нумерация по сериям и годам, отрисовка PDF, доставка |
| Электронные счета-фактуры (E-invoicing) | Структурированные форматы вроде EN 16931 UBL, а также национальные форматы конкретных стран при наличии таких требований |
| Загрузка банковских данных | Импорт выписок или подключение к банку с согласия пользователя (consented bank connection), дедупликация уже импортированных транзакций |
| Сверка (Reconciliation) | Правила сопоставления, оценка совпадений, частичные совпадения, исключения для ручной обработки |
| Выплаты (Payouts) | Генерация платежных файлов, пакетная обработка выплат, привязка выплат к исходным позициям |
| Отчетность | Оборотно-сальдовая ведомость, бухгалтерский баланс, отчет о прибылях и убытках, отчет о движении денежных средств, сводки по НДС, ведомость дебиторской задолженности по срокам |
| Налоговые регистры и декларации | Все, что требуют ваши юрисдикции, в формате, который принимает налоговый орган |
| Аудит | Субъект, действие, объект и само изменение — все доступно для запроса при каждой мутации данных |
| Хранение и экспорт | Десятилетний срок хранения данных по OSS (One Stop Shop), полный экспорт данных, защищенный архив |
Примерно два пункта из этих семнадцати — это как раз то, что представляют себе разработчики, когда говорят: «Мы напишем свой регистр».
Честная оценка стоимости
Любые цифры здесь зависят от вашей команды, поэтому воспринимайте следующие выкладки как методику, а не как готовую смету. Возьмите компоненты из таблицы выше, оцените каждый в человеко-неделях исходя из скорости вашей команды, а затем внесите три поправки, которые при оценках обычно упускают из виду.
Поправка первая: компоненты обеспечения комплаенса не являются разовой задачей. Ставки меняются, пороги меняются, форматы отчетов меняются, а пакет законов ЕС о НДС в цифровую эпоху (VAT in the Digital Age) приносит целый ряд требований с жесткими сроками: изменения по OSS и IOSS с 1 января 2027 года, расширенные правила для платформ с 1 июля 2028 года, трансграничная цифровая отчетность с 1 июля 2030 года. Собственная разработка означает, что всю эту миграцию вы будете делать своими силами.
Поправка вторая: поддержка корректности работы отнимает больше времени, чем создание новых функций. Первая версия легко справляется с базовыми сценариями. Самый хвост проблем — это возвраты после проведения выплаты, частичные возвраты, чарджбеки, приходящие недели спустя, округление валют, дублирующиеся вебхуки и платежные файлы, которые расходятся с вашими учетными данными. Именно здесь теряются месяцы календаря.
Поправка третья: бухгалтер — это полноправный участник процесса, а не просто рецензент. Если финансовый специалист отказывается подписывать сформированную отчетность, система не готова, причем такая обратная связь обычно приходит на поздних этапах разработки.
Полезная проверка на адекватность: оцените стоимость минимально жизнеспособного решения — регистр, исправления, блокировка периодов, идепотентность, точная работа с деньгами, НДС одной страны, счета-фактуры, импорт из банка, сверка и базовый набор отчетов — и сравните ее с годовой стоимостью сервиса по подписке (metered service). Тарифы Nordlet в опубликованных планах начинаются от 10 евро в месяц (включая 3000 запросов) и доходят до 300 евро в месяц (для 200 000 запросов). Если разработка обойдется в малую долю от зарплаты одного инженера за год, тогда писать свое действительно имеет смысл. Если речь идет о нескольких человеко-годах плюс постоянная поддержка, сравнение явно не в пользу разработки, и с каждым годом изменения законодательства эта разница будет только расти.
Когда собственная разработка действительно оправданна
Есть три реальных сценария.
Ваш регистр и есть ваш продукт. Если вы создаете платежную платформу, банковский продукт или кошелек, где поведение баланса в условиях высокой конкуренции запросов является главным дифференциатором, учетный регистр — это ваше ядро, и он должен быть вашим. В таком случае лучше присмотреться к специализированным инфраструктурным продуктам для ведения регистров, а не писать все с нуля, при этом выделив законную бухгалтерию в отдельный контур.
Ваша бизнес-модель не вписывается ни в одну бухгалтерскую систему. Некоторые маркетплейсы имеют действительно необычные схемы расчетов: многосторонние разделы с условными выплатами, эскроу со стадийными этапами, сложная политика резервирования. Если ни один готовый продукт этого не поддерживает, а обходные решения хуже самостоятельной разработки, пишите свое.
Ваши объемы таковы, что модель оплаты за запросы не подходит. При экстремально высоких объемах транзакций ценообразование за каждый запрос перестает быть привлекательным. Просчитайте это на реальных цифрах перед тем, как делать выводы, поскольку под «экстремальными объемами» здесь понимаются показатели, значительно превышающие уровень большинства платформ.
Когда покупка готового решения выгоднее
Покупка побеждает тогда, когда бухгалтерия необходима, но не является вашим главным конкурентным преимуществом, что и происходит в подавляющем большинстве случаев. Ни один пользователь не выбирает маркетплейс за изящность проводок в журнале. Ошибки в бухгалтерии замечают только тогда, когда она работает неверно.
Покупка также является правильным выбором, если ваши обязательства распространяются на несколько стран. Правила НДС в каждой юрисдикции, хранение подтверждающих документов и требования по электронным счетам-фактурам требуют постоянной поддержки, тогда как вендор распределяет эти затраты на всех своих клиентов. Nordlet реализует НДС стран ЕС с валидацией через VIES, расчетом деклараций OSS и IOSS, регистрами i.SAF и форматом EN 16931 UBL для сети Peppol прямо «из коробки», избавляя вас от необходимости планировать под это отдельный долгий проект.
Промежуточный путь, к которому приходит большинство команд
На практике оптимальным ответом чаще всего становится гибридный подход: купить регистр, а рабочий процесс разработать самостоятельно.
Бухгалтерский бэкенд отвечает за проводки, налоговый режим, документы, закрытие периодов и аудиторский след. Ваш продукт отвечает за все, что видят пользователи, и за всю специфическую бизнес-логику маркетплейса: когда высвобождаются средства, каковы правила резервирования, как разрешаются споры и что отображается в панели продавца. Вы обращаетесь к API бухгалтерии в те моменты, когда происходит движение денег, оставляя за собой те части системы, которые действительно уникальны для вашего бизнеса.
Такая граница разделения ответственности переносит любые изменения гораздо проще, чем альтернативные варианты. Появление новой страны требует лишь настройки конфигурации, а не нового проекта. Новая политика выплат — это ваш код, а не запрос к разработчикам вендора.
Что нужно решить перед принятием окончательного решения
- Ваш бухгалтерский регистр — это конкурентное преимущество или неизбежная обязанность? Будьте честны с собой, в большинстве случаев это обязанность.
- Сколько стран охватывает ваш бизнес и каковы требования каждой из них? Только ставки, или еще декларации, регистры и сдача отчетности?
- Как у вас организован процесс исправления ошибок? Возвраты после выплат и поздние чарджбеки — это те кейсы, которые сразу обнажают слабость проектирования.
- Кто подписывает финансовую отчетность? Привлекайте этого человека еще на этапе проектирования, а не после его завершения.
- Каков план хранения документов в течение десяти лет? Данные по OSS должны храниться в течение десяти лет после окончания года транзакции, а архив — это система, а не простая резервная копия.
- Как будет выглядеть миграция через три года? Причем в обе стороны. Сделайте тестовую выгрузку в первый же день и поддерживайте ее работоспособность.
FAQ
Сколько времени занимает создание регистра для маркетплейса?
Первая версия, умеющая проводить сбалансированные проводки, может заработать уже через несколько недель. Версия, которая корректно обрабатывает возвраты после выплат, поздние чарджбеки, многовалютные округления, дублирующиеся вебхуки провайдеров, закрытие периодов и проверки аудитора, потребует значительно больше времени, причем поддержка не закончится никогда. Закладывайте ресурсы на второй вариант, потому что именно он означает реальную продакшн-среду.
Можно ли начать с колонки balance в базе, а потом мигрировать?
Можно, и многие так делают, но будьте готовы к тому, что миграция окажется сложнее первоначальной разработки. Восстановить историю на основе изменяемого баланса возможно лишь в том случае, если вы сохраняли каждое событие, которое его меняло, то есть если у вас фактически уже был регистр.
Заменяет ли API встроенной бухгалтерии нашу финансовую команду?
Нет. Она избавляет от ручной записи и сверки. Кто-то все равно должен закрывать месяц, разбираться с исключениями, принимать экспертные решения и подавать декларации.
Как быть с GDPR, если бухгалтерский регистр неизменяем?
Храните финансовые факты и псевдонимизированные ссылки в неизменяемых записях, а персональные данные — в отдельной системе со своими регламентами хранения и удаления. Принцип неизменяемости распространяется на финансовое событие, а не на каждый привязанный к нему атрибут.
Является ли бухгалтерское ПО с открытым исходным кодом промежуточным вариантом?
Это реальный вариант, который меняет структуру затрат, но не устраняет их: вы берете на себя хостинг, обновление версий, локализацию под разные страны и обновление требований комплаенса. Оцените эти расходы заранее, прежде чем воспринимать экономию на лицензии как итоговую цифру.