إلزام E-Rechnung في ألمانيا: إصدار فواتير منظَّمة من أنظمتك الخاصة بحلول 1 يناير 2027

اعتباراً من 1 يناير 2027، لم يعد بإمكان الشركة الألمانية التي تجاوز حجم مبيعاتها في 2026 مبلغ 800,000 يورو أن ترسل فاتورة ورقية أو بصيغة PDF إلى شركة ألمانية أخرى. يجب أن تكون الفاتورة فاتورة إلكترونية منظَّمة: ملف بيانات مبني وفق المعيار الأوروبي EN 16931. واعتباراً من 1 يناير 2028 يزول الحد، وتسري القاعدة على كل الشركات، باستثناء حالات قليلة محدودة.

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

ماذا يقول القانون

التعريف وارد في § 14 UStG: فاتورة "die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht"، أي فاتورة تُصدَر وتُرسَل وتُستقبَل بصيغة إلكترونية منظَّمة وتتيح المعالجة الإلكترونية. ويجب أن تتوافق الصيغة مع المعيار الأوروبي بموجب التوجيه 2014/55/EU (أي EN 16931 عملياً)، أو أن يتفق عليها الطرفان، شريطة أن يمكن استخراج البيانات المطلوبة بشكل صحيح وكامل إلى صيغة متوافقة مع ذلك المعيار. ملف PDF لا يفي بالشرط، مهما بدا مرتباً.

يشمل الالتزام التوريدات إلى شركة أخرى حين يكون الطرفان كلاهما مقيمَين في ألمانيا. والفترة الانتقالية منصوص عليها في § 27 Abs. 38 UStG:

• التوريدات المنفذة في 2025 و2026 يجوز أن تُفوتَر ورقياً، أو بصيغة إلكترونية أخرى إن وافق العميل، ما دامت الفاتورة تُرسَل بحلول 31 ديسمبر 2026.
• التوريدات المنفذة في 2027 تحصل على التسهيل نفسه حتى 31 ديسمبر 2027، لكن فقط إن لم يتجاوز إجمالي مبيعات المُصدِر في السنة الميلادية السابقة 800,000 يورو.
• تبادل البيانات الإلكتروني (EDI) غير المطابق للمعيار يجوز أن يستمر للتوريدات المنفذة في 2027، بموافقة العميل، أياً كان حجمك.

ثلاثة تفاصيل أهم مما تبدو عليه.

الحد يُقاس على مبيعات السنة الماضية. وضعك في 2027 يتوقف على رقم 2026، ولن يعرفه أحد بدقة حتى إقفال الحسابات. إن كنت قريباً من 800,000 يورو، فابنِ على افتراض أنك فوق الحد.

التسهيل ينتهي بتاريخ إرسال. بالقراءة الحرفية، تتوقف القاعدة الانتقالية الأولى عن تغطية الفواتير الورقية وملفات PDF في 31 ديسمبر 2026، حتى عن أعمال نُفّذت في 2026. فإن كنت فوق الحد وتفوتر بأثر لاحق، فالفاتورة التي ترسلها في الأسبوع الأول من يناير عن أعمال ديسمبر يجب أن تكون منظَّمة. تأكد من ذلك مع مستشارك الضريبي، لكن لا تخطط لبدء التشغيل في منتصف يناير.

بعض الفواتير تبقى خارج النطاق: فواتير المستهلكين، والفواتير العابرة للحدود، وفواتير المبالغ الصغيرة حتى 250 يورو إجمالاً، والتذاكر التي تُعد فواتير، والفواتير الصادرة عن فئة Kleinunternehmer (المنشآت الصغيرة المعفاة)، والتوريدات المعفاة بموجب § 4 Nr. 8 إلى 29 UStG.

لا نعلم بوجود أي مشروع قانون لتغيير هذه المواعيد. خطط على أساس أنها ثابتة.

الاستقبال مطبَّق منذ 2025. الإصدار هو الجديد.

منذ 1 يناير 2025، على كل شركة ألمانية أن تكون قادرة على استقبال الفواتير الإلكترونية. والأسئلة الشائعة حول الفوترة الإلكترونية لدى وزارة المالية الاتحادية واضحة تماماً بشأن ما يتطلبه ذلك: "Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach." صندوق بريد إلكتروني يكفي.

لاحظ سطراً واحداً في § 14 نفسها: حيث يسري التزام الفاتورة الإلكترونية، لا تُشترط موافقة المستلم. فالعميل التجاري الألماني لا يستطيع رفض فاتورتك المنظَّمة.

الإصدار مشكلة مختلفة. حين تستقبل، تقرأ أداةٌ ملفاً أعدّه غيرك. وحين تُصدر، يكون نظامك هو المؤلف: إن كانت البيانات خاطئة من المصدر، فلن يستطيع أحد لاحقاً في السلسلة إصلاحها، والفاتورة التي تفشل في تحقق عميلك تبقى بلا سداد.

من يحصل على هذا في تحديث

بوضوح: إن كنت شركة صغيرة تُصدر فواتيرها من DATEV أو lexoffice أو sevDesk أو حزمة مشابهة، فالمورّد يوفّر الصيغة. راجع بياناتك الرئيسية (رقم ضريبة القيمة المضافة، وعناوين العملاء، والبيانات المصرفية)، وفعّل الميزة، وأرسل فاتورة تجريبية. لا تحتاج إلى مشروع، ولا إلى شركة برمجيات.

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

بقية هذا المقال للشركات التي تصدر فواتيرها من شيفرة تملكها، أو من شيفرة لم يعد أحد يصونها:

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

الصيغ: EN 16931 وXRechnung وZUGFeRD

EN 16931 هو المعيار الأوروبي. يحدد النموذج الدلالي للفاتورة (الحقول، ومعانيها، والإلزامي منها، وقواعد العمل بينها) ويربطه بصيغتين من XML هما UBL 2.1 وUN/CEFACT CII.

XRechnung هي المواصفة الألمانية المبنية فوق EN 16931، وتتولى KoSIT صيانتها: XML خالص بأي من الصيغتين، تشترطه الجهات العامة، وهو صالح بالقدر نفسه بين الشركات. وبحسب صفحة XRechnung لدى KoSIT، فالإصدار 3.0 نافذ منذ 1 فبراير 2024 ويبقى نافذاً حتى 31 يوليو 2027 على الأقل. وقد نُشرت نسخة أولية من الإصدار 4.0 في سبتمبر 2026، ويُتوقع الإصدار النهائي في ربيع 2027. ستبدأ التشغيل على 3.0 وتُرقّي خلال سنتك الأولى.

ZUGFeRD صيغة هجينة: ملف PDF/A-3 مضمَّن فيه XML بصيغة CII. يقرأ الناس ملف PDF، وتقرأ الآلات XML. وفي فرنسا تُسمى الصيغة نفسها Factur-X، والاثنتان متطابقتان تقنياً. وقد نشرت FeRD الإصدار 2.5.2 في 4 أغسطس 2026. وتأتي ZUGFeRD بملفات تعريف (MINIMUM وBASIC WL وBASIC وEN 16931 وEXTENDED)، وتقبل الأسئلة الشائعة للوزارة ZUGFeRD بدءاً من الإصدار 2.0.1 "mit Ausnahme der Profile MINIMUM und BASIC-WL"، أي باستثناء ملفي التعريف MINIMUM وBASIC-WL.

في الفاتورة الهجينة، العبرة بملف XML. فالأسئلة الشائعة تسمي الجزء المنظَّم "führender Teil"، أي الجزء القائد. إن اختلف ملف PDF عن XML، فملف PDF هو الخاطئ.

بالنسبة لمعظم مُصدري فواتير B2B في ألمانيا، الخيار الافتراضي المعقول هو ZUGFeRD بملف التعريف EN 16931، حتى يواصل العملاء الذين ما زالوا يقرؤون الفواتير بالعين عملهم كالمعتاد، إضافة إلى XRechnung للجهات العامة ولمن يطلبها. ويجب أن تصدر الصيغتان من كائن فاتورة داخلي واحد، لا من مسارين برمجيين.

ما الذي يجب أن يتغير في نظامك

الفاتورة تصبح بيانات لا تخطيطاً للطباعة

كثير من الأنظمة القديمة يبني الفاتورة وقت الطباعة: نص يُلصق داخل قالب، وإجماليات تُجمع داخل التقرير، وملاحظة ضريبة القيمة المضافة فقرة مكتوبة ثابتة في الشيفرة. لا شيء من ذلك يصمد أمام EN 16931. تحتاج إلى كائن فاتورة مخزَّن يحمل كل حقل، ويُولَّد منه ملف XML وملف PDF كلاهما.

الحقول التي تكون غالباً ناقصة أو خاطئة:

• بيانات الأطراف. عناوين منظَّمة برموز ISO للدول، ورقم ضريبة القيمة المضافة أو الرقم الضريبي. كتل العناوين المكتوبة نصاً حراً يجب تقسيمها.
• تاريخ التوريد أو فترة الخدمة، محفوظاً كبيانات لا كجملة في رأس الفاتورة.
• الوحدات. كل كمية تحتاج إلى رمز من التوصية رقم 20 للجنة الأمم المتحدة الاقتصادية لأوروبا (H87 للقطعة، وKGM للكيلوغرام، وDAY لليوم). ويجب مطابقة "Stk." و"pauschal" برموزها.
• ضريبة القيمة المضافة. كل بند يحمل فئة ضريبية ونسبة. وتحمل الفاتورة تفصيلاً ضريبياً واحداً لكل تركيبة من الفئة والنسبة، ويجب أن تتطابق الإجماليات تماماً عند منزلتين عشريتين. الأنظمة التي تقرّب الضريبة لكل بند تفشل هنا.
• صياغة الإعفاء والاحتساب العكسي. الجملة في أسفل ملف PDF تصبح رمز فئة ضريبية مع سبب للإعفاء.
• الدفع. وسيلة الدفع ورقم IBAN والشروط بصيغة منظَّمة.
• المراجع. رقم أمر الشراء أو مرجع المشتري الذي يطابق عليه فريق الحسابات الدائنة لدى عميلك. إن لم تكن تحفظه قط، فابدأ بجمعه الآن.

البنود النصية فقط ("التسليم حسب الاتفاق") عقبة شائعة. في الفاتورة المنظَّمة، البند هو بند قابل للفوترة، فمكان ذلك النص في ملاحظة.

التصحيحات والإشعارات الدائنة والفوترة الذاتية

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

انتبه إلى المصطلحات. في قانون ضريبة القيمة المضافة الألماني، "Gutschrift" فاتورة ذاتية، يُصدرها العميل باتفاق مسبق (§ 14 Abs. 2 UStG). أما ما يسميه المتحدث بالإنجليزية credit note (تخفيض في السعر أو إلغاء) فهو تصحيح. وكثير من الأنظمة يستخدم نوع مستند واحداً للحالتين. افصل بينهما قبل المطابقة، وإن كنت تُصدر فواتير ذاتية لمورّديك، فعامل هذه المستندات كفواتير يُصدرها نظامك.

يجوز أن تسرد الفاتورة النهائية الدفعات الجزئية السابقة في مرفق، شريطة أن يشير إليه الجزء المنظَّم؛ وتؤكد الأسئلة الشائعة أن هذا يستمر بعد 2027.

التحقق قبل خروج أي شيء

تنشر KoSIT أداة تحقق مفتوحة المصدر تفحص XML وفق المخططات وقواعد Schematron، مع إعدادات عامة لـ XRechnung. وتعمل من سطر الأوامر، أو كخدمة HTTP دائمة، أو كمكتبة برمجية. ضعها في مسار الإرسال: كل فاتورة يُتحقق منها قبل خروجها، وكل إخفاق يذهب إلى طابور له مسؤول محدد بالاسم، مع بيان الحقل الذي خالف القاعدة.

بالنسبة لـ ZUGFeRD، تحقق من XML المضمَّن وفق قواعد ملف التعريف الذي تستخدمه، وافحص حاوية PDF/A-3 على حدة، وتأكد من أن ملف PDF يعرض الإجماليات نفسها الموجودة في XML.

الإرسال

القانون، كما تقول الأسئلة الشائعة، "sieht keinen bestimmten Weg vor": لا يفرض قناة بعينها. البريد الإلكتروني مع الملف مرفقاً مقبول. وكذلك واجهة API، أو بوابة تنزيل، أو تخزين مشترك داخل المجموعة، أو (والمثال من الوزارة نفسها) ذاكرة USB. ولا تُشترط شبكة Peppol لمعاملات B2B المحلية في ألمانيا.

العمل الهندسي هنا خاص بكل عميل: عنوان لاستلام الفواتير، وصيغة مفضلة، وسجل بما أُرسل وإلى أين. وإعادة المحاولة بعد إرسال فاشل تحمل المستند نفسه برقم الفاتورة نفسه. رقمان لتوريد واحد مشكلة ضريبية، لا برمجية.

الأرشفة

يجب الاحتفاظ بالجزء المنظَّم على الأقل "unversehrt in seiner ursprünglichen Form"، أي سليماً بصيغته الأصلية، وتحدد § 14b UStG مدة الاحتفاظ بثماني سنوات من نهاية سنة الإصدار. احفظ البايتات نفسها التي أرسلتها، مع بصمة تجزئة (hash). ولا تخطط لإعادة توليد الفواتير من قاعدة البيانات لاحقاً: فبحلول ذلك الوقت تكون البيانات والشيفرة قد تغيرتا. والأمر نفسه ينطبق على الفواتير الإلكترونية التي تستقبلها.

خطة من أكتوبر إلى ديسمبر 2026

ثلاثة عشر أسبوعاً تكفي لبناء مركّز إن كانت بيانات المصدر في حالة معقولة. ولا تكفي لاستبدال نظام الفوترة.

الأسبوعان 1 و2: الحصر والقرارات. اسرد كل موضع تصدر منه فاتورة، بما فيها الإشعارات الدائنة اليدوية، والفواتير الختامية للمشاريع، وجدول البيانات الخاص بعميل كبير واحد. قارن مبيعات 2026 بالحد. اختر الصيغة الافتراضية، وقرر هل تبني المولّد بنفسك أم ترسل بيانات الفواتير إلى واجهة API لدى مزود خدمات فوترة إلكترونية.

من الأسبوع 2 إلى الأسبوع 4: تحليل فجوات البيانات. طابق فواتير حقيقية لثلاثة أشهر مع EN 16931 حقلاً بحقل. حدد الناقص، وما يجب تحويله إلى رمز، وما يُحتسب بطريقة مختلفة. هنا يظهر الحجم الحقيقي للمشروع.

من الأسبوع 4 إلى الأسبوع 9: البناء. كائن الفاتورة، والمطابقة، وتوليد XML وPDF/A-3، وأداة التحقق في مسار الإرسال، وطابور الإخفاقات، والأرشيف. وبالتوازي، يتولى أحدهم تنقيح البيانات الرئيسية وجمع عناوين استلام الفواتير من العملاء.

من الأسبوع 9 إلى الأسبوع 11: الإعادة التجريبية والتشغيل التجريبي. مرّر فواتير الأشهر الثلاثة الأخيرة عبر المولّد الجديد وتحقق من كل واحدة. ثم شغّل تجربة مع عدد من العملاء المستعدين واسألهم هل تقرأ أنظمتهم الملفات.

من الأسبوع 11 إلى الأسبوع 13: التجميد ودليل التشغيل. جمّد التغييرات في ديسمبر. دوّن من يتولى طابور الإخفاقات، وكيف يُصدَر التصحيح، وماذا يحدث حين يرفض عميل فاتورة. فواتير يناير عن أعمال ديسمبر داخلة في النطاق بالفعل.

يناير 2027. ابدأ التشغيل، وراقب الطابور يومياً طوال أول إقفال شهري وأول إقرار لضريبة القيمة المضافة.

على امتداد 2027. خطط للترقية إلى XRechnung 4.0 قبل أن يتوقف الإصدار 3.0 عن الصلاحية، وانقل شركات المجموعة التي تقل عن الحد قبل 1 يناير 2028.

إن بدأت متأخراً، فقلّص الأتمتة لا صلاحية المخرجات: أتمت أنواع الفواتير الأعلى حجماً أولاً، وأرسل المستندات النادرة يدوياً عبر أداة فوترة إلكترونية لبضعة أسابيع.

أين تحصل على المساعدة

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

نحن مهندسون لا مستشارون ضريبيون: أسئلة النطاق مكانها لدى الـ Steuerberater (مستشارك الضريبي)، ونحن نبني وفق جوابه. أخبرنا بما ينتج فواتيرك اليوم وبعدد ما يخرج منها شهرياً على وجه التقريب: راسلنا على office@c9group.dev.