إذا كانت إيرادات شركتك في الإمارات تبلغ 50 مليون درهم سنويًا أو أكثر، فإن 30 أكتوبر 2026 هو الموعد الذي يجب أن تكون قد عيّنت فيه مزوّد خدمة معتمدًا (ASP) للفوترة الإلكترونية. أما التطبيق الفعلي فيبدأ في 1 يناير 2027. وقد سبق لوزارة المالية أن مدّدت موعد تعيين المزوّد مرة واحدة، من 31 يوليو، وأكّدت بوضوح أن موعد يناير لم يتغيّر.
معظم خطط المشاريع التي اطّلعنا عليها تتعامل مع الأسابيع الأربعة المقبلة كعملية شراء: مقارنة عدد من المزوّدين، ثم توقيع عقد مع أحدهم، وينتهي الأمر. لكن اختيار المزوّد هو الجزء الأسهل. فالمزوّد يتحقق مما ترسله أنظمتك ويمرّره، وإذا أرسلت أنظمتك بيانات خاطئة، أو أرسلت الفاتورة مرتين، أو لم تعلم أصلًا أنها رُفضت، فلن يصلح المزوّد ذلك نيابةً عنك. يتناول هذا المقال الجزء الواقع في جهتك من الاتصال.
أين تقف الأمور في سبتمبر 2026
- الأساس القانوني هو القراران الوزاريان رقم 243 ورقم 244 لسنة 2025. يحدّد القرار 243 الإطار العام (النطاق، ودور المزوّد المعتمد، ونموذج البيانات، والأرشفة)، ويحدّد القرار 244 المراحل والمواعيد.
- في 10 مايو 2026 مدّدت وزارة المالية موعد تعيين المزوّد المعتمد للشركات التي تتجاوز إيراداتها 50 مليون درهم من 31 يوليو إلى 30 أكتوبر 2026، وأبقت التطبيق الكامل في 1 يناير 2027، وذكرت أن عدد المزوّدين المعتمدين بلغ آنذاك 32 مزوّدًا.
- الشركات التي تقل إيراداتها عن 50 مليون درهم تعيّن مزوّدها قبل 31 مارس 2027 وتبدأ التطبيق في 1 يوليو 2027، وتليها الجهات الحكومية في 1 أكتوبر 2027. وقد أصبح التطبيق الطوعي متاحًا منذ 1 يوليو 2026 (ملخّص Andersen).
- يشمل النطاق المعاملات بين الشركات (B2B) ومع الجهات الحكومية (B2G). أما المعاملات مع المستهلكين (B2C) فمستثناة حاليًا، وكذلك بعض الخدمات المالية وتذاكر نقل الركاب جوًا (KPMG).
- تبدأ الغرامات بموجب قرار مجلس الوزراء رقم 106 لسنة 2025 من تاريخ بدء كل مرحلة: 5,000 درهم عن كل شهر لعدم التطبيق، و100 درهم عن كل فاتورة تُرسل متأخرة (بحد أقصى 5,000 درهم شهريًا)، و1,000 درهم عن كل يوم تأخير في الإبلاغ عن عطل في النظام أو عن تغيير في البيانات (VATupdate).
ما الذي يتغيّر فعلًا
لن يعود ملف PDF المرفق برسالة بريد إلكتروني هو الفاتورة. ستصبح الفاتورة مستند XML منظّمًا بصيغة PINT AE (النسخة الإماراتية من الفاتورة الدولية لشبكة Peppol)، وتنتقل عبر نموذج الأركان الخمسة. وتصف Boru Consulting هذه الأركان كالتالي: نظام المورّد الذي تصدر منه الفاتورة، ومزوّد المورّد المعتمد (يتحقق من مطابقتها لـ PINT AE ويمرّرها عبر Peppol)، ومزوّد المشتري المعتمد، ونظام الاستلام لدى المشتري، ثم الهيئة الاتحادية للضرائب التي تتلقى البيانات الضريبية من مزوّد المورّد.
هناك نتيجتان تغيبان عن كثيرين. الأولى أن المشتري يحتاج أيضًا إلى مزوّد معتمد، أي أن فريق الحسابات الدائنة سيغيّر طريقة استلامه للفواتير، وليس فريق المبيعات وحده من سيغيّر طريقة إصدارها. والثانية أن النظام كله لا يتجاوز جودة البيانات التي يُخرجها نظامك المصدر. فرقم التسجيل الضريبي (TRN) الناقص للمشتري أو فئة ضريبة القيمة المضافة الخاطئة لن يُصحَّح بهدوء عبر تعديل ملف PDF، بل ستُرفض الفاتورة، والفاتورة المرفوضة التي لا ينتبه لها أحد تتحوّل إلى فاتورة متأخرة.
احصر كل نظام يُصدر فواتير، وليس نظام ERP وحده
في الغالب يوفّر مورّد نظام ERP موصّلًا جاهزًا. المشكلة في الأماكن الأخرى التي تُصدر فواتير للعملاء. وفي الشركات التي نعمل معها، هذه هي الحالات المعتادة:
- تطبيق فوترة أو اشتراكات مبني خصيصًا يرسل فواتيره بنفسه،
- متجر إلكتروني أو بوابة عملاء تُصدر فواتير ضريبية للمشترين من الشركات،
- وحدة خدمات أو صيانة تُصدر فواتير أعمال العقود،
- إشعارات دائنة تُعدّ يدويًا في جدول بيانات ثم تُرسل بالبريد.
تخضع الإشعارات الدائنة للقواعد نفسها التي تخضع لها الفواتير، ويشير ملخّص Andersen إلى وجوب إصدار كلٍّ منهما خلال 14 يومًا من المعاملة. فإذا كانت إشعاراتك الدائنة اليوم في جدول بيانات، فأنت أمام عملية تحتاج إلى إعادة بناء، لا مجرد حقل يُربط. وهذا الحصر فرصة أيضًا لاكتشاف الروابط المباشرة غير الموثّقة بين الأنظمة، وهي المشكلة نفسها التي تناولناها في لماذا لا تتكامل أنظمة المؤسسات.
ما تعلّمناه من ربط بوابة الدفع لدينا
بنينا صفحة الدفع في fanpino.com بأنفسنا وربطناها ببوابة دفع خارجية. هي ليست مزوّد فوترة إلكترونية، لكن أنماط الأعطال من النوع نفسه: نظامك يرسل مستندًا إلى طرف ثالث، ويتلقى معرّفًا، ثم عليه أن يطابق النتيجة لاحقًا. واجهنا خطأين يستحقان الذكر، لأن ربط أي مزوّد معتمد سيُنتج الأخطاء ذاتها.
كانت البوابة تعيد المعرّف المرجعي رقمًا في JSON، بينما توقّع الكود نصًّا. فكان كل طلب يفشل عندنا بعد أن تكون البوابة قد أنشأت عملية الدفع فعلًا. يرى المستخدم رسالة خطأ، بينما توجد معاملة حقيقية في الطرف الآخر. وبلغة الفوترة الإلكترونية: فاتورة قبلها المزوّد، بينما يظن نظام ERP أن الإرسال فشل. وإذا كان منطق إعادة المحاولة يعيد الإرسال ببساطة، فستصبح لديك فاتورة مكررة لدى الهيئة الضريبية.
الخطأ الثاني نشأ من الرقم نفسه. كانت خطوة التأكيد تبحث عن الدفعة باستخدام المعرّف نصًّا قادمًا من الرابط، بينما خُزّن في قاعدة البيانات رقمًا. هذا البحث لن يجد تطابقًا أبدًا، أي أن كل طلب مدفوع كان سيفشل عند التأكيد. ولم يظهر ذلك إلا لأننا تتبّعنا طلبًا واحدًا من أوله إلى آخره.
ما غيّرناه، وما نطلبه من أي ربط مع مزوّد معتمد:
- وحّد نوع المعرّفات عند نقطة الاتصال مرة واحدة، في الجزء الذي يتحدث مع المزوّد، بدل تحويلها في خمسة أماكن.
- استخدم رقم فاتورتك نفسه مفتاحًا لمنع التكرار. وقبل أي إعادة محاولة، اسأل المزوّد عن حالة هذا الرقم بدل إعادة الإرسال.
- تعامل مع "استلم المزوّد الفاتورة" و"تم التحقق منها وتسليمها" كحالتين مختلفتين. خزّن معرّف رسالة المزوّد وكل تغيير في الحالة. فإعادة التوجيه أو استجابة 200 لا تثبت شيئًا.
- اجعل لديك شاشة أو استعلامًا واحدًا يجيب عن سؤال: أي فواتير الأسبوع الماضي لم تصل إلى حالة نهائية؟ إذا احتاج ذلك إلى مطوّر، فلن يراجعه أحد.
لا يمكنك الإبلاغ عن عطل لم تلاحظه
تشترط القواعد إبلاغ الهيئة الاتحادية للضرائب بالأعطال التقنية خلال يومي عمل، وإخطار المزوّد المعتمد بأي تغيير في البيانات المسجّلة خلال 5 أيام عمل (Andersen). وكلاهما يفترض أنك تعرف أن شيئًا ما قد تعطّل. الربط الذي يفشل بصمت هو الحالة المكلفة، لأن غرامة عدم الإبلاغ تُحتسب يوميًا.
لذلك يحتاج الربط إلى سجلات يمكن قراءتها حتى بعد إعادة التشغيل، وإلى تنبيه عند تراكم حالات الرفض. تعلّمنا مسألة السجلات بالطريقة الصعبة في حادثة لا علاقة لها بالفوترة، حين محت إعادة بناء حاوية النسخة الوحيدة من سجلات الوصول لدينا. كان الإصلاح بسيطًا، وقد شرحناه في إرسال سجلات الحاويات إلى stdout بدل الملفات (بالإنجليزية).
البيانات الرئيسية ومكان تخزين البيانات
معظم حالات الرفض المبكرة ستأتي من البيانات الرئيسية لا من الكود. راجع أرقام التسجيل الضريبي للأطراف المقابلة، ورموز الأصناف، وفئة ضريبة القيمة المضافة في كل بند من بنود دفتر الأستاذ قبل بدء التطبيق، لا بعده. ولهذا السبب تحديدًا تضع قائمة Boru تنظيف البيانات الرئيسية بجانب اختيار المزوّد.
يتضمّن القرار 243 أيضًا قواعد للأرشفة وسيادة البيانات، ويذكر ملخّص Andersen أن بيانات الفواتير الإلكترونية يجب أن تُخزَّن داخل الإمارات. اسأل أين توجد كل نسخة فعليًا: نظام ERP إن كان سحابيًا، والمزوّد المعتمد، وأرشيف البريد الذي لا يزال يحتفظ بنسخ PDF، والنسخ الاحتياطية. هذا هو السؤال نفسه الذي يُطرح علينا بشأن خوادم البريد، والمنطق الوارد في لماذا لا تزال الشركات تستضيف بريدها بنفسها في 2026 ينطبق هنا أيضًا. تحقّق من مدة الأرشفة وصيغتها بدقة مع مستشارك الضريبي، فنحن لا نقدّم هنا استشارة ضريبية.
خطة من أربعة أسابيع قبل 30 أكتوبر
- الأسبوع الأول: احصر كل نظام يُصدر فواتير أو إشعارات دائنة، وكل نظام يستلم فواتير الموردين، وعيّن مسؤولًا عن كلٍّ منها.
- الأسبوع الثاني: اختر قائمة قصيرة من المزوّدين وفق جودة واجهاتهم البرمجية، لا السعر وحده. اطلب بيئة اختبار، ونموذج الحالات، وطريقة التعامل مع التكرار، ورموز الأخطاء التي ستصلك، واسأل أين تُستضاف بياناتهم.
- الأسبوع الثالث: نظّف البيانات الرئيسية (أرقام TRN للمشترين، ورموز الأصناف، وفئات الضريبة)، واربط فاتورة حقيقية واحدة من كل نظام مصدر بحقول PINT AE.
- الأسبوع الرابع: وقّع مع المزوّد، ثم أرسل فواتير اختبارية من كل مصدر عبر بيئة الاختبار، بينها حالة فشل متعمّدة وإعادة محاولة واحدة، وتأكّد أنك ترى الحالتين في سجلاتك أنت.
بعد 30 أكتوبر يستمر العمل حتى 1 يناير، لكن السؤال في تلك المرحلة يجب أن يكون عن جودة عمل الربط، لا عن اسم المزوّد.
أين تأتي Fanpino
لسنا مزوّدًا معتمدًا، ولا نقدّم أي شيء إلى الهيئة الاتحادية للضرائب. ما نقوم به هو الجزء الواقع في جهتك: ربط تطبيقات الفوترة الداخلية والبوابات وأنظمة الخدمات بالمزوّد الذي تختاره، مع إرسال يمنع التكرار، وتتبّع للحالات، وسجلات يستطيع فريقك المالي قراءتها. وإذا كان أحد مصادر فواتيرك نظامًا مبنيًا خصيصًا لا يرغب أحد في الاقتراب منه، فمن هناك نبدأ عادةً.
المصادر
- وزارة المالية الإماراتية: تعديلات محددة على قرارات نظام الفوترة الإلكترونية (10 مايو 2026)
- Andersen الإمارات: القراران الوزاريان رقم 243 و244 لسنة 2025
- KPMG: تطبيق نظام الفوترة الإلكترونية في الإمارات
- VATupdate: غرامات عدم الالتزام بالفوترة الإلكترونية (قرار مجلس الوزراء رقم 106 لسنة 2025)
- Boru Consulting: موعد 30 أكتوبر 2026 لتعيين المزوّد المعتمد
