Най-честите грешки при валидация на SAF-T файл и защо зелената отметка не е достатъчна

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

Не е.

Има фундаментална разлика между файл, който е структурно валиден, и файл, който НАП действително ще приеме. Тази разлика е причината, поради която стотици фирми ще подадат технически коректен XML и ще получат отказ - без ясно обяснение защо.

Тази статия обяснява точно какво проверява НАП отвъд схемата, какви са най-честите причини за отхвърляне, и защо повечето валидатори не ги улавят. Ако вече имате конкретен текст на отхвърляне пред себе си, вижте директно каталога с реални грешки от НАП - разчетени са код по код, с точния текст, който системата връща.

Два вида валидация - и повечето инструменти правят само единия

XSD валидация проверява дали XML файлът е структурно коректен - дали елементите са в правилния ред, дали задължителните полета присъстват, дали форматите на датите и числата са правилни. Това е валидацията, която повечето инструменти правят. Получавате зелена отметка. Файлът е „валиден."

Бизнес логическа валидация проверява дали данните вътре в файла са вътрешно консистентни - дали числата се събират, дали референциите между секциите съществуват, дали декларираните суми съответстват на сумите на редовете. Това е валидацията, която НАП прави при подаване. И тя е напълно отделна от XSD валидацията.

Файл може да премине XSD валидацията перфектно и да бъде отхвърлен при подаване заради бизнес логически грешки. Ето кои са най-честите от тях.

Грешка 1: Декларираните суми не съответстват на сумите на редовете

Месечният SAF-T файл съдържа няколко секции, всяка от които има декларирани обобщени полета - общ дебит, общ кредит, брой записи. НАП проверява дали тези декларирани стойности съответстват на действителните суми на редовете вътре в секцията.

Конкретните проверки са:

В секция GeneralLedgerEntries

• GL.1 - декларираният брой транзакции трябва да съответства на действителния брой транзакции
• GL.2 - декларираният общ дебит трябва да съответства на сумата на всички дебитни редове
• GL.3 - декларираният общ кредит трябва да съответства на сумата на всички кредитни редове

В секция Payments

• SD.P.1 - брой плащания
• SD.P.2 - общ дебит на плащанията
• SD.P.3 - общ кредит на плащанията

В секция SalesInvoices

• SD.SI.1 - брой фактури
• SD.SI.2 - общ дебит
• SD.SI.3 - общ кредит

В секция PurchaseInvoices

• SD.PI.1 - брой фактури
• SD.PI.2 - общ дебит
• SD.PI.3 - общ кредит

Защо се получава тази грешка? Най-честата причина е ръчно редактиране на файла след генерирането - някой коригира един ред, но забравя да актуализира обобщените полета. Или генерираният файл има закръгляване при десетичните числа, което натрупва разлика над допустимата толерантност от 0.01.

Грешка 2: Референции към несъществуващи клиенти и доставчици

Всеки клиент и доставчик, споменат в документите на файла, трябва да съществува в секцията MasterFiles. НАП проверява това кръстосано между секциите.

Конкретните проверки:

• SD.SI.CustomerID - всеки CustomerID в продажбените фактури трябва да съществува в MasterFiles.Customers
• SD.PI.SupplierID - всеки SupplierID в покупните фактури трябва да съществува в MasterFiles.Suppliers
• SD.P.22 - всеки CustomerID в редовете на плащанията трябва да съществува в MasterFiles.Customers
• SD.P.23 - всеки SupplierID в редовете на плащанията трябва да съществува в MasterFiles.Suppliers
• GL.19 / GL.28 - CustomerID в транзакциите и редовете на главната книга трябва да съществува в MasterFiles.Customers
• GL.20 / GL.29 - SupplierID в транзакциите и редовете на главната книга трябва да съществува в MasterFiles.Suppliers

Защо се получава тази грешка? При събиране на данни от различни системи - счетоводна и складова - много фирми имат партньори, записани по различен начин в двете системи. Клиент с ID "1023" в счетоводната програма може да е "K-1023" в складовата. Ако MasterFiles се попълни от едната система, а документите дойдат от другата - всички референции ще бъдат невалидни. XSD валидаторът няма да забележи нищо. НАП ще отхвърли файла.

Грешка 3: Крайните салда на сметките не съответстват на оборотите

Това е най-сложната и най-трудната за диагностициране грешка. Тя се отнася до правилата MF.GLA.11 и MF.GLA.12.

За всяка сметка в GeneralLedgerAccounts важи следното уравнение:

Ако крайното салдо, декларирано в MasterFiles, не съответства на началното салдо плюс оборотите от GeneralLedgerEntries - файлът е вътрешно неконсистентен. НАП го отхвърля.

Защо се получава тази грешка? Най-честата причина е, че данните за салдата идват от едно място, а данните за оборотите - от друго. Ако между тях има дори минимални разлики в закръгляването или пропуснати транзакции, уравнението не се събира. Допустимата толерантност е 0.01 лева. Всичко над нея е грешка.

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

Защо повечето валидатори не улавят тези грешки

XSD валидаторът на НАП и повечето онлайн инструменти за SAF-T валидация проверяват структурата на файла. Те не агрегират суми. Не кръстосват референции между секции. Не проверяват дали уравнението на салдата се събира.

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

Единственият начин да сте сигурни, че файлът ще бъде приет, е да го валидирате срещу бизнес логическите правила - не само срещу схемата.

Единичните полета са отделна тема

Освен кръстосаните проверки между секции, всяко поле в SAF-T файла има свои изисквания - допустими формати, дължини, номенклатури от НАП. Дата трябва да е в точния формат. Данъчен код трябва да е от точния списък. EIK трябва да е валиден.

Тези грешки са по-лесни за диагностициране, защото са локализирани в конкретно поле. Но са много на брой и за неопитен потребител могат да изглеждат непрозрачно. Добрият инструмент обяснява всяко поле - с пример за валидна стойност, с описание на формата, с визуализация на допустимите номенклатури. Пълния списък на изискванията за всяко поле от схемата - английско име, българско значение, формат, задължителност - ще намерите в SAF-T речника.

Накратко

При подаване на SAF-T файл НАП проверява:

• Дали декларираните суми и броеве съответстват на действителните редове във всяка секция
• Дали всички референции към клиенти и доставчици в документите съществуват в MasterFiles
• Дали крайните салда на сметките са консистентни с началните салда и оборотите от главната книга
• Дали всички единични полета отговарят на изискванията за формат и номенклатура

Повечето валидатори проверяват само последното. Грешките в първите три са причината фирми с „валидни" файлове получават отказ при подаване.

За пълния контекст зад всяко от трите правила - структурата на GeneralLedgerEntries, на MasterFiles и на SourceDocuments - вижте съответните глави в SAF-T наръчника: обяснени са поле по поле, с реални XML примери.