Въпроси и отговори във връзка с внедряването на стандартния одитен файл за данъчни цели (SAF-T)

Задължение за подаване на SAF-T и дата на възникването му:

Въпрос: Към 31.12.2023 г. представляваното от мен дружество не е голямо предприятие по смисъла на ЗСч, тъй като не отговаря на два от трите критерия посочени в чл. 19, ал. 5 от закона, а именно приходите му не превишават 100 000 000 лв. и балансовата му стойност на активите също е по-малко от 50 000 000 лв. Защо до предприятието е изпратено уведомително  писмо,  че за него възниква задължение за подаване на SAF-T от 01.01.2026 г.?

 
Отговор:
С действащата редакция на чл. 19, ал. 5 от ЗСч към 31.12.2023 г. се регламентира, че големи предприятия са предприятия, които към 31 декември на текущия отчетен период надвишават най-малко два от следните показателя:
1. балансова стойност на активите - 38 000 000 лв.;
2. нетни приходи от продажби - 76 000 000 лв.;
3. средна численост на персонала за отчетния период - 250 души. Цитираната от Вас редакция е в сила от 2024  г., с оглед на което за представляваното от Вас дружество  възниква задължение за подаване на  SAF-T от 01.01.2026 г.
 

Въпрос: Към 31.12.2023 г. представляваното от мен дружество е с показатели за голямо предприятие по смисъла на ЗСч, тъй като отговаря на два от трите критерия посочени в чл. 19, ал. 5 от закона. Защо до предприятието не е изпратено уведомително писмо, че за него възниква задължение за подаване на SAF-T от 01.01.2026 г.?

Отговор:
Съгласно чл. 20, ал. 1 от ЗСч промяна в категорията по чл. 19 се извършва, когато предприятие за последните два отчетни периода престане да отговаря на два от трите показателя за съответната категория. Категорията се променя от началото на следващия (трети) отчетен период.
Съгласно наличните в НАП данни, посочени в годишните финансови отчети на представляваното от Вас предприятие, към 31.12.2023 г. дружеството е средно предприятие по смисъла на ЗСч, тъй като няма две последователни години, в които да покрива критериите за голямо предприятие – за първи път дружеството покрива критериите в чл. 19, ал. 5 от ЗСч с показателите, които са посочени в годишния му финансов отчет към 31.12.2022 г.

Предвид гореизложеното дружеството не попада в хипотезата на т. 1 от §17, ал. 1 от ПЗР към ЗДБРБ 2025 и за него не възниква задължение за подаване на SAF-T от 01.01.2026 г.
 
 
Въпрос: Как трябва да определя категорията на представляваното от мен предприятие към 31.12.2024 г., предвид редакцията на чл. 19 от ЗСч, с която се определят нови показатели.
 
Отговор: 
С редакцията на чл. 19 от ЗСч, която е в сила от 01.01.2024 г., се регламентират нови стойности на показателите, спрямо които се определят категориите на предприятията. В §29, ал. 1 от ПЗР към Закона за изменение и допълнение на Закона за счетоводството е посочено, че предприятията определят категорията си за 2024 г. в съответствие с измененията в чл. 19 от ЗСч и съобразно показателите си към 31 декември
2023 г.
 
 
Въпрос: Според § 17, ал. 1, т. 1 от ПЗР към ЗДБРБ 2025 задължението за първоначално подаване възниква от 01.01.2026 г. за големи предприятия по смисъла на чл. 19, ал. 1 от ЗСч, ако отговарят на едно от двете условия в букви а) и б). Предприятията от обществен интерес принципно се третират като големия предприятия независимо от показателите си, но това е регламентирано в § 4 от ДР на ЗСч, а не в чл. 19. Значи ли това, че предприятие от обществен интерес, което не отговаря на критериите за голямо такова по чл. 19 от ЗСч, но в същото време нетните му приходи от продажба/постъпленията му към НАП за 2023 г. надвишават 300 млн./3,5 млн., то ще бъде задължено за първоначално подаване на файла от 01.01.2026 г.?

Отговор:

По отношение на предприятията от обществен интерес § 4, ал. 1 от ДР на ЗСч установява, че за целите на същия закон те се третират като големи предприятия, независимо от балансовата стойност на активите им, нетните приходи от продажби и средната численост на персонала. В следствие на тази норма предприятията от обществен интерес се третират като големи предприятия за целите на ЗСч, независимо дали изпълняват критериите за голямо предприятие по чл. 19, ал. 5. Определящо за действието на нормата на § 4, ал. 1 е обстоятелството  дали предприятието е такова от обществен интерес, а не дали покрива критериите за „голямо предприятие“. Това условие означава, че задълженията, които ЗСч предвижда за големите предприятия, следва да се изпълняват и от предприятията от обществен интерес. В този смисъл, приравняването на предприятията от обществен интерес към големи предприятия е само за целите и по отношение на задълженията, произтичащи от ЗСч.
Предвид посочените норми на ЗСч, предприятията от обществен интерес ще попаднат в обхвата на § 17, ал. 1, т. 1 от ПЗР към ЗДБРБ, само когато се класифицират като голямо предприятие въз основа на критериите и условията по чл. 19 и 20 от ЗСч и при условие, че изпълняват допълнителните критерии по от § 17, ал. 1, т. 1, букви „а“ и „б“ от ПЗР към ЗДБРБ 2025. Извън тази хипотеза, обстоятелството единствено, че дадено предприятие е такова от обществен интерес, не поражда за него задължение да подава стандартен одитен файл за данъчни цели от 01.01.2026 година.
 
 
Въпрос: Ще се изисква ли от чуждестранните дружества, регистрирани само по ЗДДС, да подават тази декларация?

Отговор: 
Съгласно разпоредбата на чл. 71з, ал. 1 от ДОПК, задължени лица за подаване на стандартен одитен файл за данъчни цели са предприятията по смисъла на чл. 2 от ЗСч. Чуждестранни задължени лица, които са регистрирани за целите на ЗДДС и не формират място на стопанска дейност в страната, не са предприятия по смисъла на чл. 2 от ЗСч и за тях не възниква задължение за подаване на стандартен одитен файл за данъчни цели.

 
 
Въпрос: В случай че през цялата 2023 г. дружеството е било на възстановяване на ДДС, считате ли, че възстановените суми следва да се извадят от общия размер на платените задължения, респективно – да намалят стойността на отчетените постъпления?

Отговор:
Сумата на реално възстановения на дружеството ДДС за периода 01.01. - 31.12.2023 г. попада в условието на §17, ал. 1, т. 1, буква „б“ от ПЗР на ДОПК и следва да се намали от общия размер на постъпленията по сметки на НАП за платените задължения за данъци и осигурителни вноски за посочения период.
 
 
Въпрос: Подлежат ли на включване в посочената сума прихванатите задължения, при които липсва реално плащане и движение по сметките на НАП? С други думи – третира ли се прихващането като „постъпление“ по смисъла на разпоредбата?

Отговор: 
Недължимо платени или събрани суми за данъци, задължителни осигурителни вноски, наложените от органите по приходите глоби и имуществени санкции, както и суми, подлежащи на възстановяване от НАП, съгласно данъчното и осигурителното законодателство, се прихващат от органите по приходите за погасяване на изискуеми публични вземания, събирани от НАП (чл. 128 от ДОПК). Прихващането е способ за погасяване на изискуеми и неплатени данъчни задължения и задължения за осигурителни вноски и се осъществява от органите по приходите.
Сумите, представляващи прихванати задължения, се считат за постъпления по сметки на НАП по смисъла на разпоредбата на §17, ал. 1, т. 1, буква „б“ от ПЗР на ЗБДБР 2025. Респективно, сумите с които е направено прихващането се намалява общия размер на постъпленията по сметки на НАП.

 
Въпрос: Следва ли да се отчита само моментът на плащане (независимо за кой период се отнася сумата) или е от значение и за коя година е задължението?

Отговор: 
Постъпленията по сметки на НАП за данъци и осигурителни вноски за периода 01.01. на съответната година до 31.12. на същата година, независимо за кой период се отнася задължението, се считат за ефективно внесени суми за данъци и осигурителни вноски през тази година.
 
 
Въпрос: Моля за разяснение, дали в постъпленията по сметките на НАП се включват платените суми за ДДС по внос.

Отговор: 
В постъпленията по сметките на НАП не се включват платените суми за ДДС по внос, тъй като дължимият ДДС по внос се превежда по сметка на Агенция „Митници“.
 
 
Въпрос: Дружество, задължено да подава стандартен одиторски файл от 2026 година им още няколко поделения с 13 цифрени булстати. БУЛСТАТ на основното дружество плюс още четири цифри. Към момента се водят отделни счетоводства, които регулярно се сводират на ниво хронологична и оборотна ведомости, ДДС и др., но не до толкова ниско ниво, което да позволи създаване на одиторския файл (получени, издадени фактури със съдържание, движение  на  складови запаси, където има..), тъй като те имат съсвсем различни доставчици, контрагенти и т.н. Дружеството подава общ годишен отчет! Вижда се, че в Header частта има TaxEntity, има и Сегмент, но как се ползват и дали това смисълът им, не става ясно. Какви са правилата за изготвяне на одиторския файл в такава ситуация? Може ли всяко дружество да генерира свой отделен, има ли начин за обзначаване на кого е генерирания файл, кой ще го подава, има ли начин за обединение на генерирани от подразделенията отчети в един. Как е правилно да се подходи в този случай?

Отговор: 
Съгласно изискванията на чл. 71з, ал. 1 от ДОПК задължени лица за подаване на стандартен одитен файл за данъчни цели са предприятията по смисъла на чл. 2 от ЗСч. Нормата на чл. 2, т. 1 от ЗСч регламентира, че предприятия са търговците по смисъла на ТЗ, включително клоновете на чуждестранните търговци.
Търговец е всяко лице, което по занятие извършва някои от дейностите, изброени в чл. 1, ал. 1 от ТЗ. Съгласно чл. 1, ал. 2 от ТЗ търговци са търговските дружества и кооперациите с изключение на жилищностроителните кооперации. Видовете търговци са изброени в част втора от ТЗ. Съгласно чл. 17, ал. 1 от ТЗ всеки търговец може да открие клон извън населеното място, където се намира неговото седалище. С чл. 19 от закона се регламентира, че клонът води търговски книги като самостоятелен търговец, без да съставя отделен баланс.
С оглед на горе изложеното задължение за подаване на стандартния одитен файл за данъчни цели има търговецът.
Със стандартния одитен файл за данъчни цели се подава информацията по чл. 71и от ДОПК по ред и формат определен със заповедта на изпълнителния директор на Националната агенция за приходите, издадена на основание чл. 71к от кодекса.
С чл. 53, ал. 1 от ТЗ се регламентира, че всеки търговец е длъжен да води счетоводство, в което отразява движението на имуществото на своето предприятие. Това движение се регистрира в хронологичен ред. С оглед на което търговецът следва да води счетоводство за движение своето имущество, вкл. и на това в клона и е негова отговорност да обединява, представя, декларира и оповестява информацията, съдържаща се в счетоводните регистри.

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


Въпрос: Моля да посочите кои счетоводните записвания се подават в секция GeneralLedgerEntries с месечния SAF-T – въведени в счетоводната система на предприятието до последната дата на отчетния период, за който се подава файла, или въведени до датата на създаване на файла, но отнасящи се за отчетния период?

Отговор: 
С месечния файла се подават счетоводните записи, които се отнасят за периода, който е посочен в елементи: S.SC.3 SelectionStartDate, S.SC.4 SelectionEndDate, S.SC.5
PeriodStart/ S.SC.6 PeriodStartYear, S.SC.7 PeriodEnd/ S.SC.8 PeriodEndYear, дори и да са въведени в счетоводната система след крайната дата на периода. Подават се тези счетоводни записвания, които са въведени в счетоводната система от първата дата на периода, за който се подава файла, до датата на генериране на файла.
Например:
На  10.07.2026  г. е направено осчетоводяване на документ /фактура/ с дата 15.06.2026 г., което е относимо за м. 06.2026 г., тогава в секция GeneralLedgerEntries, подсекция Transaction, във файла за м. 06.2026 г. следва да се посочат следните данни: GL.10 Period – 06; 
GL.11 PeriodYear – 2026;
GL.12 TransactionDate – 15.06.2026 г. /дата на осчетоводявания документ/;

GL.17 SystemEntryDate – 10.07.2026 г.;
GL.18 GLPostingDate – 15.06.2026 г.
 
 
Въпрос: Здравейте, моля за тълкуване на разпоредбата на § 17, ал.  2 от ПЗР към ЗДБРБ 2025 г., най- добре може да обясните с пример.
 
Отговор:
Нормата на чл. 71к, ал. 5 от ДОПК предвижда, че при първоначално възникване на задължение по чл. 71з лицата не подават SAF-T за първите шест месеца. С ал. 6 се регламентира, че след изтичането на срока по ал. 5 в подадените стандартни одитни файлове за следващите шест месеца могат да бъдат правени корекции.
В §17, ал. 2 от ПЗР към ЗДБРБ 2025 се посочва, че в случаите по ал. 1 — с която се регламентират етапите на възникване на задълженията за подаване на SAF-T, разпоредбата на чл. 71к, ал. 5 от ДОПК не се прилага, а срокът по чл. 71к, ал. 6 от ДОПК за тези лица е дванадесет месеца и започва да тече от датата на възникване на задължението за подаване на стандартен одитен файл по ал. 1.
Предвид горното срокът по чл. 71к, ал. 5 от ДОПК е приложим в случаите, когато за лицата възникне задължение за подаване на SAF-T след като преминат етапите, посочени в §17, ал. 1 от ПЗР към ЗДБРБ 2025, т.е. след 01.01.2030 г. Пример за това е микропредприятие, което се регистрира за целите на ЗДДС след 01.01.2030 г. За него задължението за подаване на SAF-T ще възникне след 01.01.2030 г., като в този случай е предвидено да може да приложи нормата на чл. 71к, ал. 5 от ДОПК и да има възможност да приведе своите системи съгласно действащите изисквания за подаване на данни със SAF-T. Това микропредприятие след това ще може да подаде коригиращи файлове за първите шест месеца, през които е подавало такива.
Предприятията, за които задължението за подаване възникне през периода от 01.01.2026 г. до 01.01.2030 г., не прилагат нормата на чл. 71к, ал. 5 от ДОПК, като след редакцията на ал. 2 от §17 от ПЗР към ЗДБРБ 2025 ще може да извършват корекции на подадените от тях файлове през първите 12 месеца. Например:

В случай че за „ХХХХХ“ ЕООД задължението за подаване на SAF-T възниква от 01.01.2026 г., дружеството следва да подава месечни SAF-T в законово определените срокове, т.е. първият файл следва да се подаде в е-услугата до края на месец февруари, вторият – до края на м. март и т.н. Подадените месечни SAF-T за периода от м. 01.2026 г. до м. 12.2026 г., вкл. и когато бъдат отхвърлени поради грешки, могат да бъдат коригирани чрез подаване на нов файл за съответния период, като крайния срок за подаване на коригиращи файлове за посочения период е до края на м. 02.2027 г.
 

Въпроси по Приложение №2 към заповедта на изпълнителния директор на НАП:


Въпрос: Ако НАП счита, че счетоводният софтуер може да импортира данни от други системи, различни от ERP, е редно това да бъде формализирано чрез разширяване на колоната „Източник на получаване на данните“ с допълнителни типове източници. Това би улеснило проследимостта и би намалило риска от грешки при деклариране.

Отговор:
Стандартния одитен файл за данъчни цели позволява информацията, която се подава с него, да е експортирана от различни софтуерни решения: системи за управление на цялостната търговска дейност; счетоводни софтуери; софтуери за управление на складовите стопанства и др.
Ако информацията във файла е генерирана от повече от един софтуер, то в заглавната структура (HeaderStructure) следва да се посочат:
- в елемент S.H.5 SoftwareCompanyName, с един запис се изброяват наименованията софтуерите;
- в елемент S.H.5 SoftwareID в един запис се посочват техните производителите/разпространители, и

- в елемент S.H.6 SoftwareVersion в един запис се посочват версиите на всички софтуери, от които е генерирана информация за създаване на файла.

Колоната „Източник на получаване на данните“ цели да насочи разработчиците на софтуери към най-вероятния източник на необходимата информация, напр. в данните за стоковите наличности е посочено: „warehouse information”.

 
Въпроси по Приложение №3 към заповедта на изпълнителния директор на НАП:


Въпрос: В приложение 3 на документацията т. 5 , относно отчетите за продажби е посочено „За тези сделки и свързаните с тях плащания не се посочват транзакционни данни, данни за клиенти, за изходни документи и за получени плащания в съответните секции на файла”. Кои са секциите и елементите от файла, в които не се подава информация? Как трябва да се подадат - оставят се празни или не присъстват във файла?.

Отговор:
Данните за доставки, за които издаването на фактура или протокол не е задължително и за които съгласно чл. 119 от ЗДДС задълженото лице съставя отчет за извършените продажби, се подават в обобщенo в:
- подсекция SalesInvoices (изходни документи) от секция SourceDocuments;
- подсекция Payments (плащания) от секция SourceDocuments;
- секция GeneralLedgerEntries (транзакционни данни).
 

Въпрос: Моля да разясните как следва да се подава информацията, която представлява банкова и застрахователна тайна, от кредитни институции и застрахователи?

Отговор:
В подаваните със SAF-T данни следва да не е налична информация, която представлява банкова или застрахователна тайна по смисъла на ЗКИ и КЗ. Тези данни следва да се подават на агрегирано/обобщено ниво.

Секция/подсекция	Задължение за издаване на ф-ра	Няма издадена фактура
GeneralLedgerEntries	индивидуализиране на всяка доставка	агрегирано
SD.SalesInvoice	индивидуализиране на всяка доставка	агрегирано
SD.PurchaseInvoice	индивидуализиране на всяка доставка	агрегирано
SD.Payments	индивидуализиране на всяка доставка	агрегирано

 

ПОДСЕКЦИЯ	ЕЛЕМЕНТ	ВЪПРОС	ОТГОВОР
Account	MF.GLA.2 AccountID	Структурата на счетоводната сметка в информационната системата е следната:   Ако сметката не е обектно ориентирана или е сметка в Централа, в полето “Обект” се поставят три звезди (***). Кодът на аналитичните признаци може да бъде число, дата или текст. Максималният брой знаци за една сметка, ако са попълнени всички елементи до допустимата дължина, е повече от 34 знака. Въпрос: При така описаната структура на счетоводната сметка кой от изброените варианти е допустим за попълването в SAF-T файла на елемент TaxpayerAccountID (Номер на сметка от информационната	Със Стандартния одитен файл за данъчни цели (SAF-T) се подaва информация за най-ниско ниво на аналитичните счетоводните сметки във воденото счетоводство от лицето, подаващо файла, мапирани към номенклатурата за сч. сметки на НАП. Информацията се подава съгласно представения от Вас Вариант 2.

		система, използвана за счетоводно отчитане от лицето) в секции GeneralLedgerAccounts и GeneralLedgerEntries? Пример: сметка 651, обект - ***, Код на признак 1 - 000001- Застраховка, а признак 2 и 3 са дата от и дата до. сметка 602, обект 001, Код на признак 1 - 000001 - Застраховки сметка 602, обект 001, Код на признак 1 – 000002 - Юридически услуги. Двата аналитични признака на сметка 602 отговарят на различни сметки от номенклатурата на НАП Вариант 1: всички сметки се подават в този елемент на файла с код на сметка, състоящ се от номер на сметка, следван от кода на обекта.   Вариант 2: сметки, в които конкретен аналитичен признак е отделна аналитична сметка от номенклатурата на НАП се подават с код на сметка, състоящ се от номер на сметката, следван от кода на обекта и кода на конкретния аналитичен признак, а останалите сметки се подават с код на сметка, състоящ се от номер на сметката и код на обект.
	MF.GLA.7 AccountType	В информационната система счетоводна сметка, която е Активна, има начално дебитно салдо и крайно кредитно салдо за подавания период.	Потвърждаваме, че данни са попълнени коректно – следва да имате предвид, че началните и крайните салда на сч. сметка, посочена в секция MasterFiles, подсекция GeneralLedgerAccounts, трябва да отговарят на

		Activе 1500.00 300.00 Въпрос: Правилно ли са попълнени данните?	дебитните и кредитните обороти на същата счетоводна сметка, посочени в секция GeneralLedgerEntries.
Customers	MF.C.2 CompanyStruct ure	Впечатление прави разликата в изискванията за информацията по колона Е. CompanyStructure. На ред 30, ИД № - MF.C.2 и съответно на ред 40 - MF.S.2 описанието по колона F не е единно. В първият случай, с колона F е предвидена „Дефиниция на структурата на компанията на клиента“ ( ред 30), в във вторият „Име и адрес на компанията“  ( ред 40). Моля, да поясните съдържанието и исканията за CompanyStructure с информацията на  ред 30, тъй като не откриваме, каква е формата на данните, които трябва да посочим. Тук трябва да се отбележи, че в базите данни за клиентските база информацията от типа CompanyStructure, т.е. ЕТ, ООД, АД или др. е част от наименованието на клиента. Ето     защо,     моля     да     потвърдите,     дали     попълването     на RegistrationNumber (референция лист 5. Structures, ИН S.C.1, ред 30) ще отговаря на изискванията за данни на ред 30, Е. CompanyStructure, на ред 30, ИД № - MF.C.2 от лист 2 . MasterFile?	Елементи MF.C.2 и MF.S.2 изискват попълването на конкретна структура  (CompanyStructure)  от  XSD-схемата  –  в  типа  на  полето (колона G) е налична препратка към нея. Информацията, която се подава със структурата на компанията, е посочена от елемент S.C.1. до елемент S.C.9. в работен лист (sheet) 5.Structures от Приложение №2 към заповедта на изпълнителния директор на НАП. Съобразно изложеното попълването няма как да бъде попълнен само елемент S.C.1. RegistrationNumber, а се изисква попълването на всички елементи, които в структурата /колона I - Режим на докладване (задължителен или незадължителен)/ са посочени като задължителни (Mandatory). Задължителни елементи, които се подават със структурата на компанията са: -              S.C.1. RegistrationNumber; -              S.C.2. Name или S.C.2.1. NameLatin (посочва се един от двата елемента алтернативно); -              S.C.3. Address – изисква попълване на структура за адрес; -              S.C.7. RelatedParty – маркер, който посочва дали контрагента е свързано лице по смисъла на ДОПК с лицето, което подава файла. -              Елемент S.C.5. TaxRegistration – задължителен за подаване при определения условия (вж. бележките в колона М).
	MF.C.3 CustomerID	Искам  да  ви  попитам  за  елемент  CustomerID/SupplierID  с какъв уникален код и логика трябва да се подава физическо лице или компания без ДДС регистрация, които не са в България, защото кодове 11 и 12 са свързани само с ДДС номера.	Когато контрагента Ви е установен в ЕС и няма активен ДДС номер, следва да се посочи с код: „14, следван от кода на държавата (съгласно ISO 3166-1 - 2 букви), следван от уникален код на икономическия оператор, присъединен от задълженото лице (обикновено генериран от информационна система).“, например 14ROXXXXXXXX, като XXXXXXXX е съответния данъчен номер (TIN) или друг номер от фирмения регистър, ако са известни на лицето, което подава файла. Ако

			на лицето, подаващо файла, не му е известен съответния номер: XXXXXXXX е номера, който е присвоен от системата. Когато контрагента Ви е установен в държава извън ЕС и няма активен ДДС номер, следва да се посочи с код: „12, следван от кода на държавата (съгласно ISO 3166-1 - 2 букви) и уникалния идентификационен код по ДДС (или друг код от официален регистър) на съответната държава, която не е нито България, нито държава-членка на ЕС - за икономически оператори от други държави, различни от България или членки на ЕС - Пример:   12TK123005284,   когато   такъв   регистрационен   номер   е наличен.“.
		Извършени са продажби към клиента до различни ДЧ, в които има клиентът има регистрация за целите на ДДС. Отразени  са  продажни  фактури  към:  RO123456…;  FR123456…; DE123456…, които са посочени в SourceDocuments.SalesInvoice.   Кой номер да се посочи в MasterFiles.Customers?	Ако за един и същи контрагент в секция SourceDocuments са подадени данни за извършени към него доставки под различни идентификатори за целите на ДДС /VIN/, присвоен в различни държави членки - в елемента (CustomerID MF.C.3) се подава информация за идентификационен номер, издаден от държавата, в която е установен клиента. В този случай структура TaxIDStructure (към която се препраща от CompanyStructure, част  от  подсекция  Customers  -  MF.C.2)  се  подава  задължително  и поотделно за всеки идентификатор за целите на ДДС на този клиент. Например: DE123456… Beta GmbH DE123456… RO123456…

			FR123456… 11DE123456… Amount >  Amount
	MF.C.5 AccountID	В информационната система може да има счетоводни записвания, които не касаят разчети с Клиенти и Доставчици, но които за целите на  управленската  отчетност  също  се  отчитат  по  контрагенти  – например, получени заеми, приходи от продажби, факторинг, лизинг и др. Въпрос: В елементи "CustomerID" и "SupplierID" за тези счетоводни записвания кой идентификатор се подава?	Съгласно Приложение №3 към Заповед №З-ЦУ-30-1247/25.08.2025 г. за изменение на Заповед №З-ЦУ-30-1085/25.07.2025 г. на изпълнителния директор, с която са утвърдени форматът и редът за подаване на файла, Доставчици (Suppliers) – съдържа информация за доставчиците, като идентификационни данни (име, адрес), аналитична сметка, за която се подава начално и крайно салдо и др. В тази подсекция се подава информация относно всички доставчици на данъкоплатеца, за които се подават данни в останалите секции/подсекции на файла за отчетния период. Напр. ако в други секции на файла /напр. GeneralLedgerEntries, SourceDocuments/ са подадени данни за клиент/доставчик, същите данни следва да се подадат и в секция MasterFiles.
		Въпрос: Питането ми е относно начина на попълване на Месечен SAF-T файл в частта MasterFiles подсекция Customers_ елементи CustomerID  и AccountID   Ако приемем, че при съставянето на файла имаме следните условия: 1/за периода на отчета има само две продажби и те са с един и същ клиент ( едно и също CustomerID) 2/първата продажба е по сметка (AccountID) 411 Вземания от клиенти 3/втората продажба е по сметка (AccountID) 414 Вземания от клиенти по продажби при определени условия	В бележките към елемент MF.C.5 AccountID от подсекция Customer, секция MasterFiles, от приложение №2 към заповедта на изпълнителния директор,   e   посочено,   че   ако   разчетите/балансите   с   клиент   на предприятието се отразяват в повече от една счетоводна сметка - се подава информация за всяка счетоводна сметка в отделна структура. Когато с даден контрагент разчетите се отразяват в повече от една счетоводна   сметка,   то   следва   да   се   подадат   толкова   структури Customer/Supplier колкото са счетоводните сметки, по които се водят разчетите. Във представения от Вас пример, xml-файла следва да се подаде:

		Как  следва  да  се  попълни  MasterFiles  в  подсекция  Customers  за елементи CustomerID и AccountID ?	DE123456… Beta GmbH 11DE123456… 411 Amount >  Amount DE123456… Beta GmbH 11DE123456… 414 Amount >  Amount
Suppliers		Означава ли, че един наш контрагент, който е и доставчик и клиент, ще трябва да се води с отделна аналитичност? Да разбираме ли, че трябва да водим различни номенклатури за един и същ контрагент един път като доставчик и втори път като клиент или това системата ще го автоматизира по някакъв начин?	При подаването на информация за контрагент, който е клиент и доставчик на предприятието се подава данни за него и в двете подсекции Customers и Suppliers, които са част от секция MasterFiles. При условие, че във воденото от Вас счетоводство за същия (контрагент, който е клиент и доставчик) не са открити отделни партиди за клиент и доставчик, то в подсекция Customers се посочва аналитичната сметка на контрагента, за която се подава начално и крайно салдо, формирани на база разчетите с контрагента, които са свързани с извършените доставки към него. В подсекция Suppliers се посочват аналитичната сметка на

			контрагента, за която се подава начално и крайно салдо, формирани на база разчетите с контрагента, които са свързани с получени доставки от него. Не се допуска компенсиране на вземания и задължения от един контрагент за целите на представянето на информация в SAF-T, в съответствие с принципите на Счетоводен стандарт 1 „Представяне на финансови отчети“, относно оповестяването на информация за вземанията и задълженията.
	MF.S.3 SupplierID	В случаите, в които доставчик от ЕС, регистриран по ДДС в друга държава членка на ЕС, е подал пред НАП Искане за прилагане на СИДДО  и  му  е  издаден  служебен  номер  от  регистъра  на  НАП, започващ с 307, кой код следва да се използва за него - 11 следван от кода на държавата (съгласно ISO 3166-1 - 2 букви) и уникалния идентификационен код по ДДС на съответната държава членка или 16 последван от предоставен от НАП служебен номер (започващ с 307)?	В конкретния пример се посочва идентификатора, с който лицето е регистрирано за целите на ДДС.
		Кои са аналогичните на ДДС данъци в държавите извън ЕС, при наличие на регистрация за които ще се препоръчва използването на код 12?	В описанието към елемента за код „12“ няма изискване на въвеждане на регистрационен  номер,  издаден  за  аналогична  регистрация  за  ДДС. Посочва се уникалния идентификационен код по ДДС или друг код от официален регистър на съответната държава (напр. TIN), която не е нито България, нито държава-членка на ЕС.
		Aко  контрагент  е  предоставил  друг  идентификационен  номер, различен от номера си за регистрация по подобен на ДДС данък в държавата  си  на  регистрация,  може  ли  да  се  използва  за  този контрагент код 13 или код 14?	В конкретния случай се посочва уникалния идентификационен код по ДДС или друг код от официален регистър на съответната държава, която не е нито България, нито държава-членка на ЕС, който следва да е предхождан с код „12“. Ако за чуждестранния контрагент няма данни за регистрационен номер – е допустимо да се използва и код „14“.
		Дали     се     включват     всички     доставчици,     примерно     други финансови/банкови институции, с които се осъществяват банкови операции или такива, предоставящи финансиране (например, EBRD, ЕСВ, EIB). Транзакциите между тези лица в коя секция/раздел биха попаднали, например, ако са свързани с финансиране?	Доставчик  е  физическо  или  юридическо  лице,  на  което  се  дължи възнаграждение  за  получена  насрещна  престанция  (стоки,  услуги, продукт, лихви, др.). В секция MasterFiles се подават данни за доставчици, които фигурират и в останалите секции на файла (GeneralLedgerEntries, SourceDocuments, др.).

	MF.S.5 AccountID	В секции PurchaseInvoices и SalesInvoices се подават и документи, които касаят само разчетите с ДДС, и в които са попълнени елементи Customers и Suppliers /протоколи, митнически декларации и др./. В тези документи в AccountID е попълнена сметката за разчет с ДДС. Въпрос: В MasterFiles секция 2.3 Customers и 2.4 Suppliers трябва ли да се подава информация за тези контрагенти? Ако отворът е Да, какво се подава в елемент AccountID и в елементите за салда?	Да, подават се и в MasterFiles, като в елемент AccountID се посочва разчетната сметка на контрагента, която е посочена и в GeneralLedgerEntries при подаване на данни за съответната счетоводна трансакция. В елементите за салда се подават данни за начално и крайно салдо по разчетната сметка с контрагента за съответния период.
		В информационната система може да има счетоводни записвания, които не касаят разчети с Клиенти и Доставчици, но които за целите на  управленската  отчетност  също  се  отчитат  по  контрагенти  – например, получени заеми, приходи от продажби, факторинг, лизинг и др. Въпрос: В елементи "CustomerID" и "SupplierID" за тези счетоводни записвания кой идентификатор се подава?	Съгласно Приложение №3 към Заповед №З-ЦУ-30-1247/25.08.2025 г. за изменение на Заповед №З-ЦУ-30-1085/25.07.2025 г. на изпълнителния директор, с която са утвърдени форматът и редът за подаване на файла, Доставчици (Suppliers) – съдържа информация за доставчиците, като идентификационни данни (име, адрес), аналитична сметка, за която се подава начално и крайно салдо и др. В тази подсекция се подава информация относно всички доставчици на данъкоплатеца, за които се подават данни в останалите секции/подсекции на файла за отчетния период. Напр. ако в други секции на файла /напр. GeneralLedgerEntries, SourceDocuments/ са подадени данни за клиент/доставчик, същите данни следва да се подадат и в секция MasterFiles.
TaxTable	MF.TT.11 BaseRate	Каква  информация  се  попълва  в  елементи  BaseRate  /MF.TT.11/, Секция MasterFiles, подсекция 2.5 TaxTable - TaxCodeDetails?	BaseRate  –  коефициент  на  приспадане  за  ЧДК  по  подразбиране  се посочва  „1,00“.  При  извършено  приспадане  се  посочва  съответният коефициент за приспадане.
UOMTable	MF.UOM.2 UnitOfMeasure	Моля,  представете  информация  относно  начина  на  подаване  на информация   за   количество   (мерна   единица)   на   услуга   със Стандартния одитен файл за данъчни цели (SAF-T)?	Данни   за   мерна   единица   се   подават   в   елементи   MF.UOM.2 UnitOfMeasure, част от секция MasterFiles, SD.MG.28 UnitOfMeasure, част от секция SourceDocuments, и S.I.40 InvoiceUOM, част от структурата на реда на фактурата (InvoiceStructureLine), като при подаването на информация в тях се попълва съответстващата мерна единица от номенклатурата. В случаите на извършване на продажби на услуги, при подаване на информация за мерната единица на услугата в описаните по-горе елементи на SAF-T следва да се подаде съответстващия код на мерна единица, с която е определено количеството на услугата, например: код H87 – piece/брой (един); код

			HUR – hour/час; друг код, съответстващ на вида на предоставяната услуга.
Product		Допустимо ли е стоки, които са подадени в подсекция Product в месечните файлове да не присъстват във файла при поискване?	С файла за наличностите и движение на стоково-материалните запаси в подсекция Products, секция MasterFiles, се подава информация за всички налични стоки и материали през периода, за който е изискан файла, независимо дали да били подадени с месечен файл за същия период.
		Услугите включват ли се в  Раздел Products <Продукти> и ако да, с какви  кодове  следва  да  се  посочват  отделните  видове  услуги, получавани и предоставяни от Дружеството в хода на дейността му?	В номенклатура „NC8_TARIC“ от файла е посочен код за услуга, който следва  да  бъде  посочен  за  всички  видове  услуги,  получавани  и предоставяни от предприятието. Например:
				Код          от системата на ЗЛ	Име на продукт	Код по NC8_ TARIC
				1000010	Услуга по електро изграждане	000000
				1000011	Довършителни СМР	000000
PhysicalStock	MF.PS.2 WarehouseID	Каква информация се подава в секция MasterFiles, подсекция 2.10 PhysicalStock - PhysicalStockEntry, елемент WarehouseID /MF.PS.2/ – наименование на склад, адрес или и двете? В описанието на елемента е посочено, че се подават и превозни средства или други,  които съдържат стоки на път. Това означава ли, че трябва да се посочат всички номера на превозни средства, с които към момента на изготвяне на файла се транспортират материални запаси?	Подава   се   информация   за   локацията   на   всеки   продукт   (склад, производствено помещение, транспортно средство при стоки на път и др.) към крайната дата от периода, за който се подава файла.
	MF.PS.6 ProductType	Каква  информация  се  подава  в  Секция  MasterFiles,  подсекция PhysicalStockEntry, елемент ProductType /MF.PS.6/?	Подава се съгласно номенклатура за вид на МЗ (5 вида съгл. СС № 2 - ОТЧИТАНЕ НА СТОКОВО-МАТЕРИАЛНИТЕ ЗАПАСИ – материали, продукция,    стоки,    незавършено    производство    и   инвестиция    в материален запас).
ASSETS		Какво се подава в подсекция 2.12 Assets?	В подсекция 2.12 Assets се подава информацията за всички дълготрайни материални и нематериални активи заведени в счетоводната отчетност на предприятието през периода, за който се подава файла.
		За дълготрайните активи данните ще се подават за определен период или ще се подават за всички активи към момента на генериране на информацията,   т.е.   ако   се   изисква   информация   за  придобити	В секция MasterFiles, подсекция Assets, се подават данни за активите, отчитани счетоводно през съответния отчетен период (година).

	дълготрайни активи за всички налични активи ли ще бъде генерирана или само за тези, които имат движение за дефинирания период?	В секция SourceDocuments, подсекция AssetTransaction, се подават данни за всички движения на дълготрайни активи през съответния отчетен период (година).
	Какви стойности да се посочат в   MF.A.16, MF.A.17, MF.A.21 и MF.A.23 ако дълготрайните активи не се отчитат по историческа цена,  а  съгласно  Международен  счетоводен  стандарт  (МСС)  16 „Имоти, машини и съоръжения“ по преоценена стойност?	В   елементи   MF.A.16,   MF.A.17,   MF.A.21   и   MF.A.23   се   посочва историческата цена на актива (цената на придобиване) в началото и края на период, разходи за подобрения на актива и историческата цена на актива при изписването му. Стойността, с която се признават (въвеждат в счетоводните регистри) активите, вкл. и когато са отчитани по Международен счетоводен стандарт (МСС) 16 „Имоти, машини и съоръжения“, се отчита в елементи: MF.A.24 BookValueBegin – балансова стойност в началото на периода; MF.A.31 BookValueEnd – балансова стойност в края на периода; Начислените амортизации, увеличения на балансовата стойност актива, преоценки - се отчитат в елементи от MF.A.25 и до MF.A.30.
MF.A.16 AcquisitionAndPr oductionCostsBeg in	Тъй като  на две места  в колона Бележки  се позовавате  на  СС4, въпросите  за  подсекция  ValuationSAP  са  зададени  използвайки определенията дадени в него, а именно Отчетната Стойност намалена с Начислената Амортизация дава Балансовата Стойност на актива (ОС-НА=БС). В елемент „MF.A.16“ отчетната стойност в началото на периода ли се посочва?	В елемента се посочва историческата цена (общо разходи за закупуване или за производство) на придобиване при счетоводното завеждане на актива.   Напр.: ако се подава SAF-T за 2026 г. и следва да се подават данни за определен актив, който е закупен през 2022 г., то в елемента се посочва историческата цена, за която е придобит през 2022 г., не балансовата му стойност към 31.12.2025 г.
	Какво следва да се посочи в елемент Master files/ValuationSap/AcquisitionAndProductionCostsBegin - Общо начално салдо разходи за придобиване (вкл. по стопански начин) на актива (в основна валута) – ако идеята е да се даде разбивка на началното салдо на разходите за придобиване на ДМА на ниво самостоятелен актив, това е практически невъзможно да бъде направено при нас, т.к. договорите за изграждане на активи (придобиване на активи, основно машини и съоръжения, чрез строителство) включват множество и различни операции, обичайно от    различни    доставчици,    като    едва    след    приключване    на	В елемент Master files/ValuationSap/AcquisitionAndProductionCostsBegin се посочва историческата цена на актива, в случай, че същият е включен в СчАП, т.е. ако е признат за дълготраен материален актив.

		изграждането може да бъде установено кои самостоятелни активи ще бъдат счетоводно отчетени. Това е така, т.к. строителството на големи проекти (например изграждане на нова производствена линия или съоръжение) е продължителен процес, който често изисква няколко години, а множество общи разходи следва да се разпределят между всички активи (например разходи за проектиране, определени разходи за строителство и др. подобни). Поради тази причина, според нас не е реално изпълнимо задължително да се подава информация за разходите за изграждане на активи на ниво отделен актив, който е в процес на изграждане.
	MF.A.17 AcquisitionAndPr oductionCostsEnd	В „MF.A.17“ се посочва: Вариант 1 - отчетна стойност в края на периода  (отчетната  стойност  в  началото  +  всички  увеличения  - всички намаления) или Вариант 2 - стойността на всички разходи за придобиване на активи за периода (както сумите за завишаване стойността на актив, вкл. по стопански начин, така и директно закупени/придобити активи през периода, вкл. по стопански начин)?	В елемента се посочва историческата цена на актива към края на периода, за който се подава файла, увеличена или намалена със сумите на допълнителни разходи за подобрения  и/или преоценки, извършени през периода. Това е историческата цена, към която са добавят сумите посочени в елемент  MF.A.21 AssetAddition и се намалява със сумите в елемент MF.A.23 AssetDisposal.
	MF.A.21 AssetAddition	В „MF.A.21“ се посочва: Вариант 1 - отчетна стойност в края на периода (отчетната стойност в началото + всички увеличения - всички намаления) или Вариант 2 -  балансовата стойност в края на периода  (отчетната  стойност  в  началото  +  всички  увеличения  - всички  намаления  -  начислената  амортизация)  или  Вариант  3  - стойността на добавените активи през периода (директно закупени/придобити активи през периода, вкл. по стопански начин, както и сумите на завишаване на актив)?	В елемента се посочва: - историческата цена на актива, когато същият е придобит през годината, за която се подава SAF-T, или - стойност на подобрения върху придобит пред отчетния период актив, ако са направени през годината, за която се подава файла, или - историческа цена на актива и подобрения върху него, ако същият е придобит и подобренията са направени през годината, за която се подава файла.
	MF.A.23 AssetDisposal	В  „MF.A.23“  се  посочва:  Вариант  1  -  отчетната  стойност  на отписаната  част  на  актива  (при  дефектирала  части  или  др.)  или Вариант 2 - балансовата стойност на отписаната част на актива (при дефектирала части или др.) към момента на отписването или Вариант 3 - отчетната стойност при отписване (продажба, бракуване, липса, апортна вноска, трансфер и т.н.) на актив, вкл. сумата на отписаната част на актива (при дефектирала части или др.)?	В елемента се посочва историческата цена при отписване на актив или на част от него.

	MF.A.24 BookValueBegin	В „MF.A.24“ се посочва: Вариант 1 - Балансовата стойност в началото на периода (отчетната стойност в началото на периода - начислената амортизация в началото на периода) или Вариант 2 - балансовата стойност в края на периода (отчетната стойност в началото на периода + всички увеличения на стойността на актива - всички намаления на стойността на актива - начислената амортизация в края на периода) или Вариант 3 - отчетната стойност в края на периода (отчетната стойност в началото на периода + всички увеличения на стойността на актива - всички намаления на стойността на актива), без да се има предвид начислената амортизация?	В елемента се посочва балансовата стойност на актива в началото на периода, за който се подава файла, или балансовата стойност на актив придобит през периода за който се подава файла.
	MF.A.28 AppreciationForP eriod	В   „MF.A.28“   се   посочва   стойността   на   всички   разходи   за придобиване  на  активи  за  периода  (както  сумите  за  завишаване стойността  на  актив,  вкл.  по  стопански  начин,  така  и  директно закупени/придобити активи през периода, вкл. по стопански начин)?	В елемента се посочват всички увеличения на балансовата стойност на актива, които са направени през периода, за който се подава файла.
		В  MF.A.21 и MF.A.28 трябва ли винаги да посочваме едни и същи данни?	В MF.A.21 AssetAddition се посочва една от посочените от Вас стойностти,  които  представляват  увеличение  на  историческата  цена (цената на придобиване/подобрение) актива. В елемент MF.A.28 AppreciationForPeriod се посочват всички увеличения на балансовата стойност на актива, които може да се различават от цената на придобиване/подобрение.
	MF.A.29 ExtraordinaryDepr eciationsForPeriod	В „MF.A.29“ се посочва сума на извънредно начислена амортизация за периода? Пример: През 2026г. се извършва подобрение на 6-ти етаж  на  сграда.  През  2026г.  се  посочва  извънредно  начислена амортизация изчислена върху сумата на подобрението на 6-ти етаж. През 2027г. се извършва подобрение на 7-ми етаж на сградата. През 2027г. се посочва извънредно начислена амортизация изчислена само върху  сумата на подобрението  на 7-ми етаж (само  на сумата на подобрението от периода). Уточняването на този въпрос е важно, защото след преоценка например, отчетната стойност на актива може да стане по-малка от стойността на всички увеличения на актива през годините. В този случай, ако не се вземат само сумите от текущия период, общата амортизация ще бъде по-малка от извънредно начислената амортизация.	В елемента се посочва извънредни разходи за амортизации съгласно Счетоводен стандарт 4, напр. при обезценка на актива, ако същата е направена през периода, за който се подава файла.

	MF.A.30 AccumulatedDepr eciation	В „MF.A.30“ се посочва Начислена амортизация в края на периода?	В елемента се посочва натрупаната амортизация за актива към края на периода, за който се подава файла.
	MF.A.31 BookValueEnd	В „MF.A.31“ се посочва балансовата стойност в края на периода (отчетната стойност в началото на периода + всички увеличения на стойността на актива - всички намаления на стойността на актива - начислената амортизация в края на периода)?	В  елемента  се  посочва  балансова  стойност  на  актива  към  края  на периода, за който се подава файла.
	MF.A.41 MonthChangeAss etValue	Ако през периода има промяна в стойността на актива повече от веднъж, кой месец се посочва в „MF.A.41“ : първи, последен или месеца с най-голяма промяна на стойността?	Елементът  не  следва  определена  структура  -    в  описаната  от  Вас хипотеза  в  него  се  подават  всички  месеци,  през  които  промяна  на стойността  на  актива,  и  всички  основания,  които  са  обусловили промените.
	MF.A.42 MonthSuspension/ ResumptionAccru al	Ако през периода сме преустановили, но след това сме възобновили начисляването  на  данъчни  амортизации,  кой  месец  посочваме  в „MF.A.42“   -   на   преустановяване   или   на   възобновяване   на начисляването на данъчни амортизации?	Този елемент също не следва определена структура - в описаната от Вас хипотеза се подават всички месеци на преустановяване/възобновяване и обстоятелствата за тях.

ПОДСЕКЦИЯ	ЕЛЕМЕНТ	ВЪПРОС	ОТГОВОР
	GL.1 NumberOfEnt ries	Какво трябва да се сумира - брой на отделните редове по всички транзакции или брой транзакции?	Броят на всички подадени отделни транзакции (елементи TransactionID /GL.9/)    в    секцията    да    отговаря    на    стойността,    посочена    в NumberOfEntries.
Transaction	GL.10 Period GL.11 PeriodYear	Какви стойности се попълват в тези полета? Текущ период или друго, ако транзакцията е свързана с осчетоводяване в предходен период?	В „Period“ и „PeriodYear“ се отразява годината и месеца за който се отнася осчетоводяването, а не дата на която е извършено осчетоводяването.
	GL.17	В следния пример: Фактура за доставка с дата 15.01.2025	При подаване на информация със Стандартния одитен файл за данъчни цели, когато същата се отнася за предходен счетоводен период, а не за

SystemEntry Date	Получена и въведена в модул Доставки на 01.04.2025 Осчетоводена на 14.04.2025  с отчетна дата 31.03.2025  (период, в който ще влезе в оборотната ведомост) Как                         се                         попълват                         полетата Period;PeriodYear;TransactionDate;SystemEntryDate;GLPostingDate   в GeneralLedgerEntries/Transaction в месечен SAF_T файл ?	периода, за който се подава файла, в елементи Period, PeriodYear и GLPostingDate се подава предходния период, за който се отнася осчетоводяването. В представения  от Вас случай, SAF-T се подава, както следва: GL Счетоводни записи ……………… ………………………. 03 2025 2025-01-15 …………………………… 2025-04-01 2025-03-31
GL.18 GLPostingDat e	Пример:  файлът  за  м.12.2024г.  е  подаден  и  приет.  Счетоводната година не е приключена. На 20.02.2025г. е получена фактура с дата 15.02.2025  за  ел.  енергия,  в  която  е  фактурирана  ел.  енергия  за периода 15.12.2024-14.01.2025. Част от разхода се отнася за 2024 и за него са въведени счетоводни записвания за период 12.2024 с дата на осчетоводяване    31.12.2024г.    Системната    дата    на    въвеждане е20.02.2025г. Файлът, който трябва да бъде подаден, е за м.02.2025г. GL Счетоводни записи ……………… ………………………. 2 2025 2025-02-15 …………………………… 2025-02-20 2024-12-31	При подаване на информация със Стандартния одитен файл за данъчни цели, когато същата се отнася за предходен счетоводен период, а не за периода, за който се подава файла, в елементи Period, PeriodYear и GLPostingDate  се  подава  предходния  период,  за  който  се  отнася осчетоводяването. В представения  от Вас случай, SAF-T се подава, както следва: GL Счетоводни записи ……………… ………………………. 12 2024 2025-02-15 …………………………… 2025-02-20 2024-12-31

	Въпрос: Правилно ли са попълнени данните?
GL.19 CustomerID	Питането ми е как да се попълнят тези два елемента (Доставчик ("SupplierID") и Клиент ("CustomerID")) , в случаите в които информацията за клиента/доставчика не се съдържа в транзакцията , а към елементите към нея (TransactionLine) Давам пример: Осчетоводяване на Банково извлечение, в което имаме три плащания към трима различни доставчици. В самото  извлечение това са три реда, като общото между тях е, че става дума за плащане по фактура за доставка. Осчетоводяването може да се направи по два начина: А/всеки ред поотделно в три      отделни счетоводни записвания(счетоводни статии): Дт 401 Доставчици - признак доставчик 1 на Кт 503 Разпл.сметка – признак Плащане по фактура за доставка – 1000 лв. Дт 401 Доставчици - признак доставчик 2 на Кт 503 Разпл.сметка – признак Плащане по фактура за доставка – 2000 лв. Дт 401 Доставчици - признак доставчик 3 на Кт 503 Разпл.сметка – признак Плащане по фактура за доставка – 3000 лв.   или   Б/В едно счетоводно записване с един кредит (по сметка 503) и три дебита  (по сметка 401 ): Кт 503 Разпл.сметка – признак -  Плащане по фактура за доставка – 6000 лв. Дт 401 Доставчици - признак доставчик 1– 1000 лв. Дт 401 Доставчици - признак доставчик 2– 2000 лв. Дт 401 Доставчици - признак доставчик 3– 3000 лв.	В посочения от Вас случай са допустими и двата вида записвания и подаване на информация. В представения от Вас вариант „А“, пример за транзакцията би бил следният: TransactionID: NNNNN CustomerID – 0 SupplierID – 10XXXXXXXXX (EИК на доставчик №1)   TransactionLine: 1 AccountID – сметка номенклатура НАП (сметка 503) TaxpayerAccountID – ан. сметка на лицето (сметка 503001) CreditAmount – 1 000,00 евро. CustomerID – 0 SupplierID – 10XXXXXXXXX (EИК на доставчик №1)   TransactionLine: 2 AccountID – сметка номенклатура НАП (сметка 401) TaxpayerAccountID – ан. сметка на лицето (сметка 4010001) DebitAmount – 1 000,00 евро. CustomerID – 0 SupplierID – 10XXXXXXXXX (EИК на доставчик №1)   В случаите, когато с една транзакция (счетоводна операция) се отразяват разчети с повече от един контрагент се допуска в   елементите CustomerID и SupplierID на подсекцията Transaction да се посочи идентификатора на лицето, което подава файла. Напр.: TransactionID: NNNNN+1 CustomerID – 10XXXXXXXXX (EИК на лицето, подаващо файла) SupplierID – 10XXXXXXXXX (EИК на лицето, подаващо файла)   TransactionLine: 1 AccountID – сметка номенклатура НАП (сметка 503)

		TaxpayerAccountID – ан. сметка на лицето (сметка 503001) CreditAmount – 6 000,00 евро. CustomerID – 10XXXXXXXXX (EИК на лицето, подаващо файла) SupplierID – 10XXXXXXXXX (EИК на лицето, подаващо файла)   TransactionLine: 2 AccountID – сметка номенклатура НАП (сметка 401) TaxpayerAccountID – ан. сметка на лицето (сметка 4010001) DebitAmount – 1 000,00 евро. CustomerID – 0 SupplierID – 10XXXXXXXXX (EИК на доставчик №1)   TransactionLine: 3 AccountID – сметка номенклатура НАП (сметка 401) TaxpayerAccountID – ан. сметка на лицето (сметка 4010002) CreditAmount – 2 000,00 евро. CustomerID – 0 SupplierID – 10XXXXXXXXX (EИК на доставчик №2)   TransactionLine: 4 AccountID – сметка номенклатура НАП (сметка 401) TaxpayerAccountID – ан. сметка на лицето (сметка 4010003) CreditAmount – 3 000,00 евро. CustomerID – 0 SupplierID – 10XXXXXXXXX (EИК на доставчик №3)
GL.20 SupplierID	В частта General ledger items имаме подобен казус, но по отношение на supplier и customer IDs. Какво правим в случай, че има adjustment/reclass/рекласификация, свързани с различни доставчици или клиенти? Най-елементарен пример - начислен е разход срещу сметка доставчици, но по грешна партида на доставчика. Преместването на сумата може да стане с операция, засягаща една сметка (в случая Доставчици), но различни аналитични показатели -	С чл. 3, ал. 3 от ЗСч се регламентира, че счетоводно отчитане се осъществява на основата на документална обоснованост на стопанските операции. С оглед на което в представения от Вас пример няма как да се извърши счетоводна операция, с която един погрешно начислен разход в партида на доставчик да се отрази по партида на друг доставчик. Когато счетоводна грешка се открие в рамките на отчетния период, в този случай би следвало неправилната операция да се сторнира и данните да се отразят отново.

	партида  на  доставчик.  В  този  случай  какво  подаваме  на  ниво Transaction?
GL.27 SourceDocume ntID	В   структурата   GeneralLedgerEntries,   полето   SourceDocumentID следва да указва връзка към първичния документ, от който произтича счетоводният запис. Въпреки това, не е ясно какво  следва  да се посочва в случаите, когато записът произтича от друг тип документ, който не е фактура – например ведомост за работна заплата, разчет за командировка,  протокол  за  начисляване  на  амортизации  и  др. Липсата на яснота по този въпрос създава затруднения при структурирането на данните и може да доведе до непълно или неконсистентно подаване на информация. Молим за указания относно допустимите стойности и формати за SourceDocumentID в такива случаи.	В елемент SourceDocumentID се подава информация както за номер на фактура, така и за всички други първични счетоводни документи, с които се регистрират стопански операции. Например: номер на протокол, номер на платежно нарежда/референция за плащане, номер на приходен/разходен касов ордер. С нормата на чл. 6, ал. 3, т. 1 от Закона за   счетоводството   се   регламентира,   че   първичният   счетоводен документ, който засяга само дейността на предприятието, следва да съдържа номер на документа, съдържащ само арабски цифри. С ал. 5 от същата норма се регламентира, че документална обоснованост е налице, когато в първичния счетоводен документ липсва част от изискуемата информация по ал. 1 и 3, но за нея има документи, които я удостоверяват. С оглед на гореизложеното ако в първичен счетоводен документ липсва негов номер, то следва да се посочи номер на съпътстващ документ.
GL.33 TaxInformation	Съгласно ЗКПО в данъчната основа за определяне на задълженията за данъка върху разходите за разходите в натура, свързани със собствени, наети и/или предоставени за ползване активи, предоставени  за  лично  ползване  и/или  свързани  с  използване  на персонал, от работници, служители и лица, наети по договори за управление и контрол (наети лица), както и от лица, упражняващи личен труд по смисъла на § 1, т. 26, буква „и" от допълнителните разпоредби на ЗДДФЛ, когато активите са данъчни амортизируеми активи, вместо счетоводните разходи за амортизации се вземат предвид данъчните амортизации. Как и къде данъчните амортизации, следва да се посочат при подаване на информация за „разход, върху който     се     дължи     данък     върху     разходите”     в     секция GeneralLedgerEntries, в TaxInformation от подсекция TransactionLine, при положение, че за тях не се прави счетоводен запис?	Кодът за данъка се посочва при осчетоводяването на първичния счетоводен документ, издаден на основание чл. 6, ал. 3 от ЗСч, с който се начислява дължимия данък. Такъв документ може да бъде счетоводна справка, мемориален ордер, др.
	При отчитане на начислени разходи за „Данък при източника“ и „Данък върху разходите“ необходимо ли е сметките от елемент „NRA Nom  of  Accounts“  да  носят  и  информация  за  код  на  вид  данък	Представения   от   Вас   случай,   описва   счетоводна   операция   за начисляване   на   данък   върху   разходите,   след   осчетоводяването първичния  счетоводен  документ,  отразяващ  разхода.  С  IV.8.2.1.  от

	(TaxType) и за код на данъка (TaxCode). В случай, че е необходимо, то трябва ли код на вид данък (TaxType) и код на данъка (TaxCode), да присъстват едновременно и от двете страни на операцията – в сметката по дебита от елемент „NRA Nom of Accounts“ и в сметката по кредита от елемент „NRA Nom of Accounts“?. Например: Дебит „60602 Разход за данъци върху разходите“, код 600010 Кредит „456 Разчети за данъци върху разходите“ код 600010.	приложение №3 към заповедта на изпълнителния директор на НАП, се регламентира, че кодът за данък върху разходите се посочва при начисляването на разходи, за които се дължи данък, а не при начисляването на дължимия данък. Код за данък върху разходите се посочва при счетоводната операция за начисляване на разхода. Например: TransactionID: NNN TransactionLine: 1 AccountID – сметка номенклатура НАП (сметка 401) TaxpayerAccountID  –  ан.  сметка  от  счетоводството  на  лицето  (см. ХХХХХХХ) CreditAmount – 5 000,00 евро. TaxInformation – вид 600 и код 600040 TransactionLine: 2 AccountID – сметка номенклатура НАП (сметка 60909) TaxpayerAccountID  –  ан.  сметка  от  счетоводството  на  лицето  (см. ХХХХХХХ) DebitAmount – 5 000,00 евро. TaxInformation – вид 600 и код 600040
	Съгласно ЗКПО в данъчната основа за определяне на задълженията за  данъка  върху  разходите  за  разходите  в  натура,  свързани  със собствени,    наети    и/или    предоставени    за    ползване    активи, предоставени за лично ползване и/или свързани с използване на персонал, от работници, служители и лица, наети по договори за управление и контрол (наети лица), както и от лица, упражняващи личен труд по смисъла на § 1, т. 26, буква „и" от допълнителните разпоредби на ЗДДФЛ, когато активите са данъчни амортизируеми активи, вместо счетоводните разходи за амортизации се вземат предвид данъчните амортизации. Как и къде данъчните амортизации, следва да се посочат при подаване на информация за „разход, върху който се дължи данък върху разходите” в секция GeneralLedgerEntries, в TaxInformation от подсекция TransactionLine, при положение, че за тях не се прави счетоводен запис?	Кодът  за  данъка  се  посочва  при  осчетоводяването  на  първичния счетоводен документ, издаден на основание чл. 6, ал. 3 от ЗСч, с който се начислява дължимия данък. Такъв документ може да бъде счетоводна справка, мемориален ордер, др.

 

ПОДСЕКЦИЯ	ЕЛЕМЕНТ	ВЪПРОС	ОТГОВОР
PurchaseInvoi ces		Митническа декларация №BG000000000 – в информационната система е въведена с един ред с текст „Митническа облагаема стойност”, мярка брой, количество 1, ед. цена 15000лв., стойност 15000лв., ДДС – 3000лв. Счетоводните операции са 4531/458-3000лв. Няма въведен код на продукт. Доставените стоки с митническата декларация са въведени с Invoice №SK5875 от чуждестранния контрагент /документът не се подава в SAF-T файла/ и са осчетоводени по сметката за разчет с контрагента 401. За доставката е въведен складов документ за покупка, в който е цитиран Invoice №SK5875. В описаната ситуация са попълнени следните данни във файла: PurchaseInvoices: ……………………………………………… BG000000000 ………………………………………………………….. 458 ………………………………………………………….	Данните в подсекция MovementOfGoods, секция SourceDocuments, са попълнени коректно. В подсекция PurchaseInvoice, секция SourceDocuments,     в     елементи     S.I.36     ProductCode     и     S.I.37 ProductDescription  следва да се посочи кодът и наименованието  на внесения  продукт  от  информационната  система  на  лицето,  което подава файла. При подаването на митническата декларация в секция SourceDocuments се посочват данни за всички внесени продукти на отделни линии, в които се посочва съответстващия им продуктов код в елемент  S.I.36  ProductCode,  в  елемент  S.I.41  InvoiceLineAmount  се посочва сбора на митническата облагаема стойност и внесените мита за съответния продукт. Данните за продуктите/стоките, които са закупени от чуждестранното лице, установено извън ЕС, следва да се посочат и в подсекция Products на секция MasterFiles и мапират към комбинираната номенклатура KN8 TARIC.   По отношение посоченото от Вас, че фактурата, с която са закупени стоките, „не се подава в SAF-T файла“, следва да имате предвид, че данни за фактурата могат да се подадат със счетоводна трансакция за

		1 4531 0 Митническа облагаема стойност ……………………………………………………. 1 H87 1 15000.00 …………………………………………………….         Митническа        облагаема        стойност ……………………………………………………… 15000.00 BGN 15000.00 …………………………………………………………… 100 100331 ………………………………………………………….. 3000.00 BGN Въпрос: Правилно ли са попълнени данните?	нейното осчетоводяване,      които се подават в секция GeneralLedgerEntries – в елемент GL.27 SourceDocumentID.
Payment		Прехвърляне на средства между собствени сметки на дружеството, обмяна  на  валута  следва  ли  да  се  посочват  в  този  Payments <Плащания>?	Прехвърляне на средства между собствени сметки на дружеството не представлява  плащания  и  не  следва  да  се  посочват  в  подсекция Payments.
		Как се отразяват данни от масови плащания – например заплати. Следва ли да се посочва трансакцията за плащане на заплата за всеки	Данните се подават съобразно отразяването им в счетоводната система на предприятието.

		отделен служител или е възможно да се посочат обобщени данни на един ред?
		Как   следва   да   се   отразят   плащания,   които   не   могат   да   се идентифицират с конкретен контрагент и да се посочи неговия ID - например покупка на финансови инструменти?	Когато няма информация за насрещен контрагент се подават данни на лицето подаващо файла.
		Някои ERP системи имат изградени системи за плащане, свързани с използването на т.нар. клиринг сметки. През тях реален касов поток към клиент или доставчик не минава, като чисто теоретично в края на деня крайния им баланс трябва да е 0. Транзакциите по тези сметки трябва ли да бъдат отчитани като плащания? Чисто счетоводно изплащането на едно задължение минава през два етапа, а не само един: а) Дебит сметка Доставчик / Кредит сметка Клиринг сметка б) Дебит сметка Клиринг сметка / Кредит сметка Разплащателна сметка Това би довело до умножаване на броя и общата сума на плащанията, които бихме показали в САФ-Т файла, което от своя страна би могло да доведе до разминавания между реалния касов поток и това, което ще видите в системите при Вас.	При подаването на информация в подсекция Payments, секция SourceDocuments, се подава информация за плащания, които закриват са свързани със задължения/вземания   от/към   контрагенти на предприятие. В подсекцията не следва се подават информация  за движения/трансакции от/към т.н. между собствени сметки и движения към клиринг сметки, каквито сте посочили в примера.
	SD.P.1 AccountID SD.P.10 PaymentMeth od SD.P.32 PaymentMech anism	Предоставен е аванс на подотчетно лице Х в размер на 130,00лв. Подотчетното лице представя фактура 0000000001 за материали от контрагент Y за 120,00лв. и касова бележка за паркинг за 10,00лв. В  Payments,  PaymentLine  коя  сметка  трябва  да  бъде  посочена  в AccountID – сметка 501 код 01 - за пари в брой и код 10 - за плащане в брой или сметка 422 код 01 - за пари в брой и код 99 – с подотчетни лица?	В елемент AccountID от подсекция PaymentLine се посочва разчетната сметка (сметка 422), тъй фактическото разплащане е извършено от подотчетното лице. В елемент SD.P.10 PaymentMethod се посочва метод за разплащане „02 – Прихващане“, съгласно номенклатура Nom_PaymentMethod. При подаване на информация в елемент SD.P.32 PaymentMechanism (опционален за подаване), част от подсекция PaymentSettlement (която също е опционална за подаване), се посочва механизъм за разплащане „99 – Подотчетни лица“.
MovementOf Goods		Какви стойности се попълват в тези полета? Текущ период или друго, ако транзакцията е свързана с осчетоводяване в предходен период?	Подсекцията MovementOfGoods е част от секция SourceDocument и с нея  се  подават  данни  за  движение  на  стоково-материални  запаси (СМЗ). Подава се само при поискване от орган по приходите. При наличие на движение на СМЗ през периода, за който е изискано да се подаде файла от орган по приходите, за подаване на информацията в

			подсекцията следва да се попълнят структури StockMovement и StockMovementLine. Съдържанието на двете структури е посочено, съответно от елемент SD.MG.5 до елемент SD.MG.14 и от елемент SD.MG.19 до елемент SD.MG.33, в секция 4. SourceDocument от Приложение №2 към заповед №З-ЦУ-30-1085/25.07.2025 г.    на изпълнителния директор на НАП. Структурите StockMovement и StockMovementLine не са посочени в съдържанието на секция 5. Structures, тъй като същите се използват само за подаването   на подсекция MovementOfGoods.
		В Приложение 2, т. 4 „SourceDocuments“ е посочена структура 4.4 „MovementOfGoods“, като в XSD схемата са налични контролни елементи за тази структура. Въпреки това, в секция 2.5 „Structures“ на същото приложение липсва нейното описание и дефиниция. Това създава неяснота относно очакваното съдържание и структура на елемента, което възпрепятства правилното му имплементиране и валидиране.	Подсекцията MovementOfGoods е част от секция SourceDocument и с нея  се  подават  данни  за  движение  на  стоково-материални  запаси (СМЗ). Подава се само при поискване от орган по приходите. При наличие на движение на СМЗ през периода, за който е изискано да се подаде файла от орган по приходите, за подаване на информацията в подсекцията следва да се попълнят структури StockMovement и StockMovementLine. Съдържанието на двете структури е посочено, съответно от елемент SD.MG.5 до елемент SD.MG.14 и от елемент SD.MG.19 до елемент SD.MG.33, в секция 4. SourceDocument от Приложение №2 към заповед №З-ЦУ-30-1085/25.07.2025 г.    на изпълнителния директор на НАП. Структурите StockMovement и StockMovementLine не са посочени в съдържанието на секция 5. Structures, тъй като същите се използват само за подаването   на подсекция MovementOfGoods.
	SD.MG.1 Number       of movement lines	Елемент SD.MG.1,  изисква попълването на конкретна информация по отношение на „Number of movement lines“. Описанието, дадено с колона „бележки“ не дава достатъчно яснота, каква е изискуемата информация. В тази връзка бихме искали да помолим за допълнителни разяснения дали  случая  касае  всички  транзакции  или  само  за  доставка  и продажба? Очакваме вашият отговор да е конкретен и съобразен със следната фактическа обстановка:	В елемента се посочва общия брой на подадените линии (редове) на движенията   на   материалните   запаси   –   независимо   от   вида   на движението (покупка, продажба, брак, движение между складове, др.), т.е.  в  елемента  се  подава  общия  брой  на  подадените  елементи SD.MG.18   Line   number   в   подсекция   4.4   MovementOfGoods   - StockMovementLine.

		Моля да сте информирани, че дейността на нашето дружество се осъществяван чрез няколко склада, разположени на територията на страната. Движението на стоките се документира  в зависимост от хипотезата, освен с фактура, дебитни и кредитни известия за покупка или продажба, а също така с документи от типа, напр. стоки на път, протоколи за брак, корекция от инвентаризация и др. Обичайно упоменатите документи съдържат няколко десетки реда, съответстващи на списъка с номенклатурата на стоките.
	SD.MG.4 Stock movement	Елемент SD.MG.4 – Моля за допълнителни разяснения, съобразена с примери от базовата информация, предоставена в т.1 хо-гора, тъй като липса описание на изискваните полета „Описание“ и „Бележки“.	Елемент SD.MG.4 StockMovement представлява конкретна структура StockMovement, съдържанието на която е посочено от елемент SD.MG.5 до елемент SD.MG.14.
	SD.MG.5 Movement reference	Елемент SD.MG.5 - Моля за допълнителни разяснения за случая, когато използваните програмни продукти не съдържат „Уникален идентификатор на материалното движение от информационната система  на  данъкоплатеца“.  Какво  трябва  да  бъзе  подадено  като информация?	В елемент SD.MG.5 Movement reference следва да се посочи уникален номер, генериран от използвания от Вас софтуер за съответното движението на стоково-материални запаси /СМЗ/. В случай че софтуерът не генерира такъв номер е допустимо в този елемент да се подаде идентификаторът на движението, посочен в елемент SD.MG.12 - System ID.
	SD.MG.10 Movement type	Елемент SD.MG.10 – моля да потвърдите, че посоченото описание в колона  F  „Вид  на  движението  съгласно  предоставената  таблица“ касае кодировките и описанието   с кодовете работен лист (sheet) Stock movement. Отделно от това, моля да потвърдите, че кодовете : 160         Брак на материални запаси 170         Материални запаси с изтекъл срок на годност 180         Други движения на материални запаси Могат да се ползват за „Стоки“, тъй като дружеството ни не оперира с  „материални запаси“? П.С.  Съгласно  Националните  счетоводни  стандарти  (НСС)  или Международните стандарти за финансово отчитане (МСФО) – термините „стоки“ и „материални запаси“ (или „материали“) имат различно счетоводно и икономическо съдържание, което определя и как те се отразяват в счетоводната номенклатура и отчетност.	В елемент SD.MG.10 Movement type се подава код на за съответното движение  на  стоково-материални  запаси,  посочено  в  работен  лист (sheet)  Stock movement. Всички кодове в номенклатурата, вкл. кодове 160, 170 и 180, се отнасят за движения на стокови-материалните запаси (стоки и материали).

	SD.MG.12 System ID	Елемент SD.MG. 12 - System ID - Моля за допълнителни разяснения, дали се касае за уникален идентификатор за транзакция или за документ? Отделно от това, какво трябва да е съдържанието, когато използваните информационни системи (повече от една) не генерират уникален идентификатор за транзакция или на ниво линия?	В елемент SD.MG. 12 - System ID следва да се посочи уникалния номер, генериран от използвания от Вас софтуер при записване на въвежданата информация за движението на СМЗ в базата данни. В случай че софтуерът не генерира друг уникален идентификатор на движението, този номер е допустимо да се подаде и в елемент SD.MG.5 Movement reference
	SD.MG.13 DocumentRefer ence	За  кои  типове  движения  от  номенклатура  "Stock  movement"  е задължително  попълването  на  елемент  DocumentReference?  Как трябва да бъде попълнен елементът, когато не се изисква документ?	Движенията на стоково-материални запаси се обективират със съставянето на първичен счетоводен документи по чл. 6 от ЗСч. В бележките към елемент SD.MG.13 Document reference е посочено пояснение „Данните в полето следва да бъдат попълнени в случаите, в които съответния тип движение от "Stock movement" номенклатурата изисква наличието  на документ.“, с оглед на което да може да се покрият изключителни случаи, при които не е наличен документ обуславящ движението на стоково-материалните запаси. Когато няма данни за документи за документ за движение на стоково-материални запаси – в елементи Document type и Document number се подава информация по преценка на лицето, подаващо файла, даваща достатъчно яснота за движението на стоково-материалните запаси.
	SD.MG.14 Line	Елемент SD.MG. 14 – Line  -  Моля  за  допълнителни  разяснения, доколкото липсват пояснения в колони „Описание“ и „бележки“.	Елемент SD.MG. 14 Line представлява    конкретна структура StockMovementLine, съдържанието на която е посочено от елемент SD.MG.18 до елемент SD.MG.33.
	SD.MG.15 DocumentTyp е	В елемента „DocumentTypе” кодът или наименованието на документа от информационната система на данъкоплатеца трябва да се посочи?	Лицето, подаващо файла, следва да посочи в елемента информацията, която ще даде достатъчно яснота относно вида на съответния документ. В тази връзка елементът не е предварително дефиниран и позволява подаване на свободен текст, като в случая следва да се подаде наименованието на документа и евентуално кодът от информационната система на лицето.
	SD.MG.18 Line number	Елемент SD.MG. 18- Моля за допълнителни разяснения дали се касае за дублирана информация с  Елемент SD.MG. 14.	Елемент SD.MG. 14 насочва към конкретна структура StockMovementLine, като елемент SD.MG. 18 Line number е част от тази структура.

	SD.MG.28 UnitOfMeasure	Моля, представете информация относно начина на подаване на информация за количество (мерна единица) на услуга със Стандартния одитен файл за данъчни цели (SAF-T)?	Данни   за   мерна   единица   се   подават   в   елементи   MF.UOM.2 UnitOfMeasure, част от секция MasterFiles, SD.MG.28 UnitOfMeasure, част от секция SourceDocuments, и S.I.40 InvoiceUOM, част от структурата на реда на фактурата (InvoiceStructureLine), като при подаването на информация в тях се попълва съответстващата мерна единица от номенклатурата. В случаите на извършване на продажби на услуги, при подаване на информация за мерната единица на услугата в описаните по-горе елементи на SAF-T следва да се подаде съответстващия   код   на   мерна   единица,   с   която   е   определено количеството на услугата, например: код H87 – piece/брой (един); код HUR – hour/час; друг код, съответстващ на вида на предоставяната услуга.
AssetTransacti ons		По позиция ,Данни за период“, например, за дълготрайните активи ще се подават за определен период или ще се подават за всички активи  към  момента на генериране на информацията, т.е. ако  се изисква информация за придобити дълготрайни активи за всички налични активи ли ще бъде генерирана или само за тези, които имат движение за дефинирания период?	В секция SourceDocuments, подсекция AssetTransaction, се подават данни за всички движения на дълготрайни активи през съответния отчетен период (година).
	SD.AT.8 Supplier/Custo mer	Режимът за докладване на SD.AT.8 е „Optional“. Задължително ли е посочване на доставчик/клиент в   SD.AT.8 или по избор, тъй като режимът за докладване е „Optional“ ?	Елемент SD.AT.8 Supplier/Customer  е опционален и може да не се подава. В случай, че в счетоводната система на лицето, което подава файла, има данни за доставчик/клиент може да се подадат данни за контрагента. В случаите, че транзакцията не е свързана с конкретен контрагент се допуска да се подаде и ЕИК на лицето, което подава файла.
	SD.AT.15 AssetValuation Type	Моля, дайте пример, какво трябва да се посочи в „SD.AT.15“.	Елементът е опционален за подаване. В него се посочва по кой метод е оценен актива, съгласно приетите счетоводни политики, например по балансова или възстановима стойност.
	SD.AT.17 BookValueOnT ransaction	В  „SD.AT.17“  се  посочва:  Вариант  1  -  отчетна  стойност  след транзакцията или Вариант 2 - балансова стойност след транзакцията?	В елемента се посочва балансова стойност на актива след транзакцията.

 

ПОДСЕКЦИЯ	ЕЛЕМЕНТ	ВЪПРОС	ОТГОВОР
BankAccountS tructure		Пиша Ви с молба за разяснение по конкретна позиция от Приложение 2: В стр. 5. Structures -> 5.4 BankAccountStructure на Приложение 2 има указание за подаване на информация, свързана с банковата сметка на фирмата. Не става ясно дали: 1. Трябва да се подадат всички активни сметки на фирмата за периода, без значение дали е имало движение по тях; 2. Трябва да се подаде само една основна, по която основно има движение; 3. Или трябва да се подадат всички активни банкови сметки, които са имали движение през отчетния период.	Със Стандартния одитен файл за данъчни цели в структура BankAccountStructure   се   подава   информация   за   всички   платежни сметки, които се използват от лицето, подаващо файла, и са открити на при  банка,  платежни  оператори,  дружества  за  електронни пари,  др. Подават се всички сметки независимо  от това дали по същите има движения и салда през периода.
HeaderStructu re	S.H.11 HeaderCo mment	Забелязахме, че елемент Header Comment в секция Header е отбелязан в  последната  версия  на  Приложение  2  като  optional.  Моля  да потвърдите дали това следва да е така. Без този елемент как следва да се отбележи дали файлът е месечен, годишен или при поискване?	С т. I.2 от Приложение № 3 към заповед № З-ЦУ-30-1085/25.7.2025 г. се определя    форматът    на    Стандартния    одитен    файл,    както    и задължителното му наименование, в зависимост от това дали се подава месечно,  годишно  или  при  поискване.  При  подаване  на  файла  в електронната услуга на приходната администрация и ако не е наименуван в съответствие с посочената конвенция в Приложение №3, то същият няма как да бъде приет. Също така XSD схемата има условия за съдържанието на трите вида файлове (месечен, годишен и при поискване). Например ако с месечен XML      файл      не      се      подаде      някоя      от      задължителните секции/подсекции/елементи, то същият няма да се валидира към XSD схемата и няма да бъде приет. Отделно от изложеното няма проблем в елемент HeaderComment да се подава информация в ограничените стойности.

InvoiceStructu re	S.I.4 AccountID	Коя  сметка  се  попълва  в  секция  „Структури“,  подсекция  5.10 InvoiceStructure, елемент S.I.4 – AccountID?	Посочва се балансова сметка за доставчик/клиент, по която се отчитат разчетите с контрагента и съответстваща на предоставената номенклатура на сметки от НАП.
		В Source documents трябва да покажем фактурите, свързани с покупки и продажби. Всяка една от тези секции съдържат в себе си структура Invoice. Последната съдържа в себе си InvoiceLine. В този ред на мисли какво трябва да бъде попълнено срещу AccountID в двете подсекции? Моята логика е, че на ниво Invoice трябва да покажем разчета с клиент/доставчик, в който се осчетоводяват вземанията/задълженията с въпросния контрагент, а на ниво InvoiceLine трябва да покажем осчетоводяването на всяка една линия от фактурите. По този начин ще се виждат всички сметки, по които е осчетоводена фактурата, а не само част от тях. Правилна ли ми е логиката?	Потвърждаваме, че в елемент S.I.4 AccountID, част от InvoiceStructure, се посочва балансова сметка за доставчик/клиент, по която се отчитат разчетите с контрагента и съответстваща на    предоставената номенклатура на сметки от НАП. Съответно в елемент S.I.30 AccountID, част от структурата InvoiceLine, се посочва     съответната балансова/разходна/приходна сметка ), кореспондираща с елемнт S.I.4. AccountID по съответната транзакция, посочена  в  елeмент  S.I.18 TransactionID.
	S.I.20 Line	Как следва да се отчитат транспорти разходи, с които се определя себестойност на стоката?	Транспортните разходи, които се разпределят в стойността на стоката, се въвеждат на отделен ред (InvoiceLine) във файла, когато са посочени на отделен ред във фактурата.
	S.I.30 AccountID	Коя  сметка  се  попълва  в  секция  „Структури“,  подсекция  5.10 InvoiceStructure-InvoiceLine, елемент S.I.30 –AccountID?	Посочва се приходна/разходна сметка за съответният ред от фактурата, която кореспондира със сметката посочена в елемент S.I.4 AccountID. Кодът на аналитичната счетоводна сметка, трябва да съответства на предоставената номенклатура на сметки от НАП.
	S.I.36 ProductCode	Покупка на артикули с фактура – в информационната система по сметка 401 е въведена фактура №0000000001 със следните редове, които са осчетоводени по разходни сметки и артикулите не подлежат на контролирано съхранение и допълнителна отчетност: Въпрос: Допустимо ли е в PurchaseInvoices да бъдат подадени три , в които в елемент „ProductCode” стои „0”?	С указанията в т. IV.6 от Приложение №3 към заповедта   на изпълнителния директор на НАП, са дадени насоки, че се допуска закупени материали, които не подлежат на контролирано съхранение, да се подават на един ред, но не задължават лицата, подаващи файла, да подават информацията в обобщен вид. Съответно се допуска, в описания от Вас случай, информацията да се подадена на три отделни реда (InvoiceLine), с посочен „ProductCode” „0”.
	S.I.47 DebitCreditIn dicator	Какво следва да се попълва в DebitCreditIndicator?	Елементът служи за контролен ред. При попълването  му  се следва счетоводната логика при осчетоводяване на  първични счетоводни документи, т.е. дали се води до генериране на приход/разход или до намаление в размера на генериран приход/разход.

TaxInformatio nStructure	S.TI.1 TaxType S.TI.2 TaxCode	Дарение на стоки Дружество е закупило стока и е упражнило право на данъчен кредит. Впоследствие  същата  стока  е  дарена  на  община.  В  този  случай дружеството  следва  да  извърши  корекция  на  ползвания  данъчен кредит и да начисли ДДС чрез протокол. Бракуване на стоки Дружество  е  закупило  стоки  и  е  ползвало  данъчен  кредит  при покупката. Впоследствие се налага бракуване на тези стоки, за които не е приложимо ограничението за корекции по чл. 80 от ЗДДС, и съответно следва да се начисли ДДС с протокол. Моля   да   ни   укажете   кои   кодове   следва   да   се   използват   в горепосочените случаи на корекция на ползван данъчен кредит по чл. 79 от ЗДДС.	Съставения протокол, с който се определя на размера на дължимия данък в случаите на корекция по реда на чл. 79 от ЗДДС, следва да се отрази  в  подсекция  SalesInvoices,  секция  SourceDocumets,  като  в TaxInformation (елемент препращаш към структура TaxInformationStructure) се посочва код „100211 Данъчна основа на облагаемите доставки със ставка 20 %“ или код „100213 ДО на облагаемите доставки със ставка 9 %“, в зависимост от приложимата ставка. В този случай в елемент S.I.46 InvoiceLineAmount (основа се облагане) се посочва: „0“ (нула).   В структура TaxInformationStructure , елементи S.TI.1 TaxType и S.TI.2 TaxCode се посочва съответния вид и код на данъка, а в елемент S.TI.6 TaxAmount   се посочва стойността на начисления ДДС.
		Необходимо ли е изобщо да се посочва код в случаите на покупки и продажби извън обхвата на ЗДДС и, ако да – кои кодове следва да се използват?	За доставките, които са извън обхвата на ЗДДС, се посочват кодовете за неприложимост, посочени в номенклатурата за вид и код на данъка (TAX-IMP), съответно: за вид на данъка се посочва „000“, за код на данъка – „000000“.
		Здравейте, Може ли да потвърдите дали изброените по-долу кодове се отнасят за: 1. Стандартни покупки с 0% ДДС – код 100330 2. Стандартни покупки с 20% ДДС – код 100331 3. Стандартни покупки с 9% ДДС - код 100332   Ако това не са правилните кодове, може ли да ни кажете кои кодове се отнасят за стандартни покупки с 0%, 9% и 20% право на данъчен кредит?	В Дневник за покупките липсва специално обособяване на колони за право на данъчен кредит с 20% и с 9% ДДС, като логиката в SAF-T е същата. При подаване на информация за получени доставки с 20% или с 9% се прилага код 100331 „Данъчна основа на получените доставки, ВОП, получените доставки по чл. 82, ал. 2 - 6 ЗДДС, вносът, както и данъчната основа на получените доставки, използвани за извършване на доставки по чл. 69, ал. 2 ЗДДС с право на пълен данъчен кредит“. Например: При подаване на информация в предварително дефинираната структура на фактурата в секция SourceDocuments, подсекция PurchaseInvoice, при покупка с 20 на сто се подават следните данни: InvoiceLine

			InvoiceLineAmount: 1 000.00 TaxInformation:         TaxType: 100 TaxCode: 100331 TaxPercentage: 20 (елементът за приложимата ставка е опционален и може да не се подава) TaxAmount: 200.00   При покупка с 9 на сто се подават следните данни: InvoiceLine InvoiceLineAmount: 1 000.00 TaxInformation:         TaxType: 100 TaxCode: 100331 TaxPercentage: 9 TaxAmount: 90.00 Код 100330 „Данъчна основа и данък на получените доставки, ВОП, получените доставки по чл. 82, ал. 2 - 6 ЗДДС и вносът без право на данъчен кредит или без данък“ се посочва при отразяването на фактури, за които лицето  няма право на приспадане на данъчен кредит, или фактури без начислен ДДС. Код 100332 „Данъчна основа на получените доставки, ВОП, получените доставки по чл. 82, ал. 2 - 6 ЗДДС, вносът, както и данъчната основа на получените доставки, използвани за извършване на доставки по чл. 69, ал. 2 ЗДДС с право на частичен данъчен кредит“ – се посочва в случаите когато лицето, подаващо файла, съгласно чл. 73 от ЗДДС има право на частичен данъчен кредит.
		Какво следва да се попълни в елемент “Tax information”? Трябва ли да бъдат посочени ДДС номерата на всички лица, от/към които сме получили/извършили плащания – т.е. плащане по плащане?	В структурата „Tax information“ не се подават ДДС номера.
		При преглед на предоставените тестови SAF-T файлове установихме, че логиката е прекалено опростена и не покрива реалните бизнес модели за отчитане. В частта SourceDocuments → TaxInformationStructure, където се начислява сумата за данъчната основа  при  доставка  на  продукти,  липсва  кореспонденция  към	В  секция  SourceDocuments,  структурата  TaxInformationStructure  се подава: -  в  структурата  на  фактурата  (InvoiceStructure,  InvoiceLine,  елемент S.I.49 Taxinformation), която се подава за продажни и покупни фактури (SalesInvoices и PurchaseInvoices), и

		счетоводна група 30, която формира данъчната основа за правото на ползване на ДДС. Това изключва възможността за коректно отчитане на фактури с редове с различни данъчни ставки. В структурата 453 се подават отчетната стойност и начисленото ДДС по видове ставки, но не е ясно кои конкретни редове от фактурите формират     съответните     данъчни     основи.     Това     затруднява проследимостта и верификацията на данните. Моля за уточнение дали се предвижда допълнително структуриране или разширение на формата, което да позволи по-прецизно отчитане.	- в реда на структурата на плащанията (PaymentLine), където този елемент е опционален (елемент SD.P.28 Taxinformation). Логиката за подаване на информация в структурата на фактурата (InvoiceStructure) е да се подава всеки ред от фактурата отделно в структура  InvoiceLine  (от  елемент  S.I.29  до  елемент  S.I.49).  При отчитането на фактура, в която има получени/извършени доставки с приложими различни данъчни ставки, за всеки ред се посочва основата за облагане (S.I.46 InvoiceLineAmount) и данни за приложимата данъчна ставка   (S.I.49   Taxinformation,   елемент   изискващ   попълването   на структура TaxInformationStructure).
		Къде се подава информация за данъчната ставка в подсекция 5.15 TaxInformationStructure?	Информация за приложимата данъчна ставка се подава с елементи S.TI.1 и S.TI.2. в подсекция 5.15 TaxInformationStructure, където се посочва вида и кода на съответния данък?
OwnershipStru cture		Как следва да бъде подадена OwnershipStructure, ако действителният собственик е повече от един? В документацията тази структура е едноредова и няма вложена структура, която да е многоредова.	В бележките (колона М) от Приложение №2 към заповедта на изпълнителния директор на НАП, са дадени насоки за подаването на информация, когато действителния собственик е повече от един. XSD- схемата допуска елементи от S.O.2 до S.O.6 да бъдат подадени неограничен брой пъти. Обръщаме внимание, че в последната версия 1.0.1. на XSD-схемата посочените елементи са опционални.

НОМЕНКЛАТУРА	ВЪПРОС	ОТГОВОР
NC8_TARIC	В приложение 2 към Заповед на изпълнителния директор за формата и реда за  подаване  на SAF-T  и  приложения  към  нея,  откривам  два  записа  с	Кодовете по Комбинираната номенклатура КН8 2025 (Интегрираната тарифа на Европейските общности TARIC - Tarif intégré des Communautés européennes) се формират по следния начин:

		Код 1604 14 21 е код от подпозиция: Скокливи риби, докато Код 1604 14  31  е  от  подпозиция:  Тон  с  жълти  перки  —  албакор  (Thunnus albacares).
	Когато доставчик (вносител) на дружеството в документи по доставката посочи код от елемента NC8_TARIC, въведен в неговата отчетна система, който код се различава от определения от дружеството-получател код за същата стока, кой код от елемента NC8_TARIC дружеството получател следва да обвърже с номенклатурата на материалните ни запаси?	Посочва се определения код от лицето, което подава файла.
	В практиката горива и смазочни материали се доставят и разходват по два начина: - ГСМ, които се съхраняват в склад на съответното дружество се доставят и изписват по номенклатурен номер на материал (за целите на SAF-T, ще се генерира и информация за елемента NC8_TARIC); - ГСМ, които се зареждат директно в резервоарите на транспортните средства на външни бензиностанции. Тези ГСМ не се съхраняват в склад на дружеството и се изписват директно като разход за материал в сметка от гр.60. За целите на контрола на изминатите километри и изразходваните ГСМ от всяко едно транспортно средство, в модул „Транспорт“ на информационната система на дружество се въвежда информация за заредените количества ГСМ. Допустимо ли е стойността на ГСМ, които се зареждат директно в резервоарите на транспортните средства на външни бензиностанции, в секция „Изходни документи“ (SourceDocuments) в структурата на покупната фактура, да се посочи на един ред /InvoiceLine/, като в елемент S.I.36 ProductCode стойност се посочи „0”? В случай, че отговорът е „не”, какви са вашите указания?	Допуска се за материали, които не се съхраняват контролирано (каквато хипотеза се застъпва и описания от Вас случай на зареждане на външни бензиностанции), в елемент S.I.36 ProductCode да се посочи „0” – вж. в този смисъл т. IV.6. от Приложение №3 към заповедта на изпълнителния директор.
	Дружество, чийто структурни звена са изнесени извън населените места, в рамките на социалната си програма организира столово хранене, за своя персонал. В този обект готовите ястия се продават по доставната цена на вложените в тях хранителните продукти, без да се добавят режийни и да се реализира  печалба  от  тази  дейност.  Сготвените  ястия,  обичайно  се реализират в деня на тяхното приготвяне. Те не подлежат на контролирано съхранение и допълнителна отчетност.	Допуска се кодът по NC8_TARIC да се подава само за хранителните продукти от които са приготвени ястията и SAF-T файла при поискване да се подава само за тях –готовите ястия (супи, салати, десерти, др.) не фигурират в NC8_TARIC. Когато за извършените продажби няма изискване за издаване на фактура са  приложими  насоките,  дадени  в  т.  IV.5.  от  приложение  №3  към заповедта на изпълнителния директор на НАП, където се регламентира,

	Хранителните продукти от които са приготвени ястията подлежат на контролирано съхранение и допълнителна отчетност. Допустимо ли е, за целите на SAF-T, елемента NC8_TARIC да се подава само за хранителните продукти от които са приготвени ястията и SAF-T файла при поискване да се подава само за тях? Допустимо ли е, за целите на месечния SAF-T, елемента S.I.36 ProductCode в секция „Изходни документи“ (SourceDocuments), подсекция SalesInvoice за приготвените ястия да се подаде със стойност „0“ и информация за тях да не се подава в секция MasterFiles, подсекция “Products”? В случай, че отговорът е „не“, какви са вашите указания?	че тази информация може да се подава на обобщено/агрегирано ниво  - в тези случаи, се допуска в I.36 ProductCode в секция „Изходни документи“ (SourceDocuments), подсекция SalesInvoice да се посочи код „0“. В случаите когато за продажбата на ресторантьорска услуга е издадена фактура, в елемента S.I.36 ProductCode в секция „Изходни документи“ (SourceDocuments),  подсекция  SalesInvoice  за  приготвените  ястия  се подава съответния код от системата на лицето, което подава файла. Същият код се мапира в секция MasterFiles, подсекция “Products” с код „0“ – отговарящ на код за неприложимост, съгласно номенклатурата NC8_TARIC. Например:
	Готовите  ястия  в  ресторантите  се  приготвят  по  заявка  в  момента  и обичайно се реализират в деня на тяхното приготвяне. Те не подлежат на контролирано съхранение и допълнителна отчетност. Хранителните  продукти  от  които  са  приготвени  ястията  подлежат  на контролирано съхранение и допълнителна отчетност. Допустимо ли е, за целите на SAF-T, елемента NC8_TARIC да се подава само за хранителните продукти от които са приготвени ястията и SAF-T файла при поискване да се подава само за тях? Допустимо ли е, за целите на месечния SAF-T, елемента S.I.36 ProductCode в секция „Изходни документи“ (SourceDocuments), подсекция SalesInvoice за приготвените ястия да се подаде със стойност „0“ и информация за тях да не се подава в секция MasterFiles, подсекция “Products”? В случай, че отговорът е „не“, какви са вашите указания?
	В нашите база данни разполагаме с информация за кодовете от КН8 само за част от нашата номенклатура. Това е обусловено от съответствието с данните, изискуеми  по действащата нормативна уредба за движенията на стоки в рамките на Европейския съюз. За останалата част от нашата номенклатура ние имаме нужда от вашето  съдействие. Целта ни е  да получим ясна и актуална информация за съответните кодове от КН8, които са относими за продуктите от сферата на фармацевтичния бизнес и лекарствените продукти. Нашето питане е по принцип и касае връзката между код по КН и например национален   номер   на   лекарствения   продукт   от   ИАЛ   или   друг	При  подаването  на  информация  със  Стандартния  одитен  файл  за данъчни   цели   (SAF-T)    в    подсекции   Products    и   PhysicalStock задължително   се   посочва   съответстващия   код   на   продуктите   от номенклатура NC8_TARIC, която е неразделна част от схемата на SAF- T.  Кодът  за  неприложимост  „0“  се  използва  в  случаите,  в  които продуктът не е посочен в комбинираната номенклатура. Националната агенция за приходите не разполага с данни, които могат да послужат за еднозначното обвързване на кодовете от комбинираната номенклатура с други кодове.

	идентификатор от националните регистри на лекарствените продукти, който биха спомогнали за коректното идентифициране на код по КН като ATC-код, Регистрационен номер в ИАЛ, INN, или др. По аналогичен начин стои въпроса продуктите подлежащи на регистрация в БАБХ (хранителни добавки, детски храни и др.), т.е.  връзка между Код по КН на ЕС и регистрационен номер в БАБХ или др. институция. В този смисъл, бихме оценили високо, ако е възможно да ни предоставите съответна информация, ако  това е възможно, или насоки  за това, как можем  да  получим  релевантна  информация  за  КН8,  например  чрез Дирекция "ИНТРАСАТ" или друг източник, който разполага с данни еднозначно обвързващи кода от   КН с други уникални кодове на регистрация в съответните национални институции, които поддържат регистри на тези продукти. На тази база ще ни бъде възможно да продължим с обвързването на кодовете със съответните продукти, като същевременно спазваме законовите изисквания.	На страницата на Националния статистически институт е публикувана подробна   информация   по   отношение   на   Статистическа   стокова номенклатура на Европейския съюз (КН-2025), вкл. са публикувани релационни  връзки  (обвързване)  на  КН-2025  с  Класификация  на продуктите   по   икономически   дейности,   Широки   икономически групировки и др. Информацията може намерите на уеб-адрес: https://www.nsi.bg/issc/NSIExt/correspTableList;jsessionid=hVj- 1gpGzoOLG6b54Wk2ZC2lonLmMxr8c9MWVzsl.issc-prod- app1?idObj=6489&lang=1&locale=bg
NRA Nom of Accounts	Във връзка с Приложение №3 към Формат на Стандартен одитен файл за данъчни цели в т.3 Секция „Счетоводни записи“ пише, че данните на счетоводните  операции  се  записват  в  съответствие  с  номенклатура  на счетоводните сметки,която е неразделна част от схемата на SAF-T. Това означава ли,че счетоводния сметкоплан на всички фирми е унифициран задължително или може да използваме индивидуален сметкоплан,защото ние използваме такъв /номерата на счетоводните сметки са изместени с една цифра надолу,примерно сметка „Каса в левове“ при нас е номер 500,а не 501/. При възможност да ползваме индивидуален сметкоплан трябва ли да уведомяваме НАП предварително за ползването на такъв?	SAF-T съдържа номенклатура на счетоводни сметки, целта на която е да гарантира получаване на стандартизирана информация от всички задължени лица, независимо от използвания от тях сметкоплан. Съгласно чл. 11, ал. 1, т. 5 от Закона за счетоводството при изграждането и поддържането на счетоводната система предприятията осигуряват прилагане на утвърдения от ръководителя на предприятието индивидуален сметкоплан – предвид което със Стандартния одитен файл за данъчни цели не се налага на предприятията да използват конкретен сметкоплан. Със Стандартния одитен файл за данъчни цели (SAF-T) се подaва информация за най-ниско ниво на аналитичните счетоводните сметки във воденото счетоводство от лицето, подаващо файла, мапирани към номенклатурата за сч. сметки на НАП. Например:
			AccountID	TaxpayerAccountID	AccountDescription

			501	500001	Каса обект 1
			501	500002	Каса обект 2
			501	500003	Каса обект 3
	В т. 2.1 „GeneralLedgerAccounts“ се изисква посочване както на вътрешните сметки на данъчно задълженото лице, така и на съответстващите от номенклатурата на НАП. В т. 3 „GeneralLedgerEntries“ се използват и двете сметки, но в т. 4 „SourceDocuments“ се допуска само сметката от номенклатурата на НАП. Това създава предпоставки за грешни съпоставки и разминавания при отчитане, особено когато: o             ERP системата използва сметки от номенклатурата на НАП; o             Счетоводната програма използва вътрешни сметки, които могат да  се  различават  в  зависимост  от  счетоводната  логика  (например: отписване в 601 вместо 302, или заприходяване в 304 вместо в сметка от група 20). Ако ERP системата предоставя данни към счетоводния софтуер със зададена сметка по номенклатурата на НАП, но счетоводителят реши да използва различна вътрешна сметка при осчетоводяване, това може да доведе до несъответствия между записите в т. 3 „GeneralLedgerEntries“ и т. 4 „SourceDocuments“. Като се има предвид, че повечето ERP системи осчетоводяват първичните документи, считаме за целесъобразно в редовете на SourceDocuments да се прилага същата логика, както в GeneralLedgerEntries – т.е. да се допуска използването и на вътрешната сметка на предприятието. Това би осигурило по-голяма проследимост и съгласуваност между системите.	Схемата на Българския SAF-T е разработена на база стандарта на ОИСР. Номенклатурата цели единствено получаване на стандартизирана информация от счетоводната отчетност на лицата, която да подлежи на последваща   автоматизирана обработка от НАП с оглед постигане целите на агенцията. С оглед на което логиката на стандартния одитен файл за данъчни цели не изисква предприятията да променят организацията си на счетоводното отчитане, а само да се подаде информация за аналитичната счетоводна сметка използвана от лицето, което подава файла,  обвързана към номенклатура на НАП.
	Допустимо ли е за отчитане на „Резерв от преоценка(актюерски печалби и загуби)”,  отчитан  през  собствения  капитал,  формиран  по  реда  на  СС 19/МСФО  19,  да  се  използва  сметка  „122  Неразпределена  печалба  от	Мапирането към сметка от номенклатурата се извършва по преценка на предприятието, подаващо файла. При мапирането се посочва сметка от номенклатурата на НАП и номер и наименование на съответстващата

	минали  години“  от  елемент  „NRA  Nom  of  Accounts“?  В  случай,  че отговорът е „не“, какви са вашите указания?	аналитична сметка от воденото счетоводство на лицето, подаващо файла. Считаме, че сметка от счетоводството на лице с наименование „Резерв от преоценка(актюерски печалби и загуби)” е по-удачно да се мапира със сметка „119 Други резерви“.
	Допустимо ли е, за отчитане на Актюерски печалби и загуби, отчитани в текущия резултат по реда на СС 19/МСФО 19, да се използва сметка „60909 Други разходи“ от елемент „NRA Nom of Accounts? В случай, че отговорът е „не“, какви са вашите указания?	Считаме, че сметка от счетоводството на лице, в която се отчита актюерски загуби е по-удачно да се мапира със сметка „604 Разходи за заплати (възнаграждения)“. Искаме да отбележим, че при подаването на информация в подсекция GeneralLedgerAccounts една сметка от номенклатурата на НАП може да бъде мапирана с повече от една сметка от счетоводството лице, което подава файла. Например:
	Допустимо ли е, за отчитане на дългосрочните задължения към персонала при пенсиониране, формирани по реда на СС 19/МСФО 19, да се използва сметка „429 Други разчети с персонала и съдружниците“ от елемент „NRA Nom of Accounts“? В случай, че отговорът е „не“, какви са вашите указания?	Считаме, че предложеното мапиране е допустимо.
	Допустимо ли е, за отчитане на вземанията от доставчици по аванси – свързани лица, да се използва сметка „402 Вземания от доставчици по аванси“ от елемент „NRA Nom of Accounts“,въпреки че разчетът е със свързано лице? В случай, че отговорът е „не“, какви са вашите указания?	Считаме, че предложеното мапиране е допустимо, като следва да се припомни, че една сметка от номенклатурата може да бъде мапирана с повече сметки от счетоводството на лицето.

	Допустимо ли е, за отчитане на задълженията към клиенти по аванси – свързани лица, да се използва сметка „412 Задължения към клиенти по аванси“ от елемент „NRA Nom of Accounts“, въпреки че разчетът е със свързано лице? В случай, че отговорът е „не“, какви са вашите указания?
	Допустимо ли ,е за отчитане на разчетите с общините по реда на ЗМДТ, за такси определени с общински наредби и тарифи на министерства и др. бюджетни организации, да се използва сметка „459 Други данъчни разчети с бюджета“ от елемент „NRA Nom of Accounts“? В случай, че отговорът е „не“, какви са вашите указания?	Считаме, че предложеното мапиране е допустимо.
	Коя сметка от елемент „NRA Nom of Accounts“ да се използва за отчитане на разчетите с ДДС по ВОП?	При мапирането на сметки, които се използват за начисляване на ДДС при ВОП и правото на ползване на данъчен кредит, е допустимо да се използват сметки от номенклатурата на НАП „4531 Начислен данък върху добавената стойност за покупките“ и „4532 Начислен данък върху добавената стойност за продажбите“.
	Коя сметка от елемент „NRA Nom of Accounts“ да се използва за отчитане на разчети с осигурители по неизползвани отпуски?	Допустимо е да се използва сметка от номенклатурата на НАП „469 Други разчети с осигурители“.
	Коя сметка от елемент „NRA Nom of Accounts“ да се използва за отчитане на разходите за лихви и глоби по данъчни задължения – сметките от група „Разходи за данъци, такси и други подобни плащания“ или „60902 Разходи за глоби, санкции и неустойки“? Коя сметка от елемент „NRA Nom of Accounts“ да се използва за отчитане на разчетите за лихвите и глобите по „Данък върху източника“ – „455 Разчети за данъци при източника“ или „459 Други данъчни разчети с бюджета“? Коя сметка от елемент „NRA Nom of Accounts“ да се използва за отчитане на разчетите за лихви и глоби по „Данъци върху разходите“ – „456 Разчети за данъци върху разходите“ или „459 Други данъчни разчети с бюджета“?	Сметките, в които се отчитат административно наказателни санкции, е допустимо да се мапират към сметка „60902 Разходи за глоби, санкции и неустойки“. Сметките за разходи за лихви е допустимо да се мапират към сметка „60902 Разходи за глоби, санкции и неустойки“.
	Допустимо ли е наличности (задължението е покрито и салдото е положително) по издадени на дружеството кредитни карти, да се посочват в  сметките  от  „група  50:  Парични  средства“,  вместо  по  сметка  „153 Кредитни карти“ от елемент „NRA Nom of Accounts“? В случай, че отговорът е „не“, какви са вашите указания?	Считаме, че предложеното мапиране е допустимо.