Какво е SAF-T и защо никой не ви казва истината за него

Ако сте счетоводител в България и сте чували за SAF-T, вероятно сте прочели едно от двете: официалната документация на НАП, която предполага, че знаете какво е XML схема, или статия от някой "доставчик на решения", която завършва с покана за демо среща.

Нито едното не ви казва това, което всъщност трябва да знаете.

Тази статия е различна. Написана е от човек, който е прекарал година в изграждане на софтуер директно срещу реалните изисквания на НАП - не документацията, а това, което системата им действително приема. И от човек, чиито родители са счетоводители от над 35 години и са едни от хилядите професионалисти, които трябва да се справят с това изискване без никаква техническа подготовка за него.

Ако след тази статия искате пълната картина - поле по поле, глава по глава - безплатният SAF-T наръчник покрива цялата схема на прост български език.

Добре, какво е SAF-T?

SAF-T означава Standard Audit File for Tax - стандартен одиторски файл за данъчни цели. Разработен е от ОИСР като начин данъчните администрации да получават структурирана финансова информация от фирмите в единен, машинночетим формат.

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

До тук - стандартна информация, която можете да намерите навсякъде. Ето какво не можете:

Какво SAF-T всъщност изисква от вас

SAF-T не е просто „експортирайте счетоводството си в нов формат." Той изисква да произведете един единствен XML файл, който съдържа едновременно:

• Целия ви сметкоплан с точната им структура
• Всички счетоводни записи за периода
• Всички продажби и покупки с детайли до ред на документ
• Движенията на складовите наличности
• Данните за всеки партньор - клиенти и доставчици
• Данъчните кодове, съпоставени с точната номенклатура на НАП

Всичко това в строго дефинирана XML структура, валидирана срещу официална XSD схема, с точни кодове, точни формати на дати, точни числови формати.

Звучи управляемо? Ето където започва реалният проблем.

Разделената реалност на българското счетоводство

Повечето български фирми работят с два отделни типа софтуер: счетоводен и складов. Счетоводната програма - вижте нашето ръководство за генериране от счетоводен софтуер - съдържа сметкоплана и счетоводните записи. Складовата програма съдържа движенията на стоките и наличностите.

Тези две системи никога не е трябвало да комуникират помежду си. Работили са независимо с години. SAF-T изисква данни и от двете - в един файл, кръстосано валидирани, без несъответствия.

Какво означава това на практика? Означава, че счетоводителят трябва ръчно да събере информация от минимум два различни експорта, да я съгласува, да провери дали данните от едната система съответстват на данните от другата, и чак тогава да се опита да произведе SAF-T файл.

За фирма с активна търговска дейност и стотици транзакции на месец - това са дни работа. Не часове. Дни.

Зелената отметка, която не означава нищо

Ето нещо, което никой доставчик на SAF-T решения не ви казва открито:

Има разлика между файл, който е структурно валиден, и файл, който НАП действително ще приеме.

Официалният валидатор на НАП проверява дали файлът ви отговаря на XSD схемата - тоест дали XML структурата е технически коректна. Получавате зелена отметка. Радвате се. Подавате файла.

И системата го отхвърля.

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

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

Проблемът с кодовете

Вашият счетоводен софтуер използва собствени вътрешни кодове за сметки. НАП изисква специфична номенклатура в SAF-T файла. Тези две системи не съответстват автоматично.

Всяка сметка от вашия сметкоплан трябва да бъде съпоставена с правилния SAF-T код. За фирма с пълен сметкоплан - това могат да бъдат стотици съпоставяния. Всяко грешно съпоставяне корумпира съответната секция на файла. А грешките в съпоставянето са тихи - файлът изглежда наред, докато не го подадете.

Колко всъщност отнема?

Базирано на реалния опит с изграждането на Magi и разговорите с счетоводители, ето реалистична оценка за фирма, която прави SAF-T за първи път ръчно:

Защо сега

Може да мислите, че имате достатъчно време. 2026 изглежда далеч.

Не е. Задължението влиза в сила поетапно и подготовката изисква повече от инсталиране на нов софтуер. Изисква да разберете структурата на вашите данни, да съпоставите вашите кодове, да тествате с реални данни и да се уверите, че системата, която използвате, действително произвежда файлове, които НАП приема - не само файлове, които изглеждат валидни.

Фирмите, които започнат рано, ще имат времето да открият и поправят проблемите. Фирмите, които изчакат, ще се опитват да решат 40-часов проблем за един уикенд преди крайния срок за подаване.

Накратко

SAF-T не е административна формалност. Той е технически проект, който изисква:

• Събиране на данни от множество системи, които никога не са комуникирали
• Ръчно съпоставяне на стотици кодове
• Разбиране на разликата между структурна и бизнес логическа валидност
• Часове работа, която няма как да се фактурира

Реалността е, че НАП изисква от счетоводители да свършат работата на инженер по данни. Без обучение за това. С инструменти, никога не създадени за тази цел.