يصل الدفع بالبطاقة إلى دفاترك عبر تقرير من شركة الاستحواذ يذكر الطلب بالفعل. أما تحويل USDC فيصلك مع عنوان ومبلغ وهاش المعاملة، ولا شيء غير ذلك. تنجح تسوية مدفوعات العملات المشفرة عندما تحمل الفاتورة المرجع التجاري، لأن التحويل نفسه لا يستطيع حمله.
هذا الدليل موجّه إلى فرق المالية والعمليات لدى التجار ومزودي خدمات الدفع (PSPs) ومؤسسات النقود الإلكترونية (EMIs) الذين يقبلون العملات المستقرة ويسوون المبالغ باليورو. يسرد الحقول التي يحتاجها سجل كل فاتورة، وكيفية التعامل مع المدفوعات الجزئية وتلك التي تأتي بعملة خاطئة، وكيف تغذّي webhooks وواجهة API الدفتر، وأي قواعد في الاتحاد الأوروبي تحدد المدة التي تحتفظ فيها بكل ذلك.
اللحظات الرئيسية
باختصار
- يحمل تحويل ERC-20 المرسِل والمستلم والمبلغ فقط. يجب أن يعيش مرجع الطلب على الفاتورة، لا في الدفعة.
- سعّر الفاتورة باليورو وسجّل المبلغ باليورو في الدفاتر. مبلغ العملة المشفرة رقم مشتق تحتفظ به لمسار التدقيق.
- معظم العمل يكمن في الاستثناءات: المدفوعات الجزئية، والفواتير المنتهية الصلاحية، والعملة الخاطئة. راجعها يوميًا لا في نهاية الشهر.
- استخدم webhook كمحفّز، وأعد قراءة الفاتورة بمعرّفها بوصفها المصدر الموثوق، واسحب قائمة الفواتير ليلًا كشبكة أمان ومصدر لتصدير CSV.
لماذا تكون تسوية مدفوعات العملات المشفرة أصعب من البطاقات؟#
تكون تسوية مدفوعات العملات المشفرة أصعب لأن تحويل البلوكتشين لا يحتوي على حقل لرقم طلبك. على Ethereum، يحدد معيار الرموز ERC-20 (EIP-20) حدث التحويل بوصفه `Transfer(address _from, address _to, uint256 _value)`: من أرسل، ومن استلم، وكم المبلغ. لا توجد ملاحظة ولا رقم فاتورة ولا اسم عميل.
المدفوعات المصرفية وبالبطاقات مبنية على العكس. يحتوي تحويل SEPA على حقل بيانات يملؤه الدافع، وتسرد تقارير التسوية لدى شركة الاستحواذ كل معاملة بطاقة مقابل مرجع التاجر لديك. ونظامك المحاسبي يطابق على هذا المرجع.
مع العملات المستقرة، تقف ثلاثة أمور أخرى في الطريق:
- المبلغ نادرًا ما يكون رقمًا صحيحًا. فاتورة بقيمة 250 يورو مسعّرة بـ USDC تصبح رقمًا مثل 279.2846 USDC، فتبدو فاتورتان بحجمين متقاربين متشابهتين.
- الدفع لا يصبح نهائيًا فورًا. ينتج Ethereum كتلة كل 12 ثانية، لكن وفقًا لموقع ethereum.org (صفحة محدّثة في أكتوبر 2026)، "يستغرق الأمر نحو 15 دقيقة حتى تصبح كتلة Ethereum نهائية." قد يظهر التحويل ومع ذلك لا يُحتسب.
- الدافعون يرتكبون أخطاء. يرسلون مبلغًا أقل، أو يرسلون مرتين، أو يرسلون عملة مختلفة، أو يدفعون بعد انتهاء صلاحية الفاتورة.
لذلك يجب أن يكون الربط موجودًا قبل أن يدفع الدافع: فاتورة واحدة لكل طلب، تحمل معرّف طلبك وعنوان الدفع الخاص بها، فيستقر كل تحويل وارد على سجل يعرف مسبقًا لأي غرض هو.
ما الحقول التي يحتاجها سجل كل فاتورة عملات مشفرة؟#
تحتاج كل فاتورة إلى مجموعة ثابتة من الحقول تربط أربعة أشياء ببعضها: طلبك، وسعره باليورو، والتحويل على السلسلة، والحالة النهائية. إذا غاب أحدها، ينتهي الأمر بشخص يطابق يدويًا. يستخدم الجدول أدناه أسماء حقول واجهة API لفواتير ItisPay؛ تستخدم مزودات أخرى أسماء مختلفة للأفكار نفسها.
| الحقل | ما يحتويه | لماذا تحتاجه المحاسبة |
|---|---|---|
| invoice_id | معرّف فريد يعيّنه المزود | المفتاح الأساسي لكل عملية بحث ولكل صف في الدفتر |
| order_id | رقم طلبك أو عقدك، فريد لكل طلب | الرابط بنظام ERP أو المتجر أو CRM لديك؛ وهو المرجع الذي تمنحك إياه البطاقات مجانًا |
| order_name | وصف موجز للطلب | يتيح لشخص مراجعة استثناء دون فتح المتجر |
| fiat_amount, fiat_currency | السعر باليورو | الإيراد الذي تقيّده في الدفاتر |
| currency, crypto_amount | العملة المفوترة والمبلغ المستحق | يبيّن ما طُلب من الدافع إرساله |
| actual_crypto_amount_paid | ما وصل فعليًا | يكشف الدفع الناقص والدفع الزائد |
| currency_paid | العملة المستخدمة، إن اختلفت عن العملة المفوترة | يُعلِّم مدفوعات العملة الخاطئة للمراجعة |
| network, address | شبكة البلوكتشين وعنوان الدفع | يثبت إلى أين أُرسلت الأموال؛ وهو لازم لأي تتبّع أو استرداد |
| transactions (tx_hash, amount, status) | سطر واحد لكل تحويل وارد | يمكن لفاتورة واحدة أن تستقبل عدة تحويلات؛ وكل هاش هو دليلك على السلسلة |
| status | new, pending, completed, expired, cancelled, paid_partial | يحدد ما إذا كنت تقيّد الدفعة أو تشحن أو تتابع أو تغلق |
| created_at, updated_at, expires_at | الطوابع الزمنية | قطع الحسابات في نهاية الشهر، وإثبات وقت دفع الطلب |
يقوم حقلان من هذه الحقول بمعظم العمل. `order_id` هو المرجع الذي لا يستطيع تحويل البلوكتشين حمله، لذا عيّنه من نظامك الخاص واجعله فريدًا لكل طلب، لا لكل عميل. قائمة `transactions` مهمة لأن الفاتورة لا تُدفع دائمًا دفعة واحدة: يحصل كل تحويل على سطر خاص به مع هاش وحالة، فتستطيع معرفة التحويلات التي يتكوّن منها المبلغ المدفوع.
احفظ مبلغ العملة المشفرة بكل منازله العشرية في عمود منفصل. يعمل دفترك العام بسنتات اليورو؛ أما أعمدة العملة المشفرة فهي أدلة لا قيم دفترية.
أي مبلغ باليورو يُسجَّل في الدفاتر؟#
سجّل سعر اليورو الوارد في الفاتورة. عندما تُصدر الفاتورة باليورو، يحوّلها المزوّد إلى مبلغ بالعملة المشفّرة وفق السعر الحالي، ويرسل الدافع ذلك المبلغ. إذا تمت تسوية الدفع إلى اليورو في حسابك، فإن رقم اليورو في الفاتورة هو إيرادك، ومبلغ العملة المشفّرة مجرد تفصيل تقني لطريقة وصول المال.
هذا هو السبب الرئيسي الذي يجعل الفرق التي تقبل مدفوعات العملات المشفّرة تلقائياً مع التحويل إلى اليورو نادراً ما تحتاج إلى محاسبة للعملات المشفّرة أصلاً: فلا توجد عملة في الميزانية لتقييمها في نهاية الشهر.
يختلف الأمر إذا احتفظت بالعملات المستقرة. قررت لجنة تفسيرات المعايير الدولية لإعداد التقارير المالية (IFRS) في يونيو 2019 أن حيازات العملات المشفّرة تندرج تحت معيار IAS 2 (المخزون) عندما تُحتفظ بها للبيع في سياق النشاط المعتاد، وتندرج تحت معيار IAS 38 (الأصول غير الملموسة) في غير ذلك. ويستبعد تعريفها للعملة المشفّرة الأصول التي تُنشئ عقداً بين الحائز وطرف آخر. أما USDC فمختلفة: تذكر Circle أنها «قابلة للاستبدال بالدولار الأمريكي بنسبة 1:1»، ومنذ يوليو 2024 تُصدر Circle عملتي USDC وEURC في الاتحاد الأوروبي بوصفهما رموز نقود إلكترونية (e-money tokens) بموجب ترخيص نقود إلكترونية من الهيئة الفرنسية للرقابة الاحترازية وتسوية المشكلات (ACPR). أما كيفية تصنيف العملة المستقرة المحتفظ بها فهو سؤال يُحال إلى مدقق حساباتك. والتسوية إلى اليورو فور الاستلام تُغني عن طرح هذه المسألة أصلًا.
كيف تتعامل مع المدفوعات الجزئية والعملات الخاطئة؟#
عامل كل فاتورة غير `completed` كاستثناء له مسؤول ومهلة محددة. معظم جهد مطابقة مدفوعات العملات المشفّرة يقع هنا؛ أما الفاتورة المدفوعة بالكامل فتتطابق من تلقاء نفسها.
إليك ما تعنيه كل حالة بالنسبة للمالية، باستخدام حالات ItisPay:
| الحالة | ما الذي حدث | ما الذي تفعله المالية | هل يُشحن الطلب أو يُفرج عنه؟ |
|---|---|---|---|
| new | الفاتورة مفتوحة ولم يُستلم شيء | لا يوجد ما يُسجَّل | لا |
| pending | رُصد تحويل ولم يكتمل بعد | انتظر تغيّر الحالة | لا |
| completed | دُفع المبلغ كاملاً | سجّل الإيراد بسعر اليورو وأفرج عن الطلب | نعم |
| paid_partial | وصل جزء من المبلغ | اطلب الباقي، أو استرد، أو أغلق الطلب باتفاق | حسب الحالة |
| expired | انتهت المهلة دون دفع كامل | أغلق الطلب وتحقّق من التحويلات المتأخرة | لا |
| cancelled | ألغيت الفاتورة من طرفك | لا قيد؛ أعد الإصدار إذا كان العميل ما زال يرغب في الدفع | لا |
المدفوعات الجزئية#
عادةً ما تعني الدفعة الجزئية أن محفظة الدافع أو منصة التداول خصمت رسوماً من المبلغ، أو أن الدافع أخطأ في كتابة المبلغ. يسجّل ItisPay كل تحويل على حدة، لذا يمكن لتحويل ثانٍ أن يُكمل الفاتورة. كما تحتوي الفاتورة على إعداد `allowed_error_percent`: وهو هامش تسامح صغير يُحدَّد لكل فاتورة، بحيث تُعدّ الدفعة التي تنقص بجزء يسير مدفوعةً. حدِّده مرة واحدة كسياسة، مثلاً بمستوى تشطبه أيضاً على التحويل المصرفي، ولا تغيّره حالةً بحالة.
إذا لم يصل الباقي أبداً، فقرر خلال عدد محدد من الأيام: اقبل النقص واشطبه، أو استرد ما وصل، أو ألغِ الطلب. دوّن القرار في سجل الفاتورة كي يرى المدقق سبب كون طلب مدفوع يقف خلفه مبلغ أقل.
عملة خاطئة أو دفعة متأخرة#
عندما يرسل الدافع عملة مستقرة مختلفة عن تلك المفوترة، يُظهر حقل `currency_paid` ذلك. لا تسجّله تلقائياً: تحقّق من المبلغ وقيمته باليورو، ثم اقبله أو استرده. والتحويل إلى فاتورة منتهية الصلاحية مشابه: المال موجود على السلسلة، لكن طلبك مغلق، لذا على أحدهم أن يقرر إما إعادة فتح الطلب أو إعادة الأموال. وإذا أُلغي طلب من طرفك، فألغِ الفاتورة عبر API (تحديث للحالة)، كي تُظهر سجلاتك أنها مغلقة قبل أن تصل أي دفعة متأخرة.
كيف تغذّي webhooks وAPI مطابقة مدفوعات العملات المشفّرة؟#
استخدم ثلاث طبقات: يخبرك webhook بأن شيئاً قد تغيّر، وتخبرك قراءة جديدة للفاتورة بما هو صحيح، وسحب ليلي لجميع الفواتير يلتقط أي شيء فاتَ الطبقتين الأوليين.
- يمكن أن تحمل كل فاتورة `callback_url`؛ ويرسل المزوّد تحديثات الحالة إليه. تعامل مع الرسالة كمحفّز لا كدليل.
- عند كل webhook، استدعِ `GET /invoices/{invoice_id}` واعتمد على الحالة والمبالغ الواردة في هذه الاستجابة. هذا يحميك من الاستدعاءات المزوّرة أو المعاد تشغيلها إلى نقطة الاتصال لديك، لأن استدعاء API يتطلب مفتاح API الخاص بك.
- اجعل المعالج قابلاً للتكرار دون أثر (idempotent): قد تصل الحالة نفسها مرتين. اربط قيد دفترك بـ`invoice_id` مع الحالة، كي لا يغيّر التكرار شيئاً.
- كل ليلة، اعرض الفواتير مرتبة حسب `updated_at` من الأحدث إلى الأقدم، وتصفّح الصفحات حتى تصل إلى آخر تشغيل لك؛ وأعد أيضاً فحص كل فاتورة ما زالت `new` أو `pending` أو `paid_partial`. قارنها بدفترك. وأي فاتورة مدفوعة في سجلات المزوّد لكنها مفتوحة في سجلاتك تُعد استثناءً.
للاختبار، يوفّر ItisPay نقطة اتصال تحاكي تغيير حالة فاتورة، وأخرى تعيد إرسال آخر webhook بحسب `invoice_id` أو `order_id`. استخدم الإعادة عندما يكون خادمك متوقفاً. والفرق التي تمرّر عدة وسائل دفع عبر طبقة تنسيق المدفوعات الواحدة تطبق النمط نفسه على كل وسيلة.
كيف تُعدّ ملف تصدير CSV للمحاسبة؟#
أعدّ الملف من واجهة قائمة الفواتير API، بصف واحد لكل فاتورة وصف إضافي لكل تحويل. في ItisPay، يُصفّي `GET /invoices` النتائج حسب الحالة والعملة وتاريخ الإنشاء، ويرتبها حسب التاريخ أو المبلغ، ويعيد حتى 100 فاتورة في كل صفحة مع عدد الصفحات. يمكن لنص برمجي صغير أن يمرّ على الصفحات ليوم أو شهر كامل، ويكتب الأعمدة وفق جدول الحقول أعلاه.
ملفان أفضل من ملف واحد:
- `invoices.csv`: invoice_id, order_id, fiat_amount, fiat_currency, currency, crypto_amount, actual_crypto_amount_paid, status, created_at, updated_at. هذا هو الملف الذي يستورده المحاسب ويطابقه مع المبيعات.
- `transfers.csv`: invoice_id, tx_hash, amount, currency, transfer status, time. هذا هو ملف الإثبات الذي يحتاجه المدقق.
استورد ملف الفواتير إلى أداة المحاسبة لديك كما تستورد تقرير تسوية مدفوعات البطاقات: سطر واحد لكل طلب، باليورو، مع رقم الطلب مفتاحًا للمطابقة.
ما قواعد الاتحاد الأوروبي التي تحكم سجلات مدفوعات العملات المشفرة؟#
ثلاث قواعد في الاتحاد الأوروبي تحدد الإطار. لا تجعل أيٌّ منها من التاجر مزوّد خدمات أصول مشفرة (CASP)، لكنها تحدد البيانات المتاحة ومدة حفظها.
- لائحة نقل الأموال (EU) 2023/1113. منذ 30 ديسمبر 2024، يجب على مزوّد خدمات الأصول المشفرة الخاص بالدافع أن يتأكد من أن كل تحويل مصحوب بمعلومات عن الدافع والمستفيد، مثل الأسماء وعناوين السجل الموزّع (distributed ledger) (المادة 14). تنتقل البيانات مع التحويل، لا داخله. بالنسبة إلى التحويلات التي تتجاوز 1,000 يورو من محفظة ذاتية الاستضافة أو إليها، يجب على المزوّد في الطرف المعني أن يقيّم ما إذا كانت هذه المحفظة تعود لعميله (المادتان 14 و16). هذه مهمة المزوّد المرخّص، وهي أحد أسباب بقاء الدفعة قيد المراجعة.
- حفظ السجلات. بموجب التوجيه الحالي بشأن AML (EU) 2015/849، المادة 40، تحتفظ الجهات الملزَمة بسجلات المعاملات لمدة خمس سنوات بعد انتهاء علاقة العمل أو وقوع المعاملة. وتُبقي اللائحة الجديدة بشأن AML (EU) 2024/1624 مدة الخمس سنوات (المادة 77)، وتسري اعتبارًا من 10 يوليو 2027.
- DAC8، التوجيه (EU) 2023/2226. ابتداءً من 1 يناير 2026، يُبلغ مزوّدو خدمات الأصول المشفرة السلطات الضريبية بمعاملات العملات المشفرة لمستخدميهم. يجب أن تتطابق سجلاتك مع ما يُبلغ عنه مزوّدك.
إذا كنت تعمل عبر شريك مرخّص، فإن الشريك يتحمّل التزامات CASP بموجب MiCA وهذه القواعد، كما هو موضح في دليلنا حول ترخيص MiCA CASP. وما زال عليك الاحتفاظ بسجلات طلباتك وبالجانب الخاص بك من المسار.
أين لا تزال تسوية المدفوعات المشفرة بحاجة إلى شخص؟#
تتولى الأتمتة حالة السداد الكامل. أما بقية الحالات فتحتاج إلى مسؤول محدد وسياسة مكتوبة موجزة.
متى لا تنفع هذه الطريقة
- الاسترداد تحويلات صادرة جديدة، وليس عكسًا للمعاملة. يحتاج إلى دفعة إلى عنوان أو IBAN، وإلى سجلاته الخاصة.
- لا يمكن دائمًا تحديد هوية الدافع الذي يرسل من حساب منصة تداول من خلال عنوان الإرسال. طابق على الفاتورة، ولا تطابق أبدًا على المرسل.
- المدفوعات لفاتورة منتهية الصلاحية، والمدفوعات المكررة، والعملات الخاطئة، تحتاج جميعها إلى قرار بشري.
- رسوم الشبكة والتقريب يحدثان فروقًا صغيرة. حدّد هامش تسامح مرة واحدة والتزم به.
روتين يومي لتسوية مدفوعات العملات المشفرة في خمس خطوات#
يجعل روتين يومي قصير إقفال نهاية الشهر مجرد إجراء شكلي:
- اسحب الفواتير التي أُنشئت أو حُدّثت منذ آخر تشغيل من API، وحدّث ملفي الفواتير والتحويلات.
- تحقّق من أن كل فاتورة بحالة `completed` لها طلب مدفوع مطابق في متجرك أو نظام ERP، والعكس صحيح.
- عالج قائمة الاستثناءات: `paid_partial`، والمدفوعات لفواتير منتهية الصلاحية، والعملات الخاطئة. أغلق كل حالة بقرار مكتوب.
- طابق تسوية اليورو في حسابك المصرفي مع مجموع الفواتير المكتملة للفترة. وتساعد حسابات IBAN الافتراضية في فصل التدفقات حسب خط العمل عند التسوية إلى IBAN.
- احفظ الملفين لمدة خمس سنوات على الأقل.
إذا أردت قبول العملات المستقرة وتلقي اليورو دون بناء هذه المنظومة بنفسك، فإن ItisPay توفر API وبيانات الفوترة والتسوية: معرّفات الفواتير والطلبات، وتجزئات كل تحويل، والحالات، وwebhooks. تتم عملية الترخيص وKYC والتسوية إلى IBAN الخاص بك عبر شريكنا المرخّص في الاتحاد الأوروبي، وهو CASP + مؤسسة دفع، ويتجاوز معظم الفرق مرحلة KYB إلى أول معاملة في أقل من أسبوع.
هذه المقالة لأغراض إعلامية فقط، ولا تُعد نصيحة قانونية أو تنظيمية.
