بعد أن أصبحت المرحلة الأولى من الفوترة الإلكترونية أمرًا واقعًا لدى معظم المنشآت في المملكة، تحوّل السؤال من «هل نصدر فواتير إلكترونية؟» إلى سؤال أصعب بكثير: هل نظامنا جاهز للربط المباشر مع هيئة الزكاة والضريبة والجمارك؟ المرحلة الثانية — مرحلة الربط والتكامل — ليست تحديثًا شكليًا على شكل الفاتورة، بل تغيير في بنية النظام نفسه: صيغة بيانات محدّدة، وختم تشفيري، وسلسلة تجزئة تربط كل فاتورة بسابقتها، واتصال مباشر بمنصة «فاتورة».
هذا الدليل يشرح ما تطلبه المرحلة الثانية من أنظمتك فعليًا، وكيف تعمل موجات التطبيق التي تحدّد موعدك، وما الخطوات العملية للربط من طلب الشهادة حتى بيئة الإنتاج. إن كنت تبحث عن مقدمة عامة أولًا، ابدأ من دليلنا الشامل: ما هي الفوترة الإلكترونية في السعودية (ZATCA)؟.
ما الذي تعنيه المرحلة الثانية عمليًا؟
في المرحلة الأولى (مرحلة الإصدار والحفظ) كان المطلوب أن تتوقف عن الفواتير اليدوية والمحرّرة يدويًا، وأن تصدر فواتيرك من نظام إلكتروني متوافق يحفظها بشكل غير قابل للتلاعب. لم يكن هناك اتصال مباشر بالهيئة.
المرحلة الثانية تضيف طبقة جديدة تمامًا: نظامك يجب أن يتحدث مع منصة «فاتورة» عبر واجهات برمجية (API)، وأن ينتج الفاتورة بصيغة بيانات قياسية بدلًا من مجرد ملف PDF أو صورة. باختصار، تنتقل الفاتورة من كونها «مستندًا» إلى كونها «رسالة بيانات» موقّعة تشفيريًا.
الفارق الجوهري في ثلاث نقاط:
- الصيغة: ملف XML مبني على معيار UBL 2.1 وفق مواصفات الهيئة، وليس مستندًا مطبوعًا فقط.
- التوقيع: ختم تشفيري (Cryptographic Stamp) مرتبط بشهادة رقمية صادرة عبر المنصة.
- الاتصال: إرسال الفاتورة إلى الهيئة إما للمشاركة (Clearance) أو للإبلاغ (Reporting) بحسب نوعها.
موجات التطبيق: كيف تعرف موعدك؟
لم تُطبَّق المرحلة الثانية على الجميع دفعة واحدة. اعتمدت الهيئة أسلوب الموجات (Waves): تُحدَّد كل موجة بمجموعة من المكلّفين بناءً على حجم الإيرادات الخاضعة للضريبة في سنة مرجعية، بدءًا بأكبر المنشآت ثم التدرّج نزولًا إلى المنشآت الأصغر.
ما يهمّك عمليًا من هذه الآلية:
- الموعد ليس اختياريًا ولا موحّدًا. منشأتك لها تاريخ ربط خاص بها يحدَّد بالموجة التي تقع فيها.
- الهيئة تُبلّغ المكلّفين مسبقًا. وفق ما أعلنته الهيئة عند إطلاق الموجات، يصل الإشعار قبل تاريخ الربط بفترة كافية للاستعداد (أُعلن عن مهلة لا تقل عن ستة أشهر في الموجات المنشورة).
- معيار الإيرادات يعود إلى سنة سابقة. أي أن انخفاض إيراداتك هذا العام لا يعني بالضرورة خروجك من الموجة التي حُدِّدت بناءً على سنة مرجعية.
- الموجات تتوسّع تدريجيًا. مع كل موجة جديدة ينخفض حدّ الإيرادات، ما يعني أن المنشآت الصغيرة والمتوسطة تدخل النطاق مع مرور الوقت.
لا تعتمد على أرقام منقولة من مقالات أو مجموعات واتساب لتحديد موجتك. الحدود والتواريخ تُنشر رسميًا وتُحدَّث مع كل موجة، والمرجع الوحيد الموثوق هو الإعلانات الرسمية على موقع هيئة الزكاة والضريبة والجمارك (zatca.gov.sa) بالإضافة إلى الإشعار الذي يصلك مباشرة. تحقّق من بريدك المسجّل ومن حسابك لدى الهيئة بشكل دوري.
صيغة الفاتورة: XML وفق UBL 2.1
حجر الأساس في المرحلة الثانية هو أن الفاتورة تُولَّد كملف XML منظّم، تتبع حقوله معيار UBL 2.1 مع القواعد الخاصة بالمملكة. هذا يعني أن كل عنصر في الفاتورة — الرقم الضريبي للبائع، بيانات المشتري، بنود الأصناف، أسس احتساب الضريبة، مبلغ ضريبة القيمة المضافة — يجب أن يوضع في الحقل الصحيح بالتنسيق الصحيح، لا أن يُطبع كنص حر.
هنا يفشل كثير من الأنظمة القديمة: فهي تطبع فاتورة جميلة الشكل، لكنها لا تحتفظ بالبيانات بشكل منظّم يسمح بتوليد XML صحيح. الأخطاء الأكثر شيوعًا في هذه المرحلة ليست أخطاء تشفير، بل أخطاء بيانات: رقم ضريبي ناقص، تصنيف ضريبي غير صحيح، أو فروق تقريب بين مجموع البنود وإجمالي الفاتورة.
بالنسبة للفواتير الضريبية القياسية، يُقبل أيضًا تسليم المشتري نسخة بصيغة PDF/A-3 يكون ملف XML مضمّنًا بداخلها، بحيث يحصل الإنسان على مستند مقروء ويحصل النظام على البيانات المهيكلة في الوقت نفسه. للتفصيل في الفرق بين نوعي الفاتورة، راجع: Simplified vs Standard Tax Invoice in Saudi Arabia.
الختم التشفيري وسلسلة التجزئة وعدّاد الفواتير
لضمان عدم التلاعب بالفواتير بعد إصدارها، تفرض المرحلة الثانية ثلاث آليات مترابطة يجب أن ينفّذها نظامك تلقائيًا:
- الختم التشفيري (Cryptographic Stamp): توقيع رقمي يُنشأ باستخدام مفتاح خاص مرتبط بشهادة رقمية صادرة عبر منصة «فاتورة». الفاتورة غير المختومة ببساطة غير مقبولة.
- سلسلة التجزئة (Hash Chain): كل فاتورة تحمل بصمة (Hash) الفاتورة السابقة لها. النتيجة سلسلة مترابطة: أي محاولة لحذف فاتورة أو تعديلها بأثر رجعي تكسر السلسلة وتصبح مكتشَفة.
- عدّاد الفواتير (Invoice Counter Value): عدّاد تسلسلي لا يُعاد ضبطه، يثبت عدم وجود فجوات في الترقيم.
يُضاف إلى ذلك معرّف فريد لكل فاتورة (UUID) وطابع زمني دقيق. مجتمعةً، هذه العناصر تجعل دفتر فواتيرك سجلًا يمكن التحقق منه رياضيًا — وهو المنطق نفسه الذي تقوم عليه أنظمة الفوترة المنظَّمة في أسواق أخرى، كما شرحنا في مقالنا عن الأثر القانوني للتوقيعات الرقمية على الفواتير.
رمز الاستجابة السريعة (QR) في المرحلة الثانية
رمز QR ليس زخرفة على الفاتورة. هو حقل بيانات مشفَّر بصيغة TLV ومحوَّل إلى Base64، ويجب أن يُولَّد آليًا من بيانات الفاتورة الفعلية. في المرحلة الأولى كان يحمل الحد الأدنى من الحقول: اسم البائع، والرقم الضريبي، والطابع الزمني، وإجمالي الفاتورة شاملًا الضريبة، ومبلغ ضريبة القيمة المضافة.
في المرحلة الثانية يتوسّع محتواه ليشمل عناصر التحقق التشفيري — من بينها بصمة ملف XML والتوقيع والمفتاح العام — بحيث يمكن التحقق من صحة الفاتورة المبسّطة ميدانيًا بمسح الرمز. عمليًا: لا تُنتج رمز QR يدويًا ولا تنسخه من فاتورة إلى أخرى؛ يجب أن يبنيه النظام لكل فاتورة على حدة.
المشاركة والإبلاغ: مساران مختلفان للفواتير
أهم نقطة يجب أن يستوعبها فريقك التقني هي أن الفواتير لا تُعامل جميعها بالطريقة نفسها:
- المشاركة (Clearance) — للفواتير الضريبية القياسية (عادة بين المنشآت B2B ومع الجهات الحكومية B2G). تُرسَل الفاتورة إلى الهيئة قبل تسليمها للمشتري، وتُعاد إليك بعد اعتمادها وختمها. الفاتورة غير المعتمدة لا تُعدّ فاتورة نظامية.
- الإبلاغ (Reporting) — للفواتير الضريبية المبسّطة (البيع للمستهلك النهائي B2C). تُسلَّم الفاتورة للعميل فورًا عند البيع، ثم تُرسل إلى الهيئة خلال مهلة قصيرة (٢٤ ساعة من لحظة الإصدار).
الأثر التشغيلي كبير: مسار المشاركة يعني أن إصدار الفاتورة أصبح يعتمد على استجابة خدمة خارجية. لذلك يجب أن يتعامل نظامك بذكاء مع حالات انقطاع الاتصال — طوابير إعادة إرسال، ومعالجة الأخطاء، وتسجيل الحالة لكل فاتورة — بدل أن يتوقف العمل عند أول انقطاع في الشبكة.
خطوات الربط: من طلب الشهادة إلى بيئة الإنتاج
عملية الانضمام (Onboarding) موحّدة إلى حد كبير، ويمكن تلخيصها في خمس خطوات:
- تجهيز الجهاز/الوحدة المُصدِرة: يولّد نظامك زوج مفاتيح تشفيري وطلب توقيع شهادة (CSR) يتضمّن بيانات المنشأة والوحدة.
- الحصول على رمز التحقق (OTP): من بوابة «فاتورة» في حساب المكلّف لدى الهيئة، لكل وحدة إصدار.
- شهادة الامتثال (Compliance CSID): يُرسل الطلب فيُصدَر لك اعتماد مؤقت لبيئة الاختبار.
- اجتياز فحوصات الامتثال: يرسل نظامك نماذج فواتير (قياسية ومبسّطة، مع إشعارات الدائن والمدين) ويجب أن تُقبل جميعها.
- شهادة الإنتاج (Production CSID): بعد النجاح تُصدَر شهادة الإنتاج ويبدأ الإرسال الفعلي. انتبه لتاريخ صلاحيتها ولإجراءات التجديد قبل انتهائها.
نقطة يغفل عنها كثيرون: كل جهاز أو وحدة إصدار (نقطة بيع، فرع، خادم) يحتاج إلى إعداده وربطه، لا المنشأة ككل. إن كان لديك عشرون نقطة بيع، فأنت أمام عشرين عملية إعداد وإدارة مفاتيح، لا واحدة.
الوظائف المحظورة في حلول الفوترة
لا يكفي أن ينتج الحل فاتورة صحيحة؛ يجب ألا يتيح الوظائف التي تسمح بالتحايل. من أبرز ما يُمنع:
- الدخول إلى النظام دون تحكّم في المستخدمين أو بصلاحيات مجهولة الهوية.
- تعديل أو حذف الفواتير الصادرة أو سجلات التدقيق (Audit Log).
- تغيير وقت النظام يدويًا للتلاعب بالطوابع الزمنية.
- تصدير أو نسخ مفتاح الختم التشفيري خارج البيئة الآمنة.
- وجود عدّادات فواتير متعددة أو إمكانية إعادة ضبط العدّاد.
عمليًا: التصحيح بعد الإصدار يتم عبر إشعار دائن أو مدين مرتبط بالفاتورة الأصلية، لا بتعديلها. وهذا مبدأ عالمي في الفوترة النظامية؛ المنطق نفسه المطبَّق في إسبانيا ضمن نظام VeriFactu.
إشعارات الدائن والمدين: التصحيح بعد الربط
بما أن تعديل الفاتورة الصادرة ممنوع، يصبح إشعار الدائن (Credit Note) وإشعار المدين (Debit Note) هما الأداة الوحيدة لتصحيح ما صدر. وهما بدورهما مستندان إلكترونيان يخضعان للمتطلبات نفسها: صيغة XML، وختم تشفيري، ودخول في سلسلة التجزئة، وإرسال عبر المسار المناسب لنوع الفاتورة الأصلية.
ما يجب أن يفعله نظامك تلقائيًا:
- الربط بالفاتورة الأصلية: يجب أن يشير الإشعار إلى رقم الفاتورة المصحَّحة وتاريخها.
- تسجيل سبب الإصدار: مرتجع، خصم لاحق، خطأ في السعر أو الكمية، أو إلغاء كامل للعملية.
- اتباع المسار الصحيح: إشعار مرتبط بفاتورة قياسية يمرّ بالمشاركة، والمرتبط بفاتورة مبسّطة يخضع للإبلاغ.
عمليًا، احرص على أن يمنع نظامك المستخدمين من «تعديل» فاتورة صدرت فعلًا، وأن يوجّههم تلقائيًا إلى إصدار إشعار بدلًا من ذلك. هذا الضبط وحده يوفّر عليك جزءًا كبيرًا من ملاحظات المراجعة لاحقًا.
كيف تختار حلًا متوافقًا؟ قائمة تحقق
قبل التوقيع مع أي مزوّد، اطلب إجابات واضحة — ويفضّل عرضًا حيًا — على الآتي:
- هل يولّد الحل XML وفق UBL 2.1 بمواصفات المملكة، ويمرّر فحوصات الامتثال؟
- هل يدعم المسارين معًا: المشاركة للفواتير القياسية والإبلاغ للمبسّطة؟
- كيف يدير المفاتيح والشهادات، وكيف يتعامل مع التجديد قبل انتهاء الصلاحية؟
- ماذا يحدث عند انقطاع الإنترنت؟ هل توجد آلية طوابير وإعادة إرسال تلقائية؟
- هل توجد لوحة تعرض حالة كل فاتورة (مقبولة / مقبولة مع ملاحظات / مرفوضة) مع سبب الرفض؟
- هل يدعم إشعارات الدائن والمدين المرتبطة بالفاتورة الأصلية؟
- هل يحتفظ بالسجلات ويتيح تصديرها لأغراض المراجعة والإقرارات الضريبية؟
- هل يعمل بواجهة عربية كاملة (RTL) وبفواتير ثنائية اللغة عند الحاجة؟
وإذا كانت لديك أعمال أو عملاء خارج المملكة، فكّر في الصورة الأشمل منذ البداية: نظام واحد يتعامل مع عملات ولغات متعدّدة يوفّر عليك ازدواج الأنظمة لاحقًا، كما نشرح في دليل الفوترة للعملاء الدوليين بعملات متعدّدة.
جدول زمني واقعي للاستعداد
الخطأ الأكثر تكلفة هو بدء المشروع قبل موعد الربط بأسابيع قليلة. توزيع معقول للمهام بعد وصول إشعار موجتك:
- الشهر الأول — التقييم: جرد أنظمة الإصدار ونقاط البيع، ومراجعة جودة بيانات العملاء (الأرقام الضريبية والعناوين) والأصناف والتصنيفات الضريبية.
- الشهر الثاني — القرار: اختيار المزوّد أو مسار التطوير الداخلي، وتحديد وحدات الإصدار التي تحتاج شهادات.
- الشهرين الثالث والرابع — الاختبار: الربط ببيئة الاختبار، وإصدار نماذج الفواتير والإشعارات، ومعالجة أسباب الرفض حتى الاجتياز الكامل.
- الشهر الخامس — التشغيل التجريبي: شهادة الإنتاج، ثم تشغيل موازٍ ومراقبة يومية لحالات الفواتير.
- الشهر السادس — التثبيت: تدريب الفرق، وتوثيق إجراءات الطوارئ عند انقطاع الاتصال، وضبط تنبيهات تجديد الشهادات.
الجزء الأطول عادةً ليس البرمجة، بل تنظيف البيانات. ابدأ به من اليوم الأول.
أخطاء شائعة عند الربط
- معاملة الفواتير المبسّطة كقياسية أو العكس — يؤدي إلى استخدام المسار الخاطئ ورفض الفواتير.
- بيانات ناقصة للمشتري في الفواتير القياسية — وعلى رأسها الرقم الضريبي.
- فروق التقريب بين مجموع البنود والإجماليات الضريبية.
- تجاهل الردود — الفاتورة المقبولة مع ملاحظات (Warnings) إشارة إلى خلل يجب تصحيحه قبل أن يتحوّل إلى رفض.
- نسيان تجديد شهادة الإنتاج — انتهاء الصلاحية يوقف الإرسال فجأة.
- الاعتماد على ملفات PDF فقط دون توليد XML مهيكل.
أسئلة شائعة
هل تُلغي المرحلة الثانية متطلبات المرحلة الأولى؟
لا. متطلبات المرحلة الأولى تبقى قائمة، وتُبنى فوقها متطلبات الربط والتكامل.
ماذا لو انقطع الإنترنت في نقطة البيع؟
الفواتير المبسّطة تُصدر وتُسلَّم للعميل، وتُرسل للهيئة عند عودة الاتصال ضمن المهلة المقررة. أما الفواتير القياسية فتعتمد على المشاركة، لذا يجب أن يوفّر نظامك آلية طوابير ومعالجة واضحة.
هل أحتاج إلى شهادة لكل نقطة بيع؟
نعم، الإعداد يتم على مستوى وحدة الإصدار لا المنشأة. كل جهاز أو نظام يصدر فواتير يحتاج إلى إعداده والحصول على اعتماده الخاص، مع خطة واضحة لإدارة الشهادات وتجديدها.
هل أستطيع الاستمرار بإصدار فواتير PDF فقط؟
لا. المستند المقروء للعميل جيد، لكن المطلوب نظاميًا هو ملف XML مهيكل ومختوم. يمكن تسليم الفاتورة القياسية بصيغة PDF/A-3 مع تضمين XML بداخلها.
ماذا يحدث إذا رُفضت الفاتورة؟
الفاتورة المرفوضة لا تُعدّ صادرة نظاميًا. يجب تصحيح سبب الرفض — وغالبًا يكون خطأ في البيانات أو التصنيف الضريبي — ثم إعادة الإرسال. لذلك من الضروري أن يعرض نظامك حالة كل فاتورة وسبب الرفض بوضوح بدل إخفائه في سجلات تقنية.
هل ضريبة القيمة المضافة مرتبطة بهذا؟
الفوترة الإلكترونية آلية إصدار وتحقق، أما نسبة الضريبة وقواعد التسجيل والإقرارات فموضوع منفصل ومكمّل — راجع: VAT in Saudi Arabia: Rates, Registration and Returns.
أين أجد التفاصيل التقنية الكاملة بالإنجليزية؟
في النسخة الإنجليزية من هذا الدليل: ZATCA Phase 2: Integration Requirements & Rollout Waves. وللمواصفات الرسمية الملزِمة، ارجع دائمًا إلى وثائق الهيئة المنشورة على zatca.gov.sa، فهي المرجع الوحيد عند أي اختلاف.
ابدأ الاستعداد قبل أن يصل الإشعار
المنشآت التي مرّت بالمرحلة الثانية بسلاسة تشترك في أمر واحد: بدأت مبكرًا وبنت بياناتها بشكل منظّم من الأساس. الفوترة الإلكترونية في جوهرها ليست مشكلة مستندات، بل مشكلة بيانات — ومن يضبط بياناته يضبط امتثاله.
مع Facturi تصدر فواتيرك من نظام واحد منظّم البيانات، بواجهة عربية كاملة ودعم لعدة لغات وعملات، وسجل فواتير مرتّب وقابل للتصدير يسهّل عليك المراجعة والامتثال في أي سوق تعمل فيه. جرّب Facturi مجانًا وابدأ بترتيب فواتيرك اليوم، لا في الأسبوع الذي يسبق موعد ربطك.