100% в браузъра · файлът никога не напуска компютъра ви · безплатно, без регистрация

НачалоБлог

Блог · 19 август 2026 · 4 мин четене

CustomerID и SupplierID: как се формират идентификаторите

Едно от най-подвеждащите отхвърляния на портала: идентификаторът на контрагента изглежда наред — ЕИК-то е вярно — а файлът се връща. Причината почти винаги е форматът: липсващ код за тип или излишен BG префикс.

Двете съобщения от портала

Официалният FAQ на НАП (въпрос IV.2.4) разглежда точно този случай — подател получава две на пръв поглед еднакви грешки:

„Стойностите в елементи GL.28 CustomerID 104104104 и GL.29 SupplierID 104104104 в секция GeneralLedgerEntries не са попълнени съгласно изискванията или са подадени идентификатори за клиент/доставчик, който не фигурира в секция 2. MasterFiles, елемент MF.C.3/ MF.S.3.“

Портал за е-услуги на НАП · „Въпроси и отговори за SAF-T“, IV.2.4

„Стойностите в елементи GL.28 CustomerID 10BG104104104 и GL.29 SupplierID 10BG104104104 в секция GeneralLedgerEntries не са попълнени съгласно изискванията или са подадени идентификатори за клиент/доставчик, който не фигурира в секция 2. MasterFiles, елемент MF.C.3/ MF.S.3.“

Портал за е-услуги на НАП · „Въпроси и отговори за SAF-T“, IV.2.4

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

Грешка 1: голият ЕИК, без код за тип

Първото съобщение се получава, защото — по думите на НАП — „подаденият идентификатор не е предхождан с код „10 - следван от ЕИК - където типът е 10, а ЕИК е уникалният идентификационен код за икономическите оператори, регистрирани в България“.

Тоест идентификаторът е съставен: първо кодът на типа, после самият номер. За българска фирма с ЕИК типът е 10:

ЕИК на контрагента:      104104104
Грешно (гол ЕИК):        <nsSAFT:CustomerID>104104104</nsSAFT:CustomerID>
Вярно (тип 10 + ЕИК):    <nsSAFT:CustomerID>10104104104</nsSAFT:CustomerID>

Същото важи за SupplierID. Счетоводният софтуер обикновено пази чистото ЕИК — представката за тип трябва да се добави при експорта към SAF-T.

Грешка 2: излишният BG префикс

Второто съобщение (стойност 10BG104104104) е обратният случай: подателят е взел ДДС номера. По FAQ-а грешката е свързана с това, че „сте подали префикса за регистрация по ЗДДС „BG“ след кода за идентификаторът – в посочения тип не се посочва префикс на държава“.

ДДС номер по ЗДДС:       BG104104104
Грешно (тип + ДДС №):    <nsSAFT:SupplierID>10BG104104104</nsSAFT:SupplierID>
Вярно (тип 10 + ЕИК):    <nsSAFT:SupplierID>10104104104</nsSAFT:SupplierID>

Ако софтуерът ви пази контрагентите с ДДС номера, при експорта префиксът BG трябва да падне — при тип 10 се подава само ЕИК.

Практично правило преди подаване: извадете всички уникални стойности на CustomerID и SupplierID от файла и ги прегледайте на един екран. Стойност с букви вътре (BG…) или гол ЕИК без представка за тип е кандидат за отказ още на портала — по-лесно е да се види в списък, отколкото ред по ред.

Другата половина на съобщението: MasterFiles

Забележете какво още казва текстът на грешката: „…или са подадени идентификатори за клиент/доставчик, който не фигурира в секция 2. MasterFiles, елемент MF.C.3/ MF.S.3“. Идентификаторът не е само формат — той е и референция. Всеки CustomerID или SupplierID, използван в записите на GeneralLedgerEntries, трябва да съществува дословно като контрагент в MasterFiles:

<!-- MasterFiles: контрагентът е деклариран веднъж -->
<nsSAFT:Customer>
  ...
  <nsSAFT:CustomerID>10104104104</nsSAFT:CustomerID>
  ...
</nsSAFT:Customer>

<!-- GeneralLedgerEntries: записът го реферира със СЪЩАТА стойност -->
<nsSAFT:TransactionLine>
  ...
  <nsSAFT:CustomerID>10104104104</nsSAFT:CustomerID>
  ...
</nsSAFT:TransactionLine>

Затова форматната грешка често се проявява двойно: ако в MasterFiles контрагентът е с 10104104104, а в записите стои голото 104104104, двете стойности не съвпадат и записът сочи към „несъществуващ“ контрагент. Класическият източник на разминаването — складовата и счетоводната програма с различни номенклатури — сме описали в речника на грешките.

Защо схемата не ви е предупредила? По XSD CustomerID и SupplierID са просто текст до 35 знака — и 104104104, и 10BG104104104 са „валидни“ за схемата. Правилото „тип + номер, без префикс на държава“ се проверява чак от портала.

Какво хваща валидаторът предварително

SAFTCheck прави кръстосана проверка на референциите: всеки CustomerID/SupplierID, реферирани в записите, се търси в MasterFiles. Несъвпадение — включително от разминал се формат между двете секции — се показва като несъвпадаща референция, преди файлът да стигне до портала. Проверката е в браузъра; файлът не се качва никъде.

Съмнявате се в контрагентите?

Пуснете файла — валидаторът сверява всички референции срещу MasterFiles и показва кой идентификатор „виси“.

Провери файла

Източник: „Въпроси и отговори за SAF-T“, ЦУ на НАП, версия 2 — въпрос IV.2.4 (страница на обявата в nra.bg). Съобщенията за грешка са цитирани дословно; типовете и дължините на елементите — по XSD схемата (Приложение №1).