A professional services firm sells time, and increasingly it sells outcomes at a fixed price. A fixed fee changes how the firm bills. It also changes what the firm may report as earned in a given month, and that second change depends on something operations people rarely think of as an accounting input: whether the hours were logged on time.
This is not accounting advice. The right treatment of your contracts is a question for your accountant, and standards differ between jurisdictions and between contract types. What follows is about the data dependency, which is the same whatever your auditor concludes.
Billing is when you send the client an invoice. Recognition is when the revenue is considered earned and reported. They are related and not identical. A firm can bill a deposit on signing and have earned none of it. It can complete half the work in a month and have billed nothing yet.
Under the common standards, revenue from a contract is recognized as the firm performs. For many fixed-fee service projects that means recognizing it over time as the work progresses, and to do that the firm needs a measure of progress. Whether a given contract qualifies, and which measure fits, is for the firm and its accountant to decide.
One widely used measure is an input measure: how much of the expected effort or cost has been spent. For a services firm the input is mostly time. If a project is priced at a fixed fee and estimated at eight hundred hours, and four hundred hours have been incurred, the project is fifty percent complete on this measure and half the fee is recognized, whatever has been billed.
The arithmetic is simple. Its inputs are the two figures on either side of the fraction: the hours incurred to date and the estimate of total hours at completion. Both are only as good as the discipline that produces them.
Late time entries. If consultants log time at the end of the week, or at the end of the month, the hours incurred to date are understated until the entries arrive. Revenue recognized for the period is lower than it should be, and it catches up the next period. A close that is run before the late entries arrive reports a figure that will later have to be corrected.
A stale estimate to complete. The estimate of total hours is set at the start. As the project proceeds, the team learns that some of the work is harder than expected, and the likely total rises. If nobody updates it, the percentage complete is computed against the old total and the revenue recognized runs ahead of the work. The overrun surfaces as a loss at the end, in one large step.
Work logged to the wrong project. An hour logged to the wrong project moves revenue from one contract to another. Both numbers are wrong and neither shows as an error.
Hours that are never logged. A senior person who does not record the time they spent on a fixed-fee project leaves the project looking cheaper and less advanced than it is. The revenue is understated and the margin is overstated, and the project looks healthier than it was.
In each case a time-entry habit changes a financial statement, and nothing alerts anyone, because the totals still add up.
Four things keep recognition honest, and none is exotic.
Time logged at least weekly, and by a fixed cut-off before the close. Entries after the cut-off belong to the next period, and the cut-off is the same each month. The shape of the entry itself, including the project and phase it belongs to, is covered in the entry that decides whether the project was profitable.
An estimate to complete, reviewed monthly. The project lead states the remaining hours expected, not the original estimate minus hours used. When the number changes, the change is recorded with a reason.
A link between the project, the contract and the invoice, so that billed and recognized amounts can be compared by project. The three joins that make this possible are described in what breaks between the proposal, the project and the invoice.
A monthly look at the difference between billed and recognized, by project. A project billed ahead of its progress carries a liability to deliver. A project ahead of its billing carries an unbilled asset. Both are normal and both want an owner.
Imagine a fixed-fee project priced at 120,000 dollars and estimated at 800 hours. At the end of the month, the team has worked 400 hours but only 300 are logged, because two consultants have not yet entered the last week.
On the logged hours the project is 37.5 percent complete, so 45,000 dollars is recognized. On the hours actually worked it is 50 percent complete, so 60,000 is earned. A close run on the logged hours understates revenue for the month by 15,000 dollars, and the margin appears to be better than it is, because the cost side is also short by the missing hours.
Now add the second problem. The project lead knows the work is harder than planned, and the likely total is 1,000 hours, not 800. At 400 hours worked the project is 40 percent complete, and 48,000 dollars is recognized. The original estimate would have recognized 60,000. The difference, 12,000 dollars, is revenue the original estimate would have put in the books before the work was done.
Neither problem is a bookkeeping error. Both are data problems, and both are fixed upstream of the ledger.
The dependency crosses a line most firms draw between delivery and finance. The project lead owns the estimate to complete and the team's time entries. The finance lead owns the close and the reported figure. Neither can fix the number alone: finance cannot make the hours accurate, and delivery cannot know what the cut-off should be.
A short monthly conversation closes the gap. Before the close, each project lead confirms that time is logged to the cut-off and gives a current estimate to complete for each fixed-fee project, with a reason where it moved. Finance then runs the close on figures that both sides have seen. The meeting takes twenty minutes for a firm with a dozen fixed-fee projects, and it replaces the larger conversation that happens when the year-end review finds the drift.
Choose one fixed-fee project that is under way. List the hours logged to date, the hours you believe have been worked, and the project lead's honest estimate of the total hours at completion. If the first two differ, or the third differs from the original estimate, you have the size of the data problem for that project. The next month-end, compare the revenue computed on the logged hours with the revenue computed on your corrected figures, and show the difference to your accountant. They will tell you what it means under your contracts.
We start with a no-risk discovery: we take one or two of your fixed-fee projects, compare the logged hours, the real hours and the estimate to complete, and show how each moves the figures, and you pay for the discovery only if you go on. A build comes with a guaranteed estimate, so if we estimate low, we absorb the difference. After go-live, Managed Technical Operations keeps the time cut-off, the estimate review and the billed-against-recognized view working in your systems.
Recognition rests on time data, and time data rests on habit.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
6:15 
6:55 
6:27 
6:14 "Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
