Data Cleaning Before Odoo Go-Live — the 10-point checklist.

I have seen Odoo implementations where the system was correctly configured, the team was trained, and the go-live date arrived — but the launch was delayed by three weeks because the opening inventory didn't match the physical stock count, and the accounts team had only just discovered that two of their major customers had been entered in Tally under four different names. The configuration was ready. The data was not.

Data migration is not an IT task. It is a business task that requires active participation from accounts, warehouse, procurement, and HR. The Odoo consultant cannot clean your data for you — they don't know which of the four "ABC Garments" entries is the correct one. You do. This checklist tells you where to look and exactly what to fix.

Dirty data imported into a clean system doesn't get cleaner. It creates reconciliation debt that compounds daily after go-live.

Why data quality determines go-live success

Every data problem that exists in your legacy system at the time of migration will exist in Odoo after go-live — at scale, with new transactions layered on top. Problems that were manageable in a familiar legacy system become critical incidents in a new system where the team is still learning. Specifically:

• Duplicate customers create split AR balances. Payment from "ABC Garments Limited" may apply to the wrong record, leaving a phantom outstanding balance that triggers unnecessary follow-up calls.
• Missing vendor TINs prevent correct TDS deduction. In Bangladesh, TDS (AIT) rates differ depending on whether a vendor has a valid TIN. Importing vendor records without TIN classification means TDS is either over-deducted (vendor complaints) or under-deducted (NBR compliance risk).
• Wrong opening stock quantities corrupt inventory valuation from day one. A warehouse team that inherited opening stock from a month-old Tally count will spend the first three months doing manual adjustments to reconcile physical vs system inventory.
• Unreconciled opening AR/AP balances mean the trial balance is wrong on day one. An accounts team chasing why Odoo's trial balance doesn't match the legacy system is not processing invoices — they are debugging history.

Conduct your data audit first

Before starting any cleanup, generate these counts from your legacy system. These numbers tell you how much cleaning work is ahead and where to focus effort.

The 10-point checklist

• 01 Customer master — deduplicate and enrich Accounts team

  Export all customer/party ledgers from the legacy system. Run a duplicate detection pass:

  • Normalize names: remove Ltd/Limited variation, standardize punctuation, remove extra spaces
  • Sort alphabetically — similar names cluster together and are easy to spot
  • Merge duplicates: consolidate all outstanding balances to the master record before migration
  • Flag inactive customers (no transaction in 2+ years) — decide whether to migrate or archive
  • Add missing fields: BIN number (for Mushak invoicing), email, phone, payment terms

  Excel duplicate detection

  =IF(COUNTIF($A$2:$A2,A2)>1,"DUPLICATE","OK")
  Paste this in column B alongside your customer name column to flag duplicates

  BLOCKER: If a customer appears in both AR and as a vendor in AP (intercompany), flag these before import. Odoo handles them as a contact with both customer and vendor roles — do not create two separate records.
• 02 Vendor master — TIN classification for TDS Accounts team

  Export all vendor/supplier ledgers. Beyond deduplication (same process as customers), the Bangladesh-specific requirement is TIN classification:

  • Column: TIN (12-digit) — collect from vendor's trade license or NBR registration
  • Column: TDS category — NBR Section (e.g., 52A for services, 52Q for imports, 52T for supply of goods) determines the AIT rate
  • Column: TDS rate — depends on TIN status: with TIN (1–10% depending on category), without TIN (double rate applies)
  • Column: Bank account — account number and routing number for electronic payment setup

  In Odoo, the TDS rate is configured on the vendor record as a default withholding tax. Incorrect TDS classification means every vendor bill will require manual correction of the tax line.

  COMPLIANCE RISK: Vendors without TIN must be taxed at the higher "without TIN" rate under NBR rules. Missing this classification is an NBR audit exposure, not just a data quality issue.
• 03 Product master — standardize and categorize Warehouse + Procurement

  Product master is typically the most time-consuming migration task for manufacturing companies. Every product record needs:

  • Internal Reference: A consistent SKU or item code. If the legacy system has no codes, create them now — do not import products without internal references
  • Product Category: Required for costing and accounting journal mapping. Agree the category hierarchy before import (e.g., Raw Material → Fabric, Raw Material → Yarn)
  • Unit of Measure: Confirm primary UoM for each product. For Bangladesh garments: pcs, dzn, kg, yards. Check that Tally UoM names map correctly to Odoo UoM names
  • Cost Price: Required for inventory valuation at go-live. Use weighted average cost as of cutover date from legacy system
  • Product Type: Storable product (tracked in inventory) vs consumable vs service. This drives accounting journal behavior
  • VAT applicability: Standard rated (15%), zero-rated (export), exempt — flag each product correctly

  Missing field check (paste in Excel)

  =COUNTIF(B2:F2,"")  → count of empty cells in this row's required fields. Any row >0 needs attention before import.
• 04 Chart of accounts — map and validate Accounts team

  The chart of accounts (CoA) must be agreed before any other financial data is migrated. In Odoo, every financial transaction posts to accounts — the CoA is the backbone of the entire accounting configuration.

  • Export all ledger accounts from the legacy system
  • Map each legacy account to an Odoo account type (receivable, payable, bank, income, expense, equity, etc.)
  • Identify accounts that should be consolidated — e.g., 12 separate "office expense" ledgers in Tally can often map to 2–3 Odoo accounts
  • Identify Bangladesh-specific accounts: VAT payable, AIT (TDS) payable, PF payable, gratuity provision
  • Accounts team signs off on the CoA before any configuration begins — changing account types after transactions are posted is a painful migration

  BLOCKER: Do not begin Odoo configuration until the CoA mapping is signed off by the CFO or senior accounts manager. The CoA is the most expensive thing to change after go-live.
• 05 Opening AR balances — reconcile before import Accounts team

  Opening accounts receivable (AR) is the outstanding amount customers owe you as of the cutover date. Import this as individual invoices (preferred) or as a journal entry opening balance.

  • Export AR aging from legacy system: list of open customer invoices with invoice number, date, customer, amount (BDT), due date
  • Reconcile against customer statements for top 20 customers by outstanding balance — confirm the amounts match their records
  • Identify and resolve disputed invoices before import — do not migrate disputed amounts as uncontested receivables
  • Identify invoices older than 180 days — discuss with CFO whether to migrate as bad debt provision or as active AR
  • Total AR in Odoo after import must match AR in legacy system trial balance as of cutover date to BDT 1
• 06 Opening AP balances — confirm against vendor statements Accounts team + Procurement

  Opening accounts payable (AP) is what you owe vendors as of the cutover date. This is often messier than AR because vendors may have invoiced amounts that are in dispute or pending approval.

  • Export AP aging from legacy system: list of open vendor bills with bill number, date, vendor, amount, due date
  • Send statement of accounts to top 20 vendors by outstanding balance — request confirmation of the balance they have on their books
  • Resolve any discrepancies: if your Tally shows BDT 8 lakh owed to a vendor and their statement shows BDT 9.5 lakh, one of you is wrong — resolve before import
  • Advance payments to vendors: ensure advance payments are correctly reflected as debit balances and will offset against future bills

  COMMON ISSUE: In Tally, some Bangladesh companies book vendor payments without first booking the vendor bill (direct debit to vendor ledger). This creates AP records that don't match actual bills. Odoo requires bills to match payments — clean up unbilled payments before import.
• 07 Opening stock — physical count, not system count Warehouse team

  This is the checklist item most frequently skipped and most regretted. The opening inventory in Odoo must come from a physical count — not from the legacy system's stock report. Legacy system stock quantities are almost always wrong: physical count discrepancies accumulate over years and are rarely reconciled.

  • Schedule a physical stock count on or immediately before cutover weekend. Count everything.
  • Record quantity and unit cost per product per storage location
  • Compare physical count to legacy system report — investigate and document all discrepancies
  • Get CFO/Finance approval to write off counted discrepancies in the legacy system before migration
  • Import into Odoo using inventory adjustment — quantity × unit cost = inventory valuation that must match the financial opening balance
  • Confirm: Odoo inventory valuation account balance = physical count value = legacy system closing stock value (after write-off)

  BLOCKER: Do not import the legacy system's stock report without a physical count. If your legacy system says you have 5,000 pcs of Product A and the physical count shows 4,200, you have 800 pcs of invisible inventory debt that will surface within 30 days of go-live.
• 08 Employee master — payroll compliance fields HR team

  If Odoo HR & Payroll is in scope, the employee master requires Bangladesh-specific compliance fields that are often missing from legacy systems:

  • NID number: National Identity Card — required for PF fund submission and payroll audit
  • Joining date: Must be accurate — gratuity calculation under Bangladesh Labour Act uses service years from joining date (5-year threshold)
  • Department and designation: Used for organizational hierarchy and leave approval workflows
  • Basic salary breakdown: Odoo salary structure requires: basic, house rent allowance, medical allowance, transport allowance (standard BD components)
  • PF enrollment date: Some employees are PF-exempt (under 5 years or by grade) — flag status in the import file
  • Bank account: Account number and bank routing for electronic salary transfer
• 09 Fixed assets register — value and depreciation Accounts team

  If Odoo Fixed Assets module is in scope, each fixed asset requires:

  • Asset name and category: Land, building, machinery, vehicles, furniture, IT equipment
  • Acquisition date and original cost: The date purchased and full purchase price in BDT
  • Accumulated depreciation to date: Total depreciation charged in the legacy system up to cutover date
  • Net book value: Cost minus accumulated depreciation — Odoo will import this as the opening value
  • Depreciation method and rate: Straight-line or declining balance; rate per annum per asset category per company policy
  • Remaining useful life: How many more months/years of depreciation to charge

  The fixed assets register is typically maintained in Excel by the accounts team. Extract it, validate net book values against the legacy system fixed assets account balance, and import before first month-end close in Odoo.

• 10 Open purchase orders and sales orders Procurement + Sales

  Open transactions — purchase orders where goods have not yet arrived, or sales orders not yet shipped — need a decision: migrate or not.

  • Recommended approach (most Bangladesh SMEs): Do not migrate open POs and SOs. Instead, re-enter open orders manually in Odoo on day one. This avoids import complexity and lets the team practice their first real transactions in the live system.
  • If migrating open orders: Export from legacy system. Only include POs with outstanding quantity (partial receipts need the received quantity adjusted). Link POs to vendors and products that have already been migrated.
  • Open LC (Letter of Credit): If LC management is in scope, document all outstanding LCs and map to the Odoo LC workflow before cutover.

  DECISION REQUIRED: The choice to migrate or re-enter open transactions must be agreed by the procurement and sales managers before the cutover plan is finalized. There is no default correct answer — it depends on volume (low volume → re-enter; high volume → migrate).

Bangladesh-specific data fields — the ones projects miss

These fields are specific to Bangladesh compliance requirements and are not present in standard Odoo out-of-the-box import templates. Confirm your implementation vendor has included them in the import templates before data cleaning begins:

• BIN (Business Identification Number): Required on customer and vendor records for Mushak invoice printing. The NBR currently issues two formats — 9-digit (old BIN) and 17-character BIN (new format post-2019 VAT Act). Both must be stored.
• TIN (Tax Identification Number): Required on vendor records for TDS (AIT) classification. 12-digit number. Vendors without TIN are subject to higher withholding rates.
• Trade License Number: Useful for vendor KYC records. Not required for tax compliance but commonly captured by procurement teams.
• BGMEA/BKMEA membership number: For RMG companies tracking buyer/supplier garments association memberships.
• NID number: On employee records for PF fund and government payroll compliance reporting.
• Bank routing number (BEFTN code): Bangladesh Electronic Funds Transfer Network routing number — required for electronic salary disbursement and vendor payment file generation.

For more on migrating data from Excel-based systems and Tally, see our Excel to Odoo migration checklist with detailed field mapping templates.

Cutover day sequence

The cutover sequence below is for a Friday evening → Sunday morning go-live window (Bangladesh weekend). Adjust for your specific dates. Every step has a named owner and a verification checkpoint before the next step begins.

Frequently asked questions

How long does data migration take for Odoo in Bangladesh?

For a Bangladesh SME, data migration typically takes 3–5 weeks of elapsed time. Week 1: data extraction and audit. Weeks 2–3: cleaning and deduplication (most time-consuming). Week 4: test import and error resolution. Week 5: final import and opening balance reconciliation. The most common delay is accounts team unavailability — explicitly block their time in the project plan for the reconciliation steps.

What data needs to be migrated to Odoo from Tally in Bangladesh?

Required data categories from Tally: master data (customer ledgers, vendor ledgers, stock items, chart of accounts, employees); opening balances (trial balance as of cutover date, AR aging, AP aging); opening stock (quantity and cost per product per warehouse from physical count); and open transactions (purchase orders not yet received, sales orders not yet shipped — recommended to re-enter manually rather than migrate for most SMEs).

What is the most common data migration problem in Bangladesh ERP projects?

Duplicate and inconsistent master data from Tally. A single customer may appear as 4–6 different ledger entries with slightly different name spellings. When migrated without deduplication, this creates split AR balances that cause incorrect customer statements and payment matching problems. The deduplication step for a company with 200–500 active counterparties typically takes 1–2 full working days.

What Bangladesh-specific data fields are required in Odoo?

Required for compliance: BIN number on customer/vendor records (for Mushak invoice printing), TIN on vendor records (for TDS rate classification), NID on employee records (for PF and payroll compliance), bank routing numbers (BEFTN code) for electronic payment files. These fields are not in standard Odoo import templates — confirm your vendor has included them before data cleaning begins.