Аналітичні рахунки продавців на маркетплейсі: виторг проти кредиторської заборгованості

Найпоширеніша помилка в бухгалтерському обліку маркетплейсів полягає в тому, що валовий платіж покупця трактується як виторг платформи. Покупець сплачує €100, ця сума надходить на рахунок платіжного провайдера, і хтось проводить її повністю на продаж. Облік певний час сходиться, виторг виглядає чудово, а потім аудитор запитує, де ж зобов'язання перед продавцем. Його немає, оскільки частка продавця у розмірі €90 ніколи не обліковувалася як заборгованість.

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

Почніть із висновку про роль принципала чи агента

Перш ніж будь-яка структура рахунків набуде значення, платформа має визначити, що саме вона продає. Відповідно до ASC 606, це оцінюється для кожного окремого товару чи послуги, і від цього залежить, чи буде виторг розгорнутим (gross), чи згорнутим (net). Платформа може бути принципалом для однієї операції та агентом для іншої.

Для типового продажу товарів продавця через маркетплейс платформа зазвичай виступає агентом. Вона організовує доставку продукту продавця покупцеві, не бере на себе ризики щодо запасів, а її винагородою є комісія. Методичні рекомендації Deloitte щодо визначення ролі принципала чи агента за ASC 606 базуються на критерії контролю: відповідальність за виконання зобов'язань, ризики щодо запасів та свобода ціноутворення є індикаторами, а не контрольним списком, який скасовує базову оцінку контролю.

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

• principal_agent_role
• specified_good_or_service
• commission_rule_id
• control_assessment_version
• effective_from / effective_to

Аудитор, який через два роки перевірятиме рядок чистої комісії, повинен бачити, чому не використовувався валовий показник. Як зазначає BillingPlatform у своєму огляді ASC 606 щодо принципалів і агентів, сама лише назва "маркетплейс" не вирішує питання. Його вирішує аналіз контролю.

Визначте баланс продавця до того, як напишете першу проводку

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

Щонайменше слід відстежувати такі категорії:

• Очікують (Pending): зароблені або зібрані кошти, які ще не підлягають виплаті
• Доступні (Available): кошти, що відповідають правилам платформи для виплати
• Зарезервовані (Reserved): утримані на випадок очікуваних повернень, суперечок чи чарджбеків
• Виплачені (Paid out): переказані або надіслані на розрахунок
• Від'ємні (Negative): сума, яку продавець винний платформі та яка підлягає стягненню з майбутніх надходжень
• Транзитні (Suspense): отримані кошти, для яких ще не визначено продавця або порядок обліку

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

План рахунків та виміри, які мають значення

Робоча початкова структура тримає транзитні рахунки, зобов'язання та виторг окремо, а також містить вимір продавця (seller dimension) для кожної суттєвої операції.

Призначення	Рахунок або вимір	Облік
Кошти платіжного провайдера до розрахунку	Транзитний рахунок платіжного провайдера	Транзитний актив
Виплата від провайдера на банківському рахунку	Банк	Актив
Зароблена, але не виплачена сума продавцю	Заборгованість перед продавцями	Зобов'язання
Деталізація на рівні продавця	Вимір seller_id	Деталізація зобов'язань, не виторг
Комісія платформи	Комісійний виторг	Виторг
ПДВ або податок з продажів	Податкові зобов'язання	Зобов'язання
Комісії платіжного провайдера	Витрати на обробку платежів	Витрати
Резерви продавця	Зобов'язання за резервами	Залежить від договору
Повернення коштів	Контрівіторг або повернення	Сторнує початкову операцію
Чарджбеки	Збиток, дебіторська заборгованість або стягнення з продавця	Залежить від того, хто бере на себе збиток
Виплати, що очікують підтвердження банку	Транзитний рахунок виплат продавцям	Транзитний рахунок

• Нерозподілені суми | Транзитні (Suspense) | Тимчасовий виняток |

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

Ви можете реалізувати аналітичний облік як один рахунок зобов'язань на кожного продавця, як один загальний рахунок кредиторської заборгованості з виміром seller_id або як розподіл між рахунками заборгованості, резервів і транзитних виплат. Підхід із загальним рахунком та вимірами масштабується краще, коли у вас є кілька десятків продавців. Узгодьте цю модель зі своїм бухгалтером, оскільки правила захисту коштів та місцеве платіжне законодавство можуть впливати на те, як ці кошти мають відображатися у звітності. Що стосується механіки проводок, наша стаття про API систем подвійної запису для обліку на маркетплейсах описує базові принципи головної книги, на яких базується ця модель.

Відображення продажу з окремими рядками для продавця та платформи

Візьмімо агентський продаж: покупець сплачує €100, комісія платформи становить €10, продавець заробляє €90. У момент, коли комісія та право на винагороду продавця зароблені:

Рахунок	Дебет	Кредит
Транзитний рахунок платіжного провайдера	€100
Заборгованість перед продавцем — Продавець А		€90
Комісійний виторг		€10

Важливий момент контролю: €90 кредитують зобов'язання, а не виторг. Платформа визнає виторг у розмірі €10. Цього результату вимагає приклад маркетплейсу в ASC 606 для агента, де платформа визнає свою комісію, а не повну суму продажу продавця.

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

Тримайте комісії провайдера осторонь від виторгу та заборгованості

Три речі постійно плутають: комісію платформи, комісію платіжного провайдера та суму виплати. Вони різні і потрапляють на різні рахунки.

Покупець сплачує €100, комісія становить €10, провайдер утримує €3.

• Комісійний виторг залишається на рівні €10, якщо це передбачено договором.
• Комісія провайдера €3 є витратами.
• Заборгованість перед продавцем становить €90, якщо в договорі не зазначено, що продавець сам сплачує комісію за обробку платежу. Тільки в цьому випадку сума зменшується до €87 із віднесенням €3 на рахунок продавця.

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

Моделювання доступності, резервів та виплат як окремих подій

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

Коли доступні кошти переводяться в резерв:

Рахунок	Дебет	Кредит
Заборгованість перед продавцем — Продавець А	€15
Зобов'язання за резервами продавця		€15

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

Виплати проходять у два етапи. На етапі затвердження:

Рахунок	Дебет	Кредит
Заборгованість перед продавцем — Продавець А	€90
Транзитний рахунок виплат продавцям		€90

На етапі підтвердження розрахунку банком:

Рахунок	Дебет	Кредит
Транзитний рахунок виплат продавцям	€90
Банк		€90

Якщо виплата не вдалася, сторнуйте транзитний рахунок назад на заборгованість перед продавцем. Виплата є погашенням зобов'язання, а не витратою. Відображення її як витрати призводить до подвійного обліку проти продажу, в якому вже було зафіксовано заборгованість. Stripe розділяє статус виплати (pending, in_transit, paid, failed, canceled) та очікувану дату надходження від моменту ініціації, і ці дати не повинні згортатися в одну позначку часу.

Модель даних від замовлення до виплати

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

• seller_id, event_id, order_id
• event_type (sale, refund, chargeback, reserve_hold, reserve_release, payout, adjustment)
• effective_date, posting_date
• currency, direction, gross, commission, fees, reserve
• refund_ref / dispute_ref
• payout_batch_id
• reversal_of
• source_status, idempotency_key

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

Кінцевий баланс продавця
= початковий баланс
+ кредити продавця
− дебети продавця
− виплати
± рух резервів
± коригування

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

• Подія журналу продавця: seller_id:order_id:event_type:version
• Пакет виплат: processor:payout_id
• Подія провайдера: processor:event_type:processor_event_id

Власні інструкції Stripe щодо вебхуків попереджають, що дублювання подій трапляється, тому виявлення дублікатів є обов'язковим. Проведені записи залишаються незмінними. Коригування виконуються через сторнуючу проводку плюс виправлену проводку, і саме ваш власний конверт подій містить посилання reversal_of та причину. Головна книга містить самі проводки, а не це посилання: Nordlet надає функції створення, отримання та переліку транзакцій у своєму довіднику з API без можливості оновлення чи видалення, тому коригування завжди є новою транзакцією, а не редагуванням існуючої.

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

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

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

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

Звіряйте дані за кожною виплатою, а не за місяць

Розкладіть кожен розрахунок провайдера на складові перед проведенням і звіряйте кожну виплату окремо, а не суму за весь місяць:

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

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

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

Поширені помилки в обліку

Тип помилки	Наслідки	Контроль
Валовий платіж покупця проведено як виторг	Завищує виторг, приховує зобов'язання перед продавцем	Розділяйте заборгованість та комісію в момент їх заробітку
Проведено лише чисті депозити	Втрачаються валові суми, комісії, повернення, резерви	Розкладіть кожну виплату на складові
Виплата відображена як витрата	Спотворює погашення зобов'язання	Дебетуйте заборгованість перед продавцем при виплаті
Єдине поле балансу продавця	Змішує очікувані, доступні, зарезервовані та виплачені кошти	Обліковуйте стани балансу окремо
Комісія розраховується в момент виплати	Виторг прив'язується до графіку виплат	Визнавайте комісію в момент її заробітку
Резерв трактується як зменшення виторгу	Спотворює часові рамки та ризики	Обліковуйте утримання, вивільнення та використання окремо
Повернення застосовується до останньої виплати	Порушує прив'язку до замовлення	Пов'язуйте повернення з початковою транзакцією
Редагування проведених записів	Знищує аудиторський слід	Використовуйте сторно та повторне проведення
Повторення вебхуків	Подвійні нарахування та виплати	Використовуйте ключі ідемпотентності та пошук дублікатів
Звірка лише за сумою і датою	Колізія різних операцій	Звіряйте за ID виплати, ID транзакції, продавцем і валютою

З чого варто почати

Сформуйте схему руху коштів, перш ніж торкатися плану рахунків. Запишіть кожну подію від надходження платежу до вивільнення резерву та позначте, які з них створюють виторг, які — зобов'язання, а які лише змінюють статус.

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

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

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

FAQ

Чи буває платіж покупця виторгом платформи?

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

Чи повинні резерви зменшувати виторг?

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

Як зупинити дублювання виплат через повтори вебхуків?

Додайте ключ ідемпотентності до кожної зовнішньої події, наприклад processor:payout_id для пакетів виплат, і виявляйте дублікати під час запису. Провайдери прямо попереджають про можливість повторної доставки вебхуків, тому головна книга повинна відхиляти другу спробу, а не проводити її знову.

Чи може баланс продавця бути від'ємним?

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

Чому варто звіряти кожну виплату окремо, а не місячний підсумок?

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

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

• API систем подвійного запису для обліку на маркетплейсах
• Звірка платежів: зіставлення виплат PSP з головною книгою
• Принципи визначення ролі принципала чи агента за ASC 606 (Deloitte)