1
Във връзка със запитвания от потребители, които са били подведени, че и за фактурите важи правилото за двойното обозначаване на цените, искаме да внесем пълна яснота. Целта на тази статия е да обясни категорично какви са законовите изисквания за издаване на фактури преди и след приемането на еврото, както и да дадем нашите препоръки. Ние ще спазим стриктно законовите изисквания по най-ефективния за нашите потребители начин. Това се отнася за всички наши инструменти – от фактуриращия софтуер в портала kik-info.com до нашата специализирана система ino.bg, която предоставяме като допълнително улеснение и сигурност за клиентите на нашата счетоводна кантора.
Какво казва законът: Има ли задължение за двойно обозначаване във фактурите?
Отговорът е кратък и категоричен: НЕ.
Задължение за двойно обозначаване на стойностите в лева и евро във фактурите няма. Това е регламентирано в чл. 15, ал. 3, т. 5 от Закона за въвеждане на еврото (ЗВЕРБ). Текстът изрично изключва от обхвата на двойното обозначаване "издаването на документи по чл. 112, ал. 1 от Закона за данък върху добавената стойност", каквито са фактурите, кредитните и дебитните известия. В допълнение, официалните "Насоки за прилагане на Глава четвърта, Раздел II „Счетоводни документи" от ЗВЕРБ" потвърждават, че всички счетоводни документи, издадени преди датата на въвеждане на еврото, не се преизчисляват и се съхраняват във валутата, в която са изготвени.
Защо законодателят е предвидил това изключение?
Логиката на законодателя се базира на няколко основни причини:
Защита на крайния потребител: Основната цел на двойното обозначаване на цените (по чл. 15 от ЗВЕРБ) е да защити крайните потребители (физическите лица). То им помага да свикнат с новите стойности, да сравняват цени и да се предпазят от нелоялни търговски практики. Фактурата, особено в B2B (бизнес-към-бизнес) отношенията, е преди всичко счетоводен документ между професионалисти, от които се очаква да могат да прилагат правилата за превалутиране.
Техническа сложност и избягване на грешки: Това е може би най-важната практическа причина. Фактурата не е само една крайна сума. Тя съдържа множество редове – единични цени, количества, стойности на ред, ДДС основа, сума на ДДС. Ако законът изискваше двойно обозначаване на всеки ред, почти сигурно сборът на редовете в евро нямаше да отговаря на превалутираната обща сума в лева. Това би създало счетоводен хаос и постоянни разлики от закръгления.
Юридическа и данъчна яснота: Фактурата е официален документ. За да има юридическа стойност, тя трябва да има една-единствена, безспорна водеща валута и стойност. Съгласно Закона за счетоводството, до датата на еврото това е левът, а след това – еврото. Задължителното присъствие на две суми би могло да създаде правна несигурност коя от двете е "вярната" при спорове или данъчни проверки.
В обобщение, законодателят е преценил, че ползите от юридическата и техническа простота при издаването на фактури в една водеща валута надделяват над удобството от информативното двойно обозначаване.
Нашият подход: Яснота и ефективност
Разбирайки напълно законовите изисквания и необходимостта от максимално улеснение на бизнеса, нашият подход за фактуриращите софтуери, които поддържаме в kik-info и в ino.bg ще бъде следният:
» До датата на въвеждане на еврото: Всички фактури, създадени през нашите системи, ще продължат да бъдат издавани само в лева, в пълно съответствие със Закона за счетоводството.
» След датата на въвеждане на еврото: Системите ще бъдат актуализирани, така че всички нови фактури да се издават само в евро, както изисква промененото законодателство.
Този подход осигурява редица ползи:
» Пълно съответствие със закона: Гарантираме, че документите, издавани с нашия софтуер, са 100% изрядни.
» Избягване на объркване: Клиентите няма да се чудят коя сума да платят или как са направени закръгленията. Документът е ясен, с една водеща валута.
» Ефективност и бързина: Изчистените документи без излишна информация се обработват по-бързо в счетоводството и на доставчика и на получателя.
Доброволно двойно обозначаване във фактурите: Добра практика или източник на проблеми?
Законът не задължава, но и не забранява на фирмите доброволно да показват втора валута на фактурите си. Някои софтуерни компании дори вече имплементират такава функционалност. Въпреки това, нашата препоръка, базирана на стремежа към максимална яснота и ефективност, е да избягвате тази практика. Тя може да създаде повече объркване и проблеми, отколкото ползи. Ето няколко практически причини защо фактура само в една валута (евро) е по-добрият подход:
» Риск от объркване при плащане: Клиентът може да се обърка коя от двете суми е дължима за плащане. Това може да доведе до грешни преводи, забавяне на плащанията и необходимост от допълнителна комуникация за изясняване.
» Проблеми със закръгленията и сумирането: Ако фактурата съдържа много редове, е почти сигурно, че сборът на информативните стойности в лева на всеки отделен ред няма да е равен на информативната обща сума в лева (получена чрез превалутиране на общата сума в евро). Това може да породи недоверие и въпроси за коректността на документа.
» Повишен шанс за счетоводни грешки: Наличието на две суми увеличава риска от техническа грешка при ръчно въвеждане на фактурата в счетоводния софтуер както при вас, така и при вашия контрагент. Някой може по погрешка да осчетоводи информативната стойност в лева, вместо официалната в евро.
» Забавяне на обработката: Чистата фактура само в евро се обработва много по-бързо. Когато има и левова равностойност, счетоводството на получателя често прави насрещна проверка дали превалутирането е извършено коректно, което е излишно губене на време.
Нашата позиция: Да защитим времето и ефективността на счетоводителя
Въвеждането на еврото неминуемо ще донесе нови отговорности и повишена натовареност за всеки счетоводител в България. В този ключов момент, нашата мисия е не само да информираме, а и да защитим най-ценния ресурс на счетоводителите – тяхното професионално време и експертиза.
Именно от позицията на загриженост, ние заставаме твърдо зад становището, че доброволното двойно обозначаване във фактурите е лоша практика. То е ненужна административна тежест, която се прехвърля директно върху раменете на счетоводителите, които обработват тези документи. Вярваме, че счетоводната професия заслужава инструменти и процеси, които улесняват, а не усложняват работата.
В заключение:
Ключов принцип в модерния бизнес е ефективността. За да се гарантира максимална яснота, бързина и ефикасност, най-добрата практика е да се придържате стриктно към изискването на Закона за счетоводството: издаване на фактури само във водещата за периода валута. Това елиминира всякакви двусмислици и улеснява работата на всички по веригата – доставчици, клиенти и техните счетоводители.
Какво казва законът: Има ли задължение за двойно обозначаване във фактурите?
Отговорът е кратък и категоричен: НЕ.
Задължение за двойно обозначаване на стойностите в лева и евро във фактурите няма. Това е регламентирано в чл. 15, ал. 3, т. 5 от Закона за въвеждане на еврото (ЗВЕРБ). Текстът изрично изключва от обхвата на двойното обозначаване "издаването на документи по чл. 112, ал. 1 от Закона за данък върху добавената стойност", каквито са фактурите, кредитните и дебитните известия. В допълнение, официалните "Насоки за прилагане на Глава четвърта, Раздел II „Счетоводни документи" от ЗВЕРБ" потвърждават, че всички счетоводни документи, издадени преди датата на въвеждане на еврото, не се преизчисляват и се съхраняват във валутата, в която са изготвени.
Защо законодателят е предвидил това изключение?
Логиката на законодателя се базира на няколко основни причини:
Защита на крайния потребител: Основната цел на двойното обозначаване на цените (по чл. 15 от ЗВЕРБ) е да защити крайните потребители (физическите лица). То им помага да свикнат с новите стойности, да сравняват цени и да се предпазят от нелоялни търговски практики. Фактурата, особено в B2B (бизнес-към-бизнес) отношенията, е преди всичко счетоводен документ между професионалисти, от които се очаква да могат да прилагат правилата за превалутиране.
Техническа сложност и избягване на грешки: Това е може би най-важната практическа причина. Фактурата не е само една крайна сума. Тя съдържа множество редове – единични цени, количества, стойности на ред, ДДС основа, сума на ДДС. Ако законът изискваше двойно обозначаване на всеки ред, почти сигурно сборът на редовете в евро нямаше да отговаря на превалутираната обща сума в лева. Това би създало счетоводен хаос и постоянни разлики от закръгления.
Юридическа и данъчна яснота: Фактурата е официален документ. За да има юридическа стойност, тя трябва да има една-единствена, безспорна водеща валута и стойност. Съгласно Закона за счетоводството, до датата на еврото това е левът, а след това – еврото. Задължителното присъствие на две суми би могло да създаде правна несигурност коя от двете е "вярната" при спорове или данъчни проверки.
В обобщение, законодателят е преценил, че ползите от юридическата и техническа простота при издаването на фактури в една водеща валута надделяват над удобството от информативното двойно обозначаване.
Нашият подход: Яснота и ефективност
Разбирайки напълно законовите изисквания и необходимостта от максимално улеснение на бизнеса, нашият подход за фактуриращите софтуери, които поддържаме в kik-info и в ino.bg ще бъде следният:
» До датата на въвеждане на еврото: Всички фактури, създадени през нашите системи, ще продължат да бъдат издавани само в лева, в пълно съответствие със Закона за счетоводството.
» След датата на въвеждане на еврото: Системите ще бъдат актуализирани, така че всички нови фактури да се издават само в евро, както изисква промененото законодателство.
Този подход осигурява редица ползи:
» Пълно съответствие със закона: Гарантираме, че документите, издавани с нашия софтуер, са 100% изрядни.
» Избягване на объркване: Клиентите няма да се чудят коя сума да платят или как са направени закръгленията. Документът е ясен, с една водеща валута.
» Ефективност и бързина: Изчистените документи без излишна информация се обработват по-бързо в счетоводството и на доставчика и на получателя.
Доброволно двойно обозначаване във фактурите: Добра практика или източник на проблеми?
Законът не задължава, но и не забранява на фирмите доброволно да показват втора валута на фактурите си. Някои софтуерни компании дори вече имплементират такава функционалност. Въпреки това, нашата препоръка, базирана на стремежа към максимална яснота и ефективност, е да избягвате тази практика. Тя може да създаде повече объркване и проблеми, отколкото ползи. Ето няколко практически причини защо фактура само в една валута (евро) е по-добрият подход:
» Риск от объркване при плащане: Клиентът може да се обърка коя от двете суми е дължима за плащане. Това може да доведе до грешни преводи, забавяне на плащанията и необходимост от допълнителна комуникация за изясняване.
» Проблеми със закръгленията и сумирането: Ако фактурата съдържа много редове, е почти сигурно, че сборът на информативните стойности в лева на всеки отделен ред няма да е равен на информативната обща сума в лева (получена чрез превалутиране на общата сума в евро). Това може да породи недоверие и въпроси за коректността на документа.
» Повишен шанс за счетоводни грешки: Наличието на две суми увеличава риска от техническа грешка при ръчно въвеждане на фактурата в счетоводния софтуер както при вас, така и при вашия контрагент. Някой може по погрешка да осчетоводи информативната стойност в лева, вместо официалната в евро.
» Забавяне на обработката: Чистата фактура само в евро се обработва много по-бързо. Когато има и левова равностойност, счетоводството на получателя често прави насрещна проверка дали превалутирането е извършено коректно, което е излишно губене на време.
Нашата позиция: Да защитим времето и ефективността на счетоводителя
Въвеждането на еврото неминуемо ще донесе нови отговорности и повишена натовареност за всеки счетоводител в България. В този ключов момент, нашата мисия е не само да информираме, а и да защитим най-ценния ресурс на счетоводителите – тяхното професионално време и експертиза.
Именно от позицията на загриженост, ние заставаме твърдо зад становището, че доброволното двойно обозначаване във фактурите е лоша практика. То е ненужна административна тежест, която се прехвърля директно върху раменете на счетоводителите, които обработват тези документи. Вярваме, че счетоводната професия заслужава инструменти и процеси, които улесняват, а не усложняват работата.
В заключение:
Ключов принцип в модерния бизнес е ефективността. За да се гарантира максимална яснота, бързина и ефикасност, най-добрата практика е да се придържате стриктно към изискването на Закона за счетоводството: издаване на фактури само във водещата за периода валута. Това елиминира всякакви двусмислици и улеснява работата на всички по веригата – доставчици, клиенти и техните счетоводители.
2
Думата "само" е на място в статията, като тя се отнася за отчитането, а не за отпечатването на касовия бон. Става въпрос за това, че в първите 12 месеца след приемането на еврото, двете правила (ал. 1 и ал. 2) важат едновременно. Система трябва да работи в евро (ще отчита продажбите и данъците в евро), но ще има задължението да изчислява и отпечатва на касовата бележка (освен в евро) информативно и равностойността в лева на крайната сума. Това се има предвид, но понеже явно не е ясно в статията малко допълнихме текста.
3
Как да се подготвим за задълженията по двойното обозначаване, фактуриране и превалутиране: Анализ на закона и официалните указания
Преходът на България към еврото е не само важна икономическа стъпка за страната, но и сериозно предизвикателство за всеки бизнес и счетоводител. За да се осигури безпроблемен и прозрачен процес, освен Закона за въвеждане на еврото в Република България (ЗВЕРБ), отговорните институции издадоха и подробни методически насоки, публикувани в края на статията в PDF за сваляне.
Целта на тази статия е да обедини нормативната рамка с практическите разяснения, за да преведе процеса в разбираеми и изпълними стъпки за вашата дейност. Този материал е създаден като подробно и практическо ръководство, което ще бъде постоянно актуализирано при изменения в законодателството, публикуване на промени в Наредба Н-18 или разяснения от институциите. Материалът ще се допълва и на база на вашите въпроси и казуси. Важно: Веднага щом датите бъдат обявени официално, те ще бъдат отразени в статията.
Преди да разгледаме конкретните задължения, е важно да се запознаете с двете златни правила, които ще се прилагат навсякъде:
Правило за превалутиране (Чл. 12 от ЗВЕРБ): Преминаването от левове към евро ще става чрез разделяне на сумата в левове на пълния официален валутен курс (1,95583). Този курс не се закръглява или съкращава по време на изчислението.
Правило за закръгляване (Чл. 13 от ЗВЕРБ): След като се раздели на курса, получената сума в евро се закръглява до втория знак след десетичната запетая по стандартния математически метод:
» Ако третият знак след запетаята е по-малък от 5, вторият знак остава непроменен. (Пример: 653,96 лв. / 1,95583 = 334,364... → 334,36 €)
» Ако третият знак е равен на или по-голям от 5, вторият знак се увеличава с единица. (Пример: 655,12 лв. / 1,95583 = 334,957... → 334,96 €)
Част 1: Двойното обозначаване на цените – ключовото задължение
Това е най-видимата и мащабна промяна за търговците. Информационните системи на предприятията трябва да имат създадена готовност за нея.
Период на задължението (Чл. 15, ал. 2): Започва един месец след датата на решението на Съвета на ЕС за приемане на еврото и приключва 12 месеца след датата на въвеждането му в България.
Изисквания към вида (Чл. 16, ал. 1): Цените в лева и евро трябва да бъдат:
» В непосредствена близост една до друга.
» Ясни, четливи, недвусмислени и лесно разбираеми.
» Изписани с еднакъв размер на шрифта.
» Придружени от символа или съкращението на валутата (напр. лв./BGN и €/EUR).
Къде е задължително (Чл. 15, ал. 1): На практика – навсякъде, където се представя цена на потребител: етикети, ценоразписи (менюта), уебсайтове, онлайн магазини, каталози и всякакви рекламни материали.
Изключения (Чл. 15, ал. 3): Законът предвижда няколко изключения, като продукти с трайно поставена цена, тютюневи изделия, табели на бензиностанции и таксиметрови апарати.
Важно: Тези изключения не освобождават търговците от задължението. Те трябва да осигурят двойно обозначаване по друг подходящ начин – например на ценовия етикет на рафта.
Част 2: Касови апарати и фискални бонове (Чл. 20 от ЗВЕРБ)
Тук промените са критични и изискват прецизна техническа подготовка, защото Чл. 20 от ЗВЕРБ въвежда две изисквания с различен, но застъпващ се период на действие:
Изискване към вида на касовата бележка (Чл. 20, ал. 1):
През целия период на двойно обозначаване (който продължава 12 месеца след датата на въвеждане на еврото), общата крайна сума на фискалния бон трябва да се показва и в лева, и в евро, заедно с официалния курс.
Изискване към работата на фискалното устройство (Чл. 20, ал. 2):
От датата на въвеждане на еврото, всички фискални устройства трябва да бъдат настроени да регистрират и отчитат (към НАП) всички плащания само в евро и центове.
Какво означава това на практика?
В първите 12 месеца след приемането на еврото двете правила важат едновременно. Вашата система ще работи в евро (ще отчита продажбите и данъците в евро), но ще има задължението да изчислява и отпечатва на касовата бележка информативно крайната сума в евро, нейната равностойност в лева и официалният валутен курс.
Част 3: Счетоводни документи и превалутиране
Това е ядрото на подготовката за всеки счетоводен отдел. Официалните насоки дават ключови разяснения. Основният принцип е, че промяната се отразява перспективно – от датата на въвеждане на еврото нататък.
Издаване на фактури и обработка на документи
Специален фокус: Фактури, известия и протоколи – какво казва законът?
Един от най-често срещаните въпроси е свързан със задължението за двойно обозначаване на стойностите във фактурите. Тук законът е категоричен и недвусмислен, за да се избегне всякакво объркване. Няма законово задължение за двойно обозначаване на цени във фактури.
Без двойно обозначаване: Изискването за двойно обозначаване не се прилага при издаването на фактури и известия към тях. Доказателството е в Чл. 15, ал. 3, т. 5 от Закона за въвеждане на еврото (ЗВЕРБ). Тази точка изрично изключва документите по чл. 112 от ЗДДС (каквито са фактурите, кредитните и дебитните известия) от задължението за двойно обозначаване на цените в лева и евро.
Как трябва да се издават фактурите на практика?
Правилото е много просто и следва основната отчетна валута за периода:
» До датата на въвеждане на еврото: Фактурите се издават в лева, както досега.
» След датата на въвеждане на еврото: Съгласно Закона за счетоводството (чл. 5, ал. 1), основната валута на счетоводните документи става еврото. Това означава, че всички фактури и известия трябва да се издават в евро. Законът не предвижда те да се издават в "лева и евро", а именно в евро.
» Старите документи не се променят: Всички първични и вторични счетоводни документи, регистри и справки, съдържащи счетоводна информация и отразени в счетоводството преди датата на въвеждане на еврото, не се преизчисляват в евро и се съхраняват във валутата, в която са изготвени (за повечето предприятия – лев).
Обработка на документи след датата:
» Документ в лева, издаден преди датата на въвеждане на еврото, но постъпил след нея, се осчетоводява в лева, ако годишният финансов отчет (ГФО) в лева още не е приет.
» Документ в евро, отнасящ се за предходен отчетен период в лева (напр. фактура за ток за декември, издадена през януари), се осчетоводява в предходния период, като сумата се превалутира обратно в левове по официалния курс.
Превалутиране на счетоводството на датата на въвеждане на еврото (Чл. 48 от ЗВЕРБ)
На тази дата крайните салда в левове се преизчисляват в евро, за да станат начални. Това се прави аналитично, за всеки актив и пасив поотделно.
Специално правило за заплати (Чл. 45 от ЗВЕРБ): При превалутиране на начислени, но неизплатени възнаграждения, обезщетения, бонуси и др. задължения към персонала, закръгляването е винаги нагоре до най-близкия евроцент, ако третият знак след десетичната запетая е по-голям от нула. Пример: Неизплатено възнаграждение от 1024,51 лв. / 1,95583 = 523,82364... Закръглената сума на задължението е 523,83 €.
Отчитане на разликите от превалутиране:
» Активи и пасиви: Всички курсови разлики, възникнали от преизчисляването, се отнасят като текущи счетоводни приходи или разходи (напр. в сметки "Разлики от промяна на валутни курсове"). Тези разлики се признават за данъчни цели в годината на счетоводното им отчитане, съгласно чл. 48, ал. 4 от ЗВЕРБ.
» Капитал: Разликите от преизчисляването на записания капитал се отнасят в сметка "Неразпределена печалба / Непокрита загуба от минали години".
Превалутиране на капитала в Търговския регистър (Чл. 31-33 от ЗВЕРБ)
Търговските дружества имат срок до 12 месеца след въвеждане на еврото да актуализират уставите/дружествените си договори.
За Акционерни дружества (АД): Процесът следва последователност:
1. Превалутира се номиналната стойност на една акция по общите правила.
2. Новата стойност на акцията се умножава по общия им брой, за да се получи новият размер на капитала.
За Дружества с ограничена отговорност (ООД):
1. Капиталът се превалутира автоматично и служебно в Търговския регистър съгласно чл. 33 от ЗВЕРБ.
2. След това предприятието извършва стойностно разпределение на превалутирания капитал между съдружниците, съразмерно на тяхното участие преди превалутирането (чл. 31, ал. 5 от ЗВЕРБ).
3. Ако сборът от новоизчислените дялове не съвпада с автоматично превалутирания капитал (поради закръгления), съдружниците могат да приемат решение за изменение на капитала с до 5% по облекчен ред (чл. 32, ал. 5 от ЗВЕРБ).
Годишни финансови отчети (ГФО)
» Отчетите с дата на отчета след датата на въвеждане на еврото се съставят и представят в евро.
» В ГФО за годината на прехода, сравнителната информация за предходния отчетен период (който е бил в лева) също трябва да бъде преизчислена и представена в евро.
» В приложенията към ГФО трябва да се оповести причината за промяната в отчетната валута.
Част 4: Първият месец – период на двойно обращение (Чл. 24, Чл. 25)
В първия месец след въвеждането на еврото и левът, и еврото са законно платежно средство.
» Правило за рестото (Чл. 25, ал. 1): Това е едно от най-важните практически правила за първия месец. Основният принцип е, че търговецът връща ресто изцяло в евро, независимо дали плащането е направено в лева или в евро.
Изключение: Законът предвижда само едно изключение – ако търговецът няма достатъчна моментна наличност в евро. В такъв случай той връща остатъка изцяло в левове.
Важно: Смесено връщане на ресто (част в евро и част в лева) не е разрешено. Рестото трябва да бъде върнато изцяло в една от двете валути.
» Ограничение за монети (Чл. 25, ал. 2): Търговците имат право да откажат да приемат повече от 50 броя монети в левове при една трансакция.
» Счетоводно: Предприятията, които приемат плащания в брой, трябва да водят паричните средства в касата аналитично в левове и в евро през този едномесечен период. Това е необходимо, защото макар основната отчетна валута на предприятието вече да е еврото, в касата ви физически ще присъстват и двете валути. За този едномесечен период, левовата наличност в касата трябва да се третира счетоводно по същия начин, както всяка друга чуждестранна валута (долари, паунди и др.). Макар да я следите количествено и стойностно в лева на аналитично ниво за целите на контрола, в синтетичното счетоводство всички операции трябва да бъдат отразени в евро.
Когато левовата наличност се внесе в банка, тя се обменя по официалния курс и постъпва по банковата сметка на дружеството в евро. Счетоводната операция ще бъде прехвърляне на стойността от аналитичната сметка "Каса в лева" към банковата сметка в евро, като по този начин левовата наличност в касата се занулява или намалява.
Част 5: Вендинг автомати и други машини за самообслужване
Законът дава ясни и категорични насоки за вендинг автоматите и всички други устройства на самообслужване. Основното правило се намира в Чл. 25, ал. 4 ЗВЕРБ и е подкрепено от насоките за адаптиране на информационните системи (PDF в края на статията).
Ето какво гласи то, преведено на практичен език:
От датата на въвеждане на еврото в България, при извършване на операции в брой с автомати, устройства и системи на самообслужване (включително вендинг машини за кафе, храни, напитки, както и всякакви други, дори такива без електрическо захранване), трябва да се използва само евро.
Това означава следното:
» Без преходен период за приемане на левове: За разлика от магазините с касиери, които през първия месец ще могат да приемат и левове, и евро, вендинг автоматите нямат такъв гратисен период. От полунощ на датата на въвеждане на еврото те трябва да са настроени да приемат само и единствено евро монети и банкноти.
» Приемане и връщане на ресто: Тъй като машините ще приемат само евро, то и рестото, което връщат (ако имат такава функция), ще бъде само в евро.
» Двойно обозначаване на цените: Важно е да се отбележи, че макар машината да приема плащане само в евро, задължението за двойно обозначаване на цените на самите продукти остава в сила. Това означава, че на етикета до всеки продукт цената трябва да бъде изписана и в лева, и в евро през целия 13-месечен период на двойно обозначаване.
Накратко: За операторите на вендинг автомати преходът е едномоментен и изисква предварителна техническа подготовка. В деня на въвеждане на еврото машините им трябва да са напълно готови да работят само с новата валута.
Част 6: Специален фокус: Техническото превалутиране – капанът на умножението
Практиката показва, че при техническата реализация на двойното обозначаване (особено в уебсайтове и софтуери) съществува сериозен риск от грешки. Често IT специалистите, за да улеснят изчисленията, използват умножение с предварително изчислен коефициент (напр. 0.51129). Този метод е грешен и води до неточни резултати.
Законът е категоричен в чл. 12 от ЗВЕРБ: превалутирането от лева в евро се извършва само чрез делене на пълната числова стойност на официалния валутен курс (1,95583).
Какво да кажете на вашите IT специалисти:
За да гарантирате съответствие със закона, изрично изисквайте от разработчиците да прилагат следната формула:
» Правилно: Сума в евро = (Сума в лева) / 1.95583
» Неправилно: Сума в евро = (Сума в лева) * 0.51129
Едва след това полученият резултат се закръглява до втория знак съгласно правилата. Всяко друго изчисление крие риск от неточности и несъответствие със законовите изисквания.
Практически казус: Как да изчислим цената в лева след въвеждането на еврото?
Законът ясно регламентира как се преминава от лева в евро. Но какво се случва след датата на въвеждане на еврото, когато основната ви цена вече е в евро, а трябва да покажете информативна цена в лева за остатъка от периода на двойно обозначаване? Законът не описва изрично тази "обратна" калкулация, но правилният и логичен подход е да се приложи обратната математическа операция:
Информационна цена в лева = (Официална цена в евро) * 1.95583
Тук възниква неизбежен математически ефект от закръгленията:
» Цена към 31.12.2025 г.: 2,00 лв.
» Превалутиране по закон: 2 / 1.95583 = 1.0225... → официална цена 1,02 €
» Информативна цена в лева към 01.01.2026 г.: 1.02 * 1.95583 = 1.9949... → информативна цена 1,99 лв.
Тази разлика от една стотинка не е грешка, а резултат от правилата за закръгляване. Важно е да прилагате избрания метод последователно за всичките си цени и да сте подготвени да обясните на клиенти, че официалната цена е тази в евро, а левовата е само информативна и изчислена на базата на нея.
В обобщение: макар математическата концепция за обратния курс да е вярна, законовият текст има предимство. Той е създаден именно за да се елиминират неточности, произтичащи от използването на закръглени коефициенти. Методът, който всички системи трябва да прилагат, е само един: деление на 1.95583. Всяко друго действие е технически компромис, който гарантирано води до грешни резултати при определени суми и е в разрез със закона.
Част 7: Адаптиране на информационните системи (ИС)
Адаптацията на софтуера е гръбнакът на успешния преход. Под "Информационни системи" се разбира целият софтуер, който обработва финансова информация: ERP, счетоводен софтуер, системи за управление на запаси, продажби, CRM, онлайн магазини и платформи за разплащане.
Препоръчителен план за действие:
1. Анализ и идентификация: Направете опис на всички ваши системи, които подлежат на адаптиране.
2. Планиране: Свържете се с доставчиците на софтуер. Идентифицирайте необходимите действия, ресурси, отговорници и срокове.
3. Адаптация и архивиране: Предприемете техническите мерки. Ключово: преди да преобразувате данните си в евро, архивирайте оригиналните данни в лева съгласно принципите за защита на данните.
4. Верификация и тестване: Проверете щателно дали всички адаптирани системи функционират правилно, дали софтуерът работи коректно с евро и дали всички бази данни с превалутирани стойности са актуализирани и проверени.
Заключение
Преходът към еврото изисква проактивност. Ето основните стъпки, които всеки бизнес трябва да предприеме:
1. Счетоводна подготовка: Изгответе детайлен план за превалутиране на счетоводните салда, активи, пасиви и капитал, следвайки официалните насоки.
2. Техническа подготовка: Стартирайте процеса по анализ и планиране на адаптацията на вашите информационни системи в тясно сътрудничество с IT доставчиците си.
3. Търговска подготовка: Планирайте и подгответе актуализацията на всички етикети, ценоразписи, менюта, онлайн магазини и рекламни материали.
4. Обучение на персонала: Проведете обучения на служителите относно извършените промени в информационните системи и новите правила за работа с тях.
Неспазването на изискванията на ЗВЕРБ ще се следи от контролни органи като КЗП и НАП, като са предвидени и значителни санкции (Чл. 55, Чл. 59 от ЗВЕРБ). С добра организация и навременна подготовка, приемането на еврото може да премине гладко и безпроблемно за вашия бизнес.
Полезни линкове и материали:
Закон за въвеждане на еврото в Република България
Насоки за счетоводството (PDF)
Насоки информационните системи (PDF)
Официален сайт за приемане на еврото в България
Сайт на Министерството на финансите
Преходът на България към еврото е не само важна икономическа стъпка за страната, но и сериозно предизвикателство за всеки бизнес и счетоводител. За да се осигури безпроблемен и прозрачен процес, освен Закона за въвеждане на еврото в Република България (ЗВЕРБ), отговорните институции издадоха и подробни методически насоки, публикувани в края на статията в PDF за сваляне.
Целта на тази статия е да обедини нормативната рамка с практическите разяснения, за да преведе процеса в разбираеми и изпълними стъпки за вашата дейност. Този материал е създаден като подробно и практическо ръководство, което ще бъде постоянно актуализирано при изменения в законодателството, публикуване на промени в Наредба Н-18 или разяснения от институциите. Материалът ще се допълва и на база на вашите въпроси и казуси. Важно: Веднага щом датите бъдат обявени официално, те ще бъдат отразени в статията.
Преди да разгледаме конкретните задължения, е важно да се запознаете с двете златни правила, които ще се прилагат навсякъде:
Правило за превалутиране (Чл. 12 от ЗВЕРБ): Преминаването от левове към евро ще става чрез разделяне на сумата в левове на пълния официален валутен курс (1,95583). Този курс не се закръглява или съкращава по време на изчислението.
Правило за закръгляване (Чл. 13 от ЗВЕРБ): След като се раздели на курса, получената сума в евро се закръглява до втория знак след десетичната запетая по стандартния математически метод:
» Ако третият знак след запетаята е по-малък от 5, вторият знак остава непроменен. (Пример: 653,96 лв. / 1,95583 = 334,364... → 334,36 €)
» Ако третият знак е равен на или по-голям от 5, вторият знак се увеличава с единица. (Пример: 655,12 лв. / 1,95583 = 334,957... → 334,96 €)
Част 1: Двойното обозначаване на цените – ключовото задължение
Това е най-видимата и мащабна промяна за търговците. Информационните системи на предприятията трябва да имат създадена готовност за нея.
Период на задължението (Чл. 15, ал. 2): Започва един месец след датата на решението на Съвета на ЕС за приемане на еврото и приключва 12 месеца след датата на въвеждането му в България.
Изисквания към вида (Чл. 16, ал. 1): Цените в лева и евро трябва да бъдат:
» В непосредствена близост една до друга.
» Ясни, четливи, недвусмислени и лесно разбираеми.
» Изписани с еднакъв размер на шрифта.
» Придружени от символа или съкращението на валутата (напр. лв./BGN и €/EUR).
Къде е задължително (Чл. 15, ал. 1): На практика – навсякъде, където се представя цена на потребител: етикети, ценоразписи (менюта), уебсайтове, онлайн магазини, каталози и всякакви рекламни материали.
Изключения (Чл. 15, ал. 3): Законът предвижда няколко изключения, като продукти с трайно поставена цена, тютюневи изделия, табели на бензиностанции и таксиметрови апарати.
Важно: Тези изключения не освобождават търговците от задължението. Те трябва да осигурят двойно обозначаване по друг подходящ начин – например на ценовия етикет на рафта.
Част 2: Касови апарати и фискални бонове (Чл. 20 от ЗВЕРБ)
Тук промените са критични и изискват прецизна техническа подготовка, защото Чл. 20 от ЗВЕРБ въвежда две изисквания с различен, но застъпващ се период на действие:
Изискване към вида на касовата бележка (Чл. 20, ал. 1):
През целия период на двойно обозначаване (който продължава 12 месеца след датата на въвеждане на еврото), общата крайна сума на фискалния бон трябва да се показва и в лева, и в евро, заедно с официалния курс.
Изискване към работата на фискалното устройство (Чл. 20, ал. 2):
От датата на въвеждане на еврото, всички фискални устройства трябва да бъдат настроени да регистрират и отчитат (към НАП) всички плащания само в евро и центове.
Какво означава това на практика?
В първите 12 месеца след приемането на еврото двете правила важат едновременно. Вашата система ще работи в евро (ще отчита продажбите и данъците в евро), но ще има задължението да изчислява и отпечатва на касовата бележка информативно крайната сума в евро, нейната равностойност в лева и официалният валутен курс.
Част 3: Счетоводни документи и превалутиране
Това е ядрото на подготовката за всеки счетоводен отдел. Официалните насоки дават ключови разяснения. Основният принцип е, че промяната се отразява перспективно – от датата на въвеждане на еврото нататък.
Издаване на фактури и обработка на документи
Специален фокус: Фактури, известия и протоколи – какво казва законът?
Един от най-често срещаните въпроси е свързан със задължението за двойно обозначаване на стойностите във фактурите. Тук законът е категоричен и недвусмислен, за да се избегне всякакво объркване. Няма законово задължение за двойно обозначаване на цени във фактури.
Без двойно обозначаване: Изискването за двойно обозначаване не се прилага при издаването на фактури и известия към тях. Доказателството е в Чл. 15, ал. 3, т. 5 от Закона за въвеждане на еврото (ЗВЕРБ). Тази точка изрично изключва документите по чл. 112 от ЗДДС (каквито са фактурите, кредитните и дебитните известия) от задължението за двойно обозначаване на цените в лева и евро.
Как трябва да се издават фактурите на практика?
Правилото е много просто и следва основната отчетна валута за периода:
» До датата на въвеждане на еврото: Фактурите се издават в лева, както досега.
» След датата на въвеждане на еврото: Съгласно Закона за счетоводството (чл. 5, ал. 1), основната валута на счетоводните документи става еврото. Това означава, че всички фактури и известия трябва да се издават в евро. Законът не предвижда те да се издават в "лева и евро", а именно в евро.
» Старите документи не се променят: Всички първични и вторични счетоводни документи, регистри и справки, съдържащи счетоводна информация и отразени в счетоводството преди датата на въвеждане на еврото, не се преизчисляват в евро и се съхраняват във валутата, в която са изготвени (за повечето предприятия – лев).
Обработка на документи след датата:
» Документ в лева, издаден преди датата на въвеждане на еврото, но постъпил след нея, се осчетоводява в лева, ако годишният финансов отчет (ГФО) в лева още не е приет.
» Документ в евро, отнасящ се за предходен отчетен период в лева (напр. фактура за ток за декември, издадена през януари), се осчетоводява в предходния период, като сумата се превалутира обратно в левове по официалния курс.
Превалутиране на счетоводството на датата на въвеждане на еврото (Чл. 48 от ЗВЕРБ)
На тази дата крайните салда в левове се преизчисляват в евро, за да станат начални. Това се прави аналитично, за всеки актив и пасив поотделно.
Специално правило за заплати (Чл. 45 от ЗВЕРБ): При превалутиране на начислени, но неизплатени възнаграждения, обезщетения, бонуси и др. задължения към персонала, закръгляването е винаги нагоре до най-близкия евроцент, ако третият знак след десетичната запетая е по-голям от нула. Пример: Неизплатено възнаграждение от 1024,51 лв. / 1,95583 = 523,82364... Закръглената сума на задължението е 523,83 €.
Отчитане на разликите от превалутиране:
» Активи и пасиви: Всички курсови разлики, възникнали от преизчисляването, се отнасят като текущи счетоводни приходи или разходи (напр. в сметки "Разлики от промяна на валутни курсове"). Тези разлики се признават за данъчни цели в годината на счетоводното им отчитане, съгласно чл. 48, ал. 4 от ЗВЕРБ.
» Капитал: Разликите от преизчисляването на записания капитал се отнасят в сметка "Неразпределена печалба / Непокрита загуба от минали години".
Превалутиране на капитала в Търговския регистър (Чл. 31-33 от ЗВЕРБ)
Търговските дружества имат срок до 12 месеца след въвеждане на еврото да актуализират уставите/дружествените си договори.
За Акционерни дружества (АД): Процесът следва последователност:
1. Превалутира се номиналната стойност на една акция по общите правила.
2. Новата стойност на акцията се умножава по общия им брой, за да се получи новият размер на капитала.
За Дружества с ограничена отговорност (ООД):
1. Капиталът се превалутира автоматично и служебно в Търговския регистър съгласно чл. 33 от ЗВЕРБ.
2. След това предприятието извършва стойностно разпределение на превалутирания капитал между съдружниците, съразмерно на тяхното участие преди превалутирането (чл. 31, ал. 5 от ЗВЕРБ).
3. Ако сборът от новоизчислените дялове не съвпада с автоматично превалутирания капитал (поради закръгления), съдружниците могат да приемат решение за изменение на капитала с до 5% по облекчен ред (чл. 32, ал. 5 от ЗВЕРБ).
Годишни финансови отчети (ГФО)
» Отчетите с дата на отчета след датата на въвеждане на еврото се съставят и представят в евро.
» В ГФО за годината на прехода, сравнителната информация за предходния отчетен период (който е бил в лева) също трябва да бъде преизчислена и представена в евро.
» В приложенията към ГФО трябва да се оповести причината за промяната в отчетната валута.
Част 4: Първият месец – период на двойно обращение (Чл. 24, Чл. 25)
В първия месец след въвеждането на еврото и левът, и еврото са законно платежно средство.
» Правило за рестото (Чл. 25, ал. 1): Това е едно от най-важните практически правила за първия месец. Основният принцип е, че търговецът връща ресто изцяло в евро, независимо дали плащането е направено в лева или в евро.
Изключение: Законът предвижда само едно изключение – ако търговецът няма достатъчна моментна наличност в евро. В такъв случай той връща остатъка изцяло в левове.
Важно: Смесено връщане на ресто (част в евро и част в лева) не е разрешено. Рестото трябва да бъде върнато изцяло в една от двете валути.
» Ограничение за монети (Чл. 25, ал. 2): Търговците имат право да откажат да приемат повече от 50 броя монети в левове при една трансакция.
» Счетоводно: Предприятията, които приемат плащания в брой, трябва да водят паричните средства в касата аналитично в левове и в евро през този едномесечен период. Това е необходимо, защото макар основната отчетна валута на предприятието вече да е еврото, в касата ви физически ще присъстват и двете валути. За този едномесечен период, левовата наличност в касата трябва да се третира счетоводно по същия начин, както всяка друга чуждестранна валута (долари, паунди и др.). Макар да я следите количествено и стойностно в лева на аналитично ниво за целите на контрола, в синтетичното счетоводство всички операции трябва да бъдат отразени в евро.
Когато левовата наличност се внесе в банка, тя се обменя по официалния курс и постъпва по банковата сметка на дружеството в евро. Счетоводната операция ще бъде прехвърляне на стойността от аналитичната сметка "Каса в лева" към банковата сметка в евро, като по този начин левовата наличност в касата се занулява или намалява.
Част 5: Вендинг автомати и други машини за самообслужване
Законът дава ясни и категорични насоки за вендинг автоматите и всички други устройства на самообслужване. Основното правило се намира в Чл. 25, ал. 4 ЗВЕРБ и е подкрепено от насоките за адаптиране на информационните системи (PDF в края на статията).
Ето какво гласи то, преведено на практичен език:
От датата на въвеждане на еврото в България, при извършване на операции в брой с автомати, устройства и системи на самообслужване (включително вендинг машини за кафе, храни, напитки, както и всякакви други, дори такива без електрическо захранване), трябва да се използва само евро.
Това означава следното:
» Без преходен период за приемане на левове: За разлика от магазините с касиери, които през първия месец ще могат да приемат и левове, и евро, вендинг автоматите нямат такъв гратисен период. От полунощ на датата на въвеждане на еврото те трябва да са настроени да приемат само и единствено евро монети и банкноти.
» Приемане и връщане на ресто: Тъй като машините ще приемат само евро, то и рестото, което връщат (ако имат такава функция), ще бъде само в евро.
» Двойно обозначаване на цените: Важно е да се отбележи, че макар машината да приема плащане само в евро, задължението за двойно обозначаване на цените на самите продукти остава в сила. Това означава, че на етикета до всеки продукт цената трябва да бъде изписана и в лева, и в евро през целия 13-месечен период на двойно обозначаване.
Накратко: За операторите на вендинг автомати преходът е едномоментен и изисква предварителна техническа подготовка. В деня на въвеждане на еврото машините им трябва да са напълно готови да работят само с новата валута.
Част 6: Специален фокус: Техническото превалутиране – капанът на умножението
Практиката показва, че при техническата реализация на двойното обозначаване (особено в уебсайтове и софтуери) съществува сериозен риск от грешки. Често IT специалистите, за да улеснят изчисленията, използват умножение с предварително изчислен коефициент (напр. 0.51129). Този метод е грешен и води до неточни резултати.
Законът е категоричен в чл. 12 от ЗВЕРБ: превалутирането от лева в евро се извършва само чрез делене на пълната числова стойност на официалния валутен курс (1,95583).
Какво да кажете на вашите IT специалисти:
За да гарантирате съответствие със закона, изрично изисквайте от разработчиците да прилагат следната формула:
» Правилно: Сума в евро = (Сума в лева) / 1.95583
» Неправилно: Сума в евро = (Сума в лева) * 0.51129
Едва след това полученият резултат се закръглява до втория знак съгласно правилата. Всяко друго изчисление крие риск от неточности и несъответствие със законовите изисквания.
Практически казус: Как да изчислим цената в лева след въвеждането на еврото?
Законът ясно регламентира как се преминава от лева в евро. Но какво се случва след датата на въвеждане на еврото, когато основната ви цена вече е в евро, а трябва да покажете информативна цена в лева за остатъка от периода на двойно обозначаване? Законът не описва изрично тази "обратна" калкулация, но правилният и логичен подход е да се приложи обратната математическа операция:
Информационна цена в лева = (Официална цена в евро) * 1.95583
Тук възниква неизбежен математически ефект от закръгленията:
» Цена към 31.12.2025 г.: 2,00 лв.
» Превалутиране по закон: 2 / 1.95583 = 1.0225... → официална цена 1,02 €
» Информативна цена в лева към 01.01.2026 г.: 1.02 * 1.95583 = 1.9949... → информативна цена 1,99 лв.
Тази разлика от една стотинка не е грешка, а резултат от правилата за закръгляване. Важно е да прилагате избрания метод последователно за всичките си цени и да сте подготвени да обясните на клиенти, че официалната цена е тази в евро, а левовата е само информативна и изчислена на базата на нея.
В обобщение: макар математическата концепция за обратния курс да е вярна, законовият текст има предимство. Той е създаден именно за да се елиминират неточности, произтичащи от използването на закръглени коефициенти. Методът, който всички системи трябва да прилагат, е само един: деление на 1.95583. Всяко друго действие е технически компромис, който гарантирано води до грешни резултати при определени суми и е в разрез със закона.
Част 7: Адаптиране на информационните системи (ИС)
Адаптацията на софтуера е гръбнакът на успешния преход. Под "Информационни системи" се разбира целият софтуер, който обработва финансова информация: ERP, счетоводен софтуер, системи за управление на запаси, продажби, CRM, онлайн магазини и платформи за разплащане.
Препоръчителен план за действие:
1. Анализ и идентификация: Направете опис на всички ваши системи, които подлежат на адаптиране.
2. Планиране: Свържете се с доставчиците на софтуер. Идентифицирайте необходимите действия, ресурси, отговорници и срокове.
3. Адаптация и архивиране: Предприемете техническите мерки. Ключово: преди да преобразувате данните си в евро, архивирайте оригиналните данни в лева съгласно принципите за защита на данните.
4. Верификация и тестване: Проверете щателно дали всички адаптирани системи функционират правилно, дали софтуерът работи коректно с евро и дали всички бази данни с превалутирани стойности са актуализирани и проверени.
Заключение
Преходът към еврото изисква проактивност. Ето основните стъпки, които всеки бизнес трябва да предприеме:
1. Счетоводна подготовка: Изгответе детайлен план за превалутиране на счетоводните салда, активи, пасиви и капитал, следвайки официалните насоки.
2. Техническа подготовка: Стартирайте процеса по анализ и планиране на адаптацията на вашите информационни системи в тясно сътрудничество с IT доставчиците си.
3. Търговска подготовка: Планирайте и подгответе актуализацията на всички етикети, ценоразписи, менюта, онлайн магазини и рекламни материали.
4. Обучение на персонала: Проведете обучения на служителите относно извършените промени в информационните системи и новите правила за работа с тях.
Неспазването на изискванията на ЗВЕРБ ще се следи от контролни органи като КЗП и НАП, като са предвидени и значителни санкции (Чл. 55, Чл. 59 от ЗВЕРБ). С добра организация и навременна подготовка, приемането на еврото може да премине гладко и безпроблемно за вашия бизнес.
Полезни линкове и материали:
Закон за въвеждане на еврото в Република България
Насоки за счетоводството (PDF)
Насоки информационните системи (PDF)
Официален сайт за приемане на еврото в България
Сайт на Министерството на финансите
4
Във връзка с публикуваните за обществено обсъждане проект на нормативната уредба и техническата спецификация на SAF-T, АССП изготви официално становище до Министъра на финансите и Изпълнителния директор на НАП. Становището очертава основните предизвикателства пред бизнеса и счетоводната общност и предлага конкретни, аргументирани решения за оптимизиране на изискванията, с цел постигане на баланс между нуждите на данъчния контрол и реалния административен капацитет на предприятията в България. По-долу можете да се запознаете с текста на становището.
ОТНОСНО: Становище по проекта на нормативната уредба и техническата спецификация на Стандартен одитен файл за данъчни цели (SAF-T) в България
УВАЖАЕМА ГОСПОЖО МИНИСТЪР,
УВАЖЕМИ ГОСПОДИН СПЕЦОВ,
От името на Асоциацията на счетоводителите и счетоводните предприятия (АССП) бихме искали да изразим нашата принципна подкрепа за въвеждането на Стандартен одитен файл за данъчни цели (SAF-T) като стъпка към модернизацията на данъчния контрол и дигитализацията на отчетните процеси.
Въпреки това, детайлният анализ на предложената нормативна и техническа рамка разкрива редица съществени проблеми, които, ако не бъдат адресирани, рискуват да направят схемата практически неприложима или непропорционално натоварваща за огромна част от българския бизнес, и по-специално за микро и малките предприятия (МСП). С настоящото становище представяме нашите виждания и конструктивни предложения, целящи да адаптират изискванията на SAF-T към реалностите на българската бизнес среда и да се постигне справедлив баланс между целите на приходната администрация и капацитета на задължените лица.
I. Прекомерна детайлизация при отчитане на фактури "ред по ред" – непосилна административна тежест и риск от изкривяване на отчетността
Идентификация на проблема:
Едно от най-обезпокоителните и практически неприложими за масовия бизнес изисквания в предложената рамка на SAF-T е задължението за детайлно описване "ред по ред" на всички фактури (покупки и продажби) в секция Source Documents/Invoice/Invoice Line. Това изисква за всеки отделен ред от оригиналната фактура да се въвеждат и подават пълни атрибути – описание, количество, мерна единица, единична цена, стойност и съответната счетоводна сметка. Това изискване е в пряко противоречие с установените счетоводни практики и възможности на микро и малките предприятия (МСП), чието счетоводство се води изнесено, и не отчита, че за голяма част от разходите и приходите такава детайлизация е напълно излишна и ненужна.
Конкретни примери за ненужна детайлизация:
Комунални услуги: На НАП не е необходима информация дали разходът за топлинна енергия на едно предприятие е формиран от компонент "топлинна енергия за подгряване на вода", "топлинна енергия за отопление" или "такса дялово разпределение". Същото важи и за компонентите на цената на електроенергията, като "дневна тарифа", "нощна тарифа", "мрежови такси" и "акциз". За целите на данъчния контрол е важна общата стойност на разхода за комунална услуга и правото на данъчен кредит, а не вътрешното ценообразуване на доставчика-монополист.
Директни разходи/приходи: Няма аналитична стойност за НАП да знае дали един административен разход е формиран от закупуването на "10 химикалки", "5 кламера" и "3 тефтера", или дали дадена консултантска услуга е разбита на редове "проведени срещи" и "изготвен доклад".
Налагането на детайлизация, диктувана от фактурата на доставчика, независимо от счетоводната практика на получателя, ще доведе до:
Многократно увеличение на времето за обработка: Счетоводителите ще бъдат принудени да "преписват" ръчно стотици хиляди редове, което е стъпка назад в дигитализацията.
Неизбежно оскъпяване на счетоводните услуги: Тази допълнителна, изключително трудоемка работа ще трябва да бъде заплатена, като тежестта ще падне върху МСП.
Повишен риск от грешки: Ръчното въвеждане на голям обем детайлни данни е предпоставка за множество технически и фактически грешки, особено в кратки срокове.
Риск от изкривяване на търговските практики: Изискването създава порочни стимули. От една страна, доставчиците могат да бъдат принудени изкуствено да детайлизират фактурите си, създавайки фиктивни продуктови кодове. От друга страна, в опит да си спестят административната тежест, много компании ще бъдат стимулирани да издават фактури с един обобщен ред "стоки/услуги по спецификация", което ще намали прозрачността на първичния документ и в крайна сметка ще затрудни, а не улесни последващия данъчен контрол.
Предложение за решение:
1. Настояваме за цялостно преосмисляне на изискването за детайлизация на ниво InvoiceLine за микро и малки предприятия. За фактури (както за покупки, така и за продажби), които се отчитат директно като разход/приход и не формират складови наличности, да се позволи в SAF-T файла да се подава един или няколко обобщени реда.
2. Информацията в тези обобщени редове да бъде съобразена с обема и вида информация, която към момента се изисква и подава чрез дневниците за покупки и продажби съгласно ЗДДС. Това ще осигури на НАП необходимата информация за данъчен контрол по ДДС, без да налага прекомерна тежест.
3. За покупки, които не формират СМЗ при купувача, НАП да разчита основно на детайлната информация от SAF-T файла на продавача. Това ще предотврати дублирането на данни и ще фокусира изискването за детайлизация там, където тя има най-голям смисъл – при източника на доставката.
II. Проблеми с консистентността на данните и дублирането на оперативна отчетност между складови и счетоводни системи при МСП
Идентификация на проблема:
Изискванията за подаване на детайлна информация за стокови наличности (PhysicalStock) и движения (MovementOfGoods) "при поискване" са проектирани така, сякаш всяко предприятие разполага със сложна, напълно интегрирана ERP система. Реалността за МСП е, че оперативната складова отчетност се води в складова програма при клиента, а счетоводната – в отделна счетоводна програма в обслужващата кантора.
Необосновано изискване за дублиране на складова отчетност: Счетоводната отчетност, съгласно своята същност и стандарти, следи стойностните изменения на материалните запаси чрез обобщени счетоводни сметки (напр. от група 30). Тя не е предназначена и не е необходимо да води детайлна оперативна складова отчетност – по количества, партиди, складови локации, специфични типове движения за всеки отделен артикул. Това е функция на специализирания складов или търговски софтуер.
Предложената схема на SAF-T обаче имплицитно предполага, че счетоводната система трябва да може да генерира или поне да борави с тази изключително детайлна складова информация, което би означавало ненужно и трудоемко дублиране на данни. Настояваме на това, че складовите наличности и движения трябва да могат се водят само в складовата/оперативната програма, а счетоводната програма да отразява само обобщените стойностни промени, каквато е реалната бизнес практика при МСП.
Несъответствие на продуктовите кодове (ProductCode): Тъй като системите са отделни, те често генерират различни и несъвпадащи ID номера за едни и същи стоки. Изискването на SAF-T за единна продуктова номенклатура в целия файл налага процес на синхронизация (съотнасяне), който при липса на интеграция е изключително трудоемък, податлив на грешки и практически невъзможен за много МСП.
Невъзможност за консолидация в краткия срок: Събирането на данни от складовата система на клиента и интегрирането им с данните от счетоводната система на кантората в единен файл е технически сложен процес, който прави спазването на 14-дневния срок за подаване "при поискване" нереалистично.
Предложение за решение:
1. НАП да признае тази практическа реалност и да разграничи ясно източниците на данни, като приеме, че детайлната оперативна информация за стоковите наличности и движения се намира само в складовия/оперативния софтуер на предприятието, а не се дублира в счетоводния.
2. Да се предвиди гъвкавост в начина на подаване на информацията за МСП с изнесено счетоводство, като се позволи подаването на данни от различни източници.
3. Клиентът да подава файл, генериран директно от неговата складова програма, съдържащ само информация за количества, единични цени, наличности.
4. Счетоводната кантора да подава основния SAF-T файл с цялата счетоводна информация (GeneralLedgerEntries, SourceDocuments с фактури, плащания, AssetTransactions и т.н.) без информация за количества, единични цени, наличности.
5. Срокът за подаване на информацията "при поискване да бъде удължен на 30-45 дни.
III. Необходимост от предварително въвеждане на задължителен електронен обмен на данни
Идентификация на проблема:
Цялата тежест по дигитализация и структуриране на данните от фактури пада върху получателя, който трябва ръчно да "преписва" информация. Освен това, от счетоводителя се очаква в процеса на осчетоводяване да проверява и въвежда допълнителна информация, която отнема много време и не е негово задължение (като статус на свързаност между доставчика и клиента или търсене на кодове по КН). Всичко това прави в пъти по-дълго времето за обработка и увеличава риска от грешки и неблагоприятни последици.
Предложение за решение:
1. Преди пълното въвеждане на SAF-T за МСП, държавата следва приоритетно да създаде рамка за задължителен електронен обмен на фактури, структурирани съгласно изискванията на SAF-T още при издаването им от доставчика.
2. Да се въведе задължение за издателя на фактурата да посочва изрично върху нея информация, която получателят трябва да подаде в своя SAF-T, а именно: Индикация "Свързано лице", ако е приложимо.
3. Кодът по Комбинираната номенклатура (ProductCommodityCode) за всяка стока или услуга, посочен на реда във фактурата. Това ще премахне нуждата счетоводителят на получателя да извършва проверки и да търси кодове, за които няма експертиза или лесен достъп до информация.
IV. Необходимост от стандартизиран електронен формат на банковите извлечения
Идентификация на проблема:
Липсата на единен стандарт за банковите извлечения налага ръчна обработка и конвертиране, което е времеемко и носи риск от грешки при отчитане на плащанията в SAF-T.
Предложение за решение:
Настояваме, преди въвеждането на SAF-T, НАП и БНБ да разработят и въведат задължителен единен електронен формат за банковите извлечения, съвместим с изискванията на SAF-T, който банките да предоставят на своите клиенти. Докато това не се въведе, изискванията за детайлизация на плащанията в SAF-T за МСП трябва да бъдат облекчени.
V. Проблеми, свързани с изискването за повторно подаване на данни, които държавата вече притежава
Идентификация на проблема:
Предложената схема на SAF-T налага на предприятията задължението да подават огромен обем информация, която вече е налична и се поддържа в актуално състояние в редица държавни публични регистри или в собствените бази данни на НАП. Това представлява неефективно дублиране на усилия и ненужна административна тежест, която е в пряко противоречие с принципите на модерното електронно управление. Конкретно визираме задължителното подаване на:
1. Идентификационни данни за подаващото предприятие (секция Header/Company): ЕИК/БУЛСТАТ, наименование на кирилица и латиница, адрес на управление, ДДС номер. Всички тези данни са официално налични в Търговския регистър и регистъра на юридическите лица с нестопанска цел (ТРРЮЛНЦ), регистър БУЛСТАТ и в регистрите на НАП.
2. Данни за собственост и действителни собственици (секция Header/Ownership): Информацията за действителните собственици на българските юридически лица вече се декларира и поддържа в ТРРЮЛНЦ съгласно Закона за мерките срещу изпирането на пари (ЗМИП).
3. Идентификационни данни за български контрагенти (MasterFiles/Customers, MasterFiles/Suppliers): Техният ЕИК/БУЛСТАТ, наименование и адрес на управление също са публично достъпни. ДДС номерата им са проверяеми от НАП.
4. Наименование на латиница (NameLatin) за български фирми: Това изискване е особено проблематично. Много български фирми нямат официално регистрирано наименование на латиница. Налагането на задължение счетоводителите да извършват транслитерация или превод е субективно, податливо на грешки и създава ненужна административна работа. Тъй като тази информация, ако съществува официално, е налична в ТРРЮЛНЦ, няма причина да се изисква повторното й подаване.
Настоящата концепция налага на бизнеса да извлича и структурира отново данни, които държавата вече притежава, вместо държавните системи да обменят тази информация помежду си по служебен път.
Предложение за решение:
1. Настояваме да се приложи на практика принципът "питай веднъж, използвай многократно" (once-only principle), който е в основата на модерното е-управление, и да отпадне задължението за подаване на информация, която НАП може да получи по служебен път.
2. За подаващото предприятие и за българските контрагенти да бъде достатъчно подаването само на техния ЕИК/БУЛСТАТ. Този уникален идентификатор трябва да служи като ключ, чрез който информационната система на НАП автоматично да извлича и свързва всички останали необходими административни и регистрационни данни от ТРРЮЛНЦ, регистър БУЛСТАТ и собствените си бази данни.
3. Категорично настояваме да отпадне задължителното изискване за подаване на NameLatin (наименование на латиница) за българските дружества и контрагенти, тъй като това е ненужно, податливо на грешки и информацията, ако е налична, е достъпна в ТРРЮЛНЦ.
Прилагането на тези предложения ще намали значително административната тежест върху бизнеса, ще намали размера на SAF-T файловете и риска от грешки при въвеждане на дублиращи се данни, и ще фокусира усилията върху подаването на действително важната транзакционна и счетоводна информация, която не е налична другаде.
VI. Проблеми, свързани с неясноти и тежест от незадължителните полета и настояване за тяхното премахване
Идентификация на проблема:
Предложената схема на SAF-T съдържа огромен брой полета, маркирани като незадължителни (О – Optional). Наличието на тези полета, макар и с незадължителен статут, създава правна несигурност и огромна практическа тежест за бизнеса и счетоводната общност. Въпреки че по закон всичко, което не е задължително, не следва да се изисква, практиката показва, че наличието на такива полета води до:
Риск от субективна преценка: Оставя се възможност на проверяващите органи по тяхна преценка да изискват попълването на "незадължителна" информация, което създава предпоставки за неравно третиране.
Напрежение за "презастраховане": В стремежа си да избегнат проблеми, предприятията и счетоводителите ще се чувстват принудени да попълват възможно най-много незадължителни полета, което на практика ги превръща в "скрито задължителни".
Усложняване и оскъпяване на софтуера: За да поддържат тези стотици незадължителни полета, разработчиците на счетоводен софтуер ще трябва да усложнят и оскъпят своите продукти. Тази тежест ще бъде прехвърлена върху крайните потребители – предприятията.
Увеличен риск от грешки: Колкото повече полета има за попълване, толкова по-голям е рискът от допускане на неволни грешки.
Създаването на сложна схема с множество незадължителни полета, които предприятията трябва да анализират и да преценяват дали да попълват, е в пряко противоречие с целта за намаляване на административната тежест. Ясната и опростена структура само със задължителни полета би била много по-ефективна.
Предложение за решение:
1. Настояваме за цялостно преразглеждане и драстично опростяване на SAF-T схемата, като от нея отпаднат всички полета, които не са от критично значение и са дефинирани като незадължителни (О – Optional). Считаме, че за целите на данъчния контрол трябва да се изисква само минималният набор от абсолютно необходима информация, която да бъде ясно дефинирана като задължителна (М) или условно задължителна (С) с недвусмислени критерии.
2. Ако НАП счита, че определена информация, която понастоящем е в незадължително поле, е важна при специфични обстоятелства, тя следва да бъде преформулирана като условно задължителна (С) с изрично и ясно дефинирани, законово обосновани условия кога нейното попълване е задължително.
3. Докато такава ревизия на схемата не бъде направена, настояваме НАП да издаде категорични и обвързващи указания, че полетата, дефинирани като незадължителни (О), действително не са задължителни за попълване и тяхното непопълване под никаква форма няма да бъде третирано като нарушение, непълнота на файла или основание за негативни констатации или санкции.
Опростяването на схемата чрез премахване на незадължителните полета ще доведе до по-голяма правна сигурност, по-малко грешки, по-опростени и по-евтини софтуерни решения и реално намаляване на административната тежест за всички задължени лица.
VII. Проблеми, свързани със срокове за подаване, дублиране на отчетност и процедури за корекции:
Тази група проблеми засяга практическото прилагане на SAF-T в контекста на съществуващата данъчна и счетоводна рамка и е от критично значение за ефективността на целия процес.
Идентификация на проблемите:
Непосилно кратък срок за месечния SAF-T: Съгласно ДОПК, срокът за подаване на месечния SAF-T файл е до 14-о число на месеца, следващ отчетния. Този срок съвпада със срока за подаване на справката-декларация по ЗДДС, но обемът и естеството на изискваната информация са несравними. Месечният SAF-T изисква не само данни за покупки и продажби, а цялостното месечно счетоводство: всички счетоводни статии от Главната книга, актуализирани основни данни със салда по всички сметки и контрагенти, всички плащания, и детайлизация ред по ред на всички фактури. Подготовката на такъв всеобхватен файл изисква приключване на абсолютно всички счетоводни операции за месеца. Концентрацията на такова огромно натоварване в първите две седмици на месеца е нереалистична и ще доведе до неизбежни грешки, породени от прибързване и преумора на счетоводителите.
Излишно дублиране на отчетност с ДДС и годишните декларации: При подаване на толкова детайлен SAF-T файл, който съдържа цялата информация от дневниците за покупки и продажби, както и пълната счетоводна информация, формираща данъчния финансов резултат, поддържането на паралелни, отделни декларации по ЗДДС и ЗКПО е напълно излишна административна тежест. Това е в пряко противоречие с прокламираната цел за намаляване на тежестта чрез дигитализация. Ако НАП получава всички данни в структуриран вид, няма логика бизнесът да ги подава повторно в различна форма.
Липса на ясна процедура за корекции: В счетоводството са неизбежни последващи корекции на операции от минали периоди. Настоящата документация не предоставя ясен механизъм как ще се коригира вече подаден месечен SAF-T файл. Тази неяснота създава правна несигурност – дали ще се подават коригиращи файлове, как ще се управляват разликите между месечните и годишния файл, и какви ще са последиците от корекциите.
Предложение за решение:
1. Настояваме срокът за подаване на месечния SAF-T файл да бъде удължен поне до края на месеца, следващ отчетния. Това ще предостави необходимото технологично време на предприятията и счетоводните кантори да обработят всички първични документи, да извършат качествено месечно приключване и да подготвят и валидират коректен и пълен SAF-T файл, без това да компрометира качеството на данните.
2. За лицата, подаващи месечен SAF-T файл, да отпадне задължението за подаване на месечна справка-декларация по ЗДДС и дневници за покупки и продажби. НАП да извлича необходимата ДДС информация директно от SAF-T.
3. За лицата, подаващи годишен SAF-T файл, да отпадне или да бъде значително опростено задължението за подаване на Годишна данъчна декларация по ЗКПО, като се подава само специфична информация, която не може да бъде извлечена от SAF-T.
4. НАП да разработи и публикува изрична и детайлна процедура за корекция на вече подадени SAF-T файлове. Тази процедура трябва да регламентира как се отразяват корекции на грешки, как се управляват разликите между месечни и годишни файлове и какви са сроковете за това, за да се осигури правна сигурност и предвидимост за задължените лица.
Само по този начин на практика ще се реализира целта за намаляване на административната тежест чрез премахване на дублиращата се отчетност, като отпаднат дублиращи се отчетни данни за подаване.
Заключение
Подчертаваме, че стандартът на ОИСР за SAF-T е рамка, а не догма, и позволява национални адаптации, които да отчитат спецификата и административния капацитет на бизнеса в съответната държава. Призоваваме НАП да се възползва от тази гъвкавост, за да намери оптималното решение за българския контекст. Въвеждането на SAF-T е възможност не само за по-добър контрол, но и за реално намаляване на общия брой декларации и отчети, които бизнесът подава, ако държавата се възползва пълноценно от потенциала на този инструмент. Кратките срокове и дублирането на отчетност биха компрометирали ползите от SAF-T и биха го превърнали в поредната административна тежест, вместо в инструмент за ефективност.
Убедени сме, че отчитането на тези предложения ще допринесе за по-гладкото и ефективно въвеждане на SAF-T в България и оставаме на разположение за въпроси обсъждания.
ОТНОСНО: Становище по проекта на нормативната уредба и техническата спецификация на Стандартен одитен файл за данъчни цели (SAF-T) в България
УВАЖАЕМА ГОСПОЖО МИНИСТЪР,
УВАЖЕМИ ГОСПОДИН СПЕЦОВ,
От името на Асоциацията на счетоводителите и счетоводните предприятия (АССП) бихме искали да изразим нашата принципна подкрепа за въвеждането на Стандартен одитен файл за данъчни цели (SAF-T) като стъпка към модернизацията на данъчния контрол и дигитализацията на отчетните процеси.
Въпреки това, детайлният анализ на предложената нормативна и техническа рамка разкрива редица съществени проблеми, които, ако не бъдат адресирани, рискуват да направят схемата практически неприложима или непропорционално натоварваща за огромна част от българския бизнес, и по-специално за микро и малките предприятия (МСП). С настоящото становище представяме нашите виждания и конструктивни предложения, целящи да адаптират изискванията на SAF-T към реалностите на българската бизнес среда и да се постигне справедлив баланс между целите на приходната администрация и капацитета на задължените лица.
I. Прекомерна детайлизация при отчитане на фактури "ред по ред" – непосилна административна тежест и риск от изкривяване на отчетността
Идентификация на проблема:
Едно от най-обезпокоителните и практически неприложими за масовия бизнес изисквания в предложената рамка на SAF-T е задължението за детайлно описване "ред по ред" на всички фактури (покупки и продажби) в секция Source Documents/Invoice/Invoice Line. Това изисква за всеки отделен ред от оригиналната фактура да се въвеждат и подават пълни атрибути – описание, количество, мерна единица, единична цена, стойност и съответната счетоводна сметка. Това изискване е в пряко противоречие с установените счетоводни практики и възможности на микро и малките предприятия (МСП), чието счетоводство се води изнесено, и не отчита, че за голяма част от разходите и приходите такава детайлизация е напълно излишна и ненужна.
Конкретни примери за ненужна детайлизация:
Комунални услуги: На НАП не е необходима информация дали разходът за топлинна енергия на едно предприятие е формиран от компонент "топлинна енергия за подгряване на вода", "топлинна енергия за отопление" или "такса дялово разпределение". Същото важи и за компонентите на цената на електроенергията, като "дневна тарифа", "нощна тарифа", "мрежови такси" и "акциз". За целите на данъчния контрол е важна общата стойност на разхода за комунална услуга и правото на данъчен кредит, а не вътрешното ценообразуване на доставчика-монополист.
Директни разходи/приходи: Няма аналитична стойност за НАП да знае дали един административен разход е формиран от закупуването на "10 химикалки", "5 кламера" и "3 тефтера", или дали дадена консултантска услуга е разбита на редове "проведени срещи" и "изготвен доклад".
Налагането на детайлизация, диктувана от фактурата на доставчика, независимо от счетоводната практика на получателя, ще доведе до:
Многократно увеличение на времето за обработка: Счетоводителите ще бъдат принудени да "преписват" ръчно стотици хиляди редове, което е стъпка назад в дигитализацията.
Неизбежно оскъпяване на счетоводните услуги: Тази допълнителна, изключително трудоемка работа ще трябва да бъде заплатена, като тежестта ще падне върху МСП.
Повишен риск от грешки: Ръчното въвеждане на голям обем детайлни данни е предпоставка за множество технически и фактически грешки, особено в кратки срокове.
Риск от изкривяване на търговските практики: Изискването създава порочни стимули. От една страна, доставчиците могат да бъдат принудени изкуствено да детайлизират фактурите си, създавайки фиктивни продуктови кодове. От друга страна, в опит да си спестят административната тежест, много компании ще бъдат стимулирани да издават фактури с един обобщен ред "стоки/услуги по спецификация", което ще намали прозрачността на първичния документ и в крайна сметка ще затрудни, а не улесни последващия данъчен контрол.
Предложение за решение:
1. Настояваме за цялостно преосмисляне на изискването за детайлизация на ниво InvoiceLine за микро и малки предприятия. За фактури (както за покупки, така и за продажби), които се отчитат директно като разход/приход и не формират складови наличности, да се позволи в SAF-T файла да се подава един или няколко обобщени реда.
2. Информацията в тези обобщени редове да бъде съобразена с обема и вида информация, която към момента се изисква и подава чрез дневниците за покупки и продажби съгласно ЗДДС. Това ще осигури на НАП необходимата информация за данъчен контрол по ДДС, без да налага прекомерна тежест.
3. За покупки, които не формират СМЗ при купувача, НАП да разчита основно на детайлната информация от SAF-T файла на продавача. Това ще предотврати дублирането на данни и ще фокусира изискването за детайлизация там, където тя има най-голям смисъл – при източника на доставката.
II. Проблеми с консистентността на данните и дублирането на оперативна отчетност между складови и счетоводни системи при МСП
Идентификация на проблема:
Изискванията за подаване на детайлна информация за стокови наличности (PhysicalStock) и движения (MovementOfGoods) "при поискване" са проектирани така, сякаш всяко предприятие разполага със сложна, напълно интегрирана ERP система. Реалността за МСП е, че оперативната складова отчетност се води в складова програма при клиента, а счетоводната – в отделна счетоводна програма в обслужващата кантора.
Необосновано изискване за дублиране на складова отчетност: Счетоводната отчетност, съгласно своята същност и стандарти, следи стойностните изменения на материалните запаси чрез обобщени счетоводни сметки (напр. от група 30). Тя не е предназначена и не е необходимо да води детайлна оперативна складова отчетност – по количества, партиди, складови локации, специфични типове движения за всеки отделен артикул. Това е функция на специализирания складов или търговски софтуер.
Предложената схема на SAF-T обаче имплицитно предполага, че счетоводната система трябва да може да генерира или поне да борави с тази изключително детайлна складова информация, което би означавало ненужно и трудоемко дублиране на данни. Настояваме на това, че складовите наличности и движения трябва да могат се водят само в складовата/оперативната програма, а счетоводната програма да отразява само обобщените стойностни промени, каквато е реалната бизнес практика при МСП.
Несъответствие на продуктовите кодове (ProductCode): Тъй като системите са отделни, те често генерират различни и несъвпадащи ID номера за едни и същи стоки. Изискването на SAF-T за единна продуктова номенклатура в целия файл налага процес на синхронизация (съотнасяне), който при липса на интеграция е изключително трудоемък, податлив на грешки и практически невъзможен за много МСП.
Невъзможност за консолидация в краткия срок: Събирането на данни от складовата система на клиента и интегрирането им с данните от счетоводната система на кантората в единен файл е технически сложен процес, който прави спазването на 14-дневния срок за подаване "при поискване" нереалистично.
Предложение за решение:
1. НАП да признае тази практическа реалност и да разграничи ясно източниците на данни, като приеме, че детайлната оперативна информация за стоковите наличности и движения се намира само в складовия/оперативния софтуер на предприятието, а не се дублира в счетоводния.
2. Да се предвиди гъвкавост в начина на подаване на информацията за МСП с изнесено счетоводство, като се позволи подаването на данни от различни източници.
3. Клиентът да подава файл, генериран директно от неговата складова програма, съдържащ само информация за количества, единични цени, наличности.
4. Счетоводната кантора да подава основния SAF-T файл с цялата счетоводна информация (GeneralLedgerEntries, SourceDocuments с фактури, плащания, AssetTransactions и т.н.) без информация за количества, единични цени, наличности.
5. Срокът за подаване на информацията "при поискване да бъде удължен на 30-45 дни.
III. Необходимост от предварително въвеждане на задължителен електронен обмен на данни
Идентификация на проблема:
Цялата тежест по дигитализация и структуриране на данните от фактури пада върху получателя, който трябва ръчно да "преписва" информация. Освен това, от счетоводителя се очаква в процеса на осчетоводяване да проверява и въвежда допълнителна информация, която отнема много време и не е негово задължение (като статус на свързаност между доставчика и клиента или търсене на кодове по КН). Всичко това прави в пъти по-дълго времето за обработка и увеличава риска от грешки и неблагоприятни последици.
Предложение за решение:
1. Преди пълното въвеждане на SAF-T за МСП, държавата следва приоритетно да създаде рамка за задължителен електронен обмен на фактури, структурирани съгласно изискванията на SAF-T още при издаването им от доставчика.
2. Да се въведе задължение за издателя на фактурата да посочва изрично върху нея информация, която получателят трябва да подаде в своя SAF-T, а именно: Индикация "Свързано лице", ако е приложимо.
3. Кодът по Комбинираната номенклатура (ProductCommodityCode) за всяка стока или услуга, посочен на реда във фактурата. Това ще премахне нуждата счетоводителят на получателя да извършва проверки и да търси кодове, за които няма експертиза или лесен достъп до информация.
IV. Необходимост от стандартизиран електронен формат на банковите извлечения
Идентификация на проблема:
Липсата на единен стандарт за банковите извлечения налага ръчна обработка и конвертиране, което е времеемко и носи риск от грешки при отчитане на плащанията в SAF-T.
Предложение за решение:
Настояваме, преди въвеждането на SAF-T, НАП и БНБ да разработят и въведат задължителен единен електронен формат за банковите извлечения, съвместим с изискванията на SAF-T, който банките да предоставят на своите клиенти. Докато това не се въведе, изискванията за детайлизация на плащанията в SAF-T за МСП трябва да бъдат облекчени.
V. Проблеми, свързани с изискването за повторно подаване на данни, които държавата вече притежава
Идентификация на проблема:
Предложената схема на SAF-T налага на предприятията задължението да подават огромен обем информация, която вече е налична и се поддържа в актуално състояние в редица държавни публични регистри или в собствените бази данни на НАП. Това представлява неефективно дублиране на усилия и ненужна административна тежест, която е в пряко противоречие с принципите на модерното електронно управление. Конкретно визираме задължителното подаване на:
1. Идентификационни данни за подаващото предприятие (секция Header/Company): ЕИК/БУЛСТАТ, наименование на кирилица и латиница, адрес на управление, ДДС номер. Всички тези данни са официално налични в Търговския регистър и регистъра на юридическите лица с нестопанска цел (ТРРЮЛНЦ), регистър БУЛСТАТ и в регистрите на НАП.
2. Данни за собственост и действителни собственици (секция Header/Ownership): Информацията за действителните собственици на българските юридически лица вече се декларира и поддържа в ТРРЮЛНЦ съгласно Закона за мерките срещу изпирането на пари (ЗМИП).
3. Идентификационни данни за български контрагенти (MasterFiles/Customers, MasterFiles/Suppliers): Техният ЕИК/БУЛСТАТ, наименование и адрес на управление също са публично достъпни. ДДС номерата им са проверяеми от НАП.
4. Наименование на латиница (NameLatin) за български фирми: Това изискване е особено проблематично. Много български фирми нямат официално регистрирано наименование на латиница. Налагането на задължение счетоводителите да извършват транслитерация или превод е субективно, податливо на грешки и създава ненужна административна работа. Тъй като тази информация, ако съществува официално, е налична в ТРРЮЛНЦ, няма причина да се изисква повторното й подаване.
Настоящата концепция налага на бизнеса да извлича и структурира отново данни, които държавата вече притежава, вместо държавните системи да обменят тази информация помежду си по служебен път.
Предложение за решение:
1. Настояваме да се приложи на практика принципът "питай веднъж, използвай многократно" (once-only principle), който е в основата на модерното е-управление, и да отпадне задължението за подаване на информация, която НАП може да получи по служебен път.
2. За подаващото предприятие и за българските контрагенти да бъде достатъчно подаването само на техния ЕИК/БУЛСТАТ. Този уникален идентификатор трябва да служи като ключ, чрез който информационната система на НАП автоматично да извлича и свързва всички останали необходими административни и регистрационни данни от ТРРЮЛНЦ, регистър БУЛСТАТ и собствените си бази данни.
3. Категорично настояваме да отпадне задължителното изискване за подаване на NameLatin (наименование на латиница) за българските дружества и контрагенти, тъй като това е ненужно, податливо на грешки и информацията, ако е налична, е достъпна в ТРРЮЛНЦ.
Прилагането на тези предложения ще намали значително административната тежест върху бизнеса, ще намали размера на SAF-T файловете и риска от грешки при въвеждане на дублиращи се данни, и ще фокусира усилията върху подаването на действително важната транзакционна и счетоводна информация, която не е налична другаде.
VI. Проблеми, свързани с неясноти и тежест от незадължителните полета и настояване за тяхното премахване
Идентификация на проблема:
Предложената схема на SAF-T съдържа огромен брой полета, маркирани като незадължителни (О – Optional). Наличието на тези полета, макар и с незадължителен статут, създава правна несигурност и огромна практическа тежест за бизнеса и счетоводната общност. Въпреки че по закон всичко, което не е задължително, не следва да се изисква, практиката показва, че наличието на такива полета води до:
Риск от субективна преценка: Оставя се възможност на проверяващите органи по тяхна преценка да изискват попълването на "незадължителна" информация, което създава предпоставки за неравно третиране.
Напрежение за "презастраховане": В стремежа си да избегнат проблеми, предприятията и счетоводителите ще се чувстват принудени да попълват възможно най-много незадължителни полета, което на практика ги превръща в "скрито задължителни".
Усложняване и оскъпяване на софтуера: За да поддържат тези стотици незадължителни полета, разработчиците на счетоводен софтуер ще трябва да усложнят и оскъпят своите продукти. Тази тежест ще бъде прехвърлена върху крайните потребители – предприятията.
Увеличен риск от грешки: Колкото повече полета има за попълване, толкова по-голям е рискът от допускане на неволни грешки.
Създаването на сложна схема с множество незадължителни полета, които предприятията трябва да анализират и да преценяват дали да попълват, е в пряко противоречие с целта за намаляване на административната тежест. Ясната и опростена структура само със задължителни полета би била много по-ефективна.
Предложение за решение:
1. Настояваме за цялостно преразглеждане и драстично опростяване на SAF-T схемата, като от нея отпаднат всички полета, които не са от критично значение и са дефинирани като незадължителни (О – Optional). Считаме, че за целите на данъчния контрол трябва да се изисква само минималният набор от абсолютно необходима информация, която да бъде ясно дефинирана като задължителна (М) или условно задължителна (С) с недвусмислени критерии.
2. Ако НАП счита, че определена информация, която понастоящем е в незадължително поле, е важна при специфични обстоятелства, тя следва да бъде преформулирана като условно задължителна (С) с изрично и ясно дефинирани, законово обосновани условия кога нейното попълване е задължително.
3. Докато такава ревизия на схемата не бъде направена, настояваме НАП да издаде категорични и обвързващи указания, че полетата, дефинирани като незадължителни (О), действително не са задължителни за попълване и тяхното непопълване под никаква форма няма да бъде третирано като нарушение, непълнота на файла или основание за негативни констатации или санкции.
Опростяването на схемата чрез премахване на незадължителните полета ще доведе до по-голяма правна сигурност, по-малко грешки, по-опростени и по-евтини софтуерни решения и реално намаляване на административната тежест за всички задължени лица.
VII. Проблеми, свързани със срокове за подаване, дублиране на отчетност и процедури за корекции:
Тази група проблеми засяга практическото прилагане на SAF-T в контекста на съществуващата данъчна и счетоводна рамка и е от критично значение за ефективността на целия процес.
Идентификация на проблемите:
Непосилно кратък срок за месечния SAF-T: Съгласно ДОПК, срокът за подаване на месечния SAF-T файл е до 14-о число на месеца, следващ отчетния. Този срок съвпада със срока за подаване на справката-декларация по ЗДДС, но обемът и естеството на изискваната информация са несравними. Месечният SAF-T изисква не само данни за покупки и продажби, а цялостното месечно счетоводство: всички счетоводни статии от Главната книга, актуализирани основни данни със салда по всички сметки и контрагенти, всички плащания, и детайлизация ред по ред на всички фактури. Подготовката на такъв всеобхватен файл изисква приключване на абсолютно всички счетоводни операции за месеца. Концентрацията на такова огромно натоварване в първите две седмици на месеца е нереалистична и ще доведе до неизбежни грешки, породени от прибързване и преумора на счетоводителите.
Излишно дублиране на отчетност с ДДС и годишните декларации: При подаване на толкова детайлен SAF-T файл, който съдържа цялата информация от дневниците за покупки и продажби, както и пълната счетоводна информация, формираща данъчния финансов резултат, поддържането на паралелни, отделни декларации по ЗДДС и ЗКПО е напълно излишна административна тежест. Това е в пряко противоречие с прокламираната цел за намаляване на тежестта чрез дигитализация. Ако НАП получава всички данни в структуриран вид, няма логика бизнесът да ги подава повторно в различна форма.
Липса на ясна процедура за корекции: В счетоводството са неизбежни последващи корекции на операции от минали периоди. Настоящата документация не предоставя ясен механизъм как ще се коригира вече подаден месечен SAF-T файл. Тази неяснота създава правна несигурност – дали ще се подават коригиращи файлове, как ще се управляват разликите между месечните и годишния файл, и какви ще са последиците от корекциите.
Предложение за решение:
1. Настояваме срокът за подаване на месечния SAF-T файл да бъде удължен поне до края на месеца, следващ отчетния. Това ще предостави необходимото технологично време на предприятията и счетоводните кантори да обработят всички първични документи, да извършат качествено месечно приключване и да подготвят и валидират коректен и пълен SAF-T файл, без това да компрометира качеството на данните.
2. За лицата, подаващи месечен SAF-T файл, да отпадне задължението за подаване на месечна справка-декларация по ЗДДС и дневници за покупки и продажби. НАП да извлича необходимата ДДС информация директно от SAF-T.
3. За лицата, подаващи годишен SAF-T файл, да отпадне или да бъде значително опростено задължението за подаване на Годишна данъчна декларация по ЗКПО, като се подава само специфична информация, която не може да бъде извлечена от SAF-T.
4. НАП да разработи и публикува изрична и детайлна процедура за корекция на вече подадени SAF-T файлове. Тази процедура трябва да регламентира как се отразяват корекции на грешки, как се управляват разликите между месечни и годишни файлове и какви са сроковете за това, за да се осигури правна сигурност и предвидимост за задължените лица.
Само по този начин на практика ще се реализира целта за намаляване на административната тежест чрез премахване на дублиращата се отчетност, като отпаднат дублиращи се отчетни данни за подаване.
Заключение
Подчертаваме, че стандартът на ОИСР за SAF-T е рамка, а не догма, и позволява национални адаптации, които да отчитат спецификата и административния капацитет на бизнеса в съответната държава. Призоваваме НАП да се възползва от тази гъвкавост, за да намери оптималното решение за българския контекст. Въвеждането на SAF-T е възможност не само за по-добър контрол, но и за реално намаляване на общия брой декларации и отчети, които бизнесът подава, ако държавата се възползва пълноценно от потенциала на този инструмент. Кратките срокове и дублирането на отчетност биха компрометирали ползите от SAF-T и биха го превърнали в поредната административна тежест, вместо в инструмент за ефективност.
Убедени сме, че отчитането на тези предложения ще допринесе за по-гладкото и ефективно въвеждане на SAF-T в България и оставаме на разположение за въпроси обсъждания.
5
Освен регулярно подаваните месечни и годишни SAF-T файлове, които разгледахме във втората част на нашата поредица "Разбери SAF-Т", НАП ще може да изисква предоставянето на одитен файл "при поискване", който е обект на анализ в настоящата трета част. Срокът за предоставяне на такъв файл е 14 дни от получаване на искането от НАП, което налага отлична подготовка и бърза реакция. Въпреки, че за много от предприятията сроковете за влизане в сила на задължението са напред във времето (от 2026 г. за големи предприятия до 2030 г. за микропредприятия), е особено важно да се предвиди от сега необходимостта от нов софтуер или актуализация на съществуващия, особено за предприятията, извършващи търговия със стоки, както и за счетоводителите, които ги обслужват, тъй като данните, изисквани в този сценарий, са специфични и изключително детайлни.
Кои секции и данни се подават основно в SAF-T файла „при поискване“?
Въз основа на предложения проект на документация на НАП (XSD схема, Приложение 2 и Приложение 3), следните секции са ключови при подаване на SAF-T "при поискване":
1. MasterFiles / PhysicalStock (Наличности на стоково-материални запаси / Физически наличности)
Тази секция, макар и дефинирана като опционална (О) в общата структура, става задължителна за подаване в 14-дневен срок при изрично поискване от НАП. Тя изисква детайлна информация за всяка стокова наличност към конкретна дата (моментна снимка) или начални/крайни салда за период.
» WarehouseID (Задължително, Идентификатор на склада)
» ProductCode (Задължително, Код на продукта/материалния запас)
» ProductType (Задължително, Вид на продукта/материалния запас, от Nom_Inventory_Types)
» StockAccountCommodityCod e (Задължително, Код от Комбинираната номенклатура NC8_TARIC)
» OwnerID (Задължително, ЕИК на собственика на стоката)
» UOMPhysicalStock (Задължително, Мерна единица на наличността)
» UOMToUOMBaseConversionFa ctor (Задължително, Коефициент на преобразуване към основната мерна единица)
» UnitPrice (Задължително, Единична цена на стоката в наличност)
» OpeningStockQuantity (Задължително, Начално количество за периода)
» OpeningStockValue (Задължително, Начална стойност за периода)
» ClosingStockQuantity (Задължително, Крайно количество за периода)
» ClosingStockValue (Задължително, Крайна стойност за периода)
Други полета като LocationID (Локация в склада), StockAccountNo (Партиден/сериен номер), ProductStatus (Статус на продукта), StockCharacteristics (Характеристики на стоката) са незадължителни.
2. SourceDocuments / MovementOfGoods (Движение на стоки / Стокови потоци)
Тази секция също се подава при поискване от НАП в 14-дневен срок и отразява всички движения на СМЗ.
» На ниво MovementOfGoods (общо за всички движения):
» NumberOfMovementLines (Задължително, Общ брой редове от всички документи за движение)
» TotalQuantityReceived (Незадължително, Общо получено количество)
» TotalQuantityIssued (Незадължително, Общо издадено количество)
» На ниво StockMovement (Задължително, за всеки документ/операция по движение):
» MovementReference (Задължително, Уникален ID на документа за движение)
» MovementDate (Задължително, Дата на документа)
» MovementType (Задължително, Вид на движението от номенклатура Stock movement)
» DocumentReference (Задължително):
» DocumentType (Задължително, Вид на свързания документ)
» DocumentNumber (Задължително, Номер на свързания документ)
» Други полета като MovementPostingDate, MovementPostingTime, TaxPointDate, SourceID, SystemID, DocumentReference/DocumentLine са Незадължителни.
» На ниво StockMovementLine (Задължително, за всеки артикул в документа за движение):
» LineNumber (Задължително, Номер на реда)
» ProductCode (Задължително, Код на продукта)
» Quantity (Задължително, Количество)
» UnitOfMeasure (Задължително, Мерна единица от документа)
» UOMToUOMPhysicalStockCon versionFactor (Задължително, Коефициент на преобразуване към мерната единица на физическия запас)
» MovementSubType (Задължително, Подвид на движението от номенклатура Stock movement)
» AccountID (Условно задължително, Счетоводна сметка, свързана с движението)
» TransactionID (Условно задължително, Връзка към счетоводна статия)
» Други полета като StockAccountNo, CustomerID, SupplierID, ShipTo, ShipFrom, BookValue, MovementComments, TaxInformation са Незадължителни или Условно задължителни.
3. SourceDocuments / AssetTransactions (Транзакции с активи)
Тази секция също се подава в 14-дневен срок при поискване от НАП и детайлизира операциите с дълготрайни активи.
» NumberOfAssetTransaction s (Задължително, Брой транзакции с активи).
» На ниво AssetTransaction (Задължително, за всяка транзакция с актив):
» AssetTransactionID (Задължително, Уникален ID на транзакцията)
» AssetID (Задължително, ID на актива от MasterFiles/Assets)
» AssetTransactionType (Задължително, Код на типа транзакция от AssetMovementTypes)
» AssetTransactionDate (Задължително, Дата на транзакцията)
» TransactionID (Задължително, Връзка към счетоводна статия)
» AssetTransactionValuatio ns (Задължително):
» AssetTransactionValuatio n (Задължително, поне един запис):
» BookValueOnTransaction (Задължително, Балансова стойност след транзакцията)
» AssetTransactionAmount (Задължително, Стойност на самата транзакция)
» Други полета като Description, AssetSupplier, AssetTransactionValuatio n/AssetValuationType, AssetTransactionValuatio n/AcquisitionAndProductionCostsOnTransaction са незадължителни.
Предизвикателства при подготовката на данни "при поискване" – какво трябва да предвидят счетоводителите и бизнесът?
Информацията за PhysicalStock и MovementOfGoods е изключително детайлна, трябва да се поддържа в реално време и обикновено се поддържа в складовия софтуер на предприятието или в модул "Склад" на ERP системата, а не директно в счетоводната програма, използвана от много счетоводни кантори, особено когато става въпрос за изнесено счетоводство.
Много микро и малки предприятия използват базови складови програми или специфичен за дейността им софтуер (напр. за производство, включително чуждестранни системи), който може да не е предвиден за експорт на данни в толкова детайлен и структуриран вид, съвместим с изискванията на SAF-T и националните номенклатури (за типове движения, мерни единици и др.). Адаптацията на такива системи може да е технически сложна, скъпа или дори невъзможна. На практика, изискванията към тези секции предполагат наличието на развита ERP система, която да може да генерира тези данни автоматично и консистентно. Това обаче не отговаря на реалността за малките предприятия в България.
Ключов проблем възниква, ако продуктовите кодове (ProductCode) и описания в складовата система на клиента се различават от тези, използвани в счетоводния софтуер на кантората (където се отразяват фактурите за покупки/продажби и се дефинира MasterFiles/Products). SAF-T изисква единна продуктова номенклатура в целия файл. Това налага или поддържането на синхронизирани номенклатури между двете системи (при клиента и в кантората), или сложен процес на съотнасяне (mapping) преди генерирането на SAF-T, което е изключително трудоемко, податливо на грешки и практически невъзможно.
Друг потенциален казус с файла при поискване
НАП изисква "при поискване" едновременно:
Заключение
Анализът на изискванията за секциите PhysicalStock (Наличности на СМЗ) и MovementOfGoods (Движение на стоки) разкрива една съществена импликация: структурата и детайлността на тези данни са предвидени така, сякаш се очаква всяко предприятие (микро, малко или голямо), търгуващо със стоки и материали, да оперира със сложна, напълно интегрирана ERP система. Такива системи обикновено обединяват в единна база данни оперативната складова отчетност (с всички детайли за партиди, локации, специфични типове движения), счетоводния модул и модула за дълготрайни активи, позволявайки автоматичното генериране на консистентна и свързана информация. Реалността за преобладаващата част от микро и малките предприятия в България обаче е различна – те често използват отделни, по-опростени счетоводни програми (често при изнесено счетоводство) и базови складови или търговски софтуери, които не са интегрирани помежду си и не поддържат необходимото ниво на детайлизация и съвместимост с изискваните от SAF-T номенклатури и структури без значителни и скъпи доработки.
Кои секции и данни се подават основно в SAF-T файла „при поискване“?
Въз основа на предложения проект на документация на НАП (XSD схема, Приложение 2 и Приложение 3), следните секции са ключови при подаване на SAF-T "при поискване":
1. MasterFiles / PhysicalStock (Наличности на стоково-материални запаси / Физически наличности)
Тази секция, макар и дефинирана като опционална (О) в общата структура, става задължителна за подаване в 14-дневен срок при изрично поискване от НАП. Тя изисква детайлна информация за всяка стокова наличност към конкретна дата (моментна снимка) или начални/крайни салда за период.
» WarehouseID (Задължително, Идентификатор на склада)
» ProductCode (Задължително, Код на продукта/материалния запас)
» ProductType (Задължително, Вид на продукта/материалния запас, от Nom_Inventory_Types)
» StockAccountCommodityCod e (Задължително, Код от Комбинираната номенклатура NC8_TARIC)
» OwnerID (Задължително, ЕИК на собственика на стоката)
» UOMPhysicalStock (Задължително, Мерна единица на наличността)
» UOMToUOMBaseConversionFa ctor (Задължително, Коефициент на преобразуване към основната мерна единица)
» UnitPrice (Задължително, Единична цена на стоката в наличност)
» OpeningStockQuantity (Задължително, Начално количество за периода)
» OpeningStockValue (Задължително, Начална стойност за периода)
» ClosingStockQuantity (Задължително, Крайно количество за периода)
» ClosingStockValue (Задължително, Крайна стойност за периода)
Други полета като LocationID (Локация в склада), StockAccountNo (Партиден/сериен номер), ProductStatus (Статус на продукта), StockCharacteristics (Характеристики на стоката) са незадължителни.
2. SourceDocuments / MovementOfGoods (Движение на стоки / Стокови потоци)
Тази секция също се подава при поискване от НАП в 14-дневен срок и отразява всички движения на СМЗ.
» На ниво MovementOfGoods (общо за всички движения):
» NumberOfMovementLines (Задължително, Общ брой редове от всички документи за движение)
» TotalQuantityReceived (Незадължително, Общо получено количество)
» TotalQuantityIssued (Незадължително, Общо издадено количество)
» На ниво StockMovement (Задължително, за всеки документ/операция по движение):
» MovementReference (Задължително, Уникален ID на документа за движение)
» MovementDate (Задължително, Дата на документа)
» MovementType (Задължително, Вид на движението от номенклатура Stock movement)
» DocumentReference (Задължително):
» DocumentType (Задължително, Вид на свързания документ)
» DocumentNumber (Задължително, Номер на свързания документ)
» Други полета като MovementPostingDate, MovementPostingTime, TaxPointDate, SourceID, SystemID, DocumentReference/DocumentLine са Незадължителни.
» На ниво StockMovementLine (Задължително, за всеки артикул в документа за движение):
» LineNumber (Задължително, Номер на реда)
» ProductCode (Задължително, Код на продукта)
» Quantity (Задължително, Количество)
» UnitOfMeasure (Задължително, Мерна единица от документа)
» UOMToUOMPhysicalStockCon versionFactor (Задължително, Коефициент на преобразуване към мерната единица на физическия запас)
» MovementSubType (Задължително, Подвид на движението от номенклатура Stock movement)
» AccountID (Условно задължително, Счетоводна сметка, свързана с движението)
» TransactionID (Условно задължително, Връзка към счетоводна статия)
» Други полета като StockAccountNo, CustomerID, SupplierID, ShipTo, ShipFrom, BookValue, MovementComments, TaxInformation са Незадължителни или Условно задължителни.
3. SourceDocuments / AssetTransactions (Транзакции с активи)
Тази секция също се подава в 14-дневен срок при поискване от НАП и детайлизира операциите с дълготрайни активи.
» NumberOfAssetTransaction s (Задължително, Брой транзакции с активи).
» На ниво AssetTransaction (Задължително, за всяка транзакция с актив):
» AssetTransactionID (Задължително, Уникален ID на транзакцията)
» AssetID (Задължително, ID на актива от MasterFiles/Assets)
» AssetTransactionType (Задължително, Код на типа транзакция от AssetMovementTypes)
» AssetTransactionDate (Задължително, Дата на транзакцията)
» TransactionID (Задължително, Връзка към счетоводна статия)
» AssetTransactionValuatio ns (Задължително):
» AssetTransactionValuatio n (Задължително, поне един запис):
» BookValueOnTransaction (Задължително, Балансова стойност след транзакцията)
» AssetTransactionAmount (Задължително, Стойност на самата транзакция)
» Други полета като Description, AssetSupplier, AssetTransactionValuatio n/AssetValuationType, AssetTransactionValuatio n/AcquisitionAndProductionCostsOnTransaction са незадължителни.
Предизвикателства при подготовката на данни "при поискване" – какво трябва да предвидят счетоводителите и бизнесът?
Информацията за PhysicalStock и MovementOfGoods е изключително детайлна, трябва да се поддържа в реално време и обикновено се поддържа в складовия софтуер на предприятието или в модул "Склад" на ERP системата, а не директно в счетоводната програма, използвана от много счетоводни кантори, особено когато става въпрос за изнесено счетоводство.
Много микро и малки предприятия използват базови складови програми или специфичен за дейността им софтуер (напр. за производство, включително чуждестранни системи), който може да не е предвиден за експорт на данни в толкова детайлен и структуриран вид, съвместим с изискванията на SAF-T и националните номенклатури (за типове движения, мерни единици и др.). Адаптацията на такива системи може да е технически сложна, скъпа или дори невъзможна. На практика, изискванията към тези секции предполагат наличието на развита ERP система, която да може да генерира тези данни автоматично и консистентно. Това обаче не отговаря на реалността за малките предприятия в България.
Ключов проблем възниква, ако продуктовите кодове (ProductCode) и описания в складовата система на клиента се различават от тези, използвани в счетоводния софтуер на кантората (където се отразяват фактурите за покупки/продажби и се дефинира MasterFiles/Products). SAF-T изисква единна продуктова номенклатура в целия файл. Това налага или поддържането на синхронизирани номенклатури между двете системи (при клиента и в кантората), или сложен процес на съотнасяне (mapping) преди генерирането на SAF-T, което е изключително трудоемко, податливо на грешки и практически невъзможно.
Друг потенциален казус с файла при поискване
НАП изисква "при поискване" едновременно:
- Данни за движение и наличности на стоки (SourceDocuments/MovementOfGoods и MasterFiles/PhysicalStock). Тази информация се намира в складовата програма в магазина на фирмата.
- Данни за транзакции с активи (SourceDocuments/AssetTransactions), които данни се водят в счетоводната програма в счетоводната кантора.
Заключение
Анализът на изискванията за секциите PhysicalStock (Наличности на СМЗ) и MovementOfGoods (Движение на стоки) разкрива една съществена импликация: структурата и детайлността на тези данни са предвидени така, сякаш се очаква всяко предприятие (микро, малко или голямо), търгуващо със стоки и материали, да оперира със сложна, напълно интегрирана ERP система. Такива системи обикновено обединяват в единна база данни оперативната складова отчетност (с всички детайли за партиди, локации, специфични типове движения), счетоводния модул и модула за дълготрайни активи, позволявайки автоматичното генериране на консистентна и свързана информация. Реалността за преобладаващата част от микро и малките предприятия в България обаче е различна – те често използват отделни, по-опростени счетоводни програми (често при изнесено счетоводство) и базови складови или търговски софтуери, които не са интегрирани помежду си и не поддържат необходимото ниво на детайлизация и съвместимост с изискваните от SAF-T номенклатури и структури без значителни и скъпи доработки.
6
В първата част на нашата поредица "Разбери SAF-T" разгледахме детайлните изисквания за отразяване на фактурите в Стандартния одитен файл за данъчни цели (SAF-T) и по-специално за въвеждането на задължението за детайлното отразяване "ред по ред" на всички фактури за покупки в счетоводните системи, включително с техните единични цени, мерни единици, количества и счетоводна сметка на всеки ред. Сега ще насочим вниманието си към останалите компоненти на месечния SAF-T файл, за да добием пълна представа за обема и естеството на информацията, която НАП ще изисква от предприятията. Важно е да се подчертае, че месечният SAF-T файл, който ще се подава до 14-о число на следващия месец, е значително по-обхватен от познатата ни месечна справка-декларация по ЗДДС.
Отвъд покупките и продажбите: Ядрото на месечния SAF-T
Месечният SAF-T файл не се изчерпва само с детайлното представяне на фактурите за покупки (PurchaseInvoices) и продажби (SalesInvoices). Той изисква предоставянето на цялостна картина на счетоводната отчетност и основните данни на предприятието за отчетния месец. Въз основа на анализа на публикуваните проектни документи на страницата на НАП, във връзка с обществените консултации за проект на заповед, с която се определят редът и формата за подаване на SAF-T, представяме резюме на това какво ще се изисква да се подава в месечния SAF-T файл, освен детайлната информация за фактурите за покупки и продажби.
Нека разгледаме ключовите секции:
1. Header (Главна страница / Обща информация за файла)
Тази секция е задължителна за всеки SAF-T файл и включва идентификационни данни за подаващия файл (версия, дата на създаване, софтуер), основна валута, критерии за избор на данните (за кой период се отнасят) и коментар, указващ, че файлът е "Monthly", както и идентификационни данни за подаващото предприятие (Company). Освен стандартната информация, впечатление прави изискването за задължително подаване на следните специфични данни за подаващото предприятие:
» RelatedParty (Задължително): Индикатор дали предприятието е свързано лице (Y/N).
» RelatedPartyStartDate и RelatedPartyEndDate (Условно задължителни, ако RelatedParty е "Y").
» Данни за собственост (Ownership - Задължително): Тази структура изисква детайлна информация за:
» IsPartOfGroup (Задължително): Дали компанията е част от група.
» Действителните собственици (физически лица – български и чуждестранни, с имена, ЕГН/идентификатори, гражданство, държава на пребиваване – всички тези полета са задължителни в рамките на структурата).
» Крайно предприятие майка (ако има такова – българско или чуждестранно, с наименования, ЕИК/идентификатори, държава на регистрация – тези полета също са задължителни в структурата, ако са приложими).
2. MasterFiles (Основни данни)
Въпреки че някои основни данни може да не се променят всеки месец, месечният SAF-T файл трябва да съдържа актуална информация или поне информация, която е релевантна за транзакциите през месеца. Ключови подсекции тук са:
GeneralLedgerAccounts (Сметкоплан - Задължително):
Задължително се подават всички счетоводни сметки от индивидуалния сметкоплан, картографирани към националния сметкоплан на НАП. За всяка сметка се посочват начални салда за отчетния месец, обороти (дебитни и кредитни) за месеца и крайни салда към края на месеца. Това е съществена част от месечното отчитане.
Customers (Клиенти) и Suppliers (Доставчици):
Задължително се подава информация за всички клиенти и доставчици, с които е имало транзакции или които имат салда през отчетния месец. За всеки контрагент се посочват идентификационни данни (ЕИК/ДДС номер, име, адрес), свързаната счетоводна сметка за разчети, начални и крайни салда по партидата на контрагента за отчетния месец, както и дали клиентът/доставчикът е свързано лице.
TaxTable (Данъчна таблица):
Задължително се подава информация за използваните данъчни кодове и техните ставки, които са били приложими за транзакциите през месеца.
UOMTable (Таблица с мерни единици):
Задължително се подават мерните единици, използвани в транзакциите през месеца.
Products (Продукти/Услуги):
Информация за продуктите/услугите, които са били обект на покупка или продажба през месеца. Това включва техните кодове, описания, кодове по КН (ProductCommodityCode).
AnalysisTypeTable (Таблица с аналитичности): Незадължително.
MovementTypeTable (Таблица за типове движения на СМЗ):
Ако има движения на СМЗ, които се отчитат месечно (макар самата секция MovementOfGoods да е при поискване, дефинициите може да се изискват, ако има такива движения в счетоводните записвания (GL)). Това трябва да се уточни от НАП.
3. GeneralLedgerEntries (Счетоводни записвания / Главна книга)
Това е ключова и задължителна част от месечния SAF-T файл. Изисква се подаването на абсолютно всички счетоводни статии (транзакции), осчетоводени през отчетния месец. Това включва:
» Осчетоводявания на фактури за покупки и продажби.
» Осчетоводявания на банкови движения и касови операции.
» Начисляване на заплати и осигуровки.
» Начисляване на амортизации.
» Начисляване на данъци.
» Начисляване на провизии.
» Отписвания, прихващания, валутни преоценки.
» Сторнировъчни операции.
» Всички други счетоводни операции, отразени в Главната книга за месеца.
За всяка счетоводна операция се подават дата на документа/транзакцията (TransactionDate), дата на системно въвеждане (SystemEntryDate), дата на осчетоводяване (GLPostingDate), описания, както и всички дебитни и кредитни счетоводни записвания (TransactionLine) с посочване на сметка, сума, описание, евентуални аналитичности и връзка към първичен документ.
4. SourceDocuments (Първични документи)
PurchaseInvoices (Фактури за покупки): Задължително се подават всички получени фактури за покупки през месеца, с детайлизация ред по ред, за което стана въпрос в първата част на SAF-Т анализа.
SalesInvoices (Фактури за продажби): Задължително се подават всички издадени фактури за продажби през месеца, с детайлизация ред по ред.
Payments (Плащания): Задължително се подава информация за извършените и получените плащания през месеца, с детайли за всяко плащане и връзката му със счетоводните записвания и евентуално с платени документи.
Секции, които не се очаква да се подават стандартно с месечния SAF-T (а са годишни или при поискване):
» MasterFiles / Assets (Дълготрайни активи с пълните САП и ДАП) – това е годишно.
» MasterFiles / PhysicalStock (Наличности на стоково-материални запаси) – това е при поискване.
» SourceDocuments / MovementOfGoods (Движение на стоки) – това е при поискване.
» SourceDocuments / AssetTransactions (Транзакции с активи) – това е при поискване.
» CorrespondingAccountsRep ort (Справка за кореспондиращи сметки) – това е опционално.
Разлика спрямо месечната ДДС декларация
В обобщение, месечният SAF-T файл е много повече от просто дневници за покупки и продажби. Обхватът му значително надхвърля информацията, подавана с месечната справка-декларация по ЗДДС и дневниците за покупки и продажби. Докато ДДС декларацията се фокусира основно върху покупките и продажбите, SAF-T изисква:
» Цялата Главна книга: Всички счетоводни операции, а не само тези от ДДС дневниците.
» Пълен сметкоплан със салда и обороти.
» Актуални основни данни с месечни салда по сметки и партиди на контрагенти, както и използвани номенклатури (сметкоплан, данъчни кодове, мерни единици, продукти/услуги).
» Детайлна информация за всички фактури за покупки и продажби за месеца.
» Детайлна информация за всички плащания за месеца.
» Информация за собственост и свързаност на подателя.
Годишен SAF-T файл
Освен месечен SAF-T файл, задължените лица трябва да подават и годишен такъв. Срокът за подаване на годишния SAF-Т е едновременно с подаването на годишната данъчна декларация по ЗКПО, която се подава до 30 юни на следващата година.
Годишния SAF-Т файл включва всички счетоводни статии за цялата отчетна година, включително годишните приключвателни операции (напр. приключване на приходни и разходни сметки, формиране на финансов резултат, начисляване на корпоративен данък за годината). Тези приключвателни операции обикновено не са част от месечните файлове (освен може би за декември, ако там се правят част от тях). Файлът включва отново всички издадени фактури, получени фактури и извършени плащания за цялата година. Годишният файл включва отново и сметкоплан с начални салда към началото на годината и крайни салда към края на годината (след всички приключвания), както и информация за всички контрагенти, с които е имало взаимоотношения през годината, с годишни начални и крайни салда по партидите им. Структурата на годишния SAF-T файл е аналогична на тази на месечния, но обхваща цялата финансова година.
Нова специфична информация, която се подава само в годишния SAF-T файл
MasterFiles/Assets (Дълготрайни активи):
Това е ключовата секция, която се подава детайлно на годишна база. Включва пълна информация за всеки дълготраен актив: идентификация, доставчик, дата на придобиване/въвеждане в експлоатация. Най-важното: Valuations с детайлен ValuationSAP (Счетоводен амортизационен план за годината) и ValuationDAP (Данъчен амортизационен план за годината). Тази детайлна информация за амортизационните планове, стойности, амортизации за периода, натрупани амортизации и т.н. се финализира и обобщава на годишна база.
SAF-Т и данни при поискване от НАП – кратък преглед
НАП може да изиска информация за следните данни за:
» MasterFiles/PhysicalStock (Наличности на стоково-материални запаси).
» SourceDocuments/MovementOfGoods (Движение на стоки).
» SourceDocuments/AssetTransactions (Транзакции с активи).
Срокът за подаване на тези данни е 14-дневен от датата на поискването от НАП. В настоящата статия само маркираме най-общо какви данни задължените лица ще трябва да предоставят на НАП при поискване, а в отделен материал сме разгледали детайлите на данните при поискване.
Поетапно въвеждане на SAF-T в България: Кой кога стартира по-подробно?
В своята страница НАП посочи, че започва внедряването на SAF-T, като в периода юли-декември 2025 г. се предвижда пилотно тестване. Съгласно разпоредбите на ДОПК задължението за подаване на SAF-T ще се въвежда поетапно, а графикът е следният:
От 1 януари 2026 г.: За големи предприятия (към 31.12.2023 г.), ако отговарят на поне едно от условията: нетни приходи от продажби за 2023 г. над 300 млн. лв. или през 2023 г. постъпленията по сметки на НАП от данъци и осигурителни вноски, намалени с възстановените суми за данъци и осигурителни вноски, са над 3 500 000 лв.
От 1 януари 2027 г.: За големи, средни или малки предприятия (към 31.12.2024 г.), ако отговарят на поне едно от условията: нетни приходи от продажби за 2024 г. над 300 млн. лв. или през 2024 г. постъпленията по сметки на НАП от данъци и осигурителни вноски, намалени с възстановените суми за данъци и осигурителни вноски, са над 3 500 000 лв.
От 1 януари 2028 г.: За големи, средни или малки предприятия (към 31.12.2025 г.), ако отговарят на поне едно от условията: нетни приходи от продажби за 2025 г. над 15 млн. лв. или през 2025 г. постъпленията по сметки на НАП от данъци и осигурителни вноски, намалени с възстановените суми за данъци и осигурителни вноски, са над 1 500 000 лв.
От 1 януари 2029 г.: За предприятията, които към 31.12.2026 г. са големи, средни или малки предприятия (без допълнителните финансови прагове от предходните групи).
От 1 януари 2030 г.: За всички останали задължени лица, непосочени по-горе, които са регистрирани по ЗДДС предприятия. В тази група се включват и микропредприятията, регистрирани по ЗДДС.
Изключени от отчитането по SAF-Т са микропредприятия, които не са регистрирани по ЗДДС, местните юридически лица, които не са търговци, бюджетните предприятия, фондовете за извършване на плащания и осигурителните каси, както и търговските представителства.
Поетапният подход за въвеждане на SAF-Т, обвързан с категорията на предприятието и специфични финансови прагове за първите групи, цели по-плавен преход към новия режим. Въпреки това, всички предприятия, които ще попаднат в обхвата на SAF-T, следва да започнат своята подготовка отрано, тъй като SAF-Т е изключително обемен и детайлен отчет, който изисква приключване на голяма част от месечното счетоводство преди да може да бъде генериран и подаден. Подготовката за подаване ще изисква сериозна реорганизация на работните процеси, надежден и адаптиран счетоводен софтуер, както и отлично познаване на изискванията и номенклатурите на НАП. Въпреки поетапното въвеждане, своевременната подготовка е от ключово значение.
Следва трета част от поредицата "Разбери SAF-Т":
SAF-T файл при поискване от НАП в 14-дневен срок: Какво трябва да знаят търговците и техните счетоводители?
Отвъд покупките и продажбите: Ядрото на месечния SAF-T
Месечният SAF-T файл не се изчерпва само с детайлното представяне на фактурите за покупки (PurchaseInvoices) и продажби (SalesInvoices). Той изисква предоставянето на цялостна картина на счетоводната отчетност и основните данни на предприятието за отчетния месец. Въз основа на анализа на публикуваните проектни документи на страницата на НАП, във връзка с обществените консултации за проект на заповед, с която се определят редът и формата за подаване на SAF-T, представяме резюме на това какво ще се изисква да се подава в месечния SAF-T файл, освен детайлната информация за фактурите за покупки и продажби.
Нека разгледаме ключовите секции:
1. Header (Главна страница / Обща информация за файла)
Тази секция е задължителна за всеки SAF-T файл и включва идентификационни данни за подаващия файл (версия, дата на създаване, софтуер), основна валута, критерии за избор на данните (за кой период се отнасят) и коментар, указващ, че файлът е "Monthly", както и идентификационни данни за подаващото предприятие (Company). Освен стандартната информация, впечатление прави изискването за задължително подаване на следните специфични данни за подаващото предприятие:
» RelatedParty (Задължително): Индикатор дали предприятието е свързано лице (Y/N).
» RelatedPartyStartDate и RelatedPartyEndDate (Условно задължителни, ако RelatedParty е "Y").
» Данни за собственост (Ownership - Задължително): Тази структура изисква детайлна информация за:
» IsPartOfGroup (Задължително): Дали компанията е част от група.
» Действителните собственици (физически лица – български и чуждестранни, с имена, ЕГН/идентификатори, гражданство, държава на пребиваване – всички тези полета са задължителни в рамките на структурата).
» Крайно предприятие майка (ако има такова – българско или чуждестранно, с наименования, ЕИК/идентификатори, държава на регистрация – тези полета също са задължителни в структурата, ако са приложими).
2. MasterFiles (Основни данни)
Въпреки че някои основни данни може да не се променят всеки месец, месечният SAF-T файл трябва да съдържа актуална информация или поне информация, която е релевантна за транзакциите през месеца. Ключови подсекции тук са:
GeneralLedgerAccounts (Сметкоплан - Задължително):
Задължително се подават всички счетоводни сметки от индивидуалния сметкоплан, картографирани към националния сметкоплан на НАП. За всяка сметка се посочват начални салда за отчетния месец, обороти (дебитни и кредитни) за месеца и крайни салда към края на месеца. Това е съществена част от месечното отчитане.
Customers (Клиенти) и Suppliers (Доставчици):
Задължително се подава информация за всички клиенти и доставчици, с които е имало транзакции или които имат салда през отчетния месец. За всеки контрагент се посочват идентификационни данни (ЕИК/ДДС номер, име, адрес), свързаната счетоводна сметка за разчети, начални и крайни салда по партидата на контрагента за отчетния месец, както и дали клиентът/доставчикът е свързано лице.
TaxTable (Данъчна таблица):
Задължително се подава информация за използваните данъчни кодове и техните ставки, които са били приложими за транзакциите през месеца.
UOMTable (Таблица с мерни единици):
Задължително се подават мерните единици, използвани в транзакциите през месеца.
Products (Продукти/Услуги):
Информация за продуктите/услугите, които са били обект на покупка или продажба през месеца. Това включва техните кодове, описания, кодове по КН (ProductCommodityCode).
AnalysisTypeTable (Таблица с аналитичности): Незадължително.
MovementTypeTable (Таблица за типове движения на СМЗ):
Ако има движения на СМЗ, които се отчитат месечно (макар самата секция MovementOfGoods да е при поискване, дефинициите може да се изискват, ако има такива движения в счетоводните записвания (GL)). Това трябва да се уточни от НАП.
3. GeneralLedgerEntries (Счетоводни записвания / Главна книга)
Това е ключова и задължителна част от месечния SAF-T файл. Изисква се подаването на абсолютно всички счетоводни статии (транзакции), осчетоводени през отчетния месец. Това включва:
» Осчетоводявания на фактури за покупки и продажби.
» Осчетоводявания на банкови движения и касови операции.
» Начисляване на заплати и осигуровки.
» Начисляване на амортизации.
» Начисляване на данъци.
» Начисляване на провизии.
» Отписвания, прихващания, валутни преоценки.
» Сторнировъчни операции.
» Всички други счетоводни операции, отразени в Главната книга за месеца.
За всяка счетоводна операция се подават дата на документа/транзакцията (TransactionDate), дата на системно въвеждане (SystemEntryDate), дата на осчетоводяване (GLPostingDate), описания, както и всички дебитни и кредитни счетоводни записвания (TransactionLine) с посочване на сметка, сума, описание, евентуални аналитичности и връзка към първичен документ.
4. SourceDocuments (Първични документи)
PurchaseInvoices (Фактури за покупки): Задължително се подават всички получени фактури за покупки през месеца, с детайлизация ред по ред, за което стана въпрос в първата част на SAF-Т анализа.
SalesInvoices (Фактури за продажби): Задължително се подават всички издадени фактури за продажби през месеца, с детайлизация ред по ред.
Payments (Плащания): Задължително се подава информация за извършените и получените плащания през месеца, с детайли за всяко плащане и връзката му със счетоводните записвания и евентуално с платени документи.
Секции, които не се очаква да се подават стандартно с месечния SAF-T (а са годишни или при поискване):
» MasterFiles / Assets (Дълготрайни активи с пълните САП и ДАП) – това е годишно.
» MasterFiles / PhysicalStock (Наличности на стоково-материални запаси) – това е при поискване.
» SourceDocuments / MovementOfGoods (Движение на стоки) – това е при поискване.
» SourceDocuments / AssetTransactions (Транзакции с активи) – това е при поискване.
» CorrespondingAccountsRep ort (Справка за кореспондиращи сметки) – това е опционално.
Разлика спрямо месечната ДДС декларация
В обобщение, месечният SAF-T файл е много повече от просто дневници за покупки и продажби. Обхватът му значително надхвърля информацията, подавана с месечната справка-декларация по ЗДДС и дневниците за покупки и продажби. Докато ДДС декларацията се фокусира основно върху покупките и продажбите, SAF-T изисква:
» Цялата Главна книга: Всички счетоводни операции, а не само тези от ДДС дневниците.
» Пълен сметкоплан със салда и обороти.
» Актуални основни данни с месечни салда по сметки и партиди на контрагенти, както и използвани номенклатури (сметкоплан, данъчни кодове, мерни единици, продукти/услуги).
» Детайлна информация за всички фактури за покупки и продажби за месеца.
» Детайлна информация за всички плащания за месеца.
» Информация за собственост и свързаност на подателя.
Годишен SAF-T файл
Освен месечен SAF-T файл, задължените лица трябва да подават и годишен такъв. Срокът за подаване на годишния SAF-Т е едновременно с подаването на годишната данъчна декларация по ЗКПО, която се подава до 30 юни на следващата година.
Годишния SAF-Т файл включва всички счетоводни статии за цялата отчетна година, включително годишните приключвателни операции (напр. приключване на приходни и разходни сметки, формиране на финансов резултат, начисляване на корпоративен данък за годината). Тези приключвателни операции обикновено не са част от месечните файлове (освен може би за декември, ако там се правят част от тях). Файлът включва отново всички издадени фактури, получени фактури и извършени плащания за цялата година. Годишният файл включва отново и сметкоплан с начални салда към началото на годината и крайни салда към края на годината (след всички приключвания), както и информация за всички контрагенти, с които е имало взаимоотношения през годината, с годишни начални и крайни салда по партидите им. Структурата на годишния SAF-T файл е аналогична на тази на месечния, но обхваща цялата финансова година.
Нова специфична информация, която се подава само в годишния SAF-T файл
MasterFiles/Assets (Дълготрайни активи):
Това е ключовата секция, която се подава детайлно на годишна база. Включва пълна информация за всеки дълготраен актив: идентификация, доставчик, дата на придобиване/въвеждане в експлоатация. Най-важното: Valuations с детайлен ValuationSAP (Счетоводен амортизационен план за годината) и ValuationDAP (Данъчен амортизационен план за годината). Тази детайлна информация за амортизационните планове, стойности, амортизации за периода, натрупани амортизации и т.н. се финализира и обобщава на годишна база.
SAF-Т и данни при поискване от НАП – кратък преглед
НАП може да изиска информация за следните данни за:
» MasterFiles/PhysicalStock (Наличности на стоково-материални запаси).
» SourceDocuments/MovementOfGoods (Движение на стоки).
» SourceDocuments/AssetTransactions (Транзакции с активи).
Срокът за подаване на тези данни е 14-дневен от датата на поискването от НАП. В настоящата статия само маркираме най-общо какви данни задължените лица ще трябва да предоставят на НАП при поискване, а в отделен материал сме разгледали детайлите на данните при поискване.
Поетапно въвеждане на SAF-T в България: Кой кога стартира по-подробно?
В своята страница НАП посочи, че започва внедряването на SAF-T, като в периода юли-декември 2025 г. се предвижда пилотно тестване. Съгласно разпоредбите на ДОПК задължението за подаване на SAF-T ще се въвежда поетапно, а графикът е следният:
От 1 януари 2026 г.: За големи предприятия (към 31.12.2023 г.), ако отговарят на поне едно от условията: нетни приходи от продажби за 2023 г. над 300 млн. лв. или през 2023 г. постъпленията по сметки на НАП от данъци и осигурителни вноски, намалени с възстановените суми за данъци и осигурителни вноски, са над 3 500 000 лв.
От 1 януари 2027 г.: За големи, средни или малки предприятия (към 31.12.2024 г.), ако отговарят на поне едно от условията: нетни приходи от продажби за 2024 г. над 300 млн. лв. или през 2024 г. постъпленията по сметки на НАП от данъци и осигурителни вноски, намалени с възстановените суми за данъци и осигурителни вноски, са над 3 500 000 лв.
От 1 януари 2028 г.: За големи, средни или малки предприятия (към 31.12.2025 г.), ако отговарят на поне едно от условията: нетни приходи от продажби за 2025 г. над 15 млн. лв. или през 2025 г. постъпленията по сметки на НАП от данъци и осигурителни вноски, намалени с възстановените суми за данъци и осигурителни вноски, са над 1 500 000 лв.
От 1 януари 2029 г.: За предприятията, които към 31.12.2026 г. са големи, средни или малки предприятия (без допълнителните финансови прагове от предходните групи).
От 1 януари 2030 г.: За всички останали задължени лица, непосочени по-горе, които са регистрирани по ЗДДС предприятия. В тази група се включват и микропредприятията, регистрирани по ЗДДС.
Изключени от отчитането по SAF-Т са микропредприятия, които не са регистрирани по ЗДДС, местните юридически лица, които не са търговци, бюджетните предприятия, фондовете за извършване на плащания и осигурителните каси, както и търговските представителства.
Поетапният подход за въвеждане на SAF-Т, обвързан с категорията на предприятието и специфични финансови прагове за първите групи, цели по-плавен преход към новия режим. Въпреки това, всички предприятия, които ще попаднат в обхвата на SAF-T, следва да започнат своята подготовка отрано, тъй като SAF-Т е изключително обемен и детайлен отчет, който изисква приключване на голяма част от месечното счетоводство преди да може да бъде генериран и подаден. Подготовката за подаване ще изисква сериозна реорганизация на работните процеси, надежден и адаптиран счетоводен софтуер, както и отлично познаване на изискванията и номенклатурите на НАП. Въпреки поетапното въвеждане, своевременната подготовка е от ключово значение.
Следва трета част от поредицата "Разбери SAF-Т":
SAF-T файл при поискване от НАП в 14-дневен срок: Какво трябва да знаят търговците и техните счетоводители?
7
С наближаването на поетапното въвеждане на Стандартния одитен файл за данъчни цели (SAF-T) в България, счетоводната общност е изправена пред необходимостта да се запознае в детайли с новите изисквания за подаване на счетоводна информация към НАП. Един от ключовите аспекти е осчетоводяването на фактурите за покупки и продажби. Каква информация ще трябва да подаваме, колко детайлна трябва да бъде тя и кои полета са абсолютно задължителни?
Съгласно последните измененията и допълнения в ДОПК (напр. ДВ, бр. 26 от 27.3.2025 г.), подаването на месечния SAF-T файл (съдържащ счетоводните записи с покупки, продажби, плащания и другите начисления) ще бъде до 14-о число на месеца, следващ отчетния, а годишният SAF-T файл (съдържащ информация за дълготрайните активи и материалните запаси) – едновременно с подаването на годишната данъчна декларация. Въпреки че за различните категории предприятия са предвидени различни срокове за влизане в сила на задължението (от 2026 г. за големи предприятия до 2030 г. за микропредприятия), подготовката и адаптацията на системите трябва да започне отрано, тъй като промените са съществени.
Един от най-притеснителните и трудоемки аспекти на SAF-T е отразяването на първичните документи, и по-специално – фактурите за покупки, защото с новите правила се изисква всички данни от фактурата, ред по ред, с количества, стойности, мерни единици и единични цени, да бъдат въвеждани в счетоводен софтуер, който да успее да генерира SAF-Т файла за подаване. Това се отнася не само за фактурите за материални запаси, но и за всички получени и издадени фактури от предприятието.
Изискванията по SAF-Т към счетоводствата са много по-мащабни, но в тази статия ще разгледаме само тези, касаещи осчетоводяването на фактурите. Въз основа на публикуваните от НАП проекти на XSD схема, таблични описания на структурата (Приложение 2) и указания за формата и реда за подаване (Приложение 3), по които тече обществено обсъждане до 09 юни, нека разгледаме как се очаква да се представят фактурите за покупки в SAF-T файла. Отразяването на продажните фактури е аналогично и поради причината, че те обичайно се издават чрез софтуер, то считаме, че за изпълнението на SAF-Т формата за тях би било по-лесно, предвид това, че данните за тях се създават директно в софтуера, с който се фактурира. Покупните фактури обаче трябва да бъдат по-детайлно въвеждани от досегашната практика.
Какво се осчетоводява и как се представя в SAF-T? Ключови аспекти на детайлизацията.
Основен принцип, заложен в SAF-T, е точното и детайлно отразяване на съдържанието на оригиналния първичен документ (фактурата). Това означава, че ако фактурата от доставчика съдържа множество редове, изброяващи различни стоки или компоненти на услуги, всеки от тези редове трябва да бъде възпроизведен като отделен InvoiceLine елемент в SAF-T файла. Това изискване е значително отклонение от текущата практика в много предприятия, особено малките и средните, където фактури за разходи (канцеларски материали, комунални услуги и др.), които не формират складови наличности, често се осчетоводяват с обобщени суми. За всяка фактура за покупка, SAF-T изисква не само общата информация, но и детайлно описание на закупените стоки или услуги на ниво ред, информация за доставчика и връзката на реда със счетоводните сметки и записвания.
Задължително използване на номенклатури на ниво ред
Едно от съществените изисквания е, че за всеки ред от фактурата (InvoiceLine) трябва да се използват кодове от официално утвърдени от НАП номенклатури. Това включва:
➤ Счетоводна сметка (AccountID): За всеки ред от фактурата трябва да се посочи счетоводната сметка (за стока, услуга, разход), като този код трябва да бъде от националния сметкоплан, предоставен от НАП (номенклатура NRA_Nom_Accounts). Предприятията ще трябва да картографират своя индивидуален сметкоплан към този на НАП.
➤ Мерна единица (InvoiceUOM): За всеки ред, където е приложимо (особено за стоки), трябва да се посочи мерната единица, като се използва код от официалната номенклатура за мерни единици (номенклатура Unit of Measure).
➤ Други кодове: Подобни изисквания за използване на кодове от номенклатури важат и за други полета като InvoiceType (тип на фактурата), GoodsServicesID (индикатор стока/услуга), TaxType и TaxCode (за ДДС информация).
Основни елементи при отчитане на фактура за покупка (със статус на задължителност)
• Обща информация за фактурата (на ниво елемент Invoice):
» InvoiceNo (Задължително): Номерът на оригиналната фактура.
» InvoiceDate (Задължително): Датата на издаване.
» InvoiceType (Задължително): Тип на документа (код от Nom_Invoice_Types).
» GLPostingDate (Задължително): Датата на осчетоводяване в Главната книга.
» TransactionID (Задължително): Уникален идентификатор, свързващ фактурата със счетоводната статия в GeneralLedgerEntries.
» AccountID (Задължително): Аналитичната счетоводна сметка за разчети с доставчика (от NRA_Nom_Accounts).
» SelfBillingIndicator (Задължително): Индикатор за самофактуриране ("0" или "1").
» PaymentTerms (Незадължително): Условия за плащане.
» Period (Незадължително) и PeriodYear (Незадължително): Счетоводен период и година.
» SourceID (Незадължително): Идентификатор на потребителя/системата, въвели фактурата.
» SystemID (Незадължително): Вътрешен системен номер на документа.
• Информация за доставчика (елемент SupplierInfo в Invoice):
» Елементът SupplierInfo е Задължителен.
» В него трябва да се попълни поне едно от следните:
» SupplierID (Задължително, ако се избере тази опция): ЕИК/БУЛСТАТ на доставчика.
» ИЛИ Name (Задължително, ако се избере тази опция): Наименование на доставчика.
» BillingAddress (Задължително): Адрес за фактуриране на доставчика.
» City (Задължително): Населено място.
» Country (Задължително): Държава (ISO код).
» Останалите компоненти на адреса (StreetName, Number, PostalCode, Region) са незадължителни.
• Редове на фактурата (елемент InvoiceLine – поне един ред е задължителен):
» LineNumber (Задължително): Пореден номер на реда.
» ProductDescription (Задължително): Описание на закупената стока или услуга.
» GoodsServicesID (Задължително): Индикатор стока ("G") или услуга ("S") (от Nom_GoodsServicesID).
» Quantity (Задължително): Закупено количество.
» InvoiceUOM (Задължително): Мерна единица (код от Unit of Measure).
» UnitPrice (Задължително): Единична цена без ДДС.
» InvoiceLineAmount (Задължително): Обща стойност на реда без ДДС (структура AmountStructure със Задължителни Amount, CurrencyCode, CurrencyAmount; ExchangeRate е Незадължително, освен при нужда).
» TaxPointDate (Задължително): Дата на данъчното събитие.
» AccountID (Задължително): Счетоводната сметка за стоката/услугата/разхода (от NRA_Nom_Accounts).
» DebitCreditIndicator (Задължително): "D" или "C".
» Description (Задължително): Описание на реда.
» TaxInformation (Задължително - поне един елемент):
» TaxType (Задължително) (от VAT_TaxType).
» TaxCode (Задължително) (от TAX-IMP).
» TaxPercentage (Условно задължително/Задължително, ако има данък).
» TaxBase (Условно задължително/Задължително, ако има данък).
» TaxAmount (Задължително) (структура AmountStructure).
» TaxExemptionReason (Незадължително).
» TaxDeclarationPeriod (Незадължително).
» ProductCode (Условно задължително): Код на продукта/услугата от MasterFiles/Products. (За услуги указанието е за общ код "00000000" за ProductCommodityCode).
» ShippingCostsAmount (Незадължително).
» Analysis (Незадължително).
• Общи суми за фактурата (елемент InvoiceDocumentTotals - Задължително):
» NetTotal (Задължително): Обща нетна стойност.
» GrossTotal (Задължително): Обща брутна стойност.
» TaxInformationTotals (Незадължително).
» ShippingCostsAmountTotal (Незадължително).
Данни за доставчика в MasterFiles/Suppliers/Supplier (Основни данни)
За пълнота, освен данните в самата фактура, в MasterFiles за доставчика се изискват:
• SupplierID (Задължително)
• CompanyStructure (Задължително):
» RegistrationNumber (Задължително)
» Name (Задължително)
» NameLatin (Задължително)
» Address (Задължително - поне един адрес):
» City (Задължително)
» Country (Задължително)
» Останалите компоненти са Незадължителни.
» RelatedParty (Задължително)
» TaxRegistration (Условно задължително, на практика Задължително за ДДС номер):
» TaxRegistrationNumber (Задължително, ако се подава TaxRegistration).
» Contact (Незадължително).
» BankAccount (Незадължително).
• AccountID (Задължително): Вашата счетоводна сметка за разчети с доставчика (от NRA_Nom_Accounts).
• OpeningDebitBalance или OpeningCreditBalance (Задължително едно от двете).
• ClosingDebitBalance или ClosingCreditBalance (Задължително едно от двете).
Примери за отчитане на различни типове фактури за покупки
Фактура за покупка на стоки за склад: Всеки ред от фактурата с различна стока ще се описва като отделен InvoiceLine в SAF-T. AccountID на реда ще бъде съответната сметка за материални запаси (напр. 304). ProductCode ще е задължителен, ако управлявате стоките с кодове.
Фактура за канцеларски материали (директен разход): Ако фактурата от доставчика изброява "химикалки - 10 бр.", "хартия - 5 пакета" и тн., то в SAF-T се очакват отделни редове с количество, единична цена, мерна единица и стойност в InvoiceLine елемента, като AccountID на всеки ред ще бъде разходната сметка (напр. 601).
Фактура за електроенергия: Ако фактурата има един основен ред за "Доставена електроенергия" с общо количество и стойност, то в SAF-T ще има един InvoiceLine. Но обичайно такава фактура детайлизира отделно дневна и нощна енергия като отделни редове с количества, мерни единици и цени, те ще бъдат отделни InvoiceLine елементи с своите мерни единици, количества, единични цени и стойности. AccountID ще е разходната сметка за ел. енергия.
Такъв е подходът за фактурите с множество компоненти, дори и стопанската операция да е директен разход (напр. фактура от "Топлофикация"). Както знаете, фактурата изброява "Топлинна енергия за подгряване на вода", "Топлинна енергия за отопление" и "Услуга дялово разпределение" и други отделни редове с количества, цени и суми, те трябва да бъдат отделни InvoiceLine елементи в SAF-T, като всеки ред сочи към съответната разходна сметка.
Примерите за такива фактури, които не отчитат стоково-материални запаси, но ще изискват това детайлно въвеждане в счетоводните системи, са неизброими.
Последици за счетоводния софтуер
Това ниво на детайлизация налага сериозна преработка и актуализация на използваните счетоводни програми. Софтуерът трябва да може не само да съхранява, но и да експортира тази информация за всеки ред от всяка фактура, независимо дали тя се управлява количествено-стойностно в склад. Доставчиците на счетоводен софтуер и самите предприятия ще трябва да инвестират време и ресурси, за да осигурят съвместимост. Препоръчително е тестването на тези функционалности да започне възможно най-рано, дори и за предприятията, за които задължението ще възникне на по-късен етап.
Заключение за счетоводната общност
Въвеждането на SAF-T ще изисква фундаментална промяна в начина, по който много счетоводни предприятия, обработват и записват данните от фактурите. Изискването за детайлизация "ред по ред" на всички фактури, независимо от тяхното счетоводно третиране като директен разход, е сериозно предизвикателство. Ключово е разбирането, че секция SourceDocuments трябва да отразява съдържанието на оригиналния документ, ред по ред, ако той е детайлизиран. Докато счетоводното отразяване в GeneralLedgerEntries може да бъде по-обобщено (напр. един ред за разход за канцеларски материали), то самата фактура в SAF-T изисква по-голяма детайлизация, ако така е издадена от доставчика. Задължителните полета са многобройни и изискват точност, както и правилното използване на дефинираните от НАП номенклатури. Въпреки наличието на незадължителни полета, за пълнота и избягване на последващи въпроси е препоръчително да се попълва максимално коректна и релевантна информация.
Всичко това налага не само пренаписване и адаптиране на счетоводните софтуери, но и отделяне на значително повече време за обработка на документите в счетоводните предприятия. Предвид кратките срокове за подаване, особено за месечния SAF-T файл (до 14-о число), е от изключителна важност предприятията и разработчиците на софтуер да започнат подготовката си своевременно, дори ако за тях задължението влиза в сила на по-късен етап от предвидената поетапност. Внимателното планиране и тестване на системите ще бъдат ключови за успешното преминаване към новия режим на отчитане.
Следва втора част от поредицата "Разбери SAF-Т":
SAF-T: Какво още включва месечният файл освен фактури? Поглед отвъд ДДС декларацията
Съгласно последните измененията и допълнения в ДОПК (напр. ДВ, бр. 26 от 27.3.2025 г.), подаването на месечния SAF-T файл (съдържащ счетоводните записи с покупки, продажби, плащания и другите начисления) ще бъде до 14-о число на месеца, следващ отчетния, а годишният SAF-T файл (съдържащ информация за дълготрайните активи и материалните запаси) – едновременно с подаването на годишната данъчна декларация. Въпреки че за различните категории предприятия са предвидени различни срокове за влизане в сила на задължението (от 2026 г. за големи предприятия до 2030 г. за микропредприятия), подготовката и адаптацията на системите трябва да започне отрано, тъй като промените са съществени.
Един от най-притеснителните и трудоемки аспекти на SAF-T е отразяването на първичните документи, и по-специално – фактурите за покупки, защото с новите правила се изисква всички данни от фактурата, ред по ред, с количества, стойности, мерни единици и единични цени, да бъдат въвеждани в счетоводен софтуер, който да успее да генерира SAF-Т файла за подаване. Това се отнася не само за фактурите за материални запаси, но и за всички получени и издадени фактури от предприятието.
Изискванията по SAF-Т към счетоводствата са много по-мащабни, но в тази статия ще разгледаме само тези, касаещи осчетоводяването на фактурите. Въз основа на публикуваните от НАП проекти на XSD схема, таблични описания на структурата (Приложение 2) и указания за формата и реда за подаване (Приложение 3), по които тече обществено обсъждане до 09 юни, нека разгледаме как се очаква да се представят фактурите за покупки в SAF-T файла. Отразяването на продажните фактури е аналогично и поради причината, че те обичайно се издават чрез софтуер, то считаме, че за изпълнението на SAF-Т формата за тях би било по-лесно, предвид това, че данните за тях се създават директно в софтуера, с който се фактурира. Покупните фактури обаче трябва да бъдат по-детайлно въвеждани от досегашната практика.
Какво се осчетоводява и как се представя в SAF-T? Ключови аспекти на детайлизацията.
Основен принцип, заложен в SAF-T, е точното и детайлно отразяване на съдържанието на оригиналния първичен документ (фактурата). Това означава, че ако фактурата от доставчика съдържа множество редове, изброяващи различни стоки или компоненти на услуги, всеки от тези редове трябва да бъде възпроизведен като отделен InvoiceLine елемент в SAF-T файла. Това изискване е значително отклонение от текущата практика в много предприятия, особено малките и средните, където фактури за разходи (канцеларски материали, комунални услуги и др.), които не формират складови наличности, често се осчетоводяват с обобщени суми. За всяка фактура за покупка, SAF-T изисква не само общата информация, но и детайлно описание на закупените стоки или услуги на ниво ред, информация за доставчика и връзката на реда със счетоводните сметки и записвания.
Задължително използване на номенклатури на ниво ред
Едно от съществените изисквания е, че за всеки ред от фактурата (InvoiceLine) трябва да се използват кодове от официално утвърдени от НАП номенклатури. Това включва:
➤ Счетоводна сметка (AccountID): За всеки ред от фактурата трябва да се посочи счетоводната сметка (за стока, услуга, разход), като този код трябва да бъде от националния сметкоплан, предоставен от НАП (номенклатура NRA_Nom_Accounts). Предприятията ще трябва да картографират своя индивидуален сметкоплан към този на НАП.
➤ Мерна единица (InvoiceUOM): За всеки ред, където е приложимо (особено за стоки), трябва да се посочи мерната единица, като се използва код от официалната номенклатура за мерни единици (номенклатура Unit of Measure).
➤ Други кодове: Подобни изисквания за използване на кодове от номенклатури важат и за други полета като InvoiceType (тип на фактурата), GoodsServicesID (индикатор стока/услуга), TaxType и TaxCode (за ДДС информация).
Основни елементи при отчитане на фактура за покупка (със статус на задължителност)
• Обща информация за фактурата (на ниво елемент Invoice):
» InvoiceNo (Задължително): Номерът на оригиналната фактура.
» InvoiceDate (Задължително): Датата на издаване.
» InvoiceType (Задължително): Тип на документа (код от Nom_Invoice_Types).
» GLPostingDate (Задължително): Датата на осчетоводяване в Главната книга.
» TransactionID (Задължително): Уникален идентификатор, свързващ фактурата със счетоводната статия в GeneralLedgerEntries.
» AccountID (Задължително): Аналитичната счетоводна сметка за разчети с доставчика (от NRA_Nom_Accounts).
» SelfBillingIndicator (Задължително): Индикатор за самофактуриране ("0" или "1").
» PaymentTerms (Незадължително): Условия за плащане.
» Period (Незадължително) и PeriodYear (Незадължително): Счетоводен период и година.
» SourceID (Незадължително): Идентификатор на потребителя/системата, въвели фактурата.
» SystemID (Незадължително): Вътрешен системен номер на документа.
• Информация за доставчика (елемент SupplierInfo в Invoice):
» Елементът SupplierInfo е Задължителен.
» В него трябва да се попълни поне едно от следните:
» SupplierID (Задължително, ако се избере тази опция): ЕИК/БУЛСТАТ на доставчика.
» ИЛИ Name (Задължително, ако се избере тази опция): Наименование на доставчика.
» BillingAddress (Задължително): Адрес за фактуриране на доставчика.
» City (Задължително): Населено място.
» Country (Задължително): Държава (ISO код).
» Останалите компоненти на адреса (StreetName, Number, PostalCode, Region) са незадължителни.
• Редове на фактурата (елемент InvoiceLine – поне един ред е задължителен):
» LineNumber (Задължително): Пореден номер на реда.
» ProductDescription (Задължително): Описание на закупената стока или услуга.
» GoodsServicesID (Задължително): Индикатор стока ("G") или услуга ("S") (от Nom_GoodsServicesID).
» Quantity (Задължително): Закупено количество.
» InvoiceUOM (Задължително): Мерна единица (код от Unit of Measure).
» UnitPrice (Задължително): Единична цена без ДДС.
» InvoiceLineAmount (Задължително): Обща стойност на реда без ДДС (структура AmountStructure със Задължителни Amount, CurrencyCode, CurrencyAmount; ExchangeRate е Незадължително, освен при нужда).
» TaxPointDate (Задължително): Дата на данъчното събитие.
» AccountID (Задължително): Счетоводната сметка за стоката/услугата/разхода (от NRA_Nom_Accounts).
» DebitCreditIndicator (Задължително): "D" или "C".
» Description (Задължително): Описание на реда.
» TaxInformation (Задължително - поне един елемент):
» TaxType (Задължително) (от VAT_TaxType).
» TaxCode (Задължително) (от TAX-IMP).
» TaxPercentage (Условно задължително/Задължително, ако има данък).
» TaxBase (Условно задължително/Задължително, ако има данък).
» TaxAmount (Задължително) (структура AmountStructure).
» TaxExemptionReason (Незадължително).
» TaxDeclarationPeriod (Незадължително).
» ProductCode (Условно задължително): Код на продукта/услугата от MasterFiles/Products. (За услуги указанието е за общ код "00000000" за ProductCommodityCode).
» ShippingCostsAmount (Незадължително).
» Analysis (Незадължително).
• Общи суми за фактурата (елемент InvoiceDocumentTotals - Задължително):
» NetTotal (Задължително): Обща нетна стойност.
» GrossTotal (Задължително): Обща брутна стойност.
» TaxInformationTotals (Незадължително).
» ShippingCostsAmountTotal (Незадължително).
Данни за доставчика в MasterFiles/Suppliers/Supplier (Основни данни)
За пълнота, освен данните в самата фактура, в MasterFiles за доставчика се изискват:
• SupplierID (Задължително)
• CompanyStructure (Задължително):
» RegistrationNumber (Задължително)
» Name (Задължително)
» NameLatin (Задължително)
» Address (Задължително - поне един адрес):
» City (Задължително)
» Country (Задължително)
» Останалите компоненти са Незадължителни.
» RelatedParty (Задължително)
» TaxRegistration (Условно задължително, на практика Задължително за ДДС номер):
» TaxRegistrationNumber (Задължително, ако се подава TaxRegistration).
» Contact (Незадължително).
» BankAccount (Незадължително).
• AccountID (Задължително): Вашата счетоводна сметка за разчети с доставчика (от NRA_Nom_Accounts).
• OpeningDebitBalance или OpeningCreditBalance (Задължително едно от двете).
• ClosingDebitBalance или ClosingCreditBalance (Задължително едно от двете).
Примери за отчитане на различни типове фактури за покупки
Фактура за покупка на стоки за склад: Всеки ред от фактурата с различна стока ще се описва като отделен InvoiceLine в SAF-T. AccountID на реда ще бъде съответната сметка за материални запаси (напр. 304). ProductCode ще е задължителен, ако управлявате стоките с кодове.
Фактура за канцеларски материали (директен разход): Ако фактурата от доставчика изброява "химикалки - 10 бр.", "хартия - 5 пакета" и тн., то в SAF-T се очакват отделни редове с количество, единична цена, мерна единица и стойност в InvoiceLine елемента, като AccountID на всеки ред ще бъде разходната сметка (напр. 601).
Фактура за електроенергия: Ако фактурата има един основен ред за "Доставена електроенергия" с общо количество и стойност, то в SAF-T ще има един InvoiceLine. Но обичайно такава фактура детайлизира отделно дневна и нощна енергия като отделни редове с количества, мерни единици и цени, те ще бъдат отделни InvoiceLine елементи с своите мерни единици, количества, единични цени и стойности. AccountID ще е разходната сметка за ел. енергия.
Такъв е подходът за фактурите с множество компоненти, дори и стопанската операция да е директен разход (напр. фактура от "Топлофикация"). Както знаете, фактурата изброява "Топлинна енергия за подгряване на вода", "Топлинна енергия за отопление" и "Услуга дялово разпределение" и други отделни редове с количества, цени и суми, те трябва да бъдат отделни InvoiceLine елементи в SAF-T, като всеки ред сочи към съответната разходна сметка.
Примерите за такива фактури, които не отчитат стоково-материални запаси, но ще изискват това детайлно въвеждане в счетоводните системи, са неизброими.
Последици за счетоводния софтуер
Това ниво на детайлизация налага сериозна преработка и актуализация на използваните счетоводни програми. Софтуерът трябва да може не само да съхранява, но и да експортира тази информация за всеки ред от всяка фактура, независимо дали тя се управлява количествено-стойностно в склад. Доставчиците на счетоводен софтуер и самите предприятия ще трябва да инвестират време и ресурси, за да осигурят съвместимост. Препоръчително е тестването на тези функционалности да започне възможно най-рано, дори и за предприятията, за които задължението ще възникне на по-късен етап.
Заключение за счетоводната общност
Въвеждането на SAF-T ще изисква фундаментална промяна в начина, по който много счетоводни предприятия, обработват и записват данните от фактурите. Изискването за детайлизация "ред по ред" на всички фактури, независимо от тяхното счетоводно третиране като директен разход, е сериозно предизвикателство. Ключово е разбирането, че секция SourceDocuments трябва да отразява съдържанието на оригиналния документ, ред по ред, ако той е детайлизиран. Докато счетоводното отразяване в GeneralLedgerEntries може да бъде по-обобщено (напр. един ред за разход за канцеларски материали), то самата фактура в SAF-T изисква по-голяма детайлизация, ако така е издадена от доставчика. Задължителните полета са многобройни и изискват точност, както и правилното използване на дефинираните от НАП номенклатури. Въпреки наличието на незадължителни полета, за пълнота и избягване на последващи въпроси е препоръчително да се попълва максимално коректна и релевантна информация.
Всичко това налага не само пренаписване и адаптиране на счетоводните софтуери, но и отделяне на значително повече време за обработка на документите в счетоводните предприятия. Предвид кратките срокове за подаване, особено за месечния SAF-T файл (до 14-о число), е от изключителна важност предприятията и разработчиците на софтуер да започнат подготовката си своевременно, дори ако за тях задължението влиза в сила на по-късен етап от предвидената поетапност. Внимателното планиране и тестване на системите ще бъдат ключови за успешното преминаване към новия режим на отчитане.
Следва втора част от поредицата "Разбери SAF-Т":
SAF-T: Какво още включва месечният файл освен фактури? Поглед отвъд ДДС декларацията
8
Здравейте, благодаря за коментара. Корекцията за по-ниските стойности от МОД е отразена в калкулатора.
9
До 15 ти април подаваме декларация по чл. 87а от ЗКПО за определяна на авансовите вноски за корпоративен данък. През годината (до 15 ноември) със същия образец можем да декларираме промени в авансовите вноски по чл. 88 от ЗКПО.
В тази връзка представяме два много полезни калкулатора.
Чрез Калкулатор: Авансови вноски ЗКПО можете:
➤ да проверите дали следва да внасяте месечна или тримесечна авансова вноска;
➤ да изчислите размерите на месечните или тримесечните авансови вноски;
➤ да видите сроковете за внасянето им.
Чрез Калкулатор: Промяна на авансови вноски ЗКПО (чл. 88) можете да направите анализ и:
➤ да изчислите увеличението или намалението на декларираните авансови вноски (тримесечни или месечни), така че да не се внасят лихви, ако са декларирани по-малки авансови вноски;
➤ да изчислите сумата на надвишението на вноските, при внесени по-високи авансови вноски и последваща по-ниска прогнозна данъчна печалба.
Кой подава декларация
Декларацията се подава от лицата, подлежащи на облагане с корпоративен данък по реда на ЗКПО, както и от физически лица, извършващи стопанска дейност като търговци по смисъла на Търговския закон, включително еднолични търговци, и от физически лица, регистрирани като земеделски стопани, избрали доходът от стопанската им дейност да се облага с данък върху годишната данъчна основа по чл. 28 от ЗДДФЛ, които съгласно чл. 43, ал. 8 от ЗДДФЛ правят авансови вноски при условията и по реда на ЗКПО.
Декларация се подава и ако прогнозният данъчен финансов резултат е отрицателна или нулева величина, но лицето е задължено да извършва авансови вноски. В този случай като размер на определената месечна/тримесечна авансова вноска, съответно размер на определената месечна/тримесечна авансова вноска след преотстъпване, се посочва нула.
Кога се подава декларация
Декларацията се подава в случай на:
➤ деклариране вида и размера на авансовите вноски по чл. 87а, ал.1 от ЗКПО;
➤ първоначално деклариране на тримесечни авансови вноски по чл. 87а, ал. 2 и 3 от ЗКПО;
➤ промени на авансови вноски по чл. 88 от ЗКПО.
Кога не се подава декларация
Декларация не подават лицата, които са освободени от авансови вноски и не са избрали да правят такива съгласно чл. 83, ал. 3 от ЗКПО:
➤ данъчно задължените лица, чиито нетни приходи от продажби за годината преди предходната година не превишават 300 000 лв.;
➤ новоучредените данъчно задължени лица за годината на учредяването им и за следващата година, с изключение на новоучредените в резултат на преобразуване по Търговския закон.
Срок за подаване
За деклариране на вида и размера на авансовите вноски
Срокът за подаване на декларацията за определените по реда на чл. 86 и 87 авансови вноски за текущата календарна година е от 1 март до 15 април на същата година.
Определените по реда на чл. 87 тримесечни авансови вноски за текущата календарна година от новоучредено в резултат на преобразуване дружество се декларират в срока за извършване на първата авансова вноска след преобразуването.
Определените по реда на чл. 87 тримесечни авансови вноски за текущата календарна година от новоучредено дружество в случаите по чл. 83, ал. 3 се декларират в срока за извършване на първата избрана тримесечна авансова вноска.
Съгласно чл. 104, ал. 1 и 2 от Данъчно-осигурителния процесуален кодекс след подаването на декларацията, но преди изтичането на законоустановения срок за подаването ѝ, подателят има право да прави промени, свързани с декларираните данни и обстоятелства, основата и определените задължения. Промени в подадена декларация се извършват с нова декларация. Следователно, когато в периода от 1 март до 15 април на текущата година са подадени например две декларации по чл. 87а от ЗКПО, втората по ред декларация заменя предходно подадената.
За промени на авансовите вноски
Съгласно чл. 88, ал. 1 от ЗКПО декларация за намаляване или увеличаване на авансовите вноски може да се подава в срок до 15 ноември на съответната година, като според ал. 2 на същия член намалението, съответно увеличението, на авансовите вноски се ползва едва след подаването на декларацията.
Пример: На 15.05. е подадена декларация за промени на месечни авансови вноски за месеците V, VІ и VІІ от Х г. Така декларираните промени се ползват, защото декларацията е подадена преди изтичане на срока за внасяне на авансовите вноски за посочените месеци. За да се ползва обаче намаление или увеличение на месечната авансова вноска за месец декември, съответно на тримесечната авансова вноска за трето тримесечие, чийто срок за внасяне е 1 декември, декларацията трябва да е подадена най-късно до 15 ноември на съответната година, защото това е предвиденият в ЗКПО краен срок за подаване на декларацията за промени на авансовите вноски.
В случаите на преобразуване по реда на глава деветнадесета, когато е налице промяна в размера на определените от приемащото дружество след преобразуването авансови вноски, декларацията се подава в срока за извършване на първата авансова вноска след преобразуването.
В тази връзка представяме два много полезни калкулатора.
Чрез Калкулатор: Авансови вноски ЗКПО можете:
➤ да проверите дали следва да внасяте месечна или тримесечна авансова вноска;
➤ да изчислите размерите на месечните или тримесечните авансови вноски;
➤ да видите сроковете за внасянето им.
Чрез Калкулатор: Промяна на авансови вноски ЗКПО (чл. 88) можете да направите анализ и:
➤ да изчислите увеличението или намалението на декларираните авансови вноски (тримесечни или месечни), така че да не се внасят лихви, ако са декларирани по-малки авансови вноски;
➤ да изчислите сумата на надвишението на вноските, при внесени по-високи авансови вноски и последваща по-ниска прогнозна данъчна печалба.
Кой подава декларация
Декларацията се подава от лицата, подлежащи на облагане с корпоративен данък по реда на ЗКПО, както и от физически лица, извършващи стопанска дейност като търговци по смисъла на Търговския закон, включително еднолични търговци, и от физически лица, регистрирани като земеделски стопани, избрали доходът от стопанската им дейност да се облага с данък върху годишната данъчна основа по чл. 28 от ЗДДФЛ, които съгласно чл. 43, ал. 8 от ЗДДФЛ правят авансови вноски при условията и по реда на ЗКПО.
Декларация се подава и ако прогнозният данъчен финансов резултат е отрицателна или нулева величина, но лицето е задължено да извършва авансови вноски. В този случай като размер на определената месечна/тримесечна авансова вноска, съответно размер на определената месечна/тримесечна авансова вноска след преотстъпване, се посочва нула.
Кога се подава декларация
Декларацията се подава в случай на:
➤ деклариране вида и размера на авансовите вноски по чл. 87а, ал.1 от ЗКПО;
➤ първоначално деклариране на тримесечни авансови вноски по чл. 87а, ал. 2 и 3 от ЗКПО;
➤ промени на авансови вноски по чл. 88 от ЗКПО.
Кога не се подава декларация
Декларация не подават лицата, които са освободени от авансови вноски и не са избрали да правят такива съгласно чл. 83, ал. 3 от ЗКПО:
➤ данъчно задължените лица, чиито нетни приходи от продажби за годината преди предходната година не превишават 300 000 лв.;
➤ новоучредените данъчно задължени лица за годината на учредяването им и за следващата година, с изключение на новоучредените в резултат на преобразуване по Търговския закон.
Срок за подаване
За деклариране на вида и размера на авансовите вноски
Срокът за подаване на декларацията за определените по реда на чл. 86 и 87 авансови вноски за текущата календарна година е от 1 март до 15 април на същата година.
Определените по реда на чл. 87 тримесечни авансови вноски за текущата календарна година от новоучредено в резултат на преобразуване дружество се декларират в срока за извършване на първата авансова вноска след преобразуването.
Определените по реда на чл. 87 тримесечни авансови вноски за текущата календарна година от новоучредено дружество в случаите по чл. 83, ал. 3 се декларират в срока за извършване на първата избрана тримесечна авансова вноска.
Съгласно чл. 104, ал. 1 и 2 от Данъчно-осигурителния процесуален кодекс след подаването на декларацията, но преди изтичането на законоустановения срок за подаването ѝ, подателят има право да прави промени, свързани с декларираните данни и обстоятелства, основата и определените задължения. Промени в подадена декларация се извършват с нова декларация. Следователно, когато в периода от 1 март до 15 април на текущата година са подадени например две декларации по чл. 87а от ЗКПО, втората по ред декларация заменя предходно подадената.
За промени на авансовите вноски
Съгласно чл. 88, ал. 1 от ЗКПО декларация за намаляване или увеличаване на авансовите вноски може да се подава в срок до 15 ноември на съответната година, като според ал. 2 на същия член намалението, съответно увеличението, на авансовите вноски се ползва едва след подаването на декларацията.
Пример: На 15.05. е подадена декларация за промени на месечни авансови вноски за месеците V, VІ и VІІ от Х г. Така декларираните промени се ползват, защото декларацията е подадена преди изтичане на срока за внасяне на авансовите вноски за посочените месеци. За да се ползва обаче намаление или увеличение на месечната авансова вноска за месец декември, съответно на тримесечната авансова вноска за трето тримесечие, чийто срок за внасяне е 1 декември, декларацията трябва да е подадена най-късно до 15 ноември на съответната година, защото това е предвиденият в ЗКПО краен срок за подаване на декларацията за промени на авансовите вноски.
В случаите на преобразуване по реда на глава деветнадесета, когато е налице промяна в размера на определените от приемащото дружество след преобразуването авансови вноски, декларацията се подава в срока за извършване на първата авансова вноска след преобразуването.
kik info
По-бързо. По-удобно. По-сигурно.*
Хиляди счетоводители се абонираха и ежедневно ползват kik-info.com.
По-бързо. По-удобно. По-сигурно.*
Хиляди счетоводители се абонираха и ежедневно ползват kik-info.com.
10
Правила на форума » Как да получавам имейл при нови статии от КиК Инфо?
27.03.2025, 15:03Можете да получавате имейл всеки път, когато публикуваме нова статия в секция "Статии от КиК Инфо" от раздела "Новини" по следния начин:
1) Влизате във профила си, а след това във Форум » Новини » Статии от КиК Инфо.
2) Натискате синия бутон "Действия".
3) От падащота меню избирате "Извести по имейл при новост" и потвърждавате своя избор.
Ако решите, че вече не желаете да получавате тези имейли, то повтаряте горните стъпки, като при последната избирате "Спри известяването по имейл", което се визуализира за всеки раздел, за който преди това сте указали известяване.
Внимание: Ще получавате уведомленията от сайта на имейла от регистрацията си.
1) Влизате във профила си, а след това във Форум » Новини » Статии от КиК Инфо.
2) Натискате синия бутон "Действия".
3) От падащота меню избирате "Извести по имейл при новост" и потвърждавате своя избор.
Ако решите, че вече не желаете да получавате тези имейли, то повтаряте горните стъпки, като при последната избирате "Спри известяването по имейл", което се визуализира за всеки раздел, за който преди това сте указали известяване.
Внимание: Ще получавате уведомленията от сайта на имейла от регистрацията си.
11
Статии от КиК Инфо » От 01.04.2025: Осигуровки, МОД, ТЗПБ, болнични
26.03.2025, 13:18В Държавен вестник брой 25 от 25.03.2025 г. са обнародвани ЗБДОО за 2025 г. и ЗБНЗОК за 2025 г. В тази връзка актуализирахме разделите:
✔ Раздел ТРЗ
✔ Раздел Данъчни
✔ Раздел Счетоводни
✔ Раздел Справочник
✔ Раздел Нормативна база, където абонираните потребители могат да сравняват новите със старите версии на законите.
По-долу обобщаваме основните ТРЗ показатели, приложими от 01.04.2025 г., като обръщаме внимание, че за периода 01.01.2025 г. - 31.03.2025 г. важат ТРЗ показателите за 2024, с изключение на минималната работна заплата за страната (МРЗ), чийто размер от 01.01.2025 г. бе увеличен от 933 лв. на 1077 лв. Увеличението е в размер на 15.44%.
➤ Увеличават се размерите на минималните осигурителни доходи (МОД) по основни икономически дейности и квалификационни групи професии. Увеличението се състои в следното: тези, които са по-ниски от МРЗ за 2025 г., се изравняват с МРЗ и стават в размер на 1077 лв., а останалите остават без промяна. По-този начин за голяма част от дейностите МОД-овете от първата до последната колона са равни на 1077 лв. Виж таблица на МОД от 01.04.2025.
➤ Увеличава се минималният месечен размер на осигурителния доход за самоосигуряващите се лица (вкл. регистрираните земеделски стопани и тютюнопроизводители) в размер на 1077 лв. Запазва се регистрираните земеделски стопани и тютюнопроизводителите да не определят окончателен размер на осигурителния доход за дейността по производство на непреработена растителна и/или животинска продукция.
➤ Увеличава се максималният месечен размер на осигурителния доход от 3750 лв. на 4130 лв. Увеличението е в размер на 10.13%.
➤ За дните на лицата в неплатен отпуск се дължи здравна осигуровка върху половината от минималния размер на осигурителния доход за самоосигуряващите се лица, тоест върху 538.50 лв (увеличение).
➤ За дните на лицата във временна неработоспособност поради болест, бременност и раждане и отглеждане на малко дете се дължи здравна осигуровка от работодателя върху минималния осигурителен доход за самоосигуряващите се лица, който е в размер на 1077 лв (увеличение).
➤ Здравната вноска за безработните се изчислява на 43.08 лв. на месец (увеличение).
➤ Има промени във вноските за фонд ТЗПБ по групи основни икономически дейности при запазване на минималната и максималната граница (0.4 - 1.1 на сто). Виж таблица на ТЗПБ.
➤ Запазват се размерите и разпределението на осигурителните вноски за фондовете "Пенсии", "ОЗМ", "Безработица" и здравноосигурителната вноска. Виж Осигуровки и данъци (таблица).
➤ Запазва се нулева вноска за фонд "Гарантирани вземания на работниците и служителите" (ГВРС).
➤ Запазва се необлагаемият размер на ваучерите за храна от 200 лв. месечно за наето лице.
➤ Времето в неплатен отпуск, което се зачита за осигурителен стаж, е до 30 работни дни за календарната година.
Обезщетения и болнични за 2025 г.
➤ Запазва се периодът, от който се изчисляват краткосрочните обезщетения при:
• временна неработоспособност – 18 календарни месеца;
• безработица – 24 календарни месеца;
• бременност и раждане – 24 календарни месеца;
• трудоустрояване поради бременност или кърмене или напреднал етап на лечение ин-витро – 24 календарни месеца.
➤ Запазва се периодът на изплащане на паричното обезщетение за бременност и раждане в размер на 410 дни.
➤ Запазва се размерът на втората година майчинство от 780 лв.
➤ Право на парично обезщетение за безработица имат лицата, за които са внесени или дължими осигурителни вноски във фонд "Безработица“ най-малко 12 месеца през последните 18 месеца преди прекратяване на осигуряването.
➤ Минимален дневен размер на обезщетението за безработица – 18 лв. (без промяна), максимален размер – 107.14 лв (без промяна).
kik info
по-лесно | по-бързо | по-сигурно*
Абонамент за пълен достъп от тук.
✔ Раздел ТРЗ
✔ Раздел Данъчни
✔ Раздел Счетоводни
✔ Раздел Справочник
✔ Раздел Нормативна база, където абонираните потребители могат да сравняват новите със старите версии на законите.
По-долу обобщаваме основните ТРЗ показатели, приложими от 01.04.2025 г., като обръщаме внимание, че за периода 01.01.2025 г. - 31.03.2025 г. важат ТРЗ показателите за 2024, с изключение на минималната работна заплата за страната (МРЗ), чийто размер от 01.01.2025 г. бе увеличен от 933 лв. на 1077 лв. Увеличението е в размер на 15.44%.
➤ Увеличават се размерите на минималните осигурителни доходи (МОД) по основни икономически дейности и квалификационни групи професии. Увеличението се състои в следното: тези, които са по-ниски от МРЗ за 2025 г., се изравняват с МРЗ и стават в размер на 1077 лв., а останалите остават без промяна. По-този начин за голяма част от дейностите МОД-овете от първата до последната колона са равни на 1077 лв. Виж таблица на МОД от 01.04.2025.
➤ Увеличава се минималният месечен размер на осигурителния доход за самоосигуряващите се лица (вкл. регистрираните земеделски стопани и тютюнопроизводители) в размер на 1077 лв. Запазва се регистрираните земеделски стопани и тютюнопроизводителите да не определят окончателен размер на осигурителния доход за дейността по производство на непреработена растителна и/или животинска продукция.
➤ Увеличава се максималният месечен размер на осигурителния доход от 3750 лв. на 4130 лв. Увеличението е в размер на 10.13%.
➤ За дните на лицата в неплатен отпуск се дължи здравна осигуровка върху половината от минималния размер на осигурителния доход за самоосигуряващите се лица, тоест върху 538.50 лв (увеличение).
➤ За дните на лицата във временна неработоспособност поради болест, бременност и раждане и отглеждане на малко дете се дължи здравна осигуровка от работодателя върху минималния осигурителен доход за самоосигуряващите се лица, който е в размер на 1077 лв (увеличение).
➤ Здравната вноска за безработните се изчислява на 43.08 лв. на месец (увеличение).
➤ Има промени във вноските за фонд ТЗПБ по групи основни икономически дейности при запазване на минималната и максималната граница (0.4 - 1.1 на сто). Виж таблица на ТЗПБ.
➤ Запазват се размерите и разпределението на осигурителните вноски за фондовете "Пенсии", "ОЗМ", "Безработица" и здравноосигурителната вноска. Виж Осигуровки и данъци (таблица).
➤ Запазва се нулева вноска за фонд "Гарантирани вземания на работниците и служителите" (ГВРС).
➤ Запазва се необлагаемият размер на ваучерите за храна от 200 лв. месечно за наето лице.
➤ Времето в неплатен отпуск, което се зачита за осигурителен стаж, е до 30 работни дни за календарната година.
Обезщетения и болнични за 2025 г.
➤ Запазва се периодът, от който се изчисляват краткосрочните обезщетения при:
• временна неработоспособност – 18 календарни месеца;
• безработица – 24 календарни месеца;
• бременност и раждане – 24 календарни месеца;
• трудоустрояване поради бременност или кърмене или напреднал етап на лечение ин-витро – 24 календарни месеца.
➤ Запазва се периодът на изплащане на паричното обезщетение за бременност и раждане в размер на 410 дни.
➤ Запазва се размерът на втората година майчинство от 780 лв.
➤ Право на парично обезщетение за безработица имат лицата, за които са внесени или дължими осигурителни вноски във фонд "Безработица“ най-малко 12 месеца през последните 18 месеца преди прекратяване на осигуряването.
➤ Минимален дневен размер на обезщетението за безработица – 18 лв. (без промяна), максимален размер – 107.14 лв (без промяна).
kik info
по-лесно | по-бързо | по-сигурно*
Абонамент за пълен достъп от тук.
12
Това е тема за въпроси и отговори относно:
- Електронната трудова книжка
- Единния електронния трудов запис
- Регистъра по заетостта
- и всичко свързано с промените в трудовото законодателство от 01.06.2025 г.
13
Заплати, осигуровки, болнични, майчинство » Re: 2022-2024: Въпроси за болнични
08.01.2025, 01:12Нова тема тук: https://kik-info.com/forum/index.php?topic=34717
14
Нова тема тук: https://kik-info.com/forum/index.php?topic=34718.0
15
Заплати, осигуровки, болнични, майчинство » 2025: Въпроси за Декларации Обр.1, 3 и 6
07.01.2025, 23:40Предходна тема: https://kik-info.com/forum/index.php?topic=29655.0
16
Заплати, осигуровки, болнични, майчинство » 2025: Въпроси за болнични
07.01.2025, 23:38Предходна тема: https://kik-info.com/forum/index.php?topic=29656.0
17
Статии от КиК Инфо » Ново: КИД-2025
18.12.2024, 12:43Нова Класификация на икономическите дейности (КИД-2025) е обнародвана в „Държавен вестник“, брой 106 от 17.12.2024 г., неофициален раздел със Заповед на председателя на НСИ № РД-05-950 от 29.11.2024 г.
КИД-2025 влиза в сила от 1 януари 2025 г. В тази връзка сме актуализирали справочника, където можете да търсите точните данни на дейността по име, код или части от тях тук.
КИД-2025 влиза в сила от 1 януари 2025 г. В тази връзка сме актуализирали справочника, където можете да търсите точните данни на дейността по име, код или части от тях тук.
18
През 2024 година бяха приети промени в Закона за счетоводството относно критериите за задължителен независим финансов одит от регистрирани одитори. В тази връзка в КиК Инфо сме актуализирали приложението за Проверка за задължителен одит.
Какви са промените
Първата промяна касае двойното увеличение на праговете за балансова стойност и активите и нетните приходи от продажби. Съгласно чл. 37, ал. 1 на задължителен независим финансов одит от регистрирани одитори подлежат годишните и консолидираните финансови отчети на:
1. малки предприятия, които към 31 декември на текущия отчетен период надвишават най-малко два от следните показатели:
а) балансова стойност на активите - 4 000 000 лв.;
б) нетни приходи от продажби - 8 000 000 лв.;
в) средна численост на персонала за отчетния период - 50 души;
2. средните и големите предприятия;
3. предприятията от обществен интерес;
4. средните и големите групи и групите, в които има поне едно предприятие от обществен интерес;
5. предприятия, за които това изискване е установено със закон.
Втората промяна е отпадането на критериите за задължителния одит за акционерните дружества и командитните дружества с акции, които не са микро. С други думи критериите за задължителен одит на АД и КАД вече са приравнени с критериите на останалите дружества.
Третата промяна касае одита на консолидираните отчети. Съгласно чл. 37, ал. 3 консолидираните финансови отчети и годишните финансови отчети на предприятията, включени в консолидацията, подлежат на независим финансов одит. Независимо от изискванията по изречение първо, годишният финансов отчет на предприятие, който е извън критериите по ал. 1 и е включен в консолидация, не подлежи на независим финансов одит, когато:
1. нетните приходи от продажби в годишния финансов отчет на съответното предприятие не превишават 0,5 на сто от нетните приходи от продажби в консолидирания финансов отчет на групата, и
2. балансовата стойност на активите в годишния финансов отчет на съответното предприятие не превишава 1 на сто от общата стойност на активите в консолидирания финансов отчет на групата.
Това изключение не се прилага за индивидуалния годишен финансов отчет на предприятието майка.
За по-точното и лесно определяне на това дали едно предприятие подлежи на задължителен одит, както и неговата категория, съгласно Закона за счетоводството, в КиК Инфо сме създали приложенията:
➤ Проверка за задължителен одит
➤ Проверка за задължителен одит на ЮЛНЦ
➤ Проверка за категория предприятие по ЗСч
➤ Проверка за категория на група предприятия по ЗСч
Какви са промените
Първата промяна касае двойното увеличение на праговете за балансова стойност и активите и нетните приходи от продажби. Съгласно чл. 37, ал. 1 на задължителен независим финансов одит от регистрирани одитори подлежат годишните и консолидираните финансови отчети на:
1. малки предприятия, които към 31 декември на текущия отчетен период надвишават най-малко два от следните показатели:
а) балансова стойност на активите - 4 000 000 лв.;
б) нетни приходи от продажби - 8 000 000 лв.;
в) средна численост на персонала за отчетния период - 50 души;
2. средните и големите предприятия;
3. предприятията от обществен интерес;
4. средните и големите групи и групите, в които има поне едно предприятие от обществен интерес;
5. предприятия, за които това изискване е установено със закон.
Втората промяна е отпадането на критериите за задължителния одит за акционерните дружества и командитните дружества с акции, които не са микро. С други думи критериите за задължителен одит на АД и КАД вече са приравнени с критериите на останалите дружества.
Третата промяна касае одита на консолидираните отчети. Съгласно чл. 37, ал. 3 консолидираните финансови отчети и годишните финансови отчети на предприятията, включени в консолидацията, подлежат на независим финансов одит. Независимо от изискванията по изречение първо, годишният финансов отчет на предприятие, който е извън критериите по ал. 1 и е включен в консолидация, не подлежи на независим финансов одит, когато:
1. нетните приходи от продажби в годишния финансов отчет на съответното предприятие не превишават 0,5 на сто от нетните приходи от продажби в консолидирания финансов отчет на групата, и
2. балансовата стойност на активите в годишния финансов отчет на съответното предприятие не превишава 1 на сто от общата стойност на активите в консолидирания финансов отчет на групата.
Това изключение не се прилага за индивидуалния годишен финансов отчет на предприятието майка.
За по-точното и лесно определяне на това дали едно предприятие подлежи на задължителен одит, както и неговата категория, съгласно Закона за счетоводството, в КиК Инфо сме създали приложенията:
➤ Проверка за задължителен одит
➤ Проверка за задължителен одит на ЮЛНЦ
➤ Проверка за категория предприятие по ЗСч
➤ Проверка за категория на група предприятия по ЗСч
19
През годината бяха направени изменения в Закона за счетоводството във връзка с определянето на категориите предприятия и групи предприятия.
Правилното определяне на тези категории е важна счетоводна процедура, от която зависи формата на годишния финансов отчет и неговите задължителни елементи, възможностите за облекченията за микро- и малките предприятия, предвидени в закона, както и различните законови изисквания към големите и средните предприятия. За по-точното и лесно определяне на категориите в КиК Инфо сме създали изчислителни приложения, които са в съответствие със Закона за счетоводството:
➤ Проверка за категория предприятие по ЗСч
➤ Проверка за категория на група предприятия по ЗСч
Какви са правилата за определяне на категориите предприятия
Показателите за определяне на категориите предприятия, са регламентирани в чл. 19 от Закона за счетоводството.
Микропредприятия са предприятия, които към 31 декември на текущия отчетен период не надвишават най-малко два от следните показателя:
1. балансова стойност на активите - 900 000 лв.;
2. нетни приходи от продажби - 1 800 000 лв.;
3. средна численост на персонала за отчетния период - 10 души.
Малки предприятия са предприятия, които към 31 декември на текущия отчетен период не надвишават най-малко два от следните показателя:
1. балансова стойност на активите - 10 000 000 лв.;
2. нетни приходи от продажби - 20 000 000 лв.;
3. средна численост на персонала за отчетния период - 50 души.
Средни предприятия са предприятия, които не са малки предприятия и които към 31 декември на текущия отчетен период не надвишават най-малко два от следните показателя:
1. балансова стойност на активите - 50 000 000 лв.;
2. нетни приходи от продажби - 100 000 000 лв.;
3. средна численост на персонала за отчетния период - 250 души.
Големи предприятия са предприятия, които към 31 декември на текущия отчетен период надвишават най-малко два от следните показателя:
1. балансова стойност на активите - 50 000 000 лв.;
2. нетни приходи от продажби - 100 000 000 лв.;
3. средна численост на персонала за отчетния период - 250 души.
Важно: Показателите по чл. 19 обаче не се прилагат самостоятелно, а в комбинация с правилата по чл. 20, ал. 1 и ал. 2, а именно:
(1) Промяна в категорията по чл. 19 се извършва, когато предприятие за последните два отчетни периода престане да отговаря на два от трите показателя за съответната категория. Категорията се променя от началото на следващия (трети) отчетен период.
(2) В случаите по ал. 1, когато за последните два отчетни периода предприятието отговаря на показателите за две различни категории, същото се категоризира според показателите за последния отчетен период.
Преходен режим за 2024
При определяне на категорията предприятие за 2024 година е предвиден преходен режим в Преходните и Заключителни разпоредби към Закона за изменение и допълнение на закона за счетоводството (обн. - дв, бр. 72 от 2024 г., в сила от 06.07.2024 г.) Съгласно § 29, ал. 1 и ал. 2, предприятията и групите предприятия определят категорията си за 2024 г. в съответствие с изменените чл. 19 и 21 съгласно показателите си към 31 декември 2023 г. За целите на прилагането на чл. 20, ал. 1 и 2 и чл. 22 се счита, че 2024 г. е първият отчетен период.
Преходният режим за 2024 също е предвиден в приложението ➤ Проверка за категория предприятие по ЗСч.
Какви са правилата за определяне на категориите групи предприятия
Показателите за определяне на категориите групи предприятия, са регламентирани в чл. 21 от Закона за счетоводството.
Малки групи са групи предприятия, на които сумата от показателите съгласно годишните им финансови отчети на консолидирана основа, съставени към 31 декември на текущия отчетен период, не надхвърля праговете най-малко на два от следните три показателя:
1. балансова стойност на активите - 10 000 000 лв.;
2. нетни приходи от продажби - 20 000 000 лв.;
3. средна численост на персонала за отчетния период - 50 души.
Средни групи са групи предприятия, които не са малки групи, на които сумата от показателите съгласно годишните им финансови отчети на консолидирана основа, съставени към 31 декември на текущата година, не надхвърля праговете най-малко на два от следните три показателя:
1. балансова стойност на активите - 50 000 000 лв.;
2. нетни приходи от продажби - 100 000 000 лв.;
3. средна численост на персонала за отчетния период - 250 души.
Големи групи са групи предприятия, на които сумата от показателите съгласно годишните им финансови отчети на консолидирана основа, съставени към 31 декември на текущата година, надхвърля праговете най-малко на два от следните три показателя:
1. балансова стойност на активите - 50 000 000 лв.;
2. нетни приходи от продажби - 100 000 000 лв.;
3. средна численост на персонала за отчетния период - 250 души.
Категориите на групите предприятия могат да се определят и на основа на сбора на стойностите на показателите съгласно индивидуалните годишни финансови отчети на предприятията от групата, съставени към 31 декември на текущия отчетен период. В този случай при определяне на категорията на групата праговете на показателите за балансова стойност на активите и нетни приходи от продажби по ал. 2, 3 и 4 се увеличават с 20 на сто.
Важно: Показателите по чл. 21 не се прилагат самостоятелно, а в комбинация с правилата в чл. 22, ал. 1 и ал. 2, а именно:
(1) Промяна в категорията по чл. 21 се извършва, когато за последните два отчетни периода група престане да отговаря на два от трите показателя за съответната категория. Категорията се променя от началото на следващия отчетен период.
(2) В случаите по ал. 1, когато за последните два отчетни периода група отговаря на показателите за две различни категории, тя се категоризира съгласно показателите за последния отчетен период.
Преходен режим за 2024 и за категориите групи предприятия
При определяне на категорията групи предприятия за 2024 година също е предвиден преходен режим в Преходните и Заключителни разпоредби към Закона за изменение и допълнение на закона за счетоводството (обн. - дв, бр. 72 от 2024 г., в сила от 06.07.2024 г.) Съгласно § 29, ал. 1 и ал. 2, предприятията и групите предприятия определят категорията си за 2024 г. в съответствие с изменените чл. 19 и 21 съгласно показателите си към 31 декември 2023 г. За целите на прилагането на чл. 20, ал. 1 и 2 и чл. 22 се счита, че 2024 г. е първият отчетен период.
Всички тези правила, както и преходни режими за категории предприятия и за категории групи предприятия са заложени в приложенията:
➤ Проверка за категория предприятие по ЗСч
➤ Проверка за категория на група предприятия по ЗСч
Правилното определяне на тези категории е важна счетоводна процедура, от която зависи формата на годишния финансов отчет и неговите задължителни елементи, възможностите за облекченията за микро- и малките предприятия, предвидени в закона, както и различните законови изисквания към големите и средните предприятия. За по-точното и лесно определяне на категориите в КиК Инфо сме създали изчислителни приложения, които са в съответствие със Закона за счетоводството:
➤ Проверка за категория предприятие по ЗСч
➤ Проверка за категория на група предприятия по ЗСч
Какви са правилата за определяне на категориите предприятия
Показателите за определяне на категориите предприятия, са регламентирани в чл. 19 от Закона за счетоводството.
Микропредприятия са предприятия, които към 31 декември на текущия отчетен период не надвишават най-малко два от следните показателя:
1. балансова стойност на активите - 900 000 лв.;
2. нетни приходи от продажби - 1 800 000 лв.;
3. средна численост на персонала за отчетния период - 10 души.
Малки предприятия са предприятия, които към 31 декември на текущия отчетен период не надвишават най-малко два от следните показателя:
1. балансова стойност на активите - 10 000 000 лв.;
2. нетни приходи от продажби - 20 000 000 лв.;
3. средна численост на персонала за отчетния период - 50 души.
Средни предприятия са предприятия, които не са малки предприятия и които към 31 декември на текущия отчетен период не надвишават най-малко два от следните показателя:
1. балансова стойност на активите - 50 000 000 лв.;
2. нетни приходи от продажби - 100 000 000 лв.;
3. средна численост на персонала за отчетния период - 250 души.
Големи предприятия са предприятия, които към 31 декември на текущия отчетен период надвишават най-малко два от следните показателя:
1. балансова стойност на активите - 50 000 000 лв.;
2. нетни приходи от продажби - 100 000 000 лв.;
3. средна численост на персонала за отчетния период - 250 души.
Важно: Показателите по чл. 19 обаче не се прилагат самостоятелно, а в комбинация с правилата по чл. 20, ал. 1 и ал. 2, а именно:
(1) Промяна в категорията по чл. 19 се извършва, когато предприятие за последните два отчетни периода престане да отговаря на два от трите показателя за съответната категория. Категорията се променя от началото на следващия (трети) отчетен период.
(2) В случаите по ал. 1, когато за последните два отчетни периода предприятието отговаря на показателите за две различни категории, същото се категоризира според показателите за последния отчетен период.
Преходен режим за 2024
При определяне на категорията предприятие за 2024 година е предвиден преходен режим в Преходните и Заключителни разпоредби към Закона за изменение и допълнение на закона за счетоводството (обн. - дв, бр. 72 от 2024 г., в сила от 06.07.2024 г.) Съгласно § 29, ал. 1 и ал. 2, предприятията и групите предприятия определят категорията си за 2024 г. в съответствие с изменените чл. 19 и 21 съгласно показателите си към 31 декември 2023 г. За целите на прилагането на чл. 20, ал. 1 и 2 и чл. 22 се счита, че 2024 г. е първият отчетен период.
Преходният режим за 2024 също е предвиден в приложението ➤ Проверка за категория предприятие по ЗСч.
Какви са правилата за определяне на категориите групи предприятия
Показателите за определяне на категориите групи предприятия, са регламентирани в чл. 21 от Закона за счетоводството.
Малки групи са групи предприятия, на които сумата от показателите съгласно годишните им финансови отчети на консолидирана основа, съставени към 31 декември на текущия отчетен период, не надхвърля праговете най-малко на два от следните три показателя:
1. балансова стойност на активите - 10 000 000 лв.;
2. нетни приходи от продажби - 20 000 000 лв.;
3. средна численост на персонала за отчетния период - 50 души.
Средни групи са групи предприятия, които не са малки групи, на които сумата от показателите съгласно годишните им финансови отчети на консолидирана основа, съставени към 31 декември на текущата година, не надхвърля праговете най-малко на два от следните три показателя:
1. балансова стойност на активите - 50 000 000 лв.;
2. нетни приходи от продажби - 100 000 000 лв.;
3. средна численост на персонала за отчетния период - 250 души.
Големи групи са групи предприятия, на които сумата от показателите съгласно годишните им финансови отчети на консолидирана основа, съставени към 31 декември на текущата година, надхвърля праговете най-малко на два от следните три показателя:
1. балансова стойност на активите - 50 000 000 лв.;
2. нетни приходи от продажби - 100 000 000 лв.;
3. средна численост на персонала за отчетния период - 250 души.
Категориите на групите предприятия могат да се определят и на основа на сбора на стойностите на показателите съгласно индивидуалните годишни финансови отчети на предприятията от групата, съставени към 31 декември на текущия отчетен период. В този случай при определяне на категорията на групата праговете на показателите за балансова стойност на активите и нетни приходи от продажби по ал. 2, 3 и 4 се увеличават с 20 на сто.
Важно: Показателите по чл. 21 не се прилагат самостоятелно, а в комбинация с правилата в чл. 22, ал. 1 и ал. 2, а именно:
(1) Промяна в категорията по чл. 21 се извършва, когато за последните два отчетни периода група престане да отговаря на два от трите показателя за съответната категория. Категорията се променя от началото на следващия отчетен период.
(2) В случаите по ал. 1, когато за последните два отчетни периода група отговаря на показателите за две различни категории, тя се категоризира съгласно показателите за последния отчетен период.
Преходен режим за 2024 и за категориите групи предприятия
При определяне на категорията групи предприятия за 2024 година също е предвиден преходен режим в Преходните и Заключителни разпоредби към Закона за изменение и допълнение на закона за счетоводството (обн. - дв, бр. 72 от 2024 г., в сила от 06.07.2024 г.) Съгласно § 29, ал. 1 и ал. 2, предприятията и групите предприятия определят категорията си за 2024 г. в съответствие с изменените чл. 19 и 21 съгласно показателите си към 31 декември 2023 г. За целите на прилагането на чл. 20, ал. 1 и 2 и чл. 22 се счита, че 2024 г. е първият отчетен период.
Всички тези правила, както и преходни режими за категории предприятия и за категории групи предприятия са заложени в приложенията:
➤ Проверка за категория предприятие по ЗСч
➤ Проверка за категория на група предприятия по ЗСч
20
Статии от КиК Инфо » Календар с работните дни за 2025 година
10.12.2024, 08:29На сайта е публикуван новия календар с работните и почивните дни за 2025 г.
От тук можете да изтеглите в PDF календара на КиК Инфо за 2025 на български език, а на английски - от тук.
Годината ще има 249 работни дни и 1992 работни часа. Официалните празници за 2025-та година са:
➤ Нова година - 1 януари (сряда)
➤ Освобождението - 3 март (понеделник)
➤ Великден - 20 април (почива се от 18 до 21 април вкл.)
➤ Ден на труда - 1 май (четвъртък)
➤ Гергьовден - 6 май (вторник)
➤ Ден на Светите братя Кирил и Методий, на българската азбука, просвета и култура - 24 май (събота), почива се на 26 май
➤ Ден на Съединението - 6 септември (събота), почива се на 8 септември
➤ Ден на Независимостта - 22 септември (понеделник)
➤ Коледа - 24, 25 и 26 декември.
Съгласно Кодекса на труда, когато официалните празници, с изключение на Великденските празници, съвпадат със събота и/или неделя, първият или първите два работни дни след тях са неприсъствени.
От тук можете да изтеглите в PDF календара на КиК Инфо за 2025 на български език, а на английски - от тук.
Годината ще има 249 работни дни и 1992 работни часа. Официалните празници за 2025-та година са:
➤ Нова година - 1 януари (сряда)
➤ Освобождението - 3 март (понеделник)
➤ Великден - 20 април (почива се от 18 до 21 април вкл.)
➤ Ден на труда - 1 май (четвъртък)
➤ Гергьовден - 6 май (вторник)
➤ Ден на Светите братя Кирил и Методий, на българската азбука, просвета и култура - 24 май (събота), почива се на 26 май
➤ Ден на Съединението - 6 септември (събота), почива се на 8 септември
➤ Ден на Независимостта - 22 септември (понеделник)
➤ Коледа - 24, 25 и 26 декември.
Съгласно Кодекса на труда, когато официалните празници, с изключение на Великденските празници, съвпадат със събота и/или неделя, първият или първите два работни дни след тях са неприсъствени.