Odoo Project Billing: Turning Billable Time Into Invoices

What Odoo project billing actually is

Odoo project billing is the link between three apps that already exist in the suite: Sales, which holds the order the customer agreed to; Project, where the work is tracked as tasks and timesheets; and Invoicing or Accounting, where the invoice is posted to the ledger. The point of the link is that the same record the consultant fills in (a timesheet line) is the record the finance team invoices from. There is no second billing spreadsheet and no end-of-month reconciliation between a time-tracking tool and the books.

The technical hinge is the service product. A product whose Product Type is set to Service can carry an Invoicing Policy such as Based on Timesheets or Based on Milestones, and a Create on Order setting that tells Odoo to spawn a project and task the moment a sales order is confirmed. That single product configuration is what makes a project billable end to end, because it is what ties the analytic account on the sales order to the analytic account on the project's timesheets.

Underneath it all sits the analytic account. Odoo's documentation is explicit that for any record to appear on the project profitability dashboard it must be linked to both the project and its analytic account, and that same account is what lets a single timesheet show up once as revenue (what the customer pays) and once as cost (what the employee earns) without doubling the books. Get the analytic account right and billing, margin, and cost reporting all read from one source of truth.

The billable chain: sales order to invoice

The cleanest way to understand Odoo project billing is to walk the chain in the order data actually moves. It starts in Sales with a quotation for a service product configured to invoice Based on Timesheets and to create a Project and Task on order. The moment the quotation is confirmed, Odoo creates the sales order and, because of the Create on Order setting, automatically creates the matching project and task in the Project app. Two smart buttons on the order (Projects and Tasks) take you straight to them.

Work then happens where work always happens: on the task. Team members open the task's Timesheets tab and add lines for the date, the employee, and the hours spent. According to Odoo's time-and-materials documentation, those hours are immediately reflected back on the sales order in the Delivered column and in a Recorded Hours smart button. The delivery, not the order, is what makes the work billable, which is the whole difference between selling time and selling a fixed product.

Invoicing is the last step, not a separate process. From the sales order you click Create Invoice, choose Regular invoice, and Create Draft Invoice. Odoo writes a customer invoice draft pre-filled with the work delivered, and the Analytic Distribution column on the invoice lines is what keeps that invoice tied to the project's profitability. Confirm the draft and it posts to the ledger, moving the corresponding amount on the profitability report from To invoice into Invoiced. No step in that chain requires typing the hours twice.

The same chain supports incremental billing. A two-week sprint can be billed as a regular invoice for hours logged so far, leaving remaining hours for the next cycle, while the sales order’s Amount to invoice keeps a running tally of what is still billable. Finance does not need a parallel tracker; the sales order is the billing queue.

Service product invoicing policies explained

The Invoicing Policy on the service product is the single decision that determines when a billable project earns revenue. Odoo's general Sales documentation frames the choice as invoicing what is ordered versus invoicing what is delivered: the default is Ordered quantities, where a customer is invoiced once the sales order is confirmed, while Delivered quantities waits until a delivery is validated before an invoice can be created. For services, that choice is specialized into the policies that drive the profitability report.

Odoo's project profitability documentation is explicit that timesheet revenue is broken down according to the Invoicing Policy on the product form, naming three service-specific options: Prepaid or Fixed Price, Based on Timesheets, and Based on Milestones. Each one answers a different commercial question, and picking the wrong one is a classic cause of billing disputes and skewed margins, so it should be decided per product during implementation rather than at go-live.

Commercially, services firms usually map those policies onto four engagement styles: pure time-and-materials, fixed-fee or prepaid productized work, phased milestone delivery, and retainers. Retainers in stock Odoo are typically modeled as prepaid or fixed-price service products (or Subscriptions for recurring cadence), not as a separate timesheet policy—overage hours still need a Based on Timesheets line if you bill beyond the included allotment.

T&M, fixed price, milestones, and retainers mapped to Odoo

Policy labels in the product form are not the same as the commercial conversation with a client. Map the engagement first, then choose the product policy that matches how cash is supposed to move. Getting this wrong is the most common reason hours sit in To invoice forever or invoices go out before work is done.

Hybrid deals are normal: discovery on T&M, build on milestones, and a prepaid support block for the first ninety days. Odoo handles that with multiple sales order lines, each with its own service product and Invoicing Policy, sharing one project analytic account. Unified reporting stays clean when every line carries the same analytic distribution; it fragments when teams invent a second project for each policy.

Time-and-materials billing with Based on Timesheets

Based on Timesheets is the policy most professional services firms reach for first, because it bills exactly the hours the team logged. To use it, the Timesheets feature must be enabled in the Project app's settings, Analytic Accounting must be checked under Accounting settings, and the service product must have its Product Type set to Service with Invoicing Policy set to Based on Timesheets and Create on Order set to Project and Task. Only products configured this way can invoice time spent on a project.

Once a sales order carrying that product is confirmed, the project and task appear automatically, and every timesheet line added to the task flows back to the order's Delivered column. When it is time to bill, Create Invoice on the sales order produces a draft that lists the delivered work, and Odoo's documentation stresses watching the Analytic Distribution column on that draft, because that distribution is what keeps subsequent time-and-material invoicing accurate and tied to the right analytic account.

Rate design matters as much as the policy. In the default configuration, project-rate billing uses a single service product and a single unit price for every timesheet on the engagement—suitable for blended-rate SOWs. Employee- or role-oriented billing is achieved by putting separate sales order lines (for example Senior Consultant and Analyst) at different unit prices and mapping people to the correct line on the project’s invoicing configuration so each timesheet inherits the matching rate. That mapping is person-based in standard Odoo: when someone rotates off a project, the mapping needs a deliberate update or the wrong rate ships on the next invoice.

What standard Odoo does not ship is a full professional-services rate card matrix—client-specific role rates, weekend multipliers, volume tiers, and pre-bill write-offs. Those patterns are common in consulting and legal work and typically require process design, pricelist discipline, or a custom module. For most SME services firms, clean product lines, correct employee mapping, and a weekly create-invoice rhythm close more leakage than a complex rate engine.

Milestone and fixed-price billing

Milestone-based invoicing is built for work delivered in clearly defined phases, billing customers progressively as each stage completes instead of all upfront or all at the end. Odoo configures it at the product level: a Service product with Invoicing Policy set to Based on Milestones, and a Create on Order of Project, Project and Task, or Task. Notably, Odoo's milestone documentation states that the Based on Milestones option only appears once at least one project has Milestones enabled, and that a project template can pre-define the milestones for every new project spun from a sales order.

The billing trigger is deliberate. Reaching a milestone does not automatically create an invoice; instead, marking a milestone as reached updates the Delivered percentage on the sales order line, which updates the amount ready to invoice. A four-stage implementation split into 25 percent increments, for example, exposes exactly one quarter of the fee as billable each time a stage is signed off. Only then does Create Invoice turn that delivered amount into a draft invoice, and the process repeats until every milestone is complete.

Fixed-price and prepaid work uses the same chain with the Ordered quantities policy: the full fee is billable on order confirmation, and a down payment is the mechanism for collecting part of it early. Odoo's down payments documentation is careful to distinguish a down payment (an upfront invoice for a percentage or fixed amount of the order) from a payment term or installment plan on a single invoice, and it warns that combining a down payment with a Delivered quantities policy can force a credit note when nothing has yet been delivered, because Odoo does not allow negative invoice totals.

Re-invoicing expenses, materials, and purchases

Billable projects rarely contain only time. Travel, lodging, subcontracted services, and pass-through materials all need to reach the customer's invoice, and Odoo routes them through the same analytic account as the timesheets. The time-and-materials documentation shows that an expense recorded in the Expenses app can be tied to a sales order through the Customer to Reinvoice and Analytic Distribution fields, after which it appears as its own line on the order and can be invoiced with Create Invoice just like delivered hours.

There is an important precondition. That Analytic Distribution field will only offer the sales order as an option when the order contains a service product billed Based on Timesheets, Based on Milestones, or on Delivered Quantities. For purchases specifically, the product on the purchase order must be marked Can be Expensed, have its Invoicing Policy set to Delivered quantities, and use the At cost option in the Re-Invoice Expenses field, so that the vendor bill lands on the project and can be passed through to the customer at cost.

The effect is that every cost-bearing record on the project (a timesheet, an expense, a validated purchase, a vendor bill) can become a revenue line on an invoice with no manual copy. Because each one carries the project's analytic account, it also appears in the right place on the profitability report, which is what lets a services firm see margin in real time rather than reconstructing it after the fact from three different systems.

Project profitability and the billable amounts

Billing is only half the picture; the other half is knowing whether the billable work is actually profitable. Odoo's project profitability dashboard sits inside the project and reads every record linked to the project and its analytic account. It splits into Revenues and Costs, and the same timesheet appears in both sections simultaneously, once as the revenue the customer pays for the work and once as the cost of the wages paid to the employee, so margin is the difference rather than a number stitched together from separate reports.

The report organizes amounts into three columns that mirror the billing lifecycle. Expected holds amounts anticipated from existing sales or purchase orders; To invoice (for revenues) or To bill (for costs) is where amounts move once work is delivered, such as when a timesheet is created or validated, a delivery is marked done, or a delivered quantity is updated on the sales order; and Invoiced or Billed is where they land once an invoice or bill is confirmed. Reading those columns tells a project manager exactly what has been earned but not yet billed.

Operationally, treat the To invoice column as the week’s work queue for finance. If hours pile up there while utilization looks healthy, you are leaking cash even though utilization reports look fine. Cost-side timesheet amounts come from the employee’s HR cost settings, so a missing cost rate makes revenue look perfect and margin look invented.

Where project billing leaks revenue (and how to close it)

Unbilled hours are the silent leak professional services partners talk about constantly: time is worked, utilization looks fine, and cash never follows. Odoo partners and practitioners repeatedly frame the problem as disconnected tools—spreadsheet timesheets, a separate PSA, and a finance system that never see the same analytic account. The native sales-order-to-invoice chain exists to remove that gap, but only if every hour lands on a billable task linked to the right order line.

Leakage is rarely one bug. It is a stack of small configuration and process misses: time logged on a non-billable internal project, a product with the wrong Invoicing Policy, missing employee-to-SO-line mapping so hours deliver to the wrong rate, expenses without Customer to Reinvoice, and a finance calendar that only creates invoices at month-end after clients have already disputed the period. Each miss shows up differently on the profitability dashboard—hours stuck in To invoice, revenue at the wrong unit price, or cost with no matching sales line.

Close the leaks with a short operating rhythm rather than a bigger report. Require timesheets on the sales-order-linked task (not a free-text project), review Delivered versus Ordered on open sales orders weekly, create draft invoices on a fixed cadence, and reject time that has no sales order item before the period closes. When migrating from another billing stack, keep the cutover on a period boundary, leave open invoices in the old system, and run one parallel billing cycle so mismatches surface before customers do.

Getting the configuration right

Most project billing problems in Odoo trace back to a handful of configuration steps skipped at setup. The apps must be installed in the right relationship, the features must be switched on, and the service product must carry the policy that matches how the work is actually sold. None of it is difficult, but each step gates the next, so it is worth laying them out as a checklist rather than discovering them one error message at a time.

Two warnings recur in the documentation and are worth flagging before the checklist. First, reaching a milestone does not create an invoice automatically; it only updates the delivered quantity, so a finance step is still required to turn a reached milestone into a posted invoice. Second, mixing a down payment with a Delivered quantities policy can produce a credit note instead of an invoice when nothing has been delivered yet, because Odoo refuses negative invoice totals, a behaviour that is correct but surprising the first time you hit it.

Projects themselves should be marked billable under Sales & Invoicing when you create or configure them from the project side, and service products used for helpdesk or field time follow the same Based on Timesheets pattern once Time Billing is enabled on the team. Consistency across Project, Helpdesk, and Field Service keeps finance from inventing a second process for “almost the same” hours.

• →Install Project and Accounting, then enable Analytic Accounting under Accounting settings, because no record shows on profitability without an analytic account.
• →Enable Timesheets in the Project app's Time Management settings; time-based invoicing is unavailable until this is on.
• →Set the service product's Product Type to Service, then choose the Invoicing Policy (Based on Timesheets, Based on Milestones, Prepaid or Fixed Price) and the Create on Order behavior (Project and Task, Project, or Task).
• →For milestone billing, enable Milestones on at least one project first, because the Based on Milestones policy only appears once that condition is met.
• →For multi-rate T&M, create one service product line per billable role on the sales order and map employees to those lines on the project invoicing configuration.
• →For re-invoiced purchases, mark the product Can be Expensed, set its Invoicing Policy to Delivered quantities, and use At cost for Re-Invoice Expenses so vendor bills pass through cleanly.
• →Watch the Analytic Distribution column on draft invoices, since that linkage is what keeps time-and-materials billing and profitability accurate.
• →Run a weekly billing review: open sales orders with Amount to invoice greater than zero, create drafts, and clear To invoice before the next period starts.

How it compares to Dynamics 365 Project Operations

Microsoft's counterpart for billable project work is Dynamics 365 Project Operations, and its billing model is built around actuals rather than a product policy. Microsoft's documentation defines actuals as the reviewed and approved financial and schedule progress on a project, created when time, expense, and material usage entries, journal entries, and invoices are approved, and it notes that the way actuals are generated depends on whether the engagement uses a time-and-materials or fixed-price billing model. In other words, the approved entry, not the sales order line, is the atom that eventually becomes an invoice.

That is a fundamentally different architecture from Odoo's. Where Odoo makes a service product on a sales order the trigger and lets the analytic account carry cost and revenue, Project Operations generates cost and sales actuals on approval, then funnels those actuals into invoice proposals for confirmation. Microsoft's time overview confirms the upstream: time entries record the actual time a resource consumes and are used to calculate cost and sales prices, and team members submit them for approval, with the ability to recall an entry for correction. The correction model is therefore heavier, using recall and correction journals to reverse or edit actuals, where Odoo leans on a manager validation step and draft invoices or credit notes.

For an SME choosing between them, the trade-off is depth versus weight. Project Operations brings a work-breakdown-structure-first design, deep resource scheduling, and tight ERP-side finance for project-heavy organizations, at the cost of a Dataverse and Power Platform deployment. Odoo delivers the same sales-order-to-invoice chain in a lighter, Kanban-first, modular app model on a single database, which is why smaller services firms often reach its threshold faster. The decision is less about which can bill a project, both can, and more about how much project-management machinery the organization actually needs around the invoice.

Frequently asked questions