PSA Software Problems: The 5 That Cost Agencies Real Money, and How to Avoid Them

Why does the dashboard-first scope failure happen so often?

The pain that gets an agency PSA project funded is always the same: the managing partner asks for current utilization in Monday's leadership meeting and gets a figure for a month that closed four days ago. So the brief is written as reporting. Sync Harvest, build a utilization dashboard, put it on a screen. It demos beautifully and it changes nothing, because the number on the dashboard is produced by the same arithmetic the operations director was already doing, just faster.

The thing that actually leaks margin sits underneath: there is no work-in-progress ledger between the timesheet and the invoice. Hours are approved, someone builds an invoice from an export, and time that never made it onto an invoice simply evaporates with no record that it existed. Two points of unbilled time across 80 billable people at a $150 blended rate is roughly $400,000 a year, and a dashboard cannot see it because a dashboard reports what was recorded, not what should have been billed.

The fix is to build the ledger first and the dashboard as a view over it. Every approved hour becomes a priced WIP line with a state: unbilled, billed, written off or carried. Writing time off requires a reason code and a name. Utilization then falls out of that data for free, and realization, which is the number that actually explains your P and L, becomes available for the first time.

What goes wrong when years of Harvest history are migrated?

Harvest exposes full time entry, project, client and invoice history through its interface, so people assume migration is a scripted afternoon. The extraction is the easy half. The problem is that your old Harvest project and task structure does not map cleanly onto the new rate card and contract model, and nobody discovers that until the mapping is attempted.

The specific defects repeat across agencies. Projects created per campaign rather than per contract, so a single master services agreement is spread across nineteen Harvest projects with no shared parent. Task codes that meant something in 2021 and were reused for something else in 2023. Time logged to a placeholder project called Internal that turns out to contain real billable work for two clients. People who left, came back as contractors, and exist twice with different cost assumptions. Feed that into a new margin engine and every historical number it produces will be wrong in a way nobody can explain.

The fix is a cleanup pass with your operations team before cutover, not during it. Produce a mapping table from old project and task codes to the new contract, client and service line structure, have a human sign off on the ambiguous rows, and decide explicitly how far back you are migrating priced history versus raw hours. Then cut over on a month boundary and run one full parallel invoice cycle, so no billing period is ever half in each system.

Why does the two-way QuickBooks sync break after launch?

The demo sync works. Draft invoice generates, pushes to QuickBooks Online, appears in the ledger. Everyone signs off. Then finance voids an invoice in QuickBooks because a client disputed a line, and the WIP behind it is still marked billed. Now your realization report is wrong and nobody knows, because the failure is silent.

The events that break a one-directional design are the ordinary ones: voids, credit memos, partial payments, an invoice edited directly in QuickBooks rather than in the new system, and a payment applied across two invoices. Each of those has to flow back and adjust the WIP lines that produced the invoice. A nightly export cannot do it, because a nightly export has no concept of which WIP line a credit memo relates to.

The fix is to design the reverse path before the forward one. Ask the developer directly what happens in their model when an invoice is voided in QuickBooks after the WIP behind it was marked billed. Anyone who has run a two-way ledger sync in production for a year answers immediately and describes the reconciliation job. Anyone who has not says the interface handles it. Insist on a daily reconciliation report that lists every invoice where the ledger and the WIP disagree, with an owner, because drift is not preventable and undetected drift is what makes the numbers untrusted again.

What happens when contract terms are not modelled properly?

Your contracts are the product of years of negotiation: a retainer with 20 percent hour rollover, a fixed-fee build billed on milestones, a master services agreement with a rate escalator on each anniversary, a time and materials engagement with a cap. If the build treats a contract as a budget number and a rate, every one of those terms goes back to being enforced by staff memory, which is exactly the failure you paid to remove.

Three consequences follow. Rollover balances get tracked in someone's head, and a client eventually claims hours you did not know they had. Escalators do not fire, so you invoice at last year's rate through the whole of the new contract year. And fixed-fee revenue gets recognised on invoicing rather than on delivery, which is fine until an acquirer's diligence team asks how revenue is recognised under ASC 606 and the answer is a spreadsheet.

The fix is to make the contract a first-class object rather than an attribute of a project. Entitlements, rollover rules with expiry, milestone schedules, caps and escalators are enforced by the system and are visible to the account director before they promise anything. Recognition schedules generate from those terms and post monthly to your ledger. If a sale or an audit is anywhere in your future, this is the part that pays for the project on its own.

Should you build custom or configure what you already own?

Below roughly 40 billable people, a single entity and mostly time and materials billing, do not build. Harvest at about $12 per seat per month plus QuickBooks plus one disciplined operations person genuinely works, and the money is better spent on the operations person. Fix the obvious things first: put cost rates in one place with dates on them, standardise your project naming so exports stop needing manual repair, and close invoicing within five working days.

If you have outgrown that, the honest next step is a mid-market PSA before any build conversation. Productive, BigTime and Kantata exist precisely for agencies at your size, and if their data model expresses your contract terms then subscribing is the better commercial decision by a wide margin. Run your three most awkward agreements through a trial and see whether the system can enforce them without a spreadsheet on the side.

Build when the spreadsheet layer survives the trial. That is the real test. If someone senior still spends three or more days a month reconciling by hand after configuring a proper PSA, if your contracts contain rollover and escalation terms no vendor's model enforces, or if you run more than one entity with cross-border staffing, then the spreadsheet is your actual PSA. It is unaudited software with one maintainer, and replacing it with owned, tested software is the conservative choice.

How do hidden costs get into the quote?

Four places, consistently. The first is the accounting sync, quoted as an integration and delivered as a one-way push, with the reconciliation work reappearing as a change request three months later. Get the void, credit memo and partial payment cases written into the scope in words.

The second is migration. Extraction is cheap and mapping is not, and the mapping effort depends entirely on how disciplined your Harvest structure has been. Ask for migration to be priced after a discovery pass on your actual data rather than before.

The third is permissioning. Account directors seeing only their own clients, partners seeing everything, contractors seeing almost nothing, and cost rates hidden from people who should not see salaries. This is rarely in a first quote and always required before go-live.

The fourth is multi-entity and multi-currency. If a London strategist works a New York account, someone has to decide the transfer rate, which entity carries the revenue and what rate the hours convert at. That is a modelling decision with tax implications, not a configuration toggle, and it should be discussed before a number is agreed. Then budget 15 to 20 percent of build cost per year for maintenance and integration upkeep.

What separates a PSA build that works from one that fails?

The builds that work start at the invoice and move backwards. If the system can produce next month's invoices correctly, with backing detail a client will accept, everything upstream of that is already right. Teams that start with resource planning because it is the most interesting screen tend to ship a beautiful forecast sitting on rates nobody trusts.

They also run parallel for one full billing cycle rather than cutting over on a weekend. Finance builds invoices both ways and compares them line by line. Every difference found in that week is a defect you would otherwise have shipped to a client, and the exercise is what converts finance from sceptics into owners.

They treat the write-off report as a feature, not an embarrassment. Making it visible who wrote off what, and why, is uncomfortable for about a month and then changes behaviour permanently, because realization stops being an accident.

And they settle ownership before kickoff: the repository, the cloud accounts, the documentation, under work-for-hire terms. This system produces the numbers in your statutory accounts and the evidence in your next diligence process. Any arrangement where a developer hosts it on accounts you cannot access, or licenses your own system back to you, is a dependency you will pay to escape later.