الفاتورة الإلكترونية في مصر (ETA): كيف تربط نظامك بمنظومة مصلحة الضرائب؟ دليل 2026

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

المشكلة نادراً ما تكون في كتابة الكود. هذه أكثر الأسباب التي رأيناها توقف مشروع ربط أو تسبب موجة رفض بعد التشغيل مباشرة.

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

قبل أن تعتمد على المنظومة في يوم عمل حقيقي، تأكد من هذه النقاط:

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

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

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

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

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

هذه الأسئلة تكشف بسرعة الفرق بين مزود بنى الربط فعلاً ومزود يَعِد به. ومعايير اختيار الشريك التقني بشكل عام — المراجع والعملية والملكية والشفافية — غطيناها بالتفصيل في دليلنا أفضل شركة برمجة في مصر.

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

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

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

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