SAF-T на счетоводен език

1.1. "SAF-T е дисциплина на данните" (не "още един отчет")

В традиционния счетоводен рефлекс центърът на доказването са документите: фактурата като PDF/хартиен образ, банковото извлечение, протоколът, договорът. Това мислене е естествено, защото класическата проверка често върви "документ по документ", а резултатът се валидира през коректно осчетоводяване и наличен първичен документ.

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

Точно тук възниква най-честото недоразумение: SAF-T изглежда сложен и затова се възприема като "още един отчет". Това е подвеждащо. Практически SAF-T е стандартизирана "снимка" на счетоводната реалност за отчетен период: какви речници/мастер данни поддържаме (сметки, контрагенти, продукти, данъчни кодове), какви операции са осчетоводени (журнал/главна книга), какви документи стоят зад тях (фактури и др.) и как са отразени свързаните плащания. Не качваме документи; подаваме данни и връзки, които трябва да се "затворят" помежду си.

Една практична формулировка, която държи концепцията "на счетоводен език", е следната: при SAF-T една и съща стопанска операция трябва да може да се "прочете" в няколко слоя едновременно (справочен слой → документен слой → счетоводен слой) и да остане проверима при автоматични съпоставки. Именно затова подготовката започва от политики, номенклатури и идентификатори, а не "в последната година", когато срокът вече притиска.

Таблица 1. Защо SAF-T не е "още един отчет", а друг вид представяне на счетоводната реалност

Критерий Финансов отчет (баланс/ОПР и др.) SAF-T: обекти и контролен фокус Единица на представяне Агрегирани позиции Данни по обекти и връзки (мастер данни + транзакции + документи) Основна цел Представяне на финансово състояние/резултат Проследимост, консистентност и проверяемост по схема; въпросът често е "има ли връзка/ключ?" "Език" Позиции, приложения, наратив Идентификатори, кодове, референции; текстът е вторичен Типична слабост "Добър отчет" може да прикрие лоша вътрешна структура на данните "Коректен бизнес" може да изглежда "шумен", ако ключовете/кодовете са хаотични; данните стават трудни за интерпретация и валидиране

Тази таблица не е просто "теория". Тя обяснява защо организация може да има коректни салда и коректно приключване, но да се затрудни при SAF-T: не защото числата са грешни, а защото идентификаторите и връзките не са стабилни и не позволяват машинна съпоставка. В SAF-T контролният фокус закономерно се измества към консистентността на обектите и връзките.

1.2. Какво реално се подава: номенклатури + операции + фактури + плащания (и при условия – активи/запаси)

1.2.1. "Граматиката" на SAF-T: секции > подсекции > елементи

Официалната рамка описва SAF-T като тристепенна дървовидна структура (секции, подсекции, елементи). Това е "граматиката", която прави файла валидируем: за всеки елемент има тип данни, режим на докладване и правила, по които информацията се проверява машинно, включително чрез XSD-валидация и проверки за консистентност.

Счетоводно това ни дава полезна рамка: основните секции на файла са функционални "слоеве" на една и съща реалност. Ние не подаваме "едно нещо", а подреждаме една и съща стопанска реалност в няколко взаимно свързани слоя: кой подава и за кой период; кои са обектите (сметки, контрагенти, данъчни кодове); кои са операциите (журналът); кои са документите (фактури) и плащанията.

1.2.2. Слоевете, преведени на счетоводен език: какво "вижда" администрацията

Един лесен начин да се разбере "какво реално се подава" е да преведем едно и също стопанско събитие в две перспективи: "в отчета" (агрегирано) и "в SAF-T" (разпаднато на обекти и връзки). Това е и практическата причина да казваме, че SAF-T е дисциплина на данните: той принуждава системата да е четима като система, не само като краен резултат.

Таблица 2. Един и същ казус "в отчета" и "в SAF-T": какво се подава като данни

Стопанско събитие (илюстративно) "В отчета" "В SAF-T": какви обекти се подават и какъв е типичният контролен въпрос Продажба на кредит (фактура към клиент) Приход + вземания Customers (MasterFiles) + SalesInvoices (SourceDocuments) + GeneralLedgerEntries. Контролният въпрос е дали има валиден CustomerID и дали е затворена връзката документ - журнал (стойности/дати/референции). Покупка на услуга (разход + ДДС кредит) Разход + задължение Suppliers (MasterFiles) + PurchaseInvoices + GeneralLedgerEntries + данъчни кодове по номенклатура (Tax Table / TAX-IMP). Контролният въпрос е дали се използват кодове (не "имена") и дали документ - осчетоводяване се затваря чрез референции. Плащане (банка/каса) Намалява пари и разчети Payments + връзка към контрагент/сметка + отражение в счетоводните записи. Контролният въпрос е дали плащането е проследимо към контрагент и/или документ, или остава изолиран запис.

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

1.2.3. Официалната "карта": кои секции се подават и какво означават счетоводно

Официалният формат за България изброява секциите и подсекциите на SAF-T (Header, MasterFiles, GeneralLedgerEntries, SourceDocuments и др.), включително кои части са опционални/незадължителни. Това е фундаментът за отговора "какво реално се подава".

Таблица 3. "Какво реално се подава" – секции/подсекции и счетоводен прочит (с акцент върху четирите ядра: номенклатури, операции, фактури, плащания)

Секция/подсекция (официален термин) Счетоводен прочит ("какво е това за нас") Какво е критично да е вярно като данни Header Контекст: кой подава, за кой период, какъв вид файл, с коя версия/схема Файлът има ясна идентичност (период, вид, версия), за да може да се валидира и сравнява във времето. MasterFiles / GeneralLedgerAccounts Сметкопланът като речник на сметките (AccountID и атрибути) "Една сметка = един устойчив код"; журналът трябва да използва само сметки, дефинирани в речника. MasterFiles / Customers, Suppliers Контрагенти като речник (CustomerID/SupplierID + идентификация/адреси) "Едно лице = една карта": без дубли и без "сливане" на различни лица под един ID. MasterFiles / TaxTable Данъчната логика като речник (TaxType / TaxCode и атрибути) "Кодове, не имена": данъчната логика не се носи като свободен текст, а като кодове по номенклатури. GeneralLedgerEntries "Журналът": всички счетоводни операции през периода на транзакционно ниво Уникални/стабилни TransactionID/RecordID; консистентни дати, суми, сметки; възможност за връзка към документи/плащания. SourceDocuments / SalesInvoices Фактурен слой – продажби, на ниво документ и ред Фактурите са структурирани записи (номер, дата, контрагент, редове, данъчна информация), не PDF-прикачвания. SourceDocuments / PurchaseInvoices Фактурен слой – покупки, на ниво документ и ред Същото: редовете имат задължителни елементи; данъчната логика е кодирана и съпоставима. SourceDocuments / Payments Платежен слой – плащания като структурирани записи Плащането трябва да е "закачено" към контрагент/сметка и (по възможност) към документ/основание; методът е по номенклатура. MasterFiles / Assets + SourceDocuments / AssetTransactions Активи и движения по активи Подават се на годишна база и изискват дисциплина в регистъра на ДМА и движенията. MasterFiles / PhysicalStock + SourceDocuments / MovementOfGoods Наличности и движения на запаси Подават се при поискване (когато е приложимо) и предполагат работеща продуктова номенклатура, UOM и проследимост. CorrespondingAccountsReport (опционална секция) Контролна справка "като главна книга" (салда / обороти / кореспонденции) Не е задължителна, но при наличност в системата подпомага съгласуванията и намалява "обяснителната тежест".

Таблицата показва точно онова, което често липсва в разговорите "ИТ ще го направи": технологично може да се изгради XML експорт по схемата, но счетоводно устойчивостта се решава от качеството на мастер данните и от това дали връзките между слоевете са затворени (сметка - контрагент - документ - операция - плащане).

1.2.4. Номенклатурите не са "справочна украса" – те са логиката на валидируемостта

В SAF-T номенклатурата не е периферия. Тя е механизъм, чрез който данните стават съпоставими и проверими. Най-видимият пример е данъчната таблица (TaxTable): ако сметкопланът казва "къде" е осчетоводено, а контрагентът казва "кой" участва, данъчната таблица казва "как" е обложено, но не чрез текст, а чрез кодове (TaxType/TaxCode) по утвърдените номенклатури.

Това има една проста счетоводна последица: "данъчно мислене на свободен текст" става риск. Вътре в ERP може да има вътрешни означения и локални практики, но в SAF-T данъчната логика се доказва чрез еднозначно кодиране, което се повтаря навсякъде, където данъчната логика се появява. Затова методиката за картографиране "вътрешен данъчен код > TaxType/TaxCode по номенклатура" е част от подготовката по същия начин, по който е част картографирането на сметки и контрагенти.

Таблица 4. Данъчната таблица (TaxTable) като "източник на истина": минимални полета и контролен смисъл

Минимално поле Роля в SAF-T и контролен смисъл TaxType Основен данъчен "тип" по номенклатура; първо ниво на класификация за автоматични проверки TaxCode Кодът, който реално се подава в документите и (където моделът изисква) в счетоводните редове; проверките "четат" кода, не текста TaxPercentage (където е приложимо) Структурен атрибут, който подпомага логическа консистентност и четивност Description Човешка четивност и помощ при вътрешно картографиране; не замества кода Country (където се изисква) ISO код на държава; необходим при определени данъчни сценарии/кодове

Механиката е "желязна": кодът се дефинира в речника (TaxTable) и "пътува" към документните редове (TaxInformation), като така проверката става възпроизводима и еднозначна.

1.2.5. Пример: текущ разход с фактура, падеж и плащане в следващ месец

Да вземем най-"скучния" казус, защото именно той най-добре показва дисциплината на данните: текущ разход (например комунална услуга) с фактура в края на месеца, падеж следващия месец и реално плащане в следващия месец.

В класическия счетоводен разказ това е "фактура – осчетоводяване – плащане". В SAF-T същото събитие трябва да бъде четимо като система: доставчикът трябва да е дефиниран в MasterFiles (Suppliers) със стабилен SupplierID; осчетоводяването трябва да е в GeneralLedgerEntries с TransactionID; самата фактура трябва да е в SourceDocuments → PurchaseInvoices и да сочи към същия SupplierID и да затвори връзката документ ↔журнал чрез референции; плащането не се "дописва" към фактурата, а се появява като отделен запис в Payments за периода на реалното плащане.

Тук има един практически важен детайл, който често се пропуска: PurchaseInvoices описва покупния документ на ниво ред и InvoiceLine има задължителни полета. Ако фактурата е за услуги/текущи разходи и не поддържате продуктова номенклатура за тях, моделът допуска обобщен ред с ProductCode = 0, но това не отменя задължителните елементи на реда (например Quantity и UnitPrice трябва да бъдат попълнени, за да е валиден файл). Обичайна защитима конвенция е Quantity = 1 и UnitPrice = нетната стойност на реда, плюс ясно описание.

В този пример се вижда разликата между "имаме счетоводство" и "имаме счетоводни данни": първото е вярно при коректни салда; второто изисква устойчиви идентификатори, стабилни кодове и затворени референции между слоевете, така че операцията да не се разпадне на несвързани записи.

1.2.6. Защо това е "дисциплина": подаване, валидиране и счетоводната цена на грешката

Причината да настоявам, че SAF-T е дисциплина на данните, а не "експорт", е и в режима на проверка. Процесът по подаване е двустепенен: първо има формални условия (XML формат, конвенция за име, подпис с КЕП) и при неспазване файлът не се приема; след приемането се правят валидации спрямо XSD-схемата и проверки за валидност и консистентност, и при несъответствия файлът се отхвърля, като се предоставя информация за грешките и 7-дневен срок за подаване на нов файл. Ако несъответствията не се отстранят в срока, файлът се счита за неподаден.

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

На счетоводен език SAF-T означава следното: подаваме не "още един отчет", а структурирани счетоводни данни в слоеве, които трябва да са свързани чрез идентификатори и кодове; подаваме речници (номенклатури), после транзакции (операции/журнал), после документи (фактури) и плащания; при условия и по отделни режими се подават активи и/или запаси. Точно това прави секция 1 критична: тя калибрира очакванията и показва защо подготовката започва от данните, не от "последния експорт".