فحص جاهزية ZATCA المرحلة الثانية

المرحلة الثانية من الفوترة الإلكترونية (e-Invoicing Phase 2) أو ما تُسمّيها هيئة الزكاة والضريبة والجمارك (ZATCA) بمرحلة "الربط والتكامل" Integration Phase، هي خطوة تطوُّرية تلت المرحلة الأولى التي كانت مرحلة "الإصدار والحفظ" Generation Phase. بدأت رسمياً في 1 يناير 2023 لأولى الموجات، وتستمر تباعاً حتى تشمل جميع المنشآت الخاضعة لـ VAT.

الفكرة الأساسية للمرحلة الثانية أن نظام الفوترة في المنشأة يجب أن يتصل مباشرة بمنصة "فاتورة" التابعة لـ ZATCA عبر واجهات برمجية (API)، فيُرسل كل فاتورة ضريبية قبل أو بعد إصدارها للعميل بحسب نوعها، ويستقبل ختمها التشفيري.

لماذا أطلقت ZATCA المرحلة الثانية؟

الهدف الأساس هو مكافحة التهرّب الضريبي والفواتير الوهمية. بربط كل فاتورة بالهيئة في الزمن الحقيقي، تصبح كل معاملة قابلة للتحقّق ومحمية من التلاعب. هذا يرفع شفافية السوق، يحمي المنشآت الملتزمة من المنافسة غير العادلة، ويدعم تحوّل الاقتصاد الرقمي ضمن رؤية 2030. المنشأة التي تفهم الغاية تتعامل مع التطبيق باعتباره فرصة تنظيم لا عبئاً.

المرحلة الأولى كانت تتطلب من المنشأة فقط أن تُصدِر فواتيرها إلكترونياً عبر نظام معتمد (لا ورق، لا ملفات صور)، وأن تُولِّد QR Code على فواتير B2C. لم يكن هناك ربط مباشر مع ZATCA، وكانت المنشأة تحتفظ بالفواتير لديها فقط.

المرحلة الثانية أضافت طبقة كاملة من المتطلبات: الفواتير يجب أن تكون بصيغة UBL 2.1 XML (لا PDF فقط)، يجب أن تحمل Cryptographic Stamp يصدر من شهادة CSID مرتبطة بسجل المنشأة الضريبي، يجب أن تُرسَل عبر API إلى منصة فاتورة، ويجب أن تستقبل المنشأة UUID و Hash من ZATCA كتأكيد للاعتماد.

تصنيف الفواتير في المرحلة الثانية

ZATCA تُقسِّم الفواتير في المرحلة الثانية إلى نوعين رئيسين: فواتير ضريبية (Tax Invoice) للمعاملات بين الشركات B2B، وفواتير ضريبية مبسَّطة (Simplified Tax Invoice) للمعاملات مع المستهلك النهائي B2C. الفواتير الضريبية B2B تتطلب اعتماد مسبق Clearance من ZATCA قبل تسليمها للعميل، أما B2C فالإبلاغ Reporting يتم خلال 24 ساعة من الإصدار.

أثر عدم الالتزام بالمرحلة الثانية

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

ZATCA اعتمدت أسلوب الدمج التدريجي عبر "موجات" Waves، كل موجة تشمل المنشآت ذات الإيرادات الخاضعة للضريبة ضمن نطاق محدد. الموجات الأولى شملت أكبر المنشآت، وكل موجة لاحقة توسِّع النطاق ليشمل منشآت أصغر، حتى تغطي الجميع.

الموجات المُعلنة (مرجعية)

الموجة الأولى: المنشآت بإيرادات أكثر من 3 مليارات ريال (يناير 2023). الموجة الثانية: أكثر من 500 مليون ريال (يوليو 2023). الموجة الثالثة: أكثر من 250 مليون ريال (أكتوبر 2023). الموجات من 4 إلى 14 غطّت تدريجياً خلال 2024 وبداية 2025 المنشآت بإيرادات تقريبية من 5 ملايين إلى 150 مليون ريال. الموجات من 15 إلى 22 نزلت خلال 2025 بالعتبة حتى مليون ريال (الموجة 22: من مليون إلى 1.25 مليون ريال، بمهلة حتى 31 ديسمبر 2025). الموجة 23 — أُعلنت معاييرها في الجريدة الرسمية في 27 يونيو 2025 — تشمل من تجاوزت إيراداته الخاضعة للضريبة 750 ألف ريال في أي سنة من 2022 إلى 2024، بمهلة التزام من 1 يناير إلى 31 مارس 2026. والموجة 24 خفضت العتبة إلى 375 ألف ريال — وهي عتبة التسجيل الإلزامي في VAT نفسها — بمهلة تنتهي في 30 يونيو 2026، أي أن الدمج بات يغطي عملياً كل المنشآت المسجَّلة.

كيف تعرف موجتك؟

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

لماذا تستبق الموجة؟

ستة أشهر تبدو وقتاً كافياً، لكنها في الواقع ضيّقة لمشروع تكامل تقني كامل: اختيار المزوّد، تعديل النظام، توليد المفاتيح، اجتياز Sandbox، والترقية إلى الإنتاج. المنشآت التي تنتظر الإشعار ثم تبدأ تجد نفسها تحت ضغط شديد قرب الموعد، وقد ترتكب أخطاء تُؤخّر الاعتماد. الاستباق يمنحك هامش أمان لاختبار شامل ومعالجة المفاجآت.

شهادة Cryptographic Stamp Identifier (CSID) هي شهادة تشفيرية تربط منشأتك بـ ZATCA وتُستخدم للتوقيع الإلكتروني على كل فاتورة. هناك نوعان: شهادة الامتثال Compliance CSID تُستخدم خلال مرحلة الاختبار في Sandbox، وشهادة الإنتاج Production CSID تُستخدم على الفواتير الحقيقية.

كيف تحصل على CSID؟

الحصول على CSID يمر بثلاث خطوات تقنية: أولاً يولِّد نظامك زوج مفاتيح ECDSA على المنحنى secp256k1 — هذا هو النوع الوحيد الذي تقبله ZATCA، وليس RSA كما يشيع خطأً في مصادر كثيرة. ثانياً يُرسل طلب توقيع شهادة Certificate Signing Request بصيغة PKCS#10 مع بيانات المنشأة الضريبية إلى نقطة compliance على API فاتورة، فيستقبل شهادة Compliance. ثالثاً بعد اجتياز اختبارات Sandbox يُرسل طلب الترقية إلى Production فيستقبل شهادة الإنتاج.

صلاحية الشهادة وتجديدها

شهادة Production CSID لها فترة صلاحية محدّدة، وعند اقترابها من الانتهاء يجب تجديدها قبل أن تتوقّف قدرتك على توقيع الفواتير. اضبط تنبيهاً مبكراً لتاريخ انتهاء الشهادة، فانتهاؤها فجأة يعني توقّف إصدار الفواتير القياسية فوراً. احتفظ كذلك بنسخة آمنة من بيانات الشهادة وربطها بسجلّ المنشأة الضريبي لتسهيل التجديد.

عملية الربط الفعلية تبدأ من بوابة فاتورة (fatoora.zatca.gov.sa) بحساب المنشأة الضريبي. من داخل البوابة تُنشئ "وحدة إصدار" جديدة وتطلب رمز تحقّق OTP — رمز قصير الصلاحية يُستخدم لمرة واحدة لربط جهازك بحسابك الضريبي، فلا تولّده قبل أن يكون نظامك جاهزاً فعلاً للإرسال.

من CSR إلى Compliance CSID

يولِّد نظامك زوج مفاتيح ECDSA secp256k1 ثم يبني طلب توقيع شهادة CSR بصيغة PKCS#10 يتضمن بيانات المنشأة: الرقم الضريبي المكوَّن من 15 رقماً، اسم الوحدة، أنواع الفواتير التي ستصدرها، والرقم التسلسلي للحل التقني. يُرسَل CSR مع OTP إلى نقطة compliance، فتعيد ZATCA شهادة Compliance CSID مع Secret يُستخدمان معاً في مصادقة Basic Auth لكل الطلبات اللاحقة.

الفواتير الست الإلزامية

قبل الترقية إلى الإنتاج يجب أن تجتاز وحدة الإصدار اختبار امتثال يغطي أنواع المستندات التي ستصدرها فعلياً: فاتورة قياسية، إشعار دائن قياسي، إشعار مدين قياسي، فاتورة مبسّطة، إشعار دائن مبسّط، وإشعار مدين مبسّط — حتى 6 مستندات اختبارية لمن يصدر النوعين معاً. فقط بعد نجاحها كلها يُقبل طلب الترقية (بمعرّف طلب الامتثال Compliance Request ID) وتصدر شهادة Production CSID لتلك الوحدة تحديداً.

فواتير المرحلة الثانية يجب أن تُولَّد بصيغة Universal Business Language الإصدار 2.1 (UBL 2.1) — وهي صيغة XML دولية معتمدة من OASIS. ZATCA حدَّدت متطلباتها المحلية في وثيقتين رسميتين: المواصفة الفنية لملف XML (XML Implementation Standard) وقاموس البيانات (Data Dictionary)، إضافة إلى قواعد تحقّق محلية تحمل البادئة BR-KSA، ويجب أن يَعبُر كل ملف XML هذه الفحوص قبل قبوله.

الحقول الإلزامية في UBL 2.1 SA

من أبرز الحقول الإلزامية: الرقم الضريبي للبائع والمشتري، UUID الفاتورة، نوع الفاتورة (Standard أو Simplified)، تاريخ ووقت الإصدار، تفاصيل البنود مع كميات وأسعار وضرائب، مجموع VAT بالتفصيل لكل فئة ضريبية، Previous Invoice Hash (هاش الفاتورة السابقة في سلسلة)، Cryptographic Stamp، و QR Code TLV.

التحقّق من صحّة XML قبل الإرسال

قبل إرسال أي فاتورة إلى منصة فاتورة، يجب أن يمرّ ملف XML محلياً على نفس فحوص Schematron التي تطبّقها ZATCA. هذا يكشف الأخطاء مبكراً ويقلّل الرفض. الفحوص تشمل اتساق الحسابات (مجموع البنود = إجمالي الفاتورة قبل VAT)، صحّة نِسب VAT لكل بند، وجود كل الحقول الإلزامية، وصحّة تنسيق التواريخ بصيغة ISO 8601. بناء طبقة تحقّق محلية يوفّر رحلات ذهاب وإياب مكلفة مع الخادم.

Cryptographic Stamp هو ختم تشفيري يُولَّد بخوارزمية ECDSA على المنحنى secp256k1 (نفس منحنى مفاتيح CSID) باستخدام مفتاحك الخاص الموقَّع من ZATCA. الختم يضمن أن الفاتورة لم تُعدَّل بعد إصدارها وأنها صادرة فعلاً من المنشأة المسجَّلة. أي تعديل لاحق على XML يكسر الختم ويجعل الفاتورة باطلة.

QR Code TLV

QR Code في المرحلة الثانية أكثر تعقيداً من المرحلة الأولى. بُنية TLV (Tag-Length-Value) تحتوي تسعة حقول إلزامية: اسم البائع، الرقم الضريبي، تاريخ ووقت الفاتورة، مجموع الفاتورة، مجموع VAT، الـ Hash، Cryptographic Stamp، Public Key، والشهادة CSID. في الفواتير المبسّطة يولِّد نظامك الـ QR محلياً ويختمه قبل التسليم، أما في الفواتير القياسية B2B فتضيف ZATCA الـ QR عند الاعتماد Clearance، ثم يُضمَّن في النسخة المقروءة PDF/A-3 التي يُرفَق بداخلها ملف XML الأصلي.

فهم بنية TLV يفيدك في تشخيص أخطاء الـ QR بنفسك دون انتظار رسالة رفض من المنصة. بعد فك ترميز Base64 تحصل على مصفوفة بايتات تُقرأ كوحدات متتالية: بايت واحد للوسم Tag، بايت واحد للطول Length، ثم عدد البايتات المذكور للقيمة Value. تُكرَّر القراءة حتى نهاية المصفوفة فتحصل على الحقول التسعة بالترتيب.

خريطة الوسوم من 1 إلى 9

الوسوم من 1 إلى 5 ورثتها المرحلة الثانية من الأولى: اسم البائع، الرقم الضريبي، الطابع الزمني، إجمالي الفاتورة مع VAT، وإجمالي VAT. المرحلة الثانية أضافت أربعة وسوم: الوسم 6 هاش XML للفاتورة، الوسم 7 توقيع ECDSA على الهاش، الوسم 8 المفتاح العام للبائع، والوسم 9 (في الفواتير المبسّطة) توقيع ZATCA على المفتاح العام نفسه — وهو ما يمنع انتحال مفاتيح غير مسجَّلة لدى الهيئة.

كيف تتحقّق برمجياً؟

أعد حساب هاش SHA-256 لملف XML وقارنه بقيمة الوسم 6، ثم تحقّق من توقيع الوسم 7 على الهاش باستخدام المفتاح العام في الوسم 8 على المنحنى secp256k1. وانتبه لخطأ شائع: قراءة القيم العربية بافتراض بايت واحد لكل حرف تُنتج نصاً مشوَّهاً، فالقيم مرمَّزة UTF-8 والحرف العربي يشغل بايتين. لتجربة الفك عملياً استخدم مفكّك QR فاتورة ZATCA.

منصة "فاتورة" Fatoora هي البوابة الرسمية لـ ZATCA لاستقبال الفواتير الإلكترونية. للمرحلة الثانية هناك ثلاث نقاط API رئيسة: نقطة Compliance للاختبار، نقطة Clearance لاعتماد الفواتير B2B، ونقطة Reporting للإبلاغ عن الفواتير B2C والملاحظات الدائنة والمدينة خلال 24 ساعة.

المتطلبات التقنية

الاتصال يتم عبر HTTPS مع TLS 1.2 على الأقل. المصادقة تعتمد على Basic Auth باستخدام Username (CSID) و Password (Secret) الصادرَين من ZATCA. الجسم body من نوع JSON يحتوي على invoiceHash و uuid و invoice (UBL XML Base64 Encoded). الرد يأتي بـ HTTP 200 إذا تم القبول، مع UUID و Hash موقَّعَين من ZATCA.

معالجة انقطاع الاتصال عبر API

تصميم نظامك يجب أن يتحمّل انقطاع الشبكة أو بطء استجابة منصة فاتورة. اعتمد سياسة إعادة محاولة retry بتراجع أُسّي exponential backoff حتى لا تغرق الخادم بطلبات متكررة، وضع الفواتير العالقة في طابور دائم يُعاد إرساله تلقائياً عند عودة الخدمة. سجّل كل محاولة ورمز الاستجابة لتشخيص الأعطال بسرعة. الفواتير القياسية تبقى معلّقة حتى تُعتمد، فلا تسلّمها للعميل قبل وصول ردّ Cleared.

قبل أي ترقية إلى الإنتاج، يجب أن تجتاز منشأتك مجموعة من الاختبارات في بيئة Sandbox التي توفِّرها ZATCA. هذه البيئة تماثل الإنتاج لكنها لا تُسجِّل فواتير حقيقية. الهدف هو ضمان أن تنفيذك يلتزم بكل قواعد UBL 2.1 و Schematron و القواعد التجارية لـ ZATCA.

أنواع الاختبارات

هناك ثلاث فئات: اختبارات Standard Invoice، اختبارات Simplified Invoice، واختبارات Credit / Debit Notes. كل فئة تتطلب توليد عينات فواتير بأنماط متعددة (مع خصم، مع شحن، مع ضريبة صفر، مع إعفاء، إلخ). ZATCA لا تمنح شهادة Production CSID حتى تجتاز كل الاختبارات اللازمة.

نظام VAT في السعودية (المادة 66 من اللائحة التنفيذية) يُلزم المنشأة بالاحتفاظ بكل الفواتير والمستندات الضريبية لمدة 6 سنوات على الأقل، وترتفع المدة لسجلات الأصول الرأسمالية: 11 سنة للأصول المنقولة و15 سنة للعقارات (فترة تعديل الأصل زائد 5 سنوات). أداة الجاهزية أعلاه تستخدم 7 سنوات كهامش أمان عملي فوق الحد الأدنى العام. للمرحلة الثانية، الأرشفة يجب أن تشمل: ملف UBL 2.1 XML الأصلي، ملف PDF/A-3 المرفق، استجابة ZATCA (UUID + Hash + Cryptographic Stamp)، وأي ملاحظات دائنة أو مدينة مرتبطة.

متطلبات الأرشيف

الأرشيف يجب أن يكون: قابلاً للقراءة بسهولة طوال فترة الاحتفاظ، محمياً من العبث (Tamper-evident)، قابلاً للبحث والاسترجاع السريع عند طلب ZATCA، ومخزَّناً في موقع آمن (سحابة محلية أو نظام DMS معتمد).

الفرق بين الحفظ والأرشفة

الحفظ يعني إبقاء الفاتورة متاحة للتشغيل اليومي، بينما الأرشفة نقلها إلى تخزين طويل الأمد مع ضمان سلامتها لسنوات. لا تكتفِ بحفظ PDF فقط؛ فالأصل القانوني هو ملف UBL 2.1 XML مع استجابة ZATCA. اختبر دورياً أن الأرشيف قابل للاسترجاع فعلاً، لأن أرشيفاً لا يُقرَأ عند طلب ZATCA يعادل عدم وجوده.

الخطوة الأولى: تحقق من إيرادك السنوي وحدِّد موجتك المتوقعة. الخطوة الثانية: اختر حلَّاً للفوترة الإلكترونية من قائمة الحلول المعتمدة من ZATCA، أو طوِّر حلَّك الداخلي إذا كنت منشأة تقنية. الخطوة الثالثة: ولِّد زوج مفاتيح ECDSA على المنحنى secp256k1 واطلب شهادة Compliance CSID. الخطوة الرابعة: عدِّل نظامك ليُولِّد UBL 2.1 XML بكل الحقول الإلزامية. الخطوة الخامسة: نفِّذ Cryptographic Stamping و QR TLV. الخطوة السادسة: ادخل Sandbox واجتز الاختبارات. الخطوة السابعة: اطلب ترقية إلى Production CSID. الخطوة الثامنة: فعِّل الإرسال الفعلي قبل تاريخ الموجة المُعلن.

جدول زمني واقعي

خصّص أسبوعين لاختيار الحلّ والتعاقد، وأسبوعين إلى أربعة لتعديل النظام وتوليد UBL والتوقيع، وأسبوعين على الأقل لاختبارات Sandbox ومعالجة الرفض، وأسبوعاً للترقية إلى الإنتاج والتشغيل التجريبي قبل التفعيل الكامل. أي تأخير في مرحلة Sandbox هو الأكثر شيوعاً، لذا لا تجعله على المسار الحرج قرب موعد الموجة. ابدأ المشروع قبل ثلاثة أشهر على الأقل من تاريخ الدمج المطلوب.

الاعتماد المسبق Clearance هو جوهر المرحلة الثانية للفواتير الضريبية B2B. عندما يُصدر نظامك فاتورة قياسية، لا تُسلَّم للعميل مباشرة، بل تُرسَل أولاً إلى نقطة Clearance في منصة فاتورة. ZATCA تفحص الفاتورة فوراً مقابل قواعد UBL 2.1 و Schematron والقواعد التجارية، فإن نجحت أعادت لك نسخة مختومة Cleared تحمل QR Code من ZATCA نفسها، وعندها فقط يحقّ لك تسليمها للمشتري.

ماذا يحدث عند الرفض؟

إذا ردّت ZATCA بحالة Rejected، تتضمّن الاستجابة قائمة أخطاء مفصّلة (Validation Errors) تشير إلى الحقل المخالف ورمز القاعدة. لا يجوز تسليم الفاتورة المرفوضة للعميل؛ يجب تصحيح السبب وإعادة الإرسال. حالة Warning تختلف: الفاتورة تُعتمد لكن مع تنبيهات يُفضَّل معالجتها قبل أن تتحوّل إلى أخطاء في تحديثات لاحقة.

الفرق بين Clearance و Reporting

Clearance متزامن real-time ويسبق التسليم، ويخصّ الفواتير القياسية. Reporting غير متزامن ويلي التسليم بحدّ أقصى 24 ساعة، ويخصّ الفواتير المبسّطة B2C. خلط النوعين — كإرسال فاتورة B2B عبر مسار Reporting — يُعدّ مخالفة جوهرية تُبطل صحّة الفاتورة قانونياً.

واحدة من أكثر آليات المرحلة الثانية إرباكاً تقنياً هي سلسلة الهاش. كل فاتورة تحمل حقل Previous Invoice Hash يحتوي على البصمة الرقمية (SHA-256) للفاتورة السابقة في تسلسل المنشأة. هذا يربط الفواتير في سلسلة متصلة بحيث لا يمكن حذف فاتورة من المنتصف أو إعادة ترتيبها دون كسر السلسلة بالكامل.

أول فاتورة في السلسلة

الفاتورة الأولى لكل جهاز إصدار تستخدم قيمة ابتدائية متفقاً عليها لأنه لا توجد فاتورة قبلها: وفق قاموس بيانات ZATCA هي ترميز Base64 لهاش SHA-256 للمحرف 0 — وليست سلسلة أصفار كما يشيع خطأً. كل فاتورة تالية تأخذ هاش الفاتورة التي سبقتها مباشرة. إن تعطّل نظامك وأعدت إصدار فاتورة بهاش سابق خاطئ، ترفض ZATCA كل ما يليها حتى تُصلح التسلسل.

التوحيد القياسي Canonicalization

الهاش يُحسب على نسخة موحَّدة canonical من ملف XML، أي بعد إزالة الفراغات الزائدة وتوحيد ترتيب العناصر وفق معيار C14N. أي اختلاف بسيط في كيفية توليد مكتبتك للـ XML — مسافة إضافية أو ترتيب سمات مختلف — يُنتج هاشاً مختلفاً عن الذي تحسبه ZATCA، فيُرفض الختم. لذا اعتمد مكتبة XML تدعم C14N بدقّة ولا تعدّل الملف يدوياً بعد توليده.

لا يقتصر النظام على الفواتير؛ فالإشعار الدائن Credit Note والإشعار المدين Debit Note يخضعان لنفس متطلبات المرحلة الثانية. الإشعار الدائن يُصدَر عند إرجاع بضاعة أو تخفيض قيمة فاتورة سابقة، والمدين عند زيادة القيمة. كلاهما يجب أن يشير صراحة إلى رقم الفاتورة الأصلية وسببها.

متى تستخدم كلاً منهما؟

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

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

أسئلة يجب طرحها على المزوّد

هل يدعم الحلّ كلاً من Clearance و Reporting؟ كيف يتعامل مع انقطاع الاتصال بمنصة فاتورة — هل يضع الفواتير في طابور retry queue؟ هل يحفظ سلسلة الهاش تلقائياً؟ ما حدود عدد الفواتير في الباقة وتكلفة التجاوز؟ هل يوفّر بيئة Sandbox منفصلة للاختبار قبل الإنتاج؟ هذه الأسئلة تكشف جاهزية المزوّد الحقيقية قبل التوقيع.

تطوير داخلي أم حلّ جاهز؟

المنشآت الصغيرة والمتوسطة عادةً تكسب أكثر باعتماد حلّ SaaS جاهز معتمد: تكلفة أقل، صيانة مستمرة، وتحديثات تلقائية مع تغيّر مواصفات ZATCA. التطوير الداخلي يناسب المنشآت الكبيرة ذات الأنظمة المعقّدة والفرق التقنية القادرة على متابعة تحديثات المواصفات. أياً كان خيارك، تأكّد أن المسؤولية عن مواكبة تغييرات ZATCA محدّدة بوضوح حتى لا تتقادم فواتيرك.

المفتاح الخاص Private Key المرتبط بشهادة Production CSID هو أخطر أصل أمني في تنفيذك. من يملكه يستطيع توقيع فواتير باسم منشأتك. لذا لا يُخزَّن أبداً نصاً صريحاً في الكود أو في ملفات الإعداد، بل في مخزن أسرار آمن (Key Vault) أو وحدة أمان مادية HSM متى توفّرت.

ممارسات حماية المفاتيح

قيّد الوصول للمفتاح بأقل صلاحيات ممكنة، وفعّل تدوير المفاتيح rotation وفق سياسة واضحة، وسجّل كل عملية توقيع في سجلّ تدقيق audit log غير قابل للتعديل. عند مغادرة موظف له صلاحية، أعد إصدار الشهادة فوراً. تذكّر أن تسريب المفتاح لا يعرّضك لغرامة فحسب، بل لفواتير احتيالية باسمك يصعب التبرّؤ منها.

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

مؤشرات يجب تتبّعها

نسبة الفواتير المرفوضة يومياً (ارتفاعها المفاجئ يعني خللاً في توليد XML)، متوسط زمن الاعتماد، عدد محاولات إعادة الإرسال، وصحّة سلسلة الهاش. اضبط تنبيهات تلقائية تُخطر الفريق فور تجاوز أي مؤشر حدّه الطبيعي، فالاكتشاف المبكر يمنع تراكم فواتير مرفوضة يصعب تصحيحها لاحقاً.

خطة استمرارية الأعمال

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

أول خطأ شائع: التهاون في اختبار Sandbox والاكتفاء بعدد محدود من السيناريوهات. ZATCA قد ترفض شهادة Production إذا اكتشفت أن الاختبارات لم تغطِّ نطاقاً كافياً. ثاني خطأ: عدم احتساب Previous Invoice Hash بشكل صحيح، فيكسر سلسلة الفواتير ويُسبِّب رفضاً متتابعاً. ثالث خطأ: استخدام مكتبات XML غير قادرة على المحافظة على الترتيب الدقيق للحقول (Canonicalization)، فيختلف الـ Hash بين البائع والـ ZATCA.

أخطاء عملية أخرى

استخدام شهادة Compliance بدل Production بعد التحوُّل (يُسبِّب رفضاً فورياً). نسيان تحديث Hash الفاتورة السابقة بعد كل إصدار. إرسال فاتورة B2B إلى نقطة Reporting بدل Clearance. استخدام تاريخ بصيغة محلية بدل ISO 8601. تجاهل Schematron rules التي تتعلَّق بالاتساق الحسابي (مثل أن مجموع البنود يطابق مجموع الفاتورة قبل VAT).

كيف تتجنّب هذه الأخطاء؟

ابنِ طبقة تحقّق محلية تحاكي قواعد Schematron قبل الإرسال، واعتمد مكتبة C14N موثوقة للحفاظ على ترتيب الحقول، وأتمت احتساب Previous Invoice Hash بحيث لا يعتمد على إدخال يدوي. أنشئ مجموعة اختبارات انحدار regression tests تشمل كل أنماط الفواتير، وشغّلها بعد أي تعديل على النظام. هذه الممارسات تحوّل الأخطاء من مفاجآت إنتاجية مكلفة إلى إخفاقات اختبار تُكتشف وتُصحَّح مبكراً. ولاختبار مخرجاتك عمليّاً استعن بـ محوّل فاتورة ZATCA إلى XML، مولّد الفاتورة الضريبيّة، و أداة فاتورة ZATCA.

هل أحتاج إلى استبدال نظام محاسبتي بالكامل؟

ليس بالضرورة. كثير من أنظمة ERP الرئيسة (SAP, Oracle, Microsoft Dynamics, Odoo) أصدرت إضافات Add-ons معتمدة من ZATCA. إذا كان نظامك الحالي يدعم API، يمكن إضافة طبقة توليد UBL وربط API دون استبدال جذري.

كم تكلفة الانتقال إلى المرحلة الثانية؟

التكلفة تتراوح من بضعة آلاف ريال (لحلول SaaS شهرية للمنشآت الصغيرة) إلى مئات الآلاف لمشاريع تكامل كاملة مع ERP الكبيرة. العامل الأهم هو حجم المنشأة وعدد الفواتير وتعقيد المنتجات.

ماذا لو فاتني تاريخ موجتي؟

منذ 2022 تعتمد ZATCA نهجاً متدرِّجاً في مخالفات الفوترة الإلكترونية: تبدأ عادة بإنذار مع مهلة تصحيح نحو 3 أشهر، ثم غرامات تتصاعد مع التكرار خلال 12 شهراً (1,000 ثم 5,000 ثم 10,000 وقد تصل إلى 40,000 ريال)، بينما يبلغ الحد الأقصى 50,000 ريال لمخالفات عدم حفظ الفواتير والسجلات. والأخطر عملياً أن فواتيرك غير المعتمدة لا تصلح مستندات خصم ضريبي لعملائك، فيتأثر نشاطك التجاري مباشرة.

هل يمكن إصدار فاتورة ورقية احتياطاً؟

لا. الفواتير الورقية أو ملفات PDF غير المُولَّدة عبر نظام فوترة إلكترونية معتمد تُعتبر مخالفة. كل فاتورة يجب أن تمرَّ بالنظام الإلكتروني وتحصل على UUID و Hash من ZATCA.

ماذا أفعل إذا انقطع الاتصال بمنصة فاتورة أثناء البيع؟

للفواتير المبسّطة B2C، يمكن لنظامك المعتمد إصدار الفاتورة وتسليمها للعميل ثم إبلاغها لاحقاً خلال مهلة 24 ساعة عند عودة الاتصال، لأن مسارها Reporting غير متزامن. أما الفواتير القياسية B2B فلا يمكن تسليمها قبل الاعتماد، لذا يجب أن يضع نظامك طلب الاعتماد في طابور إعادة محاولة retry ويعيد الإرسال تلقائياً فور استعادة الاتصال.

هل تختلف المتطلبات بين الفاتورة القياسية والمبسّطة تقنياً؟

نعم جوهرياً. القياسية B2B تتطلب الرقم الضريبي للمشتري، وتمرّ بمسار Clearance المتزامن، وتُختم من ZATCA قبل التسليم. المبسّطة B2C لا تتطلب رقماً ضريبياً للمشتري، وتُختم محلياً من نظامك، ثم تُبلَّغ عبر Reporting خلال 24 ساعة. كلاهما يستخدم UBL 2.1 لكن بحقول وقواعد تحقّق مختلفة.

هل أحتاج إلى ربط كل فرع أو نقطة بيع على حدة؟

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

كم تستغرق عملية اجتياز Sandbox عادة؟

تتراوح من أيام إلى أسابيع بحسب جاهزية نظامك وعدد سيناريوهات الاختبار. المنشآت التي تعتمد حلَّاً معتمداً جاهزاً تجتاز أسرع، بينما التطوير الداخلي قد يحتاج دورات تصحيح متعدّدة لمعالجة أخطاء Schematron وتوحيد C14N. ابدأ مبكراً قبل تاريخ موجتك بوقت كافٍ لتجنّب ضغط اللحظات الأخيرة.

هل يلزم محاسب مختص أم مطوّر للانتقال؟

يلزم الاثنان معاً. المطوّر يتولّى توليد UBL والتوقيع التشفيري وربط API، بينما يضمن المحاسب صحّة المعالجة الضريبية: فئات VAT الصحيحة، الإعفاءات، نسبة الصفر للصادرات، ومطابقة الإقرار للفواتير الصادرة. الفجوة بين الفهم التقني والمحاسبي هي مصدر كثير من الأخطاء العملية.

ما أكثر الحقول التي تُسبِّب رفض Schematron؟

الأخطاء الأكثر شيوعاً هي عدم اتساق المجاميع الحسابية بين البنود والإجمالي، نِسب VAT غير الصحيحة لفئة الإعفاء أو نسبة الصفر، تنسيق التواريخ بغير صيغة ISO 8601، الرقم الضريبي غير المكوَّن من خمسة عشر رقماً، وغياب Previous Invoice Hash أو خطأ في تسلسله. بناء طبقة تحقّق محلية تحاكي قواعد ZATCA يقلّل هذه الأخطاء قبل وصولها للمنصة.

كيف أتعامل مع كيان متعدّد المجموعات الضريبية VAT Group؟

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

هل يمكن دمج نظام QR الخاص بالمرحلة الأولى مع الثانية؟

نعم؛ المرحلة الثانية تبني فوق المرحلة الأولى ولا تُلغيها. QR Code يبقى مطلوباً على الفواتير المبسّطة، لكنه الآن يُولَّد بصيغة TLV ويتضمّن الختم التشفيري وبيانات إضافية. إذا كان نظامك يولِّد QR للمرحلة الأولى، فعادةً يحتاج تحديثاً لإضافة الحقول التشفيرية الجديدة بدلاً من استبداله بالكامل.

هل يجب الاحتفاظ ببيانات بيئة Sandbox الاختبارية؟

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

هل تنتهي صلاحية شهادة Production CSID؟

نعم، لشهادة CSID مدة صلاحية محدّدة، وانتهاؤها أثناء التشغيل يوقف قدرتك على توقيع الفواتير واعتمادها. راقب تاريخ الانتهاء واضبط تنبيهاً قبله بوقت كافٍ، ثم جدِّد الشهادة عبر بوابة فاتورة قبل انقضائها لتفادي انقطاع الإصدار في منشأتك.

المرسوم الملكي رقم (م/113) وتاريخ 1438/11/2هـ بنظام ضريبة القيمة المضافة. اللائحة التنفيذية للفوترة الإلكترونية الصادرة عن ZATCA. قرار الضوابط والمتطلبات والمواصفات الفنية والقواعد الإجرائية لتنفيذ لائحة الفوترة الإلكترونية، المنشور في الجريدة الرسمية بتاريخ 28 مايو 2021. وثائق المرحلة الثانية على بوابة ZATCA: قاموس البيانات (Data Dictionary)، المواصفة الفنية لملف XML (XML Implementation Standard)، المواصفة الأمنية (Security Features Implementation Standard)، قواعد التحقق BR-KSA، ودليل المطورين Developer Portal. الموقع الرسمي لـ ZATCA: zatca.gov.sa — منصة فاتورة، الأدلة الإرشادية، ودليل الحلول المعتمدة.