Що таке звірка платежів? Зіставлення виплат PSP із грошовою книгою

Зіставлення платежів (payment reconciliation) - це перевірка того, що постачальник платіжних послуг (PSP) фактично перерахував на ваш рахунок, проти того, що вам заборгували клієнти. Це завдання відрізняється від банківської звірки та є складнішим, оскільки виплата від PSP ніколи не складається з одного платежу за один інвойс.

Головна ознака: ви продали товарів на 10 000 €, а на банківський рахунок надійшло 9 712,40 €. Обидві цифри є правильними. Усе, що знаходиться між ними, пояснює ця звірка.

Чому виплата ніколи не збігається з продажами

Одна виплата від Stripe, Adyen або PayPal є неточним пакетом (net batch). У проміжку між оплатою від клієнта та надходженням грошей PSP:

• об’єднав багато списань за розрахунковий період,
• утримав свою комісію за кожною транзакцією,
• утримав суми повернень і чарджбеків (chargeback), що відбулися в тому ж вікні,
• можливо, утримав резервний фонд (reserve),
• і перерахував залишок через кілька днів однією сумою.

Тому у виписці з банку відображається один рядок на суму 9 712,40 €, тоді як у грошовій книзі (ledger) є десятки інвойсів, і жоден із них не дорівнює цій сумі. Пряме зіставлення виплати з інвойсами неможливе, тому виплату спершу потрібно декомпозувати.

Декомпозиція

Пакет розрахунків розбивається на категорії, і кожна категорія має своє значення для обліку:

Категорія	Що це таке	Вплив на облік
Списання (Charges)	Платежі клієнтів	Погашення дебіторської заборгованості
Повернення (Refunds)	Гроші, повернуті клієнтам	Сторнування погашеної дебіторської заборгованості
Комісії (Fees)	Комісія PSP	Витрати
Чарджбеки (Chargebacks)	Спірні платежі, які було стягнуто назад	Відновлення дебіторської заборгованості плюс комісія
Коригування / резерви (Adjustments / reserves)	Часові зсуви та ризикові утримання	Заборгованість, яку виплачує PSP

Тотожність, яка повинна дотримуватися:

Валові списання − повернення − комісії − чарджбеки ± коригування = Чиста виплата

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

Проводки

Відображення пакету розрахунків на суму 10 000 € валових списань, 250 € комісій та 37,60 € повернень:

Рахунок	Дебет	Кредит
2710 Банк	9 712,40
6800 Фінансові витрати (комісії PSP)	250,00
5000 Виручка / сторно дебіторської заборгованості (повернення)	37,60
2410 Дебіторська заборгованість за товари, роботи, послуги		10 000,00

Це читається так: заборгованість клієнтів у розмірі 10 000 € погашено, PSP утримав 250 €, 37,60 € повернуто клієнтам, а 9 712,40 € надійшли до банку. Комісія є реальними витратами, які ніколи не з’являються в жодному інвойсі клієнта. Саме тому валова виручка та банківські надходження відрізняються, а звірка лише за банківським рядком мовчки занижує і доходи, і витрати.

Для маркетплейсів є ще один рівень. Якщо виплата містить гроші, що належать продавцям, виручкою платформи є лише її комісія, а решта є зобов'язанням. Правила проводдок Nordlet охоплюють це за допомогою спеціальних ключів: settlements.fees, settlements.commissionRevenue, settlements.sellerPayable та settlements.suspense. Завдяки цьому розділена виплата зараховує комісію до виручки, а частку продавця - до кредиторської заборгованості, замість того щоб штучно завищувати дохід платформи.

Як це робить Nordlet

Процес складається з трьох кінцевих точок (endpoints):

1. Імпорт. POST /v1/bank/settlements/import зчитує звіт про звірку виплат Stripe і створює пакет розрахунків (провайдер, ідентифікатор виплати, валюта, валова сума, комісії та чистий залишок) із по одному рядку для кожної базової транзакції, кожен із яких містить свою категорію. Пакети є унікальними для кожного провайдера та ідентифікатора виплати, тому повторний імпорт того ж звіту не може призвести до подвійного обліку.
2. Зіставлення. POST /v1/bank/settlements/match пов'язує рядки списань і повернень з інвойсами на продажі, до яких вони належать. Рядки мають статус зіставлення unmatched (не зіставлено), matched (зіставлено автоматично на основі посилання на замовлення або інвойс у звіті) або manual (визначено вручну людиною). Рядки комісій та коригувань за задумом не підлягають зіставленню з інвойсами - спроби зробити це будуть відхилені, а не вгадані автоматично.
3. Проведення. POST /v1/bank/settlements/post створює проводки в обліковій книзі для всього пакету за допомогою вищезазначених правил проводдок і змінює статус пакету з imported (імпортовано) на posted (проведено). Незіставлені надходження потрапляють на транзитний рахунок (suspense account), замість того щоб примусово прив'язуватися до інвойсу. Вони залишаються видимими та навмисно привертають увагу, доки ситуацію не буде вирішено.

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

Проведений пакет прив'язується до рядка виписки з реального банківського рахунку. У розділі Bank → Match rules ви описуєте, як виплата відображається у вашій виписці: текст, який рядок містить завжди, і за бажанням префікс ідентифікатора виплати в ньому. Коли виписка імпортується, рядок, що відповідає правилу, прикріплюється до свого пакету за ідентифікатором виплати або шляхом зіставлення чистої суми пакету в межах заданого вами вікна дат. Тоді банківський рядок містить бухгалтерську проводку розрахунку, замість того щоб чекати на друге, дублююче проведення, а POST /v1/bank/settlements/link та /unlink встановлюють або виправляють зв'язок вручну.

Як робити це правильно

• Звіряйте кожну виплату окремо, а не раз на місяць. Виплата є природною одиницею обліку. Об'єднання місячних виплат перед звіркою знищує перевірку тотожності, яка дозволяє легко знаходити помилки.
• Ніколи не проводьте чисту суму як виручку. Це найпоширеніша помилка в бухгалтерському обліку платформ. Відображення виручки на суму 9 712,40 € занижує і продажі, і витрати, спотворює валовий прибуток і зазвичай занижує ПДВ, оскільки ПДВ нараховується на валову суму, яку заплатив клієнт, а не на ту, яку переслав PSP.
• Стежте за часовим розривом. Платіж, прийнятий 30 червня і виплачений 3 липня, належить до доходів червня та грошових коштів липня. На кінець періоду ця різниця залишається дебіторською заборгованістю від PSP - це реальні гроші, які лежать на чиємусь іншому рахунку.
• Звіряйте повернення з початковим продажем. Непов’язане повернення залишає закритий інвойс із виглядом оплаченого, а виручку - завищеною.

FAQ

У чем різниця між звіркою платежів та банківською звіркою?

Банківська звірка порівнює вашу облікову книгу з банківською випискою рядок за рядком. Звірка платежів розташовується на один рівень раніше: вона розбиває єдину виплату PSP на безліч списань, повернень і комісій, які за нею стоять, щоб ці банківські рядки взагалі можна було пояснити.

Чому моя виплата від Stripe не збігається з моїми продажами?

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

Чи слід зменшувати виручку на суму комісій PSP?

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

Як обробляються розподіли на маркетплейсах?

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

Що відбувається з незіставленими рядками розрахунків?

Вони потрапляють на транзитний рахунок (suspense account), замість того щоб примусово прив'язуватися до інвойсу. Це тримає грошову книгу збалансованою, а проблему - видимою. Залишок на транзитному рахунку є робочим списком, який має бути нульовим до закриття періоду.