Accounting software: the properties nobody actually demonstrates

Every accounting package demos well. The invoice looks good, the dashboard has a chart, the bank feed pulls in transactions while you watch. None of that is what you will care about in three years.

What you will care about is whether you can prove what happened, whether you can leave with your data, and whether the person who processes payments can quietly change them. Those are properties you have to go looking for, because no vendor leads with them.

This is a list of what to demand of any package, and how to test each demand during a trial rather than discovering it later.

What to take away

1. An audit trail you cannot switch off

The point of an audit trail is that the record of what happened survives someone's preference for it not to have happened.

A usable one records, for every change: who made it, when, what the value was before, and what it became. It covers posted transactions, not just user logins. It cannot be cleared by a user, including the account owner. And crucially, it treats deletion as an event to be logged rather than an absence to be left unexplained.

How to test it in a trial. Post an invoice. Change its amount. Change its date. Change the account it was coded to. Delete it entirely. Then go looking for all four events. If you can find only the current state, or only a vague "modified" flag with no before-value, you have a system that cannot answer questions about its own past.

Then repeat the whole test as a second user with restricted rights, and check that the trail names the right person.

2. An export you own

Assume, as a planning premise, that one day you will leave: through a change of provider, a price change, a merger, or a product being retired. The question is what you take with you.

What to demand:

Verify that the export includes customers, suppliers, the chart of accounts, opening balances, the full general ledger, and documents attached to transactions. Check that you can open the exported files locally and use the records outside the package.

How to test it. Do a full export on the first day of the trial, before you have invested any effort. Open it. Look for whether the attachments came too. An export you have not opened is not an export you have.

For federal tax recordkeeping, consult IRS Publication 583, Starting a Business and Keeping Records. Retention depends on the record and the circumstances, so do not assume one blanket retention period applies to every document.

3. Controls that assume more than one person

Even a two-person business needs the system to distinguish roles, because the alternative is that everyone can do everything and nothing can be attributed to anyone.

The permissions worth checking are narrower than “admin” and “user.” Ask whether a restricted role can be prevented from doing each of these:

How to test it. Create a restricted user and genuinely try to misuse the account: change a supplier's bank details, delete a posted transaction, grant yourself more rights. Everything you succeed at is something an employee, a contractor or an attacker with those credentials can also do.

4. Periods that can be closed

Once you have reported a month to a lender, an investor or a tax return, that month should stop moving.

Demand a lock that prevents dated entries into a closed period, a defined, restricted way to reopen it, and a log entry when that happens.

Then test how the system handles a transaction someone tries to date into a locked period. A good system refuses or diverts it; a bad one posts it silently, and last month's report quietly becomes a different report.

How to test it. Close a period. Run the balance sheet. Try to post into the closed period. Run the balance sheet again and compare it to the copy you saved.

5. Reports that reproduce

This is the demand most people never think to make, and it is the one that causes the most trouble.

Can you re-run last month's profit and loss statement today and get the numbers you got last month? If the answer is no because someone backdated an entry, that is a period-locking problem. If the answer is no because the report is built differently now, that is worse.

Beyond that, insist on the plumbing rather than the dashboards:

reports should be reproducible later using the same cutoff date and settings. Also check whether you can rerun a prior-period report with the same dates and filters, and identify which transactions or settings explain any changed figures.

6. Bank feeds treated as convenience, not truth

A feed saves typing. It does not reconcile anything and it is not a source document.

Test what happens when a feed duplicates a transaction, when it is disconnected and reconnected, and when a date range is re-imported. Check that you can reconcile against a bank statement item by item rather than merely matching a closing balance, and check that the reconciliation is a record you can go back to, not a screen state.

Rules that auto-code transactions are useful and quietly dangerous: they will code a mis-typed payee to the wrong account forever without anyone deciding to. Whatever the system offers, make sure you can list every rule and see which transactions each one touched.

7. Documents attached to the transactions they explain

A receipt in a shoebox and a receipt attached to the transaction are different assets. Attaching the document at entry is the habit the expense recording guide is built around.

Ask what file types are supported, whether there is a size or count limit, and whether attachments are searchable. Ask again whether they come out in the export.

Record the supported file types and the exact size and count limits for the plan you are considering. Test a typical receipt or invoice, search for it after attaching it, and confirm that it appears in the export.

8. The questions to put in writing before you commit

Answers by email are worth more than answers in a sales call.

What none of it does

Software applies the rules it has been configured with. It does not know that a payment was for a personal expense, that an invoice was raised for work not yet done, or that a receipt is for a supplier that no longer exists.

Automated tax calculations, filing features and compliance prompts are conveniences built on assumptions about your circumstances. They are not advice, and the responsibility for the return does not transfer to the vendor.

Configuration decisions belong to an accountant who knows your entity: which tax treatments apply, how the chart of accounts is structured, and what accounting basis the books are kept on. A bookkeeper's judgment covers whether the system is being used consistently and whether the records support the reports. It stops at whether the rules being applied are the correct ones.

The short version

Before you commit to a package, run four checks yourself. Find a deleted transaction in the audit trail and open a full export on your own machine.

Fail to do something as a restricted user and rerun a prior-period report to get the same answer twice. If any check fails, you know which operational risk remains, even if the subscription itself looks affordable.

Common questions