E-invoicing: PDF vs structured invoice (і чому це важливо в 2026)

"E-invoicing" вживають вільно. Багато людей використовують у сенсі "я надіслав PDF інвойсу емейлом замість паперу". Це не те, що мають на увазі податкові органи, коли вживають термін.

У регуляторному сенсі e-invoicing — це структурований, machine-readable інвойс у визначеному форматі даних (зазвичай XML), переданий через визначений канал (часто державну мережу), і автоматично провалідований за правилами податкового органу. PDF — це картинка інвойсу: читабельна людиною, непрозора для машин. E-invoice — це структуровані дані: машини можуть автоматично витягти кожне поле.

Це розрізнення стає юридичною вимогою у все більшій кількості країн. Italy, Mexico, India, Brazil та кілька інших уже мандатують e-invoicing для B2B. EU "VAT in the Digital Age" (ViDA) розкочує e-invoicing-вимоги по всіх member states до 2030. US не має федерального мандату, але кілька штатів і федеральний procurement рухаються в тому напрямку.

Гайд пояснює, що таке e-invoicing насправді, де вимагається, і що фрілансерам і малому бізнесу реально треба робити — зазвичай менше, ніж здається.

Для базових відмінностей від інших типів — what is an invoice, tax invoice, invoice vs bill.

Що таке e-invoicing насправді

Технічне визначення з трьох частин. Документ — "e-invoice", лише якщо відповідає всім трьом:

Структурований формат даних. Контент інвойсу — у визначеному форматі типу UBL (Universal Business Language), CII (Cross Industry Invoice) чи country-specific XML schema. Не PDF, не Word, не зображення.
Пряма чи platform-mediated передача. Надіслано через визначений канал — часто державну clearance-платформу (Italy SDI, Mexico CFDI, India IRP) чи peer-to-peer мережу типу Peppol.
Real-time чи near-real-time валідація. Приймаюча система (чи проміжна податкового) валідує інвойс за business rules перед тим, як він дійде до покупця.

PDF, надісланий як attachment, — жодне з цього. Це електронне зображення інвойсу, але податковий зве це "electronic invoice in PDF format" — не e-invoicing.

Різниця важлива, бо e-invoicing дає урядам real-time tax visibility. Бачать VAT/GST потоки, як вони відбуваються, не через aggregated returns місяцями пізніше. Це політична мета, що рухає глобальний rollout — зменшення "VAT gap" (оцінено в €60+ млрд/рік лише в EU).

Чому уряди мандатують це

Три драйвери за хвилею мандатів:

VAT-fraud prevention. Carousel fraud, missing-trader fraud та інші VAT-схеми коштують EU member states десятки мільярдів євро щорічно. Real-time передача інвойсів податковому значно ускладнює більшість схем.
Tax-gap reduction. Коли інвойси течуть через урядові системи, податковий може pre-fill returns, автоматично матчити VAT charged з VAT recovered і аудити аномалій за дні, не роки.
Бізнес-ефективність. Правильно імплементоване e-invoicing усуває ручне введення даних на стороні покупця. AP-система покупця інгестить структурований інвойс автоматично — без OCR, без typos, без ганяння за відсутніми полями.

Більшість урядів ведуть з #1 і #2 при оголошенні мандатів; бізнеси бачать #3 як upside, що робить compliance вартим.

Де вимагається (станом на 2026)

Ландшафт швидко змінюється. Станом на 2026, широкими мазками:

Обов'язково зараз

| Країна | Scope | Формат | |---|---|---| | Italy | Усе B2B (з 2019), B2G | FatturaPA XML через SDI | | Mexico | Усе B2B і B2C | CFDI 4.0 XML через SAT | | Brazil | Усе B2B | NF-e XML через SEFAZ | | India | B2B понад поріг (₹5cr оборот) | IRN/QR через IRP | | Chile | Усе B2B і B2C | DTE XML через SII | | Turkey | B2B понад поріг | e-Fatura XML через GİB | | Poland | Усе B2B (rollout завершується 2026) | FA(2) XML через KSeF | | Spain | B2B понад поріг (rollout 2025–2026) | FacturaE XML через FACe |

Розкочується 2026–2028

EU (ViDA) — cross-border B2B e-invoicing гармонізовано до 2028; domestic B2B варіює, більшість вирівнюються до 2027
France — domestic B2B розкочується фазами 2026–2027
Germany — domestic B2B receiving capability обов'язково з січня 2025; sending — 2027–2028
Belgium, Netherlands, Sweden — різні фази 2026–2028

Поки не обов'язково (але поширено)

United States — нема федерального мандату; федеральна procurement-система (IPP) використовує e-invoicing для vendors, що продають федеральному; деякі штати використовують Peppol
United Kingdom — нема мандату станом на 2026; HMRC консультувався; пропозиції очікуються 2027+
Canada, Australia, Japan — добровільне Peppol; мандати обговорюються, не legislated

Якщо клієнти в "обов'язково зараз" країнах вище — можливо треба complience при інвойсуванні їх, але зазвичай вимога падає на issuer based in that country, не на іноземних vendors. US-фрілансер, що інвойсить італійського клієнта, не потребує FatturaPA; procurement італійського клієнта може вимагати e-invoice receivable, але вони обробляють трансмісію на своєму боці.

Що фрілансеру реально треба робити

Коротко: зазвичай нічого поки, якщо нічого з цього не діє.

Якщо ви фрілансер у "обов'язково зараз" країні

Треба видавати e-invoices через прописану систему. Не обговорюється — провал видавати compliant e-invoices може означати штрафи, відмову в input-VAT recovery або обидва. Практичні кроки:

Використовувати invoicing-тул з e-invoicing інтеграцією для вашої країни (Xero, Sage, FreshBooks, Zoho і багато локальних підтримують основні формати)
Зареєструватися в платформі податкового, якщо потрібно (наприклад, SDI для Italy, KSeF для Poland)
Отримати electronic signature certificate, якщо країна вимагає (багато для B2G)

Якщо ви фрілансер у країні без мандату (наприклад, US, UK станом на 2026)

Поки не маєте нічого робити. Але дві ситуації, де варто подумати:

Продаєте federal/government клієнтам за кордоном. Багато government procurement-систем вимагають e-invoicing, навіть якщо commercial-сектор країни ні. Перевіряйте вимоги procurement-порталу до bid.
Продаєте великим enterprise в мандатних країнах. Покупець може наполягати на отриманні e-invoices через бажану мережу (Peppol, SDI), навіть якщо ваша країна не вимагає від вас видавати. Compliance зазвичай contract requirement, не legal.

Якщо отримуєте e-invoice від vendor

Може знадобитися AP-система, що може інгестити структурований формат. Для малих більшість облікових платформ (Xero, QuickBooks, …) обробляють Peppol і основні XML нативно. Якщо vendor шле UBL XML, а ваш облік обробляє лише PDF — робитимете ручний переклад, дратує, але рідко compliance-проблема на receiver-боці.

PDF, structured PDF і "справжній" e-invoice

Три форми "electronic invoice" існують, і різниця важлива:

| Форма | Що це | Рахується як e-invoicing? | |---|---|---| | Plain PDF | PDF, що є візуальним зображенням інвойсу | Ні | | Hybrid PDF (наприклад, ZUGFeRD, Factur-X) | PDF, що вбудовує machine-readable XML data layer | Так у EU/Germany/France | | Pure structured (XML, UBL, …) | Без PDF; інвойс — це структуровані дані | Так — канонічний e-invoice |

ZUGFeRD/Factur-X — європейський компроміс: PDF, який людина може читати, і XML data block, який машина може інгестити, в одному файлі. Для фрілансерів у переході (EU/Germany особливо) — часто найпрагматичніший формат.

Механіка: як тече e-invoice

Типовий потік e-invoice (на прикладі SDI в Italy):

1. Фрілансер створює інвойс в обліковому тулі
2. Тул експортує як FatturaPA XML
3. Тул передає XML до SDI (Sistema di Interscambio)
4. SDI валідує XML за правилами податкового
5. Якщо valid: SDI доставляє в AP-систему клієнта; шле confirmation
6. Якщо invalid: SDI відхиляє; фрілансер має fix і resubmit
7. "Офіційний" інвойс — той, що SDI прийняв; фрілансер тримає копію

Час від кроку 1 до кроку 5 зазвичай кілька хвилин максимум. Клієнт отримує digitally-signed, провалідований інвойс без ручного введення даних в AP.

Для Peppol (використовується в багатьох EU і APAC):

1. Sender створює інвойс у своєму тулі
2. Тул передає через "Peppol access point" сендера (certified gateway)
3. Access point маршрутизує через Peppol до access point покупця
4. Access point покупця доставляє в AP
5. Обидві сторони тримають audit-логи передачі

Peppol не вставляє податковий посередині; це B2B routing-мережа. Деякі країни (Belgium, Singapore) шарують tax-authority reporting зверху.

Поширені гочи

1. PDF-only не рахується, де мандати діють. Емейлити PDF клієнту в Italy чи Mexico не задовольняє e-invoicing мандат. Інвойс має текти через прописану систему, інакше це не валідний інвойс.

2. Cross-border варіює. US-фрілансер, що інвойсить італійського B2B-клієнта, зазвичай не має використовувати SDI — мандат на Italian-resident issuers. Але італійський клієнт може попросити e-invoice формат для свого AP. Завжди питайте.

3. Number ranges зарезервовані. Деякі e-invoicing платформи призначають чи валідують invoice number sequences. Якщо також шлете PDF не-e-invoice клієнтам — тримайте окремі діапазони, щоб послідовність не конфліктувала з платформою.

4. Вимоги до зберігання. E-invoiced записи часто мають суворіші правила утримання — 10+ років digitally, з audit-log preservation. PDF-архіви можуть не задовольняти.

5. Безплатні тули можуть бути не compliant. Загальні invoice generators, що видають PDF, — не e-invoicing тули в регуляторному сенсі. Compliant тули рекламують підтримку конкретних форматів (FatturaPA, Peppol, ZUGFeRD, CFDI, …) і інтеграцію з платформою.

FAQ

PDF емейлом — це e-invoicing?

Ні — не в регуляторному сенсі. "E-invoicing" конкретно означає структурований, machine-readable формат, переданий через визначений канал. PDF — електронне зображення інвойсу, але не задовольняє мандати в країнах типу Italy, Mexico, Poland.

Які країни вимагають e-invoicing у 2026?

Italy, Mexico, Brazil, India, Chile, Turkey, Poland, Spain — країни з broad-мандатами. France, Germany, інші EU members — у phased rollouts через 2026–2028. US, UK, Canada, Australia не мають broad-мандатів станом на 2026, хоча конкретні сектори (federal procurement) можуть вимагати.

Як US-фрілансер, чи треба complience з EU e-invoicing?

Зазвичай ні для видачі інвойсів EU-клієнтам — ці мандати на issuers в country. Може треба шле інвойси у форматі, який AP EU-клієнта може інгестити (Peppol чи ZUGFeRD), але це contract matter, не legal.

У чому різниця Peppol і SDI?

Peppol — peer-to-peer business document network, що використовується в багатьох EU і APAC — маршрутизує інвойси між бізнесами, але не обов'язково репортить податковому. SDI (Sistema di Interscambio) — урядова платформа Italy, що сидить між кожним B2B-інвойсом і валідує до доставки. Peppol — це plumbing; SDI — plumbing + податковий checkpoint.

Чи втрачу input-VAT recovery, якщо отримаю non-compliant invoice?

У країнах зі суворими e-invoicing мандатами так — може не вийде recover input VAT проти інвойсу, що не пройшов прописану систему. Compliance-тягар на issuer, але наслідки (no VAT recovery) на receiver. Завжди перевіряйте, що вхідні від suppliers в мандатних країнах пройшли правильний канал.

Чи e-invoicing вимагається для B2C?

У більшості мандатних країн суворі правила на B2B і B2G. B2C часто обробляється інакше — споживач не потребує структурованого інвойсу для свого VAT (не recover'ить). Mexico — виняток: CFDI на B2B і B2C однаково.

Чи треба спеціальний софт для e-invoicing?

Для compliance — так, generic PDF-інвойс-тули не працюватимуть. Більшість major облікових платформ (Xero, QuickBooks, Sage, FreshBooks, Zoho) підтримують основні e-invoicing формати й інтеграції. Local providers в мандатних країнах часто мають сильнішу інтеграцію з local платформою.

Чим e-invoicing відрізняється від EDI?

EDI (Electronic Data Interchange) — ширша, старіша сім'я стандартів B2B обміну даними — інвойси, purchase orders, shipping notices тощо. E-invoicing у сучасному регуляторному сенсі більш конкретне: структурований формат інвойсу, мандатований податковим, часто з real-time трансмісією. EDI-інвойси можуть чи не можуть задовольняти сучасні e-invoicing мандати залежно від формату й каналу.