Видове подаване и как работи практически
Трите вида подаване - месечен, годишен, при поискване - какво съдържа всеки, как се именува файлът и как работи прозорецът за корекция.
Три подавания, не едно
В глава 1 споменахме, че SAF-T има три отделни вида подаване. Тук разглеждаме всеки от тях като отделна задача - какво съдържа, кога се подава, как се именува файлът и какво означава "коригирам файл" на практика.
Най-важното да имате предвид: месечен, годишен и при поискване не са три варианта на един и същ файл с различна честота. Всеки има собствен набор от задължителни секции - и не всяка секция от XSD схемата присъства във всеки от трите.
Сравнение на трите вида на един поглед
| Месечен (M) | При поискване (D) | Годишен (A) | |
|---|---|---|---|
| Цел | Редовно счетоводство за периода | Материални запаси при поискване от НАП | Дълготрайни активи и амортизация |
| Старт | 01.01.2026 | средата на 2026 | 01.01.2027 |
| Header | Да | Да | Да |
| GeneralLedgerAccounts / Customers / Suppliers / TaxTable | Да | Не | Не |
| UOMTable / MovementTypeTable / Products / PhysicalStock | Не (UOM/Products - да, вижте по-долу) | Да | Не |
| Owners (MasterFiles) | Опционална | Опционална | Опционална |
| CorrespondingAccountsReport (Главна книга) | Опционална | Не | Не |
| Assets | Не | Не | Да |
| GeneralLedgerEntries | Да | Не | Не |
| SourceDocuments | Sales/Purchase/Payments | MovementOfGoods | AssetTransactions |
TaxTable, UOMTable и Products не са обвързани с точно един вид подаване
За разлика от повечето подсекции в таблицата по-горе, TaxTable, UOMTable и
Products присъстват и в месечния, и във файла при поискване (не само в единия) -
защото и двата вида подаване могат да цитират данъчни кодове, мерни единици или
продукти на своите редове. Не приемайте по подразбиране, че всяка подсекция принадлежи
само на един вид файл - проверявайте я конкретно.
Owners не е \"само годишна\" секция - тя е опционална навсякъде
Лесно е да се предположи, че щом Owners звучи като "собственост", тя принадлежи единствено на годишния файл заедно с Assets. Официалният ред за подаване на НАП изрично посочва Owners като незадължителна за подаване и в трите вида файл - месечен, годишен и при поискване. На практика почти никой не я попълва извън годишния файл, защото структурата на собствеността не се мени всеки месец - но това е избор на подаващия, не изискване на схемата.
Главна книга - петата, почти непозната секция
Освен Header, MasterFiles, GeneralLedgerEntries и SourceDocuments, схемата има и пета,
самостоятелна секция на върха на дървото - CorrespondingAccountsReport ("Главна
книга"). Тя не е подсекция на MasterFiles или SourceDocuments, а собствена секция,
редом с тях - и съществува само в месечния файл.
Съдържанието ѝ е просто: салда и обороти по сметки заедно с кореспондиращите им сметки - допълнителна прозрачност за проверяващия орган, отвъд самите GeneralLedgerEntries записи.
Опционална, но не защото е маловажна
CorrespondingAccountsReport е изцяло незадължителна за подаване - но НАП изрично
препоръчва подаването на всяка опционална секция, за която разполагате с данни,
защото намалява административната тежест при последващи проверки. Пропускането ѝ не
отхвърля файла; включването ѝ, ако имате данните, е чиста печалба за вас при бъдеща
ревизия.
Месечният файл - редовният ритъм
Месечният файл е този, който подавате периодично, всеки месец. Задължителните му секции са:
- Header - заглавна информация за фирмата и периода.
- MasterFiles - но не цялата секция: GeneralLedgerAccounts (сметкоплан), Customers, Suppliers и TaxTable са ядрото. Две подсекции, които звучат "основни", но всъщност не са задължителни в месечния файл: Taxonomies и AnalysisTypeTable - лесно се предполага, че щом MasterFiles е задължителна, всичко вътре в нея е задължително, но не е така. Owners също отсъства от месечния файл - тя принадлежи на годишния (виж по-долу).
- GeneralLedgerEntries - счетоводните записи за периода (глава 5).
- SourceDocuments - продажби, покупки, плащания (глава 6).
Честа грешка
Счетоводители, които подготвят Taxonomies или AnalysisTypeTable за месечния файл "за всеки случай", защото предполагат, че е задължително. Не е грешка да ги включите, ако имате данните - но не е и загуба на време да пропуснете месец, в който нямате готови.
При поискване - различна цел, различни секции
Файлът "при поискване" не е по-кратка версия на месечния - той обслужва съвсем друга цел: материални запаси. Затова и наборът му е различен:
- Header
- MasterFiles - конкретно UOMTable (мерни единици), MovementTypeTable (видове движения на стоки), Products (продуктов каталог) и PhysicalStock (наличности).
- SourceDocuments - конкретно MovementOfGoods (движение на стоки).
Забележете какво липсва тук
GeneralLedgerEntries изобщо не участва във файла при поискване. Ако очаквате "при поискване" да прилича на месечния файл само с по-тесен обхват, ще подготвите грешните данни - той не е "по-малкият месечен файл", а напълно различна структура, фокусирана единствено върху наличности и движения на стоки.
Годишният файл - активите
Годишният файл покрива нещо съвсем различно от двата по-горе - дълготрайните активи:
- Header
- MasterFiles - Owners (собственост/акционери - виж глава 3 за разликата с Header/Ownership) и Assets (активи, с двете паралелни оценки, разгледани в глава 4).
- SourceDocuments - конкретно AssetTransactions (придобиване, изписване, преоценка на активи).
AssetTransactions се подава само при поискване от администрацията
Официалната бележка в схемата уточнява, че AssetTransactions се подава конкретно
при поискване от данъчната администрация - но структурно живее под годишния файл
(SourceDocumentsAnnual), не под "при поискване" (SourceDocumentsOnDemand). Двата
режима - "кой вид файл го съдържа структурно" и "кога реално се задейства" - са
отделни въпроси, лесни за объркване именно защото имената звучат сходно.
Как се именува файлът
Грешно име на файла означава отхвърляне, независимо колко правилно е съдържанието му. Схемата е:
| Вид подаване | Формат на името | Пример (ЕИК 123456789, юни 2026) |
|---|---|---|
| Месечен | ЕИК_ММ_ГГГГ.xml |
123456789_06_2026.xml |
| Годишен | ЕИК_ГГГГ.xml |
123456789_2026.xml |
| При поискване | ЕИК_ДД_ММ_ГГГГ_ДД_ММ_ГГГГ.xml (начало и край на изисквания период) |
123456789_01_06_2026_30_06_2026.xml |
Проверявайте името толкова внимателно, колкото и съдържанието
Валидна XML структура с грешно име на файла все пак се отхвърля - системата на НАП разпознава кой вид подаване очаква именно по формата на името, преди изобщо да отвори и провери съдържанието.
Корекции - защо не е фиксиран 12-месечен срок
В глава 1 обещахме да обясним точния механизъм за корекции. Ето го: прозорецът за коригиране на вече подаден период не е фиксирани 12 месеца за всичко - той е намаляваща каскада, обвързана с това кой пореден коригиращ файл подавате за същия период:
- 1-ви коригиращ файл - 6 месеца от първоначалното подаване
- 2-ри - 5 месеца
- 3-ти - 4 месеца
- 4-ти - 3 месеца
- 5-ти - 2 месеца
- 6-ти - 1 месец
Практическата поука
Колкото повече пъти коригирате един и същ период, толкова по-тесен става прозорецът да го направите отново. Не разчитайте на "имам още много месеци" само защото сте подали корекция наскоро - проверете кой пореден файл подавате за този конкретен период, преди да отложите поредната поправка.
Как се подава - два канала
НАП изрично предвижда два начина да подадете файла (Приложение №3 към заповедта, раздел II):
- През портала на НАП с квалифициран електронен подпис (КЕП) - ръчният, познат от другите декларации начин.
- Директно система-към-система, през публичен приложно-програмен интерфейс (API) - ако счетоводната ви програма поддържа връзка към този API, без ръчно влизане в портала за всеки файл.
Кой канал реално ще ползвате
Кой от двата канала е достъпен за вас зависи изцяло от това дали софтуерът ви поддържа връзка към API-то на НАП - това не е нещо, което решавате еднолично, а възможност, която доставчикът на софтуера трябва да е изградил.
Какво да запомните от тази глава
- Трите вида подаване имат различни задължителни секции - при поискване не включва GeneralLedgerEntries, годишният е фокусиран върху активи.
- TaxTable, UOMTable и Products се появяват едновременно в повече от един вид подаване - не приемайте автоматично "една подсекция = един вид файл". Owners е опционална и в трите вида файл, не само в годишния.
- Има и пета, самостоятелна секция извън MasterFiles/GLE/SourceDocuments - CorrespondingAccountsReport ("Главна книга"), опционална и само за месечния файл.
- Taxonomies и AnalysisTypeTable са опционални дори в месечния файл.
- Името на файла следва точен формат според вида подаване - грешно име отхвърля целия файл, независимо от валидното съдържание.
- Прозорецът за корекция намалява с всеки следващ коригиращ файл за същия период (6→5→4→3→2→1), не е фиксиран 12-месечен срок.
- Подаването е възможно през портала с КЕП или директно през API.
Следващата глава разглежда Header - заглавната част на файла - и една от най-често бъркваните двойки понятия в цялата схема: Ownership срещу Owners.
Сравнение на трите вида на един поглед
Кои секции/подсекции присъстват във всеки вид подаване
Прозорецът намалява с всеки следващ коригиращ файл
За същия отчетен период
Коригиращ файл №1
6 месеца
№2
5 месеца
№3
4 месеца
№4
3 месеца
№5
2 месеца
№6
1 месец
Всеки следващ коригиращ файл за същия отчетен период получава един месец по-малко прозорец за собствена корекция - до 1 месец при шестия.
Пример
Първи файл за м.01.2026 → крайният срок за корекции на 2026-годишните периоди се сближава до един общ краен срок (в примера на НАП - края на 02.2027 г.).
Magi разпознава типа подаване вместо вас
Месечен, годишен или по искане - Magi изгражда точната структура за всеки тип подаване от тази глава, всеки месец наново.