Choose the PHP Ledger evaluation for your role

The person maintaining the server, the person reviewing the books and the business owner have different questions. Bring their answers together before adoption.

These guides describe a development preview and its boundaries. They do not create a hosting service, accounting approval or a commitment that unfinished modules are available.

Which guide should you open?

Start with your own responsibility, then share the unanswered questions with the other people involved.

Why should the roles agree?

A technically successful installation may still lack a workflow the business needs. A useful accounting demonstration may still need a recovery plan.

Agree the tasks being evaluated, the expected results and the person responsible for each decision. Use fictional records first. Keep required operational modules distinct from internal foundations, and keep a future roadmap item distinct from a feature the team can use now.

What should the team inspect together?

Follow one source through posting, reporting, correction and recovery rather than judging isolated screens.

• A simple supported receipt or expense with a predicted balance.
• The source and journal trail behind the account ledger.
• A correction that preserves the original history.
• A scoped user who must be denied an unauthorised action.
• A backup and restore plan owned by a named operator.

Use the bookkeeping lessons when terminology is unclear and the worked guides when a product path needs explanation. The glossary distinguishes concepts such as a general ledger, an open item and a completed business module.

How can a small team divide the evaluation?

Give each person a concrete result to demonstrate, with the same fictional transactions used throughout.

The business owner can write a short list of essential daily tasks, including the exceptions that cause delays today. The accountant can specify expected journals and report balances for supported examples. The operator can record installation steps, access boundaries and a recovery exercise. One person may hold several roles, but the questions still need separate answers.

For example, begin with 1,000.00 of cash income and a 125.00 cash expense, without opening balances or other activity. The reviewer expects 875.00 cash and profit. The owner checks whether the entry and correction steps are understandable. The operator checks whether the same records can be restored in an isolated test installation. Record any difference before moving to a more complex case.

Who should record the final decision?

Name one person to gather the findings, while keeping accounting, operational and business acceptance explicit.

A useful decision record names the release tested, the tasks completed, unresolved problems and who will maintain the installation. Include a date to review missing capabilities again. If invoicing is essential and unavailable, mark that requirement as unmet; an internal schema does not close it. If restoration was skipped, record it as untested. These notes make a later evaluation faster and prevent an attractive demonstration from becoming an accidental commitment.

What remains outside this release?

Version 0.4.0 includes core AR/AP screens, optional Purchasing and Inventory, and manually configured tax. Tax filing, advanced warehouses and complete statutory statement packages remain unfinished.

Read the exact product scope and hosting requirements together. A queue without an enabled connector is not a delivered integration, and a party record is not a customer invoicing workflow.

When PHP Ledger is not the right choice

If an essential task is missing or the team cannot maintain self-hosting, use another system while evaluating this project separately.

The comparison library helps frame that decision. No one needs to replace a working system merely to participate in a preview. A documented decision to wait is a valid result of a careful evaluation.