Bookkeeping Software for Small Firms: Trial It Before You Commit
How bookkeepers should evaluate new tools with real client work.
A bookkeeping practice does not buy software the way a café does. When a café picks a new tool, one business lives with the result. When a practice of three or four people picks one, twenty or sixty client files move with it, and every one of those clients assumes their ledger is safe.
That changes how a trial should run. You are not asking "is this nice to use?" You are asking "could I defend every number this produces to a client, and to the tax office, if I had to?" This guide is for principals and senior bookkeepers of small firms who want to try something new, including tools still in beta, without betting the client book on it.
Choose the trial clients before you look at features
Most trials fail because the firm tests with the cleanest file it has. Clean files prove nothing. Pick three real clients that between them cover the work that actually eats your week.
| Trial client | What it tests | | --- | --- | | A sole trader with one bank account and messy receipts | Bank feed quality, receipt capture, how fast a junior can code a month | | A company with two accounts, a loan and a credit card | Transfers between accounts, loan interest splits, credit card reconciliation | | A business with payroll or GST complications | Mixed GST supplies, payroll journals, a quarterly or monthly BAS cycle |
If your practice specialises (hospitality, trades, not-for-profits, property investors), swap in a client from that niche. The point is coverage of your real exceptions, not a tour of the product's best screen.
Keep the trial to three clients. A beta tool that is wrong on three files is a learning exercise. Wrong on thirty, it is a remediation project you are not being paid for.
Before any client data goes in
Client data is not yours to experiment with freely. Settle these before the first import.
- Consent and the engagement letter. Check whether your engagement terms cover moving client data into a new system. If in doubt, tell the three trial clients what you are doing and why. Most will be pleased you are looking after them.
- Professional obligations. If you are a registered BAS or tax agent, your confidentiality obligations do not pause because the software is new. Ask yourself whether you could explain the choice to your professional body.
- Where the data lives. Ask the builder which country the data is stored in, which sub-processors touch it, and whether it is encrypted at rest. A vague answer is an answer.
- Who can log in. Individual logins for every staff member, with the ability to limit a junior to specific clients. A shared firm login is a deal-breaker, not a detail.
- Bank feed authority. Understand whether the tool connects to banks directly or through an aggregator, and what the client has to authorise. Do not hand over a client's internet banking password under any circumstances.
The reconciliation test that tells you almost everything
Features are easy to demo. Reconciliation is where bookkeeping software earns or loses its keep, so run one full month for each trial client and compare it against what your current system produced.
Here is what that looks like for the middle client in the table above:
- Import or connect the bank feed for the month. Count the transactions. Does the number match the bank statement exactly, with no duplicates and none missing?
- Code the month using the new tool's rules. Note how many rules you had to write and whether they apply to future transactions or only the current batch.
- Handle the awkward items deliberately: a transfer between the two accounts, a loan repayment split between principal and interest, a credit card payment, and a refund.
- Reconcile to the closing bank balance. Any unexplained difference, even a few cents, is a finding worth writing down.
- Run the GST summary for the period and compare it line by line with the figures from your current system. If they disagree, find out which one is right before you trust either.
- Check the audit trail. Change a coded transaction, then look at whether the tool records who changed it, when, and what it was before.
Timing matters too. Note roughly how long the month took in each system. A tool that is accurate but doubles your coding time is a tool your team will quietly stop using by the end of the quarter.
Migration is the real product
If the trial goes well, the next question is how the whole client book would move. Test this on one trial client now, not after you have signed up.
Opening balances. Decide on a conversion date, usually the start of a quarter or financial year, and check that the trial balance on that date matches your current system to the cent.
History. Ask how much prior-year detail comes across. Many tools bring balances but not transactions, which may be fine for day-to-day work but is not fine when a client asks about a payment from two years ago. Plan to keep read access to the old system.
Attachments and notes. Receipts, invoice images and your own file notes are often the first thing lost in a migration. Ask specifically.
Locked periods. Once a BAS is lodged, that period should be locked. Check that the new tool lets you lock it and that the lock actually stops edits.
Getting out again. Ask for a full export of one trial client during the trial: chart of accounts, transactions, contacts and attachments, in a format you could load somewhere else. If a builder cannot give you that before you commit, they will not find it easier afterwards.
Who in the firm needs to be in the room
Small firms tend to let one enthusiastic person choose the software. Spread it a little.
- The principal signs off on risk, client consent and cost, and should see the reconciliation comparison, not just a summary.
- The senior bookkeeper runs the awkward client and judges whether the tool handles real complexity.
- The most junior person codes the simple client. If they cannot work in it without constant help, training costs will eat whatever time the tool saves.
- One trial client, ideally the chattiest, should see their side: invoices, receipt capture, any client portal. They are the one who will ring you if it confuses them.
Questions to put to the builder in writing
Ask these by message so you have the answers on record:
- Which reporting obligations does the product support today, which are planned, and which are out of scope?
- How are tax rate changes and rule updates handled, and how quickly after they take effect?
- What happens to a client file if the practice stops paying? Is there read-only access, and for how long?
- Is there practice-level pricing, or is every client file billed separately?
- What is the support path when a bank feed breaks the day before a lodgement deadline?
- What have you deliberately not built yet? A straight answer here is worth more than any roadmap slide.
Nothing in a trial replaces your own professional judgement about your obligations. What the trial does is give you evidence about whether the software behaves the way its builder says it does, on files you know well.
Running the trial through LetsBeta
Bookkeeping tools have their own category on LetsBeta. A few parts of how it works suit a careful practice. You apply for a place in a builder's program, and the builder decides whether to accept, so they can take on firms they are able to support. Once accepted, you get an Access Card with the link to the builder's own product, any access code, and first steps. LetsBeta does not host the software, which means the data-location questions above go straight to the builder.
The two reports are where your reconciliation comparison belongs. The mid-trial report is a good moment to send the discrepancies you have found, while the builder still has time to explain or fix them. The end-of-trial report asks whether you would pay, what a fair price is, and for a rating out of five. Each listing also shows the full price, the early-adopter price, how long the discount lasts and what happens after, so you can work out practice-level costs before you commit a single client.
Trying software costs Early Adopters nothing, with up to three trials in progress at once. If the tool you want does not exist yet, post what you need and let builders come to you.
A note for builders of bookkeeping software. Practices will forgive a missing report. They will not forgive a reconciliation that does not tie out or an export that traps their clients. Give your beta firms a written comparison method, ask them for their discrepancies, and treat every one as a priority bug. The structured feedback templates guide covers how to ask, and payroll-adjacent builders should read the HR and payroll trial guide as well.