Или защо „имаме меню SAF-T“ не означава, че имаш SAF-T
Какво е SAF-T и защо не е просто „още един XML“
SAF-T (Standard Audit File for Tax) не е поредната справка. Не е ДДС дневник. Не е оборотна ведомост в друг формат.
SAF-T е пълен рентген на счетоводството – всяка сметка, всяко движение, всеки контрагент, всяка стока, всеки актив, всяко плащане – структурирани по международен стандарт, валидирани срещу XSD схема, готови за машинно четене от данъчната администрация.
Когато НАП поиска SAF-T файл, те не искат красив PDF. Те искат суровите данни. И тези данни трябва да бъдат правилни, пълни и вътрешно съгласувани.
Двойният сметкоплан: Там където започва истинската работа
Всеки счетоводител в България работи със собствен сметкоплан. Сметка 302 при един е „Материали“, при друг е „Суровини за производство“, при трети има 15 аналитични подсметки. SAF-T изисква всяка фирмена сметка да бъде свързана с официалния сметкоплан на НАП.
В Baraba заредихме целия стандартен сметкоплан на НАП – 360+ сметки, организирани в секции и групи:
Секция 1: Сметки за капитали
├── Група 10: Основен капитал
│ ├── 101 Основен капитал - непоискан
│ └── 102 Основен капитал - поискан
├── Група 11: Капиталови резерви
│ ├── 111 Общи резерви
│ └── 112 Резерви от преоценка
└── ...
Секция 3: Сметки за стоково-материални запаси
├── Група 30: Материали, продукция, стоки
│ ├── 301 Доставки
│ ├── 302 Материали
│ ├── 303 Продукция
│ └── 304 Стоки
└── ...
Секция 5: Сметки за парични средства
├── Група 50: Парични средства
│ ├── 501 Каса
│ ├── 503 Разплащателни сметки
│ └── 509 Други парични средства
└── ...
Всяка фирмена сметка се свързва с една SAF-T сметка. Но това не е просто dropdown „избери сметка“. Това е архитектурно решение – системата трябва да знае тази връзка, за да може после автоматично да класифицира всяко движение в правилната SAF-T категория.
Движенията: Там където повечето спират
Ето къде е истинският двигател. SAF-T не иска просто „имаш Дт 302 / Кт 401 за 1000 лв“. SAF-T иска да знае, че това е движение на материални запаси тип „Покупка“ (код 10).
И тук повечето софтуерни продукти замръзват.
Три паралелни системи за класификация на движенията
В Baraba изградихме три независими mapping системи, всяка с десетки правила:
1. Материални запаси – 19 типа движения, 24+ правила
Код │ Тип движение │ Дт │ Кт │ Описание
────┼─────────────────────────────────┼──────┼──────┼──────────────────────────
10 │ Покупка │ 302 │ 401 │ Материали от доставчици
10 │ Покупка │ 303 │ 401 │ Продукция от доставчици
10 │ Покупка │ 304 │ 401 │ Стоки от доставчици
20 │ Запаси от производство │ 303 │ 611 │ Продукция от производство
20 │ Запаси от производство │ 302 │ 611 │ Материали от производство
30 │ Продажба │ 701 │ 304 │ Продажба на стоки
30 │ Продажба │ 701 │ 303 │ Продажба на продукция
40 │ Връщане от клиент │ 304 │ 701 │ Върнати стоки
40 │ Връщане от клиент │ 303 │ 701 │ Върната продукция
50 │ Връщане към доставчик │ 401 │ 302 │ Върнати материали
50 │ Връщане към доставчик │ 401 │ 304 │ Върнати стоки
70 │ Запаси за производство │ 601 │ 302 │ Разход на материали
70 │ Запаси за производство │ 611 │ 302 │ Вложени в производство
80 │ Вътрешен трансфер │ 302 │ 302 │ Между складове
110 │ Положителна инвентаризация │ 302 │ 709 │ Излишък материали
110 │ Положителна инвентаризация │ 304 │ 709 │ Излишък стоки
120 │ Отрицателна инвентаризация │ 609 │ 302 │ Липса материали
120 │ Отрицателна инвентаризация │ 609 │ 304 │ Липса стоки
160 │ Брак │ 609 │ 302 │ Бракувани материали
160 │ Брак │ 609 │ 304 │ Бракувани стоки
Забележете: покупката на стоки и покупката на материали са различни кореспонденции, но един и същи тип движение (код 10). Системата трябва да разбере, че Дт 302 / Кт 401 и Дт 304 / Кт 401 са едно и също нещо за SAF-T – покупка.
2. Парични средства – 16 типа движения, 25+ правила
Код │ Тип движение │ Дт │ Кт │ Описание
────┼─────────────────────────────────┼──────┼──────┼──────────────────────────
10 │ Каса приход │ 501 │ 411 │ Каса от клиенти
10 │ Каса приход │ 501 │ 709 │ Каса други приходи
10 │ Каса приход │ 501 │ 721 │ Каса лихви
11 │ Каса разход │ 401 │ 501 │ Каса към доставчици
11 │ Каса разход │ 602 │ 501 │ Каса външни услуги
11 │ Каса разход │ 604 │ 501 │ Каса заплати
11 │ Каса разход │ 609 │ 501 │ Каса други разходи
42 │ Банка приход │ 503 │ 411 │ Банка от клиенти
42 │ Банка приход │ 503 │ 709 │ Банка други приходи
42 │ Банка приход │ 503 │ 721 │ Банка лихви
42 │ Банка приход │ 503 │ 752 │ Банка фин. приходи
43 │ Банка разход │ 401 │ 503 │ Банка към доставчици
43 │ Банка разход │ 602 │ 503 │ Банка външни услуги
43 │ Банка разход │ 604 │ 503 │ Банка заплати
43 │ Банка разход │ 621 │ 503 │ Банка лихви по кредити
43 │ Банка разход │ 629 │ 503 │ Банка такси
48 │ Карта приход │ 503 │ 411 │ Карта от клиенти
49 │ Карта разход │ 401 │ 503 │ Карта към доставчици
80 │ Вътрешен трансфер │ 503 │ 501 │ Внасяне каса в банка
80 │ Вътрешен трансфер │ 501 │ 503 │ Теглене от банка в каса
80 │ Вътрешен трансфер │ 503 │ 503 │ Между банкови сметки
90 │ Валутна разлика + │ 503 │ 724 │ Положителна курсова разлика
91 │ Валутна разлика - │ 624 │ 503 │ Отрицателна курсова разлика
97 │ Прихващане │ 401 │ 411 │ Прихващане доставчик-клиент
99 │ Подотчетни лица │ 422 │ 501 │ Служебен аванс
99 │ Подотчетни лица │ 501 │ 422 │ Отчитане на аванс
3. Дълготрайни активи – 13 типа движения, 20+ правила
Придобиване, продажба, амортизация, вътрешен трансфер, брак, преоценка (положителна и отрицателна), излишък, липса, обезценка, сторно на обезценка, безвъзмездно предоставяне…
Pattern matching с wildcards
И тук е ключът. Различните фирми имат различни аналитични сметки. Една фирма има сметка 302, друга има 3021, 3022, 3023. Трета има 302100, 302200.
Затова mapping системата поддържа wildcards:
302* → Всички сметки, започващи с 302
30* → Всички сметки от група 30
401 → Точно сметка 401
Плюс опционален аналитичен филтър – можеш да кажеш „Дт 302, но само аналитична 3021 = Строителни материали“.
Всяко правило в mapping таблицата е per-company. Зареждаш стандартните и ги настройваш. Или пишеш от нулата. Или комбинираш.
Номенклатурите: 15 справочни таблици
SAF-T не е само сметки и движения. Зад всеки елемент стои номенклатура:
| Номенклатура | Бр. записи | Стандарт |
|---|---|---|
| Сметкоплан НАП | 360+ | Национален |
| Данъчни видове | 21 | SAF-T BG |
| Данъчни кодове (ДДС, КД, акцизи) | 30+ | SAF-T BG |
| Типове фактури | 19 | SAF-T BG |
| Методи на плащане | 9 | SAF-T BG |
| Типове продукти | 5 | SAF-T BG |
| Типове стокови движения | 19 | SAF-T BG |
| Типове движения на активи | 13 | SAF-T BG |
| Типове парични движения | 16 | SAF-T BG |
| Данъчни режими | 3 | SAF-T BG |
| Мерни единици | 60+ | UN/ECE Rec. 20 |
| Региони на България | 28 | ISO 3166-2:BG |
| IBAN формати | 60+ | ISO 13616 |
| Mapping стокови движения | 24+ per company | Вътрешен |
| Mapping парични движения | 25+ per company | Вътрешен |
| Mapping движения на активи | 20+ per company | Вътрешен |
Всяка номенклатура е предварително заредена с данните от стандарта. Не „ще се зареди“, не „очакваме обновление“. Заредена, с код, име на български и английски, готова за mapping.
Три типа отчети, три различни XML-а
SAF-T BG дефинира три типа отчети:
1. Месечен (Monthly)
- Главна книга: всички записи за периода
- Първични документи: фактури, плащания, стокови движения
2. При поискване (OnDemand)
- Физически наличности: инвентаризация на материалните запаси
3. Годишен (Annual)
- Транзакции с дълготрайни активи: придобивания, амортизации, продажби
Всеки тип генерира различен XML с различна структура. Не е copy-paste с различна дата. Различни секции, различни данни, различна валидация.
XML-ът: 924 реда генератор
SaftExporter-ът в Baraba е 924 реда Crystal код, който генерира валиден XML по схемата BG_SAFT_Schema_V_1.0.1.xsd:
<AuditFile xmlns="urn:StandardAuditFile-Taxation-Financial:BG">
<Header>
<!-- Фирма, ЕИК, ДДС номер, адрес, банкови сметки -->
<!-- Структура на собственост (бенефициери, крайни собственици) -->
</Header>
<MasterFiles>
<GeneralLedgerAccounts>...</GeneralLedgerAccounts> <!-- Сметкоплан + салда -->
<Customers>...</Customers> <!-- Клиенти + ДДС рег. -->
<Suppliers>...</Suppliers> <!-- Доставчици + ДДС рег. -->
<TaxTable>...</TaxTable> <!-- ДДС ставки -->
<UOMTable>...</UOMTable> <!-- Мерни единици -->
<Products>...</Products> <!-- Стоки/услуги -->
<PhysicalStock>...</PhysicalStock> <!-- Наличности (OnDemand) -->
<Assets>...</Assets> <!-- ДМА (Annual) -->
</MasterFiles>
<GeneralLedgerEntries>
<NumberOfEntries>1847</NumberOfEntries>
<TotalDebit>2847291.50</TotalDebit>
<TotalCredit>2847291.50</TotalCredit>
<Journal>...</Journal> <!-- Записи с данъчна инфо -->
</GeneralLedgerEntries>
<SourceDocuments>
<SalesInvoices>...</SalesInvoices> <!-- Фактури продажби -->
<PurchaseInvoices>...</PurchaseInvoices> <!-- Фактури покупки -->
<Payments>...</Payments> <!-- Плащания -->
<MovementOfGoods>...</MovementOfGoods> <!-- Стокови движения -->
<AssetTransactions>...</AssetTransactions> <!-- Движения на активи -->
</SourceDocuments>
</AuditFile>
Преди генерирането се прави валидация: пълни ли са данните на фирмата, имат ли всички контрагенти SAF-T идентификатори, съвпадат ли дебитите с кредитите, има ли mapping за всички кореспонденции. Грешките и предупрежденията се показват преди да бъде генериран файлът.
Настройките: Достъпни за счетоводителя
В Baraba страницата за SAF-T mapping-и е достъпна за счетоводителя. С три таба:
- Материални запаси – mapping на стокови движения
- Дълготрайни активи – mapping на движения с ДМА
- Парични средства – mapping на каса, банка, карти
Бутон „Зареди стандартни“ създава 70+ правила с едно натискане. После се коригират, добавят нови, деактивират ненужни.
Това е conscious design decision. Счетоводителят разбира кой тип движение е Дт 302 / Кт 401. Не му трябва консултант за да настрои SAF-T mapping-ите. Отваря таблицата, вижда правилата, коригира ако трябва.
Слонът в стаята: Пазарът на SAF-T в България
SAF-T стартира в България от 2026 г. за първите 460 фирми – най-големите по оборот. Тези фирми не ползват Microinvest. Не ползват Plus Minus. Те ползват SAP, Oracle, Microsoft Dynamics, Epicor – ERP системи, които струват колкото апартамент в София.
И тук идва неудобната истина.
Кой твърди, че е „готов“?
Огледайте се из българския софтуерен пазар. Всеки втори счетоводен продукт обявява „SAF-T ready“ на сайта си. Но:
- Нито един от масовите продукти няма клиент от тези 460 фирми. Първите 460 са твърде големи. Ползват ERP-та на световните лидери, с екипи от 20 консултанти за внедряване.
- „Готов“ при повечето означава менюто съществува. Буквално. Има бутон „SAF-T“, при натискане пише „В процес на разработка“ или генерира полупразен XML, който не минава валидация.
- Двойният сметкоплан липсва. Нямат mapping между фирмения и стандартния сметкоплан на НАП. Нямат номенклатурите. Нямат движенията. Нямат pattern matching.
- Нямат двигател. Имат волан и табло, но под капака е празно.
Бизнес моделът „вечен консултант“
Някои доставчици правят SAF-T настройките умишлено недостъпни за крайния потребител. Менюто е заключено. Mapping-ите са скрити. Номенклатурите се пълнят „от партньор“.
Преведено: плащай ни всеки месец да ти настройваме нещо, което можеш да настроиш сам за час.
В Baraba подходът е различен. Всички настройки са видими, редактируеми и разбираеми. Зареждаш стандартните, коригираш за твоя фирма, готово. Не ти трябва консултант. Трябва ти счетоводител, който знае сметкоплана си – а това е всеки счетоводител.
Реалността на „готовността“
Истинската готовност за SAF-T не е бутон в менюто. Това е:
- 15 номенклатурни таблици с реални данни
- 70+ mapping правила за класификация на движенията
- 3 типа отчети с различна структура
- Валидация преди генериране
- XSD-валиден XML на изхода
- Двоен сметкоплан с връзка между фирмения и стандартния
- 20 миграции само за SAF-T структурите в базата данни
Това е работата на месеци. Не се прави за уикенд. Не се лепва отгоре на съществуващ продукт с тиксо.
Заключение
SAF-T е сложен. Наистина сложен. Не защото XML-ът е дълъг, а защото изисква дълбока интеграция с всяка част от счетоводната система – сметкоплан, движения, контрагенти, фактури, плащания, материални запаси, дълготрайни активи.
В Baraba SAF-T не е модул, залепен отстрани. Той е вплетен в самата тъкан на системата. Всяка сметка знае своя SAF-T код. Всяко движение знае своя тип. Всеки контрагент има своя данъчна регистрация.
Двигателят работи. Под капака има мотор, не касетофон.
А останалите? Нека първо покажат XML, който минава валидация. После ще говорим за „готовност“.
Публикувано: Февруари 2026
Автор: Baraba Team