API за счетоводни регистри с двустранно записване за счетоводство на платформи

Повечето платформи (marketplaces) откриват, че имат счетоводен проблем по един и същ начин: назначават нов експерт счетоводител, който отваря таблицата с изплатените суми (payouts) и пита кой всъщност отчита задължението към продавачите в периода между плащането на купувача и напускането на средствата от сметката на платформата. Инженерният екип посочва таблицата с транзакции (transactions). Счетоводителят отбелязва, че таблицата със събития не е счетоводен отчет. Тази празнина между данните за събитията и реалното счетоводство е това, което API за счетоводни регистри с двустранно записване е създадено да запълни.

Това е технически въпрос с регулаторна тежест. Платформите държат чужди пари, изчисляват ДДС в различни юрисдикции и издават фактури от името на продавачи. Извършването на това с вътрешно разработена таблица с транзакции работи до момента, в който одитор, данъчна служба или сериозен купувач поиска доказателства.

Какво всъщност представлява едно API за регистър с двустранно записване

API за регистър с двустранно записване е програмируем счетоводен двигател, достъпен през HTTP. Всяко финансово събитие, което вашата платформа записва, се вписва като балансирана счетоводна статия: най-малко един дебит и един кредит, равни по обща сума, отразени по съответните сметки в сметкоплана. API-то налага този баланс в момента на записа и съхранява записи, които не могат да бъдат редактирани тайно на по-късен етап.

Частта с „двустранното записване“ е четиристотингодишното счетоводно правило, че всяка транзакция засяга поне две сметки. Частта с „API“ означава, че вашият продукт, а не човешки счетоводител, е страната, която отправя заявките. Частта с „неизменимост“ (immutable) означава, че корекциите се правят чрез сторниращи статии, а не чрез редакция на историята. Събрани заедно, тези три свойства правят получените счетоводни книги готови за одит, вместо просто подредени.

Полезна работна дефиниция:

API за регистър с двустранно записване приема финансови събития от вашето приложение, преобразува всяко от тях в балансирана счетоводна статия спрямо дефиниран сметкоплан, съхранява тези статии неизменимо и предоставя получените регистри, оборотна ведомост и финансови отчети чрез предвидими крайни точки (endpoints).

Nordlet е изграден точно около тази идея: реални счетоводни книги като API, като регистърът, логиката за ДДС, фактурирането и съгласуването са достъпни от същия набор крайни точки, с които вашият продукт вече комуникира.

Защо платформите имат специфична нужда от това

Софтуерът като услуга (SaaS) с един търговец често може да си позволи синхронизиране с общ счетоводен инструмент веднъж на ден. Платформите не могат по три причини.

Първо, те се намират в центъра на паричния поток. Купувачът плаща на платформата, платформата задържа средствата, след което плаща на продавачите минус таксите. Всяко от тези движения е отделно счетоводно събитие, засягащо различни сметки: парични средства, задължения към продавачи, приходи на платформата, ДДС за възстановяване/внасяне, резерви за възстановяване на суми (refund reserves). Таблицата за плащания (payments) с колона за статус (status) не отразява това.

Второ, те оперират в различни данъчни юрисдикции. Една европейска платформа с продавачи в Литва, Германия и Полша, и купувачи в целия блок, трябва да прилага правилното третиране по ДДС за всяка транзакция, да валидира ДДС номерата на продавачите чрез VIES и да изготвя декларации, които удовлетворяват съответния местен орган. Постигането на това в кода на приложението, последвано от съгласуването му с отделна счетоводна система, е моментът, в който повечето платформи се провалят незабелязано.

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

Как работи API-то, стъпка по стъпка

Механиката е по-малко екзотична, отколкото звучи. Типичният работен процес за поръчка в платформа изглежда така:

1. Вашата платформа генерира финансово събитие. Купувачът завършва плащането. Вашият сървърен софтуер (backend) извиква API-то на регистъра с данни като: ID на поръчката, купувач, продавач, брутна сума, ДДС ставка, комисиона на платформата, валута и ключ за идемпотентност (idempotency key).

2. Регистърът създава счетоводна статия. API-то превежда това събитие в дебити и кредити. За обикновена продажба в платформа това може да означава дебитиране на сметка за парични средства по пътя (cash-in-transit), кредитиране на сметка за задължения към продавача за нетната сума, кредитиране на сметка за приходи на платформата за комисионата и кредитиране на сметка за дължим ДДС за данъчната част. Всичко е балансирано. Всичко е отразено атомно.

3. Записът се осъществява неизменимо. Веднъж отразена, статията получава идентификатор и времеви печат (timestamp) и не може да бъде редактирана. Ако нещо е погрешно, вие публикувате сторнираща статия и коригирана такава. Одитната следа е основната цел.

4. Вторичните отчети се актуализират в реално време. Оборотната ведомост, салда по задължения към продавачи, ДДС обобщенията и отчетът за приходите и разходите (P&L) отразяват новия запис незабавно. Няма нощна задача, няма експорт, няма прозорец за съгласуване, в който числата да „отлежават“.

5. Уебхуковете (webhooks) уведомяват вашата система. Събития като sale_invoice.paid или bank_transaction.matched се изпращат към вашите крайни точки, така че продуктът ви да може да реагира без периодично изпитване (polling). В комбинация с ключовете за идемпотентност, това означава, че повторните опити са безопасни и дубликатите не се провличат при мрежови смущения.

Важният архитектурен момент: регистърът е източникът на истината за финансовите събития. Базата данни на вашето приложение е източникът на истината за състоянието на продукта. Двете системи се съгласуват, защото регистърът се попълва от събитията на приложението, а не обратното.

Сметкопланът е мястото, където се случва проектирането

Повечето умствени усилия при настройката на регистър за платформа са насочени към сметкоплана. Това е списъкът с наименовани пера, в които попадат дебити и кредити: банкови сметки, сметки за задължения към продавачи (често по една за продавач или една обобщена със съб-легъри), приходи на платформата по категории, дължим ДДС по държави, резерви за възстановяване, резерви за оспорени плащания (chargebacks) и т.н.

Няколко шаблона се повтарят в различните платформи:

• Средствата на продавачите са задължение, а не приход. Парите, които държите от името на продавачи, са задължение (payable). Третирането им като приход и „отчитането като разход“ на изплащането по-късно е класическата грешка, която излиза наяве при проверки и дю дилиджънс.
• ДДС е отделно задължение за всяка държава. Ако оперирате в юрисдикции от ЕС, са ви необходими отделни сметки за дължим ДДС по държави, така че отчетите да се мапват чисто.
• Таксите трябва да бъдат моделирани в момента на тяхното спечелване, а не при изплащането им. Начисленото счетоводство (accrual accounting) тук не подлежи на компромис.
• Възстановяванията, оспорванията (chargebacks) и споровете се нуждаят от собствени сметки, така че отчетът за приходите и разходите (P&L) да отразява реалността, а не хаос от положителни и отрицателни продажби.

Доброто API за регистри ви позволява да дефинирате тази структура веднъж и след това да осчетоводявате в нея с увереност, вместо да преоткривате счетоводната логика в кода за плащане на касата (checkout).

Неизменимост, заключване на периоди и защо одиторите се интересуват от това

Неизменимостта звучи като подробност около базата данни. Всъщност тя е разликата между счетоводни книги, които одиторът ще подпише, и такива, които няма да подпише.

Ако платформата може тайно да редактира статиите от миналото тримесечие, то числата от миналото тримесечие в счетоводен смисъл са непознаваеми. Неизменимият регистър налага правилото, че историята си остава история. Корекциите се виждат като корекции. Заключването на периоди разширява това: след като даден месец бъде приключен, в този период не могат да постъпват нови записи или редакции без изрично действие за отваряне, което само по себе си се регистрира в логовете.

За платформите, които в крайна сметка ще набират финансиране, ще се продават или ще се изправят пред данъчен одит, това не е екстра „за удобство“. Това е нещото, което прави счетоводните книги защитими. Регистърът на Nordlet е проектиран около това по подразбиране, като неизнемената структура с двустранно записване и заключването на периоди са вградени, а не добавени допълнително.

ДДС в ЕС: частта, която поглъща инженерно време

ДДС е областта, в която повечето счетоводни проекти на платформи надхвърлят времевите си граници. Правилата не се свеждат просто до „прилагане на процент“. Те зависят от това къде се намира купувачът, къде е продавачът, какво се продава, дали продавачът е регистриран по ДДС, дали платформата се счита за доставчик (deemed supplier) съгласно правилата за електронна търговия от 2021 г. и кой режим за отчетност се прилага на местно ниво.

Сериозното API за регистри за ЕС управлява поне:

• VIES валидация на ДДС номерата на продавачи и купувачи, в идеалния случай с кеширани резултати и отбелязване върху транзакцията
• Логика за ДДС ставките по държави, включително намалени ставки и освобождавания
• Генериране на i.SAF регистри за литовските отчети и еквивалентни структурирани изходи, където други държави членки ги изискват
• Peppol BIS 3.0 електронно фактуриране за юрисдикции, преминаващи към задължително електронно отчитане
• OSS/IOSS управление за трансгранични B2C продажби

Извършването на това в кода на приложението за всяка държава е обем работа за цял инженерен екип, който никога не приключва напълно, тъй като правилата непрекъснато се променят. Преместването му в слоя на регистъра е прагматичното решение.

Съгласуването е мястото, където си личи спестеното време

Когато регистърът стане източник на истината, банковото съгласуване (reconciliation) престава да бъде ежемесечно изпитание. Банковите извлечения пристигат, регистърът вече знае какво трябва да е там, и съпоставянето е до голяма степен автоматично.

Реалистичната версия на това не е „нула ръчна работа“. Тя е „изключенията изплуват сами“. Работен процес за съгласуване с едно щракване за десетте процента от транзакциите, които се съгласуват безпроблемно, плюс опашка от десетте процента, изискващи човешка намеса, е горе-долу това, което едно добре проектирано API за съгласуване предоставя. Интелигентното съпоставяне на плащания обработва частични плащания, надплащания и плащания, покриващи множество фактури, без човек да пише правила за всеки отделен случай.

SEPA експортът (pain.001 формат) за изплащания към доставчици и продавачи затваря кръга от изходящата страна. Вие одобрявате изплащанията във вашия продукт, регистърът генерира SEPA файла, вашата банка го обработва, и полученото движение се съгласува обратно автоматично.

Изграждане срещу закупуване срещу вграждане

Екипите на платформите обикновено разглеждат три пътя. Ето как те се сравняват по основните критерии:

Подход	Време до пускане в експлоатация	Готовност за одит	Управление на ДДС в ЕС	Впива ли се във вашия продукт
Изграждане на собствен регистър	12 до 24+ месеца	Зависи изцяло от вашия екип	Изграждате го вие, за всяка държава	Да
Синхронизиране с Xero/QuickBooks	Седмици	Добре за счетоводната част, слабо за специфични за платформи потоци	Частично, изисква допълнения	Не, работи в отделен инструмент
Вграждане на API за регистри (напр. Nordlet)	Седмици	Вградено чрез неизменен регистър и заключване на периоди	Вградено за ЕС, включително VIES и i.SAF	Да, чрез API и SDK

Самостоятелното изграждане е защитимо, ако счетоводството е вашият основен продукт. За всички останали сметката рядко излиза. Синхронизирането с традиционен счетоводен инструмент работи за предприятия с една структура, но се затруднява при потоците в платформите: разделени плащания, под-легъри за продавачи, ДДС по държави и сценарии, при които платформата се счита за доставчик (deemed supplier), не се мапват добре към инструменти, създадени за счетоводството на една единствена компания.

Вграждането на регистър, ориентиран първично към API (API-first), е решението, към което се насочват повечето модерни платформи. Счетоводните книги съществуват в потребителското изживяване на вашия продукт, продавачите виждат собствените си финансови резултати във вашия потребителски интерфейс, а тежката задача по съответствието се обработва на инфраструктурно ниво.

Какво да търсите при оценка на API за регистри

Кратък списък с въпроси, които е добре да имате под ръка по време на разговори с доставчици:

• Неизменимо съхранение с двустранно записване и коригиране чрез сторниращи статии, без редактируеми редове
• Заключване на периоди с регистрирани действия по повторно отваряне
• Ключове за идемпотентност за всяка крайна точка за запис
• Уебхукове (webhooks) за събитията, на които вашият продукт трябва да реагира, а не просто API за периодично изпитване
• Типизирани SDK на езиците, които вашият екип реално използва
• Логика за ДДС по държави, включително VIES, i.SAF или еквиваленти, и OSS/IOSS
• Поддръжка на множество фирмени субекти (multi-company), ако оперирате или планирате да оперирате с няколко юридически лица
• Ролеви достъп, достатъчно детайлен за отделяне на разработчици, счетоводители и наблюдатели
• Експорт на отчети във формат XLSX, PDF и JSON, с известия чрез уебхукове, когато големите отчети са готови
• Сандбок среда (sandbox), която отразява поведението в реална среда (production), а не орязано демо

Ако доставчикът не може да демонстрира първите три точки в технически разговор, останалите нямат значение.

Как бих постъпил първоначално

Ако една платформа започва тази дейност от нулата, последователността, която спестява най-много затруднения, е следната:

1. Начертайте реалните парични потоци на бяла дъска, преди да напишете какъвто и да е код. Кой на кого дължи, в какъв момент, в каква валута, с какво третиране по ДДС.
2. Проектирайте сметкоплана въз основа на тази схема. Задължения към продавачи, приходи на платформата, дължим ДДС по държави, резерви. Ангажирайте счетоводител да го прегледа, преди да влезе в експлоатация.
3. Изберете слоя на регистъра. Изграждане, синхронизиране или вграждане. Бъдете честни за това кое вашият екип реално може да достави и поддържа.
4. Реализирайте един поток от край до край: поръчка до фактура, до изплащане, до съгласуване. Докажете, че се балансира. След това мащабирайте.
5. Активирайте заключването на периоди веднага щом първият месец приключи чисто. Дисциплината се натрупва.

Екипите, които правят това правилно, третират регистъра като основна инфраструктура, а не като закъсняла мисъл за отчетите. Това е повратната точка и тя прави разговорите с одитор, инвеститор или данъчна служба кратки, вместо дълги.

FAQ

API за регистри с двустранно записване същото ли е като счетоводна интеграция?

Не. Една интеграция синхронизира данни от вашия продукт в външен счетоводен инструмент, обикновено със закъснение. API за регистри е самата счетоводна система, към която се пише директно и в реално време. Разликата е от значение, защото интеграциите губят точност по краищата: частични плащания, многовалутност, разделяния при платформи. API за регистри записва тези елементи естествено.

Не можем ли просто да използваме отчетите на Stripe или Adyen?

Отчетите на платежните оператори показват какво е преминало през оператора. Те не са счетоводни книги с двустранно записване. Те не знаят за вашите задължения към продавачи, които все още не са изплатени, за вашите задължения за ДДС в различните държави или за разходите ви извън платежния оператор. Те са само един входен поток към регистъра, а не негов заместител.

Колко неизменяемо е неизменимото на практика?

Записите не могат да бъдат редактирани. Корекциите представляват нови записи, които препращат към оригиналните. Това е дизайнерско решение, а не технологично. Всеки компетентен регистър ще го наложи. Причината това да има значение е, че практиката „редактирахме го, за да съвпадне с банката“ е точно моделът, който прави счетоводните книги ненадеждни.

Как стоят нещата с платформи извън ЕС?

Механиката на двустранното записване е универсална. Данъчната логика обаче не е. API за регистри, настроено за ДДС в ЕС, ще се справя добре с операции, насочени към Европа, и може да поддържа транзакции извън ЕС, но ако вашият основен пазар е щатският данък върху продажбите (sales tax) или латиноамериканските режими за електронно фактуриране, проверете конкретното съответствие с регулациите, преди да поемете ангажимент.

Колко време отнема реално внедряването?

За платформа с изчистен модел на събитията, вграждането на API за регистри до точката на изпълнение на един поток от край до край обикновено отнема няколко седмици инженерна работа. Пълната миграция от наследена система (legacy setup), включително исторически данни, отнема повече време. Променливата величина почти винаги е състоянието на съществуващите данни, а не самото API.