معيار UBL 2.1 في الفاتورة الإلكترونية

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

في هذا الدليل التقني نركّز على معيار UBL 2.1 وحده: ما هو، ولماذا اختارته الهيئة، وكيف تُبنى مساحات الأسماء (namespaces) فيه، وما أنواع المستندات التي يعرّفها، وكيف وسّعت الهيئة هذا المعيار في ملف التهيئة الخاص بها (ZATCA Profile). أما الشرح العام لسبب اعتماد XML أساساً فتجده في مقال فاتورة XML: التنسيق التقني للفاتورة الإلكترونية، والتحقق من صحة الملف عبر مخطط XSD نتناوله في مخطط الفاتورة (Invoice Schema) والتحقق منه.

ما هو معيار UBL 2.1؟

الاختصار UBL يعني Universal Business Language، أي «لغة الأعمال الموحّدة». وهو معيار دولي مفتوح يعرّف مجموعة من المستندات التجارية الإلكترونية بصيغة XML: الفاتورة، أمر الشراء، إشعار الشحن، الإشعار الدائن، الإشعار المدين، وغيرها. تشرف على تطويره منظمة OASIS، وهي هيئة معايير عالمية غير ربحية.

صدرت النسخة 2.1 من المعيار عام 2013، واعتُمدت لاحقاً معياراً دولياً تحت الرقم ISO/IEC 19845:2015. هذا الاعتماد الدولي مهم: فهو يعني أن الفاتورة المبنية على UBL 2.1 ليست تنسيقاً محلياً سعودياً، بل مستند يفهمه أي نظام في العالم يدعم المعيار نفسه.

تكمن قوة UBL في أنه يفصل بين البنية والمعنى. البنية هي شجرة العناصر في ملف XML، والمعنى هو ما يمثّله كل عنصر في الواقع التجاري. هذا الفصل يسمح لأنظمة مختلفة بتبادل الفواتير دون اتفاق مسبق على شكل الملف، لأن المعيار نفسه يحدد كل شيء.

الفرق بين UBL و«الفاتورة الإلكترونية»

كثيرون يخلطون بين المصطلحين. الفاتورة الإلكترونية مفهوم تنظيمي: فاتورة تُصدر وتُحفظ بصيغة رقمية منظمة بدلاً من الورق. أما UBL 2.1 فهو القالب التقني المحدد الذي اختارته الهيئة لكتابة هذه الفاتورة. بعبارة أخرى: الفاتورة الإلكترونية هي «ماذا»، وUBL 2.1 هو «كيف». يمكنك قراءة المتطلبات التنظيمية الكاملة في صفحة الفاتورة الإلكترونية من قيود.

لماذا اختارت الهيئة معيار UBL 2.1؟

لم يكن اختيار UBL 2.1 عشوائياً. وقفت خلفه أسباب تقنية وتنظيمية واضحة:

• معيار دولي معتمد: اعتماده تحت ISO/IEC 19845 يمنحه شرعية عالمية، ويسهّل التعامل مع الشركات الأجنبية والأنظمة العالمية.
• التوافق مع المعيار الأوروبي: يتوافق UBL 2.1 مع المعيار الدلالي الأوروبي EN 16931، الذي يُعدّ المرجع الأبرز للفوترة الإلكترونية حول العالم. اختيار قاعدة معروفة يقلّل المخاطر ويوفّر مكتبات جاهزة.
• قابلية التوسعة: يسمح UBL بإضافة عناصر امتداد (extensions) دون كسر البنية الأساسية. استغلت الهيئة هذه الخاصية لإضافة التوقيع الرقمي وبيانات الختم، كما سنرى لاحقاً.
• وفرة الأدوات: توجد مكتبات برمجية ناضجة لمعالجة UBL في معظم لغات البرمجة، ما يقلّل تكلفة بناء الأنظمة المتوافقة.
• الفصل بين البيانات والعرض: ملف UBL يحمل البيانات فقط، بينما يُترك العرض المرئي لطبقة منفصلة. هذا يسهّل التدقيق الآلي والمعالجة.

اعتمدت الهيئة معيار UBL 2.1 أساساً لتنسيق الفاتورة الضريبية والفاتورة الضريبية المبسّطة في المرحلة الثانية من الفوترة الإلكترونية، التي بدأت في الأول من يناير 2023 على شكل موجات بحسب حجم إيرادات المنشأة.

بنية ملف UBL 2.1: العنصر الجذر

كل ملف فاتورة UBL يبدأ بعنصر جذر واحد اسمه Invoice. هذا العنصر يحمل تعريفات مساحات الأسماء (namespaces) التي تربط الملف بمعيار UBL وبالعناصر المشتركة. إليك الهيكل العام للعنصر الجذر كما يظهر في فاتورة متوافقة مع متطلبات الهيئة:

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
         xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2">
    <!-- محتوى الفاتورة هنا -->
</Invoice>

لاحظ أن العنصر الجذر يعرّف أربع مساحات أسماء. كل واحدة منها لها دور محدد، وهذا ما يقودنا إلى أهم مفهوم في المعيار.

مساحات الأسماء: cbc و cac و ext

مساحة الأسماء (namespace) في XML هي طريقة لتجميع العناصر تحت مظلة واحدة وتجنّب التعارض في التسميات. في UBL 2.1 ثلاث مساحات أسماء أساسية يحتاجها كل مطوّر:

cbc: المكوّنات الأساسية المشتركة

البادئة cbc تعني Common Basic Components. هذه العناصر تحمل قيمة مفردة: نص أو رقم أو تاريخ أو معرّف. لا تحتوي على عناصر فرعية. هي الأوراق في شجرة الفاتورة.

<cbc:ID>INV-2026-00145</cbc:ID>
<cbc:IssueDate>2026-06-23</cbc:IssueDate>
<cbc:IssueTime>14:30:00</cbc:IssueTime>
<cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>

في هذا المثال: cbc:ID هو رقم الفاتورة، وcbc:IssueDate تاريخ الإصدار، وcbc:DocumentCurrencyCode عملة المستند (الريال السعودي SAR). القيمة 388 في InvoiceTypeCode هي الرمز الدولي للفاتورة الضريبية وفق قائمة UN/CEFACT.

cac: المكوّنات المجمّعة المشتركة

البادئة cac تعني Common Aggregate Components. هذه العناصر تجميعية: تحتوي على عناصر فرعية أخرى، سواء كانت cbc أو cac. هي الفروع في شجرة الفاتورة. مثال: بيانات البائع تُجمَّع داخل عنصر cac واحد:

<cac:AccountingSupplierParty>
    <cac:Party>
        <cac:PartyIdentification>
            <cbc:ID schemeID="CRN">1010101010</cbc:ID>
        </cac:PartyIdentification>
        <cac:PostalAddress>
            <cbc:StreetName>طريق الملك فهد</cbc:StreetName>
            <cbc:CityName>الرياض</cbc:CityName>
            <cbc:PostalZone>12345</cbc:PostalZone>
            <cac:Country>
                <cbc:IdentificationCode>SA</cbc:IdentificationCode>
            </cac:Country>
        </cac:PostalAddress>
        <cac:PartyTaxScheme>
            <cbc:CompanyID>300000000000003</cbc:CompanyID>
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:PartyTaxScheme>
    </cac:Party>
</cac:AccountingSupplierParty>

لاحظ التداخل: cac:AccountingSupplierParty يحتوي على cac:Party، الذي يحتوي بدوره على عناصر cac أخرى (العنوان، النظام الضريبي) وعناصر cbc طرفية (الاسم، المدينة، الرقم الضريبي المكوّن من 15 خانة). هذا التداخل المنظّم هو جوهر بنية UBL.

ext: عناصر الامتداد

البادئة ext تعني Common Extension Components. هذه المساحة مخصصة لإضافة بيانات خارج البنية القياسية دون كسر المعيار. هنا تضع الهيئة بيانات التوقيع الرقمي والختم. نعود إليها بالتفصيل في قسم ملف التهيئة السعودي.

علاقة UBL 2.1 بالمعيار الأوروبي EN 16931

لا يُفهم اختيار الهيئة لمعيار UBL 2.1 بمعزل عن المعيار الأوروبي EN 16931. هذا المعيار الأوروبي ليس صيغة ملف، بل نموذج دلالي: قائمة بالحقول التي يجب أن تحتويها أي فاتورة إلكترونية، ومعانيها، وقواعد الأعمال التي تحكم العلاقات بينها. مثال على قاعدة عمل: «إجمالي الفاتورة قبل الضريبة يجب أن يساوي مجموع مبالغ البنود».

المعيار الأوروبي يحدد «ماذا» يجب أن تحمل الفاتورة من معلومات، لكنه لا يفرض «كيف» تُكتب هذه المعلومات في ملف. لتطبيقه عملياً، يحتاج إلى صيغة تقنية (syntax) تحمل هذه الحقول. اعتمد الاتحاد الأوروبي صيغتين رسميتين: UBL 2.1 وصيغة UN/CEFACT CII. اختارت الهيئة السعودية الصيغة الأولى.

هذا الترابط يفسّر لماذا تجد أسماء عناصر UBL تتطابق مفهومياً مع حقول المعيار الأوروبي. كل حقل دلالي في EN 16931 له ما يقابله في بنية UBL. الفائدة العملية: الشركات التي بنت أنظمة للسوق الأوروبية تجد أن جزءاً كبيراً من عملها قابل لإعادة الاستخدام في السوق السعودية، مع تعديل طبقة ملف التهيئة فقط.

قواعد ترتيب العناصر (Cardinality والتسلسل)

من أكثر ما يفاجئ المطوّرين الجدد في UBL أن ترتيب العناصر إلزامي. المخطط يحدد لكل عنصر cac التسلسل الدقيق لعناصره الفرعية، وعدد مرات تكرار كل عنصر (cardinality): إلزامي مرة واحدة، أو اختياري، أو متكرر. وضع عنصر cbc:IssueDate بعد cbc:InvoiceTypeCode بدلاً من قبله يكفي لإفشال التحقق، حتى لو كانت كل القيم صحيحة.

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

أنواع المستندات التي يعرّفها UBL 2.1

يعرّف UBL 2.1 أكثر من 65 نوع مستند تجاري، لكن في سياق الفوترة الإلكترونية السعودية تهمّنا ثلاثة أنواع رئيسية، يُحدَّد كل منها عبر العنصر cbc:InvoiceTypeCode:

الإشعار الدائن والإشعار المدين يستخدمان عنصراً جذراً مختلفاً عن الفاتورة: CreditNote وDebitNote على الترتيب، لكن البنية الداخلية والمنطق نفسه. كل إشعار يجب أن يشير إلى الفاتورة الأصلية التي يعدّلها عبر عنصر cac:BillingReference.

تمييز الفاتورة القياسية من المبسّطة

إضافة إلى الرمز الدولي، تفرّق الهيئة بين الفاتورة القياسية (B2B) والمبسّطة (B2C) عبر السمة name داخل InvoiceTypeCode. هذه السمة تحمل سلسلة من سبع خانات، كل خانة تحمل معنى:

<cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>
<!-- الخانة الأولى/الثانية: 01 = فاتورة قياسية، 02 = فاتورة مبسّطة -->

هذا التمييز جوهري لأنه يحدد المسار التقني: الفاتورة القياسية تتطلب الاعتماد المسبق (clearance) من منصة فاتورة قبل تسليمها للمشتري، بينما الفاتورة المبسّطة تُصدر فوراً للمشتري وتُبلَّغ (reporting) للهيئة خلال 24 ساعة.

كيف وسّعت الهيئة معيار UBL 2.1؟

المعيار القياسي وحده لا يكفي لمتطلبات المرحلة الثانية. أضافت الهيئة طبقة من المتطلبات الإلزامية فوق UBL 2.1، تُعرف بملف التهيئة (ZATCA Profile). هذه الطبقة لا تكسر المعيار، بل تستخدم آليات التوسعة المدمجة فيه.

UUID: المعرّف الفريد للفاتورة

تتطلب الهيئة معرّفاً فريداً عالمياً لكل فاتورة، إضافة إلى رقم الفاتورة المتسلسل. يُضاف هذا المعرّف عبر عنصر cbc:UUID:

<cbc:ProfileID>reporting:1.0</cbc:ProfileID>
<cbc:ID>INV-2026-00145</cbc:ID>
<cbc:UUID>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID>

العنصر cbc:ID هو الرقم التسلسلي الذي يراه المستخدم، بينما cbc:UUID معرّف تقني فريد لا يتكرر بين أي فاتورتين على مستوى النظام كله.

تجزئة الفاتورة السابقة (Previous Invoice Hash)

لضمان سلامة سلسلة الفواتير ومنع التلاعب، تربط الهيئة كل فاتورة بالفاتورة التي سبقتها عبر بصمة تجزئة (hash). تُحفظ هذه البصمة داخل عنصر امتداد، وتُحسب بخوارزمية SHA-256. هذا يبني سلسلة مترابطة: لو حُذفت فاتورة أو عُدّلت، تنكسر السلسلة ويظهر التلاعب فوراً.

التوقيع الرقمي والختم

أهم إضافة سعودية هي التوقيع الرقمي. توقّع الفاتورة باستخدام شهادة PKI صادرة عن الهيئة، تُعرف بمعرّف ختم الامتثال (CSID). يُوضع التوقيع داخل عنصر ext:UBLExtensions في رأس الملف:

<ext:UBLExtensions>
    <ext:UBLExtension>
        <ext:ExtensionURI>urn:oasis:names:specification:ubl:dsig:enveloped:xades</ext:ExtensionURI>
        <ext:ExtensionContent>
            <sig:UBLDocumentSignatures
                 xmlns:sig="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2">
                <!-- بيانات التوقيع الرقمي والختم هنا -->
            </sig:UBLDocumentSignatures>
        </ext:ExtensionContent>
    </ext:UBLExtension>
</ext:UBLExtensions>

هذا الاستخدام لعنصر ext:UBLExtensions هو مثال نموذجي على فلسفة UBL: بدل تعديل بنية المعيار، تضع الهيئة بياناتها الخاصة في الحاوية المخصصة للتوسعة. أي نظام يقرأ الملف ويفهم UBL سيتعرّف على البنية الأساسية، حتى لو لم يفهم محتوى الامتداد.

رمز الاستجابة السريعة (QR)

تتطلب الهيئة رمز QR مضمّناً في الفاتورة، يحمل بيانات أساسية مرمّزة بصيغة TLV (Tag-Length-Value) ومحوّلة إلى Base64. يُحفظ داخل عنصر cac:AdditionalDocumentReference باسم QR:

<cac:AdditionalDocumentReference>
    <cbc:ID>QR</cbc:ID>
    <cac:Attachment>
        <cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain">
            AQ1Rb3lvZCBDb21wYW55Ag8zMDAwMDAwMDAwMDAwMDM...
        </cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
</cac:AdditionalDocumentReference>

بنية بنود الفاتورة في UBL 2.1

كل سطر في الفاتورة يُمثَّل بعنصر cac:InvoiceLine. هذا العنصر يجمّع الكمية والسعر والوصف والضريبة لبند واحد:

<cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="PCE">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="SAR">1000.00</cbc:LineExtensionAmount>
    <cac:TaxTotal>
        <cbc:TaxAmount currencyID="SAR">150.00</cbc:TaxAmount>
        <cbc:RoundingAmount currencyID="SAR">1150.00</cbc:RoundingAmount>
    </cac:TaxTotal>
    <cac:Item>
        <cbc:Name>خدمة استشارية محاسبية</cbc:Name>
        <cac:ClassifiedTaxCategory>
            <cbc:ID>S</cbc:ID>
            <cbc:Percent>15.00</cbc:Percent>
            <cac:TaxScheme>
                <cbc:ID>VAT</cbc:ID>
            </cac:TaxScheme>
        </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
        <cbc:PriceAmount currencyID="SAR">100.00</cbc:PriceAmount>
    </cac:Price>
</cac:InvoiceLine>

في هذا المثال: بند واحد بكمية 10 وحدات، سعر الوحدة 100 ريال سعودي، مجموع البند قبل الضريبة 1,000 ريال، ضريبة القيمة المضافة 15% أي 150 ريال، والإجمالي مع الضريبة 1,150 ريال. الرمز S في ClassifiedTaxCategory يعني خاضع للنسبة القياسية (Standard rated).

إجماليات الفاتورة

تُجمَّع الإجماليات في عنصر cac:LegalMonetaryTotal، الذي يحمل المبلغ قبل الضريبة وبعدها والمبلغ المستحق:

<cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="SAR">1000.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="SAR">1000.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="SAR">1150.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="SAR">1150.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

الضريبة الإجمالية تُجمَّع بشكل منفصل في عنصر cac:TaxTotal على مستوى الفاتورة كاملة، مع تفصيل لكل فئة ضريبية في cac:TaxSubtotal. هذا الفصل يسمح للهيئة بالتحقق الآلي من صحة حسابات الضريبة قبل اعتماد الفاتورة.

لماذا يهمّ المطوّر فهم UBL 2.1؟

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

كذلك يساعد فهم UBL على قراءة رسائل الخطأ التي تعيدها المنصة. حين تشير الرسالة إلى عنصر cac:TaxTotal أو cbc:TaxAmount، يعرف المطوّر الملمّ بالمعيار أين يبحث فوراً. أما من يتعامل مع XML كصندوق أسود فيضيع وقتاً طويلاً في التخمين.

أخطاء شائعة في بنية UBL تؤدي إلى رفض الفاتورة

من واقع التكامل مع منصة فاتورة، تتكرر مجموعة من الأخطاء التي يجدر بالمطوّر الانتباه لها:

• مساحة أسماء ناقصة أو خاطئة: نسيان تعريف بادئة cac أو cbc في العنصر الجذر يجعل المنصة عاجزة عن تفسير العناصر، فترفض الملف كاملاً.
• ترتيب عناصر خاطئ: وضع عنصر فرعي في غير موضعه داخل عنصر cac يخالف تسلسل المخطط ويُفشل التحقق.
• نوع بيانات غير مطابق: كتابة تاريخ بصيغة غير ISO، أو رقم بفاصلة عربية بدل النقطة العشرية، أو ترك خانة إلزامية فارغة.
• عدم اتساق الحسابات: إذا لم يساوِ cbc:TaxInclusiveAmount مجموع المبلغ قبل الضريبة والضريبة، تكسر قاعدة عمل وتُرفض الفاتورة.
• سلسلة تجزئة مكسورة: إرسال بصمة تجزئة لا تطابق الفاتورة السابقة فعلياً يكسر سلسلة الترابط.

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

الفصل بين البيانات والعرض المرئي

نقطة مهمة كثيراً ما تُغفل: ملف UBL يحمل البيانات فقط، ولا يحدد شكل الفاتورة المرئي الذي يراه العميل. تحويل الملف إلى صورة قابلة للقراءة البشرية (مثل ملف PDF/A-3) يتم في طبقة منفصلة عبر ورقة تحويل (XSLT) أو قالب عرض. هذا الفصل ميزة لا قيد: نظام واحد يولّد البيانات، وأنظمة متعددة قد تعرضها بأشكال مختلفة، دون المساس بالبيانات المعتمدة من الهيئة.

لذلك حين تستلم فاتورة بصيغة PDF/A-3، فهي في الحقيقة حاوية تحمل ملف UBL XML مضمّناً داخلها. الصورة المرئية للعين، والملف الرقمي للأنظمة والتحقق. هذه الازدواجية تخدم الطرفين: المحاسب يقرأ الفاتورة بسهولة، والنظام يتحقق منها آلياً.

كيف يساعدك قيود في التعامل مع UBL 2.1؟

الخبر الجيد لأصحاب المنشآت: لا تحتاج لكتابة سطر واحد من XML بنفسك. يتولى برنامج الفاتورة الإلكترونية من قيود توليد ملف UBL 2.1 كاملاً وراء الكواليس، متوافقاً مع متطلبات المرحلة الثانية:

• يولّد ملف UBL 2.1 لكل فاتورة آلياً وفق ملف التهيئة المعتمد من الهيئة، بمساحات الأسماء وترتيب العناصر الصحيح.
• يضيف المعرّف الفريد (UUID) وبصمة التجزئة وسلسلة الفواتير المترابطة دون أي تدخل يدوي.
• يدير شهادة الختم (CSID) ويوقّع كل فاتورة رقمياً قبل إرسالها.
• ينفّذ الاعتماد المسبق للفواتير القياسية (B2B) مع منصة فاتورة، والتبليغ خلال 24 ساعة للفواتير المبسّطة (B2C).
• يولّد رمز QR بصيغة TLV المطلوبة ويضمّنه في الفاتورة.

بهذا يحصل المحاسب على فاتورة متوافقة تقنياً بنقرة واحدة، بينما يبقى تعقيد UBL 2.1 مخفياً داخل النظام. الدعم الفني متاح 24 ساعة طوال أيام الأسبوع لمساعدتك على ربط منشأتك بمنصة فاتورة.

دورة حياة فاتورة UBL من التوليد إلى الاعتماد

لفهم موقع UBL 2.1 في المنظومة كاملة، تتبّع رحلة فاتورة قياسية (B2B) من لحظة إنشائها حتى وصولها للمشتري:

• يولّد النظام المحاسبي ملف UBL 2.1 بكل عناصره الإلزامية: بيانات البائع والمشتري والبنود والضريبة والإجماليات.
• يحسب النظام بصمة التجزئة ويربط الفاتورة بسابقتها في السلسلة المترابطة.
• يوقّع النظام الفاتورة رقمياً بشهادة الختم (CSID) ويضع التوقيع داخل عنصر الامتداد.
• يرسل النظام الملف الموقّع إلى منصة فاتورة طلباً للاعتماد المسبق.
• تتحقق المنصة من بنية الملف ومن قواعد الأعمال ومن صحة التوقيع، ثم تعتمد الفاتورة وتعيد ختمها (Cryptographic Stamp).
• يسلّم النظام الفاتورة المعتمدة للمشتري، وتصبح وثيقة ضريبية سارية.

أما الفاتورة المبسّطة (B2C) فتسلك مساراً أخف: يصدرها النظام للعميل فوراً، ثم يبلّغ بها منصة فاتورة خلال 24 ساعة. الفرق ينبع من طبيعة المعاملة: فاتورة المستهلك تحتاج سرعة عند نقطة البيع، بينما فاتورة المنشآت تحتمل خطوة الاعتماد المسبق. في الحالتين يبقى ملف UBL 2.1 هو الوعاء التقني الموحّد الذي يحمل البيانات.

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

UBL 2.1 ضمن سلسلة التوثيق التقني

يقع معيار UBL 2.1 في قلب البنية التقنية للفاتورة الإلكترونية، لكنه ليس القطعة الوحيدة. لاستكمال الصورة:

• لفهم سبب اختيار XML أساساً وكيف يُقرأ ويُعالج، راجع فاتورة XML: التنسيق التقني للفاتورة الإلكترونية.
• للتحقق من صحة بنية الملف عبر مخطط XSD وقواعد الأعمال، راجع مخطط الفاتورة (Invoice Schema) والتحقق منه.
• لمراجعة المتطلبات التنظيمية الكاملة لضريبة القيمة المضافة المرتبطة بالفوترة، راجع صفحة ضريبة القيمة المضافة.
• لنظرة شاملة على مسارات التعلّم حول الفوترة الإلكترونية، تصفّح قسم الفوترة الإلكترونية في مركز التعلّم.

الأسئلة الشائعة

ما الفرق بين UBL 2.0 و UBL 2.1؟

النسخة 2.1 أوسع وأكثر نضجاً: أضافت أنواع مستندات جديدة وعناصر إضافية، واعتُمدت معياراً دولياً تحت ISO/IEC 19845:2015. الهيئة تعتمد النسخة 2.1 حصراً في متطلبات الفوترة الإلكترونية، فلا تستخدم النسخة الأقدم.

هل يجب أن أكتب ملف UBL يدوياً لكل فاتورة؟

لا. أي نظام محاسبي متوافق مع المرحلة الثانية، مثل قيود، يولّد الملف آلياً. كتابة XML يدوياً غير عملية وعرضة للأخطاء التي تؤدي إلى رفض الفاتورة من منصة فاتورة.

ما معنى البادئتين cbc و cac في عناصر الفاتورة؟

cbc تعني المكوّنات الأساسية المشتركة، وهي عناصر تحمل قيمة مفردة كالرقم أو التاريخ. cac تعني المكوّنات المجمّعة المشتركة، وهي عناصر تحتوي على عناصر فرعية أخرى. معاً تبنيان شجرة الفاتورة كاملة.

كيف يضمن معيار UBL 2.1 سلامة الفاتورة من التلاعب؟

عبر طبقة ملف التهيئة السعودي: التوقيع الرقمي داخل عنصر الامتداد، وبصمة التجزئة (SHA-256) التي تربط كل فاتورة بسابقتها في سلسلة مترابطة. أي تعديل يكسر السلسلة ويظهر فوراً عند التحقق.

هل UBL 2.1 معيار سعودي خاص؟

لا. هو معيار دولي مفتوح تشرف عليه منظمة OASIS، ومعتمد دولياً ومتوافق مع المعيار الأوروبي EN 16931. أضافت الهيئة فوقه طبقة متطلبات محلية (ZATCA Profile) دون تعديل المعيار الأساسي.

أين توضع بيانات التوقيع الرقمي داخل ملف UBL؟

داخل عنصر ext:UBLExtensions في رأس الملف. هذه الحاوية مخصصة في المعيار لإضافة بيانات خارج البنية القياسية، فيستخدمها التوقيع والختم دون كسر بنية UBL.