Въпроси и отговори по SAF-T

Настоящата част съдържа въпроси и отговори по SAF-T, поставени от участници в проведените от автора д-р Петър П. Петров обучения във връзка с въвеждането и практическото прилагане на SAF-T. Въпросите не са хипотетични, а произтичат от реални затруднения, възникнали в работата на счетоводители, финансови специалисти, данъчни експерти и представители на бизнеса при подготовката за подаване на одитен файл, структурирането на данните и разбирането на нормативните изисквания. В този смисъл настоящата част има подчертано практическа насоченост и цели да даде ясен, систематизиран и полезен ориентир по темата.
Отговорите са подготвени с оглед на действащото към 11.03.2026 г. законодателство и следват общата ни философия – да съчетаят академичната точност с практически приложимото тълкуване. Поради това в изложението е търсена не само нормативна коректност, но и яснота по въпросите, които най-често възникват в практиката при настройването на системи, подготовката на данни, вътрешния контрол и оценката на данъчния риск.
За по-голяма прегледност въпросите и отговорите са структурирани в три тематични групи. Първата група обхваща въпроси, свързани с основните данни в одитния файл, включително сметкоплан, контрагенти, кодови таблици, идентификатори и други елементи на MasterFiles. Втората група е насочена към въпросите по документния поток и отчетните данни, включително фактури, кредитни и дебитни известия, плащания, ДДС аспекти и връзките между счетоводния и документния слой. Третата група включва въпроси по подаването на файла, сроковете, корекциите, валидирането, специфичните режими и практическите казуси, които възникват при реалното изпълнение на задълженията по SAF-T.
По този начин тази част не представлява просто приложение с отделни въпроси, а завършващ практически раздел, чрез който да се види как нормативната рамка и методологичните постановки от предходните раздели се прилагат към конкретни ситуации от практиката.

I. Номенклатури, мастер-данни и контрагенти (MasterFiles)

Въпрос 1. Бихте ли дали разяснения относно прилагането на Номенклатурата на НАП за данъци и такси?

Отговор 1. При подаването на SAF-T данъчната информация не се посочва със свободен текст, като например "ДДС 20%" или "данък върху разходите". За тази цел се използва Номенклатурата на НАП за данъци и такси, която съдържа точно определени кодове за отделните видове данъци. Именно тези кодове следва да се посочват във файла.
Това означава, че при фактурите за продажби и покупки се използват съответните кодове за ДДС, например за облагаема доставка със ставка 20 на сто, за вътреобщностна доставка със ставка 0 на сто или за освободена доставка. При счетоводните записвания в GeneralLedgerEntries се прилагат кодове и за други данъци, като данък върху разходите и данък при източника, включително когато е налице прилагане на намалена ставка по спогодба за избягване на двойното данъчно облагане.
Когато впоследствие се установи, че първоначално използваният код не съответства на действителното данъчно основание, следва да се подаде коригиран SAF-T файл. Така например, ако първоначално е приложен код за намалена ставка по спогодба, но впоследствие се установи, че условията за това не са налице, подава се корекция с правилния код.
Например, при обичайна продажба в страната, облагаема със ставка 20 на сто, във файла се посочва съответният код от номенклатурата за такава доставка. По същия начин, при начисляване на данък върху представителни разходи, се използва кодът за съответния данък, а не текстово описание.
Следователно Номенклатурата на НАП за данъци и такси изпълнява ролята на единен справочник за данъчните данни в SAF-T. Чрез нея се осигурява еднакъв подход при подаването на информацията и се създават условия за автоматизирана обработка и съпоставимост на данните.

Въпрос 2. Как се актуализират номенклатурите на НАП? Към момента те са публикувани като Excel файлове. Следващите промени по същия начин ли ще се предоставят?

Отговор 2. Към настоящия момент номенклатурите на НАП за целите на SAF-T се публикуват като част от официално обявените материали по темата, включително в Excel формат. Това е действащият практически начин, по който предприятията получават и прилагат съответните кодове и справочни данни.
При промяна в съдържанието на номенклатурите или в свързаните с тях технически изисквания следва да се изхожда от официално публикуваната от НАП версия. Нормативната основа е, че редът и форматът за подаване на SAF-T се определят със заповед на изпълнителния директор на НАП, а в публикуваната практика вече се вижда, че измененията се въвеждат именно чрез нова или изменена заповед и чрез обновяване на приложенията и файловете към нея.
Следователно към 11.03.2026 г. най-обоснованият извод е, че и следващите промени в номенклатурите ще се оповестяват по същия официален ред – чрез публикуване от НАП на нова действаща версия на съответните файлове и, когато е необходимо, на заповед за изменение. До този момент няма публично обявен отделен задължителен ред за актуализиране чрез самостоятелна електронна услуга. Поради това предприятията следва да следят именно действащата версия, публикувана на интернет страницата на НАП.

Въпрос 3. Доставчик от ЕС е посочил код по CN8/TARIC, който не съвпада с нашата вътрешна класификация. Кой код да използваме? И как процедираме, когато различни доставчици дават различни кодове за една и съща стока, а вътрешно ние я държим под един код?

Отговор 3. Когато доставчикът е посочил код по NC8/TARIC, който не съвпада с определения от Вас код за същата стока, в SAF-T се посочва кодът, определен от лицето, което подава файла. Това е и изричният отговор на НАП по този въпрос. В структурата на файла вътрешният продуктов код и кодът по комбинираната номенклатура имат различна функция: ProductCode е кодът от системата на лицето, а ProductCommodityCode е кодът по номенклатурата NC8_TARIC, който се обвързва към съответния продукт. Поради това кодът, изписан в документа на доставчика, не следва да се възприема автоматично само защото присъства в първичния документ.
Когато различни доставчици посочват различни кодове за една и съща стока, следва да поддържате последователно един код по NC8_TARIC, но само ако след Вашата преценка действително става въпрос за една и съща стока от гледна точка на класификацията. Ако различните кодове сочат към различни стоки или към различни подпозиции в комбинираната номенклатура, вътрешното Ви групиране под един общ код не е достатъчно и следва да бъде прецизирано така, че всеки отделен продукт да е обвързан със съответстващия му код.
Когато в документа на доставчика е посочен 10-цифрен TARIC, той може да служи като ориентир при вътрешната преценка, но за целите на SAF-T следва да се посочи кодът по номенклатурата NC8_TARIC, който подаващото лице е определило за продукта. Код "0" е допустим само когато продуктът не е посочен в комбинираната номенклатура; той не е общо решение при разминаване между доставчик и получател. Следователно за целите на SAF-T водещ е не кодът на доставчика, а кодът по NC8_TARIC, който Вие сте определили и поддържате последователно във Вашата продуктова номенклатура.

Въпрос 4. С каква номенклатура се отчитат полуфабрикатите в SAF-T – NC8, код "0" или друго?

Отговор 4. Полуфабрикатите по правило се обвързват с код по NC8_TARIC. В подсекция Products те са продуктови позиции и следва да имат собствен ProductCode, описание, мерна единица и ProductCommodityCode, съответстващ на комбинираната номенклатура. Това е общото правило за стоково-материалните запаси, които се включват в счетоводната отчетност на лицето.
Код "0" не следва да се използва като общо решение само защото става дума за полуфабрикат. Той е допустим единствено когато за конкретния продукт няма приложим код в комбинираната номенклатура. Следователно по-точно е да се каже, че при полуфабрикатите водещ е кодът по NC8_TARIC, а код "0" е изключение, приложимо само при липса на съответстващ код в самата номенклатура.
Необходимо е и още едно уточнение. Номенклатурата за вид на материалния запас не се попълва в Products, а в PhysicalStock, когато се подават данни за наличности при поискване. Там полуфабрикатът се отнася по съответния код за вид на материалния запас, обичайно като "продукция" или "незавършено производство" според счетоводната политика на предприятието. С други думи, полуфабрикатът участва в две различни класификации: като продукт по NC8_TARIC и, при подаване на наличности, като вид материален запас по съответната номенклатура.
За яснота следва да се разграничи и още нещо: правилото за ProductCode = "0" в PurchaseInvoices се отнася до директно разходвани покупки без контролирано съхранение. То не следва автоматично да се пренася към полуфабрикатите като материални запаси.

Въпрос 5. Ние сме производствена компания (ХВП). В процеса на производство генерираме полуфабрикати/незавършено производство и се затрудняваме да определим кода по КН 2025 (NC8). Допустимо ли е за тези артикули, отчитани по сметки от гр. 30, да се посочи код "0"? Ако отговорът е "не", кой код по NC8 следват – на крайния продукт или на материала? Пример: галета за производство на бисквити – по-правилно ли е 1105 или 1905?

Отговор 5. За полуфабрикатите и незавършеното производство не следва автоматично да се използва код "0". Когато съответният артикул е стоково-материален запас и се поддържа като продуктова позиция в SAF-T, за него следва да се посочи съответстващ код по NC8_TARIC. Код "0" е допустим само ако за конкретния продукт липсва приложим код в комбинираната номенклатура. Следователно самото обстоятелство, че артикулът е полуфабрикат или се отчита по сметки от група 30, не е достатъчно основание да се посочи код "0".
Не може да се приеме и общо правило, че полуфабрикатът следва непременно кода на крайния продукт или непременно кода на вложения материал. При класирането по КН е водещо състоянието и обективната характеристика на стоката към момента, в който тя се представя за класиране. Поради това, когато междинният продукт вече има основните белези на завършения продукт, той може да се класира като него; когато тези белези липсват, следва да се търси кодът на самия междинен продукт според неговия състав, предназначение и степен на обработка. КН 2025 се прилага от 1 януари 2025 г., а самата номенклатура съдържа общите правила за тълкуване, по които се извършва класирането.
По тази причина при смеси и теста за приготвяне на хлебарски, сладкарски или бисквитени изделия обичайно се насочва към глава 1901, а когато продуктът вече има характер на хлебарски, сладкарски или бисквитен продукт, релевантна е глава 1905.
Що се отнася до посочения пример, между 1105 и 1905 правилната глава е 1905, а не 1105. Това е така, защото код 1105 обхваща брашно, грис, прах, люспи, гранули и агломерати от картофи, докато глава 1905 обхваща хлебарски, сладкарски, бисквитени и други пекарски изделия. Следователно галета за производство на бисквити не следва да се класира по 1105. В рамките на поставената алтернатива правилният избор е 1905, като точният осемцифрен код следва да се определи според конкретните характеристики на продукта.

Въпрос 6. Ние сме лечебно заведение и в болнична аптека – структура на болницата, а не самостоятелно юридическо лице – имаме над 7 000 номенклатури лекарства, медицински консумативи, медицински изделия и др., необходими за осъществяване на лечебната дейност. Във фактурите за доставка и складовите разписки всяка номенклатура се въвежда отделно, както и разходът в лекарствените табели, които са документ за извършения разход. Не ги продаваме, а ги влагаме в дейността. В този контекст следва ли да ги обвържем с кодовете за файла и ще се подават ли в справките, поискани от НАП? Имаме и лекарства за милиони на годишна база, които РЗОК реимбурсира. Купуваме ги от доставчици, след това ги фактурираме на РЗОК и тя ни заплаща стойността на изписаните лекарствени средства. Същото се отнася и за медицински изделия, реимбурсирани от касата.

Отговор 6. Ако лекарствата, медицинските консумативи и медицинските изделия се поддържат като стоково-материални запаси под складов контрол и са част от счетоводната отчетност на лечебното заведение, те следва да бъдат включени в SAF-T. Определящо в случая не е дали се продават на свободния пазар или се влагат в лечебната дейност, а дали участват в отчетността на задълженото лице през съответния период. В действащото Приложение № 3 е посочено, че в подсекция Products при месечното подаване се включват всички стоково-материални запаси и услуги, които са в счетоводната отчетност на лицето за периода, като стоките и услугите се обвързват със съответстващ код от номенклатура NC8_TARIC.
За лекарствени продукти и медицински изделия официалните въпроси и отговори на НАП са още по-категорични. В тях изрично е посочено, че при подаване на информация в подсекциите Products и PhysicalStock следва да се посочва съответстващият код на продукта от номенклатура NC8_TARIC, а код "0" се използва само когато продуктът не е посочен в комбинираната номенклатура. НАП изрично отбелязва и че не разполага с данни за еднозначно обвързване между кодове от комбинираната номенклатура и други кодове, например национален номер на лекарствен продукт или друг вътрешен код. Това означава, че вътрешният код на болничната аптека не е достатъчен сам по себе си: необходим е и мапинг към NC8_TARIC, освен в изключителните случаи на неприложимост.
Фактът, че болничната аптека е вътрешна структура на болницата, а не отделно юридическо лице, не променя този извод. От значение е, че тези запаси са част от отчетността на лечебното заведение като задължено лице. Следователно, ако всяка номенклатура се завежда поотделно по фактури и складови разписки и се проследява при изписване, правилният модел е всеки артикул да има вътрешен ProductCode, мерна единица и съответстващ код по NC8_TARIC.
По отношение на това къде ще се виждат данните, е важно да се разграничат месечният файл и файлът при поискване. В месечния SAF-T тези артикули се виждат на първо място в MasterFiles/Products, а покупките им се отразяват и в PurchaseInvoices и в GeneralLedgerEntries според начина, по който са документирани и осчетоводени. Вътрешното им изписване по лекарствени табели не е част от обичайния месечен фактурен слой, а принадлежи към режима за наличности и движения на запаси. Именно затова при поискване от орган по приходите същите запаси следва да бъдат представени и в PhysicalStock и MovementOfGoods.
Що се отнася до лекарствата и медицинските изделия, които се реимбурсират от РЗОК, в официалната структура на SAF-T не е предвиден отделен изключващ режим за тях. Поради това те следва да се отразяват според начина, по който реално са документирани и осчетоводени в лечебното заведение: покупките от доставчиците - като покупки, а документите към РЗОК – съобразно Вашия модел на фактуриране и счетоводно отчитане. С други думи, реимбурсацията от РЗОК не изважда тези лекарства и изделия извън обхвата на SAF-T; тя само определя в коя част на документния и счетоводния поток ще се видят съответните операции. Това е извод от общата структура на файла и от липсата на специално изключение в нея.
Следователно най-точният кратък извод е следният: ако лекарствата, консумативите и медицинските изделия се водят като запаси в болничната аптека, те подлежат на обвързване с кодовете на SAF-T, включително с NC8_TARIC, и при поискване се включват и в справките за наличности и движения. Това, че са предназначени за собствена лечебна дейност или че впоследствие стойността им се реимбурсира от РЗОК, не ги изключва от файла.

Въпрос 7. Следва ли кодовете от номенклатурата TAX-IMP (TaxType/TaxCode) – в частност за корпоративен данък, данък върху разходите и данък върху дейността от опериране на кораби – да се обвързват със счетоводното записване за начисляване на конкретния данък или със счетоводните записвания, формиращи данъчната основа за начисляването му? Как следва да се процедира при данъка върху дейността от опериране на кораби, когато данъчната основа се определя по специален ред, който не поражда самостоятелно счетоводно записване?

Отговор 7. При използването на кодовете от номенклатурата TAX-IMP следва да се прави разграничение между самата номенклатура и правилата за нейното прилагане в отделните части на SAF-T. В SourceDocuments данъчните кодове се подават само за кодове, относими към ДДС и правото на данъчен кредит. Поради това кодовете за корпоративен данък, данък върху разходите и данък върху дейността от опериране на кораби не се подават през фактурните структури, а се разглеждат в контекста на GeneralLedgerEntries.
В GeneralLedgerEntries, на ниво TransactionLine, по общо правило се посочва съответният данъчен код. Наред с това официалните указания допускат използване на кодове за неприложимост, когато транзакцията не е свързана с начисляването на данъци от вид 600 "Данък върху разходите" и 700 "Данък при източника". В номенклатурата за тази цел са предвидени кодовете "000" за TaxType и "000000" за TaxCode.
За данъка върху разходите има специално изрично правило. Кодът се посочва при начисляването на разхода, за който се дължи данък върху разходите или за който може обосновано да се предположи, че ще формира такава основа. Следователно при TaxType 600 кодът по правило се обвързва със счетоводните редове за разхода, а не с отделния ред за начисляване на самия данък. Когато обаче отделен елемент от данъчната основа не поражда самостоятелен счетоводен запис, кодът се посочва при осчетоводяването на първичния счетоводен документ, с който се начислява дължимият данък.
За корпоративния данък и за данъка върху дейността от опериране на кораби официалната документация не съдържа аналогично правило, според което кодът трябва да се поставя върху редовете, формиращи данъчната основа. Поради това по-нормативно издържаният извод е, че не следва автоматично да се търси "маркиране на основата" по начина, по който това е уредено при данъка върху разходите. Ако предприятието използва конкретните кодове по TAX-IMP за тези данъци, по-защитимият подход е те да се обвързват със счетоводния запис, с който се признава самото данъчно задължение. Когато данъчната основа се определя по специален ред и не поражда самостоятелен счетоводен ред, не съществува отделен ред на "основата", към който кодът да бъде привързан. В такава хипотеза, ако се използва конкретен код, той логично се свързва със записа за начисляване на самия данък.

Въпрос 8. Може ли използването на множество мерни единици във взаимоотношения с клиент да представлява проблем от гледна точка на SAF-T отчетността? Имаме счетоводна/складова единица – кашони с артикули; на клиента се фактурира с търговска единица – бройка артикул; при връщане на стоките и отписване в склада на клиента се извършва в складова единица – кашон; продавачът издава кредитно известие с търговска единица – бройка артикул; документът за отписване е в търговска единица – бройка артикул.

Отговор 8. Използването на повече от една мерна единица само по себе си не противоречи на SAF-T. По действащите указания мерните единици се подават като кодове от официалната номенклатура, включват се в UOMTable за периода и се използват в съответните полета на документния и складовия слой, включително при InvoiceUOM и при движенията на запаси. Това означава, че системата не изисква непременно всички операции да се водят в една и съща мерна единица; тя изисква използваните мерни единици да бъдат формализирани и последователно прилагани.
Отделно, самата структура на SAF-T предвижда продуктът да има основна мерна единица, стандартна мерна единица и коефициент на преобразуване, а на ниво ред на фактурата е предвидена и мерна единица на реда, при необходимост с коефициент към базовата мерна единица. Това показва, че моделът допуска една и съща стока да се управлява в една мярка и да се фактурира в друга, стига връзката между тях да е предварително определена и устойчива.
В описания от Вас случай фактуриране в бройки и складово отчитане в кашони е допустимо, ако за съответния артикул е налице ясна и постоянна конверсия, например един кашон = определен брой артикули, и тази конверсия се прилага еднакво при продажбата, връщането, кредитното известие и складовото движение. Когато първоначалната продажба и кредитното известие са в бройки, а складовото движение е в кашони, това не е проблем, ако количествата могат еднозначно да се съпоставят след преобразуване.
Проблем възниква не от самото наличие на различни мерни единици, а от липсата на консистентност между тях. Такъв риск е налице, когато една и съща мерна единица се използва с различни кодове, когато в UOMTable липсва част от реално използваните мерни единици, когато няма зададена методика за преобразуване между складовата и търговската единица или когато редовете по документите не могат да бъдат количествено съгласувани със складовите движения. В тези случаи файлът може формално да бъде структуриран, но данните няма да бъдат достатъчно устойчиви за автоматични проверки и съпоставки.
Следователно най-точният извод е, че множеството мерни единици не са проблем за SAF-T, ако са правилно кодирани по номенклатура, включени са в UOMTable и между тях има ясна, стабилна и проверима връзка на ниво продукт и документ. Проблемът е не в различието на мерните единици, а в липсата на методика за преобразуване и проследимост между документния и складовия слой.

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

Отговор 9. Използването на различни видове кавички не е автоматично основание за грешка в SAF-T, но не следва да се приема и като напълно безрисково. На техническо ниво SAF-T се подава като XML файл в UTF-8, поради което типографските кавички в текстовото съдържание на елемент по правило не правят файла невалиден сами по себе си. Проблем може да възникне обаче на ниво конкретно поле, когато за него са предвидени по-тесни синтактични правила, стойности по номенклатура или стандартизирано попълване. Ето защо различните кавички в наименованието на дружеството обичайно не са самостоятелна причина за отхвърляне на файла, но в адресни компоненти и в полета с формализирани стойности могат да създадат риск от грешки или несъответствия. Практически правилният подход е основните данни да бъдат предварително нормализирани и да се използва единна политика на изписване, вместо да се допуска смесване на различни видове кавички в една и съща база данни.

Въпрос 10. В настоящия ни сметкоплан има сметки с букви, например 703А11, както и контрагенти с непълни адреси, например "гр. Трявна, ул. 11-ти септември" или само "гр. Трявна". Какво се случва с тях при SAF-T?

Отговор 10. При сметки като 703А11 проблемът не е в това, че кодът съдържа букви. По официалните разяснения на НАП със SAF-T се подава информация за най-ниското ниво на аналитичните счетоводни сметки, мапирани към номенклатурата на счетоводните сметки на НАП. Затова в секциите GeneralLedgerAccounts и GeneralLedgerEntries се работи с два различни кода: AccountID – съответстващият код от номенклатурата на НАП, и TaxpayerAccountID – вътрешният код на сметката в системата на лицето. Следователно код като 703А11 не следва да се отхвърля само защото е буквено-цифров; той може да остане като вътрешен код, ако това е действителният код на аналитичната сметка във Вашата система. Това, което трябва да бъде по номенклатурата на НАП, е AccountID.
Не е точно да се каже, че 703А11 "не може да бъде подаден". По-точно е да се каже, че той не следва да се подава като AccountID, но може да бъде подаден като TaxpayerAccountID, ако така е организиран вътрешният сметкоплан. Официалните въпроси и отговори на НАП дори изрично приемат, че кодът на аналитичните признаци може да бъде число, дата или текст, а информацията се подава на най-ниското аналитично ниво.
Има и още едно важно уточнение. В SourceDocuments официалната логика е по-строга: там НАП допуска само сметката от номенклатурата, а не вътрешния код на предприятието. Практически това означава, че вътрешният буквено-цифров код трябва да бъде надеждно съпоставен към валиден AccountID, а не да се прехвърля механично във всички части на файла.
По отношение на контрагентите рискът е по-съществен. В подсекциите Customers и Suppliers не е достатъчно да има само регистрационен номер или само свободно изписан адрес. По официалните отговори на НАП елементите MF.C.2 и MF.S.2 изискват структура CompanyStructure, в която задължително се подават RegistrationNumber, Name или NameLatin, Address, RelatedParty, а при определени условия и TaxRegistration. Следователно запис като "гр. Трявна" или "гр. Трявна, ул. 11-ти септември" не е достатъчен сам по себе си, ако в системата липсват данните, необходими за попълване на изискуемата адресна структура.
Затова правилният извод е следният: Сметки като 703А11 не трябва да се "прочистват" от букви насила; нужно е ясно разграничение между вътрешния код на сметката и кода по номенклатурата на НАП. При непълните адреси обаче е необходима предварителна нормализация и допълване на картоните на контрагентите, защото тук проблемът не е стилистичен, а структурен. При тази подготовка следва да се спазват и общите правила на SAF-T за текстовите полета и номенклатурите, включително за държави и области.

Въпрос 11. Ние ли трябва да си създадем кодове за: а) клиенти/доставчици; б) продукти/услуги; в) други номенклатури по SAF-T, или ги "вземаме" отнякъде?

Отговор 11. При SAF-T не може да се даде един общ отговор за всички кодове, защото режимът е различен според вида данни. Част от кодовете са вътрешни за системата на лицето, част са по официални номенклатури, а при контрагентите се прилага смесен подход.
По отношение на клиентите и доставчиците не следва да се използва напълно свободно създаден вътрешен код извън модела на схемата. CustomerID и SupplierID се формират по правилата на Приложение № 2. За български икономически оператори се използва модел 10 + ЕИК; за контрагенти от ЕС с валиден номер по ДДС – 11 + код на държава + ДДС номер; за контрагенти от трета държава с наличен официален номер – 12 + код на държава + официален номер; за физически лица – 13 + съответния персонален идентификатор. Само в изрично предвидените хипотези по кодове 14 и 15 структурата допуска уникалният код да бъде присвоен от задълженото лице, обичайно чрез информационната система. Това означава, че за контрагентите не си "измисляте" обща свободна номерация, а следвате предписания модел и генерирате идентификатор само в границите, които той допуска. Отделно от това в RegistrationNumber се подава официалният регистрационен номер на лицето – ЕИК, ДДС номер, служебен номер на НАП, ЕГН или друг официален номер за чуждестранно лице. Следователно CustomerID/SupplierID и RegistrationNumber не се заместват взаимно, а се подават с различна функция.
По отношение на продуктите и услугите логиката е различна. ProductCode е кодът от системата на лицето и в този смисъл той е Ваш вътрешен код. Именно той се подава в Products и се използва в документните редове. Това е потвърдено и в официалните разяснения на НАП, според които в редовете на документа се посочва кодът на продукта от информационната система на лицето, което подава файла. Но този вътрешен код не е достатъчен сам по себе си. В българския SAF-T продуктите и услугите следва да се обвържат и с ProductCommodityCode по номенклатура NC8_TARIC. За услугите НАП изрично приема код 000000. Следователно при продукти и услуги Вие поддържате вътрешния ProductCode, но класификационният код не се създава свободно, а се взема от официалната номенклатура. Изключение има само в ограничени случаи на ред на фактура, когато за материали, които не подлежат на контролирано съхранение, е допустимо ProductCode = 0. Това е изключение за документен ред, а не общо правило за продуктовата номенклатура.
За останалите номенклатури общото правило е, че не създавате собствени кодове, а съпоставяте вътрешните си стойности към официалните кодове на схемата. Това важи например за AccountID по номенклатурата на счетоводните сметки, за TaxType/TaxCode по данъчната номенклатура, за мерните единици в UOMTable, както и за други кодови списъци в модела. Вътрешни кодове могат да съществуват паралелно, но не заместват официалната номенклатура. Типичният пример е TaxpayerAccountID – той остава вътрешният номер на сметката във Вашата система, докато AccountID трябва да съответства на номенклатурата на НАП. Същата логика важи и при мерните единици: системата може да има вътрешна практика, но във файла се подават кодове от номенклатурата за мерни единици.
Най-краткият точен извод е следният: За клиенти и доставчици не изграждате свободна собствена номерация, а следвате модела на CustomerID/SupplierID от Приложение № 2 и отделно подавате RegistrationNumber. За продукти и услуги вътрешният ProductCode е Ваш, но класификационният код се взема от NC8_TARIC. За останалите речници по SAF-T се използват официалните номенклатури на схемата, а вътрешните кодове служат само като източник за съпоставяне, не като заместител на подлежащите на подаване кодове.

Въпрос 12. Можете ли да ни дадете препоръка как да си организираме кодовете? Имаме над 1000 контрагента, част български и част чуждестранни, и над 500 артикула.

Отговор 12. Практически най-устойчивото решение при 1000 контрагента е да организирате една централна картотека на контрагентите, в която за всеки запис да има поне: държава, вид лице, официален регистрационен номер, номер по ДДС, когато е приложимо, име и структуриран адрес. От тези полета следва автоматично да се формират CustomerID/SupplierID и RegistrationNumber. Ако контрагентът е от ЕС без активен номер по ДДС, тогава схемата допуска идентификатор по код 14, като след кода на държавата се използва известният данъчен или фирмен номер, а ако той не е известен – номер, присвоен от системата. Следователно вътрешен номер на контрагента може да имате за нуждите на ERP, но той не трябва да се смесва с идентификатора, който подавате в SAF-T.
При продуктите логиката е различна. Там ProductCode е именно кодът от Вашата информационна система и в този смисъл можете и следва да поддържате собствена вътрешна продуктова номерация. Тя обаче трябва да бъде устойчива и еднозначна във времето. За 500 артикула бих препоръчала кодът да бъде кратък, постоянен и без "вградено значение", което може да се промени, например без да съдържа в самия себе си склад, доставчик, държава или данъчен режим. Същественото е всеки ProductCode да е свързан в отделна картотека с описание, мерна единица и код по NC8_TARIC, когато това се изисква от схемата. В официалните указания на НАП изрично е посочено, че в документния слой се използва кодът на продукта от информационната система на лицето, а в Products стоките и услугите се обвързват със съответстващ код по NC8_TARIC.
За останалите номенклатури по SAF-T не следва да създавате собствени кодове, а да поддържате таблици за съпоставяне между вътрешните Ви стойности и официалните кодове на схемата. Това важи за сметките, данъчните кодове, мерните единици, държавите, валутите и останалите кодови списъци. Например вътрешната Ви счетоводна сметка може да остане в системата така, както работите с нея, но в SAF-T AccountID следва да съответства на номенклатурата на НАП; по същия начин мерните единици се подават по официалната номенклатура в UOMTable, а данъчната информация – чрез съответните кодове, а не със свободен текст.
Затова, ако трябва да обобщим препоръката в един работещ модел, той е двуслоен. На първо ниво поддържате собствените си вътрешни речници в ERP – картотека на контрагенти, картотека на продукти и вътрешни аналитичности. На второ ниво изграждате таблици за съпоставяне към изискванията на SAF-T, така че при експортиране системата автоматично да формира правилните CustomerID/SupplierID, да попълва отделно RegistrationNumber, да извежда правилния ProductCode, мерна единица и класификация, и да използва официалните кодове за сметки, данъци и други номенклатури. Така не променяте насилствено вътрешната си организация, но същевременно осигурявате файл, който е съвместим с правилата на НАП и устойчив при проверки. Изключението с ProductCode = 0 остава само за специално предвидените случаи на директно разходвани покупки в PurchaseInvoices, а не като общ метод за организиране на продуктовата номенклатура.

Въпрос 13. Необходимо ли е да взимаме информация за разплащателните сметки (IBAN) на контрагентите ни? При издаване на продажна фактура нямаме разплащателна сметка.

Отговор 13. Не е необходимо да събирате IBAN на контрагентите като общо и безусловно изискване на SAF-T. По структурата на Приложение № 2 банковата сметка е част от CompanyStructure, но е отбелязана като опционален елемент. Това означава, че за клиенти и доставчици банковата сметка не е сред минимално задължителните данни, без които записът в Customers или Suppliers е неизпълним. Същевременно в Приложение № 3 е посочено, че когато опционални данни са налични в използваните от задълженото лице информационни системи, е препоръчително да се подават с файла. Следователно IBAN на контрагента не е задължителен по принцип, но ако е наличен и се поддържа надеждно в системата, е добре да бъде включен.
Това е различно от режима за банковите сметки на самото подаващо лице. В официалните въпроси и отговори на НАП е изрично посочено, че в BankAccountStructure се подава информация за всички платежни сметки, които се използват от лицето, подаващо файла, независимо дали по тях има движение или салдо през периода. Този изричен отговор се отнася до собствените сметки на подаващото лице, а не до банковите сметки на неговите клиенти и доставчици. Поради това не бива да се пренася автоматично върху контрагентите.
При продажна фактура липсата на IBAN на клиента не е проблем. Във фактурния слой структурата изисква данни за клиента чрез CustomerInfo и CustomerID, а не задължително банкова сметка на клиента. При плащанията в подсекция Payments водещи са идентификаторът на клиента или доставчика, референтният номер на плащането и връзката към съответния документ. Тоест за целите на SAF-T е съществено плащането да може еднозначно да се свърже с контрагент и документ, а не да разполагате непременно с IBAN на насрещната страна още при издаването на фактурата.
По тази причина по-точният практически извод е следният. За клиентите и доставчиците не е нужно да събирате ретроактивно IBAN като задължителен елемент от картотеката само заради SAF-T. Ако такъв IBAN е наличен в ERP, в платежния модул или в банковите извлечения и е надеждно поддържан, може и е разумно да бъде подаден, защото повишава проследимостта. Ако не е наличен, това не прави продажната фактура или контрагента несъвместими със SAF-T. За собствените банкови сметки на дружеството обаче подходът е по-строг: те следва да бъдат поддържани и подавани като част от банковата информация на подаващото лице.

Въпрос 14. В сметка 401 "Доставчици" имаме голяма аналитичност по видове доставки – лекарства, медицински консумативи и др. до 401-16. Създадена е за анализи от страна на ръководството, както и за достоверна информация в отчетите, подавани към Министерството на здравеопазването. Един доставчик фигурира в множество сметки и подсметки, включително и по отделни договори. Следва ли за този доставчик във всички сметки да създаваме отделни кодове, или без значение на аналитичността за него да важи един единствен код?

Отговор 14. По бележката към елемент MF.S.5 AccountID и по официалните въпроси и отговори на НАП, когато разчетите или балансите с един контрагент се отразяват в повече от една счетоводна сметка, в MasterFiles се подават толкова структури Customer/Supplier, колкото са счетоводните сметки, по които се водят тези разчети. Това е действащата официална логика по SAF-T към актуалната база на НАП.
Следователно, ако един и същ доставчик се води например едновременно по различни AccountID от номенклатурата на НАП, за него не се създават "различни доставчици" в смисъл на различни лица, но в подсекция Suppliers се подават отделни структури за всяка такава счетоводна сметка. С други думи, контрагентът е един и същ, но представянето му в MasterFiles се повтаря по сметка. Официалният пример на НАП за Customers показва именно това: едно и също CustomerID се повтаря с различни AccountID, а в отговора изрично е посочено, че се подават толкова структури Customer/Supplier, колкото са счетоводните сметки. По аналогия същото правило се прилага и за доставчиците.
Но ако множествеността при Вас е само вътрешна аналитичност в рамките на един и същ AccountID 401 – например 401-01, 401-02, 401-16, отделни договори, отделни групи доставки – тогава не следва да създавате нов SupplierID за всеки договор, подсметка или вид доставка. В тази хипотеза доставчикът остава един и същ, а аналитичността се държи на най-ниското ниво на вътрешната счетоводна сметка чрез TaxpayerAccountID и другите вътрешни признаци в счетоводните записи. НАП изрично приема, че TaxpayerAccountID се подава на най-ниското ниво на аналитичните счетоводни сметки, водени в системата на лицето.
Затова най-точният извод е следният: не правите отделен код на доставчика за всеки договор или за всяка вътрешна подсметка, ако те са само аналитичност в рамките на една и съща счетоводна сметка. Правите отделни структури в Suppliers само когато един и същ доставчик се води по повече от една счетоводна сметка по смисъла на AccountID. Ако всичко е в рамките на 401, доставчикът остава един, а детайлът остава във вътрешната аналитичност.

Въпрос 15. Може ли вътрешното ID на записа в базата данни да се използва като уникален номер на клиент/доставчик?

Отговор 15. Вътрешното ID на записа в базата данни може да служи като вътрешен системен ключ в ERP или счетоводната система, но не следва автоматично да се приема, че именно то трябва да се подава в CustomerID/SupplierID. В българския SAF-T тези елементи се формират по нормативно зададена логика според вида на лицето, държавата и наличния официален идентификатор. Поради това вътрешното DB/ERP ID може да остане вътрешната опора на данните, а стойността, която се подава във файла, следва да бъде формирана по приложимия модел на схемата.
За български икономически оператор по правило се използва модел 10 + ЕИК. За контрагент от ЕС с валиден номер по ДДС се използва 11 + код на държавата + ДДС номер. За контрагент от трета държава с наличен официален номер се използва 12 + код на държавата + официалния номер, а за физически лица – 13 със съответния персонален идентификатор. При контрагент от ЕС без активен номер по ДДС се допуска 14 + код на държавата + данъчен или регистрационен номер, а ако такъв номер не е известен – номер, присвоен от системата.
Използването на вътрешно присвоен код е допустимо само в хипотезите, в които структурата изрично допуска това. Код 15 има резервен характер и не следва да се използва като обичаен заместител на ЕИК, ДДС номер или друг известен официален идентификатор. Когато е налице приложим официален номер, именно той определя логиката на CustomerID/SupplierID, а вътрешното ID остава вътрешен технически ключ.
Следва да се прави разграничение и между CustomerID/SupplierID и RegistrationNumber. RegistrationNumber е отделен елемент в CompanyStructure и представлява официалният регистрационен номер на контрагента. Следователно дори когато системата използва вътрешно DB ID за машинни връзки, във файла трябва отделно да се подаде и официалният регистрационен номер, когато такъв е налице.
Накратко, вътрешното ID на записа в базата данни може да бъде вътрешен системен ключ, но не и свободен заместител на CustomerID/SupplierID. В подадения файл идентификаторът на контрагента следва да се формира по нормативния модел за съответния вид лице, а вътрешно присвоен код се използва само там, където схемата изрично допуска това.

Въпрос 16. Задължително ли е да се събира и поддържа банкова сметка (IBAN) за всеки клиент?

Отговор 16. Не, не е задължително да се събира и поддържа IBAN за всеки клиент като общо условие за съответствие със SAF-T. В официалните разяснения на НАП за елементите MF.C.2 CompanyStructure и MF.S.2 CompanyStructure е посочено, че при подаване на тази структура следва да бъдат попълнени задължителните ? елементи, като сред тях са RegistrationNumber, Name или NameLatin, Address и RelatedParty, а TaxRegistration е задължителен само при определени условия. Банковата сметка не е посочена като безусловно задължителен елемент на структурата. Поради това липсата на IBAN в картона на конкретен клиент сама по себе си не води до несъответствие със SAF-T.
Същевременно Приложение № 3 изрично предвижда, че данните, определени като опционални, но налични в информационните системи на задълженото лице, е препоръчително да се подават с файла. Следователно, когато IBAN на клиента е наличен и се поддържа надеждно в системата, той може и е разумно да бъде включен. Това обаче не означава, че следва да се изгражда изкуствено изискване за пълно покритие на всички клиенти с банкова сметка.
Важно е да се прави разграничение между банковите сметки на контрагентите и банковите сметки на самото лице, което подава файла. Официалният документ с въпроси и отговори на НАП е категоричен, че в BankAccountStructure се подава информация за всички платежни сметки, които се използват от лицето, подаващо файла, независимо дали по тях има движения и салда през периода. Това правило се отнася до собствените сметки на подаващото лице, а не до задължение да се събира IBAN за всеки клиент.
Накратко, IBAN на клиента е опционална, а не универсално задължителна информация. Той следва да се поддържа и подава, когато е наличен и действително участва в информационния поток на предприятието, но SAF-T не изисква задължително събиране на клиентски IBAN за всеки контрагент.

Въпрос 17. Задължително ли е за всеки клиент и доставчик да е попълнен адрес и банкова сметка?

Отговор 17. По действащата към март 2026 г. официална база на НАП и публикуваните разяснения по SAF-T, за клиентите и доставчиците не може да се даде един и същ отговор за адреса и за банковата сметка, защото двата елемента имат различен режим в структурата на файла.
Адресът е задължителен. В официалните въпроси и отговори на НАП е посочено, че елементите MF.C.2 и MF.S.2 изискват попълване на CompanyStructure, а в нея сред задължителните елементи са RegistrationNumber, Name или NameLatin, Address и RelatedParty, като TaxRegistration е задължителен при определени условия. Това означава, че за клиент и доставчик не е достатъчно да има само идентификатор или само име; необходима е и адресна структура. По самото Приложение № 2 в Address Structure задължителни са най-малко City и Country, докато улица, номер, пощенски код и регион са опционални. Следователно адресът е задължителен като структура, но не всеки негов компонент е задължителен.
Банковата сметка не е универсално задължителна за всеки клиент и доставчик. В CompanyStructure елементът S.C.6 Bank Account е опционален, поради което липсата на IBAN в картона на даден контрагент сама по себе си не прави записа невалиден. Това се вписва и в общото правило на SAF-T, че когато една опционална структура не се подава, нейните вътрешни задължителни полета не се изискват.
Ако обаче банкова сметка се подава, тя трябва да бъде попълнена изцяло според правилата на BankAccountStructure. Когато сметката е с IBAN, се подава IBANNumber. Когато не е IBAN и е издадена от платежен оператор или дружество за електронни пари, се подават AccountNumber и SortCode. Следователно банковата сметка не е задължителна за всеки контрагент, но ако бъде включена във файла, вече трябва да отговаря на структурата и на формалните изисквания на схемата.
Накратко, за всеки клиент и доставчик следва да има попълнен адрес в изискуемата от схемата структура, докато банковата сметка е опционална и се подава, когато е налична и се поддържа в информационната система на лицето.

Въпрос 18. Ако имаме въведена в системата повече от една банкова сметка на контрагент, всички ли трябва да подадем? Някои фирми изискват плащане на различни фактури по различни сметки.

Отговор 18. За банковите сметки на контрагентите официалната база на НАП не въвежда правило, аналогично на това за собствените банкови сметки на лицето, което подава файла. В CompanyStructure елементът S.C.6 Bank Account е опционален, а в официалните разяснения на НАП сред задължителните елементи на тази структура са RegistrationNumber, Name или NameLatin, Address и RelatedParty, като TaxRegistration е задължителен само при определени условия. Банковата сметка не е сред безусловно задължителните елементи. За разлика от това, за банковите сметки на самото подаващо лице НАП изрично приема, че в BankAccountStructure се подават всички платежни сметки, които то използва, независимо дали по тях има движение или салдо през периода.
Оттук следва, че когато в системата са записани няколко банкови сметки на един и същ контрагент, не е налице изрично изискване по SAF-T да се подават механично всички исторически, неактивни или информационно налични сметки само защото присъстват в базата. Приложение № 3 предвижда, че когато опционални данни са налични в информационните системи на задълженото лице, е препоръчително да се подават с файла. Това следва да се разбира като подаване на надеждно поддържани и релевантни данни, а не като задължение за изчерпателен архив на всички някога въведени сметки на контрагента.
Когато различни фактури по установена практика се плащат по различни сметки на един и същ контрагент, тези сметки следва да бъдат поддържани последователно във вътрешната система, така че плащането да може еднозначно да се свърже с правилния контрагент и правилния документ. Практическият извод е, че за целите на SAF-T следва да се подават онези банкови сметки на контрагента, които са реално използвани и надеждно поддържани в документния и платежния поток, а не задължително всички исторически сметки, останали в системата.

Въпрос 19. Има ли номенклатури за сметки при префактуриране?

Отговор 19. В действащата към март 2026 г. официална база на НАП не е предвидена отделна специална номенклатура за сметки при префактуриране. В публикуваните приложения към заповедта на изпълнителния директор на НАП и в рубриката с актуалните документи по SAF-T се работи с общата номенклатура на счетоводните сметки, а не с отделен речник за операции по префактуриране.
Това означава, че при префактуриране се прилагат общите правила за счетоводните сметки. В GeneralLedgerAccounts се подава съпоставка между вътрешната сметка на лицето и съответстващата сметка от номенклатурата на НАП, тоест между TaxpayerAccountID и AccountID. В официалните въпроси и отговори на НАП изрично е посочено, че в GeneralLedgerAccounts се подават и вътрешната сметка на лицето, и съответстващата сметка от номенклатурата на НАП; в GeneralLedgerEntries се използват и двете, а в SourceDocuments се допуска само сметката от номенклатурата на НАП. Следователно, ако предприятието отчита префактурирането чрез сметки като 498, 401 и 411 или чрез друг вътрешен модел, в SAF-T не се създава нова "префактурна" номенклатура, а се подават реално използваните сметки, съпоставени към официалната номенклатура на НАП.
В документния слой префактурирането също не се третира чрез самостоятелен код за сметки. То се отразява чрез обичайните подсекции PurchaseInvoices и SalesInvoices, според това как са документирани първоначалната покупка и последващото фактуриране. Данъчната логика се подава чрез съответните данъчни кодове по общия ред на SAF-T, а не чрез отделна номенклатура на сметки за префактуриране.
Що се отнася до CorrespondingAccountReport, той не е номенклатура за префактуриране. Това е опционална контролна справка в структурата на файла, която може да подпомогне съгласуването между сметки и обороти, но не създава специален режим за такива операции. Във версия 1.0.1 е направена техническа промяна, позволяваща съответната структура да се подава многократно, но това не променя характера й на опционален контролен слой.
Накратко, при префактуриране не се използва отделна номенклатура за сметки. Прилага се общата номенклатура на НАП за счетоводните сметки, вътрешните сметки на предприятието се мапират към нея, а самата операция се отразява по общите правила на GeneralLedgerAccounts, GeneralLedgerEntries и SourceDocuments.

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

Отговор 20. При SAF-T липсата на плащания не означава, че разчетната информация отпада от файла. По официалната структура на НАП подсекция GeneralLedgerAccounts съдържа аналитичните счетоводни сметки с начални и крайни салда за периода. Отделно, подсекциите Customers и Suppliers съдържат данни за контрагентите и аналитичната сметка, за която се подава начално и крайно салдо. Следователно, когато разчетна сметка има остатък, но през месеца няма плащане, това не я изважда от обхвата на SAF-T.
Ако през конкретния месец по такава сметка няма никакво счетоводно движение, за нея не възникват редове в GeneralLedgerEntries само поради самото наличие на остатък. Тя остава видима чрез началното и крайното си салдо в GeneralLedgerAccounts, а когато е разчет с клиент или доставчик – и чрез съответната структура в Customers или Suppliers. Ако обаче има счетоводни движения без плащане, например прехвърляне, корекция, курсова разлика, обезценка или друго осчетоводено събитие, тогава тези движения се подават в GeneralLedgerEntries по общия ред.
Подсекцията Payments има по-тесен обхват. По официалните разяснения на НАП в нея се подава информация за плащания, свързани със закриване на вземания и задължения към контрагенти, а не движения между собствени сметки или към клирингови сметки. В XSD схемата елементът Payment е с minOccurs="0", поради което при липса на плащания подсекцията може изобщо да не присъства във файла. Това е валидно състояние, а не грешка.
По отношение на въпроса кога се подават движенията, официалните разяснения на НАП правят важно разграничение между SystemEntryDate и GLPostingDate. Когато информацията е въведена през текущия месец, но се отнася за предходен счетоводен период, тя се подава в текущия месечен файл, като в елементите Period, PeriodYear и GLPostingDate се посочва предходният период, за който се отнася осчетоводяването. Поради това не е точно да се каже, че всяко последващо движение "влиза" във файла на месеца по GLPostingDate. По-точно е, че то може да бъде включено в текущо подавания файл, но с ясно отбелязан предходен период в самите полета на счетоводната трансакция.
От структурата на файла следва и още един практически извод. Неплатените фактури от предходни периоди не се "преподават" всеки месец само защото остават непогасени. Документният слой отразява самите документи, а пренасянето на откритите разчети към следващия месец се вижда чрез началните и крайните салда в MasterFiles, включително в Customers и Suppliers, когато е приложимо. Самото неплащане не създава нов ред в Payments. Това е извод от начина, по който НАП е структурирала документа, плащането и салдата като различни, но свързани слоеве на информацията.
Накратко, разчетна сметка без плащане не изчезва от SAF-T. Ако няма движение, остава чрез салдата; ако има счетоводно движение, то се подава в GeneralLedgerEntries; ако няма реално плащане към или от контрагент, подсекция Payments не се попълва.

Въпрос 21. Какви видове счетоводни операции следва да се подават в SAF-T – амортизации, заплати, временни разлики?

Отговор 21. В месечния SAF-T, в секция GeneralLedgerEntries, се подават всички счетоводни операции за отчетния период, така както са записани в счетоводната система на предприятието, и то на ниво трансакция. Поради това в обхвата на тази секция попадат амортизации, начисления на възнаграждения, осигуровки, провизии, обезценки, курсови разлики, начисления и разсрочвания и всички други операции, доколкото са осчетоводени през периода.
При заплатите е важно едно уточнение. Официалните разяснения на НАП приемат, че при масови плащания, например заплати, данните се подават съобразно начина, по който са отразени в счетоводната система на предприятието. Това означава, че ако възнагражденията и плащанията са отчетени обобщено, могат да се подадат обобщено; ако са отчетени поотделно, подават се поотделно. Следователно SAF-T не налага сам по себе си отделен разпад по служители, ако такъв не съществува в счетоводното отчитане.
При амортизациите следва да се разграничат двата слоя на SAF-T. Месечните счетоводни амортизации се виждат като обичайни счетоводни операции в GeneralLedgerEntries. Наред с това данните за дълготрайните активи и движенията по тях се подават отделно в годишния SAF-T чрез подсекциите Assets и Asset Transactions. Следователно амортизацията не се "изключва" от месечния файл, а има и отделен годишен слой по активите.
По отношение на временните разлики следва да се направи още едно важно уточнение. Временните разлики не се подават като самостоятелна отделна категория само защото съществуват като данъчна или отчетна концепция. В SAF-T се подава тяхната счетоводна материализация. Това означава, че ако през периода е осчетоводен отложен данък, съответните записи влизат в GeneralLedgerEntries. Ако дадена временна разлика съществува само на ниво изчисление или работна данъчна справка и не е породила счетоводен запис, тя не се подава самостоятелно в месечния SAF-T. Това е извод от общото правило, че файлът отразява счетоводните операции така, както са записани в системата на предприятието.
Накратко, в SAF-T се подават не "видове операции по списък", а всички операции, които са осчетоводени за периода. Амортизациите влизат като счетоводни записи и имат и годишен слой по активите; заплатите се подават според начина, по който са отчетени в системата; временните разлики се виждат само дотолкова, доколкото са довели до счетоводен запис, най-често като отложен данък.

Въпрос 22. Ако сметка от група 60, например 601, се използва като "транзитна" и се приключва автоматично към сметка от група 61 при всяка операция, трябва ли сметките от група 60 да се класифицират като Active/Passive/Bifunctional?

Отговор 22. Да. Ако сметката се подава в MasterFiles/GeneralLedgerAccounts, за нея следва да се попълни MF.GLA.7 AccountType. Допустимите стойности са Active, Passive и Bifunctional. Самото обстоятелство, че сметка от група 60 се използва като "транзитна" и се приключва автоматично към сметка от група 61, не я освобождава от това изискване.
Публичните разяснения на НАП показват и още нещо важно: типът на сметката не се определя механично от това какво е крайното й салдо в даден месец. НАП изрично приема като коректно положение, при което сметка, подадена като Active, има начално дебитно и крайно кредитно салдо, стига началните и крайните салда да съответстват на дебитните и кредитните обороти по същата сметка в GeneralLedgerEntries. Това означава, че автоматичното приключване или временният кредитен остатък не водят сами по себе си до задължителна класификация като Bifunctional.
По аргумент от тази официална логика, когато сметка от група 60 е разходна по своята природа, но се използва като техническа или транзитна сметка и се приключва към сметка от група 61, най-обосновано е тя да се класифицира според своята счетоводна природа, а не според механизма на приключването. В повечето случаи това означава Active. Класификация като Bifunctional би имала основание само ако конкретната сметка по замисъл е активно-пасивна и нормално може да носи и двата вида салда, а не само защото се закрива автоматично при всяка операция. Последното е тълкувателен извод, тъй като в официалните материали няма отделно специално правило само за "транзитни" сметки от групи 60 и 61.

Въпрос 23. За сметки със салдо, но без месечен оборот подават ли се в секция GL?

Отговор 23. Сметки със салдо, но без месечен оборот не се подават в секция GeneralLedgerEntries само поради наличието на салдо. По действащата официална база на НАП секция MasterFiles / GeneralLedgerAccounts съдържа аналитичните счетоводни сметки с начални и крайни дебитни и кредитни салда за периода, а секция GeneralLedgerEntries съдържа счетоводните операции, направени през отчетния период, на ниво трансакция. Това означава, че салдото и движението са два различни слоя на файла.
Поради това, ако по дадена сметка има начално и/или крайно салдо, но през съответния месец няма осчетоводени операции по нея, сметката остава видима чрез MasterFiles / GeneralLedgerAccounts, но за нея не се създават редове в GeneralLedgerEntries. С други думи, в GL се подават само реално осчетоводени движения, а не "нулеви" записи, чиято единствена цел е да покажат липса на оборот.
Когато става въпрос за разчети с клиенти и доставчици, същата логика се вижда и в подсекциите Customers и Suppliers, където също се подават начални и крайни салда по аналитичната сметка. Следователно липсата на месечен оборот не премахва сметката от файла; тя просто не поражда записи в GeneralLedgerEntries за този месец.