ZATCA Phase 2 in Business Central: Complete Implementation Guide (2026)

ZATCA Phase 2 e-invoicing compliance is not optional for businesses operating in Saudi Arabia — it is a legal requirement that carries penalties for non-compliance. For companies running Microsoft Dynamics 365 Business Central, implementing Phase 2 requires specific technical components that go beyond what a standard BC setup provides: XML invoice generation in UBL 2.1 format, ECDSA cryptographic signing, QR code generation, and real-time clearance via ZATCA's Fatoorah API. This guide covers exactly what is required, how each component works, and the implementation approach that has produced zero compliance failures across every BC client I have delivered it for. الامتثال لمتطلبات الفوترة الإلكترونية في زاتكا المرحلة 2 ليس اختيارياً للشركات العاملة في المملكة العربية السعودية — بل هو متطلب قانوني يترتب عليه عقوبات عند عدم الالتزام. بالنسبة للشركات التي تستخدم Microsoft Dynamics 365 Business Central، يستلزم تطبيق المرحلة 2 مكونات تقنية محددة تتجاوز ما يوفره إعداد BC القياسي: توليد فواتير XML بتنسيق UBL 2.1، والتوقيع المشفر ECDSA، وتوليد رمز QR، والتخليص الفوري عبر واجهة برمجة تطبيقات فاتورة التابعة لزاتكا. يغطي هذا الدليل ما هو مطلوب بالضبط، وكيف يعمل كل مكون، ونهج التطبيق الذي أسفر عن عدم وجود أي إخفاق في الامتثال في جميع عملاء BC الذين قدمت لهم هذا الحل.

What ZATCA Phase 2 Actually Requires

Phase 1 of ZATCA's e-invoicing mandate (effective December 2021) required businesses to generate e-invoices electronically and store them — essentially replacing manual paper invoices with digital ones. Phase 2 (integration phase) goes further: invoices must be submitted to ZATCA's platform in real time (for B2B standard invoices) or reported within a few hours (for B2C simplified invoices), and ZATCA must clear or acknowledge the invoice before it is legally valid. المرحلة الأولى من متطلبات الفوترة الإلكترونية لزاتكا (نافذة في ديسمبر 2021) ألزمت الشركات بتوليد الفواتير الإلكترونية وتخزينها — واستبدال الفواتير الورقية اليدوية بفواتير رقمية. أما المرحلة 2 (مرحلة الربط) فتذهب أبعد من ذلك: يجب تقديم الفواتير إلى منصة زاتكا في الوقت الفعلي (للفواتير القياسية B2B) أو الإبلاغ عنها في غضون ساعات قليلة (للفواتير المبسطة B2C)، ويجب على زاتكا تخليص الفاتورة أو الإقرار بها قبل أن تصبح صالحة قانونياً.

Who Is Already Required to Comply

ZATCA rolled out Phase 2 in waves based on taxpayer annual revenue. The schedule has been consistently ahead of where most businesses expected: طرحت زاتكا المرحلة 2 على شكل موجات بناءً على الإيرادات السنوية للممول الضريبي. وكان الجدول الزمني ثابتاً ومتقدماً في أحيان كثيرة عما توقعته معظم الشركات:

If your business is in KSA and subject to VAT, you need to verify your current ZATCA wave date. Do not assume you have more time — the rollout has been consistent and ZATCA enforcement is active. إذا كانت شركتك في المملكة العربية السعودية وخاضعة لضريبة القيمة المضافة، تحقق من موعد موجتك الحالية مع زاتكا. لا تفترض أن لديك وقتاً أكثر — التطبيق كان ثابتاً والتنفيذ فعّال.

Technical Architecture in Business Central

A compliant ZATCA Phase 2 implementation in BC involves five technical layers, each of which must work correctly for the overall solution to function: يتضمن تطبيق زاتكا المرحلة 2 المتوافق في BC خمس طبقات تقنية، يجب أن تعمل كل منها بشكل صحيح حتى يعمل الحل الكامل:

1. Invoice XML Generation (UBL 2.1) — BC must generate invoices in the ZATCA-mandated XML format: Universal Business Language 2.1. This is not the standard BC invoice format. The XML schema is specific — field names, namespaces, and value formats are defined by ZATCA's technical specification document (available from zatca.gov.sa). The AL extension must map BC's internal invoice data to this schema with no deviations. توليد XML للفاتورة (UBL 2.1) — يجب أن يولّد BC الفواتير بتنسيق XML المحدد من زاتكا: لغة الأعمال العالمية 2.1. هذا ليس تنسيق فاتورة BC القياسي. مخطط XML محدد — أسماء الحقول والمساحات الاسمية وصيغ القيم محددة في وثيقة المواصفات التقنية لزاتكا (متوفرة من zatca.gov.sa). يجب أن يعيّن امتداد AL بيانات الفاتورة الداخلية لـ BC إلى هذا المخطط دون أي انحرافات.
2. Cryptographic Hash Chaining — Each invoice must include a hash of the previous invoice's content, creating a chain that ZATCA can verify for tamper-evidence. This means the invoices must be sequenced and the hashing must be maintained in BC's database — losing the chain (e.g., database restore to a point in time, or incorrect sequence numbering) requires re-onboarding with ZATCA. تسلسل التشفير بالتجزئة — يجب أن تتضمن كل فاتورة تجزئة محتوى الفاتورة السابقة، مما ينشئ سلسلة يمكن لزاتكا التحقق منها لضمان عدم العبث. هذا يعني أن الفواتير يجب أن تكون متسلسلة وأن يُحتفظ بالتجزئة في قاعدة بيانات BC — فقدان السلسلة (مثلاً استعادة قاعدة البيانات إلى نقطة زمنية سابقة، أو ترقيم متسلسل غير صحيح) يستلزم إعادة التسجيل مع زاتكا.
3. ECDSA Digital Signing — Each invoice must be signed using Elliptic Curve Digital Signature Algorithm with the secp256k1 curve — the same cryptographic standard used in Bitcoin. BC does not have native ECDSA support. The AL extension must either implement the signing in AL (complex) or call an external cryptographic service. The private key used for signing is issued by ZATCA during onboarding and must be stored securely — it cannot be lost or compromised. التوقيع الرقمي ECDSA — يجب توقيع كل فاتورة باستخدام خوارزمية التوقيع الرقمي على المنحنى الإهليلجي مع منحنى secp256k1 — المعيار التشفيري ذاته المستخدم في Bitcoin. لا يتوفر دعم ECDSA الأصلي في BC. يجب أن يُطبّق امتداد AL التوقيع في AL (معقد) أو يستدعي خدمة تشفير خارجية. المفتاح الخاص المستخدم للتوقيع صادر من زاتكا أثناء التسجيل ويجب تخزينه بأمان — لا يمكن فقدانه أو اختراقه.
4. QR Code Generation — Simplified invoices (B2C) must include a QR code that encodes specific invoice fields in a defined TLV (Tag-Length-Value) binary format. The QR code must be generated in BC and printed on the invoice document. Standard BC QR code generation does not produce the ZATCA-mandated format — this is custom AL code. توليد رمز QR — يجب أن تتضمن الفواتير المبسطة (B2C) رمز QR يشفّر حقول فاتورة محددة بتنسيق TLV (Tag-Length-Value) ثنائي محدد. يجب توليد رمز QR في BC وطباعته على مستند الفاتورة. توليد رمز QR القياسي في BC لا ينتج التنسيق المطلوب من زاتكا — هذا كود AL مخصص.
5. Fatoorah API Integration — The final layer: submitting the signed, hashed, XML invoice to ZATCA's Fatoorah clearance API (for B2B) or reporting API (for B2C). The API returns a clearance stamp that must be embedded in the invoice XML before the invoice is issued to the buyer. Error handling, retry logic, and API timeout management are production-critical — a failed API call cannot block invoice posting indefinitely. تكامل واجهة Fatoorah — الطبقة الأخيرة: تقديم الفاتورة الموقّعة والمجزّأة بتنسيق XML إلى واجهة التخليص Fatoorah التابعة لزاتكا (للـ B2B) أو واجهة الإبلاغ (للـ B2C). تعيد الواجهة ختم تخليص يجب تضمينه في XML الفاتورة قبل إصدارها للمشتري. معالجة الأخطاء ومنطق إعادة المحاولة وإدارة انتهاء مهلة الواجهة أمور بالغة الأهمية — لا يمكن لاستدعاء واجهة فاشل أن يمنع ترحيل الفاتورة إلى أجل غير مسمى.

Implementation Approach: Custom AL Extension vs. AppSource Solution

There are two implementation paths for ZATCA Phase 2 in BC. Which is right depends on your specific situation: هناك مساران لتطبيق زاتكا المرحلة 2 في BC. أيهما مناسب يعتمد على وضعك المحدد:

For standard retail and trading companies with straightforward invoice flows, an AppSource solution (Wabel, Mahali, or a local KSA partner's certified solution) is often the fastest path. For companies with complex invoice scenarios — multi-company structures, custom approval workflows, high-volume automated posting, or non-standard invoice types — a custom AL extension gives the necessary control. بالنسبة للشركات التجارية والتجزئة القياسية ذات تدفقات الفواتير المباشرة، غالباً ما يكون حل AppSource (Wabel أو Mahali أو حل معتمد من شريك محلي في المملكة العربية السعودية) هو الأسرع. أما الشركات ذات سيناريوهات الفواتير المعقدة — الهياكل متعددة الشركات، وسير عمل الموافقات المخصصة، والترحيل الآلي عالي الحجم، أو أنواع الفواتير غير القياسية — فإن امتداد AL المخصص يمنح التحكم الضروري.

The ZATCA Onboarding Process

Before any live invoice can be submitted to ZATCA, the implementation must go through ZATCA's onboarding process. This is a multi-step technical procedure that cannot be rushed — plan for 2–4 weeks from start to ZATCA sandbox approval: قبل أن يمكن تقديم أي فاتورة مباشرة إلى زاتكا، يجب أن يمر التطبيق بعملية التسجيل. هذا إجراء تقني متعدد الخطوات لا يمكن التعجيل به — خطط لمدة 2-4 أسابيع من البداية حتى الموافقة على البيئة الاختبارية لزاتكا:

Common Implementation Issues and How to Avoid Them

Realistic Implementation Timeline

Do not start this project 2 weeks before your ZATCA wave deadline. The sandbox testing phase alone takes 1–2 weeks, and ZATCA validation issues are common on the first submission attempt. Allow 8–10 weeks minimum from project start to go-live. لا تبدأ هذا المشروع قبل أسبوعين من موعد موجتك في زاتكا. مرحلة الاختبار في البيئة الاختبارية وحدها تستغرق 1-2 أسبوع، وأخطاء التحقق من زاتكا شائعة في محاولة التقديم الأولى. اسمح بمدة لا تقل عن 8-10 أسابيع من بدء المشروع حتى الانطلاق.

Post-Implementation: What Changes Over Time

ZATCA updates its technical specifications periodically. Schema changes, new field requirements, and API version upgrades require the BC implementation to be updated to maintain compliance. Plan for this from the start: تُحدّث زاتكا مواصفاتها التقنية بشكل دوري. تغييرات المخطط، ومتطلبات الحقول الجديدة، وترقيات إصدارات الواجهة تستلزم تحديث تطبيق BC للحفاظ على الامتثال. خطط لذلك من البداية:

• Subscribe to ZATCA's technical update notifications (available via zatca.gov.sa) اشترك في إشعارات التحديث التقني لزاتكا (متوفرة عبر zatca.gov.sa)
• Allocate annual budget for compliance maintenance — typically 1–3 weeks of development per year as ZATCA's specs evolve خصّص ميزانية سنوية لصيانة الامتثال — عادةً 1-3 أسابيع تطوير سنوياً مع تطور مواصفات زاتكا
• Test any ZATCA spec change in sandbox before pushing to production — a schema change in production that ZATCA rejects will block all invoice submission until resolved اختبر أي تغيير في مواصفات زاتكا في البيئة الاختبارية قبل نشره في الإنتاج — تغيير مخطط في الإنتاج ترفضه زاتكا سيوقف كل تقديم فواتير حتى يُحل
• Keep the private key secure and backed up separately from BC — losing it requires re-onboarding with ZATCA, which disrupts invoice operations احتفظ بالمفتاح الخاص آمناً ومنسوخاً احتياطياً بشكل مستقل عن BC — فقدانه يستلزم إعادة التسجيل مع زاتكا مما يُعطل عمليات الفوترة