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

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

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

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

لماذا يختلف الملفّان قبل وجود أي خطأ

سجل فواتير Zoho يجيب عادةً على أسئلة من هذا القبيل:

• أي فاتورة صدرت؟
• أي عميل سدّدها؟
• متى سُجّلت الدفعة؟
• ما المبلغ الإجمالي المطبّق على الفاتورة؟

ملف CSV لتسوية بوابة الدفع يجيب على أسئلة مختلفة:

• أي معاملات بطاقة أو دفع إلكتروني جرى معالجتها؟
• أيّها نجحت، وأيّها فشلت، وأيّها استُردّت أو عُكست؟
• ما الرسوم التي استُقطعت؟
• في أي تاريخ حوّلت البوابة الأموال إلى الحساب البنكي؟

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

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

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

مشكلة المرجع التي تسبّب معظم التعارضات الزائفة

اسم الملفات ليس المشكلة الحقيقية. مفاتيح المرجع هي المشكلة.

Zoho وبوابة الدفع نادراً ما تسمّيان الدفعة ذاتها بالطريقة ذاتها. قد يُظهر أحد الملفات INV-1048. وقد يُظهر آخر رقم دفعة. وثالث قد يُظهر معرّف معالج لا معنى له حتى تتتبّعه إلى دفعة العميل. إذا اخترت المفتاح الخاطئ تفشل المقارنة حتى وإن كانت جميع الدفعات موجودة.

أكثر الطرق أماناً في التعامل مع المعرّفات هو فصلها بحسب الوظيفة:

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

تسلسل أكثر موثوقية:

1. طابق على الفاتورة أو مرجع التاجر إن كان الملفان يحتويانه.
2. إن لم يكن كذلك، طابق مرجع دفعة Zoho بمرجع معاملة البوابة.
3. إن لم يُظهر أيٌّ من الملفين مرجعاً مشتركاً، استخدم المبلغ مع نافذة تاريخ ضيّقة وراجع الصفوف المتبقية يدوياً.
4. إن كان ملف البوابة ملخصاً للدفعات فحسب، أوقف محاولة إنشاء مطابقات على مستوى المعاملات من هذا الملف. جمّع بدلاً من ذلك.

هذه النقطة الأخيرة توفّر ساعات. ملخص التسوية لا يفتقر إلى أرقام الفواتير صدفةً. إنه تقرير مختلف.

قارن الملفات بترتيب حركة الأموال

لا تحتاج نموذجاً معقداً لمطابقة هذه التصاديرات. تحتاج أن يبقى ترتيب الأحداث سليماً.

الخطوة 1: افصل نشاط الفوترة عن نشاط التسوية

صفّ تصدير Zoho على الدفعات التي تهمّ في الفترة. تبحث عن فواتير بدفعات مسجّلة، لا كل فاتورة صدرت.

احتفظ بهذه الأعمدة إن توفّرت في تصديرك:

ثم افحص ملف CSV للبوابة وحدّد ما هو فعليّاً. لا تفترض من اسم الملف. إن احتوى كل سطر على إجمالي ورسوم وصافٍ وحالة وتاريخ معالجة ومعرّف معاملة، فهو على مستوى المعاملات. إن احتوى على سطر واحد لكل دفعة مع تاريخ صرف وإجمالي صافٍ، فهو على مستوى التسوية.

هذا التمييز يحدّد كيف تبدو المقارنة الصحيحة.

الخطوة 2: طابق الدفعات الناجحة قبل لمس الرسوم

أنظف مرحلة أولى هي الدفعات الإجمالية الناجحة فحسب.

تجاهل الرسوم الآن. تجاهل التجميع في دفعات الآن. اطرح سؤالاً واحداً محدداً أولاً:

أي دفعات مسجّلة في Zoho تظهر كمعاملات ناجحة في البوابة؟

يجب أن تبدو أولى جداول المطابقة هكذا:

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

• دفعة مسجّلة يدوياً في Zoho
• معاملة بوابة فاشلة أو معلّقة
• دفعة جُمّعت عبر قناة مختلفة
• إدخال مكرّر أو خاطئ في تصدير Zoho

لا تخلط هذه المشكلات بأسئلة تواريخ التسوية. إنها استثناءات مختلفة.

الخطوة 3: طابق الإجمالي بالصافي بتجميع الصفوف الصحيحة

بمجرد تطابق الدفعات الناجحة، انتقل إلى أثر التسوية.

هنا كثيراً ما يضيع المشغّلون خيط التتبع. يحاولون مقارنة دفعة إجمالية في Zoho بقيمة 400.00 بسطر تسوية في البوابة بقيمة 388.40 ويعلنونها تعارضاً في المبلغ. ليست تعارضاً في المبلغ إن كانت الـ 11.60 المفقودة هي رسوم البوابة.

جمّع صفوف البوابة حسب دفعة التسوية أو تاريخ الصرف واحسب:

ابنِ إجمالي الدفعة بـ SUMIFS قبل المقارنة على المستوى الصحيح:

=SUMIFS(Gateway!$C:$C,Gateway!$E:$E,B2,Gateway!$D:$D,"Successful")

العمود C هو المبلغ الإجمالي، والعمود E هو تاريخ الصرف أو معرّف الدفعة، وB2 هو التاريخ في صف الملخص، والعمود D هو حالة المعاملة. إن كان الملف يستخدم معرّف الصرف بدلاً من التاريخ، استبدل معيار التاريخ بعمود معرّف الصرف وقيمته.

قارن الآن على المستوى الصحيح:

• سجل فواتير Zoho يفسّر الدفعات الإجمالية للعملاء.
• ملف CSV لتسوية البوابة يفسّر كيف تحوّلت تلك الدفعات الإجمالية إلى نقد صافٍ.

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

الخطوة 4: استخدم نوافذ تواريخ تعكس وقت التسوية

تاريخ الدفع في Zoho هو عادةً تاريخ دفع العميل. تاريخ التسوية في ملف CSV للبوابة هو حين أصدر المعالج الأموال. هذان التاريخان كثيراً ما يختلفان بيوم أو عدة أيام عمل.

ليس هذا ضوضاء. هذا هو المسار الطبيعي للعمل.

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

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

ما تعنيه الفجوات الشائعة فعلاً

معظم الاختلافات غير المفسّرة تقع ضمن قائمة قصيرة. القيمة ليست في إيجادها. القيمة في تصنيفها الصحيح كي تتوقف عن ملاحقة مشكلات وهمية.

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

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

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

سير عمل شهري عملي ينتج إجابة قابلة للدفاع عنها

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

1. أنشئ مجموعة دفعات Zoho نظيفة

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

2. أنشئ مجموعة بيانات بوابة نظيفة

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

3. طابق نشاط الدفع الإجمالي

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

4. فسّر الجسر من الإجمالي إلى الصافي

أنشئ ملخصاً قصيراً كهذا:

هذا الملخص هو ما يحوّل مقارنة مُربكة إلى مطابقة قابلة للدفاع عنها.

5. أدرج الاستثناءات الحقيقية منفصلة

لا تدفنها داخل الإجماليات. اعرضها سطراً سطراً:

عند هذه النقطة لديك إجابة ذات بنية:

• أي دفعات فواتير طوبقت
• أي بنود هي فوارق توقيت
• أي خصومات تفسّر الانتقال من الإجمالي إلى الصافي
• أي استثناءات تستلزم تصحيحاً

هذا يكفي لمراجعة نهاية الشهر أو تقرير العميل أو دعم التدقيق. جدول بيانات ملوّن بنصف صفوفه مظلّلة لا يكفي.

ما يجب أن تثبته المطابقة المكتملة

مطابقة سجلات فواتير Zoho مع ملفات CSV لتسوية البوابة يجب أن تثبت أربعة أشياء:

1. الدفعات المسجّلة في Zoho معاملات حقيقية في البوابة أو مصنّفة عمداً كطريقة دفع أخرى.
2. معاملات البوابة إما سُوّيت أو استُردّت أو أُلغيت أو لا تزال معلّقة.
3. الرسوم والخصومات تفسّر الفرق بين إجمالي دفعات الفواتير والنقد الصافي.
4. الصفوف غير المطابَقة المتبقية قليلة بما يكفي لمراجعتها فردياً وإغلاقها بإجراء محدد.

إن كانت نتيجتك غير قادرة على الإجابة عن هذه الأربعة، المطابقة لا تزال غير مكتملة.

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

متى يجب أن تغادر هذه المطابقة الشهرية جدول البيانات

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