Структура и номенклатури: официалната "карта"

При SAF-T "структурата" не е технически детайл, а счетоводна рамка. Причината е проста: файлът не е наратив, а модел от взаимно свързани записи. Когато знаем къде живее всяка информация, ние всъщност знаем как се доказва една и съща стопанска реалност в различни слоеве: идентичност на файла, речници (номенклатури), операции (журнал), документи (фактури), плащания, а при определени режими – запаси и активи. Официалното описание определя SAF-T като 3-степенна дървовидна структура (секции, подсекции, елементи), което е "граматиката", по която данните се валидират и по която грешките стават машинно откриваеми.

Паралелно с това официалната "карта" (Приложение № 3 към заповедта) е направена така, че да може да се използва като практичен атлас: структурата и елементите са представени в табличен вид с идентификатор, секция/подсекция/елемент, описание на български, тип данни, източник на стойността, режим на докладване и синтактични и семантични валидационни правила.

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

3.1. Структурата като граматика: секции, подсекции, елементи и режим на докладване

Официалната рамка фиксира не само "какво има" в SAF-T, но и "как се подава". Въвеждат се три важни понятия, които имат директен счетоводен превод.

Първото е режимът на докладване на секции/подсекции/елементи: задължително, опционално или незадължително. Официалното правило е процесно, но последицата е счетоводна: ако организацията реши да подава опционална секция/подсекция, тогава елементите, означени като Mandatory, стават задължителни за попълване; опционални секции/подсекции/елементи без данни не се подават в XML файла.

Това означава, че "опционално" не е "несериозно" – то е управленско решение "полза срещу усилие" и ангажимент за качество на данните, ако бъдат подадени.

Второто е езиковото правило, което често се подценява, а има чисто практичен ефект върху експортите: всички текстови полета във файла се подават на български език, освен полетата, за които изрично е предвидено подаване на латиница (примерно NameLatin).

Това е ключово, защото структурните полета работят с кодове, но описателните полета (Description, Name и др.) са част от данните и подлежат на формални очаквания.

Третото е принципът за алтернативните елементи: с XML файла се подават само тези от алтернативните елементи, в които има подадени данни.

На практика това изисква дисциплина при "празните" стойности и при полета, които са условни, защото непоследователното им подаване създава "шум" и води до технически грешки, които в счетоводството иначе не се виждат.

3.2. Секции и подсекции: официалната карта на SAF-T в България

Официалната структура на SAF-T за България е фиксирана като списък от секции и подсекции, включително изрично е посочено кои подсекции са незадължителни и кои секции са опционални.

За счетоводителя най-важното е да види тази структура като функционални слоеве: Header дава контекст; MasterFiles дава речниците; GeneralLedgerEntries дава хронологията на осчетоводяването; SourceDocuments дава документния слой и плащанията; останалите секции (CorrespondingAccountsReport, Structures, SimpleTypes) подпомагат контрол и валидиране, но не са "регистри", които съществуват самостоятелно като бизнес процес.

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

Секция (BG/EN) Счетоводен смисъл и контролен фокус Главна страница / Header Идентичност и контекст на файла: кой подава, за кой период, какъв вид файл, версия на схемата, дата на създаване, софтуер. Това е "паспортът" на подадената информация. Основни данни / MasterFiles Речниците на счетоводството: сметки, контрагенти, данъчни таблици, мерни единици, продукти, както и специализирани подсекции за запаси и активи според режима. Контролният фокус е референтна цялост: всеки код/ID, използван в операции и документи, трябва да е дефиниран тук. Счетоводни записи / GeneralLedgerEntries "Журналът" на периода на транзакционно ниво: редове по сметки, дати, суми, контрагентни идентификатори, ключове за проследяване. Тук се проверява дали осчетоводяването е консистентно като структура. Изходни документи / SourceDocuments Документният слой: фактури за продажби/покупки и плащания, плюс движения на запаси и транзакции с активи при приложимост. Тук се проверява дали документите и плащанията "затварят" следата към счетоводния слой чрез идентификатори и кодове. Главна книга / CorrespondingAccountsReport Опционална секция за контролни съгласувания: салда/обороти и кореспонденции по сметки. Полезна е, когато данните са налични, но не е задължителна. Структури / Structures Дефиниции на структури, използвани за валидиране на елементите и връзките. Това не е счетоводен регистър, а част от рамката на схемата. Прости типове / SimpleTypes Дефиниции на типове данни (формати, допустими стойности), които позволяват автоматична проверка. Отново: рамка, не бизнес съдържание.

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

3.2.1. Header: какво съдържа и защо счетоводството трябва да го контролира

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

На пръв поглед това е "техническа" секция, но практическата последица е счетоводна: Header е идентичността на подадената версия. Ако организацията управлява версии (което е необходимо при корекции), Header е мястото, където всяка версия трябва да бъде разпознаваема по период и контекст.

Таблица 3.2. Паспорт на Header

Параметър Съдържание и счетоводен смисъл Какво е Header Заглавна структура, която описва файла и подателя: контекстът, без който данните не са интерпретируеми. Какво "заковава" счетоводно Период и вид на подаването (месечно/годишно/при поискване), версия на схемата, момент на създаване. Това са ключови метаданни при контрол и корекции. Езиково правило Текстовите полета са на български, освен изрично дефинирани полета на латиница (например NameLatin).

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

3.2.2. MasterFiles: речници, без които няма валидируемост

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

Счетоводно това е "слоят на речниците". Всяка операция и всеки документ "говори" чрез ключове: AccountID, CustomerID/SupplierID, TaxType/TaxCode, ProductCode, UOM, валута, държава. Тези ключове трябва да имат дефиниция и дисциплина именно в MasterFiles; иначе се чупи референтната цялост и файлът престава да е сравним и проверим като система.

Особено полезно за практиката е следното уточнение от "книжния" ви стил: MasterFiles не е "списък на всички контакти" или "експорт на целия CRM", а речник, който обслужва подадените операции и документи за периода. Това е разликата между "данни за удобство" и "данни за валидируемост".

За да бъде MasterFiles четим като карта и да остане в портретен формат, подсекциите са представени като двуколонна "подсекция – счетоводен прочит", включително отбелязване кога подсекцията е опционална или незадължителна.

Таблица 3.3. Подсекции в MasterFiles: какво е това и кога става релевантно

Подсекция (BG/EN) Счетоводен прочит и практичен контрол Счетоводни сметки / GeneralLedgerAccounts Речник на сметкоплана: AccountID и атрибути (описание, тип сметка и др.). Ключов тест е дали всеки AccountID, използван в журнала, е дефиниран тук и е стабилен във времето. Таксономии / Taxonomies Подсекцията не е задължителна за подаване. Когато се използва, тя е речник на класификационни схеми и изисква устойчивост на кодовете; ако няма данни, не се подава. Клиенти / Customers Речник на клиентите: идентификация, адреси, държава и връзки към разчети. Контролният риск е дублиране или "сливане" на лица, което прави разчетите неинтерпретируеми. Доставчици / Suppliers Аналогично на клиенти, но в посока покупки и плащания. Тук SupplierID е "котва", която свързва фактурата, журнала и плащането. Данъчна таблица / TaxTable Централен речник на данъчните кодове и ставки: TaxType, TaxCode и (където е приложимо) Country/процент. Принципът е "кодове, не имена", защото проверките четат кода, не текста. Таблица с мерни единици / UOMTable Речник на мерните единици: мерната единица престава да е свободен текст към фактурния ред и става код по номенклатура. Контролният риск е паралелни означения за една и съща единица ("бр.", "бр", "pcs") без правило, което води до несъпоставимост. Таблица с аналитичности / AnalysisTypeTable Подсекцията е опционална за подаване. Тя е мястото за измерения (проекти, центрове, обекти) като кодова структура; практическата стойност е да държи аналитиката отделно от идентичността на контрагента/продукта. Таблица за движения на запаси / MovementTypeTable Речник за типовете движения на стоково-материални запаси; става критичен при подаване "при поискване", защото движенията трябва да се кодират като тип, а не да се описват свободно. Продукти / Products Речник на предмета на доставките (стоки/услуги според политиката): ProductCode, описание, мерна единица, а при приложимост – класификация по КН8/NC8. Това е количествено-предметният речник на фактурните редове. Наличности на запаси / PhysicalStock Количествен слой за наличности (режим "материални запаси"). Ако складовата отчетност е непълна или описателна, подаването се превръща в проект по реконструкция. Собственици / Owners Подсекцията не е задължителна за подаване. Когато се подава, тя е master data и изисква устойчиви идентификатори и консистентни атрибути. Активи / Assets Речник на активите за годишното подаване: идентификатори и характеристики на ДМА. Практическият риск е несъгласуван активен регистър, който прави годишния файл труден за извеждане.

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

3.2.3. GeneralLedgerEntries: счетоводният слой като транзакционна хронология

GeneralLedgerEntries е секцията на "журнала": всички счетоводни операции през периода така, както са записани в системата, включително дати, описания, суми, сметки и контрагентни идентификатори, а където е приложимо – данъчна информация.

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

Таблица 3.4. Паспорт на GeneralLedgerEntries

Параметър Съдържание и счетоводен смисъл Какво е GeneralLedgerEntries Журнал на операциите на ниво транзакция и ред: структурата на осчетоводяването за периода. Какво "носи" като доказване Показва счетоводната истина за сумите, сметките и датирането; служи като мост към документния слой чрез идентификатори и референции, когато системата ги поддържа. Къде най-често се чупи При референции към несъществуващи AccountID/CustomerID/SupplierID; при неуникални или нестабилни TransactionID, което разкъсва следата към документи/плащания.

Тук е полезно да се даде неутрален пример, който показва, че SAF-T допуска счетоводни модели, стига да са ясни като структура. В официалните ВЪПРОСИ И ОТТГОВОРИ НА НАП примери се вижда как една транзакция се описва чрез TransactionID и TransactionLine, и как в редовете се използват AccountID (по номенклатура) и TaxpayerAccountID (вашата аналитична сметка), като при определени случаи се допуска специфична логика за CustomerID и SupplierID на ниво транзакция.

Това е важен детайл: SAF-T не ви принуждава да "промените счетоводството си", но ви принуждава да го направите структурно четимо и консистентно като ключове.

3.2.4. SourceDocuments: документният слой, който трябва да се затвори към журнала

SourceDocuments включва фактури за продажби, фактури за покупки и плащания, а при приложимост – движения на стоково-материални запаси и транзакции с активи.

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

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

Таблица 3.5. Подсекции в SourceDocuments: какво съдържат и какво свързват

Подсекция (BG/EN) Счетоводен прочит и типична връзка Фактури за продажби / SalesInvoices Документният слой на продажбите по логиката на ЗДДС: документ + редове + данъчна информация. Връзката към MasterFiles е чрез CustomerID, TaxType/TaxCode, ProductCode, UOM, валута и др. Фактури за покупки / PurchaseInvoices Документният слой на покупките: SupplierID, редове, данъчна информация, суми. Връзката към журнала се затваря чрез идентификатори и референции, когато се поддържат. Плащания / Payments Плащанията са част от документния слой (не от MasterFiles) и се кодират чрез номенклатура за механизми на плащане. Това позволява да се затвори следата документ > плащане, доколкото системата поддържа връзки. Движения на запаси / MovementOfGoods Подават се при поискване, когато е приложимо. Тук ключовото е типът движение да е кодиран (MovementType), а не свободно описан; иначе количествената история не е проверима. Транзакции с активи / AssetTransactions Подават се в режима за активи; движенията по активи се кодират по номенклатура за движение на активи.

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

3.2.5. CorrespondingAccountsReport, Structures и SimpleTypes: "добавъчните" части на картата

Официалната структура включва и секция "Главна книга" (CorrespondingAccountsReport), която е опционална за подаване, както и секции Structures и SimpleTypes.

Практичният счетоводен прочит е следният: CorrespondingAccountsReport е инструмент за съгласувания и може да намали административната тежест при контролни производства, когато данните са налични и качествени; Structures и SimpleTypes са част от дефиниционната рамка на схемата и съществуват, за да може файлът да се валидира по формални правила.

3.3. Номенклатури и принципът "кодове, не имена"

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

Това не е стилистика, а механизъм за сравнимост и машинна проверка: кодът е устойчив идентификатор, името е описание и е вторично.

Тук се съчетават две логики. Първата е "вътрешна": ERP и счетоводството имат свои ключове (например вътрешен код на сметка, вътрешен данъчен код, вътрешен продуктов код). Втората е "външна": стандартът изисква съпоставка към номенклатури (TaxType/TaxCode, ISO, NC8 и др.). Работещият модел не е да заменим вътрешните ключове с външните, а да поддържаме контролирано картографиране (мапинг) с версии и периоди на валидност. Това е най-добрият отговор на изкушението "за по-лесно да ползваме направо външните кодове като наши": подобно решение често разрушава историчността и сравнимостта вътре в системата.

3.3.1. Основните номенклатури и стандарти: кои са и къде се използват

Официалният списък на номенклатурите включва както национални номенклатури (за данъци, типове документи, механизми за плащане, движения на запаси и активи), така и международни ISO стандарти (IBAN, държави, области, валути).

Особено важно е, че в рамката е включена и Комбинираната номенклатура КН8-2025 за кодове на продукти (материални запаси), което поставя продуктовата класификация като част от дисциплината на данните, а не като "митническа тема, далеч от счетоводството".

Таблица 3.6. Номенклатури и стандарти: къде се появяват в структурата и защо са критични

Номенклатура/стандарт Къде се използва и какъв проблем решава Данъчна номенклатура за TaxType/TaxCode В TaxTable и в данъчната информация на документните редове. Решава проблема "данък като свободен текст" и позволява автоматични проверки по код. IBAN (ISO 13616) В платежния слой и банковата идентификация; решава проблема "банка и сметка като описание", като изисква стандартен идентификатор. Държави (ISO 3166-1) и области (ISO 3166-2) В адресни и идентификационни елементи (дружество, контрагенти). Решава проблема "Germany/Deutschland" в поле за код и прави данните сравними и валидируеми. Валути (ISO 4217) В документи и плащания във валута; решава проблема "евро/€" като текст и гарантира еднозначност (EUR, BGN и др.). Номенклатура за видове фактури/документи В документния слой (Sales/Purchase Invoices) за тип документ; подпомага правилата за кредитни известия/сторно и съпоставимост на документните събития. Номенклатура за механизми за плащане В Payments; решава проблема "метод на плащане като свободен текст" и осигурява един и същ кодов език между каса/банка и SAF-T. Номенклатура на мерни единици В UOMTable и във фактурните редове; решава проблема "мерна единица като текст" и прави количествената логика възпроизводима. КН8/NC8 (NC8/TARIC) за продукти (материални запаси) В Products като класификация при приложимост; решава проблема "продукт без официална класификация" при режими, които изискват това, особено за запаси и външнотърговски потоци. Номенклатура за движение на продукти (запаси) В MovementTypeTable и MovementOfGoods; решава проблема "движение като свободен разказ" и прави складовата хронология проверима. Номенклатура за движение на активи В AssetTransactions; кодифицира типове движение (придобиване, продажба, трансфер, брак, преоценка и др.) и прави годишния активен слой машинно четим. Номенклатура за данъчни режими и вид на материалния запас Специализирани кодове за ДДС режими и за класификация на запасите (материали, продукция, стоки, незавършено производство и др.).

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

3.3.2. "Кодове, не имена": типичните грешки, които изглеждат дребни, но блокират валидируемостта

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

Таблица 3.7. Мини-примери "правилно/неправилно"

Домейн Какво означава "кодове, не имена" на практика Данъчни кодове Правилно: TaxType/TaxCode по номенклатура; неправилно: "ДДС 20%" като свободен текст. Банкови сметки Правилно: IBAN по ISO 13616; неправилно: "банка Х, сметка Y" като описание. Държави/области Правилно: ISO 3166-1/3166-2 код; неправилно: наименование ("Germany/Deutschland") в поле за код. Валута Правилно: ISO 4217 код (например EUR, BGN); неправилно: "евро", "лева". Продукти/запаси Правилно: код по КН8/NC8 + описание, когато е приложимо; неправилно: само вътрешно име без класификация в режим, който я изисква.

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

3.3.3. КН8/NC8 и ProductCode = "0": кога е допустимо обобщение и кога е задължителна продуктова карта

Темата за продуктите е мястото, където счетоводният и складовият свят се срещат. Официалната рамка включва Комбинирана номенклатура КН8-2025 за кодове на продукти (материални запаси).

Във ВЪПРОСИ И ОТТГОВОРИ НА НАП се дава много практично разграничение, което е важно да присъства в този раздел, защото намалява риска от грешна политика.

Когато позицията е под складов контрол и се третира като стоково-материален запас (включително полуфабрикати под складов контрол), тя следва да присъства в MasterFiles/Products с вътрешен продуктов код и код по Комбинираната номенклатура (NC8/TARIC), плюс мерна единица от UOM. В този режим код "0" не е приложим.

Обратно, когато имаме покупки, които се разходват директно и не подлежат на контролирано съхранение (не се водят като запаси), е допустимо в PurchaseInvoices редът да бъде агрегатен с ProductCode = "0" и описателен текст; тогава не се подава NC8/TARIC за тази позиция.

Това разграничение е счетоводно рационално: не превръщаме насила разходните позиции в складови артикули само защото минават "управленски" през гр. 30; при липса на реален складов контрол режимът ProductCode = "0" остава защитим.

Таблица 3.8. Решение за ProductCode = "0" срещу ProductCode + NC8

Ситуация Как се подава и защо Полуфабрикат/материал под складов контрол Подавате MasterFiles/Products с вътрешен ProductCode + NC8/TARIC + UOM; документните редове реферират ProductCode; движенията се подават в MovementOfGoods при поискване. Код "0" не е допустим, защото позицията е инвентарна и трябва да има собствена продуктова идентичност и класификация. Покупка, която се разходва директно и не се води като запас В PurchaseInvoices може да има агрегатен ред с ProductCode = "0" и описателен текст; в този режим не е нужно NC8/TARIC, защото няма продуктова карта и складов контрол. Гуми/горива без контролиран склад, дори ако временно минават през гр. 30 Допустимо е да се третират като директно разходвани покупки с ProductCode = "0" и описание, без NC8, ако няма продуктови карти и реален складов контрол.

Това решение има и методологичен бонус: когато организацията е последователна, тя може ясно да обясни защо някои позиции са с NC8 (защото са запаси/артикули), а други са с ProductCode = "0" (защото са директни разходи). В SAF-T това не изглежда като противоречие, а като политика, която е видима в данните.

3.4. Кратка карта "къде какво е": BG/EN ориентир по схемата

Този раздел има нужда от компактна карта, която да позволява на счетоводителя да "превежда" термините от заповедта и практиката към етикетите в схемата. По-долу е дадена двуколонна карта BG/EN, в която EN е представен като секция/път в структурата.

Таблица 3.9. BG/EN карта: секции и ключови подсекции

Български термин (как го срещаме в описанията) EN елемент/път в схемата Главна страница Header Основни данни MasterFiles Счетоводни сметки MasterFiles/GeneralLedgerAccounts Таксономии MasterFiles/Taxonomies Клиенти MasterFiles/Customers Доставчици MasterFiles/Suppliers Данъчна таблица MasterFiles/TaxTable Мерни единици MasterFiles/UOMTable Аналитичности MasterFiles/AnalysisTypeTable Таблица за движения на запаси MasterFiles/MovementTypeTable Продукти MasterFiles/Products Наличности на запаси MasterFiles/PhysicalStock Собственици MasterFiles/Owners Активи MasterFiles/Assets Счетоводни записи GeneralLedgerEntries Изходни документи SourceDocuments Фактури за продажби SourceDocuments/SalesInvoices Фактури за покупки SourceDocuments/PurchaseInvoices Плащания SourceDocuments/Payments Движения на запаси SourceDocuments/MovementOfGoods Транзакции с активи SourceDocuments/AssetTransactions Главна книга CorrespondingAccountsReport Структури Structures Прости типове SimpleTypes

Тази карта е "ориентир". За реалната работа по подготовка е полезно да се добави втори ориентир: веригата от ключове, които свързват слоевете. Това е сърцевината на референтната цялост: всеки идентификатор, използван в операции и документи, трябва да има дефиниция в MasterFiles и да се използва последователно навсякъде.

Таблица 3.10. Ключове и връзки между слоевете: кратък "път на доказването"

Ключ (ID) и счетоводен смисъл Къде се дефинира и къде се използва (връзки) SupplierID/CustomerID – "кой" е контрагентът Дефинира се в MasterFiles/Suppliers или MasterFiles/Customers; използва се във фактурите и в счетоводните транзакции, както и в плащанията. Един и същ ID трябва да "заковава" контрагента във всички слоеве. AccountID – "къде" е осчетоводено Дефинира се в MasterFiles/GeneralLedgerAccounts; използва се в GeneralLedgerEntries/TransactionLine и в документните структури там, където моделът го изисква. TaxType/TaxCode – "как" е обложено Дефинира се в MasterFiles/TaxTable; използва се в редовете на фактурите (TaxInformation) и работи като кодов език, който машината проверява. ProductCode и UnitOfMeasure – "какво" и "в каква мярка" ProductCode се дефинира в MasterFiles/Products, UnitOfMeasure – в MasterFiles/UOMTable; използват се във фактурните редове и при режим "запаси" се връзват към движения и наличности.

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