হিসাব ও ফি
USDT পাঠানোর ফি কে দেবে: ইনভয়েসে শর্তটি কীভাবে লিখবেন
ইনভয়েসের অঙ্ক পাঠানো অঙ্ক নাকি হাতে পাওয়া অঙ্ক—এই সংজ্ঞাটি আগে থেকে লিখে রাখার নিয়ম, শর্তের খসড়া ও ঘাটতি এলে ধাপে ধাপে করণীয়।
সর্বশেষ হালনাগাদ: 2026-09-22 উৎস যাচাই: 2026-09-22T14:30:00+06:00
কাজ শেষ, ইনভয়েস 500 USDT, ক্লায়েন্ট পাঠিয়েও দিয়েছেন—কিন্তু আপনার অ্যাকাউন্টে এল 499 USDT। ক্লায়েন্ট বলছেন তিনি পুরো 500 পাঠিয়েছেন, আপনার স্ক্রিনে 499। কেউ মিথ্যা বলছেন না; ইনভয়েসে শর্তটাই লেখা ছিল না। এই এক লাইন আগে থেকে ঠিক করা থাকলে মাস শেষে হিসাব মেলানোর সময় এই ধরনের ঘাটতি নিয়ে আর আলোচনা করতে হয় না।
ফি নিয়ে বিরোধ আসলে কোথায় শুরু হয়?
বিরোধ অঙ্ক নিয়ে নয়, সংজ্ঞা নিয়ে। "500 USDT" বাক্যটি দুইভাবে পড়া যায়: ক্লায়েন্ট যা পাঠাবেন (sent amount), নাকি আপনি যা হাতে পাবেন (received amount)। দুই পক্ষ দুই অর্থে পড়লে প্রতিটি পেমেন্টে একটি ছোট ঘাটতি তৈরি হয়, আর প্রতিবার নতুন করে আলোচনা করতে হয়।
তাই শর্তটি লিখতে হয় ইনভয়েস পাঠানোর আগে, প্রথম পেমেন্টের আগে। পরে দাবি করলে সেটি নতুন দাবি হিসেবে দেখা যায়, যদিও আপনার হিসাব ঠিকই ছিল।
নেটওয়ার্ক ফি আসলে কে কাটে?
উপরের স্ক্রিনশটে Binance-এর প্রকাশ্য ফি পাতায় লেখা আছে: প্রতিটি উইথড্রয়ালে ব্যবহারকারী একটি নির্দিষ্ট (flat) ফি দেন, যা কয়েন অ্যাকাউন্টের বাইরে সরানোর খরচ মেটায়; আর এই হার ব্লকচেইন নেটওয়ার্ক নির্ধারণ করে এবং নেটওয়ার্ক ব্যস্ততার মতো কারণে আগাম নোটিশ ছাড়াই বদলাতে পারে। এর তিনটি ব্যবহারিক অর্থ আছে:
- ফি কাটা হয় পাঠানোর দিকে, অর্থাৎ ক্লায়েন্টের অ্যাকাউন্টে। তিনি যদি "500 পাঠাও" নির্দেশ ধরে ফর্মে 500 বসান, তাঁর অ্যাকাউন্ট থেকে যেতে পারে 500 + ফি, আর আপনি পাবেন 500।
- অনেক সেবা আবার ফি-টি পাঠানো অঙ্ক থেকেই কেটে নেয়—তখন ক্লায়েন্টের খরচ 500, আপনার প্রাপ্তি 500-এর কম। কোন আচরণটি ঘটবে তা সেবা ও ফর্মভেদে আলাদা, তাই অনুমান না করে ক্লায়েন্টের উইথড্রয়াল ফর্মে দেখানো "you will receive" বা সমতুল্য লাইনটি দেখতে চান।
- ফি নেটওয়ার্কভেদে ভিন্ন এবং সময়ের সঙ্গে বদলায়। স্ক্রিনশটে একই টোকেনের BEP20 ও ERC20 সারিতে যে পার্থক্য দেখা যাচ্ছে, সেটিই কারণ—তাই চুক্তিতে কোনো নির্দিষ্ট ফি-সংখ্যা বসানো নিরাপদ নয়।
আপনার প্রকৃত প্রাপ্তিতে কেবল নেটওয়ার্ক ফি নয়, প্ল্যাটফর্ম ফি ও রূপান্তরের স্প্রেডও কাজ করে। এই তিনটি উপাদান আলাদা করে হিসাব করার পদ্ধতি প্ল্যাটফর্ম ফি, নেটওয়ার্ক ফি ও স্প্রেডের হিসাব-এ বিস্তারিত আছে; এখানে আলোচনা শুধু এই খরচগুলো কে বহন করবে সেই শর্ত নিয়ে।
তিনটি সম্ভাব্য শর্ত—পার্থক্য কোথায়?
| শর্ত | অর্থ | কার ঝুঁকি |
|---|---|---|
| Gross / sender pays | ক্লায়েন্ট এমন অঙ্ক পাঠাবেন যাতে আপনার অ্যাকাউন্টে ইনভয়েসের অঙ্ক পৌঁছায় | ফি বাড়লে ক্লায়েন্টের খরচ বাড়ে |
| Net / recipient pays | ক্লায়েন্ট ইনভয়েসের অঙ্ক পাঠাবেন, ফি কাটা যাওয়ার পর যা আসে তা-ই আপনার | ফি বাড়লে আপনার আয় কমে |
| Split | নেটওয়ার্ক ফি ক্লায়েন্টের, নিজের সেবার ফি যার যার | সীমারেখা স্পষ্ট না হলে তর্ক হয় |
ছোট অঙ্কের ঘন ঘন পেমেন্টে gross শর্ত আপনার জন্য বেশি গুরুত্বপূর্ণ, কারণ নির্দিষ্ট ফি প্রতিবার পুরোটাই কাটে—অঙ্ক যত ছোট, ফির অনুপাত তত বড়। বড় অঙ্কের একক পেমেন্টে পার্থক্য তুলনায় কম। gross শর্ত নিলে ক্লায়েন্টকে ঠিক কত পাঠাতে হবে তার উল্টো হিসাব হাতে 500 ডলার পেতে কত USDT চাইবেন-এ ধাপে ধাপে দেওয়া আছে।
ইনভয়েসে শর্তটি কীভাবে লিখবেন?
ইনভয়েস সাধারণত ইংরেজিতে যায়, তাই লাইনটিও ইংরেজিতে রাখুন। gross শর্তের জন্য একটি ব্যবহারযোগ্য খসড়া:
Payment terms: The invoiced amount is the amount to be received in the recipient's account. All transfer, network and platform fees are borne by the payer. Any shortfall between the invoiced amount and the credited amount remains payable.
net শর্ত মেনে নিলে সেটিও স্পষ্ট লিখুন, যাতে পরে ঘাটতি নিয়ে দাবি না ওঠে:
Payment terms: The invoiced amount is the amount to be sent by the payer. Network and platform fees are deducted from this amount and borne by the recipient.
split শর্তে সীমারেখা নামসহ লিখতে হয়, নইলে "প্ল্যাটফর্ম ফি" কোনটি তা নিয়েই তর্ক হয়:
Payment terms: The payer bears the blockchain network fee. Each party bears the fees charged by its own service provider.
কোন শর্তটি নিচ্ছেন সেটি ইনভয়েসে যেমন থাকবে, তেমনি কাজ শুরুর আগের লিখিত সম্মতিতেও থাকা ভালো—ইনভয়েস একতরফা নথি, সম্মতি দুই পক্ষের।
"নিট প্রাপ্তি" শর্ত লিখলে আর কী সংজ্ঞায়িত করতেই হবে?
শুধু "আমি নিট 500 পাব" লিখলে ফাঁক থেকে যায়। এই চারটি ঘরও পূরণ করুন:
- অ্যাসেট ও নেটওয়ার্ক। কোন টোকেন, কোন নেটওয়ার্ক—দুই পাশের পূর্ণ লেবেল এক হতে হবে। নেটওয়ার্ক না লিখলে ক্লায়েন্ট সবচেয়ে সস্তা রুট বেছে নিতে পারেন, যা আপনার সেবা গ্রহণই না-ও করতে পারে। পাঠানোর আগে মেলানোর নিয়ম USDT ঠিকানা ও নেটওয়ার্ক নিশ্চিত করার নিয়ম-এ আছে।
- "প্রাপ্তি" মানে কী। ব্লকচেইনে পৌঁছানো, নাকি আপনার সেবায় ক্রেডিট হওয়া? পার্থক্যটা বাস্তব—চেইনে সফল লেনদেনও সেবার ন্যূনতম সীমা বা পর্যালোচনার কারণে ক্রেডিট না-ও হতে পারে।
- কত ঘাটতি উপেক্ষা করবেন। খুব ছোট গরমিলের জন্য ইনভয়েস আবার খোলা অযৌক্তিক। একটি ছোট সহনসীমা আগেই লিখে রাখলে দুই পক্ষেরই সময় বাঁচে; অঙ্কটি আপনার সাধারণ ইনভয়েসের আকার দেখে ঠিক করুন।
- সময়সীমা। ঘাটতির দাবি কত দিনের মধ্যে তুলতে হবে—নইলে পুরোনো পেমেন্ট নিয়ে অনির্দিষ্টকাল আলোচনা চলতে থাকে।
অঙ্ক কম এলে ধাপে ধাপে কী করবেন?
ক্লায়েন্টকে লেখার আগে নিজের দিকটা নিশ্চিত করুন, কারণ ঘাটতির কারণ সবসময় ক্লায়েন্ট নন।
- ধাপ ১: ট্রানজ্যাকশন হ্যাশ ধরে দেখুন চেইনে কত পাঠানো হয়েছে এবং প্রাপক ঠিকানা আপনারই কি না।
- ধাপ ২: আপনার সেবার ডিপোজিট ইতিহাসে ক্রেডিট হওয়া অঙ্ক দেখুন। চেইনের অঙ্ক আর ক্রেডিট অঙ্ক আলাদা হলে ঘাটতি আপনার সেবার দিকে, ক্লায়েন্টের দিকে নয়।
- ধাপ ৩: চেইনের অঙ্কই ইনভয়েসের চেয়ে কম হলে ঘাটতি পাঠানোর দিকে। তখন ক্লায়েন্টকে হ্যাশ, চেইনে দেখা অঙ্ক ও ইনভয়েস নম্বর একসঙ্গে দিন—অভিযোগ নয়, তিনটি তথ্য।
- ধাপ ৪: শর্তটি gross হলে বাকি অঙ্কের জন্য নতুন ছোট ইনভয়েস দিন, পুরোনোটি সম্পাদনা করবেন না। তাতে দুই পেমেন্টের রেকর্ডই অক্ষত থাকে।
কোন হ্যাশ কোন ইনভয়েস ও কোন ক্লায়েন্টের—এই সংযোগ আগে থেকে রাখা না থাকলে ধাপ ১ ও ৩ কঠিন হয়ে যায়; সংযোগ রাখার কাঠামো ইনভয়েস, ক্লায়েন্ট ও পেমেন্ট তারিখ মেলানো-এ দেওয়া আছে।
কোন ঘাটতি দাবি করা উচিত নয়?
সব গরমিল ক্লায়েন্টের দায় নয়। এগুলো আপনার নিজের দিকের খরচ, শর্ত যা-ই হোক:
- আপনার নিজের অ্যাকাউন্ট থেকে পরে অর্থ সরানো বা রূপান্তরের খরচ।
- আপনার সেবার রূপান্তর স্প্রেড—ক্লায়েন্ট USDT পাঠিয়েছেন, সেটি বদলানোর সিদ্ধান্ত আপনার।
- বাজারমূল্যের ওঠানামা, যদি ইনভয়েস USDT-তে লেখা হয়ে থাকে।
এগুলো দাবি করলে সম্পর্ক নষ্ট হয় এবং আপনার আসল দাবিটিও দুর্বল দেখায়। বরং এই খরচগুলো আগেই দরে ধরে রাখুন।
রেকর্ডে কোন ঘরগুলো রাখবেন?
| ঘর | কী লিখবেন |
|---|---|
| invoice_ref | ইনভয়েস নম্বর |
| fee_terms | gross / net / split—যেটি লিখিতভাবে সম্মত |
| invoiced_amount | ইনভয়েসের অঙ্ক ও অ্যাসেট |
| network | সম্মত পূর্ণ নেটওয়ার্ক লেবেল |
| sent_amount | চেইনে দেখা পাঠানো অঙ্ক |
| credited_amount | আপনার সেবায় ক্রেডিট হওয়া অঙ্ক |
| shortfall | ইনভয়েস ও ক্রেডিটের পার্থক্য |
| shortfall_action | মেনে নেওয়া / নতুন ইনভয়েস / আলোচনায় |
| hash | ট্রানজ্যাকশন হ্যাশ |
অজানা ঘরে শূন্য বা আন্দাজের সংখ্যা বসাবেন না—খালি রাখুন এবং কারণ লিখুন। এই ঘরগুলো থাকলে মাস শেষে ইনভয়েসের যোগফল আর অ্যাকাউন্টে আসা অঙ্কের পার্থক্য ব্যাখ্যাযোগ্য থাকে।
নতুন ক্লায়েন্টের সঙ্গে প্রথমবার কীভাবে তুলবেন?
শর্তটি তুলুন দর আলোচনার সময়, পেমেন্টের সময় নয়। কার্যকর একটি বাক্য: "ইনভয়েসের অঙ্কটি আমার অ্যাকাউন্টে পৌঁছানো অঙ্ক; ট্রান্সফার ফি পাঠানোর দিকে থাকে।" এটি বাড়তি দাবি নয়, একটি সংজ্ঞা—তাই সাধারণত আপত্তি কম আসে।
ক্লায়েন্ট রাজি না হলে net শর্ত নিন, কিন্তু তখন দরটি সেই অনুযায়ী ধরুন এবং সেটিও লিখে রাখুন। ফি নিয়ে জেনেশুনে ছাড় দেওয়া আর অজান্তে ফি বহন করা এক জিনিস নয়।
বাংলাদেশের ব্যবহারকারী কোথায় থামবেন?
শর্ত লেখা আর পেমেন্ট রুট বৈধ হওয়া—দুটি আলাদা প্রশ্ন। বাংলাদেশ ব্যাংকের FE সার্কুলার No. 24 ভার্চুয়াল অ্যাসেট লেনদেন ও তাতে সহায়তা করা নিয়ে সীমার কথা বলে। ফলে এই লেখা কাউকে USDT-তে পারিশ্রমিক নেওয়ার অনুমতি দিচ্ছে না; শুধু বলছে, শর্ত লিখতে হলে কীভাবে অস্পষ্টতা এড়াবেন।
ক্লায়েন্টের প্রস্তাব বাস্তবে চালুর আগে আপনার ব্যাংক বা অনুমোদিত ডিলারের কাছ থেকে লিখিত ব্যাখ্যা নিন, এবং অনুমোদিত ফিয়াট রুটের বিকল্পটিও জেনে নিন। "প্রযুক্তিগতভাবে সম্ভব" আর "বর্তমান নিয়মে গ্রহণযোগ্য"—দুটি আলাদা বাক্য।
সম্পাদকীয় সীমা: এটি ইনভয়েস ও ফি-শর্ত লেখার শিক্ষামূলক সহায়িকা, আইনি পরামর্শ নয়; এখানে কোনো নির্দিষ্ট ফি-হার নির্ধারণ করা হয়নি। স্ক্রিনশট ও উদ্ধৃত ফি-নীতি 2026-09-22-এ দেখা হয়েছে এবং তা বিনা নোটিশে বদলাতে পারে—চলতি হার নিজ নিজ সেবার পাতা থেকে দেখে নিন।
