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

لهذا يمكنك أن ترى رسوم Stripe بتاريخ 31 مايو وسطراً بنكياً بتاريخ 1 يونيو، وكلاهما يصف الحركة المالية نفسها. الاختلاف في التواريخ ليس نقصاً في الأموال في الغالب. هو مزيج من اختلاف المنطقة الزمنية وتوقيت التحويل، فضلاً عن أن سطور معاملات Stripe ليست مكافئة لسطور كشف الحساب البنكي.

التشخيص الأول: ما نوع اختلاف التواريخ لديك؟

قبل أن تغيّر أي تنسيق في Excel، حدّد الحالة التي أمامك. الاختلاف المتشابه في المظهر قد يصدر عن أسباب مختلفة، وليس كلها مشاكل UTC خالصة.

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

أي تاريخ من Stripe تقارن فعلاً؟

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

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

لهذا يسير الترتيب الصحيح على النحو التالي:

1. طابِق الإيداع البنكي بدفعة Stripe.
2. طابِق محتوى الدفعة بمعاملات Stripe الأساسية.
3. طابِق تلك المعاملات بالطلبات أو الفواتير أو قيود دفتر الأستاذ إذا كنت بحاجة إلى إثبات على مستوى المعاملة.

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

حوِّل الطابع الزمني لـ Stripe قبل أي مقارنة

بعد أن تحدّد حقل Stripe الصحيح، حوّله وفق نفس منطق التاريخ المستخدم في الملف البنكي. لا تبدأ بالتنسيق. أولاً تحقق إذا كان Excel قد استورد القيمة كتاريخ-وقت حقيقي أم كنص.

استخدم =TYPE(A2) على الخلية التي تحتوي تاريخ Stripe.

• 1 يعني أن Excel يرى رقماً تسلسلياً لتاريخ-وقت.
• 2 يعني أن Excel يرى نصاً، وتحتاج إلى تحليله قبل أن تنجح أي مقارنة.

إذا كانت قيمة Stripe في A2 نصاً بالنمط 2026-05-01 23:47:18 UTC، أنشئ تاريخ-وقت UTC صريحاً:

=DATE(LEFT(A2,4),MID(A2,6,2),MID(A2,9,2))+TIME(MID(A2,12,2),MID(A2,15,2),MID(A2,18,2))

يعطيك ذلك الطابع الزمني UTC كقيمة تاريخ-وقت في Excel. ثم حوّله إلى التوقيت المحلي بتطبيق إزاحة الحساب. إذا كان إعداد محاسبتك UTC-4، اطرح أربع ساعات:

=DATE(LEFT(A2,4),MID(A2,6,2),MID(A2,9,2))+TIME(MID(A2,12,2),MID(A2,15,2),MID(A2,18,2))-TIME(4,0,0)

إذا كانت منطقتك الزمنية UTC+2، أضف ساعتين:

=DATE(LEFT(A2,4),MID(A2,6,2),MID(A2,9,2))+TIME(MID(A2,12,2),MID(A2,15,2),MID(A2,18,2))+TIME(2,0,0)

بعد صحة الطابع الزمني المحلي، قلّصه إلى تاريخ تقويمي إذا كان ملف CSV البنكي لا يعطيك إلا تاريخاً:

=INT(B2)

نسّق الناتج كتاريخ. أنت الآن تقارن اليوم المحلي الذي يعنيه الطابع الزمني لـ Stripe، لا يوم UTC الخام.

إذا كان تاريخ Stripe في A2 قيمة تاريخ-وقت حقيقية في Excel، لا تحلّله من جديد. طبّق الإزاحة مباشرة:

=A2-TIME(4,0,0)

الملف البنكي يحتاج العناية نفسها. إذا استورد ملف CSV البنكي 01/05/2026 كنص، حدّد ما إذا كان المصدر يستخدم dd/mm/yyyy أم mm/dd/yyyy قبل التحويل.

إذا كان البنك يستخدم dd/mm/yyyy:

=DATE(RIGHT(C2,4),MID(C2,4,2),LEFT(C2,2))

إذا كان البنك يستخدم mm/dd/yyyy:

=DATE(RIGHT(C2,4),LEFT(C2,2),MID(C2,4,2))

لا تلجأ إلى DATEVALUE حتى تعرف التنسيق الذي صدّر به البنك. قيمة مثل 01/05/2026 ليست دليلاً بذاتها. قد تعني 1 مايو أو 5 يناير، حسب نظام المصدر والإعدادات الإقليمية في Excel.

تحذير واحد يستحق اهتماماً أكثر مما تُقرّه معظم الأدلة: إزاحة ثابتة مثل -TIME(4,0,0) أو -TIME(5,0,0) تكون صحيحة فقط إذا بقي نطاق التواريخ داخل فترة توقيت صيفي واحدة. إذا تجاوز التصدير التغيير الموسمي للوقت، قد تُصحح إزاحة واحدة نصف الملف وتُخلّ بالنصف الآخر. في هذه الحالة، قسّم الملف حسب الفترة، أو استخدم تقريراً من Stripe يعرض عمود المنطقة الزمنية للحساب مسبقاً، واحتفظ بنسخة _utc للمرجعية في التدقيق فقط.

طابِق الدفعة بالبنك قبل أن تتعامل مع الرسوم الفردية

بعد تطبيع الطوابع الزمنية، القرار التالي هو مستوى المطابقة. إذا كان ملف CSV البنكي يحتوي إيداعاً صافياً واحداً وملف Stripe رسوماً فردية واسترداداً وعمولات، فلا مطابقة سطر بسطر أمامك بعد. أمامك علاقة واحد-إلى-متعدد.

يجب مطابقة السطر البنكي أولاً بتقرير دفعة Stripe. ثم تُفسّر المعاملات الموجودة في تلك الدفعة المبلغ.

لنفترض أن ملف CSV لكشف حسابك البنكي يُظهر هذا السطر:

قد يحتوي تصدير معاملات Stripe سبعة وثلاثين سطراً أُنشئت بين 2026-05-31 21:00:00 UTC و2026-06-01 03:00:00 UTC. إذا قارنت تواريخ تلك المعاملات مباشرة بالسطر البنكي بتاريخ 1 يونيو، ستستنتج أن كثيراً من السطور «بعيدة يوماً». بعضها كذلك. لكن الحقيقة الأهم أن أياً من هذه السطور لم يكن يُفترض أن يطابق السطر البنكي منفرداً. كلها تنتمي إلى مجموعة دفعة واحدة.

الإثبات الصحيح يبدو هكذا:

• تصدير الدفعة من Stripe يُظهر دفعة صافية بقيمة 4,820.25.
• الحقل في الدفعة الذي يمثّل الوصول المتوقع للبنك يتوافق مع نافذة الإضافة البنكية.
• المعاملات التفصيلية داخل تلك الدفعة تُجمع لتعطي المبلغ الصافي نفسه بعد العمولات والاسترداد والنزاعات.

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

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

الحالات الحدية التي تُبقي اختلافات وهمية بعد التحويل

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

الفلترة في نهاية الشهر

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

الإضافة في عطل نهاية الأسبوع أو الأعياد

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

استرداد ونزاعات تصل لاحقاً

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

أعمدة منطقة زمنية مختلطة

بعض تصديرات Stripe قد تُظهر نسختي نفس الحقل: المحلية و_utc. إذا بنيت المعادلات على عمود هذا الشهر والعمود الآخر الشهر المقبل، سيُنتج المصنف تناقضات تبدو أخطاء في البيانات المصدر. اختر معياراً واثبت عليه طوال التسوية.

أضرار النسخ واللصق

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

حين يصبح العمل في جدول البيانات هو المشكلة الحقيقية

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

المعيار المطلوب ليس «كل تاريخ في Stripe يساوي تاريخاً بنكياً». المعيار أن يرتبط كل إيداع بنكي بدفعة Stripe الصحيحة، وأن تُفسَّر كل دفعة بمعاملاتها الداخلية، وأن يُصنَّف كل فارق تواريخ متبقٍّ إما كتحويل منطقة زمنية أو توقيت تسوية أو استثناء حقيقي يحتاج تصحيحاً.