12.05.2026 Ден 1  (3 часа) 

Рамка, качество на данните, Главна страница (Header) и Основни данни (MasterFiles)

1. SAF-T в България накратко: какво подаваме, кога и защо

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

2. Готовност и качество на данните преди първото реално подаване

· Минимален стандарт за качество: устойчиви идентификатори, недопускане на дубли, задължителни атрибути; „5-те най-скъпи грешки“ в подготовката; как се прави кратък речник на данните за SAF-T: кое поле, от кой източник, кой отговаря за него; защо съгласуваността между източници и връзки е оперативна необходимост, а не пожелание.

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

· Практическа логика на съгласуванията: оборотна ведомост ↔ журнали ↔ ДДС дневници/фактури ↔ плащания; какво означава контролът да е заложен в процеса; кои разминавания са най-чести и как се локализират още преди подаването.

4. Месечният SAF-T като работен маршрут

· Къде започва месечният файл; какво задължително влиза в него; кои са четирите основни работни блока – Главна страница (Header) → Основни данни (MasterFiles) → Счетоводни записи (GeneralLedgerEntries) → Изходни документи (SourceDocuments); къде са най-честите прекъсвания още преди журналите и фактурите.

5. Главна страница (Header) – кой подава, за кой период и в какъв контекст

· Версия на файла (AuditFileVersion), дата на създаване на файла (AuditFileDateCreated), име на софтуерната компания (SoftwareCompanyName), име на софтуера (SoftwareID), версия на софтуера (SoftwareVersion), основа на счетоводството за данъчни цели (TaxAccountingBasis), данни за дружеството (Company), основна валута (DefaultCurrencyCode), критерии за подбор (SelectionCriteria), структура на собствеността (Ownership).

· Типични дефекти в Главна страница (Header): период, фирмени данни, валута, банкова структура, контактни данни и критерии за подбор.

6. Основни данни (MasterFiles) I – Счетоводни сметки (GeneralLedgerAccounts)

· Код на счетоводната сметка (AccountID) срещу вътрешен номер на сметката (TaxpayerAccountID); наименование на сметката (AccountDescription), тип на сметката (AccountType), начални и крайни салда; как сметкопланът се съпоставя към файла; къде най-често се чупи връзката между счетоводна сметка, разчет и документ.

7. Основни данни (MasterFiles) II – Клиенти (Customers) и Доставчици (Suppliers)

· Идентификатор на клиента и доставчика като устойчив ключ; наименование, регистрационен номер, адрес, данъчна регистрация, свързано лице (RelatedParty), счетоводна сметка, начални и крайни салда; принципът „едно лице = един запис“; дубли, непълни атрибути и несъответствие между контрагент и разчетна сметка.

8. Основни данни (MasterFiles) III – Данъчна таблица (TaxTable), Таблица с мерни единици (UOMTable) и Продукти (Products)

· Вид данък (TaxType), код на данъка (TaxCode), мерна единица (UnitOfMeasure), код на продукт (ProductCode), описание, код по комбинираната номенклатура, основна и стандартна мерна единица; кога продуктовата номенклатура е полезен речник и кога само създава шум.

13.05.2026 Ден 2 (3 часа)

Счетоводни записи (GeneralLedgerEntries), Изходни документи (SourceDocuments), засечки, финансова логика, подаване и корекции

1. Кратко подреждане на логиката от Ден 1

· Как връзките от Основни данни (MasterFiles) „хранят“ журналите, фактурите и плащанията; какво задължително трябва да е стабилно, за да не се разпадне файлът по-нататък.

2. Счетоводни записи (GeneralLedgerEntries) – счетоводната хронология ред по ред

· Брой записи (NumberOfEntries), обща сума на дебитите (TotalDebit), обща сума на кредитите (TotalCredit); дневник (Journal), транзакция (Transaction), ред на транзакция (TransactionLine); идентификатор на транзакцията (TransactionID), период (Period), година на периода (PeriodYear), дата на транзакцията (TransactionDate), системна дата на въвеждане (SystemEntryDate), дата на осчетоводяване (GLPostingDate), идентификатор на записа (RecordID), код на сметката (AccountID), вътрешен номер на сметката (TaxpayerAccountID), дебитна и кредитна сума, данъчна информация.
Какво „вижда“ проверката, когато журналът е формално попълнен, но логически несъгласуван.

3. Изходни документи (SourceDocuments) I – Фактури за продажби (SalesInvoices) стъпка по стъпка

· Номер на фактура, код на сметката, дата на фактурата, вид на документа, индикатор за самофактуриране, идентификатор на транзакцията, данни за клиента, ред на фактурата, сума на реда, данъчна информация, индикатор дебит/кредит, контролни суми на документа.

Как Фактури за продажби (SalesInvoices) трябва да се съгласуват със Счетоводни записи (GeneralLedgerEntries) и с клиента в Основни данни (MasterFiles).

4. Изходни документи (SourceDocuments) II – Фактури за покупки (PurchaseInvoices) стъпка по стъпка

· Същата логика, но през рисковите зони при покупките; разлика между входящ документ, счетоводна статия и данъчен слой; типични грешки при код на продукт, данъчен код, контрагент и период; практически случаи, при които несъответствието не е техническо, а счетоводно.

5. Изходни документи (SourceDocuments) III – Плащания (Payments) стъпка по стъпка

· Уникален референтен номер на плащането, идентификатор на транзакцията, дата на документа, метод на плащане, описание на плащането; ред на плащането: код на сметката, CustomerID / SupplierID, индикатор дебит/кредит, сума на реда; пътеката документ → счетоводен запис → плащане; какво се чупи, когато има плащане, но няма устойчива връзка към документа или контрагента.

6. Засечки и финансова логика

· Тук влиза съкратената, но много полезна част от предходното обучение. Къде реално се срещат слоевете на файла: AccountID, TaxpayerAccountID, CustomerID, SupplierID, TransactionID, ProductCode, TaxType, TaxCode, PaymentMethod и референтният номер на плащането. Типични засечки между Основни данни (MasterFiles), Счетоводни записи (GeneralLedgerEntries), Фактури за продажби (SalesInvoices), Фактури за покупки (PurchaseInvoices) и Плащания (Payments). Съгласуване между фактурите и отчетните регистри по ЗДДС. Финансова логика на знака, периода, разчетната сметка и плащането.

7. Подаване, валидиране, корекции и заключване на периоди

· Файлът като част от повтаряем месечен процес, а не еднократно упражнение; формални и съдържателни проверки; какво означава отхвърляне и защо управлението на версиите е важно; как работи логиката на корекциите; защо при корекция не се подава само разликата, а нов пълен файл за съответния период; кога грешката се коригира назад и кога се показва в текущия файл чрез SystemEntryDate и GLPostingDate.