II. Фактури, данъчен слой и плащания (SourceDocuments – GL)
Въпрос 24. Ще се търси ли равнение между ДДС дневниците и секция SourceDocuments в SAF-T относно покупки и продажби? Възможно ли е да има документ, който да влезе в SourceDocuments, без да е попаднал в ДДС дневника?
Отговор 24. По отношение на покупки и продажби съпоставката следва да се прави не с цялата секция SourceDocuments, а конкретно с подсекциите SalesInvoices и PurchaseInvoices. По действащите указания на НАП в секция 4. SourceDocuments се подават данни съгласно изискванията на ЗДДС и ППЗДДС, като в SalesInvoices се включват документите, които се отразяват в отчетните регистри за продажби, а в PurchaseInvoices – документите, които се отразяват в отчетните регистри за покупки. Поради това ще се търси съгласуваност между ДДС дневниците и тези две подсекции на SAF-T. Към момента НАП публикува като действаща версия 1.0.1 на Приложение № 3.
Това съгласуване не следва да се разбира като механично равенство само между фактури. В SalesInvoices и PurchaseInvoices могат да се отразяват и други данъчни документи, включително дебитни и кредитни известия, протоколи, отчети за извършени продажби и митнически декларации. Следователно при определени операции водещият документ в SAF-T може да бъде протокол или митническа декларация, а не търговската фактура сама по себе си.
Възможно е да има документ, който да присъства в SourceDocuments, без да е самият документ от ДДС дневника, но това не е общо правило, а изрично допустима хипотеза. Във версия 1.0.1 е предвидено, че когато по ЗДДС водещият документ е протокол или митническа декларация, в PurchaseInvoices може допълнително да се подаде и фактурата, във връзка с която е издаден този документ, като за нея се посочват кодове за неприложимост в TaxInformation. Ето защо правилният извод е, че по отношение на покупки и продажби ще се търси съответствие между ДДС дневниците и SAF-T, но не всяка съпоставка е непременно "фактура срещу фактура", а допустимите отклонения са само тези, които са изрично уредени в указанията.
Въпрос 25. В какъв срок се предвижда отпадане на подаването на ДДС декларации и дневници, предвид факта, че информацията вече се съдържа и в SAF-T и на практика се дублира?
Отговор 25. По действащата нормативна уредба не е предвиден срок, в който подаването на справка-декларацията по ЗДДС и дневниците за покупки и продажби да отпадне поради въвеждането на SAF-T. Към момента SAF-T е уреден като отделно задължение за подаване на стандартизиран счетоводен файл, а НАП поддържа актуалната документация по този режим, включително версия 1.0.1 на Приложение № 3. Успоредно с това НАП изрично посочва, че регистрираните по ЗДДС лица продължават да подават справка-декларация, заедно с дневник за покупки и дневник за продажби за съответния данъчен период.
От тази действаща конструкция следва, че на този етап SAF-T не замества ДДС отчетността, а се прилага паралелно с нея. Самото обстоятелство, че част от информацията се съдържа и в двата режима, не е достатъчно, за да отпадне задължението за подаване на справка-декларацията и дневниците. За такъв резултат би била необходима изрична законодателна промяна. Ето защо по-точният извод е, че към момента няма нормативно определен срок за отпадане на подаването на ДДС декларацията и дневниците вследствие на SAF-T.
Въпрос 26. Имаме стотици хиляди записа за събрани/получени такси по освободени сделки. В дневниците те се отразяват с един запис. Всички счетоводни записи ли трябва да се включат във файла SAF-T?
Отговор 26. По действащата документация на НАП, включително публикуваната версия 1.0.1 на Приложение № 3, секция GeneralLedgerEntries съдържа всички счетоводни операции, направени през отчетния период, така както са записани в счетоводната система на задълженото лице, като данните се представят на ниво трансакция. Поради това, ако таксите по освободени сделки са осчетоводени като множество отделни счетоводни операции, всички тези операции следва да бъдат включени в GeneralLedgerEntries. Ако обаче са осчетоводени обобщено чрез една или няколко сумарни статии, в SAF-T се подава именно тази счетоводна следа. Обстоятелството, че в ДДС дневника те са показани с един запис, не променя обхвата на счетоводния слой на файла.
На ниво SourceDocuments правилото е различно. За SalesInvoices е предвидено, че при отчет за извършени продажби с код 81 се подава обобщена информация за продажбите за периода, а когато в отчета има повече от една данъчна група, разделянето се прави на ниво InvoiceLine по данъчни групи. Следователно нормативната уредба допуска обобщаване в документния слой, когато това е изрично предвидено.
Допълнително, в подсекция Payments е уредено, че за парични потоци, които се отчитат на нетна база по МСС 7 и СС 7, не е необходимо да се подават поотделно всички получени или извършени плащания, а може да се подаде само нетният резултат.
Следователно отговорът е следният: когато въпросът е за счетоводните записи, в GeneralLedgerEntries се подават всички операции така, както са осчетоводени в системата. Обобщаване, сходно на това в ДДС дневниците, е допустимо само в онези части на SAF-T, за които това е изрично предвидено от правилата, например при определени документи в SalesInvoices и при плащания, отчитани на нетна база.
Въпрос 27. Как се подава фактура за транспорт при покупка на стоки, когато транспортът се включва в стойността на стоката, и съответно как се въвежда митническа декларация?
Отговор 27. По действащата документация на НАП в подсекция PurchaseInvoices се подават документите, които се отразяват в отчетните регистри за покупки, включително фактури и митнически декларации. Типът на документа следва номенклатурата на видовете документи, а не свободен текст. Към момента НАП публикува като актуална редакция Приложение № 3, версия 1.0.1, изменена през февруари 2026 г.
Когато транспортът е фактуриран отделно от превозвача или от друг доставчик, този документ се подава като самостоятелна фактура в PurchaseInvoices. Обстоятелството, че по счетоводна политика транспортният разход се включва в себестойността на стоката, не променя документния му характер. В документния слой той остава отделна фактура за услуга, а включването му в стойността на запасите следва да се отрази чрез счетоводните операции в GeneralLedgerEntries. Указанията на НАП предвиждат в MasterFiles/Products да се подават и услуги, които са в счетоводната отчетност през периода, поради което транспортът следва да остане разпознаваем и като услуга в SAF-T.
Опростяването с един ред и ProductCode "0" е предвидено за текущи разходи и директно разходвани покупки. Поради това не следва да се приема като автоматично приложимо при транспорт, който се капитализира в стойността на запасите. По-точният подход е транспортната фактура да се подаде като отделен документ в PurchaseInvoices, а счетоводният ефект върху стойността на стоката да се покаже в GeneralLedgerEntries.
За митническата декларация правилото е специално. Когато е налице ЕАД, в секция SourceDocuments се подават данни за митническата декларация, а не за фактурата по доставката. Когато документът е във връзка с доставка и има контрагент, в секцията се посочват данните за конкретния контрагент. В официален пример на НАП номерът на митническата декларация е отразен в полето InvoiceNo, поради което номерът на ЕАД/MRN следва да се подава като номер на документа в PurchaseInvoices.
Действащата версия 1.0.1 допуска и свързаната фактура по вноса да бъде подадена допълнително в PurchaseInvoices. В този случай за фактурата се посочват кодове за неприложимост за вид и код на данъка, а информацията за закупените артикули се подава при фактурата, не при митническата декларация. Това е важната практически приложима особеност на действащата редакция.
При митническата декларация е допустимо в AccountID на нивото на документа да се посочи разчетната сметка, свързана с разчета с митница, а в AccountID на нивото на реда – разчетната сметка, свързана с начисления ДДС за покупки. Същественото уточнение е, че в SourceDocuments/TaxInformation се подават само кодове от TAX-IMP, относими към начисляването на ДДС и правото на данъчен кредит. Поради това не е точно да се приема, че в този елемент се въвеждат в пълен обхват мита, ДДС при внос и други публични вземания. В документния слой на PurchaseInvoices се подава ДДС логиката на документа, а митата и останалите елементи на себестойността намират отражение преди всичко в счетоводните записи.
Изводът е следният: отделната фактура за транспорт се подава като отделна покупна фактура, а капитализирането й в стойността на стоката се показва чрез счетоводното отразяване. Митническата декларация се подава в PurchaseInvoices като водещ документ по вноса, с номер на документа в InvoiceNo, с данни за контрагента, когато има такъв, и с данъчна информация само в рамките на ДДС логиката. Ако се подаде и свързаната фактура, артикулите се описват при нея, а не при митническата декларация.
Въпрос 28. Ако чуждестранен доставчик ни фактурира след 14-то число услуга, касаеща себестойността на продукт в предходен период, как следва да се включи коректно информацията във файла SAF-T?
Отговор 28. По действащата версия 1.0.1 на Приложение № 3 решаващо за SAF-T не е само обстоятелството, че фактурата е издадена или получена след 14-то число, а как е отчетена операцията и кой е приложимият данъчен документ. НАП изрично предвижда, че когато през текущия период се правят счетоводни записи, които се отнасят за предходен период, в подавания файл за текущия период в секция GeneralLedgerEntries се посочва SystemEntryDate като дата на въвеждане в системата, а GLPostingDate като дата в периода, за който се отнася осчетоводяването. Това е общото правило за периодизацията на такива късно документирани или късно отчетени разходи.
В документния слой подходът е отделен. Ако за услугата не възниква задължение за самоначисляване с протокол, документът се подава в PurchaseInvoices със своята действителна дата и с данните на чуждестранния доставчик. Ако обаче по ЗДДС за получената услуга се изисква съставяне на протокол, в SourceDocuments водещ е протоколът, а не фактурата на доставчика. По действащата версия 1.0.1 е допустимо свързаната фактура да бъде подадена допълнително в PurchaseInvoices, като за нея в TaxInformation се посочват кодове за неприложимост.
Когато услугата засяга себестойността на продукт от предходен период, счетоводният ефект следва да се покаже именно в GeneralLedgerEntries според приложимите счетоводни стандарти и счетоводната политика на предприятието. Ако към края на предходния период е било направено начисление или е използвана временна разчетна сметка за нефактурирана доставка, в предходния файл се вижда счетоводният запис, а след получаването на фактурата в текущия файл се подават документът и съответното счетоводно уреждане на тази временна позиция. Така се запазва връзката между периода, за който разходът се отнася, и момента, в който документът е получен и въведен.
Нов SAF-T файл за предходния месец е необходим тогава, когато предприятието действително коригира вече подадения период и е в допустимия срок за корекции по чл. 71к, ал. 6 ДОПК. Самият факт, че фактурата е издадена или получена след 14-то число и се отнася до предходен период, не означава автоматично, че винаги следва да се преподава старият месец. Когато счетоводният запис е направен през текущия период, но се отнася за предходен, действащите указания допускат той да се отрази в текущия файл чрез съчетанието SystemEntryDate и GLPostingDate; когато вече подаден период се отваря и променя, корекцията се прави с нов файл за съответния период в рамките на допустимия корекционен прозорец.
Следователно правилният подход е двуслоен: в SourceDocuments се подава актуалният данъчен документ със собствената му дата, а в GeneralLedgerEntries се показва счетоводното отнасяне към предходния период чрез GLPostingDate и SystemEntryDate. Ако услугата е в хипотеза на самоначисляване, водещ е протоколът; ако не е, водещ е фактурата.
Въпрос 29. Данните, които следва да подаваме за продажби през онлайн магазин – т.нар. "одиторски файл", припокриват ли се частично със SAF-T файла? "Одиторски файл" ще се подава ли?
Отговор 29. Между файла по Приложение № 38 към Наредба № Н-18 и SAF-T може да има частично припокриване по отношение на продажбите, реализирани през електронния магазин, но двата файла не са взаимозаменяеми. Файлът по Приложение № 38 е уреден за лицата по чл. 3, ал. 17 от Наредба № Н-18, тоест за електронни магазини, които са избрали алтернативния режим и отчитат продажбите чрез документ вместо фискален или системен бон при неприсъствено плащане с кредитна или дебитна карта. За тези лица чл. 52т, ал. 2 изисква за всеки календарен месец да се подава към НАП стандартизиран одиторски файл, съдържащ информация за поръчките в електронния магазин, по които са извършени доставки на стоки или услуги, като информацията се подава до 15-о число на следващия месец. Приложение № 38 описва данните, които се подават в XML формат.
SAF-T е самостоятелен режим по ДОПК и по заповедта на изпълнителния директор на НАП. Към момента НАП поддържа актуалната уредба на SAF-T след заповед от 27.02.2026 г., а месечният файл обхваща данни за цялото задължено лице, включително основни данни, счетоводни записи и изходни документи със SalesInvoices, PurchaseInvoices и Payments. И този файл е XML, но по различна структура и с различно предназначение. Поради това продажбите от онлайн магазина могат да се срещнат и в двата режима, но на различно правно основание и с различен обхват.
Следователно "одиторският файл" по Приложение № 38 продължава да се подава, когато са налице предпоставките за алтернативния режим по Наредба № Н-18. Към момента няма нормативно основание да се приеме, че SAF-T замества това задължение, а НАП поддържа паралелно както услугата за подаване на стандартизиран одиторски файл за електронен магазин, така и системата за SAF-T.
Въпрос 30. Стока е заприходена по складова разписка през октомври, а фактурата пристига през ноември и се включва в ДДС-дневниците за ноември. Как се отразява това в SAF-T?
Отговор 30. По действащата документация на НАП, включително актуалната към момента версия 1.0.1 на Приложение № 3, при такава хипотеза следва да се разграничат приемането на стоката и последващото фактуриране. Секция GeneralLedgerEntries съдържа всички счетоводни операции така, както са записани в счетоводната система, а PurchaseInvoices обхваща документите за покупки, които се отразяват в отчетните регистри за покупки. Поради това е напълно допустимо приемането на стоката и фактурата да се видят в различни месечни SAF-T файлове и в различни слоеве на файла.
Ако през октомври приемането по складова разписка е отразено и счетоводно, в месечния SAF-T за октомври това събитие се показва в GeneralLedgerEntries чрез заприхождаването на стоката и съответния временен разчет по начина, по който предприятието го води в системата. В PurchaseInvoices за октомври не се подава фактура, защото документът още не е наличен. Ако през октомври е налице само складово движение, без счетоводен запис, SAF-T не създава изкуствено ред в GeneralLedgerEntries; движението на запаса е относимо към MovementofGoods, а тази подсекция се подава при поискване от орган по приходите.
През ноември фактурата се подава в PurchaseInvoices със своята фактическа дата и се отразява в документационния слой за ноември, тъй като именно тогава участва и в дневника за покупки. В счетоводния слой за ноември се показва уреждането на временния разчет и признаването на задължението към доставчика, както и ДДС ефектът съобразно начина, по който документът е осчетоводен. Ако фактурната стойност се различава от предварително отчетената стойност при приемането, разликата се отразява съобразно приложимите счетоводни правила и счетоводната политика на предприятието.
Когато октомврийският счетоводен запис е въведен в системата по-късно, но е отнесен към октомври, проследимостта се осигурява чрез SystemEntryDate и GLPostingDate. Указанията на НАП изрично предвиждат, че в GeneralLedgerEntries се подава датата на въвеждане на записа в системата и отделно дата в периода, за който се отнася осчетоводяването, включително когато записът е направен през текущия период, а се отнася за предходен период.
Изводът е, че в SAF-T за октомври се вижда счетоводният ефект от приемането на стоката, а в SAF-T за ноември – самата фактура в PurchaseInvoices и нейното счетоводно уреждане. Така се запазва едновременно съответствието със счетоводната периодизация и с отразяването в ДДС дневниците.
Въпрос 31. Природен газ е получен в текущия месец по складова разписка или протокол, а фактурата идва в следващия. Ползва се временна разчетна сметка, която после се закрива с фактурата. Каква аналитична информация следва да държи този разчет, за да влезе коректно в SAF-T? Подходящо ли е да се използва такава разчетна сметка?
Отговор 31. Използването на временна разчетна сметка за получени, но нефактурирани доставки е подходящо и съвместимо със SAF-T. По действащата документация на НАП, актуализирана през 2026 г., месечният файл се подава по изменената схема, а секция GeneralLedgerEntries съдържа всички счетоводни операции така, както са записани в счетоводната система на лицето. Поради това, когато природният газ е получен през текущия месец, но фактурата пристигне през следващия, в SAF-T за първия месец се вижда счетоводният запис по временната разчетна сметка, а документ в PurchaseInvoices се подава едва в месеца на фактурата. Кодът за подаване на сметката следва да бъде коректно картографиран в AccountID, а вътрешният код на сметката се запазва в TaxpayerAccountID.
За да влезе коректно тази логика в SAF-T, разчетът следва да позволява еднозначна проследимост най-малко по три оси: контрагент, събитие и период. На ниво счетоводен запис това означава последователно да са налични идентификаторът на доставчика SupplierID, стабилна връзка към първичния документ или вътрешното събитие чрез SourceDocumentID, когато системата поддържа такава референция, както и двете дати SystemEntryDate и GLPostingDate, когато приемането и фактурирането попадат в различни месеци. Именно тези елементи правят възможно закриването на временния разчет при получаване на фактурата, без да се губи връзката между първоначалното признаване и последващия документ.
Що се отнася до аналитичността в по-тесен смисъл, SAF-T не предписва специален единствен модел за такава разчетна сметка, но когато предприятието поддържа аналитични измерения, те следва да бъдат кодирани като AnalysisType и AnalysisID, а не да се оставят като свободен текст. Практическият минимум, който прави разчета устойчив за контрол и закриване, е аналитичност по обект или разходен център, когато доставките на газ се разпределят по локации или дейности, и отделна аналитичност по договор, точка на доставка или друг устойчив търговски идентификатор, когато един и същ доставчик обслужва повече от един обект. Това е препоръчителният, а не нормативно единствен възможен модел, но именно той следва от речниковата логика на аналитичностите и от изискването счетоводният ред да бъде машинно съпоставим. Доставчикът не следва да се "размножава" на множество кодове заради различни обекти или договори; доставчикът остава един, а управленските разрези се държат отделно като аналитичности.
Количеството, мерната единица и предметът на доставката принадлежат преди всичко на документния слой. В PurchaseInvoices документът се подава по редове с доставчик, продуктова идентификация или описание, количество, мерна единица и данъчна информация, а при поискване движенията на запасите се подават отделно в MovementofGoods. Поради това временната разчетна сметка не следва да замества документната и количествената следа, а да осигури правилната периодизация и последващото закриване на разчета. Когато предприятието използва приемен протокол, складова разписка или отчет от измервателна точка като основание за първоначалното признаване, поддържането на стабилна вътрешна референция към този документ е най-практичният начин да се осигури връзката между месеца на получаването и месеца на фактурата.
Следователно такава разчетна сметка е подходяща. За целите на SAF-T е важно тя да бъде правилно картографирана към AccountID, да пази вътрешния си код в TaxpayerAccountID, да носи последователен SupplierID и устойчива референция към събитието, а аналитичността по обект, договор или точка на доставка да бъде кодирана отделно и последователно. Това е моделът, който осигурява едновременно правилна периодизация, проследимост и коректно закриване при получаване на фактурата.
Въпрос 32. Трябва ли в SAF-T да се подават фактури за онлайн продажби, за които ДДС се отчита в държава извън България?
Отговор 32. Решаващият критерий не е само в коя държава се дължи ДДС, а дали съответната продажба влиза в българската отчетност по ЗДДС и ППЗДДС. По действащата версия 1.0.1 на Приложение № 3 подсекция SalesInvoices обхваща документите, които се отразяват в отчетните регистри за продажби. Поради това в SAF-T не се подава автоматично всеки оборот с място на изпълнение извън България, а документният отпечатък, който следва българската ДДС отчетност за периода.
Когато онлайн продажбите се отчитат по специалните режими на ЗДДС, действащата уредба изисква да се съставя отчет за извършените продажби по чл. 119, включително когато е издадена фактура или известие към фактура. В този отчет се посочват общите суми на данъчните основи, а правилникът предвижда отразяването им и в дневника за продажбите. Следователно за тези потоци продажбата следва да намери място и в SalesInvoices, но обичайно не като всяка отделна B2C фактура, а като документ по логиката на българската ДДС отчетност, тоест като отчет за извършени продажби. В самия SAF-T за код 81 е предвидено подаване на обобщена информация за периода, а когато са налице повече от една данъчна група, разделянето се прави на ниво InvoiceLine.
От гледна точка на данъчната логика това решение е подкрепено и от номенклатурата TAX-IMP. В нея изрично е предвиден код 100218 за доставки по чл. 69, ал. 2 ЗДДС, включително доставки при условията на дистанционни продажби, с място на изпълнение на територията на друга държава членка. Това показва, че българският SAF-T модел очаква такива продажби да бъдат разпознавани и кодирани в документния слой, когато те участват в българската ЗДДС отчетност. При хипотези извън ЕС или при други чуждестранни регистрации преценката се прави по същия принцип: решаващо е кой е документът, който влиза в българската отчетност, и към кой данъчен код е картографиран.
Ако обаче конкретният поток продажби се отчита изцяло чрез чуждестранна ДДС регистрация и не се отразява в българските отчетни регистри за продажби, тогава по аргумент от действащите указания той не следва да се подава като SalesInvoices в българския SAF-T. В този случай счетоводното отражение на приходите остава видимо в GeneralLedgerEntries, тъй като тази секция съдържа всички счетоводни операции за периода така, както са записани в счетоводната система. Изводът е, че отговорът не е безусловно "да" за всяка онлайн фактура. В SAF-T се подава онзи документен слой на продажбата, който участва в българската ЗДДС отчетност; при OSS и сродни режими това най-често ще бъде отчетът за извършени продажби, а не непременно всяка отделна фактура към крайния клиент.
Въпрос № 33. При самоначисляване на ДДС, например при ВОП или при услуги по чл. 82, ал. 2–6 ЗДДС, подаваме протокол в подсекция SalesInvoices, но получаваме грешка, че в елемент CustomerID от InvoiceStructure – CustomerInfo е подаден некоректен идентификатор или е подаден CustomerID, който не фигурира в MasterFiles – Customers. Как следва да се отработи правилно този случай: чрез добавяне на контрагента в MasterFiles/Customers, чрез промяна към SupplierInfo, или по друг начин?
Отговор № 33. По действащата документация на НАП правилният документ при самоначисляване е протоколът, а не фактурата на доставчика. В подсекция SalesInvoices се подават и протоколи, издадени във връзка със самоначисляване на ДДС, а когато за доставката по ЗДДС се изисква протокол или е налице митническа декларация, в SourceDocuments се подават данни за протокола или декларацията. Към момента НАП поддържа като актуална редакция версия 1.0.1 на Приложение № 3.
Когато документът е съставен във връзка с доставка, по която има контрагент, указанията не свеждат случая само до една роля, а изрично посочват елементите CustomerInfo и SupplierInfo от InvoiceStructure. Поради това грешката не следва да се решава чрез механична смяна на ролята само за да се премине валидацията. Ако във Вашия мапинг протоколът се подава чрез CustomerInfo, съответният CustomerID задължително трябва да има огледален запис в MasterFiles/Customers, тъй като в тази подсекция се подават всички клиенти, за които има данни в останалите секции и подсекции на файла за периода.
Ако същият контрагент участва и като доставчик в други документи, той може паралелно да присъства и в MasterFiles/Suppliers със собствен SupplierID. Следователно практическото правило е следното: протоколът остава документът, който се подава; ролята на контрагента в InvoiceStructure трябва да бъде последователна спрямо избрания мапинг; а използваният идентификатор трябва да е валиден по приетия формат. Ако файлът се генерира с CustomerInfo, създава се съответен запис в MasterFiles/Customers. Ако конкретната имплементация работи със SupplierInfo и преминава приложимите валидатори, следва да се поддържа SupplierID в MasterFiles/Suppliers. Важното е да няма смесване на роля, идентификатор и справочен запис в различните части на файла.
Въпрос 34. Как се отразява плащане "разнос" – няма такъв код в номенклатурата на SAF-T?
Отговор 34. По действащата документация на НАП няма самостоятелен код "разнос" в номенклатурата за плащанията. В секция SourceDocuments/Payments полето PaymentMethod се попълва по номенклатура, а не като свободен текст, като НАП поддържа отделна номенклатура Nom_PaymentMethod за начините и механизмите на плащане. Към момента НАП публикува актуализираните версия 1.0.1 на Приложение № 3 и приложената към нея таблична структура с номенклатурите.
Следователно "разнос" не следва да се подава като самостоятелен PaymentMethod. То обозначава вътрешен канал на събиране или организация на инкасирането, а не нормативно установен начин на плащане по SAF-T. Не е точно да се приеме, че в PaymentMethod се подават отделни стойности от рода на карта, банкова сметка или ваучер като равнопоставени самостоятелни методи; по действащата номенклатура тези по-детайлни разграничения са на равнището на механизма на плащане, когато такъв е приложим в структурата.
Практически това означава следното. Ако при разнос сумата се събира в брой, плащането се отчита като плащане в брой. Ако се приема плащане с карта, плащането се отчита като безкасово плащане, а картата е конкретният механизъм. Ако сумата се събира от куриер или друг посредник и постъпва при предприятието по банкова сметка, за самото предприятие това е безкасово плащане по банкова сметка. Ако е налице прихващане, се прилага кодът за прихващане. С други думи, вътрешният код "разнос" винаги следва да бъде преведен към реалния икономически способ на уреждане.
Ако предприятието желае да запази информацията, че плащането е събрано "на разнос", това може да остане в описанието на плащането или като отделна аналитичност, когато такава се поддържа последователно в системата. Този белег обаче е управленски, а не номенклатурен. Той не замества задължението PaymentMethod и, когато е приложимо, PaymentMechanism да бъдат попълнени с официалните кодове.
Изводът е, че в SAF-T не се създава нов код "разнос". Подават се нормативният код за начина на плащане и при необходимост кодът за механизма на плащане, а "разнос" остава вътрешна характеристика на канала на събиране. За пълна проследимост редът в Payments следва да съдържа и последователна връзка към контрагента, към документа, когато такава е налична, и към правилната счетоводна сметка според икономическия смисъл на погасяването.
Въпрос 35. В практиката към един доставчик плащаме по две сметки. Например сумата за ДДС по една сметка, данъчната основа – по друга сметка. Как това се отразява в SAF-T? И когато съставяме номенклатурите за доставчиците какво следва да направим?
Отговор 35. По действащата към момента документация на НАП, включително публикуваната през 2026 г. версия 1.0.1 на Приложение № 3, при такава хипотеза в SAF-T не се разделя доставчикът и не се разделя фактурата на две доставки. Разделя се единствено уреждането на задължението. В подсекция Payments това следва да се покаже като две отделни плащания, ако в системата действително има два отделни банкови превода, или като едно платежно събитие с два PaymentLine, ако така е организирана платежната операция в системата. И в двата случая редовете следва да сочат един и същ SupplierID и, когато системата поддържа такава връзка, един и същ SourceDocumentID към фактурата, за да остане проследима връзката между документ, разчет и плащане. В модела на НАП референцията в Payments е именно SourceDocumentID, а не свободно въведен номер на фактура.
Когато плащането е по банка, PaymentMethod не се попълва като свободен текст от рода на "банков превод". По официалната номенклатура на НАП за PaymentMethod се използва кодът за безкасово плащане, а ако се попълва PaymentMechanism, за плащане по банков път или банкова сметка се използва отделният код за механизма. Следователно правилният подход е да се подадат нормативните кодове за безкасово плащане и, при необходимост, за банков механизъм, а не текстово описание на начина на превода. На ниво PaymentLine полето AccountID следва да отразява разчетната логика на погасяването, а не просто техническия носител на плащането.
Що се отнася до номенклатурата на доставчиците, следва да се поддържа един и същ доставчик с един устойчив SupplierID. Различните банкови сметки на същото лице не са основание да се създават два различни доставчика в MasterFiles/Suppliers. В българския SAF-T именно SupplierID е идентификаторът, който се повтаря във фактурата, плащането и счетоводния запис, а AccountID в подсекцията за доставчика има смисъл на разчетна счетоводна сметка, а не на банкова сметка на контрагента. Само ако разчетите с един и същ контрагент действително се водят по повече от една счетоводна сметка, официалните разяснения допускат информацията да се подава поотделно за всяка такава сметка. Това е счетоводна, а не банкова причина за повече от една структура.
Следователно при плащане на данъчната основа и ДДС по различни банкови сметки се подават отделни платежни редове или отделни платежни събития към една и съща фактура и към един и същ доставчик. В номенклатурата не се "размножава" доставчикът заради различните му банкови сметки; поддържа се единен SupplierID, а разпадането се показва в платежния слой и в съответните счетоводни записи.
Въпрос 36. Допустимо ли е при издаване на фактура в SAF-T да се посочат условия за плащане "по банка", когато към този момент не е известно дали впоследствие вземането ще бъде погасено изцяло или частично чрез прихващане с насрещно задължение към същия контрагент? Как следва да се отрази последващото частично прихващане?
Отговор 36. Да. По действащата документация на НАП структурата на фактурата различава условията за плащане по фактурата от самото уреждане. В XSD схемата на SAF-T в InvoiceStructure е предвидено отделно поле за условията за плащане на фактурата, а в InvoiceSettlement са предвидени елементите за сума на уреждането, дата на уреждането и механизъм на плащане. Поради това посочването при издаването на фактурата, че плащането е "по банка", не изключва възможността по-късно част от вземането да бъде погасена чрез прихващане. Това първоначално отбелязване описва договорения или очаквания ред на плащане, а не предрешава начина, по който впоследствие ще бъде уредено вземането. Към момента НАП поддържа актуалната редакция 1.0.1 след заповед от 27.02.2026 г.
Когато към датата на фактурата все още не е настъпило прихващане, по-консервативният подход е фактурата да съдържа условията за плащане, а самото прихващане да се отчете едва при настъпването му. В секция Payments методът на плащане се попълва по номенклатура, като в официалните разяснения на НАП за прихващането изрично е посочен методът "02 – Прихващане". Ако системата поддържа разпределение към конкретен документ, връзката се прави на ниво PaymentLine чрез SourceDocumentID, така че да остане видимо коя част от вземането е погасена и към коя фактура се отнася уреждането. Същият икономически ефект следва да се вижда и в GeneralLedgerEntries чрез съответния счетоводен запис за прихващането.
Ако след частичното прихващане остане непогасен остатък и той по-късно бъде платен по банка, тази част се отчита отделно като безкасово плащане по действащата номенклатура, със собствени платежни референции и връзка към документа. Същественото е SAF-T да покаже последователно историята на уреждането, а не да я сведе до нетен резултат. Официалните разяснения на НАП изрично посочват, че за целите на представянето на информация в SAF-T не се допуска компенсиране на вземания и задължения от един контрагент. Това не изключва законосъобразното прихващане, а означава, че то трябва да остане видимо като отделно събитие в данните. Следователно е допустимо фактурата първоначално да бъде издадена с условия за плащане "по банка", но последващото частично прихващане следва да се отчете отделно и проследимо, а не да се "скрива" в общо зануляване.
Въпрос 37. Какво се случва с данъчния амортизационен план и счетоводния амортизационен план в SAF-T? Те подават ли се?
Отговор 37. По действащата уредба не се предвижда да се подава самостоятелен отделен файл "счетоводен амортизационен план" или "данъчен амортизационен план". Данните за дълготрайните активи се подават в годишния SAF-T чрез подсекциите MasterFiles/Assets и SourceDocuments/AssetTransactions, като това подаване е в срока за годишната данъчна декларация по чл. 92 ЗКПО. Актуалната документация на НАП продължава да работи с версия 1.0.1 на Приложение № 3.
По същество това означава, че в SAF-T не се "прикачват" самите вътрешни планове като документи, а се подава тяхното съдържание в структуриран вид. В официалната схема за Assets е предвиден оценъчен блок за данни за счетоводния амортизационен план и за данъчния амортизационен план, когато е приложим, а описанието на подсекцията включва полезен срок, метод на амортизация, размер на амортизацията, преоценки и други характеристики на актива. Следователно и счетоводният, и данъчният амортизационен план стават видими за НАП не като отделни приложения, а като машинночетими елементи в самия годишен файл.
Подсекцията AssetTransactions служи за движенията по активите през периода, а GeneralLedgerEntries продължава да съдържа всички счетоводни операции така, както са записани в счетоводната система. Поради това месечните счетоводни амортизации, доколкото са осчетоводени през периода, се виждат и в счетоводния слой на SAF-T, докато по-пълният "портрет" на актива и на амортизационните му характеристики се подава годишно чрез секцията за активи.
Изводът е, че отговорът е следният: самите амортизационни планове не се подават като отделни документи, но техните съществени данни се подават структурирано в годишния SAF-T. Това важи както за счетоводния амортизационен план, така и за данъчния амортизационен план, когато такъв е приложим за съответния актив.
Въпрос 38. При плащане по разпореждане за превод в полза на НАП какъв код следва да се използва в SAF-T?
Отговор 38. В SAF-T не се използва отделен код "НАП" като начин на плащане. По действащата документация на НАП кодът в PaymentMethod отразява начина на плащане, а не получателя. Поради това, когато преводът е банков, плащането се отчита като безкасово плащане, а ако се попълва и PaymentMechanism, се използва механизмът за плащане по банкова сметка. Данъчната логика не се пренася в PaymentMethod. В официалното приложение е посочено, че TaxInformation на ниво PaymentsLine е опционално, докато кодовете за данъци, осигурителни вноски и такси се подават принципно в GeneralLedgerEntries.
Когато преводът към НАП е за собствени публични задължения на лицето, това не е плащане към клиент или доставчик. По публикуваната структура на файла за такива плащания CustomerID и SupplierID не се попълват с НАП, а с идентификатора на самото лице, което подава файла. В този случай кодът за начина на плащане отново остава кодът за безкасово плащане, ако уреждането е по банка.
Когато преводът е в полза на НАП по разпореждане, но икономически урежда задължение към конкретен доставчик или вземане от конкретен клиент, плащането следва да остане свързано именно с този контрагент. Тогава в PaymentLine се посочва съответно SupplierID или CustomerID на контрагента, а в другото поле се подава стойност 0, като връзката към документа се запазва чрез SourceDocumentID, когато системата я поддържа. Следователно правилният подход не е да се търси "код за НАП", а да се подаде правилният код за начина на плащане и правилната роля на насрещната страна според икономическия смисъл на погасяването.
Въпрос 39. Как се отразява в SAF-T авансово плащане, извършено по проформа, когато данъчната фактура се издава или се получава през следващия месец?
Отговор 39. При този казус решаващо не е наименованието "проформа", а дали за аванса е налице данъчен документ по ЗДДС. НАП изрично посочва, че фактурата е данъчен документ, а по общото правило при авансово плащане фактура се издава не по-късно от 5 дни от датата на получаване на плащането. Успоредно с това действащата документация по SAF-T предвижда в SalesInvoices и PurchaseInvoices да се подават документите, които се отразяват в отчетните регистри по ЗДДС. Оттук следва, че проформата сама по себе си не е документът, който се подава в тези подсекции; в SAF-T значение има фактурата или другият данъчен документ, който реално участва в ДДС отчетността. Към момента НАП поддържа актуалната редакция 1.0.1 на Приложение № 3.
Когато през месеца на плащането е налице само плащане по проформа, без още да е наличен или отразен данъчен документ в SalesInvoices или PurchaseInvoices, в SAF-T за този месец се подава реалното плащане в SourceDocuments/Payments и неговото счетоводно отражение в GeneralLedgerEntries. В официалната логика на файла Payments съдържа само действително извършени и получени плащания, а PaymentRefNo идентифицира самото платежно събитие. Поради това номерът на проформата може да остане само като помощна референция в описанието или във вътрешната проследимост на системата, но не замества данъчния документ в документния слой.
Ако обаче за аванса е издадена фактура още в месеца на плащането, именно тя следва да се отрази в SalesInvoices или PurchaseInvoices за същия период. В такава хипотеза не е точно да се изчака следващият месец, за да се появи първият документен отпечатък в SAF-T, защото ЗДДС свързва авансовото плащане с издаване на фактура по общото правило в кратък срок. Следващият месец тогава ще съдържа окончателната фактура или счетоводното приключване на аванса според приложимата данъчна и счетоводна логика.
Когато фактурата действително е издадена или получена през следващия месец и именно тогава се отразява в дневниците, тя се подава в SalesInvoices или PurchaseInvoices през този следващ месец, а авансовото плащане остава в предходния месец в Payments. Така SAF-T запазва разделението между платежното събитие и документното събитие, а счетоводната връзка между тях се вижда в GeneralLedgerEntries чрез съответните разчетни сметки и последващото приключване на аванса. Правната допустимост фактурата да се издаде едва в следващия месец е отделен въпрос по ЗДДС и не се решава от самото картографиране в SAF-T.
Въпрос 40. При плащане "ред по ред" по фактури необходимо ли е да има отделна информация за плащане по всяка фактура и това означава ли отделни счетоводни редове Дт 401 / Кт 503 за всяка фактура?
Отговор 40. По действащата документация на НАП подсекция Payments е структурирана на две равнища – Payment и PaymentLine. Именно на ниво PaymentLine се държат контрагентът и, когато системата поддържа такава връзка, SourceDocumentID към документа, който се погасява. Оттук следва, че когато едно плащане се разпределя по конкретни фактури, методологически коректното представяне в SAF-T е алокацията да се вижда по фактури на ниво платежен ред. Това не налага непременно отделен запис Payment за всяка фактура; възможно е да има едно платежно събитие с няколко PaymentLine, всеки от които сочи към отделна фактура или към отделна погасена част от нея. НАП поддържа като актуална редакция версия 1.0.1 на Приложение № 3.
Това обаче не означава автоматично, че в GeneralLedgerEntries трябва да има отделни счетоводни редове Дт 401 / Кт 503 за всяка фактура. По официалното описание на секция GeneralLedgerEntries в SAF-T се подават всички счетоводни операции за периода така, както са записани в счетоводната система на данъкоплатеца, и данните се представят на ниво транзакция. Следователно, ако един банков превод е осчетоводен като една агрегирана операция, в SAF-T се подава именно тази операция. Ако счетоводната система осчетоводява плащането поотделно по фактури, тогава се подават отделните редове. Стандартът не изисква изкуствено да се създават допълнителни счетоводни записвания само заради формата на файла.
Следователно правилният извод е следният: на документно ниво плащането следва да бъде четимо по фактури, когато такава алокация е налична в системата, а на счетоводно ниво се подава реално осчетоводеното. Най-добрият практически устойчив модел е един банков превод да остане едно платежно събитие, но с отделни PaymentLine към съответните фактури, докато GeneralLedgerEntries следва действителната счетоводна статия, независимо дали е агрегирана или разпределена. Ако системата не поддържа пряка връзка към фактура на ниво плащане, SAF-T не създава такава връзка вместо нея, но тогава нараства рискът от двусмислие при частични плащания и при едно плащане към повече от една фактура.
Въпрос 41. Пенсионноосигурителна компания извършва като основна дейност управление на пенсионни фондове. Как се подава в одитния файл информацията за изплатените възнаграждения на осигурителни посредници, на които се изплащат всеки месец възнаграждения за продадени пенсионни продукти по сключени граждански договори? Информацията се подава агрегирано или човек по човек, месечно или годишно? В коя част на MasterFiles се включва информацията? Как се подава в одитния файл информация за сключените сделки за покупко-продажба на ценни книжа за собствен портфейл – сделка по сделка или на агрегирано ниво, месечно или годишно? В коя част на MasterFiles се включва информацията?
Отговор 41. По действащата документация на НАП, актуализирана с версия 1.0.1 на Приложение № 3, месечният SAF-T обхваща MasterFiles, GeneralLedgerEntries и SourceDocuments, а годишният файл е предназначен за наличности и движение на дълготрайни активи чрез Assets и AssetTransactions. Поради това възнагражденията на посредници и сделките с ценни книжа за собствен портфейл не се третират като самостоятелен годишен поток; отправната точка за тях е месечният SAF-T, доколкото са част от счетоводните операции и от подлежащия на подаване документен слой за съответния период.
По отношение на възнагражденията на осигурителни посредници първоначалният отговор следва да се прецизира. Ако за възнаграждението е налице индивидуализиран документ или плащане, което влиза в подлежащите на подаване секции, подаването е месечно и по конкретен контрагент, а лицето се включва в MasterFiles/Suppliers, тъй като в тази подсекция се подават доставчиците, за които има данни в останалите секции на файла за съответния месец. Ако обаче за съответното възнаграждение съгласно ЗДДС няма законово изискване за издаване на фактура или протокол, Приложение № 3 изрично допуска данните да се подават на обобщено или агрегирано ниво, като за тези сделки и свързаните с тях плащания не се посочват индивидуализирани транзакционни данни, данни за клиенти или доставчици, изходни документи и плащания в съответните секции. В този случай счетоводният ефект остава видим в GeneralLedgerEntries така, както е осчетоводен, но не е задължително документният и контрагентният слой да е човек по човек.
Не следва по аналогия да се прилага специалният режим, предвиден за застрахователни и презастрахователни дружества и застрахователни брокери и агенти. В Приложение № 3 именно за тези лица е уредено агрегирано подаване, когато информацията попада в обхвата на застрахователната тайна, включително за възнаграждения на застрахователни посредници. Този специален текст е секторно и изрично формулиран и не създава общо правило за всички финансови предприятия.
По отношение на сделките за покупко-продажба на ценни книжа за собствен портфейл водещо е същото разграничение между счетоводен и документен слой. Счетоводните записи се подават месечно в GeneralLedgerEntries така, както са записани в счетоводната система. В Приложение № 3 има изрично уреден специален режим за сделки с финансови инструменти само за банки по смисъла на Закона за кредитните институции, когато информацията попада в обхвата на банковата тайна; за тези сделки е допустимо агрегирано подаване по видове финансови инструменти, без транзакционни данни, без клиенти или доставчици и без изходни документи в съответните секции. Същевременно НАП изрично посочва, че данните за издадените и получените фактури, включително свързаните със сделки с финансови инструменти, се подават съобразно правилата за попълване на файла. Следователно при пенсионноосигурителна компания не може автоматично да се приеме, че всички сделки с ценни книжа се подават агрегирано само защото са финансови инструменти. Ако за конкретния поток има изискуем документен слой, той се подава по общите правила; ако за самата сделка няма законово изискване за фактура или протокол, приложимо е общото правило за допустимо агрегирано подаване в съответните секции.
Що се отнася до MasterFiles, в действащата структура няма самостоятелна подсекция за "осигурителни посредници" или за "сделки с ценни книжа". В MasterFiles се включват справочните данни, които обслужват останалите секции на файла. Затова, когато посредник или насрещна страна по сделка се подава индивидуализирано в документния или платежния слой, той се включва в Suppliers или Customers според ролята си. Самите сделки с ценни книжа не се "вписват" като отделен масив в MasterFiles; задължителният им справочен отпечатък е преди всичко в GeneralLedgerAccounts, а контрагентни данни се включват само когато за тях има индивидуализирани данни в останалите секции.
Синтезирано, правилният отговор е следният: за възнагражденията на посредниците и за сделките с ценни книжа изходната логика е месечно подаване, а не годишно. Подаване човек по човек е необходимо тогава, когато самият поток се подава индивидуализирано в документния или платежния слой. Агрегиране е допустимо само при изрично уредените в Приложение № 3 случаи, най-вече когато не е налице законово изискване за фактура или протокол, както и в специално предвидения банков режим за определени сделки с финансови инструменти.
Въпрос 42. Ако доставчик ни фактурира материални запаси от един и същи вид, но с различна цена и количество, длъжни ли сме да подаваме информация за тази фактура по редове, когато редовете са над 200? Става дума за доставка на природен газ.
Отговор 42. По действащата версия 1.0.1 на Приложение № 3 въпросът не се решава само от броя на редовете във фактурата и не може да се отговори еднозначно с "винаги да" или "винаги не". Решаващо е дали в конкретния случай природният газ се третира като директно разходвана покупка или текущ разход за периода, или се води като материален запас под складов контрол. Към момента НАП поддържа именно версия 1.0.1 на документацията по SAF-T.
Когато покупката попада в хипотезата на директно разходвани артикули, неподлежащи на контролирано съхранение, или на текущи разходи за периода, указанията изрично допускат в PurchaseInvoices документът да бъде подаден на един ред, като в ProductCode се посочва стойност "0", а в Description се дава описание на отчетения разход. В самия текст на указанията като примери са посочени електрическа енергия, отопление, вода и други разходи за стопански нужди. По аргумент от тази формулировка, ако във Вашия модел природният газ се отчита като текущ енергиен разход или като директно разходван артикул без складов контрол, не е задължително фактурата да се възпроизвежда с всичките над 200 реда.
Различен е изводът, когато природният газ се води като материален запас под складов контрол. Официалното описание на подсекция Products изисква при месечно подаване да се включват всички стоково-материални запаси и услуги, които са в счетоводната отчетност през периода, а за директно разходваните покупки е предвидено отделно, изрично облекчение. Оттук следва, че ако газът е запас, а не текущ разход, не следва автоматично да се прилага режимът с ProductCode = "0". В тази хипотеза фактурата следва да се подаде по нормалната редова логика на PurchaseInvoices, с продуктова идентификация и с толкова редове, колкото са необходими, за да се запази вярно количественото, ценовото и данъчното съдържание на документа. На практика при различни количества и различни цени това обичайно означава подаване по редове.
Следователно правилният отговор е условен. Ако природният газ е текущ разход или директно разходван артикул без контролирано съхранение, може да се приложи облекчението за един ред с ProductCode "0". Ако обаче се води като запас под складов контрол, следва да се работи по редовата логика на PurchaseInvoices, а обстоятелството, че редовете са над 200, само по себе си не създава отделно нормативно изключение.
Въпрос 43. Как се отразява в SAF-T операция, за която първоначално е осчетоводен разход или плащане по друг първичен документ, а фактурата се получава по-късно и се въвежда в системата без нова счетоводна операция?
Отговор 43. По действащата документация на НАП секция GeneralLedgerEntries съдържа всички счетоводни операции така, както са записани в счетоводната система, а PurchaseInvoices обхваща документите, които се отразяват в отчетните регистри за покупки. Поради това при такава хипотеза първо се подава реално осчетоводеното събитие, а не се изчаква фактурата. Ако е отчетен разход, той се подава в GeneralLedgerEntries; ако е извършено и плащане, то се подава и в Payments за съответния период. Към момента НАП поддържа версия 1.0.1 на Приложение № 3.
В този първи етап счетоводният ред не следва да остава без документна опора само защото няма фактура. В официалните разяснения на НАП е прието, че в SourceDocumentID може да се посочва не само номер на фактура, но и номер на протокол, платежно нареждане, касов ордер или друг първичен счетоводен документ. Следователно, когато разходът към ЧСИ е осчетоводен въз основа на платежен документ, разпореждане, протокол или друг първичен документ, именно той следва да бъде референцията в счетоводния слой.
Когато по-късно се получи фактура, тя се включва в PurchaseInvoices за периода, в който документът следва да бъде отразен по правилата на тази подсекция. Самото й въвеждане не налага изкуствено създаване на нова счетоводна операция само заради SAF-T. Ако ERP системата не генерира нов счетоводен запис, файлът не следва да създава такъв вместо нея. Ако обаче с получаването на фактурата възниква допълнително счетоводно отражение, например признаване на входен ДДС, прехвърляне от аванс или разчет към задължение, или корекция на стойност, тогава и този запис се подава в GeneralLedgerEntries. Ако по конкретния разход изобщо не възниква документ от вида, който се подава в PurchaseInvoices, събитието остава само в счетоводния и при необходимост в платежния слой.
Проследимостта тук не се постига чрез дублиране на операцията, а чрез последователни ключове между слоевете: SupplierID, AccountID, устойчив първичен документ в SourceDocumentID и, когато системата го поддържа, вътрешен идентификатор на самата фактура. Ако счетоводният запис е въведен по-късно, но се отнася за по-ранен период, периодизацията се показва чрез SystemEntryDate и GLPostingDate. Следователно правилният подход е: първо се подава реално възникналата счетоводна и евентуално платежна операция, а фактурата се добавя по-късно в PurchaseInvoices, без повторно осчетоводяване, освен ако самото получаване на документа не поражда нов счетоводен ефект.
Въпрос 44. В счетоводната програма, която използваме, процесът на осчетоводяване на издадените от нас фактури не включва статия за изписване на стоката. Тя се осчетоводява с отделна операция след остойностяване на запасите. Допустимо ли е това отразяване в SAF-T?
Отговор 44. Да, това е допустимо, ако файлът отразява вярно реалната логика на счетоводната система и не оставя пропуснати операции. По действащата документация на НАП подсекция SalesInvoices съдържа документите, които се отразяват в отчетните регистри за продажби, а секция GeneralLedgerEntries съдържа всички счетоводни операции за периода така, както са записани в счетоводната система. Това означава, че SAF-T не изисква фактурата за продажба и изписването на стоката задължително да възникнат като една обща счетоводна статия. Напълно възможно е фактурата да се подаде в SalesInvoices, а изписването на запасите и разходът за продадената стока да се покажат като отделна счетоводна операция в GeneralLedgerEntries, когато именно така работи системата.
Тук е важно да се разграничат документният и счетоводният слой. В документния слой се подава самата продажбена фактура с нейните редове. В счетоводния слой се подава отражението й по сметки, а ако изписването на стоката се извършва след остойностяване, то може да се появи като отделна операция, без това само по себе си да прави файла некоректен. Същевременно MovementofGoods е отделна подсекция и по действащите правила се докладва при поискване от органите по приходите, поради което детайлното движение на стоката не е задължително да присъства в месечния файл, освен ако не е изискано.
За да бъде подходът устойчив при проверка, е необходимо да има ясна проследимост между фактурата, документа за експедиция или изписване и последващата счетоводна операция за себестойността. Официалните разяснения на НАП изискват SourceDocumentID в GeneralLedgerEntries да сочи към първичния документ, от който произтича счетоводният запис. Поради това, когато изписването на стоката се осчетоводява отделно, следва да се поддържа устойчива връзка към съответния вътрешен документ за изписване, експедиция или остойностяване, а не просто да се разчита на неформално съвпадение по суми.
Следователно правилният извод е, че такава организация може да бъде отразена коректно в SAF-T. Условието е продажбената фактура да бъде подадена в SalesInvoices, приходното й отражение да присъства в GeneralLedgerEntries, а изписването на запасите да се подаде като отделна счетоводна операция, когато именно така е осчетоводено. SAF-T не налага изкуствено обединяване на тези събития в една статия, но изисква пълнота, последователност и проследимост между документите и счетоводните записи.
Въпрос 45. Как би следвало да се подаде фактура, в която има редове, съдържащи стоки/активи, и такива, които съдържат услуги?
Отговор 45. Такава фактура се подава като един документ в PurchaseInvoices или SalesInvoices според характера на сделката, като смесеното съдържание не е пречка в рамките на един и същ документ да има отделни InvoiceLine редове за различни предмети на доставката. По действащата документация на НАП за SAF-T се работи по Приложение № 3, версия 1.0.1, а документният слой е структуриран именно на ниво документ и редове.
Същественото уточнение е, че услугите не следва автоматично да се подават с ProductCode = "0". В действащото Приложение № 3 подсекция Products обхваща не само стоково-материални запаси, но и услуги, като при месечно подаване в нея се включват всички стоки и услуги, които са в счетоводната отчетност през периода. Следователно, когато за услугата се поддържа отделна позиция в системата, редът може и следва да се подаде с обичайния ProductCode, съгласуван с MasterFiles/Products и с използваната мерна единица от UOMTable.
Код "0" е специално, а не общо правило. За PurchaseInvoices той е изрично допуснат при директно разходвани артикули, неподлежащи на контролирано съхранение, както и при текущи разходи за периода, като тогава документът може да се подаде с ProductCode "0" и описание на отчетения разход. Това означава, че услуга може да бъде подадена по този опростен ред само ако попада именно в тази специална хипотеза. Ако услугата е част от покупка, която се капитализира в стойността на запас или актив, не е правилно автоматично да се прилага режимът за текущ разход.
При продажбите правилото е още по-ясно. В SalesInvoices код "0" е изрично уреден за отчет за извършени продажби с код 81, а не като универсален режим за всяка услуга във фактура. Поради това при обикновена продажбена фактура със стоки и услуги услугата не следва механично да се маркира с ProductCode "0" само защото е услуга.
Редовете за активи се подават в документа по същата редова логика като останалите позиции. Ако съответният ред води до признаване на дълготраен актив, това има и допълнително отражение извън самата фактура: активът и движенията по него се подават годишно чрез Assets и AssetTransactions. Следователно в една и съща покупна фактура могат едновременно да присъстват ред за актив и ред за услуга, без това да налага разделяне на документа.
Следователно правилният извод е следният: фактура със смесено съдържание се подава като един документ, но по отделни редове според предмета на доставката и данъчната логика на всеки ред. Стоките и активите се подават с обичайните им редови данни. Услугите не се подават автоматично с ProductCode "0"; този код е допустим само в изрично предвидените случаи, най-вече при PurchaseInvoices за директно разходвани покупки и текущи разходи, а при SalesInvoices основно при отчет с код 81. Ако услугата се поддържа като отделна позиция в системата, тя следва да бъде подадена със собствен ProductCode.
Въпрос 46. Какво се случва при нефактурирани доставки? Например: доставено зърно на 30.10.2025 г., а фактурата е получена на 16.11.2025 г. Как се отразява това в SAF-T?
Отговор 46. По действащата документация на НАП следва да се разграничат моментът на доставката и моментът на фактурирането. В PurchaseInvoices се подават документите, които се отразяват в отчетните регистри за покупки, а в GeneralLedgerEntries се подават всички счетоводни операции за периода с техните счетоводни дати. Подсекцията MovementofGoods е отделна и се подава при поискване от орган по приходите.
Ако доставката на зърното е призната счетоводно още през октомври, в SAF-T за октомври следва да се види именно това счетоводно събитие в GeneralLedgerEntries. Практически това обичайно означава заприхождаване на запаса и насрещен временен разчет за нефактурирана доставка. За октомври не се подава PurchaseInvoice, тъй като към този момент фактура още няма. Ако през октомври е налице само складово събитие, но без счетоводен запис, то не се "създава" изкуствено в GeneralLedgerEntries; при такава организация детайлът за движението на запаса би бил относим към MovementofGoods при поискване.
Когато фактурата бъде получена през ноември, тя се подава в PurchaseInvoices за периода, в който се отразява в отчетните регистри за покупки, като самият документ запазва собствената си дата като реквизит. Ако с получаването на фактурата възникне и допълнителен счетоводен ефект, например признаване на ДДС за покупки, закриване на временния разчет или отразяване на ценова разлика, този ефект се подава и в GeneralLedgerEntries за ноември. Не следва да се дублира вече признатото заприхождаване от октомври, освен ако самата фактура не налага корекция на стойността.
Когато октомврийското осчетоводяване е въведено в системата едва през ноември, проследимостта се осигурява чрез SystemEntryDate и GLPostingDate. Ако вече подаденият октомврийски файл се коригира в допустимия срок по чл. 71к, ал. 6 ДОПК, подава се нов файл за октомври. Ако такъв корекционен прозорец не е приложим, късно въведеният запис остава в текущия файл, като двете дати показват едновременно кога е въведен и за кой период се отнася.
Следователно при нефактурирана доставка на зърно за октомври в SAF-T първо се вижда счетоводното признаване на доставката, а през ноември се вижда самата фактура в PurchaseInvoices и нейното счетоводно уреждане. Така се запазва едновременно правилната периодизация и съответствието с данните по ЗДДС.
Въпрос № 47. Ако се наложи да се направи счетоводна операция за период, за който вече е подаден SAF-T, следва ли да се подаде коригиращ SAF-T файл за миналия месец или операцията да се отрази в текущия файл със счетоводна дата от миналия месец?
Отговор № 47. По действащата документация на НАП е необходимо да се разграничат две различни хипотези: корекция на вече подаден SAF-T файл за минал период и счетоводен запис, направен през текущия период, който се отнася до предходен период. В актуалната версия 1.0.1 НАП изрично посочва, че открити счетоводни грешки през текущия или в следващ отчетен период се коригират през периода, когато грешката е установена. В тези случаи в подавания файл за текущия период в GeneralLedgerEntries се попълват SystemEntryDate като дата на въвеждане на записа в системата и GLPostingDate като дата в периода, за който се отнася осчетоводяването. По същия ред се отразяват и счетоводни записи, направени през текущия период, които се отнасят за предходен период. Това означава, че сам по себе си фактът, че операцията се отнася до стар месец, не води автоматично до задължение за подаване на нов файл за този стар месец.
Коригиращ файл за миналия месец се подава тогава, когато се коригира самият вече подаден SAF-T за този период. И в Приложение № 3, и във версия 1.0.1 на същото е посочено, че корекцията на подаден файл се извършва чрез подаване на нов файл за съответния период, като не се подава само разлика, а нова цялостна версия на периода. Следователно, ако предприятието променя назад вече подадената картина за април, май или друг минал месец, правилният процесен подход е нов SAF-T именно за този месец, доколкото е налице право на корекция в приложимия срок.
Срокът за такава корекция също следва да се чете внимателно. По общото правило на чл. 71к, ал. 6 ДОПК, възпроизведено в Приложение № 3, след изтичането на срока по ал. 5 могат да се правят корекции за следващите шест месеца чрез подаване на нов файл за съответния период. За лицата по поетапното въвеждане по § 17 от преходните и заключителните разпоредби към Закона за държавния бюджет за 2025 г. НАП изрично посочва, че чл. 71к, ал. 5 не се прилага, а срокът по ал. 6 за тези лица е дванадесет месеца, считано от датата на възникване на задължението. Поради това не е достатъчно да се каже абстрактно "има шестмесечен гратис и после шестмесечни корекции", без да се отчете специалният преходен режим за първите групи задължени лица.
Практическият извод е следният. Ако през текущия период се прави счетоводен запис, който по същество се отнася до предходен период, той може да бъде отразен в текущия SAF-T чрез SystemEntryDate и GLPostingDate, когато именно така е отчетен и коригиран в счетоводството. Ако обаче се коригира вече подаденият SAF-T за самия минал месец, следва да се подаде нов файл за този месец в рамките на допустимия корекционен срок. Следователно отговорът не е еднозначно "винаги коригиращ файл" или "винаги текущ файл", а зависи от това дали се коригира текущото счетоводно отчитане с отнасяне назад, или се заменя вече подадената версия на миналия период.
Въпрос 48. Ако получаваме фактура с 300 реда, например за 300 различни светодиода, които директно се влагат в производството, без заприхождаване, 300 реда ли трябва да осчетоводим? Как се отчитат обемните фактури в SAF-T?
Отговор 48. При този въпрос е важно да се разграничат документният и счетоводният слой на SAF-T. По действащата версия 1.0.1 на Приложение № 3 подсекция PurchaseInvoices описва документа, а GeneralLedgerEntries съдържа счетоводните операции така, както са записани в счетоводната система. Затова отговорът не зависи от самия брой редове във фактурата, а от начина, по който тези материали се третират в отчетността на предприятието.
Ако светодиодите са отчетени директно като разход в момента на покупката и за тях не се води контролирано съхранение и допълнителна отчетност, указанията изрично допускат покупната фактура да бъде подадена на един ред в PurchaseInvoices, като в ProductCode се посочва стойност "0", а в Description се дава описание на отчетения разход. В този режим не е необходимо фактурата с 300 позиции да се възпроизвежда непременно с всички 300 реда в документния слой. Самото обстоятелство, че материалите се влагат директно в производството, обаче не е достатъчно само по себе си; решаващо е дали са отчетени директно като разход и дали не са обект на складов контрол.
Ако обаче тези светодиоди се третират като материали или запаси, за които се поддържа продуктова идентификация и контрол, тогава не следва да се прилага облекчението с ProductCode = "0". В тази хипотеза месечният SAF-T предполага продуктова логика чрез MasterFiles/Products, а документът в PurchaseInvoices следва да запази редовата структура, необходима за разграничаване на отделните артикули. При 300 различни позиции това на практика означава подаване по редове, не защото броят е голям, а защото така е организирана отчетността на самите материали.
На счетоводно ниво SAF-T не изисква да се създават 300 отделни счетоводни реда, ако системата не работи така. В GeneralLedgerEntries се подават всички счетоводни операции за периода така, както са записани. Следователно, ако ERP или счетоводният софтуер е осчетоводил фактурата сумарно, например с един или няколко счетоводни реда за разход, ДДС и задължение към доставчика, в SAF-T се подава именно тази счетоводна картина. Само ако системата действително генерира отделни счетоводни редове по позиции, тогава и те се подават поотделно.
Следователно правилният извод е следният: 300 реда не означават автоматично 300 счетоводни реда. В GeneralLedgerEntries се подава реално осчетоводеното. В PurchaseInvoices един обобщен ред е допустим само когато покупката е отчетена директно като разход и не подлежи на контролирано съхранение. Ако материалите се третират като запаси или се поддържат като отделни артикули, фактурата следва да се подаде по редовата логика на документа.
Въпрос 49. При фактура с приблизително 20 позиции за метали, прием по складова разписка и осчетоводяване по модела Дт 301 / Кт 401 по фактура и Дт 302 / Кт 301 по складова разписка, ще има ли проблем при подаване на SAF-T?
Отговор 49. По принцип такъв модел е съвместим със SAF-T и сам по себе си не създава проблем. По действащата документация на НАП, актуализирана във версия 1.0.1, секция GeneralLedgerEntries съдържа всички счетоводни операции така, както са записани в счетоводната система, а PurchaseInvoices съдържа документите за покупки, които се отразяват в отчетните регистри за покупки. Това означава, че SAF-T допуска документният и счетоводният слой да следват различна вътрешна логика, стига да описват една и съща стопанска реалност по проследим начин.
В описания случай фактурата следва да се подаде в PurchaseInvoices като документ по редове, ако металите се третират като материални запаси под складов контрол. Тогава редовете на фактурата се подават с продуктова идентификация, мерна единица и данъчна информация, съгласувани с MasterFiles/Products, UOMTable и данъчната таблица. Облекчението с ProductCode = "0" е предвидено за директно разходвани покупки, които не подлежат на контролирано съхранение, и не е подходящо за материали под складов контрол. Следователно, ако 20-те позиции за метали се водят като запаси, редовото им подаване в PurchaseInvoices е правилният подход.
На счетоводно ниво не е необходимо да има 20 отделни счетоводни реда само защото фактурата има 20 позиции. InvoiceLine не е равен на TransactionLine. Ако системата осчетоводява фактурата агрегирано с Дт 301 / Кт 401, а след това със складова разписка или друг вътрешен първичен документ прави отделна операция Дт 302 / Кт 301, и двете операции могат да бъдат подадени именно така в GeneralLedgerEntries. SAF-T не изисква тези операции да бъдат изкуствено слети, нито да се разпадат по счетоводни редове едно към едно с редовете на фактурата.
Складовата разписка сама по себе си не е документът, който се подава в PurchaseInvoices, защото тази подсекция е за документите по покупката в документния слой. Нейното значение е в проследимостта на вътрешното движение и в счетоводния запис, а при поискване от орган по приходите детайлът за движението на запасите може да бъде показан и в MovementofGoods. Затова правилният модел е: фактурата стои в PurchaseInvoices, двете счетоводни операции стоят в GeneralLedgerEntries, а складовата разписка служи като вътрешна референция и, при необходимост, като част от стоковия слой.
Практически решаващо е да има устойчива връзка между трите елемента: доставчик, фактура и вътрешен документ за приемането. Най-стабилният модел е да се използват последователно SupplierID, вътрешен системен идентификатор на фактурата, когато системата поддържа такъв, и ясна референция към складовата разписка във вътрешния документен поток. Проблем възниква не от самата комбинация Дт 301 / Кт 401 и Дт 302 / Кт 301, а ако липсва проследимост между документния ред, счетоводния запис и складовото събитие, или ако мерните единици, продуктовите кодове и сумите по редове не могат да се съгласуват с тоталите по фактурата и със задължението към доставчика.
Въпрос 50. Как се отразява в SAF-T ситуация, при която стоката се експедира в последния работен ден на един месец, а се фактурира в началото на следващия, например експедиция на 30.09.2025 г. и фактура на 01.10.2025 г.?
Отговор 50. При тази хипотеза следва да се разграничат данъчният документен слой и счетоводният слой. За обикновена вътрешна доставка данъчното събитие възниква на датата, на която собствеността върху стоката е прехвърлена, а фактурата се издава не по-късно от 5 дни от тази дата. По ЗДДС данъкът е дължим за данъчния период, през който е издаден данъчният документ, а издадените данъчни документи се отразяват в дневника за продажбите за периода, през който са издадени. Поради това при експедиция на 30.09.2025 г. и фактура на 01.10.2025 г., ако фактурата е издадена в законовия срок и не става дума за специална хипотеза като вътреобщностна доставка, фактурата попада в октомврийския документен слой и в ДДС логиката на октомври. Само ако документът не е издаден или не е издаден в срока по закона, данъкът се дължи за периода, през който е станал изискуем, тоест в примера – за септември.
В SAF-T това означава, че SalesInvoices следва документа и периода на отразяването му в отчетните регистри, докато GeneralLedgerEntries следва счетоводното отразяване така, както е записано в системата. Ако според договора, експедиционния документ и счетоводната политика продажбата и себестойността са признати на 30.09.2025 г., тези счетоводни записи се виждат в септемврийския SAF-T, а в октомврийския файл се вижда самата фактура в SalesInvoices и, ако е приложимо, само последваща прекласификация на разчета, без второ признаване на приход и данък. Ако предприятието е осчетоводило продажбата едва при издаване на фактурата, SAF-T следва именно тази счетоводна следа.
Необходимо е да се има предвид и едно изключение. При вътреобщностна доставка законът предвижда специално правило: издадените данъчни документи във връзка с такава доставка се отразяват в дневника за продажбите за данъчния период, през който данъкът за доставката е станал изискуем по чл. 51. Следователно изложеното по-горе се отнася до общата хипотеза на вътрешна доставка, а при ВОД периодизацията следва специалния режим.
Въпрос 51. При префактуриране, например по модела 498/401 и 411/498, необходимо ли е в PurchaseInvoices да се подават количествени и продуктови показатели като код, количество, мярка, описание и единична цена?
Отговор 51. По общо правило да. В PurchaseInvoices се подава входящият документ в неговия документен слой, а счетоводната техника, по която впоследствие разходът се прехвърля или префактурира, не променя изискванията към самата покупна фактура. Структурата на InvoiceLine работи на ниво ред и в нея се очаква продуктова или описателна информация, количество, мерна единица, единична цена, сума по ред и данъчна информация. Поради това, когато входящата фактура е детайлизирана по позиции, в PurchaseInvoices по принцип следва да се подадат именно тези редови показатели. Към момента НАП поддържа като актуална версия 1.0.1 на Приложение № 3.
Има обаче изрично предвидено облекчение. За директно разходвани покупки, неподлежащи на контролирано съхранение, както и за текущи разходи за периода, е допустимо в PurchaseInvoices да не се посочва продуктов код от системата на лицето. В тези случаи документът може да бъде подаден на един ред, като в ProductCode се посочва стойност "0", а в Description се дава описание на отчетения разход. Публичните разяснения допускат и повече от един ред с ProductCode = "0", ако това е по-подходящо и се прилага последователно.
Следователно при префактуриране решаващият критерий не е използването на сметка 498, а характерът на входящата фактура. Ако тя е за стоки, материали или други позиции под продуктова идентификация и складов контрол, редовете следва да съдържат реалните кодове, количества, мерни единици, описания и цени. Ако обаче фактурата е за текущ разход или за директно разходвана покупка, допустим е опростеният режим с ProductCode "0" и описателен текст. С други думи, документният слой в PurchaseInvoices не отпада при префактуриране, а само може да бъде опростен в изрично предвидените от правилата случаи.
Въпрос 52. Съгласно НРД и договор между болницата и РЗОК ежемесечно се издават фактури за извършена дейност, включително клинични пътеки, процедури, лекарства, медицински изделия и други. В счетоводната система те се осчетоводяват на един ред с обща стойност. Следва ли фактурите да се въвеждат аналитично за всяка отделна номенклатура?
Отговор 52. Не е необходимо счетоводното осчетоводяване да се превръща в аналитично по всяка медицинска номенклатура само поради SAF-T. По действащата документация на НАП секция GeneralLedgerEntries съдържа всички счетоводни операции така, както са записани в счетоводната система, а SalesInvoices съдържа документите за продажби с техните фактурирани линии. Това означава, че ако във Вашето счетоводство приходът към РЗОК е осчетоводен на един ред с обща стойност, този модел може да остане в счетоводния слой на SAF-T. Към момента НАП поддържа актуализираната уредба по заповед от 27.02.2026 г. и версия 1.0.1 на Приложение № 3.
Решаващо е не как е осчетоводена фактурата, а как е издаден самият документ. Ако фактурата към РЗОК е издадена като един обобщен ред, например за дейност за съответния месец по договор, и в дневника за продажбите се отразява именно този документ, няма основание тя да се "разбива" изкуствено в SAF-T по клинични пътеки, процедури, лекарства и изделия. Ако обаче самата фактура съдържа отделни редове по номенклатури, именно тези редове следва да се подадат в SalesInvoices. Следователно SAF-T следва гранулацията на фактурата, а не на вътрешния отчет или на счетоводната статия.
При лечебните заведения има и едно специално ограничение, което е особено важно в този контекст. НАП изрично посочва, че лечебните заведения не следва да подават със SAF-T данни, представляващи здравна информация по смисъла на Закона за здравето, а ако предметът на доставката съдържа такава информация, при експорт за SAF-T той следва да бъде заменен с неутрално описание, например "здравни услуги". Това означава, че дори когато има редова структура по услуги, болницата не следва да изнася в SAF-T чувствителни медицински описания или кодове, които разкриват здравна информация за пациента или лечението.
Когато редовете по фактурата се подават отделно, техните вътрешни кодове, мерни единици и описания следва да бъдат поддържани последователно в MasterFiles/Products и UOMTable, тъй като в българския SAF-T Products обхваща и услугите, и стоково-материалните запаси, които са в счетоводната отчетност през периода. Данъчната логика на редовете не се определя от медицинската номенклатура, а от данъчните кодове по TAX-IMP. Например, когато конкретен ред е освободена доставка, се използва съответният код за освободени доставки. Това е особено важно, ако в един и същи поток съществуват различни видове дейности с различна данъчна логика.
Следователно правилният подход е двуслоен. Счетоводният слой може да остане агрегиран, ако така работи системата. Документният слой в SalesInvoices следва да отразява фактурата така, както е издадена и отразена по ЗДДС, но без здравна информация. Практическият извод при голям документооборот е, че не е необходимо ръчно аналитично въвеждане в счетоводството за всяка номенклатура; необходимо е автоматизирано извличане на документния детайл от фактуриращата или болничната система и отделно извличане на счетоводните записи от счетоводната система.
Въпрос 53. При фактура за доставка, която се отчита веднага на разход, например 601/401, може ли да не се подават количествени показатели и да е достатъчно само ProductCode = 0?
Отговор 53. Не във всички случаи. По действащата документация на НАП, актуализирана със Заповед № З-ЦУ-30-359/27.02.2026 г., използването на ProductCode = "0" е допустимо само в изрично предвидените хипотези за директно разходвани покупки, неподлежащи на контролирано съхранение, както и за текущи разходи за периода, например електроенергия, отопление, вода и други сходни разходи. Самото счетоводно отразяване по сметка от група 60, включително 601/401, не е достатъчно основание автоматично да се приложи този режим. Водещ е икономическият характер на покупката и начинът, по който тя се поддържа в отчетността на предприятието.
Когато е приложим този опростен режим, ProductCode = "0" не означава, че отпадат всички останали редови елементи на фактурата. По логиката на InvoiceLine документният ред трябва да остане машинно проверим чрез количество, единична цена, описание, сума по ред и данъчна информация. Поради това не е достатъчно да се подаде само код "0". Количествената и ценовата логика на реда следва да останат попълнени, а мерната единица се подава, когато е приложима и когато системата я поддържа по съответния ред.
Практически това означава, че когато покупката е директно отчетена като текущ разход и не се поддържа продуктова номенклатура за нея, документът може да бъде подаден на един ред с ProductCode = "0" и ясно описание на разхода. За да остане редът технически и методологически коректен, обичайният подход е да се използва една условна количествена единица и единична цена, равна на стойността на реда, ако фактурата не се води количествено в системата. Това е практическа конвенция за попълване на задължителните елементи, а не отделно нормативно изключение.
Ако обаче покупката е за материални запаси, за активи или за други позиции, за които се поддържа продуктова идентификация и количествена отчетност, режимът с ProductCode = "0" не е подходящ. В тези случаи фактурата следва да се подаде по обичайната редова логика с реалните продуктови и количествени показатели.
Следователно правилният извод е следният: ProductCode = "0" е допустим, но само в специалните случаи на директно разходвани или текущи разходи. Дори тогава не е достатъчно да се подаде само този код; редът трябва да запази необходимите количествени, ценови и описателни елементи, така че документът да остане валидируем и проследим.
Въпрос 54. Ако във фактура има много позиции, но всички са с един и същ номенклатурен код и се осчетоводяват през материална сметка, допустимо ли е фактурата да се представи на един ред?
Отговор 54. По общо правило не. По действащата към момента документация на НАП, включително актуализираната през 2026 г. версия 1.0.1 на Приложение № 3, няма общо правило, което да допуска обединяване на редовете във фактурата само защото всички позиции са с един и същ ProductCode или се отчитат по една и съща материална сметка.
Причината е, че PurchaseInvoices е документен, а не само счетоводен слой. На ниво InvoiceLine логиката на файла е редова: редът носи продуктова идентификация, количество, мерна единица, единична цена, сума по ред и данъчна информация, а ProductCode и InvoiceUOM се свързват с MasterFiles/Products и UOMTable. Следователно еднаквият продуктов код сам по себе си не заличава значението на отделните количества, цени и редова проследимост по документа.
Изрично предвиденото облекчение за един ред е друго. НАП допуска документът да бъде подаден на един ред с ProductCode = "0" при директно разходвани покупки, неподлежащи на контролирано съхранение, както и при текущи разходи за периода. Това е специална хипотеза и не следва да се пренася автоматично към материали, които минават през материална сметка и по същество се третират като запаси или като позиции под продуктова идентификация. Затова, ако фактурата е за материали под складов или продуктов контрол, по-защитимият и методологично правилен подход е тя да се подаде по редове.
Особено когато отделните позиции са с различни количества или различни единични цени, представянето им на един ред би отслабило документната проследимост и би създало излишен риск при съгласуването между редовете на фактурата, документните сборове и евентуалните стокови движения. В действащите указания не е предвидено общо нормативно основание за такова обединяване само поради еднакъв код.
На счетоводно ниво изводът е различен. GeneralLedgerEntries съдържа всички счетоводни операции така, както са записани в счетоводната система на данъкоплатеца, на ниво трансакция. Поради това не е необходимо броят на счетоводните редове да съвпада с броя на редовете във фактурата. Допустимо е документът да е редов в PurchaseInvoices, а счетоводният запис да е агрегиран в GeneralLedgerEntries, ако именно така работи системата.
Следователно правилният извод е следният: еднаквият ProductCode не е достатъчно основание фактурата да се сведе до един ред. Един ред е изрично допустим само в специалните случаи на директно разходвани и текущи разходи с ProductCode = "0". При материали, които се отчитат през материална сметка, по правило следва да се запази редовата структура на документа, докато счетоводният слой може да остане такъв, какъвто реално е в системата.
Въпрос 55. При "отчет за продажби" към физически лица, тоест при обобщени продажби, може ли да се подаде само един ред?
Отговор 55. Да, допустимо е. По действащата версия 1.0.1 на Приложение № 3, при отразяване на отчет за извършени продажби с код 81 в SalesInvoices се подава обобщена информация за продажбите за периода с идентификационните данни на лицето, подаващо файла, като в ProductCode се посочва код "0". Ако всички продажби в отчета попадат в една данъчна група, отчетът може да бъде представен само с един InvoiceLine. Ако обаче в отчета има продажби, попадащи в повече от една данъчна група, на ниво InvoiceLine те се подават отделно за всяка група. Към действащата към момента редакция НАП поддържа като актуална именно тази редакция на правилата.
Следователно решаващият критерий не е броят на продажбите, а броят на данъчните групи в самия обобщен отчет. Един ред е достатъчен само когато данъчната логика е еднородна за целия отчет. При смесена данъчна логика следва да има отделни редове за съответните данъчни групи, така че сумите и данъчната информация да останат проверими.