Субсчета продавцов на маркетплейсах: выручка и кредиторская задолженность

Самая распространенная ошибка в бухгалтерском учете маркетплейсов - отражение валового платежа покупателя в качестве выручки самой платформы. Покупатель платит 100 евро, эти 100 евро поступают на счет платежного провайдера, и всю сумму проводят по счетам реализации. Баланс на какое-то время сходится, выручка выглядит великолепно, а затем аудитор задает вопрос о том, где же отражены обязательства перед продавцом. А их нет, потому что доля продавца в размере 90 евро никогда не фиксировалась как задолженность.

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

Начните с анализа принципала и агента

Прежде чем переходить к структуре счетов, платформа должна определить, что именно она продает. Согласно стандарту ASC 606, оценка выполняется для каждого отдельного товара или услуги, и результат определяет, признается ли выручка в валовом или чистом объеме. Платформа может выступать принципалом для одной операции и агентом для другой.

При типичной продаже товаров продавца через маркетплейс платформа, как правило, является агентом. Она организует доставку товара продавца покупателю, не принимает на себя риски по товарно-материальным запасам, а ее вознаграждением выступает комиссия. В разъяснениях 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_id	Детализация обязательств, а не выручки
Комиссия платформы	Комиссионный доход	Выручка
НДС или налог с продаж	Обязательства по налогам	Обязательство
Комиссии платежного провайдера	Расходы на обработку платежей	Расход
Резервы продавца	Резервные обязательства	Зависит от условий договора
Возвраты	Контрвыручка или возвраты	Сторнирует исходный учет
Чарджбэки	Убыток, дебиторская задолженность или удержание с продавца	Зависит от того, кто несет убыток
Выплаты в ожидании подтверждения банка	Клиринговый счет выплат продавцам	Клиринговый счет
Нераспределенные суммы	Транзитный счет	Временное исключение

Каждая существенная проводка должна содержать идентификатор продавца, заказа, пакета выплат, платежного провайдера, валюту, юридическое лицо, налоговый статус, тип события, внешнюю ссылку и связь со сторнирующей операцией. Без этих данных субсчет продавца не сможет подтвердить отдельный баланс, а главная книга не сможет подтвердить общую сумму.

Вы можете реализовать субсчет в виде отдельного счета обязательств для каждого продавца, в виде единого счета кредиторской задолженности с аналитикой seller_id или через разделение на счета обязательств, резервов и клиринга выплат. Подход с единым счетом и аналитикой масштабируется лучше, как только вы переходите рубеж в несколько десятков продавцов. Согласуйте выбранную модель с бухгалтером, так как правила защиты средств и местное платежное законодательство могут влиять на требования к представлению таких средств. Технические аспекты формирования проводок описаны в нашем материале о API регистров с двойной записью для учета на маркетплейсах, на которых строится данная модель.

Отражение продажи с раздельными строками для продавца и платформы

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

Счет	Дебет	Кредит
Клиринговый счет платежного провайдера	100 €
Кредиторская задолженность - Продавец А		90 €
Комиссионный доход		10 €

Важнейший контрольный момент: 90 евро кредитуют обязательство, а не выручку. Платформа признает выручку в размере 10 евро. Именно к такому результату приводит пример маркетплейса в стандарте ASC 606 для агентской схемы, где платформа отражает свою комиссию, а не полную стоимость продажи товара продавцом.

Если налог взимается отдельно, добавьте строку обязательств по налогам и уменьшите показатель продавца или платформы в соответствии с налоговым анализом. Не следует включать налог в состав комиссии или задолженности перед продавцом ради удобства.

Исключите комиссии провайдера из расчетов выручки и кредиторской задолженности

Три понятия постоянно путают между собой: комиссию платформы, комиссию платежного провайдера и сумму выплаты. Это совершенно разные величины, и они затрагивают разные счета.

Покупатель платит 100 евро, комиссия платформы составляет 10 евро, провайдер удерживает 3 евро.

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

Если провести только чистые 97 евро, поступившие на банковский счет, вы одним движением сотрете валовые продажи, комиссию и расходы. В нашей справочной статье по сверке платежей подчеркивается тот же тезис: декомпозируйте расчеты, учитывайте комиссии провайдеров как расходы и никогда не подменяйте выручку чистым поступлением на счет.

Моделирование доступности средств, резервов и выплат как отдельных событий

Между моментом списания средств и поступлением денег на счет их статус меняется несколько раз. Каждое такое изменение заслуживает отдельной проводки, а резерв никогда не должен оформляться как необъяснимое сокращение выручки.

При переводе доступных средств в резерв:

Счет	Дебет	Кредит
Кредиторская задолженность - Продавец А	15 €
Резервные обязательства перед продавцом		15 €

При высвобождении резерва выполните обратную проводку. Общая сумма обязательств перед продавцом не изменилась; изменился лишь их статус. В документации Stripe описаны операции с резервами, которые увеличивают и высвобождают их, а также переводы для погашения давних отрицательных балансов, поэтому для таких операций требуются отдельные идентифицируемые счета, а не простая проводка сводным сальдо.

Выплаты отражаются через двухшаговую процедуру. На этапе одобрения:

Счет	Дебет	Кредит
Кредиторская задолженность - Продавец А	90 €
Клиринговый счет выплат продавцам		90 €

При подтверждении банковского расчета:

Счет	Дебет	Кредит
Клиринговый счет выплат продавцам	90 €
Банк		90 €

Если выплата не прошла, сторнируйте клиринговый счет обратно в кредиторскую задолженность перед продавцом. Выплата - это погашение обязательства, а не расход. Отражение выплаты в качестве расхода приведет к двоякому учету против продажи, по которой задолженность уже была зафиксирована. В Stripe статусы выплат (pending, in_transit, paid, failed, canceled) и ожидаемая дата поступления отделены от момента инициации, и эти даты не должны сливаться в единую временную метку.

Модель данных «от заказа до выплаты»

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

• 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 транзакции, продавцу и валюте

С чего следует начать

Сначала схематично опишите движение денежных средств, прежде чем переходить к плану счетов. Запишите каждое событие от получения платежа до высвобождения резерва и отметьте, какие из них создают выручку, какие - обязательства, а какие лишь изменяют текущий статус.

Затем постройте одну сквозную цепочку и докажите ее сбалансированность: обычная продажа, частичный возврат, чарджбэк после выплаты, удержание и высвобождение резерва, а также неудавшаяся выплата. Прогоните эти сценарии на известных ожидаемых балансах. Если контрольный счет задолженности перед продавцами равен сумме субсчетов, клиринг провайдера сходится с отчетом о расчетах, а банковский депозит соответствует идентификатору выплаты - у вас есть работающий фундамент.

Включайте блокировку периодов только после того, как первый месяц закрыт идеально чисто и без остатков на транзитном счете. Слишком раннее блокирование периодов приведет лишь к консервации ошибок.

Платформа Nordlet проводит расчеты по этой схеме «из коробки»: комиссия платформы поступает на счет комиссионного дохода, доля продавца - на кредиторскую задолженность перед продавцами, комиссии провайдера - на расходы по обработке платежей, а нераспределенные суммы направляются на транзитный счет. Отчетные периоды остаются открытыми до тех пор, пока вы не заблокируете их вручную, поэтому первый месяц можно закрыть сразу после обнуления транзитного счета. Полный перечень возможностей приведен на странице функций.

FAQ

Является ли платеж покупателя выручкой платформы?

Только для тех конкретных товаров или услуг, где платформа выступает принципалом. При продаже товаров продавца через маркетплейс по агентской схеме выручкой является комиссия, а доля продавца признается обязательством. Платформа может быть принципалом в части услуг фулфилмента и агентом в отношении самих товаров в рамках одного и того же заказа, поэтому оценка проводится для каждого отдельного товара или услуги, а не для компании в целом.

Должны ли резервы уменьшать выручку?

Нет. Резерв представляет собой перераспределение во времени и по рискам, а не корректировку выручки. Переводите средства со счета задолженности перед продавцом на счет резервных обязательств при их удержании и сторнируйте проводку при высвобождении. На выручку и комиссию факт резервирования средств продавца никак не влияет.

Как предотвратить повторные выплаты из-за повторных запросов вебхуков?

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

Может ли баланс продавца уходить в минус?

Да, и модель учета должна это допускать. Чарджбэк, поступивший после того, как продавцу уже была перечислена выплата, оставляет платформу либо с дебиторской задолженностью продавца, либо с убытком, который она принимает на себя. Сокрытие отрицательных балансов означает лишь маскировку неучтенного обязательства.

Почему следует сверять каждую выплату, а не месячный итог целиком?

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

Дополнительные материалы

• API регистров с двойной записью для учета на маркетплейсах
• Сверка платежей: сопоставление выплат PSP с регистрами учета
• Вопросы квалификации принципала и агента по стандарту ASC 606 (Deloitte)