Как да изберем счетоводен API за съответствие с ДДС в ЕС
Ръководство за купувачи на платформи и маркетинг плейс системи, които се нуждаят от истински счетоводни книги, ДДС логика по държави и регистри, готови за одити, вградени в собствения им продукт.
Повечето неуспешни интеграции на ДДС започват с фундаментална грешка в категорията. Даден екип търси начин „да обработва ДДС в ЕС“, избира API за изчисляване на данъци, пуска го в експлоатация и едва по-късно открива, че инструментът връща ставка, но никога не записва счетоводна статия, никога не свързва кредитно известие с оригиналната фактура и не може да генерира одитния файл, който данъчната администрация може да поиска години по-късно. Ставката е била правилна. Счетоводството е липсвало.
За един маркетиъм плейс или SaaS платформа, вграждащи финансова инфраструктура, първото решение е дали имате нужда от счетоводна система с вградени ДДС възможности, или от слой за данъчно съответствие, който стои върху счетоводни книги, поддържани на друго място. Това са различни продукти с различни модели на данните, като тази разлика определя почти всичко след това.
Счетоводен API спрямо API за данъчно съответствие: каква е реалната разлика
Счетоводният API поддържа главна книга (general ledger). Той записва двойно записване на стопански операции, поддържа индивидуален сметкоплан, закръгля и заключва затворени периоди, съгласува изплащания (payouts) и изготвя балансови отчети. ДДС е само един от атрибутите на транзакция, която системата вече съхранява.
API за данъчно съответствие изчислява ДДС, понякога го декларира и често издава фактури, но не води вашите счетоводни книги. Той отговаря на въпроса „какъв данък се прилага тук“ и, в управляваните версии, „кой подава декларацията“. Счетоводният запис живее в друга система.
Това е от значение, защото съответствието с ДДС не е просто справка за данъчна ставка. Работещият работен процес за ДДС в ЕС трябва да съхранява доказателствата и метаданните, които обосновават данъчното третиране, като тези доказателства трябва да се пазят цяло десетилетие. Съгласно режима OSS, записите трябва да включват държавата членка на потребление, вида и датата на данъчното събитие, дължимия ДДС и доказателствата, използвани за определяне къде е установен клиентът, като те трябва да се съхраняват в продължение на десет години от края на годината на транзакцията. Инструмент, който връща ставка и я забравя, се проваля на този тест още на първия ден.
Nordlet е създаден точно за счетоводната страна на това разделение. Той предоставя неизменяема главна книга с двойно записване, заключване на периоди, съгласуване на банкови плащания и изплащания, ДДС по държави в ЕС и одитен дневник чрез REST крайни точки (endpoints), типизиран SDK и подписани уебхукове (webhooks). Издаването на фактура за продажба създава балансирана счетоводна статия и съответните ДДС редове в рамките на една операция, така че счетоводството и данъчното третиране никога не се записват поотделно. Тази комбинация е причината той да присъства в цялото ръководство като най-подходящия избор за платформи, които трябва да притежават своя счетоводен модел на данните, вместо да наслагват данъци върху чужда главна книга. Забележка предварително: Nordlet е в ранен достъп (early access) и приема партньори за разработване на дизайна, така че сроковете за внедряване в производство и покритието на държавите са неща, които подлежат на проверка. Ценообразуването, от друга страна, е публично и базирано на потребление, а не на индивидуални оферти.
Какво трябва да обхваща „съответствието с ДДС в ЕС“
Преди да сравнявате доставчиците, определете обхвата. „Поддържа ДДС“ може да означава таблица със ставки, изчислителен механизъм, справка, услуга за регистрация или напълно управлявано деклариране. Попитайте кое точно е налично.
Практическият работен процес за ДДС в ЕС трябва да се справя с:
- Записи на ниво транзакция с място на изпълнение, дата на сделката, нето, ДДС и брутни суми, съхранявани отделно, дори когато цените за крални клиенти показват суми с включен данък.
- Доказателства за местоположението на клиента, а не просто поле за държава. Данни за фактуриране, доставка, IP адрес и банкови сигнали, заедно с решението, което системата е взела на тяхна база.
- VIES валидация за B2B сделки в рамките на ЕС. VIES проверява националните бази данни, а не единен централен регистър, така че валиден номер може да не се появи, услугата може да е временно недостъпна, а историческата валидност не може да бъде потвърдена постфактум.
- OSS и IOSS групиране, корекции и одитни експорти. Европейската комисия признава стандартния одитен файл за OSS като формат, приет във всички държави членки.
- Логика за отговорност на маркетинг плейса (marketplace liability), която моделира дали продавачът, купувачът или платформата събира и внася данъка.
- Корекции, които остават свързани с оригиналната транзакция, така че възстановяванията на суми (refunds), кредитите и отстъпките да проследяват пътя си обратно през корекцията на декларацията.
Ако даден доставчик не може да ви покаже как всяко от тези изисквания се съхранява и експортира, третирайте пропуските като реален разход, а не като маловажен детайл.
Критериите за избор, които променят решението
| Критерий | Какво да проверите | Защо е от значение |
|---|---|---|
| Счетоводна дълбочина | Неизменяема главна книга, счетоводни статии, сметкоплан, заключване на периоди, съгласуване на изплащания | Данъчният механизъм сам по себе си не генерира надеждни финансови отчети |
| Изчисляване на ДДС | Държава, тип клиент, продуктов каталог, място на изпълнение, освобождавания, обратно начисляване (reverse charge), цени с включен ДДС | Справките по стандартна ставка се провалят при смесени стоки, B2B и маркетинг плейс потоци |
| Доказателства за местоположение | Съхранение на фактуриране, доставка, IP, банкови сигнали и взетото решение | Третирането често зависи от доказателствата, а не от единична стойност за държава |
| VIES работен процес | Идентификатори на заявки, времеви отпечатъци (timestamps), кеширане, обработка на повторни опити, опашки за преглед | VIES може да е недостъпен; процесът по плащане не трябва да зависят от едно синхронно извикване |
| OSS / IOSS | Групиране, Съюзнически и извънсъюзнически режим OSS, корекции, одитни експорти | „Поддържа OSS“ може да означава само отчет или пълно управлявано деклариране |
| Правила за маркетинг плейс | Логика за фиктивен доставчик (deemed-supplier), ДДС номера на продавачи, третиране на комисионните, отчети на ниво продавач | Платформите носят отговорности, които обикновените касови системи никога не виждат |
| Одитируемост | Неизменяеми записи, заключване на периоди, изходни документи, обяснения на данъчни решения, формати за експортиране | Администрациите могат да поискат записи години по-късно |
| Интеграция | REST, уебхукове, SDK, идемпотентност (idempotency), тестова среда (sandbox), версиониране, повторно възпроизвеждане на събития | Слабата механика създава дублирани или несъгласувани данъчни записи |
| Търговски модел | На изчисляване, на транзакция, на декларация, на акаунт или на база оферта | Разходите се променят рязко с обема и юрисдикциите |
| Преносимост на данните | Експорт на главна книга, фактури, данъчни доказателства, ДДС номера, история на деклариране | Разходите за смяна на доставчик са високи, когато той е вашата система за запис |
| Зрялост | Наличност, SLA, поддръжка, референтни клиенти | Продуктът с ранен достъп може да е привлекателен, но недоказан за критична за декларирането работа |
Два от тези критерии са подценявани. Поддръжката на идемпотентност е по-важна, отколкото екипите очакват, защото повтарящото се мрежово повикване, което създава дублиран ДДС запис, тихо поврежда данъчната декларация. Nordlet приема заглавка Idempotency-Key при всяка променяща заявка, така че повтореният заявен процес никога да не може да създаде дубликат - това е типът технически детайл, който отличава счетоводния бекенд от обикновения API за ставки. Заключването на периоди е другото важно нещо: затворените месеци не трябва да бъдат презаписвани тихомълком, а корекциите трябва да създават проследими корректиращи статии вместо редакции.
Сравнение на одобрените кандидати
Повечето инструменти, които излизат при търсене на ДДС решения, не са от същия тип продукт. Ето къде се намират водещите кандидати и за какво е подходящ всеки от тях.
| Кандидат | Категория | Публични цени | Най-подходящ за |
|---|---|---|---|
| Nordlet | Облачно счетоводство с API-първи подход и вграден ДДС в ЕС | Публични: планове от €10/месец, таксуване на база API заявки, всеки модул във всеки план; ранен достъп, партньори за разработване на дизайна | Платформи и маркетинг плейс системи, които се нуждаят от счетоводни книги, изплащания и ДДС в собствения си продукт |
| Stripe Tax | Изчисляване на данъци, събиране и опционално управлявано деклариране в рамките на Stripe | Публични: €0.04 на API повикване за изчисляване и €0.45 на транзакция при регистрация за събиране; планове Tax Complete от €80 до €1,400/месец | Бизнеси, базирани на Stripe, които искат бързо изчисляване на данъци |
| Quaderno | Данъчна автоматизация, съвместимо фактуриране и отчети | Публични: от $29/месец (25 транзакции) до $149/месец (2,500); корпоративни над тези стойности по индивидуална заявка | По-малки дигитални и мултиканални продавачи, нуждаещи се от фактури, съобразени с данъците |
| Avalara | Мащабен механизъм за косвени данъци и услуги по съответствие | На база оферта | Корпорации, нуждаещи се от широко покритие и ERP интеграции |
| Vertex | Корпоративен данъчен механизъм с моделиране на отговорността на маркетинг плейсите | Непублични | Маркетинг плейси с множество продавачи, където отговорността между продавач и платформа е от ключово значение |
| Sovos | Управлявано съответствие с ДДС и регулаторни услуги | Индивидуални | Бизнеси, желаещи управлявана регистрация и декларации в мащаб |
Цените са посочени такива, каквито излизат на публичната страница с цени на съответния доставчик към момента на писане и подлежат на промяна без предизвестие; потвърдете ги преди изготвяне на бюджет.
Няколко компромиса заслужават специално внимание.
Nordlet спрямо инструментите само за данъци. Разликата е в това, че Nordlet не предлага изчисляване на ДДС наред с вашите счетоводни книги. Той е самите счетоводни книги. Когато самата платформа трябва да притежава счетоводния модел на данните, включително изплащанията и одитните следи, това е правилната форма. Честният компромис е свързан със зрелостта: продуктът е в ранен достъп и докато OSS и IOSS декларациите се изчисляват от вашите фактури с корекции за предходни периоди, пакетите за местни декларации се предлагат за три държави към момента - Литва (FR0600), Германия (UStVA) и Полша (JPK_V7M) - като никоя декларация не се подава към администрацията от ваше име. Сериозният купувач трябва да валидира покритието на държавите и работния процес по деклариране директно, вместо да ги приема за даденост.
Stripe Tax спрямо Quaderno. Stripe Tax има най-ясната публична API ценова листа в групата и се вписва перфектно, ако вече работите в екосистемата за таксуване и плащания на Stripe. Неговият API за транзакции записва данъчни транзакции, а не общи счетоводни статии. Quaderno е по-ориентиран към платформи за продажби, с прозрачни месечни абонаменти и гъвкав API за изпращане на данни за продажби, макар публичните му материали изрично да не потвърждават поддръжка на OSS/IOSS или главна книга. Нито един от тях не трябва да се представя като заместител на счетоводство с двойно записване.
Avalara, Vertex и Sovos. Това са корпоративни решения. Avalara има най-широкия обхват при косвените данъци, но изисква търговски процес за определяне на обхвата. Vertex се откроява при маркетинг плейсите, тъй като изрично моделира тристранни транзакции и определя коя страна носи отговорност. Sovos е най-силна там, където управляваната регистрация, деклариране и регулаторната поддръжка надхвърлят вграденото счетоводство. Нито една от тях не е документирана като API за главна книга.
За платформа, чието основно изискване са вградени и готови за одит счетоводни книги с ДДС, записан в същата стопанска операция, Nordlet е най-чистият избор сред тях, с уговорката, че нейната готовност за производство е нещото, което трябва да се тества, а не архитектурата ѝ.
Въпросът за периода от 2027 до 2030 г., който повечето купувачи пропускат
Изборът на ДДС инструмент през 2026 г. само на базата на днешните правила е късогледо. Европейският пакет „ДДС в ерата на цифровите технологии“ (ViDA) беше приет през март 2025 г. и се въвежда на етапи.
- От 1 януари 2027 г. режимите OSS и IOSS се променят, включително с нов механизъм за корекции, допълнителна IOSS информация и месечни IOSS справки по държава членка на потребление.
- От 1 юли 2028 г. правилата за платформите се разширяват и започва задължително обратно начисляване за определени неидентифицирани доставчици.
- От 1 юли 2030 г. дигиталното отчитане на трансгранични B2B транзакции преминава към електронно фактуриране.
- Системите за местно отчитане в реално време се хармонизират до 1 януари 2035 г.
Практическият тест не е дали даден API изчислява ДДС правилно днес. Той е дали неговият модел на данни може да съхрани оригиналната транзакция, данъчното решение, фактурата, корекцията, самоличността на продавача и доказателствата във формат, който ще захранва електронното фактуриране и дигиталното отчитане, когато тези изисквания станат задължителни. Една неизменяема главна книга със структурирани метаданни на фактурите, която вече може да генерира издадени фактури във формат EN 16931 UBL за Peppol, е в много по-добра позиция за това в сравнение с крайна точка за ставки без запазване на състояние (stateless rate endpoint).
Какво бихме тествали преди подписването на какъвто и да е договор
- Определете границите на системата. Решете дали доставчикът е вашата главна счетоводна книга, двигател за данъчни решения, услуга за деклариране или само един компонент. Запишете го.
- Моделирайте реални транзакции преди да сравнявате цените. Изпълнете сценарии за местни B2C, вътреобщностни B2C, вътреобщностни B2B с валиден ДДС номер, невалиден или недостъпен VIES, продажби с фиктивен доставчик през маркетинг плейс, възстановявания на суми, отстъпки и смесени ставки.
- Изисквайте обяснение на данъчното решение. Отговорът трябва да показва защо е избрана съответната ставка, юрисдикция, освобождаване, обратно начисляване или отговорно лице.
- Провържете VIES нарочно. Потвърдете времевите отпечатъци, идентификаторите на заявки, логиката за повторни опити, кешираните резултати и пътя за ръчна проверка.
- Инспектирайте експортите, а не таблото за управление. Поискайте примерни OSS, ДДС декларации, фактури, счетоводни дневници и одитни файлове.
- Тествайте неизменяемостта. Опитайте да презапишете затворен период. Системата трябва да откаже и да принуди създаването на проследима корекция.
- Разделете ценообразуването на изчисленията от това за съответствие. Получете пълната цена за API заявки, транзакции, регистрации, декларации, съхранение, поддръжка и допълнителни юрисдикции.
- Валидирайте икономиката на платформата. За маркетинг плейс моделирайте разходите на продавач, транзакция и активен акаунт, а не само водещата цена за търговски абонамент.
- Потвърдете готовността за производство. Нива на обслужване (SLA), ограничения на честотата (rate limits), уебхукове, идемпотентност, пълно съответствие на тестовата среда (sandbox parity), местоположение на данните и права за експорт.
- Оценете бъдещата съвместимост. Претеглете изрично промените в OSS за 2027 г., правилата за платформите от 2028 г. и трансграничното отчитане от 2030 г.
Повечето от този списък могат да бъдат изпълнени срещу тестова компания (sandbox company) за следобед; ръководството за ДДС в ЕС документира кои случаи на място на изпълнение, обратно начисляване, фиктивен доставчик и OSS/IOSS казуси решава Nordlet и къде се задействат нейните предупреждения.
FAQ
Дали ДДС API е същото като счетоводен API?
Не. Един ДДС API изчислява или подава данъци. Счетоводният API поддържа двойно записване на счетоводните книги и съхранява ДДС като един от атрибутите на записаната транзакция. Ако вашата платформа трябва да бъде официалната система за запис (system of record), инструментът само за ДДС ви оставя да поддържате главната книга на друго място и да съгласувате два източника.
Мога ли да разчитам на VIES за B2B валидация в реално време при плащане (checkout)?
Не като единствена синхронна зависимост. VIES отправя заявки към национални бази данни и може да бъде временно недостъпен; валиден номер може да не се появи, ако бизнесът не е регистриран за търговия в рамките на ЕС, а миналата валидност не може да бъде потвърдена по-късно. Изградете кеширане, повторни опити, времеви отпечатъци, идентификатори на заявки и опашка за ръчна проверка около него.
Означава ли „поддържа OSS“, че доставчикът подава моите декларации?
Рядко и никога не трябва да го приемате за даденост. Това може да означава отчет, изчисление, помощ при регистрация или напълно управлявано подаване. Попитайте точно кои държави и декларации са обхванати, кой ги подава и как се обработват корекциите.
Защо Nordlet присъства в това сравнение, при положение че все още е в ранен достъп?
Защото това е най-близката по категория платформа за компании, които се нуждаят от вградени счетоводни книги, изплащания, цялост на главната книга и ДДС метаданни в един продукт, което повечето API-та само за данъци не предоставят. Ранният достъп е реално ограничение по отношение на сроковете за производство и покритието на държавите, така че третирайте наличността и работния процес по деклариране като въпроси за валидиране, а не като уговорени факти.
Коя единична грешка причинява най-много проблеми с ДДС впоследствие?
Липсата на съхранение на доказателствата зад данъчното решение. Администрациите могат да изискват записи години след продажбата, а OSS записите трябва да се пазят десет години. Инструмент, който връща правилна ставка, но изхвърля доказателствата за местоположението, резултата от VIES и връзката с транзакцията, ще се провали на одит, въпреки че всяко изчисление е било правилно.