С наближаването на поетапното въвеждане на Стандартния одитен файл за данъчни цели (SAF-T) в България, счетоводната общност е изправена пред необходимостта да се запознае в детайли с новите изисквания за подаване на счетоводна информация към НАП. Един от ключовите аспекти е осчетоводяването на фактурите за покупки и продажби. Каква информация ще трябва да подаваме, колко детайлна трябва да бъде тя и кои полета са абсолютно задължителни?
Съгласно последните измененията и допълнения в ДОПК (напр. ДВ, бр. 26 от 27.3.2025 г.), подаването на
месечния SAF-T файл (съдържащ счетоводните записи с покупки, продажби, плащания и другите начисления) ще бъде
до 14-о число на месеца, следващ отчетния, а
годишният SAF-T файл (съдържащ информация за дълготрайните активи и материалните запаси) –
едновременно с подаването на годишната данъчна декларация. Въпреки че за различните категории предприятия са предвидени различни срокове за влизане в сила на задължението (от 2026 г. за големи предприятия до 2030 г. за микропредприятия), подготовката и адаптацията на системите трябва да започне отрано, тъй като промените са съществени.
Един от най-притеснителните и трудоемки аспекти на SAF-T е отразяването на първичните документи, и по-специално – фактурите за покупки, защото с новите правила се изисква всички данни от фактурата, ред по ред, с количества, стойности, мерни единици и единични цени, да бъдат въвеждани в счетоводен софтуер, който да успее да генерира SAF-Т файла за подаване. Това се отнася не само за фактурите за материални запаси, но и за всички получени и издадени фактури от предприятието.
Изискванията по SAF-Т към счетоводствата са много по-мащабни, но в тази статия ще разгледаме само тези, касаещи осчетоводяването на фактурите. Въз основа на
публикуваните от НАП проекти на XSD схема, таблични описания на структурата (Приложение 2) и указания за формата и реда за подаване (Приложение 3), по които тече обществено обсъждане до 09 юни, нека разгледаме как се очаква да се представят фактурите за покупки в SAF-T файла. Отразяването на продажните фактури е аналогично и поради причината, че те обичайно се издават чрез софтуер, то считаме, че за изпълнението на SAF-Т формата за тях би било по-лесно, предвид това, че данните за тях се създават директно в софтуера, с който се фактурира. Покупните фактури обаче трябва да бъдат по-детайлно въвеждани от досегашната практика.
Какво се осчетоводява и как се представя в SAF-T? Ключови аспекти на детайлизацията.
Основен принцип, заложен в SAF-T, е точното и детайлно отразяване на съдържанието на оригиналния първичен документ (фактурата). Това означава, че ако фактурата от доставчика съдържа множество редове, изброяващи различни стоки или компоненти на услуги, всеки от тези редове трябва да бъде възпроизведен като отделен InvoiceLine елемент в SAF-T файла. Това изискване е значително отклонение от текущата практика в много предприятия, особено малките и средните, където фактури за разходи (канцеларски материали, комунални услуги и др.), които не формират складови наличности, често се осчетоводяват с обобщени суми. За всяка фактура за покупка, SAF-T изисква не само общата информация, но и детайлно описание на закупените стоки или услуги на ниво ред, информация за доставчика и връзката на реда със счетоводните сметки и записвания.
Задължително използване на номенклатури на ниво ред
Едно от съществените изисквания е, че за всеки ред от фактурата (InvoiceLine) трябва да се използват кодове от официално утвърдени от НАП номенклатури. Това включва:
➤ Счетоводна сметка (AccountID): За всеки ред от фактурата трябва да се посочи счетоводната сметка (за стока, услуга, разход), като този код трябва да бъде от националния сметкоплан, предоставен от НАП (номенклатура NRA_Nom_Accounts). Предприятията ще трябва да картографират своя индивидуален сметкоплан към този на НАП.
➤ Мерна единица (InvoiceUOM): За всеки ред, където е приложимо (особено за стоки), трябва да се посочи мерната единица, като се използва код от официалната номенклатура за мерни единици (номенклатура Unit of Measure).
➤ Други кодове: Подобни изисквания за използване на кодове от номенклатури важат и за други полета като InvoiceType (тип на фактурата), GoodsServicesID (индикатор стока/услуга), TaxType и TaxCode (за ДДС информация).
Основни елементи при отчитане на фактура за покупка (със статус на задължителност)• Обща информация за фактурата (на ниво елемент Invoice):
» InvoiceNo (Задължително): Номерът на оригиналната фактура.
» InvoiceDate (Задължително): Датата на издаване.
» InvoiceType (Задължително): Тип на документа (код от Nom_Invoice_Types).
» GLPostingDate (Задължително): Датата на осчетоводяване в Главната книга.
» TransactionID (Задължително): Уникален идентификатор, свързващ фактурата със счетоводната статия в GeneralLedgerEntries.
» AccountID (Задължително): Аналитичната счетоводна сметка за разчети с доставчика (от NRA_Nom_Accounts).
» SelfBillingIndicator (Задължително): Индикатор за самофактуриране ("0" или "1").
» PaymentTerms (Незадължително): Условия за плащане.
» Period (Незадължително) и PeriodYear (Незадължително): Счетоводен период и година.
» SourceID (Незадължително): Идентификатор на потребителя/системата, въвели фактурата.
» SystemID (Незадължително): Вътрешен системен номер на документа.
• Информация за доставчика (елемент SupplierInfo в Invoice):
» Елементът SupplierInfo е Задължителен.
» В него трябва да се попълни поне едно от следните:
» SupplierID (Задължително, ако се избере тази опция): ЕИК/БУЛСТАТ на доставчика.
» ИЛИ Name (Задължително, ако се избере тази опция): Наименование на доставчика.
» BillingAddress (Задължително): Адрес за фактуриране на доставчика.
» City (Задължително): Населено място.
» Country (Задължително): Държава (ISO код).
» Останалите компоненти на адреса (StreetName, Number, PostalCode, Region) са незадължителни.
• Редове на фактурата (елемент InvoiceLine – поне един ред е задължителен):
» LineNumber (Задължително): Пореден номер на реда.
» ProductDescription (Задължително): Описание на закупената стока или услуга.
» GoodsServicesID (Задължително): Индикатор стока ("G") или услуга ("S") (от Nom_GoodsServicesID).
» Quantity (Задължително): Закупено количество.
» InvoiceUOM (Задължително): Мерна единица (код от Unit of Measure).
» UnitPrice (Задължително): Единична цена без ДДС.
» InvoiceLineAmount (Задължително): Обща стойност на реда без ДДС (структура AmountStructure със Задължителни Amount, CurrencyCode, CurrencyAmount; ExchangeRate е Незадължително, освен при нужда).
» TaxPointDate (Задължително): Дата на данъчното събитие.
» AccountID (Задължително): Счетоводната сметка за стоката/услугата/разхода (от NRA_Nom_Accounts).
» DebitCreditIndicator (Задължително): "D" или "C".
» Description (Задължително): Описание на реда.
» TaxInformation (Задължително - поне един елемент):
» TaxType (Задължително) (от VAT_TaxType).
» TaxCode (Задължително) (от TAX-IMP).
» TaxPercentage (Условно задължително/Задължително, ако има данък).
» TaxBase (Условно задължително/Задължително, ако има данък).
» TaxAmount (Задължително) (структура AmountStructure).
» TaxExemptionReason (Незадължително).
» TaxDeclarationPeriod (Незадължително).
» ProductCode (Условно задължително): Код на продукта/услугата от MasterFiles/Products. (За услуги указанието е за общ код "00000000" за ProductCommodityCode).
» ShippingCostsAmount (Незадължително).
» Analysis (Незадължително).
• Общи суми за фактурата (елемент InvoiceDocumentTotals - Задължително):
» NetTotal (Задължително): Обща нетна стойност.
» GrossTotal (Задължително): Обща брутна стойност.
» TaxInformationTotals (Незадължително).
» ShippingCostsAmountTotal (Незадължително).
Данни за доставчика в MasterFiles/Suppliers/Supplier (Основни данни)
За пълнота, освен данните в самата фактура, в MasterFiles за доставчика се изискват:
• SupplierID (Задължително)
• CompanyStructure (Задължително):
» RegistrationNumber (Задължително)
» Name (Задължително)
» NameLatin (Задължително)
» Address (Задължително - поне един адрес):
» City (Задължително)
» Country (Задължително)
» Останалите компоненти са Незадължителни.
» RelatedParty (Задължително)
» TaxRegistration (Условно задължително, на практика Задължително за ДДС номер):
» TaxRegistrationNumber (Задължително, ако се подава TaxRegistration).
» Contact (Незадължително).
» BankAccount (Незадължително).
• AccountID (Задължително): Вашата счетоводна сметка за разчети с доставчика (от NRA_Nom_Accounts).
• OpeningDebitBalance или OpeningCreditBalance (Задължително едно от двете).
• ClosingDebitBalance или ClosingCreditBalance (Задължително едно от двете).
Примери за отчитане на различни типове фактури за покупки
Фактура за покупка на стоки за склад: Всеки ред от фактурата с различна стока ще се описва като отделен InvoiceLine в SAF-T. AccountID на реда ще бъде съответната сметка за материални запаси (напр. 304). ProductCode ще е задължителен, ако управлявате стоките с кодове.
Фактура за канцеларски материали (директен разход): Ако фактурата от доставчика изброява "химикалки - 10 бр.", "хартия - 5 пакета" и тн., то в SAF-T се очакват отделни редове с количество, единична цена, мерна единица и стойност в InvoiceLine елемента, като AccountID на всеки ред ще бъде разходната сметка (напр. 601).
Фактура за електроенергия: Ако фактурата има един основен ред за "Доставена електроенергия" с общо количество и стойност, то в SAF-T ще има един InvoiceLine. Но обичайно такава фактура детайлизира отделно дневна и нощна енергия като отделни редове с количества, мерни единици и цени, те ще бъдат отделни InvoiceLine елементи с своите мерни единици, количества, единични цени и стойности. AccountID ще е разходната сметка за ел. енергия.
Такъв е подходът за фактурите с множество компоненти, дори и стопанската операция да е директен разход (напр. фактура от "Топлофикация"). Както знаете, фактурата изброява "Топлинна енергия за подгряване на вода", "Топлинна енергия за отопление" и "Услуга дялово разпределение" и други отделни редове с количества, цени и суми, те трябва да бъдат отделни InvoiceLine елементи в SAF-T, като всеки ред сочи към съответната разходна сметка.
Примерите за такива фактури, които не отчитат стоково-материални запаси, но ще изискват това детайлно въвеждане в счетоводните системи, са неизброими.
Последици за счетоводния софтуерТова ниво на детайлизация налага сериозна преработка и актуализация на използваните счетоводни програми. Софтуерът трябва да може не само да съхранява, но и да експортира тази информация за всеки ред от всяка фактура, независимо дали тя се управлява количествено-стойностно в склад. Доставчиците на счетоводен софтуер и самите предприятия ще трябва да инвестират време и ресурси, за да осигурят съвместимост. Препоръчително е тестването на тези функционалности да започне възможно най-рано, дори и за предприятията, за които задължението ще възникне на по-късен етап.
Заключение за счетоводната общностВъвеждането на SAF-T ще изисква фундаментална промяна в начина, по който много счетоводни предприятия, обработват и записват данните от фактурите. Изискването за детайлизация "ред по ред" на всички фактури, независимо от тяхното счетоводно третиране като директен разход, е сериозно предизвикателство. Ключово е разбирането, че секция SourceDocuments трябва да отразява съдържанието на оригиналния документ, ред по ред, ако той е детайлизиран. Докато счетоводното отразяване в GeneralLedgerEntries може да бъде по-обобщено (напр. един ред за разход за канцеларски материали), то самата фактура в SAF-T изисква по-голяма детайлизация, ако така е издадена от доставчика. Задължителните полета са многобройни и изискват точност, както и правилното използване на дефинираните от НАП номенклатури. Въпреки наличието на незадължителни полета, за пълнота и избягване на последващи въпроси е препоръчително да се попълва максимално коректна и релевантна информация.
Всичко това налага не само пренаписване и адаптиране на счетоводните софтуери, но и отделяне на значително повече време за обработка на документите в счетоводните предприятия. Предвид кратките срокове за подаване, особено за месечния SAF-T файл (до 14-о число), е от изключителна важност предприятията и разработчиците на софтуер да започнат подготовката си своевременно, дори ако за тях задължението влиза в сила на по-късен етап от предвидената поетапност. Внимателното планиране и тестване на системите ще бъдат ключови за успешното преминаване към новия режим на отчитане.