Who the module is for and what it fixes
Short answer: companies that sell outcomes as projects rather than units — professional services, systems implementation, construction, engineering, agencies.
Their shared problem is timing. Profitability becomes clear after the project closes, when nothing can be changed. The projects module attaches every cost — people's time, materials, subcontractor services, travel — to a specific piece of work, so margin is calculable at any moment rather than at the end.
The test worth applying. If your project manager cannot answer "are we still inside budget on this job?" without opening a spreadsheet, the accounting is retrospective. Everything below is about making it current.
Resources: people and equipment as a source of cost
| Object | What it describes | Why it matters |
|---|---|---|
| Resource | A person or a piece of equipment | Carries a unit cost per hour and a unit price per hour |
| Resource group | A set of interchangeable resources | Lets you plan by role rather than by named person |
| Capacity | Available hours from the calendar | The basis for spotting overload |
| Work types | Categories of work with their own rates | Different rates for design, development, on-site work |
The critical pair is unit cost and unit price. The first produces project cost, the second produces revenue. If those rates are blank or filled in roughly, profitability will be roughly wrong no matter how carefully the documents are posted.
Capacity comes from the resource calendar and shows how many hours a person is genuinely available. That is what lets you see overload before a deadline slips rather than after.
Project structure: tasks and planning lines
A project consists of tasks, and tasks consist of planning lines. These are two different levels, and confusing them is the most common mistake at the start.
| Level | What it is | Example |
|---|---|---|
| Task | A stage or work package | Discovery, Configuration, Training |
| Planning line | A specific cost or revenue item within a task | 20 consultant hours, licences, travel |
| Line type | Budget, Billable or Both | Determines what becomes cost and what becomes an invoice |
Line type is the field that does the real work. Budget plans internal cost. Billable forms what the client will be invoiced. Both does each at the same figure. This single field is how the system separates planned cost from future revenue.
Most services firms keep Budget and Billable separate, because internal cost and client price are rarely the same number. Fixed-price work is the usual exception.
For repeatable engagements, copy the structure from a previous project or use a project template — the next job of the same type takes minutes to set up rather than an afternoon.
Where actual costs come from
| Source | How it reaches the project |
|---|---|
| Employee time | Project journal or approved timesheets |
| Materials | Inventory issued against the project |
| Subcontractor services | Purchase orders linked to the project |
| Travel and expenses | Expense documents carrying the project code |
| Freight and item charges | Landed cost allocated to project items |
Timesheets deserve separate mention because they carry an approval step: the employee fills them in, a manager approves, and only then do the hours land on the project. That approval is the difference between real time accounting and a spreadsheet completed from memory on the last day of the month.
Invoicing and margin control
Billing method is set per project: fixed price, time and materials, milestone-based, or prepayment. Invoices are generated from planning lines marked Billable — nothing is retyped by hand.
Project statistics show the numbers that matter at any point: budgeted versus actual cost, invoiced versus remaining to invoice, and current margin.
Three readings and what they mean in practice:
- Costs exceed budget mid-project. A signal to renegotiate scope or agree additional fees now, while the client still associates the request with work in progress.
- Invoiced is well below delivered. Cash is trapped in unbilled work. In services businesses this, not profitability, is usually what causes cash-flow pressure.
- Margin below plan from month one. Almost always underestimated effort at quoting stage. Visible early enough to fix the estimating model for the next proposal.
What to decide before you configure
- Rate structure. One rate per person, or rates per work type — this shapes everything downstream.
- Task granularity. Detailed enough to manage, coarse enough that people will actually fill in timesheets.
- Who approves time and how quickly, since delayed approval delays every downstream number.
- Billing model per project type and whether prepayments are involved.
- Analytical breakdown — client, service line, delivery team — handled through dimensions rather than a proliferation of projects.
We have a dedicated page for project-based companies.
Frequently asked questions
Does the projects module require a Premium licence?
No. Project management is part of Essentials. Premium adds manufacturing and service management, which are separate areas.
What is the difference between a project task and a planning line?
A task is a stage or work package, such as Discovery or Training. A planning line is a specific cost or revenue item inside that task, such as 20 consultant hours. Tasks give structure; planning lines carry the numbers.
How is employee time recorded?
Through the project journal for simple cases, or through timesheets when approval matters. Timesheets add a step where a manager confirms the hours before they reach the project.
Can we see profitability before a project finishes?
Yes. Project statistics compare budgeted and actual cost, invoiced and remaining to invoice, and current margin at any moment during delivery.
Are milestone and fixed-price billing supported?
Yes. Billing is set per project: fixed price, time and materials, milestone-based or prepayment, and invoices are generated from planning lines marked as billable.
How do we plan team workload across several projects?
Through resource capacity, which comes from each resource's calendar. Planning by resource group rather than by named person makes it possible to allocate roles before knowing who will do the work.