تطلب حكومات أكثر فواتير إلكترونية منظَّمة بدل ملفات PDF. تعرّف على الفرق بين نماذج الاعتماد المسبق والتدقيق اللاحق وPeppol، وأي إلزامات تبدأ بين 2026 و2028، وما يجب أن يقدر عليه نظام الفوترة أو الـ ERP لديك.
Author
Anichur Rahaman
وصلت إلى مديرة المالية في شركة جملة يعمل بها 40 موظفًا، في صباح يوم اثنين من سبتمبر 2026، رسالة بريد قصيرة. أكبر عملائها بدأ للتو إصدار الفواتير المنظَّمة واستقبالها، وطلب قسم الحسابات الدائنة لديه أن تصله الفواتير الستمئة التي ترسلها كل شهر ملفاتٍ يقرؤها الحاسوب، لا ملفات PDF. (مشهد افتراضي للتوضيح، وليس شركة حقيقية.)
نظامها لا يُنتج سوى PDF. إعادة إدخال 600 فاتورة يدويًا بمعدل عشر دقائق للفاتورة تعني 100 ساعة عمل في الشهر، ورقم ضريبي واحد خاطئ يكفي لإعادة الفاتورة.
الفوترة الإلكترونية مشكلة بيانات قبل أن تكون مسألة امتثال. فعدد متزايد من الحكومات يطلب اليوم فواتير منظَّمة البيانات، أي ملفات يقرؤها الحاسوب دون تدخل بشري، وتمرّ غالبًا عبر شبكة أو منصة تابعة للسلطة الضريبية. وأي برنامج لا يستطيع بناءها بدقة من سجل الطلب يحوّل كل فاتورة إلى عمل يدوي.
إن كنت تبيع لشركات أخرى أو تشتري منها أو تفعل الأمرين، فقد تعنيك مواعيد هذا المقال حتى لو لم تتعامل خارج بلدك. فمورّد في الخارج قد يبدأ بإرسال فواتير منظَّمة إليك، وعميل قد يتوقف عن قبول فواتيرك بصيغة PDF.
يشرح المقال الفرق بين نماذج الفوترة الإلكترونية، ويرسم خريطة لأبرز الإلزامات بين 2026 و2028 (وما بعدها بقليل)، ويحدد ما يجب أن يقدر عليه نظام الفوترة أو الـ ERP لديك. المواعيد مراجَعة على مصادر رسمية ومهنية حتى أغسطس 2026. والقواعد والمهل في هذا المجال تتغير كثيرًا، فاعتمد الجدول الزمني خريطةً للاسترشاد لا استشارة قانونية.
ملف PDF المرسَل بالبريد وثيقة إلكترونية فعلًا، لكنه ليس فاتورة إلكترونية بالمعنى الذي تقصده هذه القوانين. الفاتورة الإلكترونية ملف بصيغة محددة يقرؤها الحاسوب، ولكل حقل فيها معنى ثابت: الرقم الضريبي للبائع، والرقم الضريبي للمشتري، وبنود الفاتورة، ونسبة الضريبة، ومبلغها، وشروط الدفع.
المعيار الدلالي الشائع في أوروبا هو EN 16931، وهو يحدد البيانات التي يجب أن تحملها الفاتورة. ويُعبَّر عنه بصيغتين رئيسيتين هما UBL وUN/CEFACT CII، وكلتاهما XML. أما Peppol BIS Billing 3.0 المستخدم في دول كثيرة فمبني على UBL ويلتزم بـ EN 16931. وخارج أوروبا تضع الدول عادةً صيغتها الخاصة، لكن كثيرًا منها يستعير الأفكار نفسها.
وقد يُقبل أيضًا ملف هجين، كملف PDF يحمل بداخله ملف XML (Factur-X أو ZUGFeRD)، لأن الفاتورة الحقيقية هي الـ XML، وملف PDF مجرد نسخة مقروءة للإنسان.
الصيغة تجيب عن سؤال «ما الذي تحويه الفاتورة». أما النموذج فيجيب عن سؤال «كيف تصل من البائع إلى المشتري، ومن يطّلع عليها في الطريق». ستصادف ثلاثة نماذج.
يصدر البائع فاتورة منظَّمة ويرسلها بالطريقة المتفق عليها. ولا تكون السلطة الضريبية طرفًا في الدورة لحظتها؛ فهي تتلقى البيانات لاحقًا عبر تقارير دورية، أو تفحص الفواتير أثناء التدقيق. هذا أخف نموذج على البائع، لكن الأخطاء تُكتشف بعد وقوعها.
تذهب الفاتورة أولًا إلى منصة السلطة الضريبية، فتتحقق منها وقد تمنحها معرّفًا فريدًا واعتمادًا، ولا تُسلَّم للمشتري إلا بعد ذلك. بهذه الروح يعمل نظام KSeF في بولندا ومرحلة الربط في السعودية. تحصل على حالة واضحة لكل فاتورة، لكنك تعتمد على توفر المنصة، لذا يجب أن تتضمن خطتك إجراءً بديلًا.
Peppol شبكة مفتوحة تديرها جمعية OpenPeppol. لا تحتاج إلى الارتباط بكل عميل على حدة، بل تتصل بـنقطة وصول معتمدة واحدة، فتبحث نقطتك عن نقطة وصول المشتري وتمرّر الفاتورة إليها. الزاوية الأولى نظامك، والثانية نقطة وصولك، والثالثة نقطة وصول المشتري، والرابعة نظام المشتري. وتضيف بعض الدول زاوية خامسة: نسخة من البيانات تذهب إلى السلطة الضريبية.
وتمزج دول كثيرة بين هذه الأفكار؛ فقد تستخدم دولة ما Peppol للتبادل ثم تضيف فوقه إبلاغًا لحظيًا. لذلك لا تكتفِ بالموعد النهائي، بل راجع نموذج كل سوق تتعامل معه. ويمكنك قراءة المزيد عن الشبكة على peppol.org.
يعرض الجدول أبرز الإلزامات. وهو مختارات وليس حصرًا شاملًا؛ فبعض الدول بدأت قواعد B2G (بين الشركات والحكومة) منذ وقت أبكر، وبعضها ما زال يصوغ قوانينه.
| الدولة أو المنطقة | ما الذي يبدأ | المواعيد الرئيسية | النموذج |
|---|---|---|---|
| ألمانيا | استقبال الفواتير المنظَّمة ثم إصدارها (B2B محلي) | الاستقبال: جميع الشركات منذ 1 يناير 2025. الإصدار: 1 يناير 2027 إذا تجاوز دوران العام السابق 800,000 يورو؛ و1 يناير 2028 للجميع | قائم على الصيغة، دون منصة مركزية |
| بلجيكا | فوترة B2B منظَّمة بين الشركات المسجلة في ضريبة القيمة المضافة | 1 يناير 2026. والإبلاغ اللحظي مخطَّط له في 2028 | يُوصى بـ Peppol BIS 3.0 |
| كرواتيا | فوترة B2B إلكترونية مع تثبيت مالي لحظي | 1 يناير 2026 للشركات المسجلة في ضريبة القيمة المضافة | تبادل مع إبلاغ للسلطة الضريبية |
| بولندا | النظام الوطني KSeF | 1 فبراير 2026 لمن يتجاوز دورانه 200 مليون زلوتي؛ و1 أبريل 2026 لبقية الشركات المسجلة في ضريبة القيمة المضافة؛ والمنشآت متناهية الصغر والغرامات من 1 يناير 2027 | اعتماد مسبق |
| فرنسا | الاستقبال عبر منصات معتمدة، والإصدار على مراحل | 1 سبتمبر 2026: كل الشركات تستقبل، والشركات الكبيرة والمتوسطة تُصدر. 1 سبتمبر 2027: تُصدر الشركات الصغيرة والمتناهية الصغر | منصات معتمدة ودليل مركزي |
| إسبانيا | فوترة B2B إلكترونية بموجب المرسوم الملكي 238/2026 | نُشر في 31 مارس 2026. بعد 12 شهرًا (لمن يتجاوز دورانه 8 ملايين يورو) أو 24 شهرًا (لغيرهم) من صدور قرار وزاري ما زال معلقًا. وقواعد Verifactu المنفصلة لبرامج الفوترة: 1 يناير 2027 و1 يوليو 2027 | منصة عامة ومنصات خاصة قابلة للتشغيل البيني |
| الإمارات العربية المتحدة | نظام وطني للفوترة الإلكترونية | اختياري من 1 يوليو 2026؛ وإلزامي من 1 يناير 2027 لمن يبلغ دورانه 50 مليون درهم فأكثر؛ وبقية الشركات في وقت لاحق من 2027 | قائم على Peppol، مع مزوّدي خدمة معتمدين |
| السعودية | المرحلة الثانية (الربط) من ZATCA على موجات | الموجة 24 (أكثر من 375,000 ريال): بحلول 30 يونيو 2026. الموجة 25 (أكثر من 187,500 ريال): بحلول 1 فبراير 2027 | اعتماد مسبق وإبلاغ |
| ماليزيا | MyInvois على مراحل بحسب حجم الدوران | من 1 أغسطس 2024 للأكبر حجمًا. إعفاء من يقل دورانه عن مليون رينغيت. وللفئة بين مليون و5 ملايين رينغيت فترة تخفيف بلا غرامات حتى 31 ديسمبر 2027 | تحقق من السلطة الضريبية |
| الاتحاد الأوروبي | ViDA: الفوترة الإلكترونية والإبلاغ الرقمي للمعاملات B2B العابرة للحدود | اعتُمد في مارس 2025. يسري من 1 يوليو 2030؛ ويجوز للدول الأعضاء وضع قواعد محلية أبكر | EN 16931 معيارًا |
تحقّق من القواعد المحلية في بلدك. فالحدود تُحسب غالبًا على دوران السنة السابقة، وقد تختلف فترات السماح عن تواريخ التطبيق الفعلي، وبعض الدول أجّلت مواعيدها مرة أو مرتين (ماليزيا وإسبانيا فعلتا ذلك). قبل أن تخطط، اقرأ أحدث إرشادات سلطتك الضريبية أو اسأل محاسبك.
أربعة أسئلة تحوّل العنوان الإخباري إلى خطة عمل.
النقطة الأخيرة مهمة عمليًا. فحتى لو صبرت الدولة، فلن يصبر قسم الحسابات الدائنة لدى عميل كبير. وإن كان ملزَمًا باستقبال فواتير منظَّمة فسيطلبها منك.
تبدو الإلزامات مختلفة، لكن مطالبها من البرمجيات متشابهة. قِس نظامك على هذه القائمة.
يجب أن تُنشأ الفاتورة بيانات منظَّمة من سجل الطلب أو البيع نفسه: EN 16931 بصيغة UBL أو CII في أوروبا، أو الصيغة المحلية في غيرها. النمط الخطر هو نظام يبني ملف PDF ثم يطلب من أداة خارجية قراءته وتحويله إلى XML، فكل تحويل يُفقد شيئًا من الدقة. والتصميم الأفضل يُنتج الفاتورة المنظَّمة من السجل نفسه الذي يُنتج ملف PDF، فلا يمكن أن يختلفا.
الفواتير المنظَّمة صارمة. رقم ضريبي ناقص أو رمز دولة خاطئ أو عنوان مكتوب نصًا حرًا في الحقل الخطأ يكفي لرفض الفاتورة. قبل أي موعد إلزامي، نظّف ما يلي:
يجب في معظم الأنظمة أن تكون أرقام الفواتير فريدة ومتسلسلة، ولا يجوز عادةً تعديل فاتورة جرى اعتمادها. يُصحَّح الخطأ بإشعار دائن يشير إلى الفاتورة الأصلية، ثم تصدر فاتورة جديدة. فنظامك يحتاج مسارًا سليمًا لإشعارات الدائن مرتبطًا برقم الفاتورة الأصلية، لا زر «احذف وأعد الإصدار». والإشعارات الجزئية وتصحيح الأسعار والمرتجعات كلها تسلك هذا المسار.
في النظام الشبكي لا تعني عبارة «أُرسلت» نهاية القصة. فالفاتورة قد تُقبل أو تُرفض أو تنتظر في الطابور أو تُعتمد للدفع. على نظامك أن يحفظ الحالة لكل فاتورة، ويعرضها لمن يتابعون التحصيل، وينبّه شخصًا ما حين يصل رفض. ويجب أن يأتي الرفض بسبب مقروء وطريقة واضحة للتصحيح وإعادة الإرسال، لا بتتبّع أخطاء مدفون في سجل النظام.
يتتبّع الشكل التالي فاتورة واحدة في نظام الاعتماد المسبق. قد تُردّ عند نقطتين، وفي الحالتين ينتهي الأمر إلى المكان نفسه: تصحيح البيانات.
صارت النسخة القانونية الأصلية هي الملف المنظَّم، فهو ما يجب حفظه دون تعديل طوال مدة الحفظ القانونية. وتختلف هذه المدة من دولة إلى أخرى، وتغيّرت في بعضها حديثًا (فقد قصّرت ألمانيا مدة حفظ الفواتير إلى ثماني سنوات في 2025). ابحث عن تخزين غير قابل للتعديل للملف الأصلي، وسجل يبيّن من غيّر ماذا، وإمكانية التصدير عند الطلب أثناء التدقيق.
على نظامك أن يتحدث مع جهة خارجية: نقطة وصول أو منصة معتمدة أو واجهة برمجية للسلطة الضريبية. اسأل كيف يتصل. الإعداد الجيد يدعم أكثر من مزوّد، ويتيح تغيير المزوّد دون إعادة بناء الفواتير، ويعيد المحاولة بأمان بعد انتهاء المهلة، ولا يرسل الفاتورة نفسها مرتين أبدًا. كما أن شهادات المصادقة والرموز تنتهي صلاحيتها، فلا بد أن يتولى شخص ما تجديدها.
إن كنت تبيع عبر الحدود فستواجه صيغًا ونماذج ومواعيد مختلفة في وقت واحد. ينبغي أن تُعامَل قواعد كل دولة في البرنامج إعدادًا قابلًا للضبط، لا فرعًا جديدًا من الشيفرة المخصصة، حتى لا تعني إضافة سوق جديدة إعادة كتابة الفوترة. ويجب أن تعمل معًا العملات المتعددة والترقيم متعدد الكيانات وأسعار الضريبة لكل دولة.
استخدمها تقييمًا ذاتيًا سريعًا. إذا كانت إجابتك «لا» أو «لا أعرف» عن عدة بنود، فابدأ مبكرًا.
يتسع العمل لدى معظم الشركات النامية في ربع أو ربعين من السنة. وهذا الترتيب يُبقيه تحت السيطرة.
نعد إلى شركة الجملة. صار نظامها يبني الفاتورة المنظَّمة من سجل الطلب نفسه الذي يُنتج ملف PDF، ويفحص الأرقام الضريبية عند إنشاء العميل، ويحتفظ بحالة كل فاتورة. تخرج الفواتير الستمئة دون إعادة إدخال يدوي. والقليل الذي يُردّ كل شهر يصل مصحوبًا بسبب مقروء، فيضيف موظف المرجع الناقص لدى المشتري ويعيد الإرسال في اليوم نفسه. اختفت المئة ساعة من الإدخال اليدوي، واختفت معها مفاجأة صباح الاثنين.
Anichur Rahaman مهندس برمجيات معماري ومؤسس StoreConsole، يصمّم أنظمة التجارة وERP للشركات النامية، ويهتم خصوصًا بالبنية القائمة على الأحداث وسلامة البيانات وتشغيل الأنظمة على خوادم الشركة نفسها.
About the Author
Anichur Rahaman
Continue Reading
