След обществени консултации, десетки становища и последвала среща с бизнеса, НАП публикува финалната
заповед по чл. 71к, ал. 4 от ДОПК и техническите приложения към нея, които регламентират въвеждането на SAF-T. Новите правила внасят редица промени и уточнения спрямо първоначалния проект, като част от тях са директен резултат от активния диалог с професионалната общност. В настоящата статия ще направим подробен преглед на финалната рамка и нейното практическо приложение. Ще разгледаме в детайли изискванията за всеки от трите вида файлове – месечен, годишен и "при поискване". Ще разгледаме кои са задължителните полета, и ще отправим конкретни практически препоръки както към бизнеса и счетоводителите, така и към разработчиците на счетоводен софтуер.
Месечен SAF-T файл
Срок за подаване: до 14-то число на следващия месец. След проведена среща между НАП и бизнеса Агенцията принципно възприе предложението да се преразгледа крайният срок за ежемесечно подаване на SAF-T файла и предприятията да могат да подават файла до 30-то число на следващ месец. Обсъдена бе идеята за удължаване на предвидения в закона гратисен период за нововъзникнали задължения по SAF-T от 6 на 12 месеца. НАП се съгласи с необходимостта от допълнително време за адаптация.
Какво съдържа месечният файл?Съгласно официалните указания, месечният SAF-T файл съдържа обобщена информация от няколко ключови секции.
1. Главна страница (Header):Тази секция е "паспортът" на файла и съдържа следната ключова информация.
» Идентификация на дружеството: Име, ЕИК, ДДС номер, адрес, контакти и IBAN.
» Параметри на файла: Отчетен период, дата на създаване и валута.
» Данни за софтуера: Име на софтуерната компания, наименование и версия на продукта.
» Информация за действителните собственици и участие в група. (незадължително)
2. Основни данни (MasterFiles):
Това са основните номенклатури, които счетоводството използва. Тук е мястото, където се подават и началните и крайни салда за периода. Задължителните за подаване подсекции са:
» Счетоводни сметки (GeneralLedgerAccounts): Включително дебитно/кредитно салдо в началото и в края на периода за всяка сметка.
» Клиенти (Customers) и Доставчици (Suppliers): Включително начално и крайно салдо за всеки контрагент, участвал в транзакции през месеца.
» Продукти (Products): Номенклатурата на стоките и услугите, които предприятието фактурира.
» Данъчна таблица (Tax Table) и Таблица с мерни единици (UOMTable).
3. Счетоводни записи (GeneralLedgerEntries):
Тук се включват всички счетоводни операции, направени през отчетния месец, представени на ниво транзакция. Чрез подаването на пълния списък с операции имплицитно се предоставя и информацията за месечните обороти по сметките.
4. Изходни документи (SourceDocuments): Това е най-детайлната секция, изискваща информация за:
» Фактури за продажби (SalesInvoices): Всички издадени фактури и известия.
» Фактури за покупки (PurchaseInvoices): Всички получени фактури и известия.
» Плащания (Payments): Информация за извършените и получени плащания.
Подава се изключителна детайлна информация за всички фактури за покупки и продажби, както и за всички плащания, извършени през месеца. За всяка фактура се изисква детайлно отчитане "ред по ред", което включва попълване на количество, мерна единица и единична цена за всеки отделен артикул или услуга от всеки ред, освен ако тази фактура не е за директен разход (постигнато важно изключение в хода на обществените консултации).
Важно уточнение: В структурата на SAF-T съществува и опционална секция CorrespondingAccountsRep
ort ("Главна книга"), която представлява обобщена справка за салда и обороти. Важно е да се знае, че нейното подаване не е задължително. Изясняването на този детайл е ключово, защото спестява значителни усилия на бизнеса и на разработчиците на софтуер.
Подаване и корекции на SAF-T файл
Подаването се извършва по електронен път през услуга в портала на НАП с КЕП или чрез API. При установяване на несъответствия, НАП отхвърля файла и предоставя 7-дневен срок за отстраняването им чрез подаване на нов файл. Корекция на вече приет файл се извършва чрез подаване на изцяло нов, заместващ файл за същия период.
Грешки от минали периоди се осчетоводяват в текущия, като се използват полетата SystemEntryDate (реална дата на записа) и GLPostingDate (дата, към която се отнася операцията), за да се покаже на НАП, че се коригира минал период.
След като SAF-T файлът за даден месец е генериран и подаден към НАП, данните за този период трябва да се считат за финални. Всяка последваща, неконтролирана промяна на счетоводен запис в този "затворен" период създава сериозен риск от разминаване между счетоводната база на дружеството и подадената към НАП информация. Затова е препоръчително счетоводният софтуер да въведе ясен
механизъм за "заключване" на отчетен период след генерирането и подаването на SAF-T файла. Това "заключване" трябва да ограничава възможността за инцидентни редакции или изтривания на операции в периода. Всяка необходима корекция трябва да се извършва по официално установения ред - чрез коригиращи операции, осчетоводени в текущ период, или чрез генериране на изцяло нов, заместващ SAF-T файл. Такава функционалност ще гарантира интегритета на данните и ще предпази предприятията от неволни грешки и последващи данъчни рискове.
Ключови промени и нови правила (от Приложение № 3 и срещата с НАП)
Директни разходи: Фактури за покупки, отчитани директно като разход (ток, вода, консумативи),
могат да се отчитат обобщено на един ред, като за ProductCode се посочва "0" и се добавя текстово описание.
Отчет за продажбите: Продажби към данъчно незадължени лица, документирани с "Отчет за извършени продажби", също се подават обобщено, като за ProductCode се посочва "0".
Протоколи » Фактури: При наличие на протокол (напр. за самоначисляване на ДДС при ВОП) или митническа декларация, в SourceDocuments се подават данните от протокола/декларацията, а не от фактурата към тях.
Защитена информация: Въведени са специални правила за агрегирано/обобщено подаване на данни от банки, застрахователи и лечебни заведения с цел защита на банковата, застрахователната и здравната тайна.
Сделки със свързани лица: Потвърдено бе, че изискването за деклариране на сделки със свързани лица ще остане като част от задължителната информация в SAF-T файла. Това условие е елемент от стандартизирания формат и предоставя на НАП важна информация; приходната администрация държи на запазването му предвид значимостта за данъчния контрол.
Достъп до подадени SAF-T данни: НАП потвърди, че при поискване от данъчно задължено лице, Агенцията ще предоставя обратно на това лице данните от вече подадените от него SAF-T файлове за предходни отчетни периоди. По този начин предприятията ще имат достъп до собствените си исторически данни, подадени към НАП, при необходимост от справка или проверка.
Незадължителни полета: Структурата на SAF-T съдържа и множество незадължителни полета. На срещата с НАП бе изяснено, че тези полета ще останат по избор на предприятията. Непопълването им няма да води до отхвърляне или невалидност на подадения файл, нито ще носи негативни последици за подаващото лице.
Въпреки това, представянето на стотици полета на екрана може да доведе до объркване и грешки. В тази връзка, препоръчително е софтуерните решения да предложат гъвкав интерфейс, който по подразбиране
да показва само задължителните полета. Потребителят трябва да има възможност, при желание или специфична необходимост, да активира и визуализира допълнителните, незадължителни полета. Този подход ще направи процеса по подготовка и преглед на файла много по-интуитивен и ще намали риска от грешки.
Задължителни полета
За да обхванем работата, която ни предстои, по-долу сме обобщили най-важните задължителни и условно задължителни полета за основните секции. Официалните документи, които имаме, не предоставят пълен списък кое индивидуално поле е задължително и кое не. Те дефинират задължителни/незадължителни цели секции. Списъкът по-долу е експертна интерпретация на това кои полета са логически и функционално задължителни, за да може една секция да съществува и да е пълноценна.
Задължителни и условно задължителни полета при фактурите: Номер на фактура, Номер на счетоводна операция, Дата на фактура, Дата на данъчно събитие, Вид на фактурата, Уникален код на клиента/доставчика, Име на клиента/доставчика, Град, Държава на клиента/доставчика, Номер на реда във фактурата, Уникален код на продукта/услугата, Описание на продукта/услугата, Код по Комбинираната номенклатура, Количество, Мерна единица, Единична цена, Нетна стойност на реда, Код на счетоводна сметка, Вид на данъка, Данъчен код, Брой на записите за фактури, Обща сума на дебитите, Обща сума на кредитите, Идентификатор/референция към транзакцията, Индикатор за самофактуриране.
Задължителни полета за доставчик или клиент: Име, ЕИК, ДДС номер (ако е регистриран), Град, Кодът на държавата (напр. "BG"), Индикатор за свързано лице, Начална дата на свързаност, Уникален код на контрагента, Счетоводна сметка за разчети, Начално дебитно салдо, Начално кредитно салдо, Крайно дебитно салдо, Крайно кредитно салдо.
Задължителните полета при плащания: Уникален номер на документа за плащане, Дата на транзакцията, Тип на плащането, Описание, Идентификатор на системата, Метод на плащане, Идентификатор на потребителя, Номер на реда, Номер на свързания документ, Сума по дебит или Сума по кредит, Брой на записите за плащания, Обща сума на дебитите, Обща сума на кредитите, Номер на свързания документ.
Задължителни полета за Счетоводните записвания (GeneralLedgerEntries): Идентификатор/референция към транзакцията, Период, Дата на документа/транзакцията, Описание на транзакцията, Дата на системно въвеждане, Дата на осчетоводяване, Уникален идентификатор на счетоводния запис, Код на аналитична счетоводна сметка, Сума по дебит или Сума по кредит, Брой на записите, Обща сума на дебитите, Обща сума на кредитите, Идентификатор на потребителя - посочва се потребителското име (User ID) на служителя, въвел записа в системата.
Задължителните полета за Индивидуалния сметкоплан (GeneralLedgerAccounts): Уникален код на счетоводна сметка, Описание на счетоводна сметка, Начално дебитно салдо, Начално кредитно салдо, Крайно дебитно салдо, Крайно кредитно салдо, Група на сметката, Тип на сметката.
Какво трябва да направят компаниите, когато счетоводството и склада се водят в отделни софтуери?
Един от най-често срещаните и ефективни модели на работа в българската практика е разделението между софтуера за управление на търговската дейност (продажби, склад) и чисто счетоводния софтуер.
Защо съществува това разделение?
Този модел не е случаен, а е резултат от специфичните нужди на всяка дейност:
Търговският софтуер (често наричан и "складов" или "front-office") е силно специализиран и съобразен конкретния бизнес модел – управление на рецепти в ресторант, работа с баркодове в магазин, управление на производствени поръчки, прехвърляне от склад в склад и т.н. В този софтуер липсва счетоводната част.
Счетоводният софтуер, от своя страна, е оптимизиран за съвсем други цели. Той е силно фокусиран върху нуждите на счетоводния процес: бърза обработка на документи, автоматизация на записванията и генериране на специфични справки, нужни само за счетоводството (оборотни ведомости, регистри по сметки, ДДС дневници и др.). Поради този счетоводен фокус, в него по правило не се поддържа информация за количества, мерни единици и единични цени по артикули – данни, които са от ключово значение за детайлността, изисквана от SAF-T.
Икономическа ефективност: Този двукомпонентен модел често е по-гъвкав и значително по-достъпен от внедряването на една голяма, сложна и скъпа ERP система. Освен това всеки избира софтуера според нуждите си. Клиентът според нуждите на водене на склада, счетоводната кантора според нуждите за бързодействие в кратките срокове на данъчното законодателство. И всяка страна отговаря за актуализацията и поддръжката на софтуера, с който тя работи.
Досега този модел работеше отлично. Търговската система управляваше склада и продажбите, а в счетоводния софтуер се завежда само обобщена информация без количества и стойности.
SAF-T обаче променя това из основи. Изискването за подаване на детайлна, "ред по ред" информация за всяка отделна фактура (продукт, количество, цена) в секция SalesInvoices означава, че обобщените данни вече не са достатъчни. Пълната информация съществува, но е разпръсната
в две отделни системи.
Специалните случаи: Когато един софтуер не е достатъчен
В редица индустрии използването на специализиран софтуер за управление на дейността не е въпрос на избор, а необходимост, наложена от
други закони или от самата сложност на бизнес процеса. В тези случаи разделението между оперативната и счетоводната система е практически безалтернативно. Ето няколко примера, които илюстрират тази реалност:
»
Хранително-вкусова промишленост (ХВП) и фармация: Тези сектори са обект на строги регулации (напр. HACCP) за проследяемост на партидите на суровини и готова продукция.
»
Медицински изделия и лекарства: Изискванията за проследяване на всяка опаковка правят използването на специализирани системи задължително.
»
Строителство и производство: Компаниите използват софтуери за управление на проекти, които следят разход на материали по обекти и работа на подизпълнители.
»
Транспорт и логистика: Управлението на автопаркове, работното време на шофьорите и разходът на гориво се извършват в специализирани системи.
За тези и други предприятия преминаването към единна ERP система често не е работещо решение, тъй като така рискуват да не покрият специфичните изисквания на своя бизнес модел или на други, неданъчни закони. Ето защо, интеграцията между специализираната оперативна и счетоводната система се превръща от препоръка в абсолютна необходимост. Предвид технологичната сложност на подобен проект, препоръката към тези компании е
да започнат процеса по планиране и комуникация със софтуерните си партньори възможно най-скоро, независимо колко далечен изглежда техният индивидуален срок за въвеждане на SAF-T.
Пътят напред: Варианти за действие: Как да обединим данните от двете системи?
След като установихме, че синхронизацията на данните между оперативната и счетоводната система е абсолютна необходимост, възниква въпросът какви са възможните решения.
Вариант 1: Ръчно прехвърляне на данни
Това е теоретично най-простият подход, при който данните за всяка продажба от търговския софтуер се въвеждат ръчно, ред по ред, в счетоводния софтуер.
»
Предимства: Не изисква първоначални разходи за софтуерна разработка или интеграция.
»
Недостатъци: Процесът е изключително бавен, трудоемък и изисква огромен човешки ресурс. Ръчното въвеждане е предпоставка за множество грешки – сбъркани кодове, количества, цени – всяка от които може да компрометира целия SAF-T файл. Този подход е практически неприложим и неустойчив за компании с повече от няколко фактури на месец.
»
Препоръка: Силно непрепоръчителен подход. Да се избягва на всяка цена, освен при микропредприятия с единични продажби на месец. Рискът от грешки и цената на вложения труд далеч надхвърлят краткосрочните икономии.
Вариант 2: Интеграция между системитеТова е препоръчителният и стратегически правилен подход. Той включва създаването на софтуерна "връзка", която позволява автоматизиран обмен на информация между търговската и счетоводната програма, дори те да са от различни доставчици.
»
Предимства: Спестява стотици часове ръчен труд. Елиминира риска от човешки грешки при прехвърлянето на данните.
»
Недостатъци: Изисква разходи за разработка или закупуване на модули за експорт (от търговския софтуер) и импорт (в счетоводния софтуер). Изисква активен диалог и сътрудничество между клиента и двата му софтуерни доставчика.
»
Препоръка: Това е най-балансираният и работещ модел за огромната част от предприятията. Инвестицията в интеграция е инвестиция в сигурността, точността и ефективността на счетоводния процес в новата дигитална ера.
Вариант 3: Специализиран софтуер-агрегаторПри този подход се използва трети, специализиран софтуер, който действа като посредник. Той се свързва с базите данни на двете системи (търговска и счетоводна), извлича необходимата информация, обединява я и сам генерира финалния SAF-T файл.
»
Предимства: Може да се справи с много сложни казуси и да обединява данни от повече от две системи. Не е нужно основните Ви софтуери да имат специфична SAF-T функционалност, а само да позволяват достъп до данните си.
»
Недостатъци: Обикновено това е най-скъпото от трите решения. Въвежда още една система и доставчик, които трябва да се управляват и поддържат.
»
Препоръка: Подходящо решение предимно за големи корпорации със сложна IT инфраструктура и множество разнородни системи, където ползите от подобен "хъб" за данни оправдават цената и сложността.
Годишен SAF-T файл – какво съдържа и кога се подава?
Срок за подаване: Подава се веднъж годишно, в срока за подаване на годишната данъчна декларация по чл. 92 от ЗКПО.
Какво съдържа: Този файл не е просто "по-голям" месечен файл. Той е тясно специализиран и съдържа информация единствено за дълготрайните активи на предприятието. В него се включват две основни подсекции:
» Активи (Assets): На практика, това е пълният амортизационен план на дружеството, съдържащ данни за всеки актив – дата на придобиване, стойност, метод на амортизация, натрупана амортизация, балансова стойност и др.
» Транзакции с активи (AssetTransactions): Включва информация за всички движения на дълготрайни активи през годината – придобиване, продажба, брак, преоценка и др.
Промени при отчитане на дълготрайни активи:
» Има съществена промяна между първоначалния проект и финалната версия на SAF-T засяга отчитането на транзакциите с дълготрайни активи. В първоначалния проект се е изискваше информацията за транзакции с активи (AssetTransactions) да се подава "при поискване", заедно с данните за стоковите наличности. Във финалната, действаща версия, това изискване е преместено в годишния SAF-T файл. По този начин данните за активите се подават еднократно на годишна база, а файлът "при поискване" остава фокусиран само върху данните за стоково-материалните запаси.
SAF-T файл при поискване от НАП – съдържание и срок
Срок за подаване: 14- дневен срок при поискване от НАП. Подава се само и единствено при поискване от орган по приходите в хода на контролно производство (напр. ревизия или проверка).
Какво съдържа и защо е свързан с интеграцията между счетоводния и складовия софтуер:Файлът изисква изключително детайлна информация за стоково-материалните запаси (СМЗ). Той трябва да предостави на НАП пълна картина на склада за определен от тях период. Освен основните секции като Header и номенклатури (Products, UOMTable и др.), той включва две специфични подсекции:
Наличности (PhysicalStock): Тук се изискват не само начални/крайни количества и стойности, но и данни за всеки артикул поотделно, включително:
» Идентификатор на склада (WarehouseID)
» Код на продукта/материалния запас (ProductCode)
» ЕИК на собственика на стоката (OwnerID), ако стоката е чужда
» Мерна единица на наличността (UOMPhysicalStock)
» Единична цена на стоката (UnitPrice)
» Начално количество и стойност за периода (OpeningStockQuantity, OpeningStockValue)
» Крайно количество и стойност за периода (ClosingStockQuantity, ClosingStockValue)
Движения (Movement of Goods): Тази секция изисква пълен опис на всяко едно движение на СМЗ (покупки, продажби, брак, прехвърляне и др.). За всяко движение се подават данни като:
На ниво документ за движение:
» Уникален ID на документа за движение (MovementReference)
» Дата на документа (MovementDate)
» Вид на движението от номенклатура (MovementType)
На ниво ред в документа за движение:
» Номер на реда (LineNumber)
» Код на продукта (ProductCode)
» Количество (Quantity)
» Мерна единица (UnitOfMeasure)
» Счетоводна сметка, свързана с движението (AccountID)
» Връзка към счетоводна статия (TransactionID)
Последните
две полета (в болд) са именно тези, които създават задължителната връзка със счетоводния софтуер и налагат необходимостта от интеграция или обединяване на файловете между складовия и счетоводния софтуер, ако не се работи в една система.
Успешното внедряване на SAF-T зависи в огромна степен от адекватността и удобството на счетоводните и ERP системи. Освен базовото генериране на XML файла, софтуерните разработчици могат да улеснят значително своите потребители, като предвидят множество ключови функционалности, интерграции и подобрения в потребителския интерфейс.
Да припомним кой и кога е задължен да подава SAF-T?
Въвеждането на SAF-T в България ще се случи поетапно в рамките на пет години, като предприятията са разделени на групи според размера и финансовите им показатели за предходни периоди. Ето какъв е графикът, разписан в § 17 от Преходните и заключителни разпоредби на ДОПК:
Първа група (от 1 януари 2026 г.):
» Това са най-големите компании в България. Задължението възниква за предприятия, които към края на 2023 г. са "големи" по смисъла на Закона за счетоводството и същевременно отговарят на поне едно от двете условия: нетни приходи от продажби над 300 млн. лв. за 2023 г.
или платени към НАП данъци и осигуровки над 3.5 млн. лв. за 2023 г.
Втора група (от 1 януари 2027 г.):
» Тук попадат предприятия, които покриват същите високи финансови критерии (приходи > 300 млн. лв.
или данъци > 3.5 млн. лв.), но на база данни за
2024 г.Трета група (от 1 януари 2028 г.):
» Следващата вълна от по-големи предприятия, за които праговете са значително по-ниски: нетни приходи от продажби над 15 млн. лв. за 2025 г.
или платени към НАП данъци и осигуровки над 1.5 млн. лв. за 2025 г.
Четвърта група (от 1 януари 2029 г.):
» Тази група обхваща масово останалите предприятия. Задължени стават всички, които към 31 декември 2026 г. се класифицират като големи, средни или малки по Закона за счетоводството.
Пета група (от 1 януари 2030 г.):
» Това е финалната група, която включва всички останали задължени лица, които не са попаднали в предходните групи. Това са предимно микропредприятията, регистрирани по ЗДДС.
Важно за срока за корекции: Законът уточнява, че за всяка от тези групи шестмесечният период за извършване на корекции в подадените файлове започва да тече от датата на възникване на задължението им (напр. от 01.01.2026 г. за първата група).
Заключение и препоръки към бизнеса и счетоводителите
Макар законовият график да дава значителен хоризонт за адапатация, особено за средните и малки предприятия, мащабът на изискваните промени в софтуера и процесите превръща подготовката в дългосрочен стратегически проект. Внедряването на SAF-T не е еднократна задача, а процес, който изисква проактивен подход и навременна подготовка. За да бъде преходът плавен и успешен, препоръчваме на всяко предприятие, заедно със своя счетоводител, да предприеме следните три ключови стъпки:
1. Направете вътрешен одит на Вашите процеси и данни
Преди да търсите софтуерни решения, трябва да сте наясно с текущото си състояние. Задайте си следните въпроси:
Разбираме ли изискванията? Запознайте се в детайли с новите правила. Разберете кои секции и полета се отнасят за Вашия бизнес.
Къде се намират данните ни? Направете карта на информацията. Отговорете на въпроса: "Къде в нашите системи се намира всяко задължително поле за SAF-T?". Този анализ веднага ще покаже пропуските и предизвикателствата, особено ако работите с отделни софтуери за склад и счетоводство.
Какви са пропуските? Идентифицирайте конкретните проблеми – липса на детайли за фактури в счетоводната програма, несвързаност на сметкоплана със стандартната таксономия, липса на одитна следа за потребителите и др.
2. Започнете диалог със софтуерните си партньори НЕЗАБАВНО
Разработката и внедряването на толкова мащабни промени отнема месеци. Не чакайте последния момент. Свържете се с доставчиците на Вашия счетоводен и оперативен (търговски, складов) софтуер още днес и им задайте конкретни въпроси:
Към доставчика на счетоводен софтуер: "
Каква е Вашата пътна карта за съвместимост със SAF-T? Ще разработите ли модул за импорт на детайлни данни от външни системи? Какъв формат на данните ще изисквате?"
Към доставчика на складов софтуер: "
Планирате ли да разработите модул за експорт на данни (фактури, складови движения), който да е съвместим с изискванията на SAF-T и да може лесно да се подаде към счетоводна програма?"
Ясните отговори на тези въпроси ще Ви дадат представа дали настоящите Ви софтуерни партньори могат да отговорят на нуждите Ви, или трябва да търсите алтернативи.
3. Планирайте необходимите ресурси – време и финанси
Преходът към SAF-T е инвестиционен проект. Той изисква планиране на ресурси:
Финансови ресурси: Актуализациите на софтуера, разработката на нови модули за интеграция или дори преминаването към нова система ще имат своята цена. Предвидете тези разходи в бюджета си.
Човешки ресурси: Процесът по анализ, тестване на новите функционалности и обучение на екипа ще изисква значително време от страна на счетоводния отдел и мениджмънта. Това не е задача, която може да се свърши между другото.
Стартирането на тези три стъпки днес, независимо колко далечен изглежда вашият срок за влизане в задължение, е най-сигурната гаранция за спокойна и безпроблемна адаптация към новата дигитална реалност.