Why Accounting Firms Are Moving Off Per-Seat Software — and What It Actually Takes

If you run an accounting firm, your software bill probably scales the wrong way. Every new client account, every new staff seat, every new module — another line item. Multiply that across the client base you’re supposed to be growing, and the tool that’s meant to help you scale becomes a tax on scaling.

This is the conversation happening at a lot of accounting firms right now: What would it take to move off a per-seat platform and onto something we actually own?

The honest answer is: more than a "let’s just switch systems" weekend. But it’s also more achievable — and more valuable long-term — than most firms assume. Here’s what the real path looks like.

The Real Motivation Isn’t Just Cost

License fees are the visible pain, but they’re not the main prize. The bigger shift is architectural: instead of paying for access to someone else’s system, you build a platform that becomes an asset of your firm.

For an accounting firm serving many clients, that difference compounds. A per-seat tool costs more as you grow. A platform you own costs less per client as you grow — because the expensive part (the build) is a one-time cost, and each new client is just marginal hosting and onboarding.

That only holds, though, if the platform is built to serve many clients from day one — not retrofitted later.

Migration Is a Data Problem Before It’s a Software Problem

The instinct is to treat this as "just install ERPNext and migrate the data." The actual work starts earlier: mapping every field your current system uses — purchases, sales, receipts, payments, assets, daily entries — to its equivalent in the new system, and flagging which fields are mandatory.

Skip this step and every later step inherits the ambiguity. A migration script built without a clean mapping table will need to be rebuilt once the mapping surfaces the fields nobody accounted for.

The safest sequence:

1. Map the fields before writing any migration code.
2. Pilot with one year of one client’s real data — not a demo dataset.
3. Verify the boring stuff obsessively: opening balances, trial balance, tax reports. If these don’t reconcile, nothing downstream matters.
4. Run both systems in parallel for a month or two before cutting over. Month-end reconciliation between old and new systems is what actually proves readiness — not a checklist.

Only after that does it make sense to ask whether the new system can fully replace the old one.

The Frontend Question: Build Less Than You Think

A tempting goal is "recreate our old software’s interface exactly, so nobody has to relearn anything." Resist that. It’s expensive and mostly unnecessary.

The more useful question is: who actually needs to touch this system, and for what?

For a firm whose clients will self-report their own income and upload expense documents, the real interface need is narrow:

• A simple income-entry screen (invoice, VAT, withholding tax)
• A place to upload expense documents
• A summary view of income vs. expense

That’s four or five screens, not a full accounting suite clone. Building a simplified layer for a narrow, well-defined task is a tractable project. Building a general-purpose alternative to your old software is not — and usually isn’t necessary, because your staff can work directly in the underlying system for everything else.

Document Automation Is the Hard Part — Budget Accordingly

If part of the vision is "clients upload a receipt and the system reads it automatically," treat that as its own project, not a feature bolted onto the frontend.

Optical extraction from real-world documents — thermal receipts, handwritten notes, photos taken at an angle, mixed-language tax invoices — is genuinely difficult. Even well-formed tax invoices land around 80–90% extraction accuracy; small-shop receipts are worse.

The non-negotiable design principle: extracted data goes into a review queue, never straight into the books. A human confirms before anything becomes a posted transaction. This isn’t caution for its own sake — a firm that auto-posts unverified data into a client’s books is one misread tax ID away from an incorrect VAT filing, and that liability doesn’t stay with the software.

Multi-Tenancy Isn’t Optional at Scale

If one firm is going to serve many client companies on the same platform, data isolation isn’t a nice-to-have — it’s the whole point. Each client’s books need to sit in genuinely separate storage, not just be filtered by a permission flag inside one shared database.

The operational pieces this requires are easy to underestimate:

• A repeatable way to spin up a new, isolated environment per client
• Backup and recovery that works per-client, not just system-wide
• A way for staff to move between client accounts without friction

Skip this layer and the tenth client onboarding is exactly as manual as the first. Build it, and the hundredth client costs almost nothing incremental to add.

Why Every Estimate Should Start as a Range — and How to Narrow It

Any honest estimate for a project like this starts wide, because the real cost drivers aren’t visible until you’ve looked:

• How clean is the data export from your current system?
• How messy are the real-world documents you’ll need to process?
• How many documents per client, per month, are we actually talking about?

Firms — and vendors — that skip straight to a fixed number are usually padding for risk they haven’t measured, or quietly hoping the ugly cases don’t show up. The better sequence is a short, paid discovery phase: map the fields, test a real data export, pull a handful of real documents and see how they extract. That turns an educated guess into a real quote — and the discovery cost typically gets credited against the full project once it moves forward.

The Bottom Line

Moving off per-seat accounting software isn’t a rip-and-replace weekend, and it isn’t a six-figure fantasy either — it’s a sequenced project with real, known phases: map the data, prove the migration on one client, run parallel until the numbers agree, build only the interface people actually need, and treat document automation as the specialist task it is.

Firms that go in expecting exactly that tend to end up with something worth having: a system they own, that gets cheaper per client as they grow, instead of more expensive.

Frequently Asked Questions

How long does a migration like this actually take?
For a firm with a handful of client accounts to start, expect roughly 7–9 months from field mapping through to a working rollout, with document automation and multi-tenant infrastructure built in parallel with the frontend. A firm that skips document automation and keeps the frontend narrow can move faster.

Can we keep using our old system during the transition?
Yes — and you should. Running both systems in parallel for a month or two before cutting over is how you catch discrepancies while there’s still a safety net. Switching over in one step, without a parallel period, is the single riskiest way to run this kind of project.

Is our data safe moving to an open-source platform?
Data safety depends far more on how the platform is hosted and isolated than on whether the underlying software is open-source or proprietary. The relevant question isn’t licensing model — it’s whether each client’s data sits in a genuinely separate, backed-up environment.

Do we need document automation (OCR) from day one?
Not necessarily. If document volume per client is low, having staff key in expenses manually is often cheaper than building and maintaining an extraction pipeline. It’s worth counting actual monthly document volume before committing budget to automation.

What happens if the automated document reading gets something wrong?
It should never reach the books unreviewed. Every extracted document should land in a review queue for a person to confirm before it’s posted as a transaction — that’s what keeps a misread number from turning into an incorrect filing.

How is the price determined before the work starts?
It usually starts as a range, because the real cost drivers — data export quality, document mess, transaction volume — aren’t visible until someone looks. A short, paid discovery phase turns that range into a firm number, and its cost is typically credited back once the full project moves forward.

---

Considering a similar migration for your firm? The details that matter most — data export quality, document volume, and how many client workflows you actually need to support — are worth nailing down before anyone quotes you a number.