دفتر الأستاذ الفرعي لبائعي الأسواق الرقمية: الإيرادات مقابل الالتزامات المستحقة
دليل عملي لفصل النقد المستلم من العملاء، وعمولات المنصة، والتزامات البائعين المستحقة، والاحتياطي النقدي، وعمليات الصرف باستخدام قيود يومية متوازنة ونمودج بيانات عملي يغطي دورة العمل من الطلب وحتى الصرف.
الخطأ الأكثر شيوعاً في محاسبة الأسواق الرقمية (marketplace) هو معاملة المدفوعات الإجمالية للعميل باعتبارها إيراداً للمصة. فعندما يدفع العميل 100 يورو، وتستقر هذه الـ 100 يورو في حساب بوابة الدفع، يقوم أحدهم بتسجيل المبلغ كاملاً في حساب المبيعات. تتوازن الدفترية مؤقتاً، وتبدو الإيرادات ممتازة، إلى أن يأتي المراجع الخارجي ليسأل عن التزام البائع؛ فلا يجد له أثراً، والسبب ببساطة هو أن حصة البائع البالغة 90 يورو لم تُسجل أبداً كمبلغ مستحق الدفع.
العلاج هنا هيكلي وليس تجميلياً. تحتاج الأسواق الرقمية إلى نموذج دفاتر أستاذ يفصل بين خمسة مجمعات رئيسية منذ القيد الأول: النقد المحتجز للعملاء قيد التسوية، إيرادات عمولات المنصة، التزامات البائعين، الرسوم، والاحتياطيات. وتُعد مدفوعات الصرف (payouts) الحدث السادس الذي يقوم بتسوية الالتزام المستحق، وليست حدث إيراد أو مصروف بحد ذاتها. يوضح هذا الدليل القيود المتوازنة ونموذج البيانات الذي يحافظ على استقلالية هذه المجمعات.
ابدأ باستنتاج معيار الأصيل مقابل الوكيل (Principal-versus-Agent)
قبل الاهتمام بأي هيكل للحسابات، يجب على المنصة تحديد ما تقوم ببيعه بدقة. وفقاً لمعيار المحاسبة الدولي أو المعايير ذات الصلة (مثل ASC 606)، يتم تقييم ذلك لكل سلعة أو خدمة محددة، وتحدد الإجابة بناءً على ذلك ما إذا كان الإيراد يُسجل بالإجمالي أم بالصافي. قد تكون المنصة أصيلاً في تدفق معين ووكيلًا في تدفق آخر.
في عمليات بيع سلع البائعين النموذجية عبر الأسواق الرقمية، غالباً ما تكون المنصة بمثابة وكيل (agent). فهي ترتب وصول منتج البائع إلى المشتري، ولا تتحمل مخاطر المخزون، ومقابلها المادي هو عمولة فقط. يعرض دليل ديلويت حول معيار الأصيل مقابل الوكيل وفقاً لـ ASC 606 الاختبار محصوراً حول مفهوم "السيطرة": فمسؤولية الوفاء بالوعد، ومخاطر المخزون، وحرية تسعير المنتج كلها مؤشرات وليست مجرد قائمة مهام تتجاوز تقييم السيطرة الأساسي.
والسبب وراء ضرورة تضمين هذا الاستنتاج في تصميم دفتر الأستاذ (وليس فقط في مذكرة داخلية) هو أن هذا الاستنتاج يوجه كل قيد لاحق. فإذا كانت المنصة وكيلاً، فإن حصة البائع تعتبر التزاماً بمجرد اكتسابها. أما إذا كانت أصيلاً في خدمة التوصيل أو الضمان، فإن ذلك الجزء يُعد إيراداً للمنصة. احفظ هذا الاستنتاج كبيانات هيكلية:
principal_agent_role(دور الأصيل أو الوكيل)specified_good_or_service(السلعة أو الخدمة المحددة)commission_rule_id(معرف قاعدة العمولة)control_assessment_version(إصدار تقييم السيطرة)effective_from/effective_to(ساري من / ساري إلى)
يجب أن يتمكن المراجع الذي يفحص بند صافي العمولات بعد عامين من معرفة سبب عدم استخدام الإيراد الإجمالي. وكما تشير BillingPlatform حول معيار الأصيل مقابل الوكيل في ASC 606، فإن مجرد إطلاق تسمية "سوق رقمي" لا يحسم المسألة، بل تحليل السيطرة هو ما يحسمها.
حدد رصيد البائع قبل كتابة أي قاعدة قيود يومية
"رصيد البائع" ليس رقماً واحداً. فقد يكون لدى البائع رصيد إجمالي تراكمي ممتاز ولكن لا يوجد شيء متاح للصرف لأن الأموال لا تزال معلقة أو محتجزة كاحتياطي. إذا دمجت هذه الحالات معاً، فسوف تقدم تقارير مضللة حول ما يمكن للبائع سحبه وما لا يزال مستحقاً عليه من قِبل المنصة.
كحد أدنى، تتبع الحالات التالية:
- معلق (Pending): مكتسب أو محصل، ولكنه غير مؤهل للصرف بعد.
- متاح (Available): مؤهل للصرف وفقاً لقواعد المنصة.
- محجوز كاحتياطي (Reserved): مُستقطع لمواجهة المرتجعات المتوقعة، أو النزاعات، أو المبالغ المستردة (chargebacks).
- مُصرف (Paid out): مُحول أو مُرسل للتسوية النهائية.
- سالب (Negative): مبلغ مستحق على البائع، وقابل للاسترداد من العائدات المستقبلية.
- حساب وسيط (Suspense): مُستلم، ولكن لم يتم تحديد هوية البائع أو المعالجة المحاسبية له بعد.
تتبنى منصات الدفع هذا التمييز مسبقاً. فمنصة Stripe تفصل كل حساب مرتبط بين أرصدة معلقة وأرصدة متاحة وتحتفظ برصيد احتياطي على مستوى المنصة لأرصدة البائعين السالبة المحددة. وإذا كان مزود خدمة الدفع يفصل بين هذه الأرصدة، فيجب على دفتر الأستاذ فعل ذلك أيضاً، وإلا فلن تتطابق المطابقة أبداً.
دليل الحسابات والأبعاد ذات الصلة
يحافظ هيكل البدء العملي على فصل حسابات المقاصة (clearing)، والالتزامات، والإيرادات عن بعضها البعض، مع حمل بُعد البائع (seller dimension) في كل قيد مالي جوهري.
| الغرض | الحساب أو البعد | المعالجة |
|---|---|---|
| أموال معالجات الدفع بانتظار التسوية | مقاصة معالج الدفع (Payment processor clearing) | أصل مقاصة |
| دفعات معالج الدفع المودعة في البنك | البنك | أصل |
| مبالغ البائع المكتسبة وغير المدفوعة | مستحقات البائعين (Seller payables) | التزام |
| تفاصيل مستوى البائع | بُعد seller_id |
تفاصيل التزام، وليس إيراداً |
| عمولة المنصة | إيراد العمولات | إيراد |
| ضريبة القيمة المضافة أو ضريبة المبيعات | الضرائب المستحقة | التزام |
| رسوم معالج الدفع | مصروف معالجة المدفوعات | مصروف |
| احتياطيات البائعين | التزام الاحتياطي | يعتمد على العقد |
| المرتجعات | إيراد مقابل (Contra-revenue) أو مرتجعات | يعكس المعالجة الأصلية |
| المبالغ المستردة (Chargebacks) | خسارة، أو ذمم مدينة، أو استرداد من البائع | يعتمد على من يتحمل الخسارة |
| مدفوعات بانتظار تأكيد البنك | مقاصة مدفوعات البائعين | حساب مقاصة |
| مبالغ غير مُخصصة | حساب وسيط (Suspense) | استثناء مؤقت |
يجب أن يحمل كل قيد جوهري هوية البائع، ورقم الطلب، ودفعة الصرف، ومعالج الدفع، والعملة، والكيان القانوني، والمعالجة الضريبية، نوع الحدث، المرجع الخارجي، وأي رابط قيد عكسي. وبدون هذه العناصر، لا يمكن لدفتر الأستاذ الفرعي للبائع إثبات رصيد فردي، ولا يمكن لدفتر الأستاذ العام إثبات الإجمالي.
يمكنك تنفيذ دفتر الأستاذ الفرعي إما كحساب التزام واحد لكل بائع، أو كحساب التزامات إجمالي يضم seller_id كبعد تحليلي، أو كتقسيم بين حسابات المستحقات والاحتياطي ومقاصة الصرف. النهج المعتمد على الحساب الإجمالي مع الأبعاد يتوسع بشكل أفضل بمجرد تجاوزك لعشرات البائعين. اختر النموذج بالتنسيق مع محاسبك، حيث إن قواعد حماية الأموال ولوائح المدفوعات المحلية قد تؤثر على كيفية ظهور تلك الأموال وعرضها. وبالنسبة لآليات القيود المحاسبية الكامنة وراء ذلك، فإن مقالنا حول واجهات برمجة تطبيقات دفاتر الأستاذ مزدوجة القيد لمحاسبة الأسواق الرقمية يغطي المبادئ الأساسية التي يبنى عليها هذا النموذج.
تسجيل عملية البيع بفصل خطوط البائع عن خطوط المنصة
خذ مثالاً لبيع عبر وكيل: يدفع العميل 100 يورو، عمولة المنصة 10 يورو، ويكسب البائع 90 يورو. عند نقطة استحقاق العمولة ومستحقات البائع:
| الحساب | مدين | دائن |
|---|---|---|
| مقاصة معالج الدفع | 100 يورو | |
| مستحقات البائع - البائع (أ) | 90 يورو | |
| إيراد العمولات | 10 يورو |
الرقابة المهمة هنا: اعتماد مبلغ 90 يورو كالتزام دائن، وليس كإيراد. وتعترف المنصة بمبلغ 10 يورو كإيراد لها. هذه هي النتيجة التي يهدف إليها مثال الأسواق الرقمية في معيار ASC 606 للوكيل، حيث تعترف المنصة بعمولتها بدلاً من إجمالي قيمة مبيعات البائع.
إذا تم تحصيل الضريبة بشكل منفصل، فأضف بند الضرائب المستحقة وخفض رقم البائع أو المنصة وفقاً للاستنتاج الضريبي. لا تقم بدمج الضريبة ضمن العمولات أو مستحقات البائعين كنوع من التسهيل.
إبعاد رسوم معالجات الدفع عن حسابات الإيرادات والمستحقات
هناك ثلاثة أشياء تختلط ببعضها باستمرار: عمولة المنصة، رسوم معالج الدفع، ومبلغ الصرف. فهي أمور مختلفة، وتؤثر على حسابات مختلفة.
دفع العميل 100 يورو، والعمولة 10 يورو، واستبقى معالج الدفع 3 يورو.
- يبقى إيراد العمولة 10 يورو إذا كان ذلك ما ينص عليه العقد.
- تُعد رسوم معالج الدفع البالغة 3 يورو مصروفاً.
- التزام البائع هو 90 يورو ما لم ينص عقد البائع على أن البائع يتحمل رسوم معالجة الدفع. وفقط في هذه الحالة ينخفض المبلغ إلى 87 يورو مع فرض 3 يورو مقابلة على البائع.
إن تسجيل مبلغ 90 يورو الصافي الذي يصل إلى البنك مباشرة يلغي Sale الإجمالي، والعمولة، والرسوم في خطوة واحدة. يشير مرجع مطابقة المدفوعات الخاص بنا إلى نفس النقطة: قم بتفكيك التسوية، وعامل رسوم معالجي الدفع كمصروفات، ولا تدع الإيداع الصافي يحل محل الإيراد أبداً.
نمذجة الإتاحة، والاحتياطيات، ومدفوعات الصرف كأحداث مستقلة
تتغير حالة الأموال عدة مرات بين وقت الاستحواذ ووقت تسوية النقد. وكل انتقال يستحق قيداً خاصاً به، ولا يُعد الاحتياطي النقدي أبداً اقتطاعاً غير مبرر للإيرادات.
عندما تنتقل الأموال المتاحة إلى حساب الاحتياطي:
| الحساب | مدين | دائن |
|---|---|---|
| مستحقات البائع - البائع (أ) | 15 يورو | |
| التزام احتياطي البائع | 15 يورو |
عند الإفراج عن الاحتياطي، قم بعكس القيد. فالالتزام الإجمالي للبائع لم يتغير، بل تغيرت حالته فقط. توثق Stripe المعاملات الاحتياطية التي تزيد الاحتياطيات وتفرج عنها، بالإضافة إلى عمليات تحويل التحصيل لأرصدة سالبة طويلة الأجل، ولهذا السبب تحتاج هذه الحالات إلى حسابات قابلة للتعريف بدلاً من قيد مقاصة واحد.
تحظى عمليات الصرف بمعالجة ثنائية الخطوات خاصة بها. عند الموافقة:
| الحساب | مدين | دائن |
|---|---|---|
| مستحقات البائع - البائع (أ) | 90 يورو | |
| مقاصة مدفوعات البائعين | 90 يورو |
عند تأكيد التسوية البنكية:
| الحساب | مدين | دائن |
|---|---|---|
| مقاصة مدفوعات البائعين | 90 يورو | |
| البنك | 90 يورو |
إذا فشلت عملية الصرف، قم بعكس قيد المقاصة ليRETURN إلى مستحقات البائع. تُعد عملية الصرف تسوية لالتزام وليست مصروفاً. ومعاملتها كمصروف تؤدي إلى ازدواج احتساب التكلفة مقابل البيع الذي سجل الالتزام مسبقاً. تفصل Stripe بين حالات الصرف (pending معلق، in_transit قيد العبور، paid مدفوع، failed فاشل، canceled ملغي) وبين تاريخ الوصول المتوقع من تاريخ البدء، ويجب ألا تندمج هذه التواريخ في طابع زمني واحد.
نموذج بيانات دورة الطلب إلى الصرف (Order-to-Payout)
يعمل دفتر الأستاذ الفرعي على الأحداث، وليس على حالة الطلب الحالية في التطبيق. وكل حدث يؤثر على البائع يحمل نفس الغلاف الهيكلي:
seller_id,event_id,order_id(معرف البائع، معرف الحدث، معرف الطلب)event_type(نوع الحدث: بيع، استرداد، استرجاع مدفوعات، حجز احتياطي، إفراج عن احتياطي، صرف، تسوية)effective_date,posting_date(تاريخ النفاذ، تاريخ الترحيل)currency,direction,gross,commission,fees,reserve(العملة، الاتجاه، الإجمالي، العمولة، الرسوم، الاحتياطي)refund_ref/dispute_ref(مرجع الاسترداد / مرجع النزاع)payout_batch_id(معرف دفعة الصرف)reversal_of(عكس القيد لـ)source_status,idempotency_key(حالة المصدر، مفتاح منع التكرار)
من خلال هذه الأحداث، تقوم بحساب الرصيد الختامي بدلاً من تخزين حقل قابل للتعديل:
الرصيد الختامي للبائع
= الرصيد الافتتاحي
+ دائن البائعين
− مدين البائعين
− مدفوعات الصرف
± تحركات الاحتياطي
± التصحيحات
يحتاج كل حدث خارجي إلى مفتاح منع تكرار (idempotency key) متين بحيث لا تؤدي محاولات إعادة الإرسال وإشعارات الويب المكررة (webhooks) إلى منح البائع رصيداً مزدوجاً أو صرف أموال مرتين. الأنماط الناجحة تشمل:
- حدث يومية البائع:
seller_id:order_id:event_type:version - دفعة الصرف:
processor:payout_id - حدث معالج الدفع:
processor:event_type:processor_event_id
يحذر توثيق إشعارات الويب الخاص بـ Stripe من أن الأحداث المكررة تحدث بالفعل، لذا فإن اكتشاف التكرار ليس أمراً اختيارياً. تظل القيود المرحلة ثابتة وغير قابلة للتعديل. وتتم التصحيحات من خلال قيد عكسي متبوع بقيد مُصحح، وغلاف الحدث الخاص بك هو الذي يحمل رابط reversal_of والسبب. يحتفظ دفتر الأستاذ بالقيود ولا يحتفظ بهذا الرابط فقط؛ حيث توفر منصة Nordlet عمليات الإنشاء، والاسترجاع، والقائمة لمعاملات دفتر اليومية في مرجع واجهة برمجة التطبيقات (API) الخاص بها ولا توفر أي تحديث او حذف، لذا فإن التصحيح هو دائماً معاملة جديدة بدلاً من التعديل المباشر.
المرتجعات والمبالغ المستردة تظل مترابطة وليست عائمة
المرتجعات التي تظهر في دفعة الصرف للأسبوع القادم يجب ألا تتحول أبداً إلى عملية بيع سالبة جديدة مرتبطة بهذا الصرف. اربطها بالمعاملة الأصلية واحتفظ بتخصيص البائع الأصلي. وبحسب العقد:
- يتم عكس العمولة إذا كان العقد يجعلها قابلة للاسترداد.
- يتم خصم مستحقات البائع إذا كان البائع يتحمل الاسترداد.
- يتم خصم حساب خسائر المنصة إذا كانت المنصة هي من تتحملها.
- يتم زيادة الاحتياطي أثناء فتح النزاع، والإفراج عنه أو استهلاكه عند تسويته.
تعتبر طلبات استرداد الأموال (chargebacks) التي تحدث بعد الصرف هي الموضع الذي تظهر فيه الأرصدة السالبة. فقد ذهبت أموال البائع بالفعل، لذا تسترد المنصة المبلغ من الإيرادات المستقبلية أو تبتلع الخسارة. يجب أن يسمح النموذج بأرصدة البائعين السالبة وأن يحدد قاعدة الاسترداد. تُظهر تقارير الأسواق الرقمية لدى Adyen أن الاسترداد والمبالغ المستردة تنتج صفوف مدين منفصلة لكل صاحب حساب، وهي درجة التفصيل التي يجب استهدافها.
مطابقة الحسابات لكل دفعة صرف، وليس شهرياً
قم بتفكيك كل تسوية لمعالج الدفع قبل ترحيلها، وقم بمطابقة كل دفعة صرف بدلاً من تجميع الشهر ككل:
رسوم إجمالية
− المرتجعات
− رسوم معالجات الدفع
− استرداد المدفوعات (Chargebacks)
± الاحتياطيات والتسويات
= صافي صرف معالج الدفع
ثم أثبت توافق أربعة أرصدة لكل بائع ولكل عملة: دفتر الأستاذ الفرعي للبائع، ورصيد البائع لدى معالج الدفع، وتقرير الصرف، ومقاصة البنك. وعندما تختلف، قم بتصنيف الفرق (التوقيت، حدث مفقود، تكرار، إسناد خاطئ، عملة خاطئة، صرف فاشل، استرداد مدفوعات مُرحل للطرف الخطأ). إن إخفاء الفروق عن طريق التسوية الصافية هو الطريقة التي تعوض بها الأخطاء بعضها البعض وتبقى حتى إغلاق الفترة التالية.
إن تجميع شهر كامل يسمح لفروق التوقيت بإلغاء بعضها البعض ويخفي الفروق الحقيقية. وتعمل المطابقة لكل دفعة صرف، والمفتاح فيها هو معرف الصرف ومرجع المعاملة بدلاً من المبلغ والتاريخ، على اكتشاف تلك الفروق.
أوماط الفشل الشائعة
| نمط الفشل | لماذا يؤثر سلباً | عنصر التحكم |
|---|---|---|
| تسجيل مدفوعات العملاء الإجمالية كإيرادات | تضخيم الإيرادات وإخفاء التزامات البائعين | فصل المستحقات والعمولة عند حدث الاكتسباب |
| تسجيل الإيداع الصافي فقط | ضياع الإجمالي والرسوم والمرتجعات والاحتياطيات | تفكيك كل تسوية |
| تسجيل عملية الصرف كمصروف | تشويه تسوية الالتزامات | جعل مستحقات البائع مدينة عند الصرف |
| حقل رصيد بائع واحد | خلط المعلق والمتاح والمحجوز والمدفوع | تتبع حالات الرصيد بشكل صريح |
| حساب العمولة وقت الصرف | تبعية الإيرادات لجدولة الصرف | الاعتراف بالعمولة عند اكتسابها |
| معاملة الاحتياطي كخصم من الإيرادات | طمس التوقيت والمخاطر | تتبع الحجز والإفراج والاستهلاك بشكل منفصل |
| تطبيق الاسترداد على أحدث صرف | كسر إسناد الطلب | ربط الاسترداد بالمعاملة الأصلية |
| تعديل القيود المرحلة | تدمير مسار التدقيق (Audit trail) | العكس وإعادة الترحيل |
| إشعارات الويب المُعادة (Replayed webhooks) | أرصدة ومدفوعات مكررة | مفاتيح منع التكرار واكتشاف النسخ |
| المطابقة على أساس المبلغ والتاريخ فقط | تصادم العناصر المختلفة | المطابقة بناءً على معرف الصرف، ومعرف المعاملة، والبائع، والعملة |
ما سأقوم به أولاً
قم برسم خريطة تدفق الأموال قبل لمس دليل الحسابات. اكتب كل حدث بدءاً من استلام الدفع وحتى الإفراج عن الاحتياطي، وحدد أيها ينشئ إيراداً، وأيها ينشئ التزاماً، وأيها يغير الحالة فقط.
ثم قم بناء تدفق متكامل من البداية إلى النهاية وأثبت توازنه: عملية بيع عادية، استرداد جزئي، استرداد مدفوعات بعد الصرف، احتياطي محجوز ومُفرج عنه، وصرف فاشل. قم بتشغيل هذه الحالات باستخدام أرصدة متوقعة ومعروفة. إذا كان حساب مراقبة مستحقات البائعين ي等於 مجموع دفاتر الأستاذ الفرعية، وارتبطت مقاصة معالج الدفع بتقرير التسوية، وارتبط الإيداع البنكي بمعرف الصرف، فسيكون لديك عمود فقري عملي.
قم بتفعيل قفل الفترة المحاسبية فقط بعد إغلاق الشهر الأول بشكل نظيف وبدون أي رصيد معلق في الحساب الوسيط. فإغلاق الفترة مبكراً يؤدي فقط إلى تجميد الأخطاء.
تقوم Nordlet بترحيل التسويات وفقاً لهذه المبادئ مباشرة ودون عناء: تذهب عمولة المنصة إلى إيراد العمولات، وتذهب حصة البائع إلى مستحقات البائعين، ورسوم معالج الدفع إلى مصروفات معالجة المدفوعات، وأي مبلغ لم يتم تخصيصه بعد يذهب إلى الحساب الوسيط. تظل فترات دفتر الأستاذ مفتوحة حتى تقوم بقفلها صراحة، بحيث يمكن إغلاق الشهر الأول بمجرد خلو الحساب الوسيط من أي رصيد. تعرض صفحة الميزات ما يتم تضمينه.
الأسئلة الشائعة (FAQ)
هل دفعة العميل هي إيراد للمنصة في أي وقت؟
فقط للسلع أو الخدمات المحددة التي تكون فيها المنصة هي الأصيل. أما في عمليات بيع الأسواق الرقمية كوكيل لسلع البائع، فالإيراد هو العمولة وحصة البائع هي التزام. يمكن أن تكون المنصة أصيلاً لخدمة التوصيل ووكيلًا للسلع الأساسية في نفس الطلب، لذا يتم التقييم لكل سلعة أو خدمة محددة، وليس على مستوى الشركة ككل.
هل ينبغي للاحتياطيات أن تخفض الإيرادات؟
لا. الاحتياطي هو تخصيص للتوقيت والمخاطر وليس تعديلاً للإيرادات. قم بنقل الأموال من مستحقات البائعين إلى التزام الاحتياطي عندما تحتجزها، واجعل القيد عكسياً عند الإفراج عنها. ولا تتأثر الإيرادات والعمولات بما إذا كانت أموال البائع محجوزة حالياً أم لا.
كيف أوقف عمليات الصرف المكررة الناتجة عن إعادة محاولات إشعارات الويب (webhooks)؟
أرفق مفتاح منع تكرار (idempotency key) بكل حدث خارجي، مثل processor:payout_id لدفعات الصرف، واكتشف الأحداث المكررة عند الكتابة. تحذر منصات الدفع صراحة من أن تسليم إشعارات الويب المكررة يحدث بالفعل، لذا يجب على دفتر الأستاذ رفض المحاولة الثانية بدلاً من ترحيلها مرة أخرى.
هل يمكن أن يصبح رصيد البائع سالباً؟
نعم، ويجب أن يسمح النموذج بذلك. فاسترداد المدفوعات (chargeback) الذي يحدث بعد دفع مستحقات البائع يترك المنصة إما مع ذمم مدينة على البائع أو بخسارة تتحملها. إن إخفاء الأرصدة السالبة لا يفعل سوى إخفاء التزام غير مسجل.
لماذا تتم مطابقة كل دفعة صرف بدلاً من إجمالي الشهر ككل؟
لأن فروق التوقيت والأخطاء تُلغي بعضها البعض عند تجميع الشهر، بحيث تتطابق الإجماليات بينما تكون المعاملات الفردية خاطئة. المطابقة لكل دفعة صرف، والمقترنة بمعرفات الصرف والمعاملات، تظهر الأحداث المفقودة والتكرارات واسترداد المدفوعات المُسند بشكل خاطئ قبل إغلاق الفترة.