SAF‑T и НАП: какво проверява администрацията и какво остава за вас

НАП обработва всеки SAF‑T файл на два отделни етапа, а не с една проверка при качване. Първо порталът приема файла, проверява електронния подпис и издава входящ номер. Това е доказателството за спазен срок. След това следва отделна проверка за валидност и консистентност на самото съдържание: дали кодовете отговарят на номенклатурите по Приложение № 2, дали салдата и оборотите се съгласуват и дали задължителните полета са попълнени според правилата. Резултатът от този втори етап определя дали файлът остава приет или се отказва.

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

Втората проверка следва Приложение № 2 и покрива номенклатури, картографиране на сметки и вътрешна консистентност на сумите, а не само синтаксиса на XML файла. AccountID се съпоставя с NRA_Nom_Accounts, данъчната класификация се определя от TAX-IMP и VAT_TaxType, а мерните единици от Unit_of_Measure по точния регистър на буквите. Отделно правило проверява дали посочените салда отговарят на сумата на дебитните и кредитните обороти по съответната сметка.

Тези правила са изброени в SAF‑T номенклатури и кодове по Приложение № 2, а самите съобщения за грешка и логиката зад тях са разгледани в Защо НАП отхвърля валидни SAF‑T файлове. И двете показват едно и също: съдържателната проверка гледа счетоводна логика, не просто формат.

Софтуер като Safty може да генерира файла и да го провери срещу правила, извлечени от реални откази, преди подаване, но не поема задължението за подаване по чл. 71з ДОПК и не гарантира приемане от НАП. Задължението остава на предприятието по смисъла на чл. 2 от Закона за счетоводството. Инструментът намалява риска от отказ на познати основания. Той не замества преценката дали дадена стопанска операция е класифицирана правилно в изходните счетоводни данни.

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

Отказ на съдържателния етап не отменя срока, а стартира нов, по-кратък срок, за който отговаря предприятието. По чл. 71к, ал. 7 ДОПК предприятието разполага със 7 дни от уведомлението на НАП да подаде нов, цял файл, който отстранява несъответствията. В преходния период важи допълнително 12-месечният режим по § 17, ал. 2 ПЗР ЗДБРБ 2025. Процедурата е разгледана в Корекции на SAF‑T файл: как работи 12-месечният режим.

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

Предприятие, което оценява софтуер за SAF‑T, трябва да провери какво точно прави инструментът на всеки от двата етапа, а не само дали „генерира файл“. Генерирането на валиден по формат XML е първата, по-лесната част. По-важният въпрос е дали инструментът проверява съдържанието срещу познати причини за отказ, преди файлът изобщо да стигне до портала на НАП, и дали показва ясно кои несъответствия остават за преценка на счетоводния екип.

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