Най-честите грешки в SAF‑T файла и как се поправят

Файлът има две части, които НАП проверява една срещу друга. Регистрите (MasterFiles) описват кои са клиентите, доставчиците, артикулите и сметките. Документите и счетоводните записи ги посочват по идентификатор. Ако продажба сочи клиент с идентификатор, който не съществува в раздела с клиенти, файлът пада на проверката CustomerID. Същото важи за доставчиците (SupplierID), за артикулите (ProductCode) и за сметките в счетоводните записи.

Правилото е записано в бележките към Приложение № 2 и в „Въпроси и отговори“ на НАП, т. IV.2.4. Засегнатите елементи: GL.28, MF.C.3 и S.I.23 за клиентите; GL.29, MF.S.3 и S.I.26 за доставчиците; S.I.36 и MF.P.2 за артикулите; GL.24 и MF.GLA.2 за сметките.

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

Това е най-честата причина проверката CustomerID и SupplierID да не мине дори при пълен регистър. ERP системата обикновено пази ЕИК с префикс BG или ДДС номера в свободен текст, а файлът иска строг формат: префикс за вида, след него самият идентификатор без допълнителни знаци. Клиент, записан веднъж с префикс BG и веднъж без него, е два различни контрагента за проверката.

Правилото е в бележките към Приложение № 2 и в „Въпроси и отговори“, т. IV.2.4. Засегнатите елементи: MF.C.3, MF.S.3, GL.28, GL.29.

Поправката е в картона на контрагента в счетоводната система, не във файла. Файлът се генерира наново от поправените данни. Ръчна корекция в XML решава подаването за един месец и връща грешката на следващия.

Четири отделни проверки, с четири различни източника:

Кодовете на сметките трябва да са от номенклатурата на НАП за сметкоплана (Приложение № 2, правила; елементи MF.GLA.2 и GL.24). Вътрешният сметкоплан на предприятието се картографира към нея, както е описано в статията за номенклатурите и кодовете.

Кодовете по КН8 на артикулите трябва да съществуват в номенклатурата КН8-2026 (Приложение № 2, правила; елемент MF.P.6). Осемте цифри се проверяват като цяло. Артикул с код „0“ минава като предупреждение, но трябва да бъде попълнен преди окончателното подаване (Приложение № 2, бележки).

Мерните единици трябва да са от номенклатурата UN/CEFACT (Приложение № 2, правила; елементи MF.UOM.2, MF.P.9, MF.P.10). Кодовете различават малки и главни букви: „KGM“ и „kgm“ не са един и същ код.

Всеки данъчен код, посочен в документ, трябва да е деклариран в таблицата с данъчни кодове на файла (Приложение № 2, правила; „Въпроси и отговори“, т. IV.2.3; елементи S.TI.2 и MF.TT.5).

Поправката за всички четири е в съответствието между вътрешните кодове на предприятието и номенклатурата. Веднъж направено правилно, то се пренася във всеки следващ файл. Веднъж направено „приблизително“, връща грешката всеки месец.

Елементите NumberOfEntries, TotalDebit и TotalCredit не се попълват на ръка. Те се пресмятат от самите записи при генерирането. Ако декларираният брой е различен от преброения, най-често причината е филтър при експорта: записи от края на периода, сторнирани документи или документи в чернова, които са включени в едното и изключени от другото.

Правилата са в бележките към Приложение № 2 и в „Въпроси и отговори“, т. IV.2.5. Засегнатите елементи: GL.1, GL.2, GL.3 за счетоводните записи; SD.SI.1 до SD.SI.3, SD.PI.1 до SD.PI.3 и SD.P.1 до SD.P.3 за издадените документи, получените документи и плащанията. По „Въпроси и отговори“ данъчните суми не се включват в контролите за общ дебит и общ кредит по документи, както е описано в статията за съобщенията за грешки на НАП.

Поправката е в генератора, не в числата. Ако сумата е сгрешена, редовете зад нея са непълни или дублирани, и трябва да се намерят те.

Проверката е аритметична: OpeningDebitBalance и OpeningCreditBalance, плюс оборотите за месеца, трябва да дадат ClosingDebitBalance и ClosingCreditBalance. Правилото е в Приложение № 2, правила; елементите са MF.GLA.9, MF.GLA.10, MF.GLA.11 и MF.GLA.12.

Когато равенството не излиза, причината рядко е в самата сметка. По-често има запис с дата извън отчетния месец, който е попаднал в оборотите, но не и в салдата, или обратното. Поправката е да се сравнят началното салдо и оборотите на сметката със счетоводната система за същия период и да се намери записът, който е само на едното място.

XSD схемата допуска само EUR като основна валута на файла (елемент S.H.9). Файл с BGN в заглавната част не минава схемата, независимо от съдържанието. При документи в чужда валута схемата очаква сумата във валута, курса и сумата в EUR да са съгласувани (елементи S.AM.1, S.AM.3 и S.AM.4). Несъответствието е предупреждение, не отказ, но е знак, че курсът в документа не е този, с който е осчетоводен.

Поправката: проверете кои документи са посочени и сравнете курса и сумата във валута с осчетоводените. Ако курсът е закръглен различно в ERP системата и във файла, разликата се появява във всеки документ във валута.

Това е първата проверка на е-портала и е записана в XSD схемата и в „Въпроси и отговори“, т. IV.2.1. Най-честите причини са прекъснат експорт, знак, който не е кодиран правилно в UTF-8, или незатворен елемент при ръчна редакция.

Поправката е да се генерира файлът наново. Ако грешката остане при чист експорт, генераторът произвежда невалиден XML и корекция във файла няма да помогне за следващия месец.

Инспекторът на Safty отваря файла в браузъра, без да го изпраща никъде, и проверява точно тези правила: регистри срещу документи, формат на идентификаторите, номенклатури, бройки и суми, салда, валута и XML. Всяка констатация сочи правилото и елемента, по които е направена, и какво трябва да се поправи. Окончателната преценка е на е-услугата на НАП, но тези седем грешки могат да бъдат отстранени преди тя да ги види.

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