SAF‑T и вашата ERP система: какво покрива модулът и какво остава за вас

Гледайте на модула като на производствена линия: той преобразува наличните записи в изискуемата структура. Ако входящите данни са пълни и съгласувани, модулът ускорява процеса. Ако съдържат исторически несъответствия или дублирани номенклатури, модулът пренася тези проблеми във файла.

Има и втори слой риск: НАП проверява и консистентността на данните между регистрите, затова никой генератор не може да се оценява само по това дали създава технически валиден файл. В един реален случай срещу SAF‑T модула на ERP доставчик са върнати около 5 000 грешки при проверка. Фактът не сочи конкретен доставчик: той показва, че модулът генерира, а успешното подаване зависи от данните и проверките около него.

Главната книга е във финансовата система, продажбите и покупките в отделни модули, наличностите в складова система, регистърът на активите в специализиран модул, плащанията в банкови интерфейси. Този разрив между източниците е разлика, която остава невидима до момента на проверка: контрагент с един идентификатор във фактурирането и друг в счетоводството, артикул, архивиран в склада, но жив в исторически документи, данъчен код, сменен в нов период без картографиране на старите записи.

Затова SAF‑T проектът започва с карта на данните. Не с въпроса дали има модул, а с въпросите откъде идва всеки блок от файла, кой притежава данните и как се доказва, че са съгласувани.

Месечният файл се подава до края на месеца след отчетния (чл. 71к, ал. 1 ДОПК, изм. ДВ, бр. 65 от 08.08.2025 г.), а при отказ чл. 277а ДОПК изисква коригиран файл в 7-дневен срок. Това оставя малко място за ръчни експорти и неформални проверки по имейл.

Ръчният подход носи три риска: различни хора с различни версии на номенклатурите, корекция в един месец, която не става правило за следващия, и знание за грешка, което остава при отделен служител. Автоматизацията не значи подаване без контрол: тя значи повторяеми проверки, проследима версия на данните и ясно одобрение от отговорните финансови лица.

1. 01

   Коя версия на българската SAF‑T структура поддържа модулът и как се управляват бъдещи промени?

2. 02

   Кои части от файла се попълват директно от ERP и кои изискват допълнителни източници?

3. 03

   Как модулът валидира данните преди генериране и какви проверки извършва извън XSD?

4. 04

   Има ли контролни отчети, сравняващи SAF‑T данните с главната книга и ДДС регистрите?

5. 05

   Как се поддържа картографирането на сметки, данъчни кодове, контрагенти и номенклатури?

6. 06

   Какъв е процесът при отказ от НАП и колко бързо се стига до първопричината?

7. 07

   Как се пазят версията на файла, логовете и доказателствата за корекция?

Избягвайте общи отговори. Поискайте тестов сценарий с ваши данни, описание на обхвата и списък на ограниченията. Това не е проверка на доставчика, а част от вътрешния финансов контрол.

Проверката трябва да обхване поне един затворен исторически период, за да сравните SAF‑T резултата с приключени счетоводни данни без натиска на текущо приключване.

Пълнота на данните

Всеки очакван документ, контрагент и запис присъства с нужните атрибути. Сравнете броя на документите и ключовите обороти с тези в SAF‑T извадката, с особено внимание към коригиращи документи, сторно операции и ръчни журнални записи.

Съгласуваност и картографиране

Една и съща стопанска операция има еднакъв смисъл във всички свързани данни. Следете за множество вътрешни кодове за един обект, несъответстващи мерни единици и преименувани сметки. Всяко изключение има обяснение и собственик.

Реакция при отказ

Процедурата при отказ трябва да е упражнена преди първото реално подаване: кой получава статуса, кой анализира, кой коригира, кой одобрява и кой подава отново. Измерете колко време отнема целият цикъл: това показва дали процесът реално спазва 7-дневния срок по чл. 277а ДОПК.

Заложете показатели: грешки, открити преди подаване, брой откази, време до първопричина, време до повторно подаване, повтарящи се грешки. Те показват дали процесът става по-надежден или само компенсира едни и същи проблеми с повече ръчен труд. Водете регистър на корекциите с източник, засегнати периоди, отговорник и трайното предотвратяващо правило: така организацията натрупва знание, вместо да открива един и същи проблем отново.