Реално време за ДДС в ЕС за разработчици, които създават софтуер в България

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

България изисква данни на ниво фактура с всяка ДДС декларация от години: месечното подаване представлява справка-декларация плюс дневници за покупките и продажбите, а не набор от крайни суми. В момента SAF-T постепенно се въвежда в допълнение към това, като започва с големите данъкоплатци през 2026 г. Следователно въпросът към всеки доставчик на софтуер в България е прост и категоричен - може ли той да генерира документите, стоящи зад числата, всеки месец, без ръчен експорт.

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

Какво трябва да включва „управлението на ДДС в ЕС в реално време“

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

Да определи третирането по ДДС въз основа на данните от трансакцията.
Да приложи актуалните правила за съответната държава и продукт.
Да покрива България и целия ЕС, включително B2B режима на самоначисляване и B2C данъчното облагане по местоназначение.
Да предоставя всичко това чрез API, SDK или уебхук (webhook).
Да съхранява данните за ДДС, OSS, одита и счетоводното отчитане.

Зад думите „в реално време“ се крият три различни възможности:

Изчисление в реално време - ДДС се изчислява при създаването на трансакцията или фактурата.
Счетоводство в реално време - трансакцията, счетоводната операция и данните за ДДС попадат в счетоводството незабавно.
Отчитане в реално време - данните се предават на данъчната администрация малко след трансакцията.

Повечето продукти правят първото. Много малко правят и трите. България се намира близо до третата категория без платформа за предварително одобрение (clearance): месечната декларация съдържа дневници за покупки и продажби, а SAF-T се въвежда поетапно от 2026 г., така че данъчната администрация получава данни на ниво документ.

Българските и европейските правила, които оформят сравнението

България прилага стандартна ставка от 20% и намалена ставка от 9%, обхващаща хотели и туристическо настаняване, книги и периодични издания, както и храни и хигиенни продукти за бебета, с 0% за износа и вътреобщностните доставки. Законовата основа е Законът за данък върху добавената стойност (ЗДДС). Регистрацията е задължителна при оборот над 100 000 лв. - около 51 130 евро по фиксирания курс към еврото - като регистрацията трябва да се извърши в 7-дневен срок от неговото надвишаване.

За отговарящите на условията вътреобщностни B2C дистанционни продажби и трансгранични дигитални услуги прагът за целия ЕС е 10 000 евро, определен на портала One Stop Shop на Европейската комисия. Над този праг ДДС обикновено следва държавата членка на клиента. One Stop Shop позволява на даден бизнес да се регистрира в една държава членка и да декларира трансгранично B2C ДДС за целия ЕС, но това не премахва необходимостта от логика на ниво трансакция.

Съществува и правило за електронните магазини (marketplace), което е по-строго, отколкото повечето екипи очакват. Съгласно член 14а електронният интерфейс се превръща в приносен доставчик (deemed supplier) за дистанционни продажби на вносни стоки в пратки с обща стойност, ненадвишаваща 150 евро, както и отделно за стоки, доставени на клиенти в ЕС на каквато и да е стойност, когато действителният продавач не е установен в ЕС. Обяснителните бележки на Комисията относно правилата за електронната търговия с ДДС определят и двете направления. Ако изграждате електронен магазин (marketplace), това променя архитектурата, а не просто добавя едно поле.

Кратък преглед на селекцията

Платформа	Най-добра за	Възможност за ДДС в реално време	Обхват на счетоводството, OSS и подаването	Основна забележка
Stripe Tax	Продукти и платформи, които вече използват Stripe	Изчислява ДДС при създаване на трансакцията, включително за България	Износ за ЕС и данни за OSS; няма български дневник и не подава декларации за ЕС самостоятелно	Струва си само ако Stripe вече е платежният оператор
Paddle	SaaS и софтуер за сваляне	Изчислява ДДС при плащане (checkout) спрямо местоположението на клиента	Регистрира, подава декларации и внася данъка в ролята си на търговец на запис (Merchant of Record)	Поема ролята на продавач от името на фирмата и издаването на фактурата заедно с нея
Quaderno	По-малък SaaS и дигитална търговия	Изчислява при плащане (checkout), валидира ДДС номера	Данъчни отчети и записи; автоматичното подаване не е документирано за всеки план	Данъчен и фактуритерен слой, а не счетоводна книга
Avalara AvaTax	Ентерпрайз ERP и билинг системи	Определяне в реално време с поддържано данъчно съдържание	VAT Reporting е отделен продукт в портфолиото от решения за отчетност (Returns)	Предвидена и оценена за корпоративни внедрявания
Fonoa Tax Engine	Големи платформи и маркетплейси	Определяне в реално време в над 190 юрисдикции	Декларации, електронно фактуриране и отчети; валидирането на данъчни номера е отделен продукт	Няма обявени цени
Nordlet	Вградено счетоводство в маркетплейси и платформи	Разрешава режима и ставките за всяка трансакция, осчетоводявани заедно с счетоводната операция	Неизменяема двустранна счетоводна книга, изплащания, данни за OSS и IOSS, експортируем одитен след	Няма българска декларация, дневници или SAF-T пакет; запазва детайлите на ниво фактура, върху които се изграждат и трите

Stripe Tax: бързият път, когато Stripe вече е наличен

За екипи, които вече използват плащанията, Billing или Connect на Stripe, Stripe Tax е най-достъпният слой за изчисление в реално време. Документацията обхваща изчисляването на ДДС в световен мащаб, Tax API с PaymentIntents, събирането на данък върху фактури и използването на Tax с Connect като платформа или електронен магазин.

Къде спира Stripe е посочено ясно от самия него. Неговата документация за подаване на декларации гласи: „Трябва да декларирате и внесете данъка, който събирате за всяко място, където сте регистрирани.“ Автоматизираното подаване се предлага в Съединените щати; навсякъде другаде Stripe работи с партньори за подаване, така че декларацията за ДДС в ЕС се подава от вас или от партньор, а не от Stripe Tax. Това е слой за изчисление и експорт, а не счетоводна система.

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

Paddle: прехвърлете цялата данъчна отговорност на друг

Paddle е различна категория продукт. Той действа като търговец на запис (Merchant of Record) и поема отговорността за „изчисляване, подаване и внасяне“ на данъците там, където са вашите клиенти. Той изчислява ДДС при плащане (checkout), издава фактурата и подава декларациите и плащанията вместо вас. Неговата документация за разработчици обхваща Paddle.js, каталожните API, плащането (checkout) и уебхукове като transaction.completed, който се задейства, след като трансакцията достигне статус completed и е обичайният уебхук за предоставяне на достъп след плащане.

Компромисът е по-скоро архитектурен, отколкото технически. Paddle става официален продавач (seller of record), така че вие вече не поддържате търговския, фактурния и счетоводния модел, който бихте запазили със собствения си процес на плащане (checkout).

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

Quaderno: данъчен слой за по-малки дигитални бизнеси

Quaderno е една от по-ясните насочени към разработчиците опции за по-малки дигитални бизнеси, които искат данъчна услуга, независима от конкретен платежен процесор. Неговата API документация описва крайна точка (endpoint) /tax_rates/calculate, която изчислява приложимата ставка от адреса на клиента и типа на трансакцията, крайна точка /tax_ids/validate, която обхваща ДДС номерата в ЕС, както и крайни точки за фактури, касови бележки и кредитни известия. Документираната секция Connect с ресурси за акаунти е основата, върху която би надградил един маркетплейс.

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

Той покрива изчислението при плащане. Нито месечните дневници, нито SAF-T попадат в неговия обхват.

Avalara и Fonoa: ентерпрайз данъчни двигатели

AvaTax на Avalara извършва определяне на данъци в реално време по време на плащане (checkout), фактуриране или обработка на поръчки чрез REST API и SDK. Обърнете внимание на разделението на продуктите: VAT Reporting се намира отделно в портфолиото от решения за отчетност (Returns), така че работният процес по съответствие с ДДС в ЕС не е просто „AvaTax“ - преценете модулите, които наистина са ви необходими. Avalara документира път за регистрация с 90-дневен безплатен пробен период, докато търговският модел за продукционна среда е насочен към големи предприятия.

Tax Engine на Fonoa заявява, че „изчислява правилното третиране с косвени данъци за всяка трансакция в реално време“ чрез версиониран API в над 190 юрисдикции. Едно архитектурно уточнение е от значение: валидирането на данъчни номера е отделен продукт на Fonoa (Validate), а не част от Tax Engine, така че ако доказателствата от VIES са важни за вас, заложете ги изрично в обхвата, вместо да предполагате, че двигателят ги покрива.

И двете решения са твърде мащабни за проект, насочен само към България, въпреки че поетапното въвеждане на SAF-T е именно типът изискване, което в крайна сметка тласка по-големите групи към едно от тях.

Къде се вписва Nordlet: отговорът за ДДС и счетоводната операция са един и същ запис

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

Архитектурната разлика е, че определянето на ДДС и счетоводната операция принадлежат към една и съща система. POST /v1/reference/vat/resolve дава отговор на въпроса за данъчното третиране въз основа на фактите от трансакцията:

{
  "customerCountryCode": "BG",
  "customerIsBusiness": false,
  "supplyType": "digital"
}

{
  "scheme": "oss_union",
  "vatCountryCode": "BG",
  "reverseCharge": false,
  "deemedSupplier": false,
  "zeroRated": false,
  "rates": [
    { "category": "standard", "ratePercent": "20.00" },
    { "category": "reduced", "ratePercent": "9.00" }
  ],
  "legalBasis": "Directive 2006/112/EC art. 58 - taxable where the consumer resides; report via the Union OSS"
}

Ако промените клиента на бизнес с валиден български ДДС номер, същата заявка връща reverse_charge с правно основание Directive 2006/112/EC art. 44, 196 - VAT due by the customer (reverse charge). Ако зададете actingAsMarketplace с продавач, установен извън ЕС, тя връща deemedSupplier: true съгласно art. 14a(2). Правното основание пътува заедно с отговора - именно това е детайлът, за който одиторът пита години по-късно.

Моделирани са девет режима: domestic, intra_eu_b2b, reverse_charge, oss_union, ioss, marketplace_deemed, export, out_of_scope и sme_exempt. Прагът за дистанционни продажби от 10 000 евро се проследява, а не се предполага - /v1/declarations/eu/distance-sales-threshold/get показва къде се намира дадена компания спрямо него, а /v1/declarations/eu/oss/compute и /v1/declarations/eu/ioss/compute генерират данните за периода, включително секция за корекции за минали периоди. Ставките идват от информационния поток TEDB на Европейската комисия с дати на влизане в сила, като компанията може да ги презаписва по държави.

След това резултатът от изчислението се записва в неизменяема двустранна счетоводна книга с прикрепени към записа метаданни за ДДС, така че няма нужда от повторно съгласуване между данъчен двигател и отделна система за отчетност. Паричните суми са десетични низове (decimal strings), никога числа с плаваща запетая (floating-point). Около това са изградени: типизирани SDK, уебхукове като sale_invoice.paid, поддръжка на Idempotency-Key за безопасни повторни опити, тестови компании (sandbox), VIES валидация, замразена към съответната фактура, поддръжка на множество компании и заключване на периоди, така че затворен месец да не може да бъде редактиран незабележимо.

Българската граница. Nordlet не предлага български пакет: /v1/declarations/eu/vat-return/compute с countryCode: "BG" връща грешка 422, упоменаваща Литва, Германия и Полша, така че не се генерират нито месечната ДДС декларация, нито дневниците за покупки и продажби, нито български SAF-T файл. Това, което е налично, е базовият слой, върху който са изградени и трите - неизменяема двустранна счетоводна книга, съхраняваща записи на ниво фактура през затварянето на период, определяне на ДДС, носещо своето правно основание, изчисление на OSS и IOSS с корекции, VIES валидация, замразена към фактурата - плюс фактури по стандарт EN 16931 през Peppol BIS 3.0.

Честното обобщение: ако се нуждаете от изчисление в реално време в възможно най-много държави и искате някой друг да подава декларациите, ентерпрайз данъчните двигатели и услугите за търговец на запис (Merchant of Record) са по-напред. Ако основното ви изискване са истински счетоводни книги - двустранна счетоводна книга, съобразена с маркетплейси, където плащанията и ДДС се намират на едно място - това е празнината, за която е създаден Nordlet, и никой от слоещата за изчисление не я запълва. API документацията показва целия набор от възможности, преди да се ангажирате.

Какво ви задължава България да подавате

България изисква детайлите да бъдат в самите справки и дневници.

Месечна ДДС декларация с дневници - подава се до 14-то число на следващия месец, заедно с дневниците за покупки и продажби, които описват отделните документи.
SAF-T - въвежда се поетапно от 2026 г., като започва с големите данъкоплатци, които подават ежемесечно до 14-то число, а средните и малките предприятия следват след тях.
Електронно фактуриране - задължително само спрямо публичните организации. В момента няма действащо изискване за задължително B2B електронно фактуриране.

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

Пълната картина за страната - корпоративен данък, заплати, календар за подаване и институциите зад всяка форма - е на страницата за данъците в България.

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

Преди да третирате който и да е продукт, „готов за ДДС“, като еквивалентен на друг, го проверете по следните критерии:

Изчисление или счетоводство - определя ли той третирането по ДДС, или само съхранява код, който вие му подавате?
Българско покритие - 20%, 9%, 0%, самоначисляване и прагът от 100 000 лв. с неговия 7-дневен срок за регистрация?
Логика за европейското местоназначение - може ли да разграничи българското ДДС от това на друга държава членка за B2C продажба?
B2B валидация на ДДС номер - проверява ли VIES и пази ли доказателството за това?
OSS и IOSS - агрегира ли, подготвя ли, подава ли или само експортира данни?
Отговорност на маркетплейса - може ли да моделира ролите на продавач, платформа и приносен доставчик (deemed supplier)?
Счетоводна цялост - всяко изчисление води ли до съответстваща счетоводна операция?
Ергономия за разработчици - REST API, SDK, уебхукове, sandbox среда, идемпотентност, версиониране?
Одитна следа - ставка, правило, доказателство за местоположение, ДДС номер, времеви печат (timestamp), история на редакциите?
Дневници и SAF-T - може ли да генерира месечните дневници за покупки и продажби документ по документ и SAF-T файл, когато етапът достигне до вас?
Отговорност за подаване - коя точно стъпка поема доставчикът?

FAQ

Коя платформа предлага пълно управление на ДДС в ЕС в реално време в България?

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

Достатъчен ли е Stripe Tax за български маркетплейс?

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

Nordlet подава ли български ДДС декларации автоматично?

Не, и не генерира месечните дневници или български SAF-T файл. Пакети за декларации се предлагат за Литва, Германия и Полша; за България API връща грешка 422, упоменаваща тях.

Кога се прилага SAF-T в България?

Той се въвежда поетапно от 2026 г., като започва с големите данъкоплатци, подаващи ежемесечно до 14-то число, а средните и малките предприятия следват след тях. Потвърдете своя собствен етап с Националната агенция за приходите (НАП), преди да планирате срокове.

Какво да направите първо

Решете от коя от трите възможности в реално време се нуждаете и проверете изискването за счетоводните книги на първо място, тъй като то определя структурата на данните ви, а не интеграцията. Ако продавате дигитални продукти и искате да прехвърлите подаването на декларации извън вашите задължения, тествайте Paddle. Ако счетоводството, изплащанията и ДДС трябва да се намират вътре във вашия собствен продукт, започнете с тестовата среда (sandbox) и потвърдете българския обхват, преди да изграждате системата около него. Цените са публично обявени, а не по запитване.

Източници

Всяко твърдение на доставчик по-горе води до документацията на самия доставчик. Самите правила произтичат от:

Министерство на финансите / НАП: Насоки за ДДС - ставките от 20% и 9%, прагът за регистрация и месечната декларация
Европейска комисия: ДДС One Stop Shop - прагът за дистанционни продажби от 10 000 евро

Възможностите на доставчиците и националните нормативни изисквания се променят. Всичко тук е проверено спрямо обществено достъпната документация към 8 септември 2026 г.; проверявайте всичко, върху което ви предстои да градите.