III. Корекции, периоди, подаване и валидиране

Въпрос 56. Как следва да се подават в SAF-T данните за клиентските операции на банка?

Отговор 56. Не поотделно, когато става дума за информация, свързана със сделки с финансови инструменти по смисъла на т. 11 от МСС 32, която попада в обхвата на банковата тайна по чл. 62 от Закона за кредитните институции. За този обхват Приложение № 3 предвижда специален ред, при който информацията се посочва в SAF-T на агрегирано, обобщено ниво, например по видове финансови инструменти. За тези сделки не се посочват транзакционни данни, данни за клиенти или доставчици и данни за изходни документи в съответните секции на файла.
Това не означава, че банката не подава данни по общия ред. Приложение № 3 изрично предвижда, че данните за издадените и получените фактури, включително и когато са свързани със сделки с финансови инструменти, се подават чрез SAF-T съобразно общите изисквания за попълване на файла.
Следователно най-точният извод е, че банката не подава поотделно защитената от банкова тайна информация за този кръг сделки, а я подава обобщено. Останалите данни, за които се прилагат общите правила на файла, се подават по общия ред.

Въпрос 57. Опционалните секции трябва ли да присъстват във файла, ако в тях няма данни?

Отговор 57. По общото правило не. Приложение № 3 изрично предвижда, че опционални секции, подсекции и елементи, в които няма попълнени данни, не се подават с XML файла. Същевременно, когато такава информация е налична в използваните от задълженото лице информационни системи, нейното подаване е препоръчително.
Това правило обаче следва да се прилага заедно с подробното таблично описание на структурата по Приложение № 2. В самото Приложение № 3 е посочено, че именно в това приложение са дадени детайлните характеристики на секциите, подсекциите и елементите, включително режимът на докладване, режимът на отчитане и бележките по прилагането. Затова преценката дали дадена секция следва да присъства не се прави само по означението "опционална", а по конкретните указания за съответната част от файла.
Следователно най-точният извод е следният: ако за опционална секция няма данни и за нея не е предвидено друго в приложимите указания, тя може да не се включва във файла. Ако обаче в конкретните указания е предвидено специално правило, то следва да се приложи с предимство.

Въпрос 58. Какви съпоставки могат да се правят между данните в различните секции на SAF-T? Например между салдата по сметките за клиентите, счетоводните записвания и изходните документи?

Отговор 58. По запитване на автора до НАП е получен отговор, че исканата информация относно вътрешните показатели, съотношения и съпоставки е част от техническите изисквания и спецификациите на разработвания специализиран модул, а към момента на отговора не са налице създадени, формализирани и обективирани в утвърдени документи материали в този обхват. За списъка на логическите и консистентност проверки е постановен отказ за предоставяне на достъп. Следователно към момента няма публично оповестен изчерпателен списък на всички машинни проверки, които ще се прилагат. Нормативната рамка обаче е ясна в едно: след подаването на файла се извършват валидации по XSD схемата и проверки за валидност и консистентност на подадената информация, а в табличната структура по Приложение № 2 за отделните елементи са предвидени синтактични и семантични валидационни правила.
По логиката на структурата на SAF-T могат да се очакват поне следните групи съпоставки.
1. Първо се правят форматни и структурни проверки. При тях се установява дали файлът е в правилния XML формат, дали е изграден по действащата структура, дали са налице задължителните секции и елементи и дали стойностите са в допустимия тип и формат. Смисълът на тази група проверки е да се установи дали файлът изобщо е технически годен за валидиране и последващ прочит.
2. Следват проверките за референтна цялост между справочния и транзакционния слой. Ако в счетоводните записи, фактурите, плащанията или другите секции се използват AccountID, CustomerID, SupplierID, ProductCode, TaxType, TaxCode или мерна единица, съответните стойности трябва да съществуват в MasterFiles и да бъдат използвани последователно. Смисълът е отделните секции да образуват единна система от данни, а не набор от несвързани таблици.
3. Правят се и аритметични проверки вътре в самите документи. При фактурите и плащанията общите стойности трябва да бъдат възпроизводими от редовете, от които са формирани, а сумите, знакът и данъчните стойности трябва да са вътрешно съгласувани. Смисълът е да се установи, че документът е не само формално подаден, но и математически непротиворечив.
4. Особено важни са съпоставките между салдовите данни и движенията по периода. В MasterFiles за счетоводните сметки, клиентите и доставчиците се подават начални и крайни салда, а в GeneralLedgerEntries се подават движенията, които формират тези салда. Смисълът е крайното салдо да бъде обясним резултат от началното салдо и осчетоводените движения, а не самостоятелно твърдение без опора в журнала.
5. Следва съгласуване между документния слой и счетоводния слой. Изходните документи трябва да могат да обяснят счетоводния резултат чрез устойчиви идентификатори, последователни ключове и ясна логика на сторниране и корекция. Смисълът е да се затвори одитната следа между първичния документ и счетоводното му отражение.
6. На тази основа могат да се правят и съпоставки между разчетите, документите и плащанията. Ако по клиентска или доставна сметка е отчетено салдо, то трябва да бъде обяснимо чрез документи и плащания, а плащането да е проследимо като сума, дата, метод и референция към контрагент или документ. Смисълът е да се различават реалните уреждания на вземания и задължения от вътрешни парични движения и технически записи.
7. Значима група са данъчните съпоставки. Данъчната логика следва да бъде една и съща в документа, в отчетните регистри по ЗДДС и в счетоводния ефект. Това означава последователност между данъчните кодове, данъчните основания и сумите по съответните операции. Смисълът е данъчната квалификация да бъде устойчива и съпоставима, а не зависима от различно третиране в отделните модули.
8. Когато е приложим годишният или поисканият файл, могат да се правят и съпоставки при активите и материалните запаси. При активите се търси връзка между регистъра на активите, движенията по тях и счетоводните записи. При запасите се търси връзка между наличностите, движенията и свързаните счетоводни ефекти. Смисълът е активният и складовият слой да не стоят изолирано от счетоводната картина на предприятието.
9. Накрая има и междупериодна съгласуваност. Началните салда на един период трябва да бъдат съвместими с крайните салда на предходния, а когато се подава корекция, значение има последната успешно приета версия за съответния период. Смисълът е данните да бъдат не само вътрешно консистентни за един месец, но и устойчиви във времето.
Следователно между салдата по сметките за клиенти и доставчици, счетоводните записвания, изходните документи и плащанията действително могат да се правят съществени съпоставки. Нормативно по-точно е обаче да се каже, че публично е обявена общата рамка на валидациите и проверките за валидност и консистентност, докато подробният вътрешен списък на всички машинни правила не е публично оповестен. Самата структура на SAF-T, контролните салда, общите стойности и повтарящите се идентификатори са достатъчни, за да покажат логиката на тези съпоставки.

Въпрос 59. Информацията за материалните запаси подава ли се само при поискване? Само дълготрайните активи ли са на годишна база или и материалните запаси?

Отговор 59. Ако под "информация за материалните запаси" се разбират наличностите и движенията на материалните запаси, отговорът е да – тази информация не се подава автоматично нито месечно, нито годишно, а само при поискване от орган по приходите и в определения от него срок. За разлика от това, информацията за наличности и движение на дълготрайните активи се подава на годишна база, в срока за подаване на годишната данъчна декларация по чл. 92 от ЗКПО. Това следва както от чл. 71к, ал. 2 и ал. 3 ДОПК, така и от Приложение № 3, което изрично разграничава годишния файл за активи от файла при поискване за материални запаси.
Важно е обаче да се направи едно уточнение. От това не следва, че материалните запаси изобщо отсъстват от редовния месечен SAF-T. Действащото Приложение № 3 изрично предвижда, че в подсекция Products на месечния файл се подават данни за всички стоково-материални запаси и услуги, които са в счетоводната отчетност на лицето през периода, а в UOMTable се подават мерните единици, използвани в подадения файл. С други думи, месечно може да присъства продуктовият и номенклатурният слой, но не и складовият слой на наличностите и движенията, освен ако той не бъде изискан от орган по приходите.
Следователно най-точният извод е следният: на годишна база задължително се подава само информацията за дълготрайните активи. За материалните запаси няма общо годишно задължение за подаване; при тях задължението възниква само при поискване. При тълкуването на това правило обаче трябва ясно да се различават данните за наличности и движения на материалните запаси от свързаните с тях продуктови и мерни номенклатури, които могат да присъстват и в месечния SAF-T.

Въпрос 60. За файла с материалните запаси, който се подава при поискване, как следва да се подадат данните: за всеки един артикул или обобщено за всеки артикул на годишна база?

Отговор 60. По-точно е да се каже, че данните се подават за периода, посочен в искането на органа по приходите, а не по общо правило "на годишна база". По действащата публикувана от НАП версия 1.0.1 на Приложение № 3 файлът при поискване за материални запаси включва подсекциите PhysicalStock и MovementofGoods. PhysicalStock съдържа данни за наличните стоково-материални запаси, включително склада, идентификационния код на продукта и количествата и стойностите в началото и в края на отчетния период. MovementofGoods съдържа движенията на стоково-материалните запаси през отчетния период, включително общия брой на движенията за избрания период, общото получено и общото изходящо количество, но също така и уникалната референция и датата на всяко движение, вида на движението, контрагент, счетоводна сметка, количество и мерна единица. Това показва, че моделът е изграден като проследима количествена история за периода, а не като едно обобщено годишно число по артикул.
Отделно Приложение № 3 изрично свързва подсекция Products с PhysicalStock и MovementofGoods при режима "при поискване". Това означава, че материалният запас следва да бъде разпознаваем като конкретен артикул в слоя на наличностите и в слоя на движенията. Поради това подаването е аналитично по артикул, а в слоя на наличностите може да бъде и по отделна складова позиция, а не само като една сумарна стойност за целия период.
Вярно е, че в структурата има и общи контролни стойности за периода, например общ брой движения, общо получени и общо изписани количества. Тези стойности обаче имат контролна, а не заместителна функция. Те не отменят необходимостта да се подадат самите движения за периода. Ето защо, ако органът по приходите поиска информация например за една година, следва да се подадат началните и крайните наличности за този период и движенията в рамките на същия период, а не само годишно обобщение по артикул.
Следователно най-точният извод е, че файлът за материалните запаси при поискване не се подава само като обобщение по артикул за година. Той се подава за периода, определен от органа по приходите, с аналитични данни за наличностите и с детайлни движения по артикул за този период.

Въпрос 61. Какво налага преоценка на напълно амортизирани дълготрайни активи в САП, които все още фигурират в баланса с 0,00 балансова стойност, но продължават да се използват? Прилагаме национални счетоводни стандарти. Има ли нещо, което НАП ще засича във връзка с това чрез SAF-T?

Отговор 61. Самото обстоятелство, че един дълготраен актив е напълно амортизиран, но продължава да се използва, не налага автоматична преоценка. При прилагане на националните счетоводни стандарти по-точно е да се говори не за задължителна преоценка, а за периодичен преглед на полезния срок на годност, на метода на амортизация и на остатъчната стойност. СС 16 предвижда след първоначалното признаване активът да се отчита по цена на придобиване, намалена с начислените амортизации и натрупаната загуба от обезценка, а СС 4 изисква предприятието периодично да преразглежда оценката за полезния срок на годност и при нужда да я коригира.
Тук има и едно важно уточнение. СС 4 приема, че напълно амортизираните до остатъчната им стойност активи вече не се амортизират, а балансовата стойност не може да бъде по-ниска от остатъчната стойност. Това означава, че актив с балансова стойност 0,00 може да остане в отчетността и да продължи да се използва, когато остатъчната му стойност е определена като нулева или като незначителна по счетоводната политика на предприятието. Ако обаче остатъчната стойност е съществена, нулева балансова стойност не би била логичният резултат.
Следователно корекция в САП е необходима не защото активът продължава да се използва след пълното му амортизиране, а когато първоначално определеният полезен срок, методът на амортизация или остатъчната стойност вече не отразяват реалния модел на икономическо потребление. СС 4 изрично допуска промени именно при определяне на нов срок на годност, нов метод на амортизация, промяна в отчетната стойност поради подобрения или определяне на нова остатъчна стойност. Ако по такъв актив се извършат последващи разходи, които водят до допълнителни бъдещи икономически изгоди, по СС 16 те увеличават балансовата стойност на актива. Ако от актива вече не се очакват никакви икономически изгоди, той следва да бъде отписан.
От гледна точка на SAF-T това не е автоматично несъответствие. По действащата официална база на НАП, която към момента работи с версия 1.0.2 на XSD схемата, годишният файл за активи позволява да се видят полезният срок, методът на амортизация, натрупаната амортизация, балансовата стойност в края на периода и месеците и основанията при промяна в стойността на актива. Наред с това месечните амортизации се виждат в GeneralLedgerEntries, а годишният активен слой се подава чрез Assets и AssetTransactions. Така един актив може да бъде напълно видим в данните като наличен, с натрупана амортизация и BookValueEnd 0,00, без това само по себе си да означава грешка.
По логиката на SAF-T НАП по-скоро би засичала не самия факт на нулевата балансова стойност, а последователността на счетоводната политика и вътрешната логика на данните. Въпроси могат да възникнат, ако предприятието поддържа значим брой използвани активи с нулева балансова стойност без ясна политика за полезен срок и остатъчна стойност; ако има подобрения, без те да личат като увеличение на стойността или движение по актива; ако амортизационният разход рязко се променя без видима причина в регистъра на активите; или ако годишният регистър на активите не се съгласува с журнала и движенията по активите. Това вече е аналитичен сигнал, а не автоматична грешка.
Следователно изводът е следният: при националните счетоводни стандарти продължаващото използване на напълно амортизиран актив не налага автоматична преоценка. Налага се обаче периодичен преглед на полезния срок, метода на амортизация и остатъчната стойност, а при подобрения – правилно увеличение на стойността. В среда на SAF-T това няма да се чете като формален проблем само защото активът е "на нула", но ще бъде напълно видимо дали политиката за активите е последователна и дали данните по активите, амортизациите и главната книга се движат логично заедно.

Въпрос 62. Гуми и горива, които за управленски цели минават през сметка 302, но не са под "контролиран склад" и се отписват в края на периода по пътни листи, трябва ли да се кодират по NC8/TARIC, или може да се въведе код "0"?

Отговор 62. По-точно е най-напред да се разграничат две различни неща, които въпросът смесва. Кодът по NC8_TARIC е класификационен код в подсекция Products, а стойност "0" е изключение, предвидено за ProductCode в реда на покупната фактура при определени хипотези. В Приложение № 3 е посочено, че в Products стоките и услугите задължително се обвързват със съответстващ код от номенклатура NC8_TARIC, а при месечно подаване в тази подсекция се включват всички стоково-материални запаси и услуги, които са в счетоводната отчетност на задълженото лице през периода.
Стойност "0" не е общо решение за стоки, които не се държат във физически склад. Тя е изрично допустима в PurchaseInvoices само за директно разходвани покупки и за текущи разходи за периода, при които не се изисква подаване на данни в MasterFiles/Products. Именно за тези случаи Приложение № 3 допуска в реда на покупната фактура да не се посочва код на продукта от системата на лицето и в ProductCode да се подаде "0", заедно с описателен текст.
Затова при така описаната от Вас организация не е достатъчно основание да се приеме, че може автоматично да се работи с код "0" само защото няма "контролиран склад". Ако гумите и горивата минават през сметка 302 и се отписват едва в края на периода по пътни листи, това означава, че през периода те присъстват в счетоводната отчетност като материален обект, а не като разход, отчетен директно в момента на покупката. В такава хипотеза по-нормативно точният подход е те да се третират като продуктови позиции в слоя Products, с вътрешен ProductCode, мерна единица и съответстващ код по NC8_TARIC, а в PurchaseInvoices да се използва този вътрешен продуктов код, а не "0". Липсата на физически склад сама по себе си не променя този извод.
Само ако организацията е устроила тези покупки като действително директно разходвани в момента на покупката или като текущ разход за периода, за който не се поддържа продуктова номенклатура в MasterFiles/Products, би могло да се приложи изключението с ProductCode = "0" в PurchaseInvoices. Следователно решаващият критерий не е дали материалът стои във физически склад, а дали за периода той участва в счетоводната отчетност като стоково-материален запас, за който следва да има продуктова позиция. При описаната във въпроса фактическа постановка по-точният и по-защитим отговор е: не следва автоматично да се въвежда код "0"; ако гумите и горивата минават през сметка 302 и се отписват по-късно, те следва да бъдат обхванати като продукти и съответно да бъдат обвързани с код по NC8_TARIC. Този извод е съобразен с действащите публикувани от НАП версии на Приложение № 2 и Приложение № 3.

Въпрос 63. При голям брой напълно амортизирани, но продължаващи да се използват дълготрайни активи, необходимо ли е за всеки отделен актив да се прави нова оценка или промяна на срока на полезния живот? Как се отразява това в Баланса, как се третират основните ремонти на сградите и необходимо ли е към 31.12.2025 г. да се определя възстановимата стойност на всеки актив?

Отговор 63. Не. Нито SAF-T, нито националните счетоводни стандарти налагат автоматично към 31.12.2025 г. масова индивидуална преоценка на всеки напълно амортизиран актив и механична промяна на счетоводния амортизационен план за всеки актив с нулева балансова стойност. По НСС по-точният фокус е върху периодичния преглед на полезния срок на годност и амортизационната политика, а по СС 36 – върху годишна преценка за наличие на условия за обезценка и, при необходимост, определяне на възстановимата стойност. След първоначалното признаване активите по СС 16 по правило се отчитат по цена на придобиване, намалена с начислените амортизации и натрупаната загуба от обезценка.
Този въпрос обаче не следва да се чете само нормативно. В контекста на SAF-T той има и втори, аналитичен пласт. В представените проект на ЗИД на ЗДДС (от 2024 година) и мотиви към него вече е била формулирана изрична идея данните за наличните дълготрайни активи и материални запаси да се използват за проследяване на равнището и изменението на активите и за показателя "рентабилност" на база активи. Това е много силен сигнал за посоката на бъдещия аналитичен прочит, дори когато към момента няма формализиран публичен списък от такива показатели.
Именно затова прекомерно бързата счетоводна амортизация, особено когато по съображения за удобство следва данъчната, може да се окаже лошо решение. Когато болницата работи с голям брой медицинска техника, апаратура и сгради, които реално се използват, но вече стоят с нулева балансова стойност, активната база в баланса се изтънява, а рентабилността на активите може да изглежда изкуствено висока. При нова инвестиция, капитализация на значителен ремонт или въвеждане на нова апаратура същият показател може да падне рязко, без икономическата ефективност на дейността действително да се е влошила. Това показва, че наличието на много напълно амортизирани, но използвани активи могат да направят показателите на база активи аналитично подвеждащи.
Поради това при масив от над 7 000 актива по-защитимият счетоводен подход не е всеки отделен актив с нулева балансова стойност да минава автоматично през нова индивидуална оценка. По-правилно е да се направи структуриран преглед по групи сходни активи и по същественост – например медицинска апаратура, лабораторна техника, сгради, съоръжения – и да се прецени дали счетоводните полезни срокове и амортизационната политика отразяват реалната икономическа употреба. Там, където регулаторната рамка и договорите за абонаментна поддръжка обективно удължават фактическата употреба, това следва да бъде отразено в политиката занапред и в документацията към нея, а не чрез формално "връщане" на стойност на всеки занулен актив.
По отношение на Баланса е важно да се направи едно разграничение. Самата промяна на полезния срок при вече напълно амортизиран актив не възстановява автоматично балансова стойност. Балансът се променя, когато има последващи разходи, които носят бъдещи икономически изгоди над първоначално оценената стандартна ефективност на актива, тоест когато е налице основание за капитализация. Затова при сградите решаващ е икономическият смисъл на разхода: текущият ремонт остава разход за периода, а основният ремонт или подобрението се капитализира към сградата или като отделен компонент/актив според приетата счетоводна политика.
SAF-T прави тази политика значително по-видима. В месечния файл амортизационният разход се вижда в счетоводните записвания, а в годишния файл за активи се виждат самите активи и движенията по тях – полезен срок, метод, натрупана амортизация, балансова стойност, подобрения и други движения. Именно затова SAF-T не създава ново задължение за преоценка, но дава много по-добра възможност да се прочете дали политиката по активите е последователна и дали съотношенията на база активи са икономически логични.
Следователно към 31.12.2025 г. не е необходимо да се възлага нова оценка на възстановимата стойност на всеки отделен актив само заради SAF-T. Необходим е годишен преглед по правилата на обезценката и разумен, документиран преглед на амортизационната политика, особено там, където счетоводната амортизация е била механично доближавана до данъчната. В контекста на SAF-T по-важният въпрос не е дали има активи с нулева балансова стойност, а дали активната база в счетоводството представя вярно използвания капацитет и не изкривява показатели като рентабилност на база активи. Именно в тази посока следва да се чете и този въпрос за лечебните заведения.

Въпрос 64. Как се подава информация за материални запаси при поискване, когато материалите са вложени в производство?

Отговор 64. При този режим не се подава само счетоводният резултат от влагането, а наличностите и движенията на материалните запаси за периода, определен от органа по приходите. По действащия публикуван от НАП формат при поискване се подават подсекциите PhysicalStock и MovementofGoods, а в MovementTypeTable изрично са предвидени движения като покупка, продажба, брак и влагане в производството. Това означава, че влагането в производство се отчита като движение на запас, а не само като счетоводно отнасяне към производство.
В практическо отношение материалът следва да се подаде в MovementofGoods като конкретно движение за съответния ProductCode, с дата, вид на движението, счетоводна сметка, количество, мерна единица и останалите идентифициращи данни, които структурата изисква за проследимост на движението. Логиката на тази подсекция е да покаже количествената и стойностната следа на производствения процес през периода, поради което не е достатъчно да се подаде само обща стойност на вложените материали по счетоводни сметки.
Ако към края на искания период има незавършено производство, то не следва да остава невидимо в слоя на наличностите. В официалната структура на PhysicalStock е предвидено WarehouseID да обхваща не само складове, но и производствени помещения и площадки с незавършено производство, а номенклатурата за ProductType включва отделен вид материален запас за "незавършено производство". Следователно, когато системата поддържа количествена отчетност за незавършеното производство, то следва да се покаже като наличност в съответната производствена локация и със съответния вид запас.
Когато от вложените материали през същия период се получава продукция или полуфабрикат, логиката на файла позволява да се види и резултатът от производството като отделна запасова позиция с правилната й класификация. Затова при производствените предприятия файлът при поискване следва да прави видими едновременно намалението на материалите като вход към производството и, когато е приложимо, наличностите на продукция или незавършено производство в края на периода.
Следователно най-точният извод е следният: когато материалите са вложени в производство, SAF-T при поискване не се подава като една обща счетоводна сума за производство. Подават се конкретните движения по материалните запаси, а когато е приложимо – и наличностите на незавършено производство или продукция, така че количествената история на запасите да бъде проследима и проверима.

Въпрос 65. Ако НАП не приеме SAF-T файла поради грешка, предоставя ли информация каква е грешката?

Отговор 65. Да, но тук е важно да се разграничат две различни ситуации. Първата е файлът изобщо да не бъде приет на етап подаване, когато не е във формат XML, името му не отговаря на конвенцията за съответния вид файл или не е подписан с квалифициран електронен подпис. Втората е файлът да бъде подаден и да получи входящ номер, а след това да бъде отхвърлен при валидациите по XSD схемата и при проверките за валидност и консистентност на подадената информация. Именно във втората хипотеза НАП изрично предвижда, че чрез електронната услуга на лицето се предоставя информация за установените грешки.
По действащата версия 1.0.1 на Приложение № 3, когато при валидирането бъдат установени несъответствия, се предоставя 7-дневен срок за отстраняването им чрез подаване на нов файл. Ако несъответствията не бъдат отстранени в този срок, стандартният одитен файл се счита за неподаден. Същевременно е направено и едно важно уточнение: този 7-дневен срок не се прилага за файловете, подадени в специалните срокове по чл. 71к, ал. 6 ДОПК и § 17, ал. 2 от ПЗР към Закона за държавния бюджет на Република България за 2025 г., за които важат специалните срокове, посочени в съответните норми.
Следователно най-точният извод е следният: да, при отхвърляне на файла НАП предоставя информация за грешките, но това се случва след етапа на подаване, в рамките на последващата валидация на файла. Затова в практиката трябва ясно да се различава "файлът не се приема" поради формален проблем от "файлът се отхвърля" поради грешки в структурата, съдържанието или логическата съгласуваност на данните.

Въпрос 66. Коригиращият SAF-T файл подава ли се само с разликите или с цялата информация за месеца?

Отговор 66. Коригиращият SAF-T файл не се подава само с разликите. По действащата уредба корекцията се извършва чрез подаване на нов файл за съответния период, а при подаване на корекция се подава цялата информация съгласно утвърдената структура на файла и правилата за подаването му. Това означава, че когато се коригира месечен SAF-T, се подава нова пълна версия на файла за съответния месец, а не само поправените записи.
Същата логика личи и от правилото, че в срока за подаване може да се подаде повече от един файл за един и същ период, като за редовно подаден се счита последният успешно подаден и приет от НАП файл. Следователно периодът не се "допълва" с отделни частични корекции, а се чете чрез последната валидна цялостна версия за съответния период. Именно затова корекцията е ново подаване на целия файл, а не подаване само на разлика.
Практическият извод е следният: ако се установи грешка в месечния файл, не се изпраща само коригираният ред, документ или секция, а се генерира и подава отново целият SAF-T за съответния месец в коригиран вид. Това е и причината управлението на версиите да бъде толкова важно при подготовката на SAF-T.

Въпрос 67. При подготовка на SAF-T файл за клиенти с международна ERP система възникват три практически въпроса: как се отразяват анулирани фактури в различни хипотези, как се подава ВОП в SourceDocuments и кой е първият срок за подаване при лице, за което задължението възниква от 01.01.2026 г.

Отговор 67. По първия въпрос следва да се изхожда от това, че секция SourceDocuments се попълва по правилата на ЗДДС и ППЗДДС, тоест по логиката на данъчния документ, а не само по логиката на счетоводния журнал. Затова, когато анулираната фактура съществува като документ и се отразява в дневника по ЗДДС със стойност нула, тя следва да присъства и в съответната подсекция на SourceDocuments, макар за нея да няма самостоятелен счетоводен запис. В GeneralLedgerEntries не следва да се създава изкуствена транзакция, ако такава реално няма. Ако ERP системата пази анулирания документ без редове, техническото решение трябва да осигури структурно валиден документ с нулев ефект, без да се създава несъществуващ данъчен или счетоводен резултат. Когато обаче има анулирана и анулираща фактура и в счетоводството са налице два записа, в GeneralLedgerEntries следва да се подадат и двата, така както са осчетоводени. В SourceDocuments по-проследимият подход е да се запази и двойната документна следа, дори когато външният номер е един и същ, чрез различни вътрешни системни идентификатори. Ако данъчният регистър реално пази само един нулев документен запис, SourceDocuments следва именно този документен модел.
По втория въпрос, при ВОП водещият документ в SourceDocuments е протоколът, тъй като именно той е документът, чрез който доставката се отразява за целите на ЗДДС. Поради това протоколът не следва да остава само в GeneralLedgerEntries. Действащите указания обаче допускат освен протокола в PurchaseInvoices да се подаде и фактурата, във връзка с която е издаден той. В този случай при фактурата се посочват кодове за неприложимост в TaxInformation, а артикулите се показват при фактурата, не при протокола. Следователно най-точният извод е, че при ВОП протоколът е задължителната документна следа в SourceDocuments, а фактурата може да бъде подадена допълнително, когато организацията държи да запази и фактурния слой.
По третия въпрос следва да се направи едно важно уточнение. Ако се касае за лицата от първата група по § 17 от преходните и заключителните разпоредби към Закона за държавния бюджет на Република България за 2025 г., за които задължението за подаване на SAF-T възниква от 01.01.2026 г., шестмесечният период по чл. 71к, ал. 5 ДОПК не се прилага според официално публикуваните разяснения на НАП. Следователно за тези лица първият месечен SAF-T е за отчетния период януари 2026 г. и се подава до края на февруари 2026 г. Различна е хипотезата за лицата, за които чл. 71к, ал. 5 ДОПК е действително приложим. При тях първото редовно месечно подаване е за седмия месец след възникването на задължението.

Въпрос 68. Има софтуери, които позволяват корекции на стари месеци – например корекция за април, направена през септември, която попада в опис за април. В тези ситуации как се процедира в SAF-T?

Отговор 68. Тук трябва да се разграничат две различни ситуации. По публикуваните от НАП указания, когато счетоводна грешка е открита през текущия отчетен период или през следващ отчетен период, тя се коригира през периода, в който е установена, съобразно приложимите счетоводни стандарти и счетоводната политика на предприятието. В тези случаи в подавания файл за текущия период в GeneralLedgerEntries се попълва SystemEntryDate като реалната дата на въвеждане на записа в счетоводната система, а GLPostingDate – като дата в периода, за който се отнася осчетоводяването. По същия ред се отразяват и счетоводни записи, направени през текущия период, които се отнасят за предходен период.
Отделна е хипотезата, при която не просто се осчетоводява корекция през септември, а вече подадената картина за април се променя назад, защото самият априлски период е отворен повторно и регистърът за него е изменен. Тогава корекцията на SAF-T не се прави чрез подаване само на разликата, а чрез нов файл за съответния период, който съдържа цялата информация съгласно утвърдената структура на файла. Следователно, ако през септември реално се променя вече подаденият априлски период, следва да се подаде нов пълен файл за април, а не частична корекция.
Тази възможност за връщане назад обаче не е неограничена. Приложение № 3 изрично предвижда, че корекция на подаден файл се извършва чрез подаване на нов файл за съответния период и че за вече подадените месеци се прилага намаляващ корекционен прозорец по чл. 71к, ал. 6 ДОПК, а за лицата по § 17 от преходните и заключителните разпоредби на Закона за държавния бюджет за 2025 г. действат специалните срокове.
Следователно при пример с корекция за април, направена през септември, решаващо е не какво позволява ERP системата, а как счетоводно е отразена корекцията. Ако грешката е установена и осчетоводена през септември като текуща корекция, тя се показва в текущия SAF-T файл с реална SystemEntryDate за септември и GLPostingDate към периода, за който се отнася. Ако обаче през септември се променя вече подаденият априлски период, следва да се подаде нов пълен файл за април, стига срокът за корекция на този период да не е изтекъл. Това е нормативно по-точният и практически по-защитим подход.

Въпрос 69. Трябва ли да се включва в репорта счетоводна операция, която е сторнирана в текущия месец? Тоест двата документа трябва ли да присъстват в справка GeneralLedgerEntries?
Отговор 69. По-точно е тук да се говори не за "два документа", а за две счетоводни операции. В секция GeneralLedgerEntries се подават всички счетоводни операции, направени през отчетния период, така както са записани в счетоводната система, докато документният слой е отделно в секция SourceDocuments. Поради това, когато първоначалният запис и сторниращият запис са осчетоводени в един и същ отчетен месец, и двата следва да присъстват в GeneralLedgerEntries. Сторнирането не заличава първоначалната операция от одитната следа, а се подава като отделно счетоводно събитие със собствена дата и собствен счетоводен ефект.
Не е напълно точно обаче да се каже безусловно, че "и двата документа винаги трябва да присъстват в текущия месец". Ако първоначалната операция е осчетоводена в предходен месец, а сторнирането е осчетоводено в текущия месец, в текущия месечен SAF-T по правило ще се види сторниращият запис, а първоначалният запис ще остане във файла за предходния период. Само ако предприятието отвори предходния период назад и промени вече подадената счетоводна картина за него, възниква необходимост от нов файл за съответния месец. Именно затова в SAF-T са важни SystemEntryDate и GLPostingDate, които показват кога записът е въведен в системата и към кой счетоводен период е отнесен.
Следователно най-точният извод е следният: ако и първоначалната операция, и сторнирането са в рамките на един и същ отчетен период, и двете се подават в GeneralLedgerEntries. Ако първоначалната операция е в предходен период, а сторнирането е в текущия, в текущия файл се подава сторниращият запис, а първоначалният остава в предходния файл, освен ако не се подава коригираща нова версия за този по-ранен период. Това е по-нормативно точният и практически по-защитим прочит на въпроса.

Въпрос 70. Често срещано в практиката е получаването на фактури за предходен месец, например фактура, получена през септември, с дата от месец април. Как следва да се коригират данните за предходния период в SAF-T?

Отговор 70. Не всяка фактура с дата от предходен месец води автоматично до корекция на вече подадения SAF-T за този месец. По действащата публикувана от НАП рамка решаващо значение има не само датата на документа, а начинът, по който операцията е отразена в счетоводството. Именно затова в GeneralLedgerEntries се използват едновременно SystemEntryDate и GLPostingDate: първата дата показва кога записът е въведен в счетоводната система, а втората – към кой отчетен период е отнесен счетоводно.
На практика трябва да се разграничат две хипотези. Ако фактурата е получена и осчетоводена през септември, без предприятието да връща назад априлския период, тя не налага сама по себе си нов файл за април, а се вижда в текущия файл според начина, по който е включена в счетоводството. Ако обаче периодът бъде отворен назад и осчетоводяването бъде отнесено към април, тогава вече подадената картина за април се изменя и възниква необходимост от коригиращо подаване за този месец. В официалните указания на НАП изрично е предвидено, че когато през текущия период се правят записи, които се отнасят за предходен период, в текущия файл се посочва реалната дата на въвеждане в SystemEntryDate, а в GLPostingDate – дата в периода, за който се отнася осчетоводяването.
Когато се прави корекция на вече подаден период, не се подава само разликата, а нов пълен файл за съответния месец. Това коригиращо подаване е допустимо само в рамките на корекционния прозорец по чл. 71к, ал. 6 ДОПК и приложимите специални срокове. Извън този прозорец предходният период не се подава отново, а закъснелият или коригиращият запис остава видим в текущия файл чрез правилното разграничение между SystemEntryDate и GLPostingDate. Следователно най-точният извод е, че при късно получена фактура първо се гледа счетоводното й отразяване, а едва след това се преценява дали е необходим нов файл за стария период.

Въпрос 71. Има случаи на автоматични счетоводни обработки, които генерират хиляди редове операции, които при нужда от корекция се изтриват и генерират отново. Ако тази корекция се наложи да се направи след няколко месеца, как трябва да се процедира?

Отговор 71. В тази хипотеза решаващо значение има не това, че ERP системата технически изтрива и генерира отново голям масив редове, а дали вече подаденият счетоводен период се променя назад. По режима на SAF-T, когато се коригира подаден период, не се подава само разликата, а нов пълен файл за съответния месец. Корекцията на подаден файл се извършва чрез подаване на нов файл за съответния период, а подаденият период се чете чрез последната успешно приета версия. Следователно, ако старият месец бъде отворен отново и корекцията попада в допустимия срок по чл. 71к, ал. 6 ДОПК, следва да се подаде нова цялостна версия на SAF-T за този месец с коригираната картина на периода.
Оттук следва и едно важно уточнение. Не е непременно вярно, че НАП винаги ще "вижда" едновременно първоначалния и повторно генерирания масив редове само защото системата технически ги е изтрила и създала наново. Ако корекцията е реализирана като сторно и ново осчетоводяване, и двете операции ще бъдат видими като част от счетоводната следа. Ако обаче историческият период е регенериран назад и е подадена нова пълна версия, от гледна точка на SAF-T решаваща е последната валидна версия на периода. Поради това чисто техническият механизъм в ERP не бива да се смесва със счетоводния модел на корекция.
Ако корекцията се налага след няколко месеца и периодът вече не следва да се променя назад, подходът е различен. Публичните указания на НАП приемат, че открити счетоводни грешки през текущия отчетен период или в следващ отчетен период се коригират през периода, в който е установена грешката. В тези случаи в GeneralLedgerEntries следва да се попълни SystemEntryDate като реалната дата на въвеждане на коригиращия запис, а GLPostingDate – като дата в периода, за който се отнася осчетоводяването. Следователно извън допустимия корекционен прозорец не се подава отново старият месец, а в текущия файл се отразяват действителните коригиращи записи с правилното двойно датиране.
Практическият извод е следният: при масови автоматични обработки корекцията не трябва да се мисли като "изтриване и ново генериране на XML", а като управление на версията на периода. В рамките на корекционния срок се подава нов пълен файл за стария месец. Извън него се подават текущите коригиращи записи, така както са осчетоводени, с ясно разграничение между датата на въвеждане и датата на счетоводното им отнасяне. Това е нормативно по-точният и практически по-защитим подход.

Въпрос 72. Ако разполагаме с информация на тримесечна база, която се осчетоводява при получаването й, разпределена по съответните месеци, за кой отчетен период следва да бъде включена в доклада SAF-T?

Отговор 72. По-точно е да се каже, че в SAF-T решаващо значение има не това, че информацията е получена на тримесечна база, а начинът, по който е отнесена в счетоводството. Водещи са периодът и датата на осчетоводяване, тоест Period, PeriodYear и GLPostingDate, а SystemEntryDate показва кога записът действително е въведен в системата. Следователно тримесечният характер на първичната информация сам по себе си не определя отчетния период на подаване.
По официалните разяснения на НАП, когато информацията е въведена през текущия месец, но се отнася за предходен счетоводен период, тя се подава в текущия месечен файл, като в Period, PeriodYear и GLPostingDate се посочва предходният период, за който се отнася осчетоводяването. Това означава, че ако например информацията е получена и въведена през април, но счетоводно е разпределена за януари, февруари и март, по общото правило тя ще се вижда в текущо подавания файл, а в самите счетоводни записи ще бъдат показани съответните месеци, към които е отнесена.
Само ако предприятието реши да отвори назад вече подадените месеци и да промени самата подадена картина за тях, възниква необходимост от коригиращи файлове за съответните периоди. В този случай корекцията не се прави с разлики, а чрез подаване на нов пълен файл за съответния месец, в рамките на допустимия корекционен режим.
Следователно най-точният извод е следният: ако тримесечната информация е получена сега и сега е осчетоводена, но е разпределена по предходни месеци, тя по правило се включва в текущо подавания SAF-T файл, като предходните месеци се показват чрез Period, PeriodYear и GLPostingDate. Коригиращи файлове за отделните месеци са необходими само когато организацията променя назад вече подадените периоди.

Въпрос 73. Ако има закъсняла фактура с дата април, получена през септември, и разходът се отнася за април, необходимо ли е да се подава корекция на SAF-T за април?

Отговор 73. Не непременно. Решаващо е не само каква е датата на фактурата, а как събитието е отразено в счетоводството и дали вече подадената картина за април се променя назад. По официалните указания на НАП, когато информацията е въведена през текущия месец, но се отнася за предходен счетоводен период, тя се подава в текущия месечен файл, като в GeneralLedgerEntries се посочват реалната дата на въвеждане в SystemEntryDate и дата в предходния период в GLPostingDate. Това означава, че ако фактурата е получена и осчетоводена през септември, без априлският период да се отваря назад, тя по правило не налага нов файл за април, а се вижда в текущо подавания файл с ясно разграничение между момента на въвеждане и периода, към който се отнася осчетоводяването.
Корекция на SAF-T за април е необходима тогава, когато предприятието действително промени назад вече подадения априлски период, тоест когато осчетоводяването бъде отнесено така, че да измени главната книга и отчетната картина за април. В този случай корекцията не се прави чрез подаване само на разликата, а чрез нов пълен файл за съответния период. Именно затова въпросът не е само "има ли закъсняла фактура", а "променя ли се вече подаденият период".
Следователно най-точният извод е следният: ако фактурата е включена счетоводно през септември и април не се отваря назад, корекция на априлския SAF-T не е необходима. Ако обаче счетоводният период е върнат към април и подадените вече данни за този месец се изменят, следва да се подаде нов файл за април, стига това да е допустимо в рамките на приложимия корекционен режим.

Въпрос 74. Каква е разликата между GLPostingDate и TransactionDate?

Отговор 74. В секция GeneralLedgerEntries тези две дати не дублират една и съща информация. TransactionDate е датата на документа или на самата транзакция като стопанско събитие, а GLPostingDate е датата на осчетоводяване. В табличната структура на файла TransactionDate е описана като "дата на документа/транзакцията", а GLPostingDate – като "дата на осчетоводяване". Публикуваните от НАП разяснения допълват, че в GLPostingDate се посочва дата в периода, за който се отнася осчетоводяването.
Следователно TransactionDate отговаря на въпроса кога е възникнало или е документирано събитието, а GLPostingDate – към кой счетоводен период е отнесен неговият ефект в Главната книга. Именно затова двете дати много често съвпадат, но не са длъжни да съвпадат. Ако документът е осчетоводен по собствената си дата, разлика няма. Ако обаче има начисление, приключвателна операция, закъснял документ или друга ситуация, при която датата на събитието и датата на счетоводното отнасяне не са една и съща, двете полета трябва да покажат тази разлика, а не да бъдат уеднаквявани формално.
Най-практичното разграничение е следното. TransactionDate пази хронологията на самото събитие. GLPostingDate пази счетоводната периодизация. Ако например първичният документ е от 04.01.2026 г., а счетоводният ефект е отнесен към 31.01.2026 г., тогава TransactionDate ще бъде 04.01.2026 г., а GLPostingDate – 31.01.2026 г. Именно така SAF-T прави видима разликата между събитието и счетоводното му отражение.
Полезно е да се има предвид и още нещо. Тези две дати не бива да се смесват със SystemEntryDate. TransactionDate показва кога е събитието, GLPostingDate – кога е отнесено счетоводно, а SystemEntryDate – кога записът е въведен в системата. Точно тази тройна логика позволява да се разчетат коректно закъснели документи, последващи корекции и операции по приключване на периода.
Следователно най-точният извод е следният: TransactionDate е дата на събитието или документа, а GLPostingDate е дата на счетоводното му отнасяне. Първата носи хронологията на стопанския факт, а втората – неговата периодизация в счетоводството.

Въпрос 75. По отношение на 6-месечния гратисен период, предвиден в чл. 71к, ал. 5 ДОПК, касае ли той и предприятията от първата група, за които задължението за подаване на SAF-T възниква от 01.01.2026 г.?

Отговор 75. По действащото официално тълкуване на НАП – не. Вярно е, че чл. 71к, ал. 5 ДОПК по принцип предвижда, че при първоначално възникване на задължение по чл. 71з лицата не подават стандартен одитен файл за данъчни цели за първите шест месеца. В публикуваните от НАП въпроси и отговори обаче изрично е посочено, че когато етапите на възникване на задълженията за подаване на SAF-T са регламентирани в § 17 от преходните и заключителните разпоредби към Закона за държавния бюджет на Република България за 2025 г., разпоредбата на чл. 71к, ал. 5 ДОПК не се прилага.
Следователно за предприятията от първата група, за които задължението възниква от 01.01.2026 г., първият месечен SAF-T е за отчетния период януари 2026 г. НАП изрично посочва, че за тези лица първият файл следва да се подаде до края на месец февруари, вторият – до края на месец март и т.н. Тъй като по общото правило на ДОПК, когато срокът изтича в неприсъствен ден, той изтича в първия следващ присъствен ден, практически това означава първия присъствен ден след края на февруари 2026 г.
Следователно най-точният извод е следният: за първата група задължени лица не се прилага 6-месечен гратисен период. За тях не се изчакват шест месеца, а се подава първият месечен SAF-T за януари 2026 г. в законовия срок за този период.

Въпрос 76. Ако за дадено лице е приложим шестмесечният период по чл. 71к, ал. 5 ДОПК, могат ли при първото редовно подаване да бъдат изискани отделни месечни SAF-T файлове и за предходните шест месеца?

Отговор 76. Не. Когато шестмесечният период по чл. 71к, ал. 5 ДОПК е действително приложим, за първите шест месеца не се подават месечни SAF-T файлове. Самата разпоредба е формулирана като период на неподаване, а не като отсрочка на задължението за същите файлове. Поради това тези шест месеца не следва впоследствие да се "наваксват" чрез подаване на отделни месечни файлове със задна дата.
Тук следва да се направи и едно важно уточнение. За лицата по § 17 от преходните и заключителните разпоредби към Закона за държавния бюджет на Република България за 2025 г. шестмесечният период по чл. 71к, ал. 5 ДОПК не се прилага според официално публикуваните от НАП разяснения. Следователно хипотезата за първо редовно подаване след шест месеца не е относима към първата група лица, за които задължението възниква от 01.01.2026 г.; за тях първият месечен файл е за януари 2026 г. и се подава до края на февруари 2026 г.
Следователно най-точният извод е следният: ако чл. 71к, ал. 5 ДОПК е приложим за конкретното лице, първите шест месеца не се подават и не се изискват впоследствие като отделни месечни SAF-T файлове. Ако обаче лицето попада в етапите по § 17, въпросът за този шестмесечен период изобщо не се поставя по същия начин, защото за тези лица важи специалният режим, изрично разяснен от НАП.

Въпрос 77. Първото подаване на месечния файл за януари 2026 г. следва ли да се извърши до края на февруари 2026 г.? ДДС декларациите ще продължат ли да се подават регулярно?

Отговор 77. Да. За лицата, за които задължението за подаване на SAF-T възниква от 01.01.2026 г., първият месечен файл е за януари 2026 г. НАП изрично посочва, че за тези лица първият файл се подава до края на февруари 2026 г., вторият – до края на март и така нататък. Тъй като 28.02.2026 г. е неприсъствен ден, по общото правило на ДОПК срокът изтича в първия следващ присъствен ден, тоест на 02.03.2026 г.
Подаването на SAF-T не отменя справка-декларацията и отчетните регистри по ЗДДС. Към момента НАП продължава да посочва, че всички регистрирани по ЗДДС лица подават справка-декларация, а заедно с нея и отчетните регистри. Следователно при действащата уредба задължението за SAF-T и задълженията по чл. 125 ЗДДС се изпълняват паралелно.
Следователно най-точният извод е следният: първият месечен SAF-T за януари 2026 г. се подава до края на февруари 2026 г., а на практика – до 02.03.2026 г., и това не променя редовното подаване на справка-декларацията и дневниците по ЗДДС.

Въпрос 78. Като счетоводител, необходимо ли е да познавам+ всички подробности за SAF-T? Не е ли редно доставчикът на счетоводен софтуер да подготви всичко, а аз само да натисна едно копче за експорт?

Отговор 78. Не е необходимо счетоводителят да познава в технически детайл XML структурата, XSD схемата и начина на системното генериране на файла. Техническата реализация на SAF-T действително е работа на счетоводния софтуер и на екипа, който го поддържа. Това личи и от официалната база на НАП, която е предназначена едновременно в помощ на предприятията и на разработчиците на счетоводен софтуер, както и от предвидената възможност за автоматизирано подаване чрез свързване система–система през API.
Но не е точно да се мисли, че ролята на счетоводителя се изчерпва с едно натискане на бутон. По правилата на Приложение № 3 файлът се подава за задълженото лице, подписва се от потребителя, който извършва подаването, а при грешки именно на лицето се предоставя информация за установените несъответствия и срок за отстраняването им. Това показва, че софтуерът е инструментът, но отговорността за правилността, пълнотата и обяснимостта на данните остава при организацията и при нейния счетоводен процес.
Поради това най-точният практически отговор е следният: счетоводителят не трябва да бъде програмист, но трябва да разбира логиката на SAF-T. Нужно е да знае кои данни влизат във файла, кои секции са относими за конкретното предприятие, как се срещат документният и счетоводният слой, кога се подава месечен, годишен или файл при поискване и как да разчете върнатите грешки на счетоводен език. Именно затова подготовката за SAF-T не започва от последния бутон за експорт, а от номенклатурите, идентификаторите, правилата за периодизация и съгласуването между източниците в системата.
Следователно редно е доставчикът на софтуера да осигури технически годен и максимално автоматизиран експорт, а счетоводителят да осигури правилни, последователни и защитими данни. В SAF-T техническата част може да бъде силно автоматизирана, но счетоводната логика не може да бъде изцяло възложена на софтуера. Това е и най-точният баланс между ролята на системата и ролята на професионалната счетоводна преценка.

Въпрос 79. Единствено ли на база разделението на големи, средни и малки предприятия и годините, в които влизат в сила изискванията, се определя задължението за подаване на SAF-T? Има ли допълнителни изисквания, свързани с Наредба № Н-18? Например, ако дружеството има електронен магазин, продава онлайн, изпраща с куриер и приема различни видове плащания, но не попада в критериите за първия етап, възниква ли за него задължение за подаване на SAF-T от 01.01.2026 г.?

Отговор 79. Не. По действащата уредба задължението за подаване на SAF-T не се определя само от това дали предприятието е голямо, средно или малко. Приложение № 3 изрично препраща към § 17 от преходните и заключителните разпоредби към Закона за държавния бюджет за 2025 г., където е уредено поетапното въвеждане на задължението съобразно критериите в самата норма. И официалните разяснения на НАП показват, че още първият етап от 01.01.2026 г. не е формулиран само чрез категорията на предприятието, а и чрез допълнителни показатели.
Наредба № Н-18 не променя този момент за целите на SAF-T. Тя урежда отделен режим за регистриране и отчитане на продажбите и, в определени хипотези, отделен стандартизиран одиторски файл по приложение № 38. НАП изрично посочва, че този файл се подава всеки месец от лицата по чл. 3, ал. 17 от Наредба № Н-18, тоест в рамките на специалния режим за електронни магазини с неприсъствени плащания, а не като част от режима на SAF-T по ДОПК.
Следователно самият факт, че дружеството има електронен магазин, продава онлайн, работи с куриер или приема различни начини на плащане, не поражда сам по себе си задължение за подаване на SAF-T от 01.01.2026 г. Възможно е за него да възникват отделни задължения по Наредба № Н-18, но това е различен файл, с различно правно основание, различен обхват и различна електронна услуга на НАП.
Най-точният извод е следният: дружество, което не попада в приложимия етап и критерии по § 17, не започва да подава SAF-T от 01.01.2026 г. само защото е електронен търговец или защото за него е приложим режим по Наредба № Н-18. За него задължението за SAF-T ще възникне едва когато настъпи съответният етап по § 17 за неговата категория и показатели.

Въпрос 80. Фирмата ни попада в списъка на НАП за голям данъкоплатец, съгласно заповед от 21.12.2023 г. Разбираме, че от 01.01.2024 г. сме класифицирани като "голямо предприятие", макар че към 31.12.2023 г. не попадахме в тази категория. От останалите критерии покриваме изискването за данъчни и осигурителни вноски над 3 500 000 лв. Правилно ли тълкуваме, че за нас влиза в сила прилагането на SAF-T стандарта, считано от 01.01.2027 г.?

Отговор 80. Да, по изложените факти това тълкуване е правилно. За целите на SAF-T решаващо значение има не включването в списъка на НАП за големи данъкоплатци, а това в коя група попада предприятието по § 17 от преходните и заключителните разпоредби към Закона за държавния бюджет за 2025 г. Първият етап, който започва от 01.01.2026 г., обхваща само предприятия, които към 31.12.2023 г. са големи предприятия по смисъла на чл. 19, ал. 1 от Закона за счетоводството и едновременно с това покриват поне един от двата допълнителни прага за 2023 г., включително прага за постъпления по сметки на НАП от данъци и осигурителни вноски над 3 500 000 лв.
Следователно, ако към 31.12.2023 г. дружеството не е било голямо предприятие по смисъла на Закона за счетоводството, то не попада в първия етап от 01.01.2026 г., дори да е било включено в списъка на НАП за големи данъкоплатци или от 01.01.2024 г. вече да е преминало в по-висока категория. Причината е, че нормата за SAF-T не използва критерия "голям данъкоплатец", а изрично препраща към категорията на предприятието по Закона за счетоводството към конкретната референтна дата.
За дружество в такава хипотеза ще бъде относим вторият етап, който започва от 01.01.2027 г., при условие че към 31.12.2024 г. то е голямо, средно или малко предприятие по смисъла на чл. 19, ал. 1 от Закона за счетоводството и покрива поне един от праговете за 2024 г., включително прага за постъпления към НАП над 3 500 000 лв. Ето защо, ако описаните обстоятелства са точни, задължението за подаване на SAF-T за Вас възниква от 01.01.2027 г., а не от 01.01.2026 г. Редакционно по-точно е това да се формулира чрез статуса на предприятието към 31.12.2024 г., а не чрез израза, че то е "станало голямо" от 01.01.2024 г., защото именно датите 31.12.2023 г. и 31.12.2024 г. са нормативно релевантни за двата етапа.

Въпрос 81. Задължителен ли е SAF-T за дружествата по ЗЗД и за юридическите лица с нестопанска цел?

Отговор 81. Не може да се даде един и същ отговор и за двата случая. По общото правило на чл. 71з, ал. 1 ДОПК задължени за подаване на SAF-T са предприятията по смисъла на чл. 2 от Закона за счетоводството. В чл. 2 от Закона за счетоводството изрично попадат както местните юридически лица, които не са търговци, така и неперсонифицираните дружества. Същевременно самият ДОПК предвижда и изрични изключения от това общо правило.
За дружествата по ЗЗД отговорът по принцип е да. Те попадат в категорията на неперсонифицираните дружества по чл. 2 от Закона за счетоводството, а в изключенията на чл. 71з, ал. 2 ДОПК няма специално освобождаване за предприятията по чл. 2, т. 4 ЗСч. Поради това за дружествата по ЗЗД SAF-T е приложим по общия ред, когато за тях настъпи съответният етап на въвеждане и ако не е налице някое от общите изключения, например това за микропредприятията, които не са регистрирани по ЗДДС.
При юридическите лица с нестопанска цел отговорът е по-нюансиран. Те попадат в групата на местните юридически лица, които не са търговци, тоест в чл. 2, т. 2 от Закона за счетоводството. Именно за тази група чл. 71з, ал. 2 ДОПК предвижда изключение, когато не извършват дейност по смисъла на чл. 1 от Търговския закон. Затова не е точно да се каже, че всички ЮЛНЦ са задължени да подават SAF-T. Ако конкретното ЮЛНЦ не извършва такава дейност, то остава извън обхвата. Ако обаче извършва дейност по смисъла на чл. 1 от Търговския закон, правната му форма сама по себе си не го освобождава и за него може да възникне задължение по общите правила.
Следователно най-точният извод е следният: за дружествата по ЗЗД SAF-T по принцип е задължителен, а при ЮЛНЦ задължението не зависи само от формата, а и от това дали извършват дейност по смисъла на чл. 1 от Търговския закон. Именно това разграничение е нормативно най-точно.

Въпрос 82. Счетоводител съм. IT специалистите ме питат каква информация и как трябва да преобразуват в SAF-T. Аз не разбирам от IT терминология, те – от счетоводна. Не мога ли просто да им дам справки в XLS формат, а те да подготвят SAF-T?

Отговор 82. Да, може да се работи с XLS или CSV като междинен работен формат между счетоводството и IT, но не и като краен формат за подаване към НАП. По действащия ред SAF-T се подава като XML файл по утвърдената структура, чрез електронната услуга на НАП или чрез API. Файлът не се приема, ако не е в XML формат, ако името му не отговаря на конвенцията за съответния вид файл или ако не е подписан с квалифициран електронен подпис. След подаването се извършват валидации по XSD схемата и проверки за валидност и консистентност на данните. Следователно XLS може да бъде вход към процеса, но не и самият SAF-T.
Затова въпросът не е дали може да се даде XLS, а какъв точно XLS. Ако на IT се дадат произволни справки, например обобщена оборотна ведомост, дневници по ДДС и няколко регистъра без общи ключове, те няма да могат надеждно да изградят SAF-T. Приложение № 2 неслучайно описва за всеки елемент неговия източник в счетоводните данни, режима на докладване и синтактичните и семантичните правила за валидиране. На практика това означава, че между счетоводството и IT трябва да има карта на данните: кое поле от коя справка или таблица в ERP системата захранва съответния елемент в SAF-T.
При месечното подаване IT не преобразува "една справка", а няколко взаимосвързани слоя данни: Header, MasterFiles, GeneralLedgerEntries и SourceDocuments. В MasterFiles влизат речниците – сметкоплан, клиенти, доставчици, данъчни кодове, мерни единици, продукти и, когато е приложимо, аналитичности. В GeneralLedgerEntries влизат всички счетоводни операции за периода така, както са записани в системата. В SourceDocuments влизат фактурите за продажби и покупки и плащанията. Именно затова извлеченията, които счетоводството дава на IT, трябва да пазят едни и същи устойчиви идентификатори в различните слоеве – например AccountID, CustomerID или SupplierID, ProductCode, данъчни кодове, SystemID и SourceDocumentID. Без тази повтаряемост файлът може формално да бъде сглобен, но няма да бъде надеждно съгласуван.
Практически най-добрият подход е счетоводителят да не обяснява XSD на IT екипа, а да им даде подредени изходни справки и писмено описание на счетоводния им смисъл. Това обичайно означава поне следното: справка за счетоводните сметки; справка за контрагентите; справка за данъчните кодове и мерните единици; справка за продуктите, когато са относими; журнал или главна книга по редове с TransactionID, Period, TransactionDate, SystemEntryDate, GLPostingDate, дебит, кредит и сметки; фактури за покупки и продажби по редове; плащания с техните референции към документи и контрагенти. Ако липсват такива устойчиви и нормализирани извлечения, IT ще бъде принуден да "дописва" счетоводна логика извън системата, а това е високорисково.
Следователно може да се работи с XLS, но не като със случайни справки, а като с предварително договорен междинен формат. Техническата задача на IT е да преобразува тези данни в XML по схемата на SAF-T. Счетоводната задача е да осигури правилните източници, устойчивите ключове и правилното счетоводно съдържание на полетата. Едва когато тази връзка е изчистена, "едното копче за експорт" става реалистично и надеждно.

Въпрос 83. Плащането на ДДС и мито при внос към Агенция "Митници" е над 5 млн. лв. Брои ли се това за хипотезата "постъпления по сметки на НАП от данъци и осигурителни вноски"?
Отговор 83. Не. По действащата уредба критерият е формулиран като "постъпления по сметки на Националната агенция за приходите от данъци и осигурителни вноски, намалени с възстановените суми за данъци и осигурителни вноски". Това означава, че от значение са именно постъпленията по сметки на НАП, а не всички публични плащания на предприятието изобщо.
Поради това платените суми за ДДС при внос не се включват, когато дължимият данък се превежда по сметка на Агенция "Митници". Това е изрично потвърдено и в публикуваните от НАП въпроси и отговори по SAF-T, където е посочено, че в постъпленията по сметките на НАП не се включват платените суми за ДДС по внос, тъй като този данък се превежда по сметка на Агенция "Митници".
Същият извод важи още по-силно за митото. То не само не е постъпление по сметка на НАП, но и плащането му се извършва по сметки на Агенция "Митници", която изрично поддържа отделни сметки за приходи от мита, ДДС и акциз при внос. Следователно плащанията на мито и на ДДС при внос към Агенция "Митници" не се включват при преценката на този праг.
Следователно най-точният извод е следният: за тази хипотеза се броят само нетните постъпления по сметки на НАП от данъци и осигурителни вноски. Плащанията към Агенция "Митници" за мито и ДДС при внос не участват в този критерий.

Въпрос 84. Как се подават корекции в началните салда на сметките, когато след 01.01.2026 г. се доуточнява приключването на предходната година? Не следва ли това да доведе до подаване на транзакции за предходната година?

Отговор 84. Не. Самата корекция на началните салда не превръща предходната година в период за подаване на транзакции. В месечния SAF-T началните и крайните салда се подават в MasterFiles / GeneralLedgerAccounts, а транзакциите за периода се подават в GeneralLedgerEntries. Официалната структура определя OpeningDebitBalance и OpeningCreditBalance като салда в началото на периода на файла. Поради това, когато задължението за транзакционния слой възниква от 01.01.2026 г., промяна в окончателното приключване на 2025 г. следва да се прояви като корекция на началните салда на засегнатия период от 2026 г., а не като подаване на транзакции за 2025 г.
Ако към момента на първото подаване началните салда за 01.01.2026 г. вече са окончателно уточнени, те следва да бъдат подадени още в първия файл за съответния месец. С други думи, правилният подход е първият подаден файл за 2026 г. да носи вярната начална картина към началото на периода, без да се възстановява транзакционната история на 2025 г.
Ако обаче първият засегнат месец от 2026 г. вече е подаден и след това се промени началното му салдо, по правило следва да се подаде нов пълен файл за всеки вече подаден засегнат месец, започвайки от най-ранния. Причината е, че корекцията в SAF-T не се прави с "разлика", а чрез нова версия на периода, а всяка месечна версия съдържа собствени начални и крайни салда. Затова, когато се промени началната картина на януари 2026 г., обичайно се засягат и следващите вече подадени месеци, доколкото техните начални и крайни салда са производни от същата база.
Извън допустимия срок за корекции не следва за целите на SAF-T да се "отваря" назад 2025 г. Тогава предприятието отразява разликата така, както тя е записана в счетоводството през текущия период, а следващите файлове носят вече коригираната салдова картина. Когато корекцията е реализирана чрез счетоводен запис, той се вижда в GeneralLedgerEntries със съответните дати, така че да остане ясна разликата между момента на въвеждане и периода, към който е отнесен счетоводният ефект.
Същата логика важи и когато корекцията не засяга само синтетичните салда в GeneralLedgerAccounts, а и разчетните начални салда в Customers или Suppliers. Следователно най-точният извод е следният: при промяна в окончателното приключване на предходната година не се подават транзакции за тази година само за да се "обясни" новото начално салдо. Коригира се салдовата картина на първия засегнат период от 2026 г. и, ако е необходимо, се подават нови версии на вече засегнатите месеци от 2026 г.

Въпрос 85. Земеделски производител – физическо лице, регистрирано по ЗДДС, попада ли под обхвата на SAF-T?

Отговор 85. По общото правило – не като физическо лице. За целите на SAF-T решаващият критерий е не регистрацията по ЗДДС, а дали лицето е "предприятие" по смисъла на чл. 2 от Закона за счетоводството. Чл. 71з ДОПК обвързва задължението за подаване именно с предприятията по чл. 2 ЗСч, като предвижда и изрични изключения.
Актуалният текст на чл. 2 ЗСч изброява кои са предприятия за целите на закона: търговците по смисъла на Търговския закон, местните юридически лица, които не са търговци, бюджетните предприятия, консорциумите и дружествата по ЗЗД, определени фондове и осигурителни каси, както и търговските представителства. В този кръг не са посочени физическите лица, регистрирани като земеделски производители. Поради това регистрацията по ЗДДС сама по себе си не превръща земеделския производител – физическо лице в задължено лице за SAF-T.
Тук обаче има едно важно уточнение, което често създава объркване. По чл. 29а ЗДДФЛ за физическите лица, регистрирани като земеделски производители, е предвиден специален данъчен режим, при който те прилагат Закона за счетоводството и за тази цел се приравняват на еднолични търговци. Това обаче е правило за данъчното облагане и счетоводното третиране на дохода. То не променя самостоятелно критерия на чл. 71з ДОПК, който е вързан към качеството "предприятие" по чл. 2 ЗСч. Затова по-точният нормативен прочит е, че самото физическо лице – макар и регистрирано по ЗДДС и макар да води счетоводство по този ред – не попада автоматично в обхвата на SAF-T само на това основание.
Следователно най-точният извод е следният: земеделски производител – физическо лице, регистрирано по ЗДДС, по общо правило не подава SAF-T само поради тази регистрация. Задължение за SAF-T би възникнало, ако дейността се упражнява чрез форма, която попада в чл. 2 ЗСч, например като едноличен търговец, дружество или дружество по ЗЗД, и когато настъпи приложимият за съответната категория етап на въвеждане.

Въпрос 86. Ако сме клон на чуждестранно дружество, само резултатите на клона ли се вземат предвид за определяне на вида предприятие, или се гледат резултатите на цялата група?

Отговор 86. По-нормативно точният подход е да се гледат показателите на самия клон като българско задължено лице, а не консолидираните резултати на чуждестранната група. Причината е, че за целите на Закона за счетоводството клоновете на чуждестранните търговци са изрично посочени като "предприятия" в чл. 2, а задължението за подаване на SAF-T по ДОПК е обвързано именно с предприятията по смисъла на чл. 2 ЗСч.
Категориите микро, малко, средно и голямо по чл. 19 ЗСч са уредени за предприятията. Отделно и самостоятелно законът урежда категориите на групите предприятия в чл. 21, като там изрично работи с показатели на консолидирана основа. Именно това разграничение показва, че не следва автоматично да се пренасят консолидираните показатели на предприятието майка или на международната група към клона за целите на SAF-T.
Този извод се подкрепя и от официалния формат на НАП, който идентифицира файла чрез ЕИК на задълженото лице. Следователно и на практическо равнище отправната точка е българският клон с неговата регистрация и неговата счетоводна отчетност, а не групата като консолидиран субект.
Следователно, ако клонът самостоятелно попада в приложимия етап и критерии по действащата уредба, за него възниква задължение за подаване на SAF-T. Ако не попада, самият факт, че чуждестранната компания майка или групата е голяма, не е достатъчен сам по себе си, за да възникне задължение за клона. И тук обаче следва да се имат предвид и общите изключения по чл. 71з, ал. 2 ДОПК, включително това за микропредприятията, които не са регистрирани по ЗДДС.