Nordlet

← Блог

Автоматизація звітності з ПДВ за країнами та перевірки VIES

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

Nordlet Team · · 12 хв читання

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

У цьому посібнику розглядається те, як автоматизувати звітність з ПДВ за країнами та перевірку VIES за допомогою хмарного API бухгалтерського обліку, використовуючи API бухгалтерського обліку Nordlet як контекст для реалізації. Метою є створення системи, яка фіксує належні докази в момент продажу, створює незмінні записи в головній книзі (ledger entries) та формує готові до звітності дані, згруповані за схемами та державами-членами, без необхідності повторного збору підсумків у таблицях Excel пізніше.

Що насправді повідомляє VIES, а що ні

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

Вона не встановлює право на звільнення від оподаткування внутрішньоспільнотних постачань. Європейська Комісія заявляє про це чітко. Дійсна відповідь VIES є лише одним із кількох доказів. Вам усе одно потрібно підтвердити, що клієнт є фактичним отримувачем, що постачання кваліфікується як внутрішньоєвропейське, що існують докази транспортування або відправлення, і що рахунок-фактура містить необхідне формулювання щодо перенесення податкового зобов'язання (reverse-charge).

Тому перше проєктне рішення є структурним: зберігайте статус VIES та режим оподаткування ПДВ в окремих полях. Ніколи не пов'язуйте viesStatus: valid безпосередньо з zeroRated: true. Щойно ви об'єднаєте ці два поняття, ви втратите можливість захистити обраний режим, якщо виникнуть сумніви щодо доказів.

Передумови перед написанням коду інтеграції

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

  • Країни, в яких підприємство зареєстроване або має постійні представництва
  • Країни, в яких воно має реєстрацію платника ПДВ
  • Здійснює воно продаж товарів, послуг, цифрових послуг чи їх суміші
  • Чи є транзакції операціями B2B, B2C або обома варіантами
  • Чи використовує воно внутрішні реєстрації, схеми OSS, IOSS, реверсне обкладання (reverse charge) чи правила маркетплейсу щодо уповноваженого постачальника (deemed-supplier)
  • Які вихідні дані має формувати API: дані внутрішньої звітності, дані OSS/IOSS, регістри рахунків-фактур, такі як i.SAF у Литві, виключно проводки в головній книзі або корисне навантаження (payloads) для стороннього провайдера подання звітності

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

Також не варто жорстко прописувати (hard-code) одну ставку ПДВ для кожної країни. В ЄС існують стандартні, знижені, надзвичайно знижені, проміжні, нульові ставки та спеціальні режими для конкретних товарів, і вони змінюються. Надійним джерелом інформації про конкретний товар у конкретній державі-члені є податковий орган цієї країни, а база даних TEDB Єврокомісії пропонує загальний огляд по країнах. Зберігайте джерело та версію, на основі яких було прийнято рішення щодо кожної ставки, щоб подальше оновлення таблиці ставок не переписало непомітно те, як виглядає стара транзакція.

Моделювання податкового рішення, а не лише ставки

Основою надійної інтеграції є шар податкових категорій, розташований між продуктами та ставками. Зіставте продукти з категоріями, категорії — з податковими кодами конкретної країни, а потім — зі ставками, що діють у певний період:

product/service
    → tax category
    → country-specific tax code
    → effective-dated rate and treatment

Небезпечним підходом, що призводить до розбіжностей у звітності, є схема product SKU → 21% VAT. Той самий продукт має різні ставки в різних країнах, а ставка може змінюватися посеред звітного періоду. Власні рекомендації Nordlet щодо дотримання вимог щодо ПДВ рекомендують саме таке мапування на основі категорій, а не пряму прив'язку продуктів до відсотків.

Ваша таксономія податкових категорій має бути стабільною та внутрішньою: товари за стандартною ставкою, товари за зниженою ставкою, послуги, що постачаються в електронній формі, звичайні послуги, звільнені від оподаткування постачання, постачання за нульовою ставкою, внутрішньоєвропейський B2B реверс-подáток (reverse charge), внутрішньоєвропейський дистанційний продаж, імпорт за IOSS, операція з уповноваженим постачальником (deemed-supplier). Усе подальше опрацювання спирається на цю таксономію.

Перевірка VIES як асинхронний робочий процес збору доказів

Офіційний сервіс VIES надає SOAP/WSDL інтерфейс, який приймає дволітерний код країни та номер ПДВ. Документовані збої в його роботі мають значення для обробки помилок: недійсні вхідні дані, глобальні ліміти та ліміти паралельних запитів держав-членів, недоступність сервісу, недоступність систем держави-члена та тайм-аути. Розглядайте їх як окремі результати, а не як єдину категорію „невдалих“ запитів.

Робочий процес, який витримує навантаження та перевірки аудідиторів, виглядає так:

  1. Нормалізуйте ідентифікатор ПДВ: переведіть префікс у верхній регістр, видаліть дозволені пробіли або розділові знаки, а початкове значення, введене користувачем, зберігайте окремо.
  2. Перевірте код країни та структуру номера локально, перш ніж виконувати мережевий виклик.
  3. Надішліть нормалізований номер до VIES.
  4. Збережіть нормалізований ідентифікатор, позначки часу запиту та відповіді, стан valid/invalid/not-processed, необроблену відповідь (raw response), будь-яку помилку сервісу, ідентифікатори клієнта та рахунка-фактури, а також рішення системи.
  5. Кешуйте успішні результати протягом визначеного, документованого періоду часу.
  6. Повторюйте тимчасові технічні збої із застосуванням експоненційної затримки (backoff).
  7. Скеруйте невирішені або суперечливі випадки на ручну перевірку.
  8. Повторюйте перевірку, якщо кешований результат застарів або перед проведенням транзакції, де наявність доказів є критичною.

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

Критичне правило: не робіть процес оформлення замовлення (checkout) синхронним із VIES. Збій у роботі сервісу не означає, що номер недійсний. Якщо під час продажу виникає тайм-аут VIES, затримайте транзакцію для перевірки або призначте їй тимчасовий стан. Блокування оформлення замовлення через час безвідмовної роботи сервісу Єврокомісії генерує запити до підтримки, а помилкове визначення надійного клієнта як недійсного є ще гіршим сценарієм.

Відокремлення статусу перевірки від податкового режиму

Отримавши результат VIES, рушій прийняття рішень має виконати додаткову роботу. Зберігайте такі дані в окремих полях:

{
  "viesStatus": "valid",
  "vatTreatment": "intra_eu_b2b_reverse_charge",
  "evidenceStatus": "reviewed",
  "placeOfSupply": "DE"
}

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

Створення незмінного податкового рішення на момент виставлення рахунка-фактури

Під час створення рахунка-фактури зберігайте повне рішення разом із ним, а не лише кінцеву ставку:

invoice
  ├─ line tax category
  ├─ place of supply
  ├─ VAT scheme
  ├─ country-specific rate
  ├─ rate-table version
  ├─ VIES evidence reference
  ├─ location-evidence references
  ├─ legal-basis reference
  └─ marketplace-role flags

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

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

Проводки, вебхуки та ідемпотентність

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

Dr Accounts receivable / payment clearing
    Cr Revenue
    Cr VAT payable - DE - domestic

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

Керуйте змінами стану за допомогою вебхуків, а не опитування (polling). Nordlet надсилає події, такі як sale_invoice.paid, підписує доставку та повторює спроби у разі збоїв із затримкою. Надайте кожному запису детермінований ключ ідемпотентності:

sale:{platform_order_id}:invoice:{invoice_version}

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

Групування для OSS та створення готових до звітності експортів

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

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

Кілька операційних деталей, на яких часто роблять помилки:

  • Звітні періоди для схем Union та non-Union OSS є квартальними; для IOSS — місячними. Звіти та платежі мають бути подані до кінця наступного місяця.
  • Нульова звітність вимагається за кожен період, навіть якщо жодних відповідних постачань не здійснювалося. Створіть контрольний список періодів і генеруйте нульовий звіт автоматично.
  • Звіти OSS складаються в євро із використанням довідкового курсу ЄЦБ на останній день податкового періоду, якщо потрібна конвертація. Зберігайте вихідну валюту, курс обміну, дату курсу, конвертовану суму та метод.

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

Будьте точними щодо того, що саме надає API. Nordlet обчислює звіти OSS та IOSS на основі рахунків-фактур і головної книги, включно з виправленнями за попередні періоди, формує пакети внутрішньої звітності для Литви (FR0600), Німеччини (UStVA) та Польщі (JPK_V7M), а також генерує готові для VMI регістри i.SAF для Литви. Це і є дані, готові до звітності. Один виклик API не подає декларацію з ПДВ кожної країни через кожен національний шлюз, і жоден звіт не надсилається до податкового органу від вашого імені. Зберігайте бухгалтерський облік, формування звітності, експорт, надсилання через шлюз та підтвердження оплати як окремі стани у своїй системі. Посібник з податкового рушія ЄС документує випадки, які вирішує рушій, і те, де спрацьовують його попередження.

Блокування періоду

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

Поширені типи збоїв та способи їх уникнення

Тип збою Чому це відбувається Заходи запобігання
Розгляд дійсного результату VIES як достатнього для застосування нульової ставки VIES не підтверджує право на звільнення від податку Зберігайте докази щодо клієнта, постачання, транспортування та рахунка-фактури разом із результатом
Розгляд недійсного результату як доказу відсутності реєстрації Номер може бути не активований для торгівлі всередині ЄС, або база даних може затримувати оновлення Розрізняйте недійсні результати, необроблені та технічні збої; спрямовуйте спірні випадки на перевірку
Здійснення перевірки на етапі оформлення замовлення (checkout) синхронно з VIES Ліміти паралельних запитів, тайм-аути, збої в роботі Асинхронна перевірка, короткострокове кешування, експоненційна затримка, тимчасові стани
Нескінченне кешування результатів Статус реєстрації та активації змінюється Зберігайте мітки часу та термін дії; повторно перевіряйте перед виставленням рахунка, якщо дані застаріли
Пряме зіставлення продуктів із відсотками ПДВ Ставки та звільнення залежать від країни та дати Продукт → категорія → код країни → ставка з урахуванням терміну дії
Реконструкція OSS за допомогою таблиць Підсумки не містять виправлень, країн відправлення, доказів Розраховуйте на основі незмінної головної книги з вимірами для кожної проводки
Включення послуг внутрішніх представництв до OSS Певні послуги належать до внутрішньої звітності Моделюйте представництва окремо, спрямовуйте за схемами до агрегації
Пропуск нульової звітності OSS вимагає звітування за кожен період Створіть контрольний список і автоматично генеруйте нульові звіти
Редагування закритих рахунків-фактур для виправлення Зруйнування зв'язку між поданням звіту та виправленням Використовуйте кредитові ноти та сторнувальні проводки в наступному періоді

З чого ми б почали в першу чергу

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

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

FAQ

Чи означає річна відповідь VIES можливість застосування нульової ставки до внутрішньоєвропейського B2B-продажу?

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

Чи повинна перевірка VIES блокувати оформлення замовлення (checkout)?

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

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

Він може генерувати готові до звітності дані, згруповані за схемами та державами-членами, розраховані на основі незмінної головної книги з урахуванням виправлень. Чи здійснюється також подання через кожен національний податковий шлюз, залежить від продукту та країни. Nordlet обчислює звіти OSS та IOSS, постачає пакети внутрішньої звітності для Литви, Німеччини та Польщі, а також генерує готові до VMI регістри i.SAF для Литви, але він не надсилає жодних документів до податкового органу від вашого імені. Розглядайте бухгалтерський облік, формування звітів, експорт, надсилання через шлюз та оплату як окремі стани, а не припускайте, що один виклик подає звітність скрізь.

Як обробляти виправлення після блокування періоду?

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

Подальше читання