The Revenue Recognition Agent

Every month-end, James closes his office door.

Fourteen active projects. Four contract types: fixed-price (milestone-based recognition), time-and-materials (hourly rate, recognised on approval), retainer (straight-line with quarterly true-ups), and blended (fixed deliverables plus ad-hoc time, split into two components and recognised under different rules).

He opens the spreadsheet. He opens Teamwork. He opens the contracts folder on SharePoint. He opens Xero.

For each project, he determines: which milestones completed this month (checking Teamwork, sometimes calling the project manager because the status hasn't been updated, sometimes getting a confident answer and sometimes getting a pause that means "I'll update it now"). What percentage of fixed-price work is done (hours burned against budget, cross-referenced with the PM's estimate of actual completion, which is sometimes optimistic and sometimes genuinely forgotten). Which T&M hours were logged, approved, and invoiced. Which retainer periods elapsed.

He enters numbers into his spreadsheet. He reconciles against Xero. He produces the recognition schedule.

One and a half days. Every month. Three data sources that hold no awareness of each other's existence, bridged by one man and a spreadsheet held together by institutional knowledge and four years of accumulated tab structures (no two tabs identical, understood only by James, formatted in a style that future archaeologists would find challenging).

The spreadsheet was built when the firm had six projects and two contract types. The firm now has 14 projects and four contract types. The spreadsheet was never redesigned. It just grew. This is, when you think about it, a revenue recognition system whose accuracy depends on one person's ability to hold 14 sets of contract terms in his head while simultaneously cross-referencing three systems that don't share a single data field. Which is a description of a process, not a compliment of one.

Last year, this process produced three restatements. James can do maths. The maths wasn't the problem. The milestone data was three weeks old by the time he used it.

Software consulting firm in Manchester, UK. Twenty-eight employees. Annual revenue: £2.1M across 12 to 16 concurrent projects at any given time. Professional services. Fixed-price builds, T&M staff augmentation, retainer support contracts, and blended engagements that combine elements of all three.

James is the finance director. His loaded cost is roughly £45 per hour. He spends approximately 12 hours (1.5 working days) on revenue recognition per month-end close. That's £540 per month, £6,480 per year, in James's time alone.

The partners spend additional time reviewing and attesting: roughly £3,200 per year. Total annual cost of the manual recognition process: approximately £9,680 in direct labour.

The three restatements in 24 months add a harder-to-quantify cost: board confidence, audit risk, and the opportunity cost of James spending 18 days per year on month-end close administration instead of financial analysis, forecasting, and the strategic work the firm hired a finance director to do. Estimated total annual cost: £12,000 to £18,000.

The tool stack: Teamwork for project management (project status, milestones, timesheet data). SharePoint for document storage (contracts with billing structures, payment terms, statements of work). Xero for accounting (invoiced amounts, payment receipts, journal entries). And James's spreadsheet, which serves as the bridge between the three. Built four years ago. One tab per project. No integration. No automation. No backup plan for the day James is ill during month-end (which happened once; the close was delayed by four days and the partners described the experience as "educational").

James's recognition process follows a pattern that would be familiar to any finance professional in project-based services, and troubling to anyone who examined it closely.

He opens each project tab in his spreadsheet. He checks Teamwork for milestone completions. For fixed-price projects, he needs percentage-of-completion data, which requires hours burned against budget, cross-referenced with the PM's assessment of actual progress. These two numbers should agree. They often don't. When they disagree, James calls the PM. The PM sometimes knows. Sometimes estimates. Sometimes says "let me check and get back to you" (which, during month-end, means James notes the discrepancy and moves on, returning to it if he remembers, which he sometimes doesn't).

For T&M projects, he checks timesheet approvals in Teamwork and reconciles against Xero. Timesheets are submitted weekly in policy. Fortnightly in practice. James recognises revenue based on approved hours, which means the recognition is only as current as the approvals.

For retainers, straight-line recognition with quarterly true-ups. For blended contracts, he splits the engagement into fixed and variable components, each recognised under different rules, a process that requires re-reading the contract PDF because the split ratios aren't stored anywhere except in the contract itself and James's memory.

The whole process takes 1.5 days. The data ranges from "updated yesterday" to "updated three weeks ago." The restatements were all timing errors. Revenue recognised based on milestones assumed complete that weren't yet confirmed. The calculations were correct. The inputs were stale. The Monday morning bottleneck here isn't a single morning; it's a day and a half of every month-end, building a picture from fragments.