Какво представлява API за двустранно счетоводно записване за електронни пазари (marketplace)?
Един API за двустранно счетоводно записване отчита движението на парични средства на електронните пазари като балансирани и неизменяеми счетоводни статии, така че винаги да знаете на кого и какво се дължи и защо.
Един електронен пазар (marketplace) може да изглежда стабилен в таблицата си с orders (поръчки) и въпреки това сметките му за паричните средства да са грешни. Поръчката показва състояние „платено“. Таблото за управление на продавача показва салдо. Но нищо в тази таблица не доказва с каква наличност разполага платформата в брой, колко дължи на всеки продавач, каква част от плащането е приход от комисионна или какъв ДДС подлежи на плащане към момента. API за двустранно счетоводно записване (double-entry ledger API) съществува именно за да отчита тези финансови последствия правилно - по една балансирана транзакция наведнъж.
Казано най-просто: API за двустранно счетоводно записване е програмуруема счетоводна система. Вашето приложение му изпраща финансово събитие (например получено плащане или одобрено изплащане към продавач), а счетоводната книга (ledger) записва това събитие като счетоводна статия (journal) с равни дебити и кредити по съответните сметки. Тя не превежда пари. Тя отчита истината за парите, които са се движили на друго място.
Какво означава „двустранно счетоводно записване“ в този контекст
Счетоводната книга (ledger) е запис на промените по сметките, а не таблица, която съдържа само последното салдо.една работеща счетоводна книга се основава на три свързани понятия:
- Сметка (Account): наименована финансова позиция, като например вземания от платежен оператор, задължения към продавачи, приходи от комисионни или дължим ДДС.
- Транзакция/статия (Transaction / journal): едно атомно финансово събитие, съдържащо множество балансирани редове.
- Запис/позиция (Entry / posting): един единствен дебитен или кредитен ред вътре в тази транзакция.
Инвариантът, който държи цялата архитектура стабилна, е прост: общият размер на дебитите е равен на общия размер на кредитите за всяка транзакция и във всяка валута. API за счетоводни книги обикновено отхвърлят небалансираните записи, преди те да стигнат до хранилището с данни. Документацията на Modern Treasury определя една счетоводна транзакция като включваща две или повече сметки с поне един дебит и един кредит с равни общи суми, и третира вече записаната транзакция като неизменяема (immutable).
Двустранното записване не означава точно два реда. Една единствена продажба на електронен пазар често изисква един дебит и няколко кредита. Това е частта, която хората тълкуват погрешно най-често.
Защо електронните пазари се нуждаят от счетоводна книга, а не просто от таблица с плащания
Електронният пазар поддържа няколко финансови отношения едновременно. Купувачът плаща. Операторът извършва сетълмент. Платформата може временно да контролира средствата. Продавачът печели дял от сумата. Платформата задържа комисионна. Начислява се данък за плащане. Възможно е да се задържи гаранционен резерв (reserve). По-късно изплащането (payout) превежда пари навън, а евентуални възстановявания на суми (refunds) или оспорвани плащания (chargebacks) отменя части от тях.
Таблицата с payments (плащания) може да ви каже търговския статус на една поръчка. Тя не може надеждно да ви каже:
- какъв е размерът на вземанията от платежния оператор или наличните парични средства
- колко се дължи на всеки отделен продавач
- какъв приход принадлежи на самите нас като платформа
- колко ДДС подлежи на плащане и в коя държава
- каква сума е запазена срещу възстановявания или спорове
- дали дадено изплащане е намалило точното задължение към съответния продавач
- дали сетълментите от платежния оператор съответстват на очакванията на платформата
Ръководството на Nordlet за API за двустранно счетоводно записване за счетоводство на електронни пазари чертае границата ясно: таблиците на приложението описват състоянието на продуктите, докато счетоводната книга отчита финансовите последствия от това състояние. В него се изтъква и фактът, който си струва да се повтори, а именно, че отчетите на платежните оператори са входни данни за проверки и съпоставяне (reconciliation), а не пълноценни двустранни счетоводни книги.
Примерна продажба на електронен пазар
Да предположим, че купувач плаща 100 €, продавачът има право на 85 €, а комисионната на платформата е 15 €. За яснота нека пренебрегнем ДДС и таксите на оператора.
| Сметка | Дебит | Кредит | Причина |
|---|---|---|---|
| Вземания от платежен оператор | 100 € | Операторът дължи на платформата събраното плащане | |
| Задължения към продавачи | 85 € | Платформата дължи сумата на продавача | |
| Приходи от комисионни | 15 € | Платформата е спечелила своята комисионна | |
| Общо | 100 € | 100 € | Балансирано |
Важната класификация тук е, че сумата от 85 €, дължима на продавача, е пасив (задължение), а не приход на платформата. Съгласно концепционалната рамка на МСС (IFRS), пасивът е настоящо задължение за прехвърляне на икономически ресурс. Електронният пазар не трябва да отчита цялата постъпление от продажбата на продавача като собствен приход само защото купувачът е платил чрез него. Независимо дали действате като агент, принципал или лице, считано за доставчик (deemed supplier), третирането се променя, но счетоводният механизъм остава същият.
Когато продавачът стане допустим за изплащане, не се признава нов приход. Вие погасявате задължението:
| Сметка | Дебит | Кредит |
|---|---|---|
| Задължения към продавачи | 85 € | |
| Банкова сметка или разчетна сметка за изплащания | 85 € | |
| Общо | 85 € | 85 € |
Ако платежният оператор задържи такса от 3 € преди превода, движението на паричните средства се превръща в статия от три реда: 97 € в банковата сметка, 3 € разход за обработка на плащания, 100 € извън вземанията от платежния оператор. Всяка промяна в позицията има източник и дестинация.
Как работи API стъпка по стъпка
1. Вашето приложение отчита бизнес събитие. Плащането е получено, поръчката е изпълнена, изплащането е одобрено, издадено е възстановяване на сума, открито е оспорвано плащане (chargeback), получен е сетълмент. Вашата база данни все още управлява оперативното състояние. Счетоводната книга отчита паричния ефект.
2. Изпращате структурирана заявка. Тя обикновено съдържа тип на събитието, сума и валута, идентификатор на поръчката или плащането, идентификатори на купувача и продавача, комисионна, данни за данъци, участващи сметки, дати на действие и на отчитане, ключ за идопотентност (idempotency key) и метаданни, свързващи записа с оператора и продуктовите записи. Примерът за публичен API на Nordlet показва концептуална заявка за продажба с идентификатор на продавача, тип на продажбата, сума, валута, както и държава и ставка на ДДС.
3. API валидира данните. То проверява дали дебитите и кредитите са балансирани, дали сметките съществуват и позволяват публикуване по тях, дали валутата се поддържа, дали сумата използва прецизна обработка на десетични знаци, дали ключът за идопотентност не е използван повторно за различен резултат, дали счетоводният период е отворен и дали са налице задължителните метаданни. Неуспешната проверка не оставя зад себе си частични счетоводни статии.
4. Извършва се атомно публикуване (posting). Цялата транзакция се записва като една цялост. Никога не трябва да е възможно да се запише дебитът, докато съответният кредит се проваля. За един електронен пазар частичното разделяне може да създаде фалшиво салдо на продавача без съответната парична наличност или да отрази комисионна без насрещно задължение към продавача.
5. Създават се салда и отчети от счетоводната книга. След публикуването можете да четете салда по сметки, чакащи и налични салда на продавачите, оборотна ведомост (trial balance), движение по основната счетоводна книга (general-ledger activity), обобщени справки за ДДС и история към минала дата. Салдото на продавача трябва да може да се възстанови от извършените записи, а не да се вярва сляпо на променливо поле в базата данни.
6. Уебхуковете (webhooks) уведомяват вашето приложение. Събития като sale_invoice.paid (платена фактура за продажба), публикувана статия, налично за изплащане салдо или изключение при проверка се изпращат към вас. Обработвайте ги по идопотентен начин. Уебхукът е уведомяване, а не разрешение да се прилага финансовото събитие втори път. Конвенциите за API обхващат в детайли обхватите (scopes), ключовете за идопотентност, формата на грешките и подписа на уебхуковете.
Салдата на продавачите не са едно единствено число
Повечето електронни пазари си създават проблеми, като третират салдото на продавача като една единствена цифра. Парите трябва да бъдат разпределени в различни състояния:
| Състояние | Значение |
|---|---|
| Чакащо (Pending) | Продавачът може да има право на средствата, но условията за тяхното освобождаване не са изпълнени |
| Налично (Available) | Допустимо за изплащане |
| Запазено (Reserved) | Задържано срещу възстановявания, връщания или спорове |
| Изплатено (Paid out) | Задължението е погасено чрез превод |
| Отрицателно (Negative) | Възстановяванията на суми, оспорваните плащания или таксите надвишават наличните средства |
Моделите на платежните оператори отразяват това. Потокът от отделни плащания (charges) и трансфери (transfers) на Stripe позволява на платформата да таксува собствената си сметка, след което да превежда части от сумата към свързани сметки, като таксите, възстановяванията и оспорваните плащания попадат върху салдото на самата платформа. Моделът за електронни пазари на Adyen прави разлика между сметки за салда на потребители, които съдържат средства до момента на изплащането им, и сметка за подлежащи на отговорност салда (liable balance account), която може да поеме отрицателни салда от възстановявания или спорове. Тези данни са полезни входни точки за вашата счетоводна книга, но те не представляват вашия пълен счетоводен модел.
Изплащанията и печалбите на продавачите се случват в различни моменти
Продавачът може да спечели пари в понеделник и да получи плащане през следващия понеделник. Между тези моменти поръчката се изпълнява, задържа се резерв, подготвя се пакет за изплащане (payout batch), операторът извършва сетълмент след приспадане на таксите и банковият превод пристига. Счетоводната книга трябва да запази всеки етап, вместо да презаписва поръчката с финално състояние „платено“. Това е нещото, което ви позволява да обясните времевите разлики между активността по поръчките, правото на продавача на средства, сетълмента, инициирането на изплащането и постъплението в банката.
Възстановявания и оспорвани плащания: коригирайте с насрещни записи, не презаписвайте
Възстановяванията на суми (refunds) и оспорваните плащания (chargebacks) са нови събития, свързани с първоначалното плащане. В една неизменяема счетоводна книга вие коригирате грешките с коригираща (обратна) статия, последвана от правилна такава, така че оригиналният запис да остане видим за целите на одита. Modern Treasury третира публикуваните транзакции като неизменяеми и поддържа ключове за идопотентност, за да предотврати дублиране на обекти при повторни опити.
Възстановяването на сума обикновено намалява паричните средства или вземанията от купувача, отменя задължението към продавача, може да отмени част от комисионната в зависимост от правилата, коригира данъка и може да изразходва резерв за възстановявания. Оспорваното плащане намалява паричните средства или вземанията от оператора, може да възобнови сума, дължима от продавача или платформата, отчита разход за спор и такса на оператора и превежда средства през сметка за резерви.
Проверка и съпоставяне (Reconciliation): свързване на счетоводната книга с реалните пари
Счетоводната книга може да бъде вътрешно балансирана и въпреки това да греши относно външния свят. Проверката и съпоставянето (reconciliation) сравняват вътрешните записи с външни доказателства: отчети за сетълмент от оператори, банкови извлечения, файлове с изплащания, записи за възстановявания и спорове.
Един работещ процес изглежда така:
- Импортиране на сетълмента или банковия пакет.
- Съпоставяне на всеки ред с поръчка, плащане, възстановяване, такса, изплащане или спор.
- Сравняване на очакваните брутни суми, удръжки, резерви и нетни суми.
- Публикуване на потвърдените движения в счетоводната книга.
- Изпращане на несъпоставените елементи към специална разчетна сметка (suspense account).
- Разследване на изключенията.
- Заключване на счетоводния период.
Материалите за проверка и съпоставяне на Nordlet описват точно това - импортиране на пакети за сетълмент, съпоставяне на редове за таксуване и възстановяване и насочване на несъпоставени приходи към разчетна сметка, вместо да се правят предположения за някоя фактура. Две проверки са от значение и нито една от тях не замества другата: проверката с двустранно записване пита дали всяка статия е балансирана, а съпоставянето пита дали тя съвпада с данните на оператора, банката и бизнес събитието.
Архитектурни детайли, които определят дали ще се справите правилно
Идопотентност (Idempotency). Обвържете ключа със стабилно събитие, като например payment_captured:pi_123. Повторният опит връща оригиналния резултат, а не втора счетоводна статия.
Атомност (Atomicity). Всички редове на едно събитие се публикуват заедно или изобщо не се публикуват.
Неизменяемост и корекции (Immutability and reversals). Публикуваната история не може да се редактира чрез обикновени актуализации. Корекциите създават свързани записи, които запазват първоначалната сума, дата, класификация, причина и автор.
Прецизни парични суми. Без използване на двоични плаващи запетая (binary floating point). Използвайте цели числа за най-малките парични единици (minor units) или точни десетични знаци, изрична валута и детерминистично правило за закръгляване при разделяне. Ако разделите 100 € между продавачи и такси без такова правило, една изгубена стотинка ще счупи баланса ви.
Дати на действие спрямо дати на публикуване (Effective vs posting dates). Моментът, в който купувачът е платил, моментът, в който продавачът е спечелил парите, моментът на банковия сетълмент и моментът на публикуване на записа са различни дати. Тяхното сливане прави отчитането по периоди и определянето на данъчния момент ненадеждни.
Многовалутност (Multi-currency). Дебитът и кредитът трябва да се балансират в рамките на една и съща валута. Конвертирането изисква изрично събитие за валутен курс със сметки за таксата, закръгляването и всякакви валутни печалби или загуби. Самото приемане на поле за currency (валута) не прави една счетоводна книга конвертиращ двигател.
Какво един API за счетоводна книга няма да направи вместо вас
Той няма да определи вашия индивидуален сметкоплан. Все пак трябва да решите дали сте принципал или агент, кога се печели комисионната, коя страна поема таксите на платежния оператор, как възстановяванията засягат комисионната и как се изчислява и отчита ДДС. Собствените указания на Nordlet са първо да се изготвят схемите на паричните потоци, да се състави сметкопланът, да се прегледа от счетоводител и едва тогава да се реализира един пълен поток от поръчката през изплащането и съпоставянето, преди да се премине към мащабиране.
Той няма да разреши данъчните въпроси. ДДС зависи от местоположението на купувача и продавача, вида на продукта, регистрационния статус и правилата за лицата, считани за доставчици; ръководството за ДДС в ЕС определя какво изчислява системата автоматично и какво маркира за проверка от човешки фактор. Обхватът на ДДС в Nordlet е насочен към ЕС и ЕИП, така че не се разпростира върху данъка върху продажбите в САЩ (sales tax) или латиноамериканското електронно фактуриране. И той няма да разреши оперативната неопределеност - дали срокът за връщане е изтекъл, дали дадено изплащане трябва да бъде блокирано, дали дадено плащане е измамно. Това са ваши решения. Счетоводната книга просто отчита техния финансов резултат.
Къде се вписва Nordlet
Nordlet е счетоводен API, създаден за платформи и електронни пазари, с неизменяема двустранна счетоводна книга, изплащания, обработка на ДДС в ЕС, REST крайн точки, типизирани SDK библиотеки и уебхукове, достъпни през една обща повърхност. Неговото отличително предимство е вграденото счетоводство във вашия собствен продукт, вместо използването на външен процес за плащане. Към момента на написването на тази статия продуктът е в етап на ранен достъп със среда за тестване (sandbox) за партньори по дизайна, така че го разглеждайте като силен пример за категорията и оценявайте производствената му зрялост, непрекъсваемост на работата (uptime) и юрисдикционен обхват за вашия собствен случай, преди да поемете ангажимент.
За разработчиците на електронни пазари и платформи полезният мисловен модел се състои в разделението между движението на плащанията и финансовата истина. Вашият платежен оператор превежда парите. API за двустранно счетоводно записване отчита кой какво дължи, какво сте спечелили, какви данъци и резерви носите и дали външният свят се съпоставя правилно с вашите счетоводни книги.
FAQ
API за двустранно счетоводно записване същото ли е като платежен оператор?
Не. Един оператор оторизира, събира, извършва сетълмент и понякога изплаща средства. API за счетоводна книга отчита счетоводните последствия от тези събития. Повечето електронни пазари използват и двете - оператор като Stripe или Adyen за движението на средствата и счетоводна книга за самите сметки.
Мога ли просто да използвам таблото за управление на моя платежен оператор като основна счетоводна книга?
Можете да опитате, но в крайна сметка системата ще се провали при одит. Отчетите на платежните оператори показват таксувания, такси, трансфери и сетълменти, но те обикновено не отразяват вашите пълни задължения към продавачите, данъчни задължения, разходи извън оператора или счетоводни корекции. Третирайте ги като входни данни за проверка и съпоставяне.
Означава ли балансираната счетоводна книга, че книгите ми са верни?
Само че вашите записи отговарят на правилото за дебит и кредит. Една перфектно балансирана транзакция все пак може да бъде отчетена по грешна сметка, на грешен продавач или с грешно данъчно третиране. Балансът е задължителен, но не е достатъчен. Проверката и съпоставянето (reconciliation) улавят останалите неточности.
Ако счетоводната книга е неизменяема, как да коригирам грешки?
Публикувате коригираща (обратна) статия и след това правилна такава. Оригиналният запис остава видим, което е и самата цел. Неизменяемостта защитава одитната следа, тя не затваря изхода при вашите грешки.
Счетоводният API прави ли ме автоматично съобразен с изискванията на закона (compliant)?
Не. Той налага счетоводна структура и произвежда използваеми записи. Законовото съответствие все още зависи от вашата юрисдикция, договорна роля, данъчно третиране, платежни разпоредби, процеси по познаване на клиента (KYC) и борба с изпирането на пари (AML), както и от вашите отчетни задължения.