Облік у маркетплейсах із Stripe Connect: робочий процес

Більшість проблем з обліком у маркетплейсах виникають через одну й ту саму помилку: ставлення до виплати зі Stripe (payout) як до виручки. Виплата є чистим залишком від десятків окремих економічних подій, і відображення її однією статтею доходу стирає платформову комісію, зобов'язання перед продавцем, а також кожну комісію та диспут, які заховані всередині. Правильний робочий процес декомпозує виплату до того, як вона потрапить до бухгалтерської книги.

У цьому посібнику кожну категорію балансових транзакцій (balance transaction) Stripe розподілено на належні їй облікові рахунки: дебіторську заборгованість, виручку від комісій, зобов'язання перед продавцями, витрати на обробку платежів та транзитні рахунки. Як механізм проводок використовуються задокументовані кінцеві точки (endpoints) імпорту та розрахунків Nordlet, наводиться практичний приклад розрахунку, а наприкінці пропонується чек-лист звірки, який можна виконувати перед кожним закриттям періоду.

Визначте модель платежів Connect перед початком проєктування

Бухгалтерські правила неможливо сформулювати, допоки ви не з'ясуєте, яку модель платежів використовує кожен платіжний потік. Модель визначає, на чиєму балансі у Stripe відображається платіж, хто сплачує комісії та куди в першу чергу надходять повернення коштів і диспути.

Модель Connect	Платіж створюється на	Сплачує комісії Stripe	Повернення / диспути зменшують	Бухгалтерські наслідки
Прямі платежі (Direct charges)	Підключений акаунт	Налаштовується індивідуально для кожної сторони	Баланс підключеного акаунта	Платформа відображає свою комісію як виручку; діяльність із виплат продавцю переважно обліковується в книзі підключеного акаунта
Цільові платежі (Destination charges)	Платформа, з негайним переказом на один підключений акаунт	Платформа	Платформа	Платформа відображає дебіторську заборгованість клієнта та комісію Stripe; частка продавця є кредиторською заборгованістю, а не виручкою
Окремі платежі та перекази (Separate charges and transfers)	Платіж на платформі, потім один або кілька окремих переказів	Платформа	Платформа	Платіж і перекази продавцю є окремими подіями; зобов'язання перед продавцем відстежуються незалежно від платежу клієнта

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

Практичне правило: не кажіть, що „виплата зі Stripe є виручкою продавця“ або що „продавець сплачує комісії“, доки ви не зафіксуєте модель платежів для кожного потоку. Зберігайте цю модель разом із кожною транзакцією. Змішування прямих і цільових платежів в одне правило проводок - найшвидший спосіб спотворити як виручку, так і зобов'язання.

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

Схемно відобразіть рух коштів перед імпортом першого рядка

Перш ніж торкатися імпорту, намалюйте односторінкову карту транзакцій для кожного потоку:

Customer payment
  -> Stripe charge / payment balance transaction
  -> Stripe fee
  -> platform application fee (commission)
  -> transfer to connected account
  -> refund or dispute (if applicable)
  -> Stripe payout
  -> bank receipt

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

Виберіть правильний звіт-джерело у Stripe

Для пакетів автоматичних виплат використовуйте деталізований звіт щодо звірки виплат (Payout reconciliation, itemized). Він надає один рядок на кожну балансову транзакцію, групує рядки за полем reporting_category, пов'язує кожен із них із automatic_payout_id, а також містить загальні суми брутто, комісій та нетто. Посібник із вибору звітів Stripe документує цей звіт і підтверджує наявність полів charge_id, connected_account_id та destination_payment_id як доступних полів Connect.

Якщо автоматичні виплати не активовані (деякі схеми ручних виплат), натомість використовуйте звіт про баланс (Balance report). Не вважайте підсумок виплат у Панелі керування (Dashboard) достатнім доказом для проведення проводок. Підсумок підтверджує загальну суму пакету, і лише деталізований звіт пояснює складові.

Stripe рекомендує виконувати класифікацію за полем reporting_category, а не за застарілим полем type, причому кожен рядок містить ідентифікатор source, який зв'язується з базовим об'єктом. Зверніть увагу на часові обмеження: Stripe зазначає, що дані щоденних звітів зазвичай доступні до опівдня наступного дня, а миттєві виплати не можуть бути чітко віднесені до окремих транзакцій, тому вони потребують окремої звірки історії транзакцій.

Класифікуйте кожну балансову транзакцію за категорією

Використовуйте reporting_category як основний класифікатор, а потім перевіряйте source_id, charge_id та описи. Важлива таблиця відповідності:

Операція у Stripe	Категорія звітності (reporting_category)	Бухгалтерське трактування
Платіж клієнта, картка чи локальний метод оплати	charge	Дебіторська заборгованість за рахунок клієнта або розрахунки за продажами
Повернення коштів	refund	Сторнування початкового платежу клієнта
Комісія за обробку, утримана Stripe	fee	Витрати на обробку платежів
Комісія платформи	platform_earning	Виручка від комісій
Повернена комісія платформи	platform_earning_refund	Зменшення виручки від комісій
Переказ на підключений акаунт	transfer	Зменшення зобов'язань перед продавцем
Скасований переказ	transfer_reversal	Стягнення з підключеного акаунта
Чарджбек	dispute	Збиток від чарджбеку; перевірте базовий об'єкт диспуту
Виграний або скасований чарджбек	dispute_reversal	Відшкодування раніше відображеного в обліку чарджбеку
Виплата на банківський рахунок	payout	Рух коштів по банку, а не виручка
Скасована виплата	payout_reversal	Повернення коштів на баланс Stripe
Утриманий резерв	connect_reserved_funds / risk_reserved_funds	Обмежені кошти, за замовчуванням не є витратами
Стягнення давно утримуваного від’ємного балансу	connect_collection_transfer	Подія фінансування або відшкодування, що потребує політики управління ризиками

Одне застереження щодо термінології: старіше поле типу балансової транзакції (type) використовує інші мітки для тих самих подій, серед яких payment, application_fee та adjustment. Документація Stripe щодо типів балансових транзакцій містить обидва словники. Не змішуйте значення type у правило для reporting_category і не вигадуйте категорії на кшталт dispute_loss, які Stripe не експортує. Якщо експорт містить мітку, яку ви не впізнаєте, збережіть експортоване значення та звірте його з базовим об'єктом.

Проводьте звичайну активність маркетплейса в обліковій книзі

Для платформи з цільовими платежами або окремими платежами й переказами концептуальні проводки виглядають так.

Платіж клієнта (кошти клієнта надходять на кліринговий баланс Stripe):

Dr Stripe clearing        Gross customer charge
    Cr Trade receivables   Gross customer charge

Комісія Stripe за обробку:

Dr Stripe fee expense      Stripe fee
    Cr Stripe clearing     Stripe fee

Не згортайте комісію Stripe із виручкою, якщо ваша облікова політика прямо не вимагає і не підтримує представлення в нетто-оцінці.

Комісія платформи (ваша виручка, виділена з того, що інакше належало б продавцю):

Dr Seller payable          Commission amount
    Cr Commission revenue   Commission amount

Переказ продавцю (розрахунок за заборгованістю, а не витрати):

Dr Seller payable          Transfer amount
    Cr Stripe clearing      Transfer amount

Переказ ніколи автоматично не є витратами. Частка продавця стає зобов'язанням у момент надходження платежу, а переказ погашає це зобов'язання. Правила проведення розрахунків у Nordlet дотримуються цього принципу: рядки platform_earning проводяться на виручку від комісій, тоді як рядки transfer зменшують зобов'язання перед продавцем. Задокументовані ключі проводок за замовчуванням: settlements.commissionRevenue (за замовчуванням 5001), settlements.sellerPayable (за замовчуванням 4499), settlements.fees (за замовчуванням 6800) та settlements.suspense (за замовчуванням 4440), кожний з яких можна перевизначити для кожної компанії через правила проводок в API Nordlet.

Обробляйте повернення коштів проти первинного продажу, а не як вільні банківські елементи

Повернення коштів прив'язане до початкового платежу або інвойсу. Концептуально:

Dr Refunds / sales reversals    Refund amount
    Cr Trade receivables         Refund amount

Реальна проводка залежить від того, чи була визнана виручка, чи потрібно сторнувати податок і чи була повернена комісія платформи. Одне повернення коштів може призвести до сторнування дебіторської заборгованості, сторнування податку, повернення платформи application fee, сторнування переказу або зменшення зобов'язань перед продавцем, а також до наслідків щодо комісії Stripe, які слід перевірити, а не приймати на віру.

Частка пастки: повернення коштів часто розраховується у виплаті пізнішого періоду, ніж початковий платіж. Надавайте перевагу деталізованому звіту звірки виплат порівняно зі згенерованим поверненням коштів з експорту рівня платежів. Документація Nordlet прямо попереджає, що повернення коштів, згенероване з експорту платежів (Payments), є лише приблизним, якщо повернення розраховується пізніше. Імпортер розрахунків може прийняти рядок повернення, зіставити його з початковим продажем та сторнувати дебіторську заборгованість під час проведення пакету.

Обробляйте диспути окремо від повернень коштів

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

Програний диспут з боку платформи:

Dr Chargeback loss / receivable reopened   Disputed amount
Dr Dispute-fee expense                      Dispute fee
    Cr Stripe clearing                      Combined amount

Якщо продавець бере збиток на себе і відшкодування підтверджено:

Dr Seller payable / recovery account   Recoverable amount
    Cr Chargeback recovery              Recoverable amount

Не проводьте відшкодування від продавця лише тому, що було надіслано запит на скасування переказу. Перевірте, чи було створено скасування, чи воно завершилося успішно та чи з'явилося на балансі Stripe. Якщо диспут виграно, Stripe повертає спірну суму через рядок dispute_reversal; сторнуйте збиток від чарджбеку та окремо обробіть будь-яку комісію за диспут, яку Stripe не повертає. Nordlet зіставляє рядки чарджбеків, використовуючи charge_id раніше зіставленого платежу з того самого файлу або з попереднього імпорту.

Практичний приклад розрахунку

Візьмемо один пакет автоматичних виплат. Деталізований звіт містить:

• Рядок charge: брутто 100.00, комісія Stripe 3.20, нетто 96.80
• Рядок platform_earning: 15.00, комісія платформи
• Рядок transfer: 81.80 на користь підключеного продавця
• Рядок refund від попереднього продажу: брутто 20.00, що розраховується в цьому пакеті
• Рядок payout: загальна сума пакету, що надходить до банку

Склад виплати відповідно до розрахункової ідентичності Stripe:

Gross charges                100.00
- refunds                     20.00
- Stripe fees                  3.20
- transfers                   81.80
= net to platform balance     -5.00

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

Тут переказ продавцю разом із поверненням коштів перевищують активність за чистими платежами, тому пакет дає невеликий мінус і зменшує наступну виплату або залучає кошти з балансу. Проведений журнал сторнує дебіторську заборгованість за поверненням, визнає виручку від комісій у розмірі 15.00, відображає витрати на комісію 3.20, зменшує кредиторську заборгованість перед продавцем на суму переказу та проводить сторно повернення. Рядок банку відповідає чистій сумі, що надходить на рахунок. Жодна окрема цифра не дорівнює „виручці“, у цьому й полягає сенс.

Імпорт і проведення через кінцеву точку розрахунків Nordlet

Для звірки на рівні виплат використовуйте:

POST /v1/bank/settlements/import

з провайдером Stripe та деталізованим CSV-файлом. Nordlet групує рядки за automatic_payout_id, перетворює кожну виплату на пакет розрахунків із підсумками брутто, комісій та нетто, пропускає повторні імпорти вже проведеної виплати, пропускає рядки payout зі структури виплати та автоматично зіставляє рядки платежів, повернень і диспутів за допомогою посилань на замовлення, інвойси, PaymentIntent, платежі, джерела або метадані. Stripe розділяє деталізований звіт на окремі файли за секціями, тому імпортуйте файли платежів, повернень і комісій разом: рядки, що належать до виплати, яка вже імпортована, але ще не проведена, об'єднуються в існуючий пакет. Це робочий процес імпорту та проведення, керований файлами та кінцевими точками розрахунків, а не живий конектор Stripe; сторінка функцій перелічує те, що охоплює сторона банківських операцій і розрахунків.

Зіставляйте у такому порядку: платежі з інвойсами, повернення з початковими платежами, диспути з початковими платежами, рядки комісій із правилами комісій. Зберігайте комісії Stripe, коригування, резерви та рядки виплат окремо від зіставлення з інвойсами. Глосарій платіжних звірок Nordlet зазначає, що рядки комісій та коригувань за задумом не підлягають зіставленню з інвойсами; спрямовуйте незіставлені грошові елементи на транзитний рахунок. Ручне коригування використовує bank/settlements/match { lineId, invoiceId } із null в invoiceId для скасування зіставлення.

Потім проведіть один збалансований пакет:

POST /v1/bank/settlements/post

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

Чек-лист звірки

Виконуйте ці перевірки перед кожним закриттям періоду:

• Немає дублікатів balance_transaction_id
• Немає дублікатів пакету розрахунків (provider, payout_id)
• Сума нетто у рядках дорівнює нетто пакету
• Нетто пакету дорівнює банківській виплаті з урахуванням часових рамок і політики валют
• Кожне повернення коштів має початковий платіж або зафіксований виняток
• Кожен диспут має посилання на диспут або платіж
• Кожен переказ має ідентифікатор підключеного акаунта
• Кожен рядок platform_earning має визначене правило обробки комісії
• Транзитний рахунок дорівнює нулю або повністю перевірений, включаючи будь-які нерозпізнані категорії, зазначені в попередженні про проводку
• Кредиторська заборгованість перед продавцем не є від'ємною без затвердженої політики авансів або стягнення
• Проведені пакети неможливо повторно імпортувати або провести повторно безшумно
• Виплата у валюті, що відрізняється від базової валюти компанії, конвертується за курсом на дату виплати, а різниця порівняно з власним курсом кожного інвойсу відображається як реалізовані курсові різниці (прибуток або збиток); виплата, що містить кілька валют, відхиляється під час імпорту

Звіряйте на трьох рівнях: на рівні рядка (кожна транзакція має збережений ідентифікатор, категорію, суму, валюту, джерело), на рівні виплати (деталізовані нетто дорівнюють виплаті Stripe та банківському надходженню) та на рівні книги (проведений журнал збалансований і формує призначені позиції виручки, комісій, дебіторської заборгованості, зобов'язань перед продавцями та транзитних сум). Зокрема, для балансів продавців перевірте, чи вхідна кредиторська заборгованість перед продавцем плюс нова частка продавця мінус перекази та дійсні сторно дорівнюють вихідній кредиторській заборгованості перед продавцем.

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

FAQ

Чи є виплата зі Stripe виручкою платформи?

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

З яким звітом Stripe слід звірятися?

Зі звітом щодо звірки виплат, деталізованим (Payout reconciliation, itemized), оскільки він надає один рядок на балансову транзакцію з полем reporting_category, ідентифікатором automatic_payout_id, а також сумами брутто, комісій та нетто. Підсумок виплат у Панелі керування доводить лише загальну суму пакету. Якщо автоматичні виплати не активовані, натомість використовуйте звіт про баланс (Balance report).

Чи слід проводити переказ продавцю як витрати?

Ні. Частка продавця стає зобов'язанням у момент надходження платежу клієнта, а переказ погашає це зобов'язання. Відображення переказів як витрат призводить до подвійного обліку витрат і залишає кредиторську заборгованість перед продавцем завищеною назавжди.

Що відбувається з рядком Stripe, категорію якого імпортер не розпізнає?

Він проводиться на транзитний рахунок розрахунків (за замовчуванням 4440), а відповідь на проведення повертає попередження із назвами категорій, що туди потрапили. Резерви та незвичні коригування зазвичай потрапляють туди таким чином, і це зроблено навмисно: кошти залишаються видимими, а журнал залишається збалансованим, доки хтось не вирішить, куди вони належать.

Як обробляються повернення коштів, які розраховуються у виплаті пізнішого періоду?

Вони надходять як рядок refund у деталізованому звіті пізнішої виплати та зіставляються з початковим платежем через charge_id раніше зіставленого платежу. Повернення коштів, згенероване з експорту рівня платежів (Payments), у цьому випадку є лише приблизним, тому деталізований звіт є безпечнішим джерелом.

Подальше читання

• Імпорт банківських та платіжних операцій, включаючи звірку розрахунків зі Stripe
• Звірка платежів: зіставлення виплат ПСП з бухгалтерською книгою
• Субкниги продавців маркетплейса: виручка проти кредиторської заборгованості
• Як працюють платежі в інтеграції Connect (Stripe)