Якщо ваша компанія продає програмне забезпечення, послуги або фізичні товари клієнтам у Бельгії, Франції, Німеччині чи Польщі, ви вже зараз наближаєтеся до крайнього терміну дотримання нормативних вимог — і, на відміну від більшості податкових дедлайнів, цьому байдуже, чи чули ви про нього. Починаючи з 1 січня 2026 року, Бельгія вимагає структуровані електронні рахунки-фактури для внутрішніх B2B-транзакцій. Франція приєднується 1 вересня 2026 року. Система KSeF у Польщі впроваджується поетапно з лютого по квітень 2026 року. Мандат Німеччини набуває чинності у 2027 та 2028 роках. Жодна з цих країн не чекає, поки світовий стандарт наздожене їх, і жодна з них не звільняє іноземних продавців від обов’язків лише тому, що рахунок виставлено з Огайо, а не з Антверпена.
Для експортера зі США або SaaS-компанії "електронне виставлення рахунків" (e-invoicing) звучить як проблема бек-офісу, яку вирішить хтось інший. Це не так. Це законодавча вимога створювати рахунки у специфічному машинозчитуваному форматі, передавати їх через урядову мережу та доводити, що ви зробили це правильно — інакше ви зіткнетеся зі штрафами, які, принаймні в одній країні, можуть подвоїти ПДВ, який ви винні за одним рахунком.
Що насправді означає "електронне виставлення рахунків" (це не PDF)
Цей термін вводить в оману. Надсилання клієнту PDF-рахунку електронною поштою не є електронним виставленням рахунків у регуляторному розумінні — це лише цифрова копія паперового рахунку. Справжнє електронне виставлення рахунків означає:
- Структуровані формати даних: схеми на основі XML, такі як UBL (Universal Business Language), німецькі XRechnung або ZUGFeRD, французький Factur-X або польська схема FA(3) — формати, які комп'ютер може розібрати без участі людини.
- Очищення або передача через державну платформу: багато мандатів передбачають маршрутизацію рахунків через національні вузли (як KSeF у Польщі) або спільні мережі, такі як Peppol, яку Бельгія, Нідерланди, Швеція та Данія використовують як основний рівень передачі.
- Перевірка в реальному часі або майже в реальному часі: рахунок перевіряється, отримує унікальний реєстраційний номер і підтверджується до або під час здійснення транзакції, а не звіряється через тижні під час подання звітності.
Це пакет ЄС "ПДВ у цифрову епоху" (VAT in the Digital Age — ViDA), офіційно ухвалений у березні 2025 року, який зараз запроваджується країнами-членами. Загальноєвропейська вимога щодо цифрової звітності для транскордонних B2B-транзакцій повністю запрацює лише в липні 2030 року, але — і це момент, який застає американські компанії зненацька — окремі країни-члени мають право запроваджувати внутрішні мандати за роки до цього терміну. Бельгія, Франція, Німеччина та Польща саме це і зробили.
Дедлайни, які мають значення прямо зараз
Бельгія — 1 січня 2026 року. Усі компанії, зареєстровані як платники ПДВ у Бельгії, повинні виставляти та отримувати структуровані електронні рахунки для внутрішніх B2B-транзакцій через Peppol, згідно зі стандартом EN 16931 (стандартно використовується Peppol BIS у форматі UBL). Існує тримісячний період толерантності до 31 березня 2026 року, але він не є автоматичним — ви повинні довести, що вже вжили конкретних кроків для дотримання вимог до набрання чинності мандатом. Аргумент "ми про це не чули" не вважається таким кроком.
Франція — 1 вересня 2026 року. Кожна компанія, зареєстрована як платник ПДВ у Франції, з цієї дати повинна мати можливість отримувати електронні рахунки. Прийнятні формати включають UBL 2.1, UN/CEFACT CII та Factur-X (гібридний формат PDF/XML). Обов'язки щодо видачі рахунків будуть впроваджуватися поетапно залежно від розміру компанії невдовзі після цього. Недотримання вимог тягне за собою штраф у розмірі 15 євро за рахунок, з лімітом 15 000 євро на рік — це не катастрофічно для одного рахунку, але сума швидко зростає, якщо ваш процес виставлення рахунків систематично не відповідає вимогам для сотень клієнтів.
Польща — лютий та квітень 2026 року. Великі платники податків (з річним оборотом понад 200 млн злотих) повинні виставляти рахунки через платформу KSeF починаючи з 1 лютого 2026 року; усі інші платники ПДВ — з 1 квітня 2026 року; мікропідприємці мають час до 1 січня 2027 року. Польща надає річний пільговий період щодо штрафів до кінця 2026 року, але після його закінчення 1 січня 2027 року за рахунки, виставлені поза системою KSeF, загрожують штрафи до 100% від суми ПДВ, зазначеної в рахунку. Це не помилка. Якщо припуститися помилки, ви фактично можете подвоїти свою відповідальність з ПДВ за цією транзакцією.
Німеччина — 2027 та 2028 роки. Кожна німецька компанія повинна мати можливість отримувати електронні рахунки, що відповідають стандарту EN, з 1 січня 2025 року. Видача стає обов’язковою для компаній з оборотом понад 800 000 євро з 1 січня 2027 року, а для всіх інших — з 1 січня 2028 року. Застосовні формати — XRechnung та ZUGFeRD, згідно з тим самим стандартом EN 16931, що й у Бельгії.
Чому американська компанія не може просто ігнорувати це
Інстинктивно хочеться припустити, що американська компанія, яка виставляє рахунки за межами ЄС, якимось чином знаходиться поза зоною дії цих вимог. Це надто дороге припущення, щоб перевіряти його на практиці.
Якщо у вас є місцева юридична особа, мандат застосовується безпосередньо. Німецька дочірня компанія GmbH, французька SAS або бельгійська філія розглядаються точно так само, як будь-який місцевий бізнес — жодних винятків через наявність материнської компанії у США.
Якщо ви виставляєте рахунки транскордонно з американської компанії, правила стають більш розмитими та залежать від конкретної країни. Деякі юрисдикції перекладають тягар відповідності на компанію-отримувача, вимагаючи конвертувати та перевірити рахунок; інші вимагають від сторони, що відправляє — тобто від вас — відразу виставляти рахунок у відповідному форматі. Це саме той тип неоднозначності, який під час податкової перевірки завжди вирішується проти продавця.
Якщо ви продаєте цифрові послуги (SaaS, завантаження, підписки) споживачам у ЄС, ви вже несете відповідальність за ПДВ без жодної страховки. Для продавців з-поза меж ЄС не існує порогу мінімального доходу, який іноді мають малі підприємства в ЄС. З вашого першого продажу споживачу з ЄС ви зобов’язані нараховувати місцеву ставку ПДВ та сплачувати її — і все частіше це потрібно робити через відповідний канал електронного виставлення рахунків. Для іноземних продавців немає пільгового періоду на кшталт "ми надто малі, щоб про це турбуватися".
8-кроковий підхід до вирішення цього питання
Вам не потрібно одночасно виконувати вимоги кожної країни, але вам потрібна система, яка масштабується в міру того, як все більше країн запроваджують свої вимоги. Розумна послідовність дій:
- Проінвентаризуйте, звідки насправді надходить ваш дохід. Вивантажте рахунки-фактури за останні 12 місяців за країною виставлення рахунків клієнтам. Якщо з'являються Бельгія, Франція, Німеччина чи Польща — у вас є реальний дедлайн, а не гіпотетичний.
- Визначте свою юридичну присутність у кожній країні. Наявність місцевої юридичної особи означає безпосередню відповідність вимогам; продаж через кордон від імені американської компанії означає, що вам потрібно визначити, хто саме несе зобов'язання щодо форматування.
- Запитайте, чи може ваш інструмент для виставлення рахунків генерувати структуровані формати сьогодні. Якщо ваш поточний стек створює лише PDF-файли, це ваша перша прогалина — UBL, XRechnung, Factur-X та FA(3) не є функціями, які більшість стандартних інструментів для виставлення рахунків мають за замовчуванням.
- Перевірте, чи потрібен вам доступ до мережі Peppol. Якщо ви здійснюєте транзакції з контрагентами з Бельгії, Нідерландів, Швеції чи Данії, ймовірно, потрібне підключення до Peppol (безпосередньо або через постачальника точки доступу).
- Співвіднесіть дедлайни кожної країни з вашим фіскальним календарем, а не з календарним роком — дедлайн, що припадає на середину кварталу, змінює терміни, коли системи мають запрацювати, а не лише дату офіційного набрання законом чинності.
- Вирішіть: інтеграції «точка-точка» чи централізований хаб? Побудова окремого з'єднання для кожної країни працює для одного ринку. Це швидко стає неможливим, коли ви дотримуєтеся вимог у трьох або чотирьох юрисдикціях з різними форматами та правилами валідації.
- Призначте відповідального за постійний моніторинг нормативних вимог. Ці мандати постійно змінюються: формати переглядаються, періоди терпимості закінчуються, нові країни приєднуються. Правило, яке ви правильно впровадили в січні, може застаріти до кінця року.
- Виконайте тестовий рахунок через кожен необхідний канал до настання дедлайну, а не після. Виявлення відхилення формату на вашому першому реальному рахунку після набрання чинності мандатом — це дуже дорогий спосіб вивчити правила.
Як це пов'язано з вашим бухгалтерським обліком
Мандати на електронні рахунки-фактури — це, зрештою, проблема ведення обліку, яка маскується під податкову відповідність: кожен структурований рахунок, який ви видаєте або отримуєте, повинен чітко відповідати вашій головній книзі у форматі, який дозволить пройти аудит через роки. Компанії, які вже ведуть чіткі фінансові записи з контролем версій, швидше адаптуються до цих мандатів, оскільки найскладніше — це не створення одного сумісного XML-файлу, а доведення послідовного та аудиторського ланцюжка від рахунку до запису в книзі та подання ПДВ у кожній юрисдикції, з якою ви працюєте.
Цю проблему набагато легше вирішити, коли ваші книги не заблоковані у власному пропрієтарному форматі, для читання якого потрібне спеціальне програмне забезпечення.
Тримайте свої книги готовими до аудиту в міру ускладнення вимог
У міру того, як мандати на електронні рахунки-фактури поширюються на більшу кількість країн, компанії, що адаптуються найшвидше, — це ті, чиї фінансові записи вже є прозорими та легкими для звірки. Beancount.io забезпечує ведення обліку у форматі звичайного тексту, який повністю підлягає контролю версій та аудиту — кожна транзакція зберігається у форматі, який ви можете перевірити, порівняти (diff) та відстежити, без прив'язки до постачальника та «чорних скриньок» між вашими рахунками та головною книгою. Почніть безкоштовно і дізнайтеся, чому фінансові команди, які стикаються зі зростанням складності транскордонних операцій, переходять на облік у звичайному тексті.