Costing allocation on projects: tying hours back to the budget

A quarter closes. The finance report says the design team cost 180,000 and the projects report says six projects shipped. Nobody in the room can say how much of that 180,000 belongs to each project, because nobody wrote down where the hours went. The gap between those two reports is what costing allocation is supposed to close.

The term causes trouble because it names two different jobs. In accounting, cost allocation is the practice of spreading a shared cost across the things that consumed it. In payroll systems, a costing allocation is a specific record that says which cost centre or grant a named person's pay is charged to, and for what dates. Search results mix the two freely, which is why a search for this phrase returns university finance manuals next to activity based costing explainers. Both are covered below, starting with the one that decides whether a project was profitable.

The four decisions hiding inside any allocation

Every allocation method, however it is described, is four choices. Naming them separately is the fastest way to see where an existing model goes wrong.

The cost pool. The bucket of money being split. Salaries of a shared design team. Software licences. Office rent. Cloud spend. A pool should hold costs that behave the same way, because one allocation base has to be defensible for everything in it. Rent and cloud spend in the same pool is already a problem, since floor space and compute have nothing to do with each other.

The cost object. The thing receiving the cost. For project teams this is usually a project, a client, or a product line. It can also be a single deliverable, which is where allocation starts to cost more to run than it returns.

The allocation base. The measure used to decide the split. Hours worked, headcount, revenue, square metres, number of transactions, number of seats. This is the only one of the four choices that has a right and wrong answer, because the base is a claim about causation. Choosing revenue as the base for design salaries says that a client who pays twice as much consumes twice as much design time, and that is either true or it is not.

The period. The window over which the base is measured. A month is common. A quarter smooths out holidays and sick leave. A week is almost always too short, since one person taking five days off will swing the numbers hard enough to make the report look broken.

Most arguments about allocation are really arguments about the base, dressed up as arguments about method. Fix the base and the method usually picks itself.

Methods, and what each one costs to run

The literature lists many methods. For a team under about thirty people, only a handful are worth the trouble. The table below compares them on the two things that decide whether a model survives contact with a real month: how hard it is to keep fed with data, and where it lies to you.

Method	Allocation base	Effort to run	Where it misleads
Direct costing only	None. Only costs traceable to one project are counted	Very low	Overheads vanish. Every project looks more profitable than it is
Equal split	Number of active projects	Very low	A two week job carries the same overhead as a six month one
Headcount	People assigned	Low	Ignores that one person may give a project two hours a week and another forty
Revenue based	Share of revenue	Low	Big clients absorb the cost of small difficult ones, hiding the unprofitable work
Hours based	Hours recorded against each project	Medium. Needs hour data every week	Only as good as the hour data. Unrecorded time lands nowhere
Activity based costing	Activity drivers per cost pool	High. Needs driver data per pool	The model outlives the process it describes and quietly stops matching reality
Step down	Sequential, support departments first	High	The order of departments changes the answer, and the order is a judgement call
Reciprocal	Simultaneous equations between departments	Very high	Precision that no small team can act on

Step down and reciprocal methods exist because internal service departments serve each other. IT supports finance, finance supports IT. They are standard in manufacturing and in institutions with audited indirect cost rates. For a project team with one shared pool of people, they solve a problem that does not exist yet.

Hours are the only base most teams can actually measure

Of the eight rows above, hours based allocation is the one that answers the question people are actually asking, which is whether a project was worth doing. It is also the one that fails most often, for a reason that has nothing to do with accounting: the hours are never recorded.

There is a standard failure sequence. A timesheet tool is introduced. For three weeks the data is good. Then someone files a week late, filling it in from memory in round numbers. Within two months half the team is reporting forty hours a week split neatly across whatever projects they remember, and the allocation model is now processing fiction with three decimal places of precision.

What survives is narrower and duller. Recording at the level of project and day, not task and quarter hour. Asking for the entry at the end of the day rather than the end of the week, because memory of Tuesday is gone by Friday. Accepting a category for work that belongs to no project, so that internal work, sales calls and recruitment have somewhere to go instead of being smeared across clients. A model that captures 85 percent of hours honestly beats one that claims 100 percent and invents the last third.

The practical consequence is that the hour data should come from the place where the work already lives. If tasks are tracked on a board, the board is where hours should be entered, on the card that is already open. Switching to a separate timesheet application is a context change, and context changes are what kill the habit. Tools differ on whether hour tracking is included or sold separately, which is worth checking against the pricing before a process is designed around it.

What to do about the hours nobody records

Some categories of time will never be captured reliably. Interruptions, five minute questions, reading. Rather than pretending otherwise, set an explicit overhead percentage, apply it to every project, and review the number twice a year. A stated assumption can be argued with. A gap in the data cannot.

A worked example, with the arithmetic visible

Suppose a studio has a shared design team costing 60,000 a month in salaries, plus 12,000 a month in software and rent. Three projects ran in March. Recorded hours were 320 on project A, 180 on project B, and 100 on project C, with a further 80 hours logged as internal work.

Under headcount allocation, if all four designers touched all three projects, each project carries 20,000 of salary. Project C, which consumed 100 hours, is charged the same as project A, which consumed 320.

Under hours based allocation, the 680 recorded hours are the base. Project A carries 47 percent of the pool, project B 26 percent, project C 15 percent, and internal work 12 percent. Salary charged to project A becomes roughly 28,200, and to project C roughly 8,800. If project C was billed at 15,000, the two methods disagree about whether it made money.

The second number is more useful, and it is only available because someone recorded hours against a project for a month. That is the entire cost of entry. Everything else in the field is refinement.

Note that the 80 internal hours were left in the base rather than redistributed. Redistributing them would push their cost onto clients, which overstates project cost and makes the studio look less efficient than it is. Keeping them separate produces a number worth looking at, which is how much of the month went to work that nobody paid for.

Payroll costing allocations, the other meaning

Search for this phrase and a large share of the results are instructions for HR systems, most often for assigning a costing allocation to a worker or a position. That is a different object with the same name, and the distinction matters if the two are being discussed in the same meeting.

A payroll costing allocation is a record with three parts: a worker or position, one or more cost centres with percentages that sum to 100, and an effective date range. It answers where this person's pay is charged, not how a shared cost is spread. The percentages are set in advance rather than derived from measured activity, which is the essential difference. A researcher funded 60 percent by one grant and 40 percent by another has a costing allocation of 60 and 40 regardless of how the weeks actually went.

Two properties of these records cause most of the confusion. They are dated, so changing one without setting the correct effective date produces retroactive adjustments in the next payroll run. And they are hierarchical, so an allocation on a position, a worker, and an earning can all apply, with a defined order of precedence. Anyone told to update one should confirm which level they are editing before saving.

For project teams, the link between the two meanings is direct. Payroll costing allocations determine the size of the cost pool that lands in each department. Project cost allocation then splits that pool across work. Getting the first one wrong makes the second one meaningless, because the pool itself was misstated.

Keeping the model honest once it exists

An allocation model is a description of how work happens, and work changes. Three checks keep it from drifting.

Compare allocated cost against the total. The sum of what was charged to projects, plus internal work, plus anything deliberately unallocated, should equal the pool. If it does not, something is being double counted or dropped, and the reports built on it are wrong in ways that are hard to see.

Look at the projects the model says are unprofitable and ask whether anyone believes it. Allocation models fail loudly on the extremes. A project that shows a heavy loss and felt easy is usually a data problem, not a business problem.

Review the base annually, not the method. Methods rarely need to change. Bases go stale constantly, because the thing that drove cost two years ago is not what drives it now. A team that moved from custom builds to configuration work has a different cost driver than it had, and a base set before that shift is measuring the old business.

One structural note: allocation gets easier when project boundaries are stable. Teams that create a new board or project for every small request end up with hundreds of cost objects and no signal. Where projects map to clients or to products, with a board for each and an internal board for the rest, the feature set for grouping and reporting does most of the work. Comparisons of how different tools handle time and project structure are collected in the tool comparisons.

What to change first

Pick one cost pool, choose hours as the base, and record hours against projects for a single month without changing anything else. That one month of data will tell you more than a redesigned accounting model, and it will show which projects are actually carrying the team. If hours are not being recorded anywhere yet, the shortest path is to enter them on the cards where the work already sits, which the getting started guide walks through for a first board.

Q1. What is the difference between cost allocation and cost apportionment?

The terms are used interchangeably in many places, but where a distinction is drawn, allocation means charging a whole cost to one cost object because it clearly belongs there, and apportionment means dividing a shared cost across several objects using a base. A dedicated tool bought for one project is allocated. Office rent is apportioned.

Q2. Should billable hours or total hours be used as the allocation base?

Total hours worked, including hours that were not billed. Using billable hours only charges projects for the time a client agreed to pay for, which hides exactly the problem allocation is meant to reveal. If a project consumed 40 hours and only 25 were billable, the cost of all 40 belongs to that project.

Q3. How precise does hour tracking need to be for this to work?

Project and day is enough for almost every decision a small team makes. Tracking to the task and the quarter hour multiplies the recording effort without changing which projects look profitable, and the added burden is the usual reason the habit collapses within two months.

Q4. Can costing allocation be done without any timesheet system?

Yes, using headcount or an equal split, and the result is still better than counting only direct costs. It will not tell you which projects consume disproportionate time, which is normally the reason the question came up. Headcount is a reasonable starting point and a poor stopping point.

Q5. What happens to costs that cannot be assigned to any project?

Give them a named home rather than spreading them silently. An internal or unallocated category holds administration, sales, recruitment and downtime, and the size of that category is a useful number in its own right. Spreading it across client projects inflates project cost and makes every client look more expensive than they are.