USDT পাওয়ার সময় টাকার মূল্য কীভাবে লিখবেন

সর্বশেষ হালনাগাদ: 2026-08-12 উৎস যাচাই: 2026-08-10T18:48:47+08:00

USDT amount-এর পাশে শুধু “টাকার মূল্য” লিখলে পরে হিসাবটি যাচাই করা যায় না। কোন fiat currency, কোন rate direction, কোন source, কোন সময় এবং gross না net—কোন asset amount ব্যবহার করা হয়েছে তা লিখতে হবে। Payment-date value একটি calculation record; এটি cash conversion, bank credit, tax value বা legal-tender equivalence-এর স্বয়ংক্রিয় প্রমাণ নয়।

ন্যূনতম record কী?

প্রতি payment row-এ রাখুন:

• payment date/time with timezone;
• asset ও network;
• gross, received ও valuation asset amount;
• transaction hash বা platform reference;
• manual reference rate;
• rate currency ও direction;
• rate source এবং source snapshot reference;
• rate observation time;
• calculated fiat value;
• fee ও spread treatment;
• calculation formula/version;
• note, status ও reviewer।

এই field-গুলো থাকলে অন্য কেউ একই source ও formula দিয়ে ফল পুনরায় বের করতে পারবেন। “1 USDT = 1 USD” লিখে source/time বাদ দিলে historical record হয় না।

প্রথমে কোন সময় বেছে নেবেন?

Payment event-এর একাধিক সময় থাকতে পারে: client send time, network block time, recipient service credit time এবং ledger entry time। Valuation policy-তে কোনটি primary লিখুন। Custodial account-এ usable balance পাওয়ার সময়কে ব্যবহার করলে chain timestamp আলাদা supporting field হবে। Public transfer valuation করলে confirmed block time policy হতে পারে।

Policy মাঝপথে বদলাবেন না। বদলালে effective date ও পুরোনো rows-এর treatment লিখুন। Timezone ছাড়া 2026-08-12 09:30 অসম্পূর্ণ; RFC3339 format যেমন 2026-08-12T09:30:00+06:00 ব্যবহার করলে offset স্পষ্ট হয়।

Ethereum payment time কীভাবে anchor করবেন?

Ethereum transaction documentation sender, recipient, value বা input, fee fields ও transaction hash ব্যাখ্যা করে। Hash submission-এর পরে পাওয়া গেলেও inclusion ও finality পরে হয়। তাই client message time-কে confirmed payment time লিখবেন না। Block context ও recipient credit আলাদা রাখুন।

ERC20 token transfer-এর amount event log-এ থাকতে পারে; native transaction value field-এর সঙ্গে গুলিয়ে ফেলবেন না। Explorer display থেকে value নিলে token contract, decimals ও network context record করুন। এই technical value service-income purpose নিজে থেকে জানায় না।

TRON receipt কোন সময় দেয়?

TRON transaction-information endpoint transaction ID, total fee, block number, block timestamp ও execution result দিতে পারে। Confirmed block timestamp valuation anchor হলে receipt reference রাখুন। Client তৈরি করার সময় ও block timestamp আলাদা হতে পারে।

Execution result unsuccessful হলে amount movement হয়েছে ধরে valuation করবেন না। Relevant token event ও recipient credit মিলান। Receipt fee TRX-তে এবং transfer amount USDT-তে হতে পারে; ভিন্ন unit এক field-এ যোগ করবেন না।

rate direction কীভাবে লিখবেন?

R = USD per USDT হলে fiat value USDT amount × R। USDT per USD হলে divide করতে হবে। একই number কাছাকাছি 1 হলেও direction বাদ দেবেন না। BDT value চাইলে BDT per USDT direct rate অথবা two-stage USD per USDT × BDT per USD হতে পারে; দুটির source আলাদা রাখুন।

Header example: reference_rate_value=0.998, reference_rate_unit=USD/USDT। শুধু rate=0.998 পরে বোঝা যাবে না এটি USD, BDT, buy, sell না midpoint। Bengali digit display করা গেলেও CSV numeric field standard decimal রাখলে parsing সহজ।

কোন asset amount দিয়ে value বের করবেন?

Gross amount client-এর obligation দেখাতে পারে। Received amount recipient service-এ credit হওয়া token। Net amount fee বাদে ব্যবহৃত balance। Valuation purpose অনুযায়ী একটি valuation_basis field বেছে নিন: gross, received, net_after_evidenced_fee বা অন্য documented basis।

Formula:

fiat_value = valuation_asset_amount × reference_rate

যদি received 499 USDT এবং R = 0.998 USD/USDT, calculated value 498.002 USD। Display 498.00 USD, raw result retained। এটি কোনো live input নয়; method demonstration। Gross 500 ব্যবহার করলে result আলাদা হবে। Basis না লিখলে দুই reviewer দুই ফল পাবেন।

source কীভাবে সংরক্ষণ করবেন?

Rate source-এর publisher/page name, exact URL বা statement reference, observed value, observation time এবং screenshot/PDF filename লিখুন। “Google”, “market” বা “online” যথেষ্ট নয়। Source public page হলেও later change হতে পারে, তাই permissible হলে dated snapshot বা exported statement রাখুন।

এই নিবন্ধ কোনো rate source recommend বা live rate দেয় না। আপনার accountant, AD বা প্রযোজ্য কর্তৃপক্ষ কোন valuation source/method গ্রহণ করবে তা তাদের কাছে জিজ্ঞাসা করুন। Source জনপ্রিয় হলেই tax বা regulatory purpose-এর জন্য accepted হয় না।

rate time payment time-এর কত কাছে হবে?

একটি universal minute limit নেই। নিজের policy লিখুন—same timestamp, nearest available observation, daily close, bank credit rate বা professional advice অনুযায়ী অন্য basis। Payment ও rate time-এর gap calculation করুন এবং policy limit ছাড়ালে flag দিন।

Rate পরে সংগ্রহ করলে original timing-এর ভান করবেন না। rate_observed_late=true, actual observation time এবং reason লিখুন। Historical page পাওয়া গেলে source nature উল্লেখ করুন। বর্তমান rate দিয়ে পুরোনো payment revalue করলে সেটি নতুন valuation version, original record নয়।

USDT-এর reference price ও fiat status কি এক?

Tether legal terms USDt-এর one-dollar reference, applicable fees এবং token fiat currency নয়—এই পার্থক্য দেখায়। ফলে observed fiat value token amount-এর হিসাব; USD cash বা approved currency identity নয়। Fee-free one-to-one redemption সব user-এর জন্য guarantee করা যাবে না।

বাংলাদেশ ব্যাংকের FE সার্কুলার No. 24 virtual currency-কে approved foreign exchange/currency হিসেবে স্বীকৃতি না দেওয়া এবং নির্দিষ্ট transaction/facilitation-এর সীমা জানায়। Ledger-এ BDT value লেখা এই regulatory status বদলায় না।

spread কীভাবে value record-এ থাকবে?

Reference value ও actual conversion outcome আলাদা হলে spread analysis করা যায়। Actual fiat outcome না থাকলে realized spread unknown। Assumed haircut দিয়ে planning value করলে field হবে assumed_spread, actual নয়। Rate-এর মধ্যে already spread থাকলে আবার spread কাটবেন না।

দুটি formula আলাদা রাখুন:

reference_fiat_value = asset_amount × reference_rate

estimated_after_spread = reference_fiat_value × (1 − assumed_spread)

Report label-এ “reference” ও “estimated” রাখুন। Actual bank credit হলে third field actual_fiat_credit ও bank reference থাকবে।

fee কীভাবে valuation থেকে আলাদা করবেন?

Platform fee USDT-তে, network cost ETH/TRX/BNB-তে, bank charge BDT/USD-তে হতে পারে। সব fee এক currency-তে convert করলে প্রত্যেক conversion rate/source/time দরকার। Original amount ও currency কখনো বাদ দেবেন না।

Fee gross থেকে কাটা হলে gross এবং received value দুইটি বের করা যায়। Sender আলাদা fee দিলে recipient value unchanged, কিন্তু total transaction cost বাড়ে। fee_bearer, fee_currency, fee_amount, fee_source ও included_in_valuation field রাখুন।

Freelancer ID document requirement কী শেখায়?

Freelancer ID essential documents proof-এ applicant name, income amount ও transaction date স্পষ্ট থাকার কথা বলে এবং direct-client evidence-এর সঙ্গে inward-remittance proof মিলানোর কথা জানায়। তাই valuation row client/invoice/payment evidence-এর substitute নয়। Identity, amount ও date supporting bundle-এ থাকতে হবে।

নিজের calculated BDT value-কে official income verification document বলবেন না। Application portal যে document চায় সেটিই দিন। Ledger source documents খুঁজে পেতে index হিসেবে কাজ করবে; acceptance guarantee নয়।

fiat service-export receipt হলে কোন record আলাদা?

FEPD-1 সার্কুলার No. 26 Part K-তে electronic evidence ও inward-remittance message যাচাইয়ের পরে AD-এর equivalent local-currency credit এবং eligible ERQ portion, reporting ও records-এর current framework দেয়। Fiat service-export receipt হলে foreign amount, local credit, ERQ portion, AD reference, purpose code ও evidence আলাদা columns-এ রাখুন।

এই circular USDT-কে fiat বলে না বা virtual-asset receipt/conversion authorize করে না। USDT valuation row ও AD-processed fiat remittance row এক record type নয়। Proposed route আপনার AD-এর সঙ্গে আগে যাচাই করুন।

BDT value দুই ধাপে করলে কী করবেন?

যদি direct BDT/USDT reference না নিয়ে USD bridge ব্যবহার করেন:

USD value = USDT amount × USD per USDT

BDT value = USD value × BDT per USD

দুই rate-এর source/time ও direction আলাদা fields। একটি rate payment time-এর, অন্যটি bank credit rate হলে mixed basis তৈরি হয়; policy-তে explain করুন। Intermediate USD full precision-এ রাখুন, শেষে BDT rounding করুন।

একটি combined effective BDT/USDT rate বের করলেও original two rates রাখুন। পরে source audit বা correction করতে তা দরকার।

unknown rate হলে কী লিখবেন?

Zero নয়। rate_status=missing, reason ও follow-up action লিখুন। Fiat value blank/null থাকবে। “1 ধরে provisional” করলে assumption field ও version দিন; official summary-তে confirmed value হিসেবে নেবেন না।

Source unavailable থাকলে evidence gap সত্যভাবে দেখানো ভালো। পরে reliable historical source পেলে correction log-এ old null, new value, source, correction time ও reviewer লিখুন। Original export read-only রাখুন।

payment পরে refund বা reversal হলে কী হবে?

Original receipt row delete করবেন না। Refund/reversal আলাদা event row, own date/time, asset amount, hash/reference ও valuation। Link field দিয়ে original payment-এর সঙ্গে বাঁধুন। Monthly summary policy বলে দেবে gross receipt, refund ও net কীভাবে দেখাবে।

Partial refund হলে allocation ও fee treatment লিখুন। Refund-date rate original-date rate-এর সমান ধরে নেবেন না। Tax/accounting treatment professional advice-এর বিষয়; ledger ঘটনা ও calculation আলাদা রাখবে।

একটি CSV row কেমন হতে পারে?

record_id,invoice_number,client_alias,payment_time_rfc3339,asset,network,valuation_asset_amount,valuation_basis,reference_rate,rate_unit,rate_source_ref,rate_time_rfc3339,calculated_fiat_value,fiat_currency,fee_status,hash_or_payment_ref,record_status

এটি header example, real payment নয়। কোনো fake hash, address, client বা rate দেওয়া হয়নি। Numeric field machine-readable রাখুন; note-এ comma/newline থাকলে valid CSV quoting ব্যবহার করুন।

quality review কী পরীক্ষা করবে?

1. Payment time ও timezone source-এর সঙ্গে মেলে কি?
2. Asset/network/hash বা platform reference আছে কি?
3. Valuation amount gross/received/net—স্পষ্ট কি?
4. Rate direction ও currency unit আছে কি?
5. Source ও observation time সংরক্ষিত কি?
6. Formula correct এবং intermediate precision retained কি?
7. Fee/spread double count হয়নি কি?
8. Calculated value cash receipt বলে label হয়নি কি?
9. Original ও corrected version আলাদা কি?
10. Regulatory/payment-route প্রশ্ন AD-এর কাছে আলাদা রাখা হয়েছে কি?

Review pass মানে calculation পুনর্গঠনযোগ্য; legal, tax বা application acceptance নয়। Reviewer name, time ও exception রাখুন।

শেষ নীতি কী?

একটি শক্ত payment-date fiat record চারটি প্রশ্নের উত্তর দেয়: কোন asset amount, কোন সময়, কোন rate/source এবং কোন formula? এর সঙ্গে invoice, client, hash/payment reference ও fee evidence যুক্ত হলে event বোঝা যায়। Rate একা income relationship নয়; hash একা rate নয়; calculated BDT value একা bank credit নয়।

rate snapshot-এর evidence file কীভাবে নাম দেবেন?

নামের মধ্যে record ID, rate currency, source এবং recorded time রাখুন, যেমন REC-024_USD-BDT_source_2026-08-12T09-30+06-00.webp। নামটি শুধু index; screenshot বা exported page-এর ভিতরে source identity, quoted pair, visible rate এবং capture time বোঝা দরকার। Browser clock দেখা গেলেই source-এর publication time প্রমাণ হয় না, তাই rate_recorded_at ও source-এর নিজস্ব timestamp থাকলে দুটো আলাদা field রাখুন। File hash বা read-only copy রাখা যেতে পারে যাতে পরে accidental edit ধরা যায়। কিন্তু screenshot থাকলেই rate official, permitted বা accounting-এর জন্য accepted—এমন দাবি করবেন না।

bid, ask ও midpoint-এর মধ্যে কোনটি নেবেন?

একটি source একাধিক rate দেখালে আগে policy ঠিক করুন। Asset বিক্রি করে fiat পাওয়ার record হলে relevant executable side, indicative midpoint বা institution statement—যেটি নেবেন তার নাম হুবহু লিখুন। শুধু সবচেয়ে সুবিধাজনক সংখ্যা বেছে নিলে ধারাবাহিকতা নষ্ট হয়। Source যদি side বা methodology না জানায়, indicative rate; side unknown লিখুন। মাসজুড়ে একই policy অনুসরণ করুন; policy বদলালে effective date ও কারণ নথিভুক্ত করুন। এই guide কোনো নির্দিষ্ট source বা side বাধ্যতামূলক বলে না। Accountant, bank বা AD আলাদা method চাইলে তাদের current requirement-কে অগ্রাধিকার দিন।

cross-rate ব্যবহার করলে calculation কীভাবে দেখাবেন?

Direct USDT/BDT reference না থাকলে দুটি manual reference দিয়ে cross-rate বানানো হতে পারে। উদাহরণস্বরূপ, record-এ USDT/USD = A এবং USD/BDT = B থাকলে selected convention অনুযায়ী derived rate A × B হতে পারে। দুটো source, দুটো timestamp, direction এবং formula রাখুন; শুধু final BDT number লিখবেন না। একটি pair বিপরীত দিকে থাকলে আগে reciprocal নিতে হবে এবং সেই ধাপ লিখতে হবে। Zero বা negative input, stale timestamp বা mismatched basis থাকলে calculation বন্ধ করুন। এটি illustrative bookkeeping method; live quotation বা currency-conversion offer নয়।

timezone mismatch কীভাবে সামলাবেন?

Transaction explorer UTC দেখাতে পারে, client local time পাঠাতে পারে, আর rate source অন্য timezone ব্যবহার করতে পারে। সব raw time অপরিবর্তিত রেখে একটি normalized RFC3339 value যোগ করুন। Offset বাদ দিয়ে শুধু 10:30 লিখলে দিন বদলে যেতে পারে। Daylight-saving প্রযোজ্য jurisdiction হলে source-এর দেখানো offset সংরক্ষণ করুন; অনুমান করবেন না। Rate কত মিনিট দূরে ছিল তা rate_lag_minutes-এ লেখা যায়। কোনো exact payment timestamp না থাকলে time_basis=platform_credit_time বা প্রযোজ্য বিকল্প লিখুন এবং limitation note দিন। Precision দেখানোর জন্য কৃত্রিম second তৈরি করবেন না।

partial payment ও refund-এর value কীভাবে আলাদা হবে?

এক invoice-এ দুই partial receipt এলে প্রত্যেকটির asset amount, event time এবং rate snapshot আলাদা সারিতে থাকবে। পরে refund হলে negative overwrite না করে একটি linked adjustment row বানান; original record অক্ষত রাখুন। Adjustment-এ original record ID, refund hash বা reference, amount, time, selected rate এবং reason লিখুন। Refund-এর rate original payment rate হবে কি refund-time rate হবে—এটি accounting policy; নিজে গোপনে বদলাবেন না। Unknown policy হলে calculated value ফাঁকা রেখে review status দিন। এতে gross receipt, retained amount এবং later adjustment এক সংখ্যায় গুলিয়ে যায় না।

reviewer কীভাবে calculation পুনরায় চালাবেন?

Reviewer প্রথমে amount basis, pair direction, rate source, recorded time ও formula পড়বেন। তারপর raw precision দিয়ে multiplication বা division পুনরায় চালিয়ে display rounding শেষে প্রয়োগ করবেন। আপনার result ও reviewer result না মিললে input transcription, reciprocal direction, decimal separator এবং fee deduction পরীক্ষা করুন। Original row পরিবর্তন না করে correction version তৈরি করুন। checked_by, checked_at, difference ও resolution field রাখলে review trail পরিষ্কার হয়। Self-review হলে সেটিও লিখুন; অন্য ব্যক্তি দেখেছে এমন ধারণা দেবেন না। Reproducible calculation শক্ত record, কিন্তু underlying client relationship বা lawful payment route আলাদাভাবে প্রমাণ করতে হয়।

সম্পাদকীয় সীমা: এই লেখা historical manual valuation record নিয়ে; live rate, conversion service, private exchange, tax determination বা legal approval দেয় না। উৎস 2026-08-10T18:48:47+08:00 পর্যন্ত দেখা হয়েছে। বর্তমান valuation method ও service-export payment route accountant, Bangladesh Bank ও সংশ্লিষ্ট AD-এর কাছে যাচাই করুন।