Organizing Building Material Distribution with Odoo ERP: Case Study of a Multi-Branch Distributor

Building material distribution may seem simple from the outside: buy from the factory, sell to material stores. In reality, a single transaction can involve factory delivery notes, own fleet or rented expeditions, driver travel expenses, pallet costs, unloading costs, and tax invoices that must match with Coretax DJP.

This article dissects how Odoo Enterprise is used to organize all of that in a multi-branch building material distributor in the Banten and West Java regions. The focus is on three things: ERP architecture, the modules used, and how the implementation is carried out.

Business Profile: From One Distributor to a Business Group

The company in this case study is a building material distributor serving material stores, contractors, and projects. Its products are diverse: cement, hebel (lightweight bricks), wave asbestos, boards, nails and wires, PVC, pipes and fittings, screws and bolts, up to truck tires. Its operations are spread across several commercial branches in Banten and West Java, plus a Head Office and Logistics unit, with two new branches currently being opened.

In mid-2026, the organizational structure changed. A parent company (Holding) was formed above the distribution company, and a new manufacturing subsidiary was established under it. This subsidiary has a different character: it produces instant mortar/cement, stands as a single entity without branches, and has its own bank account and financial functions.

This change immediately became a system requirement. The Holding management must be able to see the entire group at once, while certain users only need to see one branch.

Business Challenges That ERP Must Address

Almost all of this business complexity arises from one fact: the same goods can reach customers through very different channels. Here are the main challenges.

Client questions are also very practical: can profit and loss be viewed per branch, can the balance sheet separate VAT and non-VAT, and how to calculate sales commissions tied to targets and debt collection.

ERP Architecture: Holding, Company, and Branch

The answer to this group structure is a multi-company architecture in Odoo: Holding as the parent, distribution companies and manufacturing subsidiaries as child companies, and distribution branches managed with the Branch Feature.

Each distribution branch has its own warehouse, while the manufacturing subsidiary has only one warehouse. Profit and loss per branch are taken from the Branch Feature, not from the Analytic Account, so reports per branch remain tidy without additional input from users.

The chart of accounts uses a shared baseline. Accounts with the same code are automatically summed when the Holding views the consolidated report, while accounts specific to the manufacturing subsidiary appear as additional lines. Accounting staff handling both companies can use one user with access to both.

Odoo Modules Used

Implementation uses six standard Odoo 19 Enterprise modules, then fills the gaps with eight custom modules.

Custom modules developed:

1. Data migration from the old system
2. Shipping costs and delivery fees based on Fleet
3. Reimbursement
4. Delivery Order with vehicle data, driver, expedition, pallets, and unloading
5. Transfer between branches
6. Profit and loss per branch
7. VAT and non-VAT reporting
8. Sales commission

Transfer between branches is an example of why customization is unavoidable. The standard PO-based flow between companies will create fictitious trade debts and improper Input VAT, thus requiring a separate flow.

Dropshipping: Selling Goods that Never Entered the Warehouse

One of the main sales channels is Direct Goods: customers order to the branch, the branch orders to the factory, then the factory ships directly to the customer's location. In Odoo, this flow is executed with the Dropship route so that one Sales Order automatically generates a Purchase Order to the factory.

[embed: node/531905d9-83e2]

Several rules make this flow neat on the accounting and operational sides:

• Factory SJ number as the common thread. The factory delivery note number is used the same in purchase documents and sales invoices, so one shipment can be traced from both sides.
• The delivery pattern is recorded in the Sales Order. Factory Franco and Customer Loco do not incur transportation costs, while Distributor/Expedition Franco must include shipping costs or driver transportation fees.
• Dropship margin appears separate. Revenue and COGS of Direct Goods enter a separate account, different from Stock Goods, and a new journal is formed when the bill and invoice are confirmed.
• Units are adjusted before receipt. For bricks that are shipped in stages, the units in the Sales Order and Purchase Order are corrected from cubic to pcs before the virtual receipt is validated.
• Returns are handled on both sides. Returns to the factory do not automatically change the Sales Order, and the factory can reject them, so sales returns and purchase returns are processed as separate transactions.

Fleet: Own Fleet and Logistics Costs

This distributor ships with its own fleet and rented expeditions, so logistics costs must be divided into two: the cost of owning vehicles and the cost of each shipment. Both are recorded in different places to avoid mixing.

With this separation, management can answer two different questions. How much does a truck cost per month is answered by Fleet, while how much net margin a Sales Order has after shipping costs is answered by Delivery analytics.

The delivery note also stores operational data: vehicle number, expedition name, driver name, and number of pallets. Spare parts and tires are purchased through Purchase as non-trade items and valued using FIFO, so that the cost per unit can still be tracked.

Fleet capacity is also used as a reference for loading planning. For hebel, a small truck (LT) carries 6 to 8 pallets or about 10.8 to 14.4 cubic meters, while a tronton carries 18 pallets or about 48.6 cubic meters for 7.5 cm hebel.

Accounting and Tax Design Decisions

A good ERP is determined by design decisions made at the beginning, not by the number of features. This is a key decision locked in this project.

• Perpetual Valuation at Invoicing. A new inventory journal is formed when the vendor bill or invoice is confirmed, not when the goods are received or shipped. This fits the dropship model, where goods never stop at the warehouse.
• Mixed cost method. AVCO for building materials, FIFO for spare parts and tires that are easier to track per unit.
• Account separation, not CoA separation. Direct Goods and Stock Goods use different revenue and COGS accounts in the same chart of accounts, allowing for margin comparison.
• Tax is selected manually at invoice. Tax does not attach to products or Sales Orders, as the same goods can be sold with or without VAT.
• VAT/non-VAT reports through tax filters. No duplicate accounts with VAT or non-VAT suffix; separation is done through tax filters in reports.
• Coretax DJP. Instance uses the new version of the Coretax e-Invoice module. DJP unit codes are set per unit, including Cubic Meter (UM.0034) for hebel.
• Logistics costs through Analytics. Two Analytics Plans, Branch and Shipping, record costs per Sales Order or delivery note, while Fleet only records vehicle ownership costs.

One important note from testing: in Odoo 19, purchase returns do not automatically flow to the related Sales Order. If the factory rejects the return, the loss is borne by the distributor, and this scenario is intentionally made the main test case.

Implementation Approach

Implementation proceeds in five sequential phases, each with clear outputs.

1. Discovery and analysis. Mapping of sales, purchasing, logistics, and tax processes, followed by gap analysis against Odoo's standard features.
2. System configuration. Company and branch structure, warehouses, chart of accounts, journals, access rights, and item units.
3. Data migration. Customers, suppliers, products, opening balances, and stock from the old system via Excel import.
4. Training and UAT. Key users run real business scenarios in the system before go-live.
5. Go-live and support. Launch into production and hypercare period.

Some practices make this project more manageable:

• One source of truth. All configuration data is managed in one master Excel workbook containing over 30 sheets, from CoA to truck capacity references.
• Scenario-based UAT. Test documents contain 19 scenarios that mimic real business flows, including dropship, factory rejected returns, and logistics costs.
• Semi-automated UAT. Testing steps in the browser are executed with the help of an AI agent that navigates Odoo, takes screenshots, and updates test status.
• Cloud infrastructure. The system runs on Infinys Cloud with PostgreSQL as the database.

Lessons for Other Distribution Businesses

Experience in this project shows that ERP for building materials distribution is not about installing modules, but about modeling how goods and money actually move.

• Design the company structure for the future. New holdings and subsidiaries are much easier to add if a multi-company architecture is prepared from the start.
• Differentiate goods paths in accounting. Dropship and stock items have different margins and risks; separate at the account level, not at the system level.
• Logistics costs are sales costs. Road money, expedition rental, pallets, and unloading must be recorded per shipment so that the margin per Sales Order appears honest.
• Prepare taxes from day one. Coretax, DJP unit code, and the separation of VAT/non-VAT are difficult to patch after go-live.
• Test with real scenarios. Edge cases like returns rejected by the factory often cause discrepancies.

If your business has a similar pattern, such as many branches, dropshipping from factories, and your own fleet, Odoo ERP can be a strong foundation. The InfinysCloud team is ready to help map your needs. For more details on this, you can email us at sales@isi.co.id