Під час онлайн-продажу клієнт платить карткою практично миттєво. Проте гроші не обов'язково одразу надходять на банківський рахунок підприємця. Спочатку їх отримує платіжний шлюз, який потім об'єднує кілька платежів в одну виплату (payout), утримує свої комісії й перераховує на банківський рахунок уже чисту суму.
Саме тому платіжний шлюз не можна обліковувати лише за банківською випискою.
Візьмімо два платежі:
| Платіж | Сплачено клієнтом | Комісія шлюзу | Чиста сума |
|---|---|---|---|
| Клієнт A | 100,00 € | 3,00 € | 97,00 € |
| Клієнт B | 60,00 € | 2,00 € | 58,00 € |
| Разом | 160,00 € | 5,00 € | 155,00 € |
Далі платіжний шлюз об'єднує обидва платежі й перераховує на банківський рахунок підприємця одну виплату на 155 євро.
Якби ми за банківською випискою відобразили 155 євро як виручку, облік не відповідав би тому, що сталося насправді. Клієнти заплатили разом 160 євро. Різниця в 5 євро — це не зменшення продажів, а окрема комісія платіжного шлюзу.
Тому в простій бухгалтерії (jednoduché účtovníctvo) потрібно відобразити весь потік: платіж клієнта, вимогу до платіжного шлюзу, комісію та подальшу виплату на банківський рахунок.
Правовий стан на 24 серпня 2026 року.
Платіж клієнта і виплата — це різні події
Під час звичайного онлайн-продажу між виникненням заборгованості клієнта та її погашенням може минути лише кілька секунд. Клієнт оформлює замовлення або отримує рахунок і одразу платить карткою.
З погляду обліку при цьому однаково відбуваються дві речі. Заборгованість клієнта погашається, бо клієнт заплатив. Водночас виникає вимога до компанії, яка керує платіжним шлюзом і має згодом розрахуватися з підприємцем за отримані гроші.
У простій бухгалтерії одна й та сама операція відображається одразу в кількох книгах. Книга дебіторської заборгованості (kniha pohľadávok) показує, хто винен підприємцю гроші, а грошовий журнал (peňažný denník) фіксує карткову виручку через транзитну статтю.
Ці два записи не виключають один одного. Кожен відстежує свою частину тієї самої операції.
Два платежі через Stripe
Клієнт A платить 100 євро, клієнт B — 60 євро. В обох випадках оплата карткою відбувається практично одночасно з продажем.
Тож у книзі дебіторської заборгованості погашення заборгованості клієнтів і виникнення вимог до Stripe можна відобразити так:
Книга дебіторської заборгованості
| Дата | Документ | Боржник | Опис | Заборгованість | Оплата / погашення | Залишок |
|---|---|---|---|---|---|---|
| 02.08.2026 | FA | Клієнт A | Продаж послуги, оплата карткою | 100,00 € | 100,00 € | 0,00 € |
| 02.08.2026 | ID | Stripe | Платіж клієнта A, отриманий через шлюз | 100,00 € | — | 100,00 € |
| 02.08.2026 | FA | Клієнт B | Продаж послуги, оплата карткою | 60,00 € | 60,00 € | 0,00 € |
| 02.08.2026 | ID | Stripe | Платіж клієнта B, отриманий через шлюз | 60,00 € | — | 160,00 € |
Після обох платежів клієнти вже нічого не винні. Відкритою залишається вимога до Stripe на 160 євро.
З економічного погляду заборгованість нікуди не зникла. Змінився лише боржник.
Як картковий платіж потрапляє до грошового журналу
Порядок ведення простої бухгалтерії передбачає для надходжень платіжними картками транзитні статті (priebežné položky).1 Під час отримання карткової виручки дохід відображається у відповідній графі й одночасно — транзитна стаття на боці доходів. Під час подальшого зарахування на банківський рахунок транзитна стаття закривається на боці витрат.
Для наших двох платежів грошовий журнал може мати такий вигляд:
Грошовий журнал — отримані карткові платежі
| Дата | Документ | Текст | Надходження на рахунок | PP — дохід | PP — витрата | PZD — продаж товарів і послуг | VOZD — комісія |
|---|---|---|---|---|---|---|---|
| 02.08.2026 | ID | Платіж клієнта A через Stripe | — | 100,00 € | — | 100,00 € | — |
| 02.08.2026 | ID | Платіж клієнта B через Stripe | — | 60,00 € | — | 60,00 € | — |
| Разом | — | 160,00 € | — | 160,00 € | — |
На цьому етапі ми вже маємо дохід від продажів на 160 євро, хоча на банківський рахунок поки нічого не надійшло.
Транзитна стаття не означає, що 160 євро — це ще один актив поряд із вимогою до Stripe. Це механізм грошового журналу, який пов'язує надходження карткою з його подальшим зарахуванням.
Який документ підтверджує платіж через Stripe
У звичайному банку ми маємо банківську виписку. Платіжний шлюз натомість веде власний детальний облік платежів ще до того, як сформовано виплату.
Для окремих платежів у Stripe практичним підтвердним документом є насамперед Payments CSV export. У ньому видно окремі транзакції, їхню дату, суму брутто і, залежно від налаштувань експорту, також комісії та інші ідентифікатори. Експорт комісій і платіжних даних Stripe описує у своїй документації.2
Саме за таким документом можна довести, що клієнт A заплатив 100 євро, а клієнт B — 60 євро, хоча згодом у банківській виписці з'явиться лише одна спільна виплата.
На підставі експорту можна скласти внутрішній документ (interný doklad, ID), за яким карткова виручка відображається в грошовому журналі й одночасно коригується облік дебіторської заборгованості.
За сотень платежів не потрібно готувати сотні внутрішніх документів вручну. Можна працювати зі зведеним записом за чітко визначений період, якщо зберігається зв'язок із детальним експортом і окремі транзакції можна відстежити.
Головне, щоб кожен обліковий запис мав підставу і щоб згодом можна було пояснити, що сталося, коли і на яку суму.
Комісії платіжного шлюзу
З першого платежу Stripe утримує 3 євро, з другого — 2 євро. Разом 5 євро.
Тут важливо розрізняти звіт про транзакції та документ на послуги платіжного шлюзу. Payments CSV може показувати комісію за конкретним платежем, але саме зобов'язання за послуги Stripe має підтверджуватися відповідним обліковим документом.
Якщо Stripe виставляє комісії на 5 євро, виникає зобов'язання:
Книга кредиторської заборгованості
| Дата | Документ | Кредитор | Опис | Зобов'язання | Оплата / погашення | Залишок |
|---|---|---|---|---|---|---|
| 03.08.2026 | FA | Stripe | Комісії за платіжні послуги | 5,00 € | — | 5,00 € |
При цьому комісію не можна просто обчислити як різницю між сумою платежів брутто (gross payments) і виплатою.
У нашому прикладі:
160 € − 155 € = 5 €
і різниця справді складається з комісій. Проте в реальному акаунті Stripe така сама різниця може містити також повернення (refunds), спори (disputes), конвертацію валют, резерви чи інші коригування (adjustments).
Тому в обліку не можна створювати витрату як «залишок для сходження». Має бути зрозуміло, що саме становить конкретна різниця.
У модельному прикладі в грошовому журналі ми використовуємо загальне позначення VOZD — комісія. Конкретну статтю витрат потрібно визначити з огляду на характер послуги та розбивку грошового журналу, якою ви користуєтеся.
Одна виплата за два платежі клієнтів
Далі Stripe об'єднує обидва платежі в одну виплату.
Ми маємо вимогу до Stripe:
160 євро
і водночас зобов'язання за його послуги:
5 євро.
Тому Stripe перераховує на банківський рахунок:
160 € − 5 € = 155 €
У банківській виписці буде лише один рядок:
Stripe payout +155 €
Саме тут найкраще видно, чому виплата — це не виручка. За одним банківським рухом на 155 євро стоять два окремі платежі клієнтів на 160 євро брутто та окрема комісія в 5 євро.
Грошовий журнал після виплати
| Дата | Документ | Текст | Надходження на рахунок | PP — дохід | PP — витрата | PZD — продаж товарів і послуг | VOZD — комісія |
|---|---|---|---|---|---|---|---|
| 02.08.2026 | ID | Платіж клієнта A через Stripe | — | 100,00 € | — | 100,00 € | — |
| 02.08.2026 | ID | Платіж клієнта B через Stripe | — | 60,00 € | — | 60,00 € | — |
| 05.08.2026 | VBU | Виплата Stripe і залік комісій | 155,00 € | — | 160,00 € | — | 5,00 € |
| Разом | 155,00 € | 160,00 € | 160,00 € | 160,00 € | 5,00 € |
Після виплати транзитна стаття закривається:
160 € на боці доходів − 160 € на боці витрат = 0 €.
Водночас в обліку залишається правильний результат:
- дохід від продажів — 160 євро,
- комісія платіжного шлюзу — 5 євро,
- надходження на банківський рахунок — 155 євро.
Як закривається вимога до Stripe
Під час виплати вимога до Stripe зменшується не лише на 155 євро.
Stripe мав розрахуватися з підприємцем за всі 160 євро. Він зробив це двома способами: 155 євро перерахував на банківський рахунок, а 5 євро зарахував у рахунок своєї комісії.
Книга дебіторської заборгованості — Stripe
| Дата | Документ | Боржник | Опис | Заборгованість | Оплата / погашення | Залишок |
|---|---|---|---|---|---|---|
| 02.08.2026 | ID | Stripe | Платіж клієнта A | 100,00 € | — | 100,00 € |
| 02.08.2026 | ID | Stripe | Платіж клієнта B | 60,00 € | — | 160,00 € |
| 05.08.2026 | VBU / авізо | Stripe | Виплата і залік комісій | — | 160,00 € | 0,00 € |
Так само закривається зобов'язання за послуги Stripe:
Книга кредиторської заборгованості — Stripe
| Дата | Документ | Кредитор | Опис | Зобов'язання | Оплата / погашення | Залишок |
|---|---|---|---|---|---|---|
| 03.08.2026 | FA | Stripe | Комісії за платіжні послуги | 5,00 € | — | 5,00 € |
| 05.08.2026 | ID | Stripe | Залік комісій з балансу Stripe | — | 5,00 € | 0,00 € |
Після повного розрахунку (settlement) усі облікові регістри показують те саме:
Стан після розрахунку
| Стан після розрахунку | Сума |
|---|---|
| Платежі клієнтів брутто | 160,00 € |
| Дохід від продажів | 160,00 € |
| Комісії платіжного шлюзу | 5,00 € |
| Виплата на банківський рахунок | 155,00 € |
| Транзитні статті | 0,00 € |
| Заборгованість клієнтів | 0,00 € |
| Вимога до Stripe | 0,00 € |
| Зобов'язання перед Stripe | 0,00 € |
Payments CSV, щомісячний Summary і VAT Invoice мають різні завдання
У Stripe немає одного документа, який пояснював би весь місяць. Різні документи підтверджують різні частини потоку.
Payments CSV зручний для самих платежів клієнтів. У ньому видно окремі транзакції, і за ним можна визначити отримані суми брутто.
Щомісячний Summary слугує насамперед для звірки (reconciliation). Він допомагає перевірити, як між собою пов'язані отримані платежі, комісії, повернення, інші рухи, виплати та кінцевий баланс у Stripe. Stripe призначає свої звіти зокрема для контролю та звірки руху балансу.3
Stripe VAT Invoice — це окремий обліковий і податковий документ на послуги Stripe. Він є підставою для зобов'язання перед Stripe і для правильної оцінки ПДВ. Щомісячний податковий рахунок (tax invoice) і його зміст Stripe описує в розділі підтримки.4
Ці суми не обов'язково збігаються.
Наприклад, якщо Payments CSV показує за місяць payment fees на 78,60 євро, а Stripe VAT Invoice виставлено на 81,41 євро, різницю в 2,81 євро не варто просто додавати до processing fees. Спершу потрібно з'ясувати, що саме Stripe виставив цією сумою. Рахунок може містити й інші послуги чи комісії, які не прив'язані безпосередньо до одного конкретного платежу клієнта.
Так само загальну суму комісій не можна обчислити лише як різницю між платежами брутто та банківськими виплатами.
Банківська виписка підтверджує виплату, а не початкову виручку
В інтерфейсі Stripe може бути видно, що виплату створено або надіслано. Проте рух на банківському рахунку відображається на підставі виписки з банківського рахунку (výpis z bankového účtu, VBU).1
Звіт Stripe і банківська виписка підтверджують дві різні речі.
Stripe пояснює, з чого склалася виплата. Банківська виписка підтверджує, скільки і коли фактично надійшло на рахунок.
Якщо у виписці ми бачимо одну виплату на 155 євро, сам банк не скаже нам, що за нею стоять два платежі на 100 і 60 євро та комісії на 5 євро. Цю інформацію можна отримати лише з обліку платіжного шлюзу.
Тому для платіжного шлюзу недостатньо обліковувати лише банківські рухи.
Що робити, якщо Stripe ще не виплатив усіх грошей
Платежі клієнтів і виплати не обов'язково припадають на той самий день чи навіть місяць.
Якщо до кінця місяця клієнти заплатили разом 1 000 євро, а Stripe перерахував до банку лише частину цієї суми, це не означає, що доходом підприємця є тільки отримана виплата.
Клієнти вже заплатили. Нерозрахована частина залишається відкритою вимогою до платіжного шлюзу до наступної виплати чи іншого способу розрахунку.
Тому цілком нормально, якщо на кінець місяця залишається відкрита вимога до Stripe і залишок на транзитних статтях. Важливо, щоб цей стан можна було пояснити за допомогою детального обліку платформи і згодом звірити з наступними виплатами.
Не кожна платформа — це платіжний шлюз
Цей підхід не можна автоматично переносити на будь-яку платформу, яка приймає гроші від кінцевих клієнтів.
У класичному платіжному шлюзі клієнт купує в підприємця, а платформа забезпечує обробку платежу та розрахунок за ним.
Проте маркетплейс, комісійна модель, App Store чи Merchant of Record можуть працювати інакше. Платформа може сама бути продавцем для кінцевого клієнта, або між сторонами можуть існувати зовсім інші правові відносини.
Тому, перш ніж застосовувати той самий порядок обліку, потрібно зрозуміти, яку роль платформа фактично виконує в конкретній бізнес-моделі.
Висновок
Працюючи з платіжним шлюзом, банківську виплату не можна плутати з виручкою.
Якщо клієнт A заплатив 100 євро, а клієнт B — 60 євро, підприємець отримав карткову виручку брутто на 160 євро, навіть якщо після утримання комісій Stripe перераховує на банківський рахунок лише одну виплату на 155 євро.
У грошовому журналі надходження карткою відображаються як дохід і через транзитні статті. У книзі дебіторської заборгованості після оплати клієнтами відстежується вимога до платіжного шлюзу. Комісії утворюють окреме зобов'язання, а під час виплати закриваються банківське надходження, транзитна стаття, вимога і зобов'язання.
Тому в Stripe потрібно відстежувати весь потік:
продаж → платіж клієнта → вимога до Stripe → комісія → виплата → банківський рахунок.
Payments CSV показує окремі платежі клієнтів, щомісячний Summary допомагає звірити весь акаунт Stripe, VAT Invoice підтверджує послуги Stripe, а банківська виписка — саму виплату.
І саме за великої кількості платежів найкраще видно, чому це розмежування таке важливе: одна банківська виплата може бути результатом десятків або сотень окремих продажів.
