Consulting Firm Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does the rate card get scoped as a number on a person?

Because that is how every tool the firm has used represents it, so nobody thinks to question it. Harvest holds a rate on a person or a project. Float holds capacity. The specification says import rates from Harvest, and the data model inherits an assumption that a rate is a single value.

Then the first real engagement arrives and the assumption breaks in ways your commercial team considers ordinary.

• A master services agreement with four role levels and a volume discount above a threshold of hours.
• A blended rate exception for one client subsidiary that does not apply to the parent.
• An annual escalator that applies on the anniversary of signature rather than the calendar year.
• A rate renegotiated mid engagement in an email during a scoping call, effective from a date that is neither the contract start nor today.
• An expense cap expressed as a percentage of fees, which nobody tracks until the client disputes an invoice.
• Subcontractor pass through with a markup that differs from your employee rates.

The fix is to make the engagement contract a first class entity: role levels, rates, effective date ranges, volume tiers, escalators, caps and pass through rules. Every time entry then resolves its billable value against the contract at entry rather than at invoice time, so a rate change in one place reprices open work in progress and flags what already invoiced at the old figure. Realisation variance becomes visible on day two instead of day sixty. Retrofitting this later means rewriting how time is valued, which touches invoicing, work in progress and every margin report built on top.

What goes wrong when you migrate off Harvest and Float?

Time entries migrate cleanly. Almost nothing else does, and firms consistently underestimate the gap.

The hardest item is rate history, because it does not exist in either tool. Rates live in signed agreements, amendment emails and a controller's memory, and the version in Harvest is whatever was correct when someone last updated it. Reconstructing effective dated rate history for open engagements is the real migration work, and it is a finance analyst's job rather than a developer's. Budget two to three weeks of that person's time, or run document extraction over the agreements to draft the rate cards for them to approve.

The second is project structure. Harvest project codes are flat, and a phase that closed still accepts time, so historical hours are booked against codes that mean different things at different points in the year. Mapping those onto a structured engagement plan with phases and workstreams requires decisions nobody has made yet.

The third is people. Cost rates live in a spreadsheet the chief operating officer owns, skills live nowhere, and the resourcing manager's knowledge of who is actually good at payer side claims work is written down nowhere. That knowledge is why your staffing works, and capturing it is a facilitated exercise rather than an import.

Run parallel for one full billing cycle, typically 30 to 45 days, and reconcile the new system's invoices against the old ones before cutting over. Do not cut over mid month.

Why do the accounting and pipeline integrations break after launch?

The margin engine only works if money and demand data arrive reliably, and both connections degrade quietly.

Accounting is the harder one. The system has to push work in progress, unbilled revenue and period close journal entries into NetSuite, Sage Intacct, QuickBooks or Xero, and the failure is not an outage. It is drift: an invoice edited directly in the accounting system, a period reopened on one side only, a client created in accounting with no corresponding engagement, or a chart of accounts change that silently sends entries to suspense. Ask any prospective developer for the reconciliation strategy when the two disagree, because they will.

The pipeline connection is the second. Bench forecasting depends on weighted pipeline from your customer relationship system, and pipeline data is maintained by partners who update close dates optimistically and rarely mark anything lost. A forecast built on that without any decay assumption will tell you the bench is about to fill and it will be wrong every time. Calibrate against actual conversion rather than stated probability, and show the forecast alongside its own accuracy history so people learn how much to trust it.

The third is calendar and identity through Google Workspace or Microsoft 365, which underpins assisted time entry. Permission scopes here are a genuine sensitivity, and it is worth deciding early exactly what the system reads and what it never reads, because consultants will ask.

What happens when subcontractors and expense caps are not covered?

Firms above about fifty people typically run 10 to 25 percent of delivery through subcontractors and independent consultants, and this is where the largest hidden margin errors sit. Those people are not employees, so they are not in the time system. Their invoices arrive as PDFs by email, get keyed into the accounting system by an operations person weeks later, and land in a general ledger account that may not carry a project dimension. Until that happens, every engagement margin figure is wrong by that amount, and nobody knows which way.

The fix is unglamorous. Subcontractors enter time in the same system against the same project codes, with their cost rate and purchase order cap attached, so cost accrues daily and entry is blocked past the cap. Then document extraction on inbound invoices matches lines against accrued time and flags variances above a threshold such as $500 or 5 percent. The variances are the interesting output, because they are usually unauthorised scope or unlogged hours.

Expenses need the same treatment against client specific policies, since most master agreements cap travel at a percentage of fees and almost nobody tracks it until an invoice is challenged. A cap that the system enforces at the moment of entry is worth more than a report that observes the breach afterwards.

Should you build custom or configure what you already own?

Below roughly 30 to 40 billable people, on mostly time and materials work with a simple rate card in one legal entity and one currency, stay on Harvest plus Float. They cost a few hundred dollars a month and the monthly spreadsheet reconciliation genuinely does not hurt enough yet. The same answer applies if your firm is one practice doing one shape of work, because the complexity a custom build absorbs does not exist in your business. Spend the money on a good finance hire instead.

Kantata and Deltek Vantagepoint are real products solving a standardised version of this problem, and if your process can bend to their assumptions they are a reasonable buy. Expect a six figure implementation plus licensing that scales with headcount. Many firms should take that route and stop reading here.

The signal that says build is worth naming plainly: you already implemented one of these suites and the firm quietly went back to the spreadsheet. That means the mismatch is between your operating model and the tool's assumptions, and a second vendor will not fix it. The other signals are rate cards with exception logic no tool can express, more than 15 percent of delivery through subcontractors, more than one entity or currency, or a resourcing manager everyone knows is a single point of failure.

Even when you build, do not rebuild the general ledger, the customer relationship system or human resources (HR). Build the contract to time to margin chain that is specific to how your firm makes money and push clean data into everything else.

How do hidden costs get into the quote?

The bands are $60,000 to $130,000 over 12 to 16 weeks for a first release covering contract and rate card modelling, time capture with assisted entry, staffing with margin impact and live engagement economics with alerting, and $150,000 to $400,000 over 6 to 12 months for a full platform. The overruns are predictable.

Revenue recognition under ASC 606 or IFRS 15 with percentage of completion is a real engineering problem rather than a checkbox and typically adds $30,000 to $60,000, because estimate revisions, change orders and contract modifications each change the calculation. Multi currency and multi entity is the second, especially where a subsidiary bills a client abroad and intercompany transfer pricing has to net out. Deep two way integration with a legacy platform is the third, and older Deltek and NetSuite instances are the expensive ones. Client portals where the client approves time before invoicing is the fourth. Historical migration is the fifth, usually worth doing and usually underestimated.

Two items belong in the quote and rarely are. Your audit firm reviewing the recognition logic before it goes live rather than after your first close on it. And the security evidence work, because if you serve regulated clients their procurement teams will ask about data residency, segregation and controls, and answering that after launch is more expensive than designing for it.

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

The builds that work change two behaviours. First, timesheets stop being reconstructed from memory on Friday evening. Pull calendar events, project channel activity and document edits, present a pre filled draft the consultant confirms on their phone in under two minutes, and add validation the incumbents cannot: block time against closed phases, warn when someone books past a scope cap, require a note on entries over ten hours. Every number downstream becomes trustworthy because the input did. Second, the engagement plan becomes a structured object with phases, workstreams and planned hours by role level, so the system projects margin at completion from burn rate and alerts the partner in week four rather than at month close in week twelve. Week four leaves runway for a change order conversation while the client still remembers agreeing to the scope.

The builds that fail were chosen without testing the developer. Ask them to whiteboard a rate card data model in ten minutes, and if they draw a rate as a column on a person or a project, stop there. The right answer involves effective dated rate records, role level mappings, contract scoped overrides and a resolution function that takes a time entry and returns a billable value. Ask what happens to a timesheet entry after approval but before invoicing. Immutable entries with adjustment records is the correct answer, because clients dispute invoices and partners reopen closed periods.

Then own it outright. Full source in your own repository from the first commit, infrastructure accounts in your name, no licence back clause. Anything else is a hostage situation the day you want to change vendors.