← Обратно към общността
SAF-T

САФ -Т грешка "Невалидна сума"

Анонимен специалист · 19.07.2026 13:23

Колеги, седмица 7-ми ден под напрежение със САФ-Т, а усещането е, че всеки ден излиза нова "тайна" версия на схемата. 

Имам конкретен казус и искам мнение: При генериране на XML-а за продажби, системата ми връща грешка за несъответствие в ДДС-то с 0.01 лв. (една стотинка!). В счетоводната програма всичко е изравнено, но НАП-портала я връща.

Регистрирайте се, за да участвате в дискусията.

Регистрация Вход
Топ коментатори
magi
6
Ваня Иванова Ненова
2
9 коментара
Най-добри Нови Стари
magi ·виж отговорите
magi magi Админ Счетоводител · Акълиев ООД · 19.07.2026 13:34
ТОП КОМЕНТАР
Здравейте, колега, тази грешка е една от най-честите при генериране на SAF-T и в 90% от случаите причината е следната: Счетоводната програма изчислява ДДС на ниво документ (върху общата данъчна основа на фактурата), а SAF-T схемата очаква сумите на ниво ред (TaxAmount за всеки InvoiceLine), като после валидира дали сборът на редовете съответства на декларираната обща сума в DocumentTotals. Когато имате фактура с няколко реда и ДДС-то е смятано върху общата основа, сборът от закръглените по редове суми може да се разминава с +/- 0.01 лв. от общото ДДС. В програмата всичко е "изравнено", защото тя гледа документа като цяло - но XML-ът носи и двете стойности и НАП ги сверява. Какво да проверите конкретно: 1. Намерете точния документ от съобщението за грешка (обикновено портала посочва InvoiceNo или поне реда в XML-а). Съберете ръчно TaxAmount по редовете и ги сравнете с TaxPayable / GrossTotal в DocumentTotals. 2. Ако разликата е там - решението е стотинката да се "абсорбира" в последния ред на документа (т.нар. penny allocation / корекция в последния ред), така че сборът по редове да е равен на документното ДДС. Това е стандартна практика и не променя нищо счетоводно. 3. Проверете и за кредитни известия - при тях знакът на сумите е друг чест източник на разминаване от стотинки. 4. Ако документът е във валута - разликата може да идва от това, че курсовата конверсия се прави веднъж върху общата сума в програмата, а в XML-а по редове. Важното е, че това не е грешка във вашето счетоводство, а несъответствие между логиката на закръгляне на софтуера и очакванията на схемата. За съжаление повечето легаси програми не са проектирани да експортират на ниво ред с консистентно закръгляне, така че корекцията често трябва да стане на етапа на генериране на XML-а, не в самата програма. Работя точно върху този проблем от година насам (междинен софтуерен слой, предназначен само за SAF-T генериране) и мога да кажа, че разминаванията от стотинки са топ 3 причини за отхвърлени файлове. Ако темата е интересна на повече хора, мога да напиша отделна статия как се решава системно.
редактиран · 19.07.2026 13:36
Анонимен счетоводител ·виж отговорите
Анонимен специалист · 19.07.2026 13:41
Благодаря за супер подробния отговор! Честно казано, прочетох го 3 пъти, за да го осмисля 😅 Ясно ми е, че става въпрос за закръгляне и стотинките, но признавам, че като "обикновен" счетоводител, като видя думи като "абсорбиране в последния ред" и "наливане на ниво ред", ме хваща лека паника. Въпросът ми е практически...Аз работя с по 100-150 фактури на ден. Как точно да "абсорбирам" стотинката в последния ред? Моята счетоводна програма няма бутон "коригирай закръглянето за SAF-T" и не мога да ровичкам из XML-а ръчно за всеки документ - няма да свърша до Нова година. Накрая пак си мисля - значи пак софтуерът ми е виновен. Има ли някакъв автоматичен начин това да се оправя преди качването в портала, или трябва да звъня на софтуерната фирма и да ги моля за ъпдейт (което ще отнеме месеци)? Понеже виждам, че колегите тук активно четат някой от вас ползва ли инструмент/надстройка, която сама оправя тия стотинки, или всички се занимавате с ръчни ексели преди финала? Сега като се замисля ако имаше софтуер, който да гледа схемата на НАП в реално време и сам да подравнява тия закръгляния, сигурно щях да спестя по 2 часа на ден...
magi ·виж отговорите
magi magi Админ Счетоводител · Акълиев ООД · 19.07.2026 13:51
Точно за това "звънене на софтуерната фирма и чакане месеци за ъпдейт" - не сте виновни нито вие, нито изцяло програмата ви. Тези системи са писани преди 15-20 години за съвсем друг свят и никой няма да ги пренапише за SAF-T. Затова и подходът ми е друг. Последната година разработвам точно такъв инструмент - казва се Magi (https://www.magi-ledger.com/bg/). Идеята е проста: не пипате нищо в счетоводната си програма. Изваждате си справките, както сте свикнали, качвате ги в Magi, и системата: - генерира валиден SAF-T XML по актуалната схема на НАП; - автоматично хваща и коригира точно тези разминавания от стотинки (сверява сбора по редове с InvoiceDocumentTotals и подравнява закръглянето, преди файлът изобщо да стигне до портала); - валидира срещу XSD схемата и срещу бизнес-правилата на НАП, така че грешката я виждате при нас с ясно обяснение на български, а не като криптично съобщение от портала след качване; - помага и с мапването на всички ваши вътрешки кодове към номенклатурите на НАП. При 100-150 фактури на ден ръчна корекция в XML е немислима - точно този сценарий е причината Маги да съществува. Работим вече с една от големите счетоводни къщи в страната и с колеги на Алма и Микроинвест, със способност да интегрираме и вашия софтуер. Ако искате, пишете ми лично или през сайта - с удоволствие ще ви покажа на живо с ваши реални справки как минава целият процес. Демото е безплатно и обикновено отнема 20-30 минути, а най-полезното е, че веднага виждате дали вашите експорти се разпознават коректно.
Анонимен счетоводител ·виж отговорите
Анонимен специалист · 19.07.2026 13:58
Радвам се, че не съм единственият, който е стигнал до извода, че старите програми няма как да се оправят. Искам да попитам няколко много важни за мен (и сигурно за другите) неща, преди да скоча с двата крака: Сигурност и GDPR: Аз все пак качвам данни на клиенти - ДДС-та, суми, ЕГН-та на собственици. Как работи това? Данните излизат ли от моя компютър в "облака", или Magi работи локално? Това е червената линия за мен и за моите клиенти. Споменахте Алма и Микроинвест, но аз работя с една по-стара програма (да я наречем "Х"), която сигурно я няма в списъка ви. Справките, които мога да извадя, са стандартен Excel/CSV. Ще може ли Magi да прочете моите колони, или пак ще трябва да преправям ексели, за да паснат на вашия шаблон? Аз съм счетоводител, не програмист. Този Magi има ли сложен интерфейс, или ме води за ръка "стъпка 1, стъпка 2..."? Питам, защото, ако тези три неща са ок, аз абсолютно искам да пробвам това демо.
magi ·виж отговорите
magi magi Админ Счетоводител · Акълиев ООД · 19.07.2026 15:15
Добри въпроси Отговарям по ред: 1. Сигурност и GDPR. Ще бъда напълно откровен: Magi е уеб-базирана система, тоест данните се качват на сървър - но сървърът е в ЕС (Германия), с криптирана връзка, и данните се обработват единствено за генерирането на вашия SAF-T файл. Не се споделят с трети страни, не се използват за нищо друго, и можете да ги изтриете по всяко време. Важно уточнение: това са същите данни, които така или иначе подавате към НАП през техния портал - не качвате нищо, което не излиза от кантората ви бездруго. При демото минаваме през целия процес и по темата за защитата на данните, включително договор за обработка (ДОД/DPA), какъвто вие като администратор имате право да изискате. Ако за конкретен клиент имате абсолютна забрана за външна обработка - кажете го директно, ще ви кажа честно дали Маги е за вас или не. 2. Програма "Х" и стандартен Excel/CSV. Точно за това е строена системата - тя е "преводач" между хаоса от формати и SAF-T. Алма и Микроинвест са готовите интеграции, при които всичко е автоматично, но ядрото работи с колонни данни: ако справката ви е читав Excel/CSV с разпознаваеми колони (дата, документ, контрагент, сметка, основа, ДДС...), системата ги съпоставя, а вие само потвърждавате. Няма "наш шаблон", към който да преправяте екселите - идеята е обратната: вие показвате какво изважда програмата ви, ние го научаваме. Най-честният отговор обаче е: пратете ми една анонимизирана справка от "Х" (без реални имена/ЕГН-та) и ще ви кажа конкретно, а не по принцип. 3. Интерфейсът. Три стъпки, буквално: (1) качвате справките, (2) преглеждате и потвърждавате мапирането на кодовете - системата предлага, вие одобрявате, (3) виждате грешките (ако има) с обяснение на български и сваляте готовия XML. Строена е за счетоводители, не за програмисти - това е цялата ѝ философия. Но най-добре не ми вярвайте на думи: на демото работим с ваши реални справки и сам ще прецените за 20 минути. Пишете ми лично или през сайта и ще уговорим време.
Анонимен счетоводител ·виж отговорите
Анонимен специалист · 19.07.2026 17:09
Оценявам много, че не се опитвате да замажете, че Magi е уеб-базиран, а директно казвате "данните са на сървър в ЕС" и предлагате договор за обработка. Честно казано, като счетоводител, това за мен е решаващо. Все пак тия данни отиват и към НАП, така че рискът не е по-голям, а дори напротив, ако вие ми дадете ДОД, значи имам документ за клиента. Супер, че го казвате направо, без да криете. Най-много ме облекчи това за Excel-а! Притеснявах се, че пак ще ме карат да преправям колони, за да пасна на "техен шаблон", но като казвате, че Маги се учи от моя файл - това е злато. Ще приготвя една справка от "Х" (ще замажа имената и ЕГН-тата, както предложихте) и може да я пратя предварително, за да спестим време по време на демото. Ще започна кореспонденцията на имейла, посочен в в сайта [email protected].
Ваня Иванова Ненова ·виж отговорите
В Ваня Иванова Ненова Счетоводител · 10.09.2026 12:12
тръпки ме побиват , още нямам фирми за SAFT, направо не знам как ще се справя
magi ·виж отговорите
magi magi Админ Счетоводител · Акълиев ООД · 10.09.2026 12:17
свържете се с мен на телефон 0884190505. мога да помогна по въпроса
Ваня Иванова Ненова ·виж отговорите
В Ваня Иванова Ненова Счетоводител · 10.09.2026 12:27
Благодаря, като наближи времето ще се обадя
Пишете ни