16 September 2026 · Development preview

Foundations for customer and vendor accounting

PHP Ledger 0.3.0 prepares the accounting structures that invoices, bills and settlements will need. The familiar cash workflows and scoped read connections remain available.

What changed in the ledger?

Each journal line now preserves its currency, original amount, exchange-rate snapshot and functional-currency amount.

Domestic lines use the book currency and a rate of one. Exact arithmetic avoids binary floating-point money. Manual rate records are append-only; rate providers, period-end revaluation and consolidation are outside this release. Company and account properties prepare those later capabilities without presenting them as operational features.

A shared party model supports customer and vendor roles on the same identity, with contacts and entry-time identity deduplication. Vetting states and their immutable transition log are present as a schema foundation. Vetting enforcement, vendor bank change control and external connectors remain future work.

How do corrections preserve history?

A correction retains the document identity and links a dated reversing entry to the original posting and corrected repost.

The original journal remains immutable. Cancellation defaults to the cancellation date; an owner-permission exception may use the original posting date while that period remains open; reconciliation restrictions still apply. This avoids renaming the source document to create its correction. Reports can follow the effective posting while the full chain remains inspectable.

The open-item ledger is the authoritative source for remaining receivable and payable amounts. The settlement service handles partial and final allocations and realised exchange differences, including an explicit actual-rate override. These are posting mechanics for the next document milestone. The release does not add invoice, bill, payment-allocation or ageing screens.

Which technical checks passed?

The release evidence covers exact money, financial controls, installation, upgrades and recovery on specified runtimes.

The versioned validation record describes the local tests and their boundaries. The public demo remains synthetic. Passing technical checks is not an accounting opinion, a security certification or evidence of every real business workflow.

How should you upgrade?

Preserve the matching code, database, configuration and private files, rehearse restore, then follow UPGRADE.md in maintenance mode.

Keep all seventeen migration files unchanged, including the two distinct historical 006 files. Four new migrations, 013–016, add these foundations. Stop web traffic and workers while upgrading, run preflight before and after migration, and inspect the effective-source views using the intended restricted web account. The included guide explains stable view definers and recovery from interrupted schema work.

The downloadable ZIP is 3,091,799 bytes. Its SHA-256 is 6b335fa3e6a9699cb775b081570749981e7491068a2ef5221996b48fa27b76e4. These facts refer to the published 0.3.0-preview package. A website update never upgrades your own installation.

What comes next?

The next product milestone makes parties, invoices, bills and allocations usable through permissioned operator workflows.

Those documents must post through the existing central service and reconcile to authoritative open items and general-ledger control accounts. Opening unpaid-document evidence needs explicit conversion without posting the opening amount twice. Partial settlements, reversals, closed periods and repeated requests must remain traceable.

For now, evaluate the implemented cash and reporting journey using the worked guides. Choose an established operational system if your business needs invoicing, stock valuation or statutory tax filing immediately. Follow the roadmap for bounded implementation and acceptance updates.