Техническата страна на SAF-T: Готов ли е вашият ERP и счетоводен софтуер?

Счетоводната и данъчна отчетност в България навлиза в своята най-критична фаза на дигитална трансформация, която фундаментално променя правилата на играта за бизнеса. Въвеждането на стандарта SAF-T (Standard Audit File for Tax) представлява не просто поредната административна тежест или нова данъчна декларация, а напълно нова философия на комуникация между приходната администрация и данъкоплатците. Този преход към автоматизиран, алгоритмичен контрол означава, че ерата на хартиените папки, ръчните корекции в последния момент и агрегираното счетоводно отчитане приключва безвъзвратно.

Националната агенция за приходите (НАП) вече няма да изисква справки при започване на ревизия – тя ще разполага с пълно дигитално копие на корпоративните трансакции, генерирано директно от системите на предприятията. Изправени пред тази технологична революция, експертите на Balance.bg предупреждават, че неподготвеността на корпоративния софтуер не е просто ИТ предизвикателство, а директен финансов риск, водещ до автоматизирани и тежки санкции. Една от най-големите заблуди сред мениджърите е, че генерирането на файла е отговорност единствено на счетоводния отдел. Напротив, архитектурата на един качествен SAF-T ERP софтуер изисква пълна синхронизация между търговските, складовите и финансовите модули в предприятието.

Кого засяга промяната: Нормативна рамка и поетапен график

Законодателната рамка, уреждаща въвеждането на стандарта в България, е детайлно разписана в Данъчно-осигурителния процесуален кодекс (ДОПК), по-специално в новата глава осма „б“ и чл. 71з – 71к. За да се осигури плавен преход, държавата е предвидила поетапен график, който обвързва задължението за подаване на данните с финансовите показатели на компаниите от предходни отчетни периоди. Този подход обаче крие капани за бързо развиващите се бизнеси, които могат да се окажат в обхвата на закона по-рано от очакваното.

Експертният анализ на нормативните промени в ДОПК показва, че графикът е категоричен и не търпи отлагане:

Етап на въвеждане	Категория предприятие (според Закона за счетоводството)	Финансови критерии за включване в обхвата (суми в евро)	Базова година за оценка на критериите
01 януари 2026 г.	Големи предприятия	Нетни приходи от продажби над 153.39 млн. евро ИЛИ внесени данъци и осигуровки над 1.79 млн. евро	2023 г.
01 януари 2027 г.	Големи, средни и малки предприятия	Нетни приходи от продажби над 153.39 млн. евро ИЛИ внесени данъци и осигуровки над 1.79 млн. евро	2024 г.
01 януари 2028 г.	Големи, средни и малки предприятия	Нетни приходи от продажби над 7.67 млн. евро ИЛИ внесени данъци и осигуровки над 766,937 евро	2025 г.
01 януари 2029 г.	Всички големи, средни и малки предприятия	Задължително за всички субекти от тези категории, без праг за оборот	N/A
01 януари 2030 г.	Всички останали предприятия	Включва регистрираните по ЗДДС микропредприятия	N/A

Забележка: Всички финансови прагове са конвертирани в евро, съобразно влизането на Република България в еврозоната от 2026 г. Изчисленията на внесените данъци се базират на реалните постъпления в НАП, намалени с възстановените суми (например възстановено ДДС).

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

Новият данъчен календар: Срокове НАП, които променят бизнес ритъма

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

1. Месечен SAF-T файл: Това е ядрото на новата отчетност. Той съдържа всички счетоводни операции, фактури, плащания и справочна информация за месеца. Подава се до 14-то число на месеца, следващ отчетния период (синхронизирано със сроковете за ДДС декларациите). Тази времева рамка означава, че търговските и складовите документи трябва да бъдат обработени, валидирани и осчетоводени в рамките на броени дни.
2. Годишен файл за дълготрайните активи: Съдържа детайлна информация за наличностите, движенията и начислените счетоводни и данъчни амортизации на всички ДМА и ДНМА. Този файл е обвързан с годишното приключване и сроковете за подаване на ГФО и ГДД по чл. 92 от ЗКПО – подава се до 30 юни на следващата година.
3. Файл за материалните запаси (при поискване): Този специфичен файл не се подава периодично, а се активира само при изрично поискване от орган по приходите, най-често в хода на ревизия или тематична проверка. При поискване, предприятието има само 14-дневен срок да генерира и предаде пълната хронология на складовите си движения и наличности.

Технически параметри и структура на SAF-T файла

За да се разбере предизвикателството пред съвременния бизнес софтуер, е необходимо детайлно разглеждане на техническата архитектура на отчета. Стандартният одитен файл за данъчни цели не е електронна таблица; той е строго йерархичен XML (Extensible Markup Language) документ, който трябва да отговаря на специфична XSD (XML Schema Definition) структура, утвърдена от НАП (версия 1.0.2).

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

Секция „Header“ (Паспорт на файла)

Тази заглавна част съдържа идентификационните данни на дружеството (ЕИК, ДДС номер, IBAN, адрес) и параметрите на самия файл. Изключително важен нов момент е задължението за техническа прозрачност – предприятието трябва да декларира в XML файла точното име на софтуерната компания, наименованието на продукта и версията на софтуера, с който е генериран отчетът. Това позволява на НАП алгоритмично да картографира кои софтуерни системи на пазара генерират най-много грешки и потенциално да насочи данъчен контрол към техни ползватели.

Секция „MasterFiles“ (Основни данни и номенклатури)

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

• Сметкоплан (GeneralLedgerAccounts): Пълен списък на използваните от компанията счетоводни сметки, включващ начални салда, дебитни и кредитни обороти за месеца и крайно салдо.
• Клиенти и Доставчици (Customers & Suppliers): Списък на всички контрагенти с пълни адресни данни. Техническият опит показва, че липсата на точен ISO код на държавата или пощенски код в тази секция е най-честата причина за отхвърляне на файла при валидация.
• Продукти (Products): Детайлна номенклатура на стоките и услугите, търгувани през периода.

Секция „GeneralLedgerEntries“ (Главна книга)

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

Секция „SourceDocuments“ (Изходни документи)

Най-обемната и сложна част от файла, съдържаща фактурите за продажби и покупки, както и регистрираните плащания. Изискванията тук налагат пълна промяна в счетоводната парадигма: отчитането става на ниво „ред от фактура“ (InvoiceLine), а не чрез обобщени суми. За всяка закупена стока или услуга, софтуерът трябва автоматично да генерира и експортира над 300 задължителни XML атрибута, които изграждат профила на трансакцията.

Идентифициране на пропуските в текущия софтуер (Gap Analysis)

Подготовката за новите изисквания в търговското законодателство започва с безкомпромисен анализ на несъответствията (Gap Analysis) между това, което съществуващият софтуер може да генерира, и това, което НАП изисква. Експертите на Balance.bg подчертават, че най-големият риск се крие в дългогодишните навици за агрегирано осчетоводяване.

В практиката на много малки и средни предприятия фактурите за общи разходи (например комунални услуги, канцеларски материали, резервни части) се осчетоводяват с една обща сума към съответната разходна сметка. Тази практика е напълно несъвместима със SAF-T. Стандартът изисква всяка отделна позиция от първичния документ да бъде възпроизведена в XML файла с всички нейни прилежащи атрибути.

Методологията за оценка на софтуерните пропуски трябва да изследва следните критични точки:

• Гранулярност на данните: Може ли софтуерът да съхранява и експортира данни за всяка фактура ред по ред, включително описание на продукта, количество, единична цена и данъчна основа?.
• Липсващи метаданни: Поддържа ли системата специфични полета, които досега не са били задължителни? Например, софтуерът трябва да може да подава датата на данъчното събитие (TaxPointDate), точен индикатор дали даден ред е за стока или услуга (GoodsServicesID), както и индикатори за самофактуриране (SelfBillingIndicator).
• Кръстосана консистентност (Cross-reference consistency): Ако една система фактурира, а друга осчетоводява, съществува ли безупречна проследимост между фактурата, счетоводното записване в Главната книга и последващото плащане?. Разминаването дори с един цент между документа и записването ще генерира грешка в алгоритмите на приходната агенция.

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

Предизвикателства при мапирането на данни (Data Mapping)

Едно от най-тежките технологични и счетоводни изпитания при въвеждането на стандарта е процесът на „мапиране“ (Data Mapping). Администрацията не налага на бизнеса да променя вътрешните си сметки и кодове за ежедневна работа, но изисква при експортирането на файла всяка вътрешна номенклатура да бъде безупречно преведена към официалните стандарти на НАП.

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

Елемент в SAF-T	Номенклатура на НАП	Специфика и предизвикателства при мапиране
Счетоводна сметка (AccountID)	NRA_Nom_Accounts	Всяка вътрешна аналитична и синтетична сметка трябва да бъде свързана с код от националния стандартен сметкоплан. Грешно мапиране (например отчитане на финансов разход като оперативен) изкривява целия финансов профил на компанията пред НАП.
Мерна единица (InvoiceUOM)	Unit of Measure	За всеки фактуриран ред трябва да се посочи мерна единица по официалния ISO стандарт. Вътрешни кодове като „кашон“, „бр.“ или „палет“ трябва да се преведат към точните международни еквиваленти.
Данъчен код и тип (TaxCode / TaxType)	TAX-IMP / VAT_TaxType	Точно определяне на естеството на начисления данък. Особено критично при сделки с нулева ставка, вътрешнообщностни придобивания (ВОП) и освободени доставки, където се изисква и посочване на причина за необлагане (TaxExemptionReason).
Индикатор Стока/Услуга (GoodsServicesID)	Nom_GoodsServicesID	Задължително класифициране на всеки ред от фактурата с код „G“ (Goods/Стока) или „S“ (Services/Услуга). При услугите се изисква и генериране на специфичен общ продуктов код „00000000“.

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

Архитектура на решението и системна интеграция

Изправени пред резултатите от Gap анализа и сложността на мапирането, ИТ и финансовите директори трябва да вземат стратегическо решение за архитектурата на своя бъдещ SAF-T ERP софтуер. На пазара се оформят два основни подхода за решаване на проблема: директен ъпгрейд на съществуващата система или внедряване на външен междинен софтуер (middleware).

Директен ъпгрейд (Native ERP Integration)

Този подход предполага, че разработчикът на настоящата ERP или счетоводна система (напр. SAP, Microsoft Dynamics, местни доставчици) разработва специализиран модул, който генерира XML файла директно от ядрото на софтуера.

• Предимства: Данните се извличат от „един източник на истината“. Когато производството, складът и счетоводството са в обща база, рискът от вътрешни разминавания клони към нула. Системата позволява автоматично засичане на несъответствия на ниво въвеждане на първичния документ.
• Недостатъци: Изисква значителни капиталови инвестиции за обновяване на лицензи и скъпа консултантска помощ за реконфигуриране на процесите. Често старите, къстъмизирани системи (legacy systems) не могат да бъдат надградени да поддържат новия XML формат.

Междинен софтуер за трансформиране на данни (SAF-T Middleware / Bridge)

За компании с фрагментирана ИТ инфраструктура или софтуери без осигурена поддръжка, оптималното решение е внедряването на външен агрегиращ софтуер. Този тип архитектура действа като мост: тя импортира сурови данни от различни системи (чрез Excel, CSV или API интеграция), съхранява таблиците за мапиране и генерира финалния, валиден XSD файл.

• Предимства: Гъвкавост и бързо внедряване без нужда от смяна на основния ERP софтуер. Качествените middleware решения разполагат с вградени валидатори, които откриват непълни записи (например липсващ адрес на клиент) още преди експортната сесия към НАП. Освен това те поддържат архив и история на подаванията, което е безценно при нужда от корекции.
• Недостатъци: Създава се допълнително звено за управление на данни, което изисква строги протоколи за информационна сигурност и поддръжка на интерфейсите за пренос.

Процедури по тестване и валидация: Симулирани данъчни одити

Техническата изправност на генерирания файл е абсолютно задължително условие преди подаването му към портала на НАП. Файлът не се приема от системата, ако не отговаря на утвърдения XSD файлов формат или ако не е подписан с Квалифициран електронен подпис (КЕП). Затова тестването чрез специализирани инструменти за симулирани данъчни одити се превръща в ключов етап от месечното приключване.

Валидацията на данните протича на две нива, всяко от които улавя различен тип софтуерни и човешки грешки:

1. Синтактична и структурна валидация (XSD Validation): Проверява дали файлът технически отговаря на схемата. Типичен пример за грешка на това ниво е неправилният формат на датите. Софтуерът на НАП изисква стандарт „YYYY-MM-DD“. Ако системата на предприятието експортира датата в традиционния формат „15.07.2026“, XSD валидаторът ще върне фатална грешка от типа: ERROR: Element 'InvoiceDate' ... is not a valid value и файлът ще бъде отхвърлен изцяло. Подобни грешки възникват при неправилно форматирани числови стойности или използване на забранени символи.
2. Логическа и бизнес валидация: Това е по-дълбокият слой на контрол, който симулира същинската данъчна проверка. Инструментът за тестване засича дали сумата от всички редове на една фактура (InvoiceLineAmount) плюс изчисления данък (TaxAmount) съответства точно на общата брутна стойност, посочена в заглавната част на документа. Проверява се и дали всяко плащане, отразено в секция Payments, има точен еквивалент в счетоводните записвания на Главната книга.

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

Санкции при неспазване (Глоби и имуществени санкции)

Българското законодателство подхожда изключително строго към неспазването на новите изисквания за електронна отчетност. Приетите промени в чл. 277а от ДОПК дефинират тежки финансови наказания за субектите, които не подадат навреме своя стандартен одитен файл, или чийто софтуер системно генерира невалидни, отхвърлени от НАП файлове.

Неподаването на валиден файл в регламентираните срокове (или при поискване) води до автоматични административни санкции, чиито размери, конвертирани в евро, са следните:

Субект на нарушението	Наказание при първоначално нарушение	Наказание при повторно нарушение
Юридически лица и еднолични търговци (ЮЛ и ЕТ)	Имуществена санкция от 2,556.46 до 7,669.38 евро[cite: 29]	Имуществена санкция от 5,112.92 до 15,338.76 евро[cite: 29]
Физически лица	Глоба от 255.65 до 1,022.58 евро[cite: 29]	Глоба от 511.29 до 2,045.17 евро[cite: 29]

Важно уточнение: Налагането на глобата не освобождава бизнеса от отговорност. Според чл. 277а, ал. 3 от ДОПК, задълженото лице отново трябва да предостави файла след санкцията. Освен това, тези санкции се прилагат самостоятелно. Ако софтуерът на фирмата пропусне да подаде месечния файл в срок (до 14-то число), се налага една глоба; ако в хода на ревизия фирмата не успее да генерира в 14-дневен срок и файла за материалните запаси, се налага втора, отделна глоба в посочените размери. Допълнително се предвиждат санкции и лихви за всички установени чрез автоматизирания анализ укрити данъци или неправилно отчетени задължения.

Често задавани въпроси (FAQ)

1. Ако нашият ERP софтуер не поддържа SAF-T експорт, задължени ли сме да закупим нова система?

Не е задължително да подменяте целия си съществуващ софтуер, но е абсолютно задължително да намерите техническо решение за генериране на валиден XML файл. Оптималната алтернатива на скъпата миграция е внедряването на междинен агрегиращ софтуер (middleware/bridge), който извлича данните от текущата ви система (напр. чрез експорт в Excel/CSV), извършва мапирането към номенклатурите на НАП и генерира стандартизирания отчет. Условието обаче е текущата ви система да разполага с достатъчно детайлна първична информация.

2. Какво се случва, ако подадем файла на 14-то число, но сървърите на НАП го отхвърлят поради техническа грешка?

Отговорността за валидността на данните се носи изцяло от предприятието. При техническо отхвърляне (например грешна XSD схема или непълен адрес на клиент), файлът се третира като неподаден. Според утвърдените правила, НАП връща съобщение за грешка и предоставя кратък 7-дневен срок за отстраняване на несъответствията чрез подаване на нов, коректен файл за същия период. Ако този срок бъде пропуснат, автоматично се задействат процедурите по налагане на санкции.

3. Има ли предвиден гратисен период, в който да не бъдем глобявани за грешки?

Да. Законодателят е предвидил механизъм (чл. 71к, ал. 5 от ДОПК), според който за първите шест месеца от възникването на задължението (според това в коя група попадате), предприятията могат да правят корекции на подадените данни без да бъдат санкционирани. Срокът за корекции се счита за спазен, ако финалният валиден файл е подаден до изтичането на срока за подаване на отчета за седмия месец. Това обаче не е извинение за неподаване, а време за настройка на системите.

4. Трябва ли да променяме вътрешния си сметкоплан заради изискванията на НАП?

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

Системата за ранно предупреждение работи

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

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

Законодателството в България се променя постоянно. Застраховайте бизнеса си от глоби, като поверите счетоводството си на професионалистите от Balance.bg в София.