Вградено счетоводство: Разработване срещу закупуване при онлайн платформите и маркетплейсите

Списък с обхвата, модел на разходите с предварително зададени допуски и условията, при които всяко от решенията е правилно.

В крайна сметка всеки маркетплейс изгражда собствена счетоводна книга (ledger). Единственият въпрос е дали тя е създадена съзнателно като система с контроли, или случайно като колона с balance, в която пишат три микросървъра и на която никой няма пълно доверие.

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

Какво означава „вградено счетоводство“ в този контекст

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

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

Какво всъщност изграждате, ако решите да го разработите сами

Самата счетоводна книга е малката част. Екипите редовно оценяват първия елемент и откриват останалите едва след това.

Компонент	Какво включва
Дневник и сметкоплан (Journal and accounts)	Балансирани записи, сметкоплан, видове сметки, начални салда
Непроменимост (Immutability)	Хранилище само за добавяне (append-only), работен процес за сторниране и корекция, без редакции на място
Контрол на отчетни периоди	Приключване, заключване, отхвърляне на късни счетоводни записвания, контролирано повторно отваряне с одитна следа
Идемпотентност (Idempotency)	Ключове, съхранение на предишни отговори, откриване на дублиране при променени полезни данни (payloads)
Работа с парични суми	Аритметика с точни десетични знаци или най-малки парични единици (minor units), валутни кодове, валутни курсове и техния източник, корекционни сметки за закръгляване
ДДС двигател (VAT engine)	Ставки по държави с дати на валидност, място на изпълнение, обратно начисляване (reverse charge), правила за фиктивен доставчик (deemed supplier), освободени от данък доставки
Проверки за ДДС регистрация	Валидиране спрямо официалния регистър, кеширане, времеви отпечатъци, идентификатори на заявки, опашка за ръчна проверка при грешки
Документи	Фактури, кредитни известия, последователна номeрация без пропуски по серии и години, генериране на PDF, доставка
Електронно фактуриране	Структурирани формати като EN 16931 UBL и национални формати по държави, където се изискват
Импортиране на банкови данни	Ипорт на извлечения или банкова връзка със съгласие, дедупликация на вече импортирани транзакции
Съгласуване (Reconciliation)	Правила за съпоставяне, оценяване, частични съвпадения, изключения, които даден служител може да разреши
Изплащания (Payouts)	Генериране на платежни файлове, групови изплащания, съпоставяне на изплащанията обратно към съответните елементи
Отчетност	Оборотна ведомост, баланс, отчет за приходите и разходите, паричен поток, ДДС справки, хронологична ведомост на вземанията
Данъчни регистри и декларации	Всичко, което вашите държави изискват, във формата, който администрацията приема
Одит	Субект, действие, обект и самата промяна, с възможност за заявки, за всяка промяна в данните
Съхранение и експорт	Десетгодишно съхранение на OSS записи, пълен експорт на данни, защитим архив

Приблизително два от тези седемнадесет реда са частта, която повечето екипи си представят, когато кажат „ще си направим счетоводна книга“.

Честна оценка на разходите

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

Първа корекция: компонентите за съответствие (compliance) не са еднократни. Данъчните ставки се променят, праговете се променят, форматите се променят, а пакетът на ЕС „ДДС в цифровата епоха“ (ViDA) води със себе си нови задължения с конкретни срокове: промени в OSS и IOSS от 1 януари 2027 г., разширени правила за платформите от 1 юли 2028 г., трансгранично цифрово отчетно отчитане от 1 юли 2030 г. Решението да разработите системата сами означава, че вие поемате отговорността за всяка една от тези миграции.

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

Трета корекция: счетоводителят е заинтересована страна, а не просто проверяващ. Счетоводни регистри, които даден финансов специалист отказва да подпише, не са завършени, а тази обратна връзка обикновено пристига твърде късно в процеса на разработка.

Полезна проверка за здрав разум: оценете най-малкото възможно надеждно решение – счетоводна книга, коригиращи записи, заключване на периоди, идемпотентност, работа с парични суми, ДДС за една държава, фактури, импорт от банка, съпоставяне и основен набор от отчети – и я сравнете с една година използване на услуга на база потребление. Плановете на Nordlet с публикувани цени започват от 10 евро на месец с включени 3000 заявки и стигат до 300 евро на месец с 200 000 заявки. Ако разработването струва малка част от годишната заплата на един инжeнер, това е сериозен аргумент в полза на вътрешната разработка. Ако струва колкото няколко инженер-години плюс постоянна поддръжка, сравнението е безпредметно, като разликата нараства с всяка изминала година, през която правилата се променят.

Кога разработването е наистина правилното решение

Три случая, като и трите са реални.

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

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

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

Кога закупуването е правилното решение

Закупуването печели, когато счетоводството е необходимост, а не отличителна черта, което е и масовият случай. Никой не избира вашия маркетплейс заради елегантните счетоводни статии. Потребителите забелязват счетоводството само когато то е сгрешено.

Закупуването е правилното решение и когато задълженията ви обхващат множество държави. ДДС правилата по държави, съхранението на доказателства и задълженията за електронно фактуриране са постоянна задача по поддръжката, като даден доставчик разпределя тази работа между всички свои клиенти. Nordlet предлага ДДС в ЕС по държави с VIES валидация, изчисляване на OSS и IOSS декларации, i.SAF регистри и EN 16931 UBL за Peppol като част от продукта, вместо като проект, който трябва сами да планирате и изпълнявате.

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

Практичният отговор обикновено не е нито едното, нито другото изцяло. Той е следният: купете счетоводната книга, разработете работния процес.

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

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

Какво да решите, преди да се ангажирате

Вашата счетоводна книга отличителна черта ли е, или задължение? Бъдете честни със себе си; в повечето случаи тя е задължение.
Колко държави обхващате и какво изисква всяка от тях? Само ставки, или справки, или регистри, или подаване към НАП/съответните органи.
Каква е вашата стратегия за корекции? Възстановяванията след изплащане и закъснелите оспорвания са случаите, които изваждат наяве слабия дизайн.
Кой подписва счетоводните отчети? Включете този човек преди изясняването на дизайна, а не след това.
Какъв е планът за десетгодишно съхранение? Записите по OSS трябва да се съхраняват десет години от края на годината на транзакцията, а архивът е цяла система, а не обикновен резервен копие (backup).
Как би изглеждала една миграция след три години? И в двете посоки. Създайте тестов експорт още първия ден и следете той да работи постоянно.

FAQ

Колко време отнема изграждането на счетоводна книга за маркетплейс?

Първа версия, която публикува балансирани записи, може да заработи за седмици. Версия, която се справя с възстановявания след изплащане, късни оспорвания, многовалутно закръгляване, дублирани уебхукове от доставчици, приключване на период и одит, който счетоводителят би приел, отнема значително повече време, а поддръжката никога не спира. Оценете втория вариант, защото точно това означава работа в реална среда (production).

Можем ли да започнем с колона `balance` и да мигрираме по-късно?

Можете и много екипи правят точно това, но планирайте миграцията да бъде по-трудна от първоначалното разработване. Възстановяването на историята от променливо салдо е възможно само ако сте пазили всяко събитие, което го е променило – което означава, че на практика вече сте разполагали със счетоводна книга.

Заменя ли вграденото счетоводно API нашия финансов екип?

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

Как стоят нещата с GDPR, ако счетоводната книга е непроменяема (immutable)?

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

Счита ли се софтуерът с отворен код за счетоводство като междинен вариант?

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