A project can look profitable because its direct expenses are visible while office costs, support staff or another shared service sit elsewhere. Analytic accounting in the Odoo application helps you view revenue and cost by project or department. A useful result starts with an allocation basis your team can explain.

Odoo’s 19.0 documentation covers analytic plans, accounts, invoice-line distributions and distribution models 1. The Government Finance Function’s service-costing guide provides a method for identifying direct and shared costs and documenting an allocation basis 2. We use it as a management reference for a Saudi business, rather than treating British guidance as a Saudi accounting requirement.

At ToDoOps, Odoo implementation begins with the decision you need to make: which project carries its costs, and which department needs attention? A shared invoice and a representative report are better starting points than a large analytic structure that nobody can maintain.

Define the profitability question first

Do you want to compare projects, understand a department’s cost or monitor a service contract? Those are different dimensions. A project may have an account within a Projects plan, while a department has one within a Departments plan. The two views do not mean the business incurred the expense twice.

Define each report’s boundary: period, revenue included, cost categories covered and exclusions still outstanding. A margin after materials alone answers a different question from a margin after labour and shared support. Name the measure so that the owner does not compare two numbers built on different definitions.

Use our Odoo application directory to identify where costs and supporting data originate, and industry solutions to connect the design to your activity. You do not need to copy the entire financial chart of accounts into analytics. You need dimensions that support real decisions and named owners for their use.

Separate direct costs from shared costs

An expense belonging to one project can be assigned directly where evidence supports it. A service benefiting several projects needs a cost pool and an allocation basis. The service-costing guide recommends resource-related drivers, documented exceptions and reconciliation to source systems before modelling 2.

Expense Question to resolve Possible basis to approve
Material for one project Is there a reliable project reference? Direct assignment
Shared support Are hours by project dependable? Benefiting service hours
Shared premises Does actual occupancy differ? Relevant floor area
Shared digital service Is suitable usage data available? Users or consumption
Unclear relationship to projects Does allocation support this decision? Keep visible as unallocated until resolved

These are possible methods, not prescribed percentages. Hours may suit a support team but be a poor basis for rent. Where detailed data is unavailable, a simple, disclosed and reviewed basis is more useful than apparent precision hiding an unexplained assumption.

How does distribution work in Odoo?

In the 19.0 reference, plans group analytic accounts and invoice lines can be split by percentage. Plan applicability can be optional, mandatory or unavailable. Detailed applicability rules override the default setting 1.

We decide where distribution is necessary and where it is irrelevant. Making every entry mandatory can obstruct work with meaningless questions; leaving important expenses optional can produce an incomplete project report. Review the document type, financial account and company, then test an entry inside the rule and one outside it.

Distribution models use conditions such as account prefix, partner, product and company. All conditions specified in a model must match. An accidentally narrow condition can prevent a rule from working; a broad account range or company scope can apply it too widely. The design needs representative tests, not just an attractive percentage split.

Hypothetical example: SAR 12,000 split 60/40

Assume a shared support invoice of SAR 12,000 before VAT for the same reporting period as two projects. Illustrative approved support hours are 600 for Project A and 400 for Project B: 1,000 in total. Hours are the chosen basis in this scenario, not a universal rule for your services.

Item Project A Project B Total SAR
Assumed revenue for the period 50,000 35,000 85,000
Assumed direct cost 30,000 20,000 50,000
Margin before shared support 20,000 15,000 35,000
Share of support hours 60% 40% 100%
Allocated shared support 7,200 4,800 12,000
Margin after this allocation 12,800 10,200 23,000

The calculation is 12,000 × 60% = 7,200 and 12,000 × 40% = 4,800. The total expense has not changed; its project visibility has. These are margins after the costs shown, not company net profit. They do not account for unrecorded commitments, cash flows or taxes.

With an equal split, each project would carry SAR 6,000, giving margins of SAR 14,000 and SAR 9,000. The combined result remains SAR 23,000, but the comparison changes. That sensitivity explains why allocation policy matters before the report informs pricing or performance assessment. Our implementation scope calculators can help estimate the project needed to establish the workflow; they do not calculate these accounting allocations.

Avoid counting one expense twice

Reconcile the invoice total to its distribution within a single plan. Then read project and department plans as separate perspectives. Do not add both report totals and call the sum an extra cost. A SAR 12,000 expense remains SAR 12,000 even when viewed once by project and once by department.

Also distinguish a posted bill from a purchase order or an unbilled commitment. Combining an order’s amount with its resulting invoice without an explicit rule inflates the cost view. When allocating employee effort, check whether labour cost already entered through timesheets is being loaded again from the same payroll pool.

Keep unallocated items visible. The financial ledger can reconcile while a project report omits entries that lack an analytic assignment. Do not remove those differences from the discussion. Identify their reason, correction owner and review date so that the report’s coverage is understood.

Test exceptions and correction as well as the clean invoice

Prepare an invoice matching the model, one with a different partner, one using a nearby financial account outside scope and, where relevant, one from another company. Review the selected accounts and percentages before approval, then trace the report back to the original entry.

Test how an incorrect distribution is corrected, who can make the change and what evidence explains it. Do not assume a dedicated approval workflow or detailed change log for every design without verifying version and permissions. Additional governance should have a defined scope rather than being implied by the word “analytic”.

Our limited sales and inventory demonstration illustrates the basic connected workflow. Your cost-centre model and reports need a separate financial sample. The acceptance outcome is practical: finance can trace a project number to its source and the responsible manager can explain the allocation basis.

Questions before rollout

Does an analytic account replace a financial account?

No. The financial account classifies the nature of a transaction. Analytics adds a dimension such as project or department. Assigning the dimension should not create another copy of the expense.

Must every expense be allocated to every project?

Not necessarily. Define the report’s purpose and the relationship to the activity first. Exclusions should stay visible and explained, rather than disappearing or receiving an arbitrary percentage.

Can the percentages be automated?

Models can apply a distribution when their conditions match. Test matching entries and exceptions, then assign an owner to review the rules when usage, companies or accounts change.

Does a higher margin prove better performance?

It may reflect only a different allocation basis. Compare equivalent periods and explain the effect of a method change separately from changes in the underlying activity.

What should we bring to a requirements discussion?

A shared invoice, a project or department list, the current basis and a report you want to trust. Remove unnecessary sensitive information and identify where finance and operations disagree.

Make the report explainable before expanding it

Start with one cost pool and a clear management decision. Review our Odoo application services, estimate the implementation scope or discuss your cost-allocation workflow. Together we can define the plan, data, applicability rules and reconciliations that make the report useful in daily decisions.

References

[1] Odoo — 19.0 documentation, Analytic accounting: plans, accounts, applicability, distributions and their models. A functional reference to check against the installed version.

[2] Government Finance Function — Service Costing in Government, 2026: cost boundaries, allocation drivers, reconciliation and documented assumptions. A British management method used to explain the decision, not a Saudi requirement.