Генериране на SAF-T: Защо не е един бутон
Ако в момента се борите с генерирането на SAF-T и използвате счетоводен софтуер - тази статия е написана специално за вас.
Генерирането на SAF-T не е просто един отчет с един бутон. Това е фундаментална промяна в целия начин на работа с вашата програма. Преди да продължите, ако все още не сте запознати с това какво представлява SAF-T, защо го въведоха и какви са реалните проблеми за българската счетоводна практика - препоръчвам да прочетете първо Какво е SAF-T и Грешки при валидация на SAF-T. Ще ви спести много мъка.
В това ръководство ще обясня какво всъщност изисква SAF-T структурата, защо типичният счетоводен софтуер не може да го даде автоматично и какво трябва да знаете преди да се опитате да генерирате валиден файл. Думата „валиден" тук е разковничето - и ще разберете защо.
Какво предлагат счетоводните програми за SAF-T - и какво не казват
Повечето счетоводни системи на пазара са добавили SAF-T функционалност в новите си версии. Появил се е бутон Експорт SAF-T. Звучи лесно.
Не е.
Първо - модулът в повечето случаи се заплаща допълнително или изисква обновяване до нова версия. Ако не виждате SAF-T функционалност никъде в системата, ще трябва да се свържете с вашия доставчик.
Второ - в настоящата българска обстановка софтуерите не са способни да поддържат SAF-T изцяло автоматично. Решенията на разработчиците са доста често повърхностни - добавени са SAF-T полета в системата (CustomerID, SupplierID, данъчни кодове, типове документи, мерни единици, кодове от комбинираната номенклатура), но целият процес на мапиране остава ръчен. Единственото ново са полетата - работата е ваша.
Трето - дори бутонът да съществува, зелената отметка не означава нищо. Файлът може да премине XSD валидацията и пак да бъде отхвърлен от НАП заради бизнес правила, които XSD не проверява. Писали сме подробно за това тук.
Какво всъщност изисква SAF-T структурата
SAF-T файлът се състои от три основни секции. Всяка изисква конкретни данни от вашата счетоводна система - данни, които трябва да извлечете, почистите и мапирате, преди да се генерира валиден XML. За пълния, поле по поле разбор на всяка секция - вижте SAF-T наръчника; за точния списък кодове и номенклатури, които трябва да мапирате - SAF-T речника.
MasterFiles - основни номенклатури
- Сметкоплан с баланси - пълната структура на аналитичните сметки с начални и крайни салда за периода. Повечето системи имат тази справка.
- Клиенти и доставчици - пълен регистър с имена, булстати, държави, градове. Тук започват проблемите.
- Продукти и мерни единици - артикулите от вашата система, всеки трябва да е свързан с NC8/TARIC код от комбинираната номенклатура. Ръчно.
- Данъчни кодове - вашите вътрешни кодове трябва да се мапират към официалните кодове на НАП. Ръчно.
- Типове документи - всеки тип фактура, кредитно известие, дебитно известие трябва да е свързан с официален код на НАП. Ръчно.
SAF-T изисква всички контрагенти задължително да имат въведена държава по ISO 3166-2 и град. Ако не сте въвеждали градове досега - лоша новина.
Освен това всички клиенти и доставчици, които се появяват в месечните осчетоводявания, трябва да са регистрирани в пълния регистър с контрагенти. Ако НАП открие контрагент с определен булстат в транзакциите, но той не е описан в MasterFiles - файлът се отхвърля.
Има и друг, по-коварен проблем: много системи не позволяват стандартно въвеждане на булстати на чуждестранни фирми. Много счетоводители са го заобикаляли с условни булстати - просто за да приеме системата осчетоводяването. Това вече не работи. НАП ще открие несъответствието и ще върне файла. Ще се чудите защо, докато не прочетете тази статия. Пълните правила за идентификаторите на контрагентите - префикси, ЕИК/VIES/ЕГН - са в главата за контрагентите в наръчника.
GeneralLedgerEntries - счетоводни записи
Всички осчетоводявания за периода - дата, дебит, кредит, сума, контрагент, описание. Повечето системи имат справка за движения по сметки, която покрива тази секция. Важно е тя да включва аналитичните нива, не само синтетиката.
SourceDocuments - първични документи
Тук SAF-T изисква данните от конкретните фактури - не само осчетоводяването, а самият документ: номер, дата, контрагент, редове с артикули, данъчна основа, ДДС. За тази секция са нужни:
- Дневник покупки - стандартна справка, присъства в почти всички системи.
- Дневник продажби - същото.
- Детайли по осчетоводените транзакции - тук се разминават системите. Някои имат отделна справка с детайли по документи. Други нямат - и тогава тези данни трябва да се извлекат по друг начин или да се реконструират от наличните справки. Това е една от основните причини SAF-T да не е „един бутон".
Някои системи налагат лимит на редовете при експорт. За фирми с по-голям обем транзакции това е сериозен проблем - справката се отрязва и SAF-T файлът ще е непълен. Свържете се с вашия доставчик и поискайте лимитът да бъде вдигнат преди да започнете.
Реалната картина
Описаното по-горе не е лесно. И знаем го от практика, не от документация.
Да - бутонът Генерирай SAF-T съществува в повечето системи. Но и какво от това? Цялото мапиране е ваше. Множество справки за извличане. Стотици кодове за ръчно свързване с номенклатурите на НАП. Контрагенти с липсващи градове и невалидни булстати. Данъчни кодове, типове документи, мерни единици - всичко ръчно, преди да натиснете бутона.
И след всичко това - зелена отметка, която може да не означава нищо. Ако вече сте получили конкретен текст на отхвърляне от НАП, вижте каталога с реални грешки - разчетен код по код.
Популярно е схващането, че са нужни само дневникът и сметкопланът. Реалността на SAF-T структурата изисква значително повече. Разликата е в това дали файлът ви ще бъде приет от НАП или върнат.
SAF-T е абсурден в сегашния си вид за малкия бизнес. Но докато се промени нещо - трябва да оцелеем. И то с валиден файл всеки месец.
Вижте процеса на живо