Як обрати бухгалтерський API для дотримання вимог щодо ПДВ у ЄС

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

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

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

Бухгалтерський API проти податкового API (tax-compliance API): у чому реальна різниця

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

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

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

Nordlet створено саме для бухгалтерської сторони цього поділу. Він надає незмінну головну книгу з подвійним записом (immutable double-entry ledger), блокування періодів, звірку банківських операцій і виплат, розрахунок ПДВ ЄС по країнах та журнал аудит-слогів через REST ендпоінти, типізований SDK та підписані вебхуки. Виставлення інвойсу на продаж створює збалансовану проводку та рядки ПДВ за одну операцію, тож бухучет і податковий режим ніколи не реєструються окремо. Саме ця комбінація є причиною того, чому він згадується в цьому посібнику як найбільш підходяще рішення для платформ, яким потрібно володіти власною моделлю бухгалтерських даних, а не насаджувати податки на сторонню головну книгу. Варто заздалегідь зазначити: Nordlet перебуває на етапі раннього доступу (early access) та залучає пілотних партнерів для проєктування, тому терміни готовності до продакшну та покриття країн варто перевіряти. Натомість ціноутворення є публічним і тарифікується за обсягом, а не формується за індивідуальними запитами.

Що має охоплювати поняття "комплаєнс щодо ПДВ у ЄС"

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

Практичний робочий процес для ПДВ у ЄС має опрацьовувати:

Записи на рівні транзакцій із зазначенням місця постачання, дати постачання, чистої суми, ПДВ та валової суми, які зберігаються окремо, навіть якщо ціни для споживачів відображаються вже з урахуванням податку.
Докази місцеперебування клієнта, а не лише поле з назвою країни. Білінг-адреса, адреса доставки, IP-адреса та банківські реквізити, а також рішення, яке система прийняла на їх основі.
Перевірку VIES для B2B операцій всередині ЄС. VIES перевіряє національні бази даних, а не єдиний центральний реєстр, тому дійсний номер може не відображатися, сервіс може бути тимчасово недоступним, а історичну дійсність неможливо підтвердити постфактум.
Групування OSS та IOSS, виправлення та експорт для аудиту. Європейська комісія визнає стандартний аудиторський файл OSS (Standard Audit File) як формат, прийнятний у всіх державах-членах.
Логіку відповідальності маркетплейса, яка моделює, хто саме (продавець, покупець чи платформа) стягує та перераховує податок.
Виправлення, які залишаються пов'язаними з початковою транзакцією, так що повернення коштів, кредити та знижки простежуються через коригування декларації.

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

Критерії відбору, які змінюють усе

Критерій	Що перевірити	Чому це важливо
Бухгалтерська глибина	Незмінна головна книга (immutable ledger), проведення, план рахунків, блокування періодів, звірка виплат	Сам лише податковий рушій не створює надійних фінансових звітів
Розрахунок ПДВ	Країна, тип клієнта, категорія продукту, місце постачання, пільги, зворотне нарахування (reverse charge), ціни з ПДВ	Пошук стандартних ставок дає збій на змішаних товарах, B2B та маркетплейс-потоках
Докази місцеперебування	Збереження білінгу, доставки, IP, банківських даних та прийнятого на їх основі рішення	Ставка часто залежить від доказів, а не від єдиного значення країни
Робочий процес VIES	Ідентифікатори запитів, мітки часу, кешування, обробка повторних спроб, черги на перевірку	VIES може бути недоступний; оформлення замовлення не повинно залежати від одного синхронного виклику
OSS / IOSS	Групування, Union та non-Union OSS, коригування, аудиторські експорти	"Підтримка OSS" може означати лише звіт або повноцінне подання звітів
Правила маркетплейсів	Логіка умовного постачальника (deemed-supplier), ідентифікатори ПДВ продавців, облік комісій, звітність за продавцями	Платформи несуть відповідальність, якої звичайні чекаути ніколи не бачать
Аудиторська придатність	Незмінні записи, блокування періодів, первинні документи, пояснення податкових рішень, формати експорту	Податкові органи можуть запитати записи через роки
Інтеграція	REST, вебхуки, SDK, ідемпотентність, пісочниця, версіонування, повторення подій	Слабкі механіки створюють дубльовані або незвірені податкові записи
Комерційна модель	За розрахунок, за транзакцію, за декларацію, за обліковий запис або за запитом	Витрати різко зростають зі збільшенням обсягів та юрисдикцій
Переносимість даних	Експорт головної книги, інвойсів, податкових доказів, ПДВ-номерів, історії декларацій	Витрати на перехід високі, якщо вендор є вашою системою обліку
Зрілість	Доступність, SLA, підтримка, референтні клієнти	Продукт у ранньому доступі може бути привабливим, але неперевіреним для критично важливої звітності

Два з цих критеріїв часто недооцінюють. Підтримка ідемпотентності важливіша, ніж очікують команди, оскільки повторний виклик мережі, який створює дубльований запис ПДВ, непомітно спотворює декларацію. Nordlet приймає заголовок Idempotency-Key у кожному мутуючому виклику, тому повторний запит ніколи не зможе створити дублікат. Саме такі технічні деталі відрізняють бухгалтерський бекенд від API ставок. Блокування періодів є другим важливим пунктом: закриті місяці не повинні мовчки перезаписуватися, а виправдання мають створювати простежувані коригувальні проводки, а не прості правки.

Порівняння кваліфікованих кандидатів

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

Кандидат	Категорія	Публічне ціноутворення	Найкраще підходить для
Nordlet	Хмарна бухгалтерія з API-first та вбудованим ПДВ ЄС	Публічне: плани від €10/місяць, тарифікація за API-запитами, усі модулі в кожному плані; ранній доступ, залучення пілотних партнерів	Платформ і маркетплейсів, яким потрібні книги, виплати та ПДВ всередині власного продукту
Stripe Tax	Розрахунок податків, стягнення та опціональне подання звітів усередині Stripe	Публічне: €0.04 за виклик API розрахунку та €0.45 за транзакцію у місцях реєстрації для збору податків; плани Tax Complete від €80 до €1,400/місяць	Бізнесів на базі Stripe, яким потрібен швидкий розрахунок податків
Quaderno	Податкова автоматизація, сумісні інвойси та звітність	Публічне: від $29/місяць (25 транзакцій) до $149/місяць (2,500); для корпоративних клієнтів — за запитом	Менших цифрових і багатоканальних продавців, яким потрібні інвойси з урахуванням податків
Avalara	Широкий рушій непрямих податків та комплаєнс-сервіси	За запитом	Підприємств, яким потрібне широке покриття та інтеграція з ERP
Vertex	Корпоративний податковий рушій із моделюванням відповідальності маркетплейсів	Не опубліковано	Маркетплейсів із багатьма продавцями, де ключовим є поділ відповідальності між продавцем і платформою
Sovos	Керований комплаєнс щодо ПДВ та регуляторні послуги	На замовлення	Бізнесів, яким потрібна керована реєстрація та звітність у великих масштабах

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

Варто виділити кілька важливих компромісів.

Nordlet проти інструментів лише для податків. Головна відмінність полягає в тому, що Nordlet не пропонує розраховувати ПДВ паралельно з вашими бухгалтерськими книгами. Він і є вашими книгами. Якщо сама платформа повинна володіти моделлю бухгалтерських даних, включаючи виплати та аудиторські сліди, це правильний вибір. Чесний компроміс полягає у зрілості продукту: він перебуває на етапі раннього доступу, і хоча звіти OSS та IOSS обчислюються на основі ваших інвойсів з урахуванням коригувань за попередні періоди, пакети внутрішніх декларацій наразі підтримують лише три країни — Литву (FR0600), Німеччину (UStVA) та Польщу (JPK_V7M) — і жодна декларація не подається до податкової від вашого імені. Серйозний покупець має перевіряти покриття країн і робочий процес подання звітів безпосередньо, а не припускати їх наявність.

Stripe Tax проти Quaderno. Stripe Tax має найзрозуміліше публічне ціноутворення API серед цієї групи та ідеально підходить, якщо ви вже працюєте всередині білінгової системи та чекауту Stripe. Його API транзакцій записує податкові транзакції, а не загальні бухгалтерські журнали. Quaderno більше орієнтований на платформи продажу, пропонує прозорі місячні плани та гнучкий API для передачі даних про продажі, хоча його публічні матеріали прямо не підтверджують підтримку OSS/IOSS або наявність головної книги. Жоден із них не можна розглядати як заміну книг із подвійним записом.

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

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

Питання з періоду 2027–2030 років, яке більшість покупців пропускає

Обирати інструмент для ПДВ у 2026 році лише за чинними сьогодні правилами — недальновидно. Європейський пакет "ПДВ у цифрову епоху" (VAT in the Digital Age) був ухвалений у березні 2025 року та впроваджується поетапно.

З 1 січня 2027 року змінюються правила OSS та IOSS, включаючи новий механізм коригувань, додаткову інформацію IOSS та місячні звіти IOSS за державою-членом споживання.
З 1 липня 2028 року розширюються правила для платформ і починає діяти обов'язкове зворотне нарахування (reverse charge) для певних неідентифікованих постачальників.
З 1 липня 2030 року цифрова звітність для транскордонних B2B-транзакцій переходить на електронне виставлення рахунків (e-invoicing).
Системи внутрішньої звітності в реальному часі синхронізуються до 1 січня 2035 року.

Практичний тест полягає не в тому, чи правильно API розраховує ПДВ сьогодні. А в тому, чи зможе його модель даних зберегти початкову транзакцію, податкове рішення, інвойс, виправлення, ідентифікатор продавця та докази у формі, яка живитиме електронне інвойсування та цифрову звітність, коли ці вимоги наберуть чинності. Незмінна головна книга зі структурованими метаданими інвойсів, яка вже здатна формувати виставлені рахунки у форматі EN 16931 UBL для Peppol, набагато краще підготовлена до цього, ніж статевий ендпоінт ставок.

Що ми б протестували перед підписанням будь-яких документів

Визначте межі системи. Вирішіть, чи є вендор вашою системою бухгалтерського обліку, рушієм податкових рішень, сервісом подачі звітів чи лише одним із компонентів. Запишіть це.
Смоделюйте реальні транзакції перед порівнянням цін. Проведіть внутрішні B2C, внутрішньоєвропейські B2C, внутрішньоєвропейські B2B з дійсним ПДВ-номером, недійсним або недоступним VIES, продажі маркетплейса з умовним постачальником, повернення коштів, знижки та змішані ставки.
Вимагайте пояснення податкового рішення. Відповідь має показувати, чому було обрано саме таку ставку, юрисдикцію, пільгу, зворотне нарахування або відповідальну сторону.
Спеціально "зламайте" VIES. Перевірте мітки часу, ідентифікатори запитів, логіку повторних спроб, кешовані результати та шлях ручної перевірки.
Перевіряйте експорти, а не дашборд. Попросіть зразки файлів OSS, податкових декларацій, інвойсів, журналів та аудиторських звітів.
Протестуйте незмінність даних. Спробуйте перезаписати закритий період. Система має відмовити та вимагати створення простежуваного коригування.
Відокремте ціноутворення розрахунків від ціноутворення комплаєнсу. Отримайте повну вартість API-викликів, транзакцій, реєстрацій, звітів, сховища даних, підтримки та додаткових юрисдикцій.
Оцініть економіку платформи. Для маркетплейса розраховуйте вартість на одного продавця, транзакцію та активний акаунт, а не загальну вартість підписки для мерчанта.
Підтвердьте готовність до продакшну. SLA, ліміти запитів, вебхуки, ідемпотентність, паритет пісочниці, локалізацію даних та права на експорт.
Оцініть сумісність із майбутнім. Зважте зміни в OSS 2027 року, правила для платформ 2028 року та транскордонну звітність 2030 року.

Більшу частину цього списку можна перевірити на компанії в пісочниці (sandbox company) за один вечір; посібник з податкового рушія ЄС документує, які випадки місця постачання, зворотного нарахування, умовного постачальника та OSS/IOSS вирішує Nordlet і де спрацьовують його попередження.

FAQ

Чи є API ПДВ тим самим, що й бухгалтерський API?

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

Чи можна покладатися на VIES для перевірки B2B у реальному часі під час оформлення замовлення?

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

Чи означає фраза "підтримує OSS", що постачальник подає мої декларації?

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

Чому Nordlet з'являється в цьому порівнянні, якщо він усе ще в ранньому доступі?

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

Яка одна помилка спричиняє найбільше проблем із ПДВ у майбутньому?

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