Рег. №: 1787324438-21.08.2026 | Национална агенция за приходите | Прието на платформата | Дата на подаване: 21.08.2026 | Срок:04.09.2026

Физическо лице |

ЗАЯВЛЕНИЕ ЗА ДОСТЪП ДО ОБЩЕСТВЕНА ИНФОРМАЦИЯ

ДО Изпълнителния директор на НАЦИОНАЛНА АГЕНЦИЯ ЗА ПРИХОДИТЕ

Относно: бизнес валидациите, прилагани от информационната система на НАП при приемане на SAF-T, извън описаните в Приложение № 2 към Заповед № З-ЦУ-30-1085/25.07.2025 г.

Уважаеми господин Изпълнителен директор,

На основание чл. 24 и сл. от Закона за достъп до обществена информация моля да ми бъде предоставена посочената по-долу обществена информация, създавана и съхранявана от Националната агенция за приходите във връзка с прилагането на чл. 71з и сл. от ДОПК.

I. Какво вече е публикувано и защо то не съдържа исканата информация

Известно ми е, че със Заповед № З-ЦУ-30-1085/25.07.2025 г., изменена със Заповед № З-ЦУ-30-1247/25.08.2025 г. и Заповед № З-ЦУ-30-359/27.02.2026 г., са утвърдени XSD-схемата (Приложение № 1), файлът „SAF-T_BG_Structure_Definition“ (Приложение № 2) и документът „SAF-T_BG_Format_Reporting“ (Приложение № 3), като от 01.04.2026 г. файловете се подават съгласно версия 1.0.2. Настоящото заявление изрично не се отнася до тези публикувани материали и не може да бъде удовлетворено чрез препращане към тях, по следните съображения.

Приложение № 2 съдържа за всеки елемент две колони, озаглавени „Синтактични валидационни правила“ и „Семантични валидационни правила“. При съпоставка между тези колони и съобщенията, които информационната система реално връща при подаване, се установява разминаване, което е предметът на настоящото заявление.

Първо. За значителна част от елементите, по които системата отхвърля данни, и двете колони в Приложение № 2 съдържат стойност „N/A“, тоест никакво правило. Такива са, наред с други, S.H.1 AuditFileVersion, MF.C.3 CustomerID, MF.S.3 SupplierID, MF.PS.9 OwnerID, GL.9 TransactionID, GL.19 CustomerID, GL.20 SupplierID, GL.24.1 TaxpayerAccountID, GL.28 CustomerID, SD.P.1 Number of entries, SD.P.8 TransactionID, SD.P.23 SupplierID, S.I.23 CustomerID, S.I.26 SupplierID, S.I.36 ProductCode, S.C.8 RelatedPartyStartDate и S.C.9 RelatedPartyEndDate. Въпреки това системата връща за всеки от тях кодирано съобщение за несъответствие.

Второ. За друга част от елементите Приложение № 2 съдържа правило, но то е с различен предмет от реално прилаганото. Така при GL.12 TransactionDate документът предвижда единствено валидиране съгласно стандарт ISO 8601, докато системата отхвърля данните, защото датата на транзакцията е след датата на въвеждане по GL.17. При GL.17 SystemEntryDate документът отново предвижда само ISO 8601, а системата проверява дали датата не е преди началото на отчетния период или след датата на създаване на файла. При MF.GLA.11 и MF.GLA.12 семантичното правило в документа урежда само избора между дебитно и кредитно салдо, а системата съпоставя крайното салдо със сумата на оборотите по същата сметка от секция GeneralLedgerEntries. При SD.SI.2, SD.SI.3, SD.PI.2 и SD.PI.3 документът описва формата на десетичното число, а системата съпоставя сборовете с S.I.46 InvoiceLineAmount. При SD.P.9 документът предвижда ISO 8601, а системата проверява попадането на датата в отчетния период.

Трето. От наблюдаваните при подавани файлове кодове само шест съответстват на правило, описано в Приложение № 2, а именно четири, които препращат към номенклатурата на счетоводните сметки NRA_Nom_Accounts, един към номенклатурата на стоковите кодове и един към формата на IBAN. Останалите налагат кръстосани проверки между секции и времева логика, които документът не описва. Отделно, системата се позовава на номенклатура с наименование „NC8_TARIC3“, каквото в Приложение № 2 не се среща, където съответната таблица е наименувана „NC8_TARIC“.

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

Пето. Извън трите приложения към заповедта Националната агенция за приходите е публикувала документ „SAF-T. Въпроси и отговори“, версия 2 от март 2026 г., ЦУ на НАП, София, с обем 100 страници, обозначен изрично като „Публична информация. TLP-WHITE“. В раздел IV.2 „Получавани съобщения за грешки“, стр. 94 и следващите, агенцията сама възпроизвежда дословни текстове на съобщения, връщани от информационната система, и разяснява проверки, които не са описани в нито едно от приложенията. Така в т. IV.2.4 се формулира изискването контрагентите да се идентифицират с код 10 и ЕИК без префикс на държавата, при положение че колоните за валидационни правила по съответните елементи са „N/A“; в т. IV.2.5 се описва равнението на сборовете по SD.SI.2 и SD.PI.2 срещу S.I.46 без включване на S.TI.6 TaxAmount; в т. IV.2.6 се предписва подаване на празни секции с нулеви структури, включително сметка 998, дата 1900-01-01 и кодове 000 и 000000, изисквания, които не се съдържат нито в XSD-схемата, нито в колоните за валидационни правила. Документът съдържа и вътрешно позоваване на предходната си версия, от което следва, че материята се поддържа и версионира.

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

II. Искана информация

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

1. Пълният списък на кодовете (стойностите на елемента err_code) и на стандартните текстове на съобщенията (стойностите на елемента err_descr), които информационната система на НАП може да върне в резултатния файл към подателя при приемане и валидиране на SAF-T, в машинночетим вид (.xlsx или .csv).

2. За съобщенията по т. 1, наличната информация за това дали съответната проверка произтича от правило, описано в Приложение № 2 към Заповед № З-ЦУ-30-1085/25.07.2025 г. в действащата ѝ редакция, и кой е съответният елемент. Доколкото тази връзка е отразена в съществуващ документ (спецификация, техническо задание, таблица за съответствие или аналогичен материал), моля да ми бъде предоставен този документ или относимата му част. Не се иска изготвяне на нов анализ. Ако документ, който съдържа такава връзка, не съществува, моля да бъда уведомен изрично за това обстоятелство.

3. Наименованието, номерът и датата на акта, заповедта или вътрешния документ, с който са утвърдени бизнес валидациите, които не са описани в Приложение № 2, както и информация дали този акт е публикуван и на кой интернет адрес. При основание за ограничаване на достъпа до съдържанието му, моля да бъдат предоставени поне идентификационните му данни, които сами по себе си не разкриват защитена информация. Ако бизнес валидациите не са утвърдени с акт, моля да бъда уведомен изрично за това обстоятелство.

4. Общият брой на прилаганите към датата на произнасяне бизнес валидации и разпределението им по секциите на SAF-T, в обобщен числов вид, доколкото такъв обобщен показател се поддържа. Ако не се поддържа, предоставянето на списъка по т. 1 е достатъчно и по настоящата точка не се иска отделен отговор.

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

6. Наименованието на номенклатурата, срещу която се валидират стоковите кодове, посочвана в съобщенията като „NC8_TARIC3“, и съотношението ѝ към таблицата „NC8_TARIC“ от Приложение № 2, включително дали се прилага различна или актуализирана редакция.

7. Информация дали НАП публикува или предвижда да публикува списъка по т. 1 в специализираната рубрика „SAF-T в България“, а при отрицателен отговор, на какво основание информация, която системата ежедневно изпраща на подателите и част от която агенцията вече е публикувала в документа по раздел I, точка Пето, не подлежи на публикуване в пълен обем.

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

III. Мотиви

Обхват на искането. Искането изрично не се отнася до прагове, тегла, риск-скоринг, алгоритми за селекция или профилиране, критерии за възлагане на ревизии и проверки, нито до данни за конкретни лица. То обхваща съобщенията, които системата вече връща към подателите, идентификационни данни за актовете и обобщени числови показатели.

Относно чл. 14, ал. 4, т. 4 от ЗНАП. Тази разпоредба обявява за служебна тайна критериите за селекция и анализ на риска във връзка с осъществяване на ревизии и проверки. Бизнес валидациите не са такива критерии по три самостоятелни признака. Първо, те се прилагат върху всеки подаден файл без изключение, а не върху подбрана съвкупност, тоест по дефиниция не селектират. Второ, резултатът от тях се съобщава на самото подаващо лице с указание да коригира, докато селекционен критерий, съобщен на селектираното лице, престава да бъде селекционен. Трето, изходът на една и съща проверка може да бъде потвърждение за успешно валидиране и приемане, а критерий за анализ на риска, който завършва с изрично потвърждение за редовност, изпратено до самото лице, е логически невъзможен. Отделно от това, посочените в т. 4 категории са изрично изключени от предмета на настоящото искане.

Относно чл. 14, ал. 4, т. 2 от ЗНАП. Тази разпоредба обявява за служебна тайна информацията относно проектиране, изграждане и функциониране на информационни системи и мрежи за предаване на данъчна и осигурителна информация. Исканата информация не описва проектирането, изграждането или функционирането на система за предаване на данни, а съдържанието на съобщенията, които системата вече е изпратила. При обратното тълкуване, при което всяка информация, свързана с информационна система на НАП, би била служебна тайна, недопустимо би било както публикуването на самата XSD-схема и на Приложения № 2 и № 3 с колоните „Синтактични валидационни правила“ и „Семантични валидационни правила“, така и, на още по-силно основание, публикуването на дословните текстове на връщаните съобщения в раздел IV.2 на документа „SAF-T. Въпроси и отговори“, версия 2. И двата материала носят изричното отбелязване „Публична информация. TLP-WHITE“. Един и същ текст на едно и също съобщение не може да бъде публична информация, когато е поместен в разяснителен документ, и служебна тайна, когато е поместен като ред в списък. Разпоредбата очевидно не се тълкува разширително от самата агенция и искането по същество е публикуваната част да бъде допълнена до пълнота.

Относно чл. 14, ал. 4 във връзка с ал. 5 от ЗНАП. Съгласно ал. 5 сведенията, определени като служебна тайна по ал. 4, се създават, получават, обработват, предоставят, съхраняват и унищожават при условията и по реда на Закона за защита на класифицираната информация. Ако кодовете и текстовете на съобщенията попадат в обхвата на ал. 4, то автоматичното им изпращане чрез портала до всяко подаващо лице, без проучване за надеждност и без разрешение за достъп, би съставлявало системен нерегламентиран достъп до класифицирана информация. Такова положение не може да бъде поддържано. Вярна е една от две тези: или информацията не е служебна тайна и следва да бъде предоставена, или тя е служебна тайна и агенцията я разгласява ежедневно.

Относно реда за класифициране. Позоваването на служебна тайна предполага завършена верига от предпоставки. Съгласно чл. 26 от ЗЗКИ подлежащата на класификация информация се определя със закон, а ръководителят на организационната единица обявява списък на категориите за своята сфера на дейност. Класифицирането приключва с маркиране на конкретния документ с гриф за сигурност, регистрационен номер и срок на защита, който за служебна тайна е шест месеца съгласно чл. 34 от ЗЗКИ. Ако достъпът бъде ограничен, моля в решението да бъдат посочени поотделно за всяко искане: а) конкретната точка на чл. 14, ал. 4 от ЗНАП; б) съответната точка от списъка по чл. 26, ал. 3 от ЗЗКИ; в) актът за класифициране, регистрационният номер, датата на маркиране, нивото на класификация и дали срокът на защита не е изтекъл; г) конкретните мотиви защо разгласяването на текст, който системата вече е изпратила на подаващите лица, би увредило правнозащитен интерес.

Относно предходно произнасяне. С Решение № Р-ЦУ-30-33 от 09.03.2026 г. по т. 4 от предходно мое заявление достъпът беше отказан. Ограничението по чл. 37, ал. 1, т. 2 от ЗДОИ е приложимо само когато исканата информация е била предоставена на заявителя, поради което то не намира приложение. Отделно от това предметът на настоящото искане е различен и по-тесен: искат се кодовете и текстовете на съобщенията, които системата връща на подателите, а не каталогът на бизнес правилата като вътрешен методологичен документ.

Надделяващ обществен интерес. Задължението по чл. 71з и сл. от ДОПК е нормативно, санкционирано и обхваща десетки хиляди предприятия. Правилата, на които трябва да отговаря един файл, за да бъде приет, са условие за изпълнение на публично задължение, а не метод на контрол. Тъкмо това е и логиката, поради която НАП е публикувала синтактичните и семантичните правила в Приложение № 2 и част от текстовете на съобщенията в документа „Въпроси и отговори“. Прилагането на допълнителни, непубликувани правила от същия вид възлага на задължените лица да изпълняват изискване, чието съдържание научават едва след като са го нарушили, и то в частичен обем, доколкото при над тридесет хиляди констатирани несъответствия подателят получава описание на хиляда от тях и няма ред, по който да узнае останалите. Разработчиците на счетоводен и ERP-софтуер, за които рубриката „SAF-T в България“ е създадена изрично, не могат да съобразят продуктите си с правила, които не са им известни.

Частичен достъп. При наличие на основания по чл. 37, ал. 1 от ЗДОИ по отношение на част от исканата информация, моля на основание чл. 37, ал. 2 от ЗДОИ да бъде предоставен достъп до останалата част, включително чрез заличаване на отделни елементи.

Предпочитана форма: копия по електронен път в машинночетим формат (.xlsx, .csv, .pdf, .docx) или интернет адрес, на който информацията е публикувана, на посочения при подаването адрес на електронна поща.

8