Електронно фактуриране в ОАЕ от 1 юли 2027 г.: как да подготвите собствена ERP система за Peppol

От 1 януари 2027 г. предприятията в ОАЕ с годишни приходи от 50 000 000 AED или повече трябва да издават и получават фактурите си B2B и B2G като структуриран XML, изпратен чрез акредитиран доставчик на услуги (Accredited Service Provider) през мрежата Peppol. Всички под този праг ги следват на 1 юли 2027 г. и трябва да определят доставчик до 31 март 2027 г. Държавните структури започват на 1 октомври 2027 г.

От датата, на която започвате, данъчната фактура е самият XML. PDF файлът, който системата ви изпраща по имейл днес, остава нужен само като допълнение към него, за клиенти, които още не са в мрежата.

Ако фактурите ви излизат от Zoho, Tally, Wafeq или подобен готов продукт, по-голямата част от това е работа на доставчика на софтуера. И трите са включени в списъка на акредитираните доставчици на Министерството на финансите. Вашата задача е да изберете доставчик, да се регистрирате през EmaraTax и да изчистите данните за клиентите си.

Тази статия е за компании, чиито фактури идват от система, която е тяхна собственост: ERP, разработена вътрешно, инсталация, персонализирана дотам, че вече не може да се надгражда, собствен модул за фактуриране. За такива системи никой не предлага готов конектор. Насоките за електронно фактуриране на ОАЕ го казват ясно: предприятията трябва да „complete any customisations to in-house systems and begin testing the transmission of invoice data" (да завършат персонализациите на собствените си системи и да започнат да тестват предаването на данните от фактурите).

Датите

Етапите са определени с Министерско решение № 244 от 2025 г. с последващите му изменения:

Първоначално в първия ред стоеше 31 юли 2026 г. Министерско решение № 66 от 2026 г. я премести на 30 октомври 2026 г. и не промени датата на старта. Таблицата в насоките все още показва старата дата, затова четете двата документа заедно.

Доброволното прилагане е отворено за всички от 1 юли 2026 г., което е важно за плана по-долу.

Какво попада в обхвата

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

Включени са сделките B2B, B2G, G2B и G2G. Доставките за потребители остават извън обхвата, докато министърът не реши друго, а предприятие, което продава само на потребители, засега изобщо не е обхванато от системата. Има тесни изключения за суверенна държавна дейност, самолетни билети за пътници и финансови услуги, освободени от ДДС.

Ако имате ДДС група, едно облекчение е важно: сделките между членове на една и съща група получават 24-месечен гратисен период от 1 януари 2027 г. Всеки член все пак се регистрира отделно със собствения си TIN, а фактурите към външни страни попадат в обхвата от обичайната дата.

Моделът с пет участника, погледнат от вашата ERP

ОАЕ използва модел с пет участника (five-corner model):

1. Участник 1: вие, доставчикът на стоката или услугата.
2. Участник 2: вашият акредитиран доставчик на услуги (ASP).
3. Участник 3: ASP на вашия купувач.
4. Участник 4: вашият купувач.
5. Участник 5: Федералната данъчна администрация (FTA).

Вашата система разговаря само с една страна: вашия ASP. Изпращате данните за фактурата във формат, договорен с него. ASP ги валидира, при нужда ги преобразува в XML формата на ОАЕ, доставя ги на ASP на купувача и успоредно с това подава данъчните данни към FTA. ASP на купувача валидира полученото и също го подава. Потвържденията се връщат по веригата обратно до вас.

За това подаване се използва отделен документ в Peppol, UAE Tax Data Document, който спецификацията на Peppol описва като „used by both invoice issuer and invoice receiver to report an invoice" (използван както от издателя, така и от получателя на фактурата, за да я декларират). Изгражда го вашият ASP. Вие изграждате обработката на това, което се връща: потвърждение, че страната на купувача е приела фактурата, потвърждение, че FTA е получила данъчните данни, и грешките и при двете.

ASP се грижи за преноса, криптирането, търсенето на участници и UUID, който еднозначно идентифицира всяка фактура. Вие оставате отговорни за изчисляването на всяка стойност във фактурата, както и за събирането на идентификатора в Peppol на купувача си. Доставчикът ви валидира фактурата. Той не я коригира.

Определяте точно един ASP, както за изпращане, така и за получаване.

Какво трябва да генерира вашата система

Форматът

ОАЕ използва Peppol PINT-AE: UBL XML, със спецификация за фактуриране и отделна спецификация за самофактуриране (и двете във версия 1.0.4 към момента на писане). Няма QR код. Не можете да добавяте собствени полета; всичко специфично за отрасъла се договаря с вашия ASP.

Полетата, които обикновено липсват в старите системи

Министерството публикува списък на задължителните полета: 51 за електронна данъчна фактура. Ето тези, които обикновено изискват работа:

• Електронни адреси на двете страни. Вашата крайна точка е 0235 плюс вашия 10-цифрен TIN, който съвпада с първите 10 цифри на вашия TRN. Тази на купувача следва същата схема, което означава ново поле във всеки клиентски запис и някой, който да събере стойностите. Има предварително определени крайни точки за особени случаи: 0235:9900000098, когато купувачът още не е в системата, 0235:9900000099 за купувач при износ без Peppol ID, 0235:9900000097 за приравнени доставки.
• Правна регистрация на продавача. Регистрационният номер плюс неговия вид от фиксиран набор: TL (търговски лиценз), EID (Emirates ID), PAS (паспорт) или CD (решение на Министерския съвет). В търговската фактура регистрацията на купувача също е задължителна.
• Структурирани адреси, включително административната единица (емирството), за продавача и за купувача.
• Условията за плащане като данни. Дата на падеж и код на начина на плащане във всяка фактура.
• Кодирани мерни единици и пълни ценови данни на всеки ред. Код на мерната единица, брутна цена, нетна цена и базово количество за цената. Единиците, съхранявани като свободен текст („бр.", „кашон по 12"), изискват таблица за съответствие.
• Данъчна категория за всеки ред, плюс разбивка по категории: стандартна ставка, освободена доставка, извън обхвата, обратно начисляване, нулева ставка или схема за облагане на маржа. Фактурите с вътрешно обратно начисляване съдържат и пояснителен текст и вида на стоките.
• Суми в AED, винаги. Сумата на ДДС и дължимата сума за всеки ред, в AED, независимо от валутата на фактурата. Фактура в чуждестранна валута изисква и валутата за данъчно отчитане и общата сума с ДДС в AED, по курса на Централната банка.
• Флагове за вида на сделката. Осем позиции, всяка 1 или 0: свободна зона, приравнена доставка, схема за облагане на маржа, обобщена фактура, продължителна доставка, фактуриране от разкрит агент, електронна търговия, износ. В една фактура може да има няколко вдигнати флага и всеки от тях носи свои изисквания. Клиент в свободна зона например изисква и данни за бенефициера.

Едно правило заслужава собствен тестов сценарий: закръгляването се прилага към общата сума на фактурата, до два знака след десетичната запетая, а не на ниво ред или данъчна категория. Ако кодът ви за фактуриране закръглява всеки ред или всяка ставка на ДДС, тествайте го с реални фактури, преди да го направи доставчикът ви.

Стоковите кодове HSN засега не са задължителни, а датата, от която ще станат, тепърва ще бъде обявена. Ако продавате стоки, добавете ги, докато и без това работите по номенклатурата на артикулите.

Кредитни известия, аванси и задържани суми

• Фактура с отрицателна обща сума не се допуска. Кредитът трябва да се издаде като електронно кредитно известие, включително когато обобщена фактура дава нетен кредит.
• Едно кредитно известие може да се позовава на няколко предходни фактури и да покрива само част от някоя от тях. Отстъпките за обем минават през кредитни известия със съответния код на причината.
• Няма категория за проформа фактури. Всяка проформа фактура е пълноценна електронна фактура, която по-късно се коригира с кредитно известие или допълнителна фактура.
• За авансовите плащания се издава данъчна фактура при получаването им. Окончателната фактура покрива само остатъка и се позовава на авансовата фактура.
• Задържаните суми могат да се третират, като се фактурира сумата без задържаната част, а след това се издаде отделна фактура, когато задържаната сума стане изискуема.

Входящите фактури, за които всички забравят

Същият ASP получава фактурите от вашите доставчици. От датата на старта те пристигат като XML и трябва да попаднат в задълженията към доставчици. Често това е по-голямата половина от работата, защото засяга съпоставянето с поръчките и одобренията, а не просто един шаблон на документ.

Големите ви доставчици започват на 1 януари 2027 г. и ще поискат вашия идентификатор. Докато не сте се включили, те изпращат към предварително определената крайна точка и ви дават и обикновена данъчна фактура, така че при вас нищо не се чупи.

Работа с акредитиран доставчик на услуги

Списъкът на министерството съдържаше 65 акредитирани доставчици плюс 5 предварително одобрени, които още бяха в окончателна оценка, когато го проверихме на 10 октомври 2026 г. Министерско решение № 168 от 2026 г., обявено на 9 октомври и в сила от 1 октомври, заменя старите правила за доставчиците: акредитацията вече е пряка, без етап на предварително одобрение, а предварително одобреният доставчик има 30 дни от 1 октомври, за да завърши акредитацията си, иначе губи предварителното одобрение. Избирайте от списъка на акредитираните, а не на предварително одобрените. Регистрацията се стартира от вас, а не от доставчика: администраторът на вашия акаунт в EmaraTax отваря раздела за електронно фактуриране, избира доставчика и бива пренасочен към неговия портал. Първо подпишете договора и проверете дали данните на компанията ви в EmaraTax са актуални.

При собствена система въпросите, които решават проекта, са технически:

1. Какво приема доставчикът? Собствен API формат, обмен на файлове или PINT-AE XML, който генерирате сами. Неговият формат означава по-малко работа днес; собственият ви PINT-AE ви позволява да смените доставчика, без да изграждате съпоставянето наново.
2. Как се връщат потвържденията? Webhook, периодично запитване, файл? И двата вида трябва да се пазят в записа на фактурата, заедно с UUID, който ASP присвоява.
3. Какво става при повторен опит? Изтичане на времето за изчакване се случва. Повторното изпращане на фактура не бива да създава втора, затова договорете как се откриват дубликатите и водете собствен дневник на предаванията като запис на изпратеното.
4. Има ли тестова среда (sandbox), в която да тествате отказите, а не само успешния сценарий?
5. Как достигат до вас входящите фактури? И какво става, докато вашата страна не работи?
6. Ще архивира ли вместо вас? Може да го прави по договор, но задължението за съхранение остава ваше. Записите може да се намират извън ОАЕ, стига да могат да бъдат представени на FTA пълни и четими.

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

Санкциите

Решение на Министерския съвет № 106 от 2025 г. ги определя:

• Невнедряване на системата, включително неопределяне на доставчик в срок: 5 000 AED за всеки месец или част от месец.
• Неиздаване и непредаване на електронна фактура или електронно кредитно известие: 100 AED за всяко, но не повече от 5 000 AED за календарен месец.
• Неуведомяване на FTA за срив в системата или неуведомяване на вашия ASP за промени в регистрираните ви данни: 1 000 AED на ден.

Нито една от тях не се прилага за фактури, издадени доброволно преди задължителната за вас дата.

Деветмесечен план до 1 юли 2027 г.

Към началото на октомври 2026 г. компания под прага разполага с девет месеца. Това е достатъчно за собствена система, ако работата започне сега.

1. Октомври до ноември 2026 г.: анализ на несъответствията. Експортирайте фактурите и кредитните известия за една година, класифицирайте ги по категория, сценарий, данъчна категория и валута и запишете откъде ще идва всяко задължително поле.
2. Ноември до декември 2026 г.: изберете доставчик. Направете кратък списък по техническите въпроси по-горе, подпишете и получете достъп до тестовата среда. 31 март 2027 г. е крайният срок, а не целта.
3. Декември 2026 г. до февруари 2027 г.: разработка. Промени в основните данни и събиране на идентификаторите на клиентите, съпоставянето, валидиране преди изпращане, обработка на потвържденията, опашка за грешки с отговорник и обработка на входящите фактури.
4. Февруари до март 2027 г.: регистрация през EmaraTax, която завършва с вашия идентификатор на участник. Приключете доста преди 31 март.
5. Април до май 2027 г.: тестване от край до край с доставчика: всичките шест стъпки, включително грешките и кредитните известия.
6. Май до юни 2027 г.: доброволен старт. Санкциите не се прилагат за доброволно издадени фактури, така че това е най-евтиното място да откриете последните проблеми. Договорете последователността с доставчика си.
7. 1 юли 2027 г.: задължително. Осигурете хора за опашката за грешки поне до първата справка-декларация по ДДС.

Ако сте в групата на големите предприятия и не сте започнали, имате срок до 30 октомври 2026 г., за да определите доставчик, и по-малко от три месеца до старта. Важат същите стъпки, сгъстени в седмици, а входният формат на самия доставчик вероятно е по-бързият път.

Какво още може да се промени

Датите вече бяха променени веднъж, насоките са във версия 1.1, а версиите на PINT-AE се променят, като доставчиците са длъжни да използват последната. Дръжте съпоставянето в един модул, зад собствен интерфейс, така че обновяване на спецификацията да не засяга кода за фактуриране. Кодовете HSN в даден момент ще станат задължителни, а B2C остава извън обхвата само до ново решение.

Нищо от това не е причина да чакате. Решенията са в сила, а таблицата със санкциите е публикувана.

Откъде да получите помощ

Изграждаме връзката между системата, която генерира фактурите ви, и доставчика, който ги изпраща: съпоставянето на данните, промените в основните данни, валидирането, обработката на потвърждения и повторни опити и обработката на входящите фактури в задълженията към доставчици. Нашата услуга за интеграция на електронно фактуриране описва как протича тази работа, а ако изискването ви застигне по средата на подмяна на системата, вижте модернизация на ERP.

Ако фактурите ви идват от система, за която никой не продава конектор, пишете ни на office@c9group.dev.