Projects collect cost and revenue across months rather than settling in a single transaction. Project types, the work breakdown structure, categories, forecasts, work in process and the revenue recognition choice that shapes everything else.
Most transactions settle quickly. A sale is ordered, delivered, invoiced and paid, and the whole story fits inside a month.
The project type is the first and most consequential choice, because it determines behaviour rather than merely labelling the work.
The work breakdown structure is the hierarchy of tasks beneath a project, carrying estimates, durations and dependencies. It is what a plan looks like inside the system, and it is what actuals are reported against.
A project contract sits above one or more projects and holds the commercial arrangement: who is funding the work, and on what terms.
Project categories classify what a transaction is: an hour of a particular kind, an expense of a particular kind, an item, a fee.
Cost and revenue arrive from several directions, and each has its own entry surface:
When cost is posted to a fixed-price project, that cost is not yet an expense matched to revenue — the revenue has not been recognised. It sits as work in process: value on the balance sheet, waiting.
For fixed-price work, the business must decide when revenue is earned. The choice is an accounting policy with operational consequences:
Billing a project runs through a project invoice proposal — a reviewable draft assembled from billable transactions, which becomes a customer invoice when posted.
Project management and accounting inside the finance and operations app handles projects that are strongly connected to inventory, manufacturing and the ledger — capital builds, internal programmes, and delivery work whose materials come from your own stock.
Projects hold value between the work and the money, and almost every design decision follows from how that gap is measured.