Вбудований бухучет: власна розробка чи купівля для маркетплейсів

Список обсягу робіт, модель витрат із зазначеними припущеннями та умови, за яких кожна відповідь є правильною.

Зрештою кожен маркетплейс створює власний журнал обліку (ledger). Питання лише в тому, чи робиться це свідомо як системний інструмент із надійним контролем, чи випадково у вигляді колонки balance, до якої пишуть дані три різні сервіси і якій ніхто до кінця не довіряє.

Ця стаття присвячена тому, як зробити цей вибір свідомо. У ній описано реальний обсяг робіт, методика чесного розрахунку витрат без самообману, а також конкретні умови, за яких розробка власного рішення є правильним кроком (адже таке буває).

Що тут означає «вбудований бухучет» (embedded accounting)

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

Для маркетплейса це охоплює принаймні: отримані платежі від покупців, заборгованість перед продавцями, зароблену комісію, комісії платіжних систем, ПДВ на ваші послуги та на первинне постачання, повернення коштів, чарджбеки (chargebacks), резервні фонди, виплати та звірку всього цього з банківським рахунком чи платіжним провайдером.

Що ви насправді створюєте під час розробки

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

Компонент	Що він включає
Журнал і рахунки	Збалансовані проводки, план рахунків, типи рахунків, вхідні залишки
Незмінність (immutability)	Зберігання лише для додавання (append-only), робочі процеси сторнування та виправлень, відсутність редагування на місці
Контроль звітних періодів	Закриття, блокування, відхилення запізнілих проводок, контрольоване відкриття з аудиторським слідом
Ідемпотентність	Ключі, збереження попередніх відповідей, виявлення колізій у змінених корисних навантаженнях (payloads)
Робота з грошима	Точна арифметики десяткових дробів або мінімальних грошових одиниць (minor units), коди валют, курси валют та їх джерела, рахунки для округлення
Механізм ПДВ	Ставки за країнами з датами дії, місце постачання, зі зворотним нарахуванням (reverse charge), правила платника умовної послуги (deemed supplier), пільги
Перевірка ідентифікаційних номерів платників ПДВ	Валідація за офіційним реєстром, кешування, мітки часу, ідентифікатори запитів, черга ручної перевірки у разі збоїв
Документи	Рахунки-фактури, кредитові ноти, безперервна нумерація за серіями та роками, генерація PDF, доставка
Електронне виставлення рахунків	Структуровані формати на кшталт EN 16931 UBL та національні формати країн за їх наявності
Завантаження банківських виписок	Імпорт виписок або підключення до банків за згодою, дедублікація вже імпортованих транзакцій
Звірка (reconciliation)	Правила зіставлення, оцінка релевантності, часткові збіги, винятки для ручного вирішення
Виплати	Генерація платіжних файлів, пакетні виплати, зіставлення виплат з вихідними товарними позиціями
Звітність	Оборотна сальдова відомість, баланс, звіт про прибутки та збитки, рух грошових коштів, зведення з ПДВ, звіт про старіння заборгованості
Податкові реєстри та декларації	Усе, що вимагають ваші країни у прийнятному для податкової форматі
Аудит	Суб'єкт (actor), дія, об'єкт та сама зміна з можливістю запиту для кожної модифікації
Зберігання та експорт	Десятирічний термін зберігання даних для OSS, повний експорт даних, захищений архів

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

Чесний розрахунок витрат

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

Корекція перша: компоненти забезпечення відповідності вимогам не є разовими. Ставки змінюються, пороги змінюються, формати змінюються, а європейський пакет «ПДВ у цифрову епоху» (VAT in the Digital Age) приносить календарні зобов'язання — зміни для OSS та IOSS з 1 січня 2027 року, розширені правила для платформ з 1 липня 2028 року, транскордонна цифрова звітність з 1 липня 2030 року. Власна розробка означає, що кожну з цих міграцій ви робите самостійно.

Корекція друга: робота над коректністю триває довше, ніж розробка функціоналу. Перша версія зазвичай покриває лише ідеальний сценарій (happy path). Довгий шлейф включає повернення коштів після виплати, часткові повернення, чарджбеки через кілька тижнів, округлення валют, дублікати вебхуків і файли розрахунків, які не збігаються з вашими записами. Саме тут розчиняються плани та дедлайни.

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

Корисна перевірка на адекватність: оцініть найдешевшу життєздатну розробку — журнал, виправлення, блокування періодів, ідемпотентність, роботу з грошима, ПДВ однієї країни, рахунки-фактури, банківський імпорт, зіставлення та базовий набір звітів — і порівняйте її з річною вартістю сервісу за підпискою. Опубліковані плани Nordlet починаються від 10 євро на місяць із включеними 3000 запитами й сягають 300 євро на місяць для 200 000 запитів. Якщо розробка коштує лише дещицю річного бюджету одного інженера, це вагомий аргумент на користь власних сил. Якщо ж вона коштує кілька інженеро-років плюс постійна підтримка, порівняння не на користь розробки, і з кожним роком зміни правил розрив лише збільшуватиметься.

Коли розробка власними силами дійсно виправдана

Три реальні випадки.

Ваш журнал обліку і є вашим продуктом. Якщо ви створюєте платіжну платформу, банківський продукт або гаманець, де ключовим диференціатором є поведінка балансу в умовах паралельних транзакцій (concurrency), бухгалтерський журнал є ядром і має належати вам. У такому разі розгляньте спеціалізовані інфраструктурні продукти для журналів замість написання всього з нуля, а законодавчий бухучет тримайте окремо.

Ваша бізнес-модель не вписується в жодну бухгалтерську систему. Деякі маркетплейси мають справді незвичні структури розрахунків — багатосторонні розподіли з умовним вивільненням коштів, ескроу з поетапними мієлстоунами, складну політику резервування. Якщо жоден продукт на ринку не підтримує подібну модель, а обхідні шляхи гірші за розробку — пишіть своє.

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

Коли варто купувати готове

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

Купівля також є правильним рішенням, коли ваші зобов'язання стосуються багатьох країн. Правила ПДВ для різних країн, збереження доказової бази та вимоги щодо електронного виставлення рахунків створюють постійне навантаження з підтримки, тоді як вендор розподіляє ці витрати на всіх клієнтів. Nordlet постачає європейський ПДВ за країнами з валідацією VIES, розрахунком декларацій OSS та IOSS, реєстрами i.SAF та EN 16931 UBL для Peppol як частину продукту, а не як черговий проєкт у вашому графіку.

Проміжний шлях, до якого приходить більшість команд

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

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

Така межа краще витримує зміни, ніж альтернативні варіанти. Додавання нової країни вимагає налаштування конфігурації, а не окремого проєкту. Нова політика виплат — це ваш код, а не запит до вендора.

Що потрібно вирішити перед прийняттям зобов'язань

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

FAQ

Скільки часу потрібно для створення журналу обліку маркетплейса?

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

Чи можна почати з колонки `balance` і мігрувати пізніше?

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

Чи замінює вбудований API бухучету нашу фінансову команду?

Ні. Він позбавляє від ручного введення даних і звірки. Хтось усе одно має закривати місяць, перевіряти винятки, приймати рішення в неоднозначних ситуаціях та подавати декларації.

Як бути з GDPR, якщо журнал обліку є незмінним?

Зберігайте фінансові факти та псевдонімізовані посилання в незмінних записах, а персональні дані — в окремій системі зі власними процедурами зберігання та видалення. Незмінність стосується фінансової події, а не кожної прикріпленої до неї атрибути.

Чи є програмне забезпечення з відкритим кодом (open-source) проміжним варіантом?

Це реальний варіант, який змінює структуру витрат, але не усуває їх повністю: ви берете на себе хостинг, оновлення, локалізацію під конкретні країни та оновлення відповідно до вимог законодавства. Прорахуйте ці витрати, перш ніж розглядати економію на ліцензії як повну картину.