Новини

Становище за ЗИД на ЗДДС
Публикувано на: 23.10.2026 10:23

Становище на СМТ изпратено до министъра на финансите Гълъб Донев и до председателя на Комисията по бюджет и финанси Константин Проданов

 Във връзка с публикувания за обществено обсъждане Проект на Закон за изменение и допълнение на Закона за данък върху добавената стойност (ЗИД на ЗДДС) и Мотивите към него, отправяме молба да обсъдите и обърнете внимание на следните наши коментари, забележки и предложения.

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

Предложеният модел на електронно фактуриране в проекта на ЗИД на ЗДДС обаче съдържа концептуални и технически недостатъци, които са в сериозен разрез с европейската Директива (ЕС) 2025/516 (ViDA Directive), създават административна тежест за бизнеса, рискове за непрекъснатостта на търговската дейност и критична зависимост от централизирана държавна платформа.

Във връзка с гореизложеното, бихме желали да изразим своята загриженост относно следните ключови области:

I. В разрез с Директивата ViDA (Директива (ЕС) 2025/516) и принципа за незабавно/паралелно издаване на фактурите

 

В предложения § 42 от проекта (създаващ чл. 120а – 120д) е заложено, че структурираната електронна фактура се счита за издадена и съответно получена от купувача едва в момента, в който за нея бъде генериран уникален код за съответствие от Националната информационна система за структурирано електронно фактуриране и цифрово отчитане (НИССЕФ) към НАП.

Така предвидената процедура представлява скрит режим на предварително одобрение/клирънс (Clearance Model), който пряко противоречи на правото на ЕС и архитектурата на ViDA поради следните причини:

  1. Концепция за отпадане на предварителната валидация/клирънс: Директива ЕС 2025/516 (ViDA) изрично премахва възможността държавите членки да налагат задължителни системи за предварително одобрение или забавяне на издаването на фактурите от страна на данъчните органи. Фактурирането между гражданскоправните субекти е първичен търговски процес, а данъчното отчитане към държавата е вторичен съпътстващ процес.
  2. Нарушаване на европейския стандарт EN 16931: Чрез задължаването за получаване на уникален код за съответствие от НИССЕФ преди фактурата да се счита за правно валидна, се нарушава основният принцип на EN 16931 за пряка оперативно съвместима обмяна.
  3. Блокиране на търговския оборот при срив (Single Point of Failure): Централизираната завереност прави бизнеса напълно зависим от непрекъснатата работа на системата НИССЕФ . Всеки технически проблем, прекъсване на свързаността или пиково натоварване в НАП незабавно спира издаването на фактури и стокооборота в цялата страна. Според международните архитектурни стандарти Peppol/ViDA, системата трябва да прилага паралелен обмен (Parallel Exchange), при който доставчикът изпраща фактурата на купувача и едновременно с това подава данните към данъчната администрация, без едното да спира другото.

II. Погрешен централизиран модел (НИССЕФ) вместо утвърдения европейски децентрализиран 5-corner/6-corner модел (Peppol)

 

В Мотивите и проекта на ЗИД на ЗДДС се предвижда изграждането на централизирана държавна платформа НИССЕФ на стойност 20 млн. евро, през която централно да преминават, валидират и съхраняват всички електронни фактури в държавата.

Този централизиран подход е технически остарял и икономически неефективен поради следните причини:

  • Европейската стратегия и Peppol CTC архитектура: Водещите европейски държави (Белгия, Словения, Швеция, Финландия, Австралия и др.) преминават към децентрализиран 5-corner / 6-corner модел, базиран на Peppol eDelivery мрежата. В този модел доставчикът използва своя доставчик на услуги, който изпраща фактурата директно до доставчика на услуги на купувача, като паралелно подава необходимия екстракт от данъчни данни (TDD – Tax Data Document) към платформата на данъчната администрация.
  • Гъвкавост и сигурност: Децентрализираният Peppol модел премахва критичната точка на срив (Single Point of Failure) и позволява на бизнеса да използва лицензирани доставчици на услуги (Service Providers), без да се налага държавата да обработва целия оперативен трафик на данни в реално време.
  • Необоснован разход от 20 млн. евро за държавния бюджет: Изграждането на масивна централизирана монолитна система за 20 млн. евро е излишен разход, когато НАП може да изгради единствено входна точка за прием на структурирани данъчни отчети (TDD) по международно утвърдения Peppol стандарт.

III. Ключови аргументи за внедряването на модела Peppol в България

Внедряването на стандартизирания децентрализиран модел Peppol предлага редица стратегически, технически и финансови предимства спрямо изграждането на локална централизирана платформа:

  1. Богат опит с добри практики и пълна готовност за ViDA:
    • Доказан успех: Поради факта, че редица държави вече са внедрили или са в процес на внедряване на Peppol, съществува богат детайлен опит и практически доказани добри практики, които да ръководят и улеснят процеса на въвеждане у нас.
    • Проактивно съответствие: Пилотният проект Peppol ViDA (VAT in the Digital Age), в който участват множество държави, гарантира, че ранните потребители са идеално позиционирани да посрещнат плавно и безпрепятствено предстоящите европейски ViDA изисквания.
  2. Взаимна полза за приходните органи и бизнеса (Win-Win):
    • Постигане целите на данъчната администрация: Архитектурата „5-corner model“ на Peppol гарантира, че НАП получава пълната изискуема информация и прозрачност за целите на спазването на законодателството и събираемостта на данъците.
    • Ефективност за бизнеса: Бизнесът получава възможност да използва ефективни, с ниска себестойност и съвременни технологии за обработка на фактури. В крайна сметка и публичният, и частният сектор спестяват значително време и финансови ресурси.
  3. Минимизиране на рисковете от внедряването (Избягване на чести грешки):
    • Поука от чуждия опит: Практиката в страни, опитали да внедрят алтернативни или специфични „национални“ модели, показва, че тези проекти рядко протичат безпроблемно. Те постоянно страдат от забавяния в графика и най-вече от сериозни преразходи на бюджета. Приемането на вече съществуваща, стандартизирана рамка като Peppol минимизира тези рискове.
  4. Безпроблемна трансгранична интеграция и устойчивост във времето:
    • Автоматична готовност за вътреобщностни доставки: Въвеждането на Peppol на национално ниво автоматично подготвя страната за предстоящите ViDA мандати. Веднъж внедрена на местно ниво, инфраструктурата е незабавно готова да приема трансгранични (вътреобщностни) фактури от чуждестранни компании без нужда от допълнителна разработка.
    • Предимство за държавата: Държавата е пряк бенефициент, тъй като автоматично получава достъп до данни за трансграничните фактури през мрежата на Peppol.
  5. Избягване на двойни разходи за внедряване в България:
    • Дългосрочна разходна ефективност: Чрез възприемането на Peppol още сега България избягва капана на „двойното внедряване“ – сценарий, при който днес се изгражда временна или локализирана система, която по-късно изисква сложна и изключително скъпа преработка, за да се приведе в съответствие с бъдещите европейски стандарти.

 

IV. Прекомерно събиране на данни (в разрез с принципа Data Minimization) и търговска конфиденциалност

 

Проектът на закон и структурата на НИССЕФ предвиждат подаване и централизирано съхранение на пълния обем съдържание на фактурите .

  1. Нарушаване на принципа за минималност на данните (Data Minimization): Рамката ViDA и европейските добри практики изрично изискват данъчните администрации да събират само строго необходимия за данъчен контрол ред от данни (Tax Data Document – TDD), а не детайлни търговски спецификации, продуктови кодове, рецептури или търговски отстъпки по единични артикули, които съставляват търговска тайна.
  2. Рискове за киберсигурността и търговската тайна: Концентрирането на цялата търговска информация на всички бизнеси в страната в една централна база данни създава колосален риск от кибератаки, изтичане на информация и неоторизиран достъп до чувствителни ценови политики и логистични вериги.

V. Неприложими срокове, санкции и прекомерна административно-техническа тежест

 

Предложеният законов проект въвежда изключително тежки и практически неосъществими технически и правни изисквания за бизнеса:

  1. Срок за отстраняване на несъответствия (§ 42, чл. 120г, ал. 3): Имуществена санкция от 50 000 до 100 000 евро (и до 250 000 евро при повторение) за софтуерни грешки или код, блокиращ трансфера.

Срокът от 48 часа е абсолютно неприложим за големи ритейл системи, обработващи стотици хиляди фактури дневно. При технически или номенклатурен дефект такъв срок води до блокиране на плащания и непрекъснати глоби. Срокът трябва да бъде удължен най-малко на 5 до 10 дни.

  1. Санкции за разработчици и ERP среди (§ 98, чл. 192б): При несъответствие системата връща съобщение, което трябва да се отстрани в срок до 48 часа.

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

  1. Санкции за неиздаване (§ 85, чл. 182а): Имуществена санкция за юридически лица в размер на неначисления данък, но не по-малко от 1 500 евро за всяко нарушение.

Превръща всяка техническа грешка при предаване на данни в реално време в неоправдано висока глоба за търговските вериги, където броят фактури е голям, но данъкът не достига размерите на минимално посочената глоба.ЗАКЛЮЧЕНИЕ И ПРЕДЛОЖЕНИЯ

 

 

Предвид гореизложеното, апелираме Министерството на финансите и Народното събрание да преразгледат изцяло концепцията за електронно фактуриране в проекта на ЗИД на ЗДДС и да предприемат следните конкретни изменения:

  1. Премахване на режима на клирънс (предварително одобрение): Да се отмени изискването електронната фактура да се счита за издадена само след генериране на уникален код от НИССЕФ (§ 42, чл. 120а, ал. 3). Фактурата следва да се счита за издадена в момента на предаването ѝ от доставчика към купувача, а отчитането към НАП да става чрез паралелен незабавен отчет.
  2. Възприемане на децентрализирания Peppol 5-corner / 6-corner модел: Вместо монолитна централизирана платформа за 20 млн. евро, НАП да изгради стандартизирана точка за достъп в Peppol мрежата, позволявайки на бизнеса и лицензираните доставчици на услуги да обменят фактури по стандартите EN 16931 / Peppol BIS .
  3. Прилагане на принципа за минималност на данните (TDD): Към НАП да се предава само регулаторно изискуемият екстракт от данъчни данни (Tax Data Document – TDD), без да се изисква и съхранява пълното търговско съдържание на фактурите.
  4. Преразглеждане на сроковете и санкциите:
  • Срокът за коригиране на технически несъответствия по чл. 120г, ал. 3 да се увеличи от 48 часа на минимум 7 работни дни.
  • Отпадане или чувствително намаляване на санкциите по чл. 182а и чл. 192б.
  1. Удължаване на преходните срокове за тестване: Предвиденият 6-месечен срок за тестване (§ 103) да се увеличи на най-малко 12 месеца, за да се гарантира пълна интеграционна готовност на ERP средите и търговските софтуери на бизнеса.