Marketplace Seller Subledgers: Revenue vs Payables
A practitioner's guide to separating customer cash, platform commission, seller payables, reserves, and payouts with balanced journal entries and a working order-to-payout data model.
Най-честата грешка в счетоводството на платформи (marketplace) е третирането на брутното плащане от купувача като приходи на самата платформа. Клиент плаща 100 EUR, сумата попада в сметката на разплащателния доставчик (processor) и някой отчита цялата сума като продажби. Сметките излизат за известно време, приходите изглеждат страхотно и тогава одитор пита къде е задължението към търговеца. Такова няма, защото делът на търговеца в размер на 90 EUR никога не е бил отчетен като дължима сума.
Решението е структурно, а не козметично. Една платформа се нуждае от модел на главна книга (ledger), който разделя пет отделни потока още от първото записване: парични средства от клиенти в процес на превод, приходи от комисиони на платформата, задължения към търговци, такси и резерви. Изплащанията към търговците (payouts) са шести събитийен процес, който погасява задължението, а не самостоятелно събитие за приходи или разходи. Това ръководство показва балансираните счетоводни статии и модела на данните, които поддържат тези потоци отделни.
Започнете с извода за принципал срещу комисионер (principal-versus-agent)
Преди да има значение каквато и да е сметкоплавна структура, платформата трябва да определи какво точно продава. Съгласно ASC 606 това се оценява за всеки конкретен стока или услуга, като отговорът определя дали приходите са брутни или нето. Една платформа може да бъде принципал за една операция и комисионер (agent) за друга.
За типична продажба в платформа на стоки от външен търговец, платформата обикновено е комисионер (agent). Тя урежда доставката на продукта на търговеца до купувача, не носи риска от складови наличности и възнаграждението ѝ е под формата на комисиона. Насоките на Deloitte за оценката принципал срещу комисионер по ASC 606 поставят акцента върху контрола: отговорността за изпълнение на обещанието, рискът с наличностите и свободата при ценообразуването са индикатори, а не контролен списък, който отменя основната оценка на контрола.
Причината това да е част от дизайна на главната книга, а не просто вътрешна бележка, е, че този извод определя всяка следваща счетоводна статия. Ако платформата е комисионер, делът на търговеца е задължение в момента на неговото спечелване. Ако тя е принципал за услуга по изпълнение на поръчката или гаранция, тази част представлява приходи за платформата. Съхранявайте този извод като данни:
principal_agent_rolespecified_good_or_servicecommission_rule_idcontrol_assessment_versioneffective_from/effective_to
Лице, което преглежда ред с нетни комисиони две години по-късно, трябва да може да види защо не са използвани брутните суми. Както BillingPlatform отбелязва относно ASC 606 принципал срещу комисионер, етикетът „платформа“ не решава въпроса. Анализът на контрола го прави.
Дефинирайте баланса на търговеца, преди да напишете дори едно счетоводно правило
„Балансът на търговеца“ не е едно цяло число. Един търговец може да има отличен общ баланс, но нулева налична сума за изплащане, защото средствата все още са в процес на изчакване или са задържани като резерв. Ако слеете тези състояния, ще отчетете погрешно какво може да изтегли търговецът и какво все още му дължи платформата.
Най-малкото проследявайте:
- В процес на изчакване (Pending): спечелени или събрани средства, които все още не отговарят на условията за изплащане
- Налични (Available): отговарящи на условията за изплащане съгласно правилата на платформата
- Задържани в резерв (Reserved): удържани срещу очаквани възстановявания на суми (refunds), спорове или оспорвани плащания (chargebacks)
- Изплатени (Paid out): прехвърлени или подадени за уреждане
- Отрицателни (Negative): сума, която търговецът дължи и подлежи на възстановяване от бъдещи постъпления
- Временни (Suspense): получени, но търговецът или третирането им все още не са установени
Доставчиците на платежни услуги вече моделират това разграничение. Stripe разделя всяка свързана сметка на чакащи и налични баланси и поддържа резервен баланс на ниво платформа за определени отрицателни баланси на търговци. Ако платежният процесор прави това разделение, главната книга също трябва да го прави, иначе сверяването никога няма да излезе.
Сметкопланът и измеренията, които имат значение
Една работеща начална структура държи клиринговите сметки, пасивите и приходите отделно и носa измерение (dimension) за търговеца при всяко съществено отчитане.
| Цел | Сметка или измерение | Третиране |
|---|---|---|
| Средства в процесора, очакващи уреждане | Клирингова сметка на разплащателен процесор | Клирингов актив |
| Изплатени средства от процесор по банкова сметка | Банка | Актив |
| Спечелена, но неизплатена сума на търговец | Задължения към търговци (Payables) | Пасив |
| Подробности на ниво търговец | Измерение seller_id |
Детайл към пасив, не приходи |
| Комисиона на платформата | Приходи от комисиони | Приходи |
| ДДС или данък върху продажбите | Данъчни задължения | Пасив |
| Такси на процесора | Разходи за обработка на плащания | Разход |
| Резерви на търговеца | Резервни пасиви | Зависи от договора |
| Възстановявания на суми | Коррекция на приходи (Contra-revenue) или възстановявания | Обратно на първоначалното третиране |
| Оспорени плащания (Chargebacks) | Загуба, вземане или възстановяване от търговец | Зависи кой поема загубата |
| Изплащания, очакващи банково потвърждение | Клирингова сметка за изплащания към търговци | Клирингова сметка |
| Неразпределени суми | Временна сметка (Suspense) | Временно изключение |
Всяко съществено счетоводно записване трябва да носи данни за търговеца, поръчката, партидата за изплащане, процесора, валутата, юридическото лице, данъчното третиране, типа събитие, външната препратка и евентуалната връзка за сторниране. Без тях подсметката на търговеца не може да докаже отделния баланс, а главната книга не може да докаже общата сума.
Можете да реализирате подсметката като едно задължение на сметка за всеки търговец, като една обща сметка за задължения с измерение seller_id или чрез разделяне на задължения, резерви и клиринг на изплащанията. Подходът с обща сметка и измерение се мащабира по-добре, след като надхвърлите няколко десетки търговци. Изберете модела заедно със своя счетоводител, тъй като правилата за защита на средствата и местните регулации за плащанията могат да повлияят на начина, по който средствата трябва да бъдат представени. За техническата страна на записванията, нашата статия за - APIs за двустранно счетоводство за платформи разглежда основните примитиви на главната книга, върху които е изграден този модел.
Отчетете продажбата с отделни редове за търговеца и платформата
Вземете за пример продажба чрез комисионер: клиентът плаща 100 EUR, комисионата на платформата е 10 EUR, а търговецът печели 90 EUR. В момента на придобиване на правото върху комисионата и дела на търговеца:
| Сметка | Дебит | Кредит |
|---|---|---|
| Клирингова сметка на разплащателен процесор | 100 EUR | |
| Задължения към търговец – Търговец А | 90 EUR | |
| Приходи от комисиони | 10 EUR |
Контролът, който има значение: 90 EUR се кредитират по сметка за пасиви, а не като приходи. Платформата отчита 10 EUR приходи. Това е резултатът, който примерът с платформа по ASC 606 достига за комисионер, при който платформата отчита своята комисиона, а не цялата сума на продажбата на търговеца.
Ако данъкът се събира отделно, добавете реда за данъчни задължения и намалете сумата за търговеца или платформата според данъчния извод. Не включвайте данъка в комисионата или задължението към търговеца за удобство.
Дръжте таксите на процесора извън сметките за приходи и задължения
Три неща се бъркат постоянно: комисиона на платформата, такса на процесора и сума за изплащане. Те са различни и се отразяват в различни сметки.
Клиентът плаща 100 EUR, комисионата е 10 EUR, а процесорът задържа 3 EUR.
- Приходите от комисиони остават 10 EUR, ако това е заложено в договора.
- Таксата на процесора в размер на 3 EUR е разход.
- Задължението към търговеца е 90 EUR, освен ако договорът не предвижда, че търговецът поема таксата за обработка на плащането. Само тогава то спада до 87 EUR със съответваща такса от 3 EUR, начислена на търговеца.
Отчитането единствено на нетните 97 EUR, които постъпват в банковата сметка, заличава брутната продажба, комисионата и таксата с едно движение. Нашата справка за съгласуване на плащания прави същата забележка: разглобете сетълмента на съставните му части, третирайте таксите на процесора като разходи и никога не позволявайте на нетния депозит да замества приходите.
Моделирайте наличността, резервите и изплащанията като отделни събития
Парите променят статуса си няколко пъти между момента на задържане и уреждането им в брой. Всеки преход заслужава собствена счетоводна статия, като резервът никога не е необяснено намаление на приходите.
Когато наличните средства се прехвърлят в резерв:
| Сметка | Дебит | Кредит |
|---|---|---|
| Задължения към търговец – Търговец А | 15 EUR | |
| Пасиви по резерви на търговец | 15 EUR |
Когато резервът бъде освободен, сторнирайте го. Общото задължение към търговеца не се е променило, променил се е неговият статус. Stripe документира транзакции с резерви, които увеличават и освобождават резерви, както и преводи за събиране на дългогодишни отрицателни баланси, поради което за тях са необходими разпознаваеми сметки, а не еднократно нетиране.
Изплащанията получават двуетапно третиране. При одобрение:
| Сметка | Дебит | Кредит |
|---|---|---|
| Задължения към търговец – Търговец А | 90 EUR | |
| Клирингова сметка за изплащания към търговци | 90 EUR |
При потвърдено банково плащане:
| Сметка | Дебит | Кредит |
|---|---|---|
| Клирингова сметка за изплащания към търговци | 90 EUR | |
| Банка | 90 EUR |
Ако изплащането е неуспешно, върнете сумата от клиринговата сметка обратно в задълженията към търговеца. Изплащането е погасяване на пасив, а не разход. Третирането му като разход води до двойно отчитане спрямо продажбата, която вече е регистрирала задължението. Stripe отделя статуса на изплащането (pending, in_transit, paid, failed, canceled) и очакваната дата на пристигане от неговото иницииране, като тези дати не трябва да се сливат в едно времеви щамп.
Моделът на данните от поръчка до изплащане
Подсметката работи със събития, а не с текущия статус на поръчката в приложението. Всяко събитие, засягащо търговеца, носи еднакъв пакет от данни (envelope):
seller_id,event_id,order_idevent_type(продажба, възстановяване, оспорване на плащане, задържане на резерв, освобождаване на резерв, изплащане, корекция)effective_date,posting_datecurrency,direction,gross,commission,fees,reserverefund_ref/dispute_refpayout_batch_idreversal_ofsource_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 справочник и няма функции за актуализиране или изтриване, така че корекцията винаги е нова транзакция, а не редакция.
Възстановяванията на суми и оспорените плащания се свързват обратно, те никога не се движат свободно
Възстановяване на сума, което се появява в изплащането през следващата седмица, никога не трябва да се превръща в ново отрицателно продажно число, прикрепено към това изплащане. Свържете го с оригиналната транзакция и запазете първоначалното разпределение за търговеца. В зависимост от договора:
- Сторнирайте комисионата, ако договорът предвижда нейното възстановяване
- Дебитирайте задълженията към търговеца, ако той поема възстановяването
- Дебитирайте сметка за загуби на платформата, ако тя я поема
- Увеличете резерва, докато спорът е отворен, и го освободете или присходете при разрешаването му
Оспорените плащания (chargebacks) след изплащане са моментът, в който се появяват отрицателни баланси. Парите на търговеца вече ги няма, така че платформата или ги възстановява от бъдещи постъпления, или поема загубата. Моделът трябва да позволява отрицателни баланси на търговци и да дефинира правилото за възстановяване. Отчетността на Adyen за платформи показва как възстановяванията и оспорените плащания генерират отделни дебитни редове за всеки притежател на сметка, което е точно степента на детайлност, към която трябва да се стремите.
Сверявайте по всяко изплащане, а не на месечна база
Разглобете всеки сетълмент на процесора преди отчитане и съгласувайте всяко изплащане, вместо да агрегирате цял месец:
Брутни такси
− възстановявания на суми
− такси на процесора
− оспорени плащания
± резерви и корекции
= нетно изплащане от процесора
След това докажете, че четири баланса съвпадат за всеки търговец и валута: подсметката на търговеца, балансът на търговеца при процесора, отчетът за изплащанията и банковият клиринг. Когато се различават, класифицирайте разликата (времеви интервал, липсващо събитие, дубликат, погрешно приписване, погрешна валута, неуспешно изплащане, оспорено плащане, отчетено на грешната страна). Скриването на разликите чрез нетиране е начинът, по който грешките се компенсират взаимно и оцеляват до следващото приключване.
Агрегирането на цял месец позволява на времевите разлики да се неутрализират и прикрива реални пробиви. Съгласуването на база изплащания, обвързано с идентификатор на изплащането и референтен номер на транзакцията, а не само по сума и дата, ги улавя навреме.
Чести грешки и неизправности
| Грешка | Защо е вредна | Контрол |
|---|---|---|
| Брутното плащане от клиента е отчетено като приходи | Надува приходите, прикрива задълженията към търговеца | Разделете задълженията и комисионата в момента на печелене |
| Отчетени са само нетните депозити | Губи брутната сума, таксите, възстановяванията, резервите | Разглобете всеки сетълмент |
| Изплащането е заведено като разход | Представя погрешно погасяването на пасив | Дебитирайте задълженията към търговеца при изплащане |
| Едно поле за баланс на търговеца | Смесва чакащи, налични, резервирани и изплатени суми | Проследявайте състоянията на баланса изрично |
| Комисионата се изчислява в момента на изплащането | Приходите следват графика на изплащанията | Признавайте комисионата, когато е спечелена |
| Резервът се третира като намаление на приходите | Затъмнява времевия интервал и риска | Проследявайте задържането, освобождаването и усвояването поотделно |
| Възстановяването се прилага към последното изплащане | Нарушава обвързването с поръчката | Свържете възстановяването с оригиналната транзакция |
| Редактиране на отчетени записи | Унищожава одиторската следа | Сторнирайте и качете отново |
| Повторно изпълнени уебхукове | Дублирани кредити и изплащания | Идепотентни ключове, откриване на дубликати |
| Съгласуване само по сума и дата | Различни елементи се сблъскват | Съгласувайте по ID на изплащане, ID на транзакция, търговец, валута |
Какво бих направил първо
Картографирайте паричния поток, преди да докоснете сметкоплана. Запишете всяко събитие от задържането на плащането до освобождаването на резерва и отбележете кои от тях създават приходи, кои създават пасив и кои само променят статуса.
След това изградете един завършен поток от край до край и докажете, че той е балансиран: нормална продажба, частично възстановяване, оспорване на плащане след изплащане, задържан и освободен резерв и неуспешно изплащане. Изпълнете ги с предварително известни очаквани баланси. Ако контролната сметка за задължения към търговци е равна на сумата от подсметката, клирингът на процесора съответства на отчета за сетълмента, а банковият депозит съответства на идентификатора на изплащането, имате работеща основа.
Включете заключването на периоди едва след като първият месец приключи чисто и с празна временна сметка. Заключването твърде рано само замразява грешките.
Nordlet публикува сетълменти по тези правила още с първоначалната настройка: комисионата на платформата отива в приходи от комисиони, делът на търговеца – в задължения към търговец, таксите на процесора – в разходи за обработка на плащания, а всичко, което все още не е разпределено – във временна сметка. Периодите в главната книга остават отворени, докато не ги заключите изрично, така че първият месец може да бъде приключен, след като временната сметка е празна. Страницата с функции изброява какво е включено.
FAQ
Дали плащането на купувача някога е приход на платформата?
Само за конкретни стоки или услуги, при които платформата е принципал. За продажба в платформа от типа комисионер на стоки от външен търговец приходите са комисионата, а делът на търговеца е задължение. Една платформа може да бъде принципал за услуга по изпълнение и комисионер за същинските стоки в рамките на една и съща поръчка, така че оценката е за всяка конкретна стока или услуга, а не за цялата компания.
Трябва ли резервите да намаляват приходите?
Не. Резервът е разпределение на времето и риска, а не корекция на приходите. Прехвърлете средства от задълженията към търговеца в пасиви по резерви, когато ги задържите, и сторнирайте при освобождаване. Приходите и комисионите не се влияят от това дали парите на търговеца в момента са резервирани.
Как да спра дублираните изплащания от повторни опити на уебхукове?
Прикрепете ключ за идепотентност към всяко външно събитие, като например processor:payout_id за партиди за изплащане, и откривайте дублирани събития при запис. Доставчиците изрично предупреждават, че се случват дублирани доставки на уебхукове, така че главната книга трябва да отхвърли втория опит, вместо да го отчита отново.
Може ли балансът на търговец да стане отрицателен?
Да, и моделът трябва да го позволява. Оспорване на плащане (chargeback), което пристигне след като търговецът вече е бил изплатен, оставя платформата или с вземане от търговеца, или със загуба, която тя поема. Потискането на отрицателните баланси просто скрива неотчетено задължение.
Защо да съгласуваме всяко изплащане вместо месечния общ сбор?
Защото времевите разлики и грешките се неутрализират, когато агрегирате цял месец, така че общите суми могат да излязат, докато отделните транзакции са грешни. Съгласуването на база изплащания, съпоставено по ID на изплащане и транзакция, извежда на повърхността липсващи събития, дубликати и погрешно приписани оспорени плащания преди края на периода.