Odoo Consolidation for Bangladesh group companies and sister concerns.

The Sister Concern Problem

Walk into almost any established Bangladesh business family and you find the same shape. There is a garments buying house, a spinning mill, a small property arm renting out excess factory floor, and maybe a fledgling trading company one of the sons started two years ago. Each is a separate limited company with its own TIN, its own BIN, its own bank accounts, and its own auditor sign-off. All of them share the same chairman, the same finance director walking between offices, and often the same handful of senior accountants who close each entity's books independently and then, at month end, manually retype numbers into an Excel workbook that becomes the "group MIS."

This is not a failure of ambition. It is what happens when a business grows by adding legally separate entities rather than divisions, which in Bangladesh is often done deliberately: for tax planning, for lender covenants that cap exposure per entity, for keeping export incentive eligibility clean in one company while a domestic trading arm sits in another, or simply because each entity was incorporated to satisfy a different buyer's or bank's requirement at the time.

The result is a group that is data-rich at the entity level and completely blind at the group level. The chairman does not know, on any given day, the combined cash position across four companies without calling four accountants. Two sister concerns routinely sell to each other at cost or with a small margin, and that inter-company revenue sits recorded in both companies' books, quietly inflating combined turnover if anyone ever adds the entity statements together naively.

The group does not lack data. It lacks one place where the data from all the entities agrees with itself.

One Database or Separate Databases: The Real Trade-Off

This is the first decision, and it is the one I see Bangladesh groups get wrong most often, usually by defaulting to separate databases because each entity was set up on Odoo at a different time by a different implementer, rather than because anyone deliberately chose it.

The trade-off that actually matters in practice is not technical, it is organizational. A single database gives you native cross-company reporting, shared master data maintenance (one product catalog instead of four), and much simpler inter-company transaction posting. It costs you data isolation: a careless permission setup lets a user in the trading company see the manufacturing company's payroll runs, and a bad customization or a runaway report in one company can slow the system down for every other company sharing the instance.

Separate databases protect isolation completely but make consolidation strictly harder, because you now need to extract data out of each database (via export, API, or the Consolidation app's external data import) rather than simply filtering by company inside one system. I have implemented both, and for a genuine Bangladesh family group of sister concerns, most of the time the honest recommendation is one database, multiple companies, with disciplined access group configuration to handle the isolation concern rather than solving it by fragmenting the whole database.

The exception is when a sister concern is legally ring-fenced for a reason that matters: a joint venture with an outside minority shareholder who has audit rights only to that entity, or a subsidiary being carved out for eventual sale to a strategic buyer who will want a clean, exportable database. In those specific cases, separate databases avoid a much messier future untangling. For the underlying mechanics of setting up multiple companies inside one instance correctly the first time, including chart of accounts sharing and inter-company rules, see the Odoo Multi-Company Setup Guide.

Setting Up Multi-Company in Odoo Correctly

Assuming the single-database, multi-company model fits, the setup sequence I follow for Bangladesh group companies is deliberately conservative, because the mistakes made here surface eight months later as a chart of accounts that cannot be consolidated.

Start with a harmonized chart of accounts template. Each sister concern will have its own legal chart of accounts for statutory filing, but if every entity uses a different account numbering scheme, mapping them into a group consolidation later becomes a manual, error-prone translation exercise. I set up one master chart of accounts template at the group level, then let each company inherit it with entity-specific accounts added where genuinely needed (a factory-specific WIP account, for instance). This single decision saves the most time later of anything in this list.

Decide what is shared and what is not, deliberately, per master data type. Odoo lets you mark products, customers, and vendors as company-specific or shared across all companies. Share the product catalog if the sister concerns sell overlapping product lines. Keep customer and vendor records shared if the group negotiates with the same suppliers or sells to overlapping buyers under different entities, since duplicate vendor records across four companies is exactly the kind of mess that makes later consolidation painful. Keep them separate if a sister concern's customer base is genuinely distinct and commercially confidential from the others internally.

Set up inter-company rules early, not as an afterthought. Odoo's Inter-Company Transactions settings, configured under each company's settings, let you enable automatic generation of the mirror document (a purchase order on Company B when Company A raises a sales order to Company B, or an automatic vendor bill draft when an inter-company invoice posts). Configure this before go-live, not after the first inter-company sale has already been recorded twice, differently, by two different accountants.

Assign users to companies explicitly, and test the switch. A user working across two sister concerns needs both companies allowed on their user record, with a sensible default. Test, with an actual user, that switching the company context in the top bar actually restricts what they see the way you expect. This is the step most commonly skipped, and it is the one that produces the "wait, why can I see the other company's purchase prices" complaint three weeks after go-live.

Inter-Company Transactions: Getting the Flow Right

The most common real transaction pattern in a Bangladesh sister-concern group is one entity selling raw material, semi-finished goods, or a shared service (say, a shared logistics or maintenance team billed internally) to another. Configured correctly, this should require one person to record one transaction, with Odoo generating the counterparty document automatically.

In practice, I still see two failure patterns repeatedly. The first is duplicate manual entry: without inter-company automation enabled, the selling company's accountant records a sales invoice, and separately the buying company's accountant records a purchase bill, often with mismatched dates, mismatched quantities, or a different unit price if someone made a typo. These two records then need manual reconciliation at month end, which is exactly the manual burden the group was trying to escape by moving to Odoo in the first place.

The second failure pattern is subtler and more dangerous: the inter-company price is set at an arbitrary transfer price (often simply "cost plus 5%" agreed verbally years ago) with no documented transfer pricing policy, no visibility into whether that price is arm's-length, and no consistency between what different sister concerns charge each other for similar internal transactions. This becomes a genuine tax exposure question under Bangladesh's related-party transaction rules, not just a bookkeeping tidiness issue, and it is worth a conversation with the group's tax advisor, not something an ERP configuration alone can fix.

Elimination: Where Groups Actually Get It Wrong

This is the section that separates a group that has "connected its companies in Odoo" from a group that has genuinely consolidated. If Company A sells BDT 2 crore of yarn to Company B during the year, and you simply add Company A's revenue and Company B's cost of goods together to get "group revenue," you have overstated the group's real external revenue by that BDT 2 crore, because it never left the group. This is the double-counting problem, and it is the single most common consolidation error I see in Bangladesh group MIS workbooks built in Excel by well-meaning accountants who have never been trained in formal consolidation accounting.

Proper elimination requires removing three things at group level: the inter-company revenue and matching inter-company cost of sales, any inter-company payable and receivable balance between the entities (so the group balance sheet does not show the group owing itself money), and, the part almost everyone misses, any unrealized profit sitting in year-end inventory that one sister concern bought from another and has not yet sold externally. If Company B still holds, at year end, inventory it bought from Company A at a 15% markup, the group's consolidated inventory value should be reduced back to Company A's original cost, because from the group's perspective no profit has actually been earned on goods still sitting in a warehouse.

The Consolidation Module, Configured for a Bangladesh Group

Odoo Enterprise's Consolidation app is the right tool for most Bangladesh groups with somewhere between three and fifteen legal entities, and it is genuinely underused locally, mostly because implementation partners rarely get asked for it and because it requires someone on the finance side who actually understands what a consolidation worksheet is supposed to do.

The setup sequence: first, create a Consolidated Chart of Accounts, this is the group-level account structure that every subsidiary's accounts will map into. Second, create a Consolidation entity in the app and add each sister concern as a subsidiary, whether that subsidiary is a company inside the same Odoo database (which pulls trial balance data natively) or an external company whose trial balance is imported via a structured spreadsheet (relevant if a sister concern runs on a different system, or lives in a separate Odoo database by design). Third, map every account in each subsidiary's chart to the corresponding consolidated account, this mapping step is where the harmonized chart of accounts decision from earlier pays off, since a shared numbering scheme across entities makes this a fast, largely mechanical exercise rather than a line-by-line negotiation.

Fourth, and this is the step that requires real accounting judgment rather than configuration, build the elimination journal entries into the consolidation period: inter-company revenue against inter-company cost, inter-company receivables against payables, and the unrealized profit adjustment on closing inventory. Fifth, generate the consolidated trial balance and financial statements from the app, which will now reflect the group's true external position rather than a naive sum of the parts.

One honest caveat: the Consolidation app assumes a reasonably disciplined monthly or quarterly close process at the entity level. If individual sister concerns are still closing their books six weeks late, the consolidation will always be running behind, and the group MIS the chairman actually wants (a same-week view of group cash and receivables) needs the entity-level close cadence fixed first. The consolidation tool cannot compensate for slow entity bookkeeping; it only formalizes what is fed into it.

When Fiscal Structures Differ Across Entities

Bangladesh groups occasionally end up with sister concerns on different fiscal years, most often because one entity was incorporated with foreign investment and follows a July-June fiscal year to align with an international parent's reporting calendar, while the domestic sister concerns follow the standard Bangladesh January-December year, or vice versa. This is a genuine complication for consolidation, not a configuration inconvenience.

The practical approach is to run the consolidation on the group's chosen reporting calendar (usually whichever is used for the majority of entities or for the primary lender relationship) and require the misaligned entity to produce an interim trial balance cut at the group's period end, in addition to its own statutory year end. This interim cut does not need to be audited, it needs to be accurate enough for group management reporting. Odoo's Consolidation app accepts these interim imports the same way it accepts a full external subsidiary's data, so the mechanism is not the hard part. The hard part is getting the misaligned entity's accountant into the habit of producing that extra cut on time every period, which is a process discipline problem more than a software one.

Group-Level Dashboards the Family Actually Uses

The consolidation module solves the statutory and audit-facing side of group reporting. What the owning family usually wants day to day is simpler and more immediate: one screen showing combined cash position, combined receivables ageing, and revenue by entity, updated close to real time, not waiting for a quarterly consolidation close.

This is where Odoo's native multi-company dashboard filtering does most of the work without needing the full Consolidation app machinery. Once all sister concerns share one database and a harmonized chart of accounts, standard Odoo Accounting and Spreadsheet dashboards can be filtered to "all companies" or a chosen subset, giving a combined, near-real-time view. This will not have inter-company eliminations applied (it is a management view, not a statutory consolidated statement), but for the chairman deciding whether the group can afford a new equipment purchase this quarter, an unaudited, near-real-time combined cash and receivables view is usually more useful than a technically correct but three-months-delayed consolidated statement. Building this out properly, including the KPI selection that actually gets looked at rather than ignored, is covered in the Odoo Dashboards & KPI guide, and the underlying accounting setup that makes multi-entity reporting reliable in the first place is covered in Odoo Accounting Setup for Bangladesh.

I have found it useful to distinguish, explicitly, between these two artifacts for the client: a fast, unaudited group management dashboard for weekly decisions, and a slower, formally eliminated consolidated statement for quarterly board reporting and annual audit. Trying to make one artifact serve both purposes usually means the fast dashboard gets bogged down waiting for elimination entries, or the audited consolidation gets rushed to hit a weekly cadence it was never built for.

A Realistic Rollout Order

Groups that try to stand up multi-company, inter-company automation, full consolidation, and group dashboards simultaneously in one project tend to stall, because each layer depends on the one below being stable. The order that has actually worked on Bangladesh group implementations I have run:

1. Harmonize the chart of accounts across all sister concerns first, even before touching Odoo configuration. This is a finance team exercise, not an IT one, and it takes longer than people expect because it means someone has to actually reconcile why Company A calls an account "Factory Overhead" and Company B calls the equivalent "Indirect Manufacturing Cost."
2. Stand up multi-company in Odoo with the harmonized chart, shared or separated master data decided deliberately, and correct user access per entity.
3. Enable and test inter-company transaction automation on a small set of real transactions before relying on it for the full transaction volume.
4. Run one full consolidation cycle manually with the finance team, using the Consolidation app, before automating anything, so the eliminations are understood, not just clicked through.
5. Build the group dashboard last, once the underlying data across entities is trustworthy enough that a combined number actually means something.

Frequently asked questions

Should sister concerns share one Odoo database or use separate databases?

Use one database with multiple companies when the sister concerns share master data or transact with each other frequently. Use separate databases when the businesses are operationally unrelated, need independent upgrade schedules, or ownership will diverge, such as a sister concern being prepared for sale. Most Bangladesh family groups with related trading and manufacturing lines fit the single-database, multi-company model better than they initially assume.

How does Odoo handle inter-company transactions between sister concerns?

Within a single multi-company database, Odoo can auto-generate the mirrored transaction on the counterparty company when one company sells to another. At group reporting level, these inter-company sales, purchases, and any unrealized profit sitting in year-end inventory must still be manually eliminated in the consolidation module or worksheet, because standard multi-company accounting does not auto-eliminate for consolidated statements.

Does Odoo have a built-in consolidation module?

Odoo Enterprise includes a Consolidation app that lets you define a consolidation entity, map each subsidiary's chart of accounts to a common consolidated chart, pull trial balances from each company, and apply elimination journal entries before generating consolidated financial statements. It is genuinely usable for Bangladesh group structures with 3 to 15 entities, though it still requires someone who understands consolidation accounting to configure the mappings and eliminations correctly.

Can Odoo show group-level dashboards across all sister concerns?

Yes. With all entities in one database, Odoo's reporting and dashboard views can be filtered to all companies or a selected subset, giving the ownership group a combined view of revenue, cash position, and receivables without opening each company's books separately. This requires a reasonably harmonized chart of accounts and consistent analytic tagging, which is usually the harder part of the setup, not the dashboard itself.