Топ 5 най-чести грешки при генериране на SAF-T файл и как да ги избегнете

Грешки при генериране на SAF-T файл

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

SAF-T не е просто „експорт на XML файл“ от счетоводния софтуер. Това е структуриран одитен файл, в който счетоводните данни, контрагентите, документите, плащанията, сметките и номенклатурите трябва да бъдат подадени по определена логика.

Грешки при SAF-T: защо възникват още преди XML файла

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

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

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

1. Липсващ уникален SAF-T код на контрагент

Една от най-честите грешки е липсващ или неправилно формиран CustomerID или SupplierID.

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

В тестова проверка на SAF-T файл софтуерът отчита група от контрагенти, за които няма въведен уникален код за SAF-T — именно CustomerID или SupplierID.

Защо това е проблем?

Контрагентът не се използва само в една част на файла. Той може да присъства в:

  • MasterFiles;
  • счетоводни записи;
  • фактури;
  • плащания;
  • справки по сметки.

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

Как да избегнете грешката?

Преди генериране на SAF-T файл трябва да се направи преглед на всички активни клиенти и доставчици за периода:

  • имат ли SAF-T идентификатор;
  • правилно ли е формиран;
  • има ли разлика между ЕИК, ДДС номер и CustomerID/SupplierID;
  • има ли чуждестранни контрагенти, за които трябва различна логика;
  • има ли физически лица, за които се изисква специално внимание.

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

2. Разминаване между контрагента в документа и контрагента по счетоводната сметка

Друга честа грешка е документът да е издаден към един контрагент, но счетоводната аналитичност по сметката да сочи към друг. Защо това е важно?

SAF-T не гледа документа изолирано. Файлът свързва:

документ
↓
контрагент
↓
счетоводна сметка
↓
счетоводен запис
↓
MasterFiles

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

Как да избегнете грешката?

Проверете:

  • дали контрагентът в документа съвпада с аналитичността по сметката;
  • дали сметки 401/411 и аналогични разчетни сметки са правилно обвързани;
  • дали при корекции, сторна или прехвърляния не е останал стар контрагент;
  • дали няма ръчно осчетоводяване към неправилна аналитичност.

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

3. Грешен отчетен период или дата на документа

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

При тестова проверка е отчетен документ, в който основната дата и датата за включване в дневника за ДДС са извън периода за SAF-T. Защо това е проблем?

Един документ може да има няколко важни дати:

  • дата на документа;
  • дата на осчетоводяване;
  • дата за ДДС дневника;
  • дата на въвеждане в системата;
  • период, за който се подава SAF-T файлът.

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

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

Как да избегнете грешката?

Преди генериране на файла проверете:

  • дали всички документи за периода са въведени;
  • дали ДДС датата съответства на отчетния период;
  • дали документи от следващи периоди не са включени погрешно;
  • дали корекциите са отразени в правилния период;
  • дали има документи с дата на въвеждане след края на месеца, но отнасящи се за него.

Практически съвет: не проверявайте само датата на фактурата. Проверете и датата за ДДС, датата на осчетоводяване и периода на SAF-T файла.

4. Липсващи или неправилно мапнати номенклатури

SAF-T изисква данните да бъдат стандартизирани. Това означава, че вътрешните кодове от ERP системата често трябва да бъдат свързани с определени SAF-T номенклатури.

Най-често проблеми възникват при:

  • мерни единици;
  • счетоводни сметки;
  • кодове за плащане;
  • продукти;
  • данъчни кодове;
  • кодове на държави.

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

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

В счетоводната система може да има мерна единица „бр.“, „час“, „лв.“, „MWh“ или друг вътрешен код. Но за SAF-T трябва да е ясно как тази стойност се подава спрямо допустимите кодове.

Същото важи за сметки, данъчни кодове и методи на плащане.

Как да избегнете грешката?

Направете отделна проверка на номенклатурите:

  • кои мерни единици се използват в периода;
  • дали всички имат SAF-T съответствие;
  • кои сметки участват във файла;
  • дали сметкопланът е мапнат правилно;
  • дали методите на плащане са валидни;
  • дали държавите са с правилни ISO кодове.

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

5. Подценяване на връзката между MasterFiles, GeneralLedgerEntries и SourceDocuments

Една от най-сериозните грешки е SAF-T да се възприема като сбор от отделни таблици. Всъщност файлът работи като свързана структура.

MasterFiles съдържа основните данни — клиенти, доставчици, сметки, продукти, мерни единици. GeneralLedgerEntries съдържа счетоводните операции. SourceDocuments съдържа документи като фактури, покупки, продажби, плащания и движения на запаси.

Защо това е важно?

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

Как да избегнете грешката?

Преди подаване направете логическа проверка:

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

Практически съвет: не проверявайте само дали XML файлът се генерира. Проверете дали данните в него са последователни.

Какво е важно да запомните?

SAF-T грешките обикновено не са само технически. Те са резултат от качеството на данните в счетоводната система. SAF-T изисква подготовка, а не само бутон „експорт“. Как да започнете подготовката?

Практическият подход е следният:

  1. Проверете контрагентите.
  2. Проверете сметкоплана.
  3. Проверете мерните единици и продуктите.
  4. Проверете датите и отчетните периоди.
  5. Направете тестово генериране на XML.
  6. Анализирайте грешките от софтуера.
  7. Коригирайте източника на данните, а не само XML файла.

SAF-T показва много повече от това дали една декларация е подадена. Той показва как са структурирани данните в предприятието. Затова най-добрата подготовка не започва с XML файла, а с въпроса: Готови ли са нашите счетоводни данни да бъдат прочетени, свързани и проверени автоматично?

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

Можете да използвате и чек-листа за готовност на ERP или счетоводната програма за SAF-T.

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

За официална информация относно внедряването на SAF-T в България следете страницата на Националната агенция за приходите.

Подобни статии