How we test and review software
Last reviewed 14 September 2026 · Version 1.0
Most software reviews are written from the vendor’s own marketing page. Ours are written from an account we opened, a company file we set up, and a list of tasks we ran ourselves. This page describes exactly how that works, so you can judge our conclusions instead of taking them on trust.
Our four rules
We do not review software we have not used. We run the same task list on every product in a category, so comparisons mean something. We state what we could not test instead of guessing. And no vendor pays for coverage, sees a review in advance, or influences a score.
The standard task list
The problem with most comparisons is that each product is assessed on whatever the reviewer happened to try. We fix that by running an identical set of tasks on every product in a category, timing them, and recording where things went wrong.
For accounting and bookkeeping software, the list is:
- Create an organisation from scratch and complete initial setup
- Import a chart of accounts
- Import three months of bank transactions, or connect a live feed where one is available in our region
- Raise and send an invoice, including tax treatment
- Record a supplier bill and mark it paid
- Reconcile a batch of transactions, including one deliberate mismatch
- Run a profit and loss statement and a balance sheet
- Add a second user and check what permissions can be restricted
- Export the complete dataset and inspect what actually comes out
- Find the cancellation path and read what happens to the data afterwards
The last two matter more than any feature list. Software that is easy to enter and hard to leave is a risk, and it is the thing vendors are least willing to document.
What we score, and how much it counts
Every review produces a score out of 10, built from six weighted criteria. The weighting is published so you can disagree with it. If pricing matters more to you than integrations, you can read the component scores and reach a different conclusion from ours.
| Criterion | Weight | What we look at |
|---|---|---|
| Core capability | 25% | Whether the product does the job it claims, tested against the task list above |
| Setup and daily use | 20% | Time to first useful output, clarity of the interface, how much prior knowledge is assumed |
| Pricing and value | 20% | Real cost at realistic usage, what sits behind higher tiers, add-on fees, transparency of the pricing page |
| Integrations | 15% | Connections to banks, payment providers and the other tools a business already runs |
| Support and documentation | 10% | Quality of official documentation, and the response we get to a real support question |
| Data portability and security | 10% | Export formats and completeness, user permissions, two-factor authentication, published security practices |
What the numbers mean
| Score | Reading |
|---|---|
| 9.0 to 10 | Best in its category. We would use it ourselves and recommend it without qualification. |
| 7.5 to 8.9 | Strong. Does the job well, with trade-offs we can name. |
| 6.0 to 7.4 | Adequate. Works, but a specific weakness will matter to some readers. |
| 4.0 to 5.9 | Weak. Only worth considering for a narrow use case we will describe. |
| Below 4.0 | We would not recommend it, and we explain why. |
We do not grade on a curve and we do not reserve high scores. If three products in a category deserve an 8, all three get an 8.
The review process, step by step
Define the job
We decide which reader the review is for before we open the product. A sole trader raising twenty invoices a month and a firm running payroll for thirty staff need different answers.
Open a real account
We sign up as an ordinary customer, on a trial or a paid plan, and we say which in the review. We do not accept vendor-provisioned demo accounts, because they are configured to show the product at its best.
Run the task list
Every task above, in order, with a stopwatch and notes. We record what failed, what needed a support article, and what we could not complete at all.
Verify the pricing
We check every price against the vendor’s own pricing page on the day of writing, note the currency and the region it applies to, and look for the costs that appear only at checkout.
Test support
We send one genuine question through the normal support channel as an ordinary customer, without identifying ourselves as reviewers, and record what came back and how long it took.
Test the exit
We export everything, open the export outside the product, and check the cancellation terms. A review that ignores this is not finished.
Score against the rubric
Each criterion is scored from the recorded evidence, not from impression. Where evidence is missing, the review says so rather than filling the gap.
Editorial review
A second person checks every factual claim, price and screenshot before publication, under our editorial policy.
Re-check on a schedule
Pricing pages are re-verified periodically and after any vendor pricing change we become aware of. The date on the article shows when it was last checked.
What we accept from vendors, and what we do not
Acceptable
- Publicly available trials and free tiers
- Published documentation and release notes
- Answers to factual questions we put in writing
- Corrections, when supported by evidence
Never
- Payment for a review, a score or a ranking
- Advance sight of a review before publication
- Vendor-written or vendor-edited copy
- Pre-configured demo accounts in place of our own
- Removal of an accurate negative finding
On affiliate links. We earn commission on some signups, and that funds this work. Commission rates are not a scoring criterion, they are not visible to the person writing the review, and products that pay nothing are reviewed and ranked on the same basis as those that pay well. Our affiliate disclosure sets out the arrangement.
What we cannot test
Being honest about the limits is part of the method, not a caveat bolted on at the end.
- Scale. We test with realistic sample data, not with years of a real company’s records. Performance at high volume is something we report from documentation and user evidence, clearly labelled as such.
- Every integration. We test the connections most readers need. Where we have not tested one, we do not claim it works.
- Regional availability. We test from India. Bank feeds, tax modules and payment providers differ by country, and some are unavailable to us. Where a feature could not be tested from our region, the review says so.
- Long-term reliability. A review reflects weeks of use, not years. We update articles when sustained problems emerge.
- Your compliance obligations. We do not verify that a product satisfies the regulations that apply to your business. That is a question for your accountant, as set out in our disclaimer.
Who does the testing
Reviews are written by named members of our team, each with a profile you can read. The person who tested the product is the person whose name is on the article, and a second person checks the work before it goes live.
Our team of seven covers research, testing, writing and editorial review. More about the publication and the people behind it is on our about page.
Tell us when we are wrong
If a price has changed, a feature has moved, or we got something factually wrong, tell us at contact@thesoftwarescribe.com with the article URL and what is incorrect. We check it against current documentation, correct the page, and note the change. That process is described in our corrections policy.
This methodology is versioned. When we change how we test or how we weight scores, we update the version number and date at the top of this page rather than revising it silently.