SAF-T когато складът и счетоводството са в различни системи: разминаването, което години наред никой не е гледал
Повечето фирми в България отдавна водят склада в една програма, а счетоводството - в друга. Години наред това работеше спокойно. Двете системи нямаха причина да се сверяват една с друга и никой не ги караше. SAF-T им даде тази причина. И извади наяве нещо, което в много компании тихо си е седяло отдавна: количества и стойности, които отдавна не съвпадат.
Защо склад и счетоводство живеят в различни светове
Складовата програма следи физическото движение - доставки, продажби, бракове, трансфери между обекти. Счетоводната програма следи какво е осчетоводено - фактури, аналитични сметки, данъчни периоди. Гледат една и съща стока, но от два различни ъгъла, с различен ритъм на въвеждане и често от различни хора.
Докато никой не ги сравни ред по ред, разликата остава невидима. Месецът приключва счетоводно. Складът показва някакво количество. Никой не спира да провери дали числото от едната система наистина отговаря на числото от другата - защото досега нямаше нужда.
Къде точно се чупят нещата при SAF-T
SAF-T не позволява това разминаване да остане скрито. Файлът изисква MasterFiles / Products и наличностите по склад да се връзват с движенията в SourceDocuments и с крайните салда по съответните счетоводни сметки в GeneralLedgerAccounts. Три различни подсекции, захранвани от два различни софтуера - и НАП очаква числата да се връзват.
Типичните проблеми, които виждаме:
- Складова бройка, различна от счетоводно отчетеното количество - заради трансфер, въведен в склада, но още неосчетоводен.
- Стойност на наличност по среднопретеглена цена в склада, различна от салдото по сметка 304/302.
- Брак или липса, записана в склада, без съответна счетоводна статия.
- Продукт без обвързан код по NC8_TARIC, защото досега никой софтуер не го е изисквал.
Всяко от тези изглежда дребно. Натрупано през 12 месеца обаче се превръща в разминаване, което вече не може да се обясни с една корекция в последния момент.
Защо никой не го забелязва, докато НАП не го поиска
Месечният SAF-T минава, но е редно да се подаде правилно описан и мапиран склад. Разминаването между склад и счетоводство води до файл, неотразяващ реалността.
Истинският момент на истината идва също, когато НАП поиска файла „при поискване" - този с пълната складова история, движение по движение, с 14 дни за подаване. Там вече наистина няма къде да се скрие. Всяко движение трябва да сочи към конкретна счетоводна статия.
Защо това е рисково именно сега
Разминаване, което се е трупало тихо месеци наред, не се оправя с един уикенд преди подаване. Реконструкция на 12 месеца складова история, за да съвпадне със счетоводството, е точно работата, за която 14 дни обикновено не стигат. Точно този тип несъответствие е сред най-честите технически причини за санкция - вижте какво точно струва, в евро.
Истинската цена на разминаването
Не е само рискът от санкция. Това са часове, прекарани в ръчно сравняване на две таблици ред по ред. Това е решение под напрежение - да „закръглиш" число, защото няма време да намериш истинската причина. И е точно онзи тип несъответствие, което привлича внимание при ревизия - не защото счетоводството е грешно, а защото две системи разказват две различни истории за една и съща стока.
От опит мога да кажа, че в повечето случаи проблемът не е в лошия софтуер или в некомпетентни хора. Проблемът е в процеса. Когато складът и счетоводството се водят на различни системи от различни хора, на различно време, без редовна сверка, разминаванията са почти неизбежни. SAF-T просто ги прави видими.
Ако да - проверете кога за последно сте сверявали количество и стойност по продукт между двете, не само общата сума в баланса.
Ако се въвеждат от различни хора и на различно време - там се ражда разминаването.
Без него Products подсекцията не може да се попълни коректно, независимо колко точен е складът.
Ако отговорът е „трябва да проверя" - разминаването вече съществува. Въпросът е само кога ще ви излезе сметката.
Как Magi решава това
Magi приема експортите от счетоводния и складовия софтуер такива, каквито вече ги имате - без нов ERP и без да сменяте начина, по който работите. При обработката на данните системата кръстосано проверява складовите движения и наличности срещу счетоводните записи и салда, преди файлът да бъде генериран - не след подаването, когато НАП вече е открил проблема.
Там, където двете системи разказват различни истории за едно и също количество или стойност, Magi го показва като конкретна грешка с точен ред и причина, вместо общо „невалиден файл". Продуктите без код по NC8_TARIC се съпоставят автоматично чрез AI класиране, вместо ръчно, продукт по продукт.
Ако складът и счетоводството са в различни системи, Magi обединява данните, мапира продуктите към NC8_TARIC и генерира SAF-T файл, в който двете истории вече съвпадат.