At its core the module plans work and tracks what that work costs and earns. Every project carries a work breakdown of tasks and milestones, scheduled on a Gantt view with explicit dependencies so that a slip in one task propagates visibly to everything downstream. Resources are assigned to tasks with planned effort, and delivery teams book time against those tasks as the work happens, giving a continuously updated picture of progress against plan.

Alongside the operational plan sits a full project accounting layer. Each project holds a budget, accumulates committed costs as purchase orders and resource commitments are raised, and records actual costs as time and expenses land. The module maintains work in progress for effort delivered but not yet billed, and drives billing and revenue recognition against contractual terms. The result is that a project manager and a finance controller look at the same object and see, respectively, schedule health and margin, without either having to reconcile a spreadsheet against the general ledger.

The central entity is the project, which anchors both a plan and a financial structure. Beneath it, tasks form the work breakdown and carry planned effort, scheduled dates, dependencies and assigned resources. Milestones mark contractual or internal checkpoints and frequently act as billing triggers. A resource is a person or role drawn from Human Resource Management, with a cost rate and, where the project is billable, a charge rate.

Financially, each project resolves to a set of budget lines and to running balances for committed cost, actual cost, work in progress, billed amount and recognised revenue. Time bookings and expense lines are the atomic cost postings that feed those balances, each carrying the task and cost code it belongs to. Billing is expressed through contract terms, whether time and materials, fixed price or milestone based, which govern how work in progress converts into invoices and how revenue is earned. Because the data model separates the plan, the cost and the contractual value, the same task can be under budget on hours yet under water on margin, and the module shows both.

A project typically begins with planning and budgeting: the manager builds the work breakdown, sets dependencies and dates on the Gantt, assigns resources and agrees a budget by cost code. As the plan firms up, resource assignments become commitments that reserve capacity and pre-load committed cost before a single hour is booked.

Delivery then generates a steady flow of time and expense against tasks. Time bookings accrue actual cost and progress the schedule; project-coded expenses arrive from Expense Management. The manager reviews and approves these entries, at which point they harden into work in progress. On the financial side, billing runs convert eligible work in progress into invoices according to the contract term, milestone completion releases fixed-price billing, and revenue is recognised in the same cycle. The project closes only once all costs are posted, work in progress is fully billed or written off, and final margin is settled. Throughout, replanning is expected rather than exceptional: dates move, scope changes are absorbed as new tasks, and re-baselining keeps the plan honest against the original commitment.

The financial treatment is where the module earns its place next to the ledger. It maintains the standard progression of budget, commitment, actual for every cost code, so that spend is visible before it is incurred rather than only after invoices post. Work in progress is carried as an asset until billed, and the module supports both percentage of completion and completed contract approaches to recognising revenue, with the method chosen per contract and applied consistently across the reporting period.

For time and materials work, unbilled hours accrue at charge rates and release on billing; for fixed-price work, revenue is earned against measured progress while cash follows the milestone schedule, and the difference is held as accrued or deferred revenue. The module computes earned value and margin continuously, flags budget overruns at the cost-code level, and enforces approval on time, expense and billing before anything reaches Accounting & Control. Every posting is coded to project, task and account, giving a clean audit trail from a single booked hour through work in progress to recognised revenue and, ultimately, to the double-entry postings in the ledger.

Project Management is deliberately thin on things other modules own, and deep on the project itself. It draws people, roles, availability and cost rates from Human Resource Management, so resource planning reflects real capacity, leave and skills rather than a static list. It posts to Accounting & Control for all project accounting and billing: budgets, commitments, work in progress, invoices and revenue recognition all resolve into the ledger there, and the invoice a client receives is issued through that module against terms held here.

It receives project-coded costs from Expense Management, so that travel, subsistence and third-party spend land against the right task and budget line without rekeying, and flow into work in progress and billing on the same footing as booked time. Because these are modules in one suite over a shared PostgreSQL data model rather than integrations across separate systems, a project's operational and financial state is one consistent record: no batch reconciliation, no drift between the plan a manager sees and the numbers finance reports.

The suite treats AI Workers as first-class users, and in Project Management they operate directly on live project data. A manager can query a portfolio conversationally, asking which projects are trending over budget, which milestones are at risk given current schedule slip, or what the recoverable work in progress balance is this period, and receive answers grounded in the actual data model rather than a static report. Workers also execute actions: drafting a billing run, reassigning a resource to relieve an overallocation, or re-baselining a plan after an approved scope change, each subject to the same permissions and approvals a human would face.

They watch for anomalies and exceptions, surfacing a cost code about to breach budget, work in progress ageing beyond its billing window, or a dependency chain that has quietly pushed a delivery date. They perform document and data extraction, reading a statement of work or a change request and proposing the tasks, milestones and budget lines it implies. And they act as decision support and as a node in workflows: an AI Worker can review a timesheet or billing proposal, apply policy, and stand as an approval or review step in the chain, escalating to a person only where judgement or authority genuinely requires it.