كانت دفاترنا لا تتطابق أبداً: كيف أنقذنا ‘نظام التسوية الآلي’ من جحيم الأخطاء المالية الصامتة؟

بتذكرها زي كأنها مبارح. كانت الساعة حوالي 2 بعد نص الليل، أنا والمحاسب “أبو السعيد” قاعدين في المكتب، محاطين بكاسات قهوة فاضية وشاشات مليانة أرقام وجداول Excel. كنا بنحاول نغلق حسابات الشهر، والمصيبة اللي بتتكرر كل شهر: الأرقام مش راضية تطابق!

أبو السعيد، الزلمة الخمسيني اللي قضى عمره في الدفاتر والأرقام، كان يضرب كف بكف ويحكي بصوت كله تعب: “يا أبو عمر، مش منطق! نظامكم بحكي إنه دخلنا 100 ألف، والبنك بحكي 98 ألف، وبوابة الدفع بتحكي قصة ثالثة خالص… في 2000 طايرين بالهوا ومش عارفين وينهم!”.

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

ما هي التسوية المالية (Reconciliation) وليش هي كابوس؟

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

هلأ، على مستوى الشركات، الموضوع بصير أعقد بمليون مرة. المصادر اللي لازم نطابقها مع بعضها ممكن تكون:

• نظام الشركة الداخلي (Internal System): قاعدة البيانات اللي بتسجل كل طلبات البيع والشراء.
• بوابات الدفع الإلكتروني (Payment Gateways): مثل Stripe, PayPal وغيرها، كل وحدة الها تقاريرها وتنسيقاتها الخاصة.
• كشوفات الحسابات البنكية (Bank Statements): اللي بتظهر الإيداعات النهائية بعد ما بوابة الدفع تحوّل الفلوس.
• شركات الشحن والتوصيل (Delivery Companies): خصوصاً في التجارة الإلكترونية، عندهم تقارير عن الدفع عند الاستلام.

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

بناء نظام التسوية الآلي: من الفكرة للتنفيذ

بعد ليلة الأرقام الضائعة، اجتمعت مع الفريق وحكيتلهم: “يا جماعة، بدنا نبني سيستم يشتغل الشغل هاد عنا”. المهمة كانت واضحة: بناء نظام يسحب البيانات من كل المصادر، يوحدها، يقارنها، ويطلع لنا تقرير واضح بالأشياء المتطابقة والأشياء اللي بدها مراجعة (الاستثناءات).

الخطوة الأولى: جلب البيانات (Data Ingestion)

أول تحدي كان كيف بدنا “نشفط” البيانات من كل الأنظمة هاي بشكل أوتوماتيكي. قسمنا الشغل حسب المصدر:

• المصادر اللي بتدعم API: زي بوابات الدفع الحديثة. هاي كانت أسهل جزء. كتبنا سكربتات بسيطة (Jobs) بتشتغل كل فترة (مثلاً كل ساعة) وبتروح بتسحب كل العمليات الجديدة عن طريق الـ API.
• المصادر اللي بتعتمد على الملفات: زي البنوك وبعض الأنظمة القديمة اللي بترمي تقارير يومية على شكل ملفات CSV أو Excel على سيرفر FTP أو بتبعتها بالإيميل. هون الشغل كان أعقد شوي، بنينا “محلل ملفات” (File Parser) ذكي بيقدر يقرأ هاي الملفات ويفهم أعمدتها المختلفة ويحولها لبيانات منظمة.

نصيحة من أبو عمر: قبل ما تكتب سطر كود واحد، اقعد مع المحاسب أو المسؤول المالي. خليه يفتحلك كل تقرير من هدول ويشرحلك كل عمود شو معناه. “Transaction ID” في نظام ممكن تكون “Payment Reference” في نظام ثاني. هاي التفاصيل الصغيرة هي اللي بتعمل الفرق بين نظام ناجح ونظام فاشل.

الخطوة الثانية: توحيد البيانات (Data Standardization)

هلأ صار عنا بيانات من مصادر مختلفة، بس كل مجموعة بيانات شكلها غير عن الثانية. مستحيل نقارنهم وهم هيك. لازم نوحّد شكلهم. عملنا إشي بنسميه “نموذج المعاملة الموحّد” (Canonical Transaction Model). هو عبارة عن هيكل بيانات (Data Structure) ثابت بنصب فيه كل البيانات من كل المصادر.

مثلاً، النموذج تبعنا كان شكله هيك بلغة بايثون:

class StandardizedTransaction:
    def __init__(self,
                 unique_id: str,      # معرف فريد من المصدر
                 source: str,         # اسم المصدر (e.g., 'system', 'bank', 'stripe')
                 transaction_date: datetime, # تاريخ ووقت العملية
                 amount: Decimal,       # قيمة العملية
                 currency: str,       # عملة العملية
                 type: str,           # نوع العملية (e.g., 'sale', 'refund', 'fee')
                 original_data: dict  # البيانات الأصلية كما جاءت من المصدر
                ):
        self.unique_id = unique_id
        self.source = source
        # ... and so on

هاي الخطوة بتجبرنا نفكر بعمق في كل حقل بيانات. مثلاً، “المبلغ” (amount)، هل هو شامل الضريبة؟ هل هو بالموجب ولا بالسالب؟ توحيد هاي المفاهيم هو قلب عملية الأتمتة.

الخطوة الثالثة: محرك المطابقة (The Matching Engine)

هذا هو العقل المدبر للنظام. بعد ما كل البيانات صارت بشكل موحد، صار وقت المطابقة. محرك المطابقة تبعنا كان بمر بمراحل:

1. المطابقة المباشرة (Direct Match): أول إشي بدور عليه هو معرف فريد مشترك. مثلاً، لو “رقم الطلب” من نظامنا موجود في تقرير بوابة الدفع، هاي تعتبر “Golden Match” أو مطابقة ذهبية. بنعلم على العمليتين إنهم تطابقوا ومنشيلهم من المعادلة.
2. المطابقة التقريبية (Fuzzy Match): طيب لو ما في معرف مشترك؟ هون بصير الشغل أحلى. بنصير نحاول نطابق بناءً على عدة عوامل مع بعض:
   • هل المبلغ متطابق؟
   • هل تاريخ العملية ضمن نافذة زمنية معقولة (مثلاً +/- 12 ساعة)؟
   • هل العملة متطابقة؟
   • هل في أي جزء من وصف العملية في البنك بيشبه اسم العميل أو رقم الفاتورة؟

   بنعمل “سكور” أو علامة لكل مطابقة محتملة، وأعلى علامة هي اللي بنعتمدها.

3. مطابقة المجموعات (Batch Match): بوابات الدفع غالباً ما بتحولك فلوس كل عملية لحالها. هي بتجمع كل عمليات اليوم وبتخصم رسومها وبتحولك مبلغ واحد. هون المحرك لازم يكون ذكي كفاية عشان يفهم إنه عملية إيداع وحدة في البنك بقيمة 990 دينار هي عبارة عن مجموع 10 عمليات داخلية قيمتهم 1000 دينار، ناقص 10 دنانير رسوم.

الخطوة الرابعة: التعامل مع الاستثناءات (Exception Handling)

مهما كان نظامك ذكي، دايماً رح يضل في عمليات ما بتتطابق. هاي هي “الاستثناءات” (Exceptions)، وهي الكنز الحقيقي. هاي هي الأخطاء الصامتة اللي كنا بندور عليها.

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

• عمليات موجودة في نظامنا ومش موجودة في البنك: ممكن تكون عملية فشلت بس نظامنا سجلها ناجحة.
• عمليات موجودة في البنك ومش موجودة في نظامنا: ممكن تكون رسوم بنكية، أو إيداع غريب، أو عملية احتيال!
• عمليات موجودة في الطرفين بس المبلغ مختلف: هون المشكلة بتكون في الرسوم أو أسعار الصرف.

الواجهة كانت تسمح لأبو السعيد إنه يعمل مطابقة يدوية، أو يضيف ملاحظة، أو يصعّد المشكلة للفريق التقني بضغطة زر. الهدف ما كان أتمتة 100%، الهدف كان أتمتة 98% من الشغل، وتركيز الجهد البشري الذكي على الـ 2% اللي بتحتاج تحقيق.

النتائج: من الجحيم إلى النعيم المالي

بعد إطلاق النظام بأسبوعين، تغيرت حياة أبو السعيد. عملية إغلاق الحسابات اللي كانت تاخد منه 3-4 أيام من العمل اليدوي المرهق، صارت تاخد منه 30 دقيقة بس! صار يفتح النظام الصبح، يشوف تقرير المطابقة، يراجع الـ 5 أو 6 استثناءات اللي طالعة، ويقضي باقي يومه في التحليل المالي الحقيقي اللي بضيف قيمة للشركة، بدل ما يضل يطابق أرقام.

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

نصائح من قلب المعركة

إذا بتفكر تبني نظام زي هاد، خذ مني هاي النصائح اللي تعلمتها بالطريقة الصعبة:

• ابدأ صغير وبسيط (Start Small): لا تحاول تبني نظام يحل كل مشاكل العالم من أول يوم. اختار مصدرين بس (مثلاً نظامك الداخلي مع بوابة دفع وحدة) وابني الحل لهم. بعدين توسع شوي شوي.
• المحاسب هو صديقك الصدوق: الفريق المالي هو المستخدم النهائي، وهو اللي حافظ كل الخبايا والألاعيب. خليهم جزء من عملية التصميم والتطوير من اليوم الأول.
• البيانات هي الأهم (Data is King): جودة نظامك بتعتمد على جودة البيانات اللي بتدخل عليه. استثمر وقت في تنظيف وتوحيد البيانات، ولا تتهاون في هاي النقطة.
• سجّل كل شيء (Log Everything): نظامك لازم يسجل كل قرار مطابقة بعمله، وليش عمله. لما تطلع مشكلة، هاي السجلات هي اللي رح تنقذك وتساعدك تعرف وين الغلط.

الخلاصة: دفترك هو المراية المالية لشركتك

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

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

خلّوا مرايتكم دايماً نظيفة وواضحة. ✨