الإشعارات الدائنة (Credit Notes) تقنياً

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

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

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

ما هو الإشعار الدائن ومتى يُصدَر؟

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

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

يقابل الإشعار الدائن مستند آخر معاكس في الاتجاه هو الإشعار المدين (Debit Note). الإشعار المدين يرفع قيمة فاتورة سابقة بدل أن يخفّضها، ويُستخدم حين تُضاف رسوم أو يُصحَّح مبلغ ناقص أو تُحتسب فروق سعرية لصالح البائع. الفرق بينهما في الاتجاه فقط: الإشعار الدائن يخفّض لصالح المشتري، والإشعار المدين يرفع لصالح البائع. هذا المرجع مخصّص لجانب التخفيض، أي الإشعار الدائن. أما توثيق الإشعار المدين تقنيًا فهو دليل منفصل ضمن السلسلة نفسها يشرح رمز النوع 383 ومنطق الزيادة.

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

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

قبل أن نغوص في XML، تلخّص اللوحة التالية متى تختار كل مستند، لتكون مرجعًا سريعًا عند اتخاذ القرار.

متى تُصدر إشعارًا دائنًا مقابل إشعار مدين؟

رمز نوع المستند 381 في الإشعار الدائن

يميّز نظام الفوترة الإلكترونية بين أنواع المستندات عبر حقل واحد اسمه cbc:InvoiceTypeCode. هذا الحقل يحمل رمزًا رقميًا قياسيًا مأخوذًا من قائمة UN/CEFACT المعتمدة دوليًا. الفاتورة الضريبية العادية تحمل الرمز 388، أما الإشعار الدائن فيحمل الرمز 381 دائمًا. هذا الرمز هو ما يخبر منصة فاتورة أن المستند الحالي إشعار دائن وليس فاتورة بيع، فيُعامَل في المنظومة كتخفيض لا كإيراد جديد.

لا يقف الأمر عند الرمز 381 وحده. الحقل ذاته يحمل خاصية اسمها name تتضمن سلسلة من سبعة أرقام تصف نوع المستند الفرعي وخصائصه. الرقم الأول من هذه السلسلة يفرّق بين الفاتورة الضريبية القياسية (B2B) والفاتورة المبسّطة (B2C): القيمة 01 تعني قياسية، والقيمة 02 تعني مبسّطة. بقية الأرقام أعلام (flags) تشير إلى خصائص مثل وجود بنود معفاة أو خاضعة لنسبة صفرية. الإشعار الدائن يرث نوع الفاتورة الأصلية: إشعار دائن على فاتورة B2B يبقى قياسيًا، وإشعار دائن على فاتورة مبسّطة يبقى مبسّطًا.

<cbc:InvoiceTypeCode name="0211010">381</cbc:InvoiceTypeCode>

في هذا المثال، القيمة 381 تحدّد أن المستند إشعار دائن. أما السلسلة 0211010 في خاصية name فتبدأ بالرقم 02 الذي يعني فاتورة مبسّطة (B2C)، تليها أعلام الخصائص. لو كان الإشعار على فاتورة قياسية لبدأت السلسلة بالرقم 01، فتصبح مثلًا 0111010. الجدول التالي يلخّص الرموز الأكثر استخدامًا حتى لا يختلط الأمر بينها.

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

الإشارة إلى الفاتورة الأصلية: BillingReference

أهم ما يميّز الإشعار الدائن عن الفاتورة العادية هو وجوب الإشارة إلى الفاتورة التي يصحّحها. هذه الإشارة إلزامية في كل إشعار دائن أو مدين، وغيابها سبب مباشر للرفض. تُحمَل الإشارة في كتلة اسمها cac:BillingReference، وتحتها عنصر فرعي اسمه cac:InvoiceDocumentReference يحمل رقم الفاتورة الأصلية في حقل cbc:ID.

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

<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>INV-2026-000128</cbc:ID>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

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

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

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

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

كيف يربط الإشعار الدائن نفسه بالفاتورة الأصلية؟

المعرّفات الخاصة بكل إشعار: ID وUUID وICV وPIH

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

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

<cbc:ID>CN-2026-000045</cbc:ID>
<cbc:UUID>9f1c7a3e-58d2-4b6a-9c11-7e4d2f8a6b30</cbc:UUID>
<cbc:IssueDate>2026-06-24</cbc:IssueDate>
<cbc:IssueTime>13:05:44</cbc:IssueTime>

المعرّفان التاليان يعيشان داخل كتلة الإضافات الموقّعة (UBL Extensions) لا في الترويسة المرئية، لكنهما جوهريان لسلامة التسلسل. الأول هو عدّاد الفاتورة ICV أي Invoice Counter Value، وهو رقم تسلسلي يتزايد مع كل مستند تصدره المنشأة. الإشعار الدائن يأخذ قيمة العدّاد التالية في التسلسل، تمامًا كأنه فاتورة جديدة، لأن المنظومة تعدّ كل مستند موقّع وحدة واحدة في السلسلة.

الثاني هو تجزئة المستند السابق PIH أي Previous Invoice Hash. كل مستند موقّع يحمل بصمة (hash) للمستند الذي سبقه مباشرة في تسلسل المنشأة، فتتكوّن سلسلة مترابطة لا يمكن حذف حلقة منها دون كشف. الإشعار الدائن يحمل تجزئة المستند الذي سبقه في التسلسل، سواء كان فاتورة أو إشعارًا آخر، وليس بالضرورة تجزئة الفاتورة التي يصحّحها. هذه نقطة يخلط فيها كثيرون: المرجع في BillingReference يشير إلى الفاتورة المُصحَّحة، أما PIH فيشير إلى آخر مستند موقّع زمنيًا. الجدول التالي يفصل الفرق.

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

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

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

المبالغ في الإشعار الدائن: قيم موجبة باتجاه معاكس

سؤال يتكرّر كثيرًا: هل تُكتب مبالغ الإشعار الدائن بإشارة سالبة؟ الإجابة لا. في معيار UBL الذي تعتمده المنظومة، تبقى المبالغ في الإشعار الدائن قيمًا موجبة في حقولها، مثل cbc:LineExtensionAmount وإجمالي الضريبة وإجمالي المستند. الإشارة السالبة لا تُكتب داخل الحقول. ما يحدّد الاتجاه هو رمز نوع المستند 381 نفسه، لا إشارة الأرقام.

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

<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="SAR">200.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="SAR">200.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="SAR">230.00</cbc:TaxInclusiveAmount>
  <cbc:PayableAmount currencyID="SAR">230.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

في هذا المثال، الإشعار الدائن يخفّض قيمة بمقدار 200 ريال قبل الضريبة، و30 ريالًا ضريبة قيمة مضافة بنسبة 15%، فيصبح إجمالي التخفيض 230 ريالًا. كل القيم موجبة، والرمز 381 هو ما يجعل المنظومة تعاملها كتخفيض. لاحظ أيضًا أن سبب الإشعار يُكتب عادة في حقل ملاحظة على مستوى المستند داخل cbc:Note، مثل «مرتجع بضاعة» أو «خصم تسوية»، ليبقى مسار التدقيق واضحًا.

كيف يمرّ الإشعار الدائن بالمقاصة أو الإبلاغ؟

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

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

مسار الإشعار الدائن من الإصدار حتى النفاذ

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

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

أخطاء شائعة ترفض بسببها الإشعارات الدائنة

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

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

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

كيف يساعدك قيود في إصدار الإشعارات الدائنة؟

في قيود، لا تتعامل مع XML ولا مع الرمز 381 ولا مع كتلة المرجع يدويًا. تختار الفاتورة الأصلية من قائمة فواتيرك، ثم تحدّد ما تريد تخفيضه: مرتجعًا كاملًا، أو بنودًا محدّدة، أو خصمًا بقيمة معيّنة. يبني النظام الإشعار الدائن تلقائيًا برمز النوع الصحيح، ويملأ BillingReference برقم الفاتورة التي اخترتها، ويولّد UUID وICV وPIH ضمن تسلسلك الموقّع.

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

أين يقع الإشعار الدائن من بقية سلسلة التوثيق التقني؟

الإشعار الدائن جزء من منظومة مستندات مترابطة. لفهم الشكل العام لملف الفاتورة وترتيب كتله الكبرى، ارجع إلى بنية الفاتورة الإلكترونية (Invoice Structure). ولفهم حقول الترويسة التي يشاركها الإشعار مع الفاتورة، راجع ترويسة الفاتورة (Invoice Header). أما الشهادة التي يُوقَّع بها كل مستند فموضّحة في دليل شهادة CSID، والمعيار الذي تُبنى عليه الحقول في دليل معيار UBL 2.1.

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

خلاصة مرجعية للإشعار الدائن

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

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