PSA Build Vs Buy: The Question Is Which System Owns The Revenue Schedule

A consultancy of 90 people buys a well-regarded professional services automation product. Implementation goes reasonably. Eighteen months later the finance director still cannot say what the work in progress figure is without assembling it by hand, and nobody can explain where the margin went on a fixed fee engagement that everyone remembers as busy.

Nothing went wrong with the purchase. The PSA build vs buy question is usually decided long before the shortlist, by a single structural fact: whether the system that produces your invoices also owns your revenue schedule, and whether those two things are allowed to be different. Most firms should buy. The ones who should not are identifiable in advance, and the test has nothing to do with headcount.

What a PSA is actually being asked to do

A professional services firm sells time and expertise against a commercial arrangement, and the software has to hold six things at once.

It has to know the engagement and what was agreed, including the rate card and any cap. It has to capture time and expense reliably enough that people actually record it. It has to value work in progress. It has to bill, adjust and collect. It has to recognise revenue as the work is performed. And it has to tell somebody where capacity is going next month.

The order of that list matters, because each item depends on the one before it. Capacity forecasting built on unreliable time capture forecasts noise. A work in progress figure computed from an engagement record that does not hold the cap is wrong in a way nobody notices until a client disputes an invoice. Firms that buy for the last item on the list, usually resourcing, because that is the pain they feel most acutely, frequently find they have bought a good answer to a question that depends on three answers they do not yet have.

Those are not one system. A practice management product, a resourcing tool and a general ledger are three products, and buying one does not deliver the other two. Most of the difficulty in this category comes from firms assuming that a purchase covering one end of that list covers the whole of it.

The question that decides it

Here is the test, and it is worth applying before reading a single product page.

Almost every practice management product on the market will produce an invoice. Almost none will produce a revenue schedule that is independent of that invoice.

Under IFRS 15 and ASC 606, a services contract satisfied over time is recognised as progress is made. Progress is not the same event as billing. A firm that bills monthly in arrears, or on milestones, or 50 per cent up front, is recognising revenue on a pattern that does not match its invoice dates. A system that models only billing therefore has no work in progress figure it can compute. It has one somebody assembles, in a spreadsheet, usually late, and usually differently each quarter.

If your commercial arrangements are simple, and billing genuinely tracks delivery, a bought product will handle this and building is very hard to justify. Time and materials work billed monthly is close to that case.

If your arrangements are not simple, this becomes the deciding constraint. Fixed fees delivered over months, caps that sit above several engagements at once, contingent elements, multi-currency arrangements with different revenue and billing points, retainers that partially roll forward: each of these separates recognition from invoicing, and each is a place where a product that bundles the two will require a workaround that lives outside the system.

Establish which system owns the revenue schedule before anything is bought. Retrofitting it later means restating periods that are already closed, which is expensive in a way that has nothing to do with software.

Utilisation is not realisation, and only one of them finds the money

This distinction is the most common cause of a firm believing its system works when it does not.

A system holding hours plus a billable flag can tell you utilisation. It cannot tell you realisation, because that requires both the value of what was recorded and the value of what was eventually billed, and a billable boolean stores neither.

Model the time entry properly and the difference becomes visible. An entry belongs to an engagement, carries a grade, has a status, and has been through transitions: recorded, billable, billed, collected. Every write off between those states needs a reason and an author.

Do that and leakage becomes a number attributable to a client, a partner or a type of work. Skip it and leakage appears in the management accounts as a gap with no explanation, which is precisely the condition the consultancy above found itself in. This one modelling decision matters more to a firm's economics than any feature on a comparison grid, and it is worth checking against a product during evaluation rather than after.

Where bought products genuinely stop

Mid-market and larger firms are generally served by products that bundle time, billing and resourcing. The bundling is the thing to examine, because a product that models one commercial level will not always grow a second one.

Three limits recur.

The first is the level at which a commercial arrangement can sit. Many products assume the engagement is the unit. Firms that need a cap or a fee arrangement sitting above several engagements, or a programme spanning multiple clients within a group, find the model does not extend and the workaround is a spreadsheet that becomes load bearing.

The second is revenue recognition independent of billing, described above.

The third is anything specific to a profession rather than to services generally. Conflict checking with a defined process, regulatory time recording, trust or client account handling, statutory reporting to a professional body: these are not exotic requirements within their sectors and they are frequently absent or shallow in general products.

None of that means build. It means the evaluation should test those three specifically, with your own arrangements, rather than accepting a demonstration built on a simple one.

There is a fourth limit that is rarely framed as one, and it is about exit rather than function. A practice system accumulates history: closed engagements, write offs with their reasons, revenue already recognised, and the audit trail behind numbers that have been reported to partners or to a regulator. The cost of leaving a product is proportional to that history, and it grows every year. Ask during evaluation what a full export looks like, in what format, and whether it includes the transition history or only current values. A product that exports current state and not history is one you cannot leave without losing the ability to answer questions about periods you have already closed.

What building actually costs, maintenance included

The case for building is usually presented as flexibility, and the case is usually made without the maintenance line.

A practice platform is not a small system. Taking the industry-standard module split, an engagement and rate card model, time and expense capture, billing and work in progress, revenue recognition, resourcing, integrations, and a portal with reporting comes to roughly 1,180 hours for a first version. At a blended $65 per hour that is about $76,700, and $47,200 to $118,000 across a $40 to $100 rate band.

That figure is only the beginning of the commitment. A system holding financial records needs ongoing work for as long as the firm uses it: accounting standards get interpreted, tax rules change, integrations break when the general ledger vendor ships a new API version, and the firm's own commercial models evolve. Budget 15 to 20 per cent of the build annually, which is $11,500 to $15,300 a year on that example, and understand that it is a permanent line rather than a project cost.

Buying carries costs that comparison grids also leave out, and an honest analysis has to include them on both sides. Configuration, data migration from whatever exists now, integration to the general ledger, and training are real work whoever performs it, and for a firm of any size the first-year implementation frequently approaches or exceeds the first-year licence. Migration is the least predictable part, because open engagements have to move mid-life with their work in progress intact, and a cutover at a period end is the only sensible timing, which constrains the schedule in the same way an academic calendar constrains a school.

Against that, a bought product at, say, $50 per user per month for 90 people is $54,000 a year. The build looks cheaper in year three on a simple comparison and stops looking cheaper once maintenance and the internal ownership burden are included honestly. Somebody has to specify changes, test them and support users, and that person is a cost whether or not they appear in an IT budget.

One more cost sits on the build side and is almost always omitted: adoption. Neither path produces useful numbers unless people record time accurately and promptly, and a custom system does not get the benefit of familiarity, published training material or a user community. Firms that build sometimes discover that the system is correct and the data going into it is not, which produces precise reports about the wrong thing. Where recording discipline is already weak, fixing that is a larger and more valuable project than replacing the software, and it should be done first regardless of which path is chosen.

The hybrid that is usually the right answer

The framing of build against buy is a false pair, and the third option is what most firms should actually do.

Buy the product that handles the general problem well: engagement records, time capture, billing, resourcing, and the client-facing surfaces. Build only the piece that is genuinely yours and that the product cannot express, which for most firms is either the revenue schedule or a profession-specific process.

This works when the bought product has an API that exposes the underlying records rather than only reports, which is a question to ask during evaluation because the answer varies enormously. Where it does, a revenue schedule computed alongside the product, from its own data, is a small system rather than a large one, and it leaves the firm free to change the product later without restating anything.

Where the product does not expose its data usefully, that is a stronger argument against buying it than any missing feature, and it should be weighted accordingly during selection.

A practical test separates a product that will support this from one that will not. Ask whether you can retrieve, through an API, every time entry with its engagement, grade, status and full transition history, and every write off with its reason and author. If you can, a schedule and a leakage analysis can be computed alongside the product and kept accurate. If you can only retrieve a monthly summary, you are dependent on the vendor's interpretation of your own numbers, and no amount of building around the edges fixes that.

A decision rule you can apply in an afternoon

Four questions, answered honestly, settle this in most firms.

Does billing track delivery closely enough that a schedule derived from invoices would be materially correct. If yes, buy, and stop reading comparison grids after the shortlist.

Does any commercial arrangement need to sit above more than one engagement. If yes, test that specifically in every demonstration, because it is the most common structural limit.

Does the firm need to attribute leakage rather than merely measure utilisation. If yes, examine how time entry states and write-off reasons are modelled, since this cannot be added later without losing history.

Does anything in your profession carry a defined regulatory process that general products handle shallowly. If yes, expect to build that piece regardless of what else you decide.

A fifth question is worth asking only if the first four produce a mixed answer. How stable are your commercial models. A firm that has changed how it prices twice in three years, and expects to again, is buying flexibility it will genuinely use. A firm whose arrangements have been the same for a decade is buying flexibility it will pay for and leave idle, and the money is better spent on implementing a bought product properly.

A firm answering no to the last three should buy, implement well, and spend the saved money on adoption. A firm answering yes to two or more should plan a hybrid deliberately rather than discovering it after a failed implementation.

What each path costs, with the hours shown

Here is the rate, the hours and the multiplication.

The rate band for this work is $40 to $100 per hour by role. Reporting and administrative screens sit near the floor, revenue recognition and capacity forecasting near the ceiling. A mixed team blends to about $65.

Path	Hours	At the $65 blend
Full build, first version	1,180	about $76,700
Revenue schedule alongside a bought product	180 to 300	$11,700 to $19,500
Profession-specific process module	140 to 260	$9,100 to $16,900
Integration to a general ledger	120 to 200	$7,800 to $13,000

Those hybrid figures assume the bought product exposes its records properly. Where it does not, the same work costs materially more, because the data has to be reconstructed from exports on a schedule rather than read directly, and a reconciliation step has to be built to catch what the export missed. That is the practical price of the lock-in described earlier, and it is worth quantifying during selection rather than discovering afterwards.

The hybrid rows are the important ones, because they are the realistic shape of most engagements in this category. A revenue schedule and a general ledger integration together is 300 to 500 hours, or $19,500 to $32,500 at the blend, against a full build at more than double that and a permanent maintenance commitment behind it.

Two questions settle this before a shortlist exists. Does your revenue schedule have to be independent of your invoices, and if it does, which system will own it. And can the product you are considering give you its underlying records through an API rather than only its reports. A vendor who answers the second one vaguely has answered it.