Срокове, обхват и подаване

В SAF-T "срокове и подаване" не са второстепенна административна тема. Те са част от самата логика на стандарта, защото SAF-T функционира като цикъл от периодични "снимки" на счетоводните данни, които се приемат, валидират и при нужда се подават отново като нова версия за същия период. Това е различно от отчетния навик "веднъж приключихме, веднъж подадохме". При SAF-T реалността е процесна: има редовен месечен ритъм, има годишен слой за активи и има режим "при поискване" за запаси; а управлението на грешките е вградено чрез механизма на отхвърляне и 7-дневен срок за нов файл.

2.1. Видове файл и периодичност: месечен, годишен (активи), при поискване (запаси)

Електронната услуга на НАП и нормативната рамка разграничават три вида SAF-T файл и ги въвеждат поетапно: месечен SAF-T от 01.01.2026 г., подаване "при поискване" от 01.07.2026 г., и годишен SAF-T (за активи) от 01.01.2027 г.

Това разграничение е счетоводно съществено, защото зад него стоят различни "снимки" на бизнеса: месечната снимка е оперативна и универсална, годишната снимка е специализирана за активите и е вързана към данъчния годишен цикъл, а "при поискване" е инструмент за контрол върху запасите в период, определен от органа по приходите.

Таблица 2.1. Паспорт на месечния SAF-T файл

Параметър Описание Какъв е този файл в счетоводен смисъл Месечна структурирана "снимка" на счетоводните данни: основни данни/номенклатури + осчетоводени операции (журнал) + документи (фактури) + плащания за периода. Период, който описва Един календарен месец. Срок за подаване До края на месеца, следващ отчетния период. Конвенция за име на файла ЕИК_MM_YYYY.xml Пример (неутрален) За ЕИК 123456789 и месец 01.2026: 123456789_01_2026.xml Практически акцент Това е гръбнакът на SAF-T режима: ако месечният цикъл не е стабилен (номенклатури, връзки, версии), всички "по-редки" подавания стават рискови.

Тази "паспортна" структура е полезна, защото напомня на счетоводителя, че месечният файл не е равен на "главна книга" или "дневници", а е комплекс от слоеве. В месечния SAF-T се подават и речници (MasterFiles), и операции (GeneralLedgerEntries), и документният слой (SourceDocuments – фактури и плащания). Оттук следва и практичният извод: месечният SAF-T не може да бъде качествен, ако организацията третира номенклатурите като "вътрешна работа, без стандарти" – защото именно номенклатурите правят възможно валидирането на журнала и документите.

Таблица 2.2. Паспорт на годишния SAF-T файл за активи

Параметър Описание Какъв е този файл в счетоводен смисъл Годишна структурирана "снимка" на активите и движенията по тях според дефинициите в SAF-T структурата (активи + транзакции с активи). Период, който описва Финансова година. Срок за подаване В срока за годишната данъчна декларация по чл. 92 ЗКПО (подаването е обвързано с годишния данъчен цикъл). Конвенция за име на файла ЕИК_YYYY.xml Пример (неутрален) За ЕИК 123456789 и година 2026: 123456789_2026.xml Практически акцент Този файл предполага дисциплина в регистъра на ДМА (идентификатори, характеристики, движения). Обикновено проблемите са не "в XML", а в непълни или несъгласувани данни между модул "ДМА" и счетоводството.

Годишният файл често се подценява, защото "не е всеки месец". В действителност той е високорисков по друг критерий: съдържа домейн, който в много организации живее отделно (регистър на активи), а SAF-T го поставя под същата логика на структурна валидируемост и проследимост.

Таблица 2.3. Паспорт на SAF-T файла "при поискване" за запаси

Параметър Описание Какъв е този файл в счетоводен смисъл Структурирана снимка на запасите и движенията, подготвена за контрол: целта е да се даде детайлност по артикули и движения за период, определен в искането. Период, който описва Периодът е параметър на искането (не "по подразбиране месец"). Срок / тригер за подаване Само при поискване от орган по приходите и в определен от него срок. Конвенция за име на файла ЕИК_DD_MM_YYYY_DD_MM_YYYY.xml Пример (неутрален) За ЕИК 123456789 и период 01.01.2026–31.12.2026: 123456789_01_01_2026_31_12_2026.xml Практически акцент Във документа "Въпроси и отговори, свързани с внедряването на стандартния одитен файл за данъчни цели (SAF-T)" на НАП е изяснено, че не е допустимо подаване само на обобщени годишни данни по артикул; изискват се детайлни движения за всеки артикул. Това прави качеството на складовата аналитика част от SAF-T готовността.

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

2.2. "Обхват" в SAF-T: една организация, три различни контролни цели

След като уточним "вид файл", обхватът става по-ясен. При SAF-T обхватът не е само списък "какви регистри", а комбинация от: (1) период, (2) домейн на данните (операции/активи/запаси), (3) степен на детайлност, и (4) връзки между слоевете данни. В месечния режим доминират счетоводните операции и документният слой; в годишния режим доминират активите; в режима при поискване доминират запасите и движенията.

Практическата стойност на това разграничение е, че позволява да се планира готовността "на пластове". Месечният цикъл изгражда навик и дисциплина (номенклатури, връзки документ–операция–плащане). Годишният цикъл добавя зрелост на регистъра на активите. Режимът при поискване поставя условие складовата аналитика да бъде достатъчно детайлна и съгласувана. Това не са три различни проекта; това са три режима на една и съща логика: структурирани, проверими и проследими данни.

2.3. Правила за подаване: XML, конвенции за име, подписване

Подаването на SAF-T започва с формална годност на файла като носител. Спецификацията изисква XML формат, кодировка UTF-8 и спазване на конвенции за името на файла според вида подаване. На този етап най-типичните "първи" проблеми са: неправилно име на файл, несъответстващ формат, или неподписан файл.

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

Това е процесно важно, защото организациите често разделят ролите: генерирането може да е при IT/ERP екип, а подписването – при лице с КЕП. SAF-T режимът допуска това разделение, но изисква да бъде управлявано без "скъсване" на отговорността.

Таблица 2.4. Формални изисквания за подаване

Изискване Какво означава в практиката Формат XML и кодировка UTF-8 Файлът не е "експорт в какъвто и да е формат", а XML по определена структура; грешна кодировка/формат е бариера още преди съдържателните проверки. Конвенция за име на файл Името съдържа ключовата идентичност на подаването (ЕИК, период, вид файл). Неспазването води до неприемане. Подписване с КЕП Файлът се подава подписан от подаващия за задълженото лице; без подпис не се приема. Канал за подаване Подаване през портала на НАП или по система-система през публичен API – важно за автоматизация и контрол на версиите.

Към това се добавя още един формален, но съществен слой: файлът трябва да е "XML по правилния договор", т.е. да съдържа задължителните секции, подсекции и елементи за съответния вид файл; ако липсват, файлът няма да премине XSD-валидацията и няма да бъде приет като валиден.

Това уточнение е важно, защото често се мисли "XML е достатъчно", а реалността е "XML по XSD и по правилата за конкретния файл".

2.4. Отхвърляне и 7-дневен срок: как изглежда грешката като процес

Процесът по подаване има две различни "бариери". Първата е преди обработката: ако файлът не отговаря на формалните изисквания (формат/име/подпис), той не се приема. Втората е след приемане за обработка: файлът преминава проверки към XSD схемата и проверки за валидност и консистентност; при несъответствия файлът се отхвърля, предоставя се информация за грешките и се дава 7-дневен срок за подаване на нов файл след отстраняване на несъответствията.

Това разграничение е счетоводно важно, защото насочва към различен тип коригиращо действие. При "не се приема" обичайно е достатъчна техническа поправка (име, подпис, формат). При "отхвърля се" често причината е в данните и връзките: липсващ запис в номенклатурата, неконсистентни кодове, разкъсана връзка документ–журнал, конфликтни стойности. Тогава най-правилната счетоводна реакция е корекция в източника и повторно генериране, не "козметика" в XML.

Таблица 2.5. Процесна карта: "Файлът не се приема"

Параметър Съдържание Кога се случва Преди обработката и преди съдържателните проверки. Типични причини Неправилен формат/кодировка; неспазена конвенция за име; липсващ/невалиден подпис (КЕП). Какво означава "в счетоводен превод" Това е формална бариера: файлът не влиза в режим на "съдържателна оценка", т.е. проблемът обичайно не е в салда/операции, а в носителя и формата на подаване. Тип коригиращо действие Техническа корекция: правилно именуване; коректен XML/UTF-8; валиден КЕП и правилен процес по подписване/подаване. Риск при лоша организация Натрупване на сроков натиск още преди да започнат реалните проверки по данни; подаването се превръща в "гонене на формат", вместо в управляем процес.

Таблица 2.6. Процесна карта: "Файлът се отхвърля" и 7-дневният срок

Параметър Съдържание Кога се случва След като файлът е приет за обработка – при валидации към XSD и проверки за валидност/консистентност на данните. Какво следва по правилата Файлът се отхвърля; през електронната услуга се предоставя информация за грешките; дава се 7-дневен срок за отстраняване чрез подаване на нов файл. Типични "корени" на проблема Неконсистентни или непълни номенклатури; референции към несъществуващи обекти; логически конфликти между слоевете (например документният слой не може да се "затвори" към журналния по референции/стойности). Тип коригиращо действие Корекция в източника на данните (ERP/счетоводна система), в правилата за извличане/мапинг и повторно генериране на файла за периода; ръчната редакция на XML е крайно рискова и принципно не решава причината. Риск при лоша организация Ако 7-дневният срок се изпусне, файлът се третира като неподаден (в практическо измерение това вече е риск по спазване на режима, не просто "грешка").

Една неутрална илюстрация показва защо отхвърлянето е "счетоводна" тема. Ако в документните редове е използван данъчен код, който не е дефиниран в TaxTable или е дефиниран по различен начин, файлът може да е коректен като носител (XML, име, подпис), но да бъде отхвърлен при проверките за консистентност, защото речникът и документите не говорят на един и същ език. Подобни грешки не се лекуват трайно с "поправка на XML", а с дисциплина в номенклатурите и картографирането на кодове в източника.

2.5. Корекции: "подай целия файл за периода" и принципът "последният приет е редовен"

Корекциите са сърцевината на версияцията в SAF-T. Правилото е ясно: когато се подава корекция, се подава целият файл за периода – цялата информация по утвърдената структура и правила, а не "само промененото".

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

В рамките на срока за подаване лицето може да подаде повече от един файл за един и същи период; за редовно подаден се счита последният успешно подаден и приет файл.

Това изречение е управленско правило: то въвежда контрол върху процеса чрез последната версия, а не чрез първото действие. Следователно корекцията не е "изключение", а нормална част от жизнения цикъл на данните.

Таблица 2.7. Корекции и версии: принципи и практическо значение

Принцип Пояснение и неутрален пример Корекция = нов пълен файл за периода Ако коригирате нещо за януари, не подавате "само липсващите фактури", а подавате нов пълен файл за януари. Идеята е да няма "дупки" в периода при замяна на версията. Последният приет файл е редовният Ако подадете версия 1 за януари и след това версия 2 (коригирана) в срока, редовен е последният приет файл. Това изисква вътрешно да знаете коя версия е последна приета и какво е променено. Корекцията е процес по данни, не "редакция на XML" Когато причината е в номенклатура/връзки, правилният подход е поправка в източника и повторно генериране, за да бъде новата версия устойчиво правилна, а не еднократно "закърпена". Версиите трябва да са проследими Дори в малка организация е разумно да има регистър "период – версия – дата – статус". Това намалява риска да не знаете коя версия е редовна и да подадете "стар" файл като нов.

2.6. Корекционният прозорец за минали периоди: кога още има право на "нова версия" за стар месец

Освен нормалните корекции "в рамките на срока за подаване", рамката въвежда и правила за корекции на вече подадени периоди чрез подаване на нов файл за минал период в рамките на определен времеви прозорец. В общия механизъм по чл. 71к, ал. 6 ДОПК е описана логика за корекции в следващите шест месеца чрез подаване на нов файл за съответния период.

За поетапното въвеждане НАП дава ключово уточнение: за периода 01.01.2026–01.01.2030 г. чл. 71к, ал. 5 не се прилага, а срокът по чл. 71к, ал. 6 е дванадесет месеца и тече от датата на възникване на задължението.

В примерната логика това означава, че месечните файлове за първата година могат да бъдат коригирани чрез подаване на нов файл за съответния период до определен краен момент, и във файла "Въпроси и отговори, свързани с внедряването на стандартния одитен файл за данъчни цели (SAF-T)" на НАП е илюстрирано с конкретен пример за край на февруари на следващата година при старт от 01.01.

Това не е "правен детайл", а практическа политика за заключване на периодите. Ако организацията знае, че има прозорец за корекции на минали периоди, тя може да планира вътрешно кога периодът се счита "финално стабилен" за целите на SAF-T и кога все още може да се появи легитимна нова версия. В противен случай се получава типичната слабост: едната част от екипа "заключва" месеца счетоводно, а друга част (по нужда) прави промени в основните данни, които влияят на следващи версии, без ясна проследимост как това се отразява на вече подадените SAF-T периоди.

2.7. Подаване като вътрешна процедура: минималната дисциплина, която прави режима спокоен

Секция 2 (Срокове, обхват и подаване) би била непълна, ако не преведем процесните правила в организационна дисциплина. SAF-T е технологично подаване, но счетоводно управление. Затова дори при малък екип е полезно да има минимална процедура, която гарантира две неща: първо, че подаването е повторяемо, и второ, че версиите са контролируеми.

Тук отново представям дисциплината в портретна таблица с две колони (елемент – съдържание и резултат), така че да се ползва директно в наръчник или вътрешна инструкция.

Таблица 2.8. Минимална вътрешна дисциплина за SAF-T подаване

Елемент Съдържание и резултат Регистър на версиите Поддържа се лог за всеки период: дата на генериране, подаващ, статус (приет/отхвърлен), причина за промяна. Резултатът е прост: винаги знаете коя версия е последна приета и защо е различна от предходната. Контрол преди подаване Съгласуване на базови тотали и проверки за "чистота" на номенклатури (сметки/контрагенти/данъчни кодове) и връзки документ–журнал. Резултатът е по-ниска вероятност за отхвърляне и по-кратък цикъл на корекция. Процедура при грешки При отхвърляне: анализ на грешките, класификация (структурна/данни), корекция в източника, повторно генериране и ново подаване в 7 дни. Резултатът е, че срокът се управлява като част от процеса, а не като кризисно събитие.