SAF-T в България: Тиха катастрофа за складовите и счетоводните системи

SAF-T в България: Тиха катастрофа за складовите и счетоводните системи

Комбинирана номенклатура КН8-2025 2026 за кодове на продукти (материални запаси);

Защо новите изисквания на НАП поставят огромна част от бизнеса пред технологична „стена“

Въвеждането на SAF-T (Standard Audit File for Tax purposes) в България уж трябва да модернизира обмена на данни с НАП. Но в детайлите се крие проблем, който тепърва ще удари най-силно фирмите, работещи със складови програми и счетоводни системи:

изискването за работа с официални номенклатури, KN-кодове и стандартизирани мерни единици.

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

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

Проблем №1: Номенклатурата на продуктите (КН8-2025)

Задължените лица трябва да използват Комбинираната номенклатура (КН) за всички материални запаси.

Това означава:

всеки артикул -> трябва да има КН код

движенията по склад -> отчитане според номенклатурата

XML файлът -> приема само цифровите кодове, не наименования

За фирми с 200, 2000 или 20 000 артикула това е буквално процес на ръчно или автоматизирано мапване, което много системи дори не могат да поддържат.

Интрастат работи със същите кодове, но там фирмите докладват само ограничени групи артикули.

SAF-T обхваща всичко.


🔍 Проблем №2: Мерните единици

НАП въвежда задължителна стандартизирана номенклатура на мерните единици.

Истинският проблем?


90% от складовите програми в България нямат поддръжка за конвертиране между мерни единици.

У нас реално се продават стоки като:

кашон

стек

пакет

ролка

кофа

комплект

брой

литър

палет

килограм

Докато SAF-T приема само основни международни единици:

KG, L, M, M2, M3, PCE и др.


Ако една фирма продава:


1 кашон = 10 пакета

1 пакет = 12 бр.

ERP трябва да генерира движение в основната единица (например брой) и да го преобразува в стандартизираната ISO-единица, ако се изисква такава за конкретния KN-код.


Повечето системи не могат да направят това автоматично.


🔍 Проблем №3: Множество номенклатури в един файл

SAF-T изисква още:


номенклатура на валути (ISO 4217)

номенклатура на държави (ISO 3166-1)

номенклатура на области (ISO 3166-2)

номенклатура на данъчни режими

номенклатура на типове документи

номенклатура за движение на материални запаси

номенклатура за движение на активи

номенклатура на счетоводните сметки

Една нормална българска складова програма изобщо няма концепция за повечето от тези елементи. Системата трябва да:


поддържа официални кодове

позволява автоматично им мапване

позволява валидиране и преобразуване

изнася валиден XML по схемата на НАП

На практика това е цялостно пренаписване на продукта.


🔍 Проблем №4: Системите, които могат това, са малко

В момента реално поддържат многомерни единици, конверсии и сложни номенклатури:


SAP

Microsoft Dynamics 365 / NAV

ERP.NET

SoftOne

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


Microinvest

Mistral

Eltrade

Datecs POS / Daisy POS и др.

малки ERP-та

custom складови програми

нямат реална архитектура, която да може да покрие изискванията на НАП в този им вид.


❗ Реален риск: масово софтуерно „отсичане“ на функционалност

Много системи ще трябва да:


пренапишат модулите за артикули

добавят поддръжка на KN-кодове

добавят конверсионни таблици за мерни единици

променят целия модел на складовите движения

поддържат XML схеми

валидират данни по номенклатури

съхраняват пълна история на движенията

Това е гигантски проект, непосилен за част от по-малките разработчици.


🧨 Заключение:

SAF-T в сегашния си вид е технологичен шок за българския бизнес.

Най-големият проблем не е подаването на XML файл.

Проблемът е подготовката на данните:

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

преобразуване на мерни единици

уеднаквяване на номенклатури

промени в архитектурата на софтуера

Много фирми тепърва ще осъзнаят, че:


подаването на SAF-T не е задача от 5 минути — то изисква ниво на автоматизация, което повечето складови и счетоводни системи в България просто нямат.


Възможни решения има – но няма да бъдат лесни, евтини или бързи.


Или защо вашата складова програма вероятно не може да се справи с новите изисквания на НАП

Когато чета официалните документи за SAF-T, винаги търся реда, написан с по-малък шрифт. Този път го намерих на страница 7 на Приложение 3 към заповедта на НАП.


Проблемът, който ще удари всички

Всички говорят за SAF-T. Консултантите обещават „гладка дигитална трансформация“. Софтуерните компании уверяват, че „вече са готови“.

Но има един технически детайл, който ще се превърне в кошмар за 90% от българските фирми:

Комбинираната номенклатура (КН8-2025) има собствена система за мерни единици. И тя НЕ съвпада с вашата.

Какво казва НАП (с малкия шрифт)

От Приложение 3, стр. 3:

„Стоките и услугите задължително се обвързват със съответстващия код от номенклатура NC8_TARIC“

И на стр. 7:


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


Звучи невинно, нали?


Нека ви покажа какво означава това в практиката.


Пример 1: Простата фирма за хранителни стоки

Вашата система:


1 кашон сирене = 10 пакета

1 пакет = 400 грама

Продавате на: кашони, пакети, килограми

Комбинираната номенклатура КН8:


Код 0406 10 20 (Прясно сирене, с масло съдържание ≤ 40%)

Допустима мерна единица: kg (килограм)

Вашият проблем:


SAF-T иска само kg

Вашата складова програма работи с „кашони“ и „пакети“

Трябва автоматична конверсия: кашон → пакет → грам → kg

При всяко складово движение

За всеки един артикул

В реално време

И ако направите грешка в конверсията?


Несъответствие между складово количество и данъчен файл

Санкции от НАП

Невъзможност за подаване на валиден SAF-T

Пример 2: Строителна фирма

Реален казус:


Вие продавате строителни материали.


Вашият артикул Как го продавате КН8 код Мерна единица по КН8

Тухли палети (1 палет = 500 бр) 6904 10 00 1000 бр (хиляди броя)

Циментови плочи кв.м. 6810 19 kg (килограм)

Изолация ролки (1 ролка = 15 м²) 6807 10 m² (квадратен метър)

Проблемът:


Ролка изолация ≠ m² (трябва разчет: 1 ролка = 15 m²)

Палет тухли ≠ 1000 бр. (трябва: 500 бр. = 0.5 по КН8)

Циментови плочи в m² → трябва да ги претеглите и подадете в kg

Вашата складова програма може ли:


Да съхранява конверсионни коефициенти за всеки КН8 код?

Да преобразува автоматично при експорт към SAF-T?

Да валидира дали сте използвали правилната мерна единица за всеки КН8?

Спойлер: повечето не могат.

Техническата реалност

Какво трябва да направи софтуерът (според НАП):

ВАШ АРТИКУЛ:

└─ Име: "Сирене БДС 1000 г."

└─ Вашият код: ART-12345

└─ Мерна единица: пакет

└─ Количество на склад: 150 пакета


↓ ТРАНСФОРМАЦИЯ ЗА SAF-T ↓


SAF-T PRODUCT:

└─ ProductCode: ART-12345

└─ CommodityCode: 0406 10 20 ← КН8 код (ЗАДЪЛЖИТЕЛНО)

└─ UOM: kg ← ISO мерна единица (ЗАДЪЛЖИТЕЛНО)

└─ Quantity: 60.00 kg ← Конвертирано (150 пакета × 0.4 кг)

Проблеми в реалността:

Проблем 1: Множество търговски единици


Фирма продава битово масло:


На едро: кашони (1 кашон = 6 бутилки)

На дребно: бутилки (1 л)

За угоща: чаши (200 ml)

Но КН8 познава само: l (литри)


Проблем 2: Нестандартни опаковки


Фирма внася дрехи:


Поръчки в: комплекти (1 комплект = 1 блуза + 1 панталон)

КН8 изисква: бр. (брой) за всяка стока поотделно

Проблем 3: Динамични опаковки


Земеделска фирма продава картофи:


Чували с различно тегло: 25 kg, 50 kg, Big Bag 1000 kg

КН8 иска: kg

Но системата пази: брой чували

Какво НЕ може да направите (законно)

❌ Да подавате „пакет“ като мерна единица (не е в ISO номенклатурата)


❌ Да създадете собствен код „0“ за стоки без КН8 (освен за услуги)


❌ Да подавате обобщени данни „Строителни материали – 5000 kg“


❌ Да мапвате всичко към „брой“ (PCE) – не е валидно за всеки КН8


Кой може да се справи? (Списъкът е кратък)

ERP системи с реална поддръжка:


SAP ✅

Microsoft Dynamics 365 / NAV ✅

ERP.NET ✅

SoftOne ✅ (частично)

Популярни складови програми:


Microinvest ❓ (няма официална информация за пълна поддръжка)

Mistral ❓ (предстои разработка)

Eltrade ❓ (в процес)

Datecs / Daisy POS ❌ (не са проектирани за SAF-T)

Custom решения ❌ (изискват пренаписване отново)

Реалното решение (което никой не иска да чуе)

Вариант 1: Пълна миграция на ERP

Необходими стъпки:


Мапване на всички артикули → КН8 кодове (20-200 часа работа)

Дефиниране на конверсионни таблици (10-50 часа)

Тестване на експорт SAF-T (20+ часа)

Обучение на персонал (координация и време)

Цена:


Малка фирма (до 500 артикула): 5,000-15,000 лв

Средна фирма (500-5000 артикула): 15,000-50,000 лв

Голяма фирма (5000+ артикула): 50,000-200,000 лв

Срок: 3-12 месеца


Вариант 2: Междинен софтуер (middleware)

Ако вашата система не може да се промени:


СКЛАДОВА ПРОГРАМА

ЕКСПОРТ

MIDDLEWARE СОФТУЕР ← Тук става магията:

- Мапване КН8 - Конверсия единици

- Валидация - Генериране XML

SAF-T файл

НАП

Предимства:


Не променяте текущата система

По-евтино от миграция

Недостатъци:


Ръчна синхронизация

Допълнителен софтуер = допълнителни грешки

Не решава основния проблем

Вариант 3: Частично решение за малки фирми

Ако имате под 100 уникални артикула:


Ръчна подготовка на таблица:

[Вашият код] | [Име] | [КН8] | [Вашата единица] | [ISO единица] | [Коефициент]

Excel конвертор за всеки месец:

Експорт от складова → Excel

Формули за конверсия

Импорт в SAF-T генератор

Реално време на месец: 4-8 часа


Цена: Време на счетоводител

Риск: Висок (ръчна работа = грешки)

Конкретен чеклист: Готов ли е вашият софтуер?

Проверете СЕГА:


[ ] Системата може да съхранява КН8 код за всеки артикул?

[ ] Поддържа таблица с конверсионни коефициенти?

[ ] Може да експортва количества в различни мерни единици?

[ ] Генерира валиден XML по схемата на НАП?

[ ] Има вградена номенклатура UOMTable (ISO единици)?

[ ] Може да работи с NC8_TARIC номенклатурата?

[ ] Има функция за валидация на SAF-T преди подаване?

Ако имате под 4 отметки → Софтуерът ви НЕ Е ГОТОВ.


Какво да направите ДНЕС

За малки фирми (до 15 млн. лв. оборот):

Свържете се с вашия софтуер – попитайте директно за SAF-T roadmap

Започнете мапване – дори ръчно, в Excel

Имате време до 2028-2029 – използвайте го

За средни и големи (първата вълна 2026-2027):

Спешна оценка на текущата система (ТОЗИ МЕСЕЦ)

Решение: миграция или middleware? (ДО КРАЯ НА 2025)

Пилотно тестване (Q1-Q2 2026)

Реално внедряване (Q3-Q4 2026)

За всички:

Попитайте вашия доставчик на софтуер:


„Как вашият продукт обработва конверсия на мерни единици при експорт към SAF-T, съгласно изискванията на Комбинираната номенклатура КН8-2025 и номенклатурата UOMTable?“


Ако отговорът е нещо като:


„Няма проблем, ще се оправим“

„Работим по това“

„Ще видим“

→ Проблемът е ВАШ, не техен.


Заключение: Истината за SAF-T

SAF-T не е просто „нов формат за отчетност“.


SAF-T е фундаментална промяна в начина, по който данните се структурират.


Не става дума за „подаване на файл“. Става дума за:


Преструктуриране на номенклатурата

Преосмисляне на складовата логистика

Изграждане на система за реално време трансформация на данни

Истинската цена на SAF-T не е във файла.


Истинската цена е в подготовката на данните.


И колкото по-късно започнете, толкова по-скъпо ще струва.


Ресурси

Официални документи:


Заповед З-ЦУ-30-1247/25.08.2025 на НАП

Приложение 3: Формат и ред за подаване на SAF-T

Полезни инструменти:


Комбинирана номенклатура КН8-2025 (официален документ)

ISO 31/0 – Стандарт за мерни единици

Номенклатура UOMTable от НАП

Още въпроси?

Пишете в коментарите – ще отговарям конкретно по вашия случай.


Статията е написана на базата на официално публикуваното Приложение 3 към Заповед З-ЦУ-30-1247/25.08.2025 г. на НАП. Всички примери са илюстративни, но базирани на реални технически изисквания.

← Назад към всички статии