НАП отговаря: официалните въпроси и отговори за 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 от ТЗ се регламентира, че всеки търговец е длъжен да води счетоводство, в което отразява движението на имуществото на своето предприятие. Това движение се регистрира в хронологичен ред. С оглед на което търговецът следва да води счетоводство за движение своето имущество, вкл. и на това в клона и е негова отговорност да обединява, представя, декларира и оповестява информацията, съдържаща се в счетоводните регистри. Предвид гореизложеното с подаването на стандартния одитен файл за данъчни цели се подава и цялата информация, която е и в счетоводството на предприятието и в неговите клонове.

Официален въпрос

Моля да посочите кои счетоводните записвания се подават в секция 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 г.

Официален въпрос

Ние разбираме, че нормата на чл.71к, ал. 7 от ДОПК за отстраняване на несъответствия ще започне да се прилага след изтичането на 12 -месечния период за корекция на вече подадени SAF-T за 2026 г. - Може ли кратко разяснение по този текст? - Конкретно за „АЛФА“ АД, кой ще е първият период, за който допуснати несъответствия в подаден SAF-T следва да бъдат отстранени в 7-дневен срок ?

Официален отговор на НАП

Съгласно условията на § 17, ал. 2 от ПЗ) към ЗДБРБ 2025 лицата, за които задължението за подаване на стандартния одитен файл за данъчни цели възниква в етапите по ал. 1 от същата норма, ще могат да подават коригиращи файлове за първите дванадесет месеца. С лед изтичане на този период, при подаване на SAF -T файл в законово определените срокове и установяване на несъответствия между формата и съдържанието на подадената информация и изискванията за попълването на стандартния одитен файл за данъчни цели, лицето се уведомява да отстрани несъответствията в 7 - дневен срок – съгласно изискванията чл. 71к, ал. 7 от ДОПК.

Официален въпрос

Ако фирма подава файл за Януари в дадения от НАП срок и през Април реши да го предаде повторно с корекции: - Ако през м. Март НАП сте издали нова версия на файла. Данните за м. Януари с коя версия на файла трябва да бъдат предадени и валидирани – с версията, която е била към Януари или с новата версия от м. Март? - Ако Контрагент през Февруари си смени примерно адресната регистрация или ЕИК – какво трябва да предадем – данните за контрагента към м. Януари или актуалните към момента данни?

Официален отговор на НАП

В хипотезата на §17, ал. 2 от ПЗР към ЗДБРБ 2025 и чл. 71к, ал. 5 от ДОПК, когато се извършва корекция на вече подадени файлове, новите файлове следва да съответстват на XSD-схемата, която е актуална към момента на подаване на коригиращите файлове. При извършването на корекции на вече подадени стандартни одитни файлове се подава информация за контрагентите, която е актуална към момента на подаване на информацията.

Официален въпрос

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

Официален отговор на НАП

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

Официален въпрос

Бих искала да Ви попитам за следната информация: във връзка със задължителното въвеждане на SAF -T от следващата година предприятия за преработка на храни изискват от техен доставчик на хранителни суровини във всички негови документи за доставка (фактури, стокови разписки, приемо -предавателни протоколи, търговски документи, спецификации, сертификати за качество и др.) да включва за всеки доставян артикул съответния код по комбинираната номенклатура. Но търговските документи, спецификациите на продуктите и с ертификатите за качество не са счетоводни документи. Бихте ли ми казали дали доставчикът е задължен да включи този код в несчетоводните си документи?

Официален отговор на НАП

С Глава осма „б“ от ДОПК, е въведено задължение за подаване на SAF -T, определени са задължените лица, които следва да подават файла, както и съдържанието, сроковете и начина му на подаване. С ПЗР към ЗДБРБ 2025, се определят предприятията и етапите за въвеждане на задължението за подаване на стандартен одитен файл за данъчни цели (SAF-T). Със стандартния одитен файл за данъчни цели предприятията ще подават данни относно икономическата дейност и счетоводната отчетност на задълженото лице, подавани в стандартизиран формат. С файла се предоставя информация за закупувани и продавани от предприя тията стоково -материални запаси, като продуктовият код използван в информационната система на лицето, подаващо файла, следва да се обвърже с код от комбинираната номенклатура КН8-2025 (TARIC). Съгласно §17, ал. 1 от ПЗР към ЗДБРБ 2025, задължението за първоначално подаване на SAF -T възниква в периода от 01.01.2026 г. до 01.01.2030 г. за различни категории предприятия. Първоначално задължението възниква за предприятията, които са големи по смисъл а на чл. 19, ал. 1 от ЗСч към 31 декември 2023 г. и отговарят на посочени в горецитираната норма условия. От 01.01.2030 г. задължение за подаване на SAF-T ще имат всички предприятия, които са регистрирани по ЗДДС. С оглед на гореизложеното, ако за Вашето предприятие не възниква задължение за подаване на SAF-T от 01.01.2026 г., то за Вас не възниква и задължение да използвате комбинираната номенклатура за целите на стандартния одитен файл за данъчни цели от посочената дата. Предвид изложеното в запитването Ви, че Ваши клиенти, за които от 01.01.2026 г. възниква задължение за подаване на SAF-T , респ. и за подаване с него на кодовете от комбинираната номенклатура КН -2025 (TARIC), изискват от Вас да предоставяте тези кодове за продаваните от Вас продукти, следва да се има предвид, че това е обект на частноправни търговски взаимоотношения между икономически оператори, по които НАП не може да вземе отношение.

Официален въпрос

Относно секция „SourceDocuments“. В дадена фирма има счетоводен софтуер на един производител и складова програма на друг производител. Складовата програма има разработен интерфейс, който подава детайлна информация за движението на стоките към счетоводния софтуер. Допуска ли се информацията за движение на стоките да си изведе от счетоводните записи в счетоводния софтуер или е необходимо да се изведе от първоизточника?

Официален отговор на НАП

Съгласно чл. 71и, ал. 1 от ДОПК SAF -T съдържа данни относно икономическата дейност и счетоводната отчетност на задълженото лице, подавани в стандартизиран формат. Задължението е да се експортира информация от използваните софтуери, която да се подаде към Н АП в стандартизиран вид, няма изискване за източника на експортиране. Допустимо е информацията, която се подава със стандартния одитен файл за данъчни цели него, да е експортирана от една или повече информационни системи, но при спазване на изискванията за подаване на данни в съответните секции, подсекции и елементи на файла.

Официален въпрос

Относно секция „SourceDocuments“. Примерно подсекция „Payments“ – ако клиентът не води в софтуер плащанията, касова книга си я поддържа на хартиен носител. По какъв начин да се подава информация в съответната секция, ако за нея няма софтуерен продукт?

Официален отговор на НАП

Съгласно изискванията на чл. 71и, ал. 2, т. 4 от ДОПК със стандартния одитен файл за данъчни цели се подава информация за данни за плащанията, включително за начина на плащане. Съгласно т. I.1.4. от Приложение №3 към заповедта на изпълнителния директор, из дадена на основание чл. 71к, ал. 4 от ДОПК, подсекция Payments, секция SourceDocuments, съдържа информация за документи за извършени/получени плащания, включително данни за начина на плащане и свързани сметки, период, идентификатор на транзакцията, дата на трансакцията, описание и др. Съобразно изложеното със SAF-T следва да се подава информация за плащанията, която да е в съответствие с указанията за подаване на данните, дадени в Приложения №2 и №3 от заповедта на изпълнителния директор на НАП. Искаме да обърнем внимание, че съгласно изискванията на чл. 11, ал. 1, т. 1 от ЗСч при изграждането и поддържането на счетоводната система предприятията осигуряват всеобхватно хронологично регистриране на счетоводните операции. В тази връзка ако при осъществяване на счетоводството се използва счетоводен софтуер, то в него следва да се отразяват получени и извършени разплащания.

Официален въпрос

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

Официален отговор на НАП

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

Официален въпрос

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

Официален отговор на НАП

В подаваните със SAF-T данни следва да не е налична информация, която представлява банкова или застрахователна тайна по смисъла на ЗКИ и КЗ . Тези данни следва да се подават на агрегирано/обобщено ниво. Когато за извършени доставки няма задължение за издаване на фактура и същите не представляват банкова или застрахователна тайна е допустимо също да се подават на агрегирано ниво, по аргумент на т. IV.5 от Приложение №3. Информацията, представляваща банкова тайна , се подава в отделните секции на файла както следва: - GeneralLedgerEntries: Отчитане на агрегирано ниво по видове инструменти; - SourceDocuments.SalesInvoice: Отчитане на агрегирано ниво; - SourceDocuments.PurchaseInvoice: Отчитане на агрегирано ниво; - SourceDocuments.Payments: Отчитане на агрегирано ниво на лихви, такси, комисионни – не се подава информация за изплащане на кредити, погасяванията им, приемане на депозити и др., свързани с движения на средства на клиенти на банката/застрахователя. Информацията, която не представлява банкова тайна, се подава в отделните секции на файла както следва: Секция/подсекция Задължение за издаване на ф-ра Няма издадена фактура GeneralLedgerEntries индивидуализиране на всяка доставка агрегирано SD.SalesInvoice индивидуализиране на всяка доставка агрегирано SD.PurchaseInvoice индивидуализиране на всяка доставка агрегирано SD.Payments индивидуализиране на всяка доставка агрегирано При подаване на информация на агрегирано ниво за идентификатор на контрагента се посочва ЕИК на лицето, подаващо файла.

Официален въпрос

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

Официален отговор на НАП

Когато за извършени доставки няма задължение за издаване на фактура и същите не представляват банкова е допустимо също да се подават на агрегирано ниво, по аргумент на т. IV.5 от Приложение №3 към заповедта на изпълнителния директор на НАП. В тази връзка, тъй като информацията не попада в обхвата на банковата тайна по смисъла на ЗКИ, същата информация може да бъде подава и на транзакционно ниво за всяка операция. По отношение на начина на агрегиране на информация, банката следва да предприеме такъв подход, който би представил данните най -точно и вярно и в съответствие с приетите счетоводни политики на предприятието.

Официален въпрос

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

Официален отговор на НАП

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

Официален въпрос

„АЛФА“ ЕООД, като част от международна група, ще имплементира нова ERP система през 2027 г., въпроса ни е дали ще се приеме за 2027 г. два отделни файла от старата ERP система и новата ERP система за SAF -T файл, защото промяната на ERP системата ще стане около средата на годината и нямаме опция да обединим даните от старата и новата система, за да се предостави само един файл за движението на материалите и стока, както и за ДМА, който трябва да бъдат на годишна база или при поискване за стоки и материали.

Официален отговор на НАП

SAF-T, съдържащ информация за наличности и движение на материални запаси, се подава при поискване от орган по приходите в определен от него срок (чл. 71к, ал. 3 от ДОПК). Съгласно т. II от Приложение №3 към заповедта на изпълнителния директор, с която се определят редът и форматът за подаване на SAF -T, подаването на SAF-T при поискване от орган по приходите за движение и наличности на стоково -материални запаси ще започне от 01.07.2026 г. С оглед на горе изложеното, ако след тази дата Ви бъде изи скано да предоставите посочения файл за период, обхващат работата с две различни системи, ел. услуга ще позволи подаването на два различни файла, които се отнасят за два различни периода. Например: При изискване за подаване на файл за движение и наличности на материали за м. 07.2026 г., то може да се подаде един файл за движенията от 01.07.2026 г. до 15.07.2026 г. и един от 16.07.2026 г. до 31.07.2026 г. Годишният SAF -T, съдържащ информацията за наличности и движение на дълготрайни активи, се подава в срока за подаване на годишната данъчна декларация по чл. 92 от ЗКПО (чл. 71к, ал. 2 от ДОПК) – до 30.06. на годината, следваща годината, за която се отнася ф айлът. При подаване на годишен SAF -T файл, се подава цялата информация, съгласно утвърдената структура на файла и правилата за подаването му. Структурата на годишният файл изисква подаването на информация за цяла отчетна година – с оглед на което няма как да бъде подаден на части.

Официален въпрос

Във връзка със спецификата на дейността си, „ АЛФА“ ЕАД издава към своите клиенти фактури от три различни системи, две билингови и една ERP. Издаваните документи са два вида фактури: търговски фактури (за продажба на стоки) и билингови фактури (месечни такси). За цeлите на счетоводната си отчетност, данните с документи/фактури издадени от двете билингови системи на дружеството се мигрират към ERP системата на определени цикли за билинговите фактури и ежедневно за търговските фактури. При миграцията на данни: Търговските фактури издавани от дружеството, както на бизнес клиенти така и на физически лица, мигрират от двете билингови системи към ERP системата с конкретен номер, дата и позиция/ред за всяко устройство/артикул. Не се мигрират данни за конкретен клиент, а данните се подават и записват в ERP по един „dummy“ клиент. Т.е. в ERP се съдържа информация за номер, дата и позиция на документ, но не и за отделен клиент, като данните са записани по един клиент „……..“. Билинг фактури издавани от дружеството, както на юридически, така и на физически лица, мигрират от двете билингови системи към ERP без информация за номер, дата и позиция/ред във всяка фактура, а агрегирани по вид услуга. Например 100 фактури за един вид услуга/и се обединяват в един запис, който се записва в ERP отново под „dummy” клиент. Билинг фактурите са огромен набор от документи, общо от порядъка на 1,5 – 1,6 млн. броя фактури месечно, данните от които мигрират към ERP обединени. Въпроси: 1. В одиторския файл за данъчни цели SAF-T, може ли да се рапортуват данни само от ERP система, в която информацията за целите на счетоводната отчетност обединява данни от всички системи на телекома, по описания по-горе принцип? 2. По отношение на търговските фактури: Допустимо ли е в SAF-T да се рапортуват данните от ERP, с информация за всяка една фактура, както бизнес така и физически лица, с конкретен номер и дата на фактура, но без данни за клиент /по общ dummy клиент/? 3. По отношение на билинг фактурите, които представляват месечните такси за услуги: Допустимо ли е да се рапортуват, както за бизнес клиенти, така и за физически лица, данните обединено, без информация за клиент, номер фактура, позиция и т.н.? Може ли те да се рапортуват обединено?

Официален отговор на НАП

С т. ІV.5 от Приложение №3 към заповедта на изпълнителния директор на НАП, с която се определят редът и форматът за подаване на SAF -T, се дават насоки, че в случаите когато няма законово изискване за издаването на фактура, вкл. и в случаите при които фактура е издадена по желание на клиента или по инициатива на доставчика, данни за доставките може да се подават на агрегирано/обобщено ниво. Предвид гореизложеното, в случаите на издаване на фактури към данъчно незадължени физически лица, информацията за извършените продажби може да се подаде обобщено с отчета за извършените продажби в различните секции/подсекция на файла – в секция GeneralLedg erEntries и в секция SourceDocuments, подсекции SalesInvoices и Payments. По отношение фактурите към юридически лица, издадени в управляваните от Вас billing-системи, в действащата нормативна уредба не са въведени изисквания за поотделно осчетоводяване на първичните счетоводни документи. Възможността за извършване на агрегирани счетоводни записвания произтича от чл. 4, ал. 4 от ЗСч, съгласно който регистърът е носител на хронологично систематизирана информация за стопански операции от първични и/или вторични счетоводни документи. Поради това са допустими всички организационни и технически решения, които гарантират спазването на изискванията на ЗСч и осигуряват проследимост, пълнота, надеждност и проверимост на счетоводната информация. Изискванията към счетоводните системи се свеждат до способността им да осигуряват съдържание, съх ранение и възпроизвеждане на информацията по начин, който осигурява спазването на принципите по чл. 26, ал. 1 на ЗСч или принципите и изискванията на приложимите счетоводни стандарти. При обработката на счетоводната информация следва неизменно да бъде спаз ван и принципът на вярно и честно представяне. Определянето на броя, вида и взаимовръзката между използваните счетоводни системи е в компетентността на ръководителя на предприятието. Във връзка с гореизложеното, съставянето на агрегирани счетоводни записвания, обхващащи еднородни първични счетоводни документи, е допустимо съгласно счетоводното законодателство, при условие че е налице проследимост между обобщения запис и отделните първични документи, както и възможност при необходимост да бъде предоставена пълната информация независимо от формата и носителя, в който се съхранява. Предвид изложеното по -горе агрегираният счетоводен запис е допустимо да се посочи в секция GeneralLedgerEntries при условие, че е налице проследимост между него и отделните първични документи, отразени в подсекции SalesInvoices и Payments на секция SourceD ocuments – т.е. уникалният идентификатор (GL.9 TransactionID) на обобщения счетоводен запис в секция GeneralLedgerEntries следва да се посочва и да съответства на подадените в елементи S.I.18 TransactionID данни за всеки един от отразените в подсекции Sale sInvoices и Payments на секция SourceDocuments първични счетоводни документи. Обръщаме отново внимание, че всички фактури за продажби, които не са обхванати от изключението в т. ІV.5. от Приложение №3 към заповедта на изпълнителния директор на НАП, следва да се подадат в секция SourceDocuments, подсекция SalesInvoices, като за тях следва да се попълнят всички задължителни елементи в структура InvoiceStructure. До колкото в запитването Ви е посочено дали е допустимо първичните документи да се отразяват с номер, различен от този, който е генериран при издаването им, Ви уведомяваме, че при подаването на информация за получена/издадена фактура в S.I.1 InvoiceNo от с труктура InvoiceStructure следва да се посочи номерът на съответния документ, както е изписан върху него. По отношение на въпроса Ви, свързан с подаването на данни за т. нар. „dummy“ клиент, Ви уведомяваме, при подаването на агрегирана информация в различните секции на файла се посочва идентификаторът на предприятието, подаващо файла. Когато се подават транзакции, свързани с конкретен клиент/доставчик, в елементи CustomerID и SupplierID следва да се посочва уникалния идентификатор на Вашият контрагент.

Официален въпрос

Фактури за покупки на материали, които не се заприходяват в склад на дружеството, а директно се отнасят в себестойността (като разход), могат ли да се отчитан обобщено на един или няколко реда, като за „ProductCode“ се посочва „0“ и не се обвързва с код, съгласно комбинираната номенклатура.

Официален отговор на НАП

Съгласно указанията в т. IV.6 от Приложение №3 към заповедта на изпълнителния директор на НАП, с която се определят редът и форматът за подаване на SAF-T, при отразяването на извършени разходи за периода за артикули , неподлежащи на контролирано съхранение и допълнителна отчетност поради естеството на разхода и отчетени директно като разход в момента на покупката, както и текущи разходи за периода, през който са извършени, се допуска в секция „Изходни документи“ (SourceDocuments), в структурата на покупната фактура не се посочва код на продукта от информационната система на лицето, подаващо файла. В тези случаи се допуска документът (фактурата) да се посочи на един ред /InvoiceLine/, кат о в елемент S.I.36 ProductCode задължително се подава стойност „0“ (нула) и в елемент S.I.45 Description се посочва описание на отчетения текущ разход, съгласно данните в информационната система на задълженото лице. Към „директен разход“ могат да се отнесат продукти, които не участват в себестойността на продукцията, а са част от административните разходи, съгласно т. 8.2 от СС 2 и т. 16 от МСС 2. С оглед на гореизложеното разходи за покупки на материали, стойността на които се отнася при определянето на себестойност та на произвежданата продукция , се посочват на отделен ред в структурата InvoiceLine във файла, като в елемент S.I.36 ProductCode се посочва съответния продуктов код от системата на предприятието , подаващо файла. Посоченият продуктов код следва да се подаде и в секция MasterFiles, подсекция Products, където задължително следва да се обвърже с ъс съответния код от номенклатурата, работен ли ст „ NC8_TARIC“ от Приложение №2 към заповедта на изпълнителния директор на НАП (Комбинирана номенклатура КН8-2026).

Официален въпрос

Структурата на счетоводната сметка в информационната системата е следната: Ако сметката не е обектно ориентирана или е сметка в Централа, в полето “Обект” се поставят три звезди (***). Кодът на аналитичните признаци може да бъде число, дата или текст. Максималният брой знаци за една сметка, ако са попълнени всички елементи до допустимата дължина, е повече от 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: сметки, в които конкретен аналитичен признак е отделна аналитична сметка от номенклатурата на НАП се подават с код на сметка, състоящ се от номер на сметката, следван от кода на обекта и кода на конкретния аналитичен признак, а останалите сметки се подават с код на сметка, състоящ се от номер на сметката и код на обект.

Официален отговор на НАП

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

Официален въпрос

Въпрос 1: Във файл SAF -T_BG_Structure_Definition_V_1.0.1, MF.GLA.1 колона Бележки за елемент Accounts е посочено „Подават се всички сметки от утвърдения от предприятието сметкоплан, независимо от нивото на аналитичност”. Със SAF-T се подава информация за най -ниско ниво на аналитичните счетоводните сметки във воденото счетоводство от лицето, подаващо файла, мапирани към номенклатурата за сч. сметки на НАП. Не следва да се подават информация за аналитични признаци, които са свързани с Утвърдения от предприятието сметкоплан е на синтетично ниво, с указани кодове на аналитична структура - 401 *** 04Контрагент, 05валута, 303 *** 01Склад, 02код на продукт, 03 поръчка. Отделните елементи във всяка аналитичната структура се въвеждат и допълват в процеса на работа. Правилно ли разбираме, че за посочените в примера сметки в GeneralLedgerAccount трябва да подадем информация с 0,00 начално и крайно салдо за всички поръчки и номенклатурни номера които са въведени някога в системата и нямат движение, както и за всички въведени контрагенти през годините, което ще е огромно като обем ? Въпрос 2: Допустимо ли е за посочения по -горе пример следното попълване на елемент TaxpayerAccountID в подсекции GeneralLedgerEntries и GeneralLedgerAccount тъй като на синтетично ниво сметката е мапирана към една сметка на НАП? В случай, че отговорът е не, какви са вашите указания? <nsSAFT:TaxpayerAccountID>303***</nsSAFT:TaxpayerAccountID> <nsSAFT:TaxpayerAccountID>401***</nsSAFT:TaxpayerAccountID> Въпрос 3: Допустимо ли е в елемент TaxpayerAccountID на подсекции GeneralLedgerEntries и GeneralLedgerAccount да бъде подадена информация на аналитично ниво само за сметки, за които на аналитичното ниво има различно мапиране към сметки на НАП, а всички останали сметки да бъдат подадени на синтетично ниво?

Официален отговор на НАП

Със SAF-T се подава информация за най -ниско ниво на аналитичните счетоводните сметки във воденото счетоводство от лицето, подаващо файла, мапирани към номенклатурата за сч. сметки на НАП. Не следва да се подават информация за аналитични признаци, които са свързани с Утвърдения от предприятието сметкоплан е на синтетично ниво, с указани кодове на аналитична структура - 401 *** 04Контрагент, 05валута, 303 *** 01Склад, 02код на продукт, 03 поръчка. Отделните елементи във всяка аналитичната структура се въвеждат и допълват в процеса на работа. Правилно ли разбираме, че за посочените в примера сметки в GeneralLedgerAccount трябва да подадем информация с 0,00 начално и крайно салдо за всички поръчки и номенклатурни номера които са въведени някога в системата и нямат движение, както и за всички въведени контрагенти през годините, което ще е огромно като обем ? Въпрос 2: Допустимо ли е за посочения по -горе пример следното попълване на елемент TaxpayerAccountID в подсекции GeneralLedgerEntries и GeneralLedgerAccount тъй като на синтетично ниво сметката е мапирана към една сметка на НАП? В случай, че отговорът е не, какви са вашите указания? <nsSAFT:TaxpayerAccountID>303***</nsSAFT:TaxpayerAccountID> <nsSAFT:TaxpayerAccountID>401***</nsSAFT:TaxpayerAccountID> Въпрос 3: Допустимо ли е в елемент TaxpayerAccountID на подсекции GeneralLedgerEntries и GeneralLedgerAccount да бъде подадена информация на аналитично ниво само за сметки, за които на аналитичното ниво има различно мапиране към сметки на НАП, а всички останали сметки да бъдат подадени на синтетично ниво? номер на документ, дата на документ, поръчка. Подават се тези аналитични признаци, по които се формират партиди. В подсекция GeneralLedgerAccounts се подават тези счетоводните сметки, които имат салдо, различно от нула, в началото и в края на отчетния период и тези, в които има дебитни или кредитни обороти през отчетния период. Също така в подсекция GeneralLedgerAccounts, секция MasterFiles, се подават тези аналитичности на счетоводните сметки, които са подадени в секция GeneralLedgerEntries, без да се подава синтетичната сметка. Например: През периода в секция GeneralLedgerEntries са отразени движения в аналитични сметки: 303***110850536; 303***110850537 и 303***110850538. В този случай в подсекция GeneralLedgerAccounts, секция MasterFiles, се подават сметки: 303***110850536; 303***110850537 и 303***110850538 и не се подава синтетична сметка 303 и нейни аналитични признаци, които не са подадени в GeneralLedgerEntries. В подсекция GeneralLedgerAccounts се подават данни както следва: AccountID TaxpayerAccountID AccountDescription 303 303***110850536 Наименование на синтетичната сметка и аналитичните и признаци 303 303***110850537 Наименование на синтетичната сметка и аналитичните и признаци 303 303***110850538 Наименование на синтетичната сметка и аналитичните и признаци

Официален въпрос

Допустимо ли е една счетоводна сметка от сметкоплана на задълженото лице да кореспондира към 2 счетоводни сметки от При мапирането се посочва сметка от номенклатурата на НАП и номер и наименование на съответстващата аналитична сметка от воденото номенклатура NRA_Nom_Accounts, която е неразделна част от схемата? Пример: Сметка на ДЗЛ (Taxpayer Account ID): 123456 Сметка от номенклатурата (Account ID): един път се посочва 701 и един път се посочва 702 Ако отговора на горния въпрос е „Да, допустимо е.“, какво начално и крайно салдо следва да се посочи в секция GeneralLedgerAccounts при подаване на SAF-T файла за тази конкретна сметка от сметкоплана на задълженото лице: - начално и крайно салдо на сметката, както е в системата на ДЗЛ (123456), или - веднъж салдата, които кореспондират към една от сметките от номенклатура NRA_Nom_Accounts (пр. 701) и втори път салдата, които кореспондират на другата сметка (пр. 702)

Официален отговор на НАП

При мапирането се посочва сметка от номенклатурата на НАП и номер и наименование на съответстващата аналитична сметка от воденото номенклатура NRA_Nom_Accounts, която е неразделна част от схемата? Пример: Сметка на ДЗЛ (Taxpayer Account ID): 123456 Сметка от номенклатурата (Account ID): един път се посочва 701 и един път се посочва 702 Ако отговора на горния въпрос е „Да, допустимо е.“, какво начално и крайно салдо следва да се посочи в секция GeneralLedgerAccounts при подаване на SAF-T файла за тази конкретна сметка от сметкоплана на задълженото лице: - начално и крайно салдо на сметката, както е в системата на ДЗЛ (123456), или - веднъж салдата, които кореспондират към една от сметките от номенклатура NRA_Nom_Accounts (пр. 701) и втори път салдата, които кореспондират на другата сметка (пр. 702) счетоводство на лицето, подаващо файла. Не се допуска една аналитична сметка, от утвърдения индивидуален сметкоплан, да бъде мапирана към повече от една сметка от номенклатурата на НАП. Със Стандартния одитен файл за данъчни цели (SAF -T) се подaва информация за най -ниско ниво на аналитичните счетоводните сметки във воденото счетоводство от лицето, подаващо файла, мапирани към номенклатурата за сч. сметки на НАП. Например: AccountID TaxpayerAccountID AccountDescription 701 123456, партида 1 Наименование на сметката и партидата 702 123456, партида 2 Наименование на сметката и партидата

Официален въпрос

Относно поле „ TaxpayerAccountID“ в GeneralLedger – Типът на полето SAFmiddle1textType е твърде малък. Нашият сметкоплан, с който работят клиентите ни, допуска до 15 аналитични признака с максимален брой символи на аналитичността 197. Срещу тези 197 символа в таблицата пазим и идентификатор на записа, който е до 10 цифри. Това, което можем да направим за поле TaxpayerAccountID да подадем информация в два варианта: - Да промените типа на полето на „SAFlongtextType“ - Да подадем примерно XXXXXХYYYYYYYYYY – където XXXХХХ е кодът на синтетичната сметка от нашия сметкоплан, а YYYYYYYYYY е идентификатора, описващ пълната аналитичност.

Официален отговор на НАП

Предвид, че не е предоставена достатъчно яснота в поставения въпрос по отношение на „идентификатор, описващ пълната аналитичност“ , е изразено следното принципно становище: Със SAF -T се подава информация за ниско ниво на аналитичните счетоводните сметки във воденото счетоводство от лицето, подаващо файла, мапирани към номенклатурата за сч. сметки на НАП. Информацията се подава съгласно представения от Вас Вариант 2, като не следва да се подават информация за аналитични признаци, които са свързани с номер на документ и дата на документ. Подават се тези аналитични признаци, по които се формират партиди. Към момента в утвърдената XSD схема типът на елемент TaxpayerAccountID е SAFmiddle1textTyp и позволява подаването на информация за до 35 символа, съответно подаваните данни следва да са ограничени до този диапазон.

Официален въпрос

В информационната система счетоводна сметка, която е Активна, има начално дебитно салдо и крайно кредитно салдо за подавания период. <nsSAFT:GeneralLedgerAccounts> <nsSAFT:AccountType> Activе</nsSAFT:AccountType> <nsSAFT:OpeningDebitBalance>1500.00</nsSAFT:OpeningDebitBalan ce> <nsSAFT:ClosingCreditBalance>300.00</nsSAFT:ClosingCreditBalanc e> Въпрос: Правилно ли са попълнени данните?

Официален отговор на НАП

Потвърждаваме, че данни са попълнени коректно – следва да имате предвид, че началните и крайните салда на сч. сметка, посочена в секция MasterFiles, подсекция GeneralLedgerAccounts, трябва да отговарят на дебитните и кредитните обороти на същата счетоводна сметка, посочени в секция GeneralLedgerEntries.

Официален въпрос

Как се очаква да се попълнят тези Салда? Да са съобразени с флага на счетоводнатасметка Активна/Пасивна/Активно-Пасивна ли? Активна - само Дт салдо Пасивна - само Кт салдо Активно-Пасивна - Дт и Кт салдо

Официален отговор на НАП

Типът на сметката се определя съобразно възприетият от дружеството индивидуален сметкоплан. Няма изискване да салдата на по счетоводните сметки да съответстват на посоченият маркер за вид на счетоводната сметка.

Официален въпрос

Впечатление прави разликата в изискванията за информацията по колона Е. 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 – задължителен за подаване при определения условия (вж. бележките в колона М).

Официален въпрос

Задължително ли е да се въведат за всеки контрагент телефонен номер и имейл адрес?

Официален отговор на НАП

Информация за контрагентите на предприятието се посочва в подсекции Customers и Suppliers от секция MasterFiles, в които се изисква попълването на конкретна структура (CompanyStructure) от XSD - схемата. Информацията, която се подава със структурата на компанията, е посочена от елемент S.C.1. до елемент S.C.9. в работен лист (sheet) 5.Structures от Приложение №2 към заповедта на изпълнителния директор на НАП. Елемент S.C.4 Contact ( който препраща към структура за контаките) е опционална за подаване.

Официален въпрос

Искам да ви попитам за елемент CustomerID/SupplierID с какъв уникален код и логика трябва да се подава физическо лице или компания без ДДС регистрация, които не са в България, защото кодове 11 и 12 са свързани само с ДДС номера.

Официален отговор на НАП

Когато контрагента Ви е установен в ЕС и няма активен ДДС номер, следва да се посочи с код: „14, следван от кода на държавата (съгласно ISO 3166 -1 - 2 букви), следван от уникален код на икономическия оператор, присъединен от задълженото лице (обикновено ге нериран от информационна система).“, например 14ROXXXXXXXX, като XXXXXXXX е съответния данъчен номер (TIN) или друг номер от фирмения регистър, ако са известни на лицето, което подава файла. Ако на лицето, подаващо файла, не му е известен съответния номер: XXXXXXXX е номера, който е присвоен от системата. Когато контрагента Ви е установен в държава извън ЕС и няма активен ДДС номер, следва да се посочи с код: „12, следван от кода на държавата (съгласно ISO 3166-1 - 2 букви) и уникалния идентификационен код по ДДС (или друг код от официален регистър) на съот ветната държава, която не е нито България, нито държава-членка на ЕС - за икономически оператори от други държави, различни от България или членки на ЕС - Пример: 12TK123005284, когато такъв регистрационен номер е наличен.“.

Официален въпрос

Извършени са продажби към клиента до различни ДЧ, в които има клиентът има регистрация за целите на ДДС. Ако за един и същи контрагент в секция SourceDocuments са подадени данни за извършени към него доставки под различни идентификатори за целите на ДДС /VIN/, присвоен в различни държави членки - в елемента Отразени са продажни фактури към: RO123456…; FR123456…; DE123456…, които са посочени в SourceDocuments.SalesInvoice. Кой номер да се посочи в MasterFiles.Customers?

Официален отговор на НАП

Ако за един и същи контрагент в секция SourceDocuments са подадени данни за извършени към него доставки под различни идентификатори за целите на ДДС /VIN/, присвоен в различни държави членки - в елемента Отразени са продажни фактури към: RO123456…; FR123456…; DE123456…, които са посочени в SourceDocuments.SalesInvoice. Кой номер да се посочи в MasterFiles.Customers? (CustomerID MF.C.3) се подава информация за идентификационен номер, издаден от държавата, в която е установен клиента. В този случай структура TaxIDStructure (към която се препраща от CompanyStructure, част от подсекция Customers - MF.C.2) се подава задъл жително и поотделно за всеки идентификатор за целите на ДДС на този клиент. Например: <nsSAFT:CompanyStructure> <nsSAFT:RegistrationNumber> DE123456…</nsSAFT:RegistrationNumber> <nsSAFT:NameLatin>Beta GmbH</nsSAFT:NameLatin> <nsSAFT:TaxRegistration> <nsSAFT:TaxRegistrationNumber> DE123456…</nsSAFT:TaxRegistrationNumber> </nsSAFT:TaxRegistration> <nsSAFT:TaxRegistration> <nsSAFT:TaxRegistrationNumber> RO123456…</nsSAFT:TaxRegistrationNumber> </nsSAFT:TaxRegistration> <nsSAFT:TaxRegistration> <nsSAFT:TaxRegistrationNumber> FR123456…</nsSAFT:TaxRegistrationNumber> </nsSAFT:TaxRegistration> <nsSAFT:CustomerID>11DE123456…</nsSAFT:CustomerID> <nsSAFT:OpeningDebitBalance>Amount</nsSAFT:OpeningDebitBalance > <nsSAFT:ClosingDebitBalance> Amount</nsSAFT:ClosingDebitBalance>

Официален въпрос

Моля Ви за разяснение дали в секция MasterFiles застрахователите следва да подават клиенти и доставчици на агрегирано ниво относно информацията, която представлява застрахователна тайна – например, агрегирани начални и крайни салда на клиенти за месеца (елементи MF.C.6 – MF.C.9) и агрегирани начални и крайни салда на доставчици за месеца (елементи MF.S.6 – MF.S.9). Ако С т. I.1.2. от Приложение №3 към заповедта на изпълнителния директор се регламентира, че в секция MasterFiles, подсекции Customers и Suppliers, се подава информация относно всички клиенти/доставчици на данъкоплатеца, за които се подават данни в останалите секции/подсекции на файла за отчетния период. При отразяването на обобщена информация в различните секции на SAF-T се посочват информацията в секция MasterFiles следва да бъде подавана агрегирано, моля Ви да поясните какво следва да е нивото на агрегиране. Алтернативно, допустимо ли е относно клиентите и доставчиците, които представляват застрахователна тайна, да не се подава никаква информация в секция MasterFiles нито на индивидуално, нито на агрегирано ниво.

Официален отговор на НАП

С т. I.1.2. от Приложение №3 към заповедта на изпълнителния директор се регламентира, че в секция MasterFiles, подсекции Customers и Suppliers, се подава информация относно всички клиенти/доставчици на данъкоплатеца, за които се подават данни в останалите секции/подсекции на файла за отчетния период. При отразяването на обобщена информация в различните секции на SAF-T се посочват информацията в секция MasterFiles следва да бъде подавана агрегирано, моля Ви да поясните какво следва да е нивото на агрегиране. Алтернативно, допустимо ли е относно клиентите и доставчиците, които представляват застрахователна тайна, да не се подава никаква информация в секция MasterFiles нито на индивидуално, нито на агрегирано ниво. идентификационните данни на лицето, подаващо файла, като в елемент S.I.36 ProductCode се посочва код „0“ (нула). Съобразно изложеното при агрегирано подаване на информация (напр. в секция GeneralLedgerEntries) в подсекции Customers и Suppliers, в секция MasterFiles не следва да се подава информация за клиенти и доставчици, свързани с агрегираната информация.

Официален въпрос

Ако приемем, че при съставянето на файла имаме следните условия: 1/за периода на отчета има само две продажби и те са с един и същ клиент ( едно и също CustomerID) 2/първата продажба е по сметка от сметкоплана на фирмата 4110 мапната към сметка 411 Вземания от клиенти от номенклатурата на НАП (AccountID) – салдото на контрагента по сметка 4110 е 1500 лв Дт в началото на периода и 1900 лв Дт. , в края на периода 3/втората продажба е по сметка от сметкоплана на фирмата 4114 мапната към сметка 411 Вземания от клиенти от номенклатурата на НАП (AccountID) – салдото на контрагента по сметка 4114 е 3000 лв Дт в началото на периода и 2800 лв. Дт. , в края на периода Т.е и имаме две сметки от сметкоплана на фирмата, които сочат към една сметка от номенклатурата на НАП как следва да се попълни MasterFiles в подсекция Customers за елементи CustomerID , AccountID , OpeningDebitBalance и ClosingDebitBalance

Официален отговор на НАП

В бележките към елемент MF.C.5 AccountID от подсекция Customer, секция MasterFiles, от приложение №2 към заповедта на изпълнителния директор, e посочено, че ако разчетите/балансите с клиент на предприятието се отразяват в повече от една счетоводна сметка - се подава информация за всяка счетоводна сметка в отделна структура за клиента. В представения от Вас случай се допуска, както подаването на информация в две отделни структури (въпреки, че ще е посочена и двете структури една и съща счетоводна сметка от номенклатурата на НАП), така и в една структура, в която да се посочат обобщено на чалните и крайните салда по двете посочени от Вас аналитични счетоводни сметки.

Официален въпрос

Как следва да се постъпи в случай, че местно физическо лице откаже да предостави своите лични данни? Какъв код следва да бъде попълнен в такива случаи?

Официален отговор на НАП

В описания от Вас случай, когато от страна на контрагент на предприятието не се предоставят идентификационни данни, в елементи SupplierID/CustomerID в различните секции на файла се посочва уникален номер (напр. присвоен от счетоводната система), който е предхождан от код „15 - следван от уникален код на икономическия оператор, присъединен от задълженото лице (обикновено генериран от информационна система)“. Обръщаме внимание, че когато за извършени доставки няма задължение за издаване на фактура е допустимо същите да се подават на агрегирано ниво, по аргумент на т. IV.5 от Приложение №3 към заповедта на изпълнителния директор на НАП.

Официален въпрос

В информационната система може да има счетоводни записвания, които не касаят разчети с Клиенти и Доставчици, но които за целите на управленската отчетност също се отчитат по контрагенти – например, получени заеми, приходи от продажби, факторинг, лизинг и др. Въпрос: В елементи "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 Вземания от клиенти по продажби при определени условия Как следва да се попълни MasterFiles в подсекция Customers за елементи CustomerID и AccountID ?

Официален отговор на НАП

В бележките към елемент MF.C.5 AccountID от подсекция Customer, секция MasterFiles, от приложение №2 към заповедта на изпълнителния директор, e посочено, че ако разчетите/балансите с клиент на предприятието се отразяват в повече от една счетоводна сметка - се подава информация за всяка счетоводна сметка в отделна структура. Когато с даден контрагент разчетите се отразяват в повече от една счетоводна сметка, то следва да се подадат толкова структури Customer/Supplier колкото са счетоводните сметки, по които се водят разчетите. Във представения от Вас пример, xml -файла следва д а се подаде: <nsSAFT:Customers> <nsSAFT:Customer> <nsSAFT:CompanyStructure> <nsSAFT:RegistrationNumber> DE123456…</nsSAFT:RegistrationNumber> <nsSAFT:NameLatin>Beta GmbH</nsSAFT:NameLatin> </nsSAFT:CompanyStructure> <nsSAFT:CustomerID>11DE123456…</nsSAFT:CustomerID> <nsSAFT:AccountID>411</nsSAFT:AccountID> <nsSAFT:OpeningDebitBalance>Amount</nsSAFT:OpeningDebitBalance > <nsSAFT:ClosingDebitBalance> Amount</nsSAFT:ClosingDebitBalance> </nsSAFT:Customer> <nsSAFT:Customer> <nsSAFT:CompanyStructure> <nsSAFT:RegistrationNumber> DE123456…</nsSAFT:RegistrationNumber> <nsSAFT:NameLatin>Beta GmbH</nsSAFT:NameLatin> </nsSAFT:CompanyStructure> <nsSAFT:CustomerID>11DE123456…</nsSAFT:CustomerID> <nsSAFT:AccountID>414</nsSAFT:AccountID> <nsSAFT:OpeningDebitBalance>Amount</nsSAFT:OpeningDebitBalance > <nsSAFT:ClosingDebitBalance> Amount</nsSAFT:ClosingDebitBalance> </nsSAFT:Customer> </nsSAFT:Customer>

Официален въпрос

Какво трябва да се попълни в тази секция Да се покажат данни от аналитична ОВ само до ниво Клиент ? Трябва ли да се съобрази да се показва само Дебитно салдо за клиента или може да е иДебитно и Крединто ? В примерните данни има клиенти които са докладвани с нулево салдо в началото и краяна периода. Какъв е критерия по който влючваме записи тук Това клиенти които имат движения през периода ли са ?

Официален отговор на НАП

Съгласно Приложение №3 към Заповед №З-ЦУ-30-1247/25.08.2025 г. за изменение на Заповед №З -ЦУ-30-1085/25.07.2025 г. на изпълнителния директор, с която са утвърдени форматът и редът за подаване на файла, Клиенти (Customers)/ Доставчици (Suppliers) – съдържа информация за контрагентите, като идентификационни данни (име, адрес), аналитична сметка, за която се подава начално и крайно салдо и др. В тези подсекции се подава информация относно всички клиенти и доставчици на данъкоплатеца, за които се подават данни в останалите секции/подсекции на файла за отчетния период. MF.C.9 ClosingCreditB alance Напр. ако в други секции на файла /напр. GeneralLedgerEntries, SourceDocuments/ са подадени данни за клиент/доставчик, същите данни следва да се подадат и в секция MasterFiles. В посочените от Вас елементиD за салда се подават данни за начално и крайно салдо по разчетната сметка с контрагента за съответния период.

Официален въпрос

Означава ли, че един наш контрагент, който е и доставчик и клиент, ще трябва да се води с отделна аналитичност? Да разбираме ли, че трябва да водим различни номенклатури за един и същ контрагент един път като доставчик и втори път като клиент или това системата ще го автоматизира по някакъв начин?

Официален отговор на НАП

При подаването на информация за контрагент, който е клиент и доставчик на предприятието се подава данни за него и в двете подсекции Customers и Suppliers, които са част от секция MasterFiles. При условие, че във воденото от Вас счетоводство за същия (контрагент, който е клиент и доставчик) не са открити отделни партиди за клиент и доставчик, то в подсекция Customers се посочва аналитичната сметка на контрагента, за която се подава начално и кра йно салдо, формирани на база разчетите с контрагента, които са свързани с извършените доставки към него. В подсекция Suppliers се посочват аналитичната сметка на контрагента, за която се подава начално и крайно салдо, формирани на база разчетите с контрагента, които са свързани с получени доставки от него. Не се допуска компенсиране на вземания и задължения от един контрагент за целите на представянето на информация в SAF -T, в съответствие с принципите на Счетоводен стандарт 1 „Представяне на финансови отче ти“, относно оповестяването на информация за вземанията и задълженията.

Официален въпрос

В случаите, в които доставчик от ЕС, регистриран по ДДС в друга държава членка на ЕС, е подал пред НАП Искане за прилагане на СИДДО и му е издаден служебен номер от регистъра на НАП, започващ с 307, кой код следва да се използва за него - 11 следван от кода на държавата (съгласно ISO 3166 -1 - 2 букви) и уникалния идентификационен код по ДДС на съответната държава членка или 16 последван от предоставен от НАП служебен номер (започващ с 307)?

Официален отговор на НАП

В конкретния пример се посочва идентификатора, с който лицето е регистрирано за целите на ДДС.

Официален въпрос

Кои са аналогичните на ДДС данъци в държавите извън ЕС, при наличие на регистрация за които ще се препоръчва използването на код 12?

Официален отговор на НАП

В описанието към елемента за код „12“ няма изискване на въвеждане на регистрационен номер, издаден за аналогична регистрация за ДДС. Посочва се уникалния идентификационен код по ДДС или друг код от официален регистър на съответната държава (напр. TIN), която не е нито България, нито държава-членка на ЕС.

Официален въпрос

Aко контрагент е предоставил друг идентификационен номер, различен от номера си за регистрация по подобен на ДДС данък в държавата си на регистрация, може ли да се изпо лзва за този контрагент код 13 или код 14?

Официален отговор на НАП

В конкретния случай се посочва уникалния идентификационен код по ДДС или друг код от официален регистър на съответната държава, която не е нито България, нито държава -членка на ЕС , който следва да е предхождан с код „12“. Ако за чуждестранния контрагент няма данни за регистрационен номер – е допустимо да се използва и код „14“.

Официален въпрос

Дали се включват всички доставчици, примерно други финансови/банкови институции, с които се осъществяват банкови операции или такива, предоставящи финансиране (например, EBRD, ЕСВ, EIB). Транзакциите между тези лица в коя секция/раздел биха попаднали, например, ако са свързани с финансиране?

Официален отговор на НАП

Доставчик е физическо или юридическо лице, на което се дължи възнаграждение за получена насрещна престанция (стоки, услуги, продукт, лихви, др.). В секция MasterFiles се подават данни за доставчици, които фигурират и в останалите секции на файла (GeneralLedgerEntries, SourceDocuments, др.).

Официален въпрос

В „АЛФА“ ЕООД основните ни доставчици са етажна собственост, където няма обособено дружество. С какъв код би следвало да рапортуваме тези доставчици според вашата номенклатура.

Официален отговор на НАП

В случаите когато заплащате наемни възнаграждения за имущество в режим на етажна собственост (без учредено сдружение и получен ЕИК) с форма на управление общо събрание на собствениците, в елементи SupplierID в различните секции на файла за доставчиците Ви се посочва уникален номер (напр. присвоен от счетоводната система), който е предхождан от код „15 - следван от уникален код на икономическия оператор, присъединен от задълженото лице (обикновено генериран от информационна система)“.

Официален въпрос

В секции 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 г. на изпълнителния директор, с която са утвърдени форматът и редът за подаване на файла, например, получени заеми, приходи от продажби, факторинг, лизинг и др. Въпрос: В елементи "CustomerID" и "SupplierID" за тези счетоводни записвания кой идентификатор се подава? Доставчици (Suppliers) – съдържа информация за доставчиците, като идентификационни данни (име, адрес), аналитична сметка, за която се подава начално и крайно салдо и др. В тази подсекция се подава информация относно всички доставчици на данъкоплатеца, за които се подават данни в останалите секции/подсекции на файла за отчетния период. Напр. ако в други секции на файла /напр. GeneralLedgerEntries, SourceDocuments/ са подадени данни за клиент/доставчик, същите данни следва да се подадат и в секция MasterFiles.

Официален въпрос

Трябва да се покажат само данъчните кодове които са използвани по- натам във файла ? Проблем ли ще е ако се листне цялата номенклатура ?

Официален отговор на НАП

Съгласно Приложение №3 към заповедта на изпълнителния директор, в подсекция TaxTable, секция MasterFiles, се посочват конкретна информация за вида на данъци, осигуровки и такси по ЗХ, за които са подадени данни в останалите секции/подсекции на файла за отчетния период.

Официален въпрос

Каква информация се попълва в елементи BaseRate /MF.TT.11/, Секция MasterFiles, подсекция 2.5 TaxTable - TaxCodeDetails?

Официален отговор на НАП

BaseRate – коефициент на приспадане за ЧДК по подразбиране се посочва „1,00“. При извършено приспадане се посочва съответният коефициент за приспадане.

Официален въпрос

Трябва да се покажат само мерните единици които са използвани по- натам във файла ? Проблем ли ще е ако се листне цялата номенклатура - в нашето ERP ще поддържамесамо тези номенклатури от SAF_T номенклатурата които са релевантни за нас, а нецялата SAF-T номенклатура ?

Официален отговор на НАП

Съгласно Приложение №3 към заповедта на изпълнителния директор, в подсекция UOMTable, секция MasterFiles, се посочват конкретна информация за мерните единици, за които са подадени данни в останалите секции/подсекции на файла за отчетния период.

Официален въпрос

Моля, представете информация относно начина на подаване на информация за количество (мерна единица) на услуга със Стандартния одитен файл за данъчни цели (SAF-T)?

Официален отговор на НАП

Данни за мерна единица се подават в елементи MF.UOM.2 UnitOfMeasure, част от секция MasterFiles, SD.MG.28 UnitOfMeasure, част от секция SourceDocuments, и S.I.40 InvoiceUOM, част от структурата на реда на фактурата (InvoiceStructureLine), като при подаването на информация в тях се попълва съответстващата мерна единица от номенклатурата. В случаите на извършване на продажби на услуги, при подаване на информация за мерната единица на услугата в описаните по -горе елементи на SAF -T следва да се подаде съответстващия код на мерна единица, с която е определено количеството на услугата, например: код H87 – piece/брой (един); код HUR – hour/час; друг код, съответстващ на вида на предоставяната услуга.

Официален въпрос

Моля да разясните: - Каква е очакваната структура на разходните центрове? - Къде и как следва да се отразяват в SAF-T файла? - Има ли изисквания за стандартизация или кодиране на тези елементи?

Официален отговор на НАП

Информация за разходните центрове се подава с подсекция AnalysisTypeTable, секция MasterFiles, която е опционална за подаване.

Официален въпрос

Допустимо ли е стоки, които са подадени в подсекция Product в месечните файлове да не присъстват във файла при поискване?

Официален отговор на НАП

С файла за наличностите и движение на стоково-материалните запаси в подсекция Products, секция MasterFiles, се подава информация за всички налични стоки и материали през периода, за който е изискан файла, независимо дали да били подадени с месечен файл за същия период.

Официален въпрос

Услугите включват ли се в Раздел Products <Продукти> и ако да, с какви кодове следва да се посочват отделните видове услуги, получавани и предоставяни от Дружеството в хода на дейността му?

Официален отговор на НАП

В номенклатура „NC8_TARIC“ от файла е посочен код за услуга, който следва да бъде посочен за всички видове услуги, получавани и предоставяни от предприятието. Например: Код от системата на ЗЛ Име на продукт Код по NC8_ TARIC 1000010 Услуга по електро изграждане 000000 1000011 Довършителни СМР 000000

Официален въпрос

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

Официален отговор на НАП

Съгласно чл. 71и, ал. 1 от ДОПК стандартният одитен файл за данъчни цели съдържа данни относно счетоводната отчетност на задълженото лице, с оглед на което информацията, която се подава с файла следва е в съответствие с приложимите счетоводни стандартни и възприетите счетоводни политики от предприятието, подаващо файла. При отразяването на фактури за покупки или продажби в подсекции PurchaseInvoices и SalesInvoices в елемент S.I.36 ProductCode от структурата на фактурата се посочва код на закупувани/продавани стоково-материални запаси и услуги присвоен от системата на лиц ето, подаващо файла, който трябва да е подаден и в секция MasterFiles, подсекция Products. В случай, че природния газ се отчита като стоково -материален запас по смисъла на СС 2 или на МСС 2 при подаването на информация със Стандартния одитен файл за данъчни цели (SAF-T) в подсекции Products и PhysicalStock задължително се посочва съответстващия код на продуктът от номенклатура NC8_TARIC, който се обвързва с кода от счетоводната система на ли цето, което подава файла. Кодовете на получаваните и предоставяните услуги от предприятието се обвързват с общия код за услуги от номенклатура NC8_TARIC: „00000000“.

Официален въпрос

Трябва ли да се прави преоценка на стоки и материали месечно въз основа на новия регламент SAF -T или остава на годишна основа, както е до момента?

Официален отговор на НАП

Съгласно чл. 71и, ал. 1 от ДОПК стандартният одитен файл за данъчни цели съдържа данни относно счетоводната отчетност на задълженото лице, с оглед на което информацията, която се подава с файла следва е в съответствие с приложимите счетоводни стандартни и възприетите счетоводни политики от предприятието, подаващо файла. Предвид гореизложеното оценките на стоково -материалните запаси се извършват в съответствие със счетоводната политика на предприятието и със СС 2 или на МСС 2, съответно счетоводните записвания направени във връзка с такива оценки се подават със SAF-T за периода, през който са направени.

Официален въпрос

Бихте ли могли да предоставите повече информация относно изискванията към кодификацията на артикулите – какъв тип кодове се очакват, задължителни ли са и каква структура трябва да следват?

Официален отговор на НАП

При подаване на информация в секция SourceDocuments, подсекции SalesInvoice, PurchaseInvoice и MovementOfGoods, задължително се посочва код на съответния продукт (артикул) от системата на лицето, което подава файла. При подаването на информация със SAF -T в подсекции Products и PhysicalStock посочените кодове на продуктите от системата на лицето, подаващо файла, задължително се мапират към съответстващия код на продуктите от номенклатура NC8_TARIC, която е неразделна ч аст от схемата на SAF-T. С указанията в т. IV.6 от Приложение №3 към заповедта на изпълнителния директор на НАП, са дадени насоки, че за закупени материали, които не подлежат на контролирано съхранение и се отчитат като директен разход, в секция „Изходни документи“ (SourceDocuments), в структурата на покупната фактура не се посочва код на продукта от информационната система на лицето, подаващо файла. В тези случаи се допуска документът (фактурата) да се посочи на един ред /InvoiceLine/, като в елемент S.I.36 ProductCode задължително се подава стойност „0“ (нула) и в елемент S.I.45 De scription се посочва описание на отчетения текущ разход, съгласно данните в информационната система на задълженото лице.

Официален въпрос

Каква информация се подава в секция MasterFiles, подсекция 2.10 PhysicalStock - PhysicalStockEntry, елемент WarehouseID /MF.PS.2/ – наименование на склад, адрес или и двете? В описанието на елемента е посочено, че се подават и превозни средства или други, които съдържат стоки на път. Това означава ли, че трябва да се посочат всички номера на превозни средства, с които към момента на изготвяне на файла се транспортират материални запаси?

Официален отговор на НАП

Подава се информация за локацията на всеки продукт (склад, производствено помещение, транспортно средство при стоки на път и др.) към крайната дата от периода, за който се подава файла.

Официален въпрос

Каква информация се подава в Секция MasterFiles, подсекция PhysicalStockEntry, елемент ProductType /MF.PS.6/?

Официален отговор на НАП

Подава се съгласно номенклатура за вид на МЗ (5 вида съгл. СС № 2 - ОТЧИТАНЕ НА СТОКОВО-МАТЕРИАЛНИТЕ ЗАПАСИ – материали, продукция, стоки, незавършено производство и инвестиция в материален запас).

Официален въпрос

Какво се подава в тези елементи?

Официален отговор на НАП

В елемент MF.PS.12 UnitPriceBegin се посочва единичната цена стоково-материалния запас в началото за периода, за който е изискано подаването на наличности и движения на стоково-материални запаси. В елемент MF.PS.12.1. UnitPriceEnd се посочва единичната цена на артикула в края на периода, за който е изискана информация. Искаме да отбележим, че двата елемента са необходими в случаите, при които са извършени преоценки на стоково-материалните запаси в съответствие с приложимите счетовод ни стандарти и с възпри етите счетоводни политики.

Официален въпрос

Какво се подава в подсекция 2.12 Assets?

Официален отговор на НАП

В подсекция 2.12 Assets се подава информацията за всички дълготрайни материални и нематериални активи заведени в счетоводната отчетност на предприятието през периода, за който се подава файла.

Официален въпрос

За дълготрайните активи данните ще се подават за определен период или ще се подават за всички активи към момента на генериране на В секция MasterFiles, подсекция 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.

Официален въпрос

Тъй като на две места в колона Бележки се позовавате на СС4, въпросите за подсекция ValuationSAP са зададени използвайки определенията дадени в него, а именно Отчетната Стойност намалена с Начислената Амортизация дава Балансовата Стойност на актива (ОС-НА=БС). В елемент „MF.A.16“ отчетната стойност в началото на периода ли се посочва?

Официален отговор на НАП

В елемента се посочва историческата цена (общо разходи за закупуване или за производство) на придобиване при счетоводното завеждане на актива. Напр.: ако се подава SAF -T за 2026 г. и следва да се подават данни за определен актив, който е закупен през 2022 г., то в елемента се посочва историческата цена, за която е придобит през 2022 г., не балансовата му стойност към 31.12.2025 г.

Официален въпрос

Какво следва да се посочи в елемент Master files/ValuationSap/AcquisitionAndProductionCostsBegin - Общо начално салдо разходи за придобиване (вкл. по стопански начин) на актива (в основна валута) – ако идеята е да се даде разбивка на началното салдо на разходите за придобиване на ДМА на ниво самостоятелен актив, това е практически невъзможно да бъде направено при нас, т.к. договорите за изграждане на активи (придобиване на активи, основно машини и съоръжения, чрез строителство) включват множество и различни операции, обичайно от различни доставчици, като едва след при ключване на В елемент Master files/ValuationSap/AcquisitionAndProductionCostsBegin се посочва историческата цена на актива, в случай, че същият е включен в СчАП, т.е. ако е признат за дълготраен материален актив. изграждането може да бъде установено кои самостоятелни активи ще бъдат счетоводно отчетени. Това е така, т.к. строителството на големи проекти (например изграждане на нова производствена линия или съоръжение) е продължителен процес, който често изисква няколко години, а множество общи разходи следва да се разпределят между всички активи (например разходи за проектиране, определени разходи за строителство и др. подобни). Поради тази причина, според нас не е реално изпълнимо задължително да се подава информац ия за разходите за изграждане на активи на ниво отделен актив, който е в процес на изграждане.

Официален отговор на НАП

В елемент Master files/ValuationSap/AcquisitionAndProductionCostsBegin се посочва историческата цена на актива, в случай, че същият е включен в СчАП, т.е. ако е признат за дълготраен материален актив.

Официален въпрос

В „MF.A.17“ се посочва: Вариант 1 - отчетна стойност в края на периода (отчетната стойност в началото + всички увеличения - всички намаления) или Вариант 2 - стойността на всички разходи за придобиване на активи за периода (както сумите за завишаване стойността на актив, вкл. по стопански начин, така и директно закупени/придобити активи през периода, вкл. по стопански начин)?

Официален отговор на НАП

В елемента се посочва историческата цена на актива към края на периода, за който се подава файла, увеличена или намалена със сумите на допълнителни разходи за подобрения и/или преоценки, извършени през периода. Това е историческата цена, към която са доба вят сумите посочени в елемент MF.A.21 AssetAddition и се намалява със сумите в елемент MF.A.23 AssetDisposal.

Официален въпрос

Капиталови разходи за актива за периода (в основна валута) Какво се очаква да се попълни в това поле ?

Официален отговор на НАП

В бележките в Приложение №2 за елемент MF.A.18 InvestmentSupport е посочено, че посочва сумата на полученото финансиране за придобиване на актива, съгласно Национален счетоводен стандарт 20 - Отчитане на правителствени дарения и оповестяване на правителствена помощ и Международен счетоводен стандарт 20 - Счетоводно отчитане на безвъзмездни средства, предоставени от държавата, и оповестяване на държавна помощ.

Официален въпрос

В „MF.A.21“ се посочва: Вариант 1 - отчетна стойност в края на периода (отчетната стойност в началото + всички увеличения - всички намаления) или Вариант 2 - балансовата стойност в края на периода (отчетната стойност в началото + всички увеличения - всички намаления - начислената амортизация) или Вариант 3 - стойността на добавените активи през периода (директно закупени/придобити активи през периода, вкл. по стопански начин, както и сумите на завишаване на актив)?

Официален отговор на НАП

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

Официален въпрос

В „MF.A.23“ се посочва: Вариант 1 - отчетната стойност на отписаната част на актива (при дефектирала части или др.) или Вариант 2 - балансовата стойност на отписаната част на актива (при дефектирала части или др.) към момента на отписването или Вариант 3 - отчетната стойност при отписване (продажба, бракуване, липса, апортна вноска, трансфер и т.н.) на актив, вкл. сумата на отписаната част на актива (при дефектирала части или др.)?

Официален отговор на НАП

В елемента се посочва историческата цена при отписване на актив или на част от него.

Официален въпрос

В „MF.A.24“ се посочва: Вариант 1 - Балансовата стойност в началото на периода (отчетната стойност в началото на периода - начислената амортизация в началото на периода) или Вариант 2 - балансовата стойност в края на периода (отчетната стойност в началото на периода + всички увеличения на стойността на актива - всички намаления на стойността на актива - начислената амортизация в края на периода) или Вариант 3 - отчетната стойност в края на периода (отчетната стойност в началото на периода + всички увеличени я на стойността на актива - всички намаления на стойността на актива), без да се има предвид начислената амортизация?

Официален отговор на НАП

В елемента се посочва балансовата стойност на актива в началото на периода, за който се подава файла, или балансовата стойност на актив придобит през периода за който се подава файла.

Официален въпрос

В „MF.A.28“ се посочва стойността на всички разходи за придобиване на активи за периода (както сумите за завишаване стойността на актив, вкл. по стопански начин, така и директно закупени/придобити активи през периода, вкл. по стопански начин)?

Официален отговор на НАП

В елемента се посочват всички увеличения на балансовата стойност на актива, които са направени през периода, за който се подава файла.

Официален въпрос

В MF.A.21 и MF.A.28 трябва ли винаги да посочваме едни и същи данни?

Официален отговор на НАП

В MF.A.21 AssetAddition се посочва една от посочените от Вас стойностти, които представляват увеличение на историческата цена (цената на придобиване/подобрение) актива. В елемент MF.A.28 AppreciationForPeriod се посочват всички увеличения на балансовата стойност на актива, които може да се различават от цената на придобиване/подобрение.

Официален въпрос

В „MF.A.29“ се посочва сума на извънредно начислена амортизация за периода? Пример: През 2026г. се извършва подобрение на 6 -ти етаж на сграда. През 2026г. се посочва извънредно начислена амортизация изчислена върху сумата на подобрението на 6 -ти етаж. През 2027г. се извършва подобрение на 7 -ми етаж на сградата. През В елемента се посочва извънредни разходи за амортизации съгласно Счетоводен стандарт 4, напр. при обезценка на актива, ако същата е направена през периода, за който се подава файла. 2027г. се посочва извънредно начислена амортизация изчислена само върху сумата на подобрението на 7 -ми етаж (само на сумата на подобрението от периода). Уточняването на този въпрос е важно, защото след преоценка например, отчетната стойност на актива може да стане по-малка от стойността на всички увеличения на актива през годините. В този случай, ако не се вземат само сумите от текущия период, общата амортизация ще бъде по -малка от извънредно начислената амортизация.

Официален отговор на НАП

В елемента се посочва извънредни разходи за амортизации съгласно Счетоводен стандарт 4, напр. при обезценка на актива, ако същата е направена през периода, за който се подава файла.

Официален въпрос

В „MF.A.30“ се посочва Начислена амортизация в края на периода?

Официален отговор на НАП

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

Официален въпрос

В „MF.A.31“ се посочва балансовата стойност в края на периода (отчетната стойност в началото на периода + всички увеличения на стойността на актива - всички намаления на стойността на актива - начислената амортизация в края на периода)?

Официален отговор на НАП

В елемента се посочва балансова стойност на актива към края на периода, за който се подава файла.

Официален въпрос

Ако през периода има промяна в стойността на актива повече от веднъж, кой месец се посочва в „MF.A.41“ : първи, последен или месеца с най-голяма промяна на стойността?

Официален отговор на НАП

Елементът не следва определена структура - в описаната от Вас хипотеза в него се подават всички месеци, през които промяна на стойността на актива, и всички основания, които са обусловили промените.

Официален въпрос

Ако през периода сме преустановили, но след това сме възобновили начисляването на данъчни амортизации, кой месец посочваме в „MF.A.42“ - на преустановяване или на възобновяване на начисляването на данъчни амортизации?

Официален отговор на НАП

Този елемент също не следва определена структура - в описаната от Вас хипотеза се подават всички месеци на преустановяване/възобновяване и обстоятелствата за тях.

Официален въпрос

Какво трябва да се сумира - брой на отделните редове по всички транзакции или брой транзакции?

Официален отговор на НАП

Броят на всички подадени отделни транзакции (елементи TransactionID /GL.9/) в секцията да отговаря на стойността, посочена в NumberOfEntries.

Официален въпрос

Какви стойности се попълват в тези полета? Текущ период или друго, ако транзакцията е свързана с осчетоводяване в предходен период?

Официален отговор на НАП

В „Period“ и „PeriodYear“ се отразява годината и месеца за който се отнася осчетоводяването, а не дата на която е извършено осчетоводяването.

Официален въпрос

По какво полето се различава от GL.17 SystemEntryDate - правилно ли ще е дапопълваме същата стойност като GL.17 SystemEntryDate при положение, че счетоводните ни операции не са свързани с документ. Счетоводната операция има дати: GL.17 SystemEntryDate- Системно запазена дата на въвеждане GL.18. GLPostingDate- Дата на осчетоводяване

Официален отговор на НАП

В елемент GL.12 TransactionDate се посочва дата на документа, на база на който е взета счетоводната операция. На основание чл. 3, ал. 3 от ЗСч предприятията осъществяват текущото счетоводно отчитане на основата на документална обоснованост на стопанските операции. С оглед на което при осчетоводяването на операция, която е свързана със счетоводен документ, който засяга само дейността на предприят ието, и в който няма посочена дата се допуска да се подаде датата на въвеждане на транзакцията.

Официален въпрос

В следния пример: Фактура за доставка с дата 15.01.2025 Получена и въведена в модул Доставки на 01.04.2025 Осчетоводена на 14.04.2025 с отчетна дата 31.03.2025 (период, в който ще влезе в оборотната ведомост) Как се попълват полетата Period;PeriodYear;TransactionDate;SystemEntryDate;GLPostingDate в GeneralLedgerEntries/Transaction в месечен SAF_T файл ?

Официален отговор на НАП

При подаване на информация със Стандартния одитен файл за данъчни цели, когато същата се отнася за предходен счетоводен период, а не за периода, за който се подава файла, в елементи Period, PeriodYear и GLPostingDate се подава предходния период, за който с е отнася осчетоводяването. В представения от Вас случай, SAF -T се подава, както следва: <nsSAFT:JournalID>GL</nsSAFT:JournalID> <nsSAFT:Description>Счетоводни записи</nsSAFT:Description> ……………… <nsSAFT:Transaction> ………………………. <nsSAFT:Period>03</nsSAFT:Period> <nsSAFT:PeriodYear>2025</nsSAFT:PeriodYear> <nsSAFT:TransactionDate>2025-01-15</nsSAFT:TransactionDate> …………………………… <nsSAFT:SystemEntryDate>2025-04-01</nsSAFT :SystemEntry Date > <nsSAFT:GLPostingDate>2025-03-31</nsSAFT:GLPostingDate>

Официален въпрос

Пример: файлът за м.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г. <nsSAFT:JournalID>GL</nsSAFT:JournalID> <nsSAFT:Description>Счетоводни записи</nsSAFT:Description> ……………… <nsSAFT:Transaction> ………………………. <nsSAFT:Period>2</nsSAFT:Period> <nsSAFT:PeriodYear>2025</nsSAFT:PeriodYear> <nsSAFT:TransactionDate>2025-02-15</nsSAFT:TransactionDate> …………………………… <nsSAFT:SystemEntryDate>2025-02-20</nsSAFT :SystemEntry Date > <nsSAFT:GLPostingDate>2024-12-31</nsSAFT:GLPostingDate> Въпрос: Правилно ли са попълнени данните?

Официален отговор на НАП

При подаване на информация със Стандартния одитен файл за данъчни цели, когато същата се отнася за предходен счетоводен период, а не за периода, за който се подава файла, в елементи Period, PeriodYear и GLPostingDate се подава предходния период, за който с е отнася осчетоводяването. В представения от Вас случай, SAF -T се подава, както следва: <nsSAFT:JournalID>GL</nsSAFT:JournalID> <nsSAFT:Description>Счетоводни записи</nsSAFT:Description> ……………… <nsSAFT:Transaction> ………………………. <nsSAFT:Period>12</nsSAFT:Period> <nsSAFT:PeriodYear>2024</nsSAFT:PeriodYear> <nsSAFT:TransactionDate>2025-02-15</nsSAFT:TransactionDate> …………………………… <nsSAFT:SystemEntryDate>2025-02-20</nsSAFT :SystemEntry Date > <nsSAFT:GLPostingDate>2024-12-31</nsSAFT:GLPostingDate>

Официален въпрос

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

Официален въпрос

В частта General ledger items имаме подобен казус, но по отношение на supplier и customer IDs. Какво правим в случай, че има adjustment/reclass/рекласификация, свързани с различни доставчици или клиенти? Най -елементарен пример - начислен е разход срещу сметка доставчици, но по грешна партида на доставчика. Преместването на сумата може да стане с операция, засягаща една сметка (в случая Доставчици), но различни аналитични показатели - партида на доставчик. В този случай какво подаваме на ниво Transaction?

Официален отговор на НАП

С чл. 3, ал. 3 от ЗСч се регламентира, че счетоводно отчитане се осъществява на основата на документална обоснованост на стопанските операции. С оглед на което в представения от Вас пример няма как да се извърши счетоводна операция, с която един погрешно начислен разход в парт ида на доставчик да се отрази по партида на друг доставчик. Когато счетоводна грешка се открие в рамките на отчетния период, в този случай би следвало неправилната операция да се сторнира и данните да се отразят отново.

Официален въпрос

В секцията General Ledger Entries в елементи SupplierID и CustomerID в определени случаи следва да се декларира ЕИК на лицето, което подава файла (напр. ако счетоводната операция не е свързана с клиент или доставчик). Как следва да се извърши докладването - посочване само на ЕИК или пред ЕИК да се постави и код "10"

Официален отговор на НАП

В случаите когато се подава идентификатор на лицето подаващо файла, в елементите се посочва код „10“, следван от ЕИК на лицето.

Официален въпрос

Имам следното питане: В счетоводната програма записите са прости счетоводни статии – например продажба на стока 411 - 702 - 1000 лв. - това е транзакция 1232 411 - 453/2 - 200 лв. - това е транзакция 1233 Двете транзакции се отнасят към документ 42 в папка 10. Кое е TransactionID и кое е RecordID ? В GLE как да се запише този документ?

Официален отговор на НАП

В елемент GL.9 TransactionID се посочва уникалния номер на транзакцията, който е генериран от софтуера при осчетоводяването, както е посочено и във Вашия пример. В елемент GL.23 RecordID се посочва идентификатор във възходящ ред на всеки ред (подструктура GL.22 TransactionLine) от счетоводното записване (транзакцията). Номерът на документа се посочва в елемент GL.27 SourceDocumentID (опционален за подаване), а не в GL.23 RecordID. Напр.: <nsSAFT:Transaction> <nsSAFT:TransactionID>1232</nsSAFT:TransactionID> <nsSAFT:TransactionLine> <nsSAFT:RecordID>42-10</nsSAFT:RecordID> <nsSAFT:AccountID>411</nsSAFT:AccountID> <nsSAFT:DebitAmount> <nsSAFT:Amount>1000.00</nsSAFT:Amount> <nsSAFT:CurrencyCode>EUR</nsSAFT:CurrencyCode> <nsSAFT:CurrencyAmount>1000.00</nsSAFT:CurrencyAmount> <nsSAFT:ExchangeRate>1.0000</nsSAFT:ExchangeRate> </nsSAFT:DebitAmount> </nsSAFT:TransactionLine> <nsSAFT:TransactionLine> <nsSAFT:RecordID>42-10</nsSAFT:RecordID> <nsSAFT:AccountID>701</nsSAFT:AccountID> <nsSAFT:CreditAmount> <nsSAFT:Amount>1000.00</nsSAFT:Amount> <nsSAFT:CurrencyCode>EUR</nsSAFT:CurrencyCode> <nsSAFT:CurrencyAmount>1000.00</nsSAFT:CurrencyAmount> <nsSAFT:ExchangeRate>1.0000</nsSAFT:ExchangeRate> </nsSAFT:CreditAmount> </nsSAFT:TransactionLine> </nsSAFT:Transaction> <nsSAFT:Transaction> <nsSAFT:TransactionID>1233</nsSAFT:TransactionID> <nsSAFT:TransactionLine> <nsSAFT:RecordID>42-10</nsSAFT:RecordID> <nsSAFT:AccountID>411</nsSAFT:AccountID> <nsSAFT:DebitAmount> <nsSAFT:Amount>200.00</nsSAFT:Amount> <nsSAFT:Transaction> <nsSAFT:TransactionID>1232</nsSAFT:TransactionID> <nsSAFT:TransactionLine> <nsSAFT:RecordID>1</nsSAFT:RecordID> <nsSAFT:AccountID>411</nsSAFT:AccountID> <nsSAFT: SourceDocumentID>42</nsSAFT: SourceDocumentID> <nsSAFT:DebitAmount> <nsSAFT:Amount>1000.00</nsSAFT:Amount> …….. </nsSAFT:DebitAmount> </nsSAFT:TransactionLine> <nsSAFT:TransactionLine> <nsSAFT:RecordID>2</nsSAFT:RecordID> <nsSAFT:AccountID>701</nsSAFT:AccountID> <nsSAFT: SourceDocumentID>42</nsSAFT: SourceDocumentID> <nsSAFT:CreditAmount> <nsSAFT:Amount>1000.00</nsSAFT:Amount> …….. </nsSAFT:CreditAmount> </nsSAFT:TransactionLine> </nsSAFT:Transaction> <nsSAFT:CurrencyCode>EUR</nsSAFT:CurrencyCode> <nsSAFT:CurrencyAmount>1000.00</nsSAFT:CurrencyAmount> <nsSAFT:ExchangeRate>1.0000</nsSAFT:ExchangeRate> </nsSAFT:DebitAmount> </nsSAFT:TransactionLine> <nsSAFT:TransactionLine> <nsSAFT:RecordID>42-10</nsSAFT:RecordID> <nsSAFT:AccountID>4532</nsSAFT:AccountID> <nsSAFT:CreditAmount> <nsSAFT:Amount>200.00</nsSAFT:Amount> <nsSAFT:CurrencyCode>EUR</nsSAFT:CurrencyCode> <nsSAFT:CurrencyAmount>200.00</nsSAFT:CurrencyAmount> <nsSAFT:ExchangeRate>1.0000</nsSAFT:ExchangeRate> </nsSAFT:CreditAmount> </nsSAFT:TransactionLine> </nsSAFT:Transaction>

Официален въпрос

В структурата GeneralLedgerEntries, полето SourceDocumentID следва да указва връзка към първичния документ, от който произтича счетоводният запис. Въпреки това, не е ясно какво следва да се посочва в случаите, когато записът произтича от друг тип документ, който не е фактура – например ведомост за работна заплата, разчет за командировка, протокол за начисляване на амортизации и др. Липсата на яснота по този въпрос създава затруднения при структурирането на данните и може да доведе до непълно или неконсистентно подаване н а информация. Молим за указания относно допустимите стойности и формати за SourceDocumentID в такива случаи.

Официален отговор на НАП

В елемент SourceDocumentID се подава информация както за номер на фактура, така и за всички други първични счетоводни документи, с които се регистрират стопански операции. Например: номер на протокол, номер на платежно нарежда/референция за плащане, номер на приходен/разходен касов ордер. С нормата на чл. 6, ал. 3, т. 1 от Закона за счетоводството се регламентира, че първичният счетоводен документ, който засяга само дейността на предприятието, следва да съдържа номер на документа, съдържащ само арабски цифри. С ал. 5 от същата норма се регламентира, че документална обоснованост е налице, когато в първичния счетоводен документ липсва част от изискуемата информация по ал. 1 и 3, но за нея има документи, които я удостоверяват. С оглед на гореизложеното ако в първичен счетоводен документ липсва негов номер, то следва да се посочи номер на съпътстващ документ.

Официален въпрос

Съгласно ЗКПО в данъчната основа за определяне на задълженията за данъка върху разходите за разходите в натура, свързани със собствени, наети и/или предоставени за ползване активи, предоставени за лично ползване и/или свързани с използване на персонал, от работници, служители и лица, наети по договори за управление и контрол (наети лица), както и от лица, упражняващи личен труд по смисъла на § 1, т. 26, буква „и" от допълнителните разпоредби на ЗДДФЛ, когато активите са данъчни амортизируеми активи, вместо счетоводните разходи за амортизации се вземат предвид данъчните амортизации. Как и къде данъчните амортизации, следва да се посочат при подаване на информация за „разход, върху който се дължи данък върху разходите” в секция GeneralLedgerEntries, в TaxInformation от подсекция TransactionLine, при положение, че за тях не се прави счетоводен запис?

Официален отговор на НАП

Кодът за данъка се посочва при осчетоводяването на първичния счетоводен документ, издаден на основание чл. 6, ал. 3 от ЗСч, с който се начислява дължимия данък. Такъв документ може да бъде счетоводна справка, мемориален ордер, др.

Официален въпрос

При отчитане на начислени разходи за „Данък при източника“ и „Данък върху разходите“ необходимо ли е сметките от елемент „NRA Nom of Accounts“ да носят и информация за код на вид данък (TaxType) и за код на данъка (TaxCode). В случай, че е необходимо, то трябва ли код на вид данък (TaxType) и код на данъка (TaxCode), да присъстват едновременно и от двете страни на операцията – в сметката по дебита от елемент „NRA Nom of Accounts“ и в сметката по кредита от елемент „NRA Nom of Accounts“?. Например: Дебит „60602 Разход за данъци върху разходите“, код 600010 Кредит „456 Разчети за данъци върху разходите“ код 600010.

Официален отговор на НАП

Представения от Вас случай, описва счетоводна операция за начисляване на данък върху разходите, след осчетоводяването първичния счетоводен документ, отразяващ разхода. С IV.8.2.1. от приложение №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

Официален въпрос

При сключени граждански договори как следва да се подава информация за удържания данък в секция General Ledger Entries? Необходимо ли е аналитично подаване и маркиране в елементи S.TI.1 TaxType и S.TI.2 TaxCode от структура GL.33 Tax Information, подсекция Transaction Line?

Официален отговор на НАП

Съгласно изискванията на т. IV.8 от Приложение №3 към заповедта на изпълнителния директор, с която се определят редът и форматът за подаване на информация със стандартния одитен файл за данъчни цели, при подаването на данни в секция GeneralLedgerEntries задължително се посочват кодовете за данъци 600 „Данък върху разходите“ и 700 „Данък при източника“ в случаите, когато транзакцията е свързана с начисляването на посочените видове данъци. При подаването на данни за транзакции, свързани с начисляването на всички останали данъци, задължителни осигурителни вноски и такси по Закона за хазарта, посочени в номенклатура TAX - IMP, се допуска да се посочат кодове за неприложимост „000“ за вид на данъка и „000000“ за код на данъка. В случаите, при които се подава информация за начислен авансов данък за доходи от стопанска дейност, който е удържан от платеца на дохода, във всяка линия (подсекция Transaction Line), отразяваща начисленото възнаграждение, се посочват вид на данъка „700 - данък при източника“ и код на данъка „700500 - авансов данък за доход на физическо лице, който се удържа от платеца на дохода“. При условие че изплатените възнаграждения се осчетоводяват поотделно за всяко лице, с което имате облигационни отношения, то посоченият вид и код данъка се подават на всяка от тези линии. В случай че възнагражденията се осчетоводяват общо за всички лица, с които имате облигационни отношения, кодът за данъка се посочва при извършване на осчетоводяването.

Официален въпрос

Как се подава елемент GL.33 Tax Information в секция General Ledger Entries за транзакции за начисляване на социални разходи, свързани с трудови правоотношения?

Официален отговор на НАП

В случаите, при които се подава информация за извършени социални разходи, предоставени в натура на работници и служители, кодът за данъка се посочва в елемент GL.33 TaxInformation в секция GeneralLedgerEntries при осчетоводяването на направените разходи, вкл. и когато върху същите не се дължи данък. Например в случаи, при които са направени социални разходи за вноски и премии за допълнителното социално осигуряване и застраховки „Живот“, които са до размера, определен в чл. 208 от ЗКПО и не се облагат с данък върху социалните разходи, при начисляване на разхода се посочва съответния код „600020 Данък върху социалните разходи, предоставени в натура“ и в елемент S.TI.6 TaxAmount от структурата 5.15 TaxInformationStructure се посочва стойност „0,00”. В случаите, при които се подава информация за извършени социални разходи, които не са предоставени в натура и представляват доход на физическо лице, кодът за данъка се посочва при осчетоводяването на направения разход. При осчетоводяването им в посочените по-горе структура и елементи се посочват вид на данъка „700 - данък при източника“ и код на данъка „700500 - авансов данък за доход на физическо лице, който се удържа от платеца на дохода“.

Официален въпрос

Когато счетоводният запис е свързан с данък, трябва ли и на двете линии от осчетоводяването да се попълва TaxInformation - елемент GL.33, или само на сметката, която е данък?

Официален отговор на НАП

С IV.8.2.1. от приложение №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

Официален въпрос

В Приложение № 3 към заповед № З -ЦУ-30-1085/25.7.2025 г. „Формат на Стандартен одитен файл за данъчни цели (Standard Audit File for Tax - SAF-T) и ред за подаването му“, т. 8.2. Подаване на информация в секция GeneralLedgerEntries е казано следното: „При подаване на информация за първични счетоводни документи в секция GeneralLedgerEntries, в TaxInformation от подсекция TransactionLine, лицето подаващо файла, посочва съответния данъчен код за данъци/осигурителни вноски/такси. Допуска се в TaxInformation да се посочват кодове за неприложимост в случаите, когато транзакцията не е свързана с начисляването на вид на данъци 600 „Данък върху разходите“ и 700 „Данък при източника“. Допуска се да не се подава информация за данъчните кодове за лихви, дължими за неплатени в срок задължения за данъци 600 „Данък върху разходите“ и 700 „Данък при източника“.“ Означава ли цитираният по -горе текст, че в секцията GeneralLedgerEntries, в TaxInformation от подсекция TransactionLine е допустимо да не се посочват например ДДС кодове и кодове за социални и здравни осигуровки от номенклатура TAX -IMP в Приложение № 2, а вместо тях за съответните записи е допустимо да Съгласно изискванията на т. IV.8 от Приложение №3 към заповедта на изпълнителния директор, с която се определят редът и форматът за подаване на информация със стандартния одитен файл за данъчни цели, при подаването на данни в секция GeneralLedgerEntries задължително се посочват кодовете за данъци 600 „Данък върху разходите“ и 700 „Данък при източника“, в случаите когато транзакцията е свързана с начисляването на посочените видове данъци. При подаването на данни с транзакции свързани с начисляването на останалите данъци, задължителни осигурителни вноски и такси по Закона за хазарта, посочени в номенклатура TAX-IMP, се допуска да се посочат кодове за неприложимост "000" за вид на данъка и "000000" за код на данъка. се посочват кодове за неприложимост "000" за вид на данъка и "000000" за код на данъка? С други думи, означава ли цитираният по -горе текст, че в секцията GeneralLedgerEntries, в TaxInformation от подсекция TransactionLine е задължително да се посочват единствено кодове с вид на данъка 600 „Данък върху разходите“ и 700 „Данък при източника“, а за останалите видове е допустимо да се посочат кодове за неприложимост "000" за вид на данъка и "000000" за код на данъка?

Официален отговор на НАП

Съгласно изискванията на т. IV.8 от Приложение №3 към заповедта на изпълнителния директор, с която се определят редът и форматът за подаване на информация със стандартния одитен файл за данъчни цели, при подаването на данни в секция GeneralLedgerEntries задължително се посочват кодовете за данъци 600 „Данък върху разходите“ и 700 „Данък при източника“, в случаите когато транзакцията е свързана с начисляването на посочените видове данъци. При подаването на данни с транзакции свързани с начисляването на останалите данъци, задължителни осигурителни вноски и такси по Закона за хазарта, посочени в номенклатура TAX-IMP, се допуска да се посочат кодове за неприложимост "000" за вид на данъка и "000000" за код на данъка.

Официален въпрос

При отразяване на отчети за извършени продажби в подсекция 4.1 SalesInvoices, какво трябва да съдържат следните задължителни елементи: S.I.23 CustomerID и свързаните елементи S.I.24 Name и S.I.25 Billing Address на подструктура S.I.2 Customer Info към структура InvoiceStructure; S.I.4 AccountID към структура InvoiceStructure; S.I.36 ProductCode, S.I.39 Quantity и S.I.42 UnitPrice към структура InvoiceLine? Сочи се, че всеки отчет за извършени продажби се осчетоводява с един счетоводен запис (TransactionID) по дебита на сметки 501 Каса в левове (за плащания в брой) или 446 С т. IV.7. от Приложение №3 към Заповед №З -ЦУ-30-1247/25.08.2025 г. за изменение на Заповед №З -ЦУ-30-1085/25.07.2025 г. на изпълнителния директор, с която са утвърдени структурата, формата, съдържанието и начина на подаване на SAF-T, се регламентира, че при отразяването на отчет за извършени продажби (Код 81 от номенклатура Nom_Invoice_Types) се подава обобщена информация за извършените продажби за периода, за който се отнася файла, с идентификационни данни на лицето, подаващо файла, като в елемент S.I.36 ProductCode се посочва код „0“ (нула). Разчети свързани с картови транзакции (за плащания с банкови карти). Към въпроса е представено следното примерно: CustomerID (S.I.23) = ЕИК на Дружеството Name (S.I.24) = наименование на Дружеството Billing Address (S.I.25) = адрес на Дружеството AccountID (S.I.4) = 501 Каса в левове (за плащания в брой) или 446 Разчети свързани с картови транзакции (за плащания с банкови карти) ProductCode (S.I.36) = 0 Quantity (S.I.39) = 1 UnitPrice (S.I.42) = InvoiceLineAmount (S.I.46) При отразяване на фактури за продажби (платени в брой или с банкова карта) в подсекция 4.1 SalesInvoices, какво трябва да съдържа задължителния елемент S.I.4 AccountID към структура InvoiceStructure? Сочи се, че за фактури, които са заплатени в брой или с карта в обектите на дружеството, при осчетоводяване на продажбата не се използва разчетна сметка за клиент.

Официален отговор на НАП

С т. IV.7. от Приложение №3 към Заповед №З -ЦУ-30-1247/25.08.2025 г. за изменение на Заповед №З -ЦУ-30-1085/25.07.2025 г. на изпълнителния директор, с която са утвърдени структурата, формата, съдържанието и начина на подаване на SAF-T, се регламентира, че при отразяването на отчет за извършени продажби (Код 81 от номенклатура Nom_Invoice_Types) се подава обобщена информация за извършените продажби за периода, за който се отнася файла, с идентификационни данни на лицето, подаващо файла, като в елемент S.I.36 ProductCode се посочва код „0“ (нула). Разчети свързани с картови транзакции (за плащания с банкови карти). Към въпроса е представено следното примерно: CustomerID (S.I.23) = ЕИК на Дружеството Name (S.I.24) = наименование на Дружеството Billing Address (S.I.25) = адрес на Дружеството AccountID (S.I.4) = 501 Каса в левове (за плащания в брой) или 446 Разчети свързани с картови транзакции (за плащания с банкови карти) ProductCode (S.I.36) = 0 Quantity (S.I.39) = 1 UnitPrice (S.I.42) = InvoiceLineAmount (S.I.46) При отразяване на фактури за продажби (платени в брой или с банкова карта) в подсекция 4.1 SalesInvoices, какво трябва да съдържа задължителния елемент S.I.4 AccountID към структура InvoiceStructure? Сочи се, че за фактури, които са заплатени в брой или с карта в обектите на дружеството, при осчетоводяване на продажбата не се използва разчетна сметка за клиент. С оглед на изложеното в елемент CustomerID (S.I.23) и в подструктура Customer Info (S.I.2) се посочват данни за лицето, подаващо файла, както е представено в примера от запитването Ви. Също така елементи S.I.36 ProductCode, S.I.39 Quantity и S.I.42 UnitPrice са попълнени правилно в примера и съответстват на изискванията на Приложение №3. По отношение на попълването на информация S.I.4 AccountID към структура InvoiceStructure, в бележките за елемента в колона М от Приложение №2 към заповедта на изпълнителния директор е посочено, че се подава балансова сметка за доставчик/клиент. В представения от Вас случай, в който за отчитане на продажбите не се използва отделна аналитична партида на тези клиенти, е допустимо в елемента да се подаде информация за сметката, която кореспондира със счетоводната сметка за отчитане на приходите от тези продажб и. Обръщам внимание, че в елемент S.I.30 AccountID се посочва съответната балансова/разходна/приходна сметка, кореспондираща с елемент S.I.4. AccountID по съответната транзакция, посочена в елемент S.I.18 TransactionID. Следва да имате предвид, че посочените от Вас фактури във втория Ви въпрос следва да се подадат в секция SourceDocuments, съответно в секция MasterFiles следва да се посочат данни за клиентите по тях, вкл. сметки и салда по тях. Същите данни следва да се п одадат и в секция GeneralLedgerEntries. В тази връзка препоръчваме да се използва с/ка от група 41, като по този начин ще се спази изискването за консистентност на подаваните данни в различните секции на файла, както и ще се отрази оборота с действителния клиент в счетоводните Ви регистри.

Официален въпрос

Молим Ви за потвърждение, че при износ в секция 4. SourceDocuments следва да се подават данни за продажната фактура и не се подават данни за митническата декларация за износа. Описаният подход за отчитане съответства на изискванията на ЗДДС и ППЗДДС, които са водещи при отчитането на документи в секция Потвърждаваме, че извършени доставка на стоки, изпращани или превозвани извън територията на Европейския съюз, се отчитат с отразяването на продажната фактура в подсекция SalesInvoices, секция SourceDocuments. 4. SourceDocuments, съгласно изискванията на първия абзац от точка 7 на приложение 3 към заповед № З-ЦУ-30-1085/25.7.2025 г.

Официален отговор на НАП

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

Официален въпрос

Как следва да се подава информация за протоколи за ВОП на стоки от свързани лица? Молим за потвърждение, че протоколите за ВОП, за които InvoiceType (S.I.9) = 9, следва да бъдат отразени едновременно в: 3.1) подсекция 4.1 SalesInvoices, като • в структура InvoiceStructure трябва да посочим InvoiceNo (S.I.1) = номер на протокола за ВОП SupplierID (S.I.23) = ДДС номер на доставчика -свързано лице, т.е. трябва да се използва подструктура SupplierInfo (S.I.3), а не CustomerInfo (S.I.2) AccountID (S.I.4) = 405 Задължения към доставчици – свързани лица Invoice date (S.I.8) = дата на протокола за ВОП • за всеки ProductCode (S.I.36) в отделен InvoiceLine трябва да посочим AccountID (S.I.30) = 304 Стоки TaxCode (S.TI.2) = 100212 (Данъчна основа на ВОП с 20% ДДС) 3.2) подсекция 4.2 PurchaseInvoices, като • в структура InvoiceStructure трябва да посочим InvoiceNo (S.I.1) = номер на протокола за ВОП SupplierID (S.I.23) = ДДС номер на доставчика-свързано лице AccountID (S.I.4) = 405 Задължения към доставчици – свързани лица Invoice date (S.I.8) = дата на протокола за ВОП • за всеки ProductCode (S.I.36) в отделен InvoiceLine трябва да посочим AccountID (S.I.30) = 304 Стоки TaxCode (S.TI.2) = 100331 (Данъчна основа на получени ВОП

Официален отговор на НАП

Представеният в запитването Ви пример за подаване на данни в подсекции 4.1 SalesInvoices и 4.2 PurchaseInvoices е в съответствие с изискванията за подаване на информация със стандартния одитен файл за данъчни цели.

Официален въпрос

Митническа декларация №BG000000000 – в информационната система е въведена с един ред с текст „Митническа облагаема стойност”, мярка брой, количество 1, ед. цена 15000лв., стойност 15000лв., ДДС – 3000лв. Счетоводните операции са 4531/458-3000лв. Данните в подсекция MovementOfGoods, секция SourceDocuments, са попълнени коректно. В подсекция PurchaseInvoice, секция SourceDocuments, в елементи S.I.36 ProductCode и S.I.37 ProductDescription следва да се посочи кодът и наименованието на Няма въведен код на продукт. Доставените стоки с митническата декларация са въведени с Invoice №SK5875 от чуждестранния контрагент /документът не се подава в SAF -T файла/ и са осчетоводени по сметката за разчет с контрагента 401. За доставката е въведен ск ладов документ за покупка, в който е цитиран Invoice №SK5875. В описаната ситуация са попълнени следните данни във файла: PurchaseInvoices: ……………………………………………… <nsSAFT:Invoice> <nsSAFT:InvoiceNo> BG000000000</nsSAFT:InvoiceNo> ………………………………………………………….. <nsSAFT:AccountID>458</nsSAFT:AccountID> …………………………………………………………. <nsSAFT:InvoiceLine> <nsSAFT:LineNumber>1</nsSAFT:LineNumber> <nsSAFT:AccountID>4531</nsSAFT:AccountID> <nsSAFT:ProductCode>0</nsSAFT:ProductCode> <nsSAFT:ProductDescription> Митническа облагаема стойност </nsSAFT:ProductDescription> ……………………………………………………. <nsSAFT:Quantity>1</nsSAFT:Quantity> <nsSAFT:InvoiceUOM>H87</nsSAFT:InvoiceUOM> <nsSAFT:UOMToUOMBaseConversionFactor>1</nsSAFT:UOMToUO MBaseConversionFactor> <nsSAFT:UnitPrice>15000.00</nsSAFT:UnitPrice> ……………………………………………………. <nsSAFT:Description> Митническа облагаема стойност </nsSAFT:Description> ……………………………………………………… <nsSAFT:InvoiceLineAmount> <nsSAFT:Amount>15000.00</nsSAFT:Amount> <nsSAFT:CurrencyCode>BGN</nsSAFT:CurrencyCode> внесения продукт от информационната система на лицето, което подава файла. При подаването на митническата декларация в секция SourceDocuments се посочват данни за всички внесени продукти на отделни линии, в които се посочва съответстващия им продуктов код в елемент S.I.36 ProductCode, в елемент S.I.41 InvoiceLineAmount се посочва сбора на митническата облагаема стойност и внесените мита за съответния продукт. Данните за продуктите/стоките, които са закупени от чуждестранното лице, установено извън ЕС, следва да се посочат и в подсекция Products на секция MasterFiles и мапират към комбинираната номенклатура KN8 TARIC. По отношение посоченото от Вас, че фактурата, с която са закупени стоките, „не се подава в SAF -T файла“, следва да имате предвид, че данни за фактурата могат да се подадат със счетоводна трансакция за нейното осчетоводяване, които се подават в секция GeneralLedgerEntries – в елемент GL.27 SourceDocumentID. <nsSAFT:CurrencyAmount>15000.00</nsSAFT:CurrencyAmount> …………………………………………………………… <nsSAFT:TaxInformation> <nsSAFT:TaxType>100</nsSAFT:TaxType> <nsSAFT:TaxCode>100331</nsSAFT:TaxCode> ………………………………………………………….. <nsSAFT:TaxAmount> <nsSAFT:Amount>3000.00</nsSAFT:Amount> <nsSAFT:CurrencyCode>BGN</nsSAFT:CurrencyCode> Въпрос: Правилно ли са попълнени данните?

Официален отговор на НАП

Данните в подсекция MovementOfGoods, секция SourceDocuments, са попълнени коректно. В подсекция PurchaseInvoice, секция SourceDocuments, в елементи S.I.36 ProductCode и S.I.37 ProductDescription следва да се посочи кодът и наименованието на Няма въведен код на продукт. Доставените стоки с митническата декларация са въведени с Invoice №SK5875 от чуждестранния контрагент /документът не се подава в SAF -T файла/ и са осчетоводени по сметката за разчет с контрагента 401. За доставката е въведен ск ладов документ за покупка, в който е цитиран Invoice №SK5875. В описаната ситуация са попълнени следните данни във файла: PurchaseInvoices: ……………………………………………… <nsSAFT:Invoice> <nsSAFT:InvoiceNo> BG000000000</nsSAFT:InvoiceNo> ………………………………………………………….. <nsSAFT:AccountID>458</nsSAFT:AccountID> …………………………………………………………. <nsSAFT:InvoiceLine> <nsSAFT:LineNumber>1</nsSAFT:LineNumber> <nsSAFT:AccountID>4531</nsSAFT:AccountID> <nsSAFT:ProductCode>0</nsSAFT:ProductCode> <nsSAFT:ProductDescription> Митническа облагаема стойност </nsSAFT:ProductDescription> ……………………………………………………. <nsSAFT:Quantity>1</nsSAFT:Quantity> <nsSAFT:InvoiceUOM>H87</nsSAFT:InvoiceUOM> <nsSAFT:UOMToUOMBaseConversionFactor>1</nsSAFT:UOMToUO MBaseConversionFactor> <nsSAFT:UnitPrice>15000.00</nsSAFT:UnitPrice> ……………………………………………………. <nsSAFT:Description> Митническа облагаема стойност </nsSAFT:Description> ……………………………………………………… <nsSAFT:InvoiceLineAmount> <nsSAFT:Amount>15000.00</nsSAFT:Amount> <nsSAFT:CurrencyCode>BGN</nsSAFT:CurrencyCode> внесения продукт от информационната система на лицето, което подава файла. При подаването на митническата декларация в секция SourceDocuments се посочват данни за всички внесени продукти на отделни линии, в които се посочва съответстващия им продуктов код в елемент S.I.36 ProductCode, в елемент S.I.41 InvoiceLineAmount се посочва сбора на митническата облагаема стойност и внесените мита за съответния продукт. Данните за продуктите/стоките, които са закупени от чуждестранното лице, установено извън ЕС, следва да се посочат и в подсекция Products на секция MasterFiles и мапират към комбинираната номенклатура KN8 TARIC. По отношение посоченото от Вас, че фактурата, с която са закупени стоките, „не се подава в SAF -T файла“, следва да имате предвид, че данни за фактурата могат да се подадат със счетоводна трансакция за нейното осчетоводяване, които се подават в секция GeneralLedgerEntries – в елемент GL.27 SourceDocumentID.

Официален въпрос

Как се отразява вноса по режима на чл. 167а от ЗДДС?

Официален отговор на НАП

При осъществяване на внос на стоки от предприятието, подаващо файла, който се документира с опростена декларация и е с отложено начисляване на данък при внос , митническата декларация се отразява в подсекция PurchaseInvoice, секция MasterFiles – като в елемент S.TI.2 TaxCode се посочва код от номенклатура TAX -IMP: „100330 Данъчна основа и данък на получените доставки, ВОП, получените доставки по чл. 82, ал. 2 - 6 ЗДДС и вносът без право на данъчен кредит или без данък.“. По отношение на протоколa по чл. 117 от ЗДДС, издаден на основание чл. 57, ал. 6 от ЗДДС, във връзка с чл. 49а от ППЗДДС, с който ще се начисли дължимия данък, същият се отразява му в подсекция SalesInvoice, секция MasterFiles - като в елемент S.TI.2 TaxCode се посочва код „100229 Внос по чл. 167а - Приложение №3 от ЗДДС.“. Протоколът се отразява и в подсекция PurchaseInvoice, като в зависимост от това дали е налице право на ползване на пълен или частичен данъчен кредит, в елемент S.TI.2 TaxCode се посочва един от следните кодове: - „100330 Данъчна основа и данък на получените доставки, ВОП, получените доставки по чл. 82, ал. 2 - 6 ЗДДС и вносът без право на данъчен кредит или без данък“; - „100331 Данъчна основа на получените доставки, ВОП, получените доставки по чл. 82, ал. 2 - 6 ЗДДС, вносът, както и данъчната основа на получените доставки, използвани за извършване на доставки по чл. 69, ал. 2 ЗДДС с право на пълен данъчен кредит“ или - „100332 Данъчна основа на получените доставки, ВОП, получените доставки по чл. 82, ал. 2 - 6 ЗДДС, вносът, както и данъчната основа на получените доставки, използвани за извършване на доставки по чл. 69, ал. 2 ЗДДС с право на частичен данъчен кредит“.

Официален въпрос

В секцията Purchase Invoices , как следва да се докладват вътреобщностните придобивания (ВОП) - освен протокола по чл. 117 от ЗДДС, следва ли да се докладва също и фактурата от чуждестранния доставчик, която е осчетоводена (реално размера на ДДС да се докладва с протокола, а с фактура та да се докладва данъчната основа). В противен случай бихме имали осчетоводена фактура от доставчик, която не би се докладвала в секция Purchase Invoices. В секцията Purchase Invoices, как следва да се докладват случаите на внос на стоки - освен митническата декларация за внос, следва ли да се докладва също и фактурата от чуждестранния доставчик, която е осчетоводена (реално размера на ДДС да се докладва с митническата декларация, а с фактурата да се докладва данъчната основа). В противен случай бихме имали осчетоводена фактура от доставчик, която не би се докладвала в секция Purchase Invoices.

Официален отговор на НАП

Съгласно изискванията на т. IV.7 от Приложение №3 към заповедта на изпълнителния директор, с която се определят редът и форматът за подаване на информация със стандартния одитен файл за данъчни цели, за доставки, за които съгласно ЗДДС се изисква съставяне на протокол или е наличен ЕАД (митническа декларация), в секция 4. SourceDocuments се подават данни за протокола/декларацията и не се подават данни за фактурата за доставката. При подаването на информация с протокол за ВОП на стоки или митническа декларация в подсекция PurchaseInvoice, секция SourceDocuments, в елементи S.I.36 ProductCode и S.I.37 ProductDescription следва да се посочи кодът и наименованието на закупените продук ти от информационната система на лицето, което подава файла. Обръщаме внимание, че при подаването на митническата декларация в секция SourceDocuments се посочват данни за всички внесени продукти на отделни линии, в които се посочва съответстващия им продук тов код в елемент S.I.36 ProductCode, в елемент S.I.41 InvoiceLineAmount се посочва сбора на митническата облагаема стойност и внесените мита за съответния продукт. Данните за продуктите/стоките, които са закупени от чуждестранното лице, следва да се посочат и в подсекция Products на секция MasterFiles и мапират към комбинираната номенклатура KN8 TARIC.

Официален въпрос

Прехвърляне на средства между собствени сметки на дружеството, обмяна на валута следва ли да се посочват в този Payments <Плащания>?

Официален отговор на НАП

Прехвърляне на средства между собствени сметки на дружеството не представлява плащания и не следва да се посочват в подсекция Payments.

Официален въпрос

Как се отразяват данни от масови плащания – например заплати. Следва ли да се посочва трансакцията за плащане на заплата за всеки отделен служител или е възможно да се посочат обобщени данни на един ред?

Официален отговор на НАП

Данните се подават съобразно отразяването им в счетоводната система на предприятието.

Официален въпрос

Как следва да се отразят плащания, които не могат да се идентифицират с конкретен контрагент и да се посочи неговия ID - например покупка на финансови инструменти?

Официален отговор на НАП

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

Официален въпрос

Някои ERP системи имат изградени системи за плащане, свързани с използването на т.нар. клиринг сметки. През тях реален касов поток към клиент или доставчик не минава, като чисто теоретично в края на деня крайния им баланс трябва да е 0. Транзакциите по тези сметки трябва ли да бъдат отчитани като плащания? Чисто счетоводно изплащането на едно задължение минава през два етапа, а не само един: а) Дебит сметка Доставчик / Кредит сметка Клиринг сметка б) Дебит сметка Клиринг сметка / Кредит сметка Разплащателна сметка Това би довело до умножаване на броя и общата сума на плащанията, които бихме показали в САФ-Т файла, което от своя страна би могло да доведе до разминавания между реалния касов поток и това, което ще видите в системите при Вас.

Официален отговор на НАП

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

Официален въпрос

Молим Ви за коментар относно начина за отчитане на частично прихващане в секция 4. SourceDocuments. За илюстрация искаме да разгледаме следния пример: извършено е частично прихващане на търговско задължение от 150 лв. с вземане от 100 лв. към един и същ контрагент, като едновременно с това е извършено плащане на остатъчното задължение от 50 лв. Съставени са следните счетоводни операции: • Дебит сметка 401 – 150 лв. • Кредит сметка 411 – 100 лв. • Кредит сметка 503 – 50 лв. Молим Ви за коментар дали е коректно отчитането на тази транзакция с payment method 02 Прихващане на следните три реда в подсекция Payments: • 1 ред: сметка 401 с дебитен индикатор, стойност 150 лв., с попълнен Supplier ID Подсекция Payments, секция SourceDocuments, съдържа информация за документи за извършени/получени плащания, включително данни за начина на плащане и свързани сметки, период, идентификатор на транзакцията, дата на трансакцията, описание и др. В подсекцията не се подава информация за задължения към ко нтрагентите на предприятието, подаващо файла. Предвид изложеното в така представения от Вас пример, не следва да се подава информация от първият ред (PaymentLine) - „сметка 401 с дебитен индикатор, стойност 150 лв., с попълнен Supplier ID“. Когато погасяването на задължението към доставчика на предприятието, подаващо файла, е осъществено чрез различни методи за плащане следва за различните методи да се подадена отделна структура за плащането. Във дадения от Вас пример, може да се подадат следните данни, като прихващането да се отрази в две линии на една структура на плащането: • 2 ред: сметка 411 с кредитен индикатор, стойност 100 лв., с попълнен Customer ID • 3 ред: сметка 503 с кредитен индикатор, стойност 50 лв., с попълнен Supplier ID. На трите реда в съответните полета Supplier ID и Customer ID се подава информация за един и същ контрагент, с който е извършено частичното прихващане с плащане на остатъка от сумата.

Официален отговор на НАП

Подсекция Payments, секция SourceDocuments, съдържа информация за документи за извършени/получени плащания, включително данни за начина на плащане и свързани сметки, период, идентификатор на транзакцията, дата на трансакцията, описание и др. В подсекцията не се подава информация за задължения към ко нтрагентите на предприятието, подаващо файла. Предвид изложеното в така представения от Вас пример, не следва да се подава информация от първият ред (PaymentLine) - „сметка 401 с дебитен индикатор, стойност 150 лв., с попълнен Supplier ID“. Когато погасяването на задължението към доставчика на предприятието, подаващо файла, е осъществено чрез различни методи за плащане следва за различните методи да се подадена отделна структура за плащането. Във дадения от Вас пример, може да се подадат следните данни, като прихващането да се отрази в две линии на една структура на плащането: • 2 ред: сметка 411 с кредитен индикатор, стойност 100 лв., с попълнен Customer ID • 3 ред: сметка 503 с кредитен индикатор, стойност 50 лв., с попълнен Supplier ID. На трите реда в съответните полета Supplier ID и Customer ID се подава информация за един и същ контрагент, с който е извършено частичното прихващане с плащане на остатъка от сумата. Плащане №1 SD.P.5 Payment ref no.: N SD.P.10 PaymentMethod: 02 – Прихващане SD.P.18 PaymentLineLineNumber: 1 SD.P.20 AccountID: 411 SD.P.22 CustomerID: ХХХХХХХХХХХ SD.P.27 PaymentLineAmount: 100 лв. SD.P.32 PaymentMechanism: 97 Прихващане между контрагенти (опционално за подаване) SD.P.18 PaymentLineLineNumber: 2 SD.P.20 AccountID: 401 SD.P.22 SupplierID: ХХХХХХХХХХХ SD.P.27 PaymentLineAmount: 100 лв. SD.P.32 PaymentMechanism: 97 Прихващане между контрагенти (опционално за подаване) Плащане №2 SD.P.5 Payment ref no.: N+1 SD.P.10 PaymentMethod: 03 - Безкасово плащане SD.P.18 PaymentLineLineNumber: 1 SD.P.20 AccountID: 403 SD.P.23 SupplierID: ХХХХХХХХХХХ SD.P.27 PaymentLineAmount: 50 лв. SD.P.32 PaymentMechanism: 42 Плащане по банкова сметка (опционално за подаване) Или прихващането да се подаде в две отделни структури на плащанията: Плащане №1 SD.P.5 Payment ref no.: N SD.P.10 PaymentMethod: 02 – Прихващане SD.P.18 PaymentLineLineNumber: 1 SD.P.20 AccountID: 411 SD.P.22 CustomerID: ХХХХХХХХХХХ SD.P.27 PaymentLineAmount: 100 лв. SD.P.32 PaymentMechanism: 97 Прихващане между контрагенти (опционално за подаване) Плащане №2 SD.P.5 Payment ref no.: N+1 SD.P.10 PaymentMethod: 02 – Прихващане SD.P.18 PaymentLineLineNumber: 1 SD.P.20 AccountID: 401 SD.P.22 SupplierID: ХХХХХХХХХХХ SD.P.27 PaymentLineAmount: 100 лв. SD.P.32 PaymentMechanism: 97 Прихващане между контрагенти (опционално за подаване) Плащане №3 SD.P.5 Payment ref no.: N+2 SD.P.10 PaymentMethod: 03 - Безкасово плащане SD.P.18 PaymentLineLineNumber: 1 SD.P.20 AccountID: 403 SD.P.23 SupplierID: ХХХХХХХХХХХ SD.P.27 PaymentLineAmount: 50 лв. SD.P.32 PaymentMechanism: 42 Плащане по банкова сметка (опционално за подаване)

Официален въпрос

В секцията Payments следва ли да се докладват разплащания с подопечни лица и служители (т.е., те не са доставчици или клиенти). В този случай какво следва да се посочи в SupplierID? Следва ли подопечни лица, във връзка с които има осчетоводявания и/или плащания през периода, да бъдат докладвани в Master Files в секциите Customers или Suppliers?

Официален отговор на НАП

В подсекция Payments не се подават данни за предоставени парични средства на подотчетни лица, но се подава информация за извършени плащания от тях към контрагенти на лицето, подаващо файла. При извършено плащане от подотчетно лице към контрагент в елемент SD.P.20 AccountID от подсекция PaymentLine се посочва разчетната сметка (сметка 422), тъй фактическото плащане е извършено от подотчетното лице. В елемент SD.P.10 PaymentMethod се посочва метод за разплащане „02 – Прихващане“, съгласно номенклатура Nom_PaymentMethod. При подаване на информация в елемент SD.P.32 PaymentMechanism (опционален за подаване), част от подсекция PaymentSettlement (която също е опционална за подаване), се посочва механизъм за разплащане „99 – Подотчетни лица“. В елемент SD.P.23 SupplierID се посочва идентификатора на лицето, подаващо файла, като в представения от Вас случай не се подават данни за подотчетните лица в подсекции Customers и Suppliers от секция MasterFiles.

Официален въпрос

В секцията Payments, как следва да се докладват плащания на данъци и осигуровки към НАП? Какво да се посочи в SupplierID в този случай? Следва ли за тези плащания на данъци и осигуровки да се посочи Tax Type и Tax Code и какви (напр. относно плащане на ДДС за внасяне, кой код следва да се използва, след като различните кодове се отнасят за различни типове доставки или покупки, а не ДДС по принцип)?

Официален отговор на НАП

При подаването на информация за плащания за данъци и задължителни осигурителни вноски в секция Payments се допуска да се подават данни за идентификатора на лицето, подаващо файла. Структура TaxInformation в подсекция Payments е опционална за подаване и съгласно Приложение №3 към Заповед №З -ЦУ-30-1247/25.08.2025 г. изменена със Заповед №З -ЦУ-30-1085/25.07.2025 г. на изпълнителния директор, с която са утвърдени форматът и редът за подаване на стандартния одитен файл за данъчни цели (SAF -T) е препоръчително да се докладва в случаите, когато информацията е налична в поддържаната счетоводна система и в използвания счетоводен софтуер. В тази връзка, ако желаете да подадете данни от опционалната структура TaxInformation в подсекция Payments следва да посочите в ел ементи S.TI.1 TaxType и S.TI.2 TaxCode код за неприложимост, съответно „000“ и „000000“.

Официален въпрос

В процеса на счетоводно отчитане се използват сметки за вътрешни разчети, по които сметки се отчитат взаимоотношения между функционално или териториално обособени звена на дружеството. Когато се извършва плащане от едното звено, но в сумата на плащането има част, която се отнася за покриване на задължение към същия доставчик, за доставка в другото звено операцията е следната: В звено А Дт. Доставчици звено А Дт. Вътрешни разчети по доставчици със звено Б Кт. Парични средства В звено Б Дт. Доставчици звено Б Кт. Вътрешни разчети по доставчици със звено А Разчетите между отделните звена на предприятието, което подава файла, не представляват плащания и не следва да се посочват в подсекция Payments. С оглед на което правилно разбирате, че в подсекцията следва да се подаде информация само за фактическото разплащане от „звено А“ към/от доставчиците/клиентите. В този случай, счетоводната сметка „Вътрешни разчети по доставчици“ се ползва и като сметка за плащане на задължението към доставчиците в звено Б без да носи информация за номенклатурите на код за начин наплащане (PaymentMethod) и код за механизъм на плащане (PaymentMechanism). Въпрос: В дадения пример достатъчно ли е в подсекция Payment на SAF-T файла да бъде подадена информация само за кореспонденциите по счетоводна сметка „Парични средства” в звено А? В случай, че отговорът е „не”, какви са вашите указания?

Официален отговор на НАП

Разчетите между отделните звена на предприятието, което подава файла, не представляват плащания и не следва да се посочват в подсекция Payments. С оглед на което правилно разбирате, че в подсекцията следва да се подаде информация само за фактическото разплащане от „звено А“ към/от доставчиците/клиентите. В този случай, счетоводната сметка „Вътрешни разчети по

Официален въпрос

Предоставен е аванс на подотчетно лице Х в размер на 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 – Подотчетни лица“.

Официален въпрос

Какво се подава в тези елементи?

Официален отговор на НАП

В елементи: - SD.P.1 Number of entries – стойността в елемента трябва да съответства на броя на всички подадени структури SD.P.15 Line в подсекция 4.3 Payments – Payment - SD.P.2 Total Debit - стойността трябва да съответства на общата сума в поле PaymentLineAmount /SD.P.27/, на линиите на плащанията за които е посочен индикатор "D" в поле DebitCreditIndicator /SD.P.26/ - SD.P.3 Total Credit - стойността трябва да съответства на общата сума в поле PaymentLineAmount /SD.P.27/, на линиите на плащанията за които е посочен индикатор "С" в поле DebitCreditIndicator /SD.P.26/ Обръщаме внимание, че в стойността, която се подава в елемент SD.P.26 DebitCreditIndicator е дебитна или кредитна сума, т.е. дебитните суми се отнасят за входящи парични средства, а кредитните за изходящи. До колкото в описанието към елемента е посочено: „Знакът на сумите на ниво ред зависи от този индикатор и следва да съответства на счетоводното записване (отразено в GeneralLedgerEntries)“ – следва да се има предвид, че пояснението се отнася за това с какъв математически знак (положителен или отрицателен) е отразена съответната сума в GeneralLedgerEntries.

Официален въпрос

По отношение на PaymentMethod - код 02 - за прихващане - с кои задължителни елементи и какво съдържание, които следва да подадем в одитния файл? Пример: Имаме вземане и задължение към контрагент, които е едносвременно и доставчик и клиент. Страните са се съгласили да прихванат насрещн итее вземания и задължения с протокол за прихващане. Как отразяваме този протокол за целите на одитния файл?

Официален отговор на НАП

Eлемент SD.P.10 PaymentMethod, който е част от подсекция Payments, секция MasterFiles, в който се посочват кодовете, посочени в номенклатурата на Nom_PaymentMethod. По отношение на представения от Вас пример, доколкото не е изяснена в детайли фактическата обстановка, изразяваме принципно становище: Протоколът, с който се извършва прихващане на вземания, които предприятието от дружеството „АЛФА“, със задълженията към същото дружество, се отразява подсекция Payments, секция MasterFiles, като се подават следните основни елементи: SD.P.8 TransactionID – номер на транзакцията, който да съответства на номер от GeneralLedgerEntries SD.P.10 PaymentMethod – метод на плащане „02“ SD.P.16 PaymentLine SD.P.18 LineNumber - 1 SD.P.20 AccountID – сметка от номенклатурата на НАП, към която в MasterFiles e мапирана сметката, по която се отчитат вземанията от „АЛФА“; SD.P.22 CustomerID – идентификатор на АЛФА SD.P.27 PaymentLineAmount – стойност на прихващането. SD.P.16 PaymentLine SD.P.18 LineNumber - 2 SD.P.20 AccountID – сметка от номенклатурата на НАП, към която в MasterFiles e мапирана сметката, по която се отчитат задълженията към „АЛФА“; SD.P.23 SupplierID – идентификатор на АЛФА SD.P.27 PaymentLineAmount – стойност на прихващането.

Официален въпрос

Имаме прихващане между счетоводни сметки, които аналитично се водят и във валута, различна от основната – например сметка 401 Доставчик X е в USD , а 411 Клиент Y е в EUR. Въпрос: Правилно ли са попълнени за примера елементи CustomerID, SupplierID и CurrencyCode в секции GeneralLedgerEntries и Payments ?

Официален отговор на НАП

В представения от Вас пример следва на всяка отделна линия на плащането (PaymentLine) за идентификатор на клиенти и доставчик се посочва идентификатора на контрагента, на който в линията е посочена разчетната му сметка. Обръщаме внимание, че в стойността, която се подава в елемент SD.P.26 DebitCreditIndicator е дебитна или кредитна сума, т.е. дебитните суми се отнасят за входящи парични средства, а кредитните за изходящи. До колкото в описанието към елемента е посочено: „Знакът на сумите на ниво ред зависи от този индикатор и следва да съответства на счетоводното записване (отразено в GeneralLedgerEntries)“ – следва да се има предвид, че пояснението се отнася за това с какъв математически знак (положителен или отрицателен) е отразена съответната сума в GeneralLedgerEntries. Представения от Вас пример следва да се докладва по следния начин: PaymentLine: 1 AccountID - сметка номенклатура НАП (сметка 411) CustomerID – 10XXXXXXXXX (Уникален код на Y) SupplierID – 0 DebitCreditIndicator – D PaymentLineAmount …….. PaymentLine: 2 AccountID - сметка номенклатура НАП (сметка 401) CustomerID – 0 SupplierID – 10XXXXXXXXX (Уникален код на Х) DebitCreditIndicator – C PaymentLineAmount ……..

Официален въпрос

Какви стойности се попълват в тези полета? Текущ период или друго, ако транзакцията е свързана с осчетоводяване в предходен период?

Официален отговор на НАП

Подсекцията 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.18 Line number в подсекция 4.4 MovementOfGoods - StockMovementLine. Моля да сте информирани, че дейността на нашето дружество се осъществяван чрез няколко склада, разположени на територията на страната. Движението на стоките се документира в зависимост от хипотезата, освен с фактура, дебитни и кредитни известия за покупка или продажба, а също така с документи от типа, напр. стоки на път, протоколи за брак, корекция от инвентаризация и др. Обичайно упоменатите документи съдържат няколко десетки реда, съответстващи на списъка с номенклатурата на стоките.

Официален отговор на НАП

В елемента се посочва общия брой на подадените линии (редове) на движенията на материалните запаси – независимо от вида на движението (покупка, продажба, брак, движение между складове, др.), т.е. в елемента се подава общия брой на подадените елементи SD.MG.18 Line number в подсекция 4.4 MovementOfGoods - StockMovementLine.

Официален въпрос

Елемент SD.MG.4 – Моля за допълнителни разяснения, съобразена с примери от базовата информация, предоставена в т.1 хо -гора, тъй като липса описание на изискваните полета „Описание“ и „Бележки“.

Официален отговор на НАП

Елемент SD.MG.4 StockMovement представлява конкретна структура StockMovement, съдържанието на която е посочено от елемент SD.MG.5 до елемент SD.MG.14.

Официален въпрос

Елемент SD.MG.5 - Моля за допълнителни разяснения за случая, когато използваните програмни продукти не съдържат „Уникален идентификатор на материалното движение от информационната система на данъкоплатеца“. Какво трябва да бъзе подадено като информация?

Официален отговор на НАП

В елемент SD.MG.5 Movement reference следва да се посочи уникален номер, генериран от използвания от Вас софтуер за съответното движението на стоково -материални запаси /СМЗ/. В случай че софтуерът не генерира такъв номер е допустимо в този елемент да се подаде идентификаторът на движението, посочен в елемент SD.MG.12 - System ID.

Официален въпрос

Елемент 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.5 Movement reference

Официален въпрос

За кои типове движения от номенклатура "Stock movement" е задължително попълването на елемент DocumentReference? Как трябва да бъде попълнен елементът, когато не се изисква документ?

Официален отговор на НАП

Движенията на стоково -материални запаси се обективират със съставянето на първичен счетоводен документи по чл. 6 от ЗСч. В бележките към елемент SD.MG.13 Document reference е посочено пояснение „Данните в полето следва да бъдат попълнени в случаите, в които съответния тип движение от "Stock movement" номенклатурата изисква наличието на документ.“, с оглед на което да може да се покрият изключителни случаи, при които не е наличен документ обуславящ движението на стоково -материалните запаси. Когато няма данни за документи за документ за движение на стоково -материални запаси – в елементи Document type и Document number се подава информация по преценка на лицето, подаващо файла, даваща достатъчно яснота за движението на стоково-материалните запаси.

Официален въпрос

Елемент SD.MG. 14 – Line - Моля за допълнителни разяснения, доколкото липсват пояснения в колони „Описание“ и „бележки“.

Официален отговор на НАП

Елемент SD.MG. 14 Line представлява конкретна структура StockMovementLine, съдържанието на която е посочено от елемент SD.MG.18 до елемент SD.MG.33.

Официален въпрос

В елемента „DocumentTypе” кодът или наименованието на документа от информационната система на данъкоплатеца трябва да се посочи?

Официален отговор на НАП

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

Официален въпрос

Елемент SD.MG. 18- Моля за допълнителни разяснения дали се касае за дублирана информация с Елемент SD.MG. 14.

Официален отговор на НАП

Елемент SD.MG. 14 насочва към конкретна структура StockMovementLine, като елемент SD.MG. 18 Line number е част от тази структура.

Официален въпрос

Моля, представете информация относно начина на подаване на информация за количество (мерна единица) на услуга със Стандартния одитен файл за данъчни цели (SAF-T)?

Официален отговор на НАП

Данни за мерна единица се подават в елементи MF.UOM.2 UnitOfMeasure, част от секция MasterFiles, SD.MG.28 UnitOfMeasure, част от секция SourceDocuments, и S.I.40 InvoiceUOM, част от структурата на реда на фактурата (InvoiceStructureLine), като при подаването на информация в тях се попълва съответстващата мерна единица от номенклатурата. В случаите на извършване на продажби на услуги, при подаване на информация за мерната единица на услугата в описаните по -горе елементи на SAF -T следва да се подаде съответстващия код на мерна единица, с която е определено количеството на услугата, например: код H87 – piece/брой (един); код HUR – hour/час; друг код, съответстващ на вида на предоставяната услуга.

Официален въпрос

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

Официален отговор на НАП

В секция SourceDocuments, подсекция AssetTransaction, се подават данни за всички движения на дълготрайни активи през съответния отчетен период (година).

Официален въпрос

Режимът за докладване на SD.AT.8 е „Optional“. Задължително ли е посочване на доставчик/клиент в SD.AT.8 или по избор, тъй като режимът за докладване е „Optional“ ?

Официален отговор на НАП

Елемент SD.AT.8 Supplier/Customer е опционален и може да не се подава. В случай, че в счетоводната система на лицето, което подава файла, има данни за доставчик/клиент може да се подадат данни за контрагента. В случаите, че транзакцията не е свързана с кон кретен контрагент се допуска да се подаде и ЕИК на лицето, което подава файла.

Официален въпрос

Моля, дайте пример, какво трябва да се посочи в „SD.AT.15“.

Официален отговор на НАП

Елементът е опционален за подаване. В него се посочва по кой метод е оценен актива, съгласно приетите счетоводни политики, например по балансова или възстановима стойност.

Официален въпрос

В „SD.AT.17“ се посочва: Вариант 1 - отчетна стойност след транзакцията или Вариант 2 - балансова стойност след транзакцията?

Официален отговор на НАП

В елемента се посочва балансова стойност на актива след транзакцията.

Официален въпрос

Към кой период следва да се подава балансовата стойност в елемент SD.AT.17 BookValueOnTransaction, подсекция В колона C от Приложение №2 към заповедта на изпълнителния директор на НАП, с която се определят редът и форматът за подаване на SAF-T, зa елемент SD.AT.17 BookValueOnTransaction е посочено, че AssetTransactionValuation, на актив след транзакция - към края на всеки месец или към 31.12.?

Официален отговор на НАП

В колона C от Приложение №2 към заповедта на изпълнителния директор на НАП, с която се определят редът и форматът за подаване на SAF-T, зa елемент SD.AT.17 BookValueOnTransaction е посочено, че AssetTransactionValuation, на актив след транзакция - към края на всеки месец или към 31.12.? в елемента се посочва балансовата стойност на актива след всяка транзакция.

Официален въпрос

Пиша Ви с молба за разяснение по конкретна позиция от Приложение 2: В стр. 5. Structures -> 5.4 BankAccountStructure на Приложение 2 има указание за подаване на информация, свързана с банковата сметка на фирмата. Не става ясно дали: 1. Трябва да се подадат всички активни сметки на фирмата за периода, без значение дали е имало движение по тях; 2. Трябва да се подаде само една основна, по която основно има движение; 3. Или трябва да се подадат всички активни банкови сметки, които са имали движение през отчетния период.

Официален отговор на НАП

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

Официален въпрос

Забелязахме, че елемент Header Comment в секция Header е отбелязан в последната версия на Приложение 2 като optional. Моля да потвърдите дали това следва да е така. Без този елемент как следва да се отбележи дали файлът е месечен, годишен или при поискване?

Официален отговор на НАП

С т. I.2 от Приложение № 3 към заповед № З-ЦУ-30-1085/25.7.2025 г. се определя форматът на Стандартния одитен файл, както и задължителното му наименование, в зависимост от това дали се подава месечно, годишно или при поискване. При подаване на файла в електронната услуга на приходната администрация и ако не е наименуван в съответствие с посочената конвенция в Приложение №3, то същият няма как да бъде приет. Също така XSD схемата има условия за съдържанието на трите вида файлове (месечен, годишен и при поискване). Например ако с месечен XML файл не се подаде някоя от задължителните секции/подсекции/елементи, то същият няма да се валидира към XSD схемата и няма да бъде приет. Отделно от изложеното няма проблем в елемент HeaderComment да се подава информация в ограничените стойности.

Официален въпрос

Коя сметка се попълва в секция „Структури“, подсекция 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.

Официален въпрос

Допустимо ли е да се отрази сметка 405 Задължения към доставчици – свързани лица в задължителния елемент S.I.4 AccountID към структура InvoiceStructure, подсекция 4.1 SalesInvoices, респективно да се използва подструктура S.I.3 SupplierInfo, а не S.I.2 CustomerInfo във фактури за вътреобщностни доставки (ВОД)? Сочи се, че дружеството осчетоводява вземанията си по ВОД по дебита на активно-пасивната сметка 405 Задължения към доставчици – свързани лица, т.е. извършва се автоматично прихващане на вземания по ВОД със задълженията по ВОП от свързаните лица. Дружеството не използва сметка 415 Вземания от клиенти – свързани лица за осчетоводяване на ВОД.

Официален отговор на НАП

При подаването на информация в елемент S.I.4 AccountID се подава информация за използваната счетоводна сметка, в която се отчитат разчетите с контрагента, с оглед на което трябва да подадете използваната от Вас сметка – 405 Задължения към доставчици – свързани лица. С т. I.1.4. от Приложение №3 към заповедта на изпълнителния директор, се регламентира, че при подаването на информация в подсекция SalesInvoices се посочват данни за клиенти, в тази връзка следва да се попълни подструктура S.I.2 CustomerInfo в структурата на фактурата. Обръщаме внимание, че при подаването на информация за контрагент, който е клиент и доставчик на предприятието, се подават данни за него и в двете подсекции Customers и Suppliers, които са част от секция MasterFiles. При условие, че във воденото от Вас счетоводство за такъв контрагент не са открити отделни партиди за клиент и доставчик, то в подсекция Customers се посочва аналитичната сметка на контрагента (405), за която се подава начално и крайно салдо, формирани на база разчетите, които са свързани с извършените към него доставки. В подсекция Suppliers се посочва аналитичнат а сметка на контрагента (405), за която се подава начално и крайно салдо, формирани на база разчетите, които са свързани с получените от него доставки. Не се допуска компенсиране на вземания и задължения от един контрагент за целите на представянето на инф ормация в SAF-T, в съответствие с принципите на Национален счетоводен стандарт/Международен счетоводен стандарт 1 „Представяне на финансови отчети“, относно оповестяването на информация за вземанията и задълженията.

Официален въпрос

Какво следва да се отбележи в поле - Индикатор за самофактуриране?

Официален отговор на НАП

В бележките и в семантични валидационни правила от Приложение №2 към заповедта на изпълнителния директор за елемент S.I.13 Self -billing indicator е посочено, че при издадена фактура от името на доставчика (в случаите по чл. 113, ал. 11 от ЗДДС) се посочва стойност „Y”, във всички останали случаи се посочва „N”.

Официален въпрос

Как следва да се отчитат транспорти разходи , с които се определя себестойност на стоката?

Официален отговор на НАП

Транспортните разходи, които се разпределят в стойността на стоката, се въвеждат на отделен ред (InvoiceLine) във файла, когато са посочени на отделен ред във фактурата.

Официален въпрос

Коя сметка се попълва в секция „Структури“, подсекция 5.10 InvoiceStructure-InvoiceLine, елемент S.I.30 –AccountID?

Официален отговор на НАП

Посочва се приходна/разходна сметка за съответният ред от фактурата , която кореспондира със сметката посочена в елемент S.I.4 AccountID. Кодът на аналитична та счетоводна сметка, трябва да съответства на предоставената номенклатура на сметки от НАП.

Официален въпрос

Покупка на артикули с фактура – в информационната система по сметка 401 е въведена фактура №0000000001 със следните редове, които са осчетоводени по разходни сметки и артикулите не подлежат на контролирано съхранение и допълнителна отчетност: Въпрос: Допустимо ли е в PurchaseInvoices да бъдат подадени три <nsSAFT:InvoiceLine>, в които в елемент „ProductCode” стои „0”?

Официален отговор на НАП

С указанията в т. IV.6 от Приложение №3 към заповедта на изпълнителния директор на НАП, са дадени насоки, че се допуска закупени материали, които не подлежат на контролирано съхранение, да се подават на един ред, но не задължават лицата, подаващи файла, да подават информацията в обобщен вид. Съответно се допуска, в описания от Вас случай, информацията да се подадена на три отделни реда (InvoiceLine), с посочен „ProductCode” „0”.

Официален въпрос

Какво следва да се отрази в елемент S.I.36 ProductCode към структура InvoiceLine, при закупуването на дълготрайни материални активи (ДМА) и при ВОП на продукти, които не подлежат на контролирано съхранени и се отчитат директно на разход, и ДМА?

Официален отговор на НАП

За елемент S.I.36 ProductCode към структура InvoiceStructure в бележките, в колона М от Приложение №2 към заповедта на изпълнителния директор, е посочено, че се попълва съгласно кодовете от системата на предприятието, които са подадени в секция MasterFiles, подсекция Products. В елемента се попълва стойност „0“ (нула) в случаите, посочени в т. IV.6 и 7 от Приложение №3 към заповедта на изпълнителния директор на НАП. С т. I.1.2. от Приложение №3 към заповедта на изпълнителния директор се регламентира, че в секция MasterFiles, подсекция Products, се подава информация за стоково -материални запаси. ДМА и продуктите, които не подлежат на контролирано съхранени и се отчитат директно на разход, не са стоково-материални запаси по смисъла на СС или на МСС . В тази връзка при закупването (вкл. и при ВОП) на ДМА и продукти, които не подлежат на контролирано съхранени и се отчитат директно на разход, в елемент S.I.36 ProductCode се подава „0“ (нула).

Официален въпрос

Какво се подава в елемента?

Официален отговор на НАП

В елемент S.I.46 InvoiceLineAmount се посочва стойността (данъчната основа) на съответния ред от фактурата.

Официален въпрос

Какво следва да се попълва в DebitCreditIndicator?

Официален отговор на НАП

Елементът служи за контролен ред. При попълването му се следва счетоводната логика при осчетоводяване на първични счетоводни документи, т.е. дали се води до генериране на приход/разход или до намаление в размера на генериран приход/разход. За яснота може да бъде даден следният пример: При осчетоводяване на разходна фактура: Сметка Сума Debit Credi tIndic ator Дт 602 – Разходи за услуги 1 000 D Кт 401 – Задължения към доставчици 1 000 При осчетоводяване на разходна фактура с отстъпка: Сметка Сума DebitCred itIndicator Дт 602 – Разходи за услуги 1 000 D Дт 609 – Търговски Отстъпки (100) C 401 – Задължения към доставчици 900 При осчетоводяване на кредитно известие: Сметка Сума DebitCr editIndi cator Дт 602 – Разходи за услуги (1 000) C Кт 401 – Задължения към доставчици (1 000)

Официален въпрос

Може ли допълнителни разяснения, от тези посочени във версия 1 на документа за съдействие за подаване на SAF-T (въпроси и отговори), за попълване на елемент S.I.47 DebitCreditIndicator?

Официален отговор на НАП

Показва дали сумите на ниво ред са дебитни или кредитни суми, т.е. дебит се използва за увеличение на стойността на вземане/задължение, а кредит за намалие. Записът трябва да съответства на записа (като положителна или отрицателна стойност), отразен в "Сче товоден запис" (GeneralLedgerEntries). Например връщане/сторно могат да са отрицателни суми. Съгласно бележките в приложение №2, се подава една от стойностите: - „C“ за кредит - използва се, когато стойността в реда намалява размера на вземането при продажна фактура, съответно на задължението при покупна фактура (напр. при КИ, отстъпка). Индикатор „C“ се използва само в случаите когато намалението на стойността е представено с положителен знак. - „D“ за дебит - използва се, когато стойността в реда увеличава размера на вземането при продажна фактура или задължението при покупна фактура. Индикатор „D“ се използва и в случаи, когато намалението на стойността е представено с отрицателен знак. Предвид изложеното в случаите на продажна фактура, която се отразява в SalesInvoices, секция SourceDocuments, се подава следната примерна информация: GeneralLedg erEntries Кт гр. 70: 1 000 Кт гр. 70: (100) Кт гр. 70: 1 000 Дт гр. 70: 100 SD.SalesInv oices Line 1: InvoiceLineAmount: 1 000 DebitCreditIndicator: “D” Line 2: InvoiceLineAmount: (100) DebitCreditIndicator: “D” Line 1: InvoiceLineAmount: 1 000 DebitCreditIndicator: “D” Line 2: InvoiceLineAmount: 100 DebitCreditIndicator: “C” В PurchaseInvoices, секция SourceDocuments, се подава следната примерна информация: GeneralLedg erEntries Дт гр. 60: 1 000 Дт гр. 60: (100) Дт гр. 60: 1 000 Кт гр. 60: 100 SD.Purchase Invoices Line 1: InvoiceLineAmount: 1 000 DebitCreditIndicator: “D” Line 2: Line 1: InvoiceLineAmount: 1 000 DebitCreditIndicator: “D” Line 2: InvoiceLineAmount: (100) DebitCreditIndicator: “D” InvoiceLineAmount: 100 DebitCreditIndicator: “C”

Официален въпрос

Каква сума се очаква да се попълни тук , ако документа не е платен при подаване нафайла нула ли се записва, ако е платен частично - частта на плащане. Какво става акодокумента се плати в следващ период, или е платен в предишен?

Официален отговор на НАП

Елемент S.I.61 SettlementAmount е част от структура S.I.21 InvoiceSettlement, която е опционална за подаване. В елемента се посочват плащания по фактури, когато са извършени в периода, през който е подадена информация за фактурата. Останалите плащания се докладват в подсекция Payments, секция MasterFiles.

Официален въпрос

Задължително поле при фактури за покупки е „начин на плащане“, какво се посочва в случай, когато на по -късен етап, например следващ отчетен период бъде уточнено с контрагента да се извърши прихващане с насрещни разчети, а в конкретната фактура е посочено „разплащане по банкова сметка“.

Официален отговор на НАП

Съгласно изискванията на чл. 71и, ал. 2, т. 4 от ДОПК със стандартния одитен файл за данъчни цели се подава информация за плащанията, включително за начина на плащане. Съгласно т. I.1.4. от Приложение №3 към заповедта на изпълнителния директор, издадена на основание чл. 71к, ал. 4 от ДОПК, тази информация се подава в подсекция Payments, секция SourceDocuments. В елемент S.I.63 PaymentMechanism от подструктура InvoiceSettlement, към която се препраща от структурата на фактурата (InvoiceStructure), който e опционален за подаване елемент, се посочва първоначално договорения между страните начин на плащане. При извъ ршване на плащането данни за същото се подават в подсекция Payments, секция SourceDocuments, без това да налага промяна на вече подадените в предходен отчетен период данни за фактурата, по която се извършва плащането.

Официален въпрос

Ако в документа има услуги: транспорт - очаква се да не се включва в тази сума така ли ? други разходи вкарани като услуги, примерно еко такси - включват ли се или не? корекция на цена вкарана като услуга - включва ли се Елемент S.I.66 NetTotal е част от структура S.I.22 InvoiceDocumentTotals, която е опционална за подаване. В елемента се посочва общата стойност (данъчната основа) на всички линии от фактурата. В случаите, когато във фактурата са включени транспортни и други съпътстващи разходи и същите са отразени в отделни линии на фактурата (структура S.I.20 InvoiceLine), то също сбора на данъчните им друга услуга която не може да се класифицира като данък, такса или транспортенразход включва ли се ?

Официален отговор на НАП

Елемент S.I.66 NetTotal е част от структура S.I.22 InvoiceDocumentTotals, която е опционална за подаване. В елемента се посочва общата стойност (данъчната основа) на всички линии от фактурата. В случаите, когато във фактурата са включени транспортни и други съпътстващи разходи и същите са отразени в отделни линии на фактурата (структура S.I.20 InvoiceLine), то също сбора на данъчните им друга услуга която не може да се класифицира като данък, такса или транспортенразход включва ли се ? основи следва да се отрази в елемент S.I.66 NetTotal. В случаите, когато съпътстващите разходи са капитализирани в стойността на стоково - материалните запаси/активите и са отразени в елемент S.I.48 ShippingCostsAmount (опционален за подаване) от линията на фактурата, то сбора на данъчните им основи се посочва в елемент S.I.65 ShippingCostsAmountTotal от структура S.I.22 InvoiceDocumentTotals. В общите стойности, посочвани в елементи S.I.65 ShippingCostsAmountTotal и S.I.66 NetTotal, не се включва дължимия ДДС или правото на ползване на данъчен кредит, които се отразяват с подаването на информация в елемент S.I.49 TaxInformation.

Официален въпрос

Дарение на стоки Дружество е закупило стока и е упражнило право на данъчен кредит. Впоследствие същата стока е дарена на община. В този случай дружеството следва да извърши корекция на ползвания данъчен кредит и да начисли ДДС чрез протокол. Бракуване на стоки Дружество е закупило стоки и е ползвало данъчен кредит при покупката. Впоследствие се налага бракуване на тези стоки, за които не е приложимо ограничението за корекции по чл. 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 се посоч ва стойността на начисления ДДС.

Официален въпрос

Необходимо ли е в подсекции SalesInvoices и PurchaseInvoices изобщо да се посочва код в случаите на покупки и продажби извън обхвата на ЗДДС и, ако да – кои кодове следва да се използват?

Официален отговор на НАП

За доставките, които са извън обхвата на ЗДДС, се посочват кодовете за неприложимост, посочени в номенклатурата за вид и код на данъка (TAX-IMP), съответно: за вид на данъка се посочва „000“, за код на данъка – „000000“.

Официален въпрос

Здравейте, Може ли да потвърдите дали изброените по -долу кодове се отнасят за: 1. Стандартни покупки с 0% ДДС – код 100330 В Дневник за покупките липсва специално обособяване на колони за право на данъчен кредит с 20% и с 9% ДДС, като логиката в SAF -T е същата. При подаване на информация за получени доставки с 20% или с 9% се прилага код 100331 „Данъчна основа на получените до ставки, 2. Стандартни покупки с 20% ДДС – код 100331 3. Стандартни покупки с 9% ДДС - - код 100332 Ако това не са правилните кодове, може ли да ни кажете кои кодове се отнасят за стандартни покупки с 0%, 9% и 20% право на данъчен кредит?

Официален отговор на НАП

В Дневник за покупките липсва специално обособяване на колони за право на данъчен кредит с 20% и с 9% ДДС, като логиката в SAF -T е същата. При подаване на информация за получени доставки с 20% или с 9% се прилага код 100331 „Данъчна основа на получените до ставки, 2. Стандартни покупки с 20% ДДС – код 100331 3. Стандартни покупки с 9% ДДС - - код 100332 Ако това не са правилните кодове, може ли да ни кажете кои кодове се отнасят за стандартни покупки с 0%, 9% и 20% право на данъчен кредит? ВОП, получените доставки по чл. 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, където се начислява сумата за данъчната основа при доста вка на продукти, липсва кореспонденция към счетоводна група 30, която формира данъчната основа за правото на ползване на ДДС. Това изключва възможността за коректно отчитане на фактури с редове с различни данъчни ставки. В структурата 453 се подават отчетната стойност и начисленото ДДС по видове ставки, но не е ясно кои конкретни редове от фактурите формират съответните данъчни основи. Това затруднява проследимостта и верификацията на данните. Моля за уточнение дали се предвижда допълнително структуриране или разширение на формата, което да позволи по-прецизно отчитане.

Официален отговор на НАП

В секция SourceDocuments, структурата TaxInformationStructure се подава: - в структурата на фактурата (InvoiceStructure , InvoiceLine, елемент S.I.49 Taxinformation), която се подава за продажни и покупни фактури (SalesInvoices и PurchaseInvoices), и - в реда на структурата на плащанията (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, където се посочва вида и кода на съответния данък?

Официален въпрос

Във връзка с внедряването на SAF-T може ли да ни съдей ствате относно данъчните кодове, има ли описание на всеки отделен данъчен код, дали е в дневника на покупки или в дневника на продажби?

Официален отговор на НАП

Със Заповед №З-ЦУ-30-1247/25.08.2025 г. за изменение на Заповед №З- ЦУ-30-1085/25.07.2025 г. на изпълнителния директор на НАП, издадена на основание чл. 71к, ал. 4 от ДОПК, се определя редът и форматът за подаване на Стандартния одитен файл за данъчни цели (SAF -T). Приложение №2 към заповедта (файл с наименование „SAF - T_BG_Structure_Definition_V_1.0.1.xlsx) съдържа стандартизирана номенклатура за вид и код на данъка (работен лист /sheet/ с наименование TAX -IMP). В посочената номенклатура кодовет е за данъците по ЗДДС са разработени на база кодовете, посочени в Приложение №12 към ППЗДДС, които понастоящем се посочват в подаваните отчетни регистри по чл. 124, ал. 1 от закона. В тази връзка кодовете за данъчни основи за продажби са от код 100211 до код 100233, съответно кодовете за данъчни основи на покупки са от код 100242 до код 100351.

Официален въпрос

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

Официален отговор на НАП

В бележките (колона М) от Приложение №2 към заповедта на изпълнителния директор на НАП, са дадени насоки за подаването на информация, когато действителния собственик е повече от един. XSD - схемата допуска елементи от S.O.2 до S.O.6 да бъдат подадени неограничен брой пъти. Обръщаме внимание, че в последната версия 1.0.1. на XSD -схемата посочените елементи са опционални.

Официален въпрос

В приложение 2 към Заповед на изпълнителния директор за формата и реда за подаване на SAF -T и приложения към нея, откривам два записа с еднакво описание и различни тарифни кода, което поставя въпроса за прилагането им: 1604 Приготвени храни и консерви от риби; хайвер и неговите заместители, приготвени на основата на яйца от риби 9 16041421 ----- В растително масло 1604 Приготвени храни и консерви от риби; хайвер и неговите заместители, приготвени на основата на яйца от риби 9 16041431 ----- В растително масло Моля за вашето указание!

Официален отговор на НАП

Кодовете по Комбинираната номенклатура КН8 2025 (Интегрираната тарифа на Европейските общности TARIC - Tarif intégré des Communautés européennes) се формират по следния начин: - първи и втори знак: посочват главата по Хармонизираната система на номеклатурата; - трети и четвърти знак: тарифна позиция; - пети и шести знак: тарифна подпозиция и - седми и осми знак: позиции, които служат за образуване на кода по Комбинираната номенклатура. В Приложение №2 (структура в табличен вид) от Заповедта на изпълнителния директор на НАП, с която се определят форматът и реда за подаване на Стандартния одитен файл за данъчни цели, са имплементирани само кодовете по номенклатура, като са дадени пояснения, че подробности за номенклатурата, нормативните актове, с които тя се създава и регулира за ползване - можете да се намерят на уебсайта на НАП и Агенция "Митници": - https://nra.bg/wps/portal/nra/intrastat/nomenklaturi/2025/f796555 e-bef7-4de2-98f4-e49ee5d1bc35 - https://customs.bg/wps/portal/agency/home/info- business/customs-activities/nomenclatures-and- tariffs/Kombinirana%20nomenklatura%20EU В случая двата кода, които са посочени във Вашето запитване, са от различни подпозиции, за по -голяма ясното прилагаме извлечение от TARIC 2025: 1604 14 -- Тон, ивичест тон и паламуд (Sarda spp.) --- Тон и скокливи риби ---- Скокливи риби 1604 14 21 ----- В растително масло kg ----- Други 1604 14 26 ------ Филета, наречени „карета“ kg 1604 14 28 ------ Други kg ---- Тон с жълти перки — албакор (Thunnus albacares) 1604 14 31 ----- В растително масло kg ----- Други Код 1604 14 21 е код от подпозиция: Скокливи риби, докато Код 1604 14 31 е от подпозиция: Тон с жълти перки — албакор (Thunnus albacares).

Официален въпрос

Когато доставчик (вносител) на дружеството в документи по доставката посочи код от елемента NC8_TARIC, въведен в неговата отчетна система, който код се различава от определения от дружеството -получател код за същата стока, кой код от елемента NC8_TARIC дружеството получател следва да обвърже с номенклатурата на материалните ни запаси?

Официален отговор на НАП

Посочва се определения код от лицето, което подава файла.

Официален въпрос

В практиката горива и смазочни материали се доставят и разходват по два начина: Допуска се за материали, които не се съхраняват контролирано (каквато хипотеза се застъпва и описания от Вас случай на зареждане на външни бензиностанции), в елемент S.I.36 ProductCode да се посочи „0” – вж. в - ГСМ, които се съхраняват в склад на съответното дружество се доставят и изписват по номенклатурен номер на материал (за целите на SAF -T, ще се генерира и информация за елемента NC8_TARIC); - ГСМ, които се зареждат директно в резервоарите на транспортните средства на външни бензиностанции. Тези ГСМ не се съхраняват в склад на дружеството и се изписват директно като разход за материал в сметка от гр.60. За целите на контрола на изминатите километри и изразходваните ГСМ от всяко едно транспортно средство, в модул „Транспорт“ на информационната система на дружество се въвежда информация за заредените количества ГСМ. Допустимо ли е стойността на ГСМ, които се зареждат директно в резервоарите на транспортните средства на външни бензиностанции, в секция „Изходни документи“ (SourceDocuments) в структурата на покупната фактура, да се посочи на един ред /InvoiceLine/, като в елемент S.I.36 ProductCode стойност се посочи „0”? В случай, че отговорът е „не”, какви са вашите указания?

Официален отговор на НАП

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

Официален въпрос

Дружество, чийто структурни звена са изнесени извън населените места, в рамките на социалната си програма организира столово хранене, за своя персонал. В този обект готовите ястия се продават по доставната цена на вложените в тях хранителните продукти, без да се добавят режийни и да се реализира печалба от тази дейност. Сготвените ястия, обичайно се реализират в деня на тяхното приготвяне. Те не подлежат на контролирано съхранение и допълнителна отчетност. Хранителните продукти от които са приготвени ястията подлежат на контролирано съхранение и допълнителна отчетност. Допустимо ли е, за целите на SAF -T, елемента NC8_TARIC да се подава само за хранителните продукти от които са приготвени ястията и SAF -T файла при поискване да се подава само за тях? Допустимо ли е, за целите на месечния SAF-T, елемента S.I.36 ProductCode в секция „Изходни документи“ (SourceDocuments), подсекция SalesInvoice за приготвените ястия да се подаде със стойност „0“ и информация за тях да не се подава в секция MasterFiles, подсекция “Products”? В случай, че отговорът е „не“, какви са вашите указания?

Официален отговор на НАП

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

Официален въпрос

В нашите база данни разполагаме с информация за кодовете от КН8 само за част от нашата номенклатура. Това е обусловено от съответствието с данните, изискуеми по действащата нормативна уредба за движенията на стоки в рамките на Европейския съюз. За останал ата част от нашата номенклатура ние имаме нужда от вашето съдействие. Целта ни е да получим ясна и актуална информация за съответните кодове от КН8, които са относими за продуктите от сферата на фармацевтичния бизнес и лекарствените продукти. Нашето питане е по принцип и касае връзката между код по КН и например национален номер на лекарствения продукт от ИАЛ или друг идентификатор от националните регистри на лекарствените продукти, който биха спомогнали за коректното идентифициране на код по К Н като ATC-код, Регистрационен номер в ИАЛ, INN, или др. По аналогичен начин стои въпроса продуктите подлежащи на регистрация в БАБХ (хранителни добавки, детски храни и др.), т.е. връзка между Код по КН на ЕС и регистрационен номер в БАБХ или др. институция. В този смисъл, бихме оценили високо, ако е възможно да ни предоставите съответна информация, ако това е възможно, или насоки за това, как можем да получим релевантна информация за КН8, например чрез Дирекция "ИНТРАСАТ" или друг източник, който разполага с данни При подаването на информация със Стандартния одитен файл за данъчни цели (SAF -T) в подсекции Products и PhysicalStock задължително се посочва съответстващия код на продуктите от номенклатура NC8_TARIC, която е неразделна част от схемата на SAF- T. Кодът за неприложимост „0“ се използва в случаите, в които продуктът не е посочен в комбинираната номенклатура. Националната агенция за приходите не разполага с данни, които могат да послужат за еднозначното обвързване на кодовете от комбинираната номенклатура с други кодове. На страницата на Националния статистически институт е публикувана подробна информация по отношение на Статистическа стокова номенклатура на Европейския съюз (КН -2025), вкл. са публикувани релационни връзки (обвързване) на КН -2025 с Класификация на продуктите по икономически дейности, Широки икономически групировки и др. Информацията може намерите на уеб-адрес: https://www.nsi.bg/issc/NSIExt/correspTableList;jsessionid=hVj- 1gpGzoOLG6b54Wk2ZC2lonLmMxr8c9MWVzsl.issc-prod- app1?idObj=6489&lang=1&locale=bg еднозначно обвързващи кода от КН с други уникални кодове на регистрация в съответните национални институции, които поддържат регистри на тези продукти. На тази база ще ни бъде възможно да продължим с обвързването на кодовете със съответните продукти, като същевременно спазваме законовите изисквания.

Официален отговор на НАП

При подаването на информация със Стандартния одитен файл за данъчни цели (SAF -T) в подсекции Products и PhysicalStock задължително се посочва съответстващия код на продуктите от номенклатура NC8_TARIC, която е неразделна част от схемата на SAF- T. Кодът за неприложимост „0“ се използва в случаите, в които продуктът не е посочен в комбинираната номенклатура. Националната агенция за приходите не разполага с данни, които могат да послужат за еднозначното обвързване на кодовете от комбинираната номенклатура с други кодове. На страницата на Националния статистически институт е публикувана подробна информация по отношение на Статистическа стокова номенклатура на Европейския съюз (КН -2025), вкл. са публикувани релационни връзки (обвързване) на КН -2025 с Класификация на продуктите по икономически дейности, Широки икономически групировки и др. Информацията може намерите на уеб-адрес: https://www.nsi.bg/issc/NSIExt/correspTableList;jsessionid=hVj- 1gpGzoOLG6b54Wk2ZC2lonLmMxr8c9MWVzsl.issc-prod- app1?idObj=6489&lang=1&locale=bg

Официален въпрос

Здравейте, какво следва да се разбира в НОМЕНКЛАТУРА НА МЕРНИТЕ ЕДИНИЦИ за следната мерна еденица: E27 dose доза

Официален отговор на НАП

Използваната в стандартния одитен файл за данъчни цели номенклатура за мерните единици е базирана на утвърдените мерни единици за международна търговия от Организацията на обединените нации (ООН), които може да откриете на следният уеб -адрес: https://www.unece.org/cefact/codesfortrade/codes_index.html. В бележките от документацията на ООН за мерна единица E27 „dose”е посочено, че е единица за броене, определяща броя на дозите (доза: определено количество различни лекарствени форми), за справка: https://unece.org/sites/default/files/2023-10/rec20_rev3_Annex3e.pdf

Официален въпрос

Във връзка с Приложение №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 една сметка от номенклатурата на НАП може да бъде мапирана с повече от една сметка от счетоводството лице, което подава файла. Например: AccountID TaxpayerA ccountID Account Description 604 60401 Разходи за заплати – персонал 604 60402 Актюерски загуби

Официален въпрос

Допустимо ли е, за отчитане на дългосрочните задължения към персонала при пенсиониране, формирани по реда на СС 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“? В случа й, че отговорът е „не“, какви са вашите указания?

Официален отговор на НАП

Считаме, че предложеното мапиране е допустимо.

Официален въпрос

Събрани суми от компании за инкасо, преди да постъпят по банковата сметка на дружеството, в коя сметка от елемент „NRA Nom of Accounts“ следва да се посочат – в сметките от „група 50: Парични средства“ или в сметка „491 Разчети с доверители“?

Официален отговор на НАП

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

Официален въпрос

Разходи за доходи изплатени на физически лица по извънтрудови взаимоотношения в коя сметка от елемент „NRA Nom of Accounts“, следва да се посочат в сметка „60204 Разходи за наем на персонал, квалификация и преквалификация на персонал“, в сметките от „група Разходи за външни услуги” (според вида на извършената работа), в сметка „604 Разходи за заплати (възнаграждения)”?

Официален отговор на НАП

Мапирането се следва да се извърши по преценка на лицето, подаващо файла, и в съответствие с възприетите счетоводни политики за отнасянето на разходите по различни елементи. Например, ако са възприети политики, че разходите за доходи, които са изплатени на ФЛ, които са самоосигуряващи се лица (СОЛ), се отнасят в „Разходи за външни услуги“, а тези за разходи за доходи, изплатени на ФЛ, които не са заявили, че са СОЛ, се отнасят в „Разходи за възнаграждения“ – то мапирането следва да се съобрази с възприетите политики.

Официален въпрос

Разчетите с физически лица по извънтрудови взаимоотношения в коя сметка от елемент „NRA Nom of Accounts” следва да се посочат – някоя от сметките от „група 40: Доставчици и свързани с тях сметки“ или в сметка „421 Задължения към персонал“ или сметка „499 Други кредитори”?

Официален отговор на НАП

Мапирането следва да се извърши по преценка на лицето, подаващо файла, и в съответствие с възприетите счетоводния политики. Считаме, че е допустимо мапиране както към сметките „група 40: Доставчици и свързани с тях сметки“ или към сметка „421 Задължения към персонал“.

Официален въпрос

За какво следва да се използват сметките от раздел 2, група 28 на в номенклатура „NRA Nom of Accounts“?

Официален отговор на НАП

В група 28 се отчитат активи с право на ползване, вкл. и такива формирани по реда на МСФО 16 „Лизинг“.

Официален въпрос

Допустимо ли е за доставките без фактури, да се използва сметка 401„Задължения към доставчици“ от елемент „NRA Nom of Accounts“, независимо че сметка „Доставчици без фактури“ се използва и за доставчици свързани лица. В случай, че отговорът е „не”, какви са вашите указания?

Официален отговор на НАП

Считаме, че предложеното мапиране е допустимо.

Официален въпрос

Имаме сметка 8888 – неуточнени преводи – къде я отнасяме съгласно сметкоплана на НАП, ако има салдо;

Официален отговор на НАП

Считаме, че сметка от счетоводството на лице с наименование „Неуточнени преводи” е удачно да се мапира със сметка „434 Неизравнени и неуточнени суми по преводи“.

Официален въпрос

Какво следва да се подава с код 80 Вътрешен трансфер, използван в номенклатура за движение на продукти (материални запаси)?

Официален отговор на НАП

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

Официален въпрос

Възможно ли е да се приложи в заглавната част на Дебитно известие да бъде посочено, че документа е фактура, но с допълнителен текст, че това е Дебитно известие към фактура номер и съответната дата.

Официален отговор на НАП

Издаден документ, наименуван „фактура“, който по същност и съдържание да отговоря на „дебитно известие“, се подава със SAF-T, като в елемент S.I.9 InvoiceType от структурата на фактурата (InvoiceStructure) следва да се посочи код „02 Дебитно известие“ от номенклатура Nom_Invoice_Types.

Официален въпрос

1. Моля да уточните: o Задължително ли е подаването на адреси на доставчици? o Къде точно в структурата на SAF -T файла се използват следните номенклатури: • Номенклатура на области – международен стандарт ISO 3166 -2; • Номенклатура на държави – международен стандарт ISO 3166 -1. Ще бъдем благодарни, ако можете да посочите конкретни стойности или формат на използване.

Официален отговор на НАП

Информацията за контрагенти на предприятието се подава в подсекции Customers и Suppliers, които изискват попълването на структура CompanyStructure (елементи MF.C.2 и MF.S.2). За подаването на данни с посочената структура следва да се попълни и структура за адрес – елемент S.C.3 Address, който насочва към структура Address Structure. В последната структура задължителни за докладване са елементи S.AD.5 City и S.AD.8 Country – останалата част от елементите в структурата на адреса е препоръчително да се подават , в случаите когато тази информация е налична в счетоводната система на предприятието, подаващо файла. Номенклатурата на области се подава в елементите, за които в колона К „Семантични валидационни правила“ е посочено: „Валидните кодове са кодове от ISO 3166-2:BG“. Номенклатурата е част от SAF -T и списък с използваните кодове може да се установи в работен лист „ISO3166-2BG - Area Codes“. Номенклатурата на държавите се подава в елементите от тип „ISOCountryCode“, и за които в колона К „Семантични валидационни правила“ е посочено: „Валидиране съгласно ISO3166-1-CountryCodes“. Списък с използваните кодове може да се установи в работен лист „ISO3166-1-CountryCodes“. За подаването на информация в тези елементи се използват кодовете, посочени в съответната номенклатура.

Официален въпрос

Искаме да тестваме електронната услуга и да подадем тестови файлове, но в момента в който, отидем на електронната услуга SAF -T подаване и натиснем бутона - не се случва нищо, даже напротив - системата ни изхвърля. Техническа ли е причината?

Официален отговор на НАП

НАП внедри електронни услуги - „Подаване на ТЕСТОВ стандартен одитен файл за данъчни цели (SAF-T)“ и „Подаване на стандартен одитен файл за данъчни цели (SAF- T)“. Подаването на файла се извършва по електронен път, чрез съответната електронна услуга в Портала за е-услуги на НАП (е -портал), достъпна с квалифициран електронен подпис (КЕП). Достъп до е -услугата се предоставя на данъчно задължени лица /ДЗЛ/ – ЕТ и юридически лица и упълномощени от тях лица, съгласно общите правила за подаване на данни и документи чрез Портала за електронни услуги на НАП. Начинът на достъп и упълномощаване за достъп до електронните услуги на НАП са описани в Правила за ползване на електронните услуги на НАП, предоставяни с квалифициран електронен подпис, който можете да намерите на адрес: https://nra.bg/wps/portal/nra/documents/euslugi/54c9edaf-4db0-4fb8-8b9d-1f43decb4c74. За достъп до услугата трябва да подадете чрез електронния портал Заявление за достъп, в което да посочите, че ще подавате документи в посочената е -услуга. Подаването на Стандартен одитен файл за данъчни цели (SAF -T) не е изключение от общите правила за нач инът на достъп и упълномощаване за достъп до електронните услуги на НАП.

Официален въпрос

Електронната услуга не ми позволява да кача файл, визуализира се сле дното съобщение: Каква може да е причината?

Официален отговор на НАП

Моля да проверите дали подаваният от Вас файл е в съответствие с примерните XML файлове и утвърдената XSD -схема (Приложение №1 към заповедта на изпълнителния директор на НАП, с която се определя редът и форматът за подаване на SAF-T) – по-конкретно проверете дали таговете (namespace) в подаваните файлове започват с nsSAFT, например <nsSAFT:Header></nsSAFT:Header>. Тази грешка предимно се среща при посочване таг от тип: <Header></Header>. Може да валидирате генерирания от Вас файл към утвърдената XSD схема, чрез XML валидатор, например: Notepad++, вграден валидатор на Linux, други.

Официален въпрос

След подаване на SAF-T получих следното съобщение за грешка: „Невалиден Header към XSD”. Каква може да е причината?

Официален отговор на НАП

Съобщение с грешка „Некоректен Header към XSD“ се получава като се изпрати повреден файл (който не може да се обработи или данни в него са нечетими). Например файлът може да е с грешен синтаксис, като незатворен таг, невалиден UTF-8 символ.

Официален въпрос

След подаване на SAF-T получих следното съобщение за грешка: „Видът на файла (месечен, годишен, при поискване), избран при подаването му в е -услугата, не отговаря на изискуемото съдържание за съответния вид файл .”. Каква може да е причината?

Официален отговор на НАП

В приложение №3 към заповедта на изпълнителния директор, с която се определят редът и форматът за подаване на стандартния одитен файл за данъчни цели, са посочени секциите и подсекциите, които се подават месечно, годишно или при поискване от орган по прихо дите. Утвърдената XSD -схема (Приложени №1 към заповедта) е структурирана по начин, който да съответства на трите вида файла: месечен, годишен и за наличие и движение на стоково-материални запаси. При подаването на месечен файл следва да се следват условията за месечен файл, посочени в XSD -схемата, т.е. трябва да се подадат всички задължителни секции/подсекции за месечния файл: <!-- Monthly sequence --> <xs:sequence> <xs:element ref="MasterFilesMonthly"/> <xs:element ref="CorrespondingAccountsReport" minOccurs="0"/> <xs:element ref="GeneralLedgerEntries"/> <xs:element ref="SourceDocumentsMonthly"/> </xs:sequence> В тази връзка, моля да проверите дали съдържанието на файла и по -точно как е организиран подаваният от Вас месечен файл и мястото на поставяне на тагове: <nsSAFT:MasterFilesMonthly>, <nsSAFT:SourceDocumentsMonthly> и другите секции/подсекции.

Официален въпрос

След подаване на SAF-T получих следното съобщение за грешка: „В елемент TaxType, подсекция TaxInformationStructure, секция Structures, е подадена некоректна стойност за вид на данък - несъответстващ на утвърдената номенклатура TAX-IMP”. Каква може да е причината?

Официален отговор на НАП

При подаването на грешен вид и код на данъка, в съобщението за грешката се визуализира грешната стойност. Посочената грешка се получава когато се подаде празен таг TaxType и TaxCode, когато няма стойност в елемента, – например: <nsSAFT:TaxInformation> <nsSAFT:TaxType/> <nsSAFT:TaxCode/> При подаване на информация за транзакции, които не са свързани с начисляването на данък се посочат кодове за неприложимост „000“ за вид на данъка и „000000“ за код на данъка.

Официален въпрос

След подаване на SAF-T получих следните съобщения за грешки: „Стойностите в елементи GL.28 CustomerID 104104104 и GL.29 SupplierID 104104104 в секция GeneralLedgerEntries не са попълнени съгласно изискванията и ли са подадени идентификатори за клиент/доставчик, който не фигурира в секция 2. MasterFiles, елемент MF.C .3/ MF.S.3. ” и „ Стойностите в елементи GL.28 CustomerID 10BG104104104 и GL.29 SupplierID 10BG104104104 в секция GeneralLedgerEntries не са попълнени съгласно изискванията и ли са подадени идентификатори за клиент/доставчик, който не фигурира в секция 2. MasterFiles, елемент MF.C.3/ MF.S.3.“. Каква може да е причината?

Официален отговор на НАП

Първото съобщение е получено, поради обстоятел ството, че подаденият идентификатор не е предхождан с код „10 - следван от ЕИК - където типът е 10, а ЕИК е уникалният идентификационен код за икономическите оператори, регистрирани в България“. Второто съобщение за грешка е свързано с това, че сте подали префикса за регистрация по ЗДДС „ BG” след код а за идентификаторът – в посочени я тип не се посочва префикс на държава.

Официален въпрос

След подаване на SAF-T получих следното съобщение за грешка: „Посочената в поле Total Debit SD.PI.2 стойност не съответства на общите суми посочени в поле S.I.46 InvoiceLineAmount, отразени в подсекция 5.10 InvoiceStructure, във връзка с препратка от подсекция 4.2 PurchaseInvoices – елемент SD.PI.4 Invoice, и е посочен индикатор "D" в поле S.I.47 DebitCreditIndicator“. Каква може да е причината?

Официален отговор на НАП

Стойностите посочени в елементи SD.SI.2 Total Debit и SD.PI.2 Total Debit – трябва съответства на общата сума на S.I.46 InvoiceLineAmount, SalesInvoices/PurchaseInvoices с посочен индикатор „D“ в поле S.I.47 DebitCreditIndicator. Към елемент ите не следва да се сборуват стойностите в елементи S.TI.6 TaxAmount , които са част от структурата S.I.49 TaxInformation, подструктура InvoiceLine. Съответно за елементи SD.SI.3 Total Credit и SD.PI.3 Total Credit - стойността съответства на общата сума на S.I.46 InvoiceLineAmount, SalesInvoices/PurchaseInvoices с посочен индикатор „С” в поле S.I.47 DebitCreditIndicator, без да се добавя сбора на стойностите в елементи S.TI.6 TaxAmount.

Официален въпрос

През периода, за който се отнася информация, нямаме получени или извър шени плащания, какво трябва да се подаде, като XSD-схемаа очаква да има информация в секциите?

Официален отговор на НАП

По отношение на запитването Ви за подаване на секции/подсекции от SAF-T за период, в който няма движение в същите, в тези случаи в елементи Number of entries, Total Debit и Total Credit се посочва стойност „0“ и се подава една структура, в която се посочват нулеви стойности. Например за период, в който няма плащания: <nsSAFT:Payments> <nsSAFT:NumberOfEntries>0</nsSAFT:NumberOfEntries> <nsSAFT:TotalDebit>0.00</nsSAFT:TotalDebit> <nsSAFT:TotalCredit>0.00</nsSAFT:TotalCredit> <nsSAFT:Payment> <nsSAFT:PaymentRefNo>0</nsSAFT:PaymentRefNo> <nsSAFT:Period>0</nsSAFT:Period> <nsSAFT:PeriodYear>0</nsSAFT:PeriodYear> <nsSAFT:TransactionID>0</nsSAFT:TransactionID> <nsSAFT:TransactionDate>1900-01-01</nsSAFT:TransactionDate> <nsSAFT:PaymentMethod>0</nsSAFT:PaymentMethod> <nsSAFT:Description>0</nsSAFT:Description> <nsSAFT:PaymentLine> <nsSAFT:LineNumber>1</nsSAFT:LineNumber> <nsSAFT:AccountID>998</nsSAFT:AccountID> <nsSAFT:CustomerID>0</nsSAFT:CustomerID> <nsSAFT:SupplierID>0</nsSAFT:SupplierID> <nsSAFT:DebitCreditIndicator>D</nsSAFT:DebitCreditIndicator> <nsSAFT:PaymentLineAmount> <nsSAFT:Amount>0.00</nsSAFT:Amount> <nsSAFT:CurrencyCode>BGN</nsSAFT:CurrencyCode> <nsSAFT:CurrencyAmount>0.00</nsSAFT:CurrencyAmount> </nsSAFT:PaymentLineAmount> </nsSAFT:PaymentLine> </nsSAFT:Payment> </nsSAFT:Payments> Например за период, в който няма направени счетоводни записвания: <nsSAFT:GeneralLedgerEntries> <nsSAFT:NumberOfEntries>0</nsSAFT:NumberOfEntries> <nsSAFT:TotalDebit>0.00</nsSAFT:TotalDebit> <nsSAFT:TotalCredit>0.00</nsSAFT:TotalCredit> <nsSAFT:Journal> <nsSAFT:Transaction> <nsSAFT:TransactionID>1</nsSAFT:TransactionID> <nsSAFT:Period>9</nsSAFT:Period> <nsSAFT:PeriodYear>2025</nsSAFT:PeriodYear> <nsSAFT:TransactionDate>1900-01-01</nsSAFT:TransactionDate> <nsSAFT:Description> </nsSAFT:Description> <nsSAFT:SystemEntryDate>1900-01-01</nsSAFT:SystemEntryDate> <nsSAFT:GLPostingDate>1900-01-01</nsSAFT:GLPostingDate> <nsSAFT:CustomerID>0</nsSAFT:CustomerID> <nsSAFT:SupplierID>0</nsSAFT:SupplierID> <nsSAFT:TransactionLine> <nsSAFT:RecordID>1</nsSAFT:RecordID> <nsSAFT:AccountID>998</nsSAFT:AccountID> <nsSAFT:TaxpayerAccountID>0</nsSAFT:TaxpayerAccountID> <nsSAFT:CustomerID>0</nsSAFT:CustomerID> <nsSAFT:SupplierID>0</nsSAFT:SupplierID> <nsSAFT:Description> </nsSAFT:Description> <nsSAFT:DebitAmount> <nsSAFT:Amount>0.00</nsSAFT:Amount> <nsSAFT:CurrencyCode>BGN</nsSAFT:CurrencyCode> <nsSAFT:CurrencyAmount>0.00</nsSAFT:CurrencyAmount> <nsSAFT:ExchangeRate>1.0000</nsSAFT:ExchangeRate> </nsSAFT:DebitAmount> <nsSAFT:TaxInformation> <nsSAFT:TaxType>000</nsSAFT:TaxType> <nsSAFT:TaxCode>000000</nsSAFT:TaxCode> <nsSAFT:TaxAmount> <nsSAFT:Amount>0</nsSAFT:Amount> <nsSAFT:CurrencyCode>BGN</nsSAFT:CurrencyCode> <nsSAFT:CurrencyAmount>0</nsSAFT:CurrencyAmount> <nsSAFT:ExchangeRate>0</nsSAFT:ExchangeRate> </nsSAFT:TaxAmount> </nsSAFT:TaxInformation> </nsSAFT:TransactionLine> </nsSAFT:Transaction> </nsSAFT:Journal> </nsSAFT:GeneralLedgerEntries> Например за период, в който няма извършени продажби или покупки: <nsSAFT:SalesInvoices> / <nsSAFT:PurchaseInvoices> <nsSAFT:NumberOfEntries>0</nsSAFT:NumberOfEntries> <nsSAFT:TotalDebit>0.00</nsSAFT:TotalDebit> <nsSAFT:TotalCredit>0.00</nsSAFT:TotalCredit> <nsSAFT:Invoice> <nsSAFT:InvoiceNo>1</nsSAFT:InvoiceNo> <nsSAFT:CustomerInfo> <nsSAFT:CustomerID>0</nsSAFT:CustomerID> <nsSAFT:Name> </nsSAFT:Name> <nsSAFT:BillingAddress> <nsSAFT:City></nsSAFT:City> <nsSAFT:Country>BG</nsSAFT:Country> </nsSAFT:BillingAddress> </nsSAFT:CustomerInfo> <nsSAFT:AccountID>998</nsSAFT:AccountID> <nsSAFT:InvoiceDate>1900-01-01</nsSAFT:InvoiceDate> <nsSAFT:InvoiceType>01</nsSAFT:InvoiceType> <nsSAFT:SelfBillingIndicator>N</nsSAFT:SelfBillingIndicator> <nsSAFT:TransactionID>1</nsSAFT:TransactionID> <nsSAFT:InvoiceLine> <nsSAFT:LineNumber>1</nsSAFT:LineNumber> <nsSAFT:AccountID>998</nsSAFT:AccountID> <nsSAFT:ProductCode>0</nsSAFT:ProductCode> <nsSAFT:ProductDescription>0</nsSAFT:ProductDescription> <nsSAFT:Quantity>0</nsSAFT:Quantity> <nsSAFT:InvoiceUOM>0</nsSAFT:InvoiceUOM> <nsSAFT:UOMToUOMBaseConversionFactor>1</nsSAFT:UOMToUOMBaseConversionFactor> <nsSAFT:UnitPrice>0.00</nsSAFT:UnitPrice> <nsSAFT:TaxPointDate>1900-01-01</nsSAFT:TaxPointDate> <nsSAFT:Description>Продажба</nsSAFT:Description> <nsSAFT:InvoiceLineAmount> <nsSAFT:Amount>0.00</nsSAFT:Amount> <nsSAFT:CurrencyCode>BGN</nsSAFT:CurrencyCode> <nsSAFT:CurrencyAmount>0.00</nsSAFT:CurrencyAmount> </nsSAFT:InvoiceLineAmount> <nsSAFT:DebitCreditIndicator>D</nsSAFT:DebitCreditIndicator> <nsSAFT:TaxInformation> <nsSAFT:TaxType>000</nsSAFT:TaxType> <nsSAFT:TaxCode>000000</nsSAFT:TaxCode> <nsSAFT:TaxAmount> <nsSAFT:Amount>0.00</nsSAFT:Amount> <nsSAFT:CurrencyCode>BGN</nsSAFT:CurrencyCode> <nsSAFT:CurrencyAmount>0.00</nsSAFT:CurrencyAmount> </nsSAFT:TaxAmount> </nsSAFT:TaxInformation> </nsSAFT:InvoiceLine> </nsSAFT:Invoice> </nsSAFT:SalesInvoices> / </nsSAFT:PurchaseInvoices>