QR-інвойс та QR-інвойсинг: як український бізнес виставляє рахунки й отримує оплату в одне сканування

QR-інвойс — це електронний рахунок із вбудованим у нього платіжним QR-кодом. Код містить усі реквізити, потрібні банку для переказу коштів: IBAN одержувача, суму, призначення платежу, податковий номер і валюту. Замість того щоб диктувати реквізити телефоном або вручну переписувати 29-символьний IBAN, покупець відкриває банківський застосунок — наприклад, Приват24 чи monobank — сканує код, перевіряє вже заповнену форму й підтверджує. Платіж надходить безпосередньо на рахунок продавця.

QR-інвойсинг — це процес навколо цього документа: формування рахунку, доставлення його клієнту та звірка вхідного переказу. У цій статті пояснюємо, як працює і те, і інше в Україні, як між собою співвідносяться наявні рішення банків і провайдерів, і де в цій картині знаходиться банко-незалежний сервіс на кшталт pmnt.app.

QR-інвойс проти QR-інвойсингу: одне — це об'єкт, інше — процес

Ці два терміни часто вживають як синоніми, але вони описують різні речі.

• QR-інвойс — сам документ. Запит на оплату, який кодує реквізити продавця та (за потреби) фіксовану суму всередині скановного коду. Він може існувати як зображення на екрані, роздруківка біля каси, вкладення в чаті або блок на вебсторінці.
• QR-інвойсинг — наскрізна практика виставлення таких рахунків, надсилання їх через будь-який зручний для угоди канал і відстеження того, які з них оплачені. Для бізнесу інвойсинг — це регулярна рутина; інвойс — окремий її результат.

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

Що міститься всередині сумісного QR-інвойсу

В Україні платіжні QR-коди мають формат, стандартизований Національним банком України (НБУ). Поточне покоління — структура V003, яка кодує визначений набір полів так, щоб кожен сумісний банківський застосунок читав їх однаково:

• IBAN одержувача (UA + 27 символів)
• Ім'я одержувача — компанія, фізична особа-підприємець (ФОП) або приватна особа
• Податковий ідентифікатор — ЄДРПОУ для компаній (8 цифр) або РНОКПП для фізосіб (10 цифр)
• Сума та валюта (UAH)
• Призначення платежу — довільний текст, наприклад «Оплата за замовлення №123»
• Референс — структурований код, за яким банк-одержувач може звірити переказ

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

Як працює QR-інвойсинг від початку до кінця

Життєвий цикл короткий і однаковий незалежно від того, який інструмент створює код.

1. Створення. Продавець вводить свій IBAN, ім'я, податковий номер, призначення платежу та (зазвичай) суму. Інструмент кодує це у V003 QR-код і відображає його.
2. Доставлення. Код потрапляє до клієнта тим способом, що пасує ситуації, — показаний на екрані в точці продажу, роздрукований і приклеєний на касі, надісланий посиланням у Telegram чи Viber, вбудований на сторінці оплати або опублікований у соцмережах.
3. Сканування. Клієнт відкриває будь-який український банківський застосунок, торкається сканера QR і наводить камеру на код. Форма переказу заповнюється автоматично.
4. Підтвердження. Клієнт перевіряє одержувача, суму й призначення, обирає картку або рахунок для оплати та авторизує операцію PIN-кодом, відбитком пальця чи Face ID.
5. Розрахунок. Кошти рухаються безпосередньо між двома банками. Через оновлену систему електронних платежів (СЕП-4.1) миттєві перекази проходять приблизно за десять секунд, цілодобово. Більші чи особливі перекази йдуть стандартними каналами і зазвичай завершуються протягом години.

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

Наявні рішення для QR-інвойсингу в Україні

Кілька банків і провайдерів уже пропонують ту чи іншу форму QR-інвойсингу. Кожне з них побудоване навколо власного рахунку, застосунку чи еквайрингового договору.

NovaPay — швидкі рахунки для ФОП у застосунку

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

ПриватБанк — виставлення рахунків для бізнес-клієнтів

ПриватБанк пропонує інструменти виставлення рахунків для своїх бізнес-клієнтів, зокрема приймання оплати за QR і посилання, що відкривають заздалегідь заповнений переказ. Цей процес тісно інтегрований із бізнес-рахунками ПриватБанку, а там, де задіяний еквайринг, — і з його еквайринговими тарифами.

Raiffeisen Bank — pay-by-link, чат-бот та електронний рахунок

Raiffeisen об'єднує кілька методів приймання навколо свого еквайрингового продукту «Рахунок 907»: pay-by-link, чат-бот для виставлення запитів та електронне виставлення рахунків (e-invoicing). Вони охоплюють приймання карток і електронне білінгування й розраховані на торговців, що мають еквайринговий договір із Raiffeisen.

4bill.io — QR-платежі як метод оплати

4bill.io надає QR-платежі як один із підтримуваних методів приймання в межах ширшої платіжно-сервісної пропозиції, орієнтованої на онлайн-продавців, які хочуть мати QR поряд із картками та іншими каналами.

Як вони співвідносяться

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

Де знаходиться банко-незалежний сервіс

pmnt.app відштовхується від іншої вихідної точки: інвойс будується навколо IBAN продавця, а не навколо продукту конкретного банку. Оскільки платіж — це звичайний міжбанківський переказ, а не картковий еквайринг, модель відрізняється кількома практичними рисами.

• Працює будь-який український банк. Продавець може тримати рахунок будь-де; платник може платити з будь-якого банківського застосунку, що підтримує стандарт QR НБУ. Жодна зі сторін не зобов'язана мати спільний банк.
• Без комісії продавця. Прямий IBAN-переказ не несе еквайрингового відсотка, тож продавець отримує повну суму рахунку. Платник сплачує лише комісію за переказ свого банку, яка для гривневих переказів часто дорівнює нулю.
• Без фіскального обладнання. Немає POS-термінала, який треба купувати, орендувати чи обслуговувати, і немає даних картки, що проходять через системи продавця.
• Кілька способів виставлення. Рахунки можна створювати через вебінтерфейс, Telegram-бот, API для автоматизованих систем або MCP-сервер для AI-асистентів — це корисно, коли інвойсинг потрібно вбудувати в наявний інструмент, а не робити вручну.

Це не робить pmnt.app однозначно кращим за пропозицію банку для будь-якого бізнесу. Це робить його придатним для продавців, які хочуть QR-інвойсинг без прив'язки до рахунку одного банку та без сплати еквайрингу з кожного продажу.

Зауваження про фіскалізацію

Приймання IBAN-переказу через QR-інвойс не є еквайрингом, і сам QR-код не виконує фіскалізації. Там, де бізнес за законом зобов'язаний фіскалізувати продаж, цей обов'язок виконується окремо — через РРО або програмний РРО (ПРРО), незалежно від того, як було запитано оплату. QR-інвойсинг змінює те, як платить клієнт, — він сам по собі не скасовує й не виконує вимогу фіскалізації, що вже застосовується до операції. Розглядайте платіжний канал і фіскальний обов'язок як два окремих питання.

Практичні обмеження

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

• Стеля миттєвого переказу. Миттєвий розрахунок через СЕП-4.1 охоплює перекази до 100 000 грн; суми понад це йдуть стандартними каналами й можуть зайняти приблизно до години.
• Ліміти переказів для фізосіб. За меморандумом українських банків, до P2P- та IBAN-переказів приватних осіб застосовуються місячні ліміти. Перекази на бізнес-рахунки ФОПів і юридичних осіб трактуються інакше.
• Лише гривня. Поточний процес QR-інвойсингу побудований для UAH. Розрахунок в іноземній валюті використовує інші методи.
• Потрібні інтернет і банківський застосунок. Платнику в момент оплати потрібні онлайн-з'єднання та банківський застосунок; офлайн-сканування не підтримується.

Кому QR-інвойсинг приносить найбільше користі

• ФОПам і фрилансерам, які виставляють рахунки кільком клієнтам і хочуть отримувати кошти на власний IBAN без термінала чи місячної плати.
• Сервісному бізнесу — салонам, репетиторам, майстерням, — який виставляє запит і отримує оплату на місці.
• Онлайн-продавцям, які хочуть додати безкомісійний варіант поряд із картками або продають через чати та соцмережі, де посилання чи зображення — природний канал доставлення.
• Торговцям на ринках і ярмарках, які можуть роздрукувати один статичний QR-інвойс і приймати оплату, навіть не маючи смартфона на місці продажу.

Висновок

QR-інвойс стискає акт виставлення рахунку до одного сканування: повні реквізити продавця подорожують усередині коду, застосунок покупця заповнює форму, а переказ розраховується безпосередньо між банками. QR-інвойсинг — це рутина навколо нього: виставлення, доставлення та звірка цих запитів у тому обсязі, у якому працює бізнес.

В Україні вже є спроможні пропозиції банків і провайдерів — NovaPay, ПриватБанк, «Рахунок 907» від Raiffeisen, 4bill.io, — кожна сильна для бізнесу, що вже всередині її екосистеми. Спільний компроміс, який вони поділяють, — прив'язка до конкретного рахунку чи еквайрингового договору. Банко-незалежний, безкомісійний підхід на кшталт pmnt.app пасує продавцям, які радше будуватимуть інвойсинг навколо власного IBAN, прийматимуть оплату з будь-якого українського банку й залишатимуть собі повну суму кожного рахунку. Правильний вибір залежить від того, де бізнес уже обслуговується, і чи цінує він інтеграцію з одним провайдером більше за незалежність від усіх них.