ই-ইনভয়েসিং বাধ্যবাধকতা ২০২৬–২০২৮: বাড়তে থাকা ব্যবসার সফটওয়্যারে কী লাগবে

২০২৬ সালের সেপ্টেম্বরের এক সোমবার ৪০ জনের একটি পাইকারি ব্যবসার ফাইন্যান্স ম্যানেজার একটি ছোট email পড়ছেন। তাঁর সবচেয়ে বড় ক্রেতা সদ্য structured invoices issue ও গ্রহণ শুরু করেছে। তাদের accounts payable টিম জানাল, মাসে যে ৬০০টি invoices যায়, সেগুলো এখন থেকে PDF নয়, machine-readable ফাইল হিসেবে চাই। (এটি একটি কাল্পনিক দৃশ্য, কোনো বাস্তব প্রতিষ্ঠান নয়।)

তাঁর system শুধু PDF বানাতে পারে। ৬০০টি invoices হাতে type করতে প্রতিটিতে দশ মিনিট লাগলেও মাসে ১০০ ঘণ্টা চলে যায়, আর একটা tax ID ভুল হলেই invoice ফেরত আসে।

e-invoicing আগে data-র সমস্যা, তারপর compliance-র। বিভিন্ন দেশের সরকার এখন structured invoices চাইছে: যে file মানুষের সাহায্য ছাড়াই computer পড়তে পারে, আর যা প্রায়ই কোনো network বা tax authority-র platform ঘুরে যায়। order record থেকে পরিষ্কারভাবে এই file বানাতে না পারলে software প্রতিটি invoice-কে হাতের কাজ বানিয়ে ফেলে।

আপনি যদি অন্য ব্যবসার কাছে বিক্রি করেন, তাদের কাছ থেকে কেনেন, কিংবা দুটোই করেন, তাহলে এই লেখার তারিখগুলো আপনার জন্যও গুরুত্বপূর্ণ হতে পারে, এমনকি দেশের বাইরে পা না রাখলেও। বিদেশি কোনো supplier হঠাৎ আপনাকে structured invoices পাঠাতে শুরু করতে পারে, আবার কোনো customer আপনার PDF আর গ্রহণ নাও করতে পারেন।

এই লেখায় আছে e-invoicing-এর বিভিন্ন মডেলের পার্থক্য, ২০২৬ থেকে ২০২৮ (এবং তার একটু পরের) প্রধান বাধ্যবাধকতার সময়রেখা, আর আপনার invoicing বা ERP software-কে কী কী পারতে হবে তার তালিকা। তারিখগুলো ২০২৬ সালের আগস্ট পর্যন্ত সরকারি ও পেশাদার সূত্র মিলিয়ে যাচাই করা। এই ক্ষেত্রে rule আর deadline প্রায়ই বদলায়, তাই timeline-টাকে map হিসেবে দেখুন, legal advice হিসেবে নয়।

কোনটা e-invoice, কোনটা নয়

Email-এ পাঠানো PDF একটা electronic document ঠিকই, কিন্তু এই law-গুলোর অর্থে সেটা e-invoice নয়। e-invoice হলো একটা fixed, machine-readable format-এর file, যেখানে প্রতিটি field-এর অর্থ ঠিক করা থাকে: seller tax ID, buyer tax ID, line items, tax rate, tax amount, payment terms।

ইউরোপে সবচেয়ে প্রচলিত standard EN 16931। এটি ঠিক করে দেয় একটা invoice-এ কোন কোন data থাকতে হবে। এটি প্রকাশ করা হয় দুটি প্রধান syntax-এ, UBL আর UN/CEFACT CII; দুটোই XML। অনেক দেশে ব্যবহৃত Peppol BIS Billing 3.0 UBL-এর ওপর দাঁড়িয়ে আছে এবং EN 16931 মেনে চলে। ইউরোপের বাইরে দেশগুলো প্রায়ই নিজস্ব format ঠিক করে, তবে ধারণাগুলো বেশির ভাগ ক্ষেত্রে একই।

Hybrid file-ও গ্রহণযোগ্য হতে পারে, যেমন ভেতরে XML বসানো PDF (Factur-X বা ZUGFeRD)। কারণ আসল invoice হলো ওই XML, আর PDF শুধু পড়ার সুবিধার জন্য একটা copy।

e-invoices যে তিন পথে চলে

Format বলে দেয় invoice-র ভেতরে কী আছে। Model বলে দেয় invoice seller-র কাছ থেকে buyer-র কাছে কীভাবে পৌঁছায় এবং পথে কে সেটা দেখে। আপনার সামনে তিনটি model আসবে।

Post-audit

Seller একটি structured invoice তৈরি করে agreed পথে পাঠান। ওই মুহূর্তে tax authority process-এ থাকে না। তারা data পায় পরে, periodic report-এর মাধ্যমে, কিংবা audit-এর সময় invoice check করে। Seller-র জন্য এটি সবচেয়ে হালকা model, তবে error ধরা পড়ে ঘটনার পরে।

Clearance

Invoice আগে যায় tax authority-র platform-এ। Platform সেটা validate করে, একটা unique ID ও approval দিতে পারে, তারপরই সেটা buyer-র কাছে পৌঁছায়। পোল্যান্ডের KSeF আর সৌদি আরবের integration phase এই ধাঁচেই চলে। প্রতিটি invoice-র clear status পাওয়া যায়, কিন্তু platform available থাকার ওপর depend করতে হয়, তাই fallback একটা process design-র অংশ হওয়া উচিত।

Peppol আর চার-কোনার মডেল

Peppol একটি open network, যা চালায় OpenPeppol association। প্রতিটি buyer-র সঙ্গে আলাদা করে connect হতে হয় না; আপনি connect হন একটিমাত্র certified access point-এ। সেই access point buyer-র access point খুঁজে নিয়ে invoice-টা deliver করে। Corner ১ আপনার system, corner ২ আপনার access point, corner ৩ buyer-র access point, corner ৪ buyer-র system। কিছু দেশ পঞ্চম একটি corner যোগ করে: data-র একটি copy যায় tax authority-র কাছে।

অনেক দেশ এই ধারণাগুলো মিশিয়ে ব্যবহার করে। কোনো দেশ হয়তো exchange-এ Peppol ব্যবহার করে, আবার তার ওপর real-time reporting-ও চাপায়। তাই শুধু deadline নয়, যে যে market-এ ব্যবসা করেন, সেখানকার model-টাও দেখে নিন। Network-টি সম্পর্কে আরও জানতে পারেন peppol.org-এ।

২০২৫ থেকে ২০৩০: সময়রেখা

নিচের টেবিলে প্রধান বাধ্যবাধকতাগুলো আছে। এটি একটি বাছাই করা তালিকা, পূর্ণাঙ্গ নয়। অনেক দেশে B2G (ব্যবসা থেকে সরকার) নিয়ম আগেই চালু হয়েছে, আবার কিছু দেশ এখনো আইন লিখছে।

দেশ বা অঞ্চল	কী শুরু হচ্ছে	প্রধান তারিখ	মডেল
জার্মানি	স্ট্রাকচার্ড invoice গ্রহণ, তারপর ইস্যু (দেশীয় B2B)	গ্রহণ: সব ব্যবসার জন্য ১ জানুয়ারি ২০২৫ থেকে। ইস্যু: আগের বছরের টার্নওভার €৮,০০,০০০-এর বেশি হলে ১ জানুয়ারি ২০২৭; সবার জন্য ১ জানুয়ারি ২০২৮	ফরম্যাটভিত্তিক, কেন্দ্রীয় platform নেই
বেলজিয়াম	VAT-নিবন্ধিত ব্যবসার মধ্যে স্ট্রাকচার্ড B2B ইনভয়েসিং	১ জানুয়ারি ২০২৬। রিয়েল-টাইম রিপোর্টিং পরিকল্পনায় আছে ২০২৮-এর জন্য	Peppol BIS 3.0 সুপারিশকৃত
ক্রোয়েশিয়া	রিয়েল-টাইম ফিসক্যালাইজেশনসহ B2B e-invoicing	VAT-নিবন্ধিত ব্যবসার জন্য ১ জানুয়ারি ২০২৬	আদান-প্রদান আর কর কর্তৃপক্ষকে রিপোর্টিং
পোল্যান্ড	জাতীয় KSeF system	PLN ২০ কোটির বেশি টার্নওভারে ১ ফেব্রুয়ারি ২০২৬; অন্য VAT-নিবন্ধিত ব্যবসার জন্য ১ এপ্রিল ২০২৬; ক্ষুদ্র উদ্যোক্তা ও জরিমানা ১ জানুয়ারি ২০২৭ থেকে	Clearance
ফ্রান্স	অনুমোদিত platform-এর মাধ্যমে গ্রহণ; ধাপে ধাপে ইস্যু	১ সেপ্টেম্বর ২০২৬: সব ব্যবসা গ্রহণ করবে; বড় ও মাঝারি কোম্পানি ইস্যু করবে। ১ সেপ্টেম্বর ২০২৭: SME ও ক্ষুদ্র ব্যবসা ইস্যু করবে	অনুমোদিত platform ও একটি কেন্দ্রীয় ডিরেক্টরি
স্পেন	রয়্যাল ডিক্রি ২৩৮/২০২৬ অনুযায়ী B2B e-invoicing	প্রকাশিত ৩১ মার্চ ২০২৬। একটি মন্ত্রণালয়ীয় আদেশ জারির ১২ মাস পর (টার্নওভার €৮ মিলিয়নের বেশি) অথবা ২৪ মাস পর (অন্যরা); আদেশটি এখনো বাকি। আলাদা Verifactu বিলিং-software নিয়ম: ১ জানুয়ারি ২০২৭ ও ১ জুলাই ২০২৭	সরকারি platform ও আন্তঃসংযোগযোগ্য বেসরকারি platform
সংযুক্ত আরব আমিরাত	জাতীয় e-invoicing system	১ জুলাই ২০২৬ থেকে ঐচ্ছিক; AED ৫ কোটি বা তার বেশি টার্নওভারে ১ জানুয়ারি ২০২৭ থেকে বাধ্যতামূলক; অন্য ব্যবসা ২০২৭-এর পরের দিকে	Peppol-ভিত্তিক, অনুমোদিত সার্ভিস প্রোভাইডার
সৌদি আরব	ধাপে ধাপে ZATCA ফেজ ২ (integration)	ওয়েভ ২৪ (SAR ৩,৭৫,০০০-এর বেশি): ৩০ জুন ২০২৬-এর মধ্যে। ওয়েভ ২৫ (SAR ১,৮৭,৫০০-এর বেশি): ১ ফেব্রুয়ারি ২০২৭-এর মধ্যে	Clearance ও রিপোর্টিং
মালয়েশিয়া	টার্নওভার অনুযায়ী ধাপে ধাপে MyInvois	সবচেয়ে বড়দের জন্য ১ আগস্ট ২০২৪ থেকে। RM১ মিলিয়নের নিচে অব্যাহতি। RM১–৫ মিলিয়ন স্তরের জন্য জরিমানাহীন শিথিলতার সময় ৩১ ডিসেম্বর ২০২৭ পর্যন্ত	কর কর্তৃপক্ষের যাচাই
ইউরোপীয় ইউনিয়ন	ViDA: সীমান্ত পেরোনো B2B লেনদেনে e-invoicing ও ডিজিটাল রিপোর্টিং	গৃহীত হয়েছে মার্চ ২০২৫-এ। কার্যকর ১ জুলাই ২০৩০ থেকে; সদস্য দেশ চাইলে দেশীয় নিয়ম আগেও চালু করতে পারে	স্ট্যান্ডার্ড হিসেবে EN 16931

নিজের দেশের rule যাচাই করুন। Threshold প্রায়ই আগের বছরের turnover-র ওপর ঠিক হয়, grace period আর enforcement date আলাদা হতে পারে, আর কিছু দেশ ইতিমধ্যে এক-দুবার deadline সরিয়েছে (মালয়েশিয়া ও স্পেন দুজনেই)। পরিকল্পনা করার আগে আপনার tax authority-র latest guidance পড়ুন, অথবা accountant-র সঙ্গে কথা বলুন।

Mandate ঠিকভাবে পড়বেন কীভাবে

চারটি প্রশ্ন একটা headline-কে action plan-এ বদলে দেয়।

• Receive, নাকি issue? জার্মানি ও ফ্রান্স আগে receive বাধ্যতামূলক করেছে। ছোট ব্যবসাকেও structured invoices পাঠাতে বাধ্য হওয়ার আগে সেটা open করতে ও process করতে পারতে হবে।
• কোন transaction? বেশির ভাগ mandate শুধু domestic B2B-র জন্য। B2C আর cross-border sales সাধারণত আলাদা rule-এ পড়ে, যেখানে প্রায়ই e-invoicing নয়, e-reporting চাওয়া হয়।
• কোন size? Turnover-র threshold ঠিক করে আপনি কোন wave-এ পড়বেন। Threshold-র কাছাকাছি থাকলে earlier date ধরেই পরিকল্পনা করুন।
• Penalty কখন শুরু? গ্রেস পিরিয়ডে জরিমানা ছাড়াই পরীক্ষা চালানো যেতে পারে। যেমন পোল্যান্ড জরিমানা চালু করছে ২০২৭-এর জানুয়ারি থেকে, আর মালয়েশিয়ায় ছোট করদাতাদের জন্য শিথিলতার সময় আছে। জরিমানা থাক বা না থাক, নিয়ম না মানা invoice ক্রেতা ফিরিয়ে দিতে পারেন।

শেষ কথাটা বাস্তবে খুব গুরুত্বপূর্ণ। রাষ্ট্র ধৈর্য ধরলেও বড় buyer-র accounts payable টিম ধৈর্য ধরে না। তাদের structured invoices নিতে হলে তারা আপনার কাছে সেটাই চাইবে।

আপনার invoicing বা ERP software-কে কী পারতে হবে

Mandate-গুলো দেখতে আলাদা, কিন্তু software-র কাছে requirement প্রায় একই রকম। নিজের system-কে এই checklist-র সঙ্গে মিলিয়ে দেখুন।

Structured data, extra step-সহ PDF নয়

Order বা sales record থেকেই invoice তৈরি হতে হবে structured data হিসেবে: ইউরোপের জন্য UBL বা CII-তে EN 16931, অন্য জায়গায় local format। Risk-র জায়গা হলো এমন system, যা আগে PDF বানায়, তারপর third-party tool দিয়ে সেই PDF পড়ে XML বানায়। প্রতিটি conversion-এ accuracy হারায়। ভালো design-এ PDF আর structured invoice দুটোই আসে একই record থেকে, ফলে দুটোর মধ্যে mismatch হওয়ার সুযোগ থাকে না।

Master-data quality

Structured invoices-এ কোনো leniency নেই। Tax ID না থাকলে, country code ভুল হলে, কিংবা address ভুল field-এ free-text-এ লেখা থাকলে invoice রিজেক্ট হয়ে আসে। কোনো mandate-র তারিখ আসার আগেই এগুলো ঠিক করে নিন:

• Customer ও supplier-র tax ID, কর্তৃপক্ষ যেখানে validation দেয় সেখানে validation-সহ;
• Legal name আর structured address, যেখানে country, city ও postcode আলাদা field-এ;
• দেশ যেখানে ব্যবহার করে সেখানে রাউটিং আইডেন্টিফায়ার, যেমন Peppol ID বা বায়ার রেফারেন্স;
• প্রতিটি পণ্য ও সেবার ট্যাক্স ক্যাটাগরি আর অব্যাহতির কারণ।

Numbering, credit notes আর corrections

বেশির ভাগ regime-এ invoice number unique ও sequential হতে হয়, আর cleared invoice সাধারণত edit করা যায় না। Error ঠিক করতে হয় original invoice-র reference-সহ একটি credit note দিয়ে, তারপর নতুন invoice। আপনার software-এ চাই original invoice number-র সঙ্গে linked proper credit-note flow, "delete আর reissue" button নয়। Partial credit, price correction আর return সবই এই পথ ধরে চলে।

Status tracking আর rejections

Network-based system-এ "sent" মানেই গল্পের শেষ নয়। Invoice accepted, rejected, queued, বা payment approval-র জন্য থাকতে পারে। আপনার software-র উচিত প্রতিটি invoice-র status store করা, যারা payment follow-up করেন তাদের দেখানো, আর rejection এলে alert করা। Rejection-এর সঙ্গে থাকা উচিত readable reason এবং fix করে resubmit-র clear way, log-এর stack trace নয়।

নিচের চিত্রে একটি invoice-কে clearance system-এর ভেতর দিয়ে যেতে দেখা যায়। দুটি checkpoint-এ রিজেক্ট হতে পারে, আর দুই ক্ষেত্রেই শেষে একই কাজ: data fix করা।

Archiving আর audit trail

Legal original এখন structured file-টিই, তাই legal retention period পর্যন্ত সেটাই unaltered রাখতে হবে। Retention period দেশভেদে আলাদা, আর কিছু দেশে সম্প্রতি বদলেছেও (জার্মানি ২০২৫ সালে invoice সংরক্ষণের মেয়াদ কমিয়ে আট বছর করেছে)। খুঁজে দেখুন মূল ফাইলের অপরিবর্তনীয় সংরক্ষণ আছে কি না, কে কী বদলেছে তার রেকর্ড আছে কি না, আর audit-এর সময় চাইলেই এক্সপোর্ট করা যায় কি না।

Connectivity আর APIs

আপনার system-কে external system-র সঙ্গে talk করতে হবে: একটি access point, approved platform, বা tax authority-র API। Ask করুন কীভাবে connect হয়। ভালো setup-এ multiple provider support করে, invoice rebuild না করে provider switch করা যায়, timeout-র পর safely retry হয়, আর same invoice কখনো দুবার যায় না। Authentication certificate আর token-ও expire হয়, তাই renewal-র responsibility কারও থাকতে হবে।

Multiple countries-এ ব্যবসা

Cross-border বিক্রি করলে একসঙ্গে different format, model আর deadline-র সঙ্গে মোকাবিলা করতে হয়। Software-এ country-wise rule থাকা উচিত configuration হিসেবে, custom code branch হিসেবে নয়, যাতে নতুন market যোগ করতে invoicing rewrite না করতে হয়। Multi-currency, multi-entity numbering আর country-specific tax rate একসঙ্গে কাজ করতে হবে।

Readiness checklist

দ্রুত self-assess করতে এটি ব্যবহার করুন। এর বেশ কয়েকটির উত্তর "no" বা "don't know" হলে আজই শুরু করুন।

• আমরা জানি country আর নিজেদের turnover ধরে কোন কোন mandate আমাদের ওপর applicable।
• আমরা জানি প্রতিটি receive-only, issue-only, নাকি উভয়ই, আর penalty কবে শুরু।
• আমাদের system সরাসরি order থেকে structured invoices (EN 16931 বা local format) generate করতে পারে।
• অন্তত top customers আর suppliers-র tax ID আর structured address complete।
• Credit notes original invoice-র সঙ্গে linked এবং required reference carry করে।
• প্রতিটি sent invoice-র status visible, আর rejection এলে alert পাওয়া যায়।
• Received structured invoices automatically readable, manual retyping need নেই।
• Original structured files legal period পর্যন্ত unaltered store থাকে।
• Access point বা platform connection আর এর certificate-র জন্য আমাদের একজন named owner আছেন।
• Deadline-র আগে আমরা whole flow sandbox-এ test করেছি।

Six-step project plan

বেশির ভাগ growing businesses-র জন্য কাজটা এক-দুই quarter-এই হয়ে যায়। এই sequence-এ এগোলে কাজটা manageable থাকে।

1. আপনার obligation-গুলো map করুন। যেসব দেশে invoice করেন বা যাদের থেকে কেনেন, প্রতিটির mandate, আপনার wave আর penalty-র start date লিখুন। nearest date-টা calendar-এ বসিয়ে backward work করুন।
2. Invoice flow audit করুন। আজ একটা invoice কীভাবে created, approved, sent, paid ও archived হয়, তা end-to-end trace করুন। প্রতিটি manual step আর involved প্রতিটি tool document করুন।
3. Master-data fix করুন। Tax ID, address আর tax category clean করুন। কাজটা tedious এবং time-consuming, তাই এটা প্রথমে শুরু করুন।
4. Connection বেছে নিন। Certified access point বা approved platform, direct tax authority integration, অথবা software-bundled provider—এর মধ্যে decide করুন। Per-invoice cost, support, uptime আর exit terms compare করুন।
5. Configure আর test করুন। Format, numbering আর credit-note flow set করুন। Sandbox-এ realistic scenario চালান: normal sale, discount, return, rejection, partial credit, foreign customer।
6. Gradually go live আর monitor করুন। কয়েকজন customer দিয়ে start করুন, rejection rate দেখুন, root cause fix করুন। Finance team-কে rejection মানে কী আর কে handle করবে, তা train করুন।

Common mistakes থেকে এড়িয়ে চলুন

• Deadline month-এ শুরু করা। Deadline near হলে provider onboarding, certificate আর testing queue লম্বা হয়ে যায়।
• IT-only task হিসেবে ভাবা। Rule-understand করে Finance, customer data রাখে Sales, connection handle করে IT। তিনটা team-ই দরকার table-এ।
• PDF converter কেনা। প্রথম দিন compliant মনে হতে পারে, কিন্তু first credit note-এই break হয়ে যায়।
• Incoming invoices অবহেলা করা। Receive mandate প্রায়ই আগে শুরু হয়, আর supplier invoice automatic processing-এই সবচেয়ে বেশি time saving।
• Next country ভুলে যাওয়া। One market-এ কাজ করে কিন্তু scale না করা design দুই বছরের মধ্যে redo করতে হয়।

এবার সেই wholesaler-র গল্পে ফিরি। এখন তার system PDF যে order record থেকে বানায়, structured invoice ও generate করে সেখান থেকেই। Customer create-র সময়ই tax ID validate হয়, আর প্রতিটি invoice-র status stored থাকে। ৬০০টি invoices manual entry ছাড়াই চলে যায়। মাসে যে কয়েকটি bounce করে, সেগুলোর সাথে readable reason থাকে; একজন clerk buyer-র missing reference বসিয়ে সেদিনই resubmit করে। ১০০ ঘণ্টার retyping শেষ, সেই Monday morning surprise ও নেই।

মূল কথা

• e-invoice হলো structured, machine-readable file, PDF নয়। ইউরোপে standard EN 16931, UBL বা CII syntax-এ।
• প্রতিটি দেশের model জানুন: post-audit, clearance, বা Peppol-style exchange, কখনো কখনো extra reporting-সহ।
• প্রধান তারিখ: বেলজিয়াম ও ক্রোয়েশিয়া জানুয়ারি ২০২৬, পোল্যান্ড ফেব্রুয়ারি ও এপ্রিল ২০২৬, ফ্রান্স সেপ্টেম্বর ২০২৬ (SME সেপ্টেম্বর ২০২৭), জার্মানিতে ইস্যু ২০২৭ ও ২০২৮ থেকে, ইউনিয়নজুড়ে সীমান্ত-পেরোনো নিয়ম জুলাই ২০৩০। স্পেন, UAE, সৌদি আরব ও মালয়েশিয়া নিজেদের সূচিতে ধাপে ধাপে এগোচ্ছে।
• আপনার software-এ লাগবে structured invoice generation, clean master-data, credit notes, status tracking, archiving আর flexible connectivity।
• Deadline-গুলো shift হয়, threshold-ও country-specific, তাই decision নেওয়ার আগে tax authority বা accountant-র কাছে নিজের দেশের rule check করুন।
• Start করুন data আর receive side থেকে; যে connection-ই pick করুন, উভয়ই দরকার।

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।