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