Compare accounting software by the work it must do

Start with documents, people and review obligations; then compare licences, hosting requirements and product features.

Key takeaways

The best shortlist excludes applications that cannot complete your required workflows, however attractive their other features are.

• A journal, invoice app, personal ledger and ERP solve different problems.
• Self-hosting does not prove open-source licensing, offline operation or legal compliance.
• Test corrections, period boundaries and restoration as well as normal entry.
• PHP Ledger is a development preview with core invoice/bill/payment workflows, optional one-location Inventory and Purchasing, and a manually configured tax engine. Advanced operations, regional filing and independent acceptance remain outside its scope.

Which comparison should you read first?

Choose the page closest to your current system or your strongest operational requirement.

What counts as a required workflow?

A requirement describes a complete task, its exceptional cases and the evidence another person needs to review it.

Writing “invoicing” on a checklist is too broad. State whether an invoice needs deposits, partial payments, foreign currency, credit notes, approval, delivery references or electronic submission. State who creates it, who reviews it and which report must reconcile afterward. The same applies to purchases and stock. A business may be small while its transaction requirements are complex. The number of employees alone is not a useful measure of accounting scope.

Use examples whose expected result is known. A synthetic sale followed by a partial payment and a return tells you more than an empty dashboard. Keep unsupported cases visible in the evaluation. If a required task can only be completed in a spreadsheet, name that dependency and its reconciliation procedure. A manual handoff can be deliberate, but it should not be discovered after migration.

How should licensing be compared?

Read the licence attached to the selected version and distinguish core terms from apps, assets and commercial agreements.

The Open Source Initiative's approved-licence list, checked on 16 September 2026, helps distinguish open-source licences from other source-available arrangements. Licence permissions do not certify application quality. They answer questions about use, modification and redistribution. A hosted accounting practice may have different obligations from an individual running an unmodified copy. Confirm those obligations before designing the service around a product.

Our comparison pages link the checked project sources rather than reproducing an old category label. In particular, the current PHP Ledger core is AGPL-3.0-or-later, and older MIT releases retain their original terms. Akaunting's checked BSL file includes production-use restrictions and a future change licence. A summary should never erase version-specific terms or substitute for advice on an unusual legal arrangement.

What makes a hosting comparison useful?

Compare the entire maintained installation, including the database and recovery process, rather than the headline programming language.

A PHP version selector does not establish database compatibility, private configuration or command access. A Docker image does not establish a backup procedure. Ask the operator to document the runtime, database, persistent storage, update route and recovery owner. For PHP Ledger, the tested requirements include MySQL 8.4 and PHP 8.2 or newer. Those details matter more than a claim that an application runs on ordinary hosting.

Separate measured findings from assumptions. We have not run a common load benchmark across these products, so the comparisons do not promise specific hardware savings or response times. Minimum installation requirements also differ from practical production capacity. A test should use a realistic dataset, concurrent roles and a representative report, then record the environment so another operator can reproduce the result.

Which controls deserve a live demonstration?

Demonstrate how the system rejects, corrects and recovers records, as well as how it creates them.

1. Trace one source document into its double-entry accounts and reports.
2. Repeat the same posting action and inspect duplicate protection.
3. Correct an intentional mistake and preserve the original explanation.
4. Try a posting in a closed period with the relevant roles.
5. Reconcile a bank or control-account balance to its detailed records.
6. Restore an isolated backup and repeat the review.

These are evaluation proposals, not a claim that every competitor has passed them. Record the exact version, edition, options and manual steps. A balanced trial balance is necessary but cannot detect every omitted or misclassified transaction. The reviewer must be able to reach the original record and explain why it belongs in the reported period.

Where PHP Ledger loses

Several established alternatives offer business workflows that the current preview does not yet provide.

Manufacturing, advanced inventory and regional tax integration are decisive requirements for many teams. PHP Ledger does not replace those processes. Its starter includes invoices, bills, payments and optional stock workflows, but that bounded coverage is not a full ERP application. It also makes no stable-release or jurisdiction-compliance assurance. These are reasons to select another product when the missing functions are required now.

The preview is worth evaluating when a small, inspectable PHP accounting core is the intended scope and the operator accepts its limitations. It is not a reason to abandon a working, reconciled installation. Start with a configuration or upgrade review when the existing product already supports the work. Migration should solve an evidenced problem, not merely change the appearance of the same problem.

How are these comparisons maintained?

We use dated primary documentation for product facts and label interpretation, missing evidence and preview boundaries.

Verified documentation

A linked project source checked on the date shown, without claiming an installed benchmark.

Evaluation advice

A proposed method for testing fit, distinct from a report that a product passed the test.

Unverified behavior

A fact that was not established, such as an installed product's network traffic or a jurisdiction-specific acceptance result.

The research survey explains the selection method and limitations. It deliberately avoids equating repository stars with customers, or a product's published tax field with statutory approval. If a claim cannot be supported by a primary source, it is omitted or identified as unresolved. Product documentation can change after the check date, so confirm material terms again before committing.

Questions and next step

Choose a shortlist, test the required cases and retain a written explanation for the eventual decision.

Read the relevant comparison above, then the PHP Ledger release notes if its preview fits. Use synthetic data first and preserve the current system until the new process and its recovery procedure are accepted. All competitor documentation checks on this hub refer to 16 September 2026; the child pages provide the specific sources.