Електронното фактуриране Fawtara в Оман през 2027 г.: какво трябва да могат персонализираните ERP и POS системи

Оман заменя хартиените фактури и фактурите в PDF със структурирани електронни фактури в XML, които минават през акредитиран доставчик на услуги и се докладват на Данъчната администрация на Оман (Oman Tax Authority, OTA). Програмата се казва Fawtara. Данъчно задължените лица с годишни доставки над 5 милиона омански риала (OMR) започват на 1 април 2027 г. Всички останали лица, регистрирани по ДДС, започват на 1 октомври 2027 г.

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

Датите и коя от тях се отнася за вас

Източникът е Fawtara FAQ на OTA, последно обновен на 31 август 2026 г. Критерият е формулиран ясно. Внедрявате от 1 април 2027 г., ако е изпълнено едно от двете:

• доставките ви от 1 април 2026 г. до 31 март 2027 г. надхвърлят 5 000 000 OMR, или
• очакваните ви доставки от 1 април 2027 г. до 31 март 2028 г. надхвърлят 5 000 000 OMR.

„Ако нито едно от двете не е изпълнено, сте длъжни да внедрите електронно фактуриране от 1 октомври 2027 г.“

Какво се включва в сумата: облагаемите доставки без дълготрайните активи, стоките и услугите с обратно начисляване и доставките в рамките на ССЗ (Съвета за сътрудничество в Залива). ДДС групата се оценява на ниво група, а не по отделни членове. Чуждестранно лице без седалище в страната отчита само доставките, извършени в Оман.

Обърнете внимание на второто условие. Бизнес, който расте към 5 милиона OMR, може да попадне в априлската група само заради прогнозата си. Ако сте близо до прага, приемете, че сте в април.

OTA поддържа инструмент за проверка на въвеждането, който приема вашия VATIN и текущия и очаквания ви диапазон на доставките и показва възможен период на внедряване. Той е обозначен като предназначен само за информиране и подготовка, затова приемайте отговора му като ориентир, а FAQ като правилото.

Графикът вече се е променял веднъж

Собствената HTML страница с често задавани въпроси на OTA все още описва стария план: сто големи компании от август 2026 г., всички големи компании от февруари 2027 г., всички останали от август 2027 г. PDF документът заменя тези дати с април и октомври 2027 г. За първата група избрани големи данъкоплатци (Rollout 1) август 2026 г. остава официалната дата на старт, с гратисен период до края на октомври 2026 г. като част от пилотен проект.

Едно изречение в раздела за графика в PDF документа казва, че задължителното съответствие над 5 милиона OMR е в сила от „1 април 2026 г.“. Всичко останало в същия документ казва 1 април 2027 г., включително подробния отговор за обхвата, цитиран по-горе. Изглежда като грешка, но е добра причина да работите по първоизточника, а не по нечие резюме, включително нашето.

Как работи Fawtara

Fawtara работи върху Peppol по модел с пет ъгъла:

1. Ъгъл 1: вие, продавачът, издавате фактурата.
2. Ъгъл 2: вашият акредитиран доставчик на услуги (ASP) я валидира спрямо правилата на Оман и я препраща.
3. Ъгъл 3: доставчикът на услуги на купувача я получава.
4. Ъгъл 4: купувачът.
5. Ъгъл 5: OTA, която получава данъчните данни от доставчиците на услуги.

Форматът е XML, изграден по спецификациите PINT Oman, които OpenPeppol публикува (Billing Process, версия 1.0.1 към момента на писане). FAQ е категоричен: „PDF фактурата не е електронна фактура“. Все още можете да разпечатвате на хартия, но само електронната фактура е валидна фактура за данъчни цели.

Три детайла от FAQ определят инженерната работа:

• Доставчикът валидира, отговорността остава ваша. ASP проверява всяка фактура спрямо правилата schematron на Оман, но „отговорността за съответствието на фактурите остава у данъкоплатците“.
• Свързвате се с един доставчик в даден момент. Заявявате връзката през портала Fawtara и по-късно можете да смените доставчика.
• Няма стандартен API за данъкоплатците. По думите на FAQ свързването на данъкоплатец „не е стандартизирано и зависи от системата на доставчика на услуги“. Вашата ERP система комуникира с интерфейса на доставчика, а не с OTA.

Когато купувачът е потребител или бизнес, който още не е в мрежата, доставчикът ви пак докладва данъчните данни на OTA, а клиентът получава фактурата както досега. Износът минава от вас към доставчика и оттам към OTA.

Кой вече е покрит

Ако доставчикът на вашата ERP или POS система сам е акредитиран доставчик на услуги или предлага конектор към такъв, по-голямата част от тази статия не е ваш проблем. FAQ казва, че ERP системите „могат да бъдат запазени въз основа на договореността на данъкоплатците с техните акредитирани доставчици на услуги“, а при готова система тази договореност трябва да я осигури производителят. Вашата работа са основните данни и тестването.

Можете и сами да станете доставчик на услуги. Критериите за акредитация включват оманска търговска регистрация с ИТ дейности, минимален внесен капитал, история на дейността и сертификат ISO/IEC 27001, а FAQ добавя успешно преминаване на тестовите пакети Peppol eDelivery и PINT OM. Това е подходящо за софтуерни компании. За търговец на дребно не е пряк път.

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

Какво трябва да се промени в софтуера ви

Съпоставете данните от фактурите с PINT Oman

Указанието на FAQ за съпоставянето е един ред: използвайте спецификациите Oman PINT. В семантичния модел специфичните за Оман полета (с префикс BTOM) са там, където отива най-много усилие:

• UUID за всеки документ (BTOM-002). Той трябва да е RFC 4122 версия 5, т.е. базиран на име. Извличайте го от нещо стабилно, например юридическо лице, клон, каса и номер на документа, и тогава повторно изпращане дава същия UUID, а не втора фактура.
• Вид на транзакцията по фактурата (BTOM-001). Това е низ от 20 позиции, в който всяка позиция е флаг: пълна данъчна фактура, опростена данъчна фактура, самофактуриране, трета страна, износ, приравнена доставка, обратно начисляване при внос на услуги, облагане на маржа, електронна търговия, внос на стоки, доставка в специална зона, авансово плащане и други. Може да са зададени повече от един флаг. Системата ви трябва да знае кои се отнасят за всяка фактура, а повечето ERP системи никога не са съхранявали това.
• Идентификатори на продавача и купувача с код на схемата: търговска регистрация, данъчен идентификационен номер, граждански идентификационен номер, паспорт, митнически идентификатор на вносителя или номер на лиценз за специална зона.
• Валута. Валутата на фактурата, валутата за отчитане на ДДС, обменният курс между тях и общата сума на ДДС във валутата за отчитане имат отделни полета.
• Кодови списъци за освобождаване от ДДС, основания за нулева ставка, видове услуги и административни единици на страните.

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

Третирайте всяка продажба като документ

Това е правилото, което променя POS системите: „Обобщени фактури не се допускат при B2C транзакции. Електронна фактура трябва да се издава отделно за всяка фактура.“ Без обобщение в края на деня. Магазин, който маркира 3 000 продажби на ден, изпраща 3 000 електронни фактури на ден.

FAQ дава на B2C документите 24 часа за изпращане, а на B2B документите реално време. За една каса това означава:

• POS системата създава XML (или предава продажбата на услуга, която го прави) в момента на продажбата, заедно с UUID. За B2C има отделно поле за UUID на касовата бележка (BTOM-004).
• Опашка със съхранение и препращане задържа документите, когато мрежата или доставчикът не работят, и ги изпраща в рамките на 24-те часа.
• Някой получава сигнал, когато документ все още не е изпратен след няколко часа, а не след двадесет и три.

Сравнете цените на доставчика с обема си, преди да подпишете. FAQ казва, че всеки доставчик определя собствен модел, който „може да включва абонаментни такси, такси на транзакция или други ценови схеми“. При обемите в търговията на дребно таксата на документ е отделен ред в бюджета.

B2B в реално време

При фактурите между бизнеси изпращането е в реално време. ERP системата ви осчетоводява фактурата, доставчикът я валидира и резултатът се връща. Това променя процеса на фактуриране по два начина. Грешките при валидиране вече излизат в момента на осчетоводяването, затова някой във финансовия отдел има нужда от екран, който показва отказа и позволява да се поправи. Освен това номерирането на фактурите, UUID и логиката за повторни опити трябва да са правилни от първия ден, защото изтекло време за отговор, последвано от сляпо повторно изпращане, е точно начинът, по който се появяват дублирани фактури.

Потокът върви и в обратната посока. Когато вие сте купувачът, електронните фактури от доставчици, които вече са във Fawtara, пристигат като XML чрез вашия доставчик на услуги и отделът за задълженията се нуждае от начин да ги въвежда.

QR кодове на разпечатаната бележка

QR кодът се генерира от вас (ъгъл 1), а не от доставчика. Той е задължителен за всички B2C транзакции, пълни или опростени, и се отпечатва на четимата от човек фактура, а не в XML. OTA планира да го използва за проверка на фактурите чрез мобилно приложение. За съдържанието му FAQ препраща към приложение D на документа Peppol Oman Architecture (версия 1.0.2): вземете това приложение, преди някой да препроектира касовата бележка. Шаблоните на бележките и драйверите на принтерите са част от този проект.

Кредитни известия, връщания и корекции

Веднъж издадена, електронната фактура се коригира с електронно кредитно или дебитно известие. Спецификацията има полета за UUID на оригиналната фактура и код на основанието (BTOM-031 и BTOM-032), така че връщането на пари на касата трябва да може да намери оригиналната продажба.

Внос и самофактуриране

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

Архивиране

Съхранението остава за вас. FAQ казва, че OTA няма да връща информацията за фактурите на данъкоплатците, а Peppol не съхранява документи. Пазете валидирания XML, отговора на доставчика и разпечатаната версия заедно, съгласно правилата за съхранение на законодателството за ДДС.

План назад от крайния срок

FAQ казва, че OTA се свързва с участниците във въвеждането поне шест месеца преди тяхното включване. За априлската група това е сега.

Ако започвате на 1 април 2027 г.:

1. Октомври 2026 г.: потвърдете групата си с инструмента за проверка и критерия от FAQ. Избройте всяка система, която издава фактури: ERP, всяка POS система, плащането в онлайн магазина, таксуването на наеми или абонаменти и всеки кочан за ръчни фактури.
2. Ноември 2026 г.: изберете доставчик. Поискайте API документация и тестова среда, преди да подпишете, и питайте за обема на B2C, цената на документ, работата без връзка и как изглеждат отговорите при валидиране. Заявете връзката през портала Fawtara.
3. Декември 2026 г. до януари 2027 г.: разработка. Съпоставяне на полетата, генериране на UUID, логика за вида на транзакцията, опашката в POS, QR кодове, процес за кредитни известия, входящи фактури. Пускайте правилата schematron на Оман от изтеглянията на PINT Oman в собствения си тестов конвейер, за да се появяват грешките при разработката, а не при доставчика.
4. Февруари 2027 г.: тестове от край до край в тестовата среда на доставчика с реални образци от всеки вид транзакция, който действително издавате, включително неудобните (износ, връщания без бележка, чуждестранна валута).
5. Март 2027 г.: генерална репетиция в продукционна среда с един клон или една бизнес линия, план за преминаване и график на дежурствата за първите седмици.

Ако започвате на 1 октомври 2027 г., последователността е същата, изместена с шест месеца: доставчикът е избран до края на първото тримесечие, разработката е през второто, тестването приключва до август. Не изразходвайте резерва. Почистването на данните винаги отнема повече време, отколкото някой предвижда.

Какво все още не е ясно

Датите вече са се местили веднъж и може да се преместят отново. Планирайте по PDF документа от 31 август 2026 г. и проверявайте документите на OTA всеки месец, вместо да разчитате на новинарски публикации. Правното основание е Решение 189/2026, което изменя Изпълнителния правилник към Закона за ДДС. FAQ казва, че след началото на задължението ще се прилагат санкции по законодателството за ДДС, но не посочва размери, затова и ние не посочваме.

Спецификациите също имат версии. Сайтът на Peppol посочва процесите PINT OM за фактуриране, самофактуриране и данъчни данни във версия 1.0.1, без дата на издаване. Датата, която показва, 29 юли 2026 г., е датата на издаване на PDK 1.4.4 на същата страница, а не на спецификациите за Оман. Фиксирайте версията, по която разработвате, и проверявайте страницата за нови.

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

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

Ако сте в априлската група и още не сте избрали доставчик, пишете на office@c9group.dev.