How to select the right accounting system for a growing business

The accounting system you chose when you had 15 staff rarely survives contact with 60. That's not a criticism of the software – Xero, QuickBooks and Sage 50 are well-built tools for the businesses they're designed to serve. The problem is that the business has changed and the system hasn't.

The invisible cost is the one that hurts. It's not a line item in the P&L. It's the two days your finance team spends every month end building reports in Excel because the system can't produce them. It's the consolidation (combining accounts across multiple entities for group reporting) that takes a week because you're running separate instances and reconciling manually. It's the audit trail gaps that make your accountants nervous. It's the integrations held together with CSV exports and crossed fingers.

By the time most FDs or MDs decide to move, they've already absorbed 12 to 18 months of unnecessary friction. The goal of this guide is to give you a structured way to approach the decision – covering requirements mapping, how to run an RFP (Request for Proposal – a structured document sent to vendors that defines your requirements and asks them to propose a solution and price) and what to watch for when evaluating responses.

Signs your current system is holding you back

Before you start any selection process, it's worth being clear about what's actually breaking down. The following situations are reliable indicators that you've outgrown your current platform.

Manual Excel bridging. If your finance team is routinely exporting data into spreadsheets to do analysis, create management accounts or build reports that the system should produce natively, that's a gap the software isn't filling. Spreadsheets introduce errors, create version control problems and don't scale.

No multi-entity capability. Multi-entity means running accounting for multiple companies or locations within one system. If you've acquired a business, set up a subsidiary or operate across multiple legal entities, and you're managing each one in a separate system instance (or worse, a separate product), you've already hit a ceiling.

Reporting takes days, not hours. A business of 50 to 200 people should be able to produce management accounts within three working days of month end. If your finance team is spending more time than that on reconciliation and data assembly, the system is creating work rather than reducing it.

Integrations held together with CSV exports. System integrations – connecting your accounting system to other software such as your CRM, payroll platform or operations tools – should run automatically via API. If your team is manually exporting files and importing them elsewhere on a schedule, that's a brittleness risk and a time cost. It also means data is never quite in sync.

Audit trail gaps. Any system going into a finance audit needs to show a clear record of who posted what, when and why. Entry-level accounting tools often have limited audit trail functionality. If your auditors are asking questions your system can't answer, that's a material issue.

Mapping your requirements before you talk to vendors

This is the step most businesses skip, and it's the reason most selection processes go badly. If you go into vendor conversations without a clear picture of what you actually need, you'll be led through a sales deck and come out the other side half-convinced by whichever vendor gave the most impressive demo.

Do this work first.

Chart of accounts review. Your chart of accounts is the structured list of all financial categories your business uses for coding transactions. Before any migration, you need to understand whether your current structure is fit for purpose or whether this is an opportunity to rationalise it. A system change is a natural point to clean this up – but it adds scope, so it needs to be in your requirements.

Current integrations audit. List every system your finance platform currently connects to, however loosely. Payroll, CRM, e-commerce platforms, project management tools, expense management – all of it. For each one, note whether the connection is via API, CSV or manual entry. This becomes your integration requirements list.

Multi-entity and multi-currency needs. Are you operating in more than one legal entity? Do you invoice in multiple currencies? Do you need consolidated group reporting? If the answer to any of these is yes – or if it's likely to be yes within 24 months – this needs to be a hard requirement, not a nice-to-have.

Reporting requirements. Talk to the people who actually use financial reports – not just the finance team. What does the CEO need to see? What does the ops director pull regularly? What does the board pack look like? Document the ten to fifteen reports that matter most, with enough detail that a vendor can confirm whether the system produces them natively or requires customisation.

User access model. How many people need access to the system? What levels of permission do you need? Do external advisors or auditors need read-only access? AP/AR (Accounts Payable – money you owe / Accounts Receivable – money owed to you) teams often need different access levels from management accountants. Define this before you go to market – it affects both licensing cost and implementation scope.

How to structure an RFP

A well-structured RFP keeps vendors honest, makes responses comparable and signals that you're a serious buyer. Here's what to include.

Business overview. A brief description of what your business does, how it's structured, your revenue range, headcount and the markets you operate in. Vendors use this to assign the right implementation team and to sense-check whether their product is a realistic fit.

Current state. What system you're on, how long you've been on it, why you're looking to move and what the key pain points are. Include the scale of your data – number of transactions per month, number of entities, number of currencies.

Functional requirements (scored). A numbered list of requirements, grouped by area: core accounting, AP/AR, reporting, multi-entity, multi-currency and so on. Ask vendors to respond to each with a status – native, configurable, third-party or not available – and to note any caveats. Weight the requirements so you can score responses consistently.

Technical requirements. Cloud vs on-premise preference, single sign-on requirements, data residency, security certifications, uptime SLA expectations and browser/device compatibility. If you have specific IT or compliance requirements, state them here.

Integration requirements. List each system you need to connect to and ask vendors to confirm whether a native integration exists, whether it's available via API, or whether it would require custom development. Ask for specifics – not "yes we integrate with Salesforce" but "here is the data that flows, the sync frequency and the implementation approach."

Implementation expectations. Your preferred go-live timeline, any blackout periods (year-end, peak trading), the internal resource you can commit to the project and whether you expect the vendor to lead implementation or work alongside a third-party implementer.

Support model. What support is included in the licence? What's the response SLA for critical issues? Is there a dedicated account manager? What does the training provision look like? These questions matter more in year two than at the point of sale.

Pricing structure. Ask for a clear breakdown: licence cost (per user or flat), implementation cost, data migration cost, training cost and any third-party costs the vendor is aware of. Ask for a three-year total cost of ownership estimate, not just year one.

Send your RFP to no more than four vendors. More than that and you'll spend more time managing the process than analysing the responses. Give vendors three weeks to respond – enough time for a considered proposal, short enough to keep momentum.

Evaluating responses

Build a scoring matrix before responses arrive. Assign weights to your requirement categories based on their importance to your business – if multi-entity is critical, it should carry more weight than, say, expense management. Score each vendor's response against each requirement, multiply by the weighting and total up. This won't make the decision for you, but it removes subjectivity from the first cut.

Shortlist two or three vendors for demos. The most important instruction you can give at this stage: ask vendors to demo your processes, not their standard deck. Give them three or four scenarios drawn from your actual operations – month-end close, intercompany transactions, a specific report – and ask them to show you how the system handles each one. If a vendor pushes back on this or can't do it, that tells you something.

Reference checks are non-negotiable. Ask each vendor for two or three references from businesses in your sector, at roughly your size, who went through implementation in the last two years. Call them. Ask specifically: what took longer than expected, what was harder than quoted, what would you do differently, and how has support been since go-live. You'll learn more in twenty minutes on the phone than from any amount of marketing material.

What vendors won't tell you upfront

Implementation timelines are optimistic by design. A vendor quoting twelve weeks for implementation has quoted twelve weeks in ideal conditions with a fully engaged client, clean data and no scope changes. In practice, plan for 1.5 to 2 times the quoted timeline. Build that into your project plan from the start.

Data migration is always harder than quoted. Moving years of transactional data from one system to another, cleaning it, mapping it to a new chart of accounts and validating that it's arrived correctly is a significant piece of work. Vendors often underscope this because it's dependent on the state of your current data – which they haven't seen. Get a fixed-price data migration quote only after the vendor has completed a data assessment.

Training and change management are chronically under-resourced in most implementations. A day's training for the finance team at go-live is not sufficient. People need time to build confidence in a new system before the pressure of month end. Budget for training before go-live, during the first month-end cycle and at the three-month mark when gaps become apparent.

Total cost of ownership in years two and three is often higher than year one. Licence costs increase. Add-ons that were described as standard turn out to be premium modules. Customisations require maintenance. The implementation partner you relied on for go-live becomes a support dependency. Ask vendors directly: what has the average cost increase been for clients in year two? If they can't answer, that's instructive.

Common systems at each tier

This isn't a recommendation – the right system depends on your specific requirements, sector and scale. But it's useful to understand the landscape before you go to market.

Entry-level. Xero, QuickBooks and Sage 50 serve businesses well up to around 20 to 30 staff with straightforward structures. They're cloud-native, cost-effective and well-supported by accountants. They start to show limits around multi-entity, advanced reporting and complex integrations.

Mid-market. Sage 200, Access Financials, Xledger and NetSuite sit in the space between entry-level and full ERP. They offer greater reporting flexibility, multi-entity and multi-currency capability, and more robust integration options. Implementation is more involved than entry-level tools, and licensing costs reflect that.

ERP. ERP (Enterprise Resource Planning – software that integrates finance, operations, HR and other functions in one system) solutions such as SAP Business One, Microsoft Dynamics 365 and Infor are appropriate for businesses with complex operational requirements beyond finance – manufacturing, supply chain, workforce management and so on. They carry significant implementation cost and complexity and are usually the right choice only when the operational integration value justifies it.