إرسال الفاتورة (Invoice Submission) عبر API

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

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

قبل أن تبدأ، تأكّد أنك أنهيت مرحلة الإصدار وحصلت على معرّف إنتاج (Production CSID) لجهازك. إن كنت ما زلت في بيئة الاختبار، راجع تكامل API مع منصة فاتورة الذي يشرح الانتقال من الامتثال إلى الإنتاج، ثم عُد إلى هنا لبناء مسار الإرسال الفعلي.

ما الذي تجهّزه قبل أول إرسال؟

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

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

تحقّق كذلك من بيئة العمل. ابدأ دائمًا في بيئة الاختبار بمعرّف الامتثال (Compliance CSID)، وأرسل فواتير تجريبية حتى تثبت أن مسارك يبني المستند ويوقّعه ويرمّزه ويحسب تجزئته بشكل صحيح. لا تنتقل إلى الإنتاج إلا بعد أن ينجح المسار كاملًا في الاختبار. الانتقال من الامتثال إلى الإنتاج خطوة لها قواعدها، مشروحة في تكامل API مع منصة فاتورة.

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

الصورة الكبيرة: سبع خطوات بين بيانات الفاتورة والنتيجة

إرسال فاتورة واحدة ليس طلب HTTP منفردًا، بل سلسلة تحويلات على المستند نفسه. تبدأ ببيانات أعمال بسيطة (بائع، مشترٍ، بنود، ضريبة)، وتنتهي بمستند موقّع رقميًا ومُصادَق عليه من الهيئة. بينهما تمرّ الفاتورة بخمسة تحويلات تقنية قبل أن تغادر خادمك، ثم تحويلين بعد عودتها.

الترتيب ليس اختياريًا. توقيع المستند يجب أن يأتي بعد اكتمال بنائه، لأن أي تعديل لاحق على الـ XML يُبطل التوقيع. وحساب قيمة التجزئة يعتمد على المحتوى النهائي الموقّع. لذلك نتعامل مع الخطوات كخطّ إنتاج: مخرَج كل خطوة هو مدخَل التالية.

مخطط مسار الإرسال الكامل

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

الخطوة الأولى: بناء مستند الفاتورة بصيغة UBL 2.1

كل فاتورة تُرسَل إلى منصة فاتورة هي مستند XML يتبع معيار UBL 2.1 (Universal Business Language). هذا المعيار يحدّد أسماء الوسوم وترتيبها وأنواع بياناتها. لا تُرسَل الفاتورة كـ JSON ولا كنص حر، بل كمستند XML منظَّم تتعرّف عليه الهيئة حقلًا حقلًا.

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

هناك عنصران تقنيان لا غنى عنهما داخل المستند حتى قبل التوقيع. الأول هو المعرّف الفريد (UUID) الذي تولّده أنت لكل فاتورة ولا يتكرّر أبدًا. الثاني هو عدّاد الفاتورة (ICV) الذي يتزايد بمقدار واحد لكل فاتورة على نفس الجهاز، ويحفظ ترتيب السلسلة. تفاصيل توليد هذين العنصرين وقيودهما الدقيقة مشروحة في دليل نقاط نهاية API لمنصة فاتورة.

نوع الفاتورة يحدّد المسار لاحقًا

أثناء بناء المستند، تكتب نوع الفاتورة في وسم نوع المستند. هذا الحقل ليس تفصيلًا شكليًا، لأنه يحدّد لاحقًا أي مسار تسلكه الفاتورة. الفاتورة الضريبية (B2B) بين منشأتين تسلك مسار المصادقة. والفاتورة الضريبية المبسّطة (B2C) للمستهلك النهائي تسلك مسار الإبلاغ. اكتب النوع الصحيح من البداية، لأن إرسال فاتورة إلى المسار الخطأ يعيدها برمز خطأ.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ProfileID>reporting:1.0</cbc:ProfileID>
  <cbc:ID>INV-2026-000123</cbc:ID>
  <cbc:UUID>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID>
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  <cbc:IssueTime>11:40:30</cbc:IssueTime>
  <cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>
  <!-- بيانات البائع والمشتري والبنود والإجماليات -->
</Invoice>

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

الخطوة الثانية: التوقيع بمعرّف الختم المشفّر (CSID)

بعد اكتمال المستند، توقّعه رقميًا. التوقيع هو ما يحوّل ملف XML عاديًا إلى فاتورة إلكترونية معتمدة. تستخدم في التوقيع معرّف الختم المشفّر للإنتاج (Production CSID)، وهو شهادة PKI أصدرتها لك الهيئة لجهازك تحديدًا في مرحلة الإصدار.

انتبه إلى التسمية: المعرّف هو CSID اختصارًا لـ Cryptographic Stamp Identifier، وليس أي ترتيب آخر للحروف. لكل جهاز إصدار معرّف إنتاج مستقل، فإن كنت تشغّل عدة نقاط بيع أو عدة خوادم، لكلٍّ منها شهادته الخاصة، ويجب أن توقّع كل فاتورة بشهادة الجهاز الذي أصدرها فعليًا.

ماذا يضيف التوقيع إلى المستند؟

عملية التوقيع تُدرج كتلة توقيع داخل المستند نفسه، تحوي الختم المشفّر للبائع وبصمة الشهادة. كما تُحقن قيمة تجزئة الفاتورة، ورمز الاستجابة السريعة (QR) المبني على بيانات الفاتورة والتوقيع. هذه العناصر تُضاف في مواضع محدّدة من شجرة UBL، وأي إزاحة في موضعها تكسر تحقّق الهيئة.

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

الخطوة الثالثة: ترميز المستند بـ Base64

منصة فاتورة لا تستقبل مستند الـ XML كما هو في جسم الطلب. بل تستقبله مُرمَّزًا بـ Base64 داخل حقل نصي. السبب بسيط: جسم الطلب نفسه يُرسَل بصيغة JSON، ومستند XML الخام يحوي رموزًا تكسر بنية JSON. لذا نرمّز المستند الموقّع كاملًا إلى سلسلة Base64 واحدة، ونضعها في حقل invoice داخل جسم JSON.

هذا الفصل بين الغلاف والمحتوى مقصود. JSON هو غلاف النقل الذي يفهمه خادم الهيئة. وXML المُرمَّز بداخله هو المستند الضريبي الرسمي. الهيئة تفكّ الترميز عندها، وتعيد بناء المستند الأصلي بدقّة، ثم تتحقّق من توقيعه. أي خطأ في الترميز يصل كمستند تالف.

{
  "invoiceHash": "QYZ8tF...=",
  "uuid": "3cf5ee18-ee25-44ea-a444-2c37ba7f28be",
  "invoice": "PEludm9pY2UgeG1sbnM9...=="
}

لاحظ أن حقل invoice في المثال أعلاه هو المستند الموقّع كاملًا بعد ترميزه. رمّز المستند بترميز UTF-8 قبل تحويله إلى Base64، ولا تضف فواصل أسطر داخل السلسلة الناتجة. السلسلة سطر واحد متّصل.

الخطوة الرابعة: حساب قيمة التجزئة (invoiceHash)

قيمة التجزئة هي بصمة رقمية للمستند، تُحسب بخوارزمية تجزئة على المحتوى الموقّع، ثم تُرمَّز هي الأخرى بـ Base64. الهيئة تستخدمها للتحقّق من أن المستند الذي وصلها هو نفسه الذي وقّعته، دون تغيير حرف واحد في الطريق.

القيمة تُحسب على المستند بعد التوقيع لا قبله، وعلى المحتوى المعياري (Canonical) للـ XML وفق القواعد التي تحدّدها المواصفة. هذا الترتيب جوهري: لو حسبت التجزئة قبل التوقيع، ستختلف عن القيمة التي تحسبها الهيئة، فترفض الفاتورة لعدم تطابق التجزئة.

التجزئة تربط الفواتير في سلسلة

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

الخطوة الخامسة: اختيار المسار، المصادقة أم الإبلاغ

الآن صار لديك مستند موقّع ومرمّز وقيمة تجزئة. الخطوة قبل الإرسال هي اختيار وجهة الطلب. وهنا يظهر الفارق الجوهري بين مسارين تتعامل معهما الهيئة بشكل مختلف تمامًا.

مسار المصادقة (Clearance) خاص بالفاتورة الضريبية بين المنشآت (B2B). في هذا المسار، ترسل الفاتورة إلى الهيئة قبل أن تسلّمها للمشتري. الهيئة تصادق عليها بختمها الخاص، وتعيد إليك نسخة مُصادَقًا عليها. هذه النسخة العائدة، وليست التي أرسلتها، هي ما تسلّمه للمشتري. أي أن المصادقة لحظية وتسبق التسليم.

مسار الإبلاغ (Reporting) خاص بالفاتورة الضريبية المبسّطة للمستهلك (B2C). هنا تسلّم الفاتورة للمشتري فورًا عند البيع، ثم تبلّغ الهيئة بها خلال أربع وعشرين ساعة. الهيئة لا تصادق عليها مسبقًا، بل تستقبل إشعارًا بها للأرشفة والمطابقة. أي أن التسليم يسبق الإبلاغ.

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

الخطوة السادسة: إرسال الطلب (POST)

أنت الآن جاهز للإرسال. الطلب من نوع POST، وجسمه JSON يحوي الحقول الثلاثة: قيمة التجزئة، والمعرّف الفريد، والمستند المرمّز بـ Base64. أما الترويسات فتحمل بيانات المصادقة على الطلب نفسه (لا الختم المشفّر للفاتورة)، وهي مبنية على معرّف الإنتاج وسرّه المرتبط به.

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

اضبط مهلة الاتصال ولا تكرّر بلا داعٍ

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

الخطوة السابعة: تحليل الاستجابة وتخزين النتيجة

عودة الرد لا تعني انتهاء العملية، بل بدايتها من جانب التخزين. أول ما تقرؤه هو رمز الحالة. نجاح كامل يعني أن الهيئة قبلت الفاتورة. نجاح مع تحذيرات يعني أنها قُبِلت لكن مع ملاحظات يجب أن تسجّلها وتعالجها مستقبلًا. أما الرفض فيعني أنها لم تُقبَل، ولا يجوز اعتبارها فاتورة سارية.

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

ماذا تخزّن مع كل فاتورة؟

لكل فاتورة، احتفظ بحزمة كاملة قابلة للمراجعة لاحقًا: المعرّف الفريد، وعدّاد الفاتورة، وقيمة التجزئة، والمستند الموقّع، والنسخة المُصادَق عليها إن وُجدت، ورمز الحالة، وأي تحذيرات أعادتها الهيئة. هذه الحزمة هي مرجعك عند أي تدقيق، وهي ما يثبت أن الفاتورة مرّت بالمسار الصحيح ووصلت الهيئة.

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

احرص على ألّا تُرسَل الفاتورة مرّتين

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

الحماية من هذا تبدأ من طبقة التخزين. اربط كل فاتورة في نظامك بحالة واضحة: قيد الإرسال، أو أُرسِلت بنجاح، أو رُفِضت. لا تبدأ إرسالًا جديدًا لفاتورة ما زالت في حالة «قيد الإرسال» حتى يُحسَم مصيرها. وإن انقطع الرد، استعلم عن حالة الفاتورة بمعرّفها الفريد قبل أن تقرّر إعادة الإرسال. المعرّف الفريد وعدّاد الفاتورة هما أداتاك للتحقّق من أن فاتورة بعينها أُرسِلت أم لا.

جدول مرجعي سريع لخطوات الإرسال السبع

يلخّص الجدول التالي مسار الإرسال كاملًا في صف واحد لكل خطوة: ماذا تفعل فيها، وما مدخَلها، وما مخرَجها الذي يصبح مدخَل الخطوة التالية. احتفظ به مرجعًا سريعًا أثناء بناء المسار.

أخطاء شائعة في مسار الإرسال

أغلب حالات الرفض في الإرسال تعود إلى عدد محدود من الأسباب المتكرّرة. أولها التعديل على المستند بعد التوقيع، ولو بمسافة واحدة، فيُبطل التوقيع. وثانيها حساب قيمة التجزئة على نسخة غير معيارية من الـ XML، فلا تطابق ما تحسبه الهيئة.

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

القاعدة العملية: عالج كل خطأ في طبقته. خطأ بنية المستند يُصلَح في الخطوة الأولى. خطأ التوقيع في الثانية. خطأ التجزئة في الرابعة. خطأ المسار في الخامسة. لا تحاول علاج خطأ في طبقة بإعادة إرسال الطلب من طبقة أخرى.

التمييز بين الخطأ العابر والرفض المنطقي

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

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

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

كيف يساعدك قيود في إرسال الفاتورة عبر API

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

• بناء UBL 2.1 جاهزًا للإرسال: يبني قيود مستند الفاتورة بصيغة UBL المطلوبة، ويولّد المعرّف الفريد (UUID) وعدّاد الفاتورة (ICV) لكل فاتورة، فلا تصوغ XML يدويًا.
• التوقيع بمعرّف الختم المشفّر تلقائيًا: يدير قيود معرّف الإنتاج (CSID) لكل جهاز، ويوقّع كل فاتورة به، ويحقن رمز الاستجابة السريعة وكتلة التوقيع في موضعها الصحيح.
• حساب قيمة التجزئة وحفظ السلسلة: يحسب قيود قيمة التجزئة (invoiceHash) على المستند الموقّع، ويربط كل فاتورة بتجزئة سابقتها، فيحفظ سلسلة الفواتير سليمة دون انقطاع.
• توجيه المسار الصحيح آليًا: يوجّه قيود الفاتورة الضريبية إلى مسار المصادقة (Clearance) والفاتورة المبسّطة إلى مسار الإبلاغ (Reporting) حسب نوعها، فلا ترسل فاتورة إلى المسار الخطأ.
• تخزين النسخة المُصادَق عليها وتأكيد الإبلاغ: يخزّن قيود النسخة العائدة من الهيئة في مسار المصادقة، وتأكيد الإبلاغ في مسار الإبلاغ، مع رمز الحالة وأي تحذيرات، في سجلّ قابل للمراجعة عند أي تدقيق.

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

أسئلة شائعة عن إرسال الفاتورة عبر API

هل أرسل مستند XML مباشرة في جسم الطلب؟
لا. ترسل المستند الموقّع مُرمَّزًا بـ Base64 داخل حقل invoice في جسم JSON. JSON هو غلاف النقل، وXML هو المستند الضريبي بداخله.

متى أحسب قيمة التجزئة، قبل التوقيع أم بعده؟
بعد التوقيع، وعلى المحتوى المعياري للمستند. لو حسبتها قبل التوقيع، ستختلف عن قيمة الهيئة فتُرفَض الفاتورة لعدم تطابق التجزئة.

ما الفرق بين المصادقة والإبلاغ في الإرسال؟
المصادقة (Clearance) للفاتورة الضريبية B2B: ترسلها قبل تسليم المشتري، وتعيد الهيئة نسخة مُصادَقًا عليها. الإبلاغ (Reporting) للفاتورة المبسّطة B2C: تسلّمها للمشتري فورًا ثم تبلّغ الهيئة خلال 24 ساعة.

أي نسخة أسلّمها للمشتري في مسار المصادقة؟
النسخة العائدة من الهيئة بعد المصادقة، وهي التي تحمل ختم الهيئة، وليست النسخة التي أرسلتها أنت.

عدّلت بيانات الفاتورة بعد التوقيع، ماذا أفعل؟
أعد بناء المستند من الصفر ووقّعه من جديد. أي تعديل بعد التوقيع، ولو مسافة واحدة، يُبطل التوقيع ويجعل الفاتورة مرفوضة.

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