A multi-company general contractor connected estimating, project delivery, purchasing, field time, job costing, billing and finance in one Odoo Enterprise system, with each legal entity's books kept separate.
in operation (approximate)
employees across the group (approximate range, 2026)
legal entities in one Odoo database (current)
projects run through the platform to date (approximate)
This case study shows how a multi-company contractor group used Odoo Enterprise to connect estimating, project delivery, purchasing, inventory, field time, payroll inputs, job costing, billing and finance. The implementation replaced disconnected handoffs with one governed operational flow while preserving legal-entity boundaries.
The case is most relevant to general contractors, restoration companies and field-service groups that need project costs to remain visible while work is still underway, not only after the project closes.
About the evidence. The client is anonymized. Operational figures are shown only where approved and are labelled as current, historical, rounded or approximate. Results reflect this organization's process and do not guarantee the same outcome for another company.
This was not an out-of-the-box Odoo installation. It combined standard Odoo functions, configuration, customization built mostly with Odoo Studio on Odoo Online, and an external integration for field time. The section on standard Odoo, configuration, integrations and customization separates the layers.
The client is a group of related businesses in three lines: general contracting and construction, covering residential, commercial and restoration work, building-material wholesale, and cabinetry. Today the group runs 14 legal entities, each a company with its own books, bank accounts, vendors and crews. They share back-office staff and management, and often work on the same job sites.
As the group grew across several business lines, spreadsheets, disconnected tools and manual sign-offs began to slow it down. Estimating lived in one place and purchasing in another, and a project's real cost was not visible until weeks after the work was done.
The group chose Odoo Enterprise as one operating system for every entity, all in one database, and treated the rollout as an operations redesign, not a software install. For a buyer's view of the same decision, see Odoo for construction companies.
Each entity ran its own version of the process, and nothing carried a job from the sale to the ledger. The group had tried Monday.com for project management, but it fragmented the data further and could not handle the complex job costing and the high level of customization the business needed.
The workflow follows one operating thread from an accepted estimate to a customer invoice. At each stage one record is authoritative, and the next record is created from it instead of being typed again. Where information crosses a system boundary, as with field hours, this page names the integration and states whether it is event-triggered or scheduled, and does not call it real time.
An estimate is the priced scope for a job, covering labour, materials, subcontractors and equipment. Opportunities and site assessments feed structured estimates in Odoo CRM and Sales. When an estimate is accepted, it creates or informs the project in Odoo Project and the initial budget. The estimate stays the authoritative record of what was sold. The project becomes the authoritative record of what will be delivered.
A project budget is the approved planned cost for a job, and a cost code is the category that attributes each cost to a type of work. Each project keeps its company, customer, budget and cost-code context, so every later purchase, expense and labour entry can be attributed to the right job and legal entity. In this implementation, cost codes are built on analytic accounts used together with the project.
A purchase request is an internal need for material or a subcontractor, reviewed before it becomes a purchase order. Requests route through approval limits set by amount and role, so a small material request and a large subcontract follow different paths. Verbal and email approvals were replaced by this recorded route. In this implementation, standard Odoo approvals did not satisfy the required vendor-bill controls, so NGYN built the approval rules with Odoo Studio. Purchases or bills outside expected quantity or price ranges are flagged for review before they become disputes.
A purchase order is the committed order to a vendor or subcontractor. A receipt records what was delivered, and a vendor bill is the vendor's invoice. Each keeps the project and company attribution of the order. Vendor bills are matched against the purchase order and the received quantities before payment is released. The order is authoritative for what was ordered, the receipt for what arrived and the bill for what is owed.
A field hour is time worked by a crew member on a job, and a payroll input is the approved hour total passed into the payroll process. Field staff clock in through Connecteam, the group's workforce app, using mobile clocks and kiosk check-ins, not inside Odoo. An integration built on n8n carries employee records, project changes, form submissions and timesheets between Connecteam and Odoo, so hours post against the right project and cost code without re-keying. Approved hours feed payroll inputs, and payroll itself is processed in Wagepoint, outside Odoo. Connecteam is authoritative for clock events, and Odoo is authoritative for the project cost of those hours. The integration mixes two timings. Project and employee profile changes are event-triggered and passed on as they are made. Form submissions are scheduled about every 30 minutes, and timesheets are scheduled once a week. It is not real-time posting of hours. See the Odoo and n8n integration guide for the controls behind an integration like this.
Job costing compares committed cost, meaning purchase orders, and actual cost, meaning bills, expenses and labour, with the approved budget. Because each cost carries its project and cost code, project managers can review cost against budget while work is underway and not only after the project closes. Purchase and expense costs appear as they are approved, and labour cost updates as timesheets arrive, which is weekly. Expense approvals are tied to project budgets, so spend on a job is visible to the project manager as it is approved.
A customer invoice is the bill to the customer for work done or milestones reached. Finance receives governed records for billing, accounting and reporting, and each of the 14 legal entities keeps its own ledger. Leadership can review revenue, cost and margin across the group and drill into a single company or division.
| Record | What it is | Authoritative source |
|---|---|---|
| Estimate | The priced scope for a job: labour, materials, subcontractors and equipment | Odoo CRM and Sales |
| Project | The job being delivered, with its customer, company and schedule | Odoo Project |
| Project budget | The approved planned cost for the job | Odoo, on the project |
| Cost code | The category that attributes each cost to a type of work on a project | Odoo analytic accounts, used with the project |
| Purchase request | An internal need for material or a subcontractor, before it is approved | Odoo, with an approval rule built in Odoo Studio |
| Purchase order | The committed order to a vendor or subcontractor | Odoo Purchase |
| Receipt | The record of what was actually delivered | Odoo Inventory |
| Vendor bill | The vendor's invoice, matched to the order and receipt before payment | Odoo Accounting |
| Field hour | Time worked by a crew member on a job | Connecteam for clock events. Odoo for the project cost of those hours |
| Payroll input | The approved hours passed into the payroll process | The approved workforce process. Payroll is processed in Wagepoint |
| Customer invoice | The bill to the customer for work done or milestones reached | Odoo Accounting |
| Legal entity | A company with its own books, bank accounts and tax obligations | Odoo company, with its own ledger |
Where a record crosses a system boundary, this page names the integration and its timing: event-triggered or scheduled.
These are the Odoo areas that carried the workflow above. Each links to the official Odoo 19 documentation for that area.
| Odoo area | Role in this implementation | Official Odoo 19 documentation |
|---|---|---|
| CRM and Sales | Opportunities, site assessments, structured estimates, quotations and customer orders | CRM and Sales |
| Project | Projects created from accepted estimates, with budgets and cost codes attached | Project |
| Purchase | Purchase requests, approvals and purchase orders to vendors and subcontractors | Purchase |
| Inventory | Stock movements, requisitions, receipts and deliveries to sites | Inventory |
| Timesheets | Field hours from Connecteam posted against the right project and cost code, through the integration, weekly | Timesheets |
| Expenses | Expense entries routed through approval and tied to project budgets | Expenses |
| Accounting | Vendor bills and matching, a separate ledger for each legal entity, inter-company entries and group reporting | Accounting and analytic accounting |
| Employees | Employee records shared across companies and kept in step with Connecteam. Used lightly | Employees |
| Documents and Approvals | Both are used lightly. Approval of purchases and vendor bills runs on rules NGYN built with Odoo Studio, because standard Odoo approvals did not satisfy the required vendor-bill controls in this implementation | Studio |
This table lists the areas used in this implementation. A similar project may use others.
The result is one connected system, but it was built in layers. Separating them matters, because each layer has a different cost, a different owner and a different effect on future Odoo upgrades.
| Layer | What it covered here | How it is described |
|---|---|---|
| Standard Odoo function | Multi-company, CRM and estimates, projects, purchase orders, receipts, vendor bills and matching, expenses, accounting and reporting | Standard capabilities of Odoo Enterprise |
| Odoo configuration | Access rules by entity and project, the analytic-account cost-code and budget structure, and shared master data across 14 legal entities | Configured in Odoo |
| Odoo Studio or low-code adjustment | Most of the customization: approval rules for purchases and bills, and automated actions and business rules that route documents, notify approvers, flag exceptions and update statuses. NGYN's records put these in the hundreds, an approximate figure | Built with Odoo Studio. Standard Odoo approvals did not satisfy the required vendor-bill controls here |
| Custom Odoo development | Limited. The database runs on Odoo Online, which hosts databases without custom modules, so changes are made with Studio. Custom reports and other changes were carried from Odoo 17 to Odoo 19 and reviewed one by one | Mostly Studio for now |
| External integration | An integration built on n8n between Connecteam and Odoo, covering employees, projects, form submissions and timesheets. Payroll runs separately in Wagepoint | Event-triggered for project and employee changes. Scheduled for form submissions (about every 30 minutes) and timesheets (weekly) |
| Operational process change | Verbal and email approvals replaced by recorded routes. Estimates handed to projects without re-keying. Cost codes and approval limits defined before configuration | Decided with the client before configuration |
Stable through a two-version migration. Customizations, automations and security rules were carried from Odoo 17 to Odoo 19 Enterprise, and every custom report, automated action and access rule was reviewed so the system stayed reliable.
Odoo runs as one multi-company database for all 14 legal entities, not as separate instances. Each legal entity keeps its own books, chart of accounts and approval chains, while vendors, employees, catalogues and reporting roll up at group level. Odoo's own multi-company documentation describes the underlying behaviour.
Vendors, employees and materials are maintained once and used across companies, while financial transactions stay segregated by entity.
When one division's crew or equipment supports another division's project, cost allocation and internal billing happen in the system instead of through manual journal entries.
People see and approve only what is relevant to their entity, division or project. Approval limits differ by amount and role.
Leadership can review revenue, cost and margin across the group and drill into any single company or division. Before, this was a month-end exercise across exports and spreadsheets.
This is NGYN's method for an implementation of this kind, in eleven phases grouped into six stages. The duration and fees for this client are not published. Standard Odoo is run first, and customization is decided after the pilot.
Purpose. Understand how work really flows and where standard Odoo fits, then design the processes and controls. Deliverable. A fit-gap register, a target process design and an approval matrix. Client responsibility. Name a process owner for each area and make decision-makers available.
Purpose. Load clean customers, vendors, items, employees, cost codes and opening balances. Deliverable. A data map, cleaned source files and reconciled test loads. Client responsibility. Own the data, remove duplicates and confirm what history to keep.
Purpose. Configure standard Odoo for each entity and connect the systems being kept, here the Connecteam workforce app. Deliverable. A configured foundation and a working integration with defined error handling. Client responsibility. Review each configuration against real jobs and supply access to the connected systems.
Purpose. Run real scenarios end to end, from estimate to job cost, and let the business confirm which gaps are real once standard Odoo is in use. Deliverable. Test results, corrected issues and an updated gap register. Client responsibility. Provide testers from each role and sign off critical accounting, payroll and project-cost workflows.
Purpose. Close the gaps that remain after the pilot and cannot be handled by configuration or a process change. Deliverable. Approved customizations, each with acceptance criteria and a named owner. Client responsibility. Approve scope and accept long-term ownership of each change.
Purpose. Prepare people, move to production and stabilize. Deliverable. Role-based training, a cutover plan with a rollback decision point and post-go-live support. Client responsibility. Release staff for training, freeze the old process on schedule and report issues through the agreed channel. Support then continues as improvement work, priced on the fee table.
Finance, project management, purchasing, inventory and field operations for the whole group now run on one connected system instead of spreadsheets and side tools. Project managers can see cost against budget while a job is underway, and approvals follow a recorded process instead of an email chain.
| Figure | Value | Status |
|---|---|---|
| Years in operation (the group) | About 20 | Approximate, current |
| Employees across the group | 130 to 170 | Approximate range, current (2026) |
| Legal entities in one Odoo database | 14 | Current |
| Projects run through the platform | About 4,000 or more | Approximate, cumulative to date |
| Sales quotations and orders per week | About 150 to 190 | Current (2026), rounded within about 10 percent |
| Purchase orders and RFQs per week | About 170 to 200 | Current (2026), rounded within about 10 percent |
| Expense entries per week | About 60 to 90 | Current (2026), rounded within about 10 percent |
| Projects, service calls and sites active at once | About 110 to 135 | Current (2026), rounded within about 10 percent |
| Field labour hours logged per month | About 9,000 to 11,000 | Peak season, rounded within about 10 percent |
| Field hours after the integration went live | Roughly 20 to 30 times the first months, within about a year and a half | Historical, approximate |
| Purchase orders per month after adoption | From well under 50 to several hundred | Historical, approximate |
Source: NGYN's records of the live platform, approved for publication and shown rounded and varied by about 10 percent to protect exact business detail. The client is anonymized.
| Metric | Before Odoo (estimate, about 2023) | After Odoo (2026, current) |
|---|---|---|
| Employees, group-wide | About 40 | About 130 to 170 |
| Sales quotations and orders per week | About 15 to 25 | About 150 to 190 |
| Purchase orders and RFQs per week | About 10 to 20 | About 170 to 200 |
| Expense entries per week | About 10 to 15 | About 60 to 90 |
| Projects active at once | About 25 to 35 | About 110 to 135 |
The "before" column is a directional estimate. The "after" column comes from live platform activity, rounded. Much of the increase is the business itself growing. These figures show how much activity now runs on the platform. They do not show that Odoo caused the growth, and they make no claim about staffing.
Define the controls before configuring. Cost codes, approval limits and the boundary between legal entities were decided with the client first. The software then implemented decisions instead of replacing them.
Connect the field, do not move it. Crews kept Connecteam. The integration carried hours to the project instead of asking field staff to learn the ERP.
Run standard Odoo first. Customization was limited to gaps that remained after real use and built mostly with Studio on Odoo Online, which keeps the system easier to test, support and upgrade. The migration from Odoo 17 to Odoo 19 depended on that discipline.
Choose a tool that can hold complex cost. The group tried Monday.com first and found it fragmented the data and could not handle complex costing or high customization needs. A project board is not a cost system.
Budget for data and process work, not only software. See Odoo implementation cost for general contractors and Odoo ERP pricing and implementation cost in Canada and the US for how those lines are built.
Decide what to automate deliberately. The Odoo automation and practical AI hub explains how to choose between a rule, an integration and AI. If you are weighing whether to do this alone, read when you need an Odoo consultant.
Partly. It uses standard Odoo Enterprise functions and configuration, customization built mostly with Odoo Studio on Odoo Online, and an external integration for field time. The layers are separated in the section on standard Odoo, configuration, integrations and customization.
Yes, in a multi-company database. Here, 14 legal entities share one database. Each company keeps its own ledger and approvals while shared records and group reporting sit above them. Your own accounting rules should be tested before cutover.
Each purchase carries its project, cost code and company from the request onward. Receipts and vendor bills keep that attribution, and bills are matched to the order and received quantities before payment is released.
Crews clock in through Connecteam. An integration built on n8n carries employees, projects, forms and timesheets into Odoo, where hours post to the right project and cost code. Timing depends on the data: project and employee profile changes are event-triggered, form submissions are scheduled about every 30 minutes and timesheets are scheduled once a week. Payroll is processed in Wagepoint, outside Odoo.
The group tried Monday.com first. It fragmented the data and could not handle the complex job costing and the high level of customization the business needed, which is why costs now live in Odoo against projects and analytic accounts.
No custom modules were needed. In this implementation, standard Odoo approvals did not satisfy the required vendor-bill controls, so NGYN built the approval rules with Odoo Studio. The database runs on Odoo Online.
In this implementation, estimates are built in Odoo from opportunities and site assessments and become the starting point for the project and its budget. Whether that is enough for your estimating depth is a fit question to answer in discovery.
NGYN does not publish the duration or fees for this client. For how the cost lines are built, see the general contractor cost guide and the Odoo pricing guide. Support rates are on the fee table.
Not necessarily. Results reflect this organization's process, data and decisions. They do not guarantee the same outcome for another company.
A useful first conversation starts from your situation. If you can, bring:
