پرداخت کارتی از طریق گزارش بانک پذیرنده (اکوایرر) به دفاتر شما می‌رسد که از قبل سفارش را نام می‌برد. انتقال USDC با یک آدرس، یک مبلغ و یک هش تراکنش به دست شما می‌رسد و هیچ چیز دیگری ندارد. تطبیق پرداختهای رمزارزی زمانی کار میکند که فاکتور مرجع کسب‌وکار را داشته باشد، زیرا خود انتقال نمی‌تواند آن را داشته باشد.
این راهنما برای تیم‌های مالی و عملیاتی پذیرندگان، PSPها و EMIهایی است که استیبلکوین می‌پذیرند و به یورو تسویه می‌کنند. در ادامه فیلدهای مورد نیاز هر رکورد فاکتور، نحوهٔ برخورد با پرداختهای جزئی و پرداخت با رمزارز اشتباه، نحوهٔ تغذیهٔ دفتر کل از طریق وب‌هوک‌ها و API، و قواعدی از اتحادیهٔ اروپا که مدت نگهداری همهٔ این‌ها را تعیین میکند، آمده است.
لحظه‌های کلیدی
خلاصه
- یک انتقال ERC-20 فقط فرستنده، گیرنده و مبلغ را دارد. مرجع سفارش باید روی فاکتور باشد، نه در خود پرداخت.
- فاکتور را به یورو قیمت‌گذاری کنید و همان مبلغ یورویی را ثبت کنید. مبلغ رمزارزی یک عدد مشتق‌شده است که برای ردیابی حسابرسی نگه میدارید.
- بیشتر کار در استثناها است: پرداختهای جزئی، فاکتورهای منقضی‌شده و رمزارز اشتباه. آن‌ها را روزانه بررسی کنید، نه در پایان ماه.
- از وب‌هوک بهعنوان محرک استفاده کنید، فاکتور را با شناسه دوباره بخوانید و آن را مرجع معتبر بدانید، و فهرست فاکتورها را هر شب بهعنوان شبکهٔ ایمنی و منبع خروجی CSV دریافت کنید.
چرا تطبیق پرداختهای رمزارزی سخت‌تر از کارت است؟#
تطبیق پرداختهای رمزارزی سخت‌تر است، زیرا انتقال بلاکچین هیچ فیلدی برای شماره سفارش شما ندارد. در اتریوم، استاندارد توکن ERC-20 (EIP-20) رویداد انتقال را به شکل `Transfer(address _from, address _to, uint256 _value)` تعریف میکند: چه کسی فرستاده، چه کسی دریافت کرده و چقدر. هیچ یادداشتی، شماره فاکتوری و نام مشتری‌ای وجود ندارد.
پرداختهای بانکی و کارتی برعکس ساخته شده‌اند. انتقال SEPA یک فیلد اطلاعات پرداخت دارد که پرداخت‌کننده آن را پر میکند، و گزارش تسویهٔ بانک پذیرنده (اکوایرر) کارت هر تراکنش کارت را در برابر مرجع پذیرندهٔ شما فهرست میکند. سیستم حسابداری شما بر اساس همین مرجع تطبیق می‌دهد.
با استیبلکوینها سه مانع دیگر هم وجود دارد:
- مبلغ به‌ندرت گرد است. فاکتور 250 یورویی که به USDC قیمت‌گذاری شود به عددی مانند 279٫2846 USDC تبدیل میشود، بنابراین دو فاکتور با اندازهٔ مشابه میتوانند شبیه هم به نظر برسند.
- پرداخت بلافاصله قطعی نمی‌شود. اتریوم هر 12 ثانیه یک بلاک تولید میکند، اما بنا بر ethereum.org (صفحه‌ای که در ماه اکتبر 2026 به‌روز شده)، «حدود 15 دقیقه طول می‌کشد تا یک بلاک اتریوم نهایی شود.» انتقال ممکن است دیده شود و هنوز حساب نشود.
- پرداخت‌کنندگان اشتباه می‌کنند. مبلغ کمتری می‌فرستند، دو بار می‌فرستند، رمزارز دیگری می‌فرستند یا بعد از انقضای فاکتور پرداخت می‌کنند.
پس پیوند باید پیش از پرداخت وجود داشته باشد: یک فاکتور برای هر سفارش، حامل شناسهٔ سفارش شما و آدرس پرداخت اختصاصی خودش، تا هر انتقال ورودی روی رکوردی بنشیند که از قبل می‌داند برای چه چیزی است.
هر رکورد فاکتور رمزارزی به کدام فیلدها نیاز دارد؟#
هر فاکتور به مجموعه‌ای ثابت از فیلدها نیاز دارد که چهار چیز را به هم وصل کند: سفارش شما، قیمت یورویی، انتقال روی زنجیره و وضعیت نهایی. اگر یکی از آن‌ها نباشد، کسی باید دستی تطبیق دهد. جدول زیر نام فیلدهای 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 را بهعنوان توکن پول الکترونیکی و بر اساس مجوز پول الکترونیکی از نهاد نظارتی فرانسه ACPR صادر میکند. طبقه‌بندی استیبلکوین نگه‌داشته‌شده پرسشی است که باید با حسابرس شما در میان گذاشته شود. تسویه به یورو در لحظه دریافت، این موضوع را از میان برمی‌دارد.
پرداختهای جزئی و رمزارزهای اشتباه را چگونه مدیریت میکنید؟#
هر فاکتوری را که `completed` نیست، بهعنوان استثنا با یک مسئول مشخص و مهلت معین در نظر بگیرید. بیشتر تلاش مغایرت‌گیری پرداختهای رمزارزی در همین بخش صرف میشود؛ فاکتور کاملاً پرداختشده خودبه‌خود تطبیق می‌یابد.
در ادامه، معنای هر وضعیت برای امور مالی با استفاده از وضعیت‌های ItisPay آمده است:
| وضعیت | آنچه رخ داده | کار امور مالی | ارسال یا آزادسازی؟ |
|---|---|---|---|
| new | فاکتور باز است، چیزی دریافت نشده | چیزی برای ثبت وجود ندارد | خیر |
| pending | یک انتقال مشاهده شده، هنوز نهایی نشده | منتظر تغییر وضعیت بمانید | خیر |
| completed | پرداخت کامل | درآمد را به قیمت یورویی ثبت کنید و سفارش را آزاد کنید | بله |
| paid_partial | بخشی از مبلغ رسیده | بقیه را مطالبه کنید، بازپرداخت کنید یا با توافق ببندید | بسته به شرایط |
| expired | زمان بدون پرداخت کامل تمام شد | سفارش را ببندید؛ برای انتقال‌های دیرهنگام بررسی کنید | خیر |
| cancelled | شما فاکتور را باطل کردید | ثبتی انجام نشود؛ اگر مشتری همچنان می‌خواهد پرداخت کند، دوباره صادر کنید | خیر |
پرداختهای جزئی#
پرداخت جزئی معمولاً به این معناست که کیف پول یا صرافی پرداخت‌کننده کارمزدی از مبلغ کم کرده یا پرداخت‌کننده مبلغ را اشتباه وارد کرده است. ItisPay هر انتقال را جداگانه ثبت میکند، بنابراین انتقال دوم میتواند فاکتور را تکمیل کند. فاکتور همچنین تنظیمی به نام `allowed_error_percent` دارد: تلورانس کوچکی که برای هر فاکتور تعیین میشود، به‌طوری که پرداختی که کسری اندکی دارد همچنان پرداختشده محسوب شود. آن را یک بار بهعنوان سیاست تعیین کنید، مثلاً سطحی که روی انتقال بانکی هم چشم‌پوشی میکنید، و آن را موردبه‌مورد تغییر ندهید.
اگر بقیه مبلغ هرگز نرسید، در مهلتی ثابت از نظر تعداد روز تصمیم بگیرید: کسری را بپذیرید و آن را بهعنوان زیان/هزینه شطب کنید، آنچه دریافت شده را بازپرداخت کنید، یا سفارش را لغو کنید. تصمیم را روی رکورد فاکتور بنویسید تا حسابرس ببیند چرا برای یک سفارش پرداختشده پول کمتری پشت آن است.
رمزارز اشتباه یا پرداخت دیرهنگام#
وقتی پرداخت‌کننده استیبل‌کوینی غیر از آنچه فاکتور شده ارسال میکند، فیلد `currency_paid` آن را نشان می‌دهد. آن را به‌طور خودکار ثبت نکنید: مبلغ و ارزش یورویی را بررسی کنید، سپس آن را بپذیرید یا بازپرداخت کنید. انتقال به فاکتور منقضی‌شده مشابه است. وجه روی زنجیره (on-chain) است، اما سفارش شما بسته شده، پس کسی باید تصمیم بگیرد که سفارش را دوباره باز کند یا وجه را برگرداند. اگر سفارشی از سمت شما باطل شده باشد، فاکتور را از طریق API لغو کنید (به‌روزرسانی وضعیت)، تا سوابق شما پیش از رسیدن هر پرداخت دیرهنگام، آن را بسته نشان دهند.
وب‌هوک‌ها و API چگونه باید به مغایرت‌گیری پرداختهای رمزارزی خوراک دهند؟#
سه لایه به کار ببرید: وب‌هوک به شما می‌گوید چیزی تغییر کرده، خواندن تازه فاکتور مشخص میکند چه چیزی درست است، و دریافت شبانه همه فاکتورها هر چیزی را که دو لایه اول از دست داده‌اند پیدا میکند.
- هر فاکتور میتواند یک `callback_url` داشته باشد؛ ارائه‌دهنده به‌روزرسانی‌های وضعیت را به آن می‌فرستد. پیام را بهعنوان محرک در نظر بگیرید، نه بهعنوان اثبات.
- با هر وب‌هوک، `GET /invoices/{invoice_id}` را فراخوانی کنید و بر اساس وضعیت و مبالغ آن پاسخ عمل کنید. این کار شما را در برابر فراخوانی‌های جعلی یا بازپخش‌شده به نقطه‌پایانی‌تان محافظت میکند، زیرا فراخوانی API به کلید API شما نیاز دارد.
- هندلر را idempotent بسازید: همان وضعیت ممکن است دو بار برسد. ورودی دفترکل خود را با `invoice_id` به‌علاوه وضعیت کلید بزنید، تا تکرار هیچ چیزی را تغییر ندهد.
- هر شب، فاکتورها را بر اساس `updated_at` و با جدیدترین‌ها در ابتدا فهرست کنید و تا آخرین اجرای خود صفحه‌بندی کنید؛ همچنین همه فاکتورهایی را که هنوز `new`، `pending` یا `paid_partial` هستند دوباره بررسی کنید. آن‌ها را با دفترکل خود مقایسه کنید. هر موردی که در سوابق ارائه‌دهنده پرداختشده ولی در سوابق شما باز است، یک استثنا است.
برای آزمایش، ItisPay نقطه‌پایانی‌ای دارد که تغییر وضعیت یک فاکتور را شبیه‌سازی میکند، و نقطه‌پایانی‌ای که آخرین وب‌هوک را با `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، ارائه‌دهنده خدمات دارایی رمزنگاری‌شده پرداخت‌کننده باید اطمینان حاصل کند که هر انتقال با اطلاعات مربوط به پرداخت‌کننده و دریافت‌کننده همراه است، مانند نام‌ها و نشانی‌های دفتر کل (ماده 14). این داده‌ها همراه انتقال حرکت می‌کنند، نه درون آن. برای انتقال‌های بالای 1٬000 یورو به کیف‌پول خودمیزبان یا از آن، ارائه‌دهنده طرف مربوط باید بررسی کند که آیا آن کیف‌پول متعلق به مشتری خودش است یا نه (مواد 14 و 16). این وظیفه ارائه‌دهنده دارای مجوز است و یکی از دلایلی است که پرداخت میتواند در بررسی بماند.
- نگهداری سوابق. بر اساس دستورالعمل فعلی AML (EU) 2015/849، ماده 40، نهادهای مکلف سوابق تراکنش را پنج سال پس از پایان رابطه تجاری یا وقوع تراکنش نگه می‌دارند. مقررات جدید AML (EU) 2024/1624 دوره پنج‌ساله را حفظ میکند (ماده 77) و از 10 ژوئیهٔ 2027 اعمال میشود.
- DAC8، دستورالعمل (EU) 2023/2226. از 1 ژانویه 2026، ارائه‌دهندگان خدمات دارایی رمزنگاری‌شده تراکنش‌های رمزارزی کاربرانشان را به مراجع مالیاتی گزارش می‌دهند. سوابق خودتان باید با آنچه ارائه‌دهنده‌تان گزارش میکند هم‌خوان باشد.
اگر از طریق شریک دارای مجوز کار میکنید، طبق MiCA و این قواعد، تعهدات CASP بر عهده شریک است، همانطور که در راهنمای ما درباره مجوز CASP تحت MiCA توضیح داده‌ایم. با این حال سوابق سفارش و سهم خودتان از مسیر را نگه میدارید.
تطبیق رمزارز کجا همچنان به یک فرد نیاز دارد؟#
خودکارسازی حالت پرداخت کامل را پوشش می‌دهد. بقیه موارد به یک مسئول مشخص و یک سیاست کتبی کوتاه نیاز دارند.
کجا کمک نمی‌کند
- بازپرداخت‌ها انتقال‌های خروجی جدید هستند، نه برگشت تراکنش. آن‌ها به پرداخت به یک نشانی یا IBAN و سوابق مخصوص به خودشان نیاز دارند.
- پرداخت‌کننده‌ای که از حساب صرافی ارسال میکند، همیشه با نشانی ارسال‌کننده قابل شناسایی نیست. بر اساس فاکتور تطبیق دهید، هرگز بر اساس فرستنده.
- پرداخت به فاکتور منقضی‌شده، پرداختهای تکراری و رمزارزهای اشتباه همگی به تصمیم انسانی نیاز دارند.
- کارمزد شبکه و گرد کردن، تفاوت‌های کوچکی ایجاد می‌کنند. یک بار آستانه تلورانس را تعیین کنید و به آن پایبند بمانید.
روال روزانه تطبیق پرداخت رمزارزی در پنج گام#
یک روال روزانه کوتاه، بستن پایان ماه را به یک امر صوری تبدیل میکند:
- فاکتورهایی را که از آخرین اجرا ایجاد یا به‌روزرسانی شده‌اند از API دریافت کنید و فایل‌های فاکتور و انتقال را به‌روز کنید.
- بررسی کنید که هر فاکتور `completed` یک سفارش پرداختشده متناظر در فروشگاه یا ERP شما دارد، و برعکس.
- فهرست استثناها را پیگیری کنید: `paid_partial`، پرداخت به فاکتورهای منقضی‌شده، رمزارزهای اشتباه. هر مورد را با یک تصمیم کتبی ببندید.
- تسویه یورویی حساب بانکی‌تان را با مجموع فاکتورهای تکمیل‌شده در دوره مقایسه کنید. تسویه به یک IBAN جایی است که IBANهای مجازی به جداسازی جریان‌ها بر اساس خط کسب‌وکار کمک می‌کنند.
- هر دو فایل را حداقل پنج سال بایگانی کنید.
اگر می‌خواهید استیبلکوین بپذیرید و یورو دریافت کنید بدون اینکه این ساختار را خودتان بسازید، ItisPay API، صدور فاکتور و داده‌های تطبیق را ارائه می‌دهد: شناسه‌های فاکتور و سفارش، هشهای هر انتقال، وضعیت‌ها و وب‌هوک‌ها. صدور مجوز، KYC و تسویه به IBAN شما از طریق شریک CASP و مؤسسه پرداخت دارای مجوز در اتحادیه اروپا انجام میشود و بیشتر تیم‌ها از KYB تا اولین تراکنش کمتر از یک هفته فاصله دارند.
این مقاله صرفاً برای اطلاع‌رسانی است و مشاوره حقوقی یا نظارتی محسوب نمی‌شود.
