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

Why does the close board get scoped as a task app so often?

Because the requirement sounds like task management. Somebody says we need to see where every client stands in the close, and the obvious answer is a board with steps and owners. Karbon, Jetpack Workflow, Financial Cents and Aero already do that well, and any development firm can build another one. What none of them can do is tell you whether the books are actually closed, because a checkbox is a claim about the work and not a fact about the ledger.

The distinction matters more than anything else in this category. Your delivery model is built on treating a completed task as evidence of a correct file, and it is not. Undeposited funds sitting at eighteen thousand dollars, a payment processor clearing account out by four thousand, sixty transactions parked in a holding account: all of that coexists happily with a green board.

The model that works attaches a machine assertion to every step. Bank reconciliation difference equals zero. Undeposited funds below the materiality figure you set for that client. Uncategorised count equals zero. No payable older than ninety days without a reason code. The step cannot turn green while its assertion fails, and turns green by itself when it passes. The board stops being a self report and becomes a readout of the ledger, and the reviewer stops spot checking green files, which is the entire return on the build.

What goes wrong with ledger sync and historical backfill?

Two data problems sink these projects, and both are underestimated because the connection itself is easy.

The first is normalisation. QuickBooks Online and Xero disagree on nearly every entity shape, on rate limits and on how they express the same accounting concept, so the middle data model both map into is the actual work. Teams that skip it write one integration properly and bolt the second on with special cases, then discover every downstream assertion has to know which ledger it is reading. Budget each additional ledger as its own workstream rather than assuming the second is cheap, and treat Sage Intacct as a third project rather than a variation.

The second is backfill. Three years of history across a few hundred client files is engineering rather than a script: rate limits throttle you, some clients have partial permissions, a few files have closed periods with adjustments that do not tie, and a handful were migrated from desktop and carry artefacts nobody can explain. Run backfill as its own track alongside the build, reconcile each client's opening position to the ledger at capture, and surface the breaks as a work queue rather than silently absorbing them. A break discovered in month nine is a credibility problem the reviewer will never forget.

The third problem is the one nobody asks about at the start: every client's chart of accounts is different, so your own book is unreadable in aggregate. One calls it cost of goods sold, another direct costs, a third dumped everything into contract labour in 2019. Mapping each client account to a firm standard line, versioned so restatements do not corrupt history, is what turns your data into a dashboard you can sell advisory from. Nothing off the shelf builds it, because the taxonomy is yours.

Why do the ledger integrations break after launch?

They break in ways easy to miss, which is why the sync architecture belongs in the proposal in writing rather than as an integration promise.

Token expiry is the first. Authorisation refresh tokens expire, clients disconnect apps, and a firm that finds out through a stale board on day twelve of the close is finding out at the worst possible moment. Monitor connection health per client, alert on the disconnection rather than on the symptom, and give staff a one click reconnect path they can send to the client.

Silent drift is the second and the more dangerous. A sync that half completes leaves a client's data partially current, and the board keeps showing assertions computed against yesterday's picture. The system has to reconcile its own sync: compare its record counts and balances against the source, stamp every client with the time its data last landed, and show that timestamp on the board so a stale file looks stale.

Version changes are the third. Both platforms publish deprecations on a schedule, so a well built layer pins versions and fails loudly rather than quietly returning fewer fields. The failure to avoid is an integration that keeps running after a field disappears and computes an assertion against nothing.

Ask a prospective developer about refresh token expiry, throttling behaviour under rate limits, change data capture for incremental pulls, idempotent writes and what happens when a client disconnects mid close. The specificity of the answer tells you whether they have run one of these in production or only built one.

What happens when the security plan and access logging are not covered?

If any part of your firm touches tax, the Gramm Leach Bliley Act Safeguards Rule and IRS Publication 4557 require a written information security plan, and any software holding client financial data has to live inside it. Teams that treat this as paperwork written after launch end up retrofitting, which costs several times what designing it in would have.

Three concrete requirements fall out. Client credentials and tokens must be encrypted with a documented key management approach, not stored as configuration. One client's ledger must be hard segregated from another's, enforced at the data layer rather than by a filter in application code that a future query can forget. And you need access logs answering which staff member opened which client file last Tuesday, retained long enough to be useful in an incident.

The other gap is the client portal. Adding one drags in authentication, per client data segregation for external users, and an audit trail of what the client saw and changed. It is frequently added late as a small feature and it is not small. If you serve venture backed clients, expect SOC 2 Type II questions, which is a readiness programme rather than a document, so decide early and scope the weeks.

Should you build custom or configure what you already own?

Under about sixty clients, one office, fewer than eight staff, standard small business books and no vertical specialisation, stay on Karbon or Financial Cents and spend the money on people. At that size the subscriptions are cheap relative to a build and your constraint is sales, not operations. Bending your process to software you did not write is the correct trade until it is not.

Keeper deserves a mention, because it reads the ledger and checks quality signals rather than only modelling tasks, which is real progress over a pure task engine. Its limit is that it checks its own list and stops at the client boundary, so it cannot encode your rule that ecommerce clients must not advance past receivables until payout reports tie to bank deposits.

Build when these appear together: you are past a hundred and fifty files and the spreadsheet is still the source of truth, you have specialised in a vertical whose close steps no tool models, your per client and per user subscriptions total more than the salary you would spend on the ops person copying data between them, and you can describe the version of your close process you would sell to another firm. Then build only that layer. Nobody should be writing a general ledger, a payroll engine or a bill payment rail. Sit on top of the commodity and own the part where your margin lives.

How do hidden costs get into the quote?

Additional ledgers, first. A quote priced for QuickBooks Online with Xero described as also supported is a quote for one integration and an optimistic sentence. Get both named with their own estimates.

Second, historical backfill, routinely folded into the sync line and actually its own engineering track. Third, document extraction accuracy targets, where the last few points cost more than the first ninety, so agree the target and the exception workflow rather than buying a number. Fourth, the client portal and everything it drags in. Fifth, SOC 2 readiness. Sixth, marketplace app review, which has its own calendar that no budget accelerates.

The line item most often missing entirely is the assertion library. Each assertion is a rule against real ledger data with edge cases, and a firm with vertical specialisations has more of them than a generic firm. Count yours before anyone prices the work.

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

Make the developer walk a close in front of you before you talk price. Ask them to sketch bank reconciliation and a period close. If undeposited funds, clearing accounts, the cash versus accrual toggle, reversing entries, the closing date password and the fact that a closed period can still be edited are all news to them, you are buying a task app with an accounting skin, and it fails in month four when your reviewer stops trusting the board.

Second, start with the assertions that catch the failures you have actually had. Every firm has three or four recurring ways a file goes wrong, and encoding those first produces visible value in the first close cycle rather than in month six.

Third, treat client answers as durable assets rather than messages. An answer should become a versioned coding rule keyed on vendor pattern, amount range and entity, with the client's own words attached as evidence for the next bookkeeper. Chase volume then falls because the system stops asking questions it already has answers to, which is a bigger effect than any classification model.

Fourth, run parallel for one full close cycle. Nothing about a close reveals itself in a demo, and the cycle you skip is the one that would have surfaced the rule nobody wrote down.

Finally, settle ownership before kickoff: the repository in your organisation, the infrastructure in your cloud account, a migration runbook written before launch. At Digital Heroes the client owns the code from the first commit. Then ask the question that matters more than any of it: who answers the phone at eleven at night on day twelve of the close when the sync stalls and every board goes stale.