Choose your role

PHP Ledger for accountants: what to inspect before adopting it

Evaluate the posting trail and the missing workflows before the interface. The useful question is whether you can explain a balance and reproduce the evidence behind it.

PHP Ledger is a development preview with an inspectable accounting core. The 0.4.0 starter adds invoice and bill screens, partial payments, credits and ageing; statutory reporting and qualified accounting sign-off remain separate gates.

Which engagement could fit an evaluation?

A bounded technical evaluation can fit a practitioner who wants to inspect the core and can keep the exercise separate from client production records.

Begin with a synthetic business whose assumptions you control. Record a completed service receipt, an operating expense, an opening scenario and a correction. Predict the expected journals and reports before using the application. This gives the evaluation a testable purpose. Browsing attractive screens without an expected result tells you little about recognition, reconciliation or the consequences of an error.

A client who needs customer invoices, supplier payment runs, inventory costing or a supported tax connector immediately has different requirements. Do not treat the presence of general journals as an acceptable substitute for every missing operational module. Manual workarounds can create the very reconciliation problems the software is meant to help you avoid.

Can you follow a balance back to its source?

Inspect the chain from report to account ledger, journal and original source, including the selected company, book and dates.

A trial balance is useful only within a defined scope. An account ledger should explain its opening, movements and closing balance even when its transaction list is paginated. Check an inactive account with historical activity as well as an active one. A filter should not quietly change the population underlying a running balance.

The daily cash example uses original synthetic figures: a 1,000.00 completed service receipt and 125.00 operating expense leave 875.00 cash under the stated assumptions. Use those amounts as a small control, then add a separate loan receipt and explain why cash changes without additional service profit.

What does immutable posting protect?

It preserves the accounting history that earlier reports and reviews relied upon, while corrections remain explicit.

Try a wrong amount in a fictional posted expense. Inspect the linked reversal rather than changing the posted row. The current foundation supports same-source-identity correction mechanics for supported sources, with distinct posting revisions. Default reversal dates follow cancellation; the original-date exception needs the required authority and an open period. That engineering design supports traceability but does not decide the appropriate reporting treatment for every prior-period error.

Test retries as well as happy paths. A repeated identical request should return its durable result. Reusing the same request identity with changed content should fail. A network interruption is not evidence that the original operation failed to commit, so duplicate prevention belongs in the evaluation.

How should opening balances be reviewed?

Review the chart mapping, cutoff convention and supporting schedules together before confirming the opening.

The current cutover holds balances at the close of the accounting start date; later ordinary activity uses a later date. Confirm that this matches the source population you prepared. Unpaid customer and supplier schedules support the opening control balances. They must not produce a second recognition of old income or expense. A zero opening should also be explicit rather than inferred from missing input.

The internal open-item foundation activates unused control accounts only. It does not migrate historical free-text party names into new parties or convert an existing opening register automatically. If a client has retained AR/AP control balances, the later transition needs a reviewed reconciliation. That is a material adoption boundary, not an import convenience to solve with name matching.

What does the currency foundation prove—and not prove?

It establishes transaction/base storage, frozen rates and bounded realised-settlement mechanics; it does not complete period-end or group reporting.

The release stores foreign amounts and base amounts on journal lines, supports account currency designation and preserves manual rate provenance. Internal settlement mechanics include an actual-rate override and exact carrying-value relief. Partial allocations preserve the final residual rather than inventing a new balance calculation. Those are useful foundations to inspect with worked cases.

Period-end revaluation, group consolidation, presentation-currency statements and provider rate feeds remain outside the release. Outgoing settlement from a foreign-denominated bank is also restricted pending its carrying-value allocation. Do not describe the application as a complete multi-currency accounting package on the strength of the new columns alone.

How should period and bank controls be tested?

Test that a completed control cannot be invalidated by an ordinary later action without the appropriate reviewed path.

Post into an open period, close it and verify that new postings are rejected. Inspect the owner-controlled reopening process and retained reason. A period lock is one control; it does not establish that accruals, valuations, tax work or disclosures are complete. Keep the accounting close checklist separate from the software status.

For bank reconciliation, compare a supported statement row to a posted line and inspect the completion evidence. The current model is one statement row to one exact-amount journal line. Split and aggregate matching are not implemented. A bank match does not post a missing expense; that entry must go through the reviewed posting path before matching.

Which access boundaries matter for a practice?

Each client company and book must remain scoped to authorised users and connections, including read-only integrations.

Test with different memberships, not only the installation owner. A viewer should not post. A user authorised for one company should not retrieve another company’s records by changing an identifier. The read API/MCP layer uses existing identity and explicit company/book grants; it is not an autonomous financial-write interface.

Keep tokens and client data out of screenshots, issue reports and ordinary debug logs. A useful defect report can use a minimal synthetic reproduction while retaining the exact failure condition. Independent security review remains separate from the project’s automated access tests.

What evidence should an acceptance note contain?

Record the exact scope, expected results, observed results and untested cases instead of issuing a general approval based on a demo.

Distinguish a successful installation from accounting acceptance. Distinguish accounting review from a legal conclusion about a reporting framework. If a case cannot be evaluated, record why and what would establish it. That gives the owner a usable decision rather than a vague “looks good.”

When PHP Ledger is not the right choice

Wait or choose another product when the engagement requires advanced stock operations, tax transmission, issued statutory statements or independently supported production workflows now.

Review the ERPNext comparison for a broader-suite evaluation and the FrontAccounting comparison for another accounting-focused option. Verify each candidate against the actual engagement. The right recommendation may be to keep a working system while testing this foundation separately.

Coordinate the decision with your team

Read the companion guidance for accountants, for software houses and for business owners. A workable installation needs agreement between the person maintaining it, the person entering records and the person reviewing the accounting.

Project evidence

This guide describes the inspected repository and release scope as of 16 September 2026. The project repository, release package and product scope are the primary project references. Technical tests do not establish accounting approval, independent security review or a service commitment.