How to set up OpenProject time tracking and budgets for billing or controlling
To set up time tracking and budgets in a self-hosted OpenProject, configure three things in order: who logs time and at what rate, which budgets and cost types each project uses, and which cost reports finance or controlling exports. A team that needs hours and costs per project for invoicing or internal control should start here, because every figure on an invoice or in a control report depends on this chain. The Community edition is free and includes time tracking, so basic hour logging can begin without a license. Whether unit costs, budgets and cost reports are available in your edition is a question to confirm against the current feature comparison before you configure anything.
Teams usually implement this module after a pilot shows that hours are logged inconsistently, when a client contract requires hour-level evidence for billing, or when the controlling function needs project budgets compared with actual costs. The edition and cost model must be settled first because they determine what you can build. OpenProject's Enterprise on-premises plan is priced per named user per month, with the Basic, Professional and Premium tiers listed at 5.95, 10.95 and 15.95 euros per user per month, a 25-user minimum for Professional, a 100-user minimum for Premium, and Corporate offered on request for 250 or more users. These are the published list prices, so confirm current figures and any terms in writing. Your user count sets the tier, and a later move to a higher tier can change which features you rely on.
Several decisions must be made before anyone enters a rate or a budget. Decide which people are billable, which are internal, and whether rates are attached to individual users or to roles. Decide which currency, tax treatment and project code format the exports must match, because the finance system will reject data that does not fit. If you use single sign-on with SAML or OIDC, or LDAP group synchronization, both listed as Enterprise features, group membership may drive role and rate assignment. In that case the identity design must be agreed with the directory owner before the time tracking configuration begins, so that a change in a directory group does not silently change a cost rate.
Before rollout, confirm the edition's feature list in writing with OpenProject, then pilot the setup on two or three real projects. Reconcile one full month of time entries and cost reports against the figures the billing or controlling team already trusts, and record every difference. Plan the cost in two parts: one-time work for configuration, testing and training, and recurring costs for Enterprise licenses per named user and for the infrastructure you run. Ask any partner for a quote that separates these items, states who pays for each, and lists the assumptions about user counts, number of projects and export formats that the quote depends on.
What OpenProject time tracking and budgets include by edition
Time tracking sits close to the core of OpenProject, but the edition you run determines which parts of the cost and budget workflow you can rely on. The cards below separate what the documented Community edition covers from the items you must verify against the current pricing page and with OpenProject before you commit to them in a statement of work or a controller review.
Time tracking in the Community edition
The free Community edition documents time tracking alongside work packages, Gantt charts, agile boards and dashboards. For a team that only needs hours logged against tasks, this may cover the core workflow without an Enterprise license. Confirm with OpenProject that time entries, the reports you plan to use and the user roles who log time behave as you expect in the edition you choose, and test them in a staging instance before rollout.
Budgets, unit costs and cost reports
Budgets, unit costs and cost reports are the features that turn logged hours into money. They are not described in the same way across editions, so do not assume they come with Community. Check the current pricing page for each edition, then confirm exact availability with OpenProject in writing. Ask whether unit costs can differ by user, role or project, and how cost reports handle currency and rate changes over time.
Edition checks before client or controller commitments
A promise to a client or a controller about billable hours, budget tracking or cost exports should follow an edition check, not a feature list read from memory. Record which edition and version the organization runs, such as the current release line, and note the date of the pricing page you checked. If a feature is missing from your edition, decide whether to upgrade, build an export, or change the reporting promise before the engagement starts.
Enterprise licensing for cost-related features
Enterprise on-premises licenses are priced per named user per month, with tiers and minimum user counts stated on the pricing page. Cost-related features may sit in a higher tier, so the licensing count should be modeled against the people who will log time, not only the people who manage projects. Ask OpenProject which tier includes each feature you need, and ask for the license terms in writing before you size the deployment.
Which time and cost model fits your billing and controlling needs
This table compares the main setup decisions for OpenProject time tracking and budgets, including granularity of time logging, rate models, budget levels and where reporting lives. Read each row for when the option fits, what your team must maintain, and what becomes harder to change once time entries and reports accumulate.
| Decision | When it fits | What it requires from the team | What gets harder later |
|---|---|---|---|
| Log hours against work packages | Billing by task, estimate versus actual per deliverable, or fixed-price work where effort must be traced to scope | Discipline in logging on the correct work package, activity types agreed up front, and a plan for logging against closed or moved items | Restructuring work packages or merging projects reshapes historical cost views, so changes need a reconciliation step |
| Log hours against projects only | Simple internal chargeback or retainer work where the client needs totals, not task detail | Less daily effort for users, but a clear project structure, since every entry is only as specific as its project | Answering questions about which task consumed the budget requires new data, which cannot be reconstructed from totals |
| One hourly rate for all users | Teams with a uniform billing rate, such as a consultancy quoting one blended rate per engagement | Maintaining one rate per project or per activity and confirming who approves rate changes | Differentiating margins by seniority later means reworking rates on past entries, so decide early whether rates may change retroactively |
| Per-user unit costs | Internal controlling where salary-based or contractor-based costs must reflect who did the work | Keeping user cost data current, restricting access to it, and defining how it is maintained when people join or leave | Cost data becomes sensitive and needs access control; sharing cost reports widely later may conflict with HR policy |
| Budgets per project | Controlling the total spend or effort of an engagement and tracking progress against one envelope | Agreeing the budget owner, the currency and effort basis, and how change requests adjust the budget | Splitting one budget into several later makes the comparison with earlier actuals harder to explain |
| Budgets per work package | Fixed-scope deliverables where each item has its own approved effort or cost limit | Estimates maintained for each work package and a process for re-estimating when scope changes | Many small budgets create upkeep overhead, and rolling them up for client reporting requires consistent structure |
| Reports stay in OpenProject | Organizations that accept OpenProject's cost reports as the controlling record and need no separate ledger | Confirming which report views meet finance needs, and who owns report access and retention | Moving to a finance system later requires a mapping of projects, rates and accounts, so exports should be designed early |
| Reports move to a finance system | Invoicing, accruals or statutory accounting must run in the ERP or accounting system of record | An export or integration design covering identifiers, rates, dates, currencies and reconciliation checks | Each change to project structure or rates must be carried into the finance system, and drift between the two records is a recurring risk |
How unit costs, rates and budgets relate in OpenProject
Logged time becomes a cost through a chain of linked settings, and a mismatch between hours and money usually means one link in that chain is configured differently from what the team assumes. A team member records hours against a work package and selects an activity type. OpenProject then applies a unit cost to those hours to produce a cost figure, and budgets compare planned amounts with the costs that accumulate. Each link can be set up separately, so an error at one point appears as a wrong total somewhere else. Before you rely on any total, confirm in the documentation for your exact OpenProject version how each calculation is performed and which settings feed it.
The inputs are time entries, activity types and rates. A time entry stores the hours, date, user, work package and activity. Activity types classify the work, and the list is maintained by an administrator, so renaming or removing an activity changes how older entries are grouped. Unit costs, meaning the hourly rates, are attached to users or roles and may carry validity periods. Decide early whether cost should follow the person, the activity or both, and whether historical entries should keep the rate that applied when the work was done. Ask the vendor what precedence applies when a user, an activity and a project each define a rate for the same entry.
Most mismatches come from a small set of causes. Entries logged to an activity without a rate, or by a user without a rate for that period, produce zero or partial costs without any error message. A rate change may apply to new entries only, so totals for older periods look inconsistent when compared with a fresh calculation. Hours may be stored with more precision than they display, which causes small rounding gaps when figures are added up by hand. Other common causes include entries moved between work packages after a budget was set, time zone differences at the edge of a reporting period, currency and decimal separator settings in exports, and subproject entries that are counted in one roll-up but not another. Each of these produces a total that looks wrong but is computed consistently, so it is easy to miss.
Test the whole setup on a small project before you roll it out. Choose a fixed set of entries with known hours across at least two users and two activity types, and include one rate change in the middle of the period. Calculate the expected cost and budget consumption by hand in a spreadsheet first. Then compare each figure in the time report, cost report and export against your expectation, and investigate every difference until it is explained. Repeat the test after any change to rates, the activity list, permissions or the export format, and record the version you tested. This test is an illustrative check you can adapt, and it does not replace the vendor documentation for your version, which should be confirmed for every calculation your finance team will rely on.
How to set up OpenProject time tracking and budgets in sequence
This sequence takes a team from confirming which OpenProject edition covers its needs to exporting cost data for billing or controlling. Each step ends with a written output, so the next step starts from an agreed baseline rather than from memory.
Confirm the edition and required features
The project owner and the vendor or implementation partner list every time tracking, budget and reporting feature the team needs, then check each one against the current OpenProject pricing page. Time tracking and dashboards are in the free Community edition, while SSO, LDAP group synchronization and custom branding require Enterprise. Confirm in writing whether budgets and cost reports fall under the Community or an Enterprise plan before any licensing commitment. The output is a signed feature list that names the edition and the plan tier.
Decide the cost model
Finance, the project lead and the implementation team agree how labor and other costs reach the books. The decision covers whether cost comes from hourly unit rates per user, rates per activity type, or fixed budget amounts per project, plus the currency and who may approve a change to a rate. Write down which costs are one-time setup effort and which recur as rates change over time. The output is a one-page decision record approved by finance.
Configure projects and roles
The administrator creates the project hierarchy, assigns members, and defines roles that control who can log time, see cost fields, edit budgets and run cost reports. Keep the number of roles small and map each one to a job function in the decision record. Test each role with a dedicated test account for every permission level before real users are added. The output is a role matrix showing each permission and the test result that confirms it.
Set activity types and rates
The finance lead and project managers define the activity types that staff will book time against, then enter the unit rate for each user or role. Ask the vendor to confirm how the system handles rate changes over time, so that past time entries keep their original rate. Review the table with finance before it goes live. The output is a signed-off rate table with a named owner and a record of who approved each rate.
Load budgets
The project managers enter approved budgets at project level and, where the decision record requires it, at work package level, separating labor and any other cost categories. Each figure is checked against the approved budget document, not against a spreadsheet copy that may be out of date. Reconcile the loaded totals with the figures finance holds before any time is booked. The output is a budget register that finance has reconciled line by line.
Pilot with one project
The team runs one live project through time logging for a defined period, using the approved roles, activities, rates and budgets. The project lead compares the logged hours and calculated costs with a manual record kept for the same work, and investigates each difference. Fix configuration errors in a test copy first, then record the change in the decision record. The output is a reconciled pilot report, signed by the project lead and finance, that explains every variance.
Build cost reports and the billing export
The implementation team builds the cost reports that project managers and finance need, then defines the export columns for billing or the controlling system. Finance checks a sample export against the reconciled pilot report and against the accounting system's import format. Agree who runs the export, how often it runs, and how corrections to past entries are handled. The output is an approved export specification and a set of reports that finance has tested against the pilot data.
What drives the effort and cost of the setup, and how to keep it down
This table lists the main drivers of effort and cost for OpenProject time tracking and budgets, who is paid for each, and whether it is one-time or recurring. Use the last column as a list of levers to agree with your partner before scope is fixed. The largest recurring item is usually the Enterprise plan, so ask for its cost on the OpenProject pricing page and confirm which plan includes the budget and SSO features you need before you commit.
| Driver | Why it changes cost or effort | One-time or recurring | How to keep it down |
|---|---|---|---|
| Number of projects and rate tables | Each project and each rate table needs configuration, mapping to cost types and testing. More rate sets mean more checks. | One-time build, recurring when rates change | Use one rate table per role or cost type and reuse it across projects. |
| Finance rules for billable and non-billable time | Finance decisions define activity types, custom fields and report logic. Unclear rules cause rework during build and testing. | One-time | Have finance write the rules and activity list before the build starts. |
| Historical data to bring in | Past time entries, budgets and users must be mapped, cleaned and checked against reports. Volume and data quality drive the work. | One-time | Limit history to the periods that open billing or controlling needs, and confirm the import method first. |
| Approval workflows for time entries | Approval steps need design, role setup and testing, and they add review work for managers on every reporting cycle. | One-time build, recurring review effort | Keep to one approval step where the controls allow it, and set clear submission deadlines. |
| SSO and user provisioning | SSO (SAML, OIDC, CAS, Kerberos, Okta) and LDAP group synchronization are Enterprise features, and each user adds to the named-user count. | One-time integration, recurring per user | Provision only people who log time, and map groups to roles so access does not need manual changes. |
| Number of export formats | Each billing or controlling export needs a layout, field mapping and test against the receiving system. | One-time per format, recurring if formats change | Standardize on one layout that your billing or ERP import accepts, and add others only when needed. |
| Enterprise plan licenses | Named-user licenses: Basic 5.95 EUR, Professional 10.95 EUR (25-user minimum), Premium 15.95 EUR (100-user minimum), per the OpenProject pricing page. | Recurring, per named user per month | Request the Enterprise plan cost from the pricing page, confirm which plan covers budgets and SSO, and do not assume a price. |
| Hosting and sizing | Infrastructure you run is sized by user count. The OpenProject sizing guide lists 4 cores and 4 GB RAM for up to 200 users. | Recurring infrastructure cost | Size for active users who log time rather than total headcount, and review sizing when the user count changes. |
Moving historical time and cost data into OpenProject
Historical hours and costs are the part of a Jira move that the documented migrator does not carry for you. The OpenProject Jira Migrator documentation lists projects, issues, versions, custom fields, users, groups, statuses and types as imported content. Issue relations and sprint assignments are listed as coming soon, workflows and permissions are listed for later, and time entries are not listed as a supported object. For this topic, the worklogs behind your Jira reporting and the budget figures your finance team reviews should be treated as a separate workstream until the vendor confirms otherwise in writing. Ask for the current status of time entries before you assume any hours will arrive.
The migrator is in beta, and its documentation advises using it only in test setups. It supports Jira Data Center 10.x and 11.x as sources, not Jira Cloud, so the first check is the exact version your Jira instance runs. If you run Jira Cloud, the documented path does not apply to your source at all, and you need a different plan for every object in this topic. Even on a supported Data Center version, run the migration on a staging OpenProject instance and treat the result as a rehearsal. Keep the production Jira instance readable and unchanged throughout, so you can re-export worklogs and rerun any scripted step without guessing what the source looked like on cutover day.
For historical time entries, the practical path is an export from Jira followed by a controlled import that you build and test. Export worklogs with the user, issue key, date, hours, activity and any cost code fields your teams use. Then map each Jira user to an OpenProject user, each issue to the work package it was migrated to, and each cost code to the custom field or activity your budgets use. Confirm how OpenProject expects imported entries to be dated and attributed, and whether entries created by a script can be told apart from entries logged by people. Decide whether historical hours should be imported at all, or kept in a read-only archive that finance can query alongside the new reports.
Unit costs and budgets need their own decisions. OpenProject time tracking and budgets depend on the rates and budget values you configure, and rates and budget values are not on the documented list of migrated objects, so confirm what rate history your finance team needs for past periods. Historical rates may differ from current ones, and applying a single rate retroactively will change prior cost totals. Decide whether budgets for active projects will be recreated by hand, and whether closed projects need budgets at all. Before finance signs off, reconcile hours per project, user and period against the Jira totals, and record every difference and the reason for it.
When you request a quote, ask for this work as its own line item, separate from the general migration. A written scope should name the export method, the mapping tables, the import script or manual steps, the number of rehearsal runs, the reconciliation report and who signs it off. Effort is driven by the volume of worklogs, the number of users and cost codes to map, the amount of rate history to rebuild, and the quality of the Jira data, such as missing users or deleted issues. Ask how each step is repeated during the production cutover and what happens when a worklog cannot be matched. Those answers decide whether historical data arrives complete or becomes a documented archive.
Connecting time and cost data to the rest of the platform
Time and cost data only stays useful when it moves between OpenProject, the file store, the identity provider and the finance tools. This section covers the documented connections, which edition each one needs, and the export path that your team must define before the first timesheet is logged.
Nextcloud files on work packages
The Nextcloud integration is available in the Community edition and links Nextcloud files and folders to work packages, so time booked against a task sits next to the documents that explain it. It can also manage project folders automatically. Check which Nextcloud version and sharing model your organization uses, and decide who owns the folder structure before the integration creates folders for existing projects.
SSO for the Nextcloud connection
Single sign-on through an OpenID Connect provider for the Nextcloud integration is an Enterprise add-on, not part of the Community edition. Teams that want one login across OpenProject and Nextcloud must budget for that add-on and confirm it with OpenProject before design starts. Test the sign-in path with a non-administrator account, since users who cannot log in will not be able to attach files.
Enterprise single sign-on protocols
OpenProject lists SAML, OIDC, CAS, Kerberos and Okta as Enterprise single sign-on options. Choose the protocol your identity provider already runs for other applications, and confirm which options your OpenProject plan includes at the time of purchase. Record the attribute mapping for name, email and login, because time entries and cost reports are tied to the user account created at first sign-in.
LDAP group synchronization
LDAP group synchronization is an Enterprise feature that maps directory groups to OpenProject groups. For time tracking and budgets, the important question is who can view cost rates and budgets, since group membership drives roles on projects. Agree the group model with finance and project management, and test that a user removed from a directory group loses access to cost data in OpenProject.
Export into billing or controlling
OpenProject reports can be exported, but the target system, the file format and the mapping of projects, users, activity types and cost types to ledger or billing codes must be defined by your team. Confirm the export format and the target system in your environment, then test a full month of entries against the invoices or cost centers it will feed. Assign an owner for the mapping, since changes to project structure later break the link.
Identity and access changes
Moving users between identity providers, renaming accounts or changing group names after time has been logged can split one person's history across two accounts. Plan identity changes before go-live, and document how historical time entries will be reassigned if an account has to be replaced. Confirm the behavior of account deprovisioning with your OpenProject administrator before relying on it for cost accountability.
Questions buyers ask before hiring help with OpenProject time tracking
How much does it cost to hire help with OpenProject time tracking?
DeployOpen does not publish a price list, so the cost comes from a quote built on a written scope. Most of the spend is labor: scoping rate categories and budget rules, configuring time logging and cost reports, building any export to your billing or controlling system, testing with sample data from your finance team, and training the people who log time. Those are mostly one-time costs. Recurring costs depend on the edition. The Community edition is free and includes time tracking. OpenProject Enterprise on-premises is priced per named user per month: Basic at 5.95 euros and Professional at 10.95 euros (25-user minimum), Premium at 15.95 euros (100-user minimum), and Corporate on request for 250 or more users, according to OpenProject's pricing page. Ask the vendor which edition includes unit costs, budgets and cost reports, and ask your finance team which cost centers, rates and currencies the quote must cover.
Does OpenProject time tracking with budgets require an Enterprise license?
Time logging is in the free Community edition, but the supplied pricing information does not settle whether unit costs, budgets and cost reports sit in Community or Enterprise. Confirm that against the current OpenProject pricing page before you buy. Enterprise on-premises adds features that often come up in the same project, including single sign-on through SAML, OIDC, CAS, Kerberos and Okta, LDAP group synchronization and custom branding. If your identity or access requirements call for those, the license decision is partly made for you. Enterprise pricing is per named user per month, so size the license count to the people who need access to the feature, and remember that the Professional and Premium tiers carry 25-user and 100-user minimums.
How long does OpenProject time tracking setup usually take?
No duration figure is available for this work, so the reliable answer is the one your written scope gives you. Most engagements are fixed scope, and timelines are agreed in writing before work starts. The main duration drivers are the number of projects that need budgets, how many rate categories and currencies you use, whether time entries must be approved before they reach a cost report, how many export targets exist, and how much historical data must be moved and checked. Platform readiness also matters. A Linux host, a PostgreSQL 16 or later instance with the required extensions, and access for your administrators can run in parallel with design work or can hold the project up. Ask for a milestone plan that names the decisions you must make and the date each one is due.
What does the client need to provide for OpenProject time tracking work?
Most delays come from inputs the client has not yet decided. Name a business owner for rate tables and budget rules, a finance contact for cost centers and billing periods, and a project list with the people who log time and their roles. Provide a sample of the export your billing or controlling system expects. Confirm the hosting target: OpenProject's sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. Docker is the recommended installation method, and packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. The database must be PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. Plan a test instance for sign-off as well.
Can our internal team set up OpenProject time tracking without a partner?
Yes, for basic time logging an internal team can usually do it, because the Community edition includes time tracking and the platform is documented. The harder parts are budget structures, rate logic, approval paths and exports that finance will accept. Those depend on accounting knowledge as much as on OpenProject administration. Your team also needs working skills in Docker or Linux, PostgreSQL administration, backups and upgrades, since OpenProject ships regular releases, including 17.7.0 on August 5, 2026, 17.8.0 on September 2, 2026 and 17.9.0 on September 30, 2026. Weigh the staff hours against the cost of an error in a billing report. A practical test is a pilot with two projects and one export carried through to your finance team before you roll out company-wide.
What makes OpenProject budget and cost report work cost more or less?
The biggest drivers are the number of rate categories and currencies, how many projects need separate budgets, and whether reports must match an existing invoicing or ERP system closely. Each added export format, reconciliation rule or approval step adds design and test time. Migrating historical time data is a separate cost. OpenProject's Jira migrator is in beta and imports from Jira Data Center 10.x and 11.x only, so Jira Cloud is outside its documented scope, and the documentation advises using it only in test setups. Its listed scope covers projects, issues, versions, custom fields, users, groups, statuses and types, while issue relations and sprint assignments are listed as coming soon. Time entries do not appear in that list, so confirm with the vendor whether and how your historical logs move before the quote assumes they will.
What should a quote for OpenProject time tracking include?
A useful quote lists the deliverables, the environment, the acceptance tests and the exclusions in writing before work starts. Ask for the edition and license count the design assumes, the rate and budget structures to be built, each export and its target format, the test cases used to sign off cost reports, the training sessions and documentation, and the handover steps. Confirm who pays for hosting, backups and license renewals, since those recur, and whether ongoing support, upgrades and maintenance are included or offered as a retainer. Ask what changes the price after sign-off, such as adding projects, currencies or export targets. A fixed scope gives you a figure to compare against your own team's estimate, but only if both sides describe the same work.
How DeployOpen scopes and delivers OpenProject time tracking and budgets
DeployOpen scopes time tracking and budgets as part of the OpenProject deployment, starting from how your teams log time, which rates and unit costs apply, and which reports your billing or controlling processes need. Each engagement is fixed-scope, and the written scope is agreed before work starts. Ongoing support is available as a retainer.
How we scope
- The written scope lists the projects, roles and users that will log time and view budgets.
- We confirm which time tracking and budget features your chosen edition and release provide before design starts.
- The scope records export needs for billing or controlling, including file format, cadence and recipients.
How we build
- We configure time logging, activity types, unit costs and project budgets according to the agreed scope.
- We set up cost reports and filters that match your billing and controlling views, then test them with sample entries.
- We verify permissions so that only authorized roles can see rates, cost data and budget figures.
How we hand over
- We document time logging rules, budget setup and report definitions so your administrators can maintain them.
- We walk through the exports used for billing or controlling with the people who run those processes.
- We deliver a handover record covering the configuration, tested reports and any open items for your team.
How we support
- Ongoing support is available as a retainer for changes to rates, budgets and cost reports.
- Upgrades to new OpenProject releases are reviewed for changes that could affect time and cost data.
- Confirm the support terms and response expectations in the written scope before work starts.
