ملف CSV البنكي الأول لأحد العملاء يحتوي على عمودَين منفصلَين للمدين والدائن. الثاني لديه عمود واحد للمبلغ بالإشارة. الثالث يُطلق على تاريخ القيد اسم Transaction Date، والرابع يُسمّيه Value Date ويرتّب الملف بترتيب عكسي.

من هنا تبدأ التسوية الشهرية في التعثّر.

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

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

حدِّد هيكل الملف البنكي قبل البدء بالمطابقة

لا تبدأ بكتابة معادلة بحث. ابدأ بتحديد نوع ملف CSV البنكي الذي لديك.

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

كل هذه الملفات تمثّل نشاطاً بنكياً. لكنها لا يمكن مقارنتها جميعاً بالمعادلة ذاتها.

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

إن تجاوزت هذه الخطوة، قد تفشل المطابقة لأسباب لا علاقة لها بسجلات العميل. الدفعة ذاتها قد تظهر في الملفَّين، لكن أحدهما يسجّلها كـ Debit 250.00، وآخر كـ -250.00، وثالث كـ 250.00 في عمود Money Out. Excel لن يستنتج ذلك تلقائياً.

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

أنشئ عرضاً معيارياً للتسوية

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

استخدم هذه الحقول المعيارية:

هذا العرض يمنحك مكاناً واحداً لاتخاذ القرارات. كما يُبقي ملفات العملاء منفصلة — وهذا مهمّ حين يستخدم عدة عملاء البنك ذاته وتتشابه التصديرات.

مثال:

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

هنا أيضاً تبدأ جداول البيانات الرئيسية بفقدان موثوقيتها. تأخذ ملف العميل السابق كقالب للملف التالي. يصلح هذا حتى يغيّر بنك ما Credit إلى Paid In، أو يُصدّر التواريخ كـ 05/06/2026 بدلاً من 2026-06-05، أو يُضيف عموداً فارغاً قبل المبلغ. يجب أن يعتمد سير العمل على حقول مُسمَّاة وقرارات تعيين، لا على موضع العمود.

وحِّد المبالغ قبل الوثوق بالإجماليات

إشارات المبالغ من أسرع الطرق لإنشاء فارق تسوية كاذب.

ملفات CSV البنكية لا تستخدم قاعدة موحّدة. بعض البنوك تُصدّر المدفوعات الصادرة كأرقام موجبة في عمود المدين. وأخرى تُصدّرها كأرقام سالبة في عمود مبلغ واحد. وأخرى تُظهر الأموال الصادرة بقيم موجبة لأن العمود نفسه يحمل المعنى. وبعضها يتضمّن فواصل أو رموز عملة أو أقواس.

قبل مطابقة الصفوف، حوِّل كل تصدير إلى قاعدة المبلغ بالإشارة:

لملف يحتوي على عمودَي دائن ومدين منفصلَين، ادمجهما في مبلغ واحد بالإشارة:

=IF(C2<>"",VALUE(C2),-VALUE(D2))

العمود C هو عمود الدائن أو الوارد؛ والعمود D هو عمود المدين أو الصادر. VALUE تعالج المبالغ النصية. للملفات التي تستخدم الأقواس للأرقام السالبة، استخدم VALUE(SUBSTITUTE(SUBSTITUTE(A2,"(","-"),")","")) حيث A هو عمود المبلغ.

ثم تحقق من الإجماليات مقارنةً بالملف الأصلي:

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

القاعدة ذاتها تنطبق عبر العملاء. بنك يُصدّر مصاريف البطاقة كقيم موجبة قد يجاور بنكاً يُصدّرها كقيم سالبة. العرض المعياري يجعلها قابلة للمقارنة دون ادّعاء أن الملفات المصدر كانت متطابقة.

اختر التاريخ الصحيح للتسوية

أعمدة التاريخ تبدو غير مؤذية حتى نهاية الشهر.

بنك قد يُصدّر Transaction Date. وآخر قد يُصدّر Posting Date. وثالث قد يتضمّن Value Date. تصدير بطاقة ائتمان قد يُظهر Purchase Date وPosted Date. هذه ليست دائماً التاريخ ذاته.

في تسوية العميل، حدِّد أي تاريخ يتحكّم بالفترة قبل مقارنة الصفوف.

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

الخطأ هو خلط قواعد التاريخ داخل التسوية ذاتها. إن كان Client A مُصفَّى بتاريخ القيد وClient B بتاريخ المعاملة، فلا يمكن مقارنة فوارقهما. عميل قد يبدو لديه معاملات مفقودة هي في الواقع فوارق توقيت.

طبِّق قاعدة تاريخ واضحة:

1. حدِّد التاريخ المتحكّم بفترة التسوية.
2. احتفظ بحقول التاريخ الأخرى في العرض المعياري.
3. استخدم نوافذ التاريخ للمطابقة حين يختلف توقيت البنك عن النشاط المصدر.
4. صنِّف فوارق التوقيت بمعزل عن الصفوف المفقودة.

فارق التوقيت ليس معاملة مفقودة. إن ظهر المبلغ ذاته والمرجع ذاته بيوم خارج الفترة، يجب أن يُشير التقرير إلى ذلك. لا يجب تركه في مجموعة "غير مُطابَق" بلا تفسير.

أنشئ مفاتيح مطابقة تصمد مع المراجع البنكية الضعيفة

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

ابدأ بأقوى مفتاح متاح.

لمعظم ملفات CSV البنكية للعملاء، أفضل مفتاح عملي هو مفتاح مركّب:

normalized description + signed amount + date window

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

وحِّد البيانات بما يكفي لتقليل الضجيج دون إزالة التفاصيل المفيدة:

لتوحيد بيان كشف حساب بنكي في Excel، أزِل فوارق الحالة وقلِّص المسافات الزائدة:

=TRIM(SUBSTITUTE(UPPER(A2),"  "," "))

العمود A هو حقل البيان. UPPER تزيل فوارق الحالة؛ وTRIM تزيل المسافات في البداية والنهاية والمتكررة. إن كان البنك يضيف لاحقة ثابتة كرمز الفرع، أضف SUBSTITUTE متداخلاً لإزالتها أولاً: =TRIM(SUBSTITUTE(UPPER(SUBSTITUTE(A2," LONDON",""))," "," ")).

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

اعمل بطبقات، لا في مقارنة واحدة كبيرة

ملفات عدة عملاء تصعب إدارتها حين تُدمج كل الصفوف في مقارنة واحدة دفعةً واحدة.

اعمل بطبقات:

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

لنفترض أن عميلاً أرسل حسابَين من البنك ذاته:

قبل مقارنة هذه الملفات بدفتر الأستاذ للعميل، تحقق أولاً من أن عرضك المعياري يُظهر الإجماليات ذاتها:

عندها فقط قارن السجلات.

إن أظهر دفتر الأستاذ 18,400.00 في الإيداعات للحساب التشغيلي لكن -16,500.00 فقط في السحوبات، فالمشكلة لم تعد في تنسيق CSV البنكي. الملف البنكي مُحمَّل بشكل صحيح. الفارق الآن مشكلة سحب مفقود أو مُقيَّد خطأً في دفتر الأستاذ.

هذا التسلسل يمنحك إجابةً قابلة للدفاع عنها.

صنِّف الفوارق حتى يتمكن العميل من التصرف

الصف غير المُطابَق ليس نتيجةً نهائية. إنه نقطة انطلاق.

في ملفات CSV البنكية لعدة عملاء، الفوارق تحتاج إلى تسميات تشرح السبب:

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

تقرير أفضل يقول:

الإجراء التالي الآن واضح. Client A يحتاج مراجعة ثلاثة قيود في دفتر الأستاذ. Client B يحتاج حسم مرشّحي التكرار. Client C يحتاج تنظيفاً أعمق لأن عدد الفوارق أكبر ومتوزّع على عدة أنواع.

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

ما يجب أن يُثبته التقرير النهائي

تقرير التسوية المفيد لملفات CSV البنكية لعدة عملاء يجب أن يُثبت أربعة أشياء.

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

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

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

رابعاً، كل بند معلق متبقٍّ يجب أن يكون له سبب وإجراء. يجب أن يُخبر التقرير العميل بما يحتاج قيداً أو تحققاً أو تصحيحاً.

الهيكل النهائي يمكن أن يكون مختصراً:

التقرير لا يحتاج عرض كل معادلة. يحتاج أدلةً كافية لأن يتابع شخص آخر النتيجة.

سير العمل القابل للتكرار

استخدم التسلسل ذاته لكل عميل:

1. احفظ ملف CSV المصدر دون تعديل.
2. حدِّد هيكل الملف: مدين/دائن، مبلغ بالإشارة، تاريخ القيمة، تاريخ القيد، صفوف الرصيد.
3. عيِّن الملف في عرض تسوية معياري.
4. وحِّد إشارات المبالغ والبيانات.
5. اختر التاريخ المتحكّم بالفترة.
6. تحقق من عدد الصفوف والإجماليات قبل المطابقة.
7. طابق بالمراجع القوية أولاً.
8. طابق صفوف المراجع الضعيفة بمفاتيح مركّبة.
9. افصل فوارق التوقيت عن الصفوف المفقودة.
10. صنِّف الفوارق حسب السبب والإجراء.
11. أنتج تقريراً يُظهر إجماليات المصدر وقرارات التعيين والصفوف المُطابَقة والبنود المعلقة.

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

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