Stripe Connect Marketplace Accounting Workflow

Q: Как обрабатываются возвраты, проходящие в более поздней выплате?

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

A practitioner's guide to posting charges, fees, transfers, refunds, disputes, and reserves into a marketplace ledger that reconciles cleanly.

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

В этом руководстве каждая категория балансовых транзакций (balance transaction) Stripe распределяется по соответствующим бухгалтерским счетам: дебиторская задолженность, комиссионная выручка, обязательства перед продавцами, расходы на обработку платежей и транзитные счета. В качестве механизма проводок используются задокументированные эндпоинты импорта и расчетов Nordlet, приводится практический пример расчета, а в завершение предлагается контрольный список сверки (reconciliation checklist), который можно выполнять перед каждым закрытием периода.

Определите модель проведения платежей в 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

Каждая стрелка представляет собой отдельную балансовую транзакцию со своим ID, категорией, суммой и датами. Рассматривайте баланс Stripe как клиринговый счет банковского типа: платежи поступают на него, комиссии и переводы уходят с него, а выплата переводит остаток на реальный банковский счет. Документация Nordlet по импорту банковских и платежных операций рекомендует именно такой подход для обычных операций со Stripe.

Выберите правильный исходный отчет 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 заявляет, что ежедневные данные отчетов обычно доступны к полудню следующего дня, а мгновенные выплаты (instant payouts) невозможно корректно распределить по отдельным транзакциям, поэтому они требуют отдельной сверки истории транзакций.

Классифицируйте каждую балансовую транзакцию по категориям

Используйте reporting_category в качестве основного классификатора, а затем проверяйте source_id, charge_id и описания. Важные соответствия:

Операция в Stripe	Категория отчетности (`reporting_category`)	Бухгалтерская интерпретация
Платеж клиента, картой или через местный метод оплаты	`charge`	Дебиторская задолженность за счет клиентов или погашение продажи
Возврат	`refund`	Сторнирование первоначального платежа клиента
Комиссия за обработку, удержанная Stripe	`fee`	Расходы на обработку платежей
Комиссия платформы (application 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

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

Временной ловушка: возврат часто проходит в рамках выплаты, которая следует позже самого платежа. Отдавайте предпочтение детализированному отчету по сверке выплат, а не синтезированному возврату из экспорта на уровне платежей. Документация Nordlet прямо предупреждает, что возврат, полученный из экспорта платежей (Payments export), является лишь приближением, если возврат выплачивается позже. Импортер расчетов может принять строку возврата, сопоставить ее с исходной продажей и сторнировать дебиторскую задолженность при проведении пакета.

Учитывайте споры (чарджбеки) отдельно от возвратов

Спор (dispute) — это претензия держателя карты или банка-эмитента, причем 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, платежи (charge), источники (source) или метаданные. Stripe разбивает детализированный отчет на отдельные файлы по разделам, поэтому импортируйте файлы платежей, возвратов и комиссий вместе: строки, принадлежащие уже импортированной, но еще не проведенной выплате, объединяются в существующий пакет. Это рабочий процесс импорта и проведения, управляемый файлами и эндпоинтами расчетов, а не живой коннектор Stripe; на странице возможностей перечислено, что именно охватывает банковский и расчетный функционал.

Сопоставляйте в следующем порядке: платежи с инвойсами, возвраты с исходными платежами, споры с исходными платежами, строки комиссий с правилами их учета. Не включайте комиссии Stripe, корректировки, резервы и строки выплат в сопоставление с инвойсами. В глоссарии по платежной сверке Nordlet указано, что строки комиссий и корректировок по дизайну не сопоставляются с инвойсами; направляйте неразнесенные денежные статьи на транзитный счет (suspense). Ручная корректировка выполняется через bank/settlements/match { lineId, invoiceId }, причем передача null в качестве invoiceId отменяет сопоставление.

Затем проведите один сбалансированный пакет:

POST /v1/bank/settlements/post

Это создает один сбалансированный журнал, закрывает сопоставленные инвойсы, дебетует счет учета в банке на сумму нетто-выплаты, дебетовает расходы на комиссии, кредитует дебиторскую задолженность по платежам, сторнирует дебиторскую задолженность по возвратам и чарджбекам, разделяет несопоставленные платежи маркетплейса между комиссионной выручкой и обязательствами перед продавцами при указании параметра commissionPercent, а неразнесенные суммы отправляет на транзитный счет. Любая нераспознанная категория также попадает на транзитный счет, причем в ответе эти категории перечисляются в предупреждении (warning), а не поглощаются молча.

Контрольный список сверки

Выполняйте эти проверки перед каждым закрытием периода:

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

Сверка выполняется на трех уровнях: на уровне строк (каждая транзакция имеет сохраненный ID, категорию, сумму, валюту, источник), на уровне выплат (нетто-итоги по деталям равны выплате Stripe и поступлению в банк) и на уровне регистров (проведенный журнал сбалансирован и формирует корректные остатки по выручке, комиссиям, дебиторской задолженности, обязательствам перед продавцами и транзитным счетам). Конкретно для балансов продавцов проверяйте, что входящая кредиторская задолженность перед продавцами плюс новая доля продавца за вычетом переводов и действительных сторно равна исходящей кредиторской задолженности.

Повторяющаяся проблема в учете любого маркетплейса сводится к тому же, с чего все и началось: свертывание структурированной выплаты до единого числа. Держите компоненты раздельными, привязывайте каждый к стабильному идентификатору Stripe и используйте транзитный счет для всего, что вы пока не можете объяснить. Чистое закрытие периода — это то, чему доверяет аудитор.

FAQ

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

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

С каким отчетом Stripe следует выполнять сверку?

С детализированным отчетом по сверке выплат (Payout reconciliation, itemized), поскольку он предоставляет по одной строке на каждую балансовую транзакцию с указанием reporting_category, automatic_payout_id, а также сумм брутто, комиссий и нетто. Сводка выплат в панели управления доказывает только итоговую сумму пакета. Если автоматические выплаты не включены, используйте отчет о балансе.

Следует ли отражать перевод продавцу как расход?

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

Что происходит со строкой Stripe, категорию которой импортер не распознает?

Она проводится на транзитный расчетный счет (suspense account, по умолчанию 4440), а в ответ на проводку возвращается предупреждение с перечислением таких категорий. Резервы и необычные корректировки обычно попадают туда именно так, и это сделано намеренно: деньги остаются на виду, а журнал остается сбалансированным до тех пор, пока кто-то не решит, куда они относятся.

Как обрабатываются возвраты, проходящие в более поздней выплате?

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