في النصف الأول من 2026 مرّ عبر أنظمة Datev نحو 51 مليون فاتورة إلكترونية. في عام 2025 كاملاً كان الرقم نحو 64 مليونًا. أي 80٪ من حجم العام الماضي في نصف المدة، ومع ذلك وصفه الرئيس التنفيذي لـDatev نفسه في يوليو بأنه حصة صغيرة من إجمالي حركة الفواتير في ألمانيا، وأضاف أن الموضوع ببساطة ليس محل اهتمام لدى جزء كبير من شركات Mittelstand الأصغر (CIO، يوليو 2026 (opens in new tab)؛ it-daily، يوليو 2026 (opens in new tab)).
بعد اليوم يبقى من عام 2026 ثمانون يومًا. منها 58 يومًا من أيام الأسبوع العادية، قبل أن تطرح العطل الرسمية وإقفال نهاية السنة. وفي 1 يناير 2027 تنتهي الفترة الانتقالية الخاصة بإصدار الفواتير لكل شركة يتجاوز رقم أعمالها الحدّ المقرَّر.
رأينا: الشركات التي ستقع في ورطة في يناير هي التي حدّدت نطاق العمل على أنه "أداة الفوترة لدينا تحتاج إلى تصدير صيغة ملف مختلفة". صيغة الملف لا تتجاوز عُشر العمل، وهو أسهله. كل ما يجعل الفاتورة الإلكترونية صحيحة وقابلة للتسليم والمعالجة والتدقيق يقع قبل ملف XML أو بعده.
ملاحظة قبل أن نكمل: هذا إرشاد هندسي، لا نصيحة ضريبية أو قانونية. خذ الأسئلة القانونية إلى مستشارك الضريبي (Steuerberater).
ما الذي يتغيّر فعلاً في 1 يناير
بموجب § 14 UStG (opens in new tab)، يجب أن تكون الفاتورة بين منشأتين مقرّهما في ألمانيا فاتورة إلكترونية (E-Rechnung، وبنص القانون elektronische Rechnung): صيغة مُهيكلة تطابق المعيار الأوروبي EN 16931، أو صيغة يتفق عليها الطرفان ويمكن استخراجها إليه دون فقد أي بيانات. ملف PDF ليس كذلك؛ إنه sonstige Rechnung، أي "فاتورة أخرى".
الالتزام سارٍ رسميًا منذ 1 يناير 2025. ما أبقى ملفات PDF قانونية هو الحكم الانتقالي في § 27 Abs. 38 UStG (opens in new tab)، وهو من ثلاثة أجزاء:
- حتى 31 ديسمبر 2026، يجوز لأي جهة أن ترسل فاتورة ورقية، أو صيغة إلكترونية أخرى إن وافق المستلم.
- حتى 31 ديسمبر 2027، يستمر التيسير نفسه فقط إذا لم يتجاوز إجمالي رقم أعمال مُصدِر الفاتورة (Gesamtumsatz بالتعريف الوارد في § 19 Abs. 2 UStG) في السنة التقويمية السابقة 800,000 يورو.
- حتى 31 ديسمبر 2027، يجوز الاستمرار في إجراءات EDI التي لا تستوفي بعدُ متطلبات الفاتورة الإلكترونية، بموافقة المستلم.
اعتبارًا من 2028 لا يبقى شيء من ذلك. وثمة تفصيل يضيع في العناوين: الحدّ هو إجمالي رقم الأعمال، والسنة المعتبَرة لعام 2027 هي 2026، وهي لم تنتهِ بعد. إن كنت قريبًا من 800,000 يورو فلن تعرف في أي جانب تقف حتى تُقفل الدفاتر.
الاستثناءات ضيقة. وفقًا لـالأسئلة والأجوبة الصادرة عن BMF (opens in new tab) (بصيغتها في مارس 2026)، لا تلزم فاتورة إلكترونية في مبيعات B2C، ولا في كثير من التوريدات المعفاة من الضريبة، ولا في الفواتير الصغيرة حتى 250 يورو شاملة الضريبة، ولا في التذاكر التي تُعدّ فواتير، ولا في توريدات صغار المكلفين (Kleinunternehmer)، ولا في التوريدات إلى أشخاص اعتباريين ليسوا منشآت أعمال. أما الاستلام فلا استثناء فيه: كل منشأة، ومنها Kleinunternehmer، ملزمة بأن تكون قادرة على استلام الفواتير الإلكترونية منذ 1 يناير 2025.
ما مدى جاهزية السوق؟ أحدث رقم وجدناه استطلاع أجرته YouGov على 502 شركة بتكليف من مزوّد برمجيات الفوترة easybill، ونُشر في يونيو 2026: 33٪ لم ترسل فاتورة إلكترونية قط، و29٪ لم تبدأ التحوّل، و36٪ سمّت التنفيذ التقني العائق الرئيسي (Händlerbund، يونيو 2026 (opens in new tab)). الاستطلاع بتكليف من مزوّد، فخذه بالتحفظ المناسب، لكنه يطابق ما تقوله Datev.
ملف XML أهون ما في المهمة
توليد UBL أو CII صحيح نحويًا من سجل فاتورة مشكلة محلولة. توجد لها مكتبات مفتوحة المصدر ناضجة، ومعظم أنظمة ERP وأدوات الفوترة أصدرت خاصية تصدير. لكن EN 16931 نموذج بيانات دلالي له قواعد أعمال، وهذه القواعد تكشف حال بياناتك الأساسية.
البيانات الأساسية هي حيث تتعثر المشاريع
فاتورة PDF تحتمل البيانات المهملة لأن إنسانًا هو من يقرؤها. الفاتورة المُهيكلة لا تحتمل. الأنماط التي نراها في هذه التكاملات:
- معرّفات المشتري. سجلات عملاء بلا رقم التعريف الضريبي لضريبة القيمة المضافة (USt-IdNr.)، أو برقم قديم، أو برقم مكتوب في حقل ملاحظات حر. ولدى عملاء القطاع العام يكون Leitweg-ID، الذي يوجّه الفاتورة إلى الجهة الصحيحة، مفقودًا أو مخزَّنًا على الكيان الخطأ. وتشترط XRechnung تعبئة حقل مرجع المشتري (BT-10) في كل فاتورة، للقطاع العام ولغيره.
- الفئات الضريبية. كثير من الأنظمة يعرف داخليًا "19٪" و"7٪" و"0٪". أما EN 16931 فيريد أن يعرف لماذا هي صفر: إعفاء، أم احتساب عكسي (Reverse Charge)، أم توريد داخل الاتحاد الأوروبي، أم تصدير، أم خارج نطاق الضريبة. لكل حالة رمز فئة خاص بها، وفئات الإعفاء تحتاج إلى سبب. مفتاح ضريبي واحد بقيمة "0٪" غطّى أربع حالات قانونية مختلفة لا يمكن ربطه آليًا.
- وحدات القياس. المعيار يتوقع رموز التوصية رقم 20 الصادرة عن UN/ECE. أما سجل الأصناف لديك ففيه "Stk" و"Stck." و"St" و"pauschal" و"siehe Angebot".
- الحساب. صافي مبالغ البنود والخصومات وتفصيل الضريبة والإجماليات يجب أن تتطابق وفق قواعد تقريب محددة. الأنظمة التي تقرّب لكل بند في موضع ولكل مستند في موضع آخر تُنتج فواتير بفارق سنت واحد، يتجاهله الإنسان وترفضه أداة التحقق.
زر التصدير لا يصلح شيئًا من هذا. المطلوب تنظيف للبيانات يتولى مسؤوليته شخص في الإدارة المالية، وقواعد في النظام تمنع الفوضى من العودة.
التحقق مكانه قبل الإرسال، لا بعد الرفض
التعميم الثاني الصادر عن BMF بتاريخ 15 أكتوبر 2025 أدخل تمييزًا ينبغي أن يعرفه كل مهندس يعمل على هذه المشاريع. وبحسب تلخيص Deloitte (opens in new tab) وIHK Köln (opens in new tab)، هناك ثلاث فئات من الأخطاء:
- خطأ الصيغة يعني أن الملف لا يستوفي البنية النحوية للمعيار أو لا يمكن استخراجه على نحو موثوق. ملف كهذا ليس فاتورة إلكترونية أصلاً. يُعامَل على أنه "فاتورة أخرى" بصيغة إلكترونية ما.
- خطأ قواعد الأعمال يعني أن الملف سليم البنية لكنه يخالف القواعد المنطقية: حقل إلزامي مفقود، أو مبالغ ونِسب يناقض بعضها بعضًا.
- خطأ المحتوى يعني أن بيانات الفاتورة الإلزامية قانونًا خاطئة، مهما قالت أداة التحقق.
لمُصدِر فوق الحدّ في 2027، الملف الذي فيه خطأ صيغة ليس فاتورة مطابقة، والمستلم الحريص سيردّه بدل أن يخاطر بحقه في خصم ضريبة المدخلات. وتكتشف ذلك حين لا تصل الدفعة.
تقول الأسئلة والأجوبة الصادرة عن BMF إن التحقق ليس شرطًا شكليًا مسبقًا للاعتراف الضريبي، لكنها توصي بإجرائه عند الإنشاء وعند الإرسال. نحن نذهب أبعد من ذلك ونجعله بوابة في خط إنتاج الفواتير، كما يوقف الاختبار الفاشل عملية النشر. الأدوات المرجعية متاحة للعموم: تنشر KoSIT أداة التحقق (opens in new tab) الخاصة بها برخصة Apache 2.0، وهي تعمل كأداة CLI أو كمكتبة Java أو كخدمة HTTP، ومجموعة قواعد XRechnung تأتي كإعداد منفصل. اربطها بحيث لا يمكن إرسال فاتورة فاشلة، وبحيث يصل الخطأ إلى الشخص القادر على تصحيح سجل العميل.
الاختيار بين XRechnung وZUGFeRD: قرار لكل مستلم، لا لكل شركة
الصيغتان مقبولتان. تسمّي الأسئلة والأجوبة الصادرة عن BMF صيغتَي XRechnung وZUGFeRD ابتداءً من الإصدار 2.0.1 صيغتين مطابقتين، باستثناء ملفَّي التعريف MINIMUM وBASIC-WL. إن كانت أداتك الحالية تُخرج أحد هذين الملفَّين وتسمّيه "ZUGFeRD"، فليست لديك فاتورة إلكترونية.
خيارنا الافتراضي في B2B هو ZUGFeRD بملف التعريف EN 16931: موظف المستلم يستطيع أن يفتح ملف PDF كما اعتاد، وبرنامجه يحصل على XML. أما XRechnung فهي XML خالص بلا جزء مرئي؛ جهات القطاع العام تتوقعها، وبعض كبار العملاء يشترطونها.
الملفات الهجينة تحمل مقايضة تغفل عنها معظم الفرق. تنص الأسئلة والأجوبة الصادرة عن BMF على أن الأسبقية القديمة انعكست: في الفاتورة الهجينة صار الجزء المُهيكل هو المرجع، وإذا اختلف PDF عن XML فالغلبة لـXML. إن كان PDF يخرج من قالب على طريقة Word وكان XML يخرج من مسار تصدير منفصل، فلديك مصدران للحقيقة، والمُلزِم منهما هو الذي لا ينظر إليه أحد. ولّد PDF من كائن البيانات نفسه الذي يُنتج XML، أو لا تُصدر ملفات هجينة.
والمواصفات نفسها تتحرك. تذكر KoSIT (opens in new tab) أن XRechnung 3.0 تبقى سارية حتى 31 يوليو 2027 على الأقل وأن الإصدار النهائي 4.0 متوقع في ربيع 2027؛ ونشرت FeRD (opens in new tab) الإصدار ZUGFeRD 2.5.2 في أغسطس 2026. أيًّا كان ما تبنيه أو تشتريه، فهو يحتاج إلى مسؤول عن تحديثات الصيغة.
ما بعد الإصدار: الفواتير الواردة، الأرشفة، التصحيحات، النقل
الإصدار يستأثر بالاهتمام بسبب الموعد النهائي. أما الاستلام فهو إلزامي منذ قرابة سنتين، وحاله في الغالب أسوأ.
الفواتير الواردة. الحد الأدنى القانوني للاستلام صندوق بريد إلكتروني؛ الأسئلة والأجوبة الصادرة عن BMF تقول ذلك صراحة. وقد أنتج هذا الحد الأدنى ممارسة خاطئة شائعة: يصل ملف ZUGFeRD، فيفتح أحدهم PDF ويعتمده، ثم يُدخل المبالغ يدويًا في نظام المحاسبة. أما XML، وهو الفاتورة، فلا يقرؤه أحد. أبسط مسار صحيح للفواتير الواردة يستخرج XML، ويتحقق منه، ويولّد العرض المرئي من XML، ويعرض ذلك العرض على من يعتمد الفاتورة.
الأرشفة. يجب حفظ الفواتير ثماني سنوات (§ 14b UStG (opens in new tab))، وفي الفاتورة الإلكترونية يجب حفظ الجزء المُهيكل على الأقل سليمًا وبصيغته الأصلية. طباعتها، أو الاكتفاء بتخزين PDF مولَّد في نظام إدارة المستندات (DMS)، لا يحقق ذلك. تقول BMF إن تخزين الفواتير الإلكترونية خارج نظام متوافق مع GoBD ليس بحد ذاته مخالفة لـ§ 14b، لكن GoBD تبقى سارية على مسك دفاترك ككل. المتطلب الهندسي: البايتات الأصلية، غير قابلة للتعديل، مع قيمة تجزئة (hash)، مرتبطة بقيد الترحيل المحاسبي، وقابلة للاسترجاع ثماني سنوات، للفواتير الصادرة والواردة على السواء.
التصحيحات. حيث تكون الفاتورة الإلكترونية إلزامية، يجب أن يكون تصحيح الفاتورة فاتورة إلكترونية أيضًا، بنوع الفاتورة المخصص للتصحيح وبإشارة محددة لا لبس فيها إلى الفاتورة الأصلية (الأسئلة والأجوبة الصادرة عن BMF، استنادًا إلى § 31 Abs. 5 UStDV). كثير من أنظمة الفوترة يعالج التصحيحات اليوم بإعادة توليد PDF أو بإلغاء (Storno) مكتوب كنص حر. ولا يصمد أي من الأسلوبين عند الانتقال إلى البيانات المُهيكلة. تحتاج إلى أنواع مستندات حقيقية للتصحيح وللإشعار الدائن، وإلى مرجع مخزَّن للفاتورة السابقة، وإلى عدم قابلية تعديل كل ما أُرسل من قبل.
النقل. البريد الإلكتروني مسموح به. لكنه لا يصلح أساسًا تبني عليه. لا يعطيك إشعار تسليم، ولا حالة، ولا رفضًا مُهيكلاً، ومعه احتمال حقيقي أن تحجز بوابة بريد في الطرف الآخر مرفقًا بامتداد .xml. القانون يترك قناة الإرسال للطرفين. كبار العملاء سيفرضون بوابة إلكترونية أو Peppol؛ وجهات القطاع العام تفعل ذلك أصلاً. عامل النقل كمُحوِّل خلف واجهة برمجية لها ثلاث حالات على الأقل لكل فاتورة: أُرسلت، قُبلت، رُفضت مع السبب.
ما الذي يتسع له 80 يومًا، وما الذي لا يتسع
على افتراض أن رقم أعمالك فوق الحدّ وأنك تبدأ الآن، نحن نقلّص النطاق بصرامة.
افعل الآن:
- راجع البيانات الأساسية لأهم عملائك. افحص أرقام التعريف الضريبي لضريبة القيمة المضافة ومراجع المشتري والعناوين والوحدات لدى العملاء الذين يقف خلفهم معظم حجم فواتيرك في B2B. أصلح البيانات، ثم أضف تحققًا عند الإدخال حتى لا يُحفظ سجل جديد ناقص.
- فكّ تشابك مفاتيحك الضريبية. اربط كل رمز ضريبي داخلي بفئة من فئات EN 16931 مع مستشارك الضريبي. هذه هي المهمة الأطول زمنًا على التقويم، لأنها تحتاج إلى قرار بشري لكل حالة.
- ولّد صيغة واحدة وأتقنها. ZUGFeRD بملف التعريف EN 16931 لتعاملات B2B، مع توليد PDF من البيانات نفسها. أضف XRechnung فقط للعملاء الذين يشترطونها.
- ضع أداة التحقق في خط الإنتاج كبوابة صارمة، مع رسالة خطأ مقروءة لموظفي المكتب الخلفي.
- أرشِف ملف XML الأصلي وتقرير التحقق أرشفة غير قابلة للتعديل، للصادر والوارد.
- نفّذ التصحيحات والإشعارات الدائنة كأنواع مستندات من الدرجة الأولى.
- شغّل المسارين معًا في ديسمبر. أرسل ملف PDF الذي ترسله اليوم، وولّد الفاتورة الإلكترونية وتحقق منها بالتوازي، وعامل كل فشل في التحقق كعيب يجب إصلاحه قبل يناير. واطلب من عميلين أو ثلاثة من العملاء المتعاونين أن يستوردوا ملفاتك التجريبية.
أجّل، عن قصد:
- الأتمتة الكاملة للفواتير الواردة: المطابقة على مستوى البند مع أوامر الشراء، والترحيل الآلي، ومسارات الاعتماد. أتقن أولاً الاستخراج والتحقق والعرض المرئي الصحيح والأرشفة.
- Peppol ومُحوِّل لكل بوابة من بوابات العملاء. ابدأ بالبريد الإلكتروني مع ما يفرضه أكبر عملائك. ابنِ الواجهة البرمجية الآن، والمُحوِّلات لاحقًا.
- الفواتير العابرة للحدود. الإلزام يشمل التوريدات بين منشآت مقرّها في ألمانيا. حزمة الاتحاد الأوروبي "ضريبة القيمة المضافة في العصر الرقمي" (ViDA)، التي أُقرّت في 11 مارس 2025، تأتي بمتطلبات إبلاغ رقمي عن معاملات B2B العابرة للحدود اعتبارًا من 1 يوليو 2030 (المفوضية الأوروبية (opens in new tab)). هذا سبب لنمذجة بيانات فواتيرك وفق دلالات EN 16931 لا وفق نسخة ألمانية بعينها، وليس سببًا لبناء أي شيء في هذا الربع.
ما لا نؤجله هو العمل على البيانات الأساسية. معظم البنود الأخرى يمكن شراؤها أو إضافتها بسرعة. هذا البند لا.
البناء أم الشراء، بصراحة
نحن نبني برمجيات مخصصة، فخذ ما يلي بالتحفظ المناسب. معظم الشركات لا ينبغي أن تبني هذا.
مسار ERP أو Datev يكفي حين تُنشأ فواتيرك في نظام ERP أو حزمة محاسبة واسعة الانتشار أصدر مزوّدها وحدة EN 16931، وتكون حالاتك الضريبية قياسية، ولديك نظام فوترة واحد، وعملاؤك يقبلون البريد الإلكتروني. فعّل الوحدة، واصرف الوقت المتبقي على البيانات الأساسية وربط المفاتيح الضريبية، ونفّذ التشغيل المزدوج في ديسمبر. كتابة مولّد XML خاص بك في هذا الوضع ترف هندسي لا يبرره شيء.
طبقة تكامل مخصصة تستحق تكلفتها حين:
- تنشأ الفواتير خارج ERP: في نظام متخصص بقطاع معيّن، أو منصة حجز أو طلبات، أو نظام لوكالات السيارات، أو برنامج بنيته بنفسك، حيث لن يصدر أي مزوّد وحدة من أجلك.
- لديك عدة مصادر للفواتير وتريد بوابة تحقق واحدة وأرشيفًا واحدًا ومسار تدقيق واحدًا بدل ثلاثة نصف مُعَدّة.
- تُنتج إضافة المزوّد ملفًا لكنها تترك التحقق أو الأرشفة أو التصحيحات أو النقل لك، وهذا شائع.
- يفرض عملاؤك متطلبات لا تغطيها الإضافة: مراجع مشترٍ محددة، مراجع طلبات لكل بند، رفع إلى بوابة إلكترونية، Peppol.
- الخيار "القياسي" الوحيد المعروض هو استبدال النظام الذي يُنشئ الفواتير، وترحيلٌ تحت ضغط الموعد النهائي خطر أكبر من الإلزام نفسه.
الشكل الصحيح صغير: نموذج فاتورة مرجعي موحّد مبني على EN 16931، ومُحوِّلات ربط من كل نظام مصدر، وأداة التحقق من KoSIT كبوابة، ومولّد للصيغ، وأرشيف غير قابل للتعديل، ومُحوِّلات للنقل. دون إعادة كتابة النظام المصدر. هذا هو النمط الذي يقوم عليه عملنا في تكامل E-Rechnung (الصفحة باللغة الألمانية): إضافة XRechnung وZUGFeRD إلى البرنامج الذي تنشأ فيه الفواتير أصلاً، بدل استبدال ذلك البرنامج.
الخيار الذي نصرف عنه أي أحد يظهر عادةً في وقت متأخر: أداة ويب مستقلة يعيد فيها شخص ما كتابة الفواتير من النظام الحقيقي ليحصل على ملف مطابق. تلحق بالموعد النهائي، وتترك لك نظام سجل ثانيًا ومشكلة تسوية دائمة.
ما لا نقوله
لا نقول إن 80 يومًا مهلة ميؤوس منها. لشركة بياناتها الأساسية نظيفة ونظام ERP لديها محدَّث، هذا مشروع إعدادات. ولا نقول إن الفاتورة المُهيكلة عبء بيروقراطي: فاتورة تم التحقق منها، مقروءة آليًا، ويمكن ترحيلها دون إعادة كتابتها، منتَج أفضل من PDF.
نقول إن الموعد النهائي يختبر ما إذا كانت سجلات عملائك ومفاتيحك الضريبية ودورة حياة مستنداتك في حال تستطيع آلة أن تفحصها. أداة التحقق أقل تسامحًا بكثير من موظف الحسابات الدائنة الذي ظل يصلح فواتيرك بصمت منذ سنوات. ابدأ بالبيانات.
قراءات إضافية
- وزارة المالية الاتحادية (BMF)، Fragen und Antworten zur Einführung der obligatorischen E-Rechnung (بصيغتها في مارس 2026) (opens in new tab): النطاق والاستثناءات والصيغ والتحقق والأرشفة من الإدارة الضريبية نفسها.
- نص § 14 UStG (opens in new tab) و§ 27 Abs. 38 UStG (opens in new tab): التعريف والأحكام الانتقالية بصياغتها الأصلية.
- مواصفة XRechnung لدى KoSIT (opens in new tab): المواصفة الحالية وتواريخ السريان وخطة الإصدارات.
- أداة التحقق من KoSIT على GitHub (opens in new tab): محرك التحقق مفتوح المصدر.
- معيار ZUGFeRD لدى FeRD (opens in new tab): الصيغة الهجينة وإصدارها الحالي.
- تغطية Deloitte Tax-News لتعميم BMF الصادر في 15 أكتوبر 2025 (opens in new tab): فئات الأخطاء وعواقبها.
مقالة عشوائية، مرّة في الأسبوع.
أدخل بريدك الإلكتروني وسنرسل إليك مقالة مختارة من أرشيفنا — بلا بيع ولا إزعاج.
رسالة واحدة تقريباً في الأسبوع. إلغاء الاشتراك بنقرة واحدة.
مقالات ذات صلة
قتل سير عمل Excel: كيف تستبدل فرق Mittelstand جداول البيانات فعلاً
نمط ترحيل عملي لاستبدال ملف Excel المشترك الذي يُدير أعمالك — دون كسر العمليات أو فرض إدارة التغيير.
GDPR بالتصميم: أنماط هندسية لبرمجيات الشركات الصغيرة والمتوسطة (ليست نصيحة قانونية)
أنماط هندسية ملموسة للإقامة، والموافقة، والحذف، وسجلات التدقيق، ومراجعة المزوّدين — مستمدة من شحن منتجات لعملاء Mittelstand الألمان.
الوكلاء ليسوا مستخدمين: أزمة الهوية خلف 88٪ من حوادث الذكاء الاصطناعي في المؤسسات
معظم حوادث الذكاء الاصطناعي في المؤسسات ليست حقن أوامر. إنها وكلاء يعملون بصلاحيات لم يكن ينبغي أن يحصلوا عليها، تحت بيانات اعتماد لا يستطيع أحد إبطالها بشكل نظيف.