What this method produces
A cost-to-date figure per project, updated monthly, that people trust enough to act on while the work is still running. Not a post-mortem — those are easy and useless.
It covers external cost: supplier invoices, subcontracted work, materials, licences bought for a job. Internal time is the other half and comes from a different system; this guide says where the boundary is rather than pretending there is not one.
The method is deliberately a spreadsheet method. At this scale that is the right tool, because every assumption is visible and changeable — and the assumptions are where all the difficulty lives.
Three decisions before you start
Write these at the top of the sheet. Each will otherwise get decided differently in month four, and the comparison back to month one quietly stops meaning anything.
Direct cost only, or fully loaded? Direct cost is what the project manager can influence. Fully loaded includes a share of overhead and answers a different question. Pick one as the headline and show the other below it if you need both.
Cost when invoiced, or when incurred? Invoiced is simpler and lags. Incurred needs accruals and is more honest for projects with long supplier terms. Either works; mixing them does not.
How long does a project stay open for costing? Delivery date plus a defined period. This single number determines how optimistic every final margin will be.
The seven steps
1 · Define a project
At a level a supplier could write on an invoice.
2 · Get references on documents
Ask. It costs suppliers nothing and removes most of the guesswork.
3 · Extract the lines
Line level, not totals — a total cannot be allocated.
4 · Set the rules
One per supplier, recorded, so nothing is re-decided monthly.
5 · Handle the shared
Split on a recorded basis, or leave in overhead honestly.
6 · Handle the late
Keep projects open, and accrue at closure for what has not arrived.
7 · Publish and act
Cost to date against budget, to whoever can change the outcome.
Then: measure the method
Share of cost that reached a project, and how much arrived late.
Step 1 · Define what a project is
Sounds trivial and is where most implementations go wrong, because the instinct is to define projects at the level people talk about them rather than the level anyone could record them.
The workable test: could a supplier reasonably write this on an invoice? If the answer is no, the level is too granular and every cost at that level will need a human decision forever.
Too coarse fails differently. One project per client means a client with six pieces of work gets one blended margin, and the loss-making engagement hides behind the profitable ones.
Give each project a short code and use it everywhere — purchase orders, emails to suppliers, the sheet. A code that appears in a supplier’s line description is worth more than any amount of clever matching afterwards.
And decide what is not a project. Internal work, business development, general overhead: naming them explicitly stops them being pushed onto whichever project happens to be open.
Step 2 · Get references onto the documents
The cheapest improvement in the entire method, and the one almost nobody makes. Ask suppliers to put your project reference on the invoice line.
Most will agree without discussion. It is usually a field they already have, they gain a cleaner conversation about queries, and it costs them nothing. A short note when you place work is enough.
The effect is disproportionate. Every reference on a document converts a monthly judgement into a lookup, and judgements are what make this process expensive and inconsistent.
Start with your ten largest suppliers by volume of invoices, not by value. Volume is what generates the work, and ten suppliers usually account for most of it.
Where a supplier genuinely cannot, note it — that supplier will need a rule in step 4, and knowing in advance which ones is useful.
Step 3 · Extract the lines, not the totals
An invoice total is a fact about a supplier relationship. Allocation needs facts about pieces of work, and those live in the lines.
One media invoice covers three campaigns; one freelancer’s month covers four engagements. Each is a single payable and several project costs, and only the line detail distinguishes them.
Extract everything for the period in one pass — up to 100 files at a time — and make sure two things travel with each row: the source document and page, and the check that the lines sum to the invoice total. The second matters more than it sounds: an allocation built on a misread line is wrong in a way no total-level review catches.
The mechanics are on line item extraction, and the project-specific framing on project cost tracking from invoices.
Step 4 · Set the allocation rules
The step that decides whether month two takes half an hour or another full day.
A rule says: for this supplier, allocate this way. Some are trivial — this specialist only ever works on one project. Some are conditional — a reference in the line, otherwise ask. Some are splits with a fixed basis.
Record them where the tagging runs, not in someone’s head. The whole economics of the method depend on rules persisting; if they do not, you are doing the first month over and over. The mechanism is on dimension tagging.
Work through suppliers by invoice count, largest first. Twenty suppliers usually cover most of the volume, and the long tail can stay manual without hurting anything.
Review the rules once a year and not more often. A rule improved mid-year splits your dataset into two halves that cannot be compared — the same trap as changing a category list mid-year, described on period comparison.
Step 5 · Handle the genuinely shared
Some costs really do serve everything: the design tool everyone uses, the office, the account manager who touches every job. Forcing them onto projects is a choice with consequences.
| Approach | Good for | Cost of it |
|---|---|---|
| Leave in overhead | Holding managers accountable | Project margins overstate true cost |
| Allocate on a basis | Knowing what delivery really costs | Managers argue about the basis |
| Show both subtotals | Most teams, most of the time | One extra row on the report |
The third row is the pragmatic answer and costs almost nothing: a direct-cost subtotal the project manager is judged on, and a fully loaded figure below it that exists for pricing decisions.
Whatever you choose, write the basis down and keep it for the year. Re-litigating an allocation monthly costs more than any distortion the basis introduces, and the full treatment is on cost centre spend report.
Step 6 · Handle the costs that arrive late
Structural, unavoidable, and the reason so many projects look better at delivery than they turn out to have been.
Work happens in March. The subcontracted portion invoices in April, print arrives in May, a licence bought for the job renews in June. If the project closed for costing in March, all of that is homeless.
Two mechanisms handle it. Keep projects open for a defined period after delivery — long enough to cover normal supplier terms.
And accrue at closure for what is known to be coming. Even a rough estimate is far better than zero, because zero is a specific claim and it is always wrong.
Then measure it: how much cost arrives after projects close. If that number is large, your closing period is too short, and you now know by how much.
Step 7 · Publish it to someone who can act
A project cost report that goes only to finance changes nothing. The person who can change the outcome is the one running the work.
Send each project owner their own projects — not the full pack. People engage with what they are accountable for and skim the rest, which is the same reasoning as the departmental packs on budget tracking for department heads.
Show four things: budget, cost to date, committed but not invoiced, and the gap. The third is the one that turns a comfortable report into an accurate one.
And publish on a fixed day. A report that arrives predictably becomes part of how projects are run; one that arrives eventually is treated as an occasional document.
A worked example
A design agency, twenty live projects, costs previously coded to general categories. One month of supplier invoices, processed with the method above.
| Stage | What happened |
|---|---|
| Extracted | One month of supplier invoices, line level |
| Allocated by reference | Roughly half, because print and media already carried job numbers |
| Allocated by rule | A further large share — specialists who only work on one project each |
| Split | Two invoices covering several projects, on an hours basis |
| Left in overhead | Software and the office, deliberately |
| Unassigned | A short list, all small, all resolved in twenty minutes |
| Found | One project carrying costs from another, for three months |
The second row is the interesting one: half the work was already done, by suppliers, for free, because someone had once asked them to include a job number. That is the argument for step 2 in a single line.
The last row is the kind of finding that pays for the exercise. A misallocation running for three months is invisible in category-level reporting and obvious the moment costs sit under projects.
The monthly routine
Half an hour, folded into the payables process rather than standing alone. A project-costing task that lives separately is one that gets skipped in a busy month.
| When | What | How long |
|---|---|---|
| With payables | Extract the month's invoices | Minutes |
| Same session | Rules run; review the residue | Ten to twenty minutes |
| Same session | Update the commitments list | Five minutes |
| Fixed day | Send each owner their projects | Automatic once set up |
| Weekly, active projects only | Glance at anything near budget | Two minutes |
The last row is the only part that needs to happen more than monthly, and it applies to a handful of projects rather than all of them — the ones close to budget, where a week of delay changes an outcome.
Four checks before publishing
Each under a minute, and each has caught a real error often enough to be worth the habit.
Do allocations sum back to invoice totals? A split that does not reconcile means a line was dropped or double-counted.
What share of cost reached a project? Track it monthly. A falling share means rules are going stale or new suppliers are not being handled.
Is any project unusually quiet? A live project with almost no cost this month is usually a tagging failure rather than a quiet month.
How large is the unassigned bucket? By value, not by row count. Fifty small unassigned rows matter far less than one large one.
Starting halfway through a year
The usual case, and it goes wrong when people try to rebuild history before starting.
Start with live projects only. Finished ones cannot be influenced and rebuilding them is archaeology; the effort belongs on work that is still running.
Take cost from the current period forward, and note the start date on each project so nobody mistakes a partial figure for a total one.
Accept that this year’s margins are incomplete. Saying so is better than producing a figure that looks whole and is not.
And rebuild one finished project, if you want a sanity check. One is enough to learn whether the rules work; three is a project of its own.
Where this lives, and what it should not become
A recurring failure of project costing is not the method but the housing. It gets built in the wrong place, and the wrong place kills it within two quarters. Three options, with an honest account of what each costs.
A spreadsheet. Perfectly adequate up to a few hundred lines a month, and the right answer for most businesses starting out. It becomes a problem at exactly one point: when the person who built it goes on holiday and nobody else can reproduce the month. If your spreadsheet has more than two formulas nobody else understands, that point has already arrived.
Dimension fields in your accounting system. The strongest option where it exists, because the allocation lives with the transaction rather than beside it, and reporting comes free. The catch is that most systems make dimensions painful to correct after posting, which means the rules have to be right before the coding rather than after it.
A project management tool with a cost module. Attractive because the projects already exist there, and disappointing in practice because those modules record what was planned or logged rather than what was billed. They are excellent at internal time and weak at supplier invoices, which is the opposite of what this guide is about.
Whichever you choose, the thing to avoid is a fourth option that appears by accident: costs allocated in one place, revenue in another, and a monthly reconciliation between them performed by a human. That arrangement works for as long as the human is interested and fails silently afterwards.
The extraction step is deliberately independent of all three. Lines come out of the documents as Excel or CSV, and where they go next is a decision you can change later without redoing the work.
Scaling the routine without it collapsing
The routine described above works at fifty documents a month. At five hundred it does not, and the way it fails is instructive: nothing breaks, it simply stops being done, and three months later nobody can say when it stopped.
Two things carry it through the increase. The first is the ratio of automatic to manual allocation. At fifty documents, deciding twenty of them by hand is a coffee’s worth of work. At five hundred, deciding two hundred is a day, and a day-long monthly task will not survive a busy quarter. The ratio has to improve as the volume grows, which means the rules have to be written down as they are discovered rather than carried in someone’s head.
The second is batch processing. Handling documents individually scales linearly with volume; handling a month in one pass does not. Processing a hundred files into one export turns the extraction step into a constant rather than something that grows.
There is also a threshold worth naming. Somewhere around the point where two people are involved, consistency becomes a bigger risk than effort. Two people applying their own judgement to the same ambiguous supplier will produce allocations that disagree, and disagreeing allocations are worse than no allocations because they look authoritative. Once a second person is involved, the written rules stop being a convenience and become the point.
| Volume | What has to be true | Realistic monthly effort |
|---|---|---|
| Under 50 documents | Someone remembers the suppliers | 20–30 minutes |
| 50–200 | Rules written down; batch extraction | About an hour |
| 200–500 | Most suppliers send references | An hour, one person, same person |
| 500+ | Allocation lives in the ledger, not beside it | Continuous rather than monthly |
The last row is a genuine change of shape rather than more of the same. Past a certain volume, a monthly exercise becomes a weekly one and then simply part of how invoices are processed — at which point it stops being a project and starts being a habit, which was the goal all along.
Common mistakes
Defining projects too granularly
If a supplier could not write it on an invoice, every cost at that level needs a human forever.
Never asking suppliers for a reference
The cheapest improvement available, and it converts monthly judgements into lookups.
Allocating from invoice totals
A total cannot be split sensibly, so it goes to one project or to overhead — both wrong.
Re-deciding splits every month
The allocation drifts, and only a stable basis makes projects comparable to each other.
Closing projects for costing at delivery
Every final margin is then optimistic by the size of the late tail.
Ignoring committed cost
A project can be well over budget while the invoiced view still shows room.
Sending the report only to finance
The person who can change the outcome is the one running the work.
Forcing unassigned rows somewhere
Produces a tidy report and untrue numbers. An honest unassigned total is more useful.
Handing it over without losing it
The most common way project costing dies is not a decision to stop. It is a handover — the person who ran it changes role, and the routine goes with them because it lived in their head rather than in a document.
Four things have to be written down for the routine to survive a change of hands, and none of them takes long if they are recorded as they are decided rather than reconstructed afterwards.
The supplier rules. Which suppliers always belong to which project or client, and why. This is the largest body of accumulated knowledge and the one that is never in a file.
The split bases.For every supplier whose invoices are divided, the basis and the reason for it. A successor who invents new bases will produce numbers that do not compare to last year’s.
The conventions. Net or gross, how discounts and delivery are treated, where rounding differences go, what happens to a cost nobody claims. Small decisions that are invisible until someone makes them differently.
What is deliberately excluded. The costs left in overhead on purpose, and why. Without this, a successor will assume they were missed and start allocating them, and the comparison to prior periods quietly breaks.
One page covers all four for most businesses. Writing it is also a useful test of the routine itself: anything you cannot explain in a sentence is probably a decision that was never really made.
Best practices
Write the three decisions on the sheet
Direct or loaded, invoiced or incurred, and how long projects stay open. Three lines that keep month twelve comparable to month one.
One short project code, used everywhere
On purchase orders, in emails to suppliers, in the sheet. It is what makes references possible.
Rules recorded, not remembered
The difference between a half-hour month and a repeat of the first day.
A commitments list per project
Short, manual, reconciled as invoices arrive. The only way to see over-commitment.
Measure the method, not just the projects
Share of cost allocated, and how much arrives after closure. Both improve if the process is working.
Review rules annually, at a boundary
Mid-year improvements split the dataset into two halves that cannot be compared.
The agency-specific version of this routine — who does what and when — is on project accounting for agencies, and why projects look profitable until they close is examined in the accompanying article.