الفاتورة الإلكترونية في مصر وربطها بنظامك: دليل عملي للشركات.

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

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

ما هي الفاتورة الإلكترونية في مصر ومن الملزم بها؟

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

ويحدد القرار نفسه المتطلبات الفنية الأساسية: شهادة ختم إلكتروني للتوقيع، وتكويد الأصناف وفق نظام GS1 أو EGS، ثم إما ربط نظامك بالمنظومة وإما استخدام بوابتها إذا لم يكن لديك نظام لإصدار الفواتير. وإذا كنت تريد أتمتة ما بعد الإصدار مثل مطابقة الفواتير والتسويات، فقد شرحنا ذلك في دليلنا عن الذكاء الاصطناعي في المالية والفوترة الإلكترونية.

ما الطرق المتاحة لإصدار الفاتورة الإلكترونية من شركتك؟

يعتمد الاختيار على عدد فواتيرك الشهرية وعلى النظام الذي تصدر منه الفواتير اليوم. يلخص هذا الجدول الخيارات الشائعة:

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

ما الذي يحتاجه نظامك قبل ربطه بمنظومة الفاتورة الإلكترونية؟

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

• حساب الممول على المنظومة. تبدأ بوابة المطورين الرسمية بتسجيل ملف الممول ثم حساب المسؤول، الذي يدعو بقية الممثلين ويسجّل أنظمة ERP ونقاط البيع.
• بيانات دخول النظام. عند تسجيل نظامك تحصل على بيانات وصول إلى واجهات API تُضبط داخل النظام وتُستخدم في كل عملية دخول، فعاملها معاملة كلمات المرور الحساسة.
• شهادة الختم الإلكتروني. بحسب الوضع الحالي (نوفمبر 2026)، يجب أن يوقّع المُصدِر كل مستند رقميًا بشهادة من نوع X.509، وهذا التوقيع هو ما يثبت أن الفاتورة خرجت منك ولم تُعدَّل بعد ذلك.
• أكواد الأصناف. كل صنف أو خدمة في الفاتورة يحتاج إلى كود GS1 أو كود EGS داخلي تسجّله شركتك على المنظومة. ابدأ مبكرًا، فالأصناف الكثيرة تحتاج وقتًا للمراجعة والاعتماد.
• بيانات العملاء. رقم التسجيل الضريبي لكل عميل من الشركات وعنوانه كاملًا، وهي بيانات ناقصة في أغلب الأنظمة القديمة.
• الجداول المرجعية. أنواع الأنشطة وأنواع الضرائب ووحدات القياس والفروع والعملات، وكلها محددة في جداول الأكواد الرسمية ويجب أن يستخدمها نظامك كما هي.

كيف يعمل ربط الفاتورة الإلكترونية عبر API خطوة بخطوة؟

واجهات المنظومة من نوع REST وتتبادل البيانات بصيغة JSON، وتدعم المستندات بصيغتي JSON وXML. وتسير دورة كل فاتورة في نظام مربوط جيدًا على هذا الترتيب:

1. تسجيل الدخول والحصول على رمز الجلسة. يتصل نظامك بخدمة الهوية ويحصل على رمز وصول يستخدمه في الطلبات التالية. وبحسب الوضع الحالي (نوفمبر 2026)، توصي إرشادات الربط الرسمية بالاحتفاظ بالرمز طوال صلاحيته الافتراضية البالغة 60 دقيقة بدلًا من طلب رمز جديد مع كل عملية.
2. بناء المستند من بيانات النظام. تُجمع بيانات البائع والمشتري والأصناف والضرائب في الصيغة المطلوبة، ويراجع النظام اكتمالها قبل أي إرسال.
3. التوقيع. يُوقَّع المستند بشهادة الختم الإلكتروني الخاصة بشركتك.
4. الإرسال. يُرسَل مستند واحد أو مجموعة مستندات في طلب واحد، فتعود المنظومة برقم لهذا الإرسال.
5. انتظار النتيجة. جزء من المعالجة يتم لاحقًا لا لحظيًا. والطريقة الموصى بها أن يوفّر نظامك عنوانًا يستقبل إشعارات المنظومة بتغيّر حالة كل مستند، أما الاستعلام الدوري عن حالة الإرسال فخيار ثانٍ لأنه يزيد الحمل على نظامك.
6. تحديث السجل الداخلي. يحفظ نظامك حالة كل فاتورة ورقمها المرجعي في المنظومة بجانب الفاتورة الأصلية، حتى يرى المحاسب في شاشة واحدة ما قُبل وما رُفض ولماذا.

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

كيف تتعامل مع الإلغاء والرفض والتصحيح بعد الإرسال؟

بحسب الوضع الحالي (نوفمبر 2026)، الفاتورة المقبولة لا تُحذف ولا تُعدَّل، بل تُدار بإجراءات محددة تتيحها واجهات الفاتورة الإلكترونية:

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

عمليًا، اتفق مع فريقي المبيعات والمحاسبة على من يملك صلاحية الإلغاء، ومن يتابع الفواتير المرفوضة يوميًا، وما الإجراء المعتمد في كل حالة.

ما الأخطاء الشائعة في مشاريع ربط الفاتورة الإلكترونية؟

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

ما الذي تفحصه قبل الانتقال إلى التشغيل الفعلي؟

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

1. فاتورة عادية لعميل من الشركات بكل أنواع الضرائب التي تستخدمها فعلًا.
2. إشعار دائن وإشعار مدين مرتبطان بفاتورة سابقة.
3. فاتورة بعملة أجنبية إذا كنت تبيع بغير الجنيه المصري.
4. إلغاء فاتورة مع التأكد من وصول الإشعار إلى نظامك وتحديث حالتها.
5. فاتورة خاطئة عمدًا لتتأكد أن رسالة الخطأ تصل إلى المستخدم بلغة يفهمها.
6. انقطاع الاتصال أثناء الإرسال لتتأكد أن النظام لا يرسل الفاتورة مرتين.
7. مطابقة نهاية الشهر بين إجمالي فواتير نظامك وما تعرضه المنظومة.

كيف نتعامل في HBS مع ربط الفاتورة الإلكترونية؟

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

ومن عملنا مثال يوضح أهمية البيانات قبل الربط: في لوحة تحكم LDY CMS التي بنيناها لشركة لبيب دميان يوسف وشركاه، يصدر فريق المبيعات عروض الأسعار من كتالوج منتجات موحد، ببنود وخصومات وضريبة قيمة مضافة 14% بحسب الوضع الحالي (نوفمبر 2026) وشروط دفع وتسليم، ثم تنتقل العروض المقبولة إلى أوامر البيع، مع مصفوفة صلاحيات وسجل تدقيق كامل. هذا النوع من البيانات المنظمة، صنف واحد بكود واحد وعميل واحد بسجل واحد وكل تعديل مسجل باسم من قام به، هو الأساس الذي يحتاجه أي ربط ناجح بمنظومة الفاتورة الإلكترونية.

المعلومات القانونية والرسوم في هذا المقال بحسب الوضع في نوفمبر 2026 وقد تتغير، فراجع المصدر الرسمي قبل اتخاذ القرار.

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