SAF-T изисквания към фактурите: какви данни се изискват ред по ред (2026)

Когато подавате SAF-T към НАП, не подавате просто „фактурите си" — подавате структуриран XML файл с ~300 задължителни полета, базиран на международния стандарт OECD SAF-T v2.0. Това е значителна разлика спрямо текущите данъчни декларации.

В тази статия ще видите какви точно данни се изискват за всяка фактура, кои полета са най-често пропускани при ръчно подаване, как се валидира XML файлът срещу НАП XSD схемата и какво означава cross-reference консистентност между фактура, главна книга и плащане.

Какво включва SAF-T за фактурите — общ преглед

SAF-T файлът е разделен на две основни секции:

основни данни (общи данни)

Това са „речниците" на вашата счетоводна система — фиксирани данни, които се използват за многократно reference от транзакциите:

• Контрагенти (Customers и Suppliers) — клиенти и доставчици
• Артикули (Products) — стоки и услуги
• Сметкоплан (Chart of Accounts) — пълна структура на счетоводните сметки
• Данъчни таблици (TaxTable) — ставки на ДДС, корпоративен данък и др.
• Аналитични измерения (Analysis Types) — центрове на разходи, проекти, отдели

Source Documents (транзакции)

Това са реалните бизнес документи за периода:

• Продажбени фактури (SalesInvoices) — изходящи фактури
• Покупни фактури (PurchaseInvoices) — входящи фактури
• Плащания (Payments) — банкови и касови движения
• Главна книга записи (GeneralLedgerEntries) — счетоводни записи
• Движения по AR/AP — задължения и вземания

Цялата структура съдържа ~300 задължителни полета, които НАП валидира при приемане. Пропускането дори на едно задължително поле води до отхвърляне на целия файл.

основни данни — задължителни полета за контрагенти, артикули, сметки

Контрагенти (Customer / Supplier)

За всеки клиент или доставчик SAF-T изисква минимум:

Поле	Описание	Пример
CustomerID / SupplierID	Уникален идентификатор	C001234
AccountID	Свързана сметка в сметкоплана	411-001
CompanyName	Официално наименование	Пример ООД
BillingAddress	Адрес за фактуриране (улица, град, ПК, държава)	пълна структура
TaxRegistrationNumber	ДДС номер (БГ номер с префикс)	BG123456789
Country	Държава на регистрация	BG
SelfBillingIndicator	Индикатор за self-billing	0 или 1

Често пропускани полета:

• TaxRegistrationNumber за чуждестранни контрагенти (изисква VIES формат)
• BillingAddress.PostalCode (пощенски код задължителен)
• SelfBillingIndicator (мнозина считат, че е опционално)

Артикули (Product)

За всеки артикул в активни транзакции:

Поле	Описание	Пример
ProductCode	Уникален код на артикула	ART-0042
ProductGroup	Група/категория	Услуги-консултации
ProductDescription	Описание	Консултантска услуга
ProductType	Тип: P (продукт), S (услуга), O (друго)	S
UnitOfMeasure	Мерна единица	БР, ЧАС, КГ

Често пропускано поле: ProductType — много счетоводни системи не разграничават продукт от услуга в основни данни, но SAF-T изисква.

Сметкоплан (General Ledger Accounts)

Пълна структура на всички активни сметки:

Поле	Описание	Пример
AccountID	Номер на сметката	411
AccountDescription	Наименование	Клиенти
StandardAccountID	Стандартен код (по сметкоплан)	411
GroupingCategory	Балансова категория	Активи, Пасиви
OpeningDebitBalance / OpeningCreditBalance	Начално салдо за периода	0.00
ClosingDebitBalance / ClosingCreditBalance	Крайно салдо за периода	1250.50

Често пропускани: началните и крайните салда — SAF-T изисква баланс на всяка сметка в началото и края на периода, дори ако са нула.

Source Documents — детайл на полетата ред по ред

Header level (общи данни за фактурата)

За всяка фактура (продажбена или покупна):

Поле	Описание	Пример
InvoiceNo	Номер на фактурата	2026-00123
InvoiceStatus	Статус (N=Normal, A=Annulled, F=Self-billed)	N
InvoiceDate	Дата на издаване (YYYY-MM-DD)	2026-07-15
InvoiceType	Тип: FT (data), FS (simplified), NC (credit note), ND (debit note)	FT
SelfBillingIndicator	Self-billing?	0
SystemEntryDate	Дата на запис в системата	2026-07-15T14:30:00
TransactionID	Reference към GL запис	JV-2026-07-456
CustomerID / SupplierID	Reference към основни данни	C001234

Line level (за всеки ред на фактурата)

Поле	Описание	Пример
LineNumber	Пореден номер на реда	1
ProductCode	Reference към основни данни	ART-0042
ProductDescription	Описание на стоката/услугата	Консултации SAF-T
Quantity	Количество	10.00
UnitOfMeasure	Мерна единица	ЧАС
UnitPrice	Единична цена	100.00
TaxPointDate	Дата на данъчното събитие	2026-07-15
Description	Описание на реда	Юли 2026, 10 часа
CreditAmount / DebitAmount	Сума преди ДДС	1000.00
Tax.TaxType	Тип на данъка	IVA (за ДДС)
Tax.TaxCode	Код на ставката	NOR (стандартна 20%)
Tax.TaxPercentage	Процент	20.00
Tax.TaxAmount	Сума на данъка	200.00

Document totals

В края на всяка фактура:

Поле	Описание
TaxPayable	Общо ДДС за плащане
NetTotal	Сума без ДДС
GrossTotal	Обща сума с ДДС
Currency.CurrencyCode	Валута (BGN по подразбиране)
Currency.CurrencyAmount	Сума в оригинална валута (ако не е BGN)
Currency.ExchangeRate	Курс към BGN

Кои полета са най-често пропускани при ръчно подаване

От нашия опит при съпоставяне на SAF-T за български клиенти, топ 10 пропускани полета са:

1. TaxPointDate — дата на данъчното събитие, различна от InvoiceDate при доставки на услуги
2. SystemEntryDate — timestamp на въвеждане в счетоводната система (не само дата)
3. SelfBillingIndicator — задължително поле дори когато е нула
4. ProductType — разграничението между продукт (P), услуга (S) и друго (O)
5. CustomerID/SupplierID reference към основни данни — счетоводните системи често дублират имена вместо да използват ID
6. AccountID в контрагент основни данни — свързаната сметка в сметкоплана
7. OpeningBalance / ClosingBalance — началните и крайните салда на сметките
8. TransactionID — reference към съответния запис в главната книга
9. Country code за чуждестранни контрагенти (BG, DE, FR и т.н.)
10. Currency.ExchangeRate при фактури в чужда валута

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

Изчислете точно за вашата фирма: SAF-T Калкулатор →

Валидация спрямо НАП XSD схема — примерни грешки

XSD (XML Schema Definition) е техническата спецификация, която НАП използва, за да валидира всеки получен SAF-T файл. Типични грешки при валидация:

Грешка 1: Несъответствие на тип данни

ERROR: Element 'InvoiceDate': '15.07.2026' is not a valid value 
of the atomic type 'xs:date'.

Причина: Датата е в българския формат DD.MM.YYYY, а SAF-T изисква YYYY-MM-DD (ISO 8601).

Грешка 2: Липсващо задължително поле

ERROR: Element 'Invoice': The content of element 'Invoice' is not complete. 
One of '{TaxPointDate}' is expected.

Причина: Полето TaxPointDate липсва изцяло.

Грешка 3: Невалидно reference

ERROR: Element 'CustomerID': Value 'C001234' not found in основни данни.

Причина: Транзакцията референцира клиент, който не е в основни данни секцията.

Грешка 4: Дублиран запис

ERROR: Element 'InvoiceNo': Duplicate value '2026-00123' found.

Причина: Два записа с един и същ номер на фактура в един и същ период.

Грешка 5: Неправилна сума

ERROR: NetTotal + TaxPayable ≠ GrossTotal at Invoice '2026-00123'.

Причина: Сметката не се връзва (rounding errors или некоректна агрегация).

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

Cross-references — фактура ↔ GL ↔ плащане

Една от най-сложните изисквания на SAF-T е cross-reference консистентността между трите основни секции:

Фактура → Главна книга (GL)

Всяка фактура трябва да референцира съответния счетоводен запис в GL чрез TransactionID. НАП валидира, че:

• Сумата на фактурата = сумата на GL записа
• Датите съвпадат (или са в логичен ред)
• Контрагентът съвпада

Фактура → Плащане

При плащане на фактура (банкова или касова операция):

• Плащането референцира InvoiceNo
• Сумата на плащането ≤ сумата на фактурата
• Датата на плащане ≥ датата на фактурата

GL → AR/AP

Записите за задължения и вземания трябва да съответстват на:

• Salди по клиентски и доставчически сметки
• Баланс на „Клиенти" сметка = сума на отворените клиентски фактури
• Баланс на „Доставчици" сметка = сума на отворените доставчически фактури

При несъответствие НАП отхвърля целия файл.

Ръчното осигуряване на cross-reference консистентност е изключително трудоемко — една грешка в номериране или сума разруши цялата верига. Автоматизираните решения използват референциални константи, които гарантират консистентност.

За пълен преглед на ръчния срещу автоматизирания работен процес четете в нашия анализ на SAF-T автоматизация.

UTF-8 кодиране, валута BGN, дати YYYY-MM-DD

Технически изисквания за всеки SAF-T XML файл:

• Кодиране: UTF-8 (без BOM)
• Валута: BGN като основна; чужди валути в Currency.CurrencyAmount + ExchangeRate
• Дати: ISO 8601, формат YYYY-MM-DD (например 2026-07-15)
• Timestamps: ISO 8601, формат YYYY-MM-DDTHH:MM:SS (например 2026-07-15T14:30:00)
• Числа: десетична точка (НЕ запетая), 2 знака след точка за суми (например 1000.50)
• Boolean: 0 за false, 1 за true (не true/false)

Често срещани грешки в кодирането:

• Българските кирилични знаци се замразяват като ??? ако файлът не е UTF-8
• Имената на контрагенти с латински акценти (ä, ü, é) се изкривяват без UTF-8
• Excel експорти често запазват CP1251 (Windows кирилица) вместо UTF-8

За Конто 6, Microinvest и Бизнес Навигатор: експортите често изискват преобразуване на кодирането. Подробно за интеграцията четете в нашето ръководство за Конто 6, Microinvest и Бизнес Навигатор.

ЧЗВ (FAQ)

Колко полета общо има в SAF-T XML файла?

Според OECD SAF-T v2.0 има ~300 задължителни полета от общо ~1,000 възможни. Различните полета са задължителни в зависимост от типа на бизнеса (производство, услуги, retail), типа на транзакцията (фактура vs. плащане) и валутата. НАП поддържа официална XSD схема, която точно дефинира кои полета са задължителни в кои случаи.

Какво ако имам специфични полета в моя счетоводен софтуер?

SAF-T има място за аналитични измерения (AnalysisType) и специфични полета (CustomField). Можете да включите центрове на разходи, проекти, отдели и други измерения, които използвате във вашия счетоводен план. При съпоставяне процеса ние идентифицираме всички ваши специфични полета и ги съпоставяме към съответните SAF-T структури.

Каква е разликата между InvoiceDate и TaxPointDate?

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

Какво ако имам фактури в чужда валута (EUR, USD)?

SAF-T изисква всички суми в BGN като основна валута. За фактури в чужда валута трябва да включите:

• Currency.CurrencyCode — код на чуждата валута (EUR, USD, RON и т.н.)
• Currency.CurrencyAmount — сума в оригиналната валута
• Currency.ExchangeRate — курс към BGN на датата на фактурата

Курсът трябва да е валиден за съответната дата (обикновено фиксинг на БНБ).

Как НАП проверява XSD валидността?

НАП използва автоматизирана валидация при качване на файла в портала. Файлът преминава през:

1. Структурна валидация срещу официалната XSD схема
2. Бизнес правила валидация (cross-references, суми)
3. Дублирана проверка на основни идентификатори
4. Crossdate проверка спрямо данъчни декларации (ДДС, корпоративен данък)

Грешен файл се отхвърля с конкретен error report, който позволява корекция и повторно подаване.

Финален извод

SAF-T изискванията към фактурите са много по-детайлни от обичайните счетоводни справки, които българските фирми подават досега. ~300 задължителни полета, cross-reference консистентност и стриктна XSD валидация правят ръчното изпълнение почти невъзможно за фирми с над 100 фактури/месец.

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

Запазете 30-минутна безплатна оценка с нашия екип: Запазете оценка →