الامتثال10 min read

الفاتورة الإلكترونية في زاتكا المرحلة ٢ والتوقيع الإلكتروني: أين يلتقي الإطاران فعلاً

فريق سهل ساين|

تعيش فرق المالية السعودية تحت التزامات الفاتورة الإلكترونية في المرحلة ٢ من زاتكا منذ ٢٠٢٣، ويظهر التباس متكرّر في كل تنفيذ تقريباً: يُعامَل الختم التشفيري لفواتير زاتكا كما لو كان نفس الشيء كتوقيع إلكتروني بموجب نظام التعاملات الإلكترونية السعودي (ETL). ليسا كذلك. هما كائنان تشفيريان مختلفان، تنظّمهما جهتان مختلفتان، ويخدمان أغراضاً قانونية مختلفة — والخلط بينهما يخلق فجوات امتثال حقيقية في كلا الاتجاهين. الإطاران يلتقيان بالفعل، لكن في نقاط تشغيلية محدّدة تحتاج فرق المشتريات والضرائب والقانون إلى فهمها معاً. هذا هو كيف تتشابك الأنظمة فعلاً، وأين تتداخل، وما الذي يتغيّر للعقود التي تجلس فوق كل فاتورة.

ديسمبر ٢٠٢١ / يناير ٢٠٢٣

المرحلة ١ من الفاتورة الإلكترونية في زاتكا (مرحلة التوليد، ديسمبر ٢٠٢١) والمرحلة ٢ (مرحلة التكامل، يناير ٢٠٢٣) — قدّمت المرحلة ٢ تنسيق الفاتورة XML المُهيكَل، الختم التشفيري، رموز QR، والتكامل اللحظي مع منصة فاتورة (FATOORA) في زاتكا

زاتكا — هيئة الزكاة والضريبة والجمارك

UBL 2.1 + CSID

حزمة المرحلة ٢ التقنية: تنسيق فاتورة UBL 2.1 XML، معرّف الختم التشفيري (CSID) صادر لكل دافع ضريبة، XML موقَّع بـ ECDSA/RSA، رمز QR مُرمَّز بـ TLV، تكامل API لحظي لفواتير B2B و B2G

المواصفات التقنية للفاتورة الإلكترونية في زاتكا، ٢٠٢٣

~١٠ موجات

من إدراج دافعي الضرائب في تكامل المرحلة ٢ في زاتكا منذ ٢٠٢٣ — مُحجَّمة تدريجياً من أكبر الشركات المسجَّلة لضريبة القيمة المضافة إلى الشركات الصغيرة والمتوسطة. لا تزال أصغر فئات دافعي الضرائب يجري إدراجها على مراحل

إعلانات موجات زاتكا، ٢٠٢٣–٢٠٢٦

التمييز الأساسي: ختم مقابل توقيع

الختم التشفيري لزاتكا والتوقيع الإلكتروني بموجب ETL السعودي يبدوان متشابهين على المستوى التقني — كلاهما يتضمّن عمليات تشفيرية على مستند رقمي — لكنهما كائنان مختلفان قانونياً وتشغيلياً. التمييز يهمّ لأن الخلط بينهما يخلق فجوات امتثال في كلا الاتجاهين: افتراض أن ختم زاتكا يستوفي التزامات التوقيع في ETL (لا يستوفيها)، أو افتراض أن التوقيع الإلكتروني بموجب ETL يستوفي التزامات الفوترة في زاتكا (لا يستوفيها).

الختم التشفيري لزاتكا مقابل التوقيع الإلكتروني في ETL السعودي — التمييزات التقنية والقانونية التي تهمّ تشغيلياً.

JurisdictionLawCross-border transfer ruleIntensity
الأساس القانونيختم زاتكاصادر بموجب اللائحة التنفيذية لضريبة القيمة المضافة + التنظيم التقني للفاتورة الإلكترونية في زاتكا. أداة سلامة ضريبية، لا أداة عقد.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 والتزامات الفوترة في المرحلة ٢ من زاتكا:

Step ١

MSA أو عقد بيع موقّع بموجب ETL السعودي

يُنفّذ المشتري والمورّد الاتفاقية الرئيسية أو عقد البيع عبر توقيع إلكتروني ممتثل لـ ETL (AES كافية لمعظم الاتفاقيات التجارية). العقد الموقَّع يُرسي التسعير، المعالجة الضريبية، شروط الدفع، والعلاقة القانونية التي تأذن بالفوترة.

Step ٢

تُسلَّم السلع أو الخدمات؛ تُحفَّز الفاتورة

يُحفّز التسليم (أو أداء الخدمة، أو تحقيق المعلم) توليد الفاتورة وفق شروط العقد الموقَّع. محتوى العقد يقود محتوى الفاتورة — بنود البنود، التسعير، فئة الضريبة.

Step ٣

تُولَّد الفاتورة بتنسيق UBL 2.1 في زاتكا

ينتج نظام الفوترة الفاتورة بتنسيق XML المُهيكَل الذي تفرضه زاتكا. تحمل الفاتورة رقم تسجيل ضريبة القيمة المضافة للمورّد، تفاصيل المشتري (B2B)، بنود البنود، تفصيل الضريبة، والإجمالي — جميعها في بنية XML المُحدّدة.

Step ٤

يُطبَّق الختم التشفيري باستخدام CSID الخاص بالمورّد

حلّ الفوترة الإلكترونية للمورّد يطبّق الختم التشفيري باستخدام CSID الصادر من زاتكا أثناء إدراج المرحلة ٢. الختم يربط محتوى الفاتورة تشفيرياً بهوية المورّد.

Step ٥

التكامل اللحظي مع منصة فاتورة في زاتكا

لفواتير B2B و B2G، تُنقَل XML المختومة إلى منصة فاتورة في زاتكا بشكل لحظي عبر واجهة برمجة التطبيقات التكاملية. تُقرّ زاتكا؛ الفاتورة عندئذٍ صالحة للإصدار للمشتري. يُولَّد رمز QR مُرمَّز بـ TLV ويُطبَع على الفاتورة المرئية.

ما الذي يتغيّر للعقد الأعلى

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

ما تجبر المرحلة ٢ إدارة العقود الأعلى على القيام به

  • التقاط البيانات ذات الصلة بالفاتورة هيكلياً عند التوقيع

    العقود التي تقود الفوترة الآلية تحتاج التقاط بيانات مُهيكَل عند التوقيع — أرقام تسجيل ضريبة القيمة المضافة لكلا الطرفين، التسعير المتفق عليه لكل SKU/خدمة، فئات الضريبة المنطبقة، شروط الدفع. العقود التي تقتصر على PDF بنصّ تسعير حرّ هي الآن عنق زجاجة تشغيلي.

  • ربط العقد الموقَّع بهوية موقّع محدّد

    AES (أو QES للمستندات المطلوبة لها QES) بموجب ETL السعودي — يجب تحديد موقّع العقد تشفيرياً حتى يتمكّن سجل التدقيق من تتبّع أي بند فاتورة عودةً إلى بند العقد الذي أذن به، وإلى الشخص الذي وقّع ذلك العقد.

  • الاحتفاظ بالعقود الموقَّعة إلى جانب الفواتير المختومة

    قد يطلب تدقيق زاتكا ليس فقط الفواتير المختومة بل العقد الذي يأذن بها. العقود الموقَّعة يجب الاحتفاظ بها في نفس نظام الأرشفة كالفواتير المختومة، مع مراجع متبادلة بينها.

  • التعامل مع التعديلات والملاحق كمستندات موقَّعة

    تعديلات السعر في منتصف العقد، تغييرات النطاق، والملاحق جميعها تحتاج إلى التوقيع بموجب ETL بنفس صرامة العقد الأصلي — لأنها تغيّر الأساس للفواتير اللاحقة والتدقيق يحتاج إلى متابعة تلك السلسلة.

  • مواءمة تدفقات بيانات PDPL لكل من التوقيع والفوترة

    كل من توقيع العقد وعملية إصدار الفاتورة يعالجان بيانات شخصية (معرّفات الموقِّع، تفاصيل الاتصال، أحياناً معلومات المشتري الفردية لـ B2C). PDPL السعودي (مرسوم ملكي م/١٩ لعام ١٤٤٣هـ) ينطبق على كلا التدفقين؛ مشاركة امتثال PDPL تغطّي آليات حماية البيانات بالتفصيل.

ممتثل مقابل مهمل — كيف يبدو الفرق في الممارسة

Recommended

موقف عقد + فاتورة متكامل

كيف تبدو عملية B2B سعودية بالإطارين متوائمين.

  • عقود موقَّعة عبر AES بموجب ETL السعودي؛ هوية الموقّع مرتبطة تشفيرياً بالاتفاقية
  • بيانات التسعير/الضريبة/الدفع المُهيكَلة مُلتَقَطة عند التوقيع، تتغذّى مباشرةً في نظام الفوترة
  • فاتورة مُولَّدة بتنسيق UBL 2.1 في زاتكا مع ختم تشفيري مرتكز على CSID؛ تكامل لحظي مع فاتورة
  • المراجع المتبادلة بين العقود الموقَّعة والفواتير المختومة محفوظة في أرشيف موحَّد
  • التعديلات والملاحق موقَّعة بنفس صرامة ETL كالعقد الأصلي
  • معالجة بيانات ممتثلة لـ PDPL عبر كل من تدفقات التوقيع والفوترة؛ استضافة داخل المنطقة
  • يستطيع التدقيق تتبّع أي بند فاتورة عودةً إلى بند العقد والموقّع الذي أذن به
Alternative

فواتير مختومة، عقود مهملة

نمط التنفيذ الأكثر شيوعاً للمرحلة ٢ — الفوترة مُحلّت، العقود مُتروكة وراء.

  • فواتير مختومة بشكل مثالي ومتكاملة مع فاتورة
  • العقود الأساسية لا تزال مطبوعة، موقّعة باليد، ممسوحة ضوئياً، مؤرشفة في مواقع متفرّقة
  • لا تدفق بيانات مُهيكَل من العقود إلى الفواتير؛ فريق المالية يترجم الشروط يدوياً كل دورة
  • تعديلات العقد مُتعامَل معها بالبريد الإلكتروني؛ الفواتير تُصدَر تحت أساس تعاقدي غير واضح
  • يستطيع التدقيق التحقّق من سلامة الفاتورة لكنه لا يستطيع ربط الفواتير عودةً إلى العقود الموقَّعة بشكل موثوق
  • تعرّض PDPL على جانب العقد لأن منصات التوقيع تستضيف خارج المنطقة
  • نزاعات ضريبة القيمة المضافة أصعب للدفاع لأن الأساس التعاقدي للمعالجة الضريبية في ملف ورقي في مكان ما

الخلاصة

حلّت المرحلة ٢ من زاتكا الفوترة. لم تحلّ العقود. لفِرق B2B السعودية، يتطلّب الموقف الامتثالي المتكامل كليهما — التوقيع الإلكتروني الممتثل لـ ETL للعقود التي تقود الفوترة، والختم التشفيري الممتثل لزاتكا للفواتير نفسها. الإطاران متمايزان تقنياً وقانونياً لكنهما غير قابلين للفصل تشغيلياً. معاملتهما كتدفق عمل امتثال متكامل واحد (بدلاً من مشروعين متوازيين) هي ما يميّز المؤسسات التي تجتاز تدقيقات زاتكا بنظافة عن تلك العالقة في دورات المعالجة.

إطاران، تدفق عمل واحد

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

أنماط تكامل عملاء سهل ساين السعوديين، ٢٠٢٦

قراءات ذات صلة

المصادر

زاتكازاتكا المرحلة ٢فاتورةالفاتورة الإلكترونية السعوديةمنصة فاتورةالختم التشفيريCSIDPKI السعوديضريبة القيمة المضافةالسعوديةالمملكة العربية السعوديةالرياضالخليجالشرق الأوسطMENAنظام التعاملات الإلكترونية السعوديAESPDPLامتثال الفاتورة الإلكترونية

مستعد لتجربة سهل ساين؟

ابدأ تجربتك المجانية لمدة 14 يوماً. لا حاجة لبطاقة ائتمان.

جرّب مجاناً

مقالات ذات صلة

مطوّر9 min read

واجهة API سهل ساين: ادمج توقيع المستندات المتوافق مع الخليج في منتجك

REST API لفِرق SaaS والتقنية المالية التي تحتاج توقيعات ملزمة قانونياً داخل منتجها الخاص بدون تصدير البيانات خارج الخليج. نقاط النهاية، نموذج المصادقة، سطح Webhooks، ورياضيات التسعير.

Read
أدلة8 min read

التوقيع الإلكتروني للموارد البشرية: أتمتة تعيين الموظفين في قطر

فريق موارد بشرية يوظّف ٥٠ شخصاً سنوياً يوقّع ~٢٥٠ مستند تعيين. تدفق عمل رقمي يحوّل خمس ساعات من التعامل الورقي لكل موظف إلى عشر دقائق. القوالب، الإرسال الجماعي، الموافقات المتسلسلة، وسجلات التدقيق المتوافقة مع ECTL — الدليل العملي.

Read
قانوني13 min read

التوقيع الإلكتروني في QFC وADGM وDIFC

المناطق المالية الحرة الثلاث الكبرى في الخليج — مركز قطر للمال (QFC)، سوق أبوظبي العالمي (ADGM)، ومركز دبي المالي العالمي (DIFC) — تُشغّل أُطرها القانونية الخاصة المستندة إلى القانون العام، منفصلة عن أنظمة القانون المدني الفيدرالية المحيطة بها. هذا يمتد إلى قانون التوقيع الإلكتروني: لكل منطقة حرة قانون أو لائحة خاصة تحكم متى يكون التوقيع الإلكتروني صالحاً، وما شروط الموثوقية المطبَّقة، وكيف يتفاعل مع الإطار الفيدرالي المحيط. الشرح الكامل لفرق القانون والامتثال والمشتريات.

Read