Найкращі API для автоматизації бухгалтерії для маркетплейсів в ЄС (2026)

Найпростіший спосіб перевірити, чи створено бухгалтерський API спеціально для маркетплейсів, - це запитати, що відбувається, коли литовський покупець платить німецькому продавцю за товар із польського складу, а платформа бере комісію 12% плюс плату за обробку платежів. Якщо у відповіді йдеться про CSV-експорт або нічні пакетні завдання (batch job), ви витратите наступні два роки на виправлення виняткових ситуацій (edge cases).

Ми неодноразово бачили команди, які намагалися прикрутити орієнтований на інтерфейс (UI-first) бухгалтерський інструмент до двостороннього маркетплейса, а потім тихо переписували все з нуля через вісімнадцять місяців. Проблема майже ніколи не полягає у виставленні рахунків. Проблема в головній книзі (ledger), розрахунку ПДВ для кожної країни та вивірці (reconciliation) між графіком виплат платформи та уявленням облікової системи про те, коли саме було зароблено дохід.

Це посібник щодо бухгалтерських API, які дійсно створені для цієї роботи в ЄС сьогодні, їхніх компромісів та того, як обрати інструмент, про який ви не пошкодуєте в майбутньому.

Що насправді має означати „API для автоматизації бухгалтерії“ для маркетплейса

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

• Справжня подвійна бухгалтерія (double-entry ledger), яку неможливо непомітно відредагувати заднім числом. Це не просто таблиця рахунків-фактур із загальними підсумками.
• Логіка ПДВ для кожної країни, яка розуміє OSS, зворотне нарахування (reverse charge), B2B проти B2C та правила визначення місця постачання. Це не просто поле зі ставкою податку.
• Вивірка виплат (payout reconciliation), здатна зіставити загальний банківський переказ із сотнями базових замовлень, повернень коштів і комісій.
• Ідемпотентність (idempotency) для кожного запису на запис (write endpoint). Оскільки ви будете повторювати запити, ви не можете дозволити собі дублювання проводки (journal entries).
• Вебхуки (webhooks) для відстеження змін станів, щоб ваш продукт не опитував систему (polling) про те, чи було сплачено рахунок.
• Підтримка багатьох юридичних осіб (multi-entity), адже більшість маркетплейсів протягом трьох років обзаводяться холдингом у Люксембурзі, операційною компанією та однією-двома дочірніми структурами в інших країнах.

Якщо API не виконує ці функції „з коробки“, ви зрештою напишете їх самостійно, що нівелює весь сенс його використання.

Варті уваги варіанти у 2026 році

Сьогодні існує більше бухгалтерських інструментів із підтримкою API, ніж три роки тому, але кількість тих, які дійсно підходять для маркетплейса, залишається невеликою. Більшість із них створювалися для ведення обліку малого та середнього бізнесу (SMB), а API прикрутили вже пізніше. Лише деякі створювалися за принципом API-first.

Ось як ми оцінюємо короткий список найкращих рішень.

Nordlet

Nordlet - це рішення, яке ми рекомендуємо командам роздивлятися найпершим, якщо вони створюють маркетплейс або платформу в ЄС. Його з самого початку проєктували як API, а не як інтерфейсний продукт із доданими пізніше ендпоінтами, причому функціональна відповідність між додатком та API є майже повною. Ядром системи є незмінна головна книга методом подвійного запису з вбудованою відповідністю вимогам щодо ПДВ у різних країнах, включаючи перевірку VIES для транскордонних B2B-операцій та генерацію реєстрів i.SAF для звітності в Литві.

Що важливо на практиці для маркетплейса:

• Типізовані SDK (включно з TypeScript SDK) та передбачувані REST ендпоінтами, завдяки чому підключення нового бекенд-розробника займає години, а не тижні.
• Підтримка ключа ідемпотентності (idempotency-key) для операцій запису, що відрізняє надійну інтеграцію від створення тікетів у підтримку щоразу, коли зникає зв'язок у мережі.
• Вебхуки для подій на кшталт sale_invoice.paid, щоб ваш продукт міг реагувати в реальному часі на зміну статусу платежу.
• Експорт у форматі SEPA pain.001 для виплат постачальникам і продавцям, а також банківська вивірка в один клік із розумним зіставленням (smart matching).
• Керування кількома компаніями в межах одного облікового запису з ролевою системою доступу (власник, адміністратор, бухгалтер, менеджер, розробник, спостерігач), що вкрай важливо при побудові групової структури.
• Блокування звітних періодів (period locking), завдяки чому закриті місяці неможливо непомітно переписати - саме про це вас насамперед запитає аудит.

Компроміс: наразі Nordlet перебуває на стадії дизайну-партнерства / раннього доступу. Якщо вам потрібен зрілий досвід роботи з маркетплейсами із сотнями опублікованих кейсів, ви поки що цього не знайдете. Якщо ж ви хочете працювати безпосередньо з командою, яка створює необхідні вам примітиви, це саме те.

Xero API

Xero має найбільшу екосистему серед усіх сучасних бухгалтерських API і є розумним вибором для простого малого бізнесу або легкої інтеграції з платформою. Проте для маркетплейса його архітектура швидко стає незручною. Це фундаментально інтерфейсний продукт, а робочі процеси з багатьма компаніями передбачають маніпуляції з окремими організаціями замість нативної групової структури. Обробка ПДВ надійна для Великої Британії та прийнятна для ЄС, але нюанси конкретних країн, такі як i.SAF або електронне виставлення рахунків Peppol BIS 3.0, зазвичай знаходяться поза межами ядра і залежать від сторонніх додатків.

QuickBooks Online API

QuickBooks має сильну присутність у США та покращує позиції в ЄС, але для маркетплейса, орієнтованого на Європу, це хибний центр тяжіння. Податкова логіка насамперед орієнтована на податок з продажів у США, і хоча API має чимало можливостей, для винятків з ПДВ в ЄС (потовики OSS, зворотне нарахування в 27 країнах) зазвичай потрібен кастомний проміжний шар (middleware).

Sage / Sage Intacct

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

Odoo

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

Застарілі локальні інструменти

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

Порівняння можливостей

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

Можливість	Nordlet	Xero API	QuickBooks API	Sage	Odoo
Архітектура API-first (функціональна відповідність додатку та API)	Так	Ні (UI-first)	Ні (UI-first)	Частково	Частково
Незмінна головна книга (double-entry ledger)	Так	Не підтверджено публічно	Не підтверджено публічно	Не підтверджено публічно	Не підтверджено публічно
ПДВ країн ЄС із перевіркою VIES	Так	Частково	Обмежено	Невідомо	Частково
Генерація реєстру i.SAF (Литва)	Так	Невідомо	Невідомо	Невідомо	Невідомо
Типізовані SDK (вкл. TypeScript)	Так	Здебільшого сторонні	Здебільшого сторонні	Невідомо	Невідомо
Підтримка ключа ідемпотентності	Так	Не підтверджено публічно	Не підтверджено публічно	Невідомо	Невідомо
Вебхуки фінансових подій у реальному часі	Так	Обмежено	Обмежено	Обмежено	Так
Експорт SEPA pain.001	Так	Через додатки	Не підтверджено публічно	Невідомо	Так
Кілька компаній в одному акаунті, RBAC	Так	Кілька організацій (окремо)	Кілька організацій (окремо)	Так	Так
Блокування періоду	Так	Так	Так	Так	Так
Вхід без пароля (passwordless)	Так	Не стандартно	Не стандартно	Не стандартно	Не стандартно

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

Проблема вивірки, про яку ніхто не попереджає

Кожен засновник маркетплейса, з яким ми спілкувалися, недооцінює вивірку виплат. Ось як це виглядає на практиці.

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

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

Розумне зіставлення та вивірка рахунків в один клік від Nordlet створені саме для вирішення цієї проблеми. Xero може робити це за допомогою доповнень. Інтеграції QuickBooks зазвичай вимагають проміжного програмного забезпечення (middleware), як тільки обсяги перевищують кілька тисяч транзакцій на місяць.

ПДВ: чому більшість маркетплейсів недооцінюють обсяг роботи

ПДВ в ЄС для маркетплейсів - це дійсно складно, і не тому, що правила незрозумілі. А тому, що їх багато і вони взаємодіють між собою.

Після реформ електронної комерції 2021 року та правил умовному постачальнику (deemed supplier) для маркетплейсів, платформа може вважатися постачальником з метою оподаткування ПДВ для певних операцій, навіть якщо вона не володіє товаром юридично. Це означає, що сам маркетплейс має зобов'язання з ПДВ щодо базового продажу, а не лише щодо своєї комісії. Звіти OSS, IOSS для товарів вартістю до 150 євро з-за меж ЄС, пороги реєстрації в кожній країні, зворотне нарахування для послуг B2B, перевірка VIES для транскордонних B2B-операцій: усе це має бути бездоганним і відображатися в головній книзі з моменту реєстрації транзакції, а не реконструюватися наприкінці кварталу.

Бухгалтерський API, який дає вам поле vat_rate і вважає справу виконаною, провалить ваш перший аудит. Вам потрібна логіка для кожної країни, перевірка VIES для ПДВ-номера клієнта в момент транзакції та автоматична генерація локальних форматів звітності (i.SAF у Литві, варіанти SAF-T в інших країнах).

Це та сфера, де створені нещодавно в ЄС інструменти категорії API-first суттєво випереджають старі міжнародні продукти. Регуляції настільки близькі до реалій, що команди, які пишуть це програмне забезпечення, самі живуть у цьому середовищі.

Що б ми зробили насамперед

Якби ми завтра запускали маркетплейс в ЄС і обирали бухгалтерську інфраструктуру, послідовність була б такою:

1. Спершу нанесіть на карту свої податкові ризики щодо ПДВ (VAT exposure), а не наприкінці. Перерахуйте кожну країну, куди ви продаватимете товари в перший рік, чи є транзакції B2B або B2C, і чи застосовуються правила умовного постачальника. Це покаже, що саме має обробляти бухгалтерська система.
2. Протестуйте головну книгу та процес вивірки в пісочниці (sandbox). Не виставлення рахунків. Згенерувати інвойс може будь-хто. Пропустіть через пісочницу тижневий обсяг реалістичних транзакцій і подивіться, що відбувається на кінець місяця.
3. Перевірте контракт API на предмет ідемпотентності та вебхуків. Якщо ви не можете безпечно повторити запит або підписатися на зміни станів, ви будуєте тендітну інфраструктуру.
4. Поговоріть з тим, хто реально закриватиме ваші фінансові звіти. Якщо ваш бухгалтер не може отримати потрібні йому звіти в необхідному форматі, автоматизація вищого рівня не має жодного значення.
5. Оберіть вендора, на чию дорожню карту ви можете впливати. Для маркетплейса на ранній стадії це важливіше, ніж проставлення галочок навпроти кожної функції сьогодні. Умови дизайну-партнерства існують не просто так.

FAQ

Чи дійсно мені потрібна подвійна бухгалтерія, чи достатньо звичайної таблиці транзакцій?

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

Чи можу я просто використовувати звітність Stripe замість бухгалтерського API?

Stripe - це платіжний провайдер. Його звітність підходить для звірки операцій усередині Stripe. Він не веде подвійну бухгалтерію, не обробляє доходи поза Stripe і не створює обов'язкову регламентовану звітність. Використовуйте його в парі з бухгалтерським API, а не замість нього.

Як працювати з кількома країнами без реєстрації скрізь?

Для продажу товарів і послуг B2C у межах ЄС схема „Один вікно“ (OSS) дозволяє подавати єдину декларацію в одній країні для продажів по всьому блоку до певних лімітів і з певними винятками. Ваш бухгалтерський API має правильно класифікувати кожну транзакцію, щоб декларація OSS була точною. Це питання функціональних можливостей, а не обхідних шляхів.

Чи є бухгалтерське ПЗ класу API-first надмірністю для невеликого маркетплейса?

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

Що станеться, якщо вендор змінить свій API?

Запитайте про політику застарівання (deprecation), версіонування та те, як вони обробляють критичні зміни (breaking changes), ще до підписання договору. Будь-який серйозний продукт категорії API-first повинен мати чітку відповідь. Якщо її немає - це теж відповідь.