Accounting Firm Workflow Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does scoping a Karbon replacement happen so often?

The pain presents as a practice management failure, so the fix gets written as a practice management replacement. In the first scoping meeting every partner names something Karbon does not do, the list runs to two pages, and by the end of the hour the project is a new system that will hold work items, client tasks, email, documents, status and billing.

The diagnosis is usually wrong. Karbon does the things it sells reasonably well: shared inboxes, work templates, client tasks. What is broken sits at the seams, in the places no practice management product can reach. E-file acknowledgments are inside UltraTax. Signed 8879s are in SafeSend. Engagement letters are in Ignition and workpapers are in SmartVault. A replacement inherits every one of those seams, then adds the job of rebuilding email triage and task management that already worked.

The cost is specific. Replacing Karbon outright rather than building on top of it can double the total, and a longer programme has to cross a season, so the cutover lands at the worst possible date.

The fix is a scoping test you can run in ten minutes. Ask which Karbon features your staff touch daily. If the answer is triage and work items, you are not replacing it. Write the scope as a layer instead: Karbon keeps triage and tasks, the build owns cross system status, document collection and the client data model. Ship that, run a season on it, then decide whether anything else needs to move.

What goes wrong when you migrate client and entity history?

The second failure is quieter and it shows up in month three. Someone exports Karbon contacts, imports them one to one, and the new system inherits a flat list. Then the first real requirement arrives: a married couple with two S corps and a family trust, where one spouse may see three entities and the other may see two, and every consent, engagement letter and return has to hang off the right node.

A flat contacts table cannot express that, so the schema gets rebuilt with data already sitting in it, which is the most expensive order to do it in. The related failure is Section 7216 consents and engagement letters imported as documents rather than as dated records per entity, so nobody can answer which consents expire before January without opening files.

Three rules keep this out of trouble. Model entities, people and roles before importing a single row, and test that model against your messiest real client rather than a tidy one. Keep the Karbon contact identifier on every record so re-sync stays possible and you are never trapped in a one way import. And treat consents and engagement letters as dated records per entity per year with expiry dates, because that is the form the question always arrives in.

Why do the tax software integrations break after launch?

None of the major tax packages offers a friendly public API. Integration with UltraTax, Lacerte, Drake or CCH Axcess runs on scheduled exports, report file parsing and print to file workflows. Built carefully, those hold up. What they do not survive unaided is the autumn update cycle, when a report layout shifts a column or renames a field and the parser quietly starts reading the wrong thing.

The failure mode is silence. A parse error that throws is a good day. A parse that succeeds against a changed layout gives you a status board where the acknowledgment column stopped updating three weeks ago, and nobody notices until a partner asks why a return shows as e-filed and the client is holding an IRS letter.

Two fixes, both cheap at build time and awkward later. Treat every export as an untrusted feed with a schema check, so unexpected columns fail the import loudly and leave yesterday's data in place rather than writing partial rows. And put a freshness alarm on every feed, so a file that has not arrived since Tuesday raises a flag on Wednesday instead of in April.

Then plan for it. Each additional tax package is its own integration effort of roughly two to three weeks, and the autumn update is a scheduled maintenance event every year rather than an incident. Firms that write that into the support arrangement stop being surprised by it.

What happens when Publication 4557 and your WISP are not covered?

IRS Publication 4557 sets out safeguards for taxpayer data, and firms are expected to maintain a written information security plan. A build scoped without either produces a system that works and cannot be defended.

You find out at the worst time. A client requests their records, or a laptop goes missing, and the questions are who opened this return, when, and from where. If the application reaches the document store through a shared service account, the honest answer is that anyone could have. If returns sit unencrypted in a bucket a former contractor still holds keys to, that is the finding.

What has to be in scope from the start: encryption of returns and client documents at rest and in transit, role separation so a seasonal preparer cannot reach every client, per user access logging on document reads rather than only on logins, and hosting in accounts your firm controls.

The practical test when choosing a developer is to say nothing and see whether they raise it. A team that has worked with CPA firms brings up Publication 4557, access logging and role separation unprompted. A team that reads up on it after kickoff will bolt security onto a finished system, which costs more and works less well. Then update the security plan to name the new system before go live, not after.

Should you build custom or configure what you already own?

Under roughly 10 to 12 staff, or with a single service line, do not build. Most firms that size with workflow pain do not have a missing product, they have an unconfigured Karbon: templates never adapted to the firm's actual stages, triage half adopted because two partners kept working from Outlook, client tasks switched on and abandoned. A few thousand dollars of configuration work plus partner discipline beats a custom build at that scale, and we would say so rather than quote.

The signals that the arithmetic has flipped are behavioural rather than size based. Someone exports Karbon to Excel every week to answer a basic status question. A person on payroll spends most of their time rekeying between systems. You run three or more service lines with genuinely different workflows. You sit at 25 or more seats, where Karbon's published $59 to $89 per user per month starts to compare with owning your own layer. Or you merged and now need one view across two stacks.

When two or more of those are true, build the layer and keep Karbon underneath it.

How do hidden costs get into an accounting firm software quote?

Four places, and all four are visible at scoping if somebody asks.

Tax packages. A quote written for one package and a firm running three is short by two integrations, because Lacerte, UltraTax, Drake and CCH Axcess all export differently and each is its own effort.

The client portal. Anything client facing roughly doubles security and design work compared with internal only tooling, and it adds a support burden the firm carries forever. If clients have not asked for it twice, defer it.

Document classification. Reading an upload and recognising it as a K-1 rather than a W-2 sounds like a checkbox and is real work with its own accuracy tuning and review queue.

Data cleanup. Duplicate contacts, dissolved entities, consents filed against the wrong entity. Nobody quotes for it because nobody has looked at the data yet, and it is the line that moves most between the estimate and the invoice.

Then the recurring cost that gets left out entirely. Maintenance runs 10 to 20 percent of build cost per year, so roughly $8,000 to $18,000 on a $90,000 first release, covering hosting, monitoring, security patches and the autumn breakages. Ask for the quote broken out per tax package and per integration, so you can see exactly what a lower number is deferring.

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

Calendar discipline, above everything else. Production freezes from late January through 15 April. You are live and stable by November or you wait until May. A firm that lets a developer schedule a February release has already lost the season, because staff under deadline pressure revert to the spreadsheet they trust and do not come back off it.

Then a data model that starts with households and entities rather than a clients table, because that decision is cheap in week one and expensive in month three.

Then an owner inside the firm. Usually it is the tax manager who rebuilds the status tracker every Monday, because she is the only person who knows what the real stages are. Give her hours, not just a title.

Then the contract. Full ownership of source code, data and the cloud accounts, written down before kickoff. The point of the exercise is to stop renting your firm's workflow, so do not rent it again from the people you hired to fix it.

The firms where this works treat the first release as a replacement for one spreadsheet rather than for one system. The Monday tracker disappears, the document chase becomes a system job, and everything else gets decided after a season of evidence.