SAF-T грешка: съобщенията на НАП, значение и поправка

Когато НАП отхвърли SAF-T файл, съобщението е на български, дълго и написано на езика на структурата („елемент GL.28 CustomerID“, „подсекция 5.12“). Тук са събрани съобщенията, които НАП публикува в официалните Въпроси и отговори (версия 2, раздел IV.2) и в презентацията от 18.02.2026 (слайдове 55–62). Цитатите са дословни; обясненията и поправките са наши.

Бърза проверка: качете файла в безплатния валидатор или поставете съобщението в диагностиката на НАП грешки.

Две неща, които трябва да знаете първо #

Грешката не е краят. За задължения, възникнали между 01.01.2026 и 01.01.2030, няма шестмесечен гратисен период, но има 12 месеца за корекция: всеки подаден файл, получил входящ номер (дори отхвърлен), може да бъде заменен с нов за същия период. След изтичането на този прозорец (за първата вълна — от края на февруари 2027 г.) се прилага чл. 71к, ал. 7 от ДОПК: при установени несъответствия НАП ви уведомява и имате 7 дни да ги отстраните (Въпроси и отговори, т. II.2.3).

Кой поправя? Има два вида причини и е важно да ги различавате:

• Проблем в данните — грешен ЕГН/ЕИК, липсващ град, невярна дата. Поправя се в счетоводната програма или в картотеката на контрагентите, после файлът се генерира наново.
• Проблем във формата — празен таг, грешен брояч, неправилен префикс. Това е грешка на софтуера, който е генерирал файла; счетоводителят не може да я поправи ръчно и не бива да редактира XML файла.

1. Файлът дори не е приет (при качване) #

„Отказано получаване – нередно съдържание във файла“ #

Отказано получаване - нередно съдържание във файла

Файлът не получава входящ номер, защото се отказва още преди валидацията по XSD. Най-честата причина според НАП: таговете трябва да носят пространството от имена nsSAFT (<nsSAFT:Header>, не <Header>). По Приложение №3 файлът не се приема и когато не е .xml, името му не следва конвенцията (ХХХХХХХХХ_ММ_ГГГГ.xml за месечен, ХХХХХХХХХ_ГГГГ.xml за годишен) или не е подписан с КЕП. Сродни статуси са „Невалиден размер на файла“, „Отказан от потребител“, „Отказан поради неактивност“ (30 часа без активност при качването) и „Служебно отказан“.

• Какво да направите: проверете името и подписа; ако са наред, това е проблем на формата — софтуерът трябва да генерира тагове с nsSAFT.

„Открит е непозволен символ на ред 1, позиция…“ #

Открит е непозволен символ на ред 1, позиция 40.

XML не може да бъде прочетен от тази позиция: невалиден UTF-8 байт, BOM или невидим контролен символ в началото, или таг, който е отворен и не е затворен. Типичен случай е файл, редактиран ръчно (например в Word или в редактор, който подменя кавичките).

• Какво да направите: не редактирайте файла ръчно; генерирайте го наново. Файлът трябва да е UTF-8 без BOM, с XML декларация на първия ред. Формат.

„Невалиден Header към XSD“ #

Невалиден Header към XSD

Файлът е повреден и не може да се обработи (по обяснение на НАП: грешен синтаксис, незатворен таг, невалиден UTF-8 символ). Формат; поправката е същата като по-горе.

„Видът на файла … не отговаря на изискуемото съдържание“ #

Видът на файла (месечен, годишен, при поискване), избран при подаването му в е-услугата, не отговаря на изискуемото съдържание за съответния вид файл.

Месечният файл трябва да съдържа MasterFilesMonthly, GeneralLedgerEntries и SourceDocumentsMonthly. Грешката значи, че в е-услугата е избран един вид файл, а съдържанието е от друг — например годишен вместо месечен.

• Какво да направите: изберете правилния вид при подаването. Ако е избран правилният, а файлът е месечен, но липсва секция — формат.

2. Заглавната част (Header) #

Грешен ЕИК #

В елемент RegistrationNumber, подсекция CompanyHeaderStructure, секция Structures е посочен грешен ЕИК

ЕИК в заглавната част не съвпада с ЕИК на лицето, за което подавате в е-услугата. Причини: файл за друг клиент, водещ префикс или интервал, „BG“ пред номера. RegistrationNumber съдържа само цифрите на ЕИК. Името на файла също трябва да носи същия ЕИК.

• Какво да направите: подавайте файла от името на правилния клиент. Данни (или грешно избран клиент при генерирането).

Периодът не съвпада с избрания в е-услугата #

Датата за начало на отчетен период, посочена в елемент SelectionStartDate/PeriodStart/PeriodStartYear, секция Structures, подсекция 5.12 SelectionCriteriaStructure, не отговаря на началната дата на периода, посочен в е-услугата при подаването на файла.

Във файла пише един месец, а в е-услугата сте избрали друг. Проверете и месеца в името на файла.

• Какво да направите: изберете в е-услугата точно периода, за който е генериран файлът. Грешка при подаването, не на файла.

3. Контрагенти: CustomerID и SupplierID #

Най-голямата група грешки в тестовата среда е свързана с идентификаторите на клиенти и доставчици. Форматът е „двуцифрен код + идентификатор“.

GL.28 / GL.29 — идентификатор, който не е попълнен правилно или не е деклариран #

Стойностите в елементи GL.28 CustomerID и GL.29 SupplierID в секция GeneralLedgerEntries не са попълнени съгласно изискванията или са подадени идентификатори за клиент/доставчик, който не фигурира в секция 2. MasterFiles, елемент MF.C.3/MF.S.3.

Какво означава: НАП получава идентификатор, който или е с грешен вид, или няма запис в MasterFiles. Официалните примери са два: „104104104“ (липсва кодът „10“) и „10BG104104104“ (добавен е „BG“ след кода). Българското ЕИК се подава като „10“ + голото ЕИК. Идентификаторът в реда от главната книга трябва да е същият като в MasterFiles.

Некоректен двуцифрен код #

В секция MasterFiles, подсекция Suppliers, е подаден некоректен двуцифрен код за идентификатор на доставчик със SupplierID

Допустими са само кодовете 10–16:

Код „17“, както в примера на НАП, не съществува. Формат — програмата е залепила собствен префикс. Ако получите грешка от този вид, проверете как програмата ви формира префикса.

ЕГН или ЕИК, който не е истински #

Тестовата среда проверява не само формата, но и контролната цифра на ЕГН и ЕИК. В един от тестовите ни файлове НАП отхвърли 15 идентификатора и всички бяха точно тези с невалидна контролна цифра. Число, което прилича на ЕГН, но не минава проверката, не е ЕГН — и подаването му с код „13“ твърди нещо невярно.

• Какво да направите: проверете картона на контрагента. Ако нямате истински номер, подайте го като „15“ (вътрешен код). Това е проблем в данните, който счетоводителят трябва да поправи в картотеката. Софтуерът би трябвало да ви покаже кои картони не минават.
• Правило: ЕГН на физическо лице се подава с код „13“. Номер, който минава контролната цифра, но не принадлежи на реално лице, може да бъде отхвърлен, а такъв случай програма не може да засече.

Префикс на държава в ЕС #

За Гърция VIES пише „EL“, не ISO „GR“; „11GR…“ е отхвърлен като некоректен. Формат.

4. Данъчна информация #

В елемент TaxType, подсекция TaxInformationStructure, секция Structures, е подадена некоректна стойност за вид на данък - несъответстващ на утвърдената номенклатура TAX-IMP.

Най-честата причина, по обяснение на НАП: подаден е празен таг TaxType/TaxCode. Когато редът няма данък, подава се TaxType „000“ и TaxCode „000000“, никога празен елемент. Втората причина е стойност, която не е в номенклатурата TAX-IMP.

• Празен таг е формат. Стойност извън номенклатурата най-често е свързване — например свързан с неправилен ДДС код. Вижте номенклатурите.

5. Броячи и суми #

Грешен NumberOfEntries #

Стойността елемент NumberOfEntries /GL.1/, секция 3. GeneralLedgerEntries, не съответства на броя на транзакциите TransactionID /GL.9/ в тази секция.

NumberOfEntries се брои различно във всяка секция:

Total Debit / Total Credit не съвпада с InvoiceLineAmount #

Посочената в поле Total Debit SD.PI.2 стойност не съответства на общите суми посочени в поле S.I.46 InvoiceLineAmount, отразени в подсекция 5.10 InvoiceStructure, във връзка с препратка от подсекция 4.2 PurchaseInvoices - елемент SD.PI.4 Invoice, и е посочен индикатор „D“ в поле S.I.47 DebitCreditIndicator.

Total Debit и Total Credit са сбор от InvoiceLineAmount по индикатор D и C, без данъка (TaxAmount). Най-честата причина е, че данъкът е прибавен към тях. Формат.

6. Периоди без движение #

Ако в секция няма движение, не я пропускайте. НАП изисква NumberOfEntries = 0, TotalDebit = 0.00, TotalCredit = 0.00 и една празна структура с нулеви стойности. Пропускането на секцията е формат; примерите са в раздел IV.2.6.

7. „Съдържат се 1317 грешки спрямо XSD“ #

В подадения SAF-T се съдържат грешки спрямо валидацията по XSD схемата. Поради големия им брой, списъкът включва описание на първите 1000 грешки.

Файлът е „Отхвърлен – невалиден към XSD“. Не е нужно да поправяте 1 317 неща. Толкова много грешки обикновено са един системен проблем, повторен във всеки запис: липсващ задължителен елемент, грешен формат на сума или дата, грешен ред на елементите. Списъкът е отрязан до първите 1 000, така че след поправка на първия проблем може да излязат следващи — проверете файла отново, преди да го подадете.

Как да не стигате до отхвърляне #

Структурните грешки се хващат от безплатния валидатор; значението на получено съобщение ще намерите в диагностиката на грешки. При отхвърляне поправете причината и подайте наново в рамките на 12-месечния срок за корекция.

SAF-T Bridge проверява файла по правилата на НАП и по тези, които тестовата среда реално е прилагала, преди да го изтеглите, и ви показва кои контрагенти и сметки изискват ваше решение. Регистрацията е по покана, а началото е демонстрация.