الفوترة الإلكترونية في الإمارات 2026: دليل التكامل مع Peppol PINT AE

ما المهمة الهندسية الفعلية؟

لا يتعلّق انتقال الإمارات إلى الفوترة الإلكترونية الإلزامية بإيجاد برنامج جديد لإرسال ملفات PDF، إذ لن تُعدّ الفواتير الورقية وفواتير PDF ممتثلةً للمتطلبات بعد الآن. فالإلزام يشترط تبادل بيانات منظّمة، وتحديداً ملفات XML مطابقة لمواصفات Peppol PINT AE [3].

ويعمل النظام وفق نموذج لامركزي خماسي الأركان مبنيّ على شبكة Peppol [4]. ترسل مؤسّستكم (الركن 1) الفاتورة عبر مزوّد الخدمة المعتمد الذي تختارونه (ASP، الركن 2)، فيوجّهها المزوّد عبر شبكة Peppol إلى مزوّد المستلم (الركن 3)، الذي يسلّمها بدوره إلى المستلم (الركن 4). ويُبلغ كلا المزوّدين منصّة الهيئة الضريبية بالمعاملة (الركن 5)، غير أن مزوّد المشتري لا يُبلغها إلا بعد أن تجتاز الفاتورة التحقّق لديه [2, 6].

ومن منظور هندسي، تتمثّل مسؤوليتكم في إيصال فاتورة صالحة من نظامكم إلى مزوّد الخدمة. وهذه مسألة تكامل أنظمة وتحويل بيانات بامتياز: فأنتم لا تطوّرون منتجاً موجّهاً إلى المستخدمين، بل خدمة تعمل في الواجهة الخلفية وتربط مصدر بياناتكم المالية المرجعي بشبكة الفوترة الوطنية.

كيف ينبغي لفريق التطوير ترتيب العمل؟

ينبغي ترتيب العمل بحيث تُعالَج المخاطر في وقت مبكر، وأكبرها دائماً جودة بيانات المصدر وإمكانية الوصول إليها.

الخطوة 1: اكتشاف البيانات وربط الحقول (Data Mapping). قبل كتابة أي شيفرة، نبدأ بتدقيق البيانات. فوزارة المالية تحدّد 51 حقلاً إلزامياً للفاتورة الضريبية الإلكترونية و49 حقلاً للفاتورة التجارية الإلكترونية [15]. وتتمثّل مهمّتكم الأولى في تحديد موضع كل عنصر من هذه البيانات في أنظمتكم الحالية، سواء أكان نظام ERP أم CRM أم منصّة فوترة، وحصر سيناريوهات المعاملات التي تستخدمونها، لأن عدداً منها يجعل حقولاً إضافية إلزامية [10]. وتحدّد عملية ربط الحقول هذه درجة تعقيد المشروع بأكمله، وهي المرحلة التي يُستهان بها أكثر من غيرها.

الخطوة 2: اختيار مزوّد الخدمة والربط به. ستحتاجون إلى التعاقد مع مزوّد خدمة معتمد من قائمة وزارة المالية [17]، وبعد اختياره سيوفّر لكم وثائق API الفنية وبيانات الدخول إلى بيئة الاختبار. وتتمثّل المهمة التقنية في تطوير عميل API يُجري المصادقة لدى منصّته ويرسل الفواتير بالصيغة التي تتّفقون عليها معه، سواء أكانت PINT AE XML أم صيغة أخرى يتولّى المزوّد تحويلها [6].

الخطوة 3: تطوير منطق التحويل والتوليد. وهذه الخطوة هي جوهر العمل التطويري، إذ نطوّر خدمة تستخرج البيانات من أنظمة المصدر (عبر استدعاءات API أو استعلامات قواعد البيانات أو ملفات التصدير)، وتحوّلها وفق ربط الحقول المحدّد في الخطوة 1، وتنشئ ملف PINT AE XML صالحاً. ويجب أن يكون معرّف المشارك هو رقم التعريف الضريبي للمنشأة (TIN)، أي أول 10 أرقام من رقم تسجيلها للضريبة على الشركات (TRN) [1]. وإذا كانت الشركات منضوية في مجموعة ضريبية لأغراض ضريبة القيمة المضافة، فعلى كل منشأة قانونية أن تستخدم رقم تعريفها الضريبي (TIN) الخاصّ بها، لا رقم المجموعة [5].

الخطوة 4: التحقّق والاختبار. يجب أن يكون ملف XML المولَّد صالحاً وفق مخطّط UBL 2.1 Invoice، أو مخطّط CreditNote في حالة الإشعارات الدائنة [12]، وأن يجتاز مجموعتَي قواعد Schematron في PINT AE كلتيهما [10, 11]. ونُدمج هذا التحقّق مباشرةً في مسار CI/CD لدينا ليرفض آلياً أي تعديل برمجي ينتج فواتير غير صالحة. ثم عليكم اختبار الدورة الكاملة في بيئة الاختبار لدى مزوّد الخدمة، من التوليد مروراً بالإرسال ووصولاً إلى تلقّي إشعار استلام صالح.

ما الحقول الإلزامية في مواصفات PINT AE؟

تنشر وزارة المالية قائمتها الخاصّة بالحقول الإلزامية إلى جانب مواصفات Peppol: 51 حقلاً إلزامياً للفاتورة الضريبية الإلكترونية و49 للفاتورة التجارية الإلكترونية [15]. وستصادفون أيضاً مصطلح «قاموس بيانات PINT AE»، وقد ظهر أول مرة في مسوّدة قاموس البيانات التي طرحتها الوزارة للاستشارة العامة عام 2025، ثم بنت عليها مواصفات PINT AE المنشورة [21]. لذا اربطوا حقولكم بالمواصفات الحالية وبقائمة الحقول الإلزامية لدى الوزارة، لا بمسوّدة عام 2025. واعتبروا القائمة الإلزامية حدّاً أدنى، فقواعد التحقّق في PINT AE تجعل حقولاً أخرى إلزامية بمجرّد انطباق سيناريو معاملة بعينه [10].

والمفتاح الذي يفعّل هذه السيناريوهات هو رمز نوع معاملة الفاتورة (BTAE-02)، وهو حقل خاصّ بالإمارات. وتشترط القاعدة IBR-154-AE أن يكون سلسلة لا تتجاوز ثمانية محارف، لا تحوي سوى 0 و1، بخانة واحدة لكل نوع معاملة [10]. وكل خانة مفعّلة تستدعي بيانات إضافية: فالقاعدة IBR-138-AE تجعل فترة الفوترة إلزامية متى فُعِّلت خانة الفاتورة المجمّعة (XXX1XXXX)، والقاعدة IBR-137-AE تشترط معرّف الأصيل (Principal ID) في فوترة Disclosed Agent، أي الوكيل الذي يتصرّف باسم الموكّل (XXXXX1XX) [10]. وعلى طبقة ربط الحقول لديكم أن تشتقّ هذه الخانات من بيانات المعاملات في نظام ERP قبل أن تحدّد أي الحقول تملأ.

وتخضع المعرّفات والعناوين لقواعد تنسيق يجب أن تستوفيها بياناتكم المصدرية أصلاً. فمعرّف المشارك هو رقم التعريف الضريبي للمنشأة (TIN)، أي أول 10 أرقام من رقم تسجيلها للضريبة على الشركات (TRN) [1]. ويجب أن تكون معرّفات ضريبة القيمة المضافة في الفاتورة هي رقم التسجيل الضريبي المكوّن من 15 رقماً، مبتدئاً بالرقم 1 ومنتهياً بالرقمين 03 (IBR-132-AE). كما يجب أن يذكر العنوان الإماراتي الإمارة بأحد الرموز AUH أو DXB أو SHJ أو UAQ أو FUJ أو AJM أو RAK (IBR-128-AE) [10]. فإذا كان نظام ERP لديكم يخزّن الإمارة نصاً حرّاً مثل «Dubai»، فعلى مرحلة التحويل أن تقابل هذا النص برمز الإمارة الصحيح.

أما ملف XML نفسه فهو بصيغة UBL القياسية: ففاتورة PINT AE مستند من نوع UBL 2.1 Invoice، والإشعار الدائن مستند من نوع UBL 2.1 CreditNote [12]. ويجب أن يبدأ معرّف المواصفات (ibt-024، الذي يحمله العنصر cbc:CustomizationID) بالقيمة urn:peppol:pint:billing-1@ae-1، أو بالقيمة urn:peppol:pint:selfbilling-1@ae-1 في حالة الفوترة الذاتية (ALIGNED-IBRP-001-AE). ويستند المستلمون إلى هذا المعرّف في تحديد مجموعة القواعد التي يطبّقونها [10, 12, 14].

يعرض الجدولان التاليان الحقول الواحد والخمسين الواردة في قائمة الوزارة للفاتورة الضريبية، بترتيب الوزارة نفسه، ويقابلان كل حقل بمصطلح الأعمال الخاصّ به في PINT AE، وبعدد مرات وروده (Cardinality) أو القاعدة التي تحكمه، وبالموضع الذي تأتي منه قيمته عادةً في نظام ERP [10, 22, 23]. أما قائمة الفاتورة التجارية (Commercial Invoice) فتضمّ 49 حقلاً، إذ تُسقط مبلغَي البند بالدرهم (BTAE-08 و BTAE-10)، وتطلب معرّف التسجيل الضريبي للبائع بدلاً من رقم تسجيله الضريبي (ويذكر البائع الذي لا يملك رقم تسجيل رقمَ تعريفه الضريبي)، وتطلب معرّف التسجيل القانوني للمشتري ونوعه بدلاً من معرّفه الضريبي ونظامه الضريبي [23].

كيف تعمل قواعد التحقّق في PINT AE؟

يجري التحقّق على مستويين. فعلى الملف أولاً أن يكون صالحاً وفق مخطّط UBL 2.1 Invoice [12]، ثم يُفحص وفق مجموعتين من قواعد الأعمال المكتوبة بلغة Schematron والمنشورة مع مواصفات PINT AE: قواعد PINT المشتركة والقواعد الخاصّة بالإمارات [10, 11].

تنطبق القواعد المشتركة (ومعرّفاتها من قبيل IBR-001 و IBR-CO-10) على كل فاتورة PINT في أي دولة كانت، فإن أخفقت الفاتورة في أيٍّ منها فليست فاتورة PINT صالحة [11]. أما القواعد الخاصّة بالإمارات، وهي التي تنتهي معرّفاتها بالحرفين AE إضافةً إلى قواعد ALIGNED-IBRP، فتنطبق على جميع المرسِلين في الإمارات [10]. وتفحص المجموعتان معاً وجود الحقول وقوائم الرموز وصيغ المعرّفات والعمليات الحسابية: فالقاعدة IBR-CO-10 مثلاً تشترط أن يساوي مجموع صافي مبالغ البنود على مستوى المستند (ibt-106) إجمالي صافي مبالغ البنود منفردة (ibt-131) [11].

شغّلوا الفحوص نفسها في مسار التطوير لديكم، لتُخفق الفاتورة المعيبة في مرحلة CI لا لدى مزوّد الخدمة. فحزمة الموارد المتاحة للتنزيل على موقع Peppol PINT AE تضمّ مجموعتَي القواعد بصيغة Schematron وبصيغة XSLT المترجمة، إضافةً إلى قوائم الرموز وفواتير نموذجية. وثبّتوا الإصدار الذي تُجرون الاختبار عليه: فقد صحّح الإصدار PINT AE 1.0.4، الصادر في 2 يونيو 2026، منطق التحقّق في عدد من القواعد [13]، لذا أعيدوا تشغيل اختبارات الانحدار لديكم كلّما انتقل مزوّد الخدمة إلى إصدار جديد.

وتتكرّر هذه الفحوص في بيئة التشغيل الفعلي: فمزوّد خدمتكم يتحقّق من البيانات التي ترسلونها [6]، ومزوّد خدمة المشتري يتحقّق من الفاتورة، وتصلكم النتائج في صورة رسائل «حالة على مستوى الرسالة» (Message Level Status، MLS) يمرّرها مزوّد خدمتكم [7]. لذا احفظوا كل حالة مقرونةً بفاتورتها، ووجّهوا حالات الإخفاق إلى الفريق المسؤول عن بيانات المصدر.

ويبيّن الجدول التالي القواعد التي تحسم في أغلب الأحيان قبول بيانات نظام ERP أو رفضها، والأسباب المعتادة للإخفاق فيها، والمعالجة التي موضعها طبقة ربط الحقول [10, 11].

ما العقبات التقنية الشائعة؟

جودة البيانات. رداءة بيانات المصدر هي أكثر أسباب الإخفاق شيوعاً، فإذا كان حقل إلزامي مثل عنوان المشتري ناقصاً أو بتنسيق خاطئ في نظام ERP لديكم، أخفق التكامل. لذا يجب أن يتضمّن المشروع خطة لتنقية البيانات وضبط جودتها عند المصدر.

الأنظمة القديمة. كثيراً ما تفتقر أنظمة ERP القديمة أو أنظمة المحاسبة المطوّرة خصّيصاً إلى API حديث، فيصعب أحياناً استخراج البيانات المطلوبة منها، وقد يستلزم ذلك اتصالاً مباشراً بقاعدة البيانات أو عمليات تصدير هشّة عبر الملفات. وهذا يضيف تعقيداً كبيراً وأعباء صيانة إضافية مقارنةً بالاستخراج النظيف عبر API.

معالجة الأخطاء. تصل الحالة النهائية بصورة غير متزامنة: فبعد الإرسال، يعيد كلٌّ من مزوّد خدمة المشتري والمنصّة الضريبية رسالة MLS، يمرّرها إليكم مزوّد خدمتكم لاحقاً [7]. لذا يحتاج نظامكم إلى آلية لمعالجة الأخطاء تتعامل مع حالات الرفض الواردة من المزوّد، وتُبلغ الفرق الداخلية المعنية بالإخفاق، وتدير إعادة الإرسال دون إنشاء فواتير مكرّرة.

هل يستطيع QuickBooks أو غيره من برامج المحاسبة إرسال فواتير PINT AE؟

حتى أبريل 2026، لم يكن QuickBooks Online يدعم الفوترة الإلكترونية في الإمارات دعماً مدمجاً، بحسب ردود Intuit نفسها على منتداها. ففي ديسمبر 2025، ذكر ردّ من فريق QuickBooks على منتدى QuickBooks Community أن QBO لا يدعم الفوترة الإلكترونية في الإمارات مباشرةً، وأنه لا جديد بشأن خطط التكامل مع Peppol أو مع مزوّدي الخدمة المعتمدين خلال عام 2026 [18]. وفي أبريل 2026، ذكر ردّ آخر من الفريق نفسه أن الفوترة الإلكترونية في QBO غير متاحة في المنطقة، وأحال المستخدمين إلى تطبيقات طرف ثالث [19]. وهذه ردود موظّفين على منتدى، لا إعلانات رسمية عن المنتج، فتحقّقوا منها مجدّداً قبل أن تبنوا خططكم عليها.

ولا يلزم أن يولّد برنامج المحاسبة لديكم ملف PINT AE XML بنفسه، غير أنه يجب أن يوفّر كل عنصر من بيانات PINT AE. ففي النموذج الذي وضعته وزارة المالية، يرسل المورّد بيانات الفاتورة إلى مزوّد خدمته بالصيغة المتّفق عليها، فيتحقّق المزوّد منها ويحوّلها إلى صيغة XML الإماراتية المعيارية إن وصلته بصيغة مختلفة [6]. وفي حالة QuickBooks، أو أي نظام يفتقر إلى الدعم المدمج، يتّخذ التكامل شكل أداة ربط (connector) تستخرج كل فاتورة، وتربط حقولها بمواصفات API لدى مزوّد الخدمة، وترسلها، ثم تسجّل الحالة الواردة منه في سجلّ الفاتورة.

ويسري قيدان أيّاً كان من يطوّر أداة الربط هذه. الأول أن يكون مزوّد الخدمة مدرجاً في قائمة مزوّدي الخدمة المعتمدين لدى وزارة المالية، وهي قائمة تُحدَّث كلّما اعتُمد مزوّدون جدد [17]. ويشترط الاعتماد أن يكون المزوّد نشطاً وحاصلاً على شهادة Peppol، وأن يكون قد اجتاز اختبارات المطابقة لدى OpenPeppol [16]. والثاني أن إسناد العمل إلى الغير لا ينقل المسؤولية: فبموجب PINT، يجوز للمرسِل والمستلم إسناد دوريهما إلى مزوّدي خدمة، لا إسناد مسؤوليتهما [14]. فإذا عرض عليكم مورّد إضافةً برمجية لبرنامج QuickBooks، فتأكّدوا ممّا إذا كان هو نفسه مزوّد الخدمة المعتمد أم طبقة وسيطة تعمل أمام أحد المزوّدين المعتمدين.

يندرج هذا المقال ضمن عملنا في تكامل الأنظمة، ويعكس منهجية التخطيط التي تقوم عليها طريقة عملنا.

أبرز النقاط

• الفوترة الإلكترونية في الإمارات مشروع تكامل أنظمة، لا نموذج امتثال يُملأ.
• تتمثّل المهمة الأساسية في ربط بيانات مؤسّستكم بالحقول الإلزامية الـ51 في الفاتورة الضريبية وفق PINT AE، إضافةً إلى الحقول التي تجعلها سيناريوهات معاملاتكم إلزامية.
• ابدأوا بتدقيق بيانات نظام ERP وأنظمة المصدر، فهذا التدقيق هو المرحلة الأهم والأطول.
• يجب أن يولّد نظامكم ملفات XML صالحة، ويتّصل بـ API مزوّد الخدمة، ويعالج أخطاء الإرسال برمجياً.
• ينبغي أن يكون التحقّق الآلي وفق مخطّط UBL 2.1 ووفق مجموعتَي قواعد Schematron في PINT AE جزءاً من عملية التطوير والنشر.
• بحسب ردّ Intuit على منتداها في أبريل 2026، لم يكن QuickBooks Online يدعم الفوترة الإلكترونية في الإمارات دعماً مدمجاً، ولذا يحتاج إلى أداة ربط بمزوّد خدمة معتمد.

المصادر

1. UAE: Technical guidance on mandatory e-invoicing fields (kpmg.com)
2. United Arab Emirates electronic document specifications (docs.peppol.eu)
3. e-Invoicing UAE: Key Requirements, Implementation Timeline and Latest Updates (cleartax.com)
4. B2B e-Invoicing in the United Arab Emirates (UAE): EDICOM Pre-Approved e-Invoicing Service Provider| EDICOM (edicomgroup.com)
5. UAE e-invoicing mandate 2026: Readiness, ASP, and PINT AE (avalara.com)
6. eInvoicing (mof.gov.ae)
7. eInvoicing (mof.gov.ae)
8. Ministry of Finance announces targeted amendments to eInvoicing system decisions (mof.gov.ae)
9. Ministry of Finance announces targeted amendments to eInvoicing system decisions (mof.gov.ae)
10. AE specific PINT rules (docs.peppol.eu)
11. Shared PINT rules (docs.peppol.eu)
12. Peppol International (PINT) model for Billing (docs.peppol.eu)
13. Release notes for PINT AE Billing (docs.peppol.eu)
14. PINT compliance (docs.peppol.eu)
15. Mandatory e-Invoicing Fields in UAE : What Businesses Must Include (cleartax.com)
16. Accreditation of eInvoicing Service Providers (mof.gov.ae)
17. eInvoicing Accredited Service Providers (ASPs) (mof.gov.ae)
18. Will QBO integrate with the UAE FTA’s mandatory e‑invoicing system, which rolls outf rom July 2026, covering B2B and B2G transactions via Peppol standards and ASPs? (quickbooks.intuit.com)
19. E-invoicing for tax purposes in UAE (quickbooks.intuit.com)
20. Implementation of the Electronic Invoicing System in the UAE (kpmg.com)
21. MoF publishes PINT AE specifications for E-invoicing (deloitte.com)
22. PINT AE Billing semantic model (docs.peppol.eu)
23. UAE Electronic Invoice Mandatory Fields, version 1.0 (mof.gov.ae)
24. UAE Electronic Invoicing Guidelines, version 1.1 (mof.gov.ae)
25. Cabinet Decision No. 106 of 2025 on violations and administrative penalties for the electronic invoicing system (mof.gov.ae)