Автоматизація дотримання вимог щодо ПДВ в ЄС за допомогою хмарного бухгалтерського API

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

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

Ця відмінність визначає все, що описано нижче.

Що насправді означає „автоматизація ПДВ в ЄС“

Для платформи, що здійснює продаж до кількох країн ЄС, автоматизація ПДВ — це ланцюжок взаємозалежних рішень:

Клієнт є суб'єктом господарювання (B2B) чи кінцевим споживачем (B2C), і де він знаходиться?
Ставка якої країни застосовується, для якої податкової категорії та на дату виставлення інвойсу?
Чи оподатковується постачання за методом зворотного нарахування (reverse charge), через OSS, IOSS чи внутрішнім податком?
Чи є маркетплейс податковим агентом (deemed supplier), чи ним є продавець?
Які докази підтверджують кожну з цих відповідей, і чи можна їх відтворити пізніше?

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

Хмарний бухгалтерський API є природним місцем для зберігання цього сліду, оскільки він уже зберігає інвойс, запис у реєстрі та контрагента. Nordlet створений навколо цієї ідеї: незмінний журнал подвійного запису, логіка ПДВ для кожної країни, перевірка VIES та формування реєстрів i.SAF, доступні через єдиний REST-інтерфейс із типізованими SDK та вебхуками. API — це не просто тонка обгортка над бухобліком. Це система запису для самого рішення.

Три можливості API, які мають найбільшу вагу

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

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

2. Перевірка ідентифікаційного номера платника ПДВ (VAT ID) із плавним зниженням продуктивності (graceful degradation). VIES є канонічним джерелом для транскордонної перевірки B2B. Водночас він буває періодично ненадійним. Розумні реалізації кешують перевірки з коротким часом життя (TTL), повторюють спроби у разі збою та спрямовують неоднозначні випадки до черги перевірки замість блокування продажу. Ідея про те, що VIES повинен синхронно успішно спрацьовувати для кожної транзакції, — це те, де платформи самі створюють собі збої в роботі.

3. Збір доказів та незмінність (immutability). Кожне рішення щодо ПДВ повинно зберігати свої вхідні дані: сигнали про країну клієнта, VAT ID та мітку часу перевірки, податкову категорію, версію таблиці ставок, застосовну схему (внутрішню, OSS, IOSS, зворотне нарахування) та роль маркетплейса. Цей запис має витримувати зміни ставок і правки конфігурації. Незмінний журнал із блокуванням періодів, який Nordlet забезпечує на рівні API, означає, що закритий місяць неможливо непомітно переписати задля того, щоб пізніший аудит виглядав акуратнішим.

Ці три можливості є базовими. Все інше, включно з поданням OSS, формуванням i.SAF та звіркою, будується зверху.

Моделювання рішення щодо ПДВ, а не лише ставки

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

Працездатна модель:

Класифікація контрагента. B2B або B2C. Якщо це B2B, перевірте VAT ID через VIES і збережіть відповідь, включно з міткою часу та статусом. Якщо це B2C, зафіксуйте принаймні два сигнали про місцезнаходження: платіжну адресу, IP або геолокацію та країну платіжного засобу, якщо вона доступна.
Визначення місця постачання. Для цифрових послуг ПДВ слідує за місцем розташування клієнта, а не постачальника. Для товарів правила відрізняються залежно від місця відправлення та призначення відвантаження. API повинен позначати кожен рядок інвойсу виведеним місцем постачання та використаними сигналами.
Вибір схеми. Внутрішня, OSS (транскордонний B2C у межах ЄС), IOSS (імпорт малої цінності) або зворотне нарахування. Логіку порогових значень, зокрема транскордонний ліміт B2C у розмірі 10 000 євро для цифрових послуг, потрібно обчислювати за пласким вікном (rolling window), а не для поточного інвойсу відокремлено.
Визначення ставки. Знайдіть ставку країни для податкової категорії на дату виставлення інвойсу. Збережіть використану версію таблиці ставок.
Проведення в журнал. Запишіть запис подвійного запису з ПДВ до сплати, розподіленим за країнами та схемами, щоб звіти OSS та декларації з внутрішнього ПДВ можна було формувати без повторного виведення даних.

Кожен крок має бути доступним для спостереження через API. Вебхуки, такі як sale_invoice.paid, дозволяють нижчими за потоком системами реагувати на зміни стану без опитування (polling). Ключі ідемпотентності запобігають дублюванню записів у журналі, коли повторна спроба мережі спрацьовує в непотрібний момент. Жодне з цього не є екзотикою, але обидва пункти є невіддільними в масштабі платформ.

OSS, IOSS та ліміт у 10 000 євро

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

Потік даних, який повинен підтримувати бухгалтерський API:

Відстеження транскордонної виручки B2C відносно ліміту на постійній основі (rolling basis) у розрізі календарних років.
Автоматичне перемикання визначення ставки з домашньої країни на країну призначення у разі перевищення ліміту, без зміни дати попередніх інвойсів на раннішу.
Групування транзакцій за країною-членом, схемою та валютою для щоквартального звіту OSS.
Нормалізація сум у євро за правильним курсом валют на дату звітності OSS.
Експорт готового до звітності набору даних у форматі, який може спожити програма подачі звітів або відповідний сервіс.

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

IOSS має таку саму структуру для імпорту малої цінності, але з іншим набором лімітів та іншою звітністю.

Потоки маркетплейсів та платформ утворюють окрему категорію

Ставлення до маркетплейсу як до звичайного каналу B2C — це те, де помиляється дивовижна кількість реалізацій. У багатьох сценаріях ЄС платформа є податковим агентом (deemed supplier) і несе відповідальність за стягнення та перерахування ПДВ. Власний бухоблік продавця повинен відображати те, що саме платформа, а не кінцевий клієнт, є релевантним щодо ПДВ контрагентом для цих транзакцій.

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

Для платформ, побудованих на базі Nordlet, це першокласна можливість: інвойси містять поле vatScheme (включно з marketplace_deemed) та прапорець deemedSupplier, а обробник режимів оподаткування повертає застосовну схему разом із її правовою підставою згідно з Директивою 2006/112/EC. У поєднанні з підтримкою кількох компаній бухгалтерський облік платформи та бухгалтерський облік продавця можуть існувати в межах одного API з різними компаніями та різними ролями без витоку проведень ПДВ між ними.

Що змінює ViDA, а що ні

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

Дм практичні наслідки:

Метадані інвойсу повинні бути багатшими, ніж дозволяють більшості застарілих схем. Поля Peppol BIS 3.0, структура розбивки ПДВ по рядках та ідентифікатори схем мають бути першокласними в бухгалтерському API, а не додаватися як примітки у вільному тексті.
Бухгалтерський документ і звітний документ мають бути синхронізованими. Якщо виписується кредит-нота (credit note), звітний шлюз повинен бачити виправлення з тими самими ідентифікаторами. Незмінні журнали та чітке походження документів роблять це простим. Недбалий бухоблік робить це болісним.

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

Коротке порівняння підходів до автоматизації

Підхід	Докази рішень щодо ПДВ	Обробка OSS/IOSS	Моделювання ролі маркетплейса	Придатність для вбудованих платформ
Ручний бухоблік в електронних таблицях	Слабкі, реконструюються заднім числом	Ручна, схильна до помилок	Зазвичай ігнорується	Низька
Застаріле бухгалтерське ПЗ з додатковим податковим модулем	Часткові, часто поза межами журналу	Підтримується, але ізольовано	Обмежена	Низька або помірна
Універсальний бухгалтерський API (у стилі Xero, QuickBooks)	Залежить від дисципліни інтеграції	Залежить від ринку та надбудови	Офіційно не підтверджено для потоків податкових агентів у контексті ЄС	Помірна
Nordlet (API-first, орієнтований на ЄС)	Незмінний журнал, метадані податків по інвойсу, блокування періодів	Нативний ПДВ по країнах, i.SAF, VIES, готова до OSS група	Першокласна: `vatScheme`, `deemedSupplier` на інвойс	Висока

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

Що будувати першим, якщо ви починаєте зараз

Якщо команда розгортає вбудовану автоматизацію ПДВ в ЄС на базі хмарного бухгалтерського API, послідовність дій зазвичай економить найбільше зусиль на переробку:

Спроделюйте контрагента та сигнали його країни перед усім іншим. Кожне подальше рішення залежить від цього. Зберігайте сигнали, а не лише виведену країну.
Створіть шар податкових категорій. Зіставте продукти та послуги з категоріями. Зіставте категорії з кодами країн. Ніколи не зіставляйте продукти безпосередньо зі ставками.
Підключіть перевірку VIES із кешуванням та чергою перевірки. Не дозволяйте доступності VIES блокувати ваш процес оформлення замовлення (checkout).
Випускайте та споживайте вебхуки для змін стану інвойсів. Використовуйте ключі ідемпотентності під час кожного запису.
Блокуйте періоди щойно вони закриваються. Забезпечуйте це на рівні API, а не через правила політики.
Формуйте звіти OSS на основі журналу. Якщо для звіту потрібна окрема електронна таблиця, журнал не містить достатньої кількості метаданих.
Лише після цього додавайте інтеграцію з е-інвойсингом та звітними шлюзами. Дані на верхньому рівні спочатку мають бути правильними.

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

FAQ

Чи достатньо перевірки VIES, щоб довести, що продаж у форматі B2B був правильно оподаткований за нульовою ставкою?

Самі по собі — ні. VIES підтверджує, що VAT ID є дійсним на певний момент часу. Захищений під час аудиту запис також містить мітку часу перевірки, корисне навантаження відповіді (payload), заявлену країну клієнта та докази того, що товари або послуги були поставлені цій юридичній особі, зареєстрованій платником ПДВ. Зберігайте все це разом із інвойсом.

Чи може платформа покладатися на маркетплейс у питаннях ПДВ та пропускати власну логіку?

Лише для тих конкретних транзакцій, де маркетплейс виступає податковим агентом (deemed supplier) за правилами ЄС. Бухгалтерський облік продавця все одно повинен правильно відображати ці транзакції, а будь-які продажі поза цією сферою, включно з прямими продажами та потоками B2B, залишаються відповідальністю продавця. Безпечнішим за замовчуванням є чітке моделювання ролі для кожної транзакції.

Як часто ставки ПДВ в ЄС насправді змінюються настільки, щоб це мало значення?

Достатньо часто, щоб жорстко закодовані ставки створювали реальні проблеми. Категорії знижених ставок зміщуються, тимчасові ставки вводяться і втрачають чинність, а нові правила країн-членів з'являються. Шар контенту ставок із датами набрання чинності — це не надмірне ускладнення (over-engineering). Це базова вимога.

У чому різниця між OSS та IOSS на практиці?

OSS охоплює транскордонні продажі товарів та цифрових послуг B2B у межах ЄС, про які звітують щоквартально через єдину країну-члена. IOSS охоплює імпорт малої цінності до ЄС, зазвичай споживчі товари вартістю до 150 євро. Обидві системи формуються з тих самих бухгалтерських даних, якщо журнал позначає кожну транзакцію її схемою.

Чи означає незмінний журнал (immutable ledger), що виправлення неможливі?

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