ইনভয়েস, ক্লায়েন্ট ও পেমেন্ট তারিখ মেলানো

সর্বশেষ হালনাগাদ: 2026-08-12 উৎস যাচাই: 2026-08-12T11:27:09+08:00

ক্লায়েন্টের একটি পেমেন্টকে freelance income হিসেবে ব্যাখ্যা করতে শুধু ইনভয়েস বা transaction hash যথেষ্ট নয়। কাজ, ক্লায়েন্ট, invoice, amount, payment event এবং receiving record-এর মধ্যে যাচাইযোগ্য যোগসূত্র রাখতে হয়। এই পাতার reconciliation table সেই যোগসূত্র গুছিয়ে রাখে; এটি কোনো কর্তৃপক্ষের অনুমোদন বা payment channel-এর বৈধতা ঘোষণা করে না।

এক বাক্যে reconciliation কী?

Reconciliation হলো একই কাজের commercial record, client identity এবং payment evidence-কে shared reference দিয়ে মিলিয়ে দেখা। এর উদ্দেশ্য হলো reviewer যেন বুঝতে পারেন কে কাজ চেয়েছে, কী deliverable ছিল, কত পাওনা ছিল, কখন invoice হয়েছে এবং কোন payment event সেই পাওনার সঙ্গে যুক্ত। Public-chain data client-এর আইনগত নাম বা কাজের উদ্দেশ্য নিজে জানায় না। একইভাবে invoice তৈরি করলেই টাকা পাওয়া প্রমাণ হয় না। দুই দিকের evidence পাশাপাশি থাকলেই chain of evidence তৈরি হয়।

ন্যূনতম মিলের table কেমন হবে?

মিলের স্তর	সংরক্ষিত field	কোন evidence থেকে	অমিল হলে status
ক্লায়েন্ট	client_id, display name, country if needed	contract, email, platform profile	identity_review
কাজ	project_id, scope, delivery reference	agreement, brief, acceptance message	work_unlinked
ইনভয়েস	invoice_number, issue date, due date, amount, currency	original invoice PDF	invoice_mismatch
পেমেন্ট	asset, network, gross amount, hash/reference, block time	explorer বা provider record	payment_review
গ্রহণ	received amount, credit time, account reference	receiving statement	credit_unconfirmed
মূল্য	manual rate, source, rate time, fiat value	saved rate record	valuation_pending

Table-এ blank field গোপনে শূন্য করবেন না। unknown, not_applicable এবং pending আলাদা অর্থ বহন করে।

কোন field হবে shared key?

নিজস্ব record_id ও invoice number মিলের প্রধান internal key; hash সহায়ক payment key। Client-কে invoice number payment memo-তে লিখতে বলা গেলেও সব network বা platform memo সমর্থন করে না। তাই hash-এর ওপর invoice number বসানোর কল্পিত দাবি করবেন না। File name, ledger row ও evidence folder-এ একই record_id রাখুন। একটি invoice-এ একাধিক payment থাকলে INV-108-P1, INV-108-P2 ধরনের installment suffix ব্যবহার করা যায়। একই payment একাধিক invoice cover করলে allocation table দরকার; hash duplicate করে দুইবার income total-এ নেবেন না।

সরকারি Freelancer ID নির্দেশনা কী চায়?

সরকারি Essential Documents পাতা direct বা off-marketplace client-এর ক্ষেত্রে signed contract, work agreement, invoice বা client email-এর মতো valid work-relationship document-এর সঙ্গে corresponding inward-remittance proof চায়। নথিতে applicant-এর নাম, income amount ও transaction date পরিষ্কার থাকা দরকার। এর মানে এই নয় যে যেকোনো invoice বা যেকোনো payment automatically accepted। Portal-এর ভাষা evidence relationship দেখায়: commercial document এবং receipt proof পাশাপাশি রাখতে হবে।

client identity কেন hash থেকে নেবেন না?

Blockchain sender address একটি address; সেটি client-এর verified legal identity নয়। Ethereum-এর official transaction documentation sender, recipient, value, signature ও transaction hash-এর মতো field ব্যাখ্যা করে, কিন্তু freelance client-এর নাম বা invoice number দেয় না। Client অন্য payer, treasury বা platform ব্যবহার করতে পারে। এই ব্যবধান contract, client email, platform payout statement বা লিখিত payer explanation দিয়ে নথিভুক্ত করুন। Address দেখেই কোনো ব্যক্তি বা প্রতিষ্ঠানকে চূড়ান্তভাবে চিহ্নিত করবেন না।

কাজের সম্পর্ক কীভাবে দেখাবেন?

Scope, delivery এবং acceptance—এই তিনটি record client-payment সম্পর্ককে বাস্তব কাজের সঙ্গে বাঁধে। Brief বা contract-এ service description, agreed amount, currency ও milestone রাখুন। Delivery-এর জন্য file receipt, repository reference, email বা platform submission ID ব্যবহার করা যায়; গোপন client data অপ্রয়োজনীয়ভাবে copy করবেন না। Acceptance স্পষ্ট না হলে client acknowledgment বা revision closure রাখুন। Government application guide legitimate freelance বা digital-service activity থেকে verified income চায় এবং application review-এর কথা বলে। Payment একা legitimate activity প্রমাণ করে না।

invoice-এ কোন তথ্য রাখবেন?

Invoice-এ seller/applicant identity, client reference, unique number, issue date, service description, amount এবং currency স্পষ্ট রাখুন। Due date, milestone, fee bearer ও payment terms প্রযোজ্য হলে যোগ করুন। কোনো asset-এ payment আলোচনা হলেও invoice currency ও settlement asset আলাদা field করুন। পরে amount বদলালে original invoice overwrite না করে credit note বা revised version দিন। PDF-এর metadata নয়, visible content reviewer-এর জন্য প্রধান। Invoice number পুনরায় ব্যবহার করবেন না; duplicate number থাকলে chronology বিভ্রান্ত হয়।

invoice date ও payment date কি একই?

না—issue date, due date, sent time, block time এবং account-credit time পাঁচটি আলাদা ঘটনা হতে পারে। Ethereum blocks documentation block-এ transaction data ও timestamp থাকার কথা বলে। সেই block time chain observation-এর anchor হতে পারে; এটি invoice issue date বা client acceptance date নয়। Ledger-এ প্রতিটি time RFC3339 offset-সহ রাখুন। Explorer UTC দেখালে raw UTC ও normalized local display আলাদা রাখা যায়। শুধু screenshot-এর device clock payment time হিসেবে ব্যবহার করবেন না।

কোন payment date রিপোর্ট করবেন?

আপনার policy যে event-কে payment date বলে, সেটি নামসহ লিখুন এবং raw alternatives রাখুন। chain_block_time, provider_credit_time, bank_credit_time ও recorded_at field পৃথক হতে পারে। Tax, banking বা application purpose-এ কোন date গ্রহণযোগ্য তা সংশ্লিষ্ট authority, accountant বা AD নির্ধারণ করতে পারে। Site কোনো accounting basis বেছে দেয় না। Exact timestamp না থাকলে minute বা second বানাবেন না; available date এবং limitation note দিন। Policy বদলালে effective date ও version লিখুন।

amount কীভাবে মিলাবেন?

Expected, sent, received এবং allocated amount আলাদা রাখুন। Invoice amount USD-তে, settlement asset USDT-তে এবং receiving credit fee কাটার পরে হতে পারে। expected_invoice_amount, gross_asset_amount, received_asset_amount, allocated_asset_amount এবং variance লিখুন। Variance দেখলেই network fee ধরে নেবেন না; platform deduction, rounding, partial payment, refund বা data-entry error হতে পারে। Rate দরকার হলে manual source/time record ব্যবহার করুন। Unknown fee-কে zero করা বা amount মিলানোর জন্য ভুয়া adjustment row তৈরি করা যাবে না।

partial payment কীভাবে reconcile করবেন?

প্রতিটি partial receipt আলাদা payment row, কিন্তু সব row একই invoice group-এর অংশ। Installment number, expected share, actual amount, payment time ও hash/reference রাখুন। যোগফল invoice total না হলে outstanding balance দেখান। একটি installment অন্য invoice-এ reallocate করলে change log লিখুন। Month boundary পার হলে payment event নিজ নিজ মাসে থাকবে; invoice summary পুরো relationship দেখাবে। Client একটি combined transfer করলে allocation rule লিখুন এবং allocated total কখনও received amount ছাড়াবে না।

overpayment বা underpayment কীভাবে লিখবেন?

অমিলকে আড়াল না করে exception হিসেবে রাখুন। Underpayment-এর কারণ client deduction, fee, rate misunderstanding বা missing installment হতে পারে। Overpayment advance, tip, ভুল amount বা অন্য invoice-এর টাকা হতে পারে। Client-এর লিখিত confirmation ছাড়া নিজের সুবিধামতো classification করবেন না। Refund হলে original receipt delete না করে linked refund/adjustment record যোগ করুন। variance_status, reviewed_by, reviewed_at ও resolution reference রাখুন। Unresolved amount official application total-এ ধরার আগে reviewer-এর নির্দেশ নিন।

receiving credit কেন আলাদা প্রমাণ?

Successful transaction এবং আপনার usable account credit একই evidence স্তর নয়। Hash network execution দেখাতে পারে, আর platform statement নির্দিষ্ট account-এ credit দেখাতে পারে। Receiving platform asset-network pair সমর্থন না করলে successful chain event-ও balance-এ নাও দেখা যেতে পারে। Statement-এ account identity, amount, asset ও credit time থাকলে restricted evidence folder-এ রাখুন। Public report-এ full address বা account identifier অপ্রয়োজনীয় হলে mask করুন; original secure copy অক্ষত রাখুন। Secret, password, private key বা seed phrase কখনও evidence নয়।

inward-remittance evidence কোথায় আলাদা?

Bangladesh-এর current fiat service-export path-এ inward-remittance message ও AD verification আলাদা institutional evidence। Bangladesh Bank-এর FEPD-1 Circular No. 26 Part K-তে email, contract, invoice if available, platform statement বা digital communication-এর সঙ্গে inward-remittance message ব্যবহার করে AD verification ও recordkeeping-এর কথা আছে। এই fiat/foreign-exchange route-কে USDT গ্রহণের অনুমতি হিসেবে পড়া যাবে না। Payment channel ও current handling সংশ্লিষ্ট Authorized Dealer-এর কাছে আগে যাচাই করুন।

public-chain record কি customer file?

না—transfer data ও customer identity records পরস্পর সহায়ক, কিন্তু একে অপরের বিকল্প নয়। FATF-এর virtual-assets overview covered service providers-এর context-এ originator/beneficiary information ও recordkeeping-এর গুরুত্ব ব্যাখ্যা করে। Freelancer-এর local worksheet কোনো VASP compliance system নয়। Practical lesson হলো bare wallet address-কে পূর্ণ client profile ধরে না নেওয়া। আপনি যে data আইনসঙ্গত ও প্রয়োজনীয়ভাবে রাখতে পারেন শুধু সেটিই রাখুন এবং access সীমিত করুন।

reconciliation status কী কী হবে?

Status এমন হতে হবে যাতে next action বোঝা যায়। উদাহরণ:

• draft — invoice বা কাজের record এখনও অসম্পূর্ণ;
• payment_seen — transaction/reference দেখা গেছে, credit বাকি;
• credit_confirmed — receiving record আছে, allocation বাকি;
• reconciled — client, work, invoice, payment ও amount মিলেছে;
• exception — mismatch ব্যাখ্যা বা correction দরকার;
• excluded — এটি income নয় বা duplicate;
• institutional_review — AD, authority বা professional review বাকি।

Status “approved” রাখবেন না যদি কোনো authority সত্যিই approval না দেয়।

evidence folder কীভাবে সাজাবেন?

একটি record-এর সব file index-সহ রাখুন, কিন্তু original ও shareable copy আলাদা করুন। উদাহরণ structure:

2026-08/INV-108/
  01-agreement/
  02-delivery-acceptance/
  03-invoice/
  04-payment-network/
  05-receiving-credit/
  06-valuation/
  07-review-log/

Readme-তে file purpose, source, captured_at, redaction ও known gap লিখুন। Folder name evidence নয়; ভিতরের file ও linkage যাচাই করতে হবে। Client confidential material public storage-এ দেবেন না।

correction করলে audit trail কী থাকবে?

Original value, corrected value, reason, editor ও timestamp সংরক্ষণ করুন। Invoice typo হলে revised invoice link করুন; payment hash ভুল হলে original entry retain করে correction status দিন। Screenshot crop বা rename করার ফলে source context হারালে original file রাখুন। CSV export version number দিন। Quiet overwrite reviewer-কে বোঝাতে দেয় না কোন তথ্য কখন বদলেছে। Self-review হলে সেটি লিখুন; অন্য কেউ যাচাই করেছে এমন impression দেবেন না।

মাস শেষে কোন totals দেখবেন?

Invoice total, verified receipt total, allocated income total, outstanding এবং unresolved variance আলাদা report করুন। এগুলো একই সংখ্যা হওয়া বাধ্যতামূলক নয়। Client count বা hash count income amount নয়। Fiat value থাকলে valuation policy ও rate time যুক্ত করুন। Cancelled invoice, self-transfer, refund ও duplicate payment verified income থেকে আলাদা রাখুন। Summary-এর প্রতিটি total underlying record_id-তে drill down করা উচিত। এক মাসের closing report পরে বদলালে revision note তৈরি করুন।

reviewer-এর আট ধাপ কী?

1. Client ও applicant name/reference নথিতে consistent কি না দেখুন।
2. Scope ও delivery invoice-এর service description-এর সঙ্গে মিলান।
3. Invoice number, amount, currency, issue date ও due date পড়ুন।
4. Payment asset, network, amount, hash/reference ও event time যাচাই করুন।
5. Receiving credit record আলাদাভাবে দেখুন।
6. Partial allocation ও duplicate পরীক্ষা করুন।
7. Manual valuation থাকলে source, direction, time ও formula পুনরায় চালান।
8. Missing field, exception ও applicable institutional requirement লিখুন।

Checklist pass মানে internal consistency; legal বা government acceptance guarantee নয়।

কখন record-কে reconciled বলবেন না?

Client relationship অজানা, কাজের evidence নেই, invoice amount বদলানো, hash ভুল network-এর, credit দেখা যায়নি, duplicate allocation আছে বা current payment route যাচাই হয়নি—এই অবস্থায় reconciliation বন্ধ রাখুন। Deadline-এর জন্য missing field বানিয়ে দেবেন না। Client-এর কাছ থেকে clarification চাইতে পারেন, platform-এর official support record রাখতে পারেন এবং Bangladesh-specific rule AD-এর কাছে যাচাই করতে পারেন। Private exchange, transaction concealment বা regulatory evasion কোনো reconciliation method নয়।

invoice বাতিল হলে payment record কী হবে?

Cancelled invoice delete না করে cancellation reason ও date রাখুন। Payment না এলে status cancelled_unpaid; payment আগে এলে refund, credit note বা replacement invoice-এর সঙ্গে link দরকার। একই কাজের revised invoice তৈরি হলে predecessor number লিখুন। Client cancellation email এবং delivery status আলাদা evidence। মাসিক summary-তে cancelled face value income total-এ নয়, কিন্তু audit trail-এ থাকবে। এতে invoice gap দেখে reviewer হারানো payment খুঁজবেন না।

এক payer বহু client cover করলে কী করবেন?

Payer ও client এক entity না হলে relationship explanation অপরিহার্য। Agency, parent company, marketplace বা payroll provider client-এর হয়ে pay করতে পারে। Agreement, email confirmation বা provider statement-এ কে payer এবং কোন invoice cover করছে রাখুন। একটি payer address দেখে সব client একই বলে merge করবেন না। client_id, payer_id ও relationship_basis আলাদা field ব্যবহার করুন। Explanation না পাওয়া পর্যন্ত record identity_review রাখুন এবং income proof-এ certainty বাড়িয়ে লিখবেন না।

এক payment বহু invoice cover করলে allocation কী হবে?

একটি allocation table total received amount-কে invoice-wise ভাগ করবে। প্রতিটি row-তে invoice number, allocated amount, currency basis, decision date ও client confirmation রাখুন। Allocated rows-এর sum received total-এর বেশি হতে পারবে না। Remaining amount unallocated থাকবে; সুবিধামতো পুরোনো invoice-এ বসাবেন না। Client যে order দিয়েছে সেটি অনুসরণ করুন, না থাকলে written allocation চান। পরে allocation বদলালে original version retain করুন।

retainer payment কীভাবে মিলবে?

Retainer receipt ও earned invoice একই event নয়। Advance পাওয়ার সময় receipt record করুন, কিন্তু service earned হওয়ার policy আলাদাভাবে document করুন। পরের invoice-এ retainer applied amount, remaining balance ও reference দিন। Chain hash বা bank credit advance receipt দেখাতে পারে; কোন work period cover করে তা contract বলে। Tax/accounting treatment professional নির্ধারণ করবেন। Retainer-কে একই মাসে full earned income ধরে নেওয়া এই worksheet-এর কাজ নয়।

milestone acceptance না থাকলে কী করবেন?

Delivery evidence থাকলেও acceptance missing হলে সেই gap স্পষ্ট রাখুন। Client silence-কে acceptance বলার contract clause থাকলে exact clause ও elapsed period reference করুন; না থাকলে confirmation চান। Payment এসেছে বলে সব deliverable accepted infer করবেন না। Disputed milestone-এর invoice, revision message ও payment allocation আলাদা রাখুন। Partial acceptance হলে accepted scope ও disputed scope লিখুন। Evidence chain facts সাজায়, legal dispute resolve করে না।

currency mismatch কীভাবে ধরবেন?

Invoice currency, payment asset এবং reporting currency তিনটি আলাদা column। USD invoice-এর বিপরীতে অন্য denomination এলে agreed conversion source/time দরকার। Rate ছাড়া apparent overpayment বা underpayment গণনা করবেন না। Client quantity পাঠিয়েছেন কিন্তু fiat target উল্লেখ নেই—এমন হলে written clarification চান। Reconciliation sheet কোনো live rate আনে না। Manual valuation-এর source, direction, captured time ও calculation record link করুন; rate assumption invoice-এ silently বসাবেন না।

timezone boundary-তে কোন মাস নেবেন?

Raw event time offset-সহ রাখুন, তারপর declared reporting timezone policy প্রয়োগ করুন। UTC block time এক মাসে, local credit time পরের মাসে পড়তে পারে। দুটির একটিকে মুছে দিলে chronology হারায়। Monthly report কোন basis ব্যবহার করছে header-এ লিখুন। Policy consistent রাখুন এবং boundary exception list করুন। Authority বা accountant অন্য basis চাইলে তাদের নির্দেশ অনুসারে derived report বানান; original timestamp অপরিবর্তিত থাকবে।

evidence share করার আগে privacy review কী?

Reviewer-এর কাজের জন্য যতটুকু দরকার ততটুকুই share করুন। NID, full address, client email, contract clause ও bank details sensitivity অনুযায়ী classify করুন। Original secure copy থেকে redacted working copy বানালে redaction log রাখুন। Transaction hash public হলেও client identity-এর সঙ্গে join করলে profile তৈরি হয়। Access expiry ও recipient list লিখুন। Password একই message-এ পাঠাবেন না এবং private key কখনও চাইবেন না।

annual review-এ কী খুঁজবেন?

Repeated exception pattern process-এর দুর্বলতা দেখায়। কত invoice payer mismatch, missing acceptance, late credit, unresolved variance বা duplicate entry ছিল count করুন। Individual client-এর sensitive details summary-তে দেবেন না। Common cause দেখে invoice template বা confirmation card উন্নত করুন। Historical records retroactively rewrite করবেন না। Policy version ও effective date যোগ করুন। Improvement metric approval rate বা legal safety নয়; এটি internal record quality মাত্র।

reconciliation table-এর সীমা কোথায়?

Table consistency দেখায়, authenticity নয়। সব field neatly match করলেও forged invoice, compromised account বা prohibited payment route সম্ভব। Source document validity, institutional checks ও current law আলাদা। Automated matching false positive দিতে পারে; spelling বা amount match হলেই person verified নয়। Manual reviewer evidence context দেখবেন। Uncertainty থাকলে status open রাখুন এবং responsible authority-এর guidance নিন।

client confirmation-এর ভাষা কেমন হবে?

Confirmation-এ invoice number, service, payer, amount ও payment reference একসঙ্গে লিখুন। “Paid” এক শব্দের বদলে client-কে exact record confirm করতে বলুন। Reply missing হলে সেটিকে implied confirmation করবেন না। Email thread export করার সময় header, sender ও date বজায় রাখুন। Forwarded message original sender authentication নয়। Material correction এলে নতুন confirmation চান এবং old reply archive করুন।

automated spreadsheet check কী করতে পারে?

Formula duplicate ID, amount sum, empty required field ও invalid date format ধরতে পারে। এটি client identity, document authenticity বা lawful route বিচার করতে পারে না। Conditional formatting exception highlight করবে, approval নয়। Formula version lock করুন এবং export-এর আগে spot-check করুন। Hidden row বা filtered total reviewer-কে ভুল result দিতে পারে; plain CSV ও readme দিন। Macro বা external link ছাড়া local calculation সহজে review করা যায়।

handover note-এ কী থাকবে?

Reviewer-কে scope, policy ও known gaps আগে জানান। Note-এ reporting period, date basis, valuation method, included invoice count, unresolved exception এবং sensitive-file access লিখুন। “সব verified” লিখবেন না যদি institutional check বাকি। Delivered file list ও checksum optional integrity aid হতে পারে। Reviewer receipt decision নয়। Question/answer log রাখলে পরের correction trace করা যায়।

শেষ নীতি কী?

একটি শক্ত income record তিনটি প্রশ্নের উত্তর দেয়: কাজটি কার জন্য, কত পাওনা ছিল, এবং কোন যাচাইযোগ্য payment event সেই পাওনার সঙ্গে যুক্ত? Invoice commercial claim, hash technical locator, receiving statement account credit, আর inward-remittance record institutional channel দেখাতে পারে। এগুলো একত্রে context দেয়; কোনো একটিকে সবকিছুর প্রমাণ বানাবেন না।

সম্পাদকীয় সীমা: এটি evidence-reconciliation guide, legal, tax বা accounting advice নয়। কোনো payment channel অনুমোদন, USDT গ্রহণ, cash-out, private exchange বা নিয়ম এড়ানোর নির্দেশ দেয় না। সরকারি ও protocol উৎস 2026-08-12T11:27:09+08:00 পর্যন্ত পুনরায় দেখা হয়েছে; current requirement সংশ্লিষ্ট authority, accountant ও Authorized Dealer-এর কাছে যাচাই করুন।