Защо НАП отхвърля валидни SAF‑T файлове

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

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

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

В един реален случай една проверка за консистентност е върнала 649 641 грешки. Големият брой не означава толкова независими проблема: често една грешна настройка или несъгласуван код се повтаря през много редове. Затова първата задача след отказ е да се намери първопричината, а не да се обработват съобщенията едно по едно.

• Непоследователни идентификатори: един контрагент или артикул с различни кодове в различни системи.
• Липсващи задължителни данни: празни полета, които структурата допуска само при определени условия.
• Неправилно картографиране: вътрешен данъчен код или вид документ, свързан с неподходящ SAF‑T код.
• Несъгласувани суми: стойности по документ, данъчна основа, данък и счетоводен запис, които не се събират логично.
• Дублиране или липсващи връзки: документ, който не се проследява до счетоводния запис.
• Исторически данни: стари номенклатури и мигрирани записи, които не спазват текущите правила.
• Разминаване между модули: продажби, склад, активи и главна книга с различни версии на един факт.

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

Изискването е уредено в чл. 277а ДОПК, който предвижда и санкция до 15 000 лв. на файл при неизпълнение. Седемдневният срок променя организацията на подготовката: вътрешният календар трябва да оставя буфер за анализ на причината, корекция, ново генериране и повторно подаване. Добрата практика е предварително определен собственик на инцидента, ескалационен път и регистър на причините.

Режимът е уреден в § 17, ал. 2 от ПЗР на ЗДБРБ за 2025 г. (ДВ, бр. 65/2025). Периодът не отменя задължението за подаване и не е причина за отлагане на тестовете: колкото по-късно се открие системен проблем, толкова повече отчетни периоди са засегнати. Използвайте началния период за изграждане на доказуем контрол, така че след изтичането му процесът да е предвидим.

1. 01

   Контрол на източника: данните от ERP, счетоводния и складовия модул са пълни и приключени за периода.

2. 02

   Контрол на картографирането: връзките между вътрешните кодове и SAF‑T структурата имат версия и собственик.

3. 03

   Контрол на съгласуваността: ключови суми, документи и данъчни данни се сравняват между модулите.

4. 04

   Контрол след обратна връзка: всеки отказ се анализира до първопричина и ражда предотвратяваща проверка.

Тази рамка разграничава единичната грешка от системния дефект. Единичният проблем се коригира в конкретен запис; системният се коригира в правило, номенклатура или процес, за да не се повтори следващия месец.