Проверки и съгласувания (мостове)

5.1. Защо "мостовете" са централната дисциплина при SAF-T

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

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

5.2. "Ключовият мост": ОВ ↔ журнал ↔ ДДС ↔ фактури ↔ плащания

Веригата ОВ ↔журнал ↔ДДС ↔фактури ↔плащания може да се разбере като минималната "затворена следа" на периода. Идеята е проста: ако една организация може да докаже тази следа, тя не просто подава файл – тя подава проверима счетоводна система в данни.

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

Първият тип е числова консистентност: обороти, основи, ДДС суми, разчети и плащания трябва да се "затварят" по правила (включително правила за допустими изключения – закръгляния, валутни разлики, частични плащания, прихващания и др.).

Вторият тип е референтна консистентност: идентификаторите (AccountID, CustomerID/SupplierID, InvoiceNo/InvoiceRef, TransactionID, PaymentRef и др.) трябва да са стабилни и да "сочат" към реални записи в MasterFiles и към свързаните слоеве. Именно референтната консистентност е причината мостовете да не могат да се заменят с "добър отчет": отчетът може да изглежда коректен, но ако ключовете са хаотични, системата става неинтерпретируема като данни.

Таблица 1. Веригата на съгласуване като контролна логика

Мост (съгласуване) Какво доказва (в счетоводен прочит) Как изглежда "скъсването" ОВ ↔журнал Че агрегатът (оборот/салдо) е сума от редовете; че експортът на журнал е пълен за периода ОВ "съвпада" с ГФО, но журналният експорт е непълен; или има операции извън периода/с грешни дати Журнал ↔ДДС слой/фактури Че данъчната логика е счетоводно обяснима: ДДС по документи се вижда в счетоводните записи по правила Разлики в данъчна дата, ръчни корекции, смесени кодове, ДДС "не излиза" от сметките Фактури ↔ разчети ↔плащания Че историята "документ–разчет–пари" е проследима; че отворените салда са обясними Неразнесени плащания, плащания без основание, "стари" салда без ясна причина

Логиката на тези съгласувания е разработена като превантивна рамка "контроли преди подаване", именно за да се избегне цикълът "подаване → отхвърляне → корекция → нов файл".

5.3. Триъгълните съгласувания: как се строи мостът като методика

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

Първото съгласуване (ОВ ↔журнал) е фундаментът. Ако оборотите по сметки от оборотната ведомост не са равни на сумата от дебитните и кредитните редове в журнала (по същите сметки и за същия период), всички следващи проверки се превръщат в шум. Причината е проста: документният слой може да е перфектен, но ако журналът е непълен или периодизацията е неконсистентна, математиката на периода няма как да се затвори.

Второто съгласуване (журнал ↔ДДС слой/фактури) "заключва" данъка в счетоводството. SAF-T прави данъчния слой видим чрез данни – данъчни кодове, данъчни основи и ДДС суми по редове на документи. Ако организацията не може да обясни как тези суми се "превеждат" в ДДС сметки и обороти по тях (с предварително дефинирани изключения), тя ще има хронични разлики, които или водят до отхвърляне/въпроси, или създават постоянна нужда от "разказ след факта".

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

Таблица 2. "Триъгълни" съгласувания – минимално правило и доказателство

Съгласуване Минимално правило Какво остава като доказателство ОВ ↔журнал Оборотите по сметка в ОВ = сбор на редовете по същата сметка в журнала (за периода) Експорт ОВ + експорт журнал + мостова таблица ОВ–журнал журнал ↔ДДС/фактури ДДС по фактури (по правила) = движение по ДДС сметки / данъчен слой в журнала (по правила) Експорт фактури/ДДС регистър + експорт журнал + мост фактура–журнал фактури ↔разчети ↔плащания Всяко плащане има контрагент и разчетна логика; отворените салда са обясними чрез фактури/плащания Регистър плащания + списък отворени позиции + справка за неразнесени плащания

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

5.4. Как изглежда един мост като работна таблица (минипример без фирмени имена)

Нека използваме неутрален казус, който е типичен в практиката: получена фактура за текущ разход с ДДС (например енергия/услуга), осчетоводена в края на периода, а платена през следващия период. В SAF-T това събитие живее в няколко слоя: контрагент в MasterFiles, операция в GeneralLedgerEntries, документ във PurchaseInvoices и плащане в Payments за периода на плащането.

Критичният момент за мостовете е, че съгласуването не е само "сума срещу сума", а "сума + дата + ключ". Ако фактурата е за м. 01, но е въведена в системата на 10.02, тя пак трябва да попадне в SAF-T за периода, за който се отнася осчетоводяването (периодизация), а не за периода на въвеждането; именно затова полетата Period/PeriodYear и GLPostingDate са концептуално различни от SystemEntryDate.

Таблица 3. Минимост "Фактура nжурнал" (примерни стойности)

Ключ Документен слой (PurchaseInvoice) Журнален слой (GL) InvoiceRef PI-2026-01-00015 Референция към TransactionID TRX-2026-01-0042 Данъчна основа 1 000,00 Дт разход 1 000,00 ДДС 200,00 Дт ДДС за възстановяване 200,00 Общо 1 200,00 Кт доставчици 1 200,00 Данъчен код TaxCode по номенклатура Същият код/логика (в данъчната структура или чрез сметките)

Този мост е "успешен", когато (1) сумите се затварят по правила, (2) контрагентът е еднозначен и валиден, (3) данъчният код е по номенклатура, а не свободен текст, и (4) има ясна референция документ ↔операция. Именно последният елемент е това, което превръща файла от "експорт" в контролно доказателство.

5.5. Типични дефекти: как се проявяват в мостовете и защо са "скъпи"

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

Таблица 4. Дефект → как "светва" в мостовете → ранен контрол

 

Дефект (типов) Как се вижда в мостовете Ранен контрол и управленско решение Дублирани контрагенти Разчетите не се затварят; плащанията "отиват" към друг ID; фактура и плащане изглеждат несвързани Дедуп по ЕИК/ДДС № + правила "едно лице = една карта" + собственик на мастер данни Хаос в данъчни кодове ДДС слой не се съгласува; кодове са текстове; различни кодове за една и съща логика Единен данъчен речник + мапинг към номенклатура; забрана за свободен текст Липсващи референции Фактура не намира GL отпечатък или плащане няма основание Минимално правило за референции + месечен "invoice-to-GL bridge" и "unmatched payments check" Нестабилни AccountID/двусмислен мапинг ОВ-журнал дава разлики по сметки; GL редове сочат към "несъществуващи" сметки Процес за промяна на сметкоплан + версия/контрол + 100% покритие AccountID (GL ↔MasterFiles) Неконтролирани корекции и периодизация Мостовете "танцуват" месец за месец; много версии на истината Процедура за корекции и заключване; контрол на PostingDate/EntryDate и на периода на осчетоводяване

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

5.6. Особен казус, който често създава разминавания: периодът на осчетоводяване срещу датата на въвеждане

При месечния SAF-T критично значение има принципът: периодът на осчетоводяване е водещ, дори когато операцията е въведена по-късно в системата. В разясненията е показано именно това: запис може да бъде въведен през юли, но да се отнася за юни, и тогава Period/PeriodYear и GLPostingDate се попълват за периода на осчетоводяване, докато SystemEntryDate остава датата на въвеждане.

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

Първо, мостът ОВ ↔журнал трябва да стъпва на една и съща дефиниция за периода. Ако ОВ е "заключена" към дадена дата, но журналният експорт включва записи, въведени след тази дата със задна отчетна дата, мостът ще даде разлика. Решението не е да "коригираме моста", а да синхронизираме процеса на приключване: кога ОВ става финална и кога се допуска back-posting.

Второ, мостът журнал ↔фактури трябва да има правило за това кои разлики са допустими и документируеми (например: разлика в данъчна дата, разлика в отчетна дата по начисляване, ръчна корекция). Без такова правило всяка разлика изглежда като дефект, а целта е обратната: дефектите да са малко и ясни, а допустимите изключения да са предвидими и "пакетирани" като контролен разказ.

5.7. Процесна рамка: кога се изпълняват мостовете и какво остава като следа

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

Таблица 5. Месечен цикъл на мостовете като вътрешен контрол

 

Етап Какво се фиксира като "финално" Какво остава като артефакт Стабилизиране на мастер данни сметкоплан, контрагенти, данъчни кодове експорти + протокол за дедуп/мапинг Контролна ОВ агрегатът за периода ОВ + журнал + мост ОВ–журнал Данъчен слой финални ДДС регистри/фактури мост фактури–журнал + справка по данъчни кодове Разчети и плащания финален платежен регистър и разнасяне unmatched payments check + списък отворени позиции/aging Генериране и подаване SAF-T файл за периода подписан файл + протокол от вътрешна валидация

Тази рамка е особено важна, защото подаването минава през формални и логически проверки, и при несъответствия се влиза в режим на отстраняване и повторно подаване.

5.8. Допълнение: техническата проверка като част от "моста", не като отделен свят

Макар мостовете да са счетоводна дисциплина, има една техническа част, която е добре да бъде "включена" в същата логика: валидацията към актуалната XSD-схема и към приложимата версия. Когато схемата се обновява (например промени във типове елементи, промени в режими Mandatory/Optional или уеднаквявания на структури), това влияе директно върху риска от отхвърляне и върху качеството на вътрешната валидация. Практическият принцип е: вътрешната проверка трябва да използва същата схема и същите правила, спрямо които ще се валидира и подаването.

5.9. Практическо заключение: какво означава "готов мост"

"Готов мост" не означава "няма разлики". Означава три неща едновременно.

Първо, че разликите са структурирани: ясно е кое е дефект и кое е допустимо изключение по правило.

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

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

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