Odoo Projects Consultant in Denmark

Billing models for Danish consultancies and technical firms

In Odoo, how a project is billed is decided largely by the service product on the sales order. That product determines whether a project or task is created and whether invoicing follows the ordered quantity, the hours logged or milestones reached. Getting the product design right does most of the work.

The revenue types I map for a Danish IT or technical services firm:

• Fixed-price projects: an implementation or installation at an agreed price, invoiced on milestones or on a payment plan. Hours are still logged to measure margin.
• Hourly work: support, change requests and consulting billed on logged hours, sometimes against a prepaid block of hours that is drawn down.
• Recurring fees: hosting, licenses resold under your own agreements, monitoring or maintenance billed per month, quarter or year.
• Call-outs: emergency or ad hoc visits with a call-out charge plus time and materials.
• Mixed orders: a fixed installation with hourly extras and a service agreement starting after handover, all on one customer.

For each type I write the rule in plain language, agree it with sales and finance, and set it in Odoo. Then I replay a sample of past months in a test database and compare the invoices Odoo would create with what was actually sent. The general product mechanics are on my Odoo Projects page.

Service agreements, subscriptions and field visits

Recurring service revenue can matter a great deal to a Danish technical firm: maintenance of ventilation, heating, security or energy installations, IT support and hosting, or inspection agreements. In Odoo, these usually combine the Subscriptions app for the recurring billing with Field Service or Helpdesk for the work. All three have been Enterprise apps in recent versions, so confirm with Odoo or the partner before designing around them.

The design questions for agreements:

• Scope: what is included, such as a number of preventive visits or support hours, and how work outside scope is identified and billed.
• Billing rhythm: monthly, quarterly or yearly in advance, and how mid-period starts are handled.
• Indexation: how prices are adjusted under your contract terms.
• Planning: preventive visits generated from agreements and scheduled alongside project work.

And for field visits:

• worksheets in Danish written by your service lead, completed on a phone or tablet
• parts taken from van stock, with replenishment and counting rules
• customer sign-off captured on site
• a finished visit turning into invoice lines or being marked as covered by the agreement

If agreements are a small share of your revenue, recurring sales orders or simple project tasks may be enough. I test both approaches with your actual agreement list before recommending the apps.

Timesheets that support both invoicing and the bookkeeping trail

Timesheets serve two purposes in a Danish service firm. They drive invoices and margins, and they form part of the documentation behind what was billed. Danish bookkeeping rules expect transactions to be documented and traceable; how that applies to time records supporting invoices is for your accountant or auditor to judge, but a clean design makes their answer easier.

The policy I agree with delivery managers and finance covers:

• Level: logging against projects, tasks, tickets or visits, chosen so staff can find the right line quickly.
• Timing: how soon after the work hours must be logged, with a cut-off before invoicing runs.
• Approval: who checks hours before they are invoiced. Timesheet validation features have been Enterprise in recent versions.
• Included versus billable: how hours covered by an agreement or a fixed price are separated from hours billed on top.
• Descriptions: what a time entry description must say when it will appear on a customer's invoice, written in Danish.
• Changes after invoicing: how corrections are made once hours have been billed, so the trail stays intact.

Payroll in Denmark normally runs in a dedicated payroll system or with a provider, so Odoo timesheets stay focused on project and service time. Where hours must also reach payroll, I define a controlled export and test it over a full period with your provider.

Invoicing public customers: references and location numbers

Municipalities, regions and state bodies can be important customers for a Danish IT or technical service firm. They receive invoices electronically, in formats such as OIOUBL or Peppol formats, and each receiving unit is identified by its own location number, often called an EAN number. An invoice with a missing or wrong location number, order number or contact reference can be rejected.

For project and service billing, the difficulty is that one public customer can have many receiving units. A municipality might need the school, the care home and the technical department invoiced separately, each with its own location number and reference person. In Odoo I design this as:

• separate invoice addresses under the customer, each carrying the location number of its unit
• the order or requisition number and contact reference stored on the project or sales order
• agreement invoices addressed to the right unit automatically each period
• a check before invoicing that blocks public invoices missing required references

Sending the documents themselves, and how your Odoo version and edition handle OIOUBL or Peppol delivery, is configured in Odoo Accounting. The Odoo Accounting page for Denmark covers that, along with payment codes and digital bookkeeping requirements. I test project, agreement and credit note invoices to a test receiver with finance before go-live.

Edition, hosting and when Odoo Projects is the wrong tool in Denmark

Project and Timesheets are in Odoo Community. Field Service, Subscriptions, Helpdesk, Planning and timesheet validation have been Enterprise in recent versions. For a Danish service firm that relies on agreements and visits, the edition question is therefore real rather than theoretical. Confirm the split with Odoo or the partner for the version you will run. Hosting matters too: Odoo Online restricts custom modules, which can limit a payroll export or a bespoke integration with a customer portal, while Odoo.sh and self-hosting allow them.

Odoo Projects is a poor fit when:

• Construction contracting dominates, with progress billing, retention and on-account invoicing under Danish building contract terms, where construction-focused software fits better.
• A PSA tool is already working: a dedicated professional services system tied to a good accounting package may be simpler than moving everything.
• Only time tracking is missing: if accounting and invoicing already work in e-conomic or another package, a lighter tool may be enough.
• No owner exists for service products, agreements and timesheet discipline after launch.

I am not an Odoo partner and take no commissions, so I can recommend another route when it fits. See Zoho Projects in Denmark, Odoo consultant Denmark, the Denmark hub and my service management ERP page.