ما هي المرحلة الثانية من الفوترة الإلكترونية؟
أطلقت هيئة الزكاة والضريبة والجمارك (زاتكا) المرحلة الثانية من الفوترة الإلكترونية بدءاً من 1 يناير 2023، وهي مرحلة الربط والتكامل التي تشترط أن ترسل المنشآت فواتيرها مباشرة إلى منصة فاتورة الحكومية للتحقق منها قبل أو فور إصدارها.
تختلف المرحلة الثانية جوهرياً عن الأولى التي بدأت في 4 ديسمبر 2021، حيث كانت المرحلة الأولى تكتفي بإلزام المنشآت بإصدار فواتير إلكترونية مهيكلة، بينما تضيف المرحلة الثانية متطلبات تقنية متقدمة تشمل: الختم المشفّر، توقيع رقمي بشهادة CSID صادرة من زاتكا، وإرسال الفواتير عبر API محدد.
يتم إدراج المنشآت في المرحلة الثانية على دفعات حسب حجم الإيرادات السنوية، وتُبلّغ كل دفعة قبل ستة أشهر على الأقل من تاريخ الإلزام. الموجة الثامنة عشرة بدأت في يناير 2025، وموجات لاحقة تستمر بإدراج منشآت أصغر تدريجياً.
الفرق بين الفاتورة الضريبية والفاتورة المبسطة
تفرّق زاتكا بين نوعين من الفواتير الإلكترونية، ولكل نوع آلية إرسال مختلفة وخصائص فنية مميزة.
- الفاتورة الضريبية (Standard Tax Invoice): تُصدر للمنشآت المسجّلة في ضريبة القيمة المضافة (B2B) أو للجهات الحكومية (B2G). يجب إرسالها إلى زاتكا للحصول على موافقة (Clearance) قبل تسليمها للعميل، ولا تُعتبر صحيحة قانونياً حتى تختمها زاتكا برمز التشفير الخاص بها.
- الفاتورة المبسطة (Simplified Tax Invoice): تُصدر لمستهلك نهائي (B2C) في نقاط البيع غالباً. تُسلَّم للعميل فوراً عند الإصدار، ثم تُرسَل إلى زاتكا للإبلاغ (Reporting) خلال 24 ساعة كحد أقصى. يجب أن تحمل رمز QR متوافق مع مواصفات زاتكا.
هيكل ملف UBL 2.1 المطلوب
تشترط زاتكا أن تكون كل فاتورة بصيغة XML متوافقة مع معيار UBL 2.1 العالمي، مع امتدادات سعودية إضافية. الملف يحتوي على عدة أقسام أساسية يجب توفرها كاملة وإلا رُفضت الفاتورة.
- بيانات البائع: الاسم القانوني، رقم التسجيل الضريبي (15 رقم يبدأ ويُنتهى بـ3)، السجل التجاري، العنوان الوطني الكامل، ورقم البناء.
- بيانات المشتري: للفواتير الضريبية تُلزم البيانات الكاملة (اسم، عنوان، رقم ضريبي إن وجد). للفواتير المبسطة قد تُترك فارغة أو تحتوي على بيانات مختصرة.
- تفاصيل البنود: الوصف، الكمية، السعر قبل الضريبة، نسبة الخصم، نسبة وقيمة ضريبة القيمة المضافة، رمز فئة الضريبة (S للقياسية، Z للصفرية، E للمعفاة).
- إجماليات الفاتورة: المجموع قبل الضريبة، إجمالي الخصومات، إجمالي الضريبة، المبلغ المستحق الإجمالي.
- الختم المشفّر (Cryptographic Stamp): توقيع رقمي بـ ECDSA باستخدام الشهادة الصادرة من زاتكا، يُحسب على ملخص (hash) محتوى الفاتورة بصيغة Base64.
- رمز QR: نص بصيغة TLV مشفّر بـ Base64 يحتوي على اسم البائع، رقمه الضريبي، التاريخ، الإجمالي، قيمة الضريبة، توقيع الفاتورة، وملخص XML.
شهادة CSID والتوقيع الرقمي
قبل أي إرسال إلى زاتكا، يجب على كل وحدة إصدار (Electronic Generation Solution Unit) المرور بمرحلة Onboarding تنتهي بإصدار شهادة CSID خاصة بها. الشهادة تثبت هوية البائع وتُستخدم لتوقيع كل فاتورة بصورة مشفّرة.
تتم عملية الإصدار على ثلاث مراحل: أولاً يُولّد النظام زوج مفاتيح ECDSA محلياً، ثم يُرسل طلب توقيع شهادة (CSR) إلى زاتكا، وأخيراً تستلم الشهادة وتُحفظ مشفّرة في قاعدة البيانات.
المفاتيح الخاصة يجب ألا تُكشف لأي طرف، ولا تظهر في الواجهة الأمامية، ولا تُرسل في سجلات النظام (Logs). أي تسريب يُسقط مصداقية كل الفواتير الموقّعة بها ويفرض إعادة التسجيل.
آلية الإرسال إلى منصة فاتورة (Clearance & Reporting)
عند إصدار فاتورة ضريبية يقوم النظام بتجميع ملف XML، ثم يحسب الـ hash، ثم يُوقّعه بالمفتاح الخاص ويضيف الختم المشفّر للملف. بعدها يُرسل الملف إلى نقطة نهاية (endpoint) Clearance على منصة فاتورة عبر HTTPS.
تستجيب زاتكا بأحد ثلاثة احتمالات: (1) قبول مع وضع ختمها على الفاتورة وإرجاعها، وعندها فقط يحق لك تسليمها للعميل. (2) قبول مع تنبيهات (Warnings) لا تمنع الإصدار لكن يجب معالجتها مستقبلاً. (3) رفض مع تفاصيل الأخطاء، ويجب تصحيحها وإعادة الإرسال.
للفواتير المبسطة الإجراء أبسط: تُسلَّم للعميل مباشرة عند الإصدار وتحمل رمز QR متوافق، ثم تُرسَل إلى زاتكا عبر نقطة نهاية Reporting في غضون 24 ساعة. الفشل في الإبلاغ خلال هذه المدة يُعد مخالفة.
بناء رمز QR وفق مواصفات زاتكا
رمز QR هو الجزء الأكثر وضوحاً للعميل في الفاتورة المطبوعة، وأي خطأ في بنائه يجعل تطبيق زاتكا للتحقق من الفواتير غير قادر على قراءته. المواصفة دقيقة ولا تحتمل أي اختصار.
يُبنى الرمز بصيغة TLV (Tag-Length-Value) ويُشفّر النتيجة النهائية بـ Base64 قبل توليد QR. كل قيمة تأخذ Tag رقمي، يليه طول القيمة بالبايت، ثم القيمة نفسها بصيغة UTF-8.
- Tag 1: اسم البائع (مثال: شركة وتيل للحلول المحاسبية).
- Tag 2: الرقم الضريبي (15 خانة).
- Tag 3: التاريخ والوقت بصيغة ISO 8601 مع المنطقة الزمنية.
- Tag 4: إجمالي الفاتورة شاملاً ضريبة القيمة المضافة.
- Tag 5: قيمة ضريبة القيمة المضافة فقط.
- Tag 6: ملخص (hash) ملف XML بـ SHA-256 مشفّر بـ Base64.
- Tag 7: التوقيع الرقمي للفاتورة بـ ECDSA مشفّر بـ Base64.
- Tag 8: الشهادة العامة (Public Key) للبائع.
- Tag 9: توقيع زاتكا الذي وضعته عند الـ Clearance.
أخطاء شائعة عند التطبيق وكيفية تجنّبها
خبرتنا من تطبيق وتيل للمرحلة الثانية لمنشآت متعددة كشفت عن أخطاء متكررة، سردها هنا يوفّر عليك أسابيع من التشخيص.
- إرسال نفس الفاتورة مرتين بسبب فشل الشبكة: تأكد أن نظامك يحفظ نتيجة الإرسال محلياً قبل أي إعادة محاولة، ولا تعتمد على إعادة الإرسال التلقائي إلا بعد التحقق من حالة الفاتورة في زاتكا.
- اختلاف ترتيب الحقول في XML عن الترتيب المطلوب: UBL 2.1 يفرض ترتيب صارم، وبعض المُولّدات تخرج الحقول بترتيب أبجدي مما يؤدي إلى رفض الفاتورة. استخدم مولّد متخصص يحترم الترتيب.
- تنسيق التاريخ بدون منطقة زمنية: زاتكا تتطلب ISO 8601 كاملاً مع +03:00 أو Z. كتابة التاريخ بدون منطقة يُسبب رفضاً صامتاً.
- تقريب الأرقام بشكل غير متّسق بين XML ورمز QR: استخدم نفس دالة التقريب في كلا الموضعين، عادة round-half-up إلى منزلتين عشريتين.
- نسيان معالجة Warnings: حتى لو قُبلت الفاتورة مع تنبيهات، فإن تجاهلها يؤدي إلى تراكمها وتحويل بعضها لاحقاً إلى أخطاء بعد تحديثات زاتكا.
الاختبار في بيئة Sandbox قبل الإنتاج
زاتكا توفر بيئة اختبار كاملة (Sandbox) متطابقة مع الإنتاج تقنياً. كل تكامل جديد يجب أن يمر بفترة اختبار في الـ Sandbox للتأكد من قبول جميع أنواع الفواتير المتوقعة.
اختبر السيناريوهات التالية في الـ Sandbox: فاتورة عادية، فاتورة بأكثر من فئة ضريبية، فاتورة بخصم على مستوى الفاتورة، فاتورة دائنة (Credit Note)، فاتورة مدينة (Debit Note)، فاتورة بعملة أجنبية، فاتورة لعميل خارج السعودية (تصدير)، فاتورة مبسطة لمستهلك مجهول.
بعد نجاح كل السيناريوهات في الـ Sandbox لمدة لا تقل عن أسبوعين، يمكن طلب الانتقال إلى الإنتاج. زاتكا قد تطلب لقطات شاشة أو ملفات XML نموذجية كدليل على الاختبار.
كيف يبسّط وتيل المرحلة الثانية لمنشأتك
بنينا وتيل ليتعامل مع كل تعقيدات المرحلة الثانية تلقائياً، بحيث يركّز المحاسب أو صاحب العمل على عمله بدون قلق من التفاصيل التقنية.
- تسجيل وحدة الإصدار في زاتكا بضغطة واحدة من شاشة الإعدادات، مع توليد المفاتيح وإرسال CSR والاستلام الآلي للشهادة.
- توليد ملف XML بـ UBL 2.1 لكل فاتورة بشكل آلي مع جميع الحقول المطلوبة بالترتيب الصحيح.
- ختم مشفّر تلقائي بشهادة CSID المخزنة مشفّرة في قاعدة البيانات.
- إرسال آلي إلى زاتكا (Clearance أو Reporting حسب نوع الفاتورة) مع إعادة محاولة ذكية عند فشل الشبكة.
- رمز QR متوافق يُطبع تلقائياً على نسخة الفاتورة المسلّمة للعميل.
- حزمة تدقيق زاتكا (Audit Pack) جاهزة للتنزيل في أي وقت تشمل XML الأصلية، رد زاتكا، والشهادة المستخدمة.
آخر تحديث: 30/4/2026
