تعيش فرق المالية السعودية تحت التزامات الفاتورة الإلكترونية في المرحلة ٢ من زاتكا منذ ٢٠٢٣، ويظهر التباس متكرّر في كل تنفيذ تقريباً: يُعامَل الختم التشفيري لفواتير زاتكا كما لو كان نفس الشيء كتوقيع إلكتروني بموجب نظام التعاملات الإلكترونية السعودي (ETL). ليسا كذلك. هما كائنان تشفيريان مختلفان، تنظّمهما جهتان مختلفتان، ويخدمان أغراضاً قانونية مختلفة — والخلط بينهما يخلق فجوات امتثال حقيقية في كلا الاتجاهين. الإطاران يلتقيان بالفعل، لكن في نقاط تشغيلية محدّدة تحتاج فرق المشتريات والضرائب والقانون إلى فهمها معاً. هذا هو كيف تتشابك الأنظمة فعلاً، وأين تتداخل، وما الذي يتغيّر للعقود التي تجلس فوق كل فاتورة.
المرحلة ١ من الفاتورة الإلكترونية في زاتكا (مرحلة التوليد، ديسمبر ٢٠٢١) والمرحلة ٢ (مرحلة التكامل، يناير ٢٠٢٣) — قدّمت المرحلة ٢ تنسيق الفاتورة XML المُهيكَل، الختم التشفيري، رموز QR، والتكامل اللحظي مع منصة فاتورة (FATOORA) في زاتكا
زاتكا — هيئة الزكاة والضريبة والجمارك
حزمة المرحلة ٢ التقنية: تنسيق فاتورة UBL 2.1 XML، معرّف الختم التشفيري (CSID) صادر لكل دافع ضريبة، XML موقَّع بـ ECDSA/RSA، رمز QR مُرمَّز بـ TLV، تكامل API لحظي لفواتير B2B و B2G
المواصفات التقنية للفاتورة الإلكترونية في زاتكا، ٢٠٢٣
من إدراج دافعي الضرائب في تكامل المرحلة ٢ في زاتكا منذ ٢٠٢٣ — مُحجَّمة تدريجياً من أكبر الشركات المسجَّلة لضريبة القيمة المضافة إلى الشركات الصغيرة والمتوسطة. لا تزال أصغر فئات دافعي الضرائب يجري إدراجها على مراحل
إعلانات موجات زاتكا، ٢٠٢٣–٢٠٢٦
التمييز الأساسي: ختم مقابل توقيع
الختم التشفيري لزاتكا والتوقيع الإلكتروني بموجب ETL السعودي يبدوان متشابهين على المستوى التقني — كلاهما يتضمّن عمليات تشفيرية على مستند رقمي — لكنهما كائنان مختلفان قانونياً وتشغيلياً. التمييز يهمّ لأن الخلط بينهما يخلق فجوات امتثال في كلا الاتجاهين: افتراض أن ختم زاتكا يستوفي التزامات التوقيع في ETL (لا يستوفيها)، أو افتراض أن التوقيع الإلكتروني بموجب ETL يستوفي التزامات الفوترة في زاتكا (لا يستوفيها).
الختم التشفيري لزاتكا مقابل التوقيع الإلكتروني في ETL السعودي — التمييزات التقنية والقانونية التي تهمّ تشغيلياً.
| Jurisdiction | Law | Cross-border transfer rule | Intensity |
|---|---|---|---|
| الأساس القانوني | ختم زاتكا | صادر بموجب اللائحة التنفيذية لضريبة القيمة المضافة + التنظيم التقني للفاتورة الإلكترونية في زاتكا. أداة سلامة ضريبية، لا أداة عقد. | Moderate |
| الأساس القانوني | توقيع ETL إلكتروني | صادر بموجب ETL السعودي (مرسوم ملكي م/١٨ لعام ١٤٢٨هـ). أداة تنفيذ عقد تحمل وزناً إثباتياً في النزاعات التجارية. | Moderate |
| ما يربطه | ختم زاتكا | يربط فاتورة XML بمعرّف الختم التشفيري (CSID) لدافع الضريبة المُصدِر. يثبت سلامة الفاتورة وأصلها لأغراض ضريبية. | Moderate |
| ما يربطه | توقيع ETL إلكتروني | يربط مستنداً موقَّعاً بموقِّع شخص طبيعي أو كيان قانوني محدّد في وقت محدّد. يثبت نية الالتزام. | Moderate |
| الجهة المُصدِرة | ختم زاتكا | CSID صادر من زاتكا عبر تدفق إدراج منصة فاتورة؛ يستخدم PKI المُدار من زاتكا. | Moderate |
| الجهة المُصدِرة | توقيع ETL إلكتروني | مواد تشفيرية مُدارة ذاتياً (AES) أو مزوّد خدمة تصديق مرخَّص من CST (QES)؛ PKI منفصل عن زاتكا. | Moderate |
| مطلوب من قِبَل | ختم زاتكا | كل دافع ضريبة مسجَّل لضريبة القيمة المضافة في نطاق المرحلة ٢ يجب أن يطبّق الختم على كل فاتورة B2B و B2G. الفشل يحمل عقوبات ضريبية. | Strict |
| مطلوب من قِبَل | توقيع ETL إلكتروني | مطلوب للمستند الموقَّع نفسه (العقد الذي تنشأ عنه الفاتورة)، لا للفاتورة. مستندات مختلفة، متطلبات مختلفة. | Moderate |
ختم زاتكا إلزامي للفاتورة. توقيع ETL هو الآلية الطبيعية للعقد الذي يولّد الفاتورة. لا يستبدل أي منهما الآخر. عقد بيع بتوقيع إلكتروني ممتثل لـ ETL لا يزال يتطلّب كل فاتورة صادرة بموجبه أن تحمل ختم زاتكا؛ فاتورة زاتكا المختومة بشكل صحيح لا تجعل الاتفاقية الأساسية بأثر رجعي عقداً موقَّعاً قانونياً.
— النقطة التي تفوّتها معظم الفرق حتى التدقيق
أين يلتقي الإطاران فعلاً
التمييز أعلاه لا يعني أن العالمين معزولان عن بعضهما البعض. هناك أربع نقاط تقاطع تشغيلية حيث يجب اتخاذ قرارات التوقيع والختم معاً، لا بشكل منفصل:
نقاط التقاطع الأربع بين التوقيع والختم
- اتفاقيات الخدمة الرئيسية التي تحدّد شروط الفاتورة
اتفاقية الخدمة الرئيسية (MSA) بين المشتري والمورّد موقّعة بموجب ETL — تُرسي الأساس القانوني، التسعير، شروط الدفع، والمعالجة الضريبية التي تُشغّلها كل فاتورة لاحقة. MSA موقّعة بشكل سيئ تقوّض الوزن القانوني لكل فاتورة صادرة بموجبها، بصرف النظر عن مدى مثالية ختم كل فاتورة.
- عقود البيع المُحفِّزة لتوليد الفواتير
عندما يُحفّز تنفيذ عقد توليد فاتورة تلقائياً (شائع في أعمال الاشتراك، الإيرادات المتكرّرة، والأعمال القائمة على المشاريع)، حدث توقيع العقد يحتاج إلى تدفق البيانات بنظافة في نظام الفوترة. عدم التوافق بين شروط العقد الموقَّعة وبنود الفاتورة المختومة هو أكثر نتائج التدقيق شيوعاً.
- البنية التحتية لإدارة PKI والشهادات
كل من ختم زاتكا والتوقيع AES/QES في ETL يعتمدان على إدارة المفاتيح التشفيرية على مستوى المؤسسة. يجب حماية المفاتيح، تدويرها، تدقيقها، واستعادتها مقابل نفس المعايير التشغيلية حتى وإن خدمت أُطراً مختلفة. معظم المؤسسات الناضجة تمركز هذا في وظيفة حوكمة PKI واحدة.
- توافق سجل التدقيق وحفظ السجلات
كلا الإطارين يتطلّب الاحتفاظ طويل الأمد بالقطع التشفيرية (الفاتورة المختومة لزاتكا، العقد الموقَّع وسجل التدقيق لـ ETL). جداول الاحتفاظ يجب أن تُصمَّم معاً — العقد الموقَّع عادةً يحتاج احتفاظاً أطول من الفواتير التي ولّدها، لأن العقد يُثبت العلاقة القانونية بينما تُثبت الفاتورة حدثاً ضريبياً محدّداً فقط.
التدفق من البداية إلى النهاية — من العقد إلى الفاتورة إلى الامتثال
هذا ما يبدو عليه التدفق المتكامل لمعاملة B2B سعودية نموذجية تخضع لكل من التزامات التوقيع في ETL والتزامات الفوترة في المرحلة ٢ من زاتكا:
MSA أو عقد بيع موقّع بموجب ETL السعودي
يُنفّذ المشتري والمورّد الاتفاقية الرئيسية أو عقد البيع عبر توقيع إلكتروني ممتثل لـ ETL (AES كافية لمعظم الاتفاقيات التجارية). العقد الموقَّع يُرسي التسعير، المعالجة الضريبية، شروط الدفع، والعلاقة القانونية التي تأذن بالفوترة.
تُسلَّم السلع أو الخدمات؛ تُحفَّز الفاتورة
يُحفّز التسليم (أو أداء الخدمة، أو تحقيق المعلم) توليد الفاتورة وفق شروط العقد الموقَّع. محتوى العقد يقود محتوى الفاتورة — بنود البنود، التسعير، فئة الضريبة.
تُولَّد الفاتورة بتنسيق UBL 2.1 في زاتكا
ينتج نظام الفوترة الفاتورة بتنسيق XML المُهيكَل الذي تفرضه زاتكا. تحمل الفاتورة رقم تسجيل ضريبة القيمة المضافة للمورّد، تفاصيل المشتري (B2B)، بنود البنود، تفصيل الضريبة، والإجمالي — جميعها في بنية XML المُحدّدة.
يُطبَّق الختم التشفيري باستخدام CSID الخاص بالمورّد
حلّ الفوترة الإلكترونية للمورّد يطبّق الختم التشفيري باستخدام CSID الصادر من زاتكا أثناء إدراج المرحلة ٢. الختم يربط محتوى الفاتورة تشفيرياً بهوية المورّد.
التكامل اللحظي مع منصة فاتورة في زاتكا
لفواتير B2B و B2G، تُنقَل XML المختومة إلى منصة فاتورة في زاتكا بشكل لحظي عبر واجهة برمجة التطبيقات التكاملية. تُقرّ زاتكا؛ الفاتورة عندئذٍ صالحة للإصدار للمشتري. يُولَّد رمز QR مُرمَّز بـ TLV ويُطبَع على الفاتورة المرئية.
ما الذي يتغيّر للعقد الأعلى
التحوّل الأهم في الامتثال الذي قدّمته المرحلة ٢ ليس تقنياً — هو الضغط التشغيلي الذي تضعه على العقود التي تجلس فوق كل فاتورة. عندما يكون توليد الفاتورة لحظياً، مُهيكَلاً، ومرتبطاً تشفيرياً، فإن العقد الذي يأذن بالفاتورة يجب أن يكون على الأقل بنفس قابلية الدفاع كالفاتورة نفسها.
ما تجبر المرحلة ٢ إدارة العقود الأعلى على القيام به
- التقاط البيانات ذات الصلة بالفاتورة هيكلياً عند التوقيع
العقود التي تقود الفوترة الآلية تحتاج التقاط بيانات مُهيكَل عند التوقيع — أرقام تسجيل ضريبة القيمة المضافة لكلا الطرفين، التسعير المتفق عليه لكل SKU/خدمة، فئات الضريبة المنطبقة، شروط الدفع. العقود التي تقتصر على PDF بنصّ تسعير حرّ هي الآن عنق زجاجة تشغيلي.
- ربط العقد الموقَّع بهوية موقّع محدّد
AES (أو QES للمستندات المطلوبة لها QES) بموجب ETL السعودي — يجب تحديد موقّع العقد تشفيرياً حتى يتمكّن سجل التدقيق من تتبّع أي بند فاتورة عودةً إلى بند العقد الذي أذن به، وإلى الشخص الذي وقّع ذلك العقد.
- الاحتفاظ بالعقود الموقَّعة إلى جانب الفواتير المختومة
قد يطلب تدقيق زاتكا ليس فقط الفواتير المختومة بل العقد الذي يأذن بها. العقود الموقَّعة يجب الاحتفاظ بها في نفس نظام الأرشفة كالفواتير المختومة، مع مراجع متبادلة بينها.
- التعامل مع التعديلات والملاحق كمستندات موقَّعة
تعديلات السعر في منتصف العقد، تغييرات النطاق، والملاحق جميعها تحتاج إلى التوقيع بموجب ETL بنفس صرامة العقد الأصلي — لأنها تغيّر الأساس للفواتير اللاحقة والتدقيق يحتاج إلى متابعة تلك السلسلة.
- مواءمة تدفقات بيانات PDPL لكل من التوقيع والفوترة
كل من توقيع العقد وعملية إصدار الفاتورة يعالجان بيانات شخصية (معرّفات الموقِّع، تفاصيل الاتصال، أحياناً معلومات المشتري الفردية لـ B2C). PDPL السعودي (مرسوم ملكي م/١٩ لعام ١٤٤٣هـ) ينطبق على كلا التدفقين؛ مشاركة امتثال PDPL تغطّي آليات حماية البيانات بالتفصيل.
ممتثل مقابل مهمل — كيف يبدو الفرق في الممارسة
موقف عقد + فاتورة متكامل
كيف تبدو عملية B2B سعودية بالإطارين متوائمين.
- عقود موقَّعة عبر AES بموجب ETL السعودي؛ هوية الموقّع مرتبطة تشفيرياً بالاتفاقية
- بيانات التسعير/الضريبة/الدفع المُهيكَلة مُلتَقَطة عند التوقيع، تتغذّى مباشرةً في نظام الفوترة
- فاتورة مُولَّدة بتنسيق UBL 2.1 في زاتكا مع ختم تشفيري مرتكز على CSID؛ تكامل لحظي مع فاتورة
- المراجع المتبادلة بين العقود الموقَّعة والفواتير المختومة محفوظة في أرشيف موحَّد
- التعديلات والملاحق موقَّعة بنفس صرامة ETL كالعقد الأصلي
- معالجة بيانات ممتثلة لـ PDPL عبر كل من تدفقات التوقيع والفوترة؛ استضافة داخل المنطقة
- يستطيع التدقيق تتبّع أي بند فاتورة عودةً إلى بند العقد والموقّع الذي أذن به
فواتير مختومة، عقود مهملة
نمط التنفيذ الأكثر شيوعاً للمرحلة ٢ — الفوترة مُحلّت، العقود مُتروكة وراء.
- فواتير مختومة بشكل مثالي ومتكاملة مع فاتورة
- العقود الأساسية لا تزال مطبوعة، موقّعة باليد، ممسوحة ضوئياً، مؤرشفة في مواقع متفرّقة
- لا تدفق بيانات مُهيكَل من العقود إلى الفواتير؛ فريق المالية يترجم الشروط يدوياً كل دورة
- تعديلات العقد مُتعامَل معها بالبريد الإلكتروني؛ الفواتير تُصدَر تحت أساس تعاقدي غير واضح
- يستطيع التدقيق التحقّق من سلامة الفاتورة لكنه لا يستطيع ربط الفواتير عودةً إلى العقود الموقَّعة بشكل موثوق
- تعرّض PDPL على جانب العقد لأن منصات التوقيع تستضيف خارج المنطقة
- نزاعات ضريبة القيمة المضافة أصعب للدفاع لأن الأساس التعاقدي للمعالجة الضريبية في ملف ورقي في مكان ما
الخلاصة
حلّت المرحلة ٢ من زاتكا الفوترة. لم تحلّ العقود. لفِرق B2B السعودية، يتطلّب الموقف الامتثالي المتكامل كليهما — التوقيع الإلكتروني الممتثل لـ ETL للعقود التي تقود الفوترة، والختم التشفيري الممتثل لزاتكا للفواتير نفسها. الإطاران متمايزان تقنياً وقانونياً لكنهما غير قابلين للفصل تشغيلياً. معاملتهما كتدفق عمل امتثال متكامل واحد (بدلاً من مشروعين متوازيين) هي ما يميّز المؤسسات التي تجتاز تدقيقات زاتكا بنظافة عن تلك العالقة في دورات المعالجة.
التوقيع الإلكتروني في ETL يغطّي العقود؛ الختم التشفيري في زاتكا يغطّي الفواتير التي تأذن بها هذه العقود. عمليات B2B السعودية الناضجة تعاملهما كتدفق عمل امتثال متكامل واحد بحوكمة PKI مشتركة، جداول احتفاظ متوائمة، وأرشيفات بمراجع متبادلة — لا كمشروعين منفصلين يديرهما فريقا الضرائب والقانون في غرفتين مختلفتين.
أنماط تكامل عملاء سهل ساين السعوديين، ٢٠٢٦
قراءات ذات صلة
- AES مقابل QES مع نفاذ: لماذا لا يحتاج معظم التوقيع التجاري السعودي إلى الفئة المؤهَّلة — حجة اختيار الفئة الخاصة بالسعودية للعقود التي تجلس فوق كل فاتورة زاتكا مختومة.
- الامتثال لـ PDPL و PDPPL في التوقيع الإلكتروني — PDPL السعودي ينطبق على كل من تدفقات بيانات التوقيع والفوترة؛ آليات التحكّم المشترك والنقل عبر الحدود تهمّ لكليهما.
- لماذا تهمّ الاستضافة الإقليمية للمستندات الحساسة — بيانات العقد وبيانات الفاتورة تحملان نفس اعتبارات الإقامة؛ قرارات الاستضافة يجب أن تغطّي كليهما.
المصادر
- زاتكا — هيئة الزكاة والضريبة والجمارك
- الفاتورة الإلكترونية (فاتورة) في زاتكا — اللوائح والمواصفات التقنية
- منصة فاتورة في زاتكا
- نظام التعاملات الإلكترونية السعودي — مرسوم ملكي رقم م/١٨ لعام ١٤٢٨هـ
- اللائحة التنفيذية لضريبة القيمة المضافة السعودية
- قانون حماية البيانات الشخصية السعودي — مرسوم ملكي م/١٩ لعام ١٤٤٣هـ
- هيئة الاتصالات والفضاء والتقنية (CST) — منظِّم PKI
- سدايا — الهيئة السعودية للبيانات والذكاء الاصطناعي